La gestion des vulnérabilités est le processus continu d'identification, évaluation, priorisation et correction des failles de sécurité dans les systèmes informatiques. L'ISO 27002 mesure 8.8 recommande cinq étapes principales :

• Inventaire des actifs : maintenir une liste à jour de tous les équipements, systèmes et applications à protéger
• Détection des vulnérabilités : scanner régulièrement les systèmes pour identifier les failles connues (CVE), configurations faibles, et versions obsolètes
• Évaluation et priorisation : analyser la criticité de chaque vulnérabilité (score CVSS), l'exploitabilité, et l'impact potentiel pour prioriser les corrections
• Correction et mitigation : appliquer les correctifs de sécurité (patches), mettre à jour les versions, ou appliquer des mesures compensatoires si le patch n'existe pas
• Vérification et suivi : valider que les correctifs sont bien appliqués, scanner à nouveau pour confirmer la correction, suivre les vulnérabilités résiduelles

Ce processus cyclique garantit que les systèmes restent protégés contre les menaces connues et émergentes.

Catalogue exhaustif

Impossible de protéger ce qu'on ne connaît pas. Maintenir un inventaire complet : serveurs : physiques et virtuels, systèmes d'exploitation et versions, postes de travail : laptops et desktops, OS et applications installées, équipements réseau : routeurs, switches, pare-feu, versions firmware, applications : web, métier, bases de données, frameworks et bibliothèques, équipements IoT : imprimantes réseau, caméras IP, équipements connectés.

Découverte automatique

Utiliser des outils de découverte réseau : scans réseau : identifier tous les équipements connectés (nmap, Angry IP Scanner), agents de gestion : logiciels installés sur chaque poste qui remontent l'inventaire (GLPI, OCS Inventory), intégration CMDB : Configuration Management Database centralise l'inventaire.

Métadonnées critiques

Pour chaque actif, documenter : propriétaire/responsable, criticité métier (critique/important/standard), données hébergées (sensibles/standard), exposition (public/interne), date dernière mise à jour.

Scanning automatisé régulier

Analyser périodiquement tous les systèmes : scans hebdomadaires : serveurs et équipements réseau, scans mensuels : postes de travail, scans post-changement : après toute mise à jour ou déploiement majeur, scans continus : pour infrastructures critiques (monitoring permanent).

Outils de scanning

Solutions de détection des vulnérabilités : OpenVAS (open source) : scanner complet, gratuit, base de vulnérabilités régulièrement mise à jour, Nessus (Tenable) : solution professionnelle leader, détection exhaustive, rapports détaillés, Qualys VMDR : solution cloud, scanning à distance, Rapid7 InsightVM : intégration avec solutions SIEM et SOAR, Microsoft Defender Vulnerability Management : intégré Windows, gratuit pour licences E5.

Types de scans

Scan authentifié : le scanner se connecte aux systèmes avec des credentials (compte admin lecture seule), détection précise (accès direct aux versions installées, configurations), recommandé pour inventaire interne complet.

Scan non authentifié : le scanner analyse depuis l'extérieur sans credentials, simule la vision d'un attaquant externe, utile pour tester l'exposition publique (serveurs web, VPN).

Scan d'applications web

Détecter les vulnérabilités applicatives : OWASP ZAP (open source) : scanner d'applications web, détection failles OWASP Top 10, Burp Suite : outil pro pour pentesters, Acunetix, Netsparker : solutions commerciales automatisées.

Failles détectées : SQL injection, XSS (Cross-Site Scripting), CSRF, vulnérabilités d'authentification, exposition de données sensibles.

CVE - Common Vulnerabilities and Exposures

Système d'identification standardisé des vulnérabilités : chaque vulnérabilité reçoit un identifiant unique CVE-ANNÉE-NUMÉRO (exemple : CVE-2021-44228 = Log4Shell).

Base de données publique : toutes les vulnérabilités connues référencées sur cve.mitre.org et nvd.nist.gov, descriptions détaillées, systèmes affectés, correctifs disponibles.

CVSS - Common Vulnerability Scoring System

Score de criticité de 0 à 10 : 0.0 : aucun impact, 0.1-3.9 : faible (Low), 4.0-6.9 : moyen (Medium), 7.0-8.9 : élevé (High), 9.0-10.0 : critique (Critical).

Calculé selon : facilité d'exploitation (besoin d'authentification ? complexité de l'attaque ?), impact (confidentialité, intégrité, disponibilité), portée (local ou réseau distant ?).

Exemple concret : Log4Shell (CVE-2021-44228)

Score CVSS : 10.0 (Critical), Impact : exécution de code à distance sans authentification, compromission totale du serveur, Systèmes affectés : toutes applications Java utilisant Log4j 2.0 à 2.14.1, Correctif : mise à jour Log4j vers 2.15.0 minimum (puis 2.17.0 pour correction complète).

Cette vulnérabilité a été exploitée massivement dans les heures suivant sa publication en décembre 2021.

Matrice de priorisation

