Un peu de contexte
De nos jours, pour créer une application un développeur (ou une équipe de développement) doit assembler des composants open source, des composants provenant de vendeurs tiers et du code maison. Cet assemblage peut rapidement devenir complexe en fonction de la taille du projet et du nombre de librairies utilisées.
Une machine virtuelle qui démarre et qui est patché régulièrement est également un système complexe avec des centaines de versions de logiciels installés qui évoluent.
Un conteneur, bien qu'ayant une surface d'attaque réduite, contient lui aussi des dizaines de paquets installés.
Il devient donc crucial pour chaque entreprise de pouvoir établir et maintenir facilement une liste des composants de ces différents systèmes.
Un SBOM (Software Billing of Material) est un inventaire des composants (et leur version) permettant la construction d’une application (librairies) ou d’un système (logiciels installés).
C’est devenu un élément clé pour la sécurité des logiciels et la gestion du risque associé. Il permet aux organisations d'identifier et suivre facilement ces composants.
Deux standards ont émergés :
- CycloneDX (https://cyclonedx.org/capabilities/sbom/) propulsé par l'Open Web Application Security Project (OWASP). Ex :
- Software Package Data Exchange (SPDX) (https://spdx.dev) maintenu par la Linux Foundation. Ex :
Peu importe le standard choisi, la génération des SBOMs doit s'intégrer, sous peine d'être dépassée et inutile, au cycle de vie des applications/systèmes. La génération d'un SBOM n'est également pas une fin en soi, il ne s'agit là que de la première étape. Il conviendra de stocker cette liste pour chaques versions de chaques applications/systèmes à des fins d'audit et de traçabilité ultérieure.
Il est important de noter que le SBOM ne gère pas directement les vulnérabilités. Au lieu de cela, il fournit les éléments nécessaires pour prendre des décisions informées sur la façon de les gérer. Soit pour des applications existantes, soit pour l'étude de futurs composants à utiliser.
Maintenant que nous avons établi la nécessité et la pertinence de mettre en place ce type de solution, étudions la faisabilité et son déploiement dans un environnement de type cloud.
Récoltes d'informations
Comme évoqué précédemment, la récolte de l'information est la première action à mettre en place et pour éviter les frictions et frustrations, il convient de systématiser et d'automatiser ce processus.
Shift left.
Le changement culturel émergeant ces dernières années permettant de mettre en évidence les bugs, erreurs de configuration ou faille de sécurité éventuelle, le plus rapidement possible est la première solution évidente à mettre en place. Les pipelines d'intégration continue de l'application permettent une vérification à chaque merge, tag ou release. Ainsi, tout au long du cycle de vie de l'application une analyse est effectuée, et la traçabilité assurée. Cette analyse devra être stockée pour une future exploration (Dans un bucket AWS S3 par exemple).
Analyse automatique
Grâce aux technologies déployées par les clouds providers actuels, il est possible de savoir quand une image de conteneur est poussée dans un registry ou quand une nouvelle machine virtuelle est démarrée. Connaissant cette information, on peut alors déclencher un mécanisme (Comme une lambda) qui se chargera de l'analyse du conteneur ou de la machine et de stocker ce résultat.
La mise en place de ce genre de mécanisme d'automatisation permet de systématiser le processus d'analyse et d'éviter un oubli éventuel ou une erreur de configuration d'un pipeline.
Pour assurer la pertinence des informations stockées, il est également nécessaire de réitérer l'analyse à chaque mise à jour des machines virtuelles. En générant un event ou captant un event existant après la mise à jour, le dispositif décrit dans le paragraphe précédent peut être déclenché.
Analyser les résultats
Nous l'avons dit, la génération d'un SBOM n'est pas une fin en soi. Il convient de pouvoir analyser les résultats pour en tirer des conclusions ou actions à mener.
Systématique
Un cloud provider moderne nous permet à chaque fois qu'un fichier est déposé dans un contenant de type AWS bucket S3 de déclencher une action. Elle sera chargée de lancer l'analyse du fichier.
Cette solution est donc commune aux approches automatiques et shift left présentées précédemment. Elle permet une traçabilité et une auditabilité continue de la plateforme.
A la demande
Lors de l'apparition d'une nouvelle Common Vulnerabilities and Exposure (CVE), il devient indispensable de savoir rapidement si la librairie ou le logiciel impacté est présent sur la plateforme.
Les données étant déjà présentes, il suffit de lancer une analyse de l'ensemble des composants à la recherche de l'élément suspicieux pour mettre en évidence une éventuelle faille de sécurité et savoir où agir le cas échéant.
Et après ?
En cas d'alerte remontée, il sera bien évidemment nécessaire de mettre en place un mécanisme de notification pour analyse et correction, voire de remédiation automatique si possible.
Pour les remédiations, on peut imaginer, si une faille d'un niveau critique est détectée :
- bloquer la release d'une application
- blacklister une version d'une image de conteneur ou de machine virtuelle
- isoler une machine virtuelle du réseau
Loïc participe activement au programme d’innovation
Merci pour votre lecture. Si cet article vous a plu, merci de le partager sur vos réseaux 😉
VOUS AVEZ UN PROJET ?
Audit, migration, infogérance ?
Skale-5 vous écoute : contact@skale-5.com
Nous suivre :
