Compiled Wed Mar 10 00:26:11 UTC 2021
+Compiled Mon Mar 8 21:08:35 UTC 2021
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.
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 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:
Outputs are decisions.
The results are explainable.
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
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.
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,deferWhere "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 CriticalThat 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.
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.
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 @@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.
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.
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.
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 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.
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.
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 @@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 @@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.
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:
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.
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).
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:
Nearest is relative to the abstraction at which the vulnerability exists.
Relevant implies that the impacted component must be in the chain of abstraction moving upward from the location of the flaw.
More abstract means it’s at least one level of abstraction above the specific location of the vulnerability. For example, if the vulnerability is localized to a single line of code in a function, then the function, the module, the library, the application, the product, and the system it belongs to are all "more abstract."
More abstract means it’s at least one level of abstraction above the specific location of the vulnerability. For example, if the vulnerability is localized to a single line of code in a function, then the function, the module, the library, the application, the product, and the system it belongs to are all "more abstract."
Discrete means there is an identifiable thing that can be remediated (e.g., the unit of patching).
Products, libraries, and applications tend to be appropriate objects of focus when seeking the right level to analyze the impact of a vulnerability. 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.
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.
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.
(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 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:
- no: Attackers cannot reliably automate steps 1-4 of the kill chain (Hutchins, Cloppert, and Amin 2011) for this vulnerability for some reason. These steps are reconnaissance, weaponization, delivery, and exploitation. Example reasons for why a step may not be reliably automatable include
@@ -628,7 +630,7 @@
Automatable
Due to vulnerability chaining, there is some nuance as to whether reconnaissance can be automated. For example, consider a vulnerability A. If the systems vulnerable to A are usually not openly connected to incoming traffic (Exposure is small or controlled), reconnaissance probably cannot be automated (as scans should be blocked, etc.). This fact would make automatable no. However, if another vulnerability B with a yes to automatable can be reliably used to chain to vulnerability A, then that automates reconnaissance of vulnerable systems. In such a situation, the analyst should continue to analyze vulnerability A to understand whether the remaining steps in the kill chain can be automated.
Gathering Information About Automatable
An analyst should be able to sketch the automation scenario and how it either does or does not satisfy each of the four kill chain steps. Once one step is not satisfied, the analyst can stop and select no. Code that demonstrably automates all four kill chain steps certainly satisfies as a sketch. We say sketch to indicate that plausible arguments, such as convincing psuedocode of an automation pathway for each step, are also adequate evidence in favor of a yes to Automatable.
-Like all SSVC decision points, Automatable should capture the analyst's best understanding of plausible scenarios at the time of the analysis. An answer of no does not mean that it is absolutely inconceivable to automate exploitation in any scenario. It means the analyst is not able to sketch a plausible path through all four kill chain steps. "Plausible" sketches should account for widely deployed network and host-based defenses. Liveness of Internet-connected services means quite a few overlapping things (Bano et al. 2018), and for most vulnerabilities just because a port is open does not automatically mean that reconnaissance, weaponization, and delivery are automatable. Furthermore, just because two hosts are misconfigured to have expose a vulnerable service while 2 million are properly configured does not make discovery of the service automatable. Recall, as discussed in in Reasoning Steps Forward, the analyst should consider credible effects based on known use cases of the software system in order to be pragmatic about scope and providing values to decision points.
+Like all SSVC decision points, Automatable should capture the analyst's best understanding of plausible scenarios at the time of the analysis. An answer of no does not mean that it is absolutely inconceivable to automate exploitation in any scenario. It means the analyst is not able to sketch a plausible path through all four kill chain steps. "Plausible" sketches should account for widely deployed network and host-based defenses. Liveness of Internet-connected services means quite a few overlapping things (Bano et al. 2018), and for most vulnerabilities just because a port is open does not automatically mean that reconnaissance, weaponization, and delivery are automatable. Furthermore, just because two hosts are misconfigured to have expose a vulnerable service while 2 million are properly configured does not make discovery of the service automatable. Recall, as discussed in in Reasoning Steps Forward, the analyst should consider credible effects based on known use cases of the software system in order to be pragmatic about scope and providing values to decision points.
Value Density
Value Density is described as diffuse or concentrated based on the resources that the adversary will gain control over with a single exploitation event:
@@ -637,7 +639,7 @@
Value Density
Gathering Information About Value Density
The heuristics presented in the Value Density definitions involve whether the system is usually maintained by a dedicated professional or not, though we have noted some exceptions to this, such as encrypted mobile messaging apps. If there are additional counterexamples to this heuristic, please describe the example and the reasoning why the system should have the alternative decision value in an issue on the SSVC GitHub.
-An analyst might use market research reports or Internet telemetry data to assess an unfamiliar product. Organizations such as Gartner produce research on the market position and product comparisons for a large variety of systems. These generally identify how a product is deployed, used, and maintained. An organization's own marketing materials are a less reliable indicator of how a product is used, or at least how the organization expects it to be used.
+An analyst might use market research reports or Internet telemetry data to assess an unfamiliar product. Organizations such as Gartner produce research on the market position and product comparisons for a large variety of systems. These generally identify how a product is deployed, used, and maintained. An organization's own marketing materials are a less reliable indicator of how a product is used, or at least how the organization expects it to be used.
Network telemetry can inform how many instances of a software system are connected to a network. Such telemetry is most reliable for the supplier of the software, especially if software licenses are purchased and checked. Measuring how many instances of a system are in operation is useful, but more does not mean the software is a densely valuable target. Though, at some point, market penetration for some purpose of, say, greater than 75% or so starts to mean the product uniquely provides for a particular market segment or purpose. This line or reasoning is what supports a determination that a ubiquitous encrypted mobile messaging app should be considered concentrated.
Alternative Utility Outputs
Alternative heuristics for proxying adversary utility are plausible. One such example is the value the vulnerability would have were it sold on the open market. Some firms, such as Zerodium, make such pricing structures public. The valuable exploits track the automatable and value density heuristics for the most part. Within a single system—whether it is Apache, Windows, iOS or WhatsApp—more automated kill chain steps successfully leads to higher exploit value. Remote code execution with sandbox escape and without user interaction are the most valuable exploits, and those features describe automation of the relevant kill chain steps. How equivalently virulent exploits for different systems are priced relative to each other is more idiosyncratic. Price does not only track value density of the system, but presumably also the existing supply of exploits and the installation distribution among the targets of Zerodium’s customers. Currently, we simplify the analysis and ignore these factors. However, future work should look for and prevent large mismatches between the outputs of the Utility decision point and the exploit markets.
@@ -876,18 +878,22 @@Gathering Information About
As a heuristic, Utility might constrain Mission Impact if both are not used in the same decision tree. For example, if it's super effective then Mission Impact is at least MEF support crippled.
Situated Safety / Mission Impact
In pilot implementations of SSVC, we received feedback that organizations tend to think of mission and safety impacts as if they were combined into a single factor: in other words, the priority increases regardless which of the two impact factors was increased. We therefore combine Situated Safety and Mission Impact for deployers into a single Potential Impact factor as a dimension reduction step as follows. We observe that the day-to-day operations of an organization often have already built in a degree of tolerance to small-scale variance in mission impacts. Thus in our opinion we need only concern ourselves with discriminating well at the upper end of the scale. Therefore we combine the three lesser mission impacts of none, non-essential degraded, and MEF support crippled into a single category, while retaining the distinction between MEF Failure and Mission Failure at the extreme. This gives us 3 levels of mission impact to work with.
-On the other hand, most organizations' tolerance for variance in safety tends to be be lower, meaning that even small deviations in safety are unlikely to go unnoticed or unaddressed. We suspect that the presence of regulatory oversight for safety issues and its absence at the lower end of the mission impact scale influences this behavior. Because of this higher sensitivity to safety concerns, we chose to retain a four-level resolution for the safety dimension. We then combine Mission Impact with Situated Safety impact and map these onto a 4-tiered scale (Low, Medium, High, Very High). The mapping is shown in Combining Mission and Situated Safety Impact.
+ +On the other hand, most organizations' tolerance for variance in safety tends to be be lower, meaning that even small deviations in safety are unlikely to go unnoticed or unaddressed. We suspect that the presence of regulatory oversight for safety issues and its absence at the lower end of the mission impact scale influences this behavior. Because of this higher sensitivity to safety concerns, we chose to retain a four-level resolution for the safety dimension. We then combine Mission Impact with Situated Safety impact and map these onto a 4-tiered scale (Low, Medium, High, Very High). The mapping is shown in Table X.
+
- Combining Mission Impact and Situated Safety Impact into one result. + +Table X: Combining Mission Impact and Situated Safety Impact into one result. +- Mission Impact +Mission Impact @@ -897,7 +903,7 @@ Situated Safety / Mission Impact
Mission Failure - Situated Safety Impact +Situated Safety Impact None/Minor Low Medium @@ -933,12 +939,14 @@Situated Safety / Mission Impact
| Catastrophic | Very High | Very High | Very High | -->Safety and Mission Impact Decision Points for Industry Sectors
-We expect to encounter diversity in both safety and mission impacts across different organizations. However, we also anticipate a degree of commonality of impacts to arise across organizations within a given industry sector. For example, different industry sectors may have different use cases for the same software. Therefore, vulnerability information providers -- that is, vulnerability databases, Information Sharing and Analysis Organizations (ISAOs), or Information Sharing and Analysis Centers (ISACs) -- may provide SSVC information tailored as appropriate to their constituency's safety and mission concerns. For considerations on how organizations might communicate SSVC information to their constituents, see Guidance on Communicating Results.
+ +We expect to encounter diversity in both safety and mission impacts across different organizations. However, we also anticipate a degree of commonality of impacts to arise across organizations within a given industry sector. For example, different industry sectors may have different use cases for the same software. Therefore, vulnerability information providers -- that is, vulnerability databases, Information Sharing and Analysis Organizations (ISAOs), or Information Sharing and Analysis Centers (ISACs) -- may provide SSVC information tailored as appropriate to their constituency's safety and mission concerns. For considerations on how organizations might communicate SSVC information to their constituents, see [#pilot-results].
+System Exposure
-The Accessible Attack Surface of the Affected System or Service
Measuring attack surface precisely is difficult, and we do not propose to perfectly delineate between small and controlled access. Exposure should be judged against the system in its deployed context, which may differ from how it is commonly expected to be deployed. For example, the exposure of a device on a vehicle's CAN bus will vary depending on the presence of a cellular telemetry device on the same bus.
+Measuring attack surface precisely is difficult, and we do not propose to perfectly delineate between small and controlled access. Exposure should be judged against the system in its deployed context, which may differ from how it is commonly expected to be deployed. For example, the exposure of a device on a vehicle's CAN bus will vary depending on the presence of a cellular telemetry device on the same bus.
If a vulnerability cannot be remediated, other mitigations may be used. Usually, the effect of these mitigations is to reduce exposure of the vulnerable component. Therefore, a deployer’s response to Exposure may change if such mitigations are put in place. If a mitigation changes exposure and thereby reduces the priority of a vulnerability, that mitigation can be considered a success. Whether that mitigation allows the deployer to defer further action varies according to each case.
@@ -971,13 +979,13 @@ Gathering Information About
System Exposure can be readily informed by network scanning techniques. For example, if the vulnerable component is visible on Shodan or by some other external scanning service, then it is open. Network policy or diagrams are also useful information sources, especially for services intentionally open to the Internet such as public web servers. An analyst should also choose open for a phone or PC that connects to the web or email without the usual protections (for example, IP and URL blocking, updated firewalls, etc.).
Distinguishing between small and controlled is more nuanced. If open has been ruled out, some suggested heuristics for differentiating the other two are as follows. Apply these heuristics in order, and stop once one applies.
-
- If the system's networking and communication interfaces have been physically removed or disabled, choose small.
+- If the system's networking and communication interfaces have been physically removed or disabled, choose small.
- If Automatable is yes, then choose controlled. The reasoning behind this heuristic is that if reconnaissance through exploitation is automatable, then the usual deployment scenario exposes the system sufficiently that access can be automated, which contradicts the expectations of small.
- If the vulnerable component is on a network where other hosts can browse the web or receive email, choose controlled.
If you have suggestions for further heuristics, or potential counterexamples to these, please describe the example and reasoning in an issue on the SSVC GitHub.
Decisions During Vulnerability Coordination
-Coordinators are facilitators within the vulnerability management ecosystem. Since coordinators neither supply nor deploy the vulnerable component in question, their decisions are different from suppliers' or deployers' decisions. This section provides a window into CERT/CC's decisions as an example of how a coordinator might use SSVC to make its own decisions.
+Coordinators are facilitators within the vulnerability management ecosystem. Since coordinators neither supply nor deploy the vulnerable component in question, their decisions are different from suppliers' or deployers' decisions. This section provides a window into CERT/CC's decisions as an example of how a coordinator might use SSVC to make its own decisions.
Coordinators vary quite a lot, and their use of SSVC may likewise vary. A coordinator may want to gather and publish information about SSVC decision points that it does not use internally in order to assist its constituents. Furthermore, a coordinator may only publish some of the information it uses to make decisions. Consistent with other stakeholder perspectives (supplier and deployer), SSVC provides the priority with which a coordinator should take some defined action, but not how to do that action. For more information about types of coordinators and their facilitation actions within vulnerability management, see (Allen D. Householder et al. 2020a).
The two decisions that CERT/CC makes as a coordinator that we will discuss in terms of SSVC are the initial triage of vulnerability reports and whether a publication about a vulnerability is warranted. The initial coordination decision is a prioritization decision, but it does not have the same values as prioritization by a deployer or supplier. The publication decision for us is a binary yes/no. These two decisions are not the entirety of vulnerability coordination, but we leave further details of the process for future work.
Different coordinators have different scopes and constituencies. See (Allen D. Householder et al. 2020a, 3.5) for a listing of different coordinator types. If a coordinator receives a report that is outside its own work scope or constituency, it should make an effort to route the report to a more suitable coordinator. The decisions in this section assume the report or vulnerability in question is in the work scope or constituency for the coordinator.
@@ -986,7 +994,7 @@Coordination Triage Decisions
- Decline - Do not act on the report. May take different forms, including ignoring the report as well as an acknowledgement to the reporter that we will not act and suggest the reporter to go to vendor or publish if unresponsive.
- Track - Receive information about the vulnerability and monitor for status changes but do not take any overt actions.
-- Coordinate - Take action on the report. "Action" may include any one or more of: technical analysis, reproduction, notifying vendors, lead coordination (notify, communicate, and publish), publish only (amplify public message), advise only, secondary coordinator (assist another lead coordinator). See (Benetis et al. 2019) for additional vulnerability management services a coordinator may provide.
+- Coordinate - Take action on the report. "Action" may include any one or more of: technical analysis, reproduction, notifying vendors, lead coordination (notify, communicate, and publish), publish only (amplify public message), advise only, secondary coordinator (assist another lead coordinator). See (Benetis et al. 2019) for additional vulnerability management services a coordinator may provide.
Coordinator Decision Points
Our goal with the coordination decision is to base it on information that is available to the analyst when CERT/CC receives a vulnerability report. In addition to using some of the decision points in Likely Decision Points; coordination makes use of Utility and Public Safety Impact decision points. The coordination and publication decisions for CERT/CC are about the social and collaborative state of vulnerability management. To assess this, the decision involves five new decision points.
@@ -1010,7 +1018,7 @@Supplier Cardinality
- Multiple
Supplier Engagement
-Is the supplier responding to the reporter's contact effort and actively participating in the coordination effort?
+Is the supplier responding to the reporter's contact effort and actively participating in the coordination effort?
- Active
- Unresponsive
@@ -1038,29 +1046,29 @@Credibility Indicators
Indicators against Credibility include:
-
-- The report is "spammy" or exploitative. E.g., the report is an attempt to upsell the receiver on some product or service.
-- The report is vague or ambiguous about which vendors, products, or versions are affected. E.g., the report claims that all "cell phones" or "wifi" or "routers" are affected.
+- The report is "spammy" or exploitative. E.g., the report is an attempt to upsell the receiver on some product or service.
+- The report is vague or ambiguous about which vendors, products, or versions are affected. E.g., the report claims that all "cell phones" or "wifi" or "routers" are affected.
- The report is vague or ambiguous about the preconditions necessary to exploit the vulnerability.
- The report is vague or ambiguous about the impact if exploited.
- The report exaggerates the impact if exploited.
- The report makes extraordinary claims without correspondingly extraordinary evidence. E.g., the report claims that exploitation could result in catastrophic damage to some critical system without a clear causal connection between the facts presented and the impacts claimed.
-- The report is unclear about what the attacker gains by exploiting the vulnerability. What do they get that they didn't already have? E.g., An attacker with system privileges can already do lots of bad things, so a report that assumes system privileges as a precondition to exploitation needs to explain what else this gives the attacker.
+- The report is unclear about what the attacker gains by exploiting the vulnerability. What do they get that they didn't already have? E.g., An attacker with system privileges can already do lots of bad things, so a report that assumes system privileges as a precondition to exploitation needs to explain what else this gives the attacker.
- The report depends on preconditions that are extremely rare in practice, and lacks adequate evidence for why those preconditions might be expected to occur. E.g., the vulnerability is only exposed in certain non-default configurations – unless there is evidence that a community of practice has established a norm of such a non-default setup.
- The report claims dire impact for a trivially found vulnerability. It is not impossible for this to occur, but most products and services that have been around for a while have already had their low-hanging fruit major vulnerabilities picked. One notable exception would be if the reporter applied a completely new method for finding vulnerabilities to discover the subject of the report.
- The report is rambling and is more about a narrative than describing the vulnerability. One description is that the report reads like a food recipe with the obligatory search engine optimization preamble.
- The reporter is known to have submitted low-quality reports in the past.
- The report conspicuously misuses technical terminology. This is evidence that the reporter may not understand what they are talking about.
-- The analyst's professional colleagues consider the report to be not credible.
+- The analyst's professional colleagues consider the report to be not credible.
- The report consists of mostly raw tool output. Fuzz testing outputs are not vulnerability reports.
- The report lacks sufficient detail for someone to reproduce the vulnerability.
-- The report is just a link to a video or set of images, or lacks written detail while claiming "it's all in the video". Imagery should support a written description, not replace it.
+- The report is just a link to a video or set of images, or lacks written detail while claiming "it's all in the video". Imagery should support a written description, not replace it.
- The report describes a bug with no discernible security impact.
- The report fails to describe an attack scenario, and none is obvious.
We considered adding poor grammar or spelling as an indicator of non-credibility. On further reflection, we do not recommend that poor grammar or spelling be used as an indicator of low report quality, as many reporters may not be native to the coordinator's language. Poor grammar alone isn't sufficient to dismiss a report as not credible. Even when poor grammar is accompanied by other indicators of non-credibility, those other indicators are usually sufficient to make the determination.
+We considered adding poor grammar or spelling as an indicator of non-credibility. On further reflection, we do not recommend that poor grammar or spelling be used as an indicator of low report quality, as many reporters may not be native to the coordinator's language. Poor grammar alone isn't sufficient to dismiss a report as not credible. Even when poor grammar is accompanied by other indicators of non-credibility, those other indicators are usually sufficient to make the determination.
Credibility of what to whom
-SSVC is interested in the coordinating analyst's assessment of the credibility of a report. This is separate from the fact that a reporter probably reports something because they believe the report is credible.
-The analyst should assess the credibility of the report of the vulnerability, not the claims of the impact of the vulnerability. A report may be credible in terms of the fact of the vulnerability's existence even if the stated impacts are inaccurate. However, the more extreme the stated impacts are, the more skepticism is necessary. For this reason, "exaggerating the impact if exploited" is an indicator against credibility. Furthermore, a report may be factual but not identify any security implications; such reports are bug reports, not vulnerability reports, and are considered out of scope.
+SSVC is interested in the coordinating analyst's assessment of the credibility of a report. This is separate from the fact that a reporter probably reports something because they believe the report is credible.
+The analyst should assess the credibility of the report of the vulnerability, not the claims of the impact of the vulnerability. A report may be credible in terms of the fact of the vulnerability's existence even if the stated impacts are inaccurate. However, the more extreme the stated impacts are, the more skepticism is necessary. For this reason, "exaggerating the impact if exploited" is an indicator against credibility. Furthermore, a report may be factual but not identify any security implications; such reports are bug reports, not vulnerability reports, and are considered out of scope.
A coordinator also has a scope defined by their specific constituency and mission. A report can be entirely credible yet remain out of scope for your coordination practice. Decide what to do about out of scope reports separately, before the vulnerability coordination triage decision begins.
If a report arrives and would be out of scope even if true, there will be no need to proceed with judging its credibility.Coordination Triage Decision Process
@@ -1070,7 +1078,7 @@Coordination Triage Decision Proce
- If no suppliers have been contacted, then CERT/CC will decline the case unless there are multiple suppliers, super effective Utility, and significant Public Safety Impact.
In the second case, CERT/CC may encourage the reporter to contact the supplier and submit a new case request if the supplier is unresponsive.
-These two sets of exceptional circumstances mean that the seven decision points involved in the coordination triage tree can be compressed slightly, as the tree shows. This tree's information is available as either a CSV or PDF
+These two sets of exceptional circumstances mean that the seven decision points involved in the coordination triage tree can be compressed slightly, as the tree shows. This tree's information is available as either a CSV or PDF
Publication Decision
A coordinator often has to decide when or whether to publish information about a vulnerability. A supplier also makes a decision about publicity -- releasing information about a remediation or mitigation could be viewed as a kind of publication decision. While the context of publication is different for coordinators, a supplier may find some use in a publication decision if they need to decide whether to publish before a mitigation or remediation is available. However, that is not the intended use case; this section describes how a coordinator might decide to publish information about a vulnerability.
The publication decision is always a decision at a point in time. As discussed in Guidance on Communicating Results, a SSVC decision may change over time as the inputs to that decision change. A decision to publish cannot be revoked, since the publication is likely to be archived or at least remembered. However, a decision to not publish is a decision not to publish at the time the decision was made. It is not a decision never to publish in the future. One benefit of encoding the decision process in SSVC is the analysts can all agree on what new information would change the decision and prioritize maintaining awarenss of just those decision points.
@@ -1087,9 +1095,9 @@Public Value Added
- Ampliative - amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc.
- Limited - minimal value added to the existing public information because existing information is already high quality and in multiple outlets.
-The intent of the definition is that one rarely if ever transitions from limited to ampliative or ampliative to precedence. A vulnerability could transition from precedence to ampliative and ampliative to limited. That is, Public Value Added should only be downgraded through future iterations or re-evaluations. This directionality is because once other organizations make something public, they cannot effectively un-publish it (it'll be recorded and people will know about it, even if they take down a webpage). The rare case where Public Value Added increases would be if an organization published viable information, but then published additional misleading or obscuring information at a later time. Then one might go from limited to ampliative in the interest of pointing to the better information.
+The intent of the definition is that one rarely if ever transitions from limited to ampliative or ampliative to precedence. A vulnerability could transition from precedence to ampliative and ampliative to limited. That is, Public Value Added should only be downgraded through future iterations or re-evaluations. This directionality is because once other organizations make something public, they cannot effectively un-publish it (it'll be recorded and people will know about it, even if they take down a webpage). The rare case where Public Value Added increases would be if an organization published viable information, but then published additional misleading or obscuring information at a later time. Then one might go from limited to ampliative in the interest of pointing to the better information.
Supplier Involvement
-This decision point accounts for the state of the supplier's work on addressing the vulnerability.
+This decision point accounts for the state of the supplier's work on addressing the vulnerability.
- +
- Fix Ready - the supplier has provided a patch or fix
- Cooperative - the supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time.
@@ -1115,33 +1123,26 @@Supplier Tree
- Out-of-Cycle = orange
- Immediate = red with black outline
Deployer Tree
The example deployer tree PDF is depicted below.
- +Coordinator trees
As described in Decisions During Vulnerability Coordination, a coordination stakeholder usually makes separate triage and publication decisions. Each have trees presented below.
Triage decision tree
- +This tree is a suggestion in that CERT/CC believes it works for us. Other coordinators should consider customizing the tree to their needs, as described in Tree Construction and Customization Guidance.
Publication decision tree
Suggested decision values for this decision are available in CSV and PDF formats.
- +Tree Construction and Customization Guidance
-Stakeholders are encouraged to customize the SSVC decision process to their needs. Indeed, the first part of SSVC stands for "stakeholder-specific." However, certain parts of SSVC are more amenable to customization than others. In this section, we'll cover what a stakeholder should leave static, what we imagine customization looks like, and some advice on building a usable and manageable decision tree based on our experience so far.
+Stakeholders are encouraged to customize the SSVC decision process to their needs. Indeed, the first part of SSVC stands for "stakeholder-specific." However, certain parts of SSVC are more amenable to customization than others. In this section, we'll cover what a stakeholder should leave static, what we imagine customization looks like, and some advice on building a usable and manageable decision tree based on our experience so far.
We suggest that the decision points, their definitions, and the decision values should not be customized. Different vulnerability management teams inevitably think of topics such as Utility to the adversary in slightly different ways. However, a key contribution of SSVC is enabling different teams to communicate about their decision process. In order to clearly communicate differences in the process, the decision points that factor into the process need to be the same between different teams. A stakeholder community may come together and, if there is broad consensus, add or change decision points.
-Which decision points are involved in a vulnerability management team's decision and the priority label for each resulting situation are, for all intents and purposes, totally at the discretion of the team. We have provided some examples for different stakeholder communities here. What decision points a team considers reflects what it cares about and the risks prioritizes. Different teams may legitimately prioritize different objectives. It should be easier for teams to discuss and communicate such differences if the definitions of the decision points remain static. The other aspect of risk management that SSVC allows a team to customize is its risk appetite or risk tolerance.
-A team's risk appetite is reflected directly by the priority labels for each combination of decision values. For example, a vulnerability with no or minor Public Safety Impact, total Technical Impact, and efficient Utility might be handled with scheduled priority by one team and out-of-cycle priority by another. As long as each team has documented this choice and is consistent in its own application of its own choice, the two teams can legitimately have different appetites for vulnerability risk. SSVC enables teams with such different risk appetites to discuss and communicate precisely the circumstances where they differ.
-When doing the detailed risk management work of creating or modifying a tree, we recommend working from text files with one line or row for each unique combination of decision values. For examples, see SSVC/data. An important benefit, in our experience, is that it's easier to identify a question by saying "I'm unsure about row 16" than anything else we have thought of so far. Once the humans agree on the decision tree, it can be converted to a JSON schema for easier machine-readable communication, following the provided SSVC provision JSON schema.
+ +Which decision points are involved in a vulnerability management team's decision and the priority label for each resulting situation are, for all intents and purposes, totally at the discretion of the team. We have provided some examples for different stakeholder communities here. What decision points a team considers reflects what it cares about and the risks prioritizes. Different teams may legitimately prioritize different objectives. It should be easier for teams to discuss and communicate such differences if the definitions of the decision points remain static. The other aspect of risk management that SSVC allows a team to customize is its risk appetite or risk tolerance.
+A team's risk appetite is reflected directly by the priority labels for each combination of decision values. For example, a vulnerability with no or minor Public Safety Impact, total Technical Impact, and efficient Utility might be handled with scheduled priority by one team and out-of-cycle priority by another. As long as each team has documented this choice and is consistent in its own application of its own choice, the two teams can legitimately have different appetites for vulnerability risk. SSVC enables teams with such different risk appetites to discuss and communicate precisely the circumstances where they differ.
+When doing the detailed risk management work of creating or modifying a tree, we recommend working from text files with one line or row for each unique combination of decision values. For examples, see SSVC/data. An important benefit, in our experience, is that it's easier to identify a question by saying "I'm unsure about row 16" than anything else we have thought of so far. Once the humans agree on the decision tree, it can be converted to a JSON schema for easier machine-readable communication, following the provided SSVC provision JSON schema.
+Once the decision points are selected and the prioritization labels agreed upon, it is convenient to be able to visually compress the text file by displaying it as a decision tree. Making the decision process accessible has a lot of benefits. Unfortunately, it also makes it a bit too easy to overcomplicate the decision.
The SSVC version 1 ~applier~ deployer tree had 225 rows when we wrote it out in long text form. It only has four outcomes to differentiate between. Thus, on average that decision process treats one situation (combination of decision values) as equivalent to 65 other situations. If nothing else, this means analysts are spending time gathering evidence to make fine distinctions that are not used in the final decision. The added details also make it harder for the decision process to accurately manage the risks in question. This difficulty arises because more variance and complexity there is in the decision increases the possibility of errors in the decision process itself.
While there is no hard and fast rule for when a tree is too big, we suggest that if all of your outcomes are associated with more than 15 situations (unique combinations of decision values), you would benefit from asking whether your analysts actually use all the information they would be gathering. Thus, 60 unique combinations of decision values is the point at which a decision tree with four distinct outcomes is, on average, potentially too big.
@@ -1158,18 +1159,21 @@Relationship to asset management
Asset management and risk management also drive some of the up-front work an organization would need to do to gather some of the necessary information. This situation is not new; an asset owner cannot prioritize which fixes to deploy to its assets if it does not have an accurate inventory of its assets. The organization can pick its choice of tools for these things; there are about 200 asset management tools on the market (Captera 2019). Emerging standards like the Software Bill of Materials (SBOM) (Jump and Manion 2019) would likely reduce the burden on asset management, and organizations should prefer systems which make such information available. If an organization does not have an asset management or risk management (see also Gathering Information About Mission Impact) plan and process in place, then SSVC provides some guidance as to what information is important to vulnerability management decisions and the organization should start capturing, storing, and managing.
Guidance on Communicating Results
There are many aspects of SSVC that two parties might want to communicate. Not every stakeholder will use the decision points to make comparable decisions. Suppliers and deployers make interdependent decisions, but the actions of one group are not strictly dependent on the other. Recall that one reason for this is that SSVC is about prioritizing a vulnerability response action in general, not specifically applying a patch that a supplier produced. Coordinators are particularly interested in facilitating communication because that is their core function. This section handles three aspects of this challenge: formats for communicating SSVC, how to handle partial or incomplete information, and how to handle information that may change over time.
-This section is about communicating SSVC information about a specific vulnerability. Any stakeholder making a decision on allocating effort should have a decision tree with it's decision points and possible values specified already. Representation choices and Tree Construction and Customization Guidance discussed how SSVC uses a text file as the canonical form of a decision tree; the example trees can be found in SSVC/data. This section discusses the situation where one stakeholder, usually a supplier or coordinator, wants to communicate some information about a specific vulnerability to other stakeholders or constituents.
+This section is about communicating SSVC information about a specific vulnerability. Any stakeholder making a decision on allocating effort should have a decision tree with it's decision points and possible values specified already. Representation choices and Tree Construction and Customization Guidance discussed how SSVC uses a text file as the canonical form of a decision tree; the example trees can be found in SSVC/data. This section discusses the situation where one stakeholder, usually a supplier or coordinator, wants to communicate some information about a specific vulnerability to other stakeholders or constituents.
Communication Formats
We recommend two structured communication formats, abbreviated and full. The goal of the abbreviated format is to fill a need for providing identifying information about a vulnerability or decision in charts, graphs, and tables. Therefore, the abbreviated format is not designed to stand alone. The goal of the full format is to capture all the context and details about a decision or work item in a clear and machine-readable way.
Abbreviated Format
-SSVC abbreviated form borrows directly from the CVSS "vector string" notation. Since the purpose of the abbreviated form is to provide labels for charts and graphics, it does not stand alone. The basic format for SSVC is:
--SSVC/(version)/(decision point):(value)[/decision point:value[/decision point:value[...]]][/time]/Where
+ +versionisv2if it is based on this current version of the SSVC. The termdecision pointis one or two letters derived from the name of the decision point as follows:SSVC abbreviated form borrows directly from the CVSS "vector string" notation.
+
+The basic format for SSVC is:+(version)/(decision point):(value)[/decision point:value[/decision point:value[...]]][/time]/Where
+versionisSSVCv2, updated with more options in the future as needed. The termdecision pointis one or two letters derived from the name of the decision point as follows:@@ -1194,14 +1198,14 @@
- Start with the decision point name as given in Likely Decision Points and Relevant Data.
- Remove any text in parentheses (and the parentheses themselves).
-- Remove the word "Impact" if it's part of the name.
-- Create an initialism from remaining title-case words (ignore "of," etc.), taking only the first two words.
+- Remove the word "Impact" if it's part of the name.
+- Create an initialism from remaining title-case words (ignore "of," etc.), taking only the first two words.
- The first letter of the initialism is upper case; if there is a second letter, then it is lower case.
- Verify that the initialism is unique among decision points in the version of SSVC. If two initialisms collide, sort their source names equivalent to
LC_ALL=C sort. The name that sorts first keeps the initialism for which there is a collision. Set the second letter of the initialism to the first character in the name that resolves the collision. If the names wereThreatandThreshold,Twould beThreatandTswould beThreshold. We make an effort to design SSVC without such collisions.Full JSON format
The
valueterm is derived the same way asdecision pointexcept start with the value name as given in the relevant decision point subsection of Likely Decision Points and Relevant Data.Partial or Incomplete Information
What an analyst knows about a vulnerability may not be complete. However, the vulnerability management community may still benefit from partial information. Particularly, suppliers and coordinators, who may not know everything a deployer knows, may still provide benefit to deployers by sharing what partial information they do know. A second benefit to providing methods for communicating partial information is the reduction of bottlenecks or barriers to information exchange. A timely partial warning is better than a complete warning that is too late.
-The basic guidance is that the analyst should communicate all of the vulnerability's possible states, to the best of the analyst's knowledge. If the analyst knows nothing, all states are possible. For example, Utility may be laborious, efficient, or super effective. In abbreviated form, write this as
-U:LESe. Since a capital letter always indicates a new value, this is unambiguous.The reason a stakeholder might publish something like
-U:LESeis that it expresses that the analyst thought about Utility but does not have anything to communicate. A stakeholder might have information to communicate about some decision points but not others. If SSVC uses this format to list the values that are in play for a particular vulnerability, there is no need for a special "I don't know" marker.The merit in this "list all values" approach emerges when the stakeholder knows that the value for a decision point may be A or B, but not C. For example, say the analyst knows that Value Density is diffuse but does not know the value for *Automatability. Then the analyst can usefully restrict Utility to one of laborious or efficient. In abbreviated form, write this as
+U:LE. As discussed below, information can change over time. Partial information may be, but is not required to be, sharpened over time into a precise value for the decision point.The basic guidance is that the analyst should communicate all of the vulnerability's possible states, to the best of the analyst's knowledge. If the analyst knows nothing, all states are possible. For example, Utility may be laborious, efficient, or super effective. In abbreviated form, write this as
+U:LESe. Since a capital letter always indicates a new value, this is unambiguous.The reason a stakeholder might publish something like
+U:LESeis that it expresses that the analyst thought about Utility but does not have anything to communicate. A stakeholder might have information to communicate about some decision points but not others. If SSVC uses this format to list the values that are in play for a particular vulnerability, there is no need for a special "I don't know" marker.The merit in this "list all values" approach emerges when the stakeholder knows that the value for a decision point may be A or B, but not C. For example, say the analyst knows that Value Density is diffuse but does not know the value for *Automatability. Then the analyst can usefully restrict Utility to one of laborious or efficient. In abbreviated form, write this as
U:LE. As discussed below, information can change over time. Partial information may be, but is not required to be, sharpened over time into a precise value for the decision point.Information Changes Over Time
Vulnerability management decisions are dynamic, and may change over time as the available information changes. Information changes are one reason why SSVC decisions should always be timestamped. SSVC decision points have different temporal properties. Some, such as Utility, are mostly static. For Utility to change, the market penetration or deployment norms of a vulnerable component would have to meaningfully change. Some, such as State of Exploitation, may change quickly but only in one direction.
Both of these examples are out of the direct control of the vulnerability manager. Some, such as Exposure, change mostly due to actions taken by the organization managing the vulnerable component. If the actor who can usually trigger a relevant change is the organization using SSVC, then it is relatively straightforward to know when to update the SSVC decision. That is, the organization should reevaluate the decision when they make a relevant change. For those decision points that are about topics outside the control of the organization using SSVC, then the organization should occasionally poll their information sources for changes. The cadence or rate of polls is different for each decision point, based on the expected rate of change.
We expect that updating information over time will be most useful where the evidence-gathering process can be automated. Organizations that have mature asset management systems will also find this update process more efficient than those that do not. For an organization without a mature asset management system, we would recommend putting organizational resources into maturing that function before putting effort into regular updates to vulnerability prioritization decision points.
-The following decision points are usually out of the control of the organization running SSVC. As an initial heuristic, we suggest the associated polling frequency for each. These frequencies can be customized, as the update frequency is directly related to the organization's tolerance for the risk that the information is out of date. As discussed in Tree Construction and Customization Guidance, risk tolerance is unique to each organization. Risk tolerance and risk appetite are primarily reflected in the priority labels (that is, decisions) encoded in the SSVC decision tree, but information polling frequency is also a risk tolerance decision and each organization may choose different time values.
+The following decision points are usually out of the control of the organization running SSVC. As an initial heuristic, we suggest the associated polling frequency for each. These frequencies can be customized, as the update frequency is directly related to the organization's tolerance for the risk that the information is out of date. As discussed in Tree Construction and Customization Guidance, risk tolerance is unique to each organization. Risk tolerance and risk appetite are primarily reflected in the priority labels (that is, decisions) encoded in the SSVC decision tree, but information polling frequency is also a risk tolerance decision and each organization may choose different time values.
- State of Exploitation: every 1 day
- Technical Impact: never (should be static per vulnerability)
@@ -1253,7 +1257,7 @@Pilot Methodology
- Developer Portfolio Details+ Sitemagic is an open-source project. The only thing the brand name applies to is the CMS, and it does not appear to be part of another open-source umbrella. The project is under active maintenance (i.e., it's not a dead project).Sitemagic is an open-source project. The only thing the brand name applies to is the CMS, and it does not appear to be part of another open-source umbrella. The project is under active maintenance (i.e., it's not a dead project).Technical Impact of Exploit @@ -1480,13 +1484,15 @@Worked Example
According to the fictional pilot scenario, “Our mission dictates that the first and foremost priority is to contribute to human welfare and to uphold the Hippocratic oath (do no harm).” The continuity of operations planning for a hospital is complex, with many MEFs. However, even from this abstract, it seems clear that “do no harm” is at risk due to this vulnerability. A mission essential function to that mission is each of the various medical devices works as expected, or at least if a device fails, it cannot actively be used to inflict harm. Unsolicited insulin delivery would mean that MEF “fails for a period of time longer than acceptable,” matching the description of MEF failure. The question is then whether the whole mission fails, which does not seem to be the case. The recovery of MEF functioning is not affected, and most MEFs (the emergency services, surgery, oncology, administration, etc.) would be unaffected. Therefore, we select MEF failure and move on to ask about safety impact.
Given the prior three answers (PoC, small, MEF failure), the safety analysis is somewhat constrained. If the result is none, minor, or major, the priority is scheduled. Hazardous will lead to out-of-cycle, and catastrophic to immediate action. In the pilot study, this information is conveyed as follows:
-
- Use of the cyber-physical system - Insulin pumps are used to regulate blood glucose levels in diabetics. Diabetes is extremely common in the US. Misregulation of glucose can cause a variety of problems. Minor misregulation causes confusion or difficulty concentrating. Long-term minor mismanagement causes weigh management issues and blindness. Severe acute mismanagement can lead unconsciousness in a matter of minutes and death in a matter of hours. The impacted insulin pumps have a local (on-patient) wireless control, so wires to the pump do not have to be connected to the patient's control of the system, making the system lighter and less prone to be ripped out.
+- Use of the cyber-physical system - Insulin pumps are used to regulate blood glucose levels in diabetics. Diabetes is extremely common in the US. Misregulation of glucose can cause a variety of problems. Minor misregulation causes confusion or difficulty concentrating. Long-term minor mismanagement causes weigh management issues and blindness. Severe acute mismanagement can lead unconsciousness in a matter of minutes and death in a matter of hours. The impacted insulin pumps have a local (on-patient) wireless control, so wires to the pump do not have to be connected to the patient's control of the system, making the system lighter and less prone to be ripped out.
The closest match to “death in a matter of hours” would be hazardous because that description reads “serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures.” Depending on the details of the hospital’s contingency plans and its monitoring of their patients, the Safety Impact could be catastrophic. If there is no way to tell whether the insulin pumps are misbehaving, for example, then exploitation could go on for some time, leading to a catastrophic Safety Impact. The pilot information is inadequate in this regard, which is the likely source of disagreement about Safety Impact in Table 13. For the purposes of this example, imagine that after gathering that information, the monitoring situation is adequate, and select hazardous. Therefore, mitigate this vulnerability out-of-cycle, meaning that it should be addressed quickly, ahead of the usual update and patch cycle.
Related Vulnerability Management Systems
-There are several other bodies of work that are used in practice to assist vulnerability managers in making decisions. Three relevant systems are CVSS (CVSS SIG 2019), EPSS (Jacobs et al. 2019), and Tenable's Vulnerability Priority Rating (VPR). There are other systems derived from CVSS, such as RVSS for robots (Vilches et al. 2018) and MITRE's effort to adapt CVSS to medical devices (Chase and Coley 2019). There are also other nascent efforts to automate aspects of the decision making process, such as vPrioritizer. This section discusses the relationship between these various systems and SSVC.
+There are several other bodies of work that are used in practice to assist vulnerability managers in making decisions. Three relevant systems are CVSS (CVSS SIG 2019), EPSS (Jacobs et al. 2019), and Tenable's Vulnerability Priority Rating (VPR). There are other systems derived from CVSS, such as RVSS for robots (Vilches et al. 2018) and MITRE's effort to adapt CVSS to medical devices (Chase and Coley 2019). There are also other nascent efforts to automate aspects of the decision making process, such as vPrioritizer. This section discusses the relationship between these various systems and SSVC.
CVSS
CVSS v3.1 has three metric groups: base, environmental, and temporal. The metrics in the base group are all required, and are the only required metrics. In connection with this design, CVSS base scores and base metrics are far and away the most commonly used and communicated. A CVSS base score has two parts: the exploitability metrics and the impact metrics. Each of these are echoed or reflected in aspects of SSVC, though the breadth of topics considered by SSVC is wider than CVSS 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 SIG 2019). Two examples of this include 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) 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 (Wang et al. 2017).
+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.
@@ -1496,7 +1502,7 @@Exploitability metrics (Base metric group)
CVSS
Impact metrics (Base metric group)
The metrics in this group are Confidentiality, Integrity, and Availability. There is also a loosely associated Scope metric. The CIA impact metrics are directly handled by Technical Impact.
-Scope is a difficult CVSS metric to categorize. The specification describes it as "whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope" (CVSS SIG 2019). This is a fuzzy concept. SSVC better describes this concept by breaking it down into component parts. The impact of exploitation of the vulnerable component on other components is covered under Mission Impact, public and situated Well-being Impact, and the stakeholder-specific nature where SSVC is tailored to stakeholder concerns. CVSS addresses some definitions of the scope of CVSS as a whole under the Scope metric definition. In SSVC, these definitions are in the Scope section.
+Scope is a difficult CVSS metric to categorize. The specification describes it as "whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope" (CVSS SIG 2019). This is a fuzzy concept. SSVC better describes this concept by breaking it down into component parts. The impact of exploitation of the vulnerable component on other components is covered under Mission Impact, public and situated Well-being Impact, and the stakeholder-specific nature where SSVC is tailored to stakeholder concerns. CVSS addresses some definitions of the scope of CVSS as a whole under the Scope metric definition. In SSVC, these definitions are in the Scope section.
@@ -1506,27 +1512,27 @@Temporal metric groups
CVSS
The environmental metric group allows a consumer of a CVSS base score to change it based on their environment. CVSS needs this functionality because the organizations that produce CVSS scores tend to be what SSVC calls suppliers and consumers of CVSS scores are what SSVC calls deployers. These two stakeholder groups have a variety of natural differences, which is why SSVC treats them separately. SSVC does not have such customization as a bolt-on optional metric group because SSVC is stakeholder-specific by design.
EPSS
-EPSS is an "effort for predicting when software vulnerabilities will be exploited." EPSS is currently based on a machine-learning classifier and proprietary IDS alert data from Kenna Security. While the group has made an effort to make the ML classifier transparent, ML classifiers are not able to provide an intelligible, human-accessible explanation for their behavior (Jonathan M. Spring et al. 2019). The use of proprietary training data makes the system less transparent.
+EPSS is an "effort for predicting when software vulnerabilities will be exploited." EPSS is currently based on a machine-learning classifier and proprietary IDS alert data from Kenna Security. While the group has made an effort to make the ML classifier transparent, ML classifiers are not able to provide an intelligible, human-accessible explanation for their behavior (Jonathan M. Spring et al. 2019). The use of proprietary training data makes the system less transparent.
EPSS could be used to inform the Exploitation decision point. Currently, Exploitation focuses on the observable state of the world at the time of the SSVC decision. EPSS is about predicting if a transition will occur from the SSVC state of none to active. A sufficiently high EPSS score could therefore be used as an additional criterion for scoring a vulnerability as active even when there is no observed active exploitation.
VPR
-VPR is a prioritization product sold by Tenable. VPR determines the severity level of a vulnerability based on "technical impact and threat." Just as Technical Impact in SSVC, technical impact in VPR tracks the CVSSv3 impact metrics in the base metric group. The VPR threat component is about recent and future threat activity; it is comparable to Exploitation if EPSS were added to Exploitation.
+VPR is a prioritization product sold by Tenable. VPR determines the severity level of a vulnerability based on "technical impact and threat." Just as Technical Impact in SSVC, technical impact in VPR tracks the CVSSv3 impact metrics in the base metric group. The VPR threat component is about recent and future threat activity; it is comparable to Exploitation if EPSS were added to Exploitation.
VPR is therefore essentially a subset of SSVC. VPR is stylistically methodologically quite different from SSVC. VPR is based on machine learning models and proprietary data, so the results are totally opaque. There is no ability to coherently and transparently customize the VPR system. Such customization is a central feature of SSVC, as described in Tree Construction and Customization Guidance.
CVSS spin offs
Attempts to tailor CVSS to specific stakeholder groups, such as robotics or medical devices, are are perhaps the biggest single reason we created SSVC. CVSS is one-size-fits-all by design. These customization efforts struggle with adapting CVSS because it was not designed to be adaptable to different stakeholder considerations. The SSVC section Tree Construction and Customization Guidance explains how stakeholders or stakeholder communities can adapt SSVC in a reliable way that still promotes repeatability and communication.
vPrioritizer
-vPrioritizer is an open-source project that attempts to integrate asset management and vulnerablity prioritization. The software is mostly the asset management aspects. It currently includes CVSS base scores as the de facto vulnerability prioritization method; however, fundamentally the system is agnostic to prioritization method. vPrioritizer is an example of a product that is closely associated with vulnerability prioritization, but is not directly about the prioritization method. In that sense, it is compatible with any of methods mentioned above or SSVC. However, SSVC would be better suited to address vPrioritizer's broad spectrum asset management data. For example, vPrioritizer aims to collect data points on topics such as asset significance. Asset significance could be expressed through the SSVC decision points of Mission Impact and situated Well-being Impact, but it does not have a ready expression in CVSS, EPSS, or VPR.
+vPrioritizer is an open-source project that attempts to integrate asset management and vulnerablity prioritization. The software is mostly the asset management aspects. It currently includes CVSS base scores as the de facto vulnerability prioritization method; however, fundamentally the system is agnostic to prioritization method. vPrioritizer is an example of a product that is closely associated with vulnerability prioritization, but is not directly about the prioritization method. In that sense, it is compatible with any of methods mentioned above or SSVC. However, SSVC would be better suited to address vPrioritizer's broad spectrum asset management data. For example, vPrioritizer aims to collect data points on topics such as asset significance. Asset significance could be expressed through the SSVC decision points of Mission Impact and situated Well-being Impact, but it does not have a ready expression in CVSS, EPSS, or VPR.
SSVC using Current Information Sources
Some SSVC decision points can be informed or answered by currently available information feeds or sources. These include Exploitation, System Exposure, Technical Impact, and Public Safety Impact. This section provides an overview of some options; we cannot claim it is exhaustive. Each decision point has a subsection for
-Gathering Information Aboutit. These sections provide suggestions that would also contribute to creating or honing information feeds. However, if there is a category of information source we have not captured, please create an issue on the SSVC GitHub page explaining it and what decision point it informs.Various vendors provide paid feeds of vulnerabilities that are currently exploited by attacker groups. Any of these could be used to indicate that active is true for a vulnerability. Although the lists are all different, we expect they are all valid information sources -- the difficulty is matching a list's scope and vantage with a compatible scope and vantage of the consumer. We are not aware of a comparative study of the different lists of active exploits; however, we expect they have similar properties to block lists of network touchpoints (Metcalf and Spring 2015) and malware (Kührer, Rossow, and Holz 2014). Namely, each list has a different view and vantage on the problem, which makes them appear to be different, but each list accurately represents its particular vantage at a point in time.
+Various vendors provide paid feeds of vulnerabilities that are currently exploited by attacker groups. Any of these could be used to indicate that active is true for a vulnerability. Although the lists are all different, we expect they are all valid information sources -- the difficulty is matching a list's scope and vantage with a compatible scope and vantage of the consumer. We are not aware of a comparative study of the different lists of active exploits; however, we expect they have similar properties to block lists of network touchpoints (Metcalf and Spring 2015) and malware (Kührer, Rossow, and Holz 2014). Namely, each list has a different view and vantage on the problem, which makes them appear to be different, but each list accurately represents its particular vantage at a point in time.
System Exposure could be informed by the various scanning platforms such as and Shodan and Shadowserver. A service on a device should be scored as open if such a general purpose Internet scan finds that the service responds. Such scans do not find all open systems, but any system they find should be considered open. Scanning software, such as the open-source Nessus, could be used to scan for connectivity inside an organization to catalogue what devices should be scored controlled if, say, the scan finds them on an internal network where devices regularly connect to the Internet.
There are some information sources that were not designed with SSVC in mind, but can be adapted to work. Three prominent examples of this are CVSS impact base metrics, CWE, and CPE.
-Technical Impact is directly related to the CVSS impact metric group. However, this metric group cannot be directly mapped to Technical Impact in CVSSv3 because of the Scope metric. Technical Impact is only about adversary control of the vulnerable component. If the CVSSv3 value of "Scope" is "Changed," then the impact metrics are the maximum of the impact on the vulnerable component and other components in the environment. If confidentiality, integrity, and availability metrics are all "high" then Technical Impact is total, as long as the impact metrics in CVSS are clearly about just the vulnerable component. However, the other values of the CVSSv3 impact metrics cannot be mapped directly to partial because of CVSSv3.1 scoring guidance. Namely, "only the increase in access, privileges gained, or other negative outcome as a result of successful exploitation should be considered" (CVSS SIG 2019). The example given is that if an attacker already has read access, but gains all other access through the exploit, then read access didn't change and the confidentiality metric score should be "None". However, in this case, SSVC would expect the decision point to be evaluated as total because as a result of the exploit the attacker gains total control of the device, even though they started with partial control.
+Technical Impact is directly related to the CVSS impact metric group. However, this metric group cannot be directly mapped to Technical Impact in CVSSv3 because of the Scope metric. Technical Impact is only about adversary control of the vulnerable component. If the CVSSv3 value of "Scope" is "Changed," then the impact metrics are the maximum of the impact on the vulnerable component and other components in the environment. If confidentiality, integrity, and availability metrics are all "high" then Technical Impact is total, as long as the impact metrics in CVSS are clearly about just the vulnerable component. However, the other values of the CVSSv3 impact metrics cannot be mapped directly to partial because of CVSSv3.1 scoring guidance. Namely, "only the increase in access, privileges gained, or other negative outcome as a result of successful exploitation should be considered" (CVSS SIG 2019). The example given is that if an attacker already has read access, but gains all other access through the exploit, then read access didn't change and the confidentiality metric score should be "None". However, in this case, SSVC would expect the decision point to be evaluated as total because as a result of the exploit the attacker gains total control of the device, even though they started with partial control.
As mentioned in the discussion of Exploitation, CWE could be used to inform one of the conditions that satisfy proof of concept. For some classes of vulnerabilities, the proof of concept is well known because the method of exploitation is already part of open-source tools. For example, on-path attacker scenarios for intercepting TLS certificates. These scenarios are a cluster of related vulnerabilities. Since CWE classifies clusters of related vulnerabilities, the community could likely curate a list of CWE-IDs for which this condition of well known exploit technique is satisfied. Once that list were curated, it could be used to automatically populate a CVE-ID as proof of concept if the CWE-ID of which it is an instance is on the list. Such a check could not be exhaustive, since there are other conditions that satisfy proof of concept. If paired with automatic searches for exploit code in public repositories, these checks would cover many scenarios. If paired with active exploitation feeds discussed above, then the value of Exploitation could be determined almost entirely from available information without direct analyst involvement at each organization.
CPE could possibly be curated into a list of representative Public Safety Impact values for each platform or product. The Situated Safety Impact would be too specific for a classification as broad as CPE. But it might work for Public Safety Impact, since it is concerned with a more general assessment of usual use of a component. Creating a mapping between CPE and Public Safety Impact could be a community effort to associate a value with each CPE entry, or an organization might label a fragment of the CPE data with Public Safety Impact based on the platforms that the supplier needs information about most often.
Potential Future Information Feeds
So far, we have identified information sources that can support scalable decision making for most decision points. Some sources, such as CWE or existing asset management solutions, would require a little bit of connective glue to support SSVC, but not too much. The SSVC decision point that we have not identified an information source for is Utility. Utility is composed of Automatable and Value Density, so the question is what a sort of feed could support each of those decision points.
-These are both decision points where a feed is plausible. The values for Automatable and Value Density are both about the relationship between a vulnerability, the attacker community, and the aggregate state of systems connected to the Internet. While that is a broad analysis frame, it means that any community that shares a similar set of adversaries and a similar region of the Internet can share the same response to both decision points. An organization in the People's Republic of China may have a different view than an organization in the United States, but most organizations within each region should should have close enough to the same view to share values for Automatable and Value Density. These factors suggest a market for an information feed about these decision points is a viable possibility.
-At this point, it is not clear that an algorithm or search process could be designed to automate scoring Automatable and Value Density. It would be a complex natural language processing task. Perhaps a machine learning system could be designed to suggest values. But more likely, if there is a market for this information, a few analysts could be paid to score vulnerabilities on these values for the community. Supporting such analysts with further automation could proceed by small incremental improvements. For example, perhaps information about whether the Reconnaissance step in the kill chain is Automatable or not could be automatically gathered from Internet scanning firms such as Shodan or Shadowserver. This wouldn't make a determination for an analyst, but would be a step towards automatic assessment of the decision point.
+These are both decision points where a feed is plausible. The values for Automatable and Value Density are both about the relationship between a vulnerability, the attacker community, and the aggregate state of systems connected to the Internet. While that is a broad analysis frame, it means that any community that shares a similar set of adversaries and a similar region of the Internet can share the same response to both decision points. An organization in the People's Republic of China may have a different view than an organization in the United States, but most organizations within each region should should have close enough to the same view to share values for Automatable and Value Density. These factors suggest a market for an information feed about these decision points is a viable possibility.
+At this point, it is not clear that an algorithm or search process could be designed to automate scoring Automatable and Value Density. It would be a complex natural language processing task. Perhaps a machine learning system could be designed to suggest values. But more likely, if there is a market for this information, a few analysts could be paid to score vulnerabilities on these values for the community. Supporting such analysts with further automation could proceed by small incremental improvements. For example, perhaps information about whether the Reconnaissance step in the kill chain is Automatable or not could be automatically gathered from Internet scanning firms such as Shodan or Shadowserver. This wouldn't make a determination for an analyst, but would be a step towards automatic assessment of the decision point.
Future Work
We intend SSVC to offer a workable baseline from which to improve and refine a vulnerability-prioritization methodology. While the method herein should be functional, we do not claim it is ready for use as is. Therefore, we lay out some aspects of future work that would help make it ready to use. We focus on further requirements gathering, further testing of the reliability of the decision process, and expanding to additional types of stakeholders beyond deployers and suppliers.
Requirements Gathering via Sociological Research
@@ -1556,7 +1562,7 @@Acknowledgements
This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.
The view, opinions, and/or findings contained in this material are those of the author(s) and should not be construed as an official Government position, policy, or decision, unless designated by other documentation.
References herein to any specific commercial product, process, or service by trade name, trade mark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute.
-NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
+NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
[DISTRIBUTION STATEMENT A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution.
Internal use:* Permission to reproduce this material and to prepare derivative works from this material for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works.
External use:* This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other external and/or commercial use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu.
@@ -1708,6 +1714,9 @@Acknowledgements
Vilches, Vı́ctor Mayoral, Endika Gil-Uriarte, Irati Zamalloa Ugarte, Gorka Olalde Mendia, Rodrigo Izquierdo Pisón, Laura Alzola Kirschgens, Asier Bilbao Calvo, Alejandro Hernández Cordero, Lucas Apa, and César Cerrudo. 2018. “Towards an Open Standard for Assessing the Severity of Robot Security Vulnerabilities, the Robot Vulnerability Scoring System (RVSS).” arXiv Preprint arXiv:1807.10357.++Wang, Brandon, Xiaoye Li, Leandro P de Aguiar, Daniel S Menasche, and Zubair Shafiq. 2017. “Characterizing and Modeling Patching Practices of Industrial Control Systems.” Measurement and Analysis of Computing Systems 1 (1): 1–23. +Wiles, Darius, and Dave Dugal, eds. 2019. “Common Vulnerability Scoring System SIG.” FIRST. 2019. https://www.first.org/cvss/.