From 35442cc103dba727a5ee30391f69f7c4d81bdc4e Mon Sep 17 00:00:00 2001 From: j--- Date: Tue, 16 Mar 2021 09:20:35 -0400 Subject: [PATCH] update the introduction with basic fixes. (#124) --- doc/compile-citeproc.sh | 2 +- doc/md_src_files/010_introduction.md | 32 ++- doc/md_src_files/020_stateOfPractice.md | 30 ++- .../030_representingInformation.md | 58 ++--- doc/md_src_files/082_relatedSystems.md | 11 + doc/md_src_files/sources_ssvc.bib | 12 + doc/ssvc_v2-0.html | 229 +++++++++--------- 7 files changed, 214 insertions(+), 160 deletions(-) diff --git a/doc/compile-citeproc.sh b/doc/compile-citeproc.sh index 03420897..cb3c3594 100755 --- a/doc/compile-citeproc.sh +++ b/doc/compile-citeproc.sh @@ -1,7 +1,7 @@ #!/bin/sh src="./md_src_files" -pandoc --standalone --from=markdown_github+citations --to=html \ +pandoc --self-contained --from=markdown_github+citations --to=html \ --citeproc \ --bibliography="$src/sources_ssvc.bib" \ -M title="Prioritizing vulnerability response: A stakeholder-specific vulnerability categorization (DRAFT version 2.0)" \ diff --git a/doc/md_src_files/010_introduction.md b/doc/md_src_files/010_introduction.md index 138cf8fa..7a76c9a1 100644 --- a/doc/md_src_files/010_introduction.md +++ b/doc/md_src_files/010_introduction.md @@ -2,12 +2,32 @@ # Introduction -Many organizations use the Common Vulnerability Scoring System (CVSS) to prioritize actions during vulnerability management. This paper builds on prior work about prioritizing actions during vulnerability management by presenting a testable Stakeholder-Specific Vulnerability Categorization (SSVC) that avoids some problems with CVSS. SSVC takes the form of decision trees for different vulnerability management communities. We welcome others to test and improve it. +This document defines a testable Stakeholder-Specific Vulnerability Categorization (SSVC) for prioritizing actions during vulnerability management. +The stakeholders in vulnerability management are diverse, and that diversity must be accommodated in the main functionality, rather than squeezed into hard-to-use optional features. +Given this, as much as it is practical, we aim to avoid one-size-fits-all solutions. -This paper proposes a functional system to make our proposal concrete as well as preliminary tests of its usefulness. However, our proposal is a detailed hypothesis to test or a conversation starter; it is not a final proposal. The stakeholders in vulnerability management are diverse, and that diversity must be accommodated in the main functionality, rather than squeezed into hard-to-use optional features. Given this, as much as it is practical, we aim to avoid one-size-fits-all solutions. +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, 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. -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, 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. Others may have different satisfactory models, and that is okay. +Our decision-making process is based on decision trees. +A decision tree represents important elements of a decision, possible decision values, and possible outcomes. +We suggest decision trees as an adequate formalism for practical, widespread advice about vulnerability prioritization. +We do not claim this approach is the only viable option. +We suggest that specific vulnerability management stakeholder communities use decision trees. +These suggestions are hypotheses for viable replacements for CVSS in those communities, but the hypotheses require empirical testing before they can be justifiably considered fit for use. +We propose a methodology for such testing. -The organizing concept of our decision-making procedure is decision trees. A decision tree represents important elements of a decision, possible decision values, and possible outcomes. We suggest decision trees as an adequate formalism for practical, widespread advice about vulnerability prioritization. We do not claim this approach is the only viable option. We also suggest that specific vulnerability management stakeholder communities use decision trees. These suggestions are hypotheses for viable replacements for CVSS in those communities, but the hypotheses require empirical testing before they can be justifiably considered fit for use. We propose a methodology for such testing. - -The rest of the paper is organized as follows. [Section 2](#current-state-of-practice) summarizes the current state of vulnerability management. [Section 3](#representing-information-for-decisions-about-vulnerabilities) describes our design goals for an improved prioritization method. [Section 4](#decision-trees-for-vulnerability-management) proposes a definition of decision points and decision trees as a prioritization method. [Section 5](#evaluation-of-the-draft-trees) describes an early test of this method against the design goals, as much to show an adequate usability test methodology as for the results. [Section 6](#worked-example) provides examples of applying the methodology of Section 4 to sample vulnerabilities. [Section 7](#future-work) identifies future work. [Section 8](#limitations) identifies limitations in the design. [Section 9](#conclusion) concludes with some final thoughts. +The document is organized as follows. +[Current State of Practice](#current-state-of-practice) summarizes the current state of vulnerability management. +[Representing Information for Decisions About Vulnerabilities](#representing-information-for-decisions-about-vulnerabilities) describes our design goals for an improved prioritization method. +[Vulnerability Management Decisions](#vulnerability-management-decisions) defines who the decision makers are and what options they are deciding among. +[Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data) proposes a definition of decision points that a stakeholder might use during vulnerability management. +[Prioritization](#prioritization) combines these decision points into example decision trees that can be used to prioritize action on a work item. +[Evaluation of the Draft Trees](#evaluation-of-the-draft-trees) describes an early test of this method against the design goals, as much to show an adequate usability test methodology as for the results. +[Worked example](#worked-example) provides examples of applying the methodology to sample vulnerabilities and discusses the relationship between SSVC and other vulnerability management prioritization systems. +[Future Work](#future-work) identifies ideas we haven't had time to incorporate yet. +[Limitations](#limitations) identifies limitations in the design. +[Conclusion](#conclusion) concludes with some final thoughts. diff --git a/doc/md_src_files/020_stateOfPractice.md b/doc/md_src_files/020_stateOfPractice.md index ac170529..e215b2b3 100644 --- a/doc/md_src_files/020_stateOfPractice.md +++ b/doc/md_src_files/020_stateOfPractice.md @@ -2,16 +2,26 @@ # Current state of practice -**Vulnerability management** is a term of art for security practitioners, used to include “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” [@csirtservices_v2]. 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 angle. - -The de facto standard prioritization language is CVSS [@spring2018litrev]. CVSS avoids discussing decisions and, instead, takes **technical severity** as its fundamental concept. We understand severity’s role as informing decision making about vulnerability management. The CVSS standard indicates vulnerability management decisions, and only those decisions, as what they expect CVSS scores to inform -- “CVSS provides a way to capture the principal characteristics of a vulnerability … reflecting its severity … to help organizations properly assess and prioritize their vulnerability management processes” [@cvss_sig]. However, the standard does not provide clear advice about how CVSS scores might inform decisions. - -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 [@cvss_v3-1]. However, as two examples, the U.S. government [see @nist800-115, p. 7-4; @nist800-40r3, p. 4; and @bod15-01] and the global payment card industry [@pcidss_v3] both have defined such misuse as expected practice in their vulnerability management requirements. 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 [@mitre2019medical], robotics [@vilches2018towards], and industrial systems [@figueroa2020survey]. 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](https://access.redhat.com/security/updates/classification), [Microsoft](https://www.microsoft.com/en-us/msrc/security-update-severity-rating-system), and [Cisco](https://tools.cisco.com/security/center/resources/security_vulnerability_policy.html#asr). 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. The various stakeholder re-adaptations of CVSS suggest a stakeholder-specific prioritization is important. - -Unfortunately, all such re-adaptation of the basic CVSS mindset inherit its deeper issues. For example, the CVSS scoring algorithm has not been argued for transparently, and the standardization group has not justified the use of the formula either formally or empirically [@spring2018cvss]. In addition, severity should only be a part of vulnerability response prioritization [See, e.g., @farris2018vulcon]. One complaint is that a high CVSS score is not predictive of which vulnerabilities will be commonly exploited or have exploits publicly released [@allodi2012preliminary]. Studies of CVSS scoring consistency indicate that analysts do not consistently interpret the elements of a CVSSv3.0 score [@allodi2018effect], and as many adaptations of CVSS simply add additional metrics we expect they 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 [@garfinkel2014usable]. - -Surveys of security metrics [@pendleton2016survey] and information sharing in cybersecurity [@laube2017survey] do not indicate any major efforts to conduct a wholesale rethinking of vulnerability prioritization. The surveys indicate some options for available measurements a prioritization method might consider, such as exploit availability or system attack surface. Section 3 describes our design goals for a pragmatic prioritization methodology that can improve and build on the state of current 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” [@csirtservices_v2]. +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 [@spring2018litrev]. +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 [@cvss_sig]. +SSVC instead considers technical severity as one decision point in vulnerability management. +Severity should only be a part of vulnerability response prioritization [See, e.g., @farris2018vulcon]. + +Any re-adaptation of the basic CVSS mindset inherits its deeper issues. +As one example, the CVSS scoring algorithm has not been argued for transparently, and the standardization group has not justified the use of the formula either formally or empirically [@spring2018cvss]. +One complaint is that a high CVSS score is not predictive of which vulnerabilities will be commonly exploited or have exploits publicly released [@allodi2012preliminary]. +Studies of CVSS scoring consistency indicate that analysts do not consistently interpret the elements of a CVSSv3.0 score [@allodi2018effect], and as many adaptations of CVSS simply add additional metrics we expect they 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 [@garfinkel2014usable]. +SSVC aims to learn from and improve upon these issues. + +Surveys of security metrics [@pendleton2016survey] and information sharing in cybersecurity [@laube2017survey] 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](#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. diff --git a/doc/md_src_files/030_representingInformation.md b/doc/md_src_files/030_representingInformation.md index 20c11ab8..5115d94c 100644 --- a/doc/md_src_files/030_representingInformation.md +++ b/doc/md_src_files/030_representingInformation.md @@ -2,34 +2,30 @@ # Representing Information for Decisions About Vulnerabilities -We chose to build our model with decisions as the central concept. -We propose that decisions—rather than severity—are a more useful output. -Our design requirements for an adequate decision-making process is that it clearly define whose decisions are involved, properly use evidentiary categories, be based on reliably available evidence, be transparent, and be explainable. -Our inspiration and justification for these design goals is that they are the features of a satisfactory scientific enterprise [@spring2017why] adapted to this vulnerability management problem. +We propose that decisions—rather than severity—are a more useful approach. +Our design goals for the decision-making process are: clearly define whose decisions are involved, properly use evidentiary categories, be based on reliably available evidence, be transparent, and be explainable. +Our inspiration and justification for these design goals is that they are the features of a satisfactory scientific enterprise [@spring2017why] adapted to the vulnerability management problem. To consider decisions about managing the vulnerability rather than just 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. -Furthermore, organizations in the aviation industry have different priorities than organizations that make word processors. +For example, organizations in the aviation industry have different priorities than organizations that make word processors. These differences indicate a requirement: any formalism must be able to capture adequately the different decisions and priorities exhibited by different stakeholder groups. And 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 [@simon1996sciences]. -Satisficing is more appropriate to qualitative criteria; we do not need to order different methods as to which are more transparent than others, for example. Finding any system that meets all of desired criteria is enough. Decisions are not numbers. Decisions 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. +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 [@cvss_v3-1, section 7.5]. -If we take the recommended dividing line between high and critical—9.0—then it is unclear how to convert a CVSSv3.0 score of 8.9. +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. -For example, under a Gaussian error distribution, 8.9 is really 60\% high and 40\% critical. -We want decisions to be distinct and crisp; statistical overlaps of scores within 1.0 unit, for example, would muddy decision recommendations. - -We avoid numerical representations and consider only qualitative data as inputs and outputs for any vulnerability management decision process. +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. @@ -40,9 +36,9 @@ Temporal and environmental considerations should be primary, not optional as the We make the deliberation process as clear as practical; therefore, we risk belaboring some points to ensure our assumptions and reasoning are explicit. Transparency should improve trust in the results. -Finally, any result of a decision-making process should be **explainable**. -(Explainable is defined and used with its common meaning. -This meaning is not the same as “explainable,” as used in the research area of explainable artificial intelligence.) An explanation should make the process intelligible to an interested, competent, non-expert person. +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. To summarize, the following are our design goals for a vulnerability @@ -64,37 +60,34 @@ management process: ## Formalization Options -This section briefly surveys the available formalization options against the six requirements described above. -Table 1 summarizes the results. -This survey is opportunistic, and is based on conversations with several experts and our professional experience. +This section briefly surveys the available formalization options against the six design goals described above. +[Table 1](#table-form-options) summarizes the results. +This survey is opportunistic, 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 need to search only until a satisfactory option is found. -Thus, we focus on highlighting why some common options or suggestions do not meet the above criteria. +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. 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 our sense) and quantitative. +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 [@russell2011artificial]. -However, it’s not transparent enough to simply know how the available decision trees are created or mutated and why a certain set of them works better. +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 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. -However, while the explanations provided by logical tools are accessible to experts, non-experts may struggle. -However, 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. +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 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 used to document a human process. -In decision analysis “decision analysts frequently use specialized tools, such as decision tree techniques, to evaluate uncertain situations. -Unfortunately, many people, some of them educators, have confused decision analysis with decision trees. -This is like confusing surgery with the scalpel” [@howard1983readings, viii]. +In decision analysis, analysts “frequently use specialized tools, such as decision tree techniques, to evaluate uncertain situations” [@howard1983readings, viii]. We use decision trees in the tradition of decision analysis, not ML. -Table 1: Comparison of Formalization Options for Vulnerability Prioritization Decisions +Table: How Vulnerability Prioritization Options Meet the Design Goals | | **Outputs Designed to be Decisions** | **Pluralistic Recommendations** | **Qualitative Inputs** | **Qualitative Outputs** | **Transparent** | **Explainable** | | :-- | :-: | :-: | :-: | :-: | :-: | :-: | @@ -109,12 +102,11 @@ Table 1: Comparison of Formalization Options for Vulnerability Prioritization De ## Decision Trees -A decision tree is an acyclic, flowchart-like 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 more than two options and may have different options from other decision points. +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 desired criteria described above. -The two less-obvious criteria met by decision trees are plural recommendations and transparent tree-construction processes. -Decision trees support plural recommendations simply because a separate tree can represent each stakeholder group. +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. diff --git a/doc/md_src_files/082_relatedSystems.md b/doc/md_src_files/082_relatedSystems.md index d0ca12f3..b75c2ac7 100644 --- a/doc/md_src_files/082_relatedSystems.md +++ b/doc/md_src_files/082_relatedSystems.md @@ -15,6 +15,17 @@ In connection with this design, CVSS base scores and base metrics are far and aw 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 v3.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 [@cvss_v3-1]. +Two examples of this include the U.S. government [see @nist800-115, p. 7-4; @nist800-40r3, p. 4; and @bod15-01] and the global payment card industry [@pcidss_v3] 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 [@wang2017characterizing]. + +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 [@mitre2019medical], robotics [@vilches2018towards], and industrial systems [@figueroa2020survey]. +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](https://access.redhat.com/security/updates/classification), [Microsoft](https://www.microsoft.com/en-us/msrc/security-update-severity-rating-system), and [Cisco](https://tools.cisco.com/security/center/resources/security_vulnerability_policy.html#asr). +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. diff --git a/doc/md_src_files/sources_ssvc.bib b/doc/md_src_files/sources_ssvc.bib index 6a8a8704..7d7a33d9 100644 --- a/doc/md_src_files/sources_ssvc.bib +++ b/doc/md_src_files/sources_ssvc.bib @@ -145,6 +145,18 @@ @article{bano2018scanning address = {New York, NY} } +@article{wang2017characterizing, + title={Characterizing and modeling patching practices of industrial control systems}, + author={Wang, Brandon and Li, Xiaoye and de Aguiar, Leandro P and Menasche, Daniel S and Shafiq, Zubair}, + journal={Measurement and Analysis of Computing Systems}, + volume={1}, + number={1}, + pages={1--23}, + year={2017}, + publisher={ACM}, + address = {New York, NY, USA} +} + %%%% End Miscellaneous articles %%%% Miscellaneous conference proceedings diff --git a/doc/ssvc_v2-0.html b/doc/ssvc_v2-0.html index 7911b6f7..407e6a04 100644 --- a/doc/ssvc_v2-0.html +++ b/doc/ssvc_v2-0.html @@ -1,5 +1,5 @@ - + @@ -172,31 +172,30 @@

Prioritizing vulnerability response: A stakeholder-specific vulnerability categorization (DRAFT version 2.0)

Jonathan M. Spring; Eric Hatleback; Allen D. Householder; Art Manion; Madison Oliver; Vijay Sarvapalli; Deana Shick; Laurie Tyzenhaus

-

Compiled Wed Mar 10 00:26:11 UTC 2021

+

Compiled Mon Mar 8 21:08:35 UTC 2021

Introduction

-

Many organizations use the Common Vulnerability Scoring System (CVSS) to prioritize actions during vulnerability management. This paper builds on prior work about prioritizing actions during vulnerability management by presenting a testable Stakeholder-Specific Vulnerability Categorization (SSVC) that avoids some problems with CVSS. SSVC takes the form of decision trees for different vulnerability management communities. We welcome others to test and improve it.

-

This paper proposes a functional system to make our proposal concrete as well as preliminary tests of its usefulness. However, our proposal is a detailed hypothesis to test or a conversation starter; it is not a final proposal. The stakeholders in vulnerability management are diverse, and that diversity must be accommodated in the main functionality, rather than squeezed into hard-to-use optional features. Given this, as much as it is practical, we aim to avoid one-size-fits-all solutions.

-

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, 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. Others may have different satisfactory models, and that is okay.

-

The organizing concept of our decision-making procedure is decision trees. A decision tree represents important elements of a decision, possible decision values, and possible outcomes. We suggest decision trees as an adequate formalism for practical, widespread advice about vulnerability prioritization. We do not claim this approach is the only viable option. We also suggest that specific vulnerability management stakeholder communities use decision trees. These suggestions are hypotheses for viable replacements for CVSS in those communities, but the hypotheses require empirical testing before they can be justifiably considered fit for use. We propose a methodology for such testing.

-

The rest of the paper is organized as follows. Section 2 summarizes the current state of vulnerability management. Section 3 describes our design goals for an improved prioritization method. Section 4 proposes a definition of decision points and decision trees as a prioritization method. Section 5 describes an early test of this method against the design goals, as much to show an adequate usability test methodology as for the results. Section 6 provides examples of applying the methodology of Section 4 to sample vulnerabilities. Section 7 identifies future work. Section 8 identifies limitations in the design. Section 9 concludes with some final thoughts.

+

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

+

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

+

Our decision-making process is based on decision trees. A decision tree represents important elements of a decision, possible decision values, and possible outcomes. We suggest decision trees as an adequate formalism for practical, widespread advice about vulnerability prioritization. We do not claim this approach is the only viable option. We suggest that specific vulnerability management stakeholder communities use decision trees. These suggestions are hypotheses for viable replacements for CVSS in those communities, but the hypotheses require empirical testing before they can be justifiably considered fit for use. We propose a methodology for such testing.

+

The document is organized as follows. Current State of Practice summarizes the current state of vulnerability management. Representing Information for Decisions About Vulnerabilities describes our design goals for an improved prioritization method. Vulnerability Management Decisions defines who the decision makers are and what options they are deciding among. Likely Decision Points and Relevant Data proposes a definition of decision points that a stakeholder might use during vulnerability management. Prioritization combines these decision points into example decision trees that can be used to prioritize action on a work item. Evaluation of the Draft Trees describes an early test of this method against the design goals, as much to show an adequate usability test methodology as for the results. Worked example provides examples of applying the methodology to sample vulnerabilities and discusses the relationship between SSVC and other vulnerability management prioritization systems. Future Work identifies ideas we haven't had time to incorporate yet. Limitations identifies limitations in the design. Conclusion concludes with some final thoughts.

Current state of practice

-

Vulnerability management is a term of art for security practitioners, used to include “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” (Benetis et al. 2019). 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 angle.

-

The de facto standard prioritization language is CVSS (Jonathan M. Spring and Illari 2019). CVSS avoids discussing decisions and, instead, takes technical severity as its fundamental concept. We understand severity’s role as informing decision making about vulnerability management. The CVSS standard indicates vulnerability management decisions, and only those decisions, as what they expect CVSS scores to inform -- “CVSS provides a way to capture the principal characteristics of a vulnerability … reflecting its severity … to help organizations properly assess and prioritize their vulnerability management processes” (Wiles and Dugal 2019). However, the standard does not provide clear advice about how CVSS scores might inform decisions.

-

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 (CVSS SIG 2019). However, as two examples, the U.S. government (see Scarfone et al. 2008, 7–4; Souppaya and Scarfone 2013, 4; and Cybersecurity and Infrastructure Security Agency 2015) and the global payment card industry (PCI Security Standards Council 2017) both have defined such misuse as expected practice in their vulnerability management requirements. 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 (Chase and Coley 2019), robotics (Vilches et al. 2018), and industrial systems (Figueroa-Lorenzo, Añorga, and Arrizabalaga 2020). 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. The various stakeholder re-adaptations of CVSS suggest a stakeholder-specific prioritization is important.

-

Unfortunately, all such re-adaptation of the basic CVSS mindset inherit its deeper issues. For example, the CVSS scoring algorithm has not been argued for transparently, and the standardization group has not justified the use of the formula either formally or empirically (Jonathan M. Spring et al. 2018). In addition, severity should only be a part of vulnerability response prioritization (See, e.g., Farris et al. 2018). One complaint is that a high CVSS score is not predictive of which vulnerabilities will be commonly exploited or have exploits publicly released (Allodi and Massacci 2012). Studies of CVSS scoring consistency indicate that analysts do not consistently interpret the elements of a CVSSv3.0 score (Allodi et al. 2018), and as many adaptations of CVSS simply add additional metrics we expect they 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 (Garfinkel and Lipford 2014).

-

Surveys of security metrics (Pendleton et al. 2016) and information sharing in cybersecurity (Laube and Böhme 2017) do not indicate any major efforts to conduct a wholesale rethinking of vulnerability prioritization. The surveys indicate some options for available measurements a prioritization method might consider, such as exploit availability or system attack surface. Section 3 describes our design goals for a pragmatic prioritization methodology that can improve and build on the state of current 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” (Benetis et al. 2019). 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 (Jonathan M. Spring and Illari 2019). 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 (Wiles and Dugal 2019). SSVC instead considers technical severity as one decision point in vulnerability management. Severity should only be a part of vulnerability response prioritization (See, e.g., Farris et al. 2018).

+

Any re-adaptation of the basic CVSS mindset inherits its deeper issues. As one example, the CVSS scoring algorithm has not been argued for transparently, and the standardization group has not justified the use of the formula either formally or empirically (Jonathan M. Spring et al. 2018). One complaint is that a high CVSS score is not predictive of which vulnerabilities will be commonly exploited or have exploits publicly released (Allodi and Massacci 2012). Studies of CVSS scoring consistency indicate that analysts do not consistently interpret the elements of a CVSSv3.0 score (Allodi et al. 2018), and as many adaptations of CVSS simply add additional metrics we expect they 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 (Garfinkel and Lipford 2014). SSVC aims to learn from and improve upon these issues.

+

Surveys of security metrics (Pendleton et al. 2016) and information sharing in cybersecurity (Laube and Böhme 2017) 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 (Allen D. Householder et al. 2020a): "a set of conditions or behaviors that allows the violation of an explicit or implicit security policy." There are a variety of problems or issues with computer systems that are important that 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.

+We take our definition of vulnerability from (Allen D. Householder et al. 2020a): "a set of conditions or behaviors that allows the violation of an explicit or implicit security policy." There are a variety of problems or issues with computer systems that are important that 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.

Representing Information for Decisions About Vulnerabilities

-

We chose to build our model with decisions as the central concept. We propose that decisions—rather than severity—are a more useful output. Our design requirements for an adequate decision-making process is that it clearly define whose decisions are involved, properly use evidentiary categories, be based on reliably available evidence, be transparent, and be explainable. Our inspiration and justification for these design goals is that they are the features of a satisfactory scientific enterprise (Jonathan M. Spring, Moore, and Pym 2017) adapted to this vulnerability management problem.

-

To consider decisions about managing the vulnerability rather than just 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. Furthermore, organizations in the aviation industry have different priorities than organizations that make word processors. These differences indicate a requirement: any formalism must be able to capture adequately the different decisions and priorities exhibited by different stakeholder groups. And 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 (Simon 1996). Satisficing is more appropriate to qualitative criteria; we do not need to order different methods as to which are more transparent than others, for example. Finding any system that meets all of desired criteria is enough.

-

Decisions are not numbers. Decisions 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. 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 (CVSS SIG 2019, sec. 7.5). If we take the recommended dividing line between high and critical—9.0—then it is unclear how to convert a CVSSv3.0 score of 8.9.

-

For example, under a Gaussian error distribution, 8.9 is really 60% high and 40% critical. We want decisions to be distinct and crisp; statistical overlaps of scores within 1.0 unit, for example, would muddy decision recommendations.

-

We avoid numerical representations and consider only qualitative data as inputs and outputs for any 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. The context of the vulnerability, and the systems it impacts, are inextricably linked to managing it. Temporal and environmental considerations should be primary, not optional as they are in CVSS.

+

We propose that decisions—rather than severity—are a more useful approach. Our design goals for the decision-making process are: clearly define whose decisions are involved, properly use evidentiary categories, be based on reliably available evidence, be transparent, and be explainable. Our inspiration and justification for these design goals is that they are the features of a satisfactory scientific enterprise (Jonathan M. Spring, Moore, and Pym 2017) adapted to the vulnerability management problem.

+

To consider decisions about managing the vulnerability rather than just 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 be able to capture adequately the different decisions and priorities exhibited by different stakeholder groups. And 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 (Simon 1996). Finding any system that meets all of desired criteria is enough.

+

Decisions are not numbers. Decisions 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 (CVSS SIG 2019, sec. 7.5). 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. The context of the vulnerability, and the systems it impacts, are inextricably linked to managing it. Temporal and environmental considerations should be primary, not optional as they are in CVSS.

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

-

Finally, any result of a decision-making process should be explainable. (Explainable is defined and used with its common meaning. This meaning is not the same as “explainable,” as 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.

+

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.

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

Formalization Options

-

This section briefly surveys the available formalization options against the six requirements described above. Table 1 summarizes the results. This survey is opportunistic, and 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 need to search only until a satisfactory option is found. Thus, we focus on highlighting why some common options or suggestions do not meet the above criteria. We argue that decision trees are a satisfactory formalism.

-

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 our sense) and quantitative. Random forest algorithms may appear in scope since each individual decision tree can be traced and the decisions explained (Russell and Norvig 2011). However, it’s 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 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. However, while the explanations provided by logical tools are accessible to experts, non-experts may struggle. However, 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 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 used to document a human process. In decision analysis “decision analysts frequently use specialized tools, such as decision tree techniques, to evaluate uncertain situations. Unfortunately, many people, some of them educators, have confused decision analysis with decision trees. This is like confusing surgery with the scalpel” (Howard and Matheson 1983, viii). We use decision trees in the tradition of decision analysis, not ML.

-

Table 1: Comparison of Formalization Options for Vulnerability Prioritization Decisions

+

This section briefly surveys the available formalization options against the six design goals described above. Table 1 summarizes the results. This survey is opportunistic, 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.

+

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 (Russell and Norvig 2011). 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 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 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 used to document a human process. In decision analysis, analysts “frequently use specialized tools, such as decision tree techniques, to evaluate uncertain situations” (Howard and Matheson 1983, viii). We use decision trees in the tradition of decision analysis, not ML.

+

Table: How Vulnerability Prioritization Options Meet the Design Goals

@@ -309,14 +308,14 @@

Formalization Options

Decision Trees

-

A decision tree is an acyclic, flowchart-like 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 more than two options and may have different options from other decision points.

-

Decision trees can be used to meet all of the desired criteria described above. The two less-obvious criteria met by decision trees are plural recommendations and transparent tree-construction processes. Decision trees support plural recommendations simply 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.

+

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 (Manion et al. 2009). 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 have 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,slow,diffuse,laborious,partial,minor,defer
-

Where "2" is the row number, none through minor are values for decision points, and defer 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.

+

Where "2" is the row number, none through minor are values for decision points, and defer 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.

The tree visualization options are more diverse. We have provided an example format, and codified it in src/SSVC_csv-to-latex.py. The reader might ask why we have gone to this trouble when, for example, the data.tree package has a handy print-to-ASCII function. It produces output like the following:

1    start                                        
 2     ¦--AV:N                                     
@@ -330,7 +329,7 @@ 
Representation choices

 35    ¦   ¦   ¦   ¦   ¦       ¦   ¦--A:H  Critical

That sample is a snippet of the CVSSv3.0 base scoring algorithm represented as a decision tree. The full tree can be found in doc/graphics/cvss_tree_severity-score.txt. 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.

Vulnerability Management Decisions

-

This section will define who we are trying to give decision advice to, 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, 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.

+

This section will define who we are trying to give decision advice to, 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, 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 the examples realistic, we invite the community to engage and conduct empirical assessments to test examples. 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. 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 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, so whether or not the stakeholder is in a safety-critical sector, the decision will be addressed.

@@ -342,10 +341,10 @@

Enumerating Decisions

Stakeholders with different responsibilities in vulnerability management have largely 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. 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. The list goes on. Alternatively, one might view applying patches as, de facto, including some development and distribution of the updated product. Or one might take the converse view, that development, de facto, 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: (1) identify the decisions explicitly, (2) describe how they view their role(s), and (3) identify which software projects their decision relates to. If their decisions are explicit, then the decision makers can use the recommendations from this document that are relevant to them.

Enumerating Vulnerability Management Actions

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. 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. The units of work can also change as the vulnerability response progresses through a stakeholder's process. We elucidate these ideas with the following examples.

+

The unit of work may be different for different stakeholders. The units of work can also change as the vulnerability response progresses through a stakeholder's process. We elucidate these ideas with the following examples.

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.

-

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.

+

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.

+

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

-

Without belaboring the point, the above methods are similar to how CVE Numbering Authorities discern "independently fixable vulnerabilities" (CVE Board 2020). We also note that SBOM(Jump and Manion 2019) seems well-placed to aid in that resolution process for the third-party library scenarios.

-

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 Deployers' input. SSVC focuses just 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.

+

Without belaboring the point, the above methods are similar to how CVE Numbering Authorities discern "independently fixable vulnerabilities" (CVE Board 2020). We also note that SBOM(Jump and Manion 2019) seems well-placed to aid in that resolution process for the third-party library scenarios.

+

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 Deployers' input. SSVC focuses just 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.

Deployer Units of Work

Deployers are usually in the position of receiving remediations or mitigations from their Suppliers for products they have deployed. They are then faced with the decision 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

@@ -369,7 +368,7 @@

Coordinator Units of Work

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.

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.

-

To further clarify terms, "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." (Office of the DoD Chief Information Officer 2020, sec. 3.5) 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.

+

To further clarify terms, "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." (Office of the DoD Chief Information Officer 2020, sec. 3.5) 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.

Supplying Patches

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 Table 2.

Table 2: Proposed Meaning for Supplier Priority Outcomes

@@ -405,9 +404,10 @@

Supplying Patches

Deploying Patches

Whether or not to deploy available remediation is a binary decision. However, additional defensive mitigations may be necessary sooner than patches are available and may be advisable after patches are applied. We recognize that vulnerability management actions are different when a patch is available and when it is not available.

-

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. For example, effective firewall and IDS rules may change System Exposure from open to controlled. Financial well-being impact might be reduced with adequate fraud detection and insurance. Physical well-being impact might be reduced by physical barriers that restrict a robot's ability to interact with humans. Mission impact might be reduced by introducing back-up business flows that do not use the vulnerable component.

+

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. For example, effective firewall and IDS rules may change System Exposure from open to controlled. Financial well-being impact might be reduced with adequate fraud detection and insurance. Physical well-being impact might be reduced by physical barriers that restrict a robot's ability to interact with humans. Mission impact might be reduced by introducing back-up business flows that do not use the vulnerable component.

Mitigation techniques may not affect the SSVC decision. The mitigating action may not be permanent or work as designed. For example, 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.

-

A mitigation that successfully changes the value of a decision point may shift the priority of further action to a reduced state. An effective firewall or IDS rule coupled with an adequate change control process for rules may be enough to reduce the priority where no further action is necessary. In the area of Financial impacts, a better insurance policy may be purchased, providing necessary fraud insurance. Physicial well-being impact may be reduced by testing the physicial 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. If applying a mitigation reduces the priority to defer, the deployer may not need to apply a remediation if it later becomes available. Table 3 displays the action priorities for the deployer, which are similar to the supplier case.

+

A mitigation that successfully changes the value of a decision point may shift the priority of further action to a reduced state. An effective firewall or IDS rule coupled with an adequate change control process for rules may be enough to reduce the priority where no further action is necessary. In the area of Financial impacts, a better insurance policy may be purchased, providing necessary fraud insurance. Physicial well-being impact may be reduced by testing the physicial 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. If applying a mitigation reduces the priority to defer, the deployer may not need to apply a remediation if it later becomes available. Table 3 displays the action priorities for the deployer, which are similar to the supplier case.

+

Table 3: Proposed Meaning for Deployer Priority Outcomes

@@ -446,12 +446,12 @@

Coordinating Patches

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 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 (Allodi et al. 2018, see Figure 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.

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.

Risk Tolerance and Response Priority

-

SSVC enables stakeholders to balance and manage their risks themselves. We follow (ISO 2009) and define risk as "effect of uncertainty on objectives;" see (ISO 2009) for notes on the terms in the definition. For any vulnerability management practice to succeed it must balance at least two risks:

+

SSVC enables stakeholders to balance and manage their risks themselves. We follow (ISO 2009) and define risk as "effect of uncertainty on objectives;" see (ISO 2009) for notes on the terms in the definition. For any vulnerability management practice to succeed it must balance at least two risks:

  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
-

To place these risks in context, we follow the SEI's Taxonomy of Operational Cyber Security Risks (Cebula and Young 2010). 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.

+

To place these risks in context, we follow the SEI's Taxonomy of Operational Cyber Security Risks (Cebula and Young 2010). 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.

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. For example, 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.

Scope

@@ -459,18 +459,18 @@

Scope

However, users of the decision process may want to define different scopes. Users may define a different scope as long as the scope is consistent across decisions, and are credible, explicit, and accessible to all relevant decision makers.

For example, suppliers often decline to support products beyond a declared end-of-life (EOL) date. In those 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, since 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. One problem is that in every practical case, both are involved. Software is what has vulnerabilities and is what vulnerability management is focused on remediation. 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” (Jonathan M. Spring, Kern, and Summers 2015). 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 per se; they are about the 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.

+

One distinction is whether the system of interest is software per se or a cyber-physical system. One problem is that in every practical case, both are involved. Software is what has vulnerabilities and is what vulnerability management is focused on remediation. 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” (Jonathan M. Spring, Kern, and Summers 2015). 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 per se; they are about the 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 a part of another. 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. 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 (Jonathan M. Spring and Illari 2018).

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:

Products, libraries, and applications tend to be appropriate objects of focus when seeking the right level to analyze the impact of a vulnerability. Hence, when reasoning about the technical impact of a vulnerability 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 (Allen D. Householder et al. 2020a). For an organizational PSIRT or CSIRT, the organization's security policy is most relevant. The answer is less clear for coordinators or ISACs. 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.

+

Our definition of a vulnerability includes a security policy violation, but it does not clarify whose security policies are relevant (Allen D. Householder et al. 2020a). For an organizational PSIRT or CSIRT, the organization's security policy is most relevant. The answer is less clear for coordinators or ISACs. 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. Overall, 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.

Likely Decision Points and Relevant Data

@@ -510,8 +510,8 @@

Exploitation

Gathering Information About Exploitation

(Allen D. Householder et al. 2020b) presents a method for searching the GitHub repositories of open-source exploit databases. This method could be leveraged to provide some 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), perhaps we could construct a mapping of CWE-IDs which always represent vulnerabilities with well-known methods of exploitation. 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. A comprehensive set of suggested CWE-IDs for this purpose is future work.

-

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 -- say 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 what vulnerability a novel piece of malware uses may be time consuming, requiring reverse engineering and a lot of trial and error. Getting to the reverse engineering requires a capable incident detection and analysis capability as well. Most organizations do not conduct these processes fully for most incidents, so in general information about what vulnerabilities are being actively exploited comes from public reporting by those who 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 there is no evidence of exploitation. This framing admits that an analyst may not be able to detect or know about every attack. 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 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).

