CVE, CVSS et zero-day : prioriser les vulnérabilités

Toutes les serrures ne se crochètent pas pareil

Reviens aux Arcades, ce centre commercial qui sert de fil rouge à cette série. Chaque boutique a une serrure. Certaines sont robustes, d'autres sont d'un modèle dont tout le monde sait, dans le milieu, qu'il se crochète en trente secondes avec un trombone.

Ce modèle de serrure faible, c'est une vulnérabilité : un défaut connu, exploitable, qui ouvre une porte qui devrait rester fermée.

Maintenant la question pratique. Le gérant des Arcades a deux cents serrures dans le centre. Il ne peut pas toutes les changer ce soir. Laquelle d'abord ? Celle de la bijouterie, qui donne sur le coffre et la rue ? Ou celle de la réserve à balais au fond du sous-sol, derrière deux portes badgées ?

Le défaut est peut-être identique sur les deux serrures. Le risque, lui, n'a rien à voir.

Une vulnérabilité, c'est une faille exploitable dans un produit. Mais deux failles de gravité égale ne représentent pas la même menace : tout dépend de ce qu'elles protègent et de la facilité à les atteindre.

C'est exactement le problème d'une équipe sécurité. Un scanner remonte des centaines, parfois des milliers de vulnérabilités. Les corriger toutes en même temps est impossible. Il faut prioriser. Et pour prioriser, il faut d'abord comprendre trois objets qu'on confond souvent : le CVE, le CVSS et le zero-day.

Le panorama en une minute

Avant le détail, posons les trois briques côte à côte. Elles répondent à des questions différentes, et c'est précisément pour ça qu'on ne doit pas les mélanger.

Aux Arcades : le CVE, c'est la référence du modèle de serrure défectueux dans le catalogue du serrurier. Le CVSS, c'est à quel point ce défaut est sérieux. Le zero-day, c'est quand des cambrioleurs exploitent une faille de passe avant même que le fabricant ne l'ait découverte et corrigée.

Trois angles, trois usages. On les déroule.

Le CVE : un identifiant, pas une note

Un CVE (Common Vulnerabilities and Exposures) est un identifiant unique attribué à une vulnérabilité connue, publiquement documentée, dans un produit donné. Le programme est piloté par MITRE, avec un réseau d'autorités (les CNA, CVE Numbering Authorities) habilitées à attribuer ces numéros.

Le format est stable et reconnaissable : CVE-AAAA-NNNN, où AAAA est l'année et NNNN un numéro de séquence. Par exemple CVE-2021-44228. On y revient plus bas, c'est notre cas réel.

Un CVE n'est qu'une étiquette. Il dit « telle faille, dans tel produit, a été identifiée et cataloguée ». Il ne dit rien, en lui-même, de sa gravité.

C'est la confusion la plus fréquente. « On a un CVE critique » ne veut rien dire tant qu'on n'a pas regardé le score qui l'accompagne. Le CVE, c'est le numéro de référence. La gravité vient d'ailleurs.

À quoi sert ce vocabulaire commun

L'intérêt d'un identifiant universel est de parler de la même chose sans ambiguïté. Quand un scanner, un éditeur, un bulletin de sécurité et un ticket Jira mentionnent tous CVE-2021-44228, tout le monde sait qu'il s'agit de la même faille, dans le même composant.

Aux Arcades, c'est la différence entre dire « la serrure du fond, là, tu vois » et donner la référence catalogue exacte du modèle défectueux. Le serrurier, le gérant et l'assureur parlent enfin le même langage.

Le CVSS : mesurer la gravité, par un vecteur

Le CVSS (Common Vulnerability Scoring System) est un standard ouvert maintenu par le FIRST, qui attribue à une vulnérabilité un score de gravité de 0.0 à 10.0. Plus le score est haut, plus la faille est techniquement sévère.

Mais le chiffre n'est que la partie visible. Derrière, il y a un vecteur : une chaîne qui décrit comment la faille s'exploite et ce qu'elle permet. C'est le vecteur qui produit le score, pas l'inverse.

Le score de base : comment et avec quel impact

Le score de base (Base Score) répond à deux familles de questions, indépendantes du contexte de chaque organisation. La spécification CVSS v3.1 du FIRST détaille chaque métrique.

Une faille exploitable à distance, sans authentification, sans interaction de la victime, et qui donne un contrôle total : tous les curseurs au maximum, le score grimpe vers 10. Une faille qui exige un accès physique et un compte administrateur préexistant restera basse, même si techniquement elle existe.

