Pourquoi les vulnérabilités de Log4j soulignent l'importance de DevSecOps

En décembre 2021, les équipes de sécurité informatique et les organisations de développement du monde entier ont reçu un réveil brutal. Des chercheurs ont découvert une grave faille de sécurité dans l'utilitaire Apache Log4j, un composant de journalisation populaire intégré dans d'innombrables applications et services Java. L'annonce de cette vulnérabilité a poussé les équipes de sécurité informatique et les organisations de développement à se précipiter pour trouver toutes les instances des versions vulnérables de Log4j sur leurs propres réseaux.

La vulnérabilité de Log4j a également obligé les équipes DevSecOps à répondre à une question qui semble désormais moins théorique. Si Log4j ou toute autre vulnérabilité compromettait une application développée en interne, les équipes de sécurité seraient-elles en mesure d'isoler l'attaque et d'en limiter les dégâts ? Les pratiques DevOps actuelles permettent-elles à une organisation de se lancer rapidement et efficacement dans la chasse aux menaces à travers son propre code ?

Jetons un coup d'œil rapide à la vulnérabilité de Log4j, à ce qu'elle signifie pour les équipes DevSecOps et à la façon dont la segmentation zéro confiance d'Illumio peut aider les équipes DevSecOps à atténuer les menaces lorsque des logiciels vulnérables sont attaqués avant qu'ils ne puissent être corrigés.

La vulnérabilité de Log4j et son importance

La vulnérabilité qui retient toute l'attention concerne l'utilisation par Log4j de l'interface Java Naming and Directory Interface (JNDI), une API de nommage et de recherche très répandue pour les applications Java. Les premières versions de Log4j activaient par défaut la fonction de substitution de recherche de message de JNDI. Grâce à cette fonctionnalité, les attaquants peuvent soumettre des messages soigneusement construits à une application, forçant cette dernière à exécuter du code chargé à partir de serveurs LDAP ou d'autres points d'extrémité sous le contrôle de l'attaquant. Ce code peut installer des logiciels malveillants, exfiltrer des données ou effectuer d'autres actions malveillantes sur le réseau de l'application.

Log4j est largement utilisé. Google estime qu'il est présent dans 4 % des paquets Java du Maven Central Repository, largement reconnu comme le plus important référentiel de paquets Java. Log4j est utilisé dans toutes sortes de logiciels, des applications web aux services back-end en passant par les applications personnalisées pour les appareils IoT.

Dès l'annonce de cette vulnérabilité, les équipes de sécurité informatique ont commencé à parcourir leurs réseaux, à la recherche de noms de fichiers et d'autres indications de la présence de Log4j dans n'importe quel répertoire de leur environnement. Les équipes DevOps se sont également mises au travail, fouillant dans leurs propres archives à la recherche d'une quelconque utilisation de Log4j dans leurs propres applications.

Les enjeux sont importants. Les cybercriminels ont déjà utilisé cette vulnérabilité pour lancer des attaques par ransomware, installer des logiciels de minage de monnaie sur des réseaux d'entreprise et infiltrer le ministère belge de la défense. Les attaquants conçoivent de nouvelles formes de logiciels malveillants ciblant cette vulnérabilité. Par exemple, le nouveau ransomware Night Sky cible les vulnérabilités Log4j dans le logiciel VMware Horizon.

Vue d'ensemble : les vulnérabilités du code source et les risques qu'elles représentent

La vulnérabilité de Log4j met en lumière deux problèmes plus importants pour les organisations de développement interne. Tout d'abord, quelle que soit la qualité de l'organisation de leurs outils et processus DevOps, la plupart des organisations ont des difficultés à déterminer tous les composants utilisés dans leurs applications, en particulier si ces composants sont intégrés sous forme de bibliothèques ou accessibles par le biais de dépendances avec d'autres services.

Dans le cas de Log4j, par exemple, il est possible d'inclure l'utilitaire dans une application sans laisser un fichier JAR Log4j dans un référentiel. Trouver toutes les versions de tous les composants logiciels - open source ou non - dans les applications est un travail difficile et fastidieux.

Deuxièmement, si l'on découvre qu'une application est attaquée en raison d'une vulnérabilité, les équipes de sécurité ont besoin d'un moyen d'isoler l'attaque immédiatement avant qu'elle ne se propage à d'autres systèmes sur le réseau.

