La vulnérabilité Log4J atteint des proportions endémiques, selon un rapport

Chargé d’enquêter sur la vulnérabilité découverte fin 2021 dans la bibliothèque Java Log4J, le Cyber Safety Review Board (CSRB) du Department of Homeland Security (DHS) américain affirme dans un rapport récemment publié que celle-ci restera un danger pendant de nombreuses années.

Image : Getty

Ce premier rapport du CSRB révèle que, malgré les efforts des organisations des secteurs fédéral et privé pour protéger leurs réseaux, Log4j est devenu une « vulnérabilité endémique », ce qui signifie que des versions non corrigées de la bibliothèque logicielle omniprésente demeureront dans systèmes pour la prochaine décennie, sinon plus.

Le CSRB, créé l’année dernière dans le cadre d’un vaste décret exécutif du Président Joe Biden pour revoir l’approche du gouvernement fédéral en matière de cybersécurité s’est penché durant 5 mois sur la vulnérabilité. Un panel de 15 personnes a été mandaté pour étudier comment la vulnérabilité de Log4J s’est produite et des leçons qu’on peut tirer de la réponse globale de la communauté de la cybersécurité.

Rob Silvers, sous-secrétaire à la politique du DHS et président du panel a déclaré que les membres du conseil d’administration ont mené des entretiens avec environ 80 organisations et se sont entretenus avec des experts de l’industrie, des gouvernements étrangers et du domaine de la cybersécurité pour obtenir des informations. La commission a également parlé avec des représentants du gouvernement chinois, car c’est un ingénieur d’Alibaba – l’un des plus grands fournisseurs d’infonuagique chinois – qui a initialement découvert et signalé la vulnérabilité de l’outil logiciel open source.

La commission a formulé 19 recommandations que les organisations devraient suivre afin d’accroître leur vigilance contre Log4j. Les conclusions du CSRB suggèrent en outre de relever la barre de la sécurité au sein de la cyber-communauté, en particulier dans le domaine open source où les développeurs de logiciels disposent de « ressources limitées » et travaillent bénévolement, a déclaré Heather Adkins, vice-présidente de Google pour l’ingénierie de la sécurité et vice-présidente du panel. .

Parmi les principales conclusions du rapport, le CSRB a constaté que les développeurs de logiciels, ceux qui en font la maintenance, les équipes de réponse aux vulnérabilités et le gouvernement américain faisaient généralement des compromis sur les risques concernant l’utilisation et l’intégration des logiciels. Par exemple, les organisations ont décidé d’utiliser Log4j, plutôt que de développer un cadre de journalisation à partir de zéro. De même, les organisations décident d’utiliser un logiciel d’une organisation établie (par exemple, ASF) sur la base de ses processus matures et approuvés. 

L’événement Log4j a mis en évidence des lacunes fondamentales dans l’adoption des pratiques de réponse aux vulnérabilités et de l’hygiène globale de la cybersécurité. Ces lacunes ont mis en évidence les défis de la sensibilisation au sein des organisations : coordonner les sources d’information fiables et faisant autorité, l’atténuation à grande échelle, mesurer l’ampleur du risque et synchroniser la compréhension des menaces et les actions défensives correspondantes.

Matt Chiodi, directeur général de la confiance chez Cerby, une firme spécialisée en cybersécurité a déclaré que Log4J est l’un de ces composants logiciels qui est omniprésent et qu’on retrouve dans des applications telles que Apache Struts, ElasticSearch, Redis, Kafka et plusieurs autres, il n,est donc pas surprenant que le CSRB l’étiquette comme une « vulnérabilité endémique ».

Il ajoute qu’une protection à 100 % contre ce type de risques n’est pas possible mais qu’ils peuvent être minimisés en faisant deux choses :

  • Être très rigoureux au sujet de la connaissance de vos actifs et
  • Tendre vers une architecture à vérification systématique.

Le rapport (en anglais) est disponible ici.

Lire aussi :

Quatre des 15 principales vulnérabilités exploitées l’an dernier dataient de plus d’un an

Vulnérabilité dans le moteur de conteneur CRI-O pour Kubernetes

Vulnérabilité Log4j2 dans l’application Serv-U

Renaud Larue Langlois
Renaud Larue Langlois
Un peu journaliste, un peu gestionnaire TI, totalement passionné de technologie. Après plus de 25 ans dans le domaine des TI, devenir rédacteur était tout naturel pour Renaud. C'est réellement une affaire de famille. Ses champs d'intérêt sont… tout, en autant que ça concerne la technologie. On peut le joindre à [email protected].

Articles connexes

Vulnérabilité Log4j2 dans l’application Serv-U

Les administrateurs informatiques sont invités à mettre à jour l'application Serv-U de SolarWinds contre le bogue Log4j.

Recourir aux logiciels ouverts requiert agilité et vigilance

Les entreprises qui utilisent le code source ouvert ont le devoir d'agir vite quand des bogues sont trouvés, selon Apache.

Apache livre un cinquième correctif en décembre pour colmater un bogue dans Log4j

Plus d'un chercheur en sécurité a prédit que les vulnérabilités Log4j/Log4Shell qui ont été découvertes avant les fêtes ne seraient pas les dernières.

Cybersécurité : Apache publie un troisième correctif Log4j

La crise liée à la vulnérabilité Log4j se poursuit, avec des développements presque chaque jour, dont la découverte d'un nouveau vecteur d'attaque.

Log4Shell : assouplissement d’une obligation fiscale pour les entreprises

Les entreprises qui ne peuvent avoir accès à des services en ligne de Revenu Québec en raison de la fermeture temporaire des services publics en ligne de l’administration publique du Québec auront droit à l’assouplissement d’une date d’échéance.

Emplois en vedette

Les offres d'emplois proviennent directement des employeurs actifs. Les détails de certaines offres peuvent être soit en français, en anglais ou bilinguqes.