Skip to content

Compound Decision Points

todo: revise

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

Examples of compound decision points include:

  • Public Safety Impact
  • Utility
  • Human Impact

Utility

Utility

The Usefulness of the Exploit to the Adversary

Automatable Value Density Utility
no diffuse laborious
no concentrated efficient
yes diffuse efficient
yes concentrated super effective

TODO note that 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.

Public Safety Impact

Public Safety Impact

Value Definition
Minimal Safety Impact of None or Minor
Significant Safety Impact of Major, Hazardous, or Catastrophic

TODO note that 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 Major, Hazardous, or Catastrophic in the Safety Impact table.
  • Minimal is when none do.

Human Impact

Human Impact

Combined Situated Safety and Mission Impact

Situated Safety Impact Mission Impact Combined Value (Human Impact)
None/Minor Degraded/Crippled Low
None/Minor MEF Failure Medium
None/Minor Mission Failure Very High
Major Degraded/Crippled Medium
Major MEF Failure High
Major Mission Failure Very High
Hazardous Degraded/Crippled High
Hazardous MEF Failure High
Hazardous Mission Failure Very High
Catastrophic Degraded/Crippled Very High
Catastrophic MEF Failure Very High
Catastrophic Mission Failure Very High

TODO note that this is a compound decision point, therefore it is a notational convenience

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 as follows. 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 following table.

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.