SSVC : une alternative à CVSS ?

Date : 07 Juillet 2021

SSVC (CVSS à l’envers) est une initiative du CERT.org (Université de Carnegie Mellon) qui a été lancée fin 2019 pour faire suite à un article publié un an plus tôt par les mêmes auteurs et qui critiquait fortement CVSS. Mais en fait, les 2 modèles sont très différents :

  • CVSS produit une note (à partir de paramètres) qui sert ensuite dans un processus de décision.
  • SSVC est un processus de décision, qui fait intervenir des paramètres tout au long de ce processus.

Autrement dit : CVSS est une métrique alors que SSVC un processus qui produit une décision (un statut pour une vulnérabilité).

SSVC signifie Stakeholder-Specific Vulnerability Categorization. La partie « Stakeholder-Specific » signifie que SSVC est personnalisé en fonction du contexte où il est utilisé. La version 1 de SSVC considère le cas de 2 Stakeholders particuliers avec des processus de décision différents : le fabricant qui développe des patches et l’utilisateur qui déploie ces patches dans son organisation.

La version 2.0 de SSVC a été publiée en avril 2021. Nous en parlons plus loin dans l’article.

Nota : Nous avons traité une autre métrique, nommée EPSS (Exploit Prediction Scoring System) et souvent citée en plus de CVSS et SSVC, dans un article publié dans le bulletin mensuel d’octobre 2019.

 

Les principes de SSVC

Le but de SSVC est de produire une décision pour une vulnérabilité. Dans le modèle standard (cela peut être changé) il y 4 décisions possibles, qui indiquent à quelle vitesse sera déployé le patch pour une vulnérabilité :

  • Defer : pas de traitement pour le moment,
  • Scheduled : application du patch à la prochaine maintenance programmée,
  • Out-of-Band : application à une date définie spécifiquement,
  • Immediate : application immédiate.

Cette décision est prise au moyen d’un arbre de décision qui enchaine 4 questions : chaque question est un nœud et les réponses possibles sont des branches menant à la question suivante. La première question est « La vulnérabilité est-elle exploitée ? », et les 3 réponses possibles sont : « non » ou « il y a un PoC ou un exploit » ou « oui ». Pour chacune de ces réponses on se pose ensuite la même question, et dans le cas de l’arbre du Stakeholder « développeur » cette question est « quel est l’utilité/l’efficacité pour l’attaquant du PoC ou de l’exploit disponible ? ». L’arbre de décision se poursuit ainsi pour arriver au bout des 4 questions à une décision. Nous donnons ci-dessous la liste des 4 questions successives (et des réponses possibles) dans le cas des 2 Stakeholders définis par SSVC. Les termes utilisés sont plutôt intuitifs, mais pour une description exacte, vous pouvez vous reporter au document de spécification de SSVC. L’arbre de décision global est également donné dans ce document.

Liste des questions successives dans l’arbre de décision du développeur d’un patch :

  • Exploitation ? : none, PoC, active,
  • Utility ? : laborious, efficient, super efficient,
  • Technical Impact ? : partial, total,
  • Safety Impact ? : none, minor, major, hazardous, catastrophic.

Liste des questions successives dans l’arbre de décision de l’utilisateur d’un patch :

  • Exploitation ? : réponses identiques au cas du développeur,
  • Exposure ? : small, controlled, unavoidable (La V2.0 a changé ce terme en « open »),
  • Mission Impact ? : none, degraded, crippled, failed,
  • Safety Impact ? : réponses identiques au cas du développeur.

Nota : la version 2.0 de SSVC a changé l’arbre « Utilisateur » en ajoutant la question « Utility » (déjà présente dans l’arbre « Développeur ») et en regroupant les 2 questions « Mission Impact » et « Safety Impact ».

 

SSVC 2.0 et autres déclinaisons

La version 2.0 introduit quelques changements mineurs, dont ceux exposés ci-dessus. Mais surtout elle ajoute un 3eme arbre de décision : celui du coordinateur qui intervient comme intermédiaire entre le découvreur d’une vulnérabilité et le développeur d’un patch.