La détection et l'arrêt des attaques Log4j sont importants non seulement pour protéger les données sensibles et assurer la continuité des opérations, bien que ces objectifs soient évidemment cruciaux.

Mais il y a aussi un aspect de conformité. Le janvier 4, 2022, la Commission fédérale du commerce des États-Unis (FTC) a annoncé qu'elle appliquerait des sanctions et des amendes à l'encontre des entreprises qui ont permis la violation de données confidentielles de consommateurs à la suite des vulnérabilités de Log4j.

Citant la sanction de 700 millions de dollars infligée à Equifax pour la fuite de données de consommateurs en raison d'une vulnérabilité non corrigée dans le cadre Apache Struts, la FTC a annoncé son "intention d'utiliser toute son autorité légale pour poursuivre les entreprises qui ne prennent pas de mesures raisonnables pour protéger les données des consommateurs contre l'exposition résultant de Log4j, ou de vulnérabilités similaires connues à l'avenir".

Il s'avère que Log4j n'est que la partie émergée d'un gigantesque iceberg de menaces potentielles. Pour trouver et corriger les vulnérabilités liées non seulement à Log4j, mais aussi à n'importe quel composant logiciel de leurs propres applications ou des applications tierces qu'elles utilisent, les entreprises ont besoin d'une visibilité complète de leurs environnements logiciels. Le fait de ne pas détecter ces vulnérabilités avant qu'elles n'entraînent une violation de données peut conduire à des amendes réglementaires élevées et à des dommages durables pour l'image de marque d'une organisation.

Heureusement, DevSecOps peut vous aider.

Le rôle de DevSecOps dans l'atténuation des menaces liées aux vulnérabilités des logiciels

L'idée derrière DevSecOps est simple : La sécurité ne doit pas être une réflexion après coup lorsqu'il s'agit de développer et de déployer des logiciels. Au contraire, la sécurité devrait être incluse dans chaque étape de DevOps, de la conception au développement, en passant par les tests, la mise en production et la gestion des opérations. DevSecOps est la pratique qui consiste à intégrer la sécurité dans les applications logicielles développées et gérées par les processus DevOps.

Comment DevSecOps peut-il aider à résoudre des problèmes tels que la vulnérabilité de Log4j ?

Tout d'abord, les meilleures pratiques DevSecOps exigeraient que les équipes de développement utilisent des versions actualisées de composants tels que Log4j lors de la création et de la gestion d'applications.

Deuxièmement, DevSecOps demanderait également aux organisations de développement et de test de suivre les versions de tous les composants, y compris les composants open-source, utilisés dans les applications. Ainsi, si la communauté de la sécurité informatique annonce une vulnérabilité dans un composant particulier, l'organisation DevSecOps peut rapidement déterminer quelles sont ses propres applications, le cas échéant, qui sont concernées.

Tout aussi importantes, les meilleures pratiques DevSecOps préconisent l'intégration de contrôles de sécurité dans les applications, de sorte que lorsque, inévitablement, une autre bibliothèque ou un autre composant open-source s'avère vulnérable, les équipes peuvent être préparées à contenir rapidement et efficacement toute attaque de type "zero-day" contre cette vulnérabilité. Si des mesures défensives sont déjà en place, l'organisation peut agir pour se défendre contre une attaque, même si un correctif pour la vulnérabilité n'est disponible que dans quelques jours ou quelques semaines.

L'un des meilleurs contrôles de sécurité à intégrer est une solution de segmentation zéro confiance qui utilise les pare-feu intégrés aux systèmes pour appliquer des politiques de sécurité limitant le trafic réseau aux seuls utilisateurs et processus autorisés. En réduisant considérablement les chemins d'accès au réseau accessibles aux attaquants, la segmentation zéro confiance les enferme, les isolant sur les quelques systèmes qu'ils pourraient réussir à compromettre dans un premier temps. Si la segmentation zéro confiance est en place, les attaquants ne pourront pas télécharger et exécuter du code à partir d'un site malveillant.

Si une attaque est isolée sur le réseau, les cybercriminels ne peuvent pas propager le ransomware à d'autres systèmes. Ils ne peuvent pas explorer furtivement le réseau à la recherche de données précieuses à exfiltrer. Ils sont coincés sur place comme un cambrioleur malchanceux qui a réussi à s'introduire par une lucarne pour se retrouver dans un piège à ours. Ils sont entrés, mais ils ne vont nulle part. Et une alarme a été tirée.

