DevSecOps, un avenir prometteur pour la cyber sécurité ?

I. La gestion du SI — Une galère certes; mais vitale !

L’incident survenu à Equifax met en lumière de nombreux problèmes quant aux approches de sécurité informatique en entreprise et notamment la mise en place d’un patch management.

L’incident en quelques mots : en septembre 2017 une vulnérabilité touchant les Struts2 apache (CVE-2017–5638) a été découverte. Malgré un score CVSS V2 de 10.0 (score maximal), Equifax, société dont le cœur de métier est l’évaluation de cotes en bourse, a fait le choix de ne pas appliquer le patch qui était pourtant disponible à l’époque. Cette décision entraîna la fuite d’informations de 143 millions de comptes.

A la suite de quoi, l’ex CEO d’Equifax Richard Smith a imputé l’entière responsabilité de l’attaque à un seul employé qui n’a pas su dire si le SI était affecté par cette CVE. Cette déclaration fit réagir des experts en cyber sécurité comme McKenzie disant qu’une seule personne ne pouvait être responsable de mauvais choix techniques concernant la sécurité.

Aujourd’hui, plus l’application est critique pour l’entreprise plus le risque de dysfonctionnement suite aux mises à jour de sécurité devient important en recette. Finalement on choisit de privilégier le fonctionnement de l’application quitte à laisser le système vulnérable. Donc paradoxalement il arrive que les applications les plus vitales soient les moins bien patchées.

Prenons un nouvel exemple, celui de Cloudflare, entreprise proposant, entre autre, un réseau de distribution de contenu. En février 2017, un employé de Google a signalé un dysfonctionnement d’un service web de Cloudflare. Il était possible, sous des conditions particulières, d’extraire des données personnelles via des requêtes HTTP. Avant même que cette vulnérabilité ne soit rendue publique, une équipe fut mise en place et en moins d’une heure (47 min) les trois services responsables de ces fuites avaient été déconnectés, stoppant ainsi le problème momentanément. S’en suivit une implication maximale de l’équipe en question pour patcher la vulnérabilité de manière permanente. Ce qui permis la mise au point d’un patch et de son déploiement en moins de 7h.

Nous allons donc vous parler d’une nouvelle approche, similaire à celle utilisée par Cloudflare, qui semble avoir fait ses preuves. Celle-ci a pour philosophie d’intégrer directement les équipes de sécurité dans la boucle de développement, afin d’être capable de développer et de déployer une nouvelle application sécurisée et sans régression en moins d’un mois (délai imposé par le LPM). Comme l’écrit Matt Miler dans un article de BeyondTrust, la sécurité doit être intégrée aux processus et à la culture du développement. Cette démarche fait référence au “DevSecOps”.

II. L’apporche DevSecOps : L’aspirine de la sécurité ?

Le point fondamental de l’approche DevSecOps et l’incorporation de la gestion de la sécurité du SI au sein du cycle de développement Agile.

Les principes fondamentaux de l’agilité sont : des objectifs à court terme (sprint typiquement d’une à trois semaines), de la mixité de compétences chez les personnes d’une même équipe, des capacités à travailler en autonomie, une qualité mise au premier plan : Faire bien, c’est en faire le moins.

Une bonne méthode décrite par l’ANSI dans son guide pour la mise en place du DevSecOps sur projet, est d’intégrer des ateliers sécurité au cycle de développement, au même titre qu’il en existe pour le développement applicatif. Bien évidemment, ces ateliers doivent intervenir lorsque le projet arrive à une maturité nécessitant des concepts de sécurité. Cependant, il faut qu’un expert en cyber sécurité soit intégré à l’équipe, dès le début du projet, pour qu’il puisse apporter ses connaissances quant aux coûts que peut générer la mise en place des dispositifs assurant la sécurité. La sécurité se doit d’être continue et d‘avoir un scope prenant en considération l’ensemble des parties prenantes de l’application, dès sa création.

L’expert en sécurité aidera à établir une politique de sécurité claire afin d’automatiser certains aspects de la gestion de la sécurité, et d’incorporer les analyses de risques et leurs traitements aux routines Agile du projet. Cette politique concerne les trois principales mesures : d’hygiène informatique, réglementaire et normative.

