Points Clés
- En raison du volume élevé de vulnérabilités qui existent dans les grandes infrastructures de production, la distinction entre vulnérabilité et exploitabilité peut permettre aux équipes de se concentrer d'abord sur les exploits les plus dangereux.
- Une bonne première étape dans tout programme de sécurité consiste à obtenir une visibilité complète sur la sécurité du code d'application sur l'ensemble du pipeline CI/CD. Cela permet une atténuation plus précoce des catastrophes.
- Lors du classement des vulnérabilités en fonction de leur exploitabilité, chaque vulnérabilité doit être évaluée dans le contexte de l'ensemble du programme, et pas seulement par son score CVSS.
- Utilisez la technologie de filtrage pour limiter l'efficacité des activités de reconnaissance, qui sont couramment utilisées par les attaquants en préparation d'un exploit.
- La surveillance des réseaux internes, des hôtes et des charges de travail pour les indicateurs d'attaque (Indicators of Attack IoA) et les indicateurs de compromis (Indicators of Compromise IoC) peut aider à détecter toutes les attaques qui ont dépassé les défenses de votre organisation.
Les logiciels open source sous-tendent la grande majorité des applications accessibles sur Internet. La disponibilité, l'accessibilité et la qualité de tels projets permettent aux entreprises d'innover et de réussir. C'est un excellent exemple de bien public, et quelque chose qui devrait être célébré et protégé.
L'omniprésence de l'open source signifie que toute vulnérabilité découverte a un impact considérable. Les attaquants voient une énorme opportunité, et un grand nombre d'entreprises et d'autres utilisateurs doivent réagir rapidement pour identifier les instances du logiciel vulnérable dans les applications qu'ils développent et dans les applications et composants tiers qu'ils utilisent.
La réalité est que les vulnérabilités logicielles sont courantes. Comment les professionnels de la sécurité peuvent-ils évaluer le risque posé par les vulnérabilités et concentrer au mieux les efforts de leur organisation sur la correction des vulnérabilités les plus importantes ?
Construire une visibilité complète - vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir
Les équipes de sécurité sont responsables de l'intégrité de l'ensemble de l'application, y compris tous les composants open source et les dépendances tierces qui n'ont pas été écrites par les développeurs de l'entreprise. Beaucoup de travail a été fait pour améliorer la sécurité du processus de développement de logiciels et pour suivre les dépendances avec des initiatives de "décalage à gauche" et des SBOM (software bill of materials) afin que le code envoyé à la production ait une haute confiance en la sécurité. Mais lorsqu'une vulnérabilité est publiée, comment identifier rapidement où elle se trouve dans le code déployé qui s'exécute déjà en production ? Une première étape de tout programme de sécurité consiste à obtenir une visibilité complète sur la sécurité du code d'application sur l'ensemble du pipeline CI/CD, de la construction jusqu'à la production, et sur toutes les modalités d'application et d'infrastructure, y compris l'exécution de conteneurs, Kubernetes, les fournisseurs de cloud, VM et/ou bare metal. Éliminez vos angles morts afin de pouvoir détecter et atténuer les attaques suffisamment tôt.
Concentrez-vous sur ce qui compte le plus : exploitabilité vs vulnérabilité
Après avoir obtenu une visibilité totale, il n'est pas rare que les organisations voient des dizaines de milliers de vulnérabilités dans de grandes infrastructures de production. Cependant, une liste de vulnérabilités théoriques est de peu d'utilité pratique. Parmi toutes les vulnérabilités qu'une entreprise pourrait passer du temps à corriger, il est important d'identifier celles qui sont les plus critiques pour la sécurité de l'application et qui doivent donc être corrigées en premier.
Pour pouvoir déterminer cela, il est important de comprendre la différence entre une vulnérabilité, qui est une faiblesse dans un logiciel déployé qui pourrait être exploitée par des attaquants pour un résultat particulier, et l'exploitabilité, qui indique la présence d'un chemin d'attaque qui peut être exploité par un attaquant pour obtenir un gain tangible.
Les vulnérabilités qui nécessitent un accès local avec des privilèges élevés pour être exploitées sont généralement moins préoccupantes car un chemin d'attaque serait difficile à atteindre pour un attaquant distant (si un acteur malveillant a déjà obtenu une élévation de privilèges sur un hôte local, il a un grand nombre d'opportunités pour acquérir davantage de contrôle). Les vulnérabilités les plus préoccupantes sont celles qui peuvent être déclenchées, par exemple, par un trafic réseau distant qui ne serait généralement pas filtré par les pare-feux, et qui sont présentes sur des hôtes qui reçoivent régulièrement du trafic provenant directement de sources Internet non fiables.
Évaluer et classer les exploits potentiels
Lors de l'évaluation d'une vulnérabilité pour la classer en fonction de son exploitabilité, et donc de la priorité dans laquelle la corriger, vous voudrez prendre en compte certains ou tous les critères suivants :
- La gravité de la vulnérabilité : les scores CVSS (Common Vulnerability Scoring System) fournissent une bonne base de référence de la gravité d'une vulnérabilité pour vous permettre de comparer les vulnérabilités. Cependant, les scores CVSS ne tiennent pas compte du contexte de votre propre application et de votre infrastructure, ce qui constitue une lacune que vous devrez combler pour obtenir les informations les plus précises.
- Le vecteur d'attaque : accès au réseau ou au système local : les vulnérabilités accessibles via le réseau constituent souvent la première étape d'une attaque, et les vulnérabilités d'accès au système local entrent en jeu une fois qu'un attaquant a pris pied dans l'application. Cela signifie que vous devez immédiatement bloquer tous les chemins d'attaque réseau menant à vos services vulnérables les plus exploitables et simultanément rechercher des signaux de comportement d'attaque sur les nœuds et prendre des mesures correctives.
- Proximité de la surface d'attaque : existe-t-il un chemin d'attaque qui fournit une voie viable par laquelle un attaquant peut atteindre et exploiter la vulnérabilité ? Lors de l'examen des chemins d'attaque, assurez-vous d'examiner les moyens par lesquels un attaquant pourrait contourner les pare-feu, les load balancers, les proxys et d'autres éléments, et traitez toute exposition consernée, pendant que vos développeurs travaillent sur la mise à jour, les tests et le redéploiement des applications vulnérables.
- Présence d'une connexion réseau : bien que toutes les vulnérabilités accessibles à partir de sources externes soient préoccupantes, les vulnérabilités des applications qui gèrent régulièrement les connexions réseau générales, mises en évidence par les connexions actuelles, sont les plus préoccupantes. Ce sont les vulnérabilités qu'un attaquant est le plus susceptible de découvrir en utilisant des techniques de reconnaissance (recon).
La clé ici est d'ajouter un contexte d'exécution aux données de vulnérabilité afin que vous puissiez identifier vos vulnérabilités les plus exploitables, et donc votre liste de celles à corriger en premier car elles présentent le plus grand danger pour la sécurité de votre application.
Envisagez d'utiliser des outils open source tels que ThreatMapper pour vous aider à identifier vos vulnérabilités les plus exploitables. Vous devez exécuter des outils comme celui-ci à plusieurs reprises au fil du temps à mesure que les conditions changent pour concentrer vos efforts de sécurité là où ils sont le plus nécessaires.
Limiter les activités de reconnaissance
Un attaquant suivra généralement un manuel d'instructions établi, en utilisant des tactiques et des techniques documentées par MITRE ATT&CK. Ces tactiques suivent des modèles tels que la Cyber Kill Chain et commencent par des activités de reconnaissance, puis passer à un exploit initial. L'exploit initial vise généralement à obtenir un contrôle local limité sur un système tête de pont. Depuis la tête de pont, l'attaquant dispose d'un grand nombre d'options pour explorer, augmenter les privilèges, installer des systèmes de contrôle persistants et enquêter sur les systèmes adjacents afin de se propager latéralement et de localiser le plus grand prix.
Pour limiter l'efficacité des activités de reconnaissance, commencez par identifier les chemins d'attaque qu'un attaquant pourrait emprunter pour atteindre un composant vulnérable. À la manière de ceinture et bretelles, assurez-vous que chacun de ces chemins d'attaque est sécurisé avec une technologie de filtrage :
- WAF pour capturer et éliminer le trafic de reconnaissance connu
- Filtrage basé sur le protocole et la source pour limiter les clients pouvant accéder à ce chemin
- Filtrage supplémentaire au niveau de l'application pour :
- Assurez-vous que les transactions sont authentifiées
- Pour le trafic d'API, assurez-vous que les transactions proviennent d'une utilisation de client de confiance
L'outil open source ThreatMapper visualise les chemins d'attaque menant à vos vulnérabilités les plus exploitables afin que vous puissiez déterminer la meilleure façon de les sceller.
Recherchez les « indicateurs d'attaque » et les « indicateurs de compromission »
Malgré tous les efforts déployés pour sécuriser la surface d'attaque et limiter la visibilité des attaquants, des exploits peuvent toujours se produire pour diverses raisons : attaques zero-day, tentatives délibérées de compromettre la chaîne d'approvisionnement, manque de visibilité sur le Shadow IT et d'autres actifs non gérés, etc.. Les CVE sont publiées via NVD à un taux d'environ 50 par jour, donc le risque qu'une nouvelle vulnérabilité soit découverte en production est important.
Par conséquent, une autre ligne de défense critique consiste à surveiller les réseaux internes, les hôtes et les charges de travail pour les indicateurs d'attaque (IoA) et les indicateurs de compromis (IoC).
L'IoA peut inclure un trafic exploratoire, de reconnaissance provenant de sources inhabituelles ou un trafic réseau inhabituel pouvant indiquer la présence de réseaux C2C (conteneur à conteneur), une télémétrie à distance ou des tentatives d'exfiltration. Les IoC sont des indications sur l'hôte que quelque chose ne va pas et qu'un attaquant a pris pied, y compris un comportement de processus inhabituel, un accès au système de fichiers ou une modification du système de fichiers.
Il vaut la peine d'établir une fonction "équipe rouge (red team)" qui explore régulièrement les applications et peut déterminer les signaux d'attaque et leurs impacts au fur et à mesure qu'ils s'appliquent à votre organisation individuelle. Faites appel à des outils d'entreprise pour vous aider à automatiser et à gérer les énormes volumes d'événements IoA et IoC générés par les systèmes d'entreprise, notamment en minimisant les faux positifs, en stockant les événements pour une analyse ultérieure et, surtout, en corrélant les événements pour mieux comprendre les signatures d'attaque et comment ces attaques progressent contre vos applications. Fort de ces connaissances, vous pouvez ensuite déployer des contre-mesures chirurgicales ciblées pour bloquer le trafic de reconnaissance ou d'attaque provenant de sources internes ou externes, et/ou pour mettre en quarantaine les charges de travail compromises.
Conclusion
Log4j est un autre rappel que les vulnérabilités sont inévitables. Mais cela ne devrait pas empêcher les organisations d'utiliser le code open source comme moteur de l'innovation et d'autres objectifs valables. En obtenant une visibilité complète sur le trafic des applications dans toutes les modalités de l'infrastructure, en intégrant des stratégies pour évaluer et hiérarchiser les vulnérabilités en fonction de leur risque d'exploitation et en maintenant une vigilance constante dans la recherche de traces d'attaques, les responsables de la sécurité peuvent guider leurs organisations en atténuant les risques associés à Log4j et les prochaines grandes vulnérabilités.