DevSecOps : quand les cultures sécurité et DevOps s'unissent pour créer "une chaîne de confiance continue"

Comment garantir des déploiements automatisés et de plus en plus nombreux tout en répondant aux besoins critiques de sécurité et de conformité tout au long du processus de conception, développement et production ? Le point.

Le DevSecOps s’appuie sur plusieurs piliers de transformation. Tout d’abord, les exigences de la sécurité doivent être intégrées dès les phases de conception dans une approche security by design. Ensuite, des efforts sont à conduire sur l’automatisation et la standardisation des pratiques de sécurité par l‘industrialisation des tâches de la sécurité dans la chaîne CI/CD et l’uniformisation des outils, infrastructures et processus. Les responsabilités entre équipes sécurité et DevOps doivent être clarifiées et une traçabilité doit être assurée sur l’ensemble des actions réalisées jusqu’en production. Enfin il faut étendre les activités de sécurisation en production et poursuivre la recherche de vulnérabilités de manière proactive et itérative pour assurer une surveillance continue.

La démarche DevSecOps vient ainsi enrichir la philosophie globale du DevOps à travers des apports croisés entre la sécurité et le DevOps pour :

• Permettre à la sécurité de traiter l’accroissement du nombre de mises en production ;
• Détecter et corriger plus rapidement des anomalies sécurité ;
• Intégrer les contraintes de conformité et de traçabilité sur les actions réalisées ;
• Former et sensibiliser les équipes à la prise en compte de leurs contraintes respectives.

La sécurité numérique devient une priorité business et l’IT doit apporter un  nombre croissant de garanties "par défaut"

Les organisations et leur écosystème (clients, partenaires, institutions…) prennent conscience du contexte dans lequel elles évoluent et des risques auxquels elles font face. Tant sur le volet interne (incident de sécurité généré par un collaborateur, malveillance…) qu’externe (cybercriminalité, espionnage, démonstration de performance…), elles s’organisent progressivement pour intégrer les enjeux de sécurité numérique et de gestion de risques de façon transverse dans leur plans stratégiques, leurs processus métiers, leurs choix IT. L’objectif est notamment de faire face à des cyber-attaques qui sont de plus en plus nombreuses, sophistiquées et faciles à mettre en œuvre.

Paradoxalement, l’objectif d’accélération du delivery peut engendrer une diminution de la sécurisation du code applicatif et par ce bais, un point d’entrée sur l’ensemble du système d’information de l’entreprise. Plusieurs chiffres appuient ces constats :

• 61 % des applications échouent aux tests de conformité OWASP Top 10[1] ;
• 90% des cas de piratage résultent d’attaques exploitant des failles liées à des défauts de logiciels.

Les métiers et les organisations dans leur ensemble attendent donc de l’IT et de leurs équipes Sécurité qu’ils proposent des produits sécurisés « par défaut », dans leur design.

Dans le cadre du DevOps, l’approche security by design consiste à intégrer la sécurité dès la conception du produit lors des instances Agile (Sprint 0, Sprint Planning,…) et se construit sur une première modélisation des risques et menaces. Des données sensibles sont-elles utilisées ? Les communications sont-elles cryptées ? Etc.

Les premières instances Agile doivent être réalisées avec un représentant des équipes sécurité afin d’instaurer les bonnes pratiques, de former les équipes et de mettre en place le processus DevSecOps dès la phase de conception et ensuite sur l’ensemble du cycle de développement.

L'intégration de la sécurité et de la conformité se concrétise dans le backlog sous la forme d’abuser stories – des use cases envisagés sous l’angle de l’attaquant et identifiant comment le produit peut être compromis "En tant que <source de menace>, je veux provoquer <un événement redouté> en exploitant <une ou des vulnérabilités du système>". Ils sont qualifiés par rapport à la criticité du risque qu’ils représentent.

L'automatisation des tâches de sécurité est conséquente car elle adresse l'ensemble de la toolchain DevOps. Une grande partie des tests de sécurité peuvent être automatisés par intégration dans la chaîne de CI/CD DevOps. La finalité est de passer d'une application manuelle des tests à une application automatisée et itérative, configurée par les équipes de sécurité et de production.

Ainsi, les points de contact sécurité intégrés aux équipes DevOps participent à l’instauration de l’automatisation des étapes de sécurité. Cela permet au département sécurité de conserver sa connaissance et sa confiance dans les contrôles et le processus mis en place tout en formant et en rendant progressivement autonome les équipes DevOps.

