Schwachstellen-Triage: CVSS allein steuert falsch

Les équipes opérationnelles privilégient souvent le score et l’ancienneté des tickets plutôt que la surface d’attaque réellement exploitable. Dans les environnements DACH (Allemagne, Autriche, Suisse), l’évaluation doit se baser sur l’exposition, la criticité des actifs et la proximité réelle d’un exploit. Le CVSS reste un outil utile, mais son score seul ne doit pas dicter l’ordre de traitement des tickets.

Articles associés : CTEM : pourquoi le Continuous Threat Exposure Management remplace le scan de vulnérabilités  ·  Priorisation des correctifs : pourquoi le CVSS seul freine votre SOC

Ce que mesure le CVSS et ce qu’il exclut délibérément

Le CVSS (Common Vulnerability Scoring System) évalue la gravité technique d’une vulnérabilité. Ses métriques prennent notamment en compte le vecteur d’attaque, la complexité, les privilèges nécessaires, l’interaction utilisateur ainsi que les impacts sur la confidentialité, l’intégrité et la disponibilité. Selon la spécification CVSS v4.0 de FIRST (Forum of Incident Response and Security Teams), le cadre se structure en quatre groupes de métriques : Base, Menace (Threat), Environnement (Environmental) et Complémentaire (Supplemental). Le score de base reflète les caractéristiques intrinsèques d’une vulnérabilité, stables dans le temps et indépendantes du contexte d’utilisation. Les métriques Menace et Environnement ajustent l’évaluation en fonction de l’exploitation actuelle et du contexte opérationnel spécifique. Il en résulte une base comparable pour classer techniquement les vulnérabilités à travers différents produits et environnements.

Ce que le score de base exclut délibérément, c’est le contexte opérationnel. Il ne connaît ni l’actif concret dans le réseau, ni la classe de données concernée, ni si la composante vulnérable est accessible depuis Internet. L’exploitation active, la maturité des exploits et les compensations spécifiques à l’entreprise ne sont pas non plus intégrées au score de base. La National Vulnerability Database (NVD) américaine le précise clairement : « Le CVSS n’est pas une mesure du risque. » La NVD fournit généralement uniquement les métriques de base pour les entrées CVE. Les valeurs Menace, Environnement et Complémentaire doivent être définies par les organisations elles-mêmes. Le guide utilisateur de FIRST pour le CVSS v4.0 souligne le même point : le score de base mesure la gravité plutôt que le risque et ne suffit pas à lui seul pour évaluer le risque.

Appliquer le même score CVSS à un système de test isolé et à un courtier d’identité exposé sur Internet aboutit au même point de départ, mais à deux niveaux de risque radicalement différents. C’est précisément ici que naît la mauvaise orientation dans de nombreuses files d’attente de gestion des vulnérabilités.

Trois axes prioritaires supplémentaires pour l’exploitation

Pour un triage opérationnel efficace, trois dimensions doivent être ajoutées au score, et pouvoir être reflétées dans les champs des tickets ainsi que dans les règles SLA : l’exposition, la proximité d’exploitation et la criticité des actifs. L’exposition décrit à quel point un attaquant peut facilement accéder à la vulnérabilité. La proximité d’exploitation évalue dans quelle mesure la vulnérabilité est techniquement exploitable dans votre propre environnement. La criticité des actifs indique ce qui est en jeu, sur les plans opérationnel et réglementaire, en cas de compromission.

L’exposition constitue la première question de filtrage au quotidien. Une vulnérabilité affectant un service accessible publiquement sera prioritaire par rapport à une vulnérabilité équivalente dans un backend strictement segmenté. L’exposition interne compte également, notamment lorsque des mouvements latéraux sont possibles via des chemins d’administration ou des interfaces de gestion. La question ne se limite pas à une évaluation binaire « haute ou basse ». L’essentiel réside dans : d’où provient l’accès et avec quelles connaissances préalables.

La proximité d’exploitation distingue la gravité théorique de la menace actuelle. Les indications issues des avis de sécurité, les codes d’exploitation publics, les campagnes actives et la compatibilité avec votre propre infrastructure modifient l’urgence. L’Office fédéral allemand de la sécurité des systèmes d’information (BSI) exige, dans son paquet d’information NIS-2 sur les mesures de sécurité et la gestion des vulnérabilités, un traitement prioritaire des vulnérabilités critiques pour la sécurité, ainsi qu’une hiérarchisation en fonction des risques et de leur impact sur les processus métiers. L’agence américaine de cybersécurité CISA complète cette approche avec son catalogue des vulnérabilités exploitées connues (KEV) : les organisations sont invitées à corriger en priorité les vulnérabilités faisant l’objet d’une exploitation active avérée. Sans cette dimension, des vulnérabilités bruyantes mais difficilement exploitables pourraient prendre le pas sur des chemins d’attaque silencieux mais tangibles.

