Skip to content

Stakeholder-Specific Vulnerability Categorization

SSVC stands for A Stakeholder-Specific Vulnerability Categorization. It is a methodology for prioritizing vulnerabilities based on the needs of the stakeholders involved in the vulnerability management process. SSVC is designed to be used by any stakeholder in the vulnerability management process, including finders, vendors, coordinators, deployers, and others.

TODO remove this warning when the site is ready

Work in Progress

This website is a work in progress. While it is intended to eventually be the official documentation for SSVC, it is not yet complete. For the latest version of SSVC documentation, see the GitHub repository.

Where to go from here

We have organized the SSVC documentation into four main sections:

  • Get Started with SSVC

    Get started learning about SSVC and how it can help you prioritize vulnerabilities. This section is intended for people who are new to SSVC.

    Learning SSVC

  • Learn More about SSVC

    Dig deeper to understand the SSVC methodology and how it works. This section is intended for people who are already familiar with SSVC and want to learn more.

    Understanding SSVC

  • SSVC How To

    Start using SSVC in your organization today with step-by-step instructions. This section is intended for people who are already familiar with SSVC and want to start using it.

    SSVC How To

  • SSVC Reference

    Reference documentation for SSVC. This section is intended for people who are already familiar with SSVC and want to look up specific details.

    Reference

How Can I Engage with the SSVC Community?

We welcome your feedback and contributions to SSVC. Here are some ways you can get involved:

  • Ask a question

    If you have a specific question for the SSVC team, please feel free to Ask a Question.

    Questions of more general interest to the community of SSVC users might fit better in the Q&A section of the Discussion area.

  • Report a problem

    If you find a problem with the SSVC documentation, the methodology, or accompanying code, we welcome your Bug Reports

  • Suggest an improvement

    Got an idea for how to make SSVC better? We'd love to hear it! Please submit your Feature Requests

  • Join the conversation

    More in-depth conversations that might not be actionable as issues are found in the Discussions area.

  • See what we're working on

    We manage the SSVC development effort via Github Issues and Pull Requests. Drop by and see what we're working on, or leave a comment to let us know what you're interested in.

  • Get more involved

    Want more information about engaging as a collaborator? Check out the SSVC Project Wiki

Footer Icons

The icons in the footer of each page also provide links to engage with the SSVC community.

Learning SSVC ↵

Learning SSVC

todo add intro

Videos

Source Video
SEI Podcast Series A Stakeholder-Specific Approach to Vulnerability Management
CISA SSVC On-Demand Training
Nucleus Security SSVC and Decision Trees
Nucleus Security Panel Discussion: Using Decision Trees for Vulnerability Prioritization with SSVC
Nucleus Security What is SSVC?
ICS Cybersecurity Academy Create your own SSVC decision tree for ICS patching
ICS Cybersecurity Academy SSVC: A great replacement for CVSS in ICS?
Waterfall Security Solutions Industrial Security Podcast Eps. 102: Stakeholder-Specific Vulnerability Categorization (SSVC)

Other Content

Source Link
SEI Prioritizing Vulnerability Response with a Stakeholder-Specific Vulnerability Categorization
CISA Stakeholder-Specific Vulnerability Categorization (SSVC)
Qualys Effective Vulnerability Management with Stakeholder Specific Vulnerability Categorization (SSVC) and Qualys TruRisk
Vulcan Cyber The SSVC risk prioritization method: what it is, when to use it, and alternatives

Have a link to something we missed? Let us know in an issue.

Ended: Learning SSVC

Understanding SSVC ↵

Introduction

This documentation defines a testable Stakeholder-Specific Vulnerability Categorization (SSVC) for prioritizing actions during vulnerability management. The stakeholders in vulnerability management are diverse. This diversity must be accommodated in the main functionality, rather than squeezed into hard-to-use optional features. Given this, we aim to avoid one-size-fits-all solutions as much as it is practical.

We will improve vulnerability management by framing decisions better. The modeling framework determines what output types are possible, identifies the inputs, determines the aspects of vulnerability management that are in scope, defines the aspects of context that are incorporated, identifies how to handle changes over time, describes how the model handles context and different roles, and determines what those roles should be. As such, the modeling framework is important but difficult to pin down. We approach this problem as a satisficing process. We do not seek optimal formalisms, but an adequate formalism.

Key Concepts in SSVC Decision Models

SSVC models individual vulnerability management decisions. It is built around the following concepts:

  • Decision Points are the independent variables that are relevant to the decision. Each decision point represents a different aspect or dimension of the decision.
  • Decision Values are the possible values for a decision point. The decision values (or decision point values) are an ordered set of enumerated values. They are ordered because they are sortable in some dimension, usually having to do with priority or urgency. They are enumerated because they are finite and discrete.
  • Outcomes are the dependent variables that are relevant to the decision. Each outcome represents a different possible result of the decision.
  • Outcome Values are the possible values for an Outcome. Outcomes are similarly defined as an ordered set of enumerated values, usually indicating a priority or urgency.
  • A Policy is a mapping from each combination of decision point values to the set of outcome values.
  • A Decision Function is a function that accepts a set of decision point values and returns an outcome value based on a policy.
---
title: Decision Points and Values
---
flowchart LR
    subgraph dps [Decision Points]
        direction LR
        dp1[Decision Point 1] --> dv1[Decision Value 1]
        dp1 --> dv2[Decision Value 2]
        dp1 --> dv3[Decision Value 3]
    end
    subgraph Policy
        direction LR
        dp1dv1[Decision Point 1 Decision Value 1] --> o1ov1[Outcome 1 Value 1]
        dp1dv2[Decision Point 1 Decision Value 2] --> o1ov2[Outcome 1 Value 2]
        dp1dv3[Decision Point 1 Decision Value 3] --> o1ov3[Outcome 1 Value 3]
    end
    subgraph Outcomes
        direction LR
        o1[Outcome] --> ov1[Outcome Value 1]
        o1 --> ov2[Outcome Value 2]
        o1 --> ov3[Outcome Value 3]
    end
    dps --> Policy
    Policy --> Outcomes

Where do the trees come in?

Our initial concept for SSVC's decision modeling was based on decision trees. A decision tree represents important elements of a decision, possible decision values, and possible outcomes. We often represent a decision function as a decision tree because it is a convenient way to represent a Policy as a branching decision structure.
We do not claim this approach is the only viable option.

In particular, we have received feedback that decision trees are not always the best way to represent the decision function, because stakeholders have different access to the information needed to make decisions. We are open to other representations of the decision function, and we are open to representing the decision function in multiple ways to accommodate different stakeholders.

The underlying decision function that maps every combination of decision point values to an outcome value is the same regardless of how we represent it, or the order in which the decision points are considered. In other parts of the documentation, we use tables to represent the same information. Trees provide a convenient way to visualize the decision function, but they are not a requirement of the model.

Topics Overview

The remainder of this section is organized as follows:

Current state of practice

Vulnerability management covers “the discovery, analysis, and handling of new or reported security vulnerabilities in information systems [and] the detection of and response to known vulnerabilities in order to prevent them from being exploited” 1. Prioritization of organizational and analyst resources is an important precursor to vulnerability analysis, handling, and response. The general problem is: given limited resources, which vulnerabilities should be processed and which can be ignored for now. We approach this problem from a pragmatic, practitioner-centered perspective.

The de facto standard prioritization language is CVSS 2. CVSS avoids discussing decisions and, instead, takes technical severity as its fundamental operating principle. However, the standard does not provide clear advice about how CVSS scores might inform decisions 3. SSVC instead considers technical severity as one decision point in vulnerability management. Severity should only be a part of vulnerability response prioritization 4. Vulnerability managers make decisions at a particular time in a specific context. CVSS base scores are static; we will make SSVC from modular parts that are easier to compose in each manager's temporal and operational context.

Any re-adaptation of the basic CVSS mindset inherits its deeper issues. For example, arguments for the CVSS scoring algorithm have not been transparent and the standardization group has not justified the use of the formula either formally or empirically 5. One complaint is that a high CVSS score does not predict which vulnerabilities will be commonly exploited or have exploits publicly released 6. Studies of consistency in CVSS scoring indicate that analysts do not consistently interpret the elements of a CVSS version 3.0 score 7. Because many adaptations of CVSS simply add additional metrics, we expect they will inherit such inconsistency. Analyst usability has so far been an afterthought, but we know from other areas of information security that usability is not well-served as an afterthought 8. SSVC aims to learn from and improve upon these issues.

Surveys of security metrics 9 and information sharing in cybersecurity 10 do not indicate any major efforts to conduct a wholesale rethinking of vulnerability prioritization. The surveys indicate some options a prioritization method might consider, such as exploit availability or system attack surface. Representing Information for Decisions About Vulnerabilities describes our design goals for a pragmatic prioritization methodology that can improve and build on the state of current practice.

The target audience for SSVC is vulnerability managers of any kind. SSVC assumes that the vulnerability manager has identified that there is a vulnerability. We take our definition of vulnerability from 11: “a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.” A variety of problems or issues with computer systems are important but are not vulnerabilities. SSVC presents a risk prioritization method that might be useful or at least allied to other risk management methods for these other kinds of issues. However, for this work we focus on decisions in the situation where there is a vulnerability and the vulnerability management team wants to decide what to do about it.

  1. Vilius Benetis, Olivier Caleff, Cristine Hoepers, Angela Horneman, Allen Householder, Klaus-Peter Kossakowski, Art Manion, Amanda Mullens, Samuel Perl, Daniel Roethlisberger, Sigitas Rokas, Mary Rossell, Robin M. Ruefle, D'esir'ee Sacher, Krassimir T. Tzvetanov, and Mark Zajicek. Computer security incident response team (CSIRT) services framework. Technical Report ver. 2, FIRST, Cary, NC, USA, 2019. ↩

  2. Jonathan M Spring. Review of human decision-making during computer security incident analysis. Digital Threats: Research and Practice, April 2021. URL: https://doi.org/10.1145/3427787, doi:10.1145/3427787. ↩

  3. Common vulnerability scoring system SIG. URL: https://www.first.org/cvss/ (visited on 2019-03-01). ↩

  4. Katheryn A Farris, Ankit Shah, George Cybenko, Rajesh Ganesan, and Sushil Jajodia. Vulcon: a system for vulnerability prioritization, mitigation, and management. Transactions on Privacy and Security, 21(4):16, 2018. ↩

  5. Jonathan M Spring, Eric Hatleback, Allen D Householder, Art Manion, and Deana Shick. Towards improving CVSS. Technical Report, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2018. ↩

  6. Luca Allodi and Fabio Massacci. A preliminary analysis of vulnerability scores for attacks in wild: the ekits and sym datasets. In Workshop on Building analysis datasets and gathering experience returns for security, 17–24. ACM, 2012. ↩

  7. Luca Allodi, Marco Cremonini, Fabio Massacci, and Woohyun Shim. The effect of security education and expertise on security assessments: the case of software vulnerabilities. In Workshop on Economics of Information Security. Innsbruck, Austria, 2018. ↩

  8. Simson Garfinkel and Heather Richter Lipford. Usable security: history, themes, and challenges. Synthesis Lectures on Information Security, Privacy, and Trust, 5(2):1–124, 2014. ↩

  9. Marcus Pendleton, Richard Garcia-Lebron, Jin-Hee Cho, and Shouhuai Xu. A survey on systems security metrics. ACM Comput. Surv., 49(4):62:1–62:35, 2016. ↩

  10. Stefan Laube and Rainer Böhme. Strategic aspects of cyber risk information sharing. ACM Comput. Surv., November 2017. URL: https://doi.org/10.1145/3124398. ↩

  11. Allen D Householder, Garret Wassermann, Art Manion, and Christopher King. The CERT® guide to coordinated vulnerability disclosure. Technical Report CMU/SEI-2017-TR-022, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2020. URL: https://vuls.cert.org/confluence/display/CVD/Executive+Summary. ↩

Representing Information for Decisions About Vulnerabilities

We propose that decisions about vulnerabilities—rather than their severity—are a more useful approach. Our design goals for the decision-making process are to

  • clearly define whose decisions are involved
  • properly use evidentiary categories
  • be based on reliably available evidence
  • be transparent
  • be explainable

Our inspiration and justification for these design goals are that they are the features of a satisfactory scientific enterprise 1 adapted to the vulnerability management problem.

Clearly Define Whose Decisions Are Involved

To consider decisions about managing the vulnerability rather than just its technical severity, one must be clear about whose decisions are involved. Organizations that produce patches and fix software clearly have different decisions to make than those that deploy patches or other security mitigations. For example, organizations in the aviation industry have different priorities than organizations that make word processors. These differences indicate a requirement: any formalism must adequately capture the different decisions and priorities exhibited by different groups of stakeholders. As a usability requirement, the number of stakeholder groups needs to be small enough to be manageable, both by those issuing scores and those seeking them.

The goal of adequacy is more appropriate than optimality. Our search process need not be exhaustive; we are satisficing rather than optimizing 2. Finding any system that meets all of the desired criteria is enough.

Properly Use Evidentiary Categories

Decisions are not numbers. They are qualitative actions that an organization can take. In many cases, numerical values can be directly converted to qualitative decisions. For example, if your child’s temperature is 105°F (40.5°C), you decide to go to the hospital immediately. Conversion from numerical to qualitative values can be complicated by measurement uncertainty and the design of the metrics. For example, CVSS scores were designed to be accurate with +/- 0.5 points of the given score 3. Therefore, under a Gaussian error distribution, 8.9 is really 60\% high and 40\% critical since the recommended dividing line is 9.0. SSVC decisions should be distinct and crisp, without such statistical overlaps.

We avoid numerical representations for either inputs or outputs of a vulnerability management decision process. Quantified metrics are more useful when

  1. data for decision making is available, and
  2. the stakeholders agree on how to measure.

Vulnerability management does not yet meet either criterion. Furthermore, it is not clear to what extent measurements about a vulnerability can be informative about other vulnerabilities. Each vulnerability has a potentially unique relationship to the socio-technical system in which it exists, including the Internet.

Be Based on Reliably Available Evidence

Vulnerability management decisions are often contextual: given what is known at the time, the decision is to do X. But what is known can change over time, which can and should influence the decision. The context of the vulnerability, and the systems it impacts, are inextricably linked to managing it. Some information about the context will be relatively static over time, such as the contribution of a system to an organization's mission. Other information can change rapidly as events occur, such as the public release of an exploit or observation of attacks. Temporal and environmental considerations should be primary, not optional as they are in CVSS. We discuss the temporal aspects further in Information Changes over Time.

Be Transparent

We make the deliberation process as clear as is practical; therefore, we risk belaboring some points to ensure our assumptions and reasoning are explicit. Transparency should improve trust in the results.

Be Explainable

Finally, any result of a decision-making process should be explainable Explainable is defined and used with its common meaning, not as it is used in the research area of explainable artificial intelligence. An explanation should make the process intelligible to an interested, competent, non-expert person. There are at least two reasons common explainability is important:

  1. for troubleshooting and error correction and
  2. for justifying proposed decisions.

Summary

To summarize, the following are our design goals for a vulnerability management process:

  • Outputs are decisions.

  • Pluralistic recommendations are made among a manageable number of stakeholder groups.

  • Inputs are qualitative.

  • Outputs are qualitative, and there are no (unjustified) shifts to quantitative calculations.

  • Process justification is transparent.

  • Results are explainable.

  1. Jonathan M Spring, Tyler Moore, and David Pym. Practicing a science of security: a philosophy of science perspective. In New Security Paradigms Workshop. Santa Cruz, CA, USA, 2017. URL: https://tylermoore.utulsa.edu/nspw17.pdf. ↩

  2. Herbert A. Simon. The sciences of the artificial. MIT press, Cambridge, MA, 3rd edition, 1996. ↩

  3. CVSS SIG. Common vulnerability scoring system. Technical Report version 3.1 r1, Forum of Incident Response and Security Teams, Cary, NC, USA, 2019. URL: https://www.first.org/cvss/v3.1/specification-document. ↩

Formalization Options

This section briefly surveys the available formalization options against the six design goals described above. The table below summarizes the results. This survey is opportunistic; it is based on conversations with several experts and our professional experience. The search process leaves open the possibility of missing a better option. However, at the moment, we are searching for a satisfactory formalism, rather than an optimal one. We focus on highlighting why some common options or suggestions do not meet the above design goals. We argue that decision trees are a satisfactory formalism.

Quantitative Options

We rule out many quantitative options, such as anything involving statistical regression techniques or Bayesian belief propagation. Most machine learning (ML) algorithms are also not suitable because they are both unexplainable (in the common sense meaning) and quantitative. Random forest algorithms may appear in scope since each individual decision tree can be traced and the decisions explained 1. However, they are not transparent enough to simply know how the available decision trees are created or mutated and why a certain set of them works better. In any case, random forests are necessary only when decision trees get too complicated for humans to manage. We demonstrate below that in vulnerability management, useful decision trees are small enough for humans to manage.

Logics

Logics are generally better suited for capturing qualitative decisions. Boolean first-order logic is the “usual” logic—with material implication (if/then), negation, existential quantification, and predicates. For example, in program verification, satisfiability problem (SAT) and satisfiability modulo theories (SMT) solvers are used to automate decisions about when some condition holds or whether software contains a certain kind of flaw. While the explanations provided by logical tools are accessible to experts, non-experts may struggle. Under special conditions, logical formulae representing decisions about categorization based on exclusive-or conditions can be more compactly and intelligibly represented as a decision tree.

Decision Trees

Decision trees are used differently in operations research than in ML. In ML, decision trees are used as a predictive model to classify a target variable based on dependent variables. In operations research and decision analysis, a decision tree is a tool that is used to document a human process. In decision analysis, analysts “frequently use specialized tools, such as decision tree techniques, to evaluate uncertain situations” 2. We use decision trees in the tradition of decision analysis, not ML.

How Vulnerability Prioritization Options Meet the Design Goals

Outputs are Decisions Pluralistic Qualitative Inputs Qualitative Outputs Transparent Explainable
Parametric Regression ❌ ❌ ✅ ❌ ❌ ✅
CVSS v3.0 ❌ ❌ ✅ ❌ ❌ ❌
Bayesian Belief Networks ❌ Maybe ❌ ❌ ✅ ✅
Neural Networks ❌ ❌ ❌ ❌ ❌ ❌
Random Forest ✅ ✅ ✅ Maybe ❌ Maybe
Other ML ❌ Maybe ❌ ❌ ❌ ❌
Boolean First Order Logics Maybe Maybe ✅ ✅ ✅ Maybe
Decision Trees ✅ ✅ ✅ ✅ ✅ ✅

  1. Stuart J Russell and Peter Norvig. Artificial intelligence: A modern approach. Pearson Education, Upper Saddle River, NJ, 3rd edition, 2011. ↩

  2. Ronald A Howard and James E Matheson, editors. Readings on the Principles and Applications of Decision Analysis: General collection. Volume 1. Strategic Decisions Group, 1983. ↩

Decision Trees

A decision tree is an acyclic structure where nodes represent aspects of the decision or relevant properties and branches represent possible options for each aspect or property. Each decision point can have two or more options.

Decision trees can be used to meet all of the design goals, even plural recommendations and transparent tree-construction processes. Decision trees support plural recommendations because a separate tree can represent each stakeholder group. The opportunity for transparency surfaces immediately: any deviation among the decision trees for different stakeholder groups should have a documented reason—supported by public evidence when possible—for the deviation. Transparency may be difficult to achieve, since each node in the tree and each of the values need to be explained and justified, but this cost is paid infrequently.

There has been limited but positive use of decision trees in vulnerability management. For example, Vulnerability Response Decision Assistance (VRDA) studies how to make decisions about how to respond to vulnerability reports 1. This paper continues roughly in the vein of such work to construct multiple decision trees for prioritization within the vulnerability management process.

Representation choices

A decision tree can represent the same content in different ways. Since a decision tree is a representation of logical relationships between qualitative variables, the equivalent content can be represented in other formats as well. The R package data.tree has a variety of both internal representations and visualizations.

For data input, we elected to keep SSVC simpler than R, and just use a CSV (or other fixed-delimiter separated file) as canonical data input. All visualizations of a tree should be built from a canonical CSV that defines the decisions for that stakeholder. Examples are located in SSVC/data. An interoperable CSV format is also flexible enough to support a variety of uses. Every situation in SSVC is defined by the values for each decision point and the priority label (outcome) for that situation (as defined in Likely Decision Points and Relevant Data). A CSV will typically be 30-100 rows that each look something like: 

2,none,laborious,partial,significant,scheduled
Where “2” is the row number, none through significant are values for decision points, and scheduled is a priority label or outcome. Different stakeholders will have different decision points (and so different options for values) and different outcomes, but this is the basic shape of a CSV file to define SSVC stakeholder decisions.

Visualizing Decision Trees

The tree visualization options are more diverse. We provide an example format, and codified it in src/SSVC_csv-to-latex.py. Why have we gone to this trouble when (for example) the R data.tree package has a handy print-to-ASCII function? Because this function produces output like the following: 

1    start                                        
2     ¦--AV:N                                     
3     ¦   ¦--AC:L                                 
4     ¦   ¦   ¦--PR:N
...
31    ¦   ¦   ¦   ¦   ¦   ¦       ¦--A:L    Medium
32    ¦   ¦   ¦   ¦   ¦   ¦       °--A:N    Medium
33    ¦   ¦   ¦   ¦   ¦   °--C:N                  
34    ¦   ¦   ¦   ¦   ¦       ¦--I:H              
35    ¦   ¦   ¦   ¦   ¦       ¦   ¦--A:H  Critical

This sample is a snippet of the CVSS version 3.0 base scoring algorithm represented as a decision tree. The full tree can be found here. This tree representation is functional, but not as flexible or aesthetic as might be hoped. The visualizations provided by R are geared towards analysis of decision trees in a random forest ML model, rather than operations-research type trees.

  1. Art Manion, Kazuya Togashi, Joseph B. Kadane, Fumihiko Kousaka, Shawn McCaffrey, Christopher King, Masanori Yamaguchi, and Robert Weiland. Effectiveness of the vulnerability response decision assistance (VRDA) framework. Technical Report, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2009. URL: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=50301. ↩

Ended: Representing Information

Vulnerability Management Decisions

This section will define our audience for decision advice and how we are scoping our advice on vulnerability management decisions. Viable decision guidance for vulnerability management should (at a minimum) consider the stakeholder groups, their potential decision outcomes, and the data needed for relevant decision points. This section covers the first of these three parts, and the following sections address the other parts in turn. The “who” is primarily about categories of stakeholders—suppliers, deployers, and coordinators—as well as their individual risk tolerances. The “what” is about the scope, both in how the affected system is defined and how much of the world an analyst should consider when estimating effects of a vulnerability.

While we strive to make our examples realistic, we invite the community to engage and conduct empirical assessments to test them. The following construction should be treated as an informed hypothesis rather than a conclusion.

Enumerating Stakeholders

Stakeholders in vulnerability management can be identified within multiple independent axes. For example, they can be identified by their responsibility: whether the group supplies, deploys, or coordinates remediation actions. Depending what task a team is performing in a supply chain, the team may be considered a supplier, deployer, or a coordinator. Therefore, one organization may have teams that take on different roles.

Example: Supplier and Deployer Roles within an Organization

For example, an organization that develops and uses its own software might delegate the supplier role to its development team and the deployer role to its IT operations team. On the other hand, organizations using a DevOps approach to providing services might have a single group responsible for both the supplier and deployer roles.

Organizations may also be distinguished by the type of industry sector. While it might be useful to enumerate all the sectors of the economy, we propose to draft decision points that include those from multiple important sectors. For example, we have safety-related questions in the decision path for all suppliers and deployers. The decision will be assessed whether or not the stakeholder is in a safety-critical sector.

The choice not to segregate the decisions by sector is reinforced by the fact that any given software system might be used by different sectors. It is less likely that one organization has multiple responsibilities within the vulnerability management process.

Even if there is overlap within an organization, the two responsibilities are often located in distinct business units with distinct decision-making processes. We can treat the responsibilities as non-overlapping, and, therefore, we can build two decision trees—one for each of the “patch supplier” and “patch deployer” responsibilities in the vulnerability management process. Each of these trees will have different decision points that they take to arrive at a decision about a given unit of work.

The next two sections describe the decision space and the relevant decision points that we propose for these two responsibilities within the vulnerability management process.

Target Audience

The target audience for this paper is professional staff responsible for making decisions about information systems. This audience encompasses a broad class of professionals, including suppliers, system maintainers, and administrators of many types. It also includes other roles, such as risk managers, technical managers, and incident responders. Although every layperson who owns a computing device makes decisions about managing it, they are not the target audience. The following decision system may help such laypeople, but we do not intend it to be used by that audience.

While C-level executives and public policy professionals often make, shape, or incentivize decisions about managing information systems, they are not the target audience, either. To the extent that decision trees for vulnerability management help higher level policy decisions, we believe the best way to help policy makers is by making technical decisions more transparent and explainable. Policy makers may see indirect benefits, but they are not our primary audience and we are not designing an approach for them directly.

Enumerating Decisions

Stakeholders with different responsibilities in vulnerability management have very different decisions to make. This section focuses on the differences among organizations based on their vulnerability management responsibilities. Some decision makers may have different responsibilities in relation to different software.

Example: Different Responsibilities for Different Software

For example, an Android app developer is a developer of the app, but is a deployer for any changes to the Android OS API. This situation is true for libraries in general:

  • A web browser developer makes decisions about applying patches to DNS lookup libraries and transport layer security (TLS) libraries.
  • A video game developer makes decisions about applying patches released to the Unreal Engine.
  • A medical device developer makes decisions about applying patches to the Linux kernel.

One might view applying patches as including some development and distribution of the updated product. Or one might take the converse view, that development includes updating libraries. Either way, in each of these examples (mobile device apps, web browsers, video games, medical devices), we recommend that the professionals making genuine decisions do three things:

Bootstrapping SSVC

We provide a more detailed process for SSVC adoption in Bootstrapping SSVC.

  1. identify the decisions explicitly
  2. describe how they view their role(s)
  3. identify which software projects their decision relates to

SSVC models the decision of “With what priority should the organization take action on a given vulnerability management work unit?” to be agnostic to whether or not a patch is available. If their decisions are explicit, then the decision makers can use the recommendations from this documentation that are relevant to them.

The Stakeholder Role / Decision Identity

As we have continued to develop SSVC and received feedback from SSVC implementers, we've found that similar stakeholders making similar decisions can often use the same set of decision points to model their decisions. Organizations might use the same structure of decision points but have different priority levels they need to map to their decisions. For example, one organization might need to map their decisions to three priority levels, while another might need to map their decisions to five priority levels.

Variation can also arise from different organization goals or risk tolerance that alters the policy mapping the decision points to priority outcomes. The decision points themselves are often the same for the stakeholder-decision pairing, but the policy that maps the decision points to priority outcomes is different.

The salient information required to make a specific kind of decision in a specific context is often the same across organizations. For this reason, we have found it useful to think of the identity of a decision model as the combination of the stakeholder role and the decision being modeled. We've provided a few examples of different stakeholders' decision models in the SSVC How-To section:

Enumerating Vulnerability Management Units of Work

Stakeholder Units of Work

We provide a few examples of different stakeholders' units of work in the SSVC How-To section. See the Units of Work section of each stakeholder's decision model for more information.

A unit of work means either remediating the vulnerability—such as applying a patch—or deploying a mitigation. Both remediation and mitigations often address multiple identified vulnerabilities. The unit of work may be different for different stakeholders: a supplier might be selecting individual vulnerabilities to fix, while a deployer is choosing whether or not to deploy a patch bundle that fixes multiple vulnerabilities.

The units of work can also change as the vulnerability response progresses through a stakeholder's process. Coordinators might make triage decisions on individual reports, but then make publication decisions on a set of related cases at once.

Aggregation of SSVC Across Units of Work

SSVC users should answer the suggested questions for whatever discrete unit of work they are considering. There is not necessarily a reliable function to aggregate a recommendation about remediation out of its constituent vulnerabilities. For the sake of simplicity of examples, we treat the remediation as a patch of one vulnerability, and comment on any difficulty in generalizing our advice to a more complex patch where appropriate.

Remediation and Mitigation

To further clarify terms, we use the definitions from DoD Instruction 8530.01 Cybersecurity Activities Support to DoD Information Network Operations (DODI 8530.01).

  • Remediation occurs when the vulnerability is eliminated or removed.
  • Mitigation occurs when the impact of the vulnerability is decreased without reducing or eliminating the vulnerability

Examples of remediation include applying patches, fixes and upgrades; or removing the vulnerable software or system from operation. Mitigating actions may include software configuration changes, adding firewall ACLs, or otherwise limiting the system's exposure to reduce the risk of the impact of the vulnerability; or accepting the risk.

Enumerating Action Priority

Decision Outcomes and Action Priority

We provide examples of different stakeholders' action priorities in the SSVC How-To section. See the Decision Outcomes section of each stakeholder's decision model for more information.

Structuring decisions about vulnerability management action priority is a core concept of SSVC. However, we also recognize that each stakeholder has different responsibilities and therefore different decisions to make. Furthermore, even when stakeholders are making similar decisions, they may have different goals and constraints, which lead to different priorities.

For example, some suppliers might need to map their vulnerability response decisions onto a specific set of service level expectations (SLEs) set by their contractual obligations to their customers. Similarly, deployers might need to integrate their decisions into a broader risk management framework or IT Service Management (ITSM) process.

SSVC, Vulnerability Response, and Risk Management Processes

A few examples from the US Government of organizational process requirements that can affect the decision modeling process in SSVC adoption include:

  • CISA Binding Operational Directive (BOD) 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities, sets service level expectations for federal agencies to remediate vulnerabilities based on the exploitation status of the vulnerability.
  • DoDI 8510.01, Risk Management Framework for DoD Systems, includes multiple steps involving prioritization of impact levels (Task P-6), stakeholder assets (Task P-10), and security requirements (Task P-15).

SSVC implementers in organizations subject to requirements like these may need to adapt their decision models to ensure that they are consistent with the requirements of the organization's broader risk management and ITSM processes.

Items With the Same Priority

Within each setting, the decisions are a kind of equivalence class for priority. That is, if an organization must deploy patches for three vulnerabilities, and if these vulnerabilities are all assigned the scheduled priority, then the organization can decide which to deploy first. The priority is equivalent.

This is not CVSS

This approach may feel uncomfortable since CVSS gives the appearance of a finer grained priority. CVSS appears to say,

Not just 4.0 to 6.9 is ‘medium’ severity, but 4.6 is more severe than 4.5. However, as discussed previously (see page 4) , CVSS is designed to be accurate only within +/- 0.5, and, in practice, is scored with errors of around +/- 1.5 to 2.5 1.

An error of this magnitude is enough to make all of the “normal” range from 4.0 to 6.9 equivalent, because 5.5 +/- 1.5 is the range 4.0 to 7.0.

Our proposal is an improvement over this approach.

CVSS errors often cross decision boundaries; in other words, the error range often includes the transition between “high” and “critical” or “medium.” Since our approach keeps the decisions qualitatively defined, this fuzziness does not affect the results.

Three Vulnerabilities of Equivalent Priority

Returning to the example of an organization with three vulnerabilities to remediate that were assigned scheduled priority, in SSVC, they can be patched in any order. This is an improvement over CVSS, since based on the scoring errors, CVSS was essentially just giving random fine-grained priorities within qualitative categories anyway.

With our system, organizations can be more deliberate about conveniently organizing work that is of equivalent priority.

  1. Luca Allodi, Marco Cremonini, Fabio Massacci, and Woohyun Shim. The effect of security education and expertise on security assessments: the case of software vulnerabilities. In Workshop on Economics of Information Security. Innsbruck, Austria, 2018. ↩

Risk Tolerance and Response Priority

SSVC enables stakeholders to balance and manage their risks themselves. We follow the risk management vocabulary from 1 and define risk as “effect of uncertainty on objectives;” see 1 for notes on the terms in the definition. A successful vulnerability management practice must balance at least two risks:

Contexualizing Risk

To place these risks in context, we follow the SEI's Taxonomy of Operational Cyber Security Risks 2.

Change risk can be characterized as a combination of Class 2 and/or Class 3 risks.

  • Class 2: Systems and Technology Failures includes hardware, software, and systems risks.
  • Class 3: Failed Internal Processes can arise from process design, process execution, process controls, or supporting processes.

Meanwhile, vulnerability risk falls into Subclass 1.2: Actions of People: Deliberate.

  1. Change risk: the potential costs of deploying remediation, which include testing and deployment in addition to any problems that could arise from making changes to production systems.
  2. Vulnerability risk: the potential costs of incidents resulting from exploitation of vulnerable systems

In developing the decision trees in this document, we had in mind stakeholders with a moderate tolerance for risk. The resulting trees reflect that assumption. Organizations may of course be more or less conservative in their own vulnerability management practices, and we cannot presume to determine how an organization should balance their risk.

We therefore remind our readers that the labels on the trees (defer, immediate, etc.) can and should be customized to suit the needs of individual stakeholders wherever necessary and appropriate.

Risk Tolerance Influences Response Priority

  • An organization with a high aversion to change risk might choose to accept more vulnerability risk by lowering the overall response labels for many branches in the trees, resulting in fewer vulnerabilities attaining the most urgent response.
  • On the other hand, an organization with a high aversion to vulnerability risk could elevate the priority of many branches to ensure fixes are deployed quickly.

  1. ISO. Risk management – vocabulary. Technical Report 73:2009(en), International Organization for Standardization, Geneva, CH, 2009. URL: https://www.iso.org/obp/ui/#iso:std:iso:guide:73:ed-1:v1:en. ↩↩

  2. James L Cebula and Lisa R Young. A taxonomy of operational cyber security risks. Technical Report CMU/SEI-2010-TN-028, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2010. URL: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9395. ↩

Scope

Scope is an important variable in the answers of these decision points. It has at least three aspects:

  • how the boundaries of the affected system are set
  • whose security policy is relevant
  • how far forward in time or causal steps one reasons about effects and harms

We put forward recommendations for each of these aspects of scope.

However, users of the decision process may want to define different scopes.

Decision Scope can be Stakeholder-Specific

Users may define a different scope as long as the scope

  1. is consistent across decisions, and
  2. is credible, explicit, and accessible to all relevant decision makers.

Deployers and Suppliers May Define Different Scopes for End-of-Life Products

For example, suppliers often decline to support products beyond a declared end-of-life (EOL) date. In these cases, a supplier could reasonably consider vulnerabilities in those products to be out of scope.

However, a deployer may still have active instances of EOL products in their infrastructure. It remains appropriate for a deployer to use SSVC to prioritize their response to such situations. Even if there is no remediation forthcoming from the supplier, it may be possible for the deployer to mitigate or remediate the vulnerability in other ways, up to and including decommissioning the affected system(s).

Boundaries of the Affected System

One distinction is whether the system of interest is software per se or a cyber-physical system. A problem is that in every practical case, both are involved. Software is what has vulnerabilities and is what vulnerability management is focused on remediating. Multiple pieces of software run on any given computer system. To consider software vulnerabilities in a useful scope, we follow prior work and propose that a vulnerability affects “the set of software instructions that executes in an environment with a coherent function and set of permissions” 1. This definition is useful because it lets us keep to common usage and intuition and call the Linux kernel—at least a specific version of it—“one piece” of software.

But decision points about safety and mission impact are not about the software in isolation; they are about the entire cyber-physical system, of which the software is a part. The term “physical” in “cyber-physical system” should be interpreted broadly; selling stocks or manipulating press outlet content are both best understood as affecting human social institutions. These social institutions do not have much of a corporeal instantiation, but they are physical in the sense that they are not merely software, and so are parts of cyber-physical systems.

