What is SSVC?
Intro
Risk exists on a continuum, and different stakeholders have different threat models and risk appetites. Cybersecurity risk is no exception.
Imagine you're a software developer, and you just found out about a vulnerability in a library upon which your product depends. You are now concerned that your software is also vulnerable. Upon investigation, you learn that your software does not use the vulnerable part of the imported library. Is your software, in its current state, at risk of this vulnerability? You likely answered, "probably not."
In this example, you are a Supplier of software that has an upstream Supplier vulnerability, but this vulnerability is not very risky to your business, so you are not very concerned. Conversely, the upstream Supplier probably wants the vulnerability patched as quickly as possible.
Unlike other vulnerability categorization systems that rate on technical severity (how bad it could be if the vulnerability were exploited) or exploitability (how likely it is that there will be an exploit), SSVC rates vulnerabilities on risk to the concerned stakeholder. It is not an attempted one-size-fits-all solution. SSVC follows a stakeholder-defined decision model to make these determinations of risk.
Caveats
All information in this document is suggested following research, but we must reiterate: it is not a one-size-fits-all system. We encourage stakeholders to define to define their own decision points, timeframes of actionability, and possibly, even their own roles.
Defining stakeholders
The above example includes a Supplier and a Deployer, and the third role is Coordinator. A stakeholder can be an individual or a group. It is possible for all three roles to exist within the same organization. Stakeholders are determined by their role in remidiation actions. For convenience, let's define these three:
- Suppliers distribute software, and maintenance of their product can include providing remediations (patches) or suggesting mitigations for the affected product.
- Deployers receive, evaluate, and apply the remediations or mitigations that the Suppliers provide.
- Coordinators receive vulnerability reports and decide how, and whether, additional coordination is needed to improve response to the vulnerability.
All three stakeholders, even if within the same organization, will have different perspectives on risk, and therefore have different decisions to make.
Note
The three aforementioned roles are not exhaustive and are only the ones for which we have created decision models so far.
How vulnerabilities are categorized in SSVC
SSVC categorizes vulnerabilities by priority based on risk that varies among stakeholders. These categories reflect the timeliness of action to be taken. Suppliers and Deployers have different end-categories than Coordinators because they are making different decisions at different points in their responses. Decision Trees are used when asking the series of questions to categorize a vulnerability's priority. There will be more information on decision points (tree nodes) in the next section.
Prioritization categories for Suppliers and Deployers
The following categories, listed in increasing order of priority, are suggested end-categories for how a Supplier or Deployer should respond to a vulnerability. The actual actions will differ between Supplier and Deployer, but their immediacy is similar. We provide these categories as examples and encourage Suppliers and Deployers to define prioritization categories that match their needs. We've found many places have a 4-level Service Level Expectation that maps onto our categories; however, if an organization uses fewer or more priority levels, they can adapt.
- Defer: do not act at present.
- Scheduled: work during regularly scheduled time with normal resource constraints.
- Out-of-cycle: act more quickly and potentially with extra resources than usual to resolve the vulnerability at the next available opportunity.
- Immediate: use all possible resources to mitigate the the vulnerability as quickly as possible, potentially including pausing normal operations.
Many Suppliers and Deployers will want to resolve Defer vulnerabilities in due time, perhaps within 90 days. Defer simply means 'do not act at present,' not 'do not act at all.'
Prioritization categories for Coordinators
Our advice for Coordinators is based on the CERT/CC Coordinated Vulnerability Disclosure (CVD) project. Because we make separate decisions for triage and publication, we provide separate example trees, each of which has different prioritizations at the end. These trees represent how we apply SSVC to our needs, and other coordinators might make different decisions based on different inputs and output scales. The following categories are listed in increasing order of involvement.
A triage tree might have:
- Decline to act on the report.
- Track information about the reported vulnerability, but do not take overt actions.
- Coordinate a response to the vulnerabilty report, potentially including technical analysis, reproduction, notifying vendors, publication, and assisting another party.
Whereas a publication tree might have:
- Don't publish information about the vulnerability.
- Publish information about the vulnerability.
How decision models are designed
All decision points and decision outcomes (priority categories) must be explainable to the non-expert. A decision point itself is not representative of risk, but the series of decisions point values help a stakeholder determine how risky a vulnerability is to their operation. We suggest the use of Decision Trees as a visual model to aid explanation to non-experts and experts alike. While we encourage stakeholders to customize SSVC to their needs, in the interest of preserving a common vocabulary, we discourage stakeholders from modifying existing decision points; however, stakeholders are encouraged to set their responses based on their risk appetites.
Supplier decision points
Exploitation
Exploitation refers to how much evidence currently exists that the vulnerability is being exploited. This value is mutable because new evidence of exploit can arise at any time.
Exploitation v1.1.0
The present state of exploitation of the vulnerability.
| Value | Definition |
|---|---|
| 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. |
| Active | Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting. |
Utility
Utility is about how much an adversary might benefit (relative to effort) from an attack campaign via use of the vulnerability. In other words, Utility is a combination of the value of each exploit event (Value Density) and the ease and speed (Automatable) at which an adversary can cause exploit events.
Value Density is described as "diffuse" (the system has limited resources) or "concentrated" (the system is resource-rich).
Automatable is a simple yes or no, can the attacker reliably automate all four steps (reconnaissance, weaponization, delivery, exploitation) of the kill chain? If the vulnerability allows remote code execution or command injection, the expected response should be 'yes.'
We define the following combinations to determine Utility values:
Utility v1.0.1
The Usefulness of the Exploit to the Adversary
| Value | Definition |
|---|---|
| Laborious | Automatable:No AND Value Density:Diffuse |
| Efficient | (Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated) |
| Super Effective | Automatable:Yes AND Value Density:Concentrated |
Technical Impact
Technical Impact refers to how much control of a system an attacker can gain. If 'yes' to any of the following questions, then the attacker has Total control of the system:
- can the attacker install and run arbitrary software?
- can the attacker trigger all the actions that the vulnerable component can perform?
- does the attacker get an account with full privileges to the vulnerable component (administrator or root user accounts, for example)?
If the answer is 'no' to all of the above questions, then the attack is presumed to gain Partial control of the system. Examples of Partial control include denial of service and memory address information leaks.
Technical Impact v1.0.0
The technical impact of the vulnerability.
| Value | Definition |
|---|---|
| Partial | The exploit gives the adversary limited control over, or information exposure about, the behavior of the software that contains the vulnerability. Or the exploit gives the adversary an importantly low stochastic opportunity for total control. |
| 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. |
Public Safety Impact
Public Safety Impact is a reduction of the more expansive Safety Impact decision point to Signficant or Minimal. If the highest category of Safety Impact is Marginal, Critical, or Catastrophic, then the Public Safety Impact is Significant. If no types of harm are more severe than Neglible, then the Public Safety Impact is Minimal.
Public Safety Impact v2.0.1
A coarse-grained representation of impact to public safety.
| Value | Definition |
|---|---|
| Minimal | Safety Impact:Negligible |
| Significant | Safety Impact:(Marginal OR Critical OR Catastrophic) |
Safety Impact is expansive to include impacts of physical harm, operator resiliency, system resiliency, environment, financial, and psychological harm. We used IEC 61508 to guide determinations of Negligible, Marginal, Critical, and Catastrophic impact on the aforementioned types of harm. Only one type of harm needs to qualify per category. Use the highest qualifying category to determine safety impact.
Safety Impact
Safety Impact v2.0.0
The safety impact of the vulnerability. (based on IEC 61508)
| Value | Definition |
|---|---|
| Negligible | Any one or more of these conditions hold. - Physical harm: Minor injuries at worst (IEC 61508 Negligible). - Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard. - System resiliency: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation. - Environment: Minor externalities (property damage, environmental damage, etc.) imposed on other parties. - Financial: Financial losses, which are not readily absorbable, to multiple persons. - Psychological: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons. |
| Marginal | Any one or more of these conditions hold. - Physical harm: Major injuries to one or more persons (IEC 61508 Marginal). - Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard. - System resiliency: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation. - Environment: Major externalities (property damage, environmental damage, etc.) imposed on other parties. - Financial: Financial losses that likely lead to bankruptcy of multiple persons. - Psychological: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people. |
| Critical | Any one or more of these conditions hold. - Physical harm: Loss of life (IEC 61508 Critical). - Operator resiliency: Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly. - System resiliency: Parts of the cyber-physical system break; system’s ability to recover lost functionality remains intact. - Environment: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties. - Financial: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state. - Psychological: N/A. |
| Catastrophic | Any one or more of these conditions hold. - Physical harm: Multiple loss of life (IEC 61508 Catastrophic). - Operator resiliency: Operator incapacitated (includes fatality or otherwise incapacitated). - System resiliency: Total loss of whole cyber-physical system, of which the software is a part. - Environment: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties. - Financial: Social systems (elections, financial grid, etc.) supported by the software collapse. - Psychological: N/A. |
Deployer decision points
Exploitation
Exploitation is the same as for Exploitation in the Supplier model.
Exposure
Exposure refers to how difficult it would be for an attacker to access a system from the open Internet. This will vary with configurations and is therefore determined on a per-system basis.
If a system is not 'Open', we suggest the following questions to guide your decision:
- If the system's networking and communication interfaces have been physically removed or disabled, choose small.
- If Automatable is yes, then choose controlled. The reasoning behind this heuristic is that if reconnaissance through exploitation is automatable, then the usual deployment scenario exposes the system sufficiently that access can be automated, which contradicts the expectations of small.
- If the vulnerable component is on a network where other hosts can browse the web or receive email, choose controlled.
- If the vulnerable component is in a third party library that is unreachable because the feature is unused in the surrounding product, choose small.
System Exposure v1.0.1
The Accessible Attack Surface of the Affected System or Service
| Value | Definition |
|---|---|
| Small | Local service or program; highly controlled network |
| Controlled | Networked service with some access restrictions or mitigations already in place (whether locally or on the network). A successful mitigation must reliably interrupt the adversary’s attack, which requires the attack is detectable both reliably and quickly enough to respond. Controlled covers the situation in which a vulnerability can be exploited through chaining it with other vulnerabilities. The assumption is that the number of steps in the attack path is relatively low; if the path is long enough that it is implausible for an adversary to reliably execute it, then exposure should be small. |
| Open | Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers) |
Automatable
Automatable is the same question as contained in the Supplier's Utility decision point. For easy reference, Automatable is a simple yes or no, can the attacker reliably automate all four steps (reconnaissance, weaponization, delivery, exploitation) of the kill chain? If the vulnerability allows remote code execution or command injection, the expected response should be 'yes.'
Human Impact
Human Impact is similar to the Supplier's decision point Public Safety Impact in that it factors Safety Impact, but it differs in that it is a compound decision point to also consider Mission Impact.
For easy reference, the information on Safety Impact is again provided here:
Safety Impact is expansive to include impacts of physical harm, operator resiliency, system resiliency, environment, financial, and psychological harm. We used IEC 61508 to guide determinations of Negligible, Marginal, Critical, and Catastrophic impact on the aforementioned types of harm. Only one type of harm needs to qualify per category. Use the highest qualifying category to determine safety impact.
Safety Impact v2.0.0
The safety impact of the vulnerability. (based on IEC 61508)
| Value | Definition |
|---|---|
| Negligible | Any one or more of these conditions hold. - Physical harm: Minor injuries at worst (IEC 61508 Negligible). - Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard. - System resiliency: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation. - Environment: Minor externalities (property damage, environmental damage, etc.) imposed on other parties. - Financial: Financial losses, which are not readily absorbable, to multiple persons. - Psychological: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons. |
| Marginal | Any one or more of these conditions hold. - Physical harm: Major injuries to one or more persons (IEC 61508 Marginal). - Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard. - System resiliency: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation. - Environment: Major externalities (property damage, environmental damage, etc.) imposed on other parties. - Financial: Financial losses that likely lead to bankruptcy of multiple persons. - Psychological: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people. |
| Critical | Any one or more of these conditions hold. - Physical harm: Loss of life (IEC 61508 Critical). - Operator resiliency: Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly. - System resiliency: Parts of the cyber-physical system break; system’s ability to recover lost functionality remains intact. - Environment: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties. - Financial: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state. - Psychological: N/A. |
| Catastrophic | Any one or more of these conditions hold. - Physical harm: Multiple loss of life (IEC 61508 Catastrophic). - Operator resiliency: Operator incapacitated (includes fatality or otherwise incapacitated). - System resiliency: Total loss of whole cyber-physical system, of which the software is a part. - Environment: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties. - Financial: Social systems (elections, financial grid, etc.) supported by the software collapse. - Psychological: N/A. |
Mission Impact is the impact on the Mission Essential Functions of the organization. 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” 1.
Mission Impact v2.0.0
Impact on Mission Essential Functions of the Organization
| Value | Definition |
|---|---|
| Degraded | Little to no impact up to degradation of non-essential functions; chronic degradation would eventually harm essential functions |
| MEF Support Crippled | Activities that directly support essential functions are crippled; essential functions continue for a time |
| MEF Failure | Any one mission essential function fails for period of time longer than acceptable; overall mission of the organization degraded but can still be accomplished for a time |
| Mission Failure | Multiple or all mission essential functions fail; ability to recover those functions degraded; organization’s ability to deliver its overall mission fails |
We define the following combinations of Safety Impact and Mission Impact values to determine Human Impact values:
Human Impact v2.0.1
Human Impact is a combination of Safety and Mission impacts.
| Value | Definition |
|---|---|
| Low | Safety Impact:(Negligible) AND Mission Impact:(None OR Degraded OR Crippled) |
| Medium | (Safety Impact:Negligible AND Mission Impact:MEF Failure) OR (Safety Impact:Marginal AND Mission Impact:(None OR Degraded OR Crippled)) |
| High | (Safety Impact:Critical AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Marginal AND Mission Impact:MEF Failure) |
| Very High | Safety Impact:Catastrophic OR Mission Impact:Mission Failure |
Coordinator decision points for Triage
The below decision points are modeled on CERT/CC Coordinated Vulnerability Disclosure (CVD) practice, but we encourage Coordinators to define their own criteria for Triage.
The first two questions help the CERT/CC determine if our help is required.
- Report Public: If a report is already public, then CERT/CC will decline the case unless there are multiple suppliers, super effective Utility, and significant Public Safety Impact.
- Supplier Contacted: If no suppliers have been contacted, then CERT/CC will decline the case unless there are multiple suppliers, super effective Utility, and significant Public Safety Impact. In this case, CERT/CC may encourage the reporter to contact the supplier and submit a new case request if the supplier is unresponsive.
- Report Credibility: If the report is not credible, then CERT/CC will decline the case. Please see the CERT® Guide to Coordinated Vulnerability Disclosure for more information about assessing credibility.
- Supplier Cardinality: Cases involving multiple suppliers can get complicated very quickly, so we are more likely to get involved in those cases.
- Supplier Engagement: If the suppliers are already engaged in a case, there is usually less for a coordinator to do, making it less likely that we will coordinate a case.
- Utility: If the vulnerability has high utility, then CERT/CC is more likely to coordinate the case.
- Public Safety Impact: If the vulnerability has significant public safety impact, then CERT/CC is more likely to coordinate the case.
The last two questions, Utility and Public Safety Impact, are the same as asked in the Supplier decision model.
Coordinator decision points for Publication
At the CERT/CC, a decision to publish is determined after criteria for Publication are met. SSVC adds value by codifying publication criteria so that the decision is explainable. Publishing a vulnerability should add public value, and a Coordinator must decide why they should publish instead of or in addition to the Supplier. Again, the below decision points are modeled on the CERT/CC Coordinated Vulnerability Disclosure (CVD) project, but we encourage Coordinators to define their own rationales for publication based on their missions.
The publication decision reuses the Exploitation decision point and adds two new ones (Supplier Involvement and Public Value Added).
Tip
Exploitation was first described in this document under the Supplier model, and the definition is the same regardless of the stakeholder.
- Supplier Involvement - If the supplier is involved and likely to publish already, there is less need for the CERT/CC to publish.
-
Exploitation - If the vulnerability is being actively exploited, the CERT/CC is more likely to publish.
-
Public Value Added - If there is already significant public discussion of the vulnerability, there might not be much for the CERT/CC to add, making us less likely to publish.
What is the difference between Supplier Engagement and Supplier Involvement?
Supplier Engagement, asks whether a Supplier has acknowledged the vulnerability and is participating in the coordination effort. Supplier Involvement, asks what, if anything, the Supplier is doing about the vulnerability.
Final notes
SSVC enables different stakeholders to make determinations about how a vulnerability will impact them, how to respond to a vulnerability, and how to communicate and explain their decisions. Unlike other vulnerability scoring systems, SSVC evaluates risk to a particular stakeholder without imposing a one-size-fits-all approach. The below subsections describe some other details about SSVC's features and provide links to further reading about SSVC and CVD.
Multiple vulnerabilities of the same priority
Naturally, a stakeholder will have multiple vulnerabilities at any given time, and it is likely that there will be multiple vulnerabilities of the same priority. The stakeholder can choose how to order vulnerabilities within the same priority- vulnerabilities of the same priority can be addressed in any order.
Communicating results
Coordinators will be especially concerned with communicating information about vulnerabilities, but Suppliers will be just as concerned about communicating to Deployers. Because information changes over time, SSVC decisions should always be timestamped and marked with the version of SSVC that was used. We provide a self-contained, machine-readable JSON schema.
Further reading
Guidance for customizing a Decision Tree
-
Federal Emergency Management Agency. Federal continuity directive 2: federal executive branch mission essential functions and candidate primary mission essential functions identification and submission process. Technical Report, US Department of Homeland Security, Federal Emergency Management Agency, 2017. URL: https://www.fema.gov/sites/default/files/2020-07/Federal_Continuity_Directive-2_June132017.pdf. ↩