DevSecOps : les enseignements du Département de la Défense américain
Lors de l’événement GitLab Commit 2021, deux ingénieurs d’Anchore ont partagé leur expérience autour de ce projet et les enseignements qu’ils en tirent, afin de bâtir une chaîne d’outils et des pipelines CI/CD sécurisés.
Anchore est un éditeur spécialisé dans la sécurisation des containers. L’entreprise a été sélectionnée par le Département de la Défense (DoD) étatsunien, l’équivalent du ministère de la Défense en France, pour l’assister dans la conception de Platform One.
Platform One est la plateforme DevSecOps pour l’ensemble du Département de la Défense (DoD) étatsunien. Cette « usine à logiciels » réside par-dessus Cloud One, une infrastructure multicloud répartie entre des instances Microsoft Azure Government et AWS Gov Cloud.
Adopter une telle plateforme réclame de relever trois défis majeurs. Le premier d’entre eux n’est autre que d’éviter les attaques des chaînes logistiques informatiques. Solarwinds, Kaseya ou encore Codecov sont des solutions ayant fait les frais de ce type d’assaut avec des conséquences particulièrement néfastes. « Toutes ces attaques sont dirigées par des acteurs très persévérants, engagés et très créatifs », déclare Hayden Smith, Senior Engineer Field Operation chez Anchore. « Ces cybercharges pénètrent de plus en plus profond dans les couches basses de la chaîne logicielle permettant de diffuser plus largement, plus rapidement et plus facilement les menaces à travers toute une organisation ».
« Dans une étude menée par Anchore, nous avons remarqué que 64 % des organisations sondées ont subi une attaque de chaîne logistique logicielle au cours de l’année écoulée. »
Hayden SmithSenior engineer field operation, Anchore
« Dans une étude menée par Anchore, nous avons remarqué que 64 % des organisations sondées ont subi une attaque de chaîne logistique logicielle au cours de l’année écoulée », affirme-t-il. « Parmi les entreprises touchées, 15 % d’entre elles déclarent que ces attaques ont eu un impact significatif, 20 % une incidence modérée et 29 % des conséquences mineures ».
Le deuxième défi, selon l’ingénieur, concerne le choix d’architecture logicielle. Comme beaucoup de sociétés du secteur privé ou public, le DoD a adopté une plateforme de conteneurisation basée sur la version open source de Kubernetes. « Assembler des paquets logiciels est devenu plus facile que jamais avec les conteneurs, mais cela présente un risque important de sécurité parce que vous avez tellement de fichiers différents, de dépendances, de secrets à gérer. Vous avez besoin d’un moyen pour détecter les problèmes de sécurité et de conformité dans ces composants conteneurisés ».
Dans le cas de Platform One, le troisième défi consiste à automatiser ces vérifications de sécurité et de conformité. « Nous voulons nous protéger des attaques de supply chain logicielle, nous souhaitons adopter une plateforme de conteneurs et d’autres technologies cloud natives, mais nous espérons le faire en mettant en place des processus automatisés afin d’accélérer la livraison logicielle au profit des combattants ».
Néanmoins à toutes les étapes de la production logicielle, des dizaines de types d’attaque peuvent compromettre l’ensemble de la chaîne d’outils, prévient Hayden Smith.
Les questions essentielles à la pratique DevSecOps
De ces défis émergent des questions plus générales, sur la mise en place de la chaîne d’outils et des pratiques DevSecOps.
« Vous devez vous poser des questions importantes :
À qui faites-vous confiance, même en interne ?
Quels sont les composants logiciels auxquels vous pouvez faire confiance
Comment inspectez-vous ces logiciels ?
À qui appartient le modèle de sécurité et que contient-il ?
Quels éléments faut-il scanner ? Quand ? Où ? Combien de fois ?
Comment protégez-vous les éléments les plus sensibles, comme les secrets ?
Comment faites-vous cela de manière flexible ? Comment bâtir des pipelines basés sur les technologies cloud natives capables de surmonter tous ces défis sans abaisser le niveau de sécurité ? », liste Hayden Smith.
Ici, le DoD et Anchore ont choisi de s’appuyer sur GitLab et sur huit outils pour vérifier et assurer la sécurité de la chaîne et des logiciels eux-mêmes. Mais cette décision appartient à l’entreprise et à sa DSI. Préfère-t-elle adopter une plateforme centrale et y greffer plusieurs outils annexes, ou est-il plus intéressant de combiner plusieurs solutions afin de composer cette chaîne ?
De bonnes questions…
Pour sélectionner tous ces outils, le Département de la Défense avec l’aide d’Anchore s’est posé quatorze questions que James Petersen, Senior DevSecOps Engineer chez Anchore classifie en quatre catégories : la visibilité, l’inspection, le renforcement des politiques de sécurité et la remédiation.
« Les premières questions à se poser quand vous choisissez vos outils tournent autour de la visibilité », affirme-t-il. « Que trouve-t-on dans vos logiciels, dans vos containers en production ? ».
« Un ordre de l’exécutif publié récemment rend obligatoire l’adoption d’un SBOM pour tout logiciel que le gouvernement américain va utiliser », ajoute-t-il.
Un SBOM ou Software Bill of Materials est une nomenclature logicielle qui décrit chacun des composants de la chaîne d’outils et tous les éléments formant les applications. Ce concept est bien connu des industriels et de l’US Air Force, car il est directement inspiré du BOM (Bill of materials), une structure arborescente qui représente l’ensemble des organes et des pièces nécessaires à la fabrication d’un produit et son support tout au long de sa durée de vie, par exemple un avion de chasse.
« [Un SBOM] fournit une vision approfondie de la chaîne d’approvisionnement logicielle qui compose ce logiciel particulier, cette image du conteneur, et vous dit quelles sont vos dépendances et où elles se trouvent, d’où elles viennent et qui effectue réellement des changements à ce logiciel que vous utilisez ici dans votre système en production », indique James Petersen.
Puis vient la notion d’inspection qui consiste tout simplement – en tout cas sur le papier – à analyser les logiciels et les dépendances en place à la recherche d’anomalies, de failles, d’activités anormales, des secrets à l’air libre et bien évidemment de malwares.
« Peut-être que certaines des vulnérabilités sont acceptables et autorisées parce qu’elles n’affectent pas vraiment votre sécurité logicielle et qu’elles ont été vérifiées par vos responsables de la sécurité. »
James PetersenSenior DevSecOps Engineer, Anchore
Concernant les politiques de sécurité, il s’agit d’établir des standards que toute l’organisation suivra et d’établir les mesures à prendre en cas de détection de malwares ou de comportements anormaux d’un logiciel.
De manière contre-intuitive, et même si cela paraît dangereux, cela ne veut pas dire qu’il faut résoudre toutes les vulnérabilités signalées par les outils, selon l’ingénieur DevSecOps.
« Peut-être que certaines des vulnérabilités sont acceptables et autorisées parce qu’elles n’affectent pas vraiment votre sécurité logicielle et qu’elles ont été vérifiées par vos responsables de la sécurité », remarque James Petersen.
En réalité, il serait plus pertinent de faire en sorte « d’adhérer à des standards de conformité établis ». « Les standards de l’industrie n’existent pas pour faire joli », indique James Petersen. « C’est un conglomérat de meilleures pratiques formulées par des personnes très compétentes. Des choses comme les scans de sécurité, le linting (l’analyse et la correction N.D.L.R) de vos fichiers Docker, vos manifestes d’infrastructure as code ou Kubernetes, etc. tout cela est très important ».
Ensuite, il s’agirait « d’encoder des règles répétables et automatisables dans un processus, car les humains font des erreurs ». « C’est facile d’examiner une dizaine d’images de conteneurs manuellement, mais une fois que vous en avez des centaines en place, cela devient ingérable sans un système automatisé », affirme l’ingénieur DevSecOps.
Enfin, il convient de prioriser les efforts de remédiation suivant des critères d’urgence, de faisabilité et des procédures établies. Si l’équipe DevSecOps ne sait pas comment résoudre une vulnérabilité ou une faille, elle doit pouvoir s’appuyer une chaîne de signalement permettant de faire appel rapidement aux « pompiers de la cybersécurité » – internes ou externes à l’entreprise – capable d’éteindre l’incendie.
D’après l’exemple détaillé par James Petersen, le DoD a non seulement durci ses conteneurs, ses outils de sécurité, mais également ses procédures associées à l’orchestration des pipelines CI/CD, sans oublier de superviser constamment les activités au sein de la plateforme DevSecOps.
… Encore faut-il pouvoir y répondre
La plupart des praticiens sont au fait de ces conseils et ces approches. Cependant, tout cela ne se résume pas à des règles et des outils à mettre en place, mais aussi, et surtout, à une notion de culture, de connaissances et de moyens.
Concernant la gestion de secrets, certains développeurs ne savent pas où les loger de manière sécurisée. Ceux qui utilisent des outils KMS comme Hashicorp Vault, Azure Key Vault ou encore AWS KMS doivent en outre administrer la prolifération de clés de chiffrement et leur politique d’expiration. « Par exemple, HashiCorp Vault est un très bon outil, mais à part si vous êtes vigilants, vous vous retrouvez avec un fourmillement de cryptographie. Un certificat d’autorité est créé ad hoc à chaque fois que quelqu’un monte un conteneur », déclare Jon Ferguson, directeur product management chez Entrust, auprès du MagIT.
Le Département de la Défense, au vu de son activité est particulièrement sensible à la notion de cybersécurité, ce qui est également vrai pour une agence comme l’ANSSI, la Gendarmerie nationale, les armées françaises, et plus largement toutes les organisations gouvernementales directement concernées par les dangers des cyberattaques. Cependant, certaines de ses questions n’ont pas une seule solution et il faut encore établir des spécifications claires, selon certains professionnels participant au GitLab Commit. Surtout, il est plus facile de répondre à ces questions avant de bâtir sa chaîne d’outils et ses pipelines qu’en cours de route.