The hard part of delineating the boundaries of the affected system is specifying what it means for one system to be part of another system. Just because a computer is bolted to a wall does not mean the computer is part of the wall’s purpose, which is separating physical space. At the same time, an off-premises DNS server may be part of the site security assurance system if the on-premises security cameras rely on the DNS server to connect to the displays at the guard’s desk.

Defining Cyber-Physical Systems

We define computer software as part of a cyber-physical system if the two systems are mutually manipulable; that is, changes in the part (the software) will (at least, often) make detectable and relevant changes to the whole (the cyber-physical system), and changes in the whole will (often) make relevant and detectable changes in the part 2.

Locating the Vulnerability

When reasoning about a vulnerability, we assign the vulnerability to the nearest, relevant—yet more abstract—discrete component. This assignment is particularly important when assessing technical impact on a component. This description bears some clarification, via each of the adjectives:

  • Nearest is relative to the abstraction at which the vulnerability exists.
  • Relevant implies that the impacted component must be in the chain of abstraction moving upward from the location of the flaw.
  • More abstract means that the impacted component is at least one level of abstraction above the specific location of the vulnerability. For example, if the vulnerability is localized to a single line of code in a function, then the function, the module, the library, the application, the product, and the system it belongs to are all “more abstract.”
  • Discrete means there is an identifiable thing that can be remediated (e.g., the unit of patching).

Products, libraries, and applications tend to be appropriate objects of focus when seeking the right level to analyze the impact of a vulnerability.

Example of Locating the Vulnerability in a Discrete Component

For example, when reasoning about the technical impact of a vulnerability that is localized to a function in a module in an open source library, the nearest relevant discrete abstraction is the library because the patches are made available at the library level.

Similarly, analysis of a vulnerability in closed source database software that supports an enterprise resource management (ERM) system would consider the technical impact to the database, not to the ERM system.

Relevant Security Policy

Our definition of a vulnerability includes a security policy violation, but it does not clarify whose security policies are relevant 3. For an organizational PSIRT or CSIRT, the organization's security policy is most relevant. The answer is less clear for coordinators or ISACs.

Security Policy Relevance is Stakeholder-Specific

An example scenario that brings the question into focus is phone OS jailbreak methods. The owner of the phone may elect to jailbreak it; there is at least an implicit security policy from the owner that allows this method.

However, from the perspective of the explicit phone OS security policy embedded in the access controls and separation of privileges, the jailbreak is exploiting a vulnerability. If a security policy is embedded in technical controls, such as OS access controls on a phone, then anything that violates that security policy is a vulnerability.

Reasoning Steps Forward

This aspect of scope is about immediacy, prevalence, and causal importance.

  • Immediacy is about how soon after the decision point adverse effects should occur to be considered relevant.
  • Prevalence is about how common adverse effects should be to be considered relevant.
  • Causal importance is about how much an exploitation of the software in the cyber-physical system contributes to adverse effects to be considered relevant.

Our recommendation is to walk a pragmatic middle path on all three aspects. Effects are not relevant if they are merely possible, too infrequent, far distant, or unchanged by the vulnerability. But effects are relevant long before they are absolutely certain, ubiquitous, or occurring presently.

Summary of Scope

We summarize this aspect of scope as consider credible effects based on known use cases of the software system as a part of cyber-physical systems.

  1. Jonathan M Spring, Sarah Kern, and Alec Summers. Global adversarial capability modeling. In APWG Symposium on Electronic Crime Research (eCrime). Barcelona, 2015. IEEE. ↩

  2. Jonathan M Spring and Phyllis Illari. Building general knowledge of mechanisms in information security. Philosophy & Technology, 32():627–659, 2018. doi:10.1007/s13347-018-0329-z. ↩

  3. Allen D Householder, Garret Wassermann, Art Manion, and Christopher King. The CERT® guide to coordinated vulnerability disclosure. Technical Report CMU/SEI-2017-TR-022, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2020. URL: https://vuls.cert.org/confluence/display/CVD/Executive+Summary. ↩

SSVC and Asset Management

Vulnerability management is a part of asset management. SSVC can benefit from asset management practices and systems, particularly in regard to automating data collection and answers for some decision points. SSVC depends on asset management to some extent, particularly for context on the cost and risk associated with changing or updating the asset.

Asset Management Informs Decision Points

Asset management can help automate the collection of the Mission Impact, Situated Safety Impact, and System Exposure decision points. These decision points tend to apply per asset rather than per vulnerability. Therefore, once each is assessed for each asset, it can be applied to each vulnerability that applies to that asset. While the asset assessment should be reviewed occasionally for accuracy, storing this data in an asset management system should enable automated scoring of new vulnerabilities on these decision points for those assets.

Our method is for prioritizing vulnerabilities based on the risk stemming from exploitation. There are other reasonable asset management considerations that may influence remediation timelines. There are at least three aspects of asset management that may be important but are out of scope for SSVC.

  1. Mitigation Cost First and most obvious is the transaction cost of conducting the mitigation or remediation. System administrators are paid to develop or apply any remediations or mitigations, and there may be other transactional costs such as downtime for updates.

  2. Mitigation Risk Second is the risk of the remediation or mitigation introducing a new error or vulnerability. Regression testing is part of managing this type of risk.

  3. Operational Cost Finally, there may be an operational cost of applying a remediation or mitigation, representing an ongoing change of functionality or increased overhead. A decision maker could order work within one SSVC priority class (scheduled, out-of-cycle, etc.) based on these asset management considerations, for example. Once the organization remediates or mitigates all the high-priority vulnerabilities, they can then focus on the medium-level vulnerabilities with the same effort spent on the high-priority ones.

Asset management and risk management also drive some of the up-front work an organization would need to do to gather some of the necessary information. This situation is not new; an asset owner cannot prioritize which fixes to deploy to its assets if it does not have an accurate inventory of its assets. The organization can pick its choice of tools; there are about 200 asset management tools on the market 1. Emerging standards like the Software Bill of Materials (SBOM) 2 would likely reduce the burden on asset management, and organizations should prefer systems which make such information available. If an organization does not have an asset management or risk management (see also Gathering Information About Mission Impact) plan and process in place, then SSVC provides some guidance as to what information is important to vulnerability management decisions and the organization should start capturing, storing, and managing.

  1. Captera. It asset management software. URL: https://www.capterra.com/it-asset-management-software/ (visited on 2020-08-20). ↩

  2. Michelle Jump and Art Manion. Framing software component transparency: Establishing a common software bill of material (SBOM). Technical Report, National Telecommunications and Information Administration, Washington, DC, November 2019. ↩

Ended: Vulnerability Management Decisions

Putting the Pieces Together

As we have continued to refine our concept of SSVC, we have an increasing understanding of the importance of Decision Points as the foundational blocks from which the rest of the SSVC concept is built. A second, but less foundational, concept are the Outcomes that provide a vocabulary to describe the results of a decision.

Decision Points and Outcomes as Bricks

Over time, we have come to think of decision points and outcomes as the LEGO® bricks of SSVC decision models.

LEGO® Bricks

LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this site.

LEGO® Bricks come in different shapes and sizes, and they can be combined in different ways to build different structures. Similarly, decision points come in different shapes and sizes, and they can be combined in different ways to build different decision models. And just as some bricks can be substituted for others to add variation, some decision points are substitutable for others.

We have realized that part of the value of enumerated decision points is that they provide a way to organize the information that is relevant to a decision. This organization is important because it helps us to understand the decision and to communicate the decision model to others.

Decision points and outcomes have a few key characteristics that make them useful for organizing information:

  • Independence: Each decision point represents a different aspect or dimension of the decision being modeled. This means that the decision points are not redundant with each other. They may each be relevant to the decision, but they are relevant in different ways.
  • Discreteness: Each decision point has a finite and discrete set of possible values. These specific values that can then be mapped onto data collection and analysis results so that the data can be used to inform the decision.
  • Well-Definedness: Each decision point has a clear meaning and a clear, ordered set of possible values. This means that the decision point values are not ambiguous or open to interpretation.

In our brick analogy, the toy bricks are similarly independent, discrete, and well-defined. Independence means that different bricks can serve different purposes in the model. The pips on the bricks provide discrete points of attachment to allow bricks to connect together. Well-definedness (specification and manufacturing consistency) allows bricks to be combined effectively.

Model Kits and How to Use Them

When you buy a model kit at the store, you get

  • a box with a picture of the model on the front, and sometimes variation suggestions on the back
  • a set of bricks, usually organized into bags appropriate for the different stages of the build
  • a set of instructions to tell you how to combine the bricks to build the model(s) pictured on the box

From that starting point, there are a few different ways you might proceed:

Follow the examples as provided

For many people, this is the experience they want. They want to build the model exactly as it is pictured on the box, and for that purpose they can follow the instructions provided.

Adapt the examples to suit your needs

But other folks might want to build something else with the bricks. They might want to adapt the model slightly for their own purposes, perhaps turning an airplane with wheels into a seaplane by adding floats, or turning a car into a spaceship by adding a rocket booster. To do that, they might follow the instructions provided, just adapting them slightly with their own variations. Sometimes they might add a few extra bricks from their own collection to make the model more like what they want.

Combine different kits to build something new

Perhaps they might want to combine two different model kits to build something new. Knowing which parts of the instructions to follow and which parts to ignore is a matter of understanding the properties of the bricks and the context of the model they want to build.

Build something completely original

A builder might want to create something completely new that is not available in kit form, like a castle guarded by robots. In that scenario, they might think of the kit more as a supply of specific bricks than as a specific model. Advanced builders need to understand more about what they are trying to build and how the bricks can be combined to build it.

The point is that the model kits serve as a starting point with a lot of flexibility, but it is up to the builder to decide how much of that flexibility to use.

SSVC Decision Models as Kits

Similarly, SSVC provides a set of "bricks" in the form of decision points and outcomes. We have provided a set of example decision models and policies to get you started. You might choose to simply use what we've provided as a starting point. Or you might already recognize that our example gets the structure of the decision model right, but you need to adapt the outcomes or policy to better fit your situation.

You might also recognize that you need to combine different example decision models to build the model you need. For example, you might recognize that you need to combine the supplier decision model with the deployer decision model to build a model that is relevant to your situation as both a supplier and a deployer.

Or, perhaps you have a decision problem that we have not yet addressed with any of our examples. In that case, you might examine the decision points we've provided and decide which ones are relevant to your situation. You could choose to customize a decision point to better fit your situation, or you might choose to add a new decision point to better suit your needs.

This is the embodiment of the Stakeholder-Specific concept in SSVC: SSVC provides the components for you to build your own decision models, and we provide some examples to get you started. If the examples are sufficient for your needs, then you can simply use them as they are.

But we recognize that you are the expert in your own situation, and that you are in a better position than we are to decide how to combine the provided components to build the decision model you need. If you need to adapt the components we've provided, or if you need to add new components, then we encourage you to do so. And if you think that your adaptations or additions would be useful to others, then we encourage you to share your suggestions, ideas, and changes with the community.

Worked Example

As an example, we will evaluate CVE-2018-14781 step by step from the deployer point of view. The scenario here is that used for the pilot study. This example uses the SSVC version 1 deployer decision tree.

The analyst’s first question is related to exploitation. Technically, one could answer the questions in any order; however, exploitation is a good starting point because given an adequately defined search procedure, one can always answer whether it finds an available exploit or proof of concept. The scenario description for the pilot study reads as follows:

State of exploitation

Metasploit and ExploitDB do not return results for this vulnerability. The NVD does not report any active exploitation of this vulnerability.

This information rules out “active” given the (perhaps limited) search procedure. While the search did not produce a precise PoC, based on the description of the vulnerability, it is a fairly standard traffic capture and replay attack that, given access to the transmission medium, should be straightforward to conduct with Wireshark. Therefore, we select the “PoC” branch and then ask about exposure. This considers the (fictional) deployer scenario blurb and the notional deployment of the affected system, as follows.

Scenario blurb

We are a hospital that uses Medtronic devices frequently because of their quality and popularity in the market. We give these devices out to clients who need to monitor and track their insulin intake. If clients need to access data on their device, they can physically connect it to their computer or connect via Bluetooth to an app on their phone for monitoring capabilities. Occasionally, clients who use this device will have a doctor’s appointment in which the doctors have machines that can access the device as well to monitor or change settings. It is unknown how secure the doctor’s computer that interfaces directly with this insulin pump is. If the doctor’s computer is compromised, it potentially means that every device that connects to it is compromised as well. If an update to the insulin pump is required, a client can do this on their own through their computer or app or through a doctor while they are on-site at the hospital.

Deployment of affected system

These pumps are attached directly to the client. If an update is required, the client is permitted to do that through their own computer or app. However, we have not provided them with documentation on properly using their computer or app to securely access their device. This is done for convenience so that if the user needs to change something quickly, they can. They can also come to us (hospital) for a change in their device’s settings for dosage etc. The doctor’s computer that directly handles interfacing with these devices is only connected to the intranet for the purpose of updating the client’s settings on the device. Doctors authenticate with ID badge and password.

System Exposure is less straightforward than Exploitation. The option open is clearly ruled out. However, it is not clear whether the optional Bluetooth connection between the medical device and a phone app represents controlled or small exposure. The description does not explicitly handle the capture/replay aspect of the vulnerability. If the only way to exploit the vulnerability is to be within physical transmission range of the device, then that physical constraint argues for exposure being small. However, if the client’s phone app could be used to capture and replay attack packets, then unless that app is particularly well secured, the answer should be controlled. Regardless, the answer is not clear from the supplied information. Furthermore, if this fictional app is specific to the insulin pump, then even if it is not compromised, the attack might use its installation to remotely identify targets. However, since most of the hospital’s clients have not installed the app, and for nearly all cases, physical proximity to the device is necessary; therefore, we select small and move on to ask about mission impact.

According to the fictional pilot scenario, “Our mission dictates that the first and foremost priority is to contribute to human welfare and to uphold the Hippocratic oath (do no harm).” The continuity of operations planning for a hospital is complex, with many MEFs. However, even from this abstract, it seems clear that “do no harm” is at risk due to this vulnerability. A mission essential function to that mission is each of the various medical devices works as expected, or at least if a device fails, it cannot actively be used to inflict harm. Unsolicited insulin delivery would mean that MEF “fails for a period of time longer than acceptable,” matching the description of MEF failure. The question is then whether the whole mission fails, which does not seem to be the case. The recovery of MEF functioning is not affected, and most MEFs (the emergency services, surgery, oncology, administration, etc.) would be unaffected. Therefore, we select MEF failure and move on to ask about safety impact.

This particular pilot study used SSVC version 1. In the suggested deployer tree for SSVC version 2.1, mission and safety impact would be used to calculate the overall Human Impact, and Automatable would need to be answered as well. Conducting further studies with the recommended version 2.1 Deployer tree remains an area of future work. In the pilot study, this information is conveyed as follows:

Use of the cyber-physical system

Insulin pumps are used to regulate blood glucose levels in diabetics. Diabetes is extremely common in the US. Misregulation of glucose can cause a variety of problems. Minor misregulation causes confusion or difficulty concentrating. Long-term minor mismanagement causes weigh management issues and blindness. Severe acute mismanagement can lead unconsciousness in a matter of minutes and death in a matter of hours. The impacted insulin pumps have a local (on-patient) wireless control, so wires to the pump do not have to be connected to the patient's control of the system, making the system lighter and less prone to be ripped out.

The closest match to “death in a matter of hours” would be hazardous because that description reads “serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures.” Depending on the details of the hospital’s contingency plans and its monitoring of their patients, the Safety Impact could be catastrophic. If there is no way to tell whether the insulin pumps are misbehaving, for example, then exploitation could go on for some time, leading to a catastrophic Safety Impact. The pilot information is inadequate in this regard, which is the likely source of disagreement about Safety Impact in Table 13. For the purposes of this example, imagine that after gathering that information, the monitoring situation is adequate, and select hazardous. Therefore, mitigate this vulnerability out-of-cycle, meaning that it should be addressed quickly, ahead of the usual update and patch cycle.

Evaluation of the Draft Trees

We conducted a pilot test on the adequacy of the hypothesized decision trees. This section reports results for SSVC version 1. The method of the pilot test is described in Pilot Methodogy. The study resulted in several changes to the hypothesized trees; we capture those changes and the reason for each of them in Pilot Results. The version 1 supplier and deployer trees included the improvements reported in Improvement Instigated by the Pilot.

Pilot Methodology

Development Methodology

For this tabletop refinement, we could not select a mathematically representative set of CVEs. The goal was to select a handful of CVEs that would cover diverse types of vulnerabilities. The CVEs that we used for our tabletop exercises are CVE-2017-8083, CVE-2019-2712, CVE-2014-5570, and CVE-2017-5753. We discussed each one from the perspective of supplier and deployer. We evaluated CVE-2017-8083 twice because our understanding and descriptions had changed materially after the first three CVEs (six evaluation exercises). After we were satisfied that the decision trees were clearly defined and captured our intentions, we began the formal evaluation of the draft trees, which we describe in the next section.

The pilot study tested inter-rater agreement of decisions reached. Each author played the role of an analyst in both stakeholder groups (supplying and deploying) for nine vulnerabilities. We selected these nine vulnerabilities based on expert analysis, with the goal that the nine cases cover a useful series of vulnerabilities of interest. Specifically, we selected three vulnerabilities to represent safety-critical cases, three to represent regulated-systems cases, and three to represent general computing cases.

During the pilot, we did not form guidance on how to assess the values of the decision points. However, we did standardize the set of evidence that was taken to be true for the point in time representing the evaluation. Given this static information sheet, we did not synchronize an evaluation process for how to decide whether Exploitation, for example, should take the value of none, PoC, or active. We agreed on the descriptions of the decision points and the descriptions of their values. The goal of the pilot was to test the adequacy of those descriptions by evaluating whether the analysts agreed. We improved the decision point descriptions based on the results of the pilot; our changes are documented in Improvement Instigated by the Pilot.

In the design of the pilot, we held constant the information available about the vulnerability. This strategy restricted the analyst to decisions based on the framework given that information. That is, it controlled for differences in information search procedure among the analysts. The information search procedure should be controlled because this pilot was about the framework content, not how people answer questions based on that content. After the framework is more stable, a separate study should be devised that shows how analysts should answer the questions in the framework. The basis for the assessment that information search will be an important aspect in using the evaluation framework is based on our experience while developing the framework. During informal testing, often disagreements about a result involved a disagreement about what the scenario actually was; different information search methods and prior experiences led to different understandings of the scenario. This pilot methodology holds the information and scenario constant to test agreement about the descriptions themselves. This strategy makes constructing a prioritization system more tractable by separating problems in how people search for information from problems in how people make decisions. This paper focuses only on the structure of decision making. Advice about how to search for information about a vulnerability is a separate project that will be part of future work. In some domains, namely exploit availability, we have started that work in parallel.

The structure of the pilot test is as follows. Table 11 provides an example of the information provided to each analyst. The supplier portfolio details use strikeout font because this decision item was removed after the pilot. The decision procedure for each case is as follows: for each analyst, for each vulnerability, for each stakeholder group, do the following.

  1. Start at the root node of the relevant decision tree (deployer or supplier).

  2. Document the decision branch that matches the vulnerability for this stakeholder context.

  3. Document the evidence that supports that decision.

  4. Repeat this decision-and-evidence process until the analyst reaches a leaf node in the tree.

Table: Example of Scenario Information Provided to Analysts (Using CVE-2019-9042 as the Example)