La criticité des actifs empêche que la file d’attente soit triée uniquement selon la densité des tickets. Une vulnérabilité classée CVSS élevée sur un simple hôte de démonstration ne nécessite pas le même délai de traitement qu’une vulnérabilité moyenne sur un système gérant l’authentification, les données de paiement ou la commande de production. La criticité doit être définie avant le lancement du scan. Sinon, elle reste une réflexion tardive lors de l’incident.

Contexte des actifs : exposition Internet, privilèges et classe de données

Trois critères contextuels suffisent pour affiner la première analyse opérationnelle : l’exposition Internet (oui/non), les privilèges requis et accessibles, ainsi que la classe de données de l’actif. L’exposition Internet désigne les systèmes accessibles sans VPN ni accès Zero Trust. Les privilèges déterminent si la vulnérabilité peut être exploitée sans authentification, si elle permet une élévation de droits, ou si l’identité concernée dispose de droits administratifs ou de service étendus. La classe de données classe l’actif selon qu’il contient des contenus publics, des données internes ou des données sensibles à caractère personnel ou opérationnel.

Ces critères doivent figurer dans la CMDB (Configuration Management Database) ou l’inventaire des actifs, et être intégrés à chaque ticket de vulnérabilité. Leur absence force l’équipe à prioriser en fonction du score et de l’ancienneté. Leur présence permet d’établir une matrice transparente : une exposition élevée combinée à des privilèges impactants et une classe de données critique place l’actif en première ligne, indépendamment du titre marketing du CVE.

Un exemple concret illustre cette approche. En novembre 2024, Palo Alto Networks a publié son avis concernant CVE-2024-0012 (PAN-SA-2024-0015) : un contournement d’authentification dans l’interface web de gestion de PAN-OS. Le vecteur CVSS v4 indique un vecteur d’attaque réseau, des privilèges requis nuls et aucune interaction utilisateur ; le niveau de maturité de l’exploit est qualifié d’attaqué, avec un score CVSS-BT de 9,3 (Critique). Le 18 novembre 2024, la CISA a intégré cette CVE dans son catalogue KEV. L’avis précise que le risque diminue fortement si l’accès à l’interface de gestion est restreint aux adresses internes de confiance. Si le même composant est protégé par un accès administrateur MFA et une segmentation stricte au sein de l’entreprise, la priorité immédiate s’en trouve réduite. En revanche, s’il est exposé sur Internet avant le parcours IdP, le cas doit être traité dans le prochain cycle de maintenance et de communication – même si d’autres tickets sont plus anciens.

Documenter le parcours de correctif versus le parcours de compensation

Tous les constats critiques ne se terminent pas par un correctif appliqué le jour même. Les fenêtres de changement, les dépendances aux éditeurs, les exigences de certification et les effets secondaires sur les applications métiers imposent parfois un parcours de compensation. Une décision n’est opérationnellement viable que si les options de correctif et de compensation sont documentées de manière équivalente : que faire, jusqu’à quand, qui valide et quelle exposition résiduelle subsiste.

Le parcours de correctif décrit la version, la date cible, le retour arrière et la vérification. Le parcours de compensation détaille les contrôles comme les restrictions réseau, les règles WAF, la désactivation d’une fonctionnalité, une authentification renforcée ou la surveillance des indicateurs d’exploitation. Les deux parcours nécessitent une date de fin. Une compensation sans échéance devient une solution permanente silencieuse et fausse la perception des risques pour le RSSI (Responsable de la Sécurité des Systèmes d’Information).

Pour la logique de file d’attente, cela se traduit par une règle simple : la priorité détermine le lancement du traitement, mais pas nécessairement l’application immédiate du correctif en production. Un ticket hautement prioritaire peut basculer en compensation si l’exposition diminue de manière avérée et que la date du correctif est reportée de manière contraignante. Un ticket à faible priorité peut attendre si l’exposition et le niveau de criticité le permettent. Ainsi, la logique de substitution reste opérationnelle et évite l’accumulation pure de scores.

Rapport du RSSI : le risque plutôt que l’accumulation de tickets

Un rapport du RSSI (Responsable de la Sécurité des Systèmes d’Information) qui se limite à afficher les tickets ouverts et le score CVSS moyen mesure l’activité, et non le risque. Une approche plus pertinente consiste à adopter une vision par classes d’exposition, aux vulnérabilités accessibles depuis Internet présentant un fort potentiel d’exploitation, ainsi qu’aux actifs contenant des données critiques sans mesure de compensation efficace. L’ancienneté des tickets reste un indicateur de processus, mais ne répond pas à la question essentielle : quelle est la surface d’attaque réellement exposée ?