Lors des ateliers d’analyse, il est important de catégoriser les users ou abusers stories (cas d’étude quant à l’attaque du SI) à aborder en fonction de leur priorité concernant l’intégrité, la confidentialité et du niveau de preuve impliqué. Ensuite il convient de corréler cette information aux risques potentiels que peuvent impliquer la modification de la fonctionnalité concernée. Uniquement après avoir sélectionné les scénarios à corriger, on peut rentrer dans le code pour apporter une solution technique.

La dernière étape du guide est d’instaurer un suivi des retours utilisateurs dans le but de s’assurer que le problème ciblé a bien été résolu.

Néanmoins, comme le dit Yann Guernion dans sa chronique au “Journal du net”, l’utilisation du DevSecOps peut être potentiellement la porte d’entrée à de nombreuses attaques. En effet l’un des points forts du DevOps est l’utilisation de tests automatisés, ce qui requiert souvent l’utilisation de compte “administrateur” et donc finalement peut potentiellement fournir de nombreuses “back door” et permettre l’injection de codes malicieux. Des processus sur la durée de vie des accès ainsi que leurs fréquences de renouvellement doivent absolument être pris en compte.

Plusieurs approches existent quant à la prise en main du DevSecOps. Pour des groupes tels que Netflix ou Google impliquant des infrastructures massives, distribuées et complexes, c’est le choix de la division et de la segmentation qui a été fait. Le “Trunk based development” est la méthode employée chez Google. Ces fondements sont la segmentation en portions de code sur des répertoires partagés. Les équipes de sécurité travaillant en synergie avec celles de développement se voient attribuées des domaines de code sur lesquels les tests doivent être systématiquement réalisés. Suite de quoi des tests automatisés sont effectués, avant même la livraison en recette de chaque modification dans le code. Cela permet d’éviter les régressions lorsque une nouvelle version est déployée.

III. Transition en douceur ou renversement brutal

Selon un rapport publié par Puppet, entreprise spécialisée dans la vente de solutions de développement automatisé, vouloir passer à une solution DevSecOps “Up-Down” est voué à l’échec. Il faut avancer progressivement.

Entreprise fonctionnant déjà en DevOps

Pour une entreprise fonctionnant déjà avec des équipes DevOps la bascule repose surtout sur des problématiques organisationnelles.

Par exemple une première étape est de sensibiliser les équipes de développement aux problématiques de sécurité et d’y intégrer un expert en cyber sécurité. Le but étant de repenser le cycle de développement pour y intégrer les règles de sécurité et les tests automatisés, aux livrables. Par exemple, pour un patch management DevSecOps il faut intégrer des tests sur les versions des logiciels utilisés.

Aujourd’hui les tests automatisés de sécurité sont les plus compliqués à mettre oeuvre mais le jeu en vaut la chandelle. En effet, selon un article rédigé par Charles Foucault-Dumas reprenant le rapport publié par Puppet, intégrer la sécurité dans le cycle livraison diminuerait de moitié le temps consacré à la résolution de vulnérabilités de sécurité, par rapport aux méthodes classiques.

Le DevOps un mythe pour votre entreprise?

Pour une entreprise ne fonctionnant pas en DevOps, la bascule pour faire du DevSecOps sera bien plus complexe et coûteuse.

Il faut tout d’abord vérifier que les besoins de la DSI nécessitent des méthodologies DevOps. C’est à dire que le SI ait des besoins d’intégration et de livraison continue.

Les points clés pour une transition DevOps sont d’adopter des méthodes Agile pour les équipes de développement afin de fournir des livrables régulièrement et être capable de d’avoir une configuration automatisée de son infrastructure à l’aide de scripts ou de logiciels tels que “Puppet”. On parle d’infrastructure sous forme de code.
Plus les écarts entre la gestion de l’entreprise et le DevOps seront importants, plus le passage au DevSecOps sera compliqué.

Enfin il est nécessaire de savoir que le DevOps prend de plus en plus d’ampleur dans la gestion des projets. Avec aujourd’hui un projet sur cinq fait en DevOps en France et il est prévu que ce chiffre passe à 40% des projets applicatifs en 2021. Le DevOps n’est donc pas qu’une méthodologie marketing, elle a fait ses preuves et a convaincu les entreprises de son efficacité.