Gestion des vulnérabilités : cycle technique

La gestion des vulnérabilités désigne le processus continu d'identification, d'évaluation, de priorisation et de remédiation des failles de sécurité présentes dans un système d'information. Ce cycle technique repose sur plusieurs phases distinctes. La découverte s'appuie sur des scanners actifs comme Nessus, OpenVAS ou Qualys, qui interrogent les actifs du réseau pour détecter les configurations faibles, les services exposés et les versions logicielles non patchées. Chaque vulnérabilité identifiée est ensuite corrélée à une entrée CVE (Common Vulnerabilities and Exposures) et scorée via le système CVSS (Common Vulnerability Scoring System), dont la version 3.1 introduit des métriques contextuelles comme le vecteur d'attaque, la complexité et l'impact sur la confidentialité, l'intégrité et la disponibilité. La priorisation ne se limite pas au score CVSS brut. Elle intègre des facteurs opérationnels : criticité de l'actif, exploitabilité active documentée dans des bases comme EPSS ou le catalogue KEV de CISA, et contexte de segmentation réseau. La gestion des vulnérabilités est un processus vivant. Elle exige une réévaluation régulière à mesure que de nouvelles CVE sont publiées et que la surface d'attaque évolue.

Côté Blue Team et SOC, la détection des vulnérabilités non corrigées repose sur plusieurs sources de données complémentaires. Les scanners de vulnérabilités programment des analyses récurrentes, idéalement hebdomadaires sur les actifs exposés et mensuelles sur l'ensemble du parc. Les résultats sont ingérés dans un SIEM ou une plateforme de type RBVM (Risk-Based Vulnerability Management) pour suivre l'évolution du backlog. Les journaux de déploiement de patches Windows, visibles via l'Event ID 19 (WindowsUpdateClient) dans le journal System, permettent de vérifier qu'un correctif a bien été appliqué. L'absence de cet événement après une fenêtre de maintenance constitue un indicateur de dérive. Sur les systèmes Linux, les logs APT ou YUM enregistrent les installations de paquets. Des outils comme Microsoft Defender for Endpoint ou Tenable.sc exposent des tableaux de bord de couverture de remediation avec des métriques de SLA. Les indicateurs de compromission liés à l'exploitation active d'une CVE incluent des tentatives d'exécution de code inhabituelles, des connexions sortantes vers des C2 connus, ou des modifications de fichiers système. Ces signaux doivent être croisés avec les vulnérabilités ouvertes sur l'actif concerné pour qualifier rapidement la gravité d'un incident.

En Red Team et pentest, la gestion des vulnérabilités est directement mise à l'épreuve lors de la phase de reconnaissance et d'exploitation. L'attaquant commence par identifier les versions logicielles exposées via des outils comme Nmap (avec les scripts NSE de détection de version), puis croise les résultats avec des bases publiques comme ExploitDB ou Metasploit Framework pour trouver des modules d'exploitation fonctionnels. Les vulnérabilités les plus couramment exploitées dans les audits incluent des failles de type RCE non patchées, des misconfigurations de services (SMB, RDP, Jenkins), et des bibliothèques tierces vulnérables dans des applications web. Le délai entre publication d'un CVE critique et déploiement d'un correctif en production constitue la fenêtre d'exposition réelle. Les contre-mesures techniques incluent la mise en place d'un processus de patch management structuré avec des SLA différenciés selon la criticité CVSS (ex. : 24h pour un CVSS >= 9.0 sur un actif exposé). Le durcissement complémentaire passe par la réduction de la surface d'attaque via la désactivation des services non nécessaires, l'application de règles de pare-feu restrictives et le déploiement de solutions de virtual patching (WAF, IPS) pour les vulnérabilités sans correctif disponible. Les exercices Breach and Attack Simulation (BAS) permettent de valider l'efficacité réelle du programme de remédiation.