Chiffre et formules mathématiques sur un tableau

CVSS 4.0 : dur, dur, d’être un expert !

C’est comme CVSS 5.0 mais en moins bien

Avatar de l'auteur
Jean Gebarowski

Publié dans

Sécurité

30/11/2023
16

Chiffre et formules mathématiques sur un tableau

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.

Tableau de présentation des différences entre CVSS 3.x et 4.0

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.

Tableau de présentation des différences entre CVSS 3.x et 4.0

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 :

Tableau de présentation des différences entre CVSS 3.x et 4.0

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).

Tableau de présentation des différences entre CVSS 3.x et 4.0

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.

Tableau de présentation des différences entre CVSS 3.x et 4.0

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.

Tableau de présentation des différences entre CVSS 3.x et 4.0

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 :

16

Écrit par Jean Gebarowski

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Avant CVSS 4.0, un peu d’histoire

Le Soleil se lève en 2005

CVSS 3.0/3.1 : la base

Les chaises musicales du nouveau framework

Score de base

Score environnemental

Une nouvelle section

Massacre à la tronçonneuse

Les besoins de sécurité

A quand la CVSS 4.1 ?

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (16)


Oliverpool Abonné
Le 30/11/2023 à 21h 40
Un peu de lecture en anglais, par un des auteurs de curl, concernant quelques erreurs d'évaluation CVSS par le NVD:

https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerability-severity-levels/
jotak Abonné
Le 02/12/2023 à 07h 34
C'est intéressant d'avoir ce point de vue, et en même temps, c'est pas un peu gonflé d'accuser NVD de re-scoring lorsque délibérément on choisit de ne pas utiliser le framework qui normalise les scores?
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
swiper Abonné
Le 01/12/2023 à 10h 36
Un grand merci pour ces articles de culture générale sur la sécurité. J'aime beaucoup ces articles (je ne suis pas impartial car c'est mon domaine pro) et aimerais en trouver encore plus. Peut-être un qui explique les normes populaires sur le marché (PCI-DSS ou ISO 27xxx) leur histoire, leurs œuvres. Un article qu'on pourrait donc offrir à des étudiants en sécurité.
Le 01/12/2023 à 11h 05
PCI-DSS, c'est pour les systèmes hébergeant ou traitant les informations liées aux cartes de paiement. J'ai participé à des implémentations PCI-DSS jusqu'à la version 3, et je peux dire que la première chose nécessaire comme compétence pour ce type d'exercice, c'est la compréhension à la lecture (qui semble faire défaut malheureusement chez certains SecOff).

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.
Jean_G Abonné
Le 01/12/2023 à 11h 22

ragoutoutou

PCI-DSS, c'est pour les systèmes hébergeant ou traitant les informations liées aux cartes de paiement. J'ai participé à des implémentations PCI-DSS jusqu'à la version 3, et je peux dire que la première chose nécessaire comme compétence pour ce type d'exercice, c'est la compréhension à la lecture (qui semble faire défaut malheureusement chez certains SecOff).

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.
Quand je présente mon activité, je dis souvent : "en réalité, la sécurité des systèmes d’information devrait s’appeler la gestion des risques de sécurité liés à l’utilisation des systèmes d’information."

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...
eglyn Abonné
Le 01/12/2023 à 15h 34

Jean_G

Quand je présente mon activité, je dis souvent : "en réalité, la sécurité des systèmes d’information devrait s’appeler la gestion des risques de sécurité liés à l’utilisation des systèmes d’information."

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...
Je suis en plein dans la 27001, et pour au moins 1 an, je souffre :transpi:
potn Abonné
Le 02/12/2023 à 18h 34
Je suis tout à fait d'accord !
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. 😊
Le 02/12/2023 à 21h 03

potn

Je suis tout à fait d'accord !
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. 😊
Que veux-tu dire par orienté? Personnellement, je ne vois pas d'éléments spécialement sujets à controverse dans cet article. Alors, il y a des questions posées, des remarques, mais si ce sont des points qui méritent discussion, je ne vois pas de polémique, juste des éléments d'analyse à approfondir, mettre en perspective la métrique, ses composantes, le cycle de vie des valeurs, et la pertinence de remplir certaines cases avec des données qui seront sans-doutes périmées avant la fin de la réunion de crise où on aura montré le cvss aux décideurs...
potn Abonné
Le 02/12/2023 à 22h 20

ragoutoutou

Que veux-tu dire par orienté? Personnellement, je ne vois pas d'éléments spécialement sujets à controverse dans cet article. Alors, il y a des questions posées, des remarques, mais si ce sont des points qui méritent discussion, je ne vois pas de polémique, juste des éléments d'analyse à approfondir, mettre en perspective la métrique, ses composantes, le cycle de vie des valeurs, et la pertinence de remplir certaines cases avec des données qui seront sans-doutes périmées avant la fin de la réunion de crise où on aura montré le cvss aux décideurs...
À la lecture de l'article, j'ai l'impression que la v4 du CVSS est mal pensé, c'est en ça que l'article me semble orienté. 😉
Le 03/12/2023 à 01h 07

