Il est temps d'aborder le sujet des blocages et du Shift Left - Lacework

Chère sécurité, il est temps de parler blocage et Shift Left

Editorial Lacework

June 11, 2020

La nécessité d'innover n'a jamais autant pesé sur les équipes logicielles, poussant les entreprises à adopter la livraison continue et l'automatisation. Si l'on a beaucoup écrit sur la nécessité d'une étroite collaboration entre DevOps et sécurité, en pratique, peu d'équipes sont satisfaites du résultat. Après avoir côtoyé différentes entreprises, qu'elles soient grandes ou petites, nationales ou internationales, j'ai identifié un certain nombre de situations dans lesquelles les équipes se retrouvent bloquées. 

J'ai passé la majeure partie de ma carrière dans le domaine de la technologie et de l'ingénierie des systèmes, mais ces dix dernières années, j'ai concentré mon travail sur l'automatisation des applications et des infrastructures, ainsi que sur la livraison continue. Les équipes de sécurité ont souvent joué un rôle auxiliaire dans ces projets d'automatisation, mais j'ai grandement travaillé main dans la main avec les développeurs et les ingénieurs de production. Depuis que j'ai rejoint Lacework en fin d'année dernière, j'ai eu l'opportunité de collaborer avec beaucoup plus d'équipes de sécurité qu'à n'importe quel moment de ma carrière, ce qui m'a ouvert les yeux sur les défis auxquels elles sont confrontées dans le cadre d'un environnement en évolution rapide.

Attendez… Ne me dites pas que vous appliquez des modèles de sécurité hérités à un cloud moderne ?

Le mouvement « Shift Left », qui insère des tests et des barrières de sécurité plus tôt dans le cycle de développement, est une méthode qui a prouvé son efficacité dans la réduction des risques, des coûts de résolution des bugs et des vulnérabilités durant la production. En 2016 déjà (une éternité dans le secteur des technologies), le rapport State of DevOps notait : « Les équipes très performantes passent 50 % de temps en moins à remédier aux problèmes de sécurité que les équipes peu performantes. En intégrant mieux les objectifs de sécurité de l'information aux tâches quotidiennes, les équipes atteignent des niveaux de performance informatique plus élevés et construisent des systèmes plus sûrs. » Plus qu'une bonne pratique, une production correctement mise en œuvre et axée sur le Shift Left pourrait permettre de relever la plupart des défis de sécurité auxquels nous sommes confrontés aujourd'hui. En pratique, le Shift Left n'est qu'un des éléments à prendre en compte parmi tant d'autres, mais nous y reviendrons plus tard.

Si l'on compare l'approche moderne du Cloud aux processus de sécurité traditionnels, on constate que les utilisateurs dépendent d'outils qui entravent les développeurs ou les services par le biais de politiques centralisées, et que la modification de ces politiques implique souvent l'ouverture de tickets d'assistance, voire d'une soumission auprès d'un archaïque comité d'approbation des changements, ce qui retarde la mise sur le marché et ajoute des tensions.

Malheureusement, les répercussions de cet état d'esprit de blocage se font toujours sentir. L'une des questions les plus fréquentes que me posent encore les équipes de sécurité est la suivante : « Est-ce que Lacework propose des capacités de blocage ? » Après avoir interrogé de nombreuses équipes, j'ai appris que cette question avait un sens différent selon les entreprises, mais qu'il existe un cas d'utilisation commun : le processus de génération des containers. La question étant : si le container contient des vulnérabilités, Lacework bloque-t-il la génération ou le déploiement ? Elle est toujours source d'échanges passionnés, mais aussi d'un débat de fond.

Le problème ne se résume pas à une question fermée de type « Votre plateforme bloque-t-elle ? ». Dans le cas des vulnérabilités, la réponse ne se limite pas à un simple oui ou non, car vulnérabilité et risques sont deux choses différentes. Les équipes de sécurité qui souhaitent aider leur entreprise à passer au Shift Left ne doivent pas chercher de moyens de bloquer les développeurs. C'est non seulement oublier les résultats obtenus grâce à la livraison et l'automatisation continues, mais, plus important encore, c'est passer à côté d'une bonne occasion de se plonger dans l'un des domaines les plus fondamentaux où les élites excellent, à savoir la collaboration. L'important ici n'est pas de se concentrer sur le blocage, mais sur la fourniture de données permettant de prendre la décision de bloquer ou non.

