Comme tout élément fondamental, il nous faut des règles communes de mesure et de gestion. Le système commun d’évaluation des vulnérabilités (CVSS – Common Vulnerability Scoring System) est un cadre ouvert permettant de caractériser la sévérité des vulnérabilités (CVE), il permet donc aux organisations de caractériser les CVEs présentes et participe au processus de priorisation de la remédiation.

CVSS 3.1

La version actuelle de CVSS est la 3.1. Elle est basée sur un système constitué de trois composants permettant de « noter » les CVEs et de définir leurs caractéristiques. Un système « à tiroir » permet aussi de prendre en compte ou pas les particularités et les attentes de l’organisation. La notation CVSS 3.1 s’appuie sur trois familles d’attributs 

Le « Base Metric »

Ce composant caractérise la CVE « elle-même », les différents attributs constitutifs de ce composant permettent d’évaluer la sévérité de la CVE sans prendre en compte son usage réel par les attaquants ou les caractéristiques propres à l’organisation. Très souvent, par abus de langage, la plupart de vos interlocuteurs utilisent en fait le score du « Base Metric » comme étant la note globale CVSS – cet usage est bien sûr faux d’un point de vue sécurité mais comme cette note ne change jamais (sauf révision de la part du NVD) elle est bien pratique à utilise

Le « Temporal Metric »

Ce composant tente de rajouter une couleur temporelle au score CVSS. Pour faire simple, il s’agit ici de définir quel usage réel est possible de la part des groupes d’attaquants. Par nature, cette note change dans le temps, par exemple si un code permettant l’exploitation de la CVE est découvert, cette nouvelle situation va faire évoluer la note « Temporal ». Généralement, il faut avoir une équipe d’analystes et/ou un flux de CTI pour alimenter les attributs de ce composant

Le « Environmental Metric »

Ce composant permet de définir les caractéristiques liées à l’organisation, notamment les besoins en termes de confidentialité, intégrité et disponibilité. De plus, les attributs de la catégorie « Modified Base Metrics » permettent de modifier les attributs définis dans le composant « Base Metric » afin d’aligner l’évaluation de la CVE avec les besoins de l’organisation.

Comme nous l’avons vu, d’un point de vue pratique, les organisations utilisent massivement la note du composant « Base Metric » mais rencontrent d’énormes difficultés à renseigner les attributs des deux autres composants. L’étude de ces difficultés dépassent le cadre de cet article, mais gardez à l’esprit qu’il n’est pas si simple de renseigner les valeurs des attributs des composants « Temporal Metric » et « Environmental Metric ».

Point extrêmement important, le composant « Base Metric » seul ne permet pas de définir un risque, il permet uniquement d’évaluer la sévérité d’une CVE, les organisations manipulent donc généralement des indicateurs techniques sans lien réel avec leur quotidien ou même sans corrélation avec la réalité de la menace.

CVSS 4, pourquoi cette évolution ?

Depuis environ 6 ou 7 ans, nous avons, toutes et tous, constaté une augmentation quasi exponentielle des attaques réalisées par des groupes d’attaquants organisés. L’illustration la plus évidente de ce nouveau paradigme est représentée par l’explosion des attaques par ransomware. Or, les ransomwares utilisent des vulnérabilités pour se répandre dans les organisations, et la famille de vulnérabilités la plus connue est constituée des CVEs.

La version 3.1 de CVSS datant quelque peu, il a donc été décidé de travailler sur une nouvelle version permettant à priori de mieux évaluer la menace représentée par les CVEs. Les spécifications CVSS sont définies par le FIRST (Forum of Incident Response and Security Teams), association américaine mais dont les travaux possèdent un impact mondial.

