Les entreprises peuvent suivre des recommandations détaillées et appliquer les correctifs existants et appliquer les meilleures pratiques en réponse immédiate à log4j. Mais dans un deuxième temps, ils devraient jeter un regard général sur les processus liés aux chaînes d'approvisionnement logicielles.
Après tout, même Log4Shell, quelle que soit la pertinence de la faille de sécurité, n'est "qu'un" composant défectueux dans la chaîne d'approvisionnement logicielle", déclare Udo Schneider, IoT Security Evangelist Europe chez Trend Micro.
Log4Shell - Connaissez-vous votre supply chain logicielle ?
Bien sûr, la menace critique posée par la vulnérabilité Log4Shell nécessite une réponse immédiate. Mais dans un deuxième temps, les entreprises doivent généralement se poser des questions sur les processus liés aux chaînes d'approvisionnement logicielles et aux dépendances documentées (?).
La vulnérabilité Log4Shell connue il y a quelques jours est sur toutes les lèvres et tient les experts en sécurité du monde entier sur leurs gardes. Le BSI parle de "situation de menace extrêmement critique" car la bibliothèque vulnérable Log4J est, pour ainsi dire, "le" standard de journalisation dans les environnements Java. En conséquence, il est également utilisé dans des milliers d'applications et de services Internet. De plus, la vulnérabilité est facile à abuser et, dans de nombreux cas, peut être exploitée à distance, permettant finalement l'exécution de commandes arbitraires. Un vrai cauchemar du point de vue de la cybersécurité ! Les organisations peuvent suivre nos recommandations détaillées et appliquer les correctifs existants et appliquer les meilleures pratiques pour une réponse immédiate. Mais dans un deuxième temps, ils devraient jeter un regard général sur les processus liés aux chaînes d'approvisionnement logicielles. Après tout, même Log4Shell, quelle que soit la pertinence de la vulnérabilité en matière de sécurité, n'est "qu'un" composant défectueux de la chaîne d'approvisionnement logicielle.
Log4Shell le bloc de construction défectueux
Pour comprendre les chaînes d'approvisionnement en logiciels et leur contexte, il est utile de regarder le monde "réel", comme la fabrication de produits électroniques. Les soi-disant « nomenclatures » (BOM – Bill of Material) pour les assemblages sont monnaie courante. Si vous considérez une seule carte de circuit imprimé comme un assemblage, la liste des pièces appropriées contient une liste de tous les composants utilisés, tels que les résistances, les condensateurs, les diodes, les circuits intégrés et bien plus encore. Les paramètres exacts, les fabricants, les prix, les sources d'approvisionnement et finalement aussi les numéros de série ou au moins les informations de lot sont également stockés pour chaque composant.
S'il existe des informations du fabricant de l'un des composants indiquant que certains composants d'un lot ne correspondent pas aux valeurs de température spécifiées, il est possible de retracer exactement quelles cartes (chacune avec son propre numéro de série) sont a) concernées et b ) s'il est nécessaire d'agir. Si des mesures appropriées doivent être prises, les informations sur les ensembles concernés (sur la base du numéro de série) sont bien sûr d'une grande aide. En fin de compte, cette procédure se poursuit avec des "assemblages" presque à volonté... jusqu'à ce que vous finissiez par vous retrouver avec des installations massives comme le LHC au CERN. Même avec une machine aussi grande, la défaillance d'un petit composant SMD peut entraîner la défaillance de toute la machine. Si, par exemple, des lots défectueux sont connus, vous devez finalement être en mesure de vérifier chaque résistance individuelle installée.
Nomenclature logicielle (SBOM)
C'est exactement ainsi que fonctionnent les chaînes d'approvisionnement logicielles, c'est-à-dire les SBOM »- et plus précisément Log4Shell : pouvez-vous dire rapidement si vous êtes concerné par cet écart ? Avec votre propre logiciel qui utilise Log4J, la question peut peut-être trouver une réponse rapidement. Souvent, même des services SCM comme GitHub ou GitLab offrent directement de telles fonctions. Mais qu'en est-il des dépendances transitoires ? Une bibliothèque tierce que vous utilisez utilise-t-elle Log4J en interne ? Ou pire encore - une bibliothèque que vous utilisez utilise-t-elle une bibliothèque qui dépend à son tour (etc.) d'une bibliothèque qui utilise Log4J ? Le logiciel acheté d'un fournisseur de services repose-t-il sur Log4J ? Un service cloud que vous achetez utilise-t-il Log4J ?
Contenu SBOM (Image : Trend Micro).
Des questions sur des questions qui ont besoin de réponses qui vous obligent à vous attaquer aux SBOM. Log4Shell montre clairement les problèmes qui surviennent lorsque la chaîne d'approvisionnement logicielle n'est pas documentée. Mais ne soyez pas dupe. Log4Shell est certainement une sorte de pire scénario en ce moment. Mais même avec de simples "défauts" qui ne concernent pas directement la sécurité, la question de savoir si vous êtes concerné est importante !
Dépendances de documents
Fondamentalement, les SBOM consistent à documenter les dépendances. Il peut s'agir de dépendances sous forme de logiciels (composants) mais aussi de services, de licences, de serveurs et bien plus encore. Notamment lorsqu'il s'agit de modéliser les dépendances logicielles, deux formats d'échange ont émergé au fil du temps : CycloneDX et SPDX. Les deux permettent la description de différents composants logiciels, y compris les dépendances possibles :
Mais le langage descriptif ne suffit pas. Au contraire, l'environnement spécifique doit également être décrit et tenu à jour. Bien entendu, ces descriptions peuvent être créées manuellement - et parfois, par exemple lorsque l'on dépend de services externes, il n'y a pas d'autre choix. Cependant, lorsqu'il s'agit de créer des descriptions de logiciels, l'effort manuel n'a pas de sens. Ici, la création et la maintenance de ces descriptions doivent s'effectuer de manière entièrement automatique dans le cadre du pipeline CI/CD. Il existe essentiellement deux approches : l'intégration dans le processus de génération et l'analyse des artefacts de génération.
Intégration CI/CD – processus de construction
Création de SBOM pendant le processus de génération (Image : Trend Micro).
CycloneDX et SPDX ont tous deux des outils qui peuvent être intégrés directement dans le processus de construction. Ceux-ci extraient directement les dépendances "à la source" (transitoires). Il peut s'agir de bibliothèques, de fichiers exécutables, mais aussi de conteneurs ou de couches de conteneurs. L'intégration directe permet également de suivre les dépendances qui existent, par exemple, uniquement lors de la construction elle-même, mais pas dans le produit fini.
Intégration CI/CD – artefact de construction
Même si vous n'êtes pas autorisé à intervenir directement dans le processus de construction, il existe des outils pour CycloneDX et SPDX qui analysent le résultat final "après". Cela signifie que ces outils extraient les dépendances de l'application Java, par exemple, et les documentent. Comme ces outils ne voient toujours que le résultat fini, il est tout à fait possible que certaines dépendances soient tout simplement oubliées, puisqu'elles ne peuvent plus être déduites du résultat final.
Surveillance de la vulnérabilité
Création de SBOM après le processus de génération (Image : Trend Micro).
Pour les entreprises qui ne s'intéressent qu'à la surveillance des vulnérabilités, bon nombre de ces outils offrent également une corrélation directe avec les bases de données de vulnérabilités. Cela signifie que la sortie contient non seulement les composants trouvés, mais également une liste des vulnérabilités. Ceci est comparable, par exemple, à l'intégration de snyk, Trend Micro Application Security ou Trend Micro Container Security dans le pipeline CI/CD.
Suivi des dépendances OWASP
Si le suivi et la documentation des licences, l'inventaire ou le degré de distribution jouent également un rôle, d'autres solutions (en plus) sont disponibles. Dans cet environnement, l'outil de suivi des dépendances de l'OWASP (Open Web Application Security Project) est certainement l'un des meilleurs. En tant que solution open source, il est généralement intégré aux pipelines CI/CD et y reçoit les données SBOM - soit via les données CycloneDX/SPDX (manuel, API) soit directement à partir du processus de construction. De plus, Dependency Track stocke automatiquement les données de vulnérabilité de diverses bases de données de vulnérabilité et corrèle en permanence les données des versions (historiques) et des vulnérabilités. Les correspondances sont affichées en conséquence dans un tableau de bord ou signalées directement via le chat et l'intégration CI/CD ou éventuellement transmises à des outils de correction automatique.
Intégration de la piste de dépendance (Image : https://github.com/DependencyTrack/dependency-track )
Dependency Track est une base de données avec laquelle la question : "Où suis-je affecté par Log4Shell" peut être facilement répondue. Cette réponse inclut non seulement les versions actuelles du logiciel, mais également des descriptions des anciennes versions. Un constat possible peut donc être qu'une entreprise n'est pas concernée dans la version actuelle (puisqu'elle est suffisamment patchée), mais que 34 versions plus anciennes sont concernées. Si vous suivez désormais également les informations sur le nombre de versions installées, il s'agit de données presque parfaites pour une évaluation des risques bien fondée.
Conclusion sur Log4j, Log4Shell et les chaînes d'approvisionnement
Enfin, il est important de pouvoir répondre aux questions posées au début : Utilisons-nous (directement ou dans notre chaîne d'approvisionnement logicielle) Log4J ? Si oui, dans quelle mesure (version, distribution) sommes-nous concernés par Log4Shell ? L'effort requis pour répondre à cette question est un indicateur de la mesure dans laquelle vous avez un aperçu de votre chaîne d'approvisionnement logicielle et s'il vaut la peine d'utiliser des outils pour y aider.
Concernant les outils, il est important de préciser s'il s'agit "uniquement" de la question "suis-je concerné". Si tel est le cas, des outils comme snyk ou les options intégrées dans GitHub et GitLab vous aideront. D'autre part, si une vue plus complète est souhaitée, il existe d'autres solutions pour capturer et cataloguer les artefacts logiciels. Ceux-ci sont à la fois commerciaux et gratuits. Du camp open source, Dependency Track est certainement le plus répandu ici.
En fin de compte, cependant, il convient de noter que les failles de sécurité sont un argument important pour la gestion de la chaîne d'approvisionnement logicielle - mais certainement pas le seul !
Plus sur TrendMicro.com
À propos de Trend Micro En tant que l'un des principaux fournisseurs mondiaux de sécurité informatique, Trend Micro aide à créer un monde sécurisé pour l'échange de données numériques. Avec plus de 30 ans d'expertise en matière de sécurité, de recherche sur les menaces mondiales et d'innovation constante, Trend Micro offre une protection aux entreprises, aux agences gouvernementales et aux consommateurs. Grâce à notre stratégie de sécurité XGen™, nos solutions bénéficient d'une combinaison intergénérationnelle de techniques de défense optimisées pour les environnements de pointe. Les informations sur les menaces en réseau permettent une protection meilleure et plus rapide. Optimisées pour les charges de travail cloud, les terminaux, les e-mails, l'IIoT et les réseaux, nos solutions connectées offrent une visibilité centralisée sur l'ensemble de l'entreprise pour une détection et une réponse plus rapides aux menaces.