Le score de base ne décrit que la faille elle-même, isolée. Il ne sait rien de ton réseau, de tes données, ni de qui s'intéresse à toi.

Score temporel et environnemental : le contexte revient

La spécification prévoit deux groupes de métriques supplémentaires, trop souvent ignorés.

Le score temporel ajuste selon l'état du monde au fil du temps : existe-t-il un exploit public ? Un correctif officiel ? La faille est-elle confirmée ou supposée ? Une vulnérabilité dont l'exploit circule librement est plus pressante que la même faille restée théorique.

Le score environnemental réintègre ton contexte : l'actif touché est-il critique chez toi ? As-tu déjà des parades qui réduisent l'exposition ? C'est là que le score de base, universel, redevient ton score, personnel.

Aux Arcades, le score de base dit « ce modèle de serrure est faible dans l'absolu ». L'environnemental ajoute « mais celle-ci protège le coffre, et celle-là une réserve vide ». Le défaut est le même ; la priorité, non.

Les limites du CVSS

Le CVSS est précieux, mais il a des angles morts qu'il faut connaître.

• Il mesure une gravité potentielle, pas une probabilité d'attaque réelle.
• En pratique, beaucoup d'équipes n'utilisent que le score de base et ignorent le temporel et l'environnemental. On compare alors des failles hors de leur contexte.
• Une note élevée n'implique pas une exploitation imminente, et une note moyenne n'est pas forcément négligeable si l'actif est exposé.

D'où la règle qui structure tout ce billet : le CVSS est une entrée, pas la décision finale.

Le zero-day : une question de calendrier

Un zero-day (ou 0-day) est une vulnérabilité exploitée alors qu'aucun correctif n'est encore disponible. Le nom vient de là : l'éditeur a eu « zéro jour » pour réagir avant que l'attaque ne commence.

Le point clé : un zero-day ne se définit pas par sa gravité, mais par le moment. C'est une faille en avance sur sa propre correction.

Aux Arcades, imagine que des cambrioleurs découvrent qu'une certaine clé de service ouvre, par défaut de fabrication, toutes les serrures d'un étage. Ils l'exploitent discrètement. Le fabricant ne sait même pas que ce défaut existe. Il n'y a ni avis, ni rustine, ni alerte. La fenêtre est grande ouverte, et personne ne la voit.

Le cycle de vie d'une vulnérabilité

Pour situer le zero-day, il faut voir la chronologie complète. Une vulnérabilité traverse plusieurs étapes, et la fenêtre d'exploitation dépend du moment où la découverte est faite.

Quand un chercheur ou l'éditeur trouve la faille en premier, on suit le chemin sûr : divulgation responsable, puis correctif, puis déploiement. La fenêtre reste courte et maîtrisée.

Quand un attaquant trouve la faille en premier, on bascule sur le chemin rouge : exploitation silencieuse, sans correctif disponible. C'est le zero-day. La fenêtre reste ouverte jusqu'à ce que la faille soit enfin connue et corrigée.

Un zero-day n'est pas forcément la faille la plus grave techniquement. C'est la plus dangereuse à un instant donné, parce que la défense n'a encore aucune parade officielle.

Et même après publication d'un correctif, la fenêtre ne se ferme pas instantanément. Tant que le centre n'a pas changé toutes les serrures concernées, certaines portes restent ouvrables. La période entre « correctif disponible » et « correctif déployé partout » est, elle aussi, une fenêtre d'exposition.

Le NVD : du CVE au score, et le pont vers le risque