Information Item Description Provided to Analysts
Use of Cyber-Physical System Sitemagic’s content management system (CMS) seems to be fairly popular among smaller businesses because it starts out with a free plan to use it. Then it gradually has small increments in payment for additional features. Its ease-of-use, good designs, and one-stop-shopping for businesses attracts a fair number of clients. Like any CMS, it “manages the creation and modification of digital content. These systems typically support multiple users in a collaborative environment, allowing document management with different styles of governance and workflows. Usually the content is a website” \([Wikipedia](https://en.wikipedia.org/w/index.php?title=Content_management_system&oldid=913022120), 2019\)
State of Exploitation Appears to be active exploitation of this vulnerability according to NVD. They have linked to the exploit: http://www.iwantacve.cn/index.php/archives/116/.
Developer Portfolio Details Sitemagic is an open-source project. The only thing the brand name applies to is the CMS, and it does not appear to be part of another open-source umbrella. The project is under active maintenance (i.e., it is not a dead project).
Technical Impact of Exploit An authenticated user can upload a .php file to execute arbitrary code with system privileges.
Scenario Blurb We are a small business that uses Sitemagic to help run our business. Sitemagic handles everything from digital marketing and site design to facilitating the e-commerce transactions of the website. We rely on this website heavily, even though we do have a brick-and-mortar store. Many times, products are not available in-store, but are available online, so we point many customers to our online store.
Deployer Mission We are a private company that must turn a profit to remain competitive. We want to provide customers with a valuable product at a reasonable price, while still turning a profit to run the business. As we are privately held (and not public), we are free to choose the best growth strategy (that is, we are not legally bound to demonstrate quarterly earnings for shareholders and can take a longer-term view if it makes us competitive).
Deployment of Affected System We have deployed this system such that only the web designer Cheryl and the IT admin Sally are allowed to access the CMS as users. They login through a password-protected portal that can be accessed anywhere in the world for remote administration. The CMS publishes content to the web, and that web server and site are publicly available.

This test structure produced a series of lists similar in form to the contents of Table 12. Analysts also noted how much time they spent on each vulnerability in each stakeholder group.

Table: Example Documentation of a Single Decision Point

Decision Point Branch Selected Supporting Evidence
Exploitation=active Controlled The CMS has a limited number of authorized users, and the vulnerability is exploitable only by an authenticated user

We evaluated inter-rater agreement in two stages. In the first stage, each analyst independently documented their decisions. This stage produced 18 sets of decisions (nine vulnerabilities across each of two stakeholder groups) per analyst. In the second stage, we met to discuss decision points where at least one analyst differed from the others. If any analyst changed their decision, they appended the information and evidence they gained during this meeting in the “supporting evidence” value in their documentation. No changes to decisions were forced, and prior decisions were not erased, just amended. After the second stage, we calculated some statistical measures of inter-rater agreement to help guide the analysis of problem areas.

To assess agreement, we calculate Fleiss’ kappa, both for the value in the leaf node reached for each case and every decision in a case 1. Evaluating individual decisions is complicated slightly because the different paths through the tree mean that a different number of analysts may have evaluated certain items, and Fleiss’ kappa requires a static number of raters. “Leaf node reached” is described to pick out the specific path through the tree the analyst selected and to treat that as a label holistically. Measuring agreement based on the path has the drawback that ostensibly similar paths (for example, paths that agree on 3 of 4 decisions) are treated as no more similar than paths that agree on 0 of 4 decisions. The two measures of agreement (per decision and per path) are complementary, so we report both.

Pilot participant details

The pilot participants are the five authors plus one analyst who had not seen the draft system before participating. Five of the six participants had spent at least one year as professional vulnerability analysts prior to the pilot (Spring was the exception). Three of the participants had at least ten years of experience each. The participants experience is primarily as coordinators at the CERT® Coordination Center. On the one hand, this is a different perspective than either suppliers or deployers; on the other, the coordinator role is an information broker that often interacts with these perspectives 2.

These participant demographics limit the generalizability of the results of the pilot. Even though the results cannot be systematically generalized to other analysts, there are at least three benefits to conducting the pilot among this limited demographic. First, it should surface any material tacit disagreements about term usage among the authors. Tacit agreements that are not explained in the text likely survive the pilot study without being acknowledged, but places where the authors tacitly disagreed should be surfaced. We found this to be the case; Improvement Instigated by the Pilot documents these results. Second, the pilot provides a case study that demonstrate SSVC is at least possible for some small group of analysts to use. This achievement is not large, but it is a first step. Third, the pilot provides a proof of concept method and metric that any vulnerability prioritization method could use to examine usability for analysts more generally. While the effect of education on vulnerability assessment with CVSS has been tested 3, we are not aware of any current vulnerability prioritization method that tests usability or agreement among analysts as part of the development process. Future work on SSVC as well as further development of other prioritization methods can benefit from using the method described in the pilot. Future instances should use more representative participant demographics.

Vulnerabilities used as examples

The vulnerabilities used as case studies are as follows. All quotes are from the National Vulnerability Database (NVD) and are illustrative of the vulnerability; however, during the study each vulnerability was evaluated according to information analogous to that in Table 11.

Safety-Critical Cases

  • CVE-2015-5374: “Vulnerability … in [Siemens] Firmware variant PROFINET IO for EN100 Ethernet module… Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device…”

  • CVE-2014-0751: “Directory traversal vulnerability in … GE Intelligent Platforms Proficy HMI/SCADA - CIMPLICITY before 8.2 SIM 24, and Proficy Process Systems with CIMPLICITY, allows remote attackers to execute arbitrary code via a crafted message to TCP port 10212, aka ZDI-CAN-1623.”

  • CVE-2015-1014: “A successful exploit of these vulnerabilities requires the local user to load a crafted DLL file in the system directory on servers running Schneider Electric OFS v3.5 with version v7.40 of SCADA Expert Vijeo Citect/CitectSCADA, OFS v3.5 with version v7.30 of Vijeo Citect/CitectSCADA, and OFS v3.5 with version v7.20 of Vijeo Citect/CitectSCADA. If the application attempts to open that file, the application could crash or allow the attacker to execute arbitrary code.”

Regulated Systems Cases

  • CVE-2018-14781: “Medtronic insulin pump [specific versions] when paired with a remote controller and having the “easy bolus” and “remote bolus” options enabled (non-default), are vulnerable to a capture-replay attack. An attacker can … cause an insulin (bolus) delivery.”

  • CVE-2017-9590: “The State Bank of Waterloo Mobile … app 3.0.2 … for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.”

  • CVE-2017-3183: “Sage XRT Treasury, version 3, fails to properly restrict database access to authorized users, which may enable any authenticated user to gain full access to privileged database functions. Sage XRT Treasury is a business finance management application. …”

General Computing Cases

  • CVE-2019-2691: “Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Security: Roles). Supported versions that are affected are 8.0.15 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to … complete DoS of MySQL Server.”

  • CVE-2019-9042: “[I]n Sitemagic CMS v4.4… the user can upload a .php file to execute arbitrary code, as demonstrated by 404.php. This can only occur if the administrator neglects to set FileExtensionFilter and there are untrusted user accounts. …”

  • CVE-2017-5638: “The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via crafted [specific headers], as exploited in the wild in March 2017…”

Pilot Results

For each of the nine CVEs, six analysts rated the priority of the vulnerability as both a supplier and deployer. Table 13 summarizes the results by reporting the inter-rater agreement for each decision point. For all measures, agreement (k) is above zero, which is generally interpreted as some agreement among analysts. Below zero is interpreted as noise or discord. Closer to 1 indicates more or stronger agreement.

How close k should be to 1 before agreement can be considered strong enough or reliable enough is a matter of some debate. The value certainly depends on the number of options among which analysts select. For those decision points with five options (mission and safety impact), agreement is lowest. Although portfolio value has a higher k than mission or safety impact, it may not actually have higher agreement because portfolio value only has two options. The results for portfolio value are nearly indistinguishable as far as level of statistical agreement from mission impact and safety impact. The statistical community does not have hard and fast rules for cut lines on adequate agreement. We treat k as a descriptive statistic rather than a test statistic.

Table 13 is encouraging, though not conclusive. k\<0 is a strong sign of discordance. Although it is unclear how close to 1 is success, k\<0 would be clear sign of failure. In some ways, these results may be undercounting the agreement for SSVC as presented. These results are for SSVC prior to the improvements documented in Improvement Instigated by the Pilot, which are implemented in SSVC version 1. On the other hand, the participant demographics may inflate the inter-rater agreement based on shared tacit understanding through the process of authorship. The one participant who was not an author surfaced two places where this was the case, but we expect the organizational homogeneity of the participants has inflated the agreement somewhat. The anecdotal feedback from vulnerability managers at several organizations (including VMware 4 and McAfee) is about refinement and tweaks, not gross disagreement. Therefore, while further refinement is necessary, this evidence suggests the results have some transferability to other organizations and are not a total artifact of the participant organization demographics.

Table: Inter-Rater Agreement for Decision Points

Safety Impact Exploitation Technical Impact Portfolio Value Mission Impact Exposure Dev Result Deployer Result
Fleiss’ k 0.122 0.807 0.679 0.257 0.146 0.480 0.226 0.295
Disagreement range 2,4 1,2 1,1 1,1 2,4 1,2 1,3 2,3

For all decision points, the presumed goal is for k to be close or equal to 1. The statistics literature has identified some limited cases in which Fleiss’ k behaves strangely—for example it is lower than expected when raters are split between 2 of q ratings when q>2 5. This paradox may apply to the safety and mission impact values, in particular. The paradox would bite hardest if the rating for each vulnerability was clustered on the same two values, for example, minor and major. Falotico and Quatto’s proposed solution is to permute the columns, which is safe with unordered categorical data. Since the nine vulnerabilities do not have the same answers as each other (that is, the answers are not clustered on the same two values), we happen to avoid the worst of this paradox, but the results for safety impact and mission impact should be interpreted with some care.

This solution identifies another difficulty of Fleiss’ kappa, namely that it does not preserve any order; none and catastrophic are considered the same level of disagreement as none and minor. Table 13 displays a sense of the range of disagreement to complement this weakness. This value is the largest distance between rater selections on a single vulnerability out of the maximum possible distance. So, for safety impact, the most two raters disagreed was by two steps (none to major, minor to hazardous, or major to catastrophic) out of the four possible steps (none to catastrophic). The only values of k that are reliably comparable are those with the same number of options (that is, the same maximum distance). In other cases, closer to 1 is better, but how close is close enough to be considered “good” changes. In all but one case, if raters differed by two steps then there were raters who selected the central option between them. The exception was mission impact for CVE-201814781; it is unclear whether this discrepancy should be localized to a poor test scenario description, or to SSVC’s mission impact definition. Given it is an isolated occurrence, we expect the scenario description at least partly.

Nonetheless, k provides some way to measure improvement on this a conceptual engineering task. The pilot evaluation can be repeated, with more diverse groups of stakeholders after the descriptions have been refined by stakeholder input, to measure fit to this goal. For a standard to be reliably applied across different analyst backgrounds, skill sets, and cultures, a set of decision point descriptions should ideally achieve k of 1 for each item in multiple studies with diverse participants. Such a high level of agreement would be difficult to achieve, but it would ensure that when two analysts assign a priority with the system that they get the same answer. Such agreement is not the norm with CVSS currently 3.

Table: SSVC pilot scores compared with the CVSS base scores for the vulnerabilities provided by NVD.

CVE-ID Representative SSVC decision values SSVC recommendation (supplier, deployer) NVD’s CVSS base score
CVE-2014-0751 E:N/T:T/U:L/S:H/X:C/M:C (Sched, OOC) 7.5 (High) (v2)
CVE-2015-1014 E:N/T:T/U:L/S:J/X:S/M:F (Sched, Sched) 7.3 (High) (v3.0)
CVE-2015-5374 E:A/T:P/U:L/S:H/X:C/M:F (Immed, Immed) 7.8 (High) (v2)
CVE-2017-3183 E:N/T:T/U:E/S:M/X:C/M:C (Sched, Sched) 8.8 (High) (v3.0)
CVE-2017-5638 E:A/T:T/U:S/S:M/X:U/M:C (Immed, OOC) 10.0 (Critical) (v3.0)
CVE-2017-9590 E:P/T:T/U:E/S:M/X:U/M:D (OOC, Sched) 5.9 (Medium) (v3.0)
CVE-2018-14781 E:P/T:P/U:L/S:H/X:C/M:F (OOC, OOC) 5.3 (Medium) (v3.0)
CVE-2019-2691 E:N/T:P/U:E/S:M/X:C/M:C (Sched, Sched) 4.9 (Medium) (v3.0)
CVE-2019-9042 E:A/T:T/U:L/S:N/X:C/M:C (OOC, Sched) 7.2 (High) (v3.0)

Table 14 presents the mode decision point value for each vulnerability tested, as well as the recommendation that would result from that set based on the recommended decision trees in SSVC version 1. The comparison with the NVD’s CVSS base scores mostly confirms that SSVC is prioritizing based on different criteria, as designed. In particular, differences in the state of exploitation and safety impact are suggestive.

Based on these results, we made about ten changes, some bigger than others. We did not execute a new rater agreement experiment with the updated descriptions. The pilot results are encouraging, and we believe it is time to open up a wider community discussion.

Improvements Instigated by the Pilot

The following changes were reflected in the version 1 Section "Decision Trees for Vulnerability Management."

  • Technical impact: We clarified that partial/total is decided regarding the system scope definition, which considers a database or a web server program as the “whole” system. Furthermore, “total” also includes any technical impact that exposes authentication credentials to the adversary, if those credentials are to the whole system.

  • We added advice for information gathering to answer safety impact and mission impact questions. This change is needed because of the particularly wide variety of background assumptions analysts made that influenced results and agreement.

  • We clarified that “MEF failure” refers to any one essential function failing, not failure of all of them. We changed most severe mission impact to “mission failure” to better reflect the relationship between MEFs and the organization’s mission.

  • We removed the “supplier portfolio value” question since it had poor agreement, and there is no clear way to correct it. We replaced this question with Utility, which better captures the relevant kinds of value (namely, to the adversary) of the affected component while remaining amenable to pragmatic analysis.

  • We clarified that “proof of concept” (see Exploitation) includes cases in which existing tooling counts as a PoC. The examples listed are suggestive, not exhaustive.

  • We reorganized the decision trees based on which items are easier to gather information for or which ones have a widely verifiable state. This change moved exploitation to the first question.

  • We changed the decision tree results such that if exposure is “small,” then the resulting priority is lower than before the pilot study. That is, “small” exposure has a stronger effect on reducing urgency.

Questions Removed as Ineffective

In this section, we present ideas we tried but rejected for various reasons. We are not presenting this section as the final word on excluding these ideas, but we hope the reasons for excluding them are instructive, will help prevent others from re-inventing the proverbial wheel, and can guide thinking on future work.

Initially, we brainstormed approximately 12 potential decision points, most of which we removed early in our development process through informal testing. These decision points included adversary’s strategic benefit of exploiting the vulnerability, state of legal or regulatory obligations, cost of developing remediation, patch distribution readiness, financial losses to customers due to potential exploitation, and business losses to the deployer.

Some of these points left marks on other decision points. The decision point “financial losses of customers” led to an amendment of the definition of Safety to include “well-being,” such that, for example, bankruptcies of third parties are now a major safety impact. The “business losses to the deployer” decision point is covered as a mission impact insofar as profit is a mission of publicly traded corporations.

Three of the above decision points left no trace on the current system. “State of legal or regulatory obligations,” “cost of developing remediation,” and “patch distribution readiness” were dropped as either being too vaguely defined, too high level, or otherwise not within the scope of decisions by the defined stakeholders. The remaining decision point, “adversary’s strategic benefit of exploiting the vulnerability,” transmuted to a different sense of system value. In an attempt to be more concrete and not speculate about adversary motives, we considered a different sense of value: supplier portfolio value.

The only decision point that we have removed following the pilot is developer portfolio value. This notion of value was essentially an over-correction to the flaws identified in the “adversary’s strategic benefit of exploiting the vulnerability” decision point. “Supplier portfolio value” was defined as “the value of the affected component as a part of the developer’s product portfolio. Value is some combination of importance of a given piece of software, number of deployed instances of the software, and how many people rely on each. The developer may also include lifecycle stage (early development, stable release, decommissioning, etc.) as an aspect of value.” It had two possible values: low and high. As Table 13 demonstrates, there was relatively little agreement among the six analysts about how to evaluate this decision point. We replaced this sense of portfolio value with Utility, which combines Value Density and Automatability.

  1. Joseph L Fleiss and Jacob Cohen. The equivalence of weighted kappa and the intraclass correlation coefficient as measures of reliability. Educational and psychological measurement, 33(3):613–619, 1973. ↩

  2. Allen D Householder, Garret Wassermann, Art Manion, and Christopher King. The CERT® guide to coordinated vulnerability disclosure. Technical Report CMU/SEI-2017-TR-022, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2020. URL: https://vuls.cert.org/confluence/display/CVD/Executive+Summary. ↩

  3. Luca Allodi, Marco Cremonini, Fabio Massacci, and Woohyun Shim. The effect of security education and expertise on security assessments: the case of software vulnerabilities. In Workshop on Economics of Information Security. Innsbruck, Austria, 2018. ↩↩

  4. Muhammad Akbar. A critical first look at stakeholder specific vulnerability categorization (ssvc). 2020. URL: https://blog.secursive.com/posts/critical-look-stakeholder-specific-vulnerability-categorization-ssvc/ (visited on 2020-06-20). ↩

  5. Rosa Falotico and Piero Quatto. Fleiss' kappa statistic without paradoxes. Quality & Quantity, 49(2):463–470, 2015. ↩

Related Vulnerability Management Systems

There are several other bodies of work that are used in practice to assist vulnerability managers in making decisions. Three relevant systems are CVSS 1, EPSS 2, and Tenable's Vulnerability Priority Rating (VPR). There are other systems derived from CVSS, such as RVSS for robots 3 and MITRE's effort to adapt CVSS to medical devices 4. There are also other nascent efforts to automate aspects of the decision making process, such as vPrioritizer. This section discusses the relationship between these various systems and SSVC.

CVSS version 3.1 has three metric groups: base, environmental, and temporal. The metrics in the base group are all required, and are the only required metrics. In connection with this design, CVSS base scores and base metrics are far and away the most commonly used and communicated. A CVSS base score has two parts: the exploitability metrics and the impact metrics. Each of these are echoed or reflected in aspects of SSVC, though the breadth of topics considered by SSVC is wider than CVSS version 3.1.

How CVSS is used matters. Using just the base scores, which are “the intrinsic characteristics of a vulnerability that are constant over time and across user environments,” as a stand-alone prioritization method is not recommended 1. Two examples of this include the U.S. government 567 and the global payment card industry 8 where both have defined such misuse as expected practice in their vulnerability management requirements. CVSS scores have a complex relationship with patch deployment in situations where it is not mandated, at least in an ICS context 9.

CVSS has struggled to adapt to other stakeholder contexts. Various stakeholder groups have expressed dissatisfaction by making new versions of CVSS, such as medical devices 4, robotics 3, and industrial systems 10. In these three examples, the modifications tend to add complexity to CVSS by adding metrics. Product vendors have varying degrees of adaptation of CVSS for development prioritization, including but not limited to Red Hat, Microsoft, and Cisco. The vendors codify CVSS’s recommended qualitative severity rankings in different ways, and Red Hat and Microsoft make the user interaction base metric more important.

Exploitability metrics (Base metric group)

The four metrics in this group are Attack Vector, Attack Complexity, Privileges Required, and User Interaction. This considerations may likely be involved in the Automatability decision point. If Attack Vector = Network and Privileges Required = None, then the delivery phase of the kill chain is likely to be automatable. Attack Vector may also be correlated with the Exposure decision point. Attack Complexity may influence how long it may take an adversary to craft an automated exploit, but Automatability only asks whether exploitation can be automated, not how difficult it was. However, Attack Complexity may influence the weaponization phase of the kill chain. User Interaction does not cleanly map to a decision point. In general, SSVC does not care whether a human is involved in exploitation of the vulnerability or not. Some human interaction is for all intents and purposes automatable by attackers: most people click on links in emails as part of their normal processes. In most such situations, user interaction does not present a firm barrier to automatability; it presents a stochastic barrier. Automatability is written to just consider firm barriers to automation.

Automatability includes considerations that are not included in the exploitability metrics. Most notably the concept of vulnerability chaining is addressed in Automatability but not addressed anywhere in CVSS. Automatability is also outcomes focused. A vulnerability is evaluated based on an observable outcome of whether the first four steps of the kill chain can be automated for it. A proof of automation in a relevant environment is an objective evaluation of the score in a way that cannot be provided for some CVSS elements, such as Attack Complexity.

Impact metrics (Base metric group)

The metrics in this group are Confidentiality, Integrity, and Availability. There is also a loosely associated Scope metric. The CIA impact metrics are directly handled by Technical Impact.

Scope is a difficult CVSS metric to categorize. The specification describes it as “whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope” 1. This is a fuzzy concept. SSVC better describes this concept by breaking it down into component parts. The impact of exploitation of the vulnerable component on other components is covered under Mission Impact, public and situated Well-being Impact, and the stakeholder-specific nature where SSVC is tailored to stakeholder concerns. CVSS addresses some definitions of the scope of CVSS as a whole under the Scope metric definition. In SSVC, these definitions are in the Scope section.

Temporal metric groups

The temporal metric group primarily contains the Exploit Code Maturity metric. This metric expresses a concept similar to Exploitation. The main difference is that Exploitation is not optional in SSVC and that SSVC accounts for the observation that most vulnerabilities with CVE-IDs do not have public exploit code 11 and are not actively exploited 122.

Environmental metric group

The environmental metric group allows a consumer of a CVSS base score to change it based on their environment. CVSS needs this functionality because the organizations that produce CVSS scores tend to be what SSVC calls suppliers and consumers of CVSS scores are what SSVC calls deployers. These two stakeholder groups have a variety of natural differences, which is why SSVC treats them separately. SSVC does not have such customization as a bolt-on optional metric group because SSVC is stakeholder-specific by design.

The Exploit Prediction Scoring System (EPSS) is “a data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild.” EPSS is currently based on a machine-learning classifier and proprietary data from Fortiguard, Alienvault OTX, the Shadowserver Foundation and GreyNoise. While the group has made an effort to make the ML classifier transparent, ML classifiers are not able to provide an intelligible, human-accessible explanation for their behavior 13. The use of proprietary training data makes the system less transparent.

EPSS could be used to inform the Exploitation decision point. Currently, Exploitation focuses on the observable state of the world at the time of the SSVC decision. EPSS is about predicting if a transition will occur from the SSVC state of none to active. A sufficiently high EPSS score could therefore be used as an additional criterion for scoring a vulnerability as active even when there is no observed active exploitation.

VPR is a prioritization product sold by Tenable. VPR determines the severity level of a vulnerability based on “technical impact and threat.” Just as Technical Impact in SSVC, technical impact in VPR tracks the CVSS version 3 impact metrics in the base metric group. The VPR threat component is about recent and future threat activity; it is comparable to Exploitation if EPSS were added to Exploitation.

VPR is therefore essentially a subset of SSVC. VPR is stylistically methodologically quite different from SSVC. VPR is based on machine learning models and proprietary data, so the results are totally opaque. There is no ability to coherently and transparently customize the VPR system. Such customization is a central feature of SSVC, as described in Tree Construction and Customization Guidance.

Attempts to tailor CVSS to specific stakeholder groups, such as robotics or medical devices, are are perhaps the biggest single reason we created SSVC. CVSS is one-size-fits-all by design. These customization efforts struggle with adapting CVSS because it was not designed to be adaptable to different stakeholder considerations. The SSVC section Tree Construction and Customization Guidance explains how stakeholders or stakeholder communities can adapt SSVC in a reliable way that still promotes repeatability and communication.

vPrioritizer is an open-source project that attempts to integrate asset management and vulnerablity prioritization. The software is mostly the asset management aspects. It currently includes CVSS base scores as the de facto vulnerability prioritization method; however, fundamentally the system is agnostic to prioritization method. vPrioritizer is an example of a product that is closely associated with vulnerability prioritization, but is not directly about the prioritization method. In that sense, it is compatible with any of methods mentioned above or SSVC. However, SSVC would be better suited to address vPrioritizer's broad spectrum asset management data. For example, vPrioritizer aims to collect data points on topics such as asset significance. Asset significance could be expressed through the SSVC decision points of Mission Impact and situated Well-being Impact, but it does not have a ready expression in CVSS, EPSS, or VPR.

SSVC using Current Information Sources

Some SSVC decision points can be informed or answered by currently available information feeds or sources. These include

This section provides an overview of some options; we cannot claim it is exhaustive. Each decision point has a subsection for Gathering Information About it. These sections provide suggestions that would also contribute to creating or honing information feeds. However, if there is a category of information source we have not captured, please create an issue on the SSVC GitHub page explaining it and what decision point it informs.

Exploitation

Various vendors provide paid feeds of vulnerabilities that are currently exploited by attacker groups. Any of these could be used to indicate that active is true for a vulnerability. Although the lists are all different, we expect they are all valid information sources; the difficulty is matching a list's scope and vantage with a compatible scope and vantage of the consumer. We are not aware of a comparative study of the different lists of active exploits; however, we expect they have similar properties to block lists of network touchpoints 1 and malware 2. Namely, each list has a different view and vantage on the problem, which makes them appear to be different, but each list accurately represents its particular vantage at a point in time.

System Exposure

System Exposure could be informed by the various scanning platforms such as Shodan and Shadowserver. A service on a device should be scored as open if such a general purpose Internet scan finds that the service responds. Such scans do not find all open systems, but any system they find should be considered open. Scanning software, such as the open-source tool Nessus, could be used to scan for connectivity inside an organization to catalogue what devices should be scored controlled if, say, the scan finds them on an internal network where devices regularly connect to the Internet.

Adapting other Information Sources

Some information sources that were not designed with SSVC in mind can be adapted to work with it. Three prominent examples are CVSS impact base metrics, CWE, and CPE.

CVSS and Technical Impact

Technical Impact is directly related to the CVSS impact metric group. However, this metric group cannot be directly mapped to Technical Impact in CVSS version 3 because of the Scope metric. Technical Impact is only about adversary control of the vulnerable component. If the CVSS version 3 value of “Scope” is “Changed,” then the impact metrics are the maximum of the impact on the vulnerable component and other components in the environment. If confidentiality, integrity, and availability metrics are all “high” then Technical Impact is total, as long as the impact metrics in CVSS are clearly about just the vulnerable component. However, the other values of the CVSS version 3 impact metrics cannot be mapped directly to partial because of CVSS version 3.1 scoring guidance. Namely, “only the increase in access, privileges gained, or other negative outcome as a result of successful exploitation should be considered” 3. The example given is that if an attacker already has read access, but gains all other access through the exploit, then read access didn't change and the confidentiality metric score should be “None” . However, in this case, SSVC would expect the decision point to be evaluated as total because as a result of the exploit the attacker gains total control of the device, even though they started with partial control.

CWE and Exploitation

As mentioned in the discussion of Exploitation, CWE could be used to inform one of the conditions that satisfy proof of concept. For some classes of vulnerabilities, the proof of concept is well known because the method of exploitation is already part of open-source tools. For example, on-path attacker scenarios for intercepting TLS certificates. These scenarios are a cluster of related vulnerabilities. Since CWE classifies clusters of related vulnerabilities, the community could likely curate a list of CWE-IDs for which this condition of well known exploit technique is satisfied. Once that list were curated, it could be used to automatically populate a CVE-ID as proof of concept if the CWE-ID of which it is an instance is on the list. Such a check could not be exhaustive, since there are other conditions that satisfy proof of concept. If paired with automatic searches for exploit code in public repositories, these checks would cover many scenarios. If paired with active exploitation feeds discussed above, then the value of Exploitation could be determined almost entirely from available information without direct analyst involvement at each organization.

CPE and Safety Impact

CPE could possibly be curated into a list of representative Public Safety Impact values for each platform or product. The Situated Safety Impact would be too specific for a classification as broad as CPE. But it might work for Public Safety Impact, since it is concerned with a more general assessment of usual use of a component. Creating a mapping between CPE and Public Safety Impact could be a community effort to associate a value with each CPE entry, or an organization might label a fragment of the CPE data with Public Safety Impact based on the platforms that the supplier needs information about most often.

Potential Future Information Feeds

So far, we have identified information sources that can support scalable decision making for most decision points. Some sources, such as CWE or existing asset management solutions, would require a little bit of connective glue to support SSVC, but not too much.

Automatable and Value Density

The SSVC decision point that we have not identified an information source for is Utility. Utility is composed of Automatable and Value Density, so the question is what a sort of feed could support each of those decision points.

A feed is plausible for both of these decision points. The values for Automatable and Value Density are both about the relationship between a vulnerability, the attacker community, and the aggregate state of systems connected to the Internet. While that is a broad analysis frame, it means that any community that shares a similar set of adversaries and a similar region of the Internet can share the same response to both decision points. An organization in the People's Republic of China may have a different view than an organization in the United States, but most organizations within each region should should have close enough to the same view to share values for Automatable and Value Density. These factors suggest a market for an information feed about these decision points is a viable possibility.

At this point, it is not clear that an algorithm or search process could be designed to automate scoring Automatable and Value Density. It would be a complex natural language processing task. Perhaps a machine learning system could be designed to suggest values. But more likely, if there is a market for this information, a few analysts could be paid to score vulnerabilities on these values for the community. Supporting such analysts with further automation could proceed by small incremental improvements. For example, perhaps information about whether the Reconnaissance step in the kill chain is Automatable or not could be automatically gathered from Internet scanning firms such as Shodan or Shadowserver. This wouldn't make a determination for an analyst, but would be a step towards automatic assessment of the decision point.

  1. Leigh B Metcalf and Jonathan M Spring. Blacklist ecosystem analysis: spanning Jan 2012 to Jun 2014. In Workshop on Information Sharing and Collaborative Security, 13–22. Denver, 2015. ACM. ↩

  2. Marc Kührer, Christian Rossow, and Thorsten Holz. Paint it black: evaluating the effectiveness of malware blacklists. In Recent Advances in Intrusion Detection, number 8688 in LNCS, 1–21. Gothenburg, Sweden, 2014. Springer. ↩

  3. CVSS SIG. Common vulnerability scoring system. Technical Report version 3.1 r1, Forum of Incident Response and Security Teams, Cary, NC, USA, 2019. URL: https://www.first.org/cvss/v3.1/specification-document. ↩

Limitations

SSVC has some inherent limits in its approach, which should be understood as tradeoffs. There are other limiting aspects of our implementation, but those have been covered as topics that need improvement and are described in Future Work.

We made two important tradeoffs compared to the current state of the practice. Other systems make different tradeoffs, which may be better or worse depending on the context of use. While these are inherently limitations of SSVC, we do not intend SSVC to be the one and only vulnerability management tool available. Those for whom these limitations are a must-have may be better supported by a different vulnerability management framework.

Eliminated Numerical Scores

We eliminated numerical scores; this may make some practitioners uncomfortable. We explained the reasons for this in depth, but even though CVSS contains false precision, we still must contend with the fact that, psychologically, users find that comforting. As this comfort gap may negatively impact adoption, this fact is a limitation. Although it is ungainly, it would be sound to convert the priority outcomes to numbers at the end of the process, if existing processes require it. Which numbers we choose to convert to is immaterial, as long as the ordering is preserved. CVSS has set a precedent that higher numbers are worse, so a scale [1, 2, 3, 4] would work, with defer = 1 and immediate = 4. However, if it were important to maintain backwards compatibility to the CVSS range zero to ten, we could just as well relabel outcomes as [2, 5.5, 8, 9.5] for the midpoints of the current CVSS severity ranges. This is not a calculation of any kind, just an assignment of a label which may make adoption more convenient. Of course, these labels are dangerous, as they may be misused as numbers. Therefore, we prefer the use defer, scheduled, etc., as listed in Enumerating Vulnerability Management Actions.

Expanded Context

We incorporated a wider variety of inputs from contexts beyond the affected component. Some organizations are not prepared or configured to reliably produce such data (e.g., around mission impact or safety impact). There is adequate guidance for how to elicit and curate this type information from various risk management frameworks, including OCTAVE 1. Not every organization is going to have sufficiently mature risk management functions to apply SSVC.\

This second limitation should be approached with two strategies:

  1. Organizations should be encouraged and enabled to mature their risk management capabilities
  2. In the meantime, organizations such as NIST could consider developing default advice. The most practical framing of this approach might be for the NIST NVD to produce scores from the perspective of a new stakeholder—something like “national security” or “public well-being” that is explicitly a sort of default advice for otherwise uninformed organizations that can then explicitly account for national priorities, such as critical infrastructure.

  1. Richard Caralli, James Stevens, Lisa Young, and William Wilson. Introducing OCTAVE allegro: improving the information security risk assessment process. Technical Report CMU/SEI-2007-TR-012, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2007. URL: https://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=8419. ↩

Future Work

We intend SSVC to offer a workable baseline from which to improve and refine a vulnerability-prioritization methodology. We are working to improve SSVC. Several of the future work items in this section have issues associated with them on the SSVC GitHub page (https://github.com/CERTCC/SSVC/issues), which is a good place to go to check on progress or help. Plans for future work focus on further requirements gathering, analysis of types of risk, and further testing of the reliability of the decision process.

Requirements Gathering via Sociological Research

The community should know what users of a vulnerability prioritization system want. To explore their needs, it is important to understand how people actually use CVSS and what they think it tells them. In general, such empirical, grounded evidence about what practitioners and decision makers want from vulnerability scoring is lacking. We have based this paper’s methodology on multiple decades of professional experience and myriad informal conversations with practitioners. Such evidence is not a bad place to start, but it does not lend itself to examination and validation by others. The purpose of understanding practitioner expectations is to inform what a vulnerability-prioritization methodology should actually provide by matching it to what people want or expect. The method this future work should take is long-form, structured interviews. We do not expect anyone to have access to enough consumers of CVSS to get statistically valid results out of a short survey, nor to pilot a long survey.

Coordinators in particular are likely to be heterogeneous. While the FIRST service frameworks for PSIRTs and CSIRTs differentiate two broad classes of coordinators, we have focused on CSIRTs here. PSIRTs may have somewhat different concerns. Investigating the extent to which SSVC should be customized for this group is future work as well.

Types of Risks

SSVC estimates the relative risk created by a vulnerability in an information system. The priority of acting to mitigate or remediate a vulnerability goes up as this vulnerability risk goes up. SSVC does not currently take into account the change risk due to applying a mitigation or remediation.

One way to view what SSVC currently provides is that it tells you how urgently a stakeholder should analyze overall risk due to a vulnerability. For all but the most dire vulnerabilities, what the stakeholder chooses to do may include accepting the vulnerability risk because the change risk or other costs of mitigation or remediation are too high. Future work should attempt to provide a method for evaluating change risk or cost relative to vulnerability risk.

Tree Construction and Customization Guidance discusses how the prioritization labels in an SSVC tree reflect risk appetite or risk tolerance. Specifically, these reflect vulnerability risk appetite. Appetite for vulnerability risk may be negatively correlated with change risk; future work could explore this relationship. Furthermore, future work could examine suggested practices for connecting tree customization to risk management.

Reasoning Steps Forward states the scope of SSVC analysis is “consider credible effects based on known use cases of the software system as a part of cyber-physical systems.” The unit of prioritization in SSVC should be work items. For deployers, a work item is often applying a patch that addresses multiple vulnerabilities. The “credible effects” to consider are those of all vulnerabilities remediated by the patch. How exactly to aggregate these different effects is not currently specified except to say that the unit of analysis is the whole work item. Future work should provide some examples of how this holistic analysis of multiple vulnerabilities remediated in one patch should be conducted.

Further Decision Tree Testing

More testing with diverse analysts is necessary before the decision trees are reliable. In this context, reliable means that two analysts, given the same vulnerability description and decision process description, will reach the same decision. Such reliability is important if scores and priorities are going to be useful. If they are not reliable, they will vary widely over time and among analysts. Such variability makes it impossible to tell whether a difference in scores is really due to one vulnerability being higher priority than other.

The SSVC version 1 pilot study provides a methodology for measuring and evaluating reliability of the decision process description based on the agreement measure k. This study methodology should be repeated with different analyst groups, from different sectors and with different experience, using the results to make changes in the decision process description until the agreement measure is adequately close to 1.

Internationalization and localization of SSVC will also need to be considered and tested in future work. It is not clear how best to consider translating SSVC decision points, if at all. An actionable item of future work would be to include non-native English speakers in future usability studies.

A different approach to testing the Utility decision point could be based on the Alternative Utility Outputs found in that page. Namely, future work could example exploit resale markets and compare the value of exploits to the Utility score of the exploited vulnerability. There are some limitations to this approach, since exploit markets target certain adversary groups (such as those with lots of resources) and may not be representative of all adversary types. However, such analysis would provide some information as to whether the definition of Utility is reasonable.

Ended: Understanding SSVC

SSVC How-To ↵

Using SSVC

Prerequisites

The Using SSVC section assumes that you have

  • An interest in using SSVC in a vulnerability management process
  • Basic familiarity with SSVC

If you are unfamiliar with SSVC, we suggest you start with the Understanding SSVC section, which provides necessary background detail. For technical reference, see Reference.

Given a specific stakeholder decision and set of useful decision points, we are now in a position to combine them into a comprehensive set of decisions about the priority with which to act. The definition of choices can take a logical form, such as:

This example logical statement is captured in line 35 of the deployer .csv file.

There are different formats for capturing these prioritization decisions depending on how and where they are going to be used. In this documentation, we primarily represent a full set of guidance on how one stakeholder will make a decision as a decision tree.

This section presents example trees for various stakeholders, followed by guidance on how to adapt and customize SSVC to fit your organization's needs.

Bootstrapping an SSVC Process from Scratch

Using SSVC to prioritize vulnerability response requires a few steps. The steps are:

Bootstrapping SSVC Overview

flowchart
    start([Start])
    prep[Prepare to use SSVC]
    dataops[Data Operations]
    runtime[Use SSVC]
    r[Vulnerability Response]
    start --> prep
    prep --> dataops
    dataops --> runtime
    runtime --> r
    r --> dataops
Step Description
Prepare Define the decision you want to make, the outcomes you care about, the decision points you will use to make the decision, the decision policy, and the data you need to inform the decision points.
Collect Collect the data you need to make informed decisions.
Use SSVC Use SSVC to make decisions about how to respond to vulnerabilities.
Respond Respond to vulnerabilities according to the prioritization.

We cover each of these in the following sections, starting with Prepare to Use SSVC. If you want to skip ahead to the full process, see Bootstrapping SSVC Summary.

Prepare to Use SSVC

Preparing to use SSVC involves defining a decision you want to make, the information you need to make that decision, and the policy you want to use to make that decision.

Here is a diagram of the preparation process:

flowchart
    subgraph prep [Prepare to use SSVC]
        dcd{{Choose Decision to Model}}
        outcomes[Define Outcomes]
        decisionpoints[Define Inputs]
        dataeng[Data Mapping]
        dm[/Data Map/]
        policy[Policy Development]
        p[/Policy/]        
    end
    dcd --> outcomes
    outcomes --> decisionpoints
    dcd --> decisionpoints
    decisionpoints --> dataeng
    outcomes --> policy
    decisionpoints --> policy
    policy --> p
    dataeng --> dm

We will go through each step in detail.

Choose a Decision to Model

Example

Decisions we have modeled with SSVC include:

The first step in preparing to use SSVC is to choose a decision to model. SSVC is designed to help you make decisions about how to respond to a vulnerability. In the SSVC documentation, we provide a number of example decisions that you might want to make. You can use one of these decisions, or you can define your own decision.


flowchart LR
    subgraph dd[Choose Decision]
        dcd{{Choose Decision to Model}}
        d[/Decision/]
    end
    dcd --> d

Define Outcomes

Example

In the Patch Supplier and Patch Deployer prioritization examples, the outcomes are: Defer, Scheduled, Out-of-Cycle, and Immediate. In the Coordinator Triage example, the outcomes are Coordinate, Track, and Decline. In the Coordinator Publication example, the outcomes are Publish and Do Not Publish.

Once you have chosen a decision to model, you need to define the outcomes for that decision. An outcome is the result of making a decision. Outcomes are often tailored specifically to the stakeholder context in which the decision is being made. We call the set of possible outcomes for a decision an outcome set.

We have provided a number of example outcome sets in the SSVC documentation, but you can define your own outcome set to meet your needs.

flowchart LR
    subgraph dd[Choose Decision]
    d[/Decision/]
    end
    subgraph outcomes [Define Outcomes]
        oc1[/Use available<br/>outcome sets?\]
        dos{{Define Outcome Sets}}
        oss[\Outcome Sets/]
        cos{{Choose Outcome Set}}
        os[/Outcome Set/]
    end
    d --> oc1
    oc1 -->|y| oss
    oc1 -->|n| dos
    dos --> oss
    cos --> os
    oss --> cos

Example

Imagine two different Service Providers, each of which is responsible for managing vulnerabilities in their respective environments. One Service Provider might use a 5-tier incident response model, and so might define their outcome set as: Severity 1, Severity 2, Severity 3, Severity 4, and Severity 5. Another Service Provider might only have three tiers, and so might define their outcome set as: High, Medium, and Low. So even though both Service Providers are making the same prioritization decision about their response to the same, vulnerability, they can use different outcome sets.

Define Inputs

Once you know what decision you want to make and what the possible outcomes are, you need to define the information you need to make that decision. A decision usually requires more than one piece of information. SSVC organizes this information into decision points. A single decision point enumerates a set of options for a particular aspect of the decision. We have defined a number of decision points in the SSVC documentation. You can choose from these decision points, or you can define your own decision points to meet your needs.

Whether you choose from the existing decision points or define your own, the set of decision points you use to make a decision is called a Decision Point Set.

flowchart LR
    subgraph dd[Choose Decision]
    d[/Decision/]
    end
    subgraph do[Define Outcomes]
    oc[/Outcome Set/]
    end

    subgraph decisionpoints [Define Inputs]
        dp1[/Use available<br/>decision points?\]
        ddp{{Define Decision Points}}
        dpt[\Decision Points/]
        cdp{{Choose Decision Points}}
        dps[/Decision Point Set/]
    end
    oc --> dp1
    d --> dp1

    dp1 -->|y| dpt
    dp1 -->|n| ddp
    ddp --> dpt
    dpt --> cdp
    cdp --> dps

Example

A medical device manufacturer has specific regulatory requirements for how they respond to vulnerabilities. As an organization, they have divided their product line into three categories: regulated devices, non-regulated devices, and support services. Vulnerability reports for regulated devices are handled differently than vulnerability reports for non-regulated devices. Also, vulnerability reports for support services are handled differently than vulnerability reports for devices of any kind because support services are covered by medical privacy regulations in addition to device safety regulations. So, the medical device manufacturer might define a decision point called Regulated with the values Regulated Device, Non-Regulated Device, and Support Service.

Define Policy

So far, you have chosen a decision to model, defined the possible outcomes for that decision, and defined the information you need to make that decision. Now, you need to define the policy you want to use to make that decision. A policy is a function that takes a set of decision point values as input and returns an outcome as output. While we often choose to represent policies as decision trees, they can be represented in other ways as well. In fact, we find that it is often useful to represent policies in tabular form, for example as a CSV file. We have provided a number of example policies in the SSVC documentation, but you can define your own policy to meet your needs.

flowchart LR
    subgraph do[Define Outcomes]
    oc[/Outcome Set/]
    end
    subgraph di [Define Inputs]
    dps[/Decision Point Set/]
    end
    subgraph policy [Policy Development]
        dfp{{Define Policy}}
        p[/Policy/]
    end
    oc --> dfp
    dps --> dfp
    dfp --> p

Example

A small bank has a policy that they must deploy patches within 48 hours of release if the vulnerability affects systems that could lead to customer data being exposed. They examine the example Deployer Prioritization decision model and decide that both the outcome set and the decision point set that define the structure of the decision model are appropriate for their needs. They map the 48 hour requirement to the Immediate outcome, because it essentially represents their highest priority response. However, they notice that the specific policy given in the Deployer Prioritization example—that is, the mapping from decision point values to outcomes—is not appropriate for their needs because it has too few Immediate outcomes to suit their policy. Therefore, the bank decides to reuse the same decision point set and outcome set but define their own policy.

Data Mapping

In SSVC, data mapping is the process of defining what data can be used to assign a value to each decision point. The resulting data map indicates which data sources are relevant to each decision point, and how to interpret the data from each data source to assign a value to the decision point.

flowchart LR
    subgraph di[Define Inputs]
        dps[/Decision Point Set/]
    end
    subgraph dataeng [Data Mapping]
        dd1[/Use existing data?\]
        dpm[/Data Map/]
        dp2d{{Map Decision Points to Data}}
        dd{{Define Data}}
        ddf[/Data Definition/]
    end
    dps --> dd1
    dps --> dp2d
    dd1 -->|y| ddf
    dd1 -->|n| dd
    dd --> ddf
    ddf --> dp2d
    dp2d --> dpm

Example

A Software-as-a-Service Provider differentiates its service levels into three categories: silver, gold, and platinum. In the Define Inputs step, they defined a custom decision point called Service Level with the values Silver, Gold, and Platinum. Now, they need to define a data map that will assign a value to the Service Level decision point. The data they need to assign a value to the Service Level decision point originates in the service level agreement (SLA) for each service. These SLAs are stored in a database. They decide to write a script that will query the database for the SLA for each service and assign a value to the Service Level decision point based on the SLA. As these SLAs do not change very often, they decide to run the script once a day and store the results in a file. They define a data map that indicates that the data source for the Service Level decision point is the file containing the SLA data, and document that the script they wrote will assign a value to the Service Level decision point based on the SLA data.

Data Operations

Note

The diagram below shows two kinds of data emanating from the Data Operations process: Vulnerability Data and Environment Data. Vulnerability Data is data about the vulnerability itself, such as the technical impact or exploit availability. Environment Data is data about the environment in which the vulnerable systems exist, such as network topology or system criticality. We generally expect that Environment Data will be more stable than Vulnerability Data, but that is not always the case.

While the actual collection of operational data is outside the scope of SSVC, it is an important part of any implementation of the process. SSVC is designed to be flexible enough to accommodate a variety of data collection methods. The Data Mapping step defines the data that is needed to assign a value to each decision point. The Data Operations process collects that data so that it can be used to assign values to decision points in the Use SSVC step.

We include a feedback loop on the data collection node to indicate that it is expected to be a continuous process. 

flowchart LR
    subgraph dmp[Data Mapping]
       dd[/Data Definition/]
    end
    subgraph do[Data Operations]
        cd[Collect Data]
        vd[/Vulnerability Data/]
        ed[/Environment Data/]
        dt[\Available Data/]
    end
    dd --> cd
    cd --> cd
    cd --> vd
    cd --> ed
    vd --> dt
    ed --> dt

Example

Having defined a data map that translates certain values from specific threat feeds to the Exploitation decision point values PoC or Active, an organization maintains a subscription to those threat feeds and collects the data from them on a continuous basis. They also write a script that parses the data from the threat feeds and applies the data map to assign a value to the Exploitation decision point.

Guidance for Evidence Gathering

To answer each of these decision points, a stakeholder should, as much as possible, have a repeatable evidence collection and evaluation process. However, we are proposing decisions for humans to make, so evidence collection and evaluation is not totally automatable. That caveat notwithstanding, some automation is possible.

Evidence of Exploitation

For example, whether exploitation modules are available in ExploitDB, Metasploit, or other sources is straightforward. We hypothesize that searching Github and Pastebin for exploit code can be captured in a script. A supplier or deployer could then define Exploitation to take the value of PoC if there are positive search results for a set of inputs derived from the CVE entry in at least one of these venues. At least, for those vulnerabilities that are not “automatically” PoC-ready, such as on-path attackers for TLS or network replays.

Some of the decision points require a substantial upfront analysis effort to gather risk assessment or organizational data. However, once gathered, this information can be efficiently reused across many vulnerabilities and only refreshed occasionally.

Evidence of Mission Impact

An obvious example of this is the mission impact decision point. To answer this, a deployer must analyze their essential functions, how they interrelate, and how they are supported.

Evidence of Exposure

Exposure is similar; answering that decision point requires an asset inventory, adequate understanding of the network topology, and a view of the enforced security controls. Independently operated scans, such as Shodan or Shadowserver, may play a role in evaluating exposure, but the entire exposure question cannot be reduced to a binary question of whether an organization’s assets appear in such databases.

Once the deployer has the situational awareness to understand MEFs or exposure, selecting the answer for each individual vulnerability is usually straightforward.

Stakeholders who use the prioritization method should consider releasing the priority with which they handled the vulnerability. This disclosure has various benefits. For example, if the supplier publishes a priority ranking, then deployers could consider that in their decision-making process. One reasonable way to include it is to break ties for the deployer. If a deployer has three “scheduled” vulnerabilities to remediate, they may address them in any order. If two vulnerabilities were produced by the supplier as “scheduled” patches, and one was “out-of-cycle,” then the deployer may want to use that information to favor the latter.

Suggested Default Values

In the case where no information is available or the organization has not yet matured its initial situational analysis, we can suggest something like defaults for some decision points.

Default Exposure Values

If the deployer does not know their exposure, that means they do not know where the devices are or how they are controlled, so they should assume System Exposure is open.

Default Safety Values

If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a major Safety Impact. This position is conservative, but software is thoroughly embedded in daily life now, so we suggest that the decision maker provide evidence that no one’s well-being will suffer.

The reach of software exploits is no longer limited to a research network.

Default Mission Impact Values

Similarly, with Mission Impact, the deployer should assume that the software is in use at the organization for a reason, and that it supports essential functions unless they have evidence otherwise. With a total lack of information, assume support crippled as a default. Exploitation needs no special default; if adequate searches are made for exploit code and none is found, the answer is none.

Default Automatable Values

If nothing is known about Automatable, the safer answer to assume is yes. Value Density should always be answerable; if the product is uncommon, it is probably diffuse.

The resulting decision set {none, open, yes, medium} results in a scheduled patch application in our recommended deployer tree.

Use SSVC

The preparation is complete, data is being collected, and now it is time to use SSVC to make decisions about how to respond to vulnerabilities.

flowchart LR
    subgraph pd[Policy Development]
        p[/Policy/]
    end
    subgraph dmp[Data Mapping]
        dm[/Data Map/]
    end
    subgraph do[Data Operations]
        vd[/Vulnerability Data/]    
        ed[/Environment Data/]
    end
    subgraph runtime [Use SSVC]
        mdp[[Apply Decision Point Mapping to Data]]
        dp[/Decision Point Values/]
        ap[[Apply Policy]]
        oc[/Outcome/]
    end
    dm --> mdp
    vd --> mdp
    ed --> mdp
    mdp --> dp
    p --> ap
    dp --> ap
    ap --> oc

Example

A government agency has a need to prioritize vulnerability response as part of their vulnerability management process. Certain vulnerabilities require special handling as a matter of government policy, and the agency wants to make sure that they are not overlooked.

The agency completed the preparation steps and has defined the decision, the outcome set, and the decision points and values they want to use. Because of some special requirements for government agencies, they chose to use a custom outcome set that more closely matches their existing process. These same requirements also led them to define a decision function based on a custom selection of existing decision points. They've mapped their agency policy to a decision policy that assigns specific decision point values to specific outcomes. They have also enumerated the data they need to inform the relevant decision point values. The agency has a process for collecting the data they need, and they have collected the data for a particular vulnerability. Now they are ready to use SSVC to decide how to respond to a vulnerability.

Taking the data they have collected, they first combine it with the data map to produce a set of decision point values. Then they apply the policy to the decision point values to produce an outcome. The outcome is a prioritization decision that they can use to inform their response to the vulnerability.

Respond to Vulnerabilities

The actual response to vulnerabilities is outside the scope of SSVC. But since SSVC is intended to support the vulnerability response process, we include a node to indicate that the vulnerability response process is the ultimate consumer of the prioritization decision. We also include a feedback loop from the response node to the data operations node to indicate that the response process may generate new data that can be used to inform future prioritization decisions.

flowchart LR
    use[Use SSVC]
    r[Vulnerability Response]
    dataops[Data Operations]
    use --> r
    r --> dataops
    dataops --> use

Example

Different organizations will have different vulnerability response processes. The government agency in the previous example might need to notify system owners of the vulnerability and track other information about the vulnerability for reporting and auditing purposes. The service providers in previous examples might need to notify customers of the vulnerability and schedule maintenance windows to apply patches. Medical device manufacturers might need to develop patches, notify regulators of the vulnerability, and provide instructions to hospital users for applying patches. SSVC does not prescribe any particular response process, but it does provide a structured way to make decisions within the response process.

Guidance on Communicating Results

There are many aspects of SSVC that two parties might want to communicate. Not every stakeholder will use the decision points to make comparable decisions. Suppliers and deployers make interdependent decisions, but the actions of one group are not strictly dependent on the other. Recall that one reason for this is that SSVC is about prioritizing a vulnerability response action in general, not specifically applying a patch that a supplier produced. Coordinators are particularly interested in facilitating communication because that is their core function. This section handles three aspects of this challenge: formats for communicating SSVC, how to handle partial or incomplete information, and how to handle information that may change over time.

This section is about communicating SSVC information about a specific vulnerability. Any stakeholder making a decision on allocating effort should have a decision tree with its decision points and possible values specified already. Representation choices and Tree Construction and Customization Guidance discussed how SSVC uses a text file as the canonical form of a decision tree; the example trees can be found in SSVC/data. This section discusses the situation where one stakeholder, usually a supplier or coordinator, wants to communicate some information about a specific vulnerability to other stakeholders or constituents.

Communication Formats

We recommend two structured communication formats, abbreviated and full. The goal of the abbreviated format is to fill a need for providing identifying information about a vulnerability or decision in charts, graphs, and tables. Therefore, the abbreviated format is not designed to stand alone. The goal of the full format is to capture all the context and details about a decision or work item in a clear and machine-readable way.

Abbreviated Format

SSVC abbreviated form borrows directly from the CVSS “vector string” notation. Since the purpose of the abbreviated form is to provide labels for charts and graphics, it does not stand alone. The basic format for SSVC is: 

SSVC/(version)/(decision point):(value)[/decision point:value[/decision point:value[...]]][/time]/
Where version is v2 if it is based on this current version of the SSVC. The term decision point is one or two letters derived from the name of the decision point as follows: - Start with the decision point name as given in Likely Decision Points and Relevant Data. - Remove any text in parentheses (and the parentheses themselves). - Remove the word “Impact” if it is part of the name. - Create an initialism from remaining title-case words (ignore “of,” etc.), taking only the first two words. - The first letter of the initialism is upper case; if there is a second letter, then it is lower case. - Verify that the initialism is unique among decision points in the version of SSVC. If two initialisms collide, sort their source names equivalent to LC_ALL=C sort. The name that sorts first keeps the initialism for which there is a collision. Set the second letter of the initialism to the first character in the name that resolves the collision. If the names were Threat and Threshold, T would be Threat and Ts would be Threshold. We make an effort to design SSVC without such collisions.

For example, Technical Impact becomes T and Public Safety Impact becomes Ps.

The term value is a statement of the value or possible values of the decision point that precedes it and to which it is connected by a colon (:). Similar to decision point, value should be made up of one or two letters derived from the name of the decision value in the section for its associated decision point. For example MEF support crippled becomes Ms and efficient becomes E. The process is the same as above except that labels for a value do not need to be unique to the SSVC version, just unique to the associated decision point.

The character / separates decision-point:value pairs. As many pairs should be provided in the abbreviated form as are required to communicate the desired information about the vulnerability or work item. A vector must contain at least one decision-point:value pair. The ordering of the pairs should be sorted alphabetically from A to Z by the ASCII characters representing the decision points. A trailing / is used to close the string.

The vector is not tied to a specific decision tree. It is meant to communicate information in a condensed form. If priority labels (defer, etc.) are connected to a vector, then the decision tree used to reach those decisions should generally be noted. However, for complex communication, machine-to-machine communication, or long-term storage of SSVC data, the JSON format and schema should be used.

The optional parameter time is the date and time of the SSVCv2 record creation as represented in RFC 3339, section 5.6. This is a subset of the date format also commonly known as ISO8601 format.

Based on this, an example string could be: 

SSVCv2/Ps:M/T:T/U:E/2018-11-13T20:20:00Z/
For a vulnerability with minimal Public Safety Impact, total Technical Impact, and efficient Utility, which was evaluated on Nov 13,2018 at 8:20 PM UTC.

While these abbreviated format vectors can be uniquely produced based on a properly formatted JSON object, going from abbreviated form to JSON is not supported. Therefore, JSON is the preferred storage and transmission method.

Full JSON format

For a more robust, self-contained, machine-readable, we provide JSON schemas. The provision schema is equivalent to a decision tree and documents the full set of logical statements that a stakeholder uses to make decisions. The computed schema expresses a set of information about a work item or vulnerability at a point in time. A computed schema should identify the provision schema used, so the options from which the information was computed are specified.

Each element of choices should be an object that is a key-value pair of decision point:value, where the term decision point is a string derived from the name of the decision point as follows: - Start with the decision point name as given in Likely Decision Points and Relevant Data. - Remove any text in parentheses (and the parentheses themselves). - Remove colon characters, if any (:). - Convert the string to lower camel case by lowercasing the string, capitalizing any letter after a space, and removing all spaces.

The value term is derived the same way as decision point except start with the value name as given in the relevant decision point subsection of Likely Decision Points and Relevant Data.

Partial or Incomplete Information

What an analyst knows about a vulnerability may not be complete. However, the vulnerability management community may still benefit from partial information. In particular, suppliers and coordinators who might not know everything a deployer knows can still provide benefit to deployers by sharing what partial information they do know. A second benefit to providing methods for communicating partial information is the reduction of bottlenecks or barriers to information exchange. A timely partial warning is better than a complete warning that is too late.

The basic guidance is that the analyst should communicate all of the vulnerability's possible states, to the best of the analyst's knowledge. If the analyst knows nothing, all states are possible. For example, Utility may be laborious, efficient, or super effective. In abbreviated form, write this as U:LESe. Since a capital letter always indicates a new value, this is unambiguous.

The reason a stakeholder might publish something like U:LESe is that it expresses that the analyst thought about Utility but does not have anything to communicate. A stakeholder might have information to communicate about some decision points but not others. If SSVC uses this format to list the values that are in play for a particular vulnerability, there is no need for a special “I don't know” marker.

The merit in this “list all values” approach emerges when the stakeholder knows that the value for a decision point may be A or B, but not C. For example, say the analyst knows that Value Density is diffuse but does not know the value for Automatability. Then the analyst can usefully restrict Utility to one of laborious or efficient. In abbreviated form, write this as U:LE. As discussed below, information can change over time. Partial information may be, but is not required to be, sharpened over time into a precise value for the decision point.

Information Changes Over Time

Vulnerability management decisions are dynamic, and may change over time as the available information changes. Information changes are one reason why SSVC decisions should always be timestamped. SSVC decision points have different temporal properties. Some, such as Utility, are mostly static. For Utility to change, the market penetration or deployment norms of a vulnerable component would have to meaningfully change. Some, such as Exploitation, may change quickly but only in one direction.

Both of these examples are out of the direct control of the vulnerability manager. Some, such as System Exposure, change mostly due to actions taken by the organization managing the vulnerable component. If the actor who can usually trigger a relevant change is the organization using SSVC, then it is relatively straightforward to know when to update the SSVC decision. That is, the organization should reevaluate the decision when they make a relevant change. For those decision points that are about topics outside the control of the organization using SSVC, then the organization should occasionally poll their information sources for changes. The cadence or rate of polls is different for each decision point, based on the expected rate of change.

We expect that updating information over time will be most useful where the evidence-gathering process can be automated. Organizations that have mature asset management systems will also find this update process more efficient than those that do not. For an organization without a mature asset management system, we would recommend putting organizational resources into maturing that function before putting effort into regular updates to vulnerability prioritization decision points.

The following decision points are usually out of the control of the organization running SSVC. As an initial heuristic, we suggest the associated polling frequency for each. These frequencies can be customized, as the update frequency is directly related to the organization's tolerance for the risk that the information is out of date. As discussed in Tree Construction and Customization Guidance, risk tolerance is unique to each organization. Risk tolerance and risk appetite are primarily reflected in the priority labels (that is, decisions) encoded in the SSVC decision tree, but information polling frequency is also a risk tolerance decision and each organization may choose different time values.

Decision Point Suggested Polling Frequency
Exploitation every 1 day
Technical Impact never (should be static per vulnerability)
Utility every 6 months
Public Safety Impact every 1 year

The following decision points are usually in the control of the organization running SSVC and should be reevaluated when a relevant change is made or during annual reviews of assets.

If SSVC information is all timestamped appropriately (as discussed earlier in this section), then an analyst can compare the timestamp to the current date and determine whether information is considered stale. The above rates are heuristic suggestions, and organizations may choose different ones. Any public repository of vulnerability information should keep a change log of when values change for each decision point, for each vulnerability. Vulnerability response analysts should keep such change logs as well. Similar to logging practices recommended for incident response 1, such practices make the process less error-prone and facilitate after-action reviews.

  1. Paul Cichonski, Tom Millar, Tim Grance, and Karen Scarfone. Computer security incident handling guide. Technical Report SP 800-61r2, US Dept of Commerce, National Institute of Standards and Technology, Gaithersburg, MD, August 2012. ↩

Bootstrapping SSVC Summary

Using SSVC to prioritize vulnerability response requires a few steps. The steps are:

Step Description
Prepare Define the decision you want to make, the outcomes you care about, the decision points you will use to make the decision, the decision policy, and the data you need to inform the decision points.
Collect Collect the data you need to make informed decisions.
Use SSVC Use SSVC to make decisions about how to respond to vulnerabilities.
Respond Respond to vulnerabilities according to the prioritization.

We covered each of these in the previous sections, see the links in the table above for more information.

The diagram below shows the complete process of using SSVC.

flowchart
start([Start])
subgraph prep [Prepare to use SSVC]
    dcd{{Choose Decision to Model}}
    d[/Decision/]
    subgraph outcomes [Define Outcomes]
        oc1[/Use available<br/>outcome sets?\]
        dos{{Define Outcome Sets}}
        oss[\Outcome Sets/]
        cos{{Choose Outcome Set}}
        os[/Outcome Set/]
    end
    subgraph decisionpoints [Define Inputs]
        dp1[/Use available<br/>decision points?\]
        ddp{{Define Decision Points}}
        dpt[\Decision Points/]
        cdp{{Choose Decision Points}}
        dps[/Decision Point Set/]
    end
    subgraph dataeng [Data Mapping]
        dd1[/Use existing data?\]
        dpm[/Data Map/]
        dp2d{{Map Decision Points to Data}}
        dd{{Define Data}}
        ddf[/Data Definition/]
    end
    subgraph policy [Policy Development]
        dfp{{Define Policy}}
        p[/Policy/]
    end
end
subgraph dataops [Data Operations]
    cd[Collect Data]
    vd[/Vulnerability Data/]
    ed[/Environment Data/]
    dt[\Available Data/]

end
subgraph runtime [Use SSVC]
    mdp[[Apply Decision Point Mapping to Data]]
    dp[/Decision Point Values/]
    ap[[Apply Policy]]
    oc[/Outcome/]
end
r[Vulnerability Response]
start --> dcd
dcd --> d
d --> oc1
dps --> dd1
oc1 -->|y| oss
oc1 -->|n| dos
dp1 -->|y| dpt
dp1 -->|n| ddp
dd1 -->|y| ddf
dd1 -->|n| dd
ddp --> dpt
dos --> oss
dpt --> cdp
cdp --> dps
cos --> os
oss --> cos
os --> dfp
os --> dp1
d --> dp1
dps --> dp2d
dp2d --> dpm
dps --> dfp
dpm --> mdp
dd --> ddf
ddf --> dp2d
ddf --> cd
cd --> cd
cd --> vd
cd --> ed
vd --> dt
ed --> dt
dt --> mdp
mdp --> dp
dfp --> p
p --> ap
dp --> ap
ap --> oc
oc --> r
r --> l1((1))
l2((1)) --> cd

Ended: Bootstrapping SSVC

Prioritizing Patch Creation

Here we describe an example decision model for a Supplier deciding the priority of creating a patch for a vulnerability in their software.

Supplier Patch Creation Priority

As noted in Enumerating Decisions, the root of a decision model's identity is the combination of the stakeholder and the decision being modeled. In this case, the stakeholder is the Supplier and the decision is the priority of creating a patch.

Supplier Units of Work

On the input side of the Supplier process, Suppliers typically receive reports of vulnerabilities in one or more versions of their product. Part of the Supplier's task on initial report intake is to resolve the initial report into a set of products and versions that are affected by the reported vulnerability.

Supplier Unit of Work

For the purposes of SSVC, we consider the unit of work for a Supplier to be combination of the vulnerability with each affected product.

Our working assumption is that for SSVC purposes, the supplier's unit of work is the combination of the vulnerability with each affected product. This implies the need for Suppliers to be able to resolve whatever they receive to that level of granularity in order to make best use of SSVC.

Products will often need to be addressed individually because they may have diverse development processes or usage scenarios. There are a variety of ways a Supplier might need to resolve the set of affected products. For example, they might

Independently Fixable Vulnerabilities

Without belaboring the point, these methods are similar to how CVE Numbering Authorities discern “independently fixable vulnerabilities”.

We also note that Software Bill of Materials (SBOM) seems well-placed to aid in that resolution process for the third-party library scenarios.

  • recognize, on further investigation of the initial report, that additional versions of the product are affected
  • discover that other products are affected due to code sharing or programmer error consistent across products
  • receive reports of vulnerabilities in third party libraries they utilize in one or more of their products
  • receive fix bundles for third party libraries used in one or more of their products (where a fix bundle might resolve multiple vulnerabilities or add new features)

In the end, Suppliers provide remediations and/or mitigations for affected products. A supplier-provided remediation is usually a software update which contains fixes for multiple vulnerabilities and, often, new or improved features. Supplier output is relevant because it will become input to Deployers. SSVC focuses only on the remediation in this case; a set of remediations for multiple vulnerabilities is a fix bundle. Suppliers may also produce mitigations, such as recommended configuration changes, to limit the impact of a vulnerability.

Supplier Decision Outcomes

At a basic level, the decision at a software development organization is whether to issue a work order and what resources to expend to remediate a vulnerability in the organization’s software. Prioritization is required because, at least in the current history of software engineering, the effort to patch all known vulnerabilities will exceed available resources. The organization considers several other factors to build the patch; refactoring a large portion of the code base may be necessary for some patches, while others require relatively small changes. We focus only on the priority of building the patch, and we consider four categories of priority, as outlined in the table below.

Patch Supplier Priority

Supplier Priority Description
Defer Do not work on the patch at present.
Scheduled Develop a fix within regularly scheduled maintenance using supplier resources as normal.
Out-of-Cycle Develop mitigation or remediation out-of-cycle, taking resources away from other projects and releasing the fix as a security patch when it is ready.
Immediate Develop and release a fix as quickly as possible, drawing on all available resources, potentially including drawing on or coordinating resources from other parts of the organization.

Supplier Decision Points

The decision to create a patch is based on the following decision points:

  • Exploitation - A vulnerabilty with known exploitation is more likely to be given a higher priority.
  • Utility - The more useful a vulnerability is to an attacker, the more likely it is to be given a higher priority.
  • Technical Impact - The more severe the technical impact of a vulnerability, the more likely it is to be given a higher priority.
  • Public Safety Impact - The more severe the public safety impact of a vulnerability, the more likely it is to be given a higher priority.

More detail about each of these decision points is provided at the links above, here we provide a brief summary of each.

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. 
{
  "namespace": "ssvc",
  "version": "1.1.0",
  "key": "E",
  "name": "Exploitation",
  "description": "The present state of exploitation of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability."
    },
    {
      "key": "P",
      "name": "Public PoC",
      "description": "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."
    },
    {
      "key": "A",
      "name": "Active",
      "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting."
    }
  ]
}

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 
{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "U",
  "name": "Utility",
  "description": "The Usefulness of the Exploit to the Adversary",
  "values": [
    {
      "key": "L",
      "name": "Laborious",
      "description": "Automatable:No AND Value Density:Diffuse"
    },
    {
      "key": "E",
      "name": "Efficient",
      "description": "(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)"
    },
    {
      "key": "S",
      "name": "Super Effective",
      "description": "Automatable:Yes AND Value Density:Concentrated"
    }
  ]
}

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. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "TI",
  "name": "Technical Impact",
  "description": "The technical impact of the vulnerability.",
  "values": [
    {
      "key": "P",
      "name": "Partial",
      "description": "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."
    },
    {
      "key": "T",
      "name": "Total",
      "description": "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 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) 
{
  "namespace": "ssvc",
  "version": "2.0.1",
  "key": "PSI",
  "name": "Public Safety Impact",
  "description": "A coarse-grained representation of impact to public safety.",
  "values": [
    {
      "key": "M",
      "name": "Minimal",
      "description": "Safety Impact:Negligible"
    },
    {
      "key": "S",
      "name": "Significant",
      "description": "Safety Impact:(Marginal OR Critical OR Catastrophic)"
    }
  ]
}

Public Safety Impact is a notational convenience

The Public Safety Impact decision point is a simplification of the more detailed Safety Impact decision point.

Supplier Decision Model

The example supplier decision model below shows a prioritization policy for the supplier. We display the decision model as a decision tree, which provides a compact representation of the policy, showing the relative priority of different situations.

Tree Notation

Rectangles are decision points, and triangles represent outcomes. The values for each decision point are different, as described above. Outcomes are priority decisions (defer, scheduled, out-of-cycle, immediate). Outcome triangles are color coded:

  • Defer = gray with green outline
  • Scheduled = yellow
  • Out-of-Cycle = orange
  • Immediate = red with black outline

Table of Values

row Exploitation Utility Technical Impact Public-Safety Impact Priority
1 none laborious partial minimal defer
2 none laborious partial significant scheduled
3 none laborious total minimal scheduled
4 none laborious total significant out-of-cycle
5 none efficient partial minimal scheduled
6 none efficient partial significant out-of-cycle
7 none efficient total minimal scheduled
8 none efficient total significant out-of-cycle
9 none super effective partial minimal scheduled
10 none super effective partial significant out-of-cycle
11 none super effective total minimal out-of-cycle
12 none super effective total significant out-of-cycle
13 PoC laborious partial minimal scheduled
14 PoC laborious partial significant out-of-cycle
15 PoC laborious total minimal scheduled
16 PoC laborious total significant immediate
17 PoC efficient partial minimal scheduled
18 PoC efficient partial significant immediate
19 PoC efficient total minimal out-of-cycle
20 PoC efficient total significant immediate
21 PoC super effective partial minimal out-of-cycle
22 PoC super effective partial significant immediate
23 PoC super effective total minimal out-of-cycle
24 PoC super effective total significant immediate
25 active laborious partial minimal out-of-cycle
26 active laborious partial significant immediate
27 active laborious total minimal out-of-cycle
28 active laborious total significant immediate
29 active efficient partial minimal out-of-cycle
30 active efficient partial significant immediate
31 active efficient total minimal out-of-cycle
32 active efficient total significant immediate
33 active super effective partial minimal immediate
34 active super effective partial significant immediate
35 active super effective total minimal immediate
36 active super effective total significant immediate

Prioritizing Patch Deployment

Here we describe an example decision model for a Deployer deciding the priority of deploying a patch for a vulnerability in their infrastructure.

Deployer Patch Deployment Priority

As noted in Enumerating Decisions, the root of a decision model's identity is the combination of the stakeholder and the decision being modeled. In this case, the stakeholder is the Deployer and the decision is the priority of deploying a patch.

Deployer Units of Work

Deployer Unit of Work

The unit of work for a Deployer is usually a single deployable patch or patch bundle such as a service pack.

Deployers are usually in the position of receiving remediations or mitigations from their Suppliers for products they have deployed. They must then decide whether to deploy the remediation or mitigation to a particular instance (or not). Whether they have the option of deploying only part of a remediation such as a fix bundle depends on whether the Supplier has engineered their release process to permit that degree of flexibility. For example, if service packs are fix bundles, the Supplier might choose to release individually deployable fixes as well.

The vulnerability management process for deployers has at its core the collation of data including

Relationship to asset management

The relationship between SSVC and asset management is discussed further in SSVC and Asset Management.

  • an inventory of deployed instances of product versions
  • a mapping of vulnerabilities to remediations or mitigations
  • a mapping of remediations and/or mitigations to product versions

The first must be collected by the Deployer, while the latter two most often originate from the product Supplier. Managing this information is generally called asset management.

In turn, Deployers must resolve this information into specific actions in which a remediation or mitigation is slated for deployment to replace or modify a particular instance of the product. The Deployer model described below considers the mission and safety risks inherent to the category of systems to which those deployed instances belong. For this reason, we recommend that the pairing of remediation or mitigation to a product version instance constitutes the unit of work most appropriate for the Deployer.

Deployer Decision Outcomes

A deployer's decision centers on with what priority to deploy a given remediation or mitigation to their infrastructure. Similar to the Supplier case, we consider four categories of priority, as outlined in the table below. While we've used the same priority names, the meaning of the priority may have different implications for the deployer than for the supplier.

Patch Deployer Priority

Deployer Priority Description
Defer Do not act at present.
Scheduled Act during regularly scheduled maintenance time.
Out-of-cycle Act more quickly than usual to apply the mitigation or remediation out-of-cycle, during the next available opportunity, working overtime if necessary.
Immediate Act immediately; focus all resources on applying the fix as quickly as possible, including, if necessary, pausing regular organization operations.

When remediation is available, usually the action is to apply it. When remediation is not yet available, the action space is more diverse, but it should involve mitigating the vulnerability (e.g., shutting down services or applying additional security controls) or accepting the risk of not mitigating the vulnerability.

Applying mitigations may change the value of decision points. A mitigation that successfully changes the value of a decision point may shift the priority of further action to a reduced state. If applying a mitigation reduces the priority to defer, the deployer may not need to apply a remediation if it later becomes available.

Mitigation Examples

  • An effective firewall or IDS rule coupled with an adequate change control process for rules may change System Exposure from open to controlled. This could be enough to reduce the priority where no further action is necessary.
  • In the area of Financial Safety Impact, a better insurance policy may be purchased, providing necessary fraud insurance.
  • Physical Safety Impact may be reduced by testing the physical barriers designed to restrict a robot's ability to interact with humans.
  • Mission Impact could be reduced by correcting the problems identified in a disaster recover test-run of the alternate business flow.

However, mitigation techniques will not always be adequate to address the risk posed by the vulnerability.

Examples of Inadequate Mitigation

  • The implementation of a firewall or IDS rule to mitigate System Exposure from open to controlled is only valid until someone changes the rule.
  • In the area of Financial impacts, the caps on the insurance may be too low to act as a mitigation.
  • The Physical impact may be increased by incorrect installation of the physical barriers designed to restrict a robot’s ability to interact with humans.
  • The Mission Impact could be increased when a disaster recovery test-run identifies problems with an alternate business flow.
  • The mitigating action may not be permanent or work as designed.

As opposed to mitigation, applying a remediation finishes an SSVC analysis of a deployed system.

Remediation is not a final state

While specific vulnerabilities in specific systems can be remediated, the vulnerability cannot be 'disposed of' or eliminated from future consideration within an IT environment. Since software and systems are dynamic, a single vulnerability can be re-introduced after initial remediation through updates, software rollbacks, or other systemic actions that change the operating conditions within an environment. It is therefore important to continually monitor remediated environments for vulnerabilities reintroduced by either rollbacks or new deployments of outdated software.

Deployer Decision Points

The Deployer Patch Deployment Priority decision model uses the following decision points:

  • Exploitation - A vulnerability with known exploitation is more likely to be given a higher priority.
  • System Exposure - The more exposed a system is, the more likely it is to be given a higher priority.
  • Utility - The more useful a vulnerability is to an attacker, the more likely it is to be given a higher priority.
  • Human Impact - The more severe the human (safety, mission) impact of a vulnerability, the more likely it is to be given a higher priority.

More detail about each of these decision points is provided at the links above, here we provide a brief summary of each.

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. 
{
  "namespace": "ssvc",
  "version": "1.1.0",
  "key": "E",
  "name": "Exploitation",
  "description": "The present state of exploitation of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability."
    },
    {
      "key": "P",
      "name": "Public PoC",
      "description": "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."
    },
    {
      "key": "A",
      "name": "Active",
      "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting."
    }
  ]
}

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) 
{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "EXP",
  "name": "System Exposure",
  "description": "The Accessible Attack Surface of the Affected System or Service",
  "values": [
    {
      "key": "S",
      "name": "Small",
      "description": "Local service or program; highly controlled network"
    },
    {
      "key": "C",
      "name": "Controlled",
      "description": "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\u2019s 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."
    },
    {
      "key": "O",
      "name": "Open",
      "description": "Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers)"
    }
  ]
}

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 
{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "U",
  "name": "Utility",
  "description": "The Usefulness of the Exploit to the Adversary",
  "values": [
    {
      "key": "L",
      "name": "Laborious",
      "description": "Automatable:No AND Value Density:Diffuse"
    },
    {
      "key": "E",
      "name": "Efficient",
      "description": "(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)"
    },
    {
      "key": "S",
      "name": "Super Effective",
      "description": "Automatable:Yes AND Value Density:Concentrated"
    }
  ]
}

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 
{
  "namespace": "ssvc",
  "version": "2.0.1",
  "key": "HI",
  "name": "Human Impact",
  "description": "Human Impact is a combination of Safety and Mission impacts.",
  "values": [
    {
      "key": "L",
      "name": "Low",
      "description": "Safety Impact:(Negligible) AND Mission Impact:(None OR Degraded OR Crippled)"
    },
    {
      "key": "M",
      "name": "Medium",
      "description": "(Safety Impact:Negligible AND Mission Impact:MEF Failure) OR (Safety Impact:Marginal AND Mission Impact:(None OR Degraded OR Crippled))"
    },
    {
      "key": "H",
      "name": "High",
      "description": "(Safety Impact:Critical AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Marginal AND Mission Impact:MEF Failure)"
    },
    {
      "key": "VH",
      "name": "Very High",
      "description": "Safety Impact:Catastrophic OR Mission Impact:Mission Failure"
    }
  ]
}

