ISO 27001 • Gestion des vulnérabilités
Vulnerability Management expliqué simplement
Vous entendez partout parler de CVE, de scanners et de patchs critiques, mais comment structurer tout cela ? Le Vulnerability Management n'est pas un outil, c'est un processus continu et stratégique qui transforme le chaos des vulnérabilités en risques pilotables. Indispensable pour l'ISO 27001, il est la différence entre subir les cyberattaques et les anticiper.
1. C'est quoi le Vulnerability Management ? Définition simple
Le Vulnerability Management (Gestion des Vulnérabilités) est un processus cyclique, continu et proactif qui vise à identifier, évaluer, prioriser, corriger et suivre les vulnérabilités présentes dans les actifs d'une organisation. Une vulnérabilité, dans le langage de la norme ISO 27001, est une faiblesse d'un actif ou d'un contrôle qui peut être exploitée par une ou plusieurs menaces.
Contrairement à une idée reçue, il ne s'agit pas simplement de lancer un scanner Nessus, Qualys ou OpenVAS une fois par mois. Le scanner n'est qu'un capteur dans une chaîne beaucoup plus large. Le Vulnerability Management englobe la gouvernance : qui est responsable de quel actif ? Quelle est la criticité métier de ce serveur ? Quel est le niveau de risque acceptable ? Comment prouver que le correctif a bien été appliqué et que la vulnérabilité ne réapparaît pas ?
Pensez-y comme à l'entretien préventif d'un avion. Vous ne vous contentez pas de vérifier les moteurs la veille d'un vol long-courrier ; vous avez un carnet de maintenance, des inspections programmées, une hiérarchisation des défauts (une fissure sur le hublot vs. un boulon manquant), et une traçabilité totale des réparations. En cybersécurité, c'est exactement la même logique, mais appliquée à vos serveurs, postes de travail, applications SaaS, containers et bibliothèques open-source.
L'ISO 27001:2022 exige dans le contrôle A.8.8 que les informations sur les vulnérabilités techniques des systèmes d'information soient obtenues, que l'exposition de l'organisation soit évaluée et que des mesures appropriées soient prises. Le Vulnerability Management est la réponse opérationnelle directe à cette exigence.
2. Le cycle de vie du Vulnerability Management en 6 étapes
Un programme mature suit un cycle documenté et adapté au risque. Voici un exemple de démarche opérationnelle.
Étape 1 : Asset Discovery & Inventory
Vous ne pouvez pas protéger ce que vous ne connaissez pas. La première étape consiste à maintenir un inventaire vivant et classifié de tous les actifs : on-premise, cloud, shadow IT, IoT, bibliothèques open-source (SBOM). Sans inventaire à jour, un scan sera toujours incomplet. La classification (Confidentiel, Interne, Public) et le propriétaire métier (Asset Owner) sont indispensables pour la priorisation future.
Étape 2 : Vulnerability Identification (Détection)
C'est l'étape technique où l'on collecte les données. On utilise des scanners de vulnérabilités authentifiés, des agents EDR, l'analyse de composition logicielle (SCA) pour les dépendances, et la veille sur les flux CVE (NVD, CERT-FR). Cette étape doit être automatisée et fréquente : hebdomadaire pour l'infrastructure critique, mensuelle pour le reste. Attention à ne pas confondre vulnérabilité et mauvaise configuration : le Vulnerability Management couvre les deux (ex: port RDP exposé sur internet).
Étape 3 : Assessment & Prioritization (Évaluation)
C'est l'étape la plus sous-estimée. Un CVSS 9.8 n'est pas toujours prioritaire. Nous utilisons une matrice de risque contextuelle : CVSS + EPSS (probabilité d'exploitation réelle) + Criticité de l'actif + Exposition (internet ou interne) + Existence d'un exploit public. Un score CVSS 7.5 sur un serveur de paiement exposé sur internet avec un exploit actif est 10 fois plus urgent qu'un CVSS 9.8 sur un poste de test isolé sans accès réseau. Cette phase évite de noyer les équipes IT sous 10 000 tickets non triés.
- Faux positifs : Vérifiez et supprimez-les avec preuves. Ils polluent les métriques.
- SLA de correction : Exemple : Critique = 7 jours, Haute = 30 jours, Moyenne = 90 jours.
- Risk Acceptance : Formalisez les exceptions avec date de revue et signature du Risk Owner.
Étape 4 : Remediation & Mitigation
La correction (remediation) consiste à appliquer un patch, mettre à jour une bibliothèque, durcir une configuration (baseline CIS). Si le patch n'existe pas ou casse la production, on applique une atténuation (mitigation) : règle WAF, segmentation réseau, désactivation d'une fonctionnalité. Toute action doit être tracée dans un outil de ticketing (Jira, ServiceNow) avec un lien vers la CVE et l'actif concerné.
Étape 5 : Verification & Validation
Vérifiez les corrections par un scan ciblé ou une autre preuve appropriée. Conservez les résultats pour démontrer l’efficacité des mesures ; la méthode dépend du contexte et des exigences de votre audit.
Étape 6 : Reporting & Amélioration continue
Produisez des métriques actionnables pour la direction : MTTR (Mean Time To Remediate), taux de couverture de scan, nombre de vulnérabilités critiques ouvertes > SLA, top 5 des actifs les plus à risque. Ces KPI alimentent la revue de direction ISO 27001 et permettent d'améliorer le processus (PDCA). Le reporting ne doit pas être punitif mais orienté amélioration des processus.
3. Vulnerability Management vs Pentest : arrêtons la confusion
C'est l'une des confusions les plus fréquentes et les plus coûteuses pour les PME. Ces deux activités sont complémentaires, pas interchangeables.
| Critère | Vulnerability Management | Pentest |
|---|---|---|
| Objectif | Couverture large et continue, réduire l'exposition globale | Profondeur ponctuelle, démontrer un scénario d'attaque réaliste |
| Fréquence | Continu / hebdomadaire | 1 à 2 fois par an, ou à chaque changement majeur |
| Méthode | Automatisée, basée sur signatures CVE | Manuelle, créative, humaine |
| Résultat | Liste priorisée de 500+ vulnérabilités avec plan de correction | Rapport de 15-30 pages avec 5-10 chemins d'attaque prouvés |
| Auditeur ISO 27001 | Exige un processus continu prouvé | Considéré comme une mesure complémentaire, pas suffisante seule |
En résumé : le Vulnerability Management vous dit où vous êtes vulnérable en permanence. Le pentest vous dit comment un attaquant enchaînerait ces vulnérabilités pour atteindre votre actif le plus critique. Faire un pentest sans avoir de Vulnerability Management en place, c'est comme demander un bilan cardiaque complet alors que vous n'avez jamais mesuré votre tension.
4. Pourquoi le Vulnerability Management est crucial pour l'ISO 27001:2022
Si vous visez la certification ISO 27001, vous ne pouvez pas faire l'impasse. La norme a considérablement renforcé ses exigences techniques dans sa version 2022.
Contrôle A.8.8 – Gestion des vulnérabilités techniques : C'est le contrôle phare. L'auditeur va demander : quelle est votre source d'information sur les vulnérabilités ? Comment évaluez-vous le risque ? Quels délais appliquez-vous ? Avez-vous des preuves de corrections et de revérifications ? Un simple export de scanner ne suffit pas.
Contrôle A.8.5 – Authentification sécurisée et A.8.9 – Gestion de la configuration : Beaucoup de vulnérabilités détectées sont en fait des écarts de configuration (mots de passe par défaut, SMBv1 activé). Le Vulnerability Management alimente directement ces contrôles.
Clause 6.1.2 et 6.1.3 – Appréciation et traitement des risques : Chaque vulnérabilité non corrigée est un risque qui doit être intégré à votre registre des risques. Le processus de Vulnerability Management est la traduction opérationnelle de votre processus de gestion des risques.
Préparez votre procédure, les évaluations de risques, les actions de correction et les preuves de vérification pertinentes. Les éléments attendus dépendent du périmètre et de la déclaration d’applicabilité, sans durée de preuves universelle.
5. Bonnes pratiques et erreurs à éviter
- Automatisez mais ne déshumanisez pas : L'automatisation pour les scans et le ticketing est vitale, mais la priorisation doit rester humaine et contextuelle.
- Impliquez les propriétaires métier : La sécurité ne peut pas patcher seule la production. Définissez des RACI clairs.
- Gérez l'open-source : 70% des vulnérabilités modernes viennent des dépendances. Intégrez le SCA dans votre CI/CD.
- Erreur #1 : Vouloir tout corriger. Vous n'y arriverez jamais. Priorisez sur le risque réel, pas sur le CVSS brut.
- Erreur #2 : Scanner sans authentification. Vous manquerez 60% des vulnérabilités critiques (patchs manquants non visibles depuis le réseau).
- Erreur #3 : Aucune gestion des exceptions. Tout ce qui n'est pas corrigé doit avoir une fiche de risque accepté avec date de fin.
Conclusion : De la dette technique à l'avantage stratégique
Le Vulnerability Management n'est pas une corvée technique pour faire plaisir à l'auditeur. C'est le système immunitaire de votre système d'information. Un programme mature réduit le MTTR de 80%, diminue drastiquement la surface d'attaque exploitable et, surtout, il fournit à la direction une vision chiffrée et pilotable du risque cyber.
Commencez petit : un inventaire fiable à 90%, un scanner authentifié hebdomadaire sur les actifs critiques, une matrice de priorisation simple et un tableau de bord mensuel. L'ISO 27001 ne demande pas la perfection au jour 1, elle demande un processus qui s'améliore en continu. C'est exactement ce que le Vulnerability Management vous offre.
Dans le prochain article de cette série, nous verrons comment construire un tableau de bord Vulnerability Management qui parle aussi bien à votre RSSI qu'à votre CFO.
FAQ – Vulnerability Management
CVE est l'identifiant unique d'une vulnérabilité. CVSS note sa sévérité technique (0-10). EPSS estime la probabilité qu'elle soit exploitée dans les 30 prochains jours. Un bon programme combine les trois.
Pour une PME, commencez avec une solution tout-en-un avec agents (ex: Qualys, Tenable, Rapid7) ou une alternative open-source robuste comme OpenVAS/Greenbone couplée à un bon inventaire. L'outil importe moins que le processus derrière.
Le contrôle A.8.8 porte sur la gestion des vulnérabilités techniques. Son traitement dépend de l’analyse de risques et de la déclaration d’applicabilité. Aucun outil ni cadence universelle de scan ne garantit à lui seul la certification.
Définissez une fréquence fondée sur l’exposition, la criticité et les changements. Une fréquence hebdomadaire ou mensuelle peut servir de point de départ, à adapter aux risques et aux obligations applicables.
Ces conseils généraux ne remplacent pas un audit personnalisé ni un avis juridique. Toute vérification technique doit être autorisée par le propriétaire du système.