De tels problèmes sont susceptibles d’affecter de manière disproportionnée les petites et moyennes entreprises, dit-il, et les rendent presque impossibles à résoudre facilement. L’analyse de Sonatype a révélé qu’environ 30 % de la consommation de Log4j provient de versions potentiellement vulnérables de l’outil. « Certaines entreprises n’ont pas compris le message, n’ont pas le matériel et ne savent même pas par où commencer », explique Fox. Sonatype est l’une des sociétés qui fournissent un outil d’analyse pour identifier le problème, s’il existe. Un client leur a dit que sans cela, ils auraient dû envoyer un e-mail à 4 000 propriétaires d’applications avec lesquels ils travaillaient pour leur demander de déterminer individuellement s’ils étaient concernés.
Une partie du problème, bien sûr, est la dépendance excessive des entreprises à but lucratif à l’égard des logiciels libres et open source développés et maintenus par une petite équipe de bénévoles débordée. Les problèmes de Log4j ne sont pas les premiers – le bogue Heartbleed qui a ravagé OpenSSL en 2014 est un exemple très médiatisé d’un problème similaire – et ne sera pas le dernier. « Nous n’achèterions pas de produits comme des voitures ou de la nourriture à des entreprises qui ont des pratiques de chaîne d’approvisionnement vraiment terribles », déclare Brian Fox, directeur de la technologie chez Sonatype, un spécialiste de la gestion et de la sécurité de la chaîne d’approvisionnement logicielle. « Pourtant, nous le faisons tout le temps avec un logiciel.
Les entreprises qui savent qu’elles utilisent Log4j et qui utilisent une version assez récente de l’utilitaire ont peu à s’inquiéter et peu à faire. « C’est la réponse peu séduisante : cela peut en fait être très facile », explique Fox.
Le problème survient lorsque les entreprises ne savent pas qu’elles utilisent Log4j, car il est utilisé dans une petite section d’une application ou d’un outil importés sur lesquels ils n’ont aucun contrôle et ne savent pas par où commencer à le rechercher. « C’est un peu comme comprendre quel minerai de fer est entré dans l’acier qui s’est retrouvé dans le piston de votre voiture », explique Glass. « En tant que consommateur, vous n’avez aucune chance de comprendre cela. »
La vulnérabilité de Log4j, dans une bibliothèque de logiciels, rend difficile la correction, explique Moussouris, car de nombreuses organisations doivent attendre que les fournisseurs de logiciels le corrigent eux-mêmes, ce qui peut prendre du temps et des tests. « Certaines organisations ont en leur sein des personnes plus qualifiées sur le plan technique qui peuvent élaborer différentes mesures d’atténuation pendant qu’elles attendent, mais essentiellement, la majorité des organisations s’appuient sur leurs fournisseurs pour produire des correctifs de haute qualité qui incluent des bibliothèques mises à jour ou des ingrédients mis à jour dans ces packages », a-t-elle déclaré. dit.
Pourtant, les entreprises, grandes et petites, aux États-Unis – et dans le monde – doivent bouger rapidement. L’un d’eux était Starling Bank, la banque challenger basée au Royaume-Uni. Parce que ses systèmes étaient en grande partie construits et codés en interne, ils ont pu détecter rapidement que leurs systèmes bancaires ne seraient pas affectés par la vulnérabilité Log4j. « Cependant, nous savions également qu’il pourrait y avoir des vulnérabilités potentielles à la fois dans les plates-formes tierces que nous utilisons et dans le code provenant de la bibliothèque que nous utilisons pour les intégrer », explique Mark Rampton, responsable de la cybersécurité de la banque.
Il y avait. « Nous avons rapidement identifié des instances de code Log4j présentes dans nos intégrations tierces qui avaient été remplacées par d’autres frameworks de journalisation », dit-il. Starling a supprimé ces traces et les a empêchées d’être utilisées à l’avenir. Simultanément, la banque a chargé son centre d’opérations de sécurité (SOC) d’analyser des centaines de milliers d’événements pour voir si Starling était ciblé par ceux qui recherchaient des vulnérabilités Log4j. Ils ne l’étaient pas, mais gardent un œil sur. Les efforts requis sont importants, mais nécessaires, dit Rampton. « Nous avons décidé d’adopter une approche » coupable jusqu’à preuve du contraire « , car la vulnérabilité s’effilochait à un rythme tel que nous ne pouvions faire aucune hypothèse », dit-il.
« Je comprends d’où la FTC essaie de venir », déclare Thornton-Trump. « Ils essaient d’encourager les gens à gérer la vulnérabilité. Mais c’est totalement sourd au risque de menace réel que cette vulnérabilité fait peser sur de nombreuses entreprises. En gros, ils vous obligent à appuyer sur le bouton de panique sur quelque chose que vous ne savez même pas si vous avez à ce stade. »
Plus de belles histoires WIRED