Deployer Decision Model

Below we provide an example deployer prioritization policy that maps the decision points just listed to the outcomes described above.

Notes on the Deployer Decision Model Example Policy

In the example policy shown below:

Tree Notation

Rectangles are decision points, and triangles represent outcomes. The values for each decision point are different, as described above. Outcomes are priority decisions (defer, scheduled, out-of-cycle, immediate). Outcome triangles are color coded:

  • Defer = gray with green outline
  • Scheduled = yellow
  • Out-of-Cycle = orange
  • Immediate = red with black outline

Table of Values

row Exploitation Exposure Automatable Human Impact Priority
1 none small no low defer
2 none small no medium defer
3 none small no high scheduled
4 none small no very high scheduled
5 none small yes low defer
6 none small yes medium scheduled
7 none small yes high scheduled
8 none small yes very high scheduled
9 none controlled no low defer
10 none controlled no medium scheduled
11 none controlled no high scheduled
12 none controlled no very high scheduled
13 none controlled yes low scheduled
14 none controlled yes medium scheduled
15 none controlled yes high scheduled
16 none controlled yes very high scheduled
17 none open no low defer
18 none open no medium scheduled
19 none open no high scheduled
20 none open no very high scheduled
21 none open yes low scheduled
22 none open yes medium scheduled
23 none open yes high scheduled
24 none open yes very high out-of-cycle
25 PoC small no low defer
26 PoC small no medium scheduled
27 PoC small no high scheduled
28 PoC small no very high scheduled
29 PoC small yes low scheduled
30 PoC small yes medium scheduled
31 PoC small yes high scheduled
32 PoC small yes very high scheduled
33 PoC controlled no low defer
34 PoC controlled no medium scheduled
35 PoC controlled no high scheduled
36 PoC controlled no very high scheduled
37 PoC controlled yes low scheduled
38 PoC controlled yes medium scheduled
39 PoC controlled yes high scheduled
40 PoC controlled yes very high out-of-cycle
41 PoC open no low scheduled
42 PoC open no medium scheduled
43 PoC open no high scheduled
44 PoC open no very high out-of-cycle
45 PoC open yes low scheduled
46 PoC open yes medium scheduled
47 PoC open yes high out-of-cycle
48 PoC open yes very high out-of-cycle
49 active small no low scheduled
50 active small no medium scheduled
51 active small no high out-of-cycle
52 active small no very high out-of-cycle
53 active small yes low scheduled
54 active small yes medium out-of-cycle
55 active small yes high out-of-cycle
56 active small yes very high out-of-cycle
57 active controlled no low scheduled
58 active controlled no medium scheduled
59 active controlled no high out-of-cycle
60 active controlled no very high out-of-cycle
61 active controlled yes low out-of-cycle
62 active controlled yes medium out-of-cycle
63 active controlled yes high out-of-cycle
64 active controlled yes very high out-of-cycle
65 active open no low scheduled
66 active open no medium out-of-cycle
67 active open no high out-of-cycle
68 active open no very high immediate
69 active open yes low out-of-cycle
70 active open yes medium out-of-cycle
71 active open yes high immediate
72 active open yes very high immediate

Vulnerability Coordination Decisions

Coordinators are facilitators within the vulnerability management ecosystem. Since coordinators neither supply nor deploy the vulnerable component in question, their decisions are different from suppliers' or deployers' decisions. This section provides a window into CERT/CC's decisions as an example of how a coordinator might use SSVC to make its own decisions.

Coordinators vary quite a lot, and their use of SSVC may likewise vary. A coordinator may want to gather and publish information about SSVC decision points that it does not use internally in order to assist its constituents. Furthermore, a coordinator may only publish some of the information it uses to make decisions. Consistent with other stakeholder perspectives (supplier and deployer), SSVC provides the priority with which a coordinator should take some defined action, but not how to do that action. For more information about types of coordinators and their facilitation actions within vulnerability management, see The CERT Guide to Coordinated Vulnerability Disclosure

The two decisions that CERT/CC makes as a coordinator that we will discuss in terms of SSVC are

  1. Coordination Triage - The initial triage of vulnerability reports. This initial coordination decision is a prioritization decision, but it does not have the same values as prioritization by a deployer or supplier.
  2. Publication - Whether a publication about a vulnerability is warranted. The publication decision for us is a binary yes/no.

These two decisions are not the entirety of vulnerability coordination, but we leave further details of the process for future work.

CISA and SSVC

For another example of how a coordinator is using SSVC, see the CISA SSVC website.

Different coordinators have different scopes and constituencies. See The CERT Guide to Coordinated Vulnerability Disclosure for a listing of different coordinator types. If a coordinator receives a report that is outside its own work scope or constituency, it should make an effort to route the report to a more suitable coordinator. The decisions in this section assume the report or vulnerability in question is within the work scope or constituency for the coordinator.

Prioritizing Vulnerability Coordination

In coordinated vulnerability disclosure (CVD), there are two available decisions modelled in SSVC. The first is whether or not to coordinate a vulnerability report. This decision is also known as triage.

Coordination Triage Priority

As noted in Enumerating Decisions, the root of a decision model's identity is the combination of the stakeholder and the decision being modeled. In this case, the stakeholder is the Coordinator and the decision is the priority of coordinating a vulnerability report.

Coordinator Triage Units of Work

Coordinator Unit of Work

The unit of work for a Coordinator is usually a single report to be coordinated.

Coordinator units of work tend to coincide with whatever arrives in a single report, which spans the range from a single vulnerability affecting a specific version of an individual product from one Supplier all the way to fundamental design flaws in system specifications that could affect every Supplier and product that uses or implements the flawed specification. Coordinators may need to reorganize reports (e.g., merge, split, expand, or contract) according to their workflow demands. SSVC can be applied to either the initial report or to the results of such refinement.

Coordinator Triage Decision Outcomes

We take three priority levels in our decision about whether and how to coordinate a vulnerability based on an incoming report:

Coordinator Triage Priority

Triage Priority Description
Decline Do not act on the report.
Track Receive information about the vulnerability and monitor for status changes but do not take any overt actions.
Coordinate Take action on the report. “Action” may include any one or more of: technical analysis, reproduction, notifying vendors, publication, and assist another party.
  • Decline — Do not act on the report. May take different forms, including ignoring the report as well as an acknowledgement to the reporter that we will not act and suggest the reporter to go to vendor or publish if unresponsive.
  • Track — Receive information about the vulnerability and monitor for status changes but do not take any overt actions.
  • Coordinate — Take action on the report. “Action” may include any one or more of: technical analysis, reproduction, notifying vendors, lead coordination (notify, communicate, and publish), publish only (amplify public message), advise only, secondary coordinator (assist another lead coordinator). See the FIRST CSIRT Services Framework for additional vulnerability management services a coordinator may provide.

Coordinator Triage Decision Points

Prior CERT/CC Work on Prioritizing Coordination Decisions

Vulnerability Response Decision Assistance (VRDA) provides a starting point for a decision model for this situation. VRDA is likely adequate for national-level CSIRTs that do general CVD, but other CSIRT types may have different needs. The CERT Guide to Coordinated Vulnerability Disclosure provides something similar for those who are deciding how to report and disclose vulnerabilities they have discovered.

The coordination and publication decisions for CERT/CC are about the social and collaborative state of vulnerability management. Our goal with the coordination decision is to base it on information that is available to the analyst when CERT/CC receives a vulnerability report. In addition to using some of the decision points common to Suppliers and Deployers (Utility and Public Safety Impact), we have added five new decision points for the coordination decision model.

The first two function as gating questions:

These two sets of exceptional circumstances mean that the seven decision points involved in the coordination triage tree can be compressed slightly, as the decision model below shows.

The remaining five decision points are:

  • Report Credibility: If the report is not credible, then CERT/CC will decline the case.
  • 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.

More detail about each of these decision points is provided at the links above, here we provide a brief summary of each.

Report Public v1.0.0

Is a viable report of the details of the vulnerability already publicly available?

Value Definition
Yes A public report of the vulnerability exists.
No No public report of the vulnerability exists. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "RP",
  "name": "Report Public",
  "description": "Is a viable report of the details of the vulnerability already publicly available?",
  "values": [
    {
      "key": "Y",
      "name": "Yes",
      "description": "A public report of the vulnerability exists."
    },
    {
      "key": "N",
      "name": "No",
      "description": "No public report of the vulnerability exists."
    }
  ]
}

Supplier Contacted v1.0.0

Has the reporter made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method?

Value Definition
No The supplier has not been contacted.
Yes The supplier has been contacted. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SC",
  "name": "Supplier Contacted",
  "description": "Has the reporter made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method?",
  "values": [
    {
      "key": "N",
      "name": "No",
      "description": "The supplier has not been contacted."
    },
    {
      "key": "Y",
      "name": "Yes",
      "description": "The supplier has been contacted."
    }
  ]
}

Report Credibility v1.0.0

Is the report credible?

