Avant CVSS 4.0, un peu d’histoire

Autrefois, c’était le néant absolu : tout le monde se fichait de la sécurité informatique. Celui qui réussissait à pénétrer un système informatique grâce au mot de passe que seul le héros pouvait deviner grâce à sa sagacité et sa connaissance du concepteur du système – car il est bien connu qu’il allait employer un mot ayant une symbolique forte dans sa vie – et qu’une fois compromis tout allait péter dans une gerbe d’étincelles et...

Quittons le cinéma et revenons sur Terre : avant 2005, il n’y avait rien. Ou disons que chaque éditeur avait sa petite recette, son nommage, son évaluation de gravité, etc. Nous étions très loin d’une structuration industrielle et d’un langage commun (qui est pourtant un des piliers de base en sécurité informatique).

Le Soleil se lève en 2005

Plus les systèmes informatiques se sont complexifiés, et plus les vulnérabilités ont proliféré. Pour être plus efficace, il est nécessaire de s’organiser, et donc de standardiser les pratiques et la forme des échanges. De plus, la croissance du marché de la cybersécurité a aussi induit la nécessité de pouvoir comparer les solutions concurrentes et à tendre vers l’interopérabilité, ce qui a naturellement conduit le NIAC (National Infrastructure Advisory Council) à recommander d’avoir un système d’évaluation standard des vulnérabilités, le premier CVSS. Comme souvent, et faute d’intérêt important à l’époque, ce standard était critiqué et largement améliorable. Nous avions néanmoins la première brique, souvent la plus difficile à construire.

Le modèle initial pour le CVSS (source : first.org)

Les recherches ont commencé en 2003 et, comme souvent dans le cinéma, les travaux du NIAC servaient à conseiller le président des États-Unis (pour sauver le monde). L’idée de base était d’avoir un score le plus objectif possible, mesurable (et donc avec des métriques), flexible, interopérable et surtout ouvert à tous. À partir d’avril 2005, le FIRST (Forum of Incident Response and Security Teams) fut désigné pour être responsable de ce système de mesure.

Exemple de métrique et de calcul (BaseScore)

Assez rapidement, le système CVSS 1.0 fut revu et amélioré grâce à l’examen minutieux de très nombreuses vulnérabilités réelles, qui pullulaient désormais sur nos systèmes informatiques. Une version 2 naquit en juin 2007, qu’on qualifiera de version de « calibrage » pour que les scores soient consistants, cohérents et représentatifs.

Une mouture encore améliorée vit le jour en 2015, la version 3.0 : elle introduisit la notion de « scope », ajouta l’indication de la nécessité ou non de disposer de privilèges élevés pour attaquer, ainsi qu’un indicateur de complexité de l’attaque.

Une version améliorée de juin 2019, la 3.1, n’ajouta aucune métrique nouvelle, mais a surtout clarifié l’usage et les termes liés à cette norme.

Même améliorée, cette version n’en restait pas moins perfectible. Par exemple, au vu des métriques employées, on s’est rendu compte qu’au final il n’y avait qu’une centaine de scores possibles (de 0 à 10). Outre ce manque de finesse, il fallait aussi compléter un « score de base » à l’aide d’informations pas toujours discriminantes ou complètes.

CVSS 3.0/3.1 : la base

Pour faire simple, la note CVSS possède trois composantes :

