Use SSVC

The preparation is complete, data has been 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 deployers (e.g., device maintainers at hospitals) 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 model its decision points and possible outcome 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.

JSON Format

We provide a structured communication format for SSVC information using JSON schemas. The goal of this format is to capture all the context and details about a decision or work item in a clear and machine-readable way.

• The provision schema is equivalent to a decision model 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.

Deriving a Decision Point JSON key-value pair

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.

Communicating All Possible States

For example, Utility may be laborious, efficient, or super effective.

Utility v1.0.1

TextJSON

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"
    }
  ]
}

The reason a stakeholder might publish a decision point with all its possible values is that doing so 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.

When Some Values Are Known (But Others Are Not)

Extending the previous example, say the analyst knows that Value Density is diffuse but does not know the value for Automatability.

Value Density v1.0.0

TextJSON

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."
    }
  ]
}

Automatable v2.0.0

TextJSON

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."
    }
  ]
}

Therefore they could rule out super effective for Utility but not laborious or efficient. In this case, the analyst could usefully restrict Utility to one of laborious or efficient while leaving Automatability open.

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.

Focus on Automation

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.

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 re-evaluate 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.

Decision Points Not Under Direct Control

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

Decision Points Under Direct Control

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

• Situated Safety Impact
• Mission Impact
• System Exposure

Timestamping SSVC Information

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 ¹, 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. ↩