Toutes les vulnérabilités ne sont pas égales. Prioriser selon : criticité CVSS : score 9-10 = correction immédiate, exploitabilité : exploit public disponible ? exploitation active constatée (0-day) ?, exposition : système accessible depuis Internet ? en DMZ ?, **criticité métier** : système critique pour l'activité ?, données sensibles : héberge-t-il des données confidentielles ou personnelles ?

Catégories de priorité

P0 - Critique urgent : CVSS 9-10 + exploitation active + système exposé → correction sous 24-48h maximum, P1 - Critique : CVSS 9-10 ou exploitation publique connue → correction sous 7 jours, P2 - Élevé : CVSS 7-8.9 + système important → correction sous 30 jours, P3 - Moyen : CVSS 4-6.9 → correction sous 90 jours, P4 - Faible : CVSS 0.1-3.9 → correction lors de prochaine fenêtre de maintenance planifiée.

Contexte et risque réel

Un CVSS élevé ne signifie pas toujours urgence absolue : vulnérabilité locale : nécessite déjà un accès au système (moins urgent si système bien protégé), système non exposé : serveur en zone sensible sans accès Internet direct (moins urgent), mesures compensatoires : pare-feu bloque le vecteur d'attaque (réduit l'urgence mais ne remplace pas le patch).

Inversement, un CVSS moyen peut être critique si : système ultra-critique pour l'activité, exposition publique maximale, exploitation déjà observée dans des attaques réelles.

Application des correctifs (patching)

Déployer les mises à jour de sécurité : correctifs OS : Windows Update, yum/apt pour Linux, correctifs applicatifs : mises à jour logicielles (Java, navigateurs, Office), firmware équipements : routeurs, switches, pare-feu.

Processus : tester le patch en environnement de recette avant production, planifier une fenêtre de maintenance, sauvegarder avant application, appliquer le patch, vérifier le bon fonctionnement, scanner à nouveau pour confirmer correction.

Outils de gestion des correctifs

Automatiser le déploiement : WSUS (Windows Server Update Services) : centralise les mises à jour Windows, SCCM (System Center Configuration Manager) : gestion complète Microsoft, Automox, PDQ Deploy : solutions tierces multi-OS, Ansible, Puppet : automatisation pour infrastructures Linux.

Mises à jour automatiques vs contrôlées

Postes de travail : mises à jour automatiques recommandées (les utilisateurs ne patchent jamais manuellement), déploiement graduel (pilote puis général), serveurs critiques : mises à jour contrôlées obligatoires (test préalable, fenêtre planifiée, validation post-déploiement), jamais de mise à jour automatique non supervisée en production.

Mesures compensatoires

Quand le patch n'existe pas encore ou ne peut être appliqué immédiatement : isolation réseau : bloquer l'accès au système vulnérable via pare-feu (règle temporaire), désactivation fonctionnalité : désactiver la fonction vulnérable si non critique, **WAF** (Web Application Firewall) : bloquer les tentatives d'exploitation pour applications web, surveillance renforcée : monitoring intensif pour détecter toute tentative d'exploitation, restriction accès : limiter drastiquement qui peut accéder au système.

Ces mesures sont TEMPORAIRES et ne remplacent pas le patch définitif.

Serveurs Windows

Patch Tuesday : Microsoft publie les correctifs le 2e mardi de chaque mois, délais recommandés : correctifs critiques (7 jours), correctifs importants (30 jours), WSUS/SCCM : centralise et contrôle le déploiement, réversibilité : possibilité de désinstaller un patch si problème.

Serveurs Linux

Mises à jour continues : pas de calendrier fixe, correctifs publiés dès disponibles, gestionnaires de paquets : apt (Debian/Ubuntu), yum/dnf (RedHat/CentOS), automatisation : Ansible pour patcher des centaines de serveurs, kernels : nécessite redémarrage (planifier), live patching (KernelCare, Ksplice) pour éviter redémarrages.

Applications web et frameworks

Vulnérabilités fréquentes dans : WordPress, Drupal, Joomla : CMS nécessitent mises à jour fréquentes (core + plugins + thèmes), frameworks : Laravel, Django, React, Angular (dépendances npm/pip), bibliothèques : Log4j, OpenSSL, Apache Struts (failles critiques régulières).

Outils : Dependabot (GitHub) alerte sur vulnérabilités dépendances, npm audit, pip-audit vérifient bibliothèques installées, composer audit pour PHP.

Équipements réseau

Souvent négligés mais critiques : firmware : routeurs, switches, pare-feu, points d'accès WiFi, process : télécharger firmware depuis site constructeur, sauvegarder configuration actuelle, appliquer firmware, vérifier fonctionnement.

Attention : firmware mal appliqué peut bricker l'équipement (le rendre inutilisable). Suivre strictement la procédure constructeur.

Équipements IoT

Très problématiques (souvent non patchables) : caméras IP, imprimantes réseau : rarement mis à jour, firmware obsolète, solution : isolation réseau stricte (VLAN dédié sans accès aux serveurs), surveillance renforcée, remplacement si trop ancien et vulnérable.

Systèmes non patchables

