Skip to content

Stakeholder-Specific Vulnerability Categorization (SSVC)

Overview

This section covers Stakeholder-Specific Vulnerability Categorization and how EPSS can be used with it.

🧑‍💻 Source Code

SSVC

Stakeholder-Specific Vulnerability Categorization (SSVC) is an alternative methodology for prioritizing vulnerabilities.

  • It is designed to address some of the issues with CVSS - including CVSS scoring.
  • It provides a method for developing vulnerability management decision models that are tailored to the specific needs of different stakeholders.

It is based on research performed by the CERT Division of the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU):

CISA and SSVC

CISA has adopted a customized version of SSVC as a framework for their vulnerability management decisions.

Quote

“CISA encourages every organization to use a vulnerability management framework that considers a vulnerability’s exploitation status, such as SSVC.”

https://www.cisa.gov/news-events/news/transforming-vulnerability-management-landscape

Quote

“The goal of SSVC is to assist in prioritizing the remediation of a vulnerability based on the impact exploitation would have to the particular organization(s).”

https://www.cisa.gov/sites/default/files/publications/cisa-ssvc-guide%20508c.pdf

CISA's SSVC Decision Tree https://www.cisa.gov/ssvc-calculator

CISA's SSVC Decision Tree Outcomes https://www.cisa.gov/ssvc-calculator

Exploitation: Evidence of Active Exploitation of a Vulnerability

Quote

"The intent of this measure is the present state of exploitation of the vulnerability. The intent is not to predict future exploitation but only to acknowledge the current state of affairs. Predictive systems, such as EPSS, could be used to augment this decision or to notify stakeholders of likely changes."

Value Definition
None There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability.
PoC (Proof of Concept) One of the following cases is true: (1) exploit code is sold or traded on underground or restricted fora; (2) a typical public PoC in places such as Metasploit or ExploitDB; or (3) the vulnerability has a well-known method of exploitation. Some examples of condition (3) are open-source web proxies serve as the PoC code for how to exploit any vulnerability in the vein of improper validation of TLS certificates. As another example, Wireshark serves as a PoC for packet replay attacks on ethernet or WiFi networks.
Active Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting.

Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization

Observations

  1. The Exploitation Node comes first in the Decision Tree in line with prioritizing by Exploitation.
  2. The order of the Decision Nodes gives the order of importance in making a remediation decision i.e. in this order (see Permutation and Drop Column Importance per Analysis in Source code)
    1. Exploitation
    2. Automatable
    3. Technical Impact
  3. The output is a Decision that is meaningful to the user e.g. "Act" means the "vulnerability requires immediate attention".
  4. Weaponized Exploits are not called out/supported explicitly i.e. per the Risk Taxonomy section, weaponized exploits are much more likely to be exploited than if the exploit just has a PoC (and there's a significant difference in associated count of CVEs for these populations.)
  5. CVSS Base Score Exploitability metrics can be used to inform the "Automatable" Node
  6. CVSS Base Score Impact metrics can be used to inform the "Impact" Node

Takeaways

  1. The order of importance of the risk factors in making a remediation decision is

    1. Exploitation
    2. Automatable
    3. Technical Impact