Points clés
- Le délai entre la publication d'une CVE et son exploitation active par des attaquants se raccourcit — il était de plusieurs mois en 2010, il est de quelques jours en 2024.
- Les vulnérabilités les plus exploitées ne sont pas toujours les plus récentes — de nombreuses CVE datant de plusieurs années restent massivement exploitées faute de patch.
- La combinaison vulnérabilité + mauvaise configuration est le scénario d'exploitation le plus fréquent — rarement la vulnérabilité seule suffit.
- Le processus de gestion des vulnérabilités (de la détection à la remédiation) doit être outillé, mesuré et soumis à des SLA définis.
L'accélération du cycle exploitation
La publication d'une CVE (Common Vulnerability and Exposure) déclenche un processus simultané de deux côtés : les défenseurs cherchent à déployer le patch, les attaquants cherchent à exploiter la vulnérabilité avant que les patches soient déployés. Ce jeu de vitesse a évolué défavorablement pour les défenseurs : des études récentes (Rapid7, Google Project Zero) documentent que le délai médian entre publication d'une CVE critique et première exploitation dans la nature est passé de plusieurs mois à quelques jours pour les vulnérabilités les plus attrayantes.
Cette accélération résulte de l'automatisation côté attaquant : des scanners automatiques qui détectent les instances vulnérables exposées sur internet dans les heures suivant la publication d'une CVE, des frameworks d'exploitation qui intègrent les nouveaux exploits rapidement. La réponse défensive doit être proportionnellement plus rapide — ce qui impose des processus de patch management d'urgence distincts des cycles de mise à jour standard.
La longue traîne des vulnérabilités anciennes
Paradoxalement, les vulnérabilités les plus exploitées en volume ne sont pas les plus récentes. La CISA (Cybersecurity and Infrastructure Security Agency) publie régulièrement des listes des vulnérabilités les plus exploitées — et certaines figurent dans ces listes depuis plusieurs années. Des CVE datant de 2017 (EternalBlue/MS17-010), 2019 (vulnérabilités Citrix, Pulse Secure) ou 2021 (ProxyLogon/Exchange) continuent d'être exploitées massivement en 2024 sur des systèmes non patchés.
Ce phénomène révèle que le problème majeur n'est pas l'existence de vulnérabilités (inévitables dans tout logiciel complexe) mais la lenteur des processus de patch management. Les organisations qui ont des SLA de patch management définis et respectés présentent une surface d'exposition à ces exploits massivement réduite par rapport aux organisations qui appliquent les patches de manière réactive et non systématique.
La combinaison vulnérabilité + misconfiguration
L'exploitation d'une vulnérabilité seule est rarement suffisante pour un impact significatif. Dans la majorité des incidents documentés, c'est la combinaison d'une vulnérabilité avec une mauvaise configuration (misconfiguration) qui permet l'escalade vers un impact majeur. Une vulnérabilité dans un service web + un compte de service avec des privilèges excessifs = compromission du serveur + mouvement latéral vers d'autres systèmes. Une vulnérabilité d'injection SQL + une base de données accessible depuis internet avec un compte de service non restreint = exfiltration massive.
Cette combinaison implique que la remédiation des vulnérabilités et la correction des misconfigurations doivent être traitées conjointement dans le programme de sécurité. Un patch appliqué sur une application dont la configuration reste problématique ne résout qu'une partie du risque.
Le processus de gestion des vulnérabilités comme fonction critique
La gestion des vulnérabilités (Vulnerability Management) est un processus continu qui couvre : la découverte (scans réguliers avec des outils comme Nessus, Qualys, OpenVAS, ou les fonctionnalités de vulnerability assessment des plateformes cloud) ; la priorisation (scoring CVSS combiné au contexte — la même CVE a un impact différent selon que le service est exposé sur internet ou uniquement sur le réseau interne) ; la remédiation (déploiement du patch ou mise en place d'une mesure de compensation documentée) ; et la vérification (confirmation que le patch a bien été appliqué et que la vulnérabilité est effectivement corrigée).
Ce processus doit être soumis à des SLA définis et mesurés. Un délai de remédiation moyen de 90 jours pour les vulnérabilités critiques — observé dans de nombreuses organisations sans SLA formels — est disproportionné face à un délai d'exploitation de quelques jours.