Remédiation et SBOM : les deux enseignements de Log4j

CVE-2021-44228 : et Log4Shell fut

Il existe bien des outils pour détecter les vulnérabilités, dont ceux de Snyk, mais la plupart d’entre eux s’appuient sur des bases de données publiques ou privées rassemblant des failles détectées, analysées et mises au jour par des équipes de sécurité, des hackers blancs, ou des cabinets spécialisés.

« Je n’ai pas connaissance d’un quelconque outillage qui aurait pu détecter cette vulnérabilité en amont », admet Nicolas Massé.

Faut-il attendre que suffisamment de signaux faibles remontent aux oreilles des experts pour qu’ils se mettent à inspecter un possible trouble dans un dispositif à l’apparence anodine ? Cela semble trop souvent le cas aujourd’hui.

« Des audits de code indépendants et des programmes “bug bounty” (récompense monétaire à la personne qui trouve une vulnérabilité) auraient peut-être pu permettre de détecter cette vulnérabilité plus tôt », continue le Solution Architect chez Red Hat.

Open source ou non, un logiciel sans failles n’existe pas, selon Bryan Vermeer. « Avec le temps, on découvrira une nouvelle vulnérabilité ayant un impact potentiel élevé ou critique. Ce que nous pouvons faire, c’est en être conscient et nous assurer qu’une fois qu’une vulnérabilité est signalée, nos clients peuvent agir rapidement », affirme-t-il.

Quand l’évangéliste de Snyk dit « nos clients », il émet une recommandation pour toute l’industrie, et pas seulement en direction des mainteneurs de projets open source.

Divulguer n’est pas jouer

En ce sens, il faut bien distinguer quatre phases : la détection, la divulgation, l’alerte et la correction d’une vulnérabilité. La publication d’un CVE sans en informer les administrateurs ou les propriétaires d’un logiciel peut s’avérer nocive, signale Bryan Vermeer. « La divulgation responsable est très importante. Publier une vulnérabilité sans donner aux mainteneurs le temps de la corriger provoquera une panique inutile et augmentera très certainement le nombre d’attaques ».

« Nous n’envoyons pas d’alertes sur une liste de diffusion publique sans avoir donné une chance aux responsables du projet de corriger la faille ».

Gaël Blondelle, vice-président de l’écosystème de développement pour la Fondation Eclipse est du même avis. La fondation open source documente la majorité de ses actions. La divulgation fait exception. « C’est l’un des rares cas où l’on ne travaille pas forcément de manière transparente », explique-t-il. « Nous n’envoyons pas d’alertes sur une liste de diffusion publique sans avoir donné une chance aux responsables du projet de corriger la faille ».

C’est une méthode classique dans le monde de la cybersécurité. Les experts, les chercheurs et les hackers blancs attendent à minima que les éditeurs, les organisations ou les entreprises leur fassent une réponse en retour.

La fondation Eclipse mitige ainsi les notifications de sécurité en provenance de l’extérieur et de l’intérieur de l’organisation. « Un rapport de vulnérabilité arrive à l’équipe cyber de la fondation. Cette équipe dissémine la vulnérabilité auprès des responsables des projets », décrit Mikaël Barbero, responsable Release Engineering et technologie pour la Fondation Eclipse.

« Nous sommes aussi CVE Numbering Authority (CNA) : nous pouvons créer notre propre CVE », précise Gaël Blondelle.

Ensuite, le CVE peut être diffusé largement, avec le plus souvent un lien vers le correctif proposé par les responsables du projet.

Cette méthodologie est appliquée par la fondation Apache qui est également une CNA. Les entreprises privées qui ont demandé ce statut agissent peu ou prou de la même manière. 

Dans le cas de Log4j, les CVE et les corrections se sont multipliés à une allure folle, surtout pour des bénévoles et des volontaires.

« Les communautés open source ont la responsabilité de corriger les vulnérabilités découvertes, mais les communautés qui en dépendent ont la responsabilité de mettre à jour leurs dépendances […]. »

« Je tiens à féliciter les mainteneurs de Log4j, car le problème initial du RCE avait déjà été corrigé dans une version plus récente avant d’être signalé au reste du monde », souligne Bryan Vermeer. « Par la suite, d’autres vulnérabilités ont été découvertes et divulguées et l’équipe de Log4j a fait un travail remarquable pour les corriger rapidement. N’oubliez pas qu’il s’agit d’un logiciel open source maintenu par un très petit nombre de personnes pendant leur temps libre ».