potn

À la lecture de l'article, j'ai l'impression que la v4 du CVSS est mal pensé, c'est en ça que l'article me semble orienté. 😉
C'est vrai que l'article dénote une forme de point de vue, mais c'est normal puisqu'il s'agit d'une analyse et non d'une page de manuel. Je ne suis pas d'accord sur tout mais le mérite du texte est indéniable.

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.
Modifié le 03/12/2023 à 01h08
jotak Abonné
Le 03/12/2023 à 09h 11

ragoutoutou

C'est vrai que l'article dénote une forme de point de vue, mais c'est normal puisqu'il s'agit d'une analyse et non d'une page de manuel. Je ne suis pas d'accord sur tout mais le mérite du texte est indéniable.

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.
J'ai pas lu tous les détails sur le site de FIRST, mais c'est tout de même une spec conçue avec pas mal d'acteurs du milieu (cf https://www.first.org/cvss/v4.0/specification-document#Appendix-A---Acknowledgments) donc j'imagine que les points soulevés ont été abondamment discutés. Il y a forcément des imperfections mais vu de l'extérieur, on ne mesure pas toujours l'ensemble des cas de figure, et pour les concepteurs il s'agit bien souvent de faire le moins mauvais choix.

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
jotak Abonné
Le 03/12/2023 à 09h 14

jotak

J'ai pas lu tous les détails sur le site de FIRST, mais c'est tout de même une spec conçue avec pas mal d'acteurs du milieu (cf https://www.first.org/cvss/v4.0/specification-document#Appendix-A---Acknowledgments) donc j'imagine que les points soulevés ont été abondamment discutés. Il y a forcément des imperfections mais vu de l'extérieur, on ne mesure pas toujours l'ensemble des cas de figure, et pour les concepteurs il s'agit bien souvent de faire le moins mauvais choix.

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
(ah, les liens ne sont pas cliquables?)
Le 03/12/2023 à 13h 14

jotak

J'ai pas lu tous les détails sur le site de FIRST, mais c'est tout de même une spec conçue avec pas mal d'acteurs du milieu (cf https://www.first.org/cvss/v4.0/specification-document#Appendix-A---Acknowledgments) donc j'imagine que les points soulevés ont été abondamment discutés. Il y a forcément des imperfections mais vu de l'extérieur, on ne mesure pas toujours l'ensemble des cas de figure, et pour les concepteurs il s'agit bien souvent de faire le moins mauvais choix.

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
Je suppose qu'effectivement, comme dans tout comité de standardisation , on se retrouve à devoir garder des archaïsmes et des fausses bonnes idées parceque certains y sont maladivement attachés.

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)
jotak Abonné
Le 03/12/2023 à 19h 54

ragoutoutou

Je suppose qu'effectivement, comme dans tout comité de standardisation , on se retrouve à devoir garder des archaïsmes et des fausses bonnes idées parceque certains y sont maladivement attachés.

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)
Si je suis ce que tu dis, tu devrais voir d'un bon œil les distinctions entre les notes B/BT/BE/BTE, qui répond précisément à cette problématique de vouloir tout/trop intégrer. Les entreprises ayant une gestion du risque suffisamment élaborée peuvent se focaliser sur le score B en l'intégrant à leur propres analyses. Ça n'en rend pas moins les autres scores utiles à d'autres personnes dans d'autres situations ? Il me semble justement que l'approche modulaire/multiscore proposée permet d'adresser des use cases différents de façon assez transparente.
Le 03/12/2023 à 21h 03

jotak

Si je suis ce que tu dis, tu devrais voir d'un bon œil les distinctions entre les notes B/BT/BE/BTE, qui répond précisément à cette problématique de vouloir tout/trop intégrer. Les entreprises ayant une gestion du risque suffisamment élaborée peuvent se focaliser sur le score B en l'intégrant à leur propres analyses. Ça n'en rend pas moins les autres scores utiles à d'autres personnes dans d'autres situations ? Il me semble justement que l'approche modulaire/multiscore proposée permet d'adresser des use cases différents de façon assez transparente.
Oui, personnellement, avec CVSS 3.x j'utilise un modèle genre BE, mais la partie E est stockée en lien avec les données de la gestion d'asset. Dans mes scripts de gestion, je crée une nouvelle entrée pour chaque cve/cvss assigné à une catégorie de système, je dérive directement l'environnement lié aux systèmes pour adapter le scoring.

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)
Modifié le 03/12/2023 à 21h11
donutboy63 Abonné
Le 01/12/2023 à 14h 10
J'ai cru un instant que l'article portait sur le sujet du CSS :)