Combler le fossé organisationnel grâce aux données

Si l'on se penche à nouveau sur les défis de la sécurité spécifiques à la création et au déploiement de containers, de nombreux facteurs doivent être pris en compte, et le fait de savoir qu'il existe des vulnérabilités ne suffit pas pour décider d'un blocage. À quel moment du processus voulez-vous bloquer ? Voulez-vous empêcher les développeurs de créer/publier un container s'il y a une vulnérabilité (d'après mon expérience, ce n'est pas une stratégie gagnante) ou souhaitez-vous empêcher le déploiement d'un container s'il présente une vulnérabilité ? Préférez-vous empêcher les containers d'être déployés dans n'importe quel environnement, ou certains environnements doivent-ils être traités avec plus d'attention que d'autres (PCI, SOC 2, HIPAA) ?

Analyser les vulnérabilités elles-mêmes nous permet d'identifier la quantité de vulnérabilités de niveau critique, élevé, moyen, faible ou informatif. Combien de ces vulnérabilités ont été corrigées ? Le service fonctionne-t-il dans un environnement de production ? Quelle est la probabilité que cette vulnérabilité soit exploitée, et quel est l'impact sur l'entreprise si elle l'est ?

Est-il rentable de consacrer des cycles de développement à chaque vulnérabilité ?

Les mises en œuvre réussies du Shift Left tiennent compte du contexte plus large du service et de la manière dont il est déployé en production. J'ai récemment discuté avec une cliente, responsable de la résolution des vulnérabilités des containers dans un très gros environnement cloud. Elle a expliqué que, pendant que leur solution d'analyse des vulnérabilités des containers existante alertait l'équipe des vulnérabilités pendant le processus de génération, sans qu'ils ne puissent comprendre où ces services étaient exécutés, elle et son équipe ont passé leur temps à faire de la « science des données de m... » pour calculer le risque. Tout cela montre que nous avons besoin de plus de données pour prendre des décisions sur les priorités en matière d'ingénierie, et que nous avons besoin de beaucoup plus de collaboration entre les équipes.

Les développeurs et les ingénieurs de production s'appuient sur le code, l'automatisation et les pipelines de livraison continue pour faire leur travail. Ils ont recours à des tests automatisés pour exécuter et prendre des décisions. Ils recherchent des API robustes qu'ils peuvent intégrer et à partir desquelles ils peuvent créer des tests automatisés afin d'avancer rapidement et efficacement. Mais n'ayez crainte, la rapidité et l'efficacité ne sont pas incompatibles avec la sécurité. Lorsque l'on passe au Shift Left, la clé n'est pas le freinage ou le blocage : il s'agit de fournir l'accès aux données qui permettront de prendre des décisions automatisées en matière de sécurité et de risque afin que nous puissions continuer à prendre ces décisions.

Une plateforme de données pour stimuler le changement

Lacework est avant tout une plateforme de données massivement évolutive et flexible. Les données que nous capturons, organisons et présentons à nos clients sont spécifiquement conçues pour aider à combler le fossé entre la sécurité et DevOps, afin que les organisations puissent fonctionner à très grande vitesse, sans compromettre la sécurité. Mais au-delà des capacités de sa plateforme, Lacework s'engage à aider ses clients à faire aboutir leurs projets en mettant l'accès sur les modèles les plus réussis afin d'aider les équipes à collaborer et à fournir une valeur continue sans sacrifier la sécurité.

L'évolution du DevSecOps qui se profile

Les équipes de sécurité doivent commencer à réfléchir à une refonte du blocage. Il ne s'agit plus de chercher des outils pour fournir un blocage en tant que fonctionnalité. Le DevSecOps repose davantage sur une culture de collaboration que sur la technologie. Prenez le temps d'échanger avec vos développeurs et ingénieurs de production, et comprenez comment ils développent et livrent leurs services. Essayez de leur fournir les données de sécurité pertinentes dont ils ont besoin pour tester et évaluer en permanence le risque lié au déploiement de ces services. Mesurez non seulement vos propres résultats en matière de sécurité, mais aussi votre capacité à faire en sorte que votre entreprise offre de nouvelles fonctionnalités à vos clients avec rapidité et efficacité. C'est ainsi que nous pourrons tous atteindre nos objectifs, apprendre et évoluer.

 

Photo via Ilario Piatti on Unsplash