Une vue synthétique du risque permet de répondre à trois questions directrices : quelles vulnérabilités accessibles impactent les actifs critiques ? Où les mesures de compensation sont-elles en place, et où sont-elles en retard ? Quelles décisions nécessitent une capacité de changement dans les prochains cycles ? Ainsi, la direction peut piloter la capacité et l’acceptation des risques, plutôt que de commenter une liste croissante de tickets en attente.

Les implications pour l’exploitation sont claires : le score CVSS reste une valeur technique de départ. La file d’attente est gérée en fonction de l’exposition, du potentiel d’exploitation et de la criticité des actifs. En intégrant ces axes dans les champs des tickets, les SLA (Service Level Agreements) et les rapports du RSSI, les priorités sont établies en fonction de la surface d’attaque accessible, et non de l’intensité du score.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.

Comment intégrer l’exposition aux risques, la proximité avec les vulnérabilités et la criticité des actifs dans les systèmes de tickets existants ?

Les trois axes sont modélisés comme champs obligatoires dans le ticket de vulnérabilité et sont alimentés à partir de la CMDB (base de données de gestion des configurations) ou de l’inventaire des actifs. Les règles de SLA (niveau de service) s’appuient sur la classe d’exposition, la classe de données et la proximité d’exploit pour fixer les échéances correspondantes. Si ces caractéristiques manquent dans l’inventaire, l’équipe doit les compléter avant le lancement du scan. À défaut, le groupe est contraint de prioriser en fonction du score et de l’ancienneté du ticket.

Dans quelles circonstances une vulnérabilité classée comme priorité critique peut-elle être intégrée dans un processus de compensation plutôt que de faire l’objet d’un correctif immédiat ?

Lorsque les fenêtres de changement, les dépendances des fournisseurs ou les obligations de certification retardent le correctif de production, l’équipe documente les contrôles mis en place, comme les restrictions réseau, les règles de pare-feu applicatif (WAF), la désactivation de fonctionnalités ou un renforcement de l’authentification. Les éléments contraignants incluent la date cible, la validation et l’exposition résiduelle restante. La priorité détermine le lancement du traitement ; la compensation réduit effectivement l’exposition et recule la date du correctif. Sans date d’échéance, la mesure devient une solution permanente non déclarée.

Comment les directives CISA-KEV et celles du BSI s’intègrent-elles dans l’évaluation de la proximité des exploits ?

La proximité d’un exploit sépare la gravité théorique d’une menace tangible. La CISA exige, via son catalogue des vulnérabilités exploitées connues (Known Exploited Vulnerabilities Catalog), la fermeture prioritaire des failles actuellement exploitées. Pour sa part, le BSI (Bundesamt für Sicherheit in der Informationstechnik) préconise, dans son paquet d’informations relatif à la directive NIS-2, un traitement prioritaire des résultats critiques pour la sécurité, en fonction du risque et de leur impact sur les processus métiers. Les avis de sécurité, les codes d’exploit publics, les campagnes actives et l’adéquation avec son propre environnement technique complètent cette même logique.

Pourquoi l’ancienneté des tickets ne suffit-elle pas comme indicateur central dans le rapport du RSSI (Responsable de la Sécurité des Systèmes d’Information) ?

L’ancienneté des tickets reste un indicateur de processus pour le temps de traitement et la pression liée au backlog, sans évaluer la surface d’attaque réellement exposée. Des rapports exploitables classent les vulnérabilités par niveaux d’exposition, les résultats accessibles depuis Internet avec un risque d’exploitation élevé, ainsi que les actifs critiques dépourvus de mesures de compensation efficaces. La direction pilote la capacité et l’acceptation des risques à travers trois questions clés : les vulnérabilités exploitables sur les actifs critiques, les compensations appliquées ou en retard, et la capacité de changement nécessaire pour les prochains cycles.

Les choix de la rédaction

À lireCTEM : Pourquoi le Continuous Threat Exposure Management remplace le scan de vulnérabilitésÀ lirePriorisation des correctifs : Pourquoi CVSS seul freine votre SOCÀ lirePourquoi le certificat ISO ne suffit pas au BSI à lui seul

Plus du réseau MBF Media

Digital ChiefsG?opolitique et datacenters : ce que les DSI s?curisentMyBusinessFutureAI Act de l’UE à partir d’août 2026 : ce que les PME doivent étiqueter maintenantcloudmagazinXFS4IoT rencontre le Cloud : le distributeur automatique de billets devient une plateforme