Entre le CVE (l'identifiant, chez MITRE) et le CVSS (le score, standard du FIRST), il manque un maillon : qui calcule le score pour chaque CVE et le publie au même endroit ? Le NVD, la base nationale des vulnérabilités du NIST.

Le NVD enrichit les CVE publiés : il y ajoute un score CVSS, le vecteur, les produits affectés et des références. C'est la fiche de référence qu'on consulte quand un CVE remonte.

Mais attention à la marche à ne pas rater. Le score CVSS publié par le NVD est un score de base. Il décrit la faille dans l'absolu, pas chez toi.

C'est le lien direct avec la notion de risque vue dans le premier billet de cette série. Le risque, c'est la combinaison de la vraisemblance d'une attaque et de sa gravité pour ton activité. Le CVSS de base couvre essentiellement un facteur de gravité technique. Il ne dit ni la probabilité réelle d'exploitation, ni l'impact métier chez toi.

Le score CVSS du NVD est une excellente première lecture. Le confondre avec le risque, c'est confondre la fiche technique d'une serrure avec la valeur de ce qu'elle protège.

Cas réel : Log4Shell (CVE-2021-44228)

Le meilleur exemple de tout ce qui précède reste Log4Shell, publiée en décembre 2021. Elle touche Apache Log4j 2, une bibliothèque de journalisation Java omniprésente, embarquée dans d'innombrables applications et produits.

La faille permettait, dans des configurations vulnérables, une exécution de code à distance via une simple chaîne de caractères enregistrée dans les logs. Sa fiche est consultable sur le NVD pour CVE-2021-44228, et l'éditeur a documenté le défaut et les versions concernées dans son avis de sécurité Apache Log4j.

Pourquoi elle illustre parfaitement le billet :

• Côté CVE : un identifiant unique, CVE-2021-44228, a permis au monde entier de parler de la même faille, dans le même composant, du jour au lendemain.
• Côté CVSS : le NVD lui attribue un score de base de 10.0, le maximum. Exploitable à distance, sans authentification, avec un impact total. Tous les curseurs au plafond.
• Côté zero-day : avant le correctif, des tentatives d'exploitation ont été observées très tôt. La fenêtre était ouverte, et la pression de patcher, immédiate.

Aux Arcades, c'est la situation cauchemar : un défaut de fabrication présent sur presque toutes les serrures du centre à la fois, trivial à exploiter, et des cambrioleurs déjà à l'œuvre. On ne se demande pas s'il faut agir. On se demande par où commencer, et vite.

Prioriser pour de vrai

Voilà le cœur pratique. Un score CVSS seul ne suffit jamais à décider. Pour prioriser honnêtement, on croise trois dimensions.

La troisième brique mérite un mot. L'EPSS (Exploit Prediction Scoring System), également porté par le FIRST, estime la probabilité qu'une vulnérabilité soit exploitée dans un horizon court. Là où le CVSS dit « à quel point c'est grave », l'EPSS dit « à quel point c'est probable ». Les deux sont complémentaires, pas concurrents.

Un raisonnement de priorisation ressemble alors à ceci.

Le réflexe à éviter est de trier la liste du scanner par CVSS décroissant et de corriger de haut en bas. Cela revient à changer d'abord les serrures qui ont la pire note de fabrication, même si elles ferment des placards vides, pendant que la bijouterie attend.

Prioriser, c'est croiser gravité, exploitabilité et exposition. Le CVSS seul classe les failles ; il ne décide pas de l'ordre dans lequel les corriger.

Une faille notée 7 mais activement exploitée sur un serveur exposé à Internet passe souvent avant une faille notée 9 enfouie dans un service interne inaccessible. C'est contre-intuitif quand on ne regarde que le score. C'est évident quand on raisonne en risque.

Points clés

• Un CVE est un identifiant unique de vulnérabilité (catalogue MITRE), pas une mesure de gravité.
• Le CVSS (FIRST) note la gravité de 0 à 10 via un vecteur ; le score de base ignore ton contexte, que les scores temporel et environnemental réintègrent.
• Le NVD (NIST) relie CVE et CVSS, mais publie un score de base : ne le confonds pas avec le risque réel.
• Un zero-day se définit par le calendrier (exploité avant correctif), pas par sa note de gravité.
• Prioriser se fait en croisant gravité (CVSS), exploitabilité (EPSS, exploits publics) et exposition (contexte métier), jamais le CVSS seul.

Dans la série

Palier 1 : Connaître les lieux. Domaine : Menaces.

• Précédent : Cyber Kill Chain et MITRE ATT&CK
• Suivant : Threat modeling avec STRIDE
• Vue d'ensemble : Par où commencer dans Les Arcades

Pour aller plus loin

• Spécification CVSS v3.1 (FIRST) pour décortiquer chaque métrique du vecteur.
• EPSS (FIRST) pour la dimension probabilité d'exploitation.
• Programme CVE (MITRE) et la base NVD du NIST pour la recherche de fiches.
• Fiche NVD de Log4Shell, CVE-2021-44228 et l'avis de sécurité Apache Log4j.
• Qu'est-ce que le DevSecOps ? pour replacer la gestion des vulnérabilités dans un cycle de livraison sécurisé.