La vulnérabilité « Log4Shell » dans la bibliothèque open source Log4j a atteint des proportions « endémiques » et la réplique pourrait se répercuter pendant « une décennie ou plus », selon un rapport historique du gouvernement américain.

Le rapport inaugural du Cyber ​​Safety Review Board (CSRB) a fourni 19 recommandations sur la manière dont les organisations et les agences gouvernementales peuvent renforcer leurs réseaux et leurs applications contre la menace.

Le CSRB a été créé en février 2022 par le Département de la sécurité intérieure (DHS) conformément à un décret exécutif axé sur la cybersécurité signé par le président Biden un an plus tôt.

L’initiative public-privé est chargée d’examiner les événements graves de cybersécurité et de fournir des recommandations stratégiques au gouvernement, à l’industrie et à la communauté de la sécurité de l’information.

« Institution de transformation »

La vulnérabilité Log4Shell, qui a fait surface en décembre 2021, offre une puissante combinaison de super-criticité – atteignant un score de gravité CVSS maximal de 10 – et d’une surface d’attaque énorme étant donné la quasi-omniprésence de Log4j dans la fourniture d’une journalisation basée sur Java à une myriade d’applications.

Secrétaire à la sécurité intérieure Alejandro Mayorkas a dit le CSRB était une « institution transformationnelle qui fera progresser notre cyber-résilience de manière sans précédent », et son rapport contribuera à « renforcer notre cyber-résilience et faire progresser le partenariat public-privé qui est si vital pour notre sécurité collective ».

Tim Mackey, stratège principal en matière de sécurité au Synopsys Cybersecurity Research Center, a déclaré que le rapport était inhabituel en fournissant « un examen complet de l’impact et des causes profondes d’un cyberincident si rapidement ».

N’OUBLIEZ PAS DE LIRE La pollution des prototypes dans Blitz.js conduit à l’exécution de code à distance

Le CSRB rapport (PDF), publié le 14 juillet, a déclaré que « les instances vulnérables de Log4j resteront dans les systèmes pendant de nombreuses années, peut-être une décennie ou plus. Un risque important demeure.

L’Apache Software Foundation, qui gère Log4j, a été félicitée pour son « cycle de vie de développement logiciel bien établi » et « pour avoir reconnu la criticité du problème » en publiant rapidement des correctifs.

Le rapport a également salué la production rapide de conseils, d’outils et d’informations sur les menaces efficaces par les fournisseurs et les gouvernements.

Cependant, plus en aval de la chaîne d’approvisionnement, « les organisations ont encore du mal à réagir à l’événement, et le travail acharné de mise à niveau des logiciels vulnérables est loin d’être terminé dans de nombreuses organisations ».

De plus, l’événement a mis en évidence « les risques de sécurité propres à la communauté open source aux ressources limitées et basée sur le volontariat », qui, selon le CSRB, nécessitait davantage de soutien de la part des parties prenantes des secteurs public et privé.

‘Difficile à croire’

Le rapport indique que le CSRB n’était « pas au courant d’attaques importantes basées sur Log4j sur des systèmes d’infrastructure critiques », et que l’exploitation hostile semblait s’être « produite à des niveaux inférieurs à ce que de nombreux experts avaient prévu ».

Cependant, Matt Chiodi, responsable de la confiance chez le fournisseur de sécurité Cerby, a trouvé ces affirmations « très difficiles à croire », notant que – comme le CSRB l’a lui-même reconnu – les organisations ne sont pas obligées de signaler l’exploitation de vulnérabilités graves.

Chiodi a également déclaré que les recommandations, qui couvrent entre autres l’atténuation des risques Log4j en cours et la migration vers un modèle de gestion proactive des vulnérabilités, « sont trop opaques pour que les entreprises puissent les mettre en œuvre sous leur forme actuelle ».

Il a conseillé aux organisations de devenir « extrêmement sérieuses quant à la connaissance de vos actifs et à la transition vers une architecture de confiance zéro », notant que « la plupart des organisations ont de terribles pratiques de gestion des actifs », en particulier en ce qui concerne les « applications locales dans le cloud ».

Mackey, quant à lui, a mis en garde contre «la dépendance à l’égard d’un fournisseur commercial pour alerter les consommateurs d’un problème suppose que le fournisseur gère correctement leur utilisation de l’open source et qu’il est capable d’identifier et d’alerter tous les utilisateurs de leur logiciel impacté – même si la prise en charge de ce logiciel est terminé.

Dans cet esprit, « les consommateurs de logiciels doivent implémenter un modèle de confiance mais de vérification pour valider si le logiciel qui leur est fourni ne contient pas de vulnérabilités non corrigées ».