Value Definition
Not Credible The report is not credible.
Credible The report is credible. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "RC",
  "name": "Report Credibility",
  "description": "Is the report credible?",
  "values": [
    {
      "key": "NC",
      "name": "Not Credible",
      "description": "The report is not credible."
    },
    {
      "key": "C",
      "name": "Credible",
      "description": "The report is credible."
    }
  ]
}

Supplier Cardinality v1.0.0

How many suppliers are responsible for the vulnerable component and its remediation or mitigation plan?

Value Definition
One There is only one supplier of the vulnerable component.
Multiple There are multiple suppliers of the vulnerable component. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SC",
  "name": "Supplier Cardinality",
  "description": "How many suppliers are responsible for the vulnerable component and its remediation or mitigation plan?",
  "values": [
    {
      "key": "O",
      "name": "One",
      "description": "There is only one supplier of the vulnerable component."
    },
    {
      "key": "M",
      "name": "Multiple",
      "description": "There are multiple suppliers of the vulnerable component."
    }
  ]
}

Supplier Engagement v1.0.0

Is the supplier responding to the reporter’s contact effort and actively participating in the coordination effort?

Value Definition
Active The supplier is responding to the reporter’s contact effort and actively participating in the coordination effort.
Unresponsive The supplier is not responding to the reporter’s contact effort and not actively participating in the coordination effort. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SE",
  "name": "Supplier Engagement",
  "description": "Is the supplier responding to the reporter\u2019s contact effort and actively participating in the coordination effort?",
  "values": [
    {
      "key": "A",
      "name": "Active",
      "description": "The supplier is responding to the reporter\u2019s contact effort and actively participating in the coordination effort."
    },
    {
      "key": "U",
      "name": "Unresponsive",
      "description": "The supplier is not responding to the reporter\u2019s contact effort and not actively participating in the coordination effort."
    }
  ]
}

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 
{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "U",
  "name": "Utility",
  "description": "The Usefulness of the Exploit to the Adversary",
  "values": [
    {
      "key": "L",
      "name": "Laborious",
      "description": "Automatable:No AND Value Density:Diffuse"
    },
    {
      "key": "E",
      "name": "Efficient",
      "description": "(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)"
    },
    {
      "key": "S",
      "name": "Super Effective",
      "description": "Automatable:Yes AND Value Density:Concentrated"
    }
  ]
}

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) 
{
  "namespace": "ssvc",
  "version": "2.0.1",
  "key": "PSI",
  "name": "Public Safety Impact",
  "description": "A coarse-grained representation of impact to public safety.",
  "values": [
    {
      "key": "M",
      "name": "Minimal",
      "description": "Safety Impact:Negligible"
    },
    {
      "key": "S",
      "name": "Significant",
      "description": "Safety Impact:(Marginal OR Critical OR Catastrophic)"
    }
  ]
}

Coordinator Triage Decision Model

The following example decision model is a policy that closely follows our own decision model at the CERT/CC. Other coordinators should consider customizing the tree to their needs, as described in Tree Construction and Customization Guidance.

SSVC Customization in Action: CISA

CISA has customized an SSVC decision model to suit their coordination needs. It is available at https://www.cisa.gov/ssvc.

Table of Values

row Public Contacted Report_Credibility Cardinality Engagement Utility Public_Safety_Impact Priority
1 no yes no one active laborious minimal decline
2 no yes no one active laborious significant decline
3 no yes no one active efficient minimal decline
4 no yes no one active efficient significant track
5 no yes no one active super effective minimal decline
6 no yes no one active super effective significant track
7 no yes no one unresponsive laborious minimal decline
8 no yes no one unresponsive laborious significant decline
9 no yes no one unresponsive efficient minimal decline
10 no yes no one unresponsive efficient significant track
11 no yes no one unresponsive super effective minimal decline
12 no yes no one unresponsive super effective significant track
13 no yes no multiple active laborious minimal decline
14 no yes no multiple active laborious significant track
15 no yes no multiple active efficient minimal decline
16 no yes no multiple active efficient significant track
17 no yes no multiple active super effective minimal track
18 no yes no multiple active super effective significant coordinate
19 no yes no multiple unresponsive laborious minimal decline
20 no yes no multiple unresponsive laborious significant track
21 no yes no multiple unresponsive efficient minimal decline
22 no yes no multiple unresponsive efficient significant track
23 no yes no multiple unresponsive super effective minimal track
24 no yes no multiple unresponsive super effective significant coordinate
25 no yes yes one active laborious minimal decline
26 no yes yes one active laborious significant decline
27 no yes yes one active efficient minimal decline
28 no yes yes one active efficient significant track
29 no yes yes one active super effective minimal decline
30 no yes yes one active super effective significant track
31 no yes yes one unresponsive laborious minimal track
32 no yes yes one unresponsive laborious significant coordinate
33 no yes yes one unresponsive efficient minimal coordinate
34 no yes yes one unresponsive efficient significant coordinate
35 no yes yes one unresponsive super effective minimal coordinate
36 no yes yes one unresponsive super effective significant coordinate
37 no yes yes multiple active laborious minimal decline
38 no yes yes multiple active laborious significant track
39 no yes yes multiple active efficient minimal decline
40 no yes yes multiple active efficient significant track
41 no yes yes multiple active super effective minimal coordinate
42 no yes yes multiple active super effective significant coordinate
43 no yes yes multiple unresponsive laborious minimal coordinate
44 no yes yes multiple unresponsive laborious significant coordinate
45 no yes yes multiple unresponsive efficient minimal coordinate
46 no yes yes multiple unresponsive efficient significant coordinate
47 no yes yes multiple unresponsive super effective minimal coordinate
48 no yes yes multiple unresponsive super effective significant coordinate
49 yes yes no multiple active super effective significant coordinate
50 yes yes no multiple unresponsive super effective significant coordinate
51 yes yes yes multiple active super effective significant coordinate
52 yes yes yes multiple unresponsive super effective significant coordinate
53 yes no no multiple active super effective significant coordinate
54 yes no no multiple unresponsive super effective significant coordinate
55 yes no yes multiple active super effective significant coordinate
56 yes no yes multiple unresponsive super effective significant coordinate
57 yes yes no one active laborious minimal decline
58 yes yes no one active efficient minimal decline
59 yes yes no one unresponsive laborious minimal decline
60 yes yes no one unresponsive efficient minimal decline
61 yes yes yes one active laborious minimal decline
62 yes yes yes one active efficient minimal decline
63 yes yes yes one unresponsive laborious minimal decline
64 yes yes yes one unresponsive efficient minimal decline
65 yes no no one active laborious minimal decline
66 yes no no one active efficient minimal decline
67 yes no no one unresponsive laborious minimal decline
68 yes no no one unresponsive efficient minimal decline
69 yes no yes one active laborious minimal decline
70 yes no yes one active efficient minimal decline
71 yes no yes one unresponsive laborious minimal decline
72 yes no yes one unresponsive efficient minimal decline
73 no no no multiple active super effective significant coordinate
74 no no no multiple unresponsive super effective significant coordinate
75 no no yes multiple active super effective significant coordinate
76 no no yes multiple unresponsive super effective significant coordinate
77 no no no one active laborious minimal decline
78 no no no one active efficient minimal decline
79 no no no one unresponsive laborious minimal decline
80 no no no one unresponsive efficient minimal decline
81 no no yes one active laborious minimal decline
82 no no yes one active efficient minimal decline
83 no no yes one unresponsive laborious minimal decline
84 no no yes one unresponsive efficient minimal decline

Coordinator Publication Decision

Coordinators have to make two decisions about publication of information about a vulnerability. The first is whether to coordinate the vulnerability, which we discuss in Coordination Triage. The second decision is whether to publish information about a vulnerability. While other stakeholders may also have to make a publication decision, here we focus on the coordinator's decision.

Coordinator Publication Decision

As noted in Enumerating Decisions, the root of a decision model's identity is the combination of the stakeholder and the decision being modeled. In this case, the stakeholder is the Coordinator and the decision is whether to publish an advisory about the vulnerability.

Policy Constraints and Publication Decisions

Other Stakeholders' Publication Decisions

Other stakeholders may also have to make a publication decision. For example, a supplier may have to decide whether to publish information about a vulnerability in their product. A deployer may have to decide whether to publish information about a vulnerability in their infrastructure. A vulnerability finder may have to decide whether to publish information about a vulnerability they have discovered. Each of these decisions is likely to be different from the coordinator's decision.

The decision to publish information about a vulnerability is a policy choice, and is likely to differ from organization to organization. Two points where CERT/CC policy clearly influences the publication decision are embargo periods and scope.

Publication and Embargo Periods

As a matter of policy, CERT/CC will support an embargo from the public of information about a vulnerability through its choice not to publish that information while a number of conditions hold:

  • A negotiated embargo timer has not expired. The CERT/CC default embargo period is 45 days.
  • Other exceptions have not been met, including active exploitation of the vulnerability in the wild or other public discussion of the vulnerability details.

Regardless, the decision described in this section assumes the embargo period is over, one way or another.

Triage Decisions and Publication

The second point is related to the Coordination Triage Decision and the status of the vulnerability. CERT/CC only expects to publish about vulnerabilities with a coordinate status. While an issue that is tracked or declined may be reevaluated at a later date and status changed to coordinate, unless that happens we would not publish about the vulnerability. Other organizations, such as NVD, would have different publication criteria and may want to include decision points or the decision itself from the Coordination Triage Decision in their publication decision.

Coordinator Publication Units of Work

Coordinator Publication Unit of Work

The unit of work for the coordinator publication decision a single publication. For CERT/CC, this corresponds to a CERT Vulnerability Note.

In the CERT/CC's vulnerability coordination practice, a single report leads to a single coordination case which leads to a single publication. Therefore the unit of work for the publication decision is often the same as the unit of work for the coordination triage decision.

That is sometimes not the case, however. For example, there could be multiple reports of multiple vulnerabilities and the coordinator might choose to publish a single advisory covering all of them if the vulnerabilities are variations on a central theme and have a common set of affected products.

Multiple Reports, Single Advisory

There are numerous examples of multiple reported vulnerabilities being consolidated into a single publication in the CERT/CC's history. A few recent cases include:

  • VU#132380 Vulnerabilities in EDK2 NetworkPkg IP stack implementation.
  • VU#434994 Multiple race conditions due to TOCTOU flaws in various UEFI Implementations
  • VU#811862 Image files in UEFI can be abused to modify boot behavior

Another possibility is that a single report could lead to multiple advisories, for example if the product is a library that is used in multiple other products, and the coordinator chooses to publish separate advisories based on some other criteria.

Single Report, Multiple Advisories

Occasionally, a single report leads to multiple advisories. For example

  • VU#854306 Multiple vulnerabilities in SNMPv1 request handling
  • VU#107186 Multiple vulnerabilities in SNMPv1 trap handling

arrived as a single report and were published as separate vulnerability notes because they affected different aspects of the libraries in question. Although this example pre-dates SSVC by many years, it is illustrative of the situation where a single report leads to multiple advisories.

Coordinator Publication Decision Outcomes

For the CERT/CC, the publication decision is binary: publish or do not publish.

Coordinator Publish Priority

Publish Priority Description
Do not publish Do not publish information about the vulnerability.
Publish Publish information about the vulnerability.

The Publication Decision is Time Sensitive

The publication decision is always a decision at a point in time. As discussed in Guidance on Communicating Results, a SSVC decision may change over time as the inputs to that decision change. A decision to publish cannot be revoked, since the publication is likely to be archived or at least remembered. However, a decision to not publish is a decision not to publish at the time the decision was made. It is not a decision never to publish in the future.

One benefit of encoding the decision process in SSVC is the analysts can all agree on what new information would change the decision and prioritize maintaining awarenss of just those decision points.

CERT/CC Publication Decision Outcomes Over Time

The CERT/CC has a long history of publishing information about vulnerabilities. In the past, the CERT/CC had multiple publication vehicles, including Vulnerability Notes, CERT Advisories, and Current Activity entries. Each of these had different publication criteria. Had we been using SSVC at the time, we might have modeled the publication decision differently for each of these vehicles. Or we might have modeled the decision as a single decision with multiple outcomes, each of which would lead to a different publication vehicle. This is an example of how SSVC can be customized to the needs of the organization using it.

Coordinator Publication Decision Points

The publication decision reuses the Exploitation decision point and adds two new ones (Supplier Involvement and Public Value Added).

  • 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.

More detail about each of these decision points is provided at the links above, here we provide a brief summary of each.

Supplier Involvement v1.0.0

What is the state of the supplier’s work on addressing the vulnerability?

Value Definition
Fix Ready The supplier has provided a patch or fix.
Cooperative The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time.
Uncooperative/Unresponsive The supplier has not responded, declined to generate a remediation, or no longer exists. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SI",
  "name": "Supplier Involvement",
  "description": "What is the state of the supplier\u2019s work on addressing the vulnerability?",
  "values": [
    {
      "key": "FR",
      "name": "Fix Ready",
      "description": "The supplier has provided a patch or fix."
    },
    {
      "key": "C",
      "name": "Cooperative",
      "description": "The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time."
    },
    {
      "key": "UU",
      "name": "Uncooperative/Unresponsive",
      "description": "The supplier has not responded, declined to generate a remediation, or no longer exists."
    }
  ]
}

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. 
{
  "namespace": "ssvc",
  "version": "1.1.0",
  "key": "E",
  "name": "Exploitation",
  "description": "The present state of exploitation of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability."
    },
    {
      "key": "P",
      "name": "Public PoC",
      "description": "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."
    },
    {
      "key": "A",
      "name": "Active",
      "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting."
    }
  ]
}

Public Value Added v1.0.0

How much value would a publication from the coordinator benefit the broader community?

Value Definition
Limited Minimal value added to the existing public information because existing information is already high quality and in multiple outlets.
Ampliative Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc.
Precedence The publication would be the first publicly available, or be coincident with the first publicly available. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "PVA",
  "name": "Public Value Added",
  "description": "How much value would a publication from the coordinator benefit the broader community?",
  "values": [
    {
      "key": "L",
      "name": "Limited",
      "description": "Minimal value added to the existing public information because existing information is already high quality and in multiple outlets."
    },
    {
      "key": "A",
      "name": "Ampliative",
      "description": "Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc."
    },
    {
      "key": "P",
      "name": "Precedence",
      "description": "The publication would be the first publicly available, or be coincident with the first publicly available."
    }
  ]
}

Coordinator Publication Decision Model

An example coordinator publication decision model is shown below. The policy described by the model is based on CERT/CC publication decisions. Other organizations may have different publication criteria and may want to include other decision points in their publication decision model.

Table of Values

row Supplier involvement Exploitation Value added Priority
1 fix ready none precedence publish
2 fix ready none ampliative don't publish
3 fix ready none limited don't publish
4 fix ready PoC precedence publish
5 fix ready PoC ampliative don't publish
6 fix ready PoC limited don't publish
7 fix ready active precedence publish
8 fix ready active ampliative publish
9 fix ready active limited don't publish
10 cooperative none precedence publish
11 cooperative none ampliative don't publish
12 cooperative none limited don't publish
13 cooperative PoC precedence publish
14 cooperative PoC ampliative don't publish
15 cooperative PoC limited don't publish
16 cooperative active precedence publish
17 cooperative active ampliative publish
18 cooperative active limited don't publish
19 uncoop/unresponsive none precedence publish
20 uncoop/unresponsive none ampliative don't publish
21 uncoop/unresponsive none limited don't publish
22 uncoop/unresponsive PoC precedence publish
23 uncoop/unresponsive PoC ampliative publish
24 uncoop/unresponsive PoC limited don't publish
25 uncoop/unresponsive active precedence publish
26 uncoop/unresponsive active ampliative publish
27 uncoop/unresponsive active limited publish

Ended: Coordinator Decision Models

Ended: Stakeholder Decision Models

Modeling Other Decisions and Customization Guidance

Stakeholders are encouraged to customize the SSVC decision process to their needs. Indeed, the first part of SSVC stands for “stakeholder-specific." However, certain parts of SSVC are more amenable to customization than others. In this section, we'll cover what a stakeholder should leave static, what we imagine customization looks like, and some advice on building a usable and manageable decision tree based on our experience so far.

Use Existing Decision Points Where Possible

We suggest that the decision points, their definitions, and the decision values should not be customized. Different vulnerability management teams inevitably think of topics such as Utility to the adversary in slightly different ways. However, a key contribution of SSVC is enabling different teams to communicate about their decision process. In order to clearly communicate differences in the process, the decision points that factor into the process need to be the same between different teams. A stakeholder community may come together and, if there is broad consensus, add or change decision points.

Customizing a Decision Model

Which decision points are involved in a vulnerability management team's decision and the priority label for each resulting situation are, for all intents and purposes, totally at the discretion of the team. We have provided some examples for different stakeholder communities here. What decision points a team considers reflects what it cares about and the risks prioritizes. Different teams may legitimately prioritize different objectives. It should be easier for teams to discuss and communicate such differences if the definitions of the decision points remain static. The other aspect of risk management that SSVC allows a team to customize is its risk appetite or risk tolerance.

Customizing for Risk Appetite

A team's risk appetite is reflected directly by the priority labels for each combination of decision values. For example, a vulnerability with no or minor Public Safety Impact, total Technical Impact, and efficient Utility might be handled with scheduled priority by one team and out-of-cycle priority by another. As long as each team has documented this choice and is consistent in its own application of its own choice, the two teams can legitimately have different appetites for vulnerability risk. SSVC enables teams with such different risk appetites to discuss and communicate precisely the circumstances where they differ.

When doing the detailed risk management work of creating or modifying a tree, we recommend working from text files with one line or row for each unique combination of decision values. For examples, see SSVC/data. An important benefit, in our experience, is that it is easier to identify a question by saying “I'm unsure about row 16” than anything else we have thought of so far. Once the humans agree on the decision tree, it can be converted to a JSON schema for easier machine-readable communication, following the provided SSVC provision JSON schema.

Once the decision points are selected and the prioritization labels agreed upon, it is convenient to be able to visually compress the text file by displaying it as a decision tree. Making the decision process accessible has a lot of benefits. Unfortunately, it also makes it a bit too easy to overcomplicate the decision.

The academic literature surrounding the measurement of decision tree quality is primarily concerned with measuring classification errors given a particular tree and a labeled data set. In our case, we are not attempting to fit a tree to data. Rather, we are interested in producing usable trees that minimize extraneous effort. To that end, we briefly examine the qualities for which decision tree measurement is suitable.

Decision Tree Construction Concerns

Decision tree construction methods must address five significant concerns: - feature selection - feature type - overfitting - parsimony - versioning

Feature selection

Feature selection is perhaps the most important consideration for SSVC, because it directly affects the information gathering requirements placed on the analyst attempting to use the tree. Each decision point in SSVC is a feature.

The SSVC version 1 applier deployer tree had 225 rows when we wrote it out in long text form. It only has four outcomes to differentiate between. Thus, on average that decision process treats one situation (combination of decision values) as equivalent to 65 other situations. If nothing else, this means analysts are spending time gathering evidence to make fine distinctions that are not used in the final decision. The added details also make it harder for the decision process to accurately manage the risks in question. This difficulty arises because more variance and complexity there is in the decision increases the possibility of errors in the decision process itself.

Feature types

Regarding feature types, all of the features included in SSVC version 2 can be considered ordinal data. That is, while they can be ordered (e.g., for Exploitation, active is greater than poc is greater than none), they can not be compared via subtraction or division (active - poc = nonsense). The use of ordinal features is a key assumption behind our use of the parsimony analysis that follows.

Overfitting

When decision trees are used in a machine learning context, overfitting increases tree complexity by incorporating the noise in the training data set into the decision points in a tree. In our case, our “data” is just the set of outcomes as decided by humans, so overfitting is less of a concern, assuming the feature selection has been done with care.

Parsimony

Parsimony is, in essence, Occam's Razor applied to tree selection. Given the choice between two trees that have identical outputs, one should choose the tree with fewer decisions. One way to evaluate the parsimony of a tree is by applying the concept of feature importance to ensure that each feature is contributing adequately to the result. While there are a few ways to compute feature importance, the one we found most useful is permutation importance. Permutation importance can be calculated on a candidate tree to highlight potential issues. It works by randomly shuffling the values for each feature individually and comparing a fitness metric on the shuffled tree to the original. The change in fitness is taken to be the importance of the feature that was shuffled. Permutation importance is usually given as a number in the interval [0,1]. Python's scikit-learn 1 provides a permutation importance method, which we used to evaluate our trees.

Interpreting the results of a permutation importance computation on a tree involves nuance, but one rule we can state is this: any feature with a computed permutation importance of zero can be eliminated from the tree without losing any relevant information. When all of the permutation importance scores for all features are relatively equal, that is an indication that each feature is approximately equally relevant to the decision.

More likely, however, is that some subset of features will be of relatively equal importance, and one might be of considerably lower importance (yet not zero). In this case, the lowest importance feature should be considered for refinement or elimination. It is possible that adjusting the definition of a feature or its available values (whether redefining, adding, or removing options) could increase its importance. Reasons to retain a low-importance feature include: * the feature is relevant to a small set of important circumstances that a tree without the feature would otherwise be unable to discriminate * the effort required to determine the correct value for the feature is relatively small, for example information that might be collected automatically * the feature enables other features to be defined more clearly Features that meet none of the above criteria may be good candidates for elimination.

Customizing a tree by changing the outcome priority labels can also affect the importance of a feature. This sort of customization is often the simplest way to adjust the importance of a feature.

While there is no hard and fast rule for when a tree is too big, we suggest that if all of your outcomes are associated with more than 15 situations (unique combinations of decision values), you would benefit from asking whether your analysts actually use all the information they would be gathering. Thus, 60 unique combinations of decision values is the point at which a decision tree with four distinct outcomes is, on average, potentially too big.

Tree Versioning

SSVC trees should be identifiable by name and version. A tree name is simply a short descriptive label for the tree derived from the stakeholder and/or function the tree is intended for. Tree versions are expected to share the major and minor version numbers with the SSVC version in which their decision points are defined. Revisions should increment the patch number. For example: “Applier Tree v1.1.0” would be the identity of the version of the Applier Tree as published in version 1.1 of SSVC. “Coordinator Publish Tree v2.0.3” would be the identity of a future revision of the Coordinator Publish Tree as described in this document. The terms “major”, “minor”, and “patch” with respect to version numbering are intended to be consistent with Semantic Versioning 2.0.0.

Sharing Trees With Others

Communities of shared interest may desire to share information about decision points or even create custom trees to share within their community. Examples include: - an Information Sharing and Analysis Organization (ISAO) within a critical infrastructure sector might want to define a custom decision point relevant to their constituents' regulatory compliance. - a corporate Computer Security Incident Response Team (CSIRT) might choose to adjust decision priorities for an existing tree for use by its subsidiaries. - a government department might define a separate tree using existing decision points to address a particular governance process within their constituent agencies. - a regional coordinator might want to produce decision point information as a product of its threat analysis work and provide this information to its constituency in an advisory.

In these and other scenarios, there are two scopes to consider: 1. Decision Point Scope 2. Decision Tree Scope

Decision Point Scope

Each decision point defined in this document has a characteristic scope, either stakeholder-agnostic or stakeholder-specific.

  • Stakeholder-agnostic decision points describe the state of the world outside the stakeholder's environment. One might think of them as global facts that form the background context in which the stakeholder is making a prioritization decision. Nearly all stakeholders should agree on the assignment of specific values to these decision points.
  • Stakeholder-specific decision points are expected to be contextual to some set of stakeholders. Information about a stakeholder-specific decision point can still be inherited by other stakeholders using the same tree. For example in the corporate CSIRT scenario above, the System Exposure value might be consistent across all subsidiaries for a centrally managed service.

We generally consider the following decision points to be stakeholder-agnostic: - Exploitation - Technical Impact - Automatable

On the contrary, we consider the following decision points to be stakeholder-specific: - Value Density - Utility - Safety Impact - Public Safety Impact - Situated Safety Impact - Mission Impact - Human Impact - System Exposure

We anticipate that most custom decision points created by stakeholders for themselves or a constituency will be of the stakeholder-specific variety. Examples of these sorts of custom decision points include - A decision point indicating whether a system or mission context is affected by regulatory oversight that might alter the decision priority. E.g., a healthcare-focused ISAO might define a decision point about whether a vulnerability affects patient data privacy protection. - A decision point that incorporates the concept of change risk to a deployer. E.g., a financial institution might have a very low tolerance for changes to a transaction clearing system. - A decision point that indicates whether the affected software belongs to a list of critical software for a specific constituency. E.g., an open-source consortium might want to prioritize fix development for a set of key projects.

Decision Tree Scope

Two kinds of modifications are possible at the decision tree level.

  • A Risk Appetite Shift retains the structure of an existing tree and all its decision points, and simply adjusts the decision outputs according to the stakeholder's risk appetite. For example, an organization with sufficient resources to efficiently deploy fixes might choose to defer fewer cases than the default tree would recommend.
  • Tree Customization can be done in one of three ways:
  • incorporating an already-defined decision point into an existing tree that does not already contain it.
  • defining a new decision point and adding it to an existing tree. Note that adding or removing an option from an existing decision point should be treated as creating a new decision point. The new decision point should be given a distinct name as well.
  • defining a new tree entirely from existing or new decision points.

Because tree customization changes the tree structure and implies the addition or removal of leaf nodes, it will be necessary for the organization to review the decision outputs in light of its risk appetite as well.

Risk-shifted or customized trees can be shared among a community of interest, of course. Further customization within each stakeholder remains an option as well, although there is likely a diminishing return on more than a few layers of customization for the same basic decision. Of course, SSVC users might choose to construct other trees to inform other decisions.

  1. F. Pedregosa, G. Varoquaux, A. Gramfort, V. Michel, B. Thirion, O. Grisel, M. Blondel, P. Prettenhofer, R. Weiss, V. Dubourg, J. Vanderplas, A. Passos, D. Cournapeau, M. Brucher, M. Perrot, and E. Duchesnay. Scikit-learn: machine learning in Python. Journal of Machine Learning Research, 12:2825–2830, 2011. ↩

Acuity Ramp

Why Acuity? Isn't this a Maturity Model?

The acuity ramp concept is similar to the idea of a maturity model, but the term maturity carries a sort of moral bias in the sense that it has an implied "good" direction from "immature" to "mature".

Acuity has a more neutral connotation, and represents the ability to perceive the world in more detail. In our usage, Acuity as a dimension is more akin to the idea of resolution in the imagery/photography sense.

Given the choice between a lower-resolution and a higher-resolution decision point, stakeholders should choose the one that is most appropriate for both their decision and context. It is not inherently better to use a higher-resolution decision point, and it is not inherently worse to use a lower-resolution decision point.

An SSVC acuity ramp is a concept that describes a series of decision functions that are increasingly more detailed and complex while addressing the same decision. The idea is that a decision maker can start with a simple decision model and then, as their needs, resources, or abilities change, they can gather and analyze more or different data to understand their environment with more acuity.

Acuity Tradeoffs

In Cybersecurity Threat and Vulnerability analysis, as with most decision-making processes, decision makers must balance trade-offs between the volume, quality, or detail of the information they use and the cost of gathering and analyzing that information. There are many good reasons that decision makers might choose to use a lower resolution indicator that is readily available over a higher resolution indicator that comes at a high cost in terms of time, money, or effort.

One way to think about the tradeoffs in acuity is to consider the cost or difficulty of gathering and analyzing data. Some vulnerability information is readily available for free as a public resource. Other information is available for purchase, for example as a subscription to a threat intelligence feed. Still other information is only available if you set up a system to collect and manage it yourself, such as an internal asset management system. For direct cost tradeoffs, one might conduct a cost-benefit analysis of whether the additional acuity provides value more than its cost. Sometimes, tradeoffs are not directly cost-based.

The quality and readiness for use of the information can also vary. Structured, low resolution public data might be easier to incorporate into a decision model than unstructured data that requires a lot of manual analysis. At the CERT/CC, we have observed otherwise high quality threat intelligence provided as PDF files with threat indicators embedded as screenshots of text, which would be difficult to extract and use in a decision model.

Another tradeoff is that sometimes one decision point can serve as a close-enough proxy for another decision point that is more costly or difficult to acquire. For example, in a given deployment context, Value Density might be more readily discerned than Mission Impact for some stakeholders because it's easier to count how many of something there are than to estimate the impact of a loss of specific instances of the thing. Alternately, information about Value Density might be available from another source, such as a CVSS v4 scoring provider, whereas Mission Impact might require a more detailed understanding of the stakeholder's mission and environment. An organization might start with Value Density as a proxy for Mission Impact and then, as they develop a better understanding of their environment, they could replace Value Density with Mission Impact in their decision model.

An Acuity Ramp in Action

The acuity ramp idea is a way to show how a stakeholder could "grow into" their desired decision function as their data collection and analysis capabilities increase. We demonstrate this with the following example.

An Acuity Ramp for a Growing System Deployer Organization

A system deployer organization with few initial resources might start with a simple decision model that only includes a custom IN_KEV decision point. The IN_KEV decision point would be a simple binary indicator of whether a vulnerability has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog. Because this information is free, publicly available, and because it is a simple binary indicator, it is easy to gather and analyze even for a very small organization.

The following table shows how the organization might expand their decision model as they grow in capability.

Acutiy Level Tree
1 [IN_KEV]
2 [EXPLOITATION_1]
3 [EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1]
4 [EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1, AUTOMATABLE_2]
5 [EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1, AUTOMATABLE_2, MISSION_IMPACT_2, SAFETY_IMPACT_1]

Acuity Levels are Stakeholder-Specific

This example is demonstrating the concept of acuity levels in SSVC adoption. We are specifically not saying that there are 5 levels of acuity in SSVC; in principle this concept could be applied to any number of levels (including just one). In practice, the number of levels necessary would be a stakeholder-specific implementation choice, so there is no inherent meaning to the "Acuity Levels" shown here outside the context of this example.

The remainder of this example shows one path the organization might take to grow their decision model according to the table above.

Improved Exploit Awareness (Acuity Level 2)

As the organization becomes more capable of gathering and analyzing data, they might start collecting their own data on exploitation, allowing them to move to a more detailed decision model that replaces the binary IN_KEV decision point with the trinary EXPLOITATION_1 decision point. For example, they might incorporate data from the Exploit Database or the Exploit Prediction Scoring System (EPSS) into their decision model.

Exploitation v1.0.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.
PoC One of the following cases is true: (1) private evidence of exploitation is attested but not shared; (2) widespread hearsay attests to exploitation; (3) typical public PoC in places such as Metasploit or ExploitDB; or (4) 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. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "E",
  "name": "Exploitation",
  "description": "The present state of exploitation of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability."
    },
    {
      "key": "P",
      "name": "PoC",
      "description": "One of the following cases is true: (1) private evidence of exploitation is attested but not shared; (2) widespread hearsay attests to exploitation; (3) typical public PoC in places such as Metasploit or ExploitDB; or (4) the vulnerability has a well-known method of exploitation."
    },
    {
      "key": "A",
      "name": "Active",
      "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting."
    }
  ]
}

Improved Asset Management (Acuity Level 3)

As they continue to develop their internal asset management capabilities, they might find they have enough asset data to reflect the degree to which a system is exposed to the internet, allowing them to incorporate the SYSTEM_EXPOSURE_1_0_1 decision point into their decision model.

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) 
{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "EXP",
  "name": "System Exposure",
  "description": "The Accessible Attack Surface of the Affected System or Service",
  "values": [
    {
      "key": "S",
      "name": "Small",
      "description": "Local service or program; highly controlled network"
    },
    {
      "key": "C",
      "name": "Controlled",
      "description": "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\u2019s 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."
    },
    {
      "key": "O",
      "name": "Open",
      "description": "Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers)"
    }
  ]
}

Improved Threat and Vulnerability Analysis (Acuity Level 4)

Over time, the organization's threat and vulnerability analysis capabilities might reach a point where they can begin to collect data on the degree to which a vulnerability is automatable, allowing them to incorporate the AUTOMATABLE_1 decision point into their decision model. This decision point might be informed by data from the National Vulnerability Database (NVD) or by translating CVSS v3 or v4 scores into a value for this decision point.

Automatable v2.0.0

Can an attacker reliably automate creating exploitation events for this vulnerability?

Value Definition
No Attackers cannot reliably automate steps 1-4 of the kill chain for this vulnerability. These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation.
Yes Attackers can reliably automate steps 1-4 of the kill chain. 
{
  "namespace": "ssvc",
  "version": "2.0.0",
  "key": "A",
  "name": "Automatable",
  "description": "Can an attacker reliably automate creating exploitation events for this vulnerability?",
  "values": [
    {
      "key": "N",
      "name": "No",
      "description": "Attackers cannot reliably automate steps 1-4 of the kill chain for this vulnerability. These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation."
    },
    {
      "key": "Y",
      "name": "Yes",
      "description": "Attackers can reliably automate steps 1-4 of the kill chain."
    }
  ]
}

Improved Mission and Safety Impact Understanding (Acuity Level 5)

Now that the deployer organization has been at this for a while, they might have a better understanding of the degree to which a vulnerability impacts both their mission and public safety, allowing them to incorporate the MISSION_IMPACT_2 and SAFETY_IMPACT_1 decision points into their decision model.

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 
{
  "namespace": "ssvc",
  "version": "2.0.0",
  "key": "MI",
  "name": "Mission Impact",
  "description": "Impact on Mission Essential Functions of the Organization",
  "values": [
    {
      "key": "D",
      "name": "Degraded",
      "description": "Little to no impact up to degradation of non-essential functions; chronic degradation would eventually harm essential functions"
    },
    {
      "key": "MSC",
      "name": "MEF Support Crippled",
      "description": "Activities that directly support essential functions are crippled; essential functions continue for a time"
    },
    {
      "key": "MEF",
      "name": "MEF Failure",
      "description": "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"
    },
    {
      "key": "MF",
      "name": "Mission Failure",
      "description": "Multiple or all mission essential functions fail; ability to recover those functions degraded; organization\u2019s ability to deliver its overall mission fails"
    }
  ]
}

Safety Impact v1.0.0

The safety impact of the vulnerability.

Value Definition
None The effect is below the threshold for all aspects described in Minor.
Minor Any one or more of these conditions hold. Physical harm: Physical discomfort for users (not operators) of the system. 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.
Major Any one or more of these conditions hold. Physical harm: Physical distress and injuries for users (not operators) of the system. 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.
Hazardous Any one or more of these conditions hold. Physical harm: Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures. 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 immediate fatalities (Emergency response probably cannot save the victims.) 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. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SI",
  "name": "Safety Impact",
  "description": "The safety impact of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "The effect is below the threshold for all aspects described in Minor."
    },
    {
      "key": "M",
      "name": "Minor",
      "description": "Any one or more of these conditions hold. Physical harm: Physical discomfort for users (not operators) of the system. 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."
    },
    {
      "key": "J",
      "name": "Major",
      "description": "Any one or more of these conditions hold. Physical harm: Physical distress and injuries for users (not operators) of the system. 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."
    },
    {
      "key": "H",
      "name": "Hazardous",
      "description": "Any one or more of these conditions hold. Physical harm: Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures. 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\u2019s 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."
    },
    {
      "key": "C",
      "name": "Catastrophic",
      "description": "Any one or more of these conditions hold. Physical harm: Multiple immediate fatalities (Emergency response probably cannot save the victims.) 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."
    }
  ]
}

In this way, the organization can grow into a more detailed decision model as their understanding and capabilities improve.

Conclusion

The acuity ramp concept is a way to show how a stakeholder could "grow into" their desired decision function as their data collection and analysis capabilities improve. It is a way to show how a decision model can be adapted to the context of the decision maker, and how the decision maker can make trade-offs between the cost of gathering information and the quality of the decision they are able to make.

