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 été prises de court. Les chercheurs avaient découvert une grave faille de sécurité dans l'utilitaire Apache Log4j, un composant de journalisation populaire intégré à 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 démener pour trouver toutes les instances des versions vulnérables de Log4j sur leurs propres réseaux.

La vulnérabilité Log4j a également contraint 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 atténuer les dégâts ? Les pratiques DevOps actuelles permettent-elles à une organisation de rechercher les menaces rapidement et efficacement via son propre code ?

Examinons rapidement la vulnérabilité Log4j, ce qu'elle signifie pour les équipes DevSecOps et comment la segmentation Zero Trust d'Illumio peut aider les équipes DevSecOps à atténuer les menaces lorsqu'un logiciel vulnérable est attaqué avant qu'il ne puisse être corrigé.

La vulnérabilité Log4j et pourquoi c'est important

La vulnérabilité qui attire toute cette attention implique Utilisation par Log4j de l'interface Java de dénomination et de répertoire (JNDI), une API de dénomination et de recherche populaire pour les applications Java. Les premières versions de Log4j activaient la fonction de substitution de recherche de messages de JNDI par défaut. Grâce à cette fonctionnalité, les attaquants peuvent envoyer des messages soigneusement conçus à une application, forçant celle-ci à exécuter du code chargé depuis des serveurs LDAP ou d'autres points de terminaison sous le contrôle de l'attaquant. Ce code pourrait 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 que c'est dans 4 % des packages Java dans le référentiel central Maven, largement reconnu comme le plus important référentiel de packages Java. Log4j est utilisé dans toutes sortes de logiciels, des applications Web aux services principaux et aux applications personnalisées pour les appareils IoT.

Dès que cette vulnérabilité a été annoncée, 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 occupées de rechercher dans leurs propres archives toute 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 rançongiciel, installer un logiciel de minage de pièces sur les 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, de nouvelles cibles du ransomware Night Sky Vulnérabilités Log4j dans le logiciel VMware Horizon.

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

La vulnérabilité Log4j met en lumière deux problèmes plus importants pour les organisations de développement internes. Tout d'abord, quelle que soit la qualité de l'organisation de leurs outils et processus DevOps, la plupart des organisations ont du mal à 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 via des 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 de fichier JAR Log4j dans un référentiel. Trouver toutes les versions de tous les composants logiciels, qu'ils soient open source ou non, dans les applications est un travail difficile et chronophage.

Ensuite, s'il est découvert qu'une application est attaquée en raison d'une vulnérabilité, les équipes de sécurité doivent trouver un moyen d'isoler l'attaque immédiatement avant qu'elle ne se propage à d'autres systèmes du réseau.

Détecter et stopper les attaques Log4j est important non seulement pour protéger les données sensibles et garantir la continuité opérationnelle, mais ces objectifs sont évidemment essentiels.

Mais il y a aussi un aspect de conformité. Le 4 janvier 2022, le La Federal Trade Commission (FTC) des États-Unis a annoncé qu'elle appliquerait des sanctions et des amendes contre les entreprises qui ont autorisé la violation des données confidentielles des consommateurs en raison des vulnérabilités Log4j.

Citant ses Amende de 700 millions de dollars contre Equifax pour avoir divulgué des données de consommateurs en raison d'une vulnérabilité non corrigée dans le framework Apache Struts, la FTC a annoncé qu'elle « avait l'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 toute exposition résultant de Log4j, ou de vulnérabilités similaires connues à l'avenir ».

Il s'avère que Log4j n'est que la pointe d'un énorme iceberg de menaces potentielles. Pour trouver et corriger les vulnérabilités non seulement liées à Log4j mais aussi à n'importe quel composant logiciel dans leurs propres applications ou dans les applications tierces qu'elles exécutent, les entreprises ont besoin d'une visibilité complète de leurs environnements logiciels. Ne pas détecter ces vulnérabilités avant qu'elles n'entraînent une violation de données peut entraîner de lourdes amendes réglementaires et des dommages durables à l'image de marque d'une organisation.

Heureusement, DevSecOps peut vous aider.

Le rôle de DevSecOps dans l'atténuation des menaces de vulnérabilité logicielle

L'idée qui sous-tend DevSecOps est simple : la sécurité ne doit pas être une question secondaire lorsqu'il s'agit de développer et de déployer des logiciels. La sécurité doit plutôt être incluse à chaque étape du DevOps, de la conception au développement, en passant par les tests, les versions 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 le biais de processus DevOps.

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