• La base (« base metric group ») qui permet d’évaluer la sévérité de la vulnérabilité. Sans rentrer dans les détails, la « sévérité » est intrinsèque à la faille, et ne changera pas avec le temps (sauf en cas de réévaluation, ce qui peut arriver en cours d’examen de la faille où on découvre de nouveaux éléments sur la faille elle-même). Cela permet de calculer un score de base.
• Un score temporel, qui ne mesure pas le temps comme son nom (mal choisi) le laisserait croire, mais des critères susceptibles d’évoluer avec le temps ; ainsi, le critère « Exploit Code Maturity » évoluera forcément. Au départ, on découvre souvent la faille sans qu’elle soit exploitée, ni sans qu’on sache comment l’exploiter (par contre, si c’est le cas, on parle de zero day et on se doute que c’est grave). Puis on aura un POC (proof of concept), une exploitation fonctionnelle, puis une exploitation en masse. Le danger augmentera donc au fil du temps.
• Un score environnemental, indiquant les impacts en termes de confidentialité, d’intégrité et de disponibilité, ce qui n’est pas facile à évaluer dans le cadre général et prête souvent à interprétation. Cette partie doit en principe être évaluée par l’organisation cible (l’entreprise ou l’utilisateur final) pour estimer la gravité dans son contexte.

Dans tous les cas, le score final reste une indication devant être mise en perspective dans chaque organisation et chaque système d’information pour en évaluer le risque réel. Une vulnérabilité même très grave n’aura pas forcément de conséquences graves dans tous les systèmes : cela dépendra de l’architecture du système, de son exposition, de ses usages et ses fonctionnalités, des données traitées, etc.

Lorsque vous trouvez une note CVSS 3.1, il s’agit en général du score de base. Si par hasard vous avez une note complète (avec les 3 sections renseignées), elle est généralement renseignée de façon assez générique, sans réelle adaptation au système cible, alors que la partie environnementale devrait l’être, en théorie ; la partie temporelle reste évaluable par des organismes externes (chercheurs, éditeurs, etc.).

Les chaises musicales du nouveau framework

CVSS 4.0 introduit plusieurs types de score, et pas un score unique. Il y en a 4 :

• • CVSS-B : score de base, toujours présent

• • CVSS-BT : le score de base mais avec des éléments de menaces (« Threat »)

• • CVSS-BE : le score de base mais avec des éléments de contexte (d’environnement)

• • CVSS-BTE : la totale, à savoir score de base plus contexte et renseignements de menace

Ces scores seront calculés (savamment) d’après les informations des différentes sections, et chacun prendra celui qui lui convient le mieux selon le contexte étudié. Si on compare les deux frameworks, il y a un peu du jeu des chaises musicales, et quelques ajouts. De nombreux critères sont reconduits, parfois déplacés, quelques-uns supprimés et plusieurs ajoutés.

Le modèle passe de 3 à 5 briques (sections). Dans les versions 3.x, on avait 3 sections « score de base », « score environnemental » et « score temporel ». Dans la version 4, on scinde le score environnemental en deux et on ajoute une section « supplemental metrics ». Expliquons.

Score de base

Le score de base doit refléter la sévérité intrinsèque de la faille. Voici les changements :

Un élément nouveau apparaît : « attack requirement ». Cela indique si le système vulnérable présente les conditions d’exploitation de la vulnérabilité, ou si un attaquant à quelque chose à faire au préalable.

L’élément « scope » indiquait si la vulnérabilité pouvait affecter un autre système que le système initial. Il a été supprimé pour être remplacé par une évaluation plus fine et plus complète, appelée « subsequent system impact metrics » où on doit évaluer les impacts sur les systèmes liés.

Dans l’absolu, c’est une bonne chose. Imaginez qu’un routeur réseau est compromis : on se dit que l’ensemble des infrastructures réseaux risquent de souffrir. Mais deux remarques viennent à l’esprit :

• • d’abord il va être difficile de faire cette évaluation puisqu’elle va dépendre énormément du contexte, notamment en termes d’impacts ! Or le CVSS 4.0 propose de faire cette évaluation dans la partie « base score », censée être immuable, et surtout indépendante du contexte, justement.

• • d’autre part, cette partie est généralement renseignée par les CERT, les éditeurs de logiciels, les chercheurs, qui n’ont aucune vision sur les systèmes cibles. Ils vont avoir du mal à l’évaluer correctement.

