Faille Log4j : l'open source n'est pas le problème

Après la Maison-Blanche, c’est au Sénat américain de s’interroger sur l'impact à long terme de la grave vulnérabilité découverte à la fin de l'année dernière dans le logiciel open source Apache Log4j. « L'open source n'est pas le problème », a déclaré le Dr Trey Herr, directeur de l'initiative Cyber Statecraft au sein du think tank américain Atlantic Council spécialisé dans les relations internationales, lors d'une audition de la commission de la sécurité intérieure et des affaires gouvernementales du Sénat américain (Senate Committee on Homeland Security & Government Affairs) cette semaine. « Cela fait des années que les problèmes de sécurité de la supply chain des logiciels préoccupent la communauté de la cybersécurité », a-t-il ajouté.

Selon les experts, il faudra beaucoup de temps et un travail de longue haleine pour remédier à la faille Log4j et à son impact. Ainsi, les chercheurs en sécurité de Cisco Talos, pensent que, à l’avenir, Log4j sera fortement exploité, et que les utilisateurs devraient appliquer sans attendre des correctifs aux produits concernés et mettre en œuvre des solutions d'atténuation. Le logiciel de journalisation Java est très répandu dans les services, les sites web et les applications d'entreprise et grand public, car c’est un outil facile à utiliser dans le développement d'applications client/serveur.

Une défense de l’open source

Si elle est exploitée, la faille Log4j donne la possibilité à un acteur distant non authentifié de prendre le contrôle d'un système serveur affecté et d'accéder aux informations de l'entreprise ou de déclencher une attaque par déni de service. La commission du Sénat a demandé à des experts de lui exposer les réponses apportées par l'industrie et les moyens de prévenir de futures expositions de logiciels. Parce que la faille Logj4 affecte un logiciel open source, les experts ont passé beaucoup de temps à défendre l’usage de logiciels open source dans les plateformes critiques. « La vulnérabilité Log4j, qui peut être exploitée en ne tapant que 12 caractères, n'est qu'un exemple de la menace sérieuse que peuvent présenter pour la sécurité nationale et économique des vulnérabilités logicielles répandues, y compris celles qui se trouvent dans un code open source, ou un code disponible librement et développé par des individus », a déclaré le président de la commission, le sénateur Gary Peters (D-MI). « En termes de quantité de services en ligne, de sites et de dispositifs exposés, l'impact potentiel de cette vulnérabilité logicielle est incommensurable, et elle met toutes nos infrastructures critiques, depuis les banques et les réseaux électriques, jusqu’aux agences gouvernementales, à la merci de violations de réseau », a ajouté le sénateur.

Le responsable de la sécurité de Cisco Brad Arkin a voulu défendre le logiciel libre. « Je pense que les logiciels open source ne sont pas en cause, comme certains l'ont suggéré, et il serait malvenu de laisser croire que la vulnérabilité Log4j est la preuve d'une faille unique ou que les logiciels open source présentent un risque accru », a déclaré Brad Arkin, vice-président senior et responsable de la sécurité de Cisco, à la commission. « La vérité, c’est que tous les logiciels contiennent des vulnérabilités dues à des erreurs de conception, d'intégration et d'écriture relevant de la compétence humaine », a-t-il encore plaidé. « Cisco est un utilisateur important et un contributeur actif aux projets de sécurité open source. Ces efforts sont essentiels et nécessaires pour maintenir l'intégrité des blocs de code partagés entre des éléments fondamentaux de l'infrastructure IT », a encore déclaré M. Arkin. « Cependant, se concentrer exclusivement sur les risques posés par les logiciels open source pourrait nous détourner d'autres domaines importants où nous pouvons remédier aux risques de sécurité inhérents à tous les logiciels », a ajouté le vice-président senior et responsable de la sécurité de Cisco.

Avoir une vision sur le long terme et les moyens de remédiation