Cet arbre est totalement différent des précédents. Les décisions possibles sont :

  • Decline : indiquer au découvreur que l’on ne souhaite pas prendre en charge la coordination sur cette vulnérabilité,
  • Track : suivre la discussion entre le découvreur et le fournisseur sans intervenir sur le fond,
  • Coordinate : intervenir de façon active entre le découvreur et le fournisseur.

Dans ce cas, l’arbre de décision inclus 7 questions que nous ne détaillons pas ici (voir la page 37 du document de spécification SSVC V2.0).

En juin 2021, la CISA a présenté lors de la conférence B-Side NoVA (qui se déroule dans la région NoVA : Northern Virginia aux Etats-Unis) un 4eme arbre : celui expérimenté par la CISA pour la gestion des vulnérabilités (au sein de la branche « Disclosure » de l’entité « Vulnerability Management » de la CISA). Dans ce cas les décisions possibles sont :

  • Track : Suivre l’évolution de la vulnérabilité en interne dans l’équipe « Vulnerability Management », mais pas de communication externe.
  • Attend : Informer la communauté sur la vulnérabilité et leur demander de se préparer à agir.
  • Act : Demander à la communauté d’agir immédiatement pour prendre en compte une vulnérabilité.

Dans ce cas, les questions de l’arbre de décision sont :

  • Exploitation ?
  • Virulance ?
  • Technical Impact ?
  • Mission impact & Well-being impact ?

 

Conclusions

CVSS vs SSVC ?:

SSVC propose une méthode pour aider à affecter des priorités dans le traitement des vulnérabilités. Il ne nous semble pas qu’il faille l’opposer à CVSS puisque SSVC est un processus de décision (Le C de SSVC rappelle qu’il s’agit de ranger une vulnérabilité dans une Catégorie) alors que CVSS est une méthode pour affecter une gravité (le S final de CVSS rappelle qu’il s’agit de donner un Score à une vulnérabilité).

Une adaptabilité déroutante

Nous avons vu dans cet article, 4 utilisations différentes de SSVC. SSVC est donc très flexible (adaptable). Il peut être tellement personnalisé, que le seul point commun reste l’utilisation d’un arbre de décision. C’est assez déroutant et il sera difficile de fédérer les utilisateurs puisque chaque domaine va développer son propre arbre de décision. On se demande même si on ne pourrait pas imaginer plusieurs arbres au sein d’une même organisation pour prendre en compte des systèmes informatiques de sensibilités différentes (par exemple un arbre pour les systèmes de bureautique et un autre pour les systèmes exposés à Internet).

SSVC est aussi un peu déroutant sur le fait qu’il évalue la situation actuelle mais ne propose pas de méthode pour anticiper le futur. Si actuellement une vulnérabilité est « Scheduled » (prévue pour la prochaine mise à jour programmée), ne faudrait-il pas anticiper le fait qu’elle pourrait passer « Immediate » demain si un programme d’exploitation devient disponible ? Cela oblige à recalculer la note SSVC en simulant les évolutions possibles des vulnérabilités et cela semble compliqué. Sur cet aspect prédictif, la réponse de SSVC semble de renvoyer vers d’autres métriques comme EPSS (qui est un modèle de prédiction), mais l’analyse que nous avons faite (cf. notre article sur EPSS) montre que EPSS n’est pas totalement convaincant dans ce domaine.

Des concepts intéressants

SSVC apporte cependant indéniablement des concepts intéressants. Par exemple :

  • Le fait de définir clairement des catégories de patches (Defer, Scheduled, OOB, Immediate).
  • Ou le fait que le modèle du CISA (4eme arbre de décision dans notre article) est une source d’inspiration intéressante pour construire un arbre de décision pour le déclenchement d’alertes.

 

 

Pour plus d’informations

Nous n’avons pas trouvé de chronologie officielle à propos de SSVC, mais à l’occasion de cet article nous avons identifié les éléments suivants :

 

En plus de ces documents de référence, voici quelques ressources intéressantes sur le sujet.

Précedent Précedent Suivant Suivant Imprimer Imprimer

© 2024 Cert-IST