Illumio offre la visibilité et l'automatisation dont les équipes DevSecOps ont besoin.

La segmentation zéro confiance d'Illumio est une solution de sécurité précieuse pour toute organisation DevSecOps, car elle permet aux équipes de développement d'intégrer facilement des contrôles de sécurité rigoureux dans les applications sans avoir à apprendre les subtilités des pratiques de réseau ou de sécurité.

Illumio protège les applications en permettant aux développeurs et aux équipes de sécurité de définir facilement des politiques de segmentation sans confiance. Une fois créées, les organisations peuvent alors facilement appliquer ces politiques en utilisant le Virtual Enforcement Node (VEN) d'Illumio ainsi que les pare-feu basés sur l'hôte déjà intégrés dans les systèmes où les applications de l'organisation sont exécutées. Le VEN d'Illumio est un client léger, à sécurité intégrée, qui peut être facilement inclus dans les logiciels. Aucune modification importante de la conception n'est nécessaire.

La solution d'Illumio utilise des pare-feux, mais épargne aux développeurs l'obligation de programmer des ensembles complexes de règles de pare-feux. En revanche, il permet aux développeurs et aux équipes de sécurité de définir les politiques qu'ils souhaitent voir appliquer, en n'autorisant que le trafic nécessaire à passer par leurs applications, puis de transmettre ces politiques aux réseaux virtuels intégrés dans les applications pour qu'elles soient appliquées.

Les organisations DevSecOps peuvent affiner les politiques en fonction des applications et des environnements. Plus précisément, ils peuvent définir des politiques basées sur :

• Rôles dans l'application
• L'application elle-même
• L'environnement dans lequel l'application s'exécute, tel que le développement, le test ou la production.
• L'emplacement de l'environnement : par exemple, un environnement de production dans un centre de données de la côte ouest des États-Unis.

Ensuite, l'équipe DevSecOps ajoute simplement un VEN Illumio à une version du logiciel. Une fois installé dans l'environnement de l'application, le VEN applique les politiques de confiance zéro, émet des alertes en cas de détection d'un mouvement latéral suspect et réduit le trafic en réponse à des attaques actives, isolant ainsi les points d'extrémité infectés du reste du réseau.

Illumio propose également un client C-VEN et un service Kubelink pour une utilisation dans les environnements conteneurisés, qui sont populaires dans les architectures microservices. C-VEN est un agent Illumio léger, s'exécutant en tant que pod sur chaque nœud d'un cluster Kubernetes, qui protège le nœud et tous les pods qui s'y exécutent. Livré sous la forme d'un DaemonSet, C-VEN s'adapte à l'évolution du cluster. Kubelink est un service Illumio qui surveille le serveur API Kubernetes pour en savoir plus sur les ressources au sein du cluster et fournir un contexte Kubernetes au PCE. Il est livré sous forme de paquet et ne nécessite qu'une seule réplique par grappe, ce qui contribue à rendre les solutions de conteneurs d'Illumio très évolutives.

Les équipes DevSecOps ont deux façons d'interagir avec le PCE d'Illumio : par l'interface utilisateur du PCE ou par ses API REST bien documentées. Les équipes DevSecOps peuvent utiliser les API pour intégrer Illumio dans les pipelines CI/CD, de sorte que la segmentation zéro confiance devienne une partie standard des flux de travail DevSecOps. Les API permettent également aux équipes de sécurité d'intégrer Illumio à d'autres outils et flux de travail de sécurité.

La suite de produits Illumio offre une segmentation sans confiance partout où les applications et les services sont déployés, y compris les points d'extrémité dans.. :

• Centres de données : Illumio Core
• Nuages publics, privés ou hybrides : Illumio CloudSecure
• Périphériques d'extrémité : Illumio Edge

Log4j ne sera pas le dernier composant logiciel présentant une vulnérabilité dangereuse. En adoptant des pratiques DevSecOps et en utilisant Illumio pour appliquer la segmentation zéro confiance dans toutes les applications, les organisations peuvent être prêtes à protéger leurs données, leurs applications et leurs employés pendant que le travail fastidieux de balayage du réseau et de chasse aux menaces se poursuit.

Pour en savoir plus :

• Consultez le résumé de la solution, Illumio pour DevSecOps.
• Contactez-nous pour une démonstration.