Selon le Dr. Herr, du think tank américain Atlantic Council, il faut s’attendre à découvrir d’autres vulnérabilités similaires. « Le programme de journalisation Log4j est extrêmement populaire, et la correction de ses failles a nécessité des efforts considérables et une large attention publique, mais ce n’est pas la dernière fois que ce type d'incident se produira », a déclaré M. Herr « Parmi les efforts que les instances fédérales devraient entreprendre pour améliorer la sécurité de l'open source, serait de financer ce qui est ordinaire, en fournissant des ressources là où l'industrie ne le ferait pas, ou dans des domaines où le public manifeste peu d’intérêt, afin d'apporter des améliorations structurelles à la sécurité des supply chain en logiciels pour tous les développeurs et mainteneurs. Une meilleure sécurisation des supply chain en logiciels et du code open source est un problème d'infrastructure, et le même modèle d'investissement à long terme s'applique ».

En réponse à Log4Shell et aux futures vulnérabilités, Jen Miller-Osborn, directrice adjointe du renseignement sur les menaces auprès des chercheurs en sécurité de Unit 42 de Palo Alto Networks, a recommandé plusieurs mesures de remédiation notamment :

- Automatiser la conformité aux politiques de gestion des vulnérabilités : « Nous félicitons l'Agence de cybersécurité et d'infrastructure du ministère de la Sécurité intérieure (Department of Homeland Cybersecurity and Infrastructure Agency) d’avoir créé et mis à jour un catalogue des vulnérabilités exploitées connues, mais il est peu probable que le signalement manuel à plus de 100 agences civiles fédérales permette de garder une longueur d'avance sur l'adversaire ».

- Susciter un engagement de l'ensemble du secteur en faveur des opérations de sécurité du développement : « Un travail impressionnant est déjà réalisé dans ce domaine, mais la communauté gagnerait à adopter plus largement les outils de développement existants pour contrôler l'accès aux composants open source. Ces outils peuvent analyser tous les paquets open source pour en vérifier l'intégrité et la sécurité avant qu'ils ne soient approuvés et autorisés par les équipes d'ingénieurs à les utiliser dans les produits ».

Passer à la segmentation des réseaux et au zero trust

Brad Arkin de Cisco a aussi déclaré que la mise en œuvre d'architectures sécurisées était essentielle pour créer la séparation nécessaire à l'intérieur des systèmes afin de limiter l'impact des vulnérabilités et permettre une récupération et une résilience rapides. « Une segmentation appropriée rend plus difficile un déplacement latéral dans le réseau, même si l’attaquant peut obtenir un accès initial en exploitant une vulnérabilité », a déclaré M. Arkin. « La mise en œuvre d'un environnement zero trust protège davantage les données et les systèmes critiques contre les intrusions et l'exploitation en garantissant que chaque tentative de connexion au réseau et d'accès aux données et systèmes importants est examinée », a-t-il ajouté. M. Arkin et d'autres ont déclaré que le développement de logiciels sécurisés et les exigences de mise en réseau zero trust publiées dans un décret présidentiel l'année dernière sont des étapes importantes à suivre, indépendamment du fait qu'elles auraient pu empêcher la vulnérabilité Log4Shell.

« Les erreurs de code ne sont pas près de disparaître », a déclaré David Nalley, président de l'Apache Software Foundation. « Le fait est que, les logiciels étant écrits par des humains, il y aura encore et toujours des bogues et, malgré les meilleurs efforts, certains logiciels comporteront des failles de sécurité. En outre, parce que le monde est de plus en plus connecté et numérique, le nombre de vulnérabilités va augmenter, de même que les conséquences potentielles », a-t-il ajouté. « Il n’existe pas de solution facile en matière de sécurité logicielle. La défense doit s’appliquer en profondeur. Elle doit couvrir le développement en amont des projets open source, les fournisseurs chargés de l’intégration de ces projets, les développeurs qui utilisent le logiciel dans des applications personnalisées, et même les entreprises et organisations qui déploient ces applications pour fournir des services critiques à leurs utilisateurs », a déclaré M. Nalley.