Nicolas Massé considère qu’il n’y a rien d’anormal dans la procédure, qui implique également les utilisateurs de Log4j, dont les éditeurs.
« Les communautés open source ont la responsabilité de corriger les vulnérabilités découvertes, mais les communautés qui en dépendent ont la responsabilité de mettre à jour leurs dépendances pour ne pas livrer de versions qui ne seraient plus supportées et vulnérables. Et c’est bien ce qu’il s’est passé pour la faille Log4Shell. Les trois mainteneurs Log4j de la fondation Apache ont corrigé les multiples vulnérabilités et Red Hat a intégré ces correctifs dans ses produits impactés », illustre-t-il.

Patcher le plus vite possible

Encore faut-il que les entreprises soient notifiées de cette alerte et de l’existence d’un correctif. Dans le cas de Log4Shell, la diffusion de l’information a été bonne : les médias, les analystes et les éditeurs ont largement partagé l’information. Dans d’autres, cette diffusion est plus complexe et certaines entités semblent sourdes aux bruits des alertes.

« Toute personne utilisant des bibliothèques tierces doit être en mesure d’identifier rapidement si elles sont vulnérables et d’agir vite si nécessaire », récite Bryan Vermeer. « Il est donc utile d’être à jour avec la version la plus récente de votre librairie. Si vous utilisez une version plus ancienne, cela demandera sans doute plus de travail. En outre, le processus de création, de test et de diffusion d’un logiciel doit être conçu de telle sorte qu’il soit possible de diffuser rapidement une version plus récente au besoin ».

Cette réduction du temps moyen de remédiation (MTTR), entre la diffusion d’un correctif et son application est essentielle pour Massimiliano Gori, Product Manager for Cybersecurity Compliance chez Canonical. « Si vous avez déjà travaillé dans un SOC, ce que vous constatez c’est que la plupart du temps les plus grosses failles dans les SI ne sont pas provoquées par des vulnérabilités nouvelles, mais parce que les entreprises prennent beaucoup de temps pour appliquer les patchs. C’est le premier problème à résoudre ».

Le SBOM, un dispositif nécessaire

Mais revenons à notre problème de départ. C’est à l’entreprise ou aux experts qu’elles mandatent de découvrir où se trouve le logiciel vérolé dans son SI. Une fois la CVE passée, des outils de scans et de maintenance de dépendances tels ceux de Snyk ou de JFrog sont utiles. Mais ils ne couvrent pas forcément tous les composants d’un système d’information.

Alors que faire ? Les initiatives gouvernementales sont une bonne réponse, selon nos interlocuteurs.

« Des éléments contraignants comme l’Executive Order de l’Administration Biden considérant que toute entreprise doit connaître son Software Bill of Materials (SBOM ou nomenclature logicielle) me semblent assez majeurs. Je pense que l’Europe devrait aussi s’intéresser à cela et demander aux entreprises européennes d’avoir une approche similaire », déclare Gaël Blondelle.

Un SBOM permet d’identifier les composants logiciels utilisés dans une entreprise. Un tel dispositif centralisé mentionne les noms des composants, leurs versions, leurs origines et la ou les licences associées.

« Être conscient de l’existence d’une vulnérabilité n’est pas aussi important que d’être capable de comprendre comment cette vulnérabilité s’applique à votre environnement […]. »

La connaissance des logiciels et des différentes dépendances matérielles et logicielles devient clé pour assurer ce MTTR, selon Massimiliano Gori. « En fin de compte, être conscient de l’existence d’une vulnérabilité n’est pas aussi important que d’être capable de comprendre comment cette vulnérabilité s’applique à votre environnement et d’être capable de la corriger dans un délai qui ne permet pas à un attaquant de profiter du laps de temps entre la découverte et la remédiation », déclare-t-il.

Ces principes n’ont rien de nouveau. Les entreprises connaissent bien l’intérêt de ces nomenclatures, selon une étude consacrée à la maturité des entreprises en matière d’adoption du SBOM. Ce sondage a été mené au troisième trimestre 2021 par la Fondation Linux auprès de 412 entreprises, dont 32 % d’entre elles sont installées en Europe de l’Ouest et 40 % en Amérique du Nord.

Peu importe leur nationalité, 80 % d’entre elles sont au courant de l’Executive Order de l’Administration Biden et elles comptent prendre des actions en conséquence.