Une version préliminaire de la version 4 de CVSS a été publiée sur le site du FIRST (voir https://www.first.org/cvss/v4-0/cvss-v40-specification.pdf), elle est publiquement accessible et devrait rentrer en application à la fin de l’année 2023 ou au début de l’année 2024. Même s’il s’agit d’une version préliminaire, nous pouvons considérer qu’il s’agit de la version « quasi » définitive des spécifications CVSS 4.

Quels changements dans CVSS 4 ?

Nous allons donc explorer les différents composants de CVSS 4 et mettre en lumière les changements majeurs par rapport à CVSS 3.1. Néanmoins, cet article n’a pas pour vocation de fournir l’ensemble des informations exhaustives sur ce sujet – vous devrez réaliser votre propre investigation pour comprendre comment cette évolution peut impacter vos processus d’évaluation de la menace.

Nomenclature

CVSS 4 est constitué maintenant de 4 composants, il a donc fallu revoir la nomenclature des différents ensembles de composants. En effet, si le composant Base est par définition toujours présent, il peut être associé à un ou plusieurs des trois autres composants. Voici la nouvelle nomenclature :

Vous avez certainement remarqué que le composant « Supplemental Metric » n’apparait pas dans les diverses combinaisons, nous y reviendrons un peu plus loin dans cet article…

Le composant « Base Metric »

Le composant « Base Metric » n’a pas subi de modifications majeures, du moins en première lecture.

Nouvel attribut « Attack Requirements (AT) »

Cet attribut permet de déterminer les conditions de déploiement et d’exécution de l’attaque sur le système vulnérable porteur de la CVE. Ces conditions diffèrent des techniques/technologies d’amélioration de la sécurité (cf. Attack Complexity) car leur objectif premier n’est pas d’atténuer explicitement les attaques, mais plutôt d’apparaître naturellement comme une conséquence du déploiement et de l’exécution de l’attaque. Si l’attaquant ne prend pas de mesures pour surmonter ces conditions, l’attaque peut ne réussir qu’occasionnellement ou ne pas réussir du tout.

Si cet attribut contient la valeur « Present », cela signifie que la réussite de l’attaque dépend de la présence de conditions spécifiques de déploiement et d’exécution, par exemple :

• L’attaque ne peut se réaliser que dans un timing spécifique afin d’exploiter avec succès la vulnérabilité
• La réussite de l’attaque dépend de conditions d’exécution qui ne sont pas entièrement contrôlées par l’attaquant
• L’attaque peut devoir être lancée plusieurs fois contre une seule cible avant de réussir
• L’attaquant doit s’introduire dans le chemin logique du réseau entre la cible et la ressource demandée par la victime

Cet attribut semble intéressant, pourtant il semble quelque peu redondant avec l’attribut « Attack Complexity ». Néanmoins gardons ici le bénéfice du doute, nous déterminerons avec l’expérience si cet attribut sera réellement discriminant ou non.

Nouveaux attributs « Subsequent System Impact (SC) (SI) (SA) »

La version 3.1 de CVSS comporte déjà des attributs (C, I & A) permettant d’évaluer les impacts en termes de Confidentialité, Intégrité et Disponibilité suite à une attaque réussie sur un système donné. Les codes associés à ces trois attributs sont renommés :

• Confidentiality (C)          => Confidentiality (VC)
• Integrity (I)                      => Integrity (VI)
• Availability (A)                => Availability (VA)

De plus, trois nouveaux attributs font leur apparition :

• Subsequent System Impact Confidentiality (SC)
• Subsequent System Impact Integrity (SI)
• Subsequent System Impact Availability (SA)

L’objectif de ces trois nouveaux attributs n’est pas de définir l’impact CIA sur le système cible de l’attaque mais de définir si une compromission utilisant la CVE permettrait d’impacter d’autres systèmes que le système cible en termes de Confidentialité, Intégrité et Disponibilité.

Ces trois attributs sont extrêmement intéressants. Néanmoins, nous avons quelques doutes sur l’évaluation de ces trois nouveaux attributs par les fournisseurs. De plus, il faudra évaluer dans le détail comment ces nouveaux attributs seront utilisés dans la version définitive de la formule de calcul CVSS-B.

Le composant « Temporal Metric » devient « Threat Metric »

Le composant « Temporal Metric » subit une transformation majeure, il est renommé en « Threat Metric » et deux attributs disparaissent de l’évaluation : « Remediation Level » et « Report Confidence » :

Premier élément, l’attribut « Exploit Code Maturity » est renommé en « Exploit Maturity », pour l’instant pas de problème. Deuxième élément, les attributs « Remediation Level » et « Report Confidence » disparaissent de l’équation…

Nous avons ici une interrogation, pourquoi avoir enlevé les attributs « Remediation Level » et « Report Confidence » qui nous semblent être deux attributs essentiels pour évaluer la menace réelle ? Mystère et boule de gomme… En effet, les flux de CTI modernes ont la capacité de renseigner ces informations. De plus, les valeurs de ces deux attributs ne sont pas fournies par le NVD, il appartient donc à l’organisation de les utiliser ou non.

Nous ne comprenons pas les motivations qui ont abouti à l’élimination de ces attributs, car la partie « menace » (anciennement « Temporal ») nous apparait comme un élément essentiel pour prioriser les actions de remédiation. Or, la priorisation est un élément fondamental du cycle de gestion des vulnérabilités…

Le composant « Environmental Metric »

Pour rappel, l’objectif de ce composant est de fournir des attributs permettant de pondérer les valeurs d’attributs du « Base Metric » en injectant des données qui caractérisent l’environnement propre de l’organisation. Pas de changements majeurs de ce côté-ci.

Un nouveau composant : « Supplemental Metric »

Il va falloir nous habituer à cette nouvelle donne, CVSS 4 comporte maintenant quatre composants !

Un nouveau composant optionnel, appelé « Supplemental Metric », fournit une série de nouveaux attributs qui décrivent et mesurent les attributs extrinsèques supplémentaires d’une vulnérabilité. L’utilisation de chaque attribut est déterminée par le consommateur CVSS (l’organisation). Ces informations contextuelles peuvent être utilisées différemment dans l’environnement de chaque utilisateur. Aucun attribut n’aura, dans le cadre de sa spécification, d’impact sur le score CVSS final (par exemple CVSS-B). Les organisations peuvent ensuite attribuer une importance et/ou un impact effectif à chaque attribut, en leur donnant plus ou moins d’effet sur l’analyse de risque finale.

Vous l’avez compris, les valeurs des attributs de ce composant n’ont aucun effet sur le score CVSS global, il s’agit ici d’attributs permettant à l’organisation de réaliser une étude de risque plus poussée, qui pourraient être utilisés en liaison avec une CMDB par exemple.

Vous pouvez consulter la version préliminaire de CVSS 4 pour une explication poussée de ces attributs : https://www.first.org/cvss/v4.0/specification-document

Alors CVSS 4, c’est bien ou pas ?

L’étude complète des spécifications CVSS 4 nous a laissé un goût amer… En effet, nous sommes convaincus qu’il faut faire évoluer le modèle pour que les organisations puissent mieux comprendre les CVEs et surtout évaluer leurs besoins de remédiations à court, moyen et long terme.

L’évolution des attributs du composant « Base Metric » nous semble réellement intéressante. Nos projections sur la différence entre score de base CVSS 3.1 et 4 démontrent que nous obtiendrons un peu plus de finesse lors de l’évaluation de la sévérité d’une CVE.

L’apparition du composant « Supplemental Metric » nous parait aussi utile. Il est néanmoins dommage que les valeurs d’attributs ne puissent pas impacter le score global. Peut-être s’agira-t-il d’une évolution ou d’une option dans CVSS 4.1 ? Dans l’attente, ce composant vous permettra d’affiner vos études de risque, ce n’est déjà pas si mal.

La réduction à peau de chagrin du composant « Temporal Metric » est incompréhensible… Pourquoi réduire à un seul attribut la notion temporelle et l’usage réel de la CVE par les groupes d’attaquants ? Franchement, nous n’avons aucune réponse éclairée à fournir sur ce sujet, cela reste un mystère.

Nous espérons que la lecture de cet article aura pu vous fournir des informations intéressantes si vous travaillez dans le monde de la gestion des vulnérabilités.

A très vite pour de nouvelles découvertes.

Sylvain CORTES

VP Strategy chez HACKUITY