La menace persistante
Cela fait plus de 18 mois que la vulnérabilité log4j a provoqué une onde de choc dans la communauté de la cybersécurité. Pourtant, des rapports récents indiquent que pas moins de 40 % des téléchargements de log4j sont toujours vulnérables aux exploitations et que 72 % des organisations étaient encore vulnérables à log4j au 1er octobre 2022. Rien qu’en mai 2023, notre plateforme F5 Distributed Cloud a contribué à protéger nos clients contre plus d’un million de tentatives d’attaque log4j, qui ont été neutralisées avec succès grâce aux fonctionnalités de protection des applications web et des API.
Il ne s’agit que d’un exemple de CVE illustrant les difficultés persistantes auxquelles les organisations sont confrontées pour suivre la gestion des correctifs liés aux CVE, un problème qui ne fera que s’amplifier. Le nombre de CVE publiées augmente rapidement, et F5 Labs prévoit que le nombre de nouvelles CVE publiées au cours d’une semaine type atteindra 500 par semaine d’ici 2025. Cela fait presque deux ans que la vulnérabilité log4j a été révélée, et les organisations tentent toujours de rattraper leur retard tandis que le problème global continue d’évoluer. Malgré la disponibilité de correctifs et de mises à jour, de nombreux facteurs contribuent à la persistance de vulnérabilités telles que log4j.
Défis organisationnels
Le nombre considérable et la fréquence des nouvelles vulnérabilités empêchent les organisations de suivre le rythme — voire d’en avoir connaissance — à mesure qu’elles apparaissent, faute d’informations ou de ressources suffisantes pour se tenir au courant des nouveaux avis de sécurité. Une fois une vulnérabilité identifiée, l’application de correctifs aux systèmes concernés peut s’avérer complexe, en particulier dans les grandes organisations dotées de systèmes interconnectés. Elle exige alors des efforts et une coordination considérables, ce qui allonge les cycles de déploiement des correctifs. La coexistence d’infrastructures, de systèmes et d’applications anciens et modernes dans la plupart des organisations accroît encore cette complexité et peut entraîner des problèmes de compatibilité, des coûts élevés ou des contraintes de temps importantes lors du déploiement de mises à jour critiques. En outre, l’application de correctifs et les mises à jour sont compliquées par les dépendances indirectes susceptibles d’exister au sein des chaînes d’approvisionnement logicielles ou des composants d’infrastructure. Celles-ci peuvent constituer un angle mort, même lorsqu’une organisation n’utilise pas directement le système vulnérable. Comme pour le code logiciel lui-même, les erreurs humaines et les négligences peuvent également entraver les efforts d’atténuation : les développeurs ou les administrateurs peuvent ne pas voir la nécessité d’appliquer un correctif ou configurer incorrectement les systèmes. Enfin, les organisations dotées d’infrastructures informatiques complexes ou d’une culture réticente au risque peuvent tarder à adopter les correctifs en raison de tests approfondis, de craintes de perturbations ou de priorités opérationnelles concurrentes. Pour ne rien arranger, la plupart des organisations manquent de personnel, en particulier dans le domaine de la sécurité. Alors, comment peuvent-elles suivre le rythme tout en s’efforçant sans relâche d’appliquer des correctifs et de mettre à jour leurs systèmes et applications ?
Conclusion
La correction de vulnérabilités telles que log4j nécessite un effort collectif de la part des organisations, des développeurs, des fournisseurs et de l’ensemble de la communauté de la cybersécurité. L’application rapide et complète des correctifs, une meilleure sensibilisation, de solides pratiques de gestion des vulnérabilités et une surveillance continue sont essentielles pour limiter la persistance des vulnérabilités et protéger les organisations contre d’éventuelles attaques. Bien que les correctifs soient indispensables pour remédier aux vulnérabilités connues telles que log4j, ils ne peuvent garantir une protection totale, car de nouvelles vulnérabilités apparaissent constamment. Pour réduire efficacement les risques, les organisations doivent adopter des solutions de sécurité complètes. Cela inclut la mise en place de pare-feu pour applications web (WAF) et de mesures de sécurité des API afin de se prémunir contre les attaques visant la couche applicative. En outre, une surveillance continue est cruciale pour détecter les menaces émergentes et y répondre rapidement. En adoptant une approche globale associant l’application de correctifs, des mesures de sécurité robustes et une surveillance continue, les organisations peuvent mieux protéger leurs systèmes et leurs données contre des risques de sécurité en constante évolution.
Les correctifs sont bien appliqués, mais souvent (comme dans le cas de log4j), ils ne le sont pas assez rapidement, tandis que de nouvelles CVE sont identifiées à un rythme soutenu. Il est donc essentiel que les entreprises disposent d’une couche de sécurité complète en amont de leurs applications, quel que soit leur niveau de mise à jour et d’application des correctifs. La protection des applications internes comme de celles accessibles sur le Web à l’aide d’une solution telle que la solution de protection des applications Web et des API de F5 Distributed Cloud (WAAP) est essentielle pour combler les failles de sécurité pendant que les entreprises résorbent leur retard en matière de correctifs et de mises à jour.
Quelques ressources et liens connexes :
- F5 Labs : l’évolution du paysage des CVE – et les 7 CVE les plus étranges (vous n’allez pas croire la numéro 6 !)
- Blog F5 : Protection contre la vulnérabilité Apache Log4j2 (CVE-2021-44228)
- F5 DevCentral : Pourquoi nous publions des CVE
- CVE.org : découvrez la mission du programme CVE et bien plus encore
- National Vulnerability Database (NVD) : restez informé des vulnérabilités liées à Log4j et des autres CVE
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.