SSVC: an alternative to CVSS?

Date : July 07, 2021

SSVC (CVSS flipped backwards) is an initiative of CERT.org (Carnegie Mellon University) launched in late 2019 as a follow-up to a paper published a year earlier by the same authors that was highly critical about CVSS. But in fact, the 2 models are very different:

  • CVSS produces a score (based on parameters) which can be used in a decision process.
  • SSVC is a decision process, which uses parameters all along the decision process.

In other words: CVSS is a metric, whereas SSVC is a process that produces a decision (a status for a vulnerability).

SSVC stands for Stakeholder-Specific Vulnerability Categorization. The "Stakeholder-Specific" part means that SSVC is customized to fit the context where it is used. SSVC version 1 considers 2 specific Stakeholders with 2 different decision processes: the vendor who develops patches and the user who deploys these patches in his organisation.

Version 2.0 of SSVC was released in April 2021. We discuss it later in this article.

Note: We covered another metric, called EPSS (Exploit Prediction Scoring System) and often cited in addition to CVSS and SSVC, in an article published in the October 2019 monthly Bulletin.

 

SSVC principles

The purpose of SSVC is to produce a decision for a vulnerability. In the standard model (this can be changed) there are 4 possible decisions, which indicate how quickly the patch for a vulnerability will be deployed:

  • Defer: no patch planned so far,
  • Scheduled: apply the patch at the next scheduled maintenance,
  • Out-of-Band: apply the patch at a specifically defined date,
  • Immediate: apply the patch immediately.

This decision is reached using a decision tree that chains together 4 questions: each question is a node and the possible answers are branches leading to the next question. The first question is "Is the vulnerability exploited?" and the 3 possible answers are: "no" or "there is a PoC or an exploit" or "yes". For each of these answers the same question is then asked, and in the case of the "developer" tree, this question is "how useful/effective is the available PoC or exploit for the attacker?". The decision tree continues this way to reach a decision after the 4th question. Below we list the 4 successive questions (and possible answers) in the case of the 2 Stakeholders defined by SSVC. The terms used are rather intuitive, but for an exact description you can read the SSVC specification document. The whole decision tree is also shown in this document.

List of consecutive questions in the decision tree for a patch developer:

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

List of consecutive questions in the decision tree for a patch user:

  • Exploitation?: same answers as for the developer case,
  • Exposure?: small, controlled, unavoidable (V2.0 changed this to "open"),
  • Mission Impact?: none, degraded, crippled, failed,
  • Safety Impact?: same answers as for the developer case.

Note: SSVC version 2.0 changed the "User" tree by adding the "Utility" question (already present in the "Developer" tree) and by grouping together the 2 questions "Mission Impact" and "Safety Impact".

 

SSVC 2.0 and other variations

Version 2.0 introduces a few minor changes, including the ones explained above. But more importantly, it adds a 3rd decision tree: the decision tree for the coordinator who acts as an intermediary between the discoverer of a vulnerability and the developer of a patch.

This tree is totally different from the previous ones. The possible decisions are:

  • Decline: indicate to the discoverer that you do not wish to take charge of coordination for this vulnerability,
  • Track: follow the discussion between the discoverer and the developer without participating,
  • Coordinate: actively participate between the discoverer and the developer.

In this case the decision tree includes 7 questions that we will not detail here (see page 37 of the SSVC V2.0 specification document).

In June 2021, CISA presented a 4th tree at the B-Side NoVA conference (held in the NoVA region: Northern Virginia in the United States): the one experimented by CISA for vulnerability management (within the "Disclosure" branch of the CISA "Vulnerability Management" entity).

In this case the possible decisions are:

  • Track: Monitor vulnerability internally in the Vulnerability Management team, but no external communication.
  • Attend: Inform the community about the vulnerability and ask them to prepare to act.
  • Act: Ask the community to act immediately to address a vulnerability.

In this case the questions in the decision tree are:

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

 

Conclusions

CVSS vs SSVC?

SSVC is a method to help prioritize vulnerability remediation. It does not seem to us that it should be opposed to CVSS since SSVC is a decision process (the C in SSVC reminds that it aims to put a vulnerability in a Category) whereas CVSS is a method to assign a score (the final S in CVSS reminds that it aims to give a Score to a vulnerability).

Confusing adaptability

We have seen in this article 4 possible usages of SSVC. SSVC is therefore very adaptable. It can be so much customised, that the only common point is the use of a decision tree. This is quite confusing and it will be difficult to federate users since each domain will develop its own decision tree. One might even imagine several trees used inside the same organisation to take into account IT systems with different sensitivities (for example, one tree for office computers and another for servers exposed to the Internet).

SSVC is also a bit confusing in that it assesses the current situation but does not provide a method to anticipate on the future. If a vulnerability is currently "Scheduled" (planned for the next scheduled update), shouldn't we anticipate the fact that it could become "Immediate" tomorrow if an exploit becomes available? This means that the SSVC score must be recomputed in order to evaluate the possible evolution of vulnerabilities and this seems complicated. On this predictive aspect, SSVC's answer seems to refer to other metrics such as EPSS (which is a prediction model), but the analysis we have done (see our article on EPSS) shows that EPSS is not totally convincing in this area.

Interesting concepts

However, SSVC does provide some interesting concepts. For example:

  • The fact that the categories clearly define the patching policy (Defer, Scheduled, OOB, Immediate),
  • Or the fact that the CISA model (4th decision tree in our article) is an interesting source of inspiration to build a decision tree for triggering alerts.

 

For more information

We have not found an official timeline about CVSS creation, but while writing this article we have identifies the following events:

 

In addition to these reference documents, here are some interesting resources on the subject.

Previous Previous Next Next Print Print

© 2024 Cert-IST