En bref
Corrigez d’abord les vulnérabilités déjà exploitées dans la nature (catalogue KEV de la CISA) qui touchent un système exposé à Internet, puis celles dont la probabilité d’exploitation est élevée (score EPSS du FIRST), puis le reste selon le score CVSS et la criticité de l’actif. Le CVSS seul trie par gravité théorique et noie les équipes ; croiser exposition, exploitation avérée et criticité métier produit une liste courte, que l’équipe peut réellement tenir.
Pourquoi le score CVSS ne suffit-il pas à prioriser ?
Le CVSS : définition (Common Vulnerability Scoring System) mesure la gravité technique d’une vulnérabilité dans l’absolu : ce qu’elle permet de faire, avec quelle complexité, à quelles conditions. Il ne dit rien sur le fait qu’elle soit exploitée aujourd’hui, ni sur l’endroit où elle se trouve chez vous. Le FIRST, qui maintient le CVSS, rappelle lui-même qu’il mesure la gravité, pas le risque.
Trier un parc par CVSS décroissant donne un résultat connu des équipes : plusieurs milliers de lignes notées « critique » ou « élevé », dont la grande majorité ne sera jamais exploitée chez vous. L’équipe corrige dans l’ordre du score et passe à côté de la vulnérabilité de gravité moyenne dont un code d’exploitation circule déjà.
Que mesurent l’EPSS et le catalogue KEV ?
- EPSS (Exploit Prediction Scoring System, FIRST) : une probabilité entre 0 et 1 qu’une vulnérabilité soit exploitée dans les trente jours, recalculée régulièrement à partir de données d’observation. C’est une estimation statistique, utile pour trier de grands volumes.
- KEV (Known Exploited Vulnerabilities, CISA) : un catalogue de vulnérabilités dont l’exploitation réelle est confirmée, assorti d’échéances de correction pour les agences fédérales américaines. C’est un fait établi, pas une probabilité, et un bon déclencheur d’urgence.
- CVSS : la gravité technique, utile pour estimer l’impact si l’exploitation réussit, à combiner avec les deux autres.
- Votre propre contexte : exposition à Internet, criticité de l’actif, présence de mesures de protection. Aucun score public ne peut le fournir.
Quels délais de correction fixer ?
Il n’y a pas de délai universel. Ce qui compte est d’en avoir un par catégorie, écrit et suivi. À titre d’illustration, une vulnérabilité exploitée sur un système exposé appelle une atténuation en quelques heures et un correctif en quelques jours, alors qu’une vulnérabilité sans exploitation connue sur un système interne peut suivre un cycle mensuel. Les délais se discutent avec les équipes d’exploitation, parce qu’un délai irréaliste n’est jamais tenu.
Le guide du NIST sur la planification de la gestion des correctifs (SP 800-40 rév. 4) propose de regrouper les actifs en catégories de maintenance, chacune avec son propre rythme et ses propres règles d’exception. C’est une bonne manière de formaliser des délais différents sans multiplier les cas particuliers.
Que faire quand on ne peut pas corriger ?
- Désactiver la fonction vulnérable si elle ne sert pas.
- Filtrer l’accès : le service n’est joignable que depuis les réseaux qui en ont besoin.
- Isoler le système, notamment les équipements anciens qui ne reçoivent plus de correctifs.
- Ajouter une règle de détection ciblée sur l’exploitation connue du défaut.
- Documenter l’exception : propriétaire, mesure compensatoire, date de revue, acceptation du risque signée par un responsable.
Quels indicateurs suivre ?
- Le délai de correction des vulnérabilités exploitées sur les systèmes exposés, qui est l’indicateur le plus parlant.
- La part du parc couverte par un scan authentifié, car un actif non scanné reste inconnu.
- Le nombre et l’ancienneté des exceptions en cours.
- Les vulnérabilités qui reviennent après correction : signe d’une image de base ou d’un processus à corriger en amont.
Qui doit s’en occuper dans une petite structure ?
Une personne nommée suffit, à condition qu’elle ait le pouvoir de demander un correctif et un jour par mois pour la revue. Commencez par ce qui est exposé à Internet : c’est le périmètre le plus petit et celui où une exploitation a le plus de chances d’arriver en premier. Étendez ensuite aux postes, aux serveurs internes et aux applications.
Un programme documenté vaut aussi pour vos clients et votre assureur : il montre que les correctifs suivent un processus. Pour une organisation soumise à NIS 2 : définition, la gestion des vulnérabilités fait partie des mesures de gestion des risques qu’elle doit pouvoir justifier.
À retenir
- 1Le CVSS mesure la gravité, pas le risque : il ne suffit pas à ordonner les correctifs.
- 2Une entrée du catalogue KEV sur un système exposé est le signal d’urgence le plus fiable.
- 3L’EPSS aide à trier de grands volumes, mais reste une estimation statistique.
- 4Un délai de correction par catégorie, écrit et suivi, vaut mieux qu’une règle unique qu’on ne tient pas.
Sources citées
- Exploit Prediction Scoring System (EPSS), FIRST
- Common Vulnerability Scoring System (CVSS), FIRST
- SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, NIST
- CIS Critical Security Control 7: Continuous Vulnerability Management, Center for Internet Security
Comment construire une règle de priorisation simple ?