Certains systèmes ne peuvent pas être mis à jour : applications métier legacy : éditeur disparu, plus de support, incompatibilité avec OS récents, équipements industriels : automates, SCADA avec OS figé pour certification, systèmes médicaux certifiés : matériel médical avec logiciel validé FDA/CE non modifiable.

Mesures compensatoires obligatoires : isolation réseau stricte (VLAN dédié, pas d'accès Internet), pare-feu applicatif devant le système, surveillance renforcée (IDS/IPS), accès restreint au strict minimum, plan de remplacement à moyen terme.

Fenêtres de maintenance limitées

Systèmes critiques 24/7 avec disponibilité extrême : solution : architecture redondante permettant patching par rotation (patcher serveur A, basculer charge sur B, puis patcher B), live patching quand possible (Linux KernelCare), accepter fenêtres courtes nocturnes (2-4h), utiliser mesures compensatoires entre temps si délai trop long.

Validation métier nécessaire

Certaines applications nécessitent validation métier avant patch : tests fonctionnels longs (ERP, CRM critiques), certification métier requise (finance, santé).

Approche : patcher en priorité les couches basses (OS, infrastructure) qui n'impactent pas le métier, pour l'applicatif critique, mesures compensatoires pendant validation, accélérer les tests métier pour vulnérabilités critiques.

Rescanning post-patch

Après application des correctifs, vérifier la correction : scanner à nouveau le système, confirmer que la vulnérabilité n'apparaît plus, vérifier qu'aucune nouvelle vulnérabilité n'a été introduite, documenter la correction (date, qui, version appliquée).

Tableaux de bord

Visualiser l'état de sécurité : métriques clés : nombre total de vulnérabilités détectées, répartition par criticité (Critical/High/Medium/Low), délai moyen de correction par criticité, taux de conformité (% systèmes à jour), vulnérabilités en retard (dépassent le délai cible).

Outils : rapports Nessus/OpenVAS, tableaux de bord Qualys, intégration dans SIEM pour corrélation.

KPI de gestion des vulnérabilités

Indicateurs de performance : Time to Patch : délai moyen entre publication patch et déploiement, cible < 7 jours pour critiques, Vulnerability Backlog : nombre de vulnérabilités non corrigées, cible décroissante, Coverage : % actifs scannés régulièrement, cible 100%, Compliance Rate : % systèmes conformes (sans vulnérabilité critique), cible > 95%.

Sources officielles

Suivre les publications de vulnérabilités : NVD (National Vulnerability Database) : base officielle US, flux RSS par sévérité, CERT-FR (ANSSI) : alertes et bulletins pour France, recommandations en français, constructeurs : bulletins de sécurité Microsoft, Cisco, VMware, Adobe, Oracle.

Flux de menaces

S'abonner aux alertes : US-CERT : alertes du CERT américain, CISA KEV (Known Exploited Vulnerabilities) : liste des vulnérabilités activement exploitées, priorité absolue, listes de diffusion : Full Disclosure, BugTraq (anciennes mais historiques).

Communauté sécurité

Suivre les experts : Twitter/X : chercheurs en sécurité publient souvent en premier, blogs spécialisés : Krebs on Security, Schneier on Security, forums : Reddit r/netsec, r/cybersecurity.

• Ne jamais scanner : ne pas détecter les vulnérabilités expose à des failles connues exploitables. Scanning mensuel minimum obligatoire.
• Ignorer les CVSS élevés : reporter indéfiniment les correctifs critiques car "pas le temps" laisse des portes ouvertes. Délai maximum 7 jours pour CVSS 9-10.
• Patcher sans tester : appliquer directement en production sans test peut casser des applications. Toujours tester en recette d'abord sauf urgence P0.
• Oublier les équipements réseau : se concentrer uniquement sur serveurs et PC en oubliant routeurs/switches laisse des angles morts. Inclure tous les actifs dans le scanning.

La gestion des vulnérabilités est un processus cyclique d'identification, évaluation et correction des failles de sécurité. L'inventaire exhaustif des actifs (serveurs, postes, réseau, applications) constitue le prérequis indispensable. La détection combine scanning automatisé régulier (hebdomadaire serveurs, mensuel postes) via des outils comme Nessus, OpenVAS ou Qualys, avec identification des CVE (vulnérabilités standardisées) et calcul CVSS (score 0-10).

La priorisation s'appuie sur la criticité CVSS, l'exploitabilité (exploit public disponible ?), l'exposition du système, et sa criticité métier, avec des délais de correction adaptés (24-48h pour P0 critique urgent, 7 jours pour P1, 30 jours pour P2). La correction applique les patches via outils de gestion (WSUS, SCCM, Ansible) après test en recette, ou met en place des mesures compensatoires temporaires (isolation réseau, WAF) si le patch n'est pas disponible.

La vérification rescanne les systèmes post-patch pour confirmer la correction. Le suivi via tableaux de bord et KPI (Time to Patch, taux de conformité) mesure l'efficacité. La veille (NVD, CERT-FR, CISA KEV) détecte les nouvelles menaces rapidement