The example above is just a single illustration of the acuity ramp concept. There are many other ways that an organization might evolve their decision model from a simple starting point toward a more detailed decision model for any particular decision. Substituting one decision point for another, adding decision points over time, or even customizing decision points to better fit the organization's specific context are all ways that an organization might grow from a simple decision model to a more robust one.

Ended: SSVC How-To

Reference ↵

SSVC Reference

Prerequisites

This section assumes that you are already familiar with SSVC and want to look up specific details.

If you are new to SSVC, you may want to start with the Learning SSVC section. If you are already familiar with SSVC and want to learn more, you may want to start with either the Understanding SSVC or SSVC How To sections.

In this section, we provide reference documentation for SSVC. We have organized the reference documentation into two main sections:

Likely Decision Points and Relevant Data

Feedback Welcome

We made every effort to put forward informed and useful decision frameworks with wide applicability, but the goal of this documentation is more to solicit feedback than make a declaration. We welcome questions, constructive criticism, refuting evidence, or supporting evidence about any aspect of this proposal. Please submit feedback to the GitHub repository.

We propose the following decision points and associated values should be a factor when making decisions about vulnerability prioritization. We emphasize that these descriptions are hypotheses to be further tested and validated.

We propose satisfactory decision points for vulnerability management in the next sections, in alphabetical order. Each decision point page includes advice on gathering information about the decision point. SSVC using Current Information Sources provides some suggestions about how existing sources of information about vulnerabilities can be used to collate responses to these decision points.

Decision Point Values are Ordered Sets

The values for each decision point are ordered sets, meaning that the order of the values is significant. The ordering of the values is intended to reflect the relative importance of the values, with the first value being the least important and the last value being the most important. By requiring ordered sets, we can apply consistency checks that ensure that the outcome priority of a set of decision point values is greater than or equal to the outcome priority of another set of decision point values if the first set of values is greater than or equal to the second set of values in every dimension.

What determines the ordering?

The relevant dimension to which the ordering for both decision points and outcomes applies can be different for different decision points and outcomes. Sometimes this is a "better" or "worse" dimension, but it seems to generalize to a "more likely to act" or "less likely to act" of dimension.

Where are the Unknown options?

One important omission from the values for each category is an unknown option. Instead, we recommend explicitly identifying an option that is a reasonable assumption based on prior events. Such an option requires reliable historical evidence for what tends to be the case; of course, future events may require changes to these assumptions over time. Therefore, our assumptions require evidence and are open to debate in light of new evidence. Different risk tolerance or risk discounting postures are not addressed in the current work; accommodating such tolerance or discounting explicitly is an area for future work. This flexibility fits into our overall goal of supplying a decision-making framework that is both transparent and fits the needs of different communities. Resisting an unknown option discourages the modeler from silently embedding these assumptions in their choices for how the decision tree flows below the selection of any unknown option.

Automatable

Automatable v2.0.0

Can an attacker reliably automate creating exploitation events for this vulnerability?

Value Definition
No Attackers cannot reliably automate steps 1-4 of the kill chain for this vulnerability. These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation.
Yes Attackers can reliably automate steps 1-4 of the kill chain. 
{
  "namespace": "ssvc",
  "version": "2.0.0",
  "key": "A",
  "name": "Automatable",
  "description": "Can an attacker reliably automate creating exploitation events for this vulnerability?",
  "values": [
    {
      "key": "N",
      "name": "No",
      "description": "Attackers cannot reliably automate steps 1-4 of the kill chain for this vulnerability. These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation."
    },
    {
      "key": "Y",
      "name": "Yes",
      "description": "Attackers can reliably automate steps 1-4 of the kill chain."
    }
  ]
}

See also

Automatable combines with Value Density to inform Utility

Automatable captures the answer to the question “Can an attacker reliably automate creating exploitation events for this vulnerability?”

What are Steps 1-4 of the Kill Chain?

These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation.

When is Automatable no?

Reasons why a step may not be reliably automatable could include the following:

  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
  4. exploitation is not reliable, due to exploit-prevention techniques (e.g., ASLR) enabled by default

When is Automatable yes?

If the vulnerability allows remote code execution or command injection, the expected response should be yes.

Due to vulnerability chaining, there is some nuance as to whether reconnaissance can be automated.

Vulnerability Chaining

For example, consider a vulnerability A. If the systems vulnerable to A are usually not openly connected to incoming traffic (that is, Exposure is small or controlled), reconnaissance probably cannot be automated (scans would be blocked, etc.). This would make Automatable equal to no for vulnerability A. However, suppose that another vulnerability B where Automatable is equal to yes can be reliably used to chain to vulnerability A. This automates the reconnaissance of vulnerable systems. In this situation, the analyst should continue to analyze vulnerability A to understand whether the remaining steps in the kill chain can be automated.

Gathering Information About Automatable

An analyst should be able to sketch the automation scenario and how it either does or does not satisfy each of the four kill chain steps. Once one step is not satisfied, the analyst can stop and select no. Code that demonstrably automates all four kill chain steps certainly satisfies as a sketch. We say sketch to indicate that plausible arguments, such as convincing psuedocode of an automation pathway for each step, are also adequate evidence in favor of a yes to Automatable.

Like all SSVC decision points, Automatable should capture the analyst's best understanding of plausible scenarios at the time of the analysis. An answer of no does not mean that it is absolutely inconceivable to automate exploitation in any scenario. It means the analyst is not able to sketch a plausible path through all four kill chain steps. “Plausible” sketches should account for widely deployed network and host-based defenses. Liveness of Internet-connected services means quite a few overlapping things 1. For most vulnerabilities, an open port does not automatically mean that reconnaissance, weaponization, and delivery are automatable. Furthermore, discovery of a vulnerable service is not automatable in a situation where only two hosts are misconfigured to expose the service out of 2 million hosts that are properly configured. As discussed in in Reasoning Steps Forward, the analyst should consider credible effects based on known use cases of the software system to be pragmatic about scope and providing values to decision points.

Prior Versions

Virulence v1.0.0

The speed at which the vulnerability can be exploited.

Value Definition
Slow Steps 1-4 of the kill chain cannot be reliably automated for this vulnerability for some reason. These steps are reconnaissance, weaponization, delivery, and exploitation.
Rapid Steps 1-4 of the of the kill chain can be reliably automated. If the vulnerability allows remote code execution or command injection, the default response should be rapid. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "V",
  "name": "Virulence",
  "description": "The speed at which the vulnerability can be exploited.",
  "values": [
    {
      "key": "S",
      "name": "Slow",
      "description": "Steps 1-4 of the kill chain cannot be reliably automated for this vulnerability for some reason. These steps are reconnaissance, weaponization, delivery, and exploitation."
    },
    {
      "key": "R",
      "name": "Rapid",
      "description": "Steps 1-4 of the of the kill chain can be reliably automated. If the vulnerability allows remote code execution or command injection, the default response should be rapid."
    }
  ]
}

Virulence is Superseded by Automatable

Virulence is superseded by Automatable, which clarified the concept we we were attempting to capture.

  1. Shehar Bano, Philipp Richter, Mobin Javed, Srikanth Sundaresan, Zakir Durumeric, Steven J Murdoch, Richard Mortier, and Vern Paxson. Scanning the internet for liveness. SIGCOMM Computer Communication Review, 48(2):2–9, 2018. ↩

Exploitation

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. 
{
  "namespace": "ssvc",
  "version": "1.1.0",
  "key": "E",
  "name": "Exploitation",
  "description": "The present state of exploitation of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability."
    },
    {
      "key": "P",
      "name": "Public PoC",
      "description": "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."
    },
    {
      "key": "A",
      "name": "Active",
      "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting."
    }
  ]
}

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 1.

Gathering Information About Exploitation

2 presents a method for searching the GitHub repositories of open-source exploit databases. This method could be employed to gather information about whether PoC is true. However, part (3) of PoC would not be represented in such a search, so more information gathering would be needed. For part (3), one approach is to construct a mapping of CWE-IDs which always represent vulnerabilities with well-known methods of exploitation. We provide a list of possible CWE-IDs for this purpose below.

Gathering information for active is a bit harder. If the vulnerability has a name or public identifier (such as a CVE-ID), a search of news websites, Twitter, the vendor's vulnerability description, and public vulnerability databases for mentions of exploitation is generally adequate. However, if the organization has the ability to detect exploitation attempts—for instance, through reliable and precise IDS signatures based on a public PoC—then detection of exploitation attempts also signals that active is the right choice. Determining which vulnerability a novel piece of malware uses may be time consuming, requiring reverse engineering and a lot of trial and error. Additionally, capable incident detection and analysis capabilities are required to make reverse engineering possible. Because most organizations do not conduct these processes fully for most incidents, information about which vulnerabilities are being actively exploited generally comes from public reporting by organizations that do conduct these processes. As long as those organizations also share detection methods and signatures, the results are usually quickly corroborated by the community. For these reasons, we assess public reporting by established security community members to be a good information source for active; however, one should not assume it is complete.

The description for none says that there is no evidence of active exploitation. This framing admits that an analyst may not be able to detect or know about every attack. Acknowledging that Exploitation values can change relatively quickly, we recommend conducting these searches frequently: if they can be automated to the organization's satisfaction, perhaps once a day (see also Guidance on Communicating Results). An analyst should feel comfortable selecting none if they (or their search scripts) have performed searches in the appropriate places for public PoCs and active exploitation (as described above) and found none. Acknowledging that Exploitation.

CWE-IDs for PoC

The table below lists CWE-IDs that could be used to mark a vulnerability as PoC if the vulnerability is described by the CWE-ID.

CWE-295

For example, CWE-295, Improper Certificate Validation , and its child CWEs,
describe improper validation of TLS certificates. These CWE-IDs could always be marked as PoC since that meets condition (3) in the definition.

CWE-ID CWE name In NVD's CWE Slice? Possible PoC? How could vulnerabilities containing this CWE be exploited? Tools Links to tools
20 Improper Input Validation yes no nan nan nan
22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') yes yes directory/path traversal "../" Panoptic; Burp Suite https://github.com/lightos/Panoptic; https://portswigger.net/burp
59 Improper Link Resolution Before File Access ('Link Following') yes yes symlink attack No specialized resources are required to execute this type of attack. The only requirement is the ability to create the necessary symbolic link. https://capec.mitre.org/data/definitions/132.html
73 External Control of File Name or Path no no nan nan nan
74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') yes no nan nan nan
77 Improper Neutralization of Special Elements used in a Command ('Command Injection') yes yes command injection Commix https://github.com/commixproject/commix
78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') yes yes OS command injection Commix; Burp Suite https://github.com/commixproject/commix; https://portswigger.net/burp
79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') yes yes cross-site scripting attack XSSER; Pybelt; XSStrike https://github.com/epsylon/xsser; https://github.com/Ekultek/Pybelt; https://github.com/s0md3v/XSStrike
88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') yes yes argument/parameter injection Argument Injection Hammer https://github.com/nccgroup/argumentinjectionhammer
89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') yes yes malicious SQL command injection SQLMap; BBQSQL; JSQL injection; NoSQLMap https://github.com/sqlmapproject/sqlmap; https://github.com/CiscoCXSecurity/bbqsql; https://github.com/ron190/jsql-injection; https://github.com/codingo/NoSQLMap
91 XML Injection (aka Blind XPath Injection) yes yes inject XML code into a web input, XML file or stream XXExploiter https://github.com/luisfontes19/xxexploiter
94 Improper Control of Generation of Code ('Code Injection') yes no nan nan nan
115 Misinterpretation of Input no no nan nan nan
116 Improper Encoding or Escaping of Output yes no nan nan nan
119 Improper Restriction of Operations within the Bounds of a Memory Buffer yes no nan nan nan
120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') yes no nan nan nan
122 Heap-based Buffer Overflow no no nan nan nan
125 Out-of-bounds Read yes no nan nan nan
129 Improper Validation of Array Index yes no nan nan nan
131 Incorrect Calculation of Buffer Size yes no nan nan nan
134 Use of Externally-Controlled Format String yes no nan nan nan
178 Improper Handling of Case Sensitivity yes no nan nan nan
190 Integer Overflow or Wraparound yes no nan nan nan
191 Integer Underflow (Wrap or Wraparound) yes no nan nan nan
193 Off-by-one Error yes no nan nan nan
194 Unexpected Sign Extension no no nan nan nan
200 Exposure of Sensitive Information to an Unauthorized Actor yes no nan nan nan
201 Insertion of Sensitive Information Into Sent Data no no nan nan nan
203 Observable Discrepancy yes no nan nan nan
209 Generation of Error Message Containing Sensitive Information yes yes read/capture sensitive information contained in error message OWASP ZAP; Burp Suite https://www.zaproxy.org/; https://portswigger.net/burp
212 Improper Removal of Sensitive Information Before Storage or Transfer yes no nan nan nan
252 Unchecked Return Value yes no nan nan nan
257 Storing Passwords in a Recoverable Format no no nan nan nan
264 Permissions, Privileges, and Access Controls no no nan nan nan
269 Improper Privilege Management yes no nan nan nan
273 Improper Check for Dropped Privileges yes no nan nan nan
275 Permission Issues no no nan nan nan
276 Incorrect Default Permissions yes yes try to access data or privileges you normally should not have access to No specialized resources are required to execute this type of attack. In order to discover unrestricted resources, the attacker does not need special tools or skills. They only have to observe the resources or access mechanisms invoked as each action is performed and then try and access those access mechanisms directly. https://capec.mitre.org/data/definitions/1.html
280 Improper Handling of Insufficient Permissions or Privileges no no nan nan nan
281 Improper Preservation of Permissions yes no nan nan nan
284 Improper Access Control no no nan nan nan
287 Improper Authentication yes no nan nan nan
290 Authentication Bypass by Spoofing yes no nan nan nan
294 Authentication Bypass by Capture-replay yes yes capture-replay attack Wireshark; smartsniff https://www.wireshark.org/; https://www.nirsoft.net/utils/smsniff.html
295 Improper Certificate Validation yes no nan nan nan
305 Authentication Bypass by Primary Weakness no no nan nan nan
306 Missing Authentication for Critical Function yes no nan nan nan
307 Improper Restriction of Excessive Authentication Attempts yes yes brute force attack THC Hydra; John the Ripper; L0phtCrack; Hashcat https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/
311 Missing Encryption of Sensitive Data yes no nan nan nan
312 Cleartext Storage of Sensitive Information yes yes find sensitive data stored in system OWASP ZAP; Burp Suite https://www.zaproxy.org/; https://portswigger.net/burp
319 Cleartext Transmission of Sensitive Information yes yes capture traffic and extract sensitive information Wireshark; Smartsniff https://www.wireshark.org/; https://www.nirsoft.net/utils/smsniff.html
321 Use of Hard-coded Cryptographic Key no no nan nan nan
326 Inadequate Encryption Strength yes no nan nan nan
327 Use of a Broken or Risky Cryptographic Algorithm yes no nan nan nan
330 Use of Insufficiently Random Values yes yes brute force attack THC Hydra; John the Ripper; L0phtCrack; Hashcat https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/
331 Insufficient Entropy yes yes brute force attack/predictive programs hashcat; php_mt_seed https://hashcat.net/hashcat/; https://github.com/openwall/php_mt_seed
335 Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG) yes no nan nan nan
337 Predictable Seed in Pseudo-Random Number Generator (PRNG) no no nan nan nan
338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) yes no nan nan nan
345 Insufficient Verification of Data Authenticity yes no nan nan nan
346 Origin Validation Error yes no nan nan nan
347 Improper Verification of Cryptographic Signature yes no nan nan nan
352 Cross-Site Request Forgery (CSRF) yes yes CSRF Burp Suite; XSRFProbe https://portswigger.net/burp; https://github.com/0xInfection/XSRFProbe
354 Improper Validation of Integrity Check Value yes no nan nan nan
362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') yes no nan nan nan
367 Time-of-check Time-of-use (TOCTOU) Race Condition yes no nan nan nan
369 Divide By Zero yes no nan nan nan
384 Session Fixation yes no nan nan nan
388 7PK - Errors no no nan nan nan
400 Uncontrolled Resource Consumption yes no nan nan nan
401 Missing Release of Memory after Effective Lifetime yes no nan nan nan
404 Improper Resource Shutdown or Release yes no nan nan nan
405 Asymmetric Resource Consumption (Amplification) no no nan nan nan
407 Inefficient Algorithmic Complexity yes no nan nan nan
415 Double Free yes no nan nan nan
416 Use After Free yes no nan nan nan
425 Direct Request ('Forced Browsing') yes yes forcibly navigate to unintended (by the system) URLs Dirbuster; Dirstalk https://sourceforge.net/projects/dirbuster/; https://github.com/stefanoj3/dirstalk
426 Untrusted Search Path yes yes malicious dll injection/loading evildll; evilldll-gen https://github.com/CrackerCat/evildll; https://gist.github.com/klezVirus/e24c94d7061f5736e2452eee022f4011
427 Uncontrolled Search Path Element yes yes malicious dll injection/loading evildll; evilldll-gen https://github.com/CrackerCat/evildll; https://gist.github.com/klezVirus/e24c94d7061f5736e2452eee022f4011
428 Unquoted Search Path or Element yes yes insert malicious input into unquoted search path Metasploit https://www.metasploit.com/
434 Unrestricted Upload of File with Dangerous Type yes yes uploading of malicious file (program lacks restrictions to prevent this from occuring) No specialized resources are required to execute this type of attack. https://capec.mitre.org/data/definitions/1.html
436 Interpretation Conflict yes no nan nan nan
441 Unintended Proxy or Intermediary ('Confused Deputy') no no nan nan nan
444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') yes yes HTTP smuggling Smuggler https://github.com/defparam/smuggler
451 User Interface (UI) Misrepresentation of Critical Information no no nan nan nan
459 Incomplete Cleanup yes no nan nan nan
470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') yes no nan nan nan
476 NULL Pointer Dereference yes no nan nan nan
494 Download of Code Without Integrity Check yes no nan nan nan
502 Deserialization of Untrusted Data yes no nan nan nan
521 Weak Password Requirements yes yes brute force attack THC Hydra; John the Ripper; L0phtCrack; Hashcat https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/
522 Insufficiently Protected Credentials yes yes search for exposed credentials, capture traffic, or brute force (context-dependent) Context-dependent, may utilize traffic sniffing tools, tools for discovering sensitive information, or brute forcing tools https://www.wireshark.org/; https://www.nirsoft.net/utils/smsniff.html; https://www.zaproxy.org/; https://portswigger.net/burp; https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/
532 Insertion of Sensitive Information into Log File yes yes access log files and search them for sensitive information OWASP ZAP; Burp Suite - along with the ability to access log files https://www.zaproxy.org/; https://portswigger.net/burp
552 Files or Directories Accessible to External Parties yes no nan nan nan
565 Reliance on Cookies without Validation and Integrity Checking yes no nan nan nan
592 Authentication Bypass Issues no no nan nan nan
601 URL Redirection to Untrusted Site ('Open Redirect') yes no nan nan nan
602 Client-Side Enforcement of Server-Side Security no no nan nan nan
610 Externally Controlled Reference to a Resource in Another Sphere yes no nan nan nan
611 Improper Restriction of XML External Entity Reference yes yes XML external entity injection XXExploiter https://github.com/luisfontes19/xxexploiter
613 Insufficient Session Expiration yes no nan nan nan
617 Reachable Assertion yes no nan nan nan
639 Authorization Bypass Through User-Controlled Key yes yes modify key values to change what data attacker has access to, insecure direct object vulnerability exploit AuthZ for burpsuite https://portswigger.net/bappstore/4316cc18ac5f434884b2089831c7d19e
640 Weak Password Recovery Mechanism for Forgotten Password yes no nan nan nan
662 Improper Synchronization yes no nan nan nan
665 Improper Initialization yes no nan nan nan
667 Improper Locking yes no nan nan nan
668 Exposure of Resource to Wrong Sphere yes no nan nan nan
669 Incorrect Resource Transfer Between Spheres yes no nan nan nan
670 Always-Incorrect Control Flow Implementation yes no nan nan nan
672 Operation on a Resource after Expiration or Release yes no nan nan nan
674 Uncontrolled Recursion yes no nan nan nan
681 Incorrect Conversion between Numeric Types yes no nan nan nan
682 Incorrect Calculation yes no nan nan nan
697 Incorrect Comparison yes no nan nan nan
703 Improper Check or Handling of Exceptional Conditions no no nan nan nan
704 Incorrect Type Conversion or Cast yes no nan nan nan
706 Use of Incorrectly-Resolved Name or Reference yes no nan nan nan
732 Incorrect Permission Assignment for Critical Resource yes no nan nan nan
749 Exposed Dangerous Method or Function no no nan nan nan
754 Improper Check for Unusual or Exceptional Conditions yes no nan nan nan
755 Improper Handling of Exceptional Conditions yes no nan nan nan
759 Use of a One-Way Hash without a Salt no no nan nan nan
763 Release of Invalid Pointer or Reference yes no nan nan nan
770 Allocation of Resources Without Limits or Throttling yes no nan nan nan
772 Missing Release of Resource after Effective Lifetime yes no nan nan nan
776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') yes yes XML entity expansion XXExploiter https://github.com/luisfontes19/xxexploiter
787 Out-of-bounds Write yes no nan nan nan
789 Memory Allocation with Excessive Size Value no no nan nan nan
798 Use of Hard-coded Credentials yes yes discover and use hardcoded credentials Context-dependent, may use password cracking tools, binary analysis tools, or may not require any tools (just knowledge of the default hard-coded credentials) https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/; https://www.powergrep.com/
823 Use of Out-of-range Pointer Offset no no nan nan nan
824 Access of Uninitialized Pointer yes no nan nan nan
829 Inclusion of Functionality from Untrusted Control Sphere yes no nan nan nan
834 Excessive Iteration yes no nan nan nan
835 Loop with Unreachable Exit Condition ('Infinite Loop') yes no nan nan nan
838 Inappropriate Encoding for Output Context yes no nan nan nan
843 Access of Resource Using Incompatible Type ('Type Confusion') yes no nan nan nan
862 Missing Authorization yes no nan nan nan
863 Incorrect Authorization yes no nan nan nan
908 Use of Uninitialized Resource yes no nan nan nan
909 Missing Initialization of Resource yes no nan nan nan
913 Improper Control of Dynamically-Managed Code Resources yes no nan nan nan
916 Use of Password Hash With Insufficient Computational Effort yes yes brute force THC Hydra; John the Ripper; L0phtCrack; Hashcat https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/
917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression La yes no nan nan nan
918 Server-Side Request Forgery (SSRF) yes yes SSRF SSRFmap; Burp Suite https://github.com/swisskyrepo/SSRFmap; https://portswigger.net/web-security/ssrf
920 Improper Restriction of Power Consumption yes no nan nan nan
922 Insecure Storage of Sensitive Information yes no nan nan nan
924 Improper Enforcement of Message Integrity During Transmission in a Communication Channel yes no nan nan nan
1021 Improper Restriction of Rendered UI Layers or Frames yes no nan nan nan
1188 Insecure Default Initialization of Resource yes yes use default credentials Context-dependent, but may not need any tools (for example, try to use default credentials or access resources that typically require permissions) - knowledge of the system (and its defaults) helps nan
1236 Improper Neutralization of Formula Elements in a CSV File yes yes CSV injection No specialized resources are required to execute this type of attack, it is more based on payloads. https://gitlab.com/pentest-tools/PayloadsAllTheThings/-/tree/master/CSV%20Injection; https://owasp.org/www-community/attacks/CSV_Injection
1284 Improper Validation of Specified Quantity in Input yes no nan nan nan
1321 Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') yes yes prototype pollution DOM Invader (Burp Suite) https://portswigger.net/burp/documentation/desktop/tools/dom-invader
1333 Inefficient Regular Expression Complexity yes yes ReDoS or exponential backtracking ReScue https://2bdenny.github.io/ReScue/
NVD-noinfo There is insufficient information about the issue to classify it; details are unkown or unspecified. yes no nan nan nan
NVD-Other NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset. yes no nan nan nan

  1. Jay Jacobs, Sasha Romanosky, Benjamin Edwards, Idris Adjerid, and Michael Roytman. Exploit prediction scoring system (epss). Digital Threats, Jul 2021. URL: https://doi.org/10.1145/3436242, doi:10.1145/3436242. ↩

  2. Allen D Householder, Jeff Chrabaszcz, Trent Novelly, David Warren, and Jonathan M Spring. Historical analysis of exploit availability timelines. In Workshop on Cyber Security Experimentation and Test. Virtual conference, 2020. USENIX. ↩

Mission Impact

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 
{
  "namespace": "ssvc",
  "version": "2.0.0",
  "key": "MI",
  "name": "Mission Impact",
  "description": "Impact on Mission Essential Functions of the Organization",
  "values": [
    {
      "key": "D",
      "name": "Degraded",
      "description": "Little to no impact up to degradation of non-essential functions; chronic degradation would eventually harm essential functions"
    },
    {
      "key": "MSC",
      "name": "MEF Support Crippled",
      "description": "Activities that directly support essential functions are crippled; essential functions continue for a time"
    },
    {
      "key": "MEF",
      "name": "MEF Failure",
      "description": "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"
    },
    {
      "key": "MF",
      "name": "Mission Failure",
      "description": "Multiple or all mission essential functions fail; ability to recover those functions degraded; organization\u2019s ability to deliver its overall mission fails"
    }
  ]
}

See also

Mission Impact combines with Safety Impact to inform Human Impact

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. Identification and prioritization of mission essential functions enables effective continuity planning or crisis planning. Mission Essential Functions are in effect critical activities within an organization that are used to identify key assets, supporting tasks, and resources that an organization requires to remain operational in a crises situation, and so must be included in its planning process. During an event, key resources may be limited and personnel may be unavailable, so organizations must consider these factors and validate assumptions when identifying, validating, and prioritizing MEFs.

When reviewing the list of organizational functions, an organization must first identify whether a function is essential or non-essential. The distinction between these two categories is whether or not an organization must perform a function during a disruption to normal operations and must continue performance during emergencies 1. Essential functions are both important and urgent. Functions that can be deferred until after an emergency are identified as non-essential. For example, DoD defines MEFs in DoD Directive 3020.26 DoD Continuity Policy using similar terminology to FCD-2 2.

As mission essential functions are most clearly defined for government agencies, stakeholders in other sectors may be familiar with different terms of art from continuity planning. For example, infrastructure providers in the US may better align with National Critical Functions. Private sector businesses may better align with operational and financial impacts in a business continuity plan.

While the processes, terminology, and audience for these different frameworks differ, they all can provide a sense of the criticality of an asset or assets within the scope of the stakeholder conducting the cyber vulnerability prioritization with SSVC. In that sense they all function quite similarly within SSVC. Organizations should use whatever is most appropriate for their stakeholder context, with Mission Essential Function analysis serving as a fully worked example in the SSVC documents.

Gathering Information About Mission Impact

The factors that influence the mission impact level are diverse. This paper does not exhaustively discuss how a stakeholder should answer a question; that is a topic for future work. At a minimum, understanding mission impact should include gathering information about the critical paths that involve vulnerable components, viability of contingency measures, and resiliency of the systems that support the mission. There are various sources of guidance on how to gather this information; see for example the FEMA guidance in Continuity Directive 2 1 or OCTAVE FORTE 3. This is part of risk management more broadly. It should require the vulnerability management team to interact with more senior management to understand mission priorities and other aspects of risk mitigation.

As a heuristic, Utility might constrain Mission Impact if both are not used in the same decision tree. For example, if the Utility is super effective, then Mission Impact is at least MEF support crippled.

Prior Versions

Mission Impact v1.0.0

Impact on Mission Essential Functions of the Organization

Value Definition
None Little to no impact
Non-Essential Degraded 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 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "MI",
  "name": "Mission Impact",
  "description": "Impact on Mission Essential Functions of the Organization",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "Little to no impact"
    },
    {
      "key": "NED",
      "name": "Non-Essential Degraded",
      "description": "Degradation of non-essential functions; chronic degradation would eventually harm essential functions"
    },
    {
      "key": "MSC",
      "name": "MEF Support Crippled",
      "description": "Activities that directly support essential functions are crippled; essential functions continue for a time"
    },
    {
      "key": "MEF",
      "name": "MEF Failure",
      "description": "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"
    },
    {
      "key": "MF",
      "name": "Mission Failure",
      "description": "Multiple or all mission essential functions fail; ability to recover those functions degraded; organization\u2019s ability to deliver its overall mission fails"
    }
  ]
}

  1. 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/media-library-data/1499702987348-c8eb5e5746bfc5a7a3cb954039df7fc2/FCD-2June132017.pdf. ↩↩↩

  2. DOD. Dod directive 3020.26 dod continuity policy. Technical Report, US Department of Defense, 2018. URL: https://github.com/CERTCC/SSVC/pull/281/commits/791dcabd716c2e681215493b26cba79f3863887b. ↩

  3. Brett Tucker. Octave® forte and fair connect cyber risk practitioners with the boardroom. 2018. URL: https://insights.sei.cmu.edu/insider-threat/2018/06/octave-forte-and-fair-connect-cyber-risk-practitioners-with-the-boardroom.html (visited on 2020-01-20). ↩

Public Value Added

Public Value Added v1.0.0

How much value would a publication from the coordinator benefit the broader community?

Value Definition
Limited Minimal value added to the existing public information because existing information is already high quality and in multiple outlets.
Ampliative Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc.
Precedence The publication would be the first publicly available, or be coincident with the first publicly available. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "PVA",
  "name": "Public Value Added",
  "description": "How much value would a publication from the coordinator benefit the broader community?",
  "values": [
    {
      "key": "L",
      "name": "Limited",
      "description": "Minimal value added to the existing public information because existing information is already high quality and in multiple outlets."
    },
    {
      "key": "A",
      "name": "Ampliative",
      "description": "Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc."
    },
    {
      "key": "P",
      "name": "Precedence",
      "description": "The publication would be the first publicly available, or be coincident with the first publicly available."
    }
  ]
}

The intent of the definition is that one rarely if ever transitions from limited to ampliative or ampliative to precedence. A vulnerability could transition from precedence to ampliative and ampliative to limited. That is, Public Value Added should only be downgraded through future iterations or re-evaluations. This directionality is because once other organizations make something public, they cannot effectively un-publish it (it'll be recorded and people will know about it, even if they take down a webpage). The rare case where Public Value Added increases would be if an organization published viable information, but then published additional misleading or obscuring information at a later time. Then one might go from limited to ampliative in the interest of pointing to the better information.

Report Credibility

Report Credibility v1.0.0

Is the report credible?

Value Definition
Not Credible The report is not credible.
Credible The report is credible. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "RC",
  "name": "Report Credibility",
  "description": "Is the report credible?",
  "values": [
    {
      "key": "NC",
      "name": "Not Credible",
      "description": "The report is not credible."
    },
    {
      "key": "C",
      "name": "Credible",
      "description": "The report is credible."
    }
  ]
}

An analyst should start with a presumption of credibility and proceed toward disqualification. The reason for this is that, as a coordinator, occasionally doing a bit of extra work on a bad report is preferable to rejecting legitimate reports. This is essentially stating a preference for false positives over false negatives with respect to credibility determination.

There are no ironclad rules for this assessment, and other coordinators may find other guidance works for them. Credibility assessment topics include indicators for and against credibility, perspective, topic, and relationship to report scope.

Credibility Indicators

The credibility of a report is assessed by a balancing test. The indicators for or against are not commensurate, and so they cannot be put on a scoring scale, summed, and weighed.

Note

A report may be treated as credible when either

  1. the vendor confirms the existence of the vulnerability or
  2. independent confirmation of the vulnerability by an analyst who is neither the reporter nor the vendor.

If neither of these confirmations are available, then the value of the Report Credibility decision point depends on a balancing test among the following indicators.

Indicators for Credibility include:

  • The report is specific about what is affected
  • The report provides sufficient detail to reproduce the vulnerability.
  • The report describes an attack scenario.
  • The report suggests mitigations.
  • The report includes proof-of-concept exploit code or steps to reproduce.
  • Screenshots and videos, if provided, support the written text of the report and do not replace it.
  • The report neither exaggerates nor understates the impact.

Indicators against Credibility include:

  • The report is “spammy” or exploitative (for example, the report is an attempt to upsell the receiver on some product or service).
  • The report is vague or ambiguous about which vendors, products, or versions are affected (for example, the report claims that all “cell phones” or “wifi” or “routers” are affected).
  • The report is vague or ambiguous about the preconditions necessary to exploit the vulnerability.
  • The report is vague or ambiguous about the impact if exploited.
  • The report exaggerates the impact if exploited.
  • The report makes extraordinary claims without correspondingly extraordinary evidence (for example, the report claims that exploitation could result in catastrophic damage to some critical system without a clear causal connection between the facts presented and the impacts claimed).
  • The report is unclear about what the attacker gains by exploiting the vulnerability. What do they get that they didn't already have? For example, an attacker with system privileges can already do lots of bad things, so a report that assumes system privileges as a precondition to exploitation needs to explain what else this gives the attacker.
  • The report depends on preconditions that are extremely rare in practice, and lacks adequate evidence for why those preconditions might be expected to occur (for example, the vulnerability is only exposed in certain non-default configurations—unless there is evidence that a community of practice has established a norm of such a non-default setup).
  • The report claims dire impact for a trivially found vulnerability. It is not impossible for this to occur, but most products and services that have been around for a while have already had their low-hanging fruit major vulnerabilities picked. One notable exception would be if the reporter applied a completely new method for finding vulnerabilities to discover the subject of the report.
  • The report is rambling and is more about a narrative than describing the vulnerability. One description is that the report reads like a food recipe with the obligatory search engine optimization preamble.
  • The reporter is known to have submitted low-quality reports in the past.
  • The report conspicuously misuses technical terminology. This is evidence that the reporter may not understand what they are talking about.
  • The analyst's professional colleagues consider the report to be not credible.
  • The report consists of mostly raw tool output. Fuzz testing outputs are not vulnerability reports.
  • The report lacks sufficient detail for someone to reproduce the vulnerability.
  • The report is just a link to a video or set of images, or lacks written detail while claiming “it's all in the video”. Imagery should support a written description, not replace it.
  • The report describes a bug with no discernible security impact.
  • The report fails to describe an attack scenario, and none is obvious.

We considered adding poor grammar or spelling as an indicator of non-credibility. On further reflection, we do not recommend that poor grammar or spelling be used as an indicator of low report quality, as many reporters may not be native to the coordinator's language. Poor grammar alone is not sufficient to dismiss a report as not credible. Even when poor grammar is accompanied by other indicators of non-credibility, those other indicators are sufficient to make the determination.

Credibility of what to whom

SSVC is interested in the coordinating analyst's assessment of the credibility of a report. This is separate from the fact that a reporter probably reports something because they believe the report is credible.

The analyst should assess the credibility of the report of the vulnerability, not the claims of the impact of the vulnerability. A report may be credible in terms of the fact of the vulnerability's existence even if the stated impacts are inaccurate. However, the more extreme the stated impacts are, the more skepticism is necessary. For this reason, “exaggerating the impact if exploited” is an indicator against credibility. Furthermore, a report may be factual but not identify any security implications; such reports are bug reports, not vulnerability reports, and are considered out of scope.

A coordinator also has a scope defined by their specific constituency and mission. A report can be entirely credible yet remain out of scope for your coordination practice. Decide what to do about out of scope reports separately, before the vulnerability coordination triage decision begins. If a report arrives and would be out of scope even if true, there will be no need to proceed with judging its credibility.

Report Public

Report Public v1.0.0

Is a viable report of the details of the vulnerability already publicly available?

