X
Alain Clapaud / samedi 20 juillet 2019 / Thèmes: Dossier, Sécurité

DevSecOps

Comment faire rimer cybersécurité et agilité

À l’intersection du développement, de l’exploitation et de la sécurité, DevSecOps vise à réconcilier trois populations aux intérêts souvent divergents. Inculquer vitesse et agilité aux experts sécurité n’a rien de simple alors que ceux-ci doivent garantir la pérennité du système d’information sur la durée.

DevSecOps vient ajouter la composante cybersécurité aux démarches DevOps des entreprises. L’enjeu est bien de pouvoir sécuriser au plus tôt les développements afin de ne pas freiner les sprints des développeurs.

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. »

6002

x
Rechercher dans les dossiers

Actuellement à la Une...
Depuis quelques jours le port du masque est obligatoire dans les lieux clos, Pepper, le robot de SoftBank Robotics, est doté d'une nouvelle fonctionnalité, la reconnaissance des masques.

L’éditeur de solutions de sécurité dans le Cloud reprend Spell Security, une start-up qui a développé un EDR (Endpoint Detection and Response).

Cedric O a annoncé que l’application de contact tracing avait été téléchargé plus de deux millions de ...

L’entreprise spécialisée en cybersécurité CheckPoint a découvert dans la célèbre application de “dating” plusieurs vulnérabilités qui auraient pu permettre à des attaquants, au moyen de faux liens, de dérober les données des utilisateurs et utilisatrices du site de rencontre.

Le vendeur de portefeuilles à cryptomonnaies a été victime fin juin d’une intrusion dans ses systèmes. Une attaque qui n’a pas été détectée avant mi-juillet, mais qui ne touche pas directement les fonds stockés par les utilisateurs : les pirates n’ont eu accès qu’à une base de données e-commerce et marketing, contenant principalement des adresses email.

Toutes les autres News
LIVRES BLANCS

Aujourd'hui, les Directeurs Comptables et Financiers ont envie de dématérialiser leurs factures fournisseurs. C'est plutôt l'idée de devoir s'intégrer à un environnement multi-ERP déjà existant qui les freine. Mais est-ce réellement une barrière ? Dans son nouveau Livre Blanc, Esker explore ce sujet. En le téléchargeant, vous découvrirez comment la dématérialisation peut être une aubaine plutôt qu'un fardeau.


Actuellement, il existe un gouffre entre les environnements informatiques traditionnels des entreprises et le cloud public. Tout diffère : les modèles de gestion, de consommation, les architectures applicatives, le stockage, les services de données.


Les avantages de l’architecture hyperconvergée étant de plus en plus reconnus, de nombreuses entreprises souhaitent l’utiliser pour des types d’applications variés. Cependant, son manque de souplesse pour une mise à niveau des ressources de calcul indépendantes de celles de stockage ne lui permet pas d’être utilisée plus largement.

Au cours de l’événement HPE Discover qui s’est tenu en juin 2019, HPE a répondu à cette préoccupation en présentant la plateforme HPE Nimble Storage dHCI.

Ce Livre Blanc IDC se penche sur les exigences du marché ayant stimulé le besoin de solutions HCI plus flexibles, puis il examine brièvement la solution HPE Nimble Storage dHCI en expliquant pourquoi elle répond à ce besoin.


Découvrez dans ce livre blanc, les avantages des toutes nouvelles solutions NETGEAR, pour simplifier et rentabiliser vos déploiements, et gérer votre réseau à distance, où que vous soyez, au bureau ou en télé-travail.


Tous les Livres Blancs