Pas de stratégie DevSecOps possible sans une forte culture CI/CD dans l’entreprise, une plate-forme cloud ou On-Premise qui fonctionne et une automatisation à outrance des outils de test, de build et de déploiement.
Pour les développeurs et les exploitants, ceux qui parlent sécurité sont ceux qui disent non ! Parfois, ouvrir un simple port sur un firewall – quelques clics – a tout du parcours du combattant. Incompréhensible pour les développeurs, qui livrent leur code à rythme élevé, qu’il faille des semaines parfois des mois pour que le RSSI leur ouvre un simple port sur le firewall. Et pourtant, quand on regarde les statistiques des tentatives d’intrusion dans les systèmes informatiques des entreprises, on peut comprendre que les responsables de la sécurité soient plus que prudents et réticents à faire évoluer les protections du SI en temps réel.
À l’heure de la transformation digitale et de l’agilité triomphante, il faut revoir la façon de gérer la sécurité dans les entreprises et surtout savoir comment concilier ce besoin d’agilité et de sécurité renforcée. Ces deux notions antagonistes dans une approche traditionnelle peuvent fonctionner de concert, c’est en tout cas ce que poussent les évangélistes de DevSecOps.
Une étude bien connue du NIST et de Ponemon Institute démontre que plus un bug ou une faille de sécurité est détectée tard dans le cycle de vie de l’application, plus il est coûteux de le corriger, avec un écart de pratiquement 1 à 100 entre la phase de déploiement et la correction en phase de maintenance.
Des outils et des méthodes
Basculer dans une approche DevSecOps demande déjà une maturité forte en termes de chaîne de développement et d’intégration continue. L’entreprise doit déjà avoir automatisé tout ou au moins une grande partie de son CI/CD (Continuous Integration/ Continuous Delivery) avant d’envisager y intégrer des briques de sécurité et faire entrer dans la danse les experts de sécurité. L’un des points-clés de la démarche, c’est privilégier l’automatisation à outrance en intégrant les outils de sécurité à la chaîne d’intégration continue. On peut ainsi amener les développeurs à produire un code « Secure by Design » en lui faisant traverser une série de tests de sécurité bien avant sa mise en production ou même le build. Tout comme le debugging, la traque des failles de sécurité doit être menée au plus tôt, c’est-à-dire là où il sera le moins coûteux de les corriger. D’autres phases du cycle de vie de l’application peuvent être instrumentées d’outils de cybersécurité, qu’il s’agisse de détecter les vulnérabilités en production ou encore tisser des liens avec la Threat Intelligence ou même les SIEM vers lesquels convergent les logs de fonctionnement de l’application en production et le SOC lui-même. Pour Bertrand Méens, CTO de l’entreprise Oskab, l’intégration de la sécurité dans une plate-forme DevOps passe par la réflexion de constituer son Security Pipeline pour outiller la sécurité dans l’usine à développement : « Il est essentiel de ne plus penser à intégrer la sécurité dans les projets mais dans le cycle de vie des applications (SDLC). Le Security Pipeline intègre des outils de sécurisation (audit de code SAST/DAST, audit d’intrusion ou Bug Bounty…) pour améliorer le niveau de sécurité intrinsèque de l’application et des outils de protection (WAF, IPS voire des structures comme le SOC) pour se défendre contre les attaques indépendamment du nouveau de sécurité. » Pour cet expert, il n’existe pas un seul outil incontournable ; il faut additionner plusieurs outils et ainsi concevoir sa boîte à outils en fonction de ses besoins, de son budget et de sa maturité.
L’OWASP a référencé une série d’actions à mener tout au long du cycle de vie de l’application afin de faire tendre la chaîne d’intégration continue vers les concepts DevSecOps.
Pénurie de ressources humaines
Outiller les chaînes CI/CD est un prérequis indispensable, mais c’est encore insuffisant pour décrocher son label « DevSecOps ». En effet, il faut impliquer l’équipe de sécurité dans les équipes DevOps et cela n’a rien de simple. Impossible d’allouer un RSSI à chaque équipe DevOps afin que celui-ci assiste aux “stand-up meetings” du matin de chaque équipe en sprint. Les RSSI sont des ressources rares et chères qu’il faut allouer au mieux. Une solution souvent usitée est de désigner un développeur, qui, formé aux enjeux de la sécurité dans le code, se voit bombardé DevSecOps leader et chargé de prêcher la bonne parole et surtout les bonnes pratiques au sein de l’équipe DevOps à laquelle il appartient. Bien évidemment RSSI, Pentester, ingénieurs de sécurité vont être amenés à intervenir lors des sprints lorsque le besoin s’en fait sentir. Pour Nicolas Bousquet, Responsable Sécurité Applicative chez Octo Technology, ce Security Champion doit jouer le rôle d’ambassadeur des bonnes pratiques de sécurité dans l’équipe DevOps : « Il ne s’agit pas nécessairement d’un expert, il peut toujours s’appuyer sur l’expertise de l’équipe sécurité, mais c’est notamment lui qui va mettre à jour la gestion des risques, ajouter des exigences de sécurité dans les User Stories lorsque c’est nécessaire, ajouter des End User Stories, c’est-à-dire se mettre à la place d’un utilisateur malveillant à qui on veut interdire telle ou telle manipulation lors de chaque sprint. Cela permet d’écrire noir sur blanc le comportement de sécurité qui est attendu de l’application. »
Les principaux outils du DevSecOps
Des référentiels de bonnes pratiques DevSecOps sont apparus, notamment ceux de l’OWASP (Open Web Application Security Project) et du SANS Institute, organisation regroupant bon nombre d’experts en cybersécurité. De son côté, le MITRE a référencé plus de huit cents vulnérabilités logicielles dans son CWE (Common Weakness Enumeration), tandis que l’OWASP a créé le DevSecOps Studio, un environnement virtuel qui permet de s’entraîner et se former aux concepts DevSecOps avant de chercher à les appliquer en grandeur réelle.
Si DevOps progresse rapidement dans les entreprises, l’Europe est à la traîne dans l’adoption de la démarche DevSecOps, notamment comparée aux États-Unis mais ce qui manque le plus à l’essor de ce DevSecOps, c’est la pénurie de compétences en sécurité applicative, un mal chronique en France qui freine aujourd’hui la transformation digitale de nombre d’entreprises. ❍
« La sécurité doit faciliter le changement et l’innovation ! »
Nicolas Bouquet, responsable sécurité applicative chez Octo Technology
« Beaucoup d’entreprises viennent nous voir afin de mettre en place DevSecOps et implémenter des outils pour automatiser la sécurité. Le volet automatisation des tests est sans doute celui qui est le plus facile à mettre en place. Cela permet de découvrir les failles de sécurité au plus tôt dans la chaîne de développement mais de commencer par l’outillage pour pouvoir dire que l’on a basculé dans DevSecOps est une erreur. En effet, la partie culturelle et organisationnelle de la démarche est tout aussi importante, voire plus, dans le succès de la démarche. DevSecOps et DevOps sont des enfants des méthodes agiles. L’agile s’est attaché à briser le mur d’incompréhension entre les développeurs et les métiers. DevSops s’est ensuite attaqué au mur entre développeurs et exploitants en charge des infrastructures. Reste encore ce mur avec la sécurité qui est en général une équipe bien à part, et qui est considéré comme l’interlocuteur qui dit non aux nouveaux outils dans le Cloud, aux nouvelles applications, etc. L’approche est de transformer les pratiques pour que la sécurité facilite les changements, faciliter l’innovation. La sécurité doit être orientée métier, comprendre les besoins des métiers afin de faciliter le business, c’est une transformation de la sécurité qui va au-delà de DevSecOps. »
« Les équipes DevOps doivent prendre en compte la sécurité le plus en amont possible »
Bruno Riguet, expert sécurité chez Renault Digital
« Notre vision de la sécurité, c’est d’une part la sécurité “ by design ”, la sécurité avant-gardiste et enfin l’amélioration continue. Nous voulons prendre en compte la sécurité le plus en amont possible dans les projets mais aussi dans l’infrastructure. Le volet avant-gardiste de notre approche passe par une veille technologique pour trouver de nouvelles solutions, réaliser des poc. Enfin, le volet amélioration continue, c’est le PDCA, améliorer sans cesse ce qui a pu être mis en place. Dans ce cadre, le rôle de l’équipe DevSecOps, c’est d’une part l’incubation de la sécurité dans les équipes projet, c’est-à-dire aider et supporter les équipes DevOps afin qu’elles prennent en compte la sécurité le plus en amont possible. Cela passe notamment par la réalisation de poc puis de mise en place des outils pour le faire, délivrer les solutions. Ensuite, la démarche qui est propre à Renault Digital, c’est que nous permettons à nos équipes de se challenger afin de progresser. Les équipes doivent apprendre les meilleures pratiques, mais aussi être conscientes des enjeux de la sécurité dans leur travail. Il est nécessaire de responsabiliser les équipes projet, que les actions prises ont un impact pour eux. »
« Attention à ne pas oublier de sécuriser la plate-forme DevOps elle-même ! »
Bertrand Méens, CTO d’Oskab
« Inclure la sécurité dans la culture DevOps est un double enjeu : on pense instinctivement à intégrer les principes de sécurité dans le DevOps, dans l’organisation comme dans l’outillage, mais il ne faut pas oublier de sécuriser la plate-forme DevOps. Par plateforme DevOps, j’entends la boîte à outils qui constitue l’usine à développement du repository (Git, SVN…) pour les sources à l’infrastructure d’hébergement (Cloud, Virtual Datacenter, Container, Serverless…) en passant par les outils CI/CD. Dans un environnement de développement non-DevOps, les développeurs et les administrateurs sont majoritairement dans des équipes séparées avec une automatisation faible et des droits d’accès aux environnements de production globalement bien identifiés. Le DevOps décloisonnant l’organisation et augmentant l’automatisation, ce sont des outils, pour ne nommer qu’eux, comme Jenkins, Gitlab CI, Ansible ou Terraform qui assurent les mises en production et qui deviennent donc les nouveaux administrateurs. Dans ce contexte, un outil de CI/CD devient une cible de choix pour le pirate pour le risque d’intrusion, il est plus aisé de s’introduire dans un seul outil, qui administre les serveurs de production, que sur tous les serveurs de production. »