Surprise pour la Fondation Linux, 90 % des organisations ont commencé à adopter un SBOM et 47 % des entreprises interrogées en utilisent un, mais celui-ci couvre l’entièreté de la pile technologique pour seulement 23 % des sondés. La majorité (52 %) d’entre eux emploient un SBOM « dans un, plusieurs ou de nombreux domaines de leur activité ».

Bonne nouvelle, la Linux Foundation estime que 88 % des sociétés utiliseront un SBOM en 2023. Pourquoi la LF s’intéresse-t-elle à ce sujet ? Quatre-vingt-dix-huit pour cent des entreprises utilisent des logiciels open source. 

« Les SBOM joueront un rôle essentiel dans l’instauration d’une plus grande confiance et transparence dans la façon dont tous les logiciels sont créés, distribués, et consommés tout au long des chaînes d’approvisionnement », écrit Jim Zemlin, Président exécutif de la Fondation Linux en introduction de l’étude.

À contre-courant des résultats positifs de l’étude, les responsables de la Fondation Eclipse et de Canonical sont plus méfiants et préfèrent se fier à la réalité du terrain.

« Chez Canonical, nous considérons que la conformité réglementaire est un élément clé pour garantir que les entreprises adoptent une approche cohérente de la sécurité de la chaîne d’approvisionnement, parce que c’est quelque chose que nous ne voyons absolument pas se produire pour le moment, même chez les grands comptes », affirme Massimiliano Gori.

Selon Mikaël Barbero, beaucoup d’entreprises ont prouvé qu’elles ne maintenaient pas de listes de logiciels lors de la crise Log4Shell.

« Si certaines entreprises ont passé beaucoup de temps à réaliser des analyses de version et à solliciter leurs fournisseurs afin de savoir s’ils utilisent Log4j, c’est qu’elles n’utilisent pas de SBOM. Que ce soit dans leurs produits ou dans les produits qu’elles embarquent à N niveau d’imbrication, elles ne sont pas capables de lister leurs dépendances », affirme Mikaël Barbero. « Nous voulons mener des initiatives pour proposer des outils et des méthodes afin de générer des SBOM de manière plus efficace et systématique ».

En clair, les entreprises clientes ne sont pas les seules à devoir répertorier les composants présents dans leurs systèmes, les éditeurs et les fournisseurs doivent aussi le faire. « Quand vous achetez une friandise au supermarché, le paquet mentionne une liste d’ingrédients. Pourquoi n’attendons-nous pas le même niveau de transparence des logiciels fondamentaux qui assurent le maintien et la croissance de nos activités commerciales, de nos organisations et de nos infrastructures critiques ? », interroge Allan Friedman, Senior Advisor & Strategist pour le CISA, lors d’un webinaire organisé par la Fondation Linux, le 1er février 2022. « Si un logiciel contient une vulnérabilité potentielle, il est important de pouvoir l’adopter en connaissant les risques encourus ».

« N’oublions pas que derrière les logiciels open source il y a des humains, des membres de la communauté qui partagent leurs efforts. »

Reste à s’entendre sur des standards pour bâtir des nomenclatures interopérables. À ce sujet, le président de la Fondation Linux est confiant.

« Heureusement, nous disposons déjà des normes et des outils nécessaires pour mettre en œuvre des pratiques de sécurité logicielle plus strictes tout au long des chaînes d’approvisionnement en utilisant les SBOM », assure Jim Zemlin en évoquant les efforts récurrents autour de SPDX, un projet visant à cartographier les dépendances open source.

« Des entreprises telles que Hitachi, Samsung, Microsoft, Intel, Cisco, Siemens, Google, et beaucoup d’autres ont déjà produit et consommé des fichiers SPDX depuis des années. Nous nous attendons à ce que ce phénomène se développe de manière significative dans les années à venir. Nous espérons comprendre les défis auxquels sont confrontés les nouveaux arrivants dans l’écosystème des SBOM afin de nous permettre d’être plus efficaces et de faciliter l’adoption des meilleures pratiques », ajoute-t-il.

Massimiliano Gori, lui, s’interroge sur les dispositifs légaux à mettre en œuvre. « La réglementation elle-même est un peu ouverte pour le moment. Il n’y a rien qui soit directement obligatoire. La véritable question est de savoir jusqu’où nous sommes prêts à aller pour renforcer la sécurité. N’oublions pas que derrière les logiciels open source il y a des humains, des membres de la communauté qui partagent leurs efforts ».