Value Definition
Yes A public report of the vulnerability exists.
No No public report of the vulnerability exists. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "RP",
  "name": "Report Public",
  "description": "Is a viable report of the details of the vulnerability already publicly available?",
  "values": [
    {
      "key": "Y",
      "name": "Yes",
      "description": "A public report of the vulnerability exists."
    },
    {
      "key": "N",
      "name": "No",
      "description": "No public report of the vulnerability exists."
    }
  ]
}

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.		 
{
  "namespace": "ssvc",
  "version": "2.0.0",
  "key": "SI",
  "name": "Safety Impact",
  "description": "The safety impact of the vulnerability. (based on IEC 61508)",
  "values": [
    {
      "key": "N",
      "name": "Negligible",
      "description": "Any one or more of these conditions hold.<br/><br/>- *Physical harm*: Minor injuries at worst (IEC 61508 Negligible).<br/>- *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.<br/>- *System resiliency*: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation.<br/>- *Environment*: Minor externalities (property damage, environmental damage, etc.) imposed on other parties.<br/>- *Financial*: Financial losses, which are not readily absorbable, to multiple persons.<br/>- *Psychological*: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons."
    },
    {
      "key": "M",
      "name": "Marginal",
      "description": "Any one or more of these conditions hold.<br/><br/>- *Physical harm*: Major injuries to one or more persons (IEC 61508 Marginal).<br/>- *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.<br/>- *System resiliency*: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation.<br/>- *Environment*: Major externalities (property damage, environmental damage, etc.) imposed on other parties.<br/>- *Financial*: Financial losses that likely lead to bankruptcy of multiple persons.<br/>- *Psychological*: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people."
    },
    {
      "key": "R",
      "name": "Critical",
      "description": "Any one or more of these conditions hold.<br/><br/>- *Physical harm*: Loss of life (IEC 61508 Critical).<br/>- *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.<br/>- *System resiliency*: Parts of the cyber-physical system break; system\u2019s ability to recover lost functionality remains intact.<br/>- *Environment*: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties.<br/>- *Financial*: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state.<br/>- *Psychological*: N/A."
    },
    {
      "key": "C",
      "name": "Catastrophic",
      "description": "Any one or more of these conditions hold.<br/><br/>- *Physical harm*: Multiple loss of life (IEC 61508 Catastrophic).<br/>- *Operator resiliency*: Operator incapacitated (includes fatality or otherwise incapacitated).<br/>- *System resiliency*: Total loss of whole cyber-physical system, of which the software is a part.<br/>- *Environment*: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties.<br/>- *Financial*: Social systems (elections, financial grid, etc.) supported by the software collapse.<br/>- *Psychological*: N/A."
    }
  ]
}

See also

We take an expansive view of safety, in which a safety violation is a violation of what the United States Centers for Disease Control (CDC) calls well-being. Physical well-being violations are common safety violations, but we also consider economic, social, emotional, and psychological well-being to be important. Weighing fine differences among these categories is probably not possible, so we will not try. Each decision option lists examples of the effects that qualify for that value/answer in the various types of violations of well-being. These examples should not be considered comprehensive or exhaustive, but rather as suggestive.

The stakeholder should consider the safety impact on the system operators (by “system operator,” we mean those who are professionally responsible for the proper operation of the cyber-physical system, as the term is used in the safety analysis literature) and users of the software they provide. If software is repackaged and resold by a stakeholder to further downstream entities who will then sell a product, the initial stakeholder can only reasonably consider so many links in that supply chain. However, a stakeholder should know its immediate consumers who are one step away in the supply chain. Those consumers may repackage or build on the software and then provide that product further on.

We expect that a stakeholder should be aware of common usage of their software about one step away in the supply chain. This expectation holds in both open source and proprietary contexts. Further steps along the supply chain are probably not reasonable for the stakeholder to consider consistently; however, this is not a license to willfully ignore common downstream uses of the stakeholder’s software. If the stakeholder is contractually or legally responsible for safe operation of the software or cyber-physical system of which it is part, that also supersedes our rough supply-chain depth considerations.

For software used in a wide variety of sectors and deployments, the stakeholder may need to estimate an aggregate safety impact. Aggregation suggests that the stakeholder’s response to this decision point cannot be less than the most severe credible safety impact, but we leave the specific aggregation method or function as a domain-specific extension for future work.

Gathering Information About Safety Impact

The factors that influence the safety impact level are diverse. This paper does not exhaustively discuss how a stakeholder should answer a question; that is a topic for future work. At a minimum, understanding safety impact should include gathering information about survivability of the vulnerable component, determining available operator actions to compensate for the vulnerable component, understanding relevant insurance, and determining the viability of existing backup measures. Because each of these information items depends heavily on domain-specific knowledge, it is out of the scope of this paper to give a general-purpose strategy for how they should be included. For example, viable manual backup mechanisms are likely to be important in assessing the safety impact of an industrial control system in a sewage plant, but in banking the insurance structures that prevent bankruptcies are more important.

The decision values for safety impact are based on the hazard categories for aircraft software 12. To assign a value to Safety Impact, at least one type of harm must reach that value. For example, for a Safety Impact of major, at least one type of harm must reach major level. All types of harm do not need to rise to the level of major, just one type of harm does.

Situated Safety Impact

Deployers are anticipated to have a more fine-grained perspective on the safety impacts broadly defined in Safety Impact. We defer this topic for now because we combine it with Mission Impact to simplify implementation for deployers.

Prior Versions

Safety Impact v1.0.0

The safety impact of the vulnerability.

Value Definition
None The effect is below the threshold for all aspects described in Minor.
Minor Any one or more of these conditions hold. Physical harm: Physical discomfort for users (not operators) of the system. 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.
Major Any one or more of these conditions hold. Physical harm: Physical distress and injuries for users (not operators) of the system. 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.
Hazardous Any one or more of these conditions hold. Physical harm: Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures. 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 immediate fatalities (Emergency response probably cannot save the victims.) 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. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SI",
  "name": "Safety Impact",
  "description": "The safety impact of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "The effect is below the threshold for all aspects described in Minor."
    },
    {
      "key": "M",
      "name": "Minor",
      "description": "Any one or more of these conditions hold. Physical harm: Physical discomfort for users (not operators) of the system. 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."
    },
    {
      "key": "J",
      "name": "Major",
      "description": "Any one or more of these conditions hold. Physical harm: Physical distress and injuries for users (not operators) of the system. 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."
    },
    {
      "key": "H",
      "name": "Hazardous",
      "description": "Any one or more of these conditions hold. Physical harm: Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures. 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\u2019s 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."
    },
    {
      "key": "C",
      "name": "Catastrophic",
      "description": "Any one or more of these conditions hold. Physical harm: Multiple immediate fatalities (Emergency response probably cannot save the victims.) 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."
    }
  ]
}

  1. RTCA, Inc. Software considerations in airborne systems and equipment certification. Technical Report DO-178C, EUROCAE WG-12, Washington, DC, 2012. ↩

  2. FAA. System safety handbook. Technical Report, US Dept. of Transportation, Federal Aviation Administration, Washington, DC, 2000. URL: https://www.faa.gov/regulations_policies/handbooks_manuals/aviation/risk_management/ss_handbook/. ↩

Supplier Cardinality

Supplier Cardinality v1.0.0

How many suppliers are responsible for the vulnerable component and its remediation or mitigation plan?

Value Definition
One There is only one supplier of the vulnerable component.
Multiple There are multiple suppliers of the vulnerable component. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SC",
  "name": "Supplier Cardinality",
  "description": "How many suppliers are responsible for the vulnerable component and its remediation or mitigation plan?",
  "values": [
    {
      "key": "O",
      "name": "One",
      "description": "There is only one supplier of the vulnerable component."
    },
    {
      "key": "M",
      "name": "Multiple",
      "description": "There are multiple suppliers of the vulnerable component."
    }
  ]
}

Supplier Contacted

Supplier Contacted v1.0.0

Has the reporter made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method?

Value Definition
No The supplier has not been contacted.
Yes The supplier has been contacted. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SC",
  "name": "Supplier Contacted",
  "description": "Has the reporter made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method?",
  "values": [
    {
      "key": "N",
      "name": "No",
      "description": "The supplier has not been contacted."
    },
    {
      "key": "Y",
      "name": "Yes",
      "description": "The supplier has been contacted."
    }
  ]
}

Quality Contact Method

A quality contact method is a publicly posted known good email address, public portal on vendor website, etc.

Supplier Engagement

Supplier Engagement v1.0.0

Is the supplier responding to the reporter’s contact effort and actively participating in the coordination effort?

Value Definition
Active The supplier is responding to the reporter’s contact effort and actively participating in the coordination effort.
Unresponsive The supplier is not responding to the reporter’s contact effort and not actively participating in the coordination effort. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SE",
  "name": "Supplier Engagement",
  "description": "Is the supplier responding to the reporter\u2019s contact effort and actively participating in the coordination effort?",
  "values": [
    {
      "key": "A",
      "name": "Active",
      "description": "The supplier is responding to the reporter\u2019s contact effort and actively participating in the coordination effort."
    },
    {
      "key": "U",
      "name": "Unresponsive",
      "description": "The supplier is not responding to the reporter\u2019s contact effort and not actively participating in the coordination effort."
    }
  ]
}

Supplier Involvement

Supplier Involvement v1.0.0

What is the state of the supplier’s work on addressing the vulnerability?

Value Definition
Fix Ready The supplier has provided a patch or fix.
Cooperative The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time.
Uncooperative/Unresponsive The supplier has not responded, declined to generate a remediation, or no longer exists. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "SI",
  "name": "Supplier Involvement",
  "description": "What is the state of the supplier\u2019s work on addressing the vulnerability?",
  "values": [
    {
      "key": "FR",
      "name": "Fix Ready",
      "description": "The supplier has provided a patch or fix."
    },
    {
      "key": "C",
      "name": "Cooperative",
      "description": "The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time."
    },
    {
      "key": "UU",
      "name": "Uncooperative/Unresponsive",
      "description": "The supplier has not responded, declined to generate a remediation, or no longer exists."
    }
  ]
}

System Exposure

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) 
{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "EXP",
  "name": "System Exposure",
  "description": "The Accessible Attack Surface of the Affected System or Service",
  "values": [
    {
      "key": "S",
      "name": "Small",
      "description": "Local service or program; highly controlled network"
    },
    {
      "key": "C",
      "name": "Controlled",
      "description": "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\u2019s 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."
    },
    {
      "key": "O",
      "name": "Open",
      "description": "Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers)"
    }
  ]
}

Measuring the attack surface precisely is difficult, and we do not propose to perfectly delineate between small and controlled access. Exposure should be judged against the system in its deployed context, which may differ from how it is commonly expected to be deployed. For example, the exposure of a device on a vehicle's CAN bus will vary depending on the presence of a cellular telemetry device on the same bus.

If a vulnerability cannot be remediated, other mitigations may be used. Usually, the effect of these mitigations is to reduce exposure of the vulnerable component. Therefore, a deployer’s response to Exposure may change if such mitigations are put in place. If a mitigation changes exposure and thereby reduces the priority of a vulnerability, that mitigation can be considered a success. Whether that mitigation allows the deployer to defer further action varies according to each case.

Gathering Information About System Exposure

System Exposure is primarily used by Deployers, so the question is about whether some specific system is in fact exposed, not a hypothetical or aggregate question about systems of that type. Therefore, it generally has a concrete answer, even though it may vary from vulnerable component to vulnerable component, based on their respective configurations.

System Exposure can be readily informed by network scanning techniques. For example, if the vulnerable component is visible on Shodan or by some other external scanning service, then it is open. Network policy or diagrams are also useful information sources, especially for services intentionally open to the Internet such as public web servers. An analyst should also choose open for a phone or PC that connects to the web or email without the usual protections (IP and URL blocking, updated firewalls, etc.).

Distinguishing between small and controlled is more nuanced. If open has been ruled out, some suggested heuristics for differentiating the other two are as follows. Apply these heuristics in order and stop when one of them applies. - 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.

The unreachable vulnerable component scenario may be a point of concern for stakeholders like patch suppliers who often find it more cost-effective to simply update the included library to an existing fixed version rather than try to explain to customers why the vulnerable code is unreachable in their own product. In those cases, we suggest the stakeholder reviews the decision outcomes of the tree to ensure the appropriate action is taken (paying attention to defer vs scheduled, for example).

If you have suggestions for further heuristics, or potential counterexamples to these, please describe the example and reasoning in an issue on the SSVC GitHub.

Prior Versions

System Exposure v1.0.0

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.
Unavoidable Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers) 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "EXP",
  "name": "System Exposure",
  "description": "The Accessible Attack Surface of the Affected System or Service",
  "values": [
    {
      "key": "S",
      "name": "Small",
      "description": "Local service or program; highly controlled network"
    },
    {
      "key": "C",
      "name": "Controlled",
      "description": "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\u2019s 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."
    },
    {
      "key": "U",
      "name": "Unavoidable",
      "description": "Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers)"
    }
  ]
}

Technical Impact

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. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "TI",
  "name": "Technical Impact",
  "description": "The technical impact of the vulnerability.",
  "values": [
    {
      "key": "P",
      "name": "Partial",
      "description": "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."
    },
    {
      "key": "T",
      "name": "Total",
      "description": "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."
    }
  ]
}

When evaluating Technical Impact, recall the scope definition in the Scope Section. Total control is relative to the affected component where the vulnerability resides. If a vulnerability discloses authentication or authorization credentials to the system, this information disclosure should also be scored as “total” if those credentials give an adversary total control of the component.

As mentioned in Current State of Practice, the scope of SSVC is just those situations in which there is a vulnerability. Our definition of vulnerability is based on the determination that some security policy is violated. We consider a security policy violation to be a technical impact—or at least, a security policy violation must have some technical instantiation. Therefore, if there is a vulnerability then there must be some technical impact.

Gathering Information About Technical Impact

Assessing Technical Impact amounts to assessing the degree of control over the vulnerable component the attacker stands to gain by exploiting the vulnerability. One way to approach this analysis is to ask whether the control gained is total or not. If it is not total, it is partial. If an answer to one of the following questions is yes, then control is total. After exploiting the vulnerability,

  • 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)?

This list is an evolving set of heuristics. If you find a vulnerability that should have total Technical Impact but that does not answer yes to any of these questions, please describe the example and what question we might add to this list in an issue on the SSVC GitHub.

Value Density

Value Density v1.0.0

The concentration of value in the target

Value Definition
Diffuse The system that contains the vulnerable component has limited resources. That is, the resources that the adversary will gain control over with a single exploitation event are relatively small.
Concentrated The system that contains the vulnerable component is rich in resources. Heuristically, such systems are often the direct responsibility of “system operators” rather than users. 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "VD",
  "name": "Value Density",
  "description": "The concentration of value in the target",
  "values": [
    {
      "key": "D",
      "name": "Diffuse",
      "description": "The system that contains the vulnerable component has limited resources. That is, the resources that the adversary will gain control over with a single exploitation event are relatively small."
    },
    {
      "key": "C",
      "name": "Concentrated",
      "description": "The system that contains the vulnerable component is rich in resources. Heuristically, such systems are often the direct responsibility of \u201csystem operators\u201d rather than users."
    }
  ]
}

See also

Value Density combines with Automatability to inform Utility.

User vs. System Operator

A “user” is anyone whose professional task is something other than the maintenance of the system or component. As with Safety Impact, a “system operator” is anyone who is professionally responsible for the proper operation or maintenance of a system.

Diffuse

Examples of systems with diffuse value are email accounts, most consumer online banking accounts, common cell phones, and most personal computing resources owned and maintained by users.

Concentrated

Examples of concentrated value are database systems, Kerberos servers, web servers hosting login pages, and cloud service providers. However, usefulness and uniqueness of the resources on the vulnerable system also inform value density. For example, encrypted mobile messaging platforms may have concentrated value, not because each phone’s messaging history has a particularly large amount of data, but because it is uniquely valuable to law enforcement.

Gathering Information About Value Density

The heuristics presented in the Value Density definitions involve whether the system is usually maintained by a dedicated professional, although we have noted some exceptions (such as encrypted mobile messaging applications). If there are additional counterexamples to this heuristic, please describe them and the reasoning why the system should have the alternative decision value in an issue on the SSVC GitHub.

An analyst might use market research reports or Internet telemetry data to assess an unfamiliar product. Organizations such as Gartner produce research on the market position and product comparisons for a large variety of systems. These generally identify how a product is deployed, used, and maintained. An organization's own marketing materials are a less reliable indicator of how a product is used, or at least how the organization expects it to be used.

Network telemetry can inform how many instances of a software system are connected to a network. Such telemetry is most reliable for the supplier of the software, especially if software licenses are purchased and checked. Measuring how many instances of a system are in operation is useful, but having more instances does not mean that the software is a densely valuable target. However, market penetration greater than approximately 75% generally means that the product uniquely serves a particular market segment or purpose. This line of reasoning is what supports a determination that an ubiquitous encrypted mobile messaging application should be considered to have a concentrated Value Density.

Compound Decision Points

For notational convenience we will sometimes combine multiple decision points into a single compound decision point.

Examples of compound decision points include:

Human Impact

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 
{
  "namespace": "ssvc",
  "version": "2.0.1",
  "key": "HI",
  "name": "Human Impact",
  "description": "Human Impact is a combination of Safety and Mission impacts.",
  "values": [
    {
      "key": "L",
      "name": "Low",
      "description": "Safety Impact:(Negligible) AND Mission Impact:(None OR Degraded OR Crippled)"
    },
    {
      "key": "M",
      "name": "Medium",
      "description": "(Safety Impact:Negligible AND Mission Impact:MEF Failure) OR (Safety Impact:Marginal AND Mission Impact:(None OR Degraded OR Crippled))"
    },
    {
      "key": "H",
      "name": "High",
      "description": "(Safety Impact:Critical AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Marginal AND Mission Impact:MEF Failure)"
    },
    {
      "key": "VH",
      "name": "Very High",
      "description": "Safety Impact:Catastrophic OR Mission Impact:Mission Failure"
    }
  ]
}

See also

Human Impact is a combination of Safety Impact and Mission Impact

Note: This is a compound decision point1, therefore it is a notational convenience.

Human Impact is a combination of how a vulnerability can affect an organization's mission essential functions as well as safety considerations, whether for the organization's personnel or the public at large. We observe that the day-to-day operations of an organization often have already built in a degree of tolerance to small-scale variance in mission impacts. Thus in our opinion we need only concern ourselves with discriminating well at the upper end of the scale. Therefore we combine the two lesser mission impacts of degraded and MEF support crippled into a single category, while retaining the distinction between MEF Failure and Mission Failure at the extreme. This gives us three levels of mission impact to work with. On the other hand, most organizations tend to have lower tolerance for variance in safety. Even small deviations in safety are unlikely to go unnoticed or unaddressed. We suspect that the presence of regulatory oversight for safety issues and its absence at the lower end of the mission impact scale influences this behavior. Because of this higher sensitivity to safety concerns, we chose to retain a four-level resolution for the safety dimension. We then combine Mission Impact with Situated Safety impact and map them onto a 4-tiered scale (Low, Medium, High, Very High). The mapping is shown in the table above.

Safety and Mission Impact Decision Points for Industry Sectors

We expect to encounter diversity in both safety and mission impacts across different organizations. However, we also anticipate a degree of commonality of impacts to arise across organizations within a given industry sector. For example, different industry sectors may have different use cases for the same software. Therefore, vulnerability information providers—that is, vulnerability databases, Information Sharing and Analysis Organizations (ISAOs), or Information Sharing and Analysis Centers (ISACs)—may provide SSVC information tailored as appropriate to their constituency's safety and mission concerns. For considerations on how organizations might communicate SSVC information to their constituents, see Guidance on Communicating Results.

Prior Versions

Human Impact v2.0.0

Human Impact is a combination of Safety and Mission impacts.

Value Definition
Low Safety Impact:(None OR Minor) AND Mission Impact:(None OR Degraded OR Crippled)
Medium (Safety Impact:(None OR Minor) AND Mission Impact:MEF Failure) OR (Safety Impact:Major AND Mission Impact:(None OR Degraded OR Crippled))
High (Safety Impact:Hazardous AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Major AND Mission Impact:MEF Failure)
Very High Safety Impact:Catastrophic OR Mission Impact:Mission Failure 
{
  "namespace": "ssvc",
  "version": "2.0.0",
  "key": "HI",
  "name": "Human Impact",
  "description": "Human Impact is a combination of Safety and Mission impacts.",
  "values": [
    {
      "key": "L",
      "name": "Low",
      "description": "Safety Impact:(None OR Minor) AND Mission Impact:(None OR Degraded OR Crippled)"
    },
    {
      "key": "M",
      "name": "Medium",
      "description": "(Safety Impact:(None OR Minor) AND Mission Impact:MEF Failure) OR (Safety Impact:Major AND Mission Impact:(None OR Degraded OR Crippled))"
    },
    {
      "key": "H",
      "name": "High",
      "description": "(Safety Impact:Hazardous AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Major AND Mission Impact:MEF Failure)"
    },
    {
      "key": "VH",
      "name": "Very High",
      "description": "Safety Impact:Catastrophic OR Mission Impact:Mission Failure"
    }
  ]
}

Mission and Well-Being Impact v1.0.0

Mission and Well-Being Impact is a combination of Mission Prevalence and Public Well-Being Impact.

Value Definition
Low Mission Prevalence:Minimal AND Public Well-Being Impact:Minimal
Medium Mission Prevalence:Support AND Public Well-Being Impact:(Minimal OR Material)
High Mission Prevalence:Essential OR Public Well-Being Impact:(Irreversible) 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "MWI",
  "name": "Mission and Well-Being Impact",
  "description": "Mission and Well-Being Impact is a combination of Mission Prevalence and Public Well-Being Impact.",
  "values": [
    {
      "key": "L",
      "name": "Low",
      "description": "Mission Prevalence:Minimal AND Public Well-Being Impact:Minimal"
    },
    {
      "key": "M",
      "name": "Medium",
      "description": "Mission Prevalence:Support AND Public Well-Being Impact:(Minimal OR Material)"
    },
    {
      "key": "H",
      "name": "High",
      "description": "Mission Prevalence:Essential OR Public Well-Being Impact:(Irreversible)"
    }
  ]
}

  1. In pilot implementations of SSVC, we received feedback that organizations tend to think of mission and safety impacts as if they were combined into a single factor: in other words, the priority increases regardless which of the two impact factors was increased. We therefore combine Safety Impact and Mission Impact for deployers into a single Human Impact factor as a dimension reduction step. ↩

Public Safety Impact

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) 
{
  "namespace": "ssvc",
  "version": "2.0.1",
  "key": "PSI",
  "name": "Public Safety Impact",
  "description": "A coarse-grained representation of impact to public safety.",
  "values": [
    {
      "key": "M",
      "name": "Minimal",
      "description": "Safety Impact:Negligible"
    },
    {
      "key": "S",
      "name": "Significant",
      "description": "Safety Impact:(Marginal OR Critical OR Catastrophic)"
    }
  ]
}

See also

This is a compound decision point, therefore it is a notational convenience.

Suppliers necessarily have a rather coarse-grained perspective on the broadly defined Safety Impact Decision Point. Therefore we simplify the above into a binary categorization:

  • Significant is when any impact meets the criteria for an impact of Marginal, Critical, or Catastrophic in the Safety Impact table.
  • Minimal is when none do.

Prior Versions

Public Safety Impact v2.0.0

A coarse-grained representation of impact to public safety.

Value Definition
Minimal Safety Impact:(None OR Minor)
Significant Safety Impact:(Major OR Hazardous OR Catastrophic) 
{
  "namespace": "ssvc",
  "version": "2.0.0",
  "key": "PSI",
  "name": "Public Safety Impact",
  "description": "A coarse-grained representation of impact to public safety.",
  "values": [
    {
      "key": "M",
      "name": "Minimal",
      "description": "Safety Impact:(None OR Minor)"
    },
    {
      "key": "S",
      "name": "Significant",
      "description": "Safety Impact:(Major OR Hazardous OR Catastrophic)"
    }
  ]
}

Public Well-Being Impact v1.0.0

A coarse-grained representation of impact to public well-being.

Value Definition
Minimal The effect is below the threshold for all aspects described in material.
Material Any one or more of these conditions hold. Physical harm: Does one or more of the following: (a) Causes physical distress or injury to system users. (b) Introduces occupational safety hazards. (c) Reduces and/or results in failure of cyber-physical system safety margins. Environment: Major externalities (property damage, environmental damage, etc.) are imposed on other parties. Financial: Financial losses likely lead to bankruptcy of multiple persons. Psychological: Widespread emotional or psychological harm, sufficient to necessitate counseling or therapy, impact populations of people.
Irreversible Any one or more of these conditions hold. Physical harm: One or both of the following are true: (a) Multiple fatalities are likely.(b) The cyber-physical system, of which the vulnerable componen is a part, is likely lost or destroyed. Environment: Extreme or serious externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) are imposed on other parties. Financial: Social systems (elections, financial grid, etc.) supported by the software are destabilized and potentially collapse. Psychological: N/A 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "PWI",
  "name": "Public Well-Being Impact",
  "description": "A coarse-grained representation of impact to public well-being.",
  "values": [
    {
      "key": "M",
      "name": "Minimal",
      "description": "The effect is below the threshold for all aspects described in material. "
    },
    {
      "key": "M",
      "name": "Material",
      "description": "Any one or more of these conditions hold. Physical harm: Does one or more of the following: (a) Causes physical distress or injury to system users. (b) Introduces occupational safety hazards. (c) Reduces and/or results in failure of cyber-physical system safety margins. Environment: Major externalities (property damage, environmental damage, etc.) are imposed on other parties. Financial: Financial losses likely lead to bankruptcy of multiple persons. Psychological: Widespread emotional or psychological harm, sufficient to necessitate counseling or therapy, impact populations of people. "
    },
    {
      "key": "I",
      "name": "Irreversible",
      "description": "Any one or more of these conditions hold. Physical harm: One or both of the following are true: (a) Multiple fatalities are likely.(b) The cyber-physical system, of which the vulnerable componen is a part, is likely lost or destroyed.  Environment: Extreme or serious externalities (immediate public health threat, environmental damage leading to small  ecosystem collapse, etc.) are imposed on other parties.  Financial: Social systems (elections, financial grid, etc.) supported by the software are destabilized and potentially collapse.  Psychological: N/A "
    }
  ]
}

Utility

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 
{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "U",
  "name": "Utility",
  "description": "The Usefulness of the Exploit to the Adversary",
  "values": [
    {
      "key": "L",
      "name": "Laborious",
      "description": "Automatable:No AND Value Density:Diffuse"
    },
    {
      "key": "E",
      "name": "Efficient",
      "description": "(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)"
    },
    {
      "key": "S",
      "name": "Super Effective",
      "description": "Automatable:Yes AND Value Density:Concentrated"
    }
  ]
}

See also

Utility is a combination of Automatable and Value Density

This is a compound decision point, therefore it is a notational convenience.

Utility estimates an adversary's benefit compared to their effort based on the assumption that they can exploit the vulnerability. Utility is independent from the state of Exploitation, which measures whether a set of adversaries have ready access to exploit code or are in fact exploiting the vulnerability. In economic terms, Exploitation measures whether the capital cost of producing reliable exploit code has been paid or not. Utility estimates the marginal cost of each exploitation event. More plainly, Utility is about how much an adversary might benefit from a campaign using the vulnerability in question, whereas Exploitation is about how easy it would be to start such a campaign or if one is already underway.

Heuristically, we base Utility on a combination of the value density of vulnerable components and whether potential exploitation is automatable. This framing makes it easier to analytically derive these categories from a description of the vulnerability and the affected component. Automatable as (no or yes) and Value Density as (diffuse or concentrated) define those decision points.

Roughly, Utility is a combination of two things: (1) the value of each exploitation event and (2) the ease and speed with which the adversary can cause exploitation events. We define Utility as laborious, efficient, or super effective, as described in the table above.

Alternative Utility Outputs

Alternative heuristics can plausibly be used as proxies for adversary utility. One example is the value of the vulnerability if it were sold on the open market. Some firms, such as Zerodium, make such pricing structures public. The valuable exploits track the Automatable and Value Density heuristics for the most part. Within a single system—whether it is Apache, Windows, iOS or WhatsApp—more successfully automated steps in the kill lead to higher exploit value. Remote code execution with sandbox escape and without user interaction are the most valuable exploits, and these features describe automation of the relevant kill chain steps.

How equivalently Automatable exploits for different systems are priced relative to each other is more idiosyncratic. Price does not only track the Value Density of the system, but presumably also the existing supply of exploits and the installation distribution among the targets of Zerodium’s customers. Currently, we simplify the analysis and ignore these factors. However, future work should look for and prevent large mismatches between the outputs of the Utility decision point and the exploit markets.

Previous Versions

Utility v1.0.0

The Usefulness of the Exploit to the Adversary

Value Definition
Laborious Virulence:Slow and Value Density:Diffuse
Efficient Virulence:Rapid and Value Density:Diffuse OR Virulence:Slow and Value Density:Concentrated
Super Effective Virulence:Rapid and Value Density:Concentrated 
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "key": "U",
  "name": "Utility",
  "description": "The Usefulness of the Exploit to the Adversary",
  "values": [
    {
      "key": "L",
      "name": "Laborious",
      "description": "Virulence:Slow and Value Density:Diffuse"
    },
    {
      "key": "E",
      "name": "Efficient",
      "description": "Virulence:Rapid and Value Density:Diffuse OR Virulence:Slow and Value Density:Concentrated"
    },
    {
      "key": "S",
      "name": "Super Effective",
      "description": "Virulence:Rapid and Value Density:Concentrated"
    }
  ]
}

See also

Utility v1.0.0 was a combination of Virulence and Value Density

Ended: Compound Decision Points

Ended: Decision Points

SSVC Code Documentation

This section provides documentation for the SSVC Python modules. These include:

SSVC CSV Analyzer

This module provides a script for analyzing an SSVC tree csv file.

usage: csv_analyzer.py [-h] [--outcol OUTCOL] [--permutation] csvfile

Analyze an SSVC tree csv file

positional arguments:
  csvfile          the csv file to analyze

options:
  -h, --help       show this help message and exit
  --outcol OUTCOL  the name of the outcome column
  --permutation    use permutation importance instead of drop column importance
Example

Given a test.csv file like this: 

row,Exploitation,Exposure,Automatable,Human Impact,Priority
1,none,small,no,low,defer
2,none,small,no,medium,defer
3,none,small,no,high,scheduled
...
Analyze the csv file: 
$ python csv_analyzer.py test.csv

Feature Importance after Dropping Each Feature in test.csv
         feature  feature_importance
0  exploitation_            0.347222
1  human_impact_            0.291667
2   automatable_            0.180556
3      exposure_            0.166667

Higher values imply more important features.

drop_col_feature_importance(df, target)

Compute feature importance using drop column feature importance

Parameters:

Name Type Description Default
df DataFrame

the dataframe to analyze

 required
target str

the name of the target column to analyze against

 required

Returns:

Type Description
DataFrame

a dataframe of feature importances
Source code in src/ssvc/csv_analyzer.py 
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
def drop_col_feature_importance(df: pd.DataFrame, target: str) -> pd.DataFrame:
    """
    Compute feature importance using drop column feature importance

    Args:
        df: the dataframe to analyze
        target: the name of the target column to analyze against

    Returns:
        a dataframe of feature importances
    """
    X2, y = _prepare_data(df, target)
    # construct tree
    dt = DecisionTreeClassifier(random_state=99, criterion="entropy")

    imp = _drop_col_feat_imp(dt, X2, y)
    return imp

permute_feature_importance(df, target)

Compute feature importance using permutation feature importance

Parameters:

Name Type Description Default
df DataFrame

the dataframe to analyze

 required
target str

the name of the target column to analyze against

 required

Returns:

Type Description
DataFrame

a dataframe of feature importances
Source code in src/ssvc/csv_analyzer.py 
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
def permute_feature_importance(df: pd.DataFrame, target: str) -> pd.DataFrame:
    """
    Compute feature importance using permutation feature importance

    Args:
        df: the dataframe to analyze
        target: the name of the target column to analyze against

    Returns:
        a dataframe of feature importances
    """
    X2, y = _prepare_data(df, target)
    # construct tree
    dt = DecisionTreeClassifier(random_state=99, criterion="entropy")

    imp = _perm_feat_imp(dt, X2, y)
    return imp

SSVC Policy Generator Tool

The SSVC Policy Generator is a Python object that generates an SSVC decision policy (a decision tree) from a set of input parameters.

It is intended to be used as a library, for example within a Jupyter notebook.

Provides a Policy Generator class for SSVC decision point groups.

PolicyGenerator

Generates a policy for a given decision point group and outcome group.

An SSVC policy is represented as a table of decision point values and outcomes. Each row of the table represents a specific set of decision point values, and the outcome that results from those values.

Internally, the PolicyGenerator represents a policy as a directed graph. Each node in the graph corresponds to a specific set of decision point values. Each edge in the graph indicates an ordering between two states. Taken together, the graph represents a partial ordering of the decision point values mapped to outcomes.

