Tout change, tout augmente, pour le meilleur le plus souvent mais parfois pour le pire. CVSS (pour Common Vulnerability Scoring System) est un système d’évaluation de la gravité de vulnérabilités informatiques, en place depuis 2005, et dont l’utilisation est désormais largement répandue. Une nouvelle version 4.0 vient de voir le jour, regardons si les évolutions vont dans le bon sens, à savoir une meilleure information des utilisateurs informatiques et donc une meilleure préparation face aux menaces.
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 :
Commentaires (16)
#1
https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerability-severity-levels/
#1.1
D'autre part ça me paraît aussi plus sain que la note fournie par les mainteneurs puisse être challengée, et pas nécessairement reprise aveuglément
#2
#2.1
Dans l'ensemble, ISO 27k1 est très intéressant, mais il s'agit surtout de gouvernance et de processus encadrant le contexte sécurité (formalisation, exécution et contrôle) plutôt que de sécurité elle-même. Connaître la norme est important évidemment important si on veut obtenir la certification pour une entreprise, mais cela ne fonctionne que si on a du personnel sécurité compétent pour faire fonctionner ces processus. Pour moi un des points vraiment très importants de la norme est que ça met un cadre autour des analyses de risque et peut inciter les entreprises à les faire correctement (par exemple via iso 27k5), car sans gestion du risque correcte, on ne peut pas prendre de décisions éclairées.
#2.2
PCI-DSS sert en effet pour les moyens de paiement, ISO27001 est une norme de qualité s'appliquant aux SMSI (Systèmes de Management de la Sécurité de l'Information) mais qui traite assez peu de sécurité (directement) : son objet est plutôt l'amélioration continue de sa gestion de la sécurité. En gros, on peut être certifié ISO27001 en ayant une sécurité pourrie. Simplement, ça veut dire que vous avez mis en place une gestion qui tend à l'améliorer en permanence. Et comme tout norme, elle s'applique sur un périmètre précis. C'est un peu comme l'ISO9001 (dont elle est très proche) mais appliqué à la sécu info.
Après, chez Next, on écoute nos lecteurs, donc si ça intéresse quelqu'un...
#2.3
#2.4
Merci pour cet article !
Il me semble par contre assez orienté, et j'aimerais bien avoir l'avis d'experts pour savoir si c'est plutôt unanime ou très sujet à débat. 😊
#2.5
#2.6
#2.7
Personnellement, j'ai tendance à voir le CVSS 4.0 comme une amélioration même si je trouve, par exemple, que le Remediation Level aurait toute sa place dans 'base' et 'environnemental' et qu'"exploit maturity" aurait du disparaître car c'est une métrique dont l'évaluation est objectivement difficile et qui peut mener à des sous-évaluations de la menace.
#2.8
Il y a aussi une FAQ sur le site, qui répond peut-être à certains points soulevés, ex. sur le "pourquoi c'est au consumer de remplir telle métrique" https://www.first.org/cvss/v4.0/faq#Why-is-this-the-responsibility-of-the-consumer-and-not-the-provider-vendor
#2.9
#2.10
Le CVSS est un format qui clairement est un peu parti dans tous les sens: on est passé d'un outil tentant de mesurer la gravité d'une vulnérabilité à un outil tentant de faire de la contextualisation et à servir de moyen pour faire de l'analyse de risque chez le client.
A cette dernière fin, on a ajouté et maintenu certains paramètres qui n'ont rien à voir ou ne devraient n'avoir rien à voir avec le score final d'une vulnérabilité, ce sont les valeurs "pense-bête" qu'on retrouve dans les valeurs supplémentaires.
Pour en revenir à l' "exploit maturity", il s'agit d'une métrique difficile à évaluer, et dont l'impact serait de minimiser le CVSS sur base d'informations non-fiables et pouvant varier rapidement. Dans la mesure où les fournisseurs ne veulent pas se risquer à évaluer cette métrique et préfèrent travailler sur base du scénario le plus pessimiste, on peut se demande pourquoi un tel champ existe, il aurait dû être éliminé comme les autres attributs temporels.
Dans le standard cvss, on a les valeurs de type "supplemental", qui n'impactent pas le score mais peuvent être utilisées par les utilisateurs pour stocker des informations complémentaires, cet endroit puisqu'il existe, serait la bonne place pour une notion comme la maturité de l'exploit.
Reste que l'ensemble des valeurs "supplemental" peuvent ressembler à une tentative de faire de la gestion de risque pour l'utilisateur, mais pour moi ça reste beaucoup trop insuffisant pour un contexte de grande entreprise est cela tente de mettre à plat un modèle qui devrait être plus adapté (dans une modèle relationnel, ces éléments seraient des attributs sur le lien entre une vulnérabilité et les contextes multiples où elle s'applique, tout comme les scores environnementaux)
#2.11
#2.12
Tout le problème du système cvss est que c'est une signalétique composite et quand on veut correctement gérer le risque, il faut découpler les données et définir quelle source est responsable pour quoi. Pour le score de base, c'est facle, pour environnemental, c'est souvent à déléguer, pour le temporel, c'est généralement une perte de temps. Quand aux supplémentaires, c'est vraiment des données qui n'ont qu'un intérêt moyen, insuffisantes si le but est de faire un benchmark du processus de remédiation (ce qui reste important si on veut produire des kpi)
#3