+

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 -- say 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 what vulnerability a novel piece of malware uses may be time consuming, requiring reverse engineering and a lot of trial and error. Getting to the reverse engineering requires a capable incident detection and analysis capability as well. Most organizations do not conduct these processes fully for most incidents, so in general information about what vulnerabilities are being actively exploited comes from public reporting by those who 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 there is no evidence of exploitation. This framing admits that an analyst may not be able to detect or know about every attack. 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 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).

Technical Impact

Technical Impact of Exploiting the Vulnerability

@@ -552,9 +552,11 @@

Utility

The Usefulness of the Exploit to the Adversary

-

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 exploit code to or are in fact exploiting the vulnerability. In economics 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 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. Subsections for 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 Utility Decision Values. The next table is an equivalent expression of Utility more like a lookup table a program might use.

+ +

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 exploit code to or are in fact exploiting the vulnerability. In economics 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 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) are defined in Sections 4.4.3.1 and 4.4.3.2.

+

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 Table 6. Table 7 is an equivalent expression of Utility more like a lookup table a program might use.

+ @@ -614,7 +616,7 @@

Utility

Automatable

-

Automatable captures the answer to the question "Can an attacker reliably automate creating exploitation events for this vulnerability?" The metric can take the values no or yes:

+

Automatable captures the answer to the question "Can an attacker reliably automate creating exploitation events for this vulnerability?" The metric can take the values no or yes: