Au cours des deux dernières décennies, nous avons vu la sécurité devenir de plus en plus granulaire, allant plus loin dans la pile génération après génération : du matériel au réseau, au serveur, au conteneur et maintenant de plus en plus au code.
Il doit être axé sur les données. Tout d’abord.
La prochaine frontière en matière de sécurité concerne les données, en particulier les données sensibles. Les données sensibles sont les données que les organisations ne veulent pas voir divulguées ou violées. Cela comprend les données PHI, PII, PD et financières. Une violation de données sensibles entraîne de réelles sanctions. Certaines sont tangibles, comme les amendes GDPR (10 millions d’euros ou 2 % du chiffre d’affaires annuel), les amendes FTC (par exemple, 150 millions de dollars contre Twitter) et frais juridiques. Viennent ensuite les coûts intangibles, tels que la perte de confiance des clients (par exemple, Chegg exposé données appartenant à 40 millions d’utilisateurs), la douleur de la restructuration, et pire encore.
>>Ne manquez pas notre numéro spécial : L’agenda du CIO : la feuille de route 2023 pour les responsables informatiques.<<
Les technologies de protection des données d’aujourd’hui adoptent trop souvent des approches complémentaires. Regardez la gestion des identités. Il est conçu pour vérifier qui est qui. En réalité, ces approches contiennent des points d’échec inévitables. Une fois autorisés par la gestion des identités, les utilisateurs ont carte blanche pour accéder aux données importantes avec un minimum de contraintes.
Que se passerait-il si vous placiez les données au centre de l’univers de la sécurité ?
L’un des actifs les plus précieux que les entreprises souhaitent protéger, ce sont les données, et des violations massives de données et des fuites de données se produisent trop souvent. Il est temps pour une nouvelle évolution de la cybersécurité : la sécurité des données avant tout.
Les données sont différentes
Tout d’abord, reconnaissons que les données n’existent pas dans le vide. Si vous avez eu du mal à comprendre et à respecter le RGPD, vous savez que les données sont étroitement liées à de nombreux systèmes. Les données sont traitées, stockées, copiées, modifiées et transférées par et entre les systèmes. A chaque étape, le potentiel de vulnérabilité augmente. C’est parce que les systèmes associés à ces étapes sont vulnérables, pas parce que les données le sont.
Le concept de base est simple. Arrêtez de vous concentrer sur chaque système individuellement sans aucune connaissance des données qu’ils transportent et des liens qui les unissent. Au lieu de cela, commencez par les données, puis tirez le fil. Des données sensibles sont-elles impliquées dans les enregistreurs bavards ? Les données sont-elles partagées avec des tiers non autorisés ? Les données stockées dans les compartiments S3 manquent-elles de contrôles de sécurité ? Les données manquent-elles de cryptage ? La liste des vulnérabilités potentielles est longue.
Le défi de la sécurité des données est que les données circulent presque à l’infini entre les systèmes, en particulier dans une infrastructure cloud native. Dans un monde idéal, nous devrions être en mesure de suivre les données et les risques et vulnérabilités associés sur chaque système, à tout moment. En réalité, nous en sommes loin.
La sécurité des données doit commencer dans le code. Cela signifie avec les développeurs : Décalage vers la gauche. Selon GitLab, 57 % des équipes de sécurité ont déjà déplacé la sécurité vers la gauche ou prévoyez de le faire cette année. Commencez au début du parcours, en sécurisant les données pendant que vous codez.
Mais le sale secret du décalage à gauche est que trop souvent, cela signifie simplement que les organisations poussent plus de travail sur l’équipe d’ingénierie. Par exemple, ils peuvent leur demander de remplir des enquêtes et des questionnaires qui supposent d’une manière ou d’une autre qu’ils ont une expertise dans les exigences de gouvernance des données dans les économies mondiales, les marchés locaux et les industries verticales hautement réglementées. Ce n’est pas ce que font les développeurs.
Ainsi, une approche de sécurité axée sur les données doit inclure trois éléments : 1) cela ne peut pas être un autre problème de sécurité ; 2) Il doit comprendre le contexte de propriété ; 3) Il protège contre les erreurs dans la logique métier personnalisée (toutes les failles n’impliquent pas un bogue).
Pas un autre passif de sécurité
La sécurité consiste à atténuer les risques. L’ajout d’un nouvel outil ou fournisseur va à l’encontre de ce principe de base. Nous avons tous SolarWinds en tête, mais d’autres émergent quotidiennement. Avoir un nouvel outil s’intégrant à votre environnement de production est une grande demande, non seulement pour l’équipe de sécurité, mais aussi pour l’équipe SRE/Ops. Effectuer la découverte de données sur l’infrastructure de production signifie examiner les valeurs réelles, les données des clients potentiels – essentiellement ce que nous essayons de protéger en premier lieu. Peut-être que la meilleure façon de ne pas devenir un autre risque est de ne pas accéder aux infrastructures et aux données sensibles.
Étant donné qu’une approche de sécurité axée sur les données repose sur la connaissance des données sensibles, il peut être surprenant de pouvoir effectuer cette découverte uniquement à partir de la base de code, en particulier lorsque nous sommes habitués aux solutions DLP et de gestion de la posture de sécurité des données (DSPM) qui effectuer une découverte sur les données de production. Il est vrai que dans la base de code, nous n’avons pas accès aux données réelles (valeurs), uniquement aux métadonnées. Mais curieusement, il est également très précis de découvrir des données sensibles de cette façon. En effet, le manque d’accès aux valeurs est contrebalancé par l’accès à une quantité massive de contextes, ce qui est clé pour la classification.
Aussi précieuse que soit la sécurité traditionnelle à décalage vers la gauche, une approche de sécurité axée sur les données offre encore plus de valeur lorsqu’il s’agit de ne pas représenter un risque supplémentaire pour l’organisation.
Contexte de propriété< /span>
En matière de sécurité et de protection des données, tout n’est pas noir ou blanc. Certains risques et vulnérabilités sont extrêmement faciles à identifier. Les exemples incluent un enregistreur qui fuit des PHI ou une injection SQL exposant des PD, mais d’autres nécessitent un certain niveau de discussion pour évaluer les risques et finalement décider de la meilleure solution. Nous entrons maintenant dans le territoire limite de la conformité, qui n’est jamais très loin quand on parle de sécurité des données.
Ce sont des questions auxquelles les organisations doivent répondre à un certain moment. Aujourd’hui, ces questions sont de plus en plus traitées par les équipes de sécurité, en particulier dans les environnements cloud natifs. Il est presque impossible d’y répondre et d’identifier les risques associés sans dévoiler la « propriété ».
En assurant la sécurité des données d’abord du point de vue du code, nous avons un accès direct à des informations contextuelles massives ; en particulier, quelque chose a été introduit et par . Les solutions DSPM ne peuvent tout simplement pas fournir ce contexte en examinant exclusivement les magasins de données de production.
Trop souvent, les organisations s’appuient sur une « évaluation manuelle ». Ils envoient des questionnaires à toute l’équipe d’ingénierie pour comprendre quelles données sensibles sont traitées, pourquoi et comment. Les développeurs détestent ces questionnaires et souvent ne comprennent pas beaucoup de questions. Les mauvais résultats en matière de sécurité des données sont prévisibles.
Comme pour la plupart des choses « techniques », l’approche la plus efficace consiste à automatiser les tâches fastidieuses avec un processus qui s’intègre dans les flux de travail existants avec un minimum ou pas de friction si vous êtes sérieux au sujet de la sécurité des données, en particulier à grande échelle.
Logique métier personnalisée
Comme chaque organisation est différente, les pratiques de codage et les règles associées diffèrent, en particulier pour les équipes d’ingénieurs plus importantes. Nous avons vu de nombreuses entreprises effectuer un chiffrement au niveau de l’application, un chiffrement de bout en bout ou se connecter à leur entrepôt de données de manière très spécifique. La plupart de ces flux logiques sont extrêmement difficiles à détecter en dehors du code, ce qui entraîne un manque de surveillance et introduit des failles de sécurité.
Prenons Airbnb comme exemple. Il est notoirement construit sa propre plateforme de protection des données. Ce qui est intéressant à regarder ici, c’est la logique personnalisée que l’entreprise a mise en place pour chiffrer ses données sensibles. Au lieu de s’appuyer sur un service de cryptage ou une bibliothèque tiers (il en existe des dizaines), Airbnb a créé le sien, Cypher. Cela fournit des bibliothèques dans différents langages qui permettent aux développeurs de chiffrer et de déchiffrer des données sensibles à la volée. Détecter cette logique de chiffrement, ou plus important encore son absence, sur certaines données sensibles en dehors de la base de code s’avérerait très difficile.
Mais est-ce que le code est suffisant ?
Démarrer un voyage de sécurité axé sur les données à partir du code est très logique, d’autant plus que de nombreuses informations trouvées là-bas ne sont accessibles nulle part ailleurs (même s’il est vrai que certaines informations peuvent manquer et ne se trouver qu’au niveau de l’infrastructure ou de la production.)
Réconcilier les informations entre le code et la production est extrêmement difficile, en particulier avec les actifs de données circulant partout. Airbnb montre à quel point cela peut être complexe. La bonne nouvelle est qu’avec le passage à l’infrastructure en tant que code (IaC), nous pouvons établir les connexions au niveau du code et éviter de devoir faire face à une réconciliation douloureuse.
Compte tenu des défis associés à la sécurité et aux données, chaque solution de sécurité devra devenir au moins « consciente des données » et peut-être « donnée d’abord » quelle que soit la couche de la pile dans laquelle elle existe. Nous pouvons déjà voir la posture de sécurité du cloud solutions de gestion (CSPM) se mêlant à DSPM, mais cela suffira-t-il ?
.
