Understanding Stake-holder Specific Vulnerability Categorization (SSVC) for Risk Prioritization
Risk Prioritization is not a new technology in the cyber security space. Cybersecurity professionals look for products that can integrate with existing vulnerability assessment reports to help prioritize risks, most often just software vulnerabilities. Primitive modus operandi such as Prioritization...
Risk Prioritization is not a new technology in the cyber security space. Cybersecurity professionals look for products that can integrate with existing vulnerability assessment reports to help prioritize risks, most often just software vulnerabilities. Primitive modus operandi such as Prioritization based on the Common Vulnerability Scoring System (CVSS) is an easy go-to approach for ordering mitigation plans. Should we also consider a step forward? What also matters is the stakeholders on which a vulnerability exists. Is the vulnerability on a mission-critical device Is there a mitigation or workaround already in place to avoid vulnerability attacks We not only base our decisions merely on software vulnerabilities but also look deep into the misconfiguration in the systems.
We, at SecPod, discovered a thought-provoking document from CISA on Stakeholder Specific Vulnerability Categorization (SSVC), a customized decision tree model that assists in prioritizing vulnerability response for customers by evaluating vulnerabilities. The goal of SSVC is to assist in prioritizing remediation based on the impact a vulnerability exploitation would have on the organization(s). The decision tree determines four possible outcomes for a risk – Track, Track*, Attend, and Act. The table below explains Vulnerability Decisions and Possible Outcomes.
| Track | The vulnerability does not require action at this time. The organization would continue to track the vulnerability and reassess it if new information becomes available. CISA recommends remediating Track vulnerabilities within standard update timelines. |
| Track* | The vulnerability contains specific characteristics that may require closer monitoring for changes. CISA recommends remediating Track* vulnerabilities within standard update timelines. |
| Attend | The vulnerability requires attention from the organization’s internal, supervisory-level individuals. Necessary actions may include requesting assistance or information about the vulnerability and may involve publishing a notification, either internally and/or externally, about the vulnerability. CISA recommends remediating Attend vulnerabilities sooner than standard update timelines. |
| Act | The vulnerability requires attention from the organization’s internal, supervisory-level, and leadership-level individuals. Necessary actions include requesting assistance or information about the vulnerability, as well as publishing a notification either internally and/or externally. Typically, internal groups would meet to determine the overall response and then execute agreed-upon actions. CISA recommends remediating Act vulnerabilities as soon as possible |
| Value | One of the following is true: (1) Typical public PoC exists in sources such as Metasploit or websites like ExploitDB, or (2) the vulnerability has a well-known method of exploitation. Some examples of condition (2) are open-source web proxies that serve as the PoC code for how to exploit any vulnerability in the vein of improper validation of Transport Layer Security (TLS) certificates, and Wireshark serving as a PoC for packet replay attacks on ethernet or Wi-Fi networks. |
| None | There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability. |
| Public PoC | One of the following is true: (1) Typical public PoC exists in sources such as Metasploit or websites like ExploitDB; or (2) the vulnerability has a well-known method of exploitation. Some examples of condition (2) are open-source web proxies that serve as the PoC code for how to exploit any vulnerability in the vein of improper validation of Transport Layer Security (TLS) certificates, and Wireshark serving as a PoC for packet replay attacks on ethernet or Wi-Fi networks. |
| Active | Shared, observable, and reliable evidence that cyber threat actors have used the exploit in the wild; the public reporting is from a credible source. |
| Value | Definition |
| Partial | One of the following is true: The exploit gives the threat actor limited control over, or information exposure about, the behavior of the software that contains the vulnerability; or the exploit gives the threat actor a low stochastic opportunity for total control. In this context, “low” means that the attacker cannot reasonably make enough attempts to overcome obstacles, either physical or security-based, to achieve total control. A denial-of-service attack is a form of limited control over the behavior of the vulnerable component. |
| Total | The exploit gives the adversary total control over the behavior of the software, or it gives total disclosure of all information on the system that contains the vulnerability. |
| Value | Definition |
| No | Steps 1-4 of the kill chain—reconnaissance, weaponization, delivery, and exploitation—cannot be reliably automated for this vulnerability.1 Examples for explanations of why each step may not be reliably automatable include: (1) the vulnerable component is not searchable or enumerable on the network, (2) weaponization may require human direction for each target, (3) delivery may require channels that widely deployed network security configurations block, and (4) exploitation may be frustrated by adequate exploit-prevention techniques enabled by default (address space layout randomization [ASLR] is an example of an exploit-prevention tool). |
| Yes | Steps 1-4 of the of the kill chain can be reliably automated. If the vulnerability allows unauthenticated remote code execution (RCE) or command injection, the response is likely yes. |
| Value | Definition |
| No | Steps 1-4 of the kill chain—reconnaissance, weaponization, delivery, and exploitation—cannot be reliably automated for this vulnerability.1 Examples for explanations of why each step may not be reliably automatable include: (1) the vulnerable component is not searchable or enumerable on the network, (2) weaponization may require human direction for each target, (3) delivery may require channels that widely deployed network security configurations block, and (4) exploitation may be frustrated by adequate exploit-prevention techniques enabled by default (address space layout randomization [ASLR] is an example of an exploit-prevention tool). |
| Yes | Steps 1-4 of the kill chain—reconnaissance, weaponization, delivery, and exploitation—cannot be reliably automated for this vulnerability.1 Examples for explanations of why each step may not be reliably automatable include: (1) the vulnerable component is not searchable or enumerable on the network, (2) weaponization may require human direction for each target, (3) delivery may require channels that widely deployed network security configurations block and (4) exploitation may be frustrated by adequate exploit-prevention techniques enabled by default (address space layout randomization [ASLR] is an example of an exploit-prevention tool). |
Decision Points of SSVC
There are four factors that determine a vulnerability on a device to be one Act, Attend, Track*, Track. The decision-making points embrace reasonable assumptions made with a prior understanding of a vulnerability and scenarios. The four factors comprise Exploitation, Automatable, Technical Impact,and Mission Prevalence.
(State of) Exploitation
Any evidence of active exploitation of a vulnerability through various sources such as CISA Known Exploited Vulnerabilities (KEVs), other certified information from various internet sources, National Vulnerability Database (NVD) plays an important role in decision-making.
Exploitation Decision Values from CISA SSVC
Technical Impact
If a vulnerability discloses authentication or authorization credentials to the system, this type of information disclosure should also be scored as Total if those credentials give an adversary total control of the component. This implies that Technical impact has a scope and is relative to the affected component where the vulnerability resides.
Technical Impact Decision Values from CISA SSVC
Automatable
It represents the ease and speed with which attackers can exploit the vulnerabilities. We can mark Automatable as Yes if we can reliably automate steps 1-4 of the Kill Chain. Developed by Lockheed Martin, the Cyber Kill Chain® framework is part of the Intelligence Driven Defense® model for the identification and prevention of cyber intrusion activity. The model identifies what the adversaries must complete in order to achieve their objective.
Cyber Kill Chain Steps, a series of steps that trace stages of a cyberattack,
- Reconnaissance
- Weaponization
- Delivery
- Exploitation
- Installation
- Command and Control
- Actions on Objectives
Another way of making decisions for Automatable is to identify barriers posed by the device that make it difficult for attackers to exploit vulnerabilities. Vulnerability Chaining and open connectivity to the internet can enable attackers to exploit a vulnerability by using other weaknesses. To decide on a value of No or Yes, analyzer algorithms must consider all reasonable scenarios.
Automatable Decision Values from CISA SSVC
Mission Prevalence
This determines what is the impact on the Mission Essential Functions of Relevant Entities. A mission essential function (MEF) is a function directly related to accomplishing the organization’s mission as set forth in its statutory or executive charter. Identifying MEFs is part of business continuity planning or crisis planning. In contrast to non-essential functions, an organization “must perform a [MEF] during a disruption to normal operations.” The mission is the reason an organization exists, and MEFs are how that mission is realized.
Mission Prevalence Decision Values from CISA SSVC
SSVC Decision Tree
Stitching all the decision factors together gives a Decision Tree of CISA SSVC. It meticulously determines a vulnerability to be considered either as Act, Attend, Track*, or Track on a specific device. The same vulnerability on another device may fall into a different category (Act, Attend, Track* or Track) based on the characteristics analyzed while deriving the four decision points – Exploitation, Technical Impact, Automatable, and Mission Prevalence. Defying the fact that prioritization based on the severity score of a vulnerability would have resulted in vulnerabilities of two devices being considered as same priority, CISA’s Stakeholder Vulnerabilities Categorization provides a unique approach to the risk prioritization algorithms.
SSVC Decision Tree for Vulnerability Prioritization
Table Representing Vulnerability Prioritization