Tout d'abord, les meilleures pratiques DevSecOps demanderaient aux équipes de développement d'utiliser des versions mises à jour de composants tels que Log4j lors de la création et de la gestion des 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 applications sont concernées, le cas échéant.

Tout aussi important, les meilleures pratiques DevSecOps nécessiteraient 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 se révélerait vulnérable, les équipes puissent être prêtes à contenir attaques de type « jour zéro » contre cette vulnérabilité rapidement et efficacement. Si des mesures défensives sont déjà en place, l'organisation peut agir pour se défendre contre une attaque, même si la mise à jour de la vulnérabilité est prévue dans des jours ou des semaines.

L'un des meilleurs contrôles de sécurité à intégrer est une solution de segmentation Zero Trust qui utilise les pare-feux 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 réseau disponibles pour les attaquants, Zero Trust Segmentation enferme les attaquants et les isole sur les quelques systèmes qu'ils pourraient initialement réussir à compromettre. Avec la segmentation Zero Trust en place, les attaquants ne seraient pas en mesure de télécharger et d'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 de rançongiciel à 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 malheureux cambrioleur qui a réussi à entrer 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é déclenchée.

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

Segmentation Zero Trust 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 du réseau ou des pratiques 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 Zero Trust. Une fois créées, les organisations peuvent facilement appliquer ces politiques à l'aide d'Illumio Nœud d'application virtuel (VEN) ainsi que les pare-feux basés sur l'hôte déjà intégrés aux systèmes sur lesquels s'exécutent les applications de l'organisation. L'Illumio VEN est un client léger et infaillible qui peut être facilement inclus dans les versions logicielles. Aucune modification de conception importante n'est requise.

La solution Illumio utilise des pare-feux mais évite aux développeurs d'avoir à programmer des ensembles complexes de règles de pare-feu. Au lieu de cela, il permet aux développeurs et à l'équipe de sécurité de définir les politiques qu'ils souhaitent appliquer, en n'autorisant que le trafic nécessaire à transiter par leurs applications, puis de transmettre ces politiques aux VENs intégrés aux applications pour application.

Les organisations DevSecOps peuvent affiner les politiques pour divers environnements et applications. Plus précisément, ils peuvent définir des politiques sur la base de :

• Rôles au sein de l'application
• L'application elle-même
• L'environnement dans lequel l'application s'exécute, tel que le développement, les tests 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 Illumio VEN à une version logicielle. Une fois exécuté dans l'environnement de l'application, le VEN applique Politiques Zero Trust, émet des alertes dès la détection d'un mouvement latéral suspect et réduit le trafic en réponse à des attaques actives, isolant ainsi les terminaux infectés du reste du réseau.

Illumio propose également un Client C-VEN et service Kubelink pour une utilisation dans des environnements conteneurisés, très répandus dans les architectures de microservices. C-VEN est un agent Illumio léger, qui s'exécute en tant que pod sur chaque nœud d'un cluster Kubernetes, qui protège le nœud et tous les pods qui y sont exécutés. Fourni sous forme de DaemonSet, C-VEN évolue de haut en bas au fur et à mesure de l'évolution du cluster. Kubelink est un service Illumio qui surveille le serveur API Kubernetes pour en savoir plus sur les ressources du cluster et fournir le contexte Kubernetes au PCE. Il est livré sous forme de package et ne nécessite qu'une seule réplique par cluster, ce qui contribue à rendre les solutions de conteneurs Illumio très évolutives.

Les équipes DevSecOps peuvent interagir avec l'Illumio PCE de deux manières : via l'interface utilisateur du PCE ou 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 Zero Trust devienne un élément 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 fournit une segmentation Zero Trust partout où les applications et les services sont déployés, y compris les terminaux dans :

• Centres de données : Noyau Illumio
• Clouds publics, privés ou hybrides : Illumio CloudSecure
• Appareils terminaux : Illumio Edge

Log4j ne sera pas le dernier composant logiciel à présenter une vulnérabilité dangereuse. En adoptant les pratiques DevSecOps et en utilisant Illumio pour appliquer la segmentation Zero Trust dans toutes les applications, les organisations peuvent être prêtes à protéger leurs données, leurs applications et leurs employés tout en poursuivant le travail fastidieux d'analyse du réseau et de recherche des menaces.

Pour en savoir plus :

• Consultez le descriptif de la solution, Illumio pour DevSecOps.
• Nous contacter pour une démonstration.