On retrouve aussi une évaluation contextuelle (impacts en confidentialité, intégrité, disponibilité du système concerné et des systèmes liés) dans la partie environnementale, ce qui est beaucoup plus logique. Ces évaluations seront nommées « Modified » pour indiquer que les évaluations de base sont revues et modifiées par l’utilisateur final, en fonction de son contexte.

Score environnemental

Passons tout de suite au score environnemental. Globalement, peu de changement (à part la disparition du « modified score » (disparu également du « base score »), mais des métriques nettement affinées avec 3 ou 4 niveaux au lieu de 2. Cette section est destinée à être renseigné par la cible, c’est-à-dire l’organisation qui veut évaluer le risque de la vulnérabilité dans son contexte (son système d’information).

Une nouvelle section

Une partie « supplemental metrics » apparaît, mais elle n’impactera aucune des 4 variantes du score (rappel : le score de base n’est pas le score final...). Cette partie est destinée a être remplie par les analystes externes, comme pour le score de base.

On indique donc ici si la vulnérabilité concerne un système lié à la sécurité (pare-feu, gestionnaire de mot de passe, fournisseur d’identité, etc.), si l’attaque est automatisable par un attaquant, si les dégâts semblent pouvoir être récupérés, etc. Cela ressemble à un fourre-tout, utile, mais sans impact sur le score, ce qui paraîtrait pourtant logique.

Massacre à la tronçonneuse

Une section a été bizarrement réduite à un seul item : le score temporel, fournissant pourtant des indications importantes. On retrouve bien des informations dans la section précédente, mais rappelez-vous qu’elles n’entrent dans aucun score !

Encore plus curieux, le standard indique que c’est au client final (et non aux chercheurs de failles) de le compléter, alors qu’ils ne sont pas les mieux placés pour évaluer la maturité de l’exploitation. Ce genre d’information est plus du domaine de la threat intel, et des spécialistes de sécurité, pas des organismes pouvant être la cible des attaques. Très curieux, donc.

Les besoins de sécurité

La dernière section que nous regarderons est nouvelle : les besoins de sécurité de l’utilisateur (Environmental Security Requirements). Ici, le département informatique indiquera ses exigences de sécurité (c'est-à-dire si son système traite de données confidentielles, ou s’il a des besoins forts en intégrité et disponibilité). Logiquement, cela influera sur le résultat (score) final.

A quand la CVSS 4.1 ?

CVSS 4.0 apporte naturellement des améliorations par rapport à la version 3.0, mais on sent confusément que des réglages seront nécessaires pour que les nouveaux scores reflètent le plus fidèlement possible le danger des vulnérabilités.

L’examen minutieux et la confrontation à la réalité des choses ont conduit rapidement la version 1.0 à se transformer en 2.0. Est-ce que la marche sera aussi haute cette fois-ci ?

La version 3.0 n’était pas parfaite mais permettait d’avoir clairement une base « stable » et « contextuelle » : les spécialistes de sécurité donnaient une première indication, et les utilisateurs informatiques (au sens large du terme) modulaient le score final en fonction de leur environnement.

Ici, on affine des aspects pour être plus précis, mais en mélangeant un peu les genres, voire en écartant des éléments paraissant utiles. Alors, mieux que 3.0 mais moins bien que 5.0 ?

Sources :

• • CVSS 4: Révolution dans la gestion des vulnérabilités ou coup d’épée dans l’eau ? (itpro.fr)

• • CVSS : une v4 plus précise pour noter les vulnérabilités logicielles | Silicon

• • CVSS v4 Is Now Live and What You Need To Know About It | Qualys Security Blog

• • Vulnérabilités : la nouvelle norme CVSS 4.0 est disponible ! (it-connect.fr)

• • Here Comes CVSS v4.0 (nist.gov)

• • NVD - Vulnerability Metrics (nist.gov)

• • What's New in CVSS v4 | Rapid7 Blog