Source code in src/ssvc/policy_generator.py 
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
class PolicyGenerator:
    """
    Generates a policy for a given decision point group and outcome group.

    An SSVC policy is represented as a table of decision point values and outcomes.
    Each row of the table represents a specific set of decision point values, and the outcome that results from those values.

    Internally, the PolicyGenerator represents a policy as a directed graph.
    Each node in the graph corresponds to a specific set of decision point values.
    Each edge in the graph indicates an ordering between two states.
    Taken together, the graph represents a partial ordering of the decision point values mapped to outcomes.
    """

    def __init__(
        self,
        dp_group: SsvcDecisionPointGroup = None,
        outcomes: OutcomeGroup = None,
        outcome_weights: List[float] = None,
        validate: bool = False,
    ):
        """
        Create a policy generator.

        If outcome weights are unspecified, then the weights are evenly distributed across the outcomes.

        Args:
            dp_group: The decision point group to generate a policy for.
            outcomes: The outcome group to generate a policy for.
            outcome_weights: The relative weights of the outcomes (optional)

        Raises:
            ValueError: If dp_group or outcomes are None.
        """
        if dp_group is None:
            raise ValueError("dp_group is required")
        else:
            self.dpg: SsvcDecisionPointGroup = dp_group

        if outcomes is None:
            raise ValueError("outcomes is required")
        else:
            self.outcomes: OutcomeGroup = outcomes

        if outcome_weights is None:
            weight = 1.0 / len(list(self.outcomes))
            self.outcome_weights = [weight for _ in self.outcomes]
        else:
            # validate the number of outcome weights
            if len(outcome_weights) != len(list(self.outcomes)):
                raise ValueError(
                    f"Outcome weights must have {len(list(self.outcomes))} elements, but has {len(outcome_weights)}"
                )

            # validate that the outcome weights sum to 1.0
            total = sum(outcome_weights)
            if not math.isclose(total, 1.0):
                raise ValueError(f"Outcome weights must sum to 1.0, but sum to {total}")

            self.outcome_weights = outcome_weights
        logger.debug(f"Outcome weights: {self.outcome_weights}")

        self.policy: pd.DataFrame = None
        self.G: nx.DiGraph = nx.DiGraph()
        self.top: Tuple[int] = None
        self.bottom: Tuple[int] = None

        self._enumerated_vec = None
        self._check_valid_paths = validate

    def __enter__(self) -> "PolicyGenerator":
        """
        Sets up a policy generator runtime context.

        The runtime context performs the following steps in order:

        1. Converts the decision point group to a vector
        representation.
        2. Adds nodes to the graph. A node is represented as a tuple of decision point values as
        integers. E.g., `(0,1,0,2)`, `(1,2,1,3)`
        3. Adds edges to the graph where each edge $(u,v)$ indicates that $u < v$.
        4. Assigns outcomes to each node in the graph according to the outcome weights.
        5. Validates that the graph
        meets the requirement that outcome ordering is consistent with node ordering.
        6. Converts the graph to a policy table. The policy table is a dataframe where each row represents a node in
        the graph.

        !!! note "Node ordering"

            A node $u$ is considered less than another node $v$ if $u[i] <= v[i]$ for all $i$.


        Example:
            ```python
            with PolicyGenerator(dp_group, outcomes) as pg:
                pg.emit_policy()
            ```

        Returns:
            The policy generator context.
        """
        self._setup()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        pass

    def _setup(self):
        """
        Convert the decision point group to a vector representation.
        """

        self._enumerate_dp_values()
        self._add_nodes()
        self._add_edges()
        self._assign_outcomes()
        if self._check_valid_paths:
            self._validate_paths()
        self._create_policy()

    def _validate_paths(self):
        for path in nx.all_simple_paths(self.G, self.bottom, self.top):
            for start, end in zip(path[:-1], path[1:]):
                u = self.G.nodes[start]["outcome"]
                v = self.G.nodes[end]["outcome"]
                if u > v:
                    raise (ValueError(f"Invalid path: {u} !<= {v} in {path}"))

    def _create_policy(self):
        rows = []
        for node in self.G.nodes:
            row = {}
            for i in range(len(node)):
                # turn the numerical indexes back into decision point names
                col1 = f"{self.dpg.decision_points[i].name}"
                row[col1] = self.dpg.decision_points[i].values[node[i]].name
                # numerical values
                col2 = f"idx_{self.dpg.decision_points[i].name}"
                row[col2] = node[i]

            oc_idx = self.G.nodes[node]["outcome"]
            row["outcome"] = self.outcomes.outcomes[oc_idx].name

            row["idx_outcome"] = oc_idx
            rows.append(row)

        self.policy = pd.DataFrame(rows)

    def clean_policy(self) -> pd.DataFrame:
        df = self.policy.copy()
        print_cols = [c for c in df.columns if not c.startswith("idx_")]
        for c in print_cols:
            df[c] = df[c].str.lower()

        return pd.DataFrame(df[print_cols])

    def emit_policy(self) -> None:
        """
        Prints the policy to stdout in CSV format.
        """
        df = self.clean_policy()

        print(df.to_csv(index=False))

    def _assign_outcomes(self):
        node_count = len(self.G.nodes)
        outcomes = [outcome.name for outcome in self.outcomes.outcomes]
        logger.debug(f"Outcomes: {outcomes}")

        layers = list(nx.topological_generations(self.G))
        logger.debug(f"Layer count: {len(layers)}")
        logger.debug(f"Layer sizes: {[len(layer) for layer in layers]}")

        outcome_counts = [round(node_count * weight) for weight in self.outcome_weights]

        toposort = list(nx.topological_sort(self.G))
        logger.debug(f"Toposort: {toposort[:4]}...{toposort[-4:]}")

        outcome_idx = 0
        assigned_counts = [0 for _ in self.outcomes.outcomes]
        for node in toposort:
            # step through the nodes in topological order
            # and assign outcomes to each node
            self.G.nodes[node]["outcome"] = outcome_idx
            assigned_counts[outcome_idx] += 1

            # if we've assigned enough of this outcome, move on to the next outcome
            if (
                outcome_idx < (len(outcomes) - 1)
                and outcome_counts[outcome_idx] <= assigned_counts[outcome_idx]
            ):
                outcome_idx += 1

        logger.debug(f"Expected counts: {dict(zip(outcomes,outcome_counts))}")
        logger.debug(f"Assigned counts: {dict(zip(outcomes,assigned_counts))}")

    def _add_edges(self):
        # for each node, create an edge to the next node if the next node is strictly greater than the current node
        for u, v in itertools.product(self.G.nodes, self.G.nodes):
            if u == v:
                # don't create an edge from a node to itself
                continue

            # if the next node has at least one value greater than the current node
            if all(u[i] <= v[i] for i in range(len(u))):
                # then create an edge from the current node to the next node
                self.G.add_edge(u, v)

        # the previous loop creates a much larger graph than we need
        # so replace it with the transitive reduction of the graph
        logger.debug(f"Edge count (pre-reduction): {len(self.G.edges)}")
        self.G = nx.transitive_reduction(self.G)
        logger.info(f"Edge count: {len(self.G.edges)}")

    def _add_nodes(self):
        # then get the cartesian product of the values
        # so [[0,1,2],[0,1],[0,1,2]] becomes
        # [[0,0,0],[0,0,1],[0,0,2],[0,1,0],[0,1,1],[0,1,2]]
        vec = self._enumerated_vec

        self.bottom = tuple([min(t) for t in vec])
        self.top = tuple([max(t) for t in vec])

        logger.debug(f"Top node: {self.top}")
        logger.debug(f"Bottom node: {self.bottom}")

        # add a node for each cartesian product of the elements of vec
        for node in itertools.product(*vec):
            node = tuple(node)
            self.G.add_node(node)

        node_count = len(self.G.nodes)
        logger.info(f"Node count: {node_count}")
        return node_count

    def _enumerate_dp_values(self):
        # for each decision point in the group, get an enumeration of the values
        # so [[a,b,c],[d,e],[f,g,h]] becomes [[0,1,2],[0,1],[0,1,2]]
        vec = []
        for dp in self.dpg.decision_points:
            vec.append(tuple(range(len(dp.values))))

        logger.debug(f"Enumerated vector: {vec}")

        self._enumerated_vec = vec

    def _confirm_topological_order(self, node_order: list) -> None:
        """
        Throw an exception if the given node order is not a valid topological sort of the graph.

        Args:
            node_order: a list of nodes expected to be in topological order

        Returns:
            None: if the node order is a valid topological sort of the graph

        Raises:
            ValueError: If the node order is not a valid topological sort of the graph
        """
        # all nodes must be in the graph
        for node in node_order:
            if node not in self.G.nodes:
                raise ValueError(f"Node order contains node {node} not in the graph")

        for node in self.G.nodes:
            if node not in node_order:
                raise ValueError(f"Graph contains node {node} not in the node order")

        node_idx = {node: i for i, node in enumerate(node_order)}

        for u, v in self.G.edges:
            if node_idx[u] > node_idx[v]:
                raise ValueError(
                    f"Node order is not a valid topological sort of the graph ({u} > {v} are out of order)"
                )

    def _is_topological_order(self, node_order: list) -> bool:
        """
        Determine whether the given node order is a valid topological sort of the graph.
        This is the boolean version of _confirm_topological_order.

        Args:
            node_order: a list of nodes expected to be in topological order

        Returns:
            True: if the node order is a valid topological sort of the graph
            False: if the node order is not a valid topological sort of the graph
        """
        try:
            self._confirm_topological_order(node_order)
        except ValueError as e:
            logger.warning(e)
            return False

        return True

__enter__()

Sets up a policy generator runtime context.

The runtime context performs the following steps in order:

  1. Converts the decision point group to a vector representation.
  2. Adds nodes to the graph. A node is represented as a tuple of decision point values as integers. E.g., (0,1,0,2), (1,2,1,3)
  3. Adds edges to the graph where each edge \((u,v)\) indicates that \(u < v\).
  4. Assigns outcomes to each node in the graph according to the outcome weights.
  5. Validates that the graph meets the requirement that outcome ordering is consistent with node ordering.
  6. Converts the graph to a policy table. The policy table is a dataframe where each row represents a node in the graph.

Node ordering

A node \(u\) is considered less than another node \(v\) if \(u[i] <= v[i]\) for all \(i\).

Example 
with PolicyGenerator(dp_group, outcomes) as pg:
    pg.emit_policy()

Returns:

Type Description
PolicyGenerator

The policy generator context.
Source code in src/ssvc/policy_generator.py 
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
def __enter__(self) -> "PolicyGenerator":
    """
    Sets up a policy generator runtime context.

    The runtime context performs the following steps in order:

    1. Converts the decision point group to a vector
    representation.
    2. Adds nodes to the graph. A node is represented as a tuple of decision point values as
    integers. E.g., `(0,1,0,2)`, `(1,2,1,3)`
    3. Adds edges to the graph where each edge $(u,v)$ indicates that $u < v$.
    4. Assigns outcomes to each node in the graph according to the outcome weights.
    5. Validates that the graph
    meets the requirement that outcome ordering is consistent with node ordering.
    6. Converts the graph to a policy table. The policy table is a dataframe where each row represents a node in
    the graph.

    !!! note "Node ordering"

        A node $u$ is considered less than another node $v$ if $u[i] <= v[i]$ for all $i$.


    Example:
        ```python
        with PolicyGenerator(dp_group, outcomes) as pg:
            pg.emit_policy()
        ```

    Returns:
        The policy generator context.
    """
    self._setup()
    return self

__init__(dp_group=None, outcomes=None, outcome_weights=None, validate=False)

Create a policy generator.

If outcome weights are unspecified, then the weights are evenly distributed across the outcomes.

Parameters:

Name Type Description Default
dp_group SsvcDecisionPointGroup

The decision point group to generate a policy for.

 None
outcomes OutcomeGroup

The outcome group to generate a policy for.

 None
outcome_weights List[float]

The relative weights of the outcomes (optional)

 None

Raises:

Type Description
ValueError

If dp_group or outcomes are None.
Source code in src/ssvc/policy_generator.py 
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
def __init__(
    self,
    dp_group: SsvcDecisionPointGroup = None,
    outcomes: OutcomeGroup = None,
    outcome_weights: List[float] = None,
    validate: bool = False,
):
    """
    Create a policy generator.

    If outcome weights are unspecified, then the weights are evenly distributed across the outcomes.

    Args:
        dp_group: The decision point group to generate a policy for.
        outcomes: The outcome group to generate a policy for.
        outcome_weights: The relative weights of the outcomes (optional)

    Raises:
        ValueError: If dp_group or outcomes are None.
    """
    if dp_group is None:
        raise ValueError("dp_group is required")
    else:
        self.dpg: SsvcDecisionPointGroup = dp_group

    if outcomes is None:
        raise ValueError("outcomes is required")
    else:
        self.outcomes: OutcomeGroup = outcomes

    if outcome_weights is None:
        weight = 1.0 / len(list(self.outcomes))
        self.outcome_weights = [weight for _ in self.outcomes]
    else:
        # validate the number of outcome weights
        if len(outcome_weights) != len(list(self.outcomes)):
            raise ValueError(
                f"Outcome weights must have {len(list(self.outcomes))} elements, but has {len(outcome_weights)}"
            )

        # validate that the outcome weights sum to 1.0
        total = sum(outcome_weights)
        if not math.isclose(total, 1.0):
            raise ValueError(f"Outcome weights must sum to 1.0, but sum to {total}")

        self.outcome_weights = outcome_weights
    logger.debug(f"Outcome weights: {self.outcome_weights}")

    self.policy: pd.DataFrame = None
    self.G: nx.DiGraph = nx.DiGraph()
    self.top: Tuple[int] = None
    self.bottom: Tuple[int] = None

    self._enumerated_vec = None
    self._check_valid_paths = validate

emit_policy()

Prints the policy to stdout in CSV format.

Source code in src/ssvc/policy_generator.py 
189
190
191
192
193
194
195
def emit_policy(self) -> None:
    """
    Prints the policy to stdout in CSV format.
    """
    df = self.clean_policy()

    print(df.to_csv(index=False))

Outcome Values and Outcome Groups

Provides outcome group and outcome value classes for SSVC.

OutcomeGroup dataclass

Bases: _Base

Models an outcome group.

Source code in src/ssvc/outcomes/base.py 
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
@dataclass_json
@dataclass(kw_only=True)
class OutcomeGroup(_Base):
    """
    Models an outcome group.
    """

    outcomes: Iterable[OutcomeValue]

    def __iter__(self):
        """
        Allow iteration over the outcomes in the group.
        """
        return iter(self.outcomes)

    def __len__(self):
        """
        Allow len() to be called on the group.
        """
        return len(self.outcomes)

__iter__()

Allow iteration over the outcomes in the group.

Source code in src/ssvc/outcomes/base.py 
43
44
45
46
47
def __iter__(self):
    """
    Allow iteration over the outcomes in the group.
    """
    return iter(self.outcomes)

__len__()

Allow len() to be called on the group.

Source code in src/ssvc/outcomes/base.py 
49
50
51
52
53
def __len__(self):
    """
    Allow len() to be called on the group.
    """
    return len(self.outcomes)

OutcomeValue dataclass

Bases: _Base, _Keyed

Models a single value option for an SSVC outcome.

Source code in src/ssvc/outcomes/base.py 
26
27
28
29
30
31
@dataclass_json
@dataclass(kw_only=True)
class OutcomeValue(_Base, _Keyed):
    """
    Models a single value option for an SSVC outcome.
    """

Provides a set of outcome groups for use in SSVC.

CISA = OutcomeGroup(name='CISA Levels', description='The CISA outcome group. CISA uses its own SSVC decision tree model to prioritize relevant vulnerabilities into four possible decisions: Track, Track*, Attend, and Act.', outcomes=(OutcomeValue(name='Track', key='T', description='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.'), OutcomeValue(name='Track*', key='T*', description='The vulnerability contains specific characteristics that may require closer monitoring for changes. CISA recommends remediating Track* vulnerabilities within standard update timelines.'), OutcomeValue(name='Attend', key='A', description="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."), OutcomeValue(name='Act', key='A', description="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."))) module-attribute

The CISA outcome group. Based on CISA's customizations of the SSVC model. See https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc

COORDINATE = OutcomeGroup(name='Decline, Track, Coordinate', description='The coordinate outcome group.', outcomes=(OutcomeValue(name='Decline', key='D', description='Decline'), OutcomeValue(name='Track', key='T', description='Track'), OutcomeValue(name='Coordinate', key='C', description='Coordinate'))) module-attribute

The coordinate outcome group.

CVSS = OutcomeGroup(name='CVSS Levels', description='The CVSS outcome group.', outcomes=(OutcomeValue(name='Low', key='L', description='Low'), OutcomeValue(name='Medium', key='M', description='Medium'), OutcomeValue(name='High', key='H', description='High'), OutcomeValue(name='Critical', key='C', description='Critical'))) module-attribute

The CVSS outcome group.

DSOI = OutcomeGroup(name='Defer, Scheduled, Out-of-Cycle, Immediate', description='The original SSVC outcome group.', outcomes=(OutcomeValue(name='Defer', key='D', description='Defer'), OutcomeValue(name='Scheduled', key='S', description='Scheduled'), OutcomeValue(name='Out-of-Cycle', key='O', description='Out-of-Cycle'), OutcomeValue(name='Immediate', key='I', description='Immediate'))) module-attribute

The original SSVC outcome group.

EISENHOWER = OutcomeGroup(name='Do, Schedule, Delegate, Delete', description='The Eisenhower outcome group.', outcomes=(OutcomeValue(name='Delete', key='D', description='Delete'), OutcomeValue(name='Delegate', key='G', description='Delegate'), OutcomeValue(name='Schedule', key='S', description='Schedule'), OutcomeValue(name='Do', key='O', description='Do'))) module-attribute

The Eisenhower outcome group.

MOSCOW = OutcomeGroup(name="Must, Should, Could, Won't", description='The Moscow outcome group.', outcomes=(OutcomeValue(name="Won't", key='W', description="Won't"), OutcomeValue(name='Could', key='C', description='Could'), OutcomeValue(name='Should', key='S', description='Should'), OutcomeValue(name='Must', key='M', description='Must'))) module-attribute

The MoSCoW outcome group.

PUBLISH = OutcomeGroup(name='Publish, Do Not Publish', description='The publish outcome group.', outcomes=(OutcomeValue(name='Do Not Publish', key='N', description='Do Not Publish'), OutcomeValue(name='Publish', key='P', description='Publish'))) module-attribute

The publish outcome group.

THE_PARANOIDS = OutcomeGroup(name='theParanoids', description='PrioritizedRiskRemediation outcome group based on TheParanoids.', outcomes=(OutcomeValue(name='Track 5', key='5', description='Track'), OutcomeValue(name='Track Closely 4', key='4', description='Track Closely'), OutcomeValue(name='Attend 3', key='3', description='Attend'), OutcomeValue(name='Attend 2', key='2', description='Attend'), OutcomeValue(name='Act 1', key='1', description='Act'), OutcomeValue(name='Act ASAP 0', key='0', description='Act ASAP'))) module-attribute

Outcome group based on TheParanoids' PrioritizedRiskRemediation. Their model is a 6-point scale, with 0 being the most urgent and 5 being the least. See https://github.com/theparanoids/PrioritizedRiskRemediation

VALUE_COMPLEXITY = OutcomeGroup(name='Value, Complexity', description='The Value/Complexity outcome group.', outcomes=(OutcomeValue(name='Drop', key='D', description='Drop'), OutcomeValue(name='Reconsider Later', key='R', description='Reconsider Later'), OutcomeValue(name='Easy Win', key='E', description='Easy Win'), OutcomeValue(name='Do First', key='F', description='Do First'))) module-attribute

The Value/Complexity outcome group.

YES_NO = OutcomeGroup(name='Yes, No', description='The Yes/No outcome group.', outcomes=(OutcomeValue(name='No', key='N', description='No'), OutcomeValue(name='Yes', key='Y', description='Yes'))) module-attribute

The Yes/No outcome group.

Doctools

Provides tools to assist with generating documentation for SSVC decision points.

Writes the following files for each decision point: - a markdown table that can be used in the decision point documentation - a json example that can be used in the decision point documentation - a markdown file that builds an insert using mkdocs tabs to switch between the markdown description and the json example

Examples

To generate the documentation for the decision points, use the following command:

python -m ssvc.doctools --overwrite --outdir ./tmp/md_out --jsondir ./tmp/json_out`

To regenerate the existing docs, use the following command:

python -m ssvc.doctools --overwrite --outdir docs/_generated/decision_points --jsondir data/json/decision_points

EnsureDirExists

A runtime context that ensures that a directory exists or creates it otherwise.

Example:

with EnsureDirExists(dir):
    assert os.path.exists(dir)
Source code in src/ssvc/doctools.py 
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
class EnsureDirExists:
    """
    A runtime context that ensures that a directory exists or creates it otherwise.

    Example:

        with EnsureDirExists(dir):
            assert os.path.exists(dir)
    """

    def __init__(self, dir: str):
        """
        Create a new EnsureDirExists context.

        Args:
            dir (str): The directory to ensure exists.

        Returns:
            EnsureDirExists: The new EnsureDirExists context.
        """
        self.dir = dir

    def __enter__(self):
        os.makedirs(self.dir, exist_ok=True)

    def __exit__(self, exc_type, exc_val, exc_tb):
        pass

__init__(dir)

Create a new EnsureDirExists context.

Parameters:

Name Type Description Default
dir str

The directory to ensure exists.

 required

Returns:

Name Type Description
EnsureDirExists

The new EnsureDirExists context.
Source code in src/ssvc/doctools.py 
110
111
112
113
114
115
116
117
118
119
120
def __init__(self, dir: str):
    """
    Create a new EnsureDirExists context.

    Args:
        dir (str): The directory to ensure exists.

    Returns:
        EnsureDirExists: The new EnsureDirExists context.
    """
    self.dir = dir

dump_decision_point(jsondir, outdir, dp, overwrite)

Generate the markdown table, json example, and markdown table file for a decision point.

Parameters:

Name Type Description Default
jsondir str

The directory to write the json example to.

 required
outdir str

The directory to write the markdown table file to.

 required
dp SsvcDecisionPoint

The decision point to generate documentation for.

 required
overwrite bool

Whether to overwrite existing files.

 required

Returns:

Name Type Description
dict dict

A dictionary with the following keys: - include_file: The path to the markdown table file. - symlink: The path to the symlink that points to the markdown table file. - json_file: The path to the json example file.
Source code in src/ssvc/doctools.py 
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
def dump_decision_point(
    jsondir: str, outdir: str, dp: SsvcDecisionPoint, overwrite: bool
) -> dict:
    """
    Generate the markdown table, json example, and markdown table file for a decision point.

    Args:
        jsondir (str): The directory to write the json example to.
        outdir (str): The directory to write the markdown table file to.
        dp (SsvcDecisionPoint): The decision point to generate documentation for.
        overwrite (bool): Whether to overwrite existing files.

    Returns:
        dict: A dictionary with the following keys:
            - include_file: The path to the markdown table file.
            - symlink: The path to the symlink that points to the markdown table file.
            - json_file: The path to the json example file.
    """
    # - generate markdown table
    # make dp.name safe for use in a filename
    basename = _filename_friendly(dp.name) + f"_{_filename_friendly(dp.version)}"
    # - generate json example
    json_file = dump_json(basename, dp, jsondir, overwrite)

    # - generate markdown table file
    r = dump_markdown(basename, dp, json_file, outdir, overwrite)
    r["json_file"] = json_file
    return r

dump_json(basename, dp, jsondir, overwrite)

Generate the json example for a decision point.

Parameters:

Name Type Description Default
basename str

The basename of the json example file.

 required
dp SsvcDecisionPoint

The decision point to generate documentation for.

 required
jsondir str

The directory to write the json example to.

 required
overwrite bool

Whether to overwrite existing files.

 required

Returns:

Name Type Description
str str

The path to the json example file.
Source code in src/ssvc/doctools.py 
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
def dump_json(
    basename: str, dp: SsvcDecisionPoint, jsondir: str, overwrite: bool
) -> str:
    """
    Generate the json example for a decision point.

    Args:
        basename (str): The basename of the json example file.
        dp (SsvcDecisionPoint): The decision point to generate documentation for.
        jsondir (str): The directory to write the json example to.
        overwrite (bool): Whether to overwrite existing files.

    Returns:
        str: The path to the json example file.
    """
    json_file = f"{jsondir}/{basename}.json"
    if overwrite:
        remove_if_exists(json_file)
    with EnsureDirExists(jsondir):
        try:
            with open(json_file, "x") as f:
                f.write(dp.to_json(indent=2))
        except FileExistsError:
            logger.warning(
                f"File {json_file} already exists, use --overwrite to replace"
            )
    return json_file

dump_markdown(basename, dp, json_file, outdir, overwrite)

Generate the markdown table file for a decision point.

Parameters:

Name Type Description Default
basename str

The basename of the markdown table file.

 required
dp SsvcDecisionPoint

The decision point to generate documentation for.

 required
json_file str

The path to the json example file.

 required
outdir str

The directory to write the markdown table file to.

 required
overwrite bool

Whether to overwrite existing files.

 required

Returns:

Name Type Description
dict dict

A dictionary with the following keys: - include_file: The path to the markdown table file. - symlink: The path to the symlink that points to the markdown table file.
Source code in src/ssvc/doctools.py 
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
def dump_markdown(
    basename: str, dp: SsvcDecisionPoint, json_file: str, outdir: str, overwrite: bool
) -> dict:
    """
    Generate the markdown table file for a decision point.

    Args:
        basename (str): The basename of the markdown table file.
        dp (SsvcDecisionPoint): The decision point to generate documentation for.
        json_file (str): The path to the json example file.
        outdir (str): The directory to write the markdown table file to.
        overwrite (bool): Whether to overwrite existing files.

    Returns:
        dict: A dictionary with the following keys:
            - include_file: The path to the markdown table file.
            - symlink: The path to the symlink that points to the markdown table file.
    """
    include_file = f"{outdir}/{basename}.md"

    relative_json_file = os.path.relpath(json_file, outdir)

    if overwrite:
        remove_if_exists(include_file)
    with EnsureDirExists(outdir):
        try:
            with open(include_file, "x") as f:
                formatted_template = MD_INCLUDE_TEMPLATE.format(
                    dp=dp,
                    json_file=relative_json_file,
                    table=(to_markdown_table(dp)),
                )
                f.write(formatted_template)
        except FileExistsError:
            logger.warning(
                f"File {include_file} already exists, use --overwrite to replace"
            )

    # update the symlink
    # because we don't want to have to edit each markdown file every time something changes
    symlink = f"{outdir}/{_filename_friendly(dp.name)}.md"
    remove_if_exists(symlink)
    relative_md_file = os.path.relpath(include_file, outdir)
    os.symlink(relative_md_file, symlink)

    result = {
        "include_file": include_file,
        "symlink": symlink,
    }

    return result

to_markdown_table(dp)

Generate a markdown table for a decision point.

Parameters:

Name Type Description Default
dp SsvcDecisionPoint

The decision point to generate a markdown table for.

 required

Returns:

Name Type Description
str str

The markdown table.
Source code in src/ssvc/doctools.py 
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
def to_markdown_table(dp: SsvcDecisionPoint) -> str:
    """
    Generate a markdown table for a decision point.

    Args:
        dp (SsvcDecisionPoint): The decision point to generate a markdown table for.

    Returns:
        str: The markdown table.
    """
    rows = []
    # prepend the header
    rows.append(f"{dp.description}")
    rows.append("")
    indent = " " * 8
    rows.append(f"{indent}| Value | Definition |")
    rows.append(f"{indent}|:-----|:-----------|")

    # add a row for each value
    for value in dp.values:
        rows.append(indent + MD_TABLE_ROW_TEMPLATE.format(value=value))

    return "\n".join(rows)

Ended: Code

Ended: Reference

About ↵

About SSVC

SSVC presents a method for suppliers, deployers, and coordinators to use to prioritize their effort to mitigate vulnerabilities. We have built on previous SSVC versions through public presentation and feedback, private consultation, and continued analyst testing. The evaluation process we developed in version 1 remains an important part of continued improvement of SSVC, and will be used to continue refinements of SSVC going forward. We invite participation and further refinement of the prioritization mechanism from the community as well, such as by posting an issue. We endeavored to be transparent about our process and provide justification for design decisions.

We invite questions, comments, and further community refinement in moving forward with a transparent and justified vulnerability prioritization methodology that is inclusive for the various stakeholders and industries that develop and use information and computer technology.

How Can I Engage with the SSVC Community?

We welcome your feedback and contributions to SSVC. Here are some ways you can get involved:

  • Ask a question

    If you have a specific question for the SSVC team, please feel free to Ask a Question.

    Questions of more general interest to the community of SSVC users might fit better in the Q&A section of the Discussion area.

  • Report a problem

    If you find a problem with the SSVC documentation, the methodology, or accompanying code, we welcome your Bug Reports

  • Suggest an improvement

    Got an idea for how to make SSVC better? We'd love to hear it! Please submit your Feature Requests

  • Join the conversation

    More in-depth conversations that might not be actionable as issues are found in the Discussions area.

  • See what we're working on

    We manage the SSVC development effort via Github Issues and Pull Requests. Drop by and see what we're working on, or leave a comment to let us know what you're interested in.

  • Get more involved

    Want more information about engaging as a collaborator? Check out the SSVC Project Wiki

Footer Icons

The icons in the footer of each page also provide links to engage with the SSVC community.

How to contribute

Thanks for your help on improving our stakeholder-specific vulnerability categorization work. To account for different stakeholder perspectives, we benefit from a diverse group of contributors.

Please see our project documentation in the wiki that accompanies this repository for more information on how you can contribute to the project.

Licenses

  • The license for all code in the repository is here
  • The license for all English writing in the repository is here

Questions

If you have any questions, an issue or discussion is the best way to get in touch with us.

SSVC Decision Records

We have adopted the use of Markdown Any Decision Records to document significant decisions made in the development of SSVC. Below is a list of all the decision records that have been made.

See repository for authoritative source of decision records

While we include these records in the site for reference, the authoritative source for these records, including their current adoption status, is the SSVC GitHub repository.

Accepted Records

Rejected Records

  • None

Superseded Records

Deprecated Records

  • None

Records with non-standard statuses

  • None

Acknowledgements

The authors would first like to acknowledge the valuable contributions of previous authors who have worked on earlier versions of this report: Art Manion, Madison Oliver, and Deana Shick.

The authors thank the contributors to the SSVC project on Github as well as the following individuals for helpful comments on prior drafts (listed in alphabetical order): Muhammad Akbar, Will Dormann, Manish Gaur, Ralph Langer, David Oxley Dale Peterson, Jeroen van der Ham, Michel van Eeten, and Sounil Yu.

The authors also thank those others too numerous to name individually who provided comments and feedback, including: Attendees at S4, Miami FL 2020; Attendees at A Conference on Defense (ACoD), Austin TX 2020; Anonymous WEIS reviewers; Various staff members and analysts at CERT/CC, CISA, McAfee, and VMWare; FIRST CVSS SIG and EPSS SIG members; and others who wish to remain anonymous.

Changelog

Version 2.1 Changelog

This section summarizes the changes between SSVC 2.1 and SSVC version 2.0. The details of what changes were made can be viewed on the SSVC Github under the SSVC v2.1 milestone.

  • Introduced a demo SSVC Calc App which became the basis for CISA's SSVC Calculator
  • Updated Deployer tree to use Automatable instead of Utility, which reduced the size from 108 leaf nodes to 72.
  • Adjusted Deployer tree decisions based on stakeholder feedback
  • Adjusted Supplier tree decisions based on stakeholder feedback
  • Added section on Sharing Trees With Others including a discussion of decision point scope and decision tree scope.
  • Improved clarity of time-sensitivity of some decision points in Representing Information for Decisions About Vulnerabilities
  • Improved description of Mission Impact
  • Improved consistency of Public Safety Impact usage throughout the document and tooling
  • Improved consistency of Human Impact usage throughout the document
  • Clarified that known default passwords are an example of Exploitation:PoC
  • Clarified that unreachable code (as in unused library features) are System Exposure:small
  • Mention DoD MEF definition in Mission Impact
  • Updated references to EPSS to reflect recent publications
  • Refactored markdown files to better track chapter and section numbering, improving findability when editing
  • Automated HTML and PDF generation into a Github Workflow
  • Updated python tools to maintain sync with current SSVC decision models
  • Consolidated the SSVC document style guide into a single file in the repository
  • Miscellaneous typo fixes and readability improvements (e.g., headings, bulleted lists)

Version 2 Changelog

This section summarizes the changes between SSVC version 2 and SSVC version 1.1 as published at the Workshop on the Ecnomics of Information Security (WEIS 2020). The details of what changes were made can be viewed on the SSVC GitHub issues closed under the SSVC v2 Development project. We addressed about 60 issues. About 10 issues identified “bugs” or errors in version 1.1. About 20 issues improved documentation of tools or improved the clarity of document text. The remaining 30 issues were focused on enhancing SSVC based on feedback received on version 1, though several of the bug fixes and documentation improvements also provided improvements. This section focuses on changes that provided enhancements.

Coordinator stakeholder

Version 1 only considered two stakeholders: those who make software, and those who use information systems. Version 2 introduces a coordinator stakeholder and two distinct decisions for that stakeholder group: vulnerability intake triage and publication about a vulnerability. These decisions use some existing decision points, but also introduce six new decision points to support coordinators in making these decisions. The coordinator stakeholder is based on CERT/CC's experience coordinating vulnerabilities.

Terminology changes

Some terms have been adjusted to better align with other usage in the field or based on feedback. Therefore, “patch developer” became supplier and “patch applier” became deployer. These terms in version 2 better reflect the stakeholder's relationship to the vulnerable component and also help keep clear that SSVC is about prioritization of work items in vulnerability management, not just patches. We have also generally removed the word patch and instead use the more general “remediation” for a complete fix and “mitigation” for actions that reduce risk but do not remove a vulnerability from a system. “Virulence” was renamed Automatable in a effort to be more direct and clear, rather than relying on an epidemiology metaphor. We changed “out-of-band” to out-of-cycle.

Some concepts needed to be clarified or added. These changes are a bit more substantive than the above terminology changes, but are similar. For example, we clarified how end-of-life products are prioritized with SSVC. We also clarified in Scope concepts around vulnerability identificatin and disambiguation. Version 2 adopts an explicit definition of risk (from ISO Guide 73). We also differentiated between vulnerability risk, or that risk arising from an unmanaged vulnerability in an information system, and change risk, or that risk from modifying or updating an information system to mitigate or remediate a vulnerability. SSVC version 2 focuses on assessing and managing vulnerability risk, not change risk. This stance was not explicit in SSVC version 1.

Improvements to decision points

Version 1 had a decision point for well-being impact that was shared between supplier and deployer stakeholders. Since these types of stakeholder have access to different information about safety and well-being, Version 2 splits this concept into Public Safety Impact and Situated Safety Impact. The underlying definition remains largely the same. However, Public Safety Impact has fewer output options (it is less granular) in recognition that a supplier or coordinator has less information about the context of deployment than a deployer does.

In addition, based on feedback from SSVC users, the SSVC version 2 recommended applier tree makes use of a combined value for Mission Impact and Situated Safety Impact. The intuition behind this change is that if a person is going to die OR the organization is going to fail (for example, go bankrupt), then the organization will likely want to act with highest priority. Either situation is sufficient to increase the priority, and there do not appear to be situations where a low Mission Impact would mitigate a high Situated Safety Impact or vice versa. On the other hand, a low Utility or System Exposure may mitigate a high mission or well-being impact. So the Version 2 recommended tree is more usable than the Version 1 tree, thanks to these changes.

Tree management and communication tools

The section Tree Construction and Customization Guidance is largely new or revised. We produced new software tools for interacting with SSVC, which are documented in that section. Version 2 adds reasoning behind why a stakeholder might customize a decision tree, what aspects of the tree are best to customize, tools for encoding custom trees in JSON, and scripts for visualizing custom trees.

Similarly, the section on Guidance on Communicating Results is largely new. The section presents both an abbreviated and unabridged format for communicating SSVC information about a vulnerability. This communication may be connected to the formats for communicating a whole decision tree. Version 2 also addresses several other questions about SSVC information management, such as handling information changes over time, partial information, sourcing information for each decision point, and how collection and analysis of SSVC decision points can be automated.

Copyright

Copyright 2019-2023 Carnegie Mellon University.

This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.

The view, opinions, and/or findings contained in this material are those of the author(s) and should not be construed as an official Government position, policy, or decision, unless designated by other documentation.

References herein to any specific commercial product, process, or service by trade name, trade mark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute.

NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

[DISTRIBUTION STATEMENT A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution.

Internal use:* Permission to reproduce this material and to prepare derivative works from this material for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works.

External use:* This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other external and/or commercial use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu.

* These restrictions do not apply to U.S. government entities.

Carnegie Mellon®, CERT Coordination Center® and OCTAVE® are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

DM19-1222

Contact Us

Software Engineering Institute
4500 Fifth Avenue, Pittsburgh, PA 15213-2612

Phone: 412.268.5800 | 888.201.4479
Web: www.sei.cmu.edu
Email: info@sei.cmu.edu

How Can I Engage with the SSVC Community?

We welcome your feedback and contributions to SSVC. Here are some ways you can get involved:

  • Ask a question

    If you have a specific question for the SSVC team, please feel free to Ask a Question.

    Questions of more general interest to the community of SSVC users might fit better in the Q&A section of the Discussion area.

  • Report a problem

    If you find a problem with the SSVC documentation, the methodology, or accompanying code, we welcome your Bug Reports

  • Suggest an improvement

    Got an idea for how to make SSVC better? We'd love to hear it! Please submit your Feature Requests

  • Join the conversation

    More in-depth conversations that might not be actionable as issues are found in the Discussions area.

  • See what we're working on

    We manage the SSVC development effort via Github Issues and Pull Requests. Drop by and see what we're working on, or leave a comment to let us know what you're interested in.

  • Get more involved

    Want more information about engaging as a collaborator? Check out the SSVC Project Wiki

Footer Icons

The icons in the footer of each page also provide links to engage with the SSVC community.

Ended: About