Une traçabilité tout au long du processus et une standardisation du delivery

L'intégration de la sécurité dans la chaîne de CI/CD permet aussi de disposer de points de validation grâce à la signature de code. Chaque outil de test ajoute au code une signature qui sera spécifique au code, à l’utilisateur et à l’application via des systèmes de clés privées. Un outil de vérification contrôle ensuite ces signatures, l'intégrité du code et la séparation des tâches en utilisant les clés publiques dédiées aux outils de tests.

La traçabilité de l’ensemble du processus ainsi acquise facilite la réalisation des audits et permet d’accélérer les mises en production tout en respectant le principe de séparation des tâches. Elle permet également d’être un facteur de réussite clé en assurant au département sécurité un respect du processus de mise en production.

Par ailleurs, le DevSecOps est un levier de standardisation du delivery. L’automatisation des tâches de sécurité diminue fortement la probabilité d'occurrence d'une erreur humaine. La sécurisation du cloud permet de disposer à la demande d'environnements de développement et de test sécurisés et la containerisation permet de réduire l'effort de sécurisation de l'architecture en production en s'appuyant sur des conteneurs sécurisés et des images pré-validées. Enfin, la mise à jour automatique d’une liste blanche (whitelist) des éléments pouvant tourner en production empêche l’exécution de tâches ou de fichiers non répertoriés.

Assurer une sécurisation proactive et en continu de la production

Le risque 0 n’existe pas. Les cybercriminels ayant un temps d’avance sur la défense et l’humain n’étant pas infaillible, cela signifie qu’une surveillance en continu doit être réalisée pour limiter le risque d’impact. Pour cela, les organisations doivent renforcer leur capacité de pilotage transverse de la sécurité, de prévention, de protection des actifs critiques de l’entreprise, de détection & réaction en cas d’incident, de reconstruction des données et doivent assurer leur conformité avec les standards et règlementation. Sur les volets de la protection du SI et de la détection d’incidents de sécurité, les organisations ont généralement déployé des mesures de défense périmétrique (antivirus classique) et des systèmes d’alerting, dans certains cas avec des Security Operations Centers (SOC), responsable de la qualification des alertes et de la réaction aux incidents.

Aujourd’hui, il existe des outils d'analyse comportementale modernes et englobants s’appuyant sur le machine learning pour identifier des actions suspectes ou des comportements du SI jugés "anormaux" :

• Les outils d'User Behaviour Analysis (UBA) se focalisent sur l'analyse de modèles de comportements humains pour limiter les actions des utilisateurs ou robots malveillants ;
• Les outils de Runtime Application Self Protection (RASP) analysent les entrants et le comportement des applications et déclenchent des actions de protection (fin de session, relance de l'application…). 

Changement de culture et répartition des rôles : une responsabilisation des équipes DevOps 

Cette intégration des enjeux de sécurité dans les organisations DevOps est une transformation conséquente dont la réussite repose sur deux facteurs principaux :

• Une conduite du changement (de culture) au sein des équipes DevOps et sécurité ;
• Une définition claire des rôles et des responsabilités.

En termes de rôles et responsabilité, la sécurité doit être intégrée aux équipes DevOps pour porter le niveau d’exigence de l’organisation, participer à l’automatisation du processus, mais aussi former et accompagner les équipes DevOps afin de les rendre progressivement autonomes. De leur côté, les Dev et les Ops doivent assimiler les enjeux de sécurité.

Les experts sécurité intégrant temporairement les équipes DevOps sont un maillon essentiel pour instaurer et coordonner la démarche au sein de l’entreprise. Ces points de contact ont un rôle multiple : ils participent à la mise en place de la démarche DevSecOps tout en sensibilisant les équipes. Ils ont un rôle d’appui dans la définition et le suivi des exigences dans le cadre des développements. Ils identifient et mettent en place des outils sécurité à disposition des équipes et coordonnent les actions de sécurisation du SI une fois les failles identifiées, lors du développement mais aussi en production.

En termes de culture, la démarche DevSecOps est un changement de paradigme s’appuyant sur une nouvelle répartition des responsabilités entre les équipes DevOps et Sécurité. Une nouvelle confiance doit s’établir entre la sécurité et les équipes de delivery pour permettre la délégation d’une grande partie des activités de sécurité. Dans un contexte où chaque ligne de code ou paramètre de configuration peut se transformer en faille critique, il n’est plus possible de compter uniquement sur les spécialistes. Il s’agit d’un changement de culture fort qui nécessite un accompagnement dans la durée.