| Safety Impact | -Type of Harm | -Description | -
|---|---|---|
| None | -All | -Does not mean no impact literally; it just means that the effect is below the threshold for all aspects described in Minor | -
| Minor -(Any one or more of these conditions hold.) |
-Physical harm | -Physical discomfort for users (not operators) of the system | -
| - | Operator -resiliency |
-Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard | -
| - | System -resiliency |
-Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation | -
| - | Environment | -Minor externalities (property damage, environmental damage, etc.) imposed on other parties | -
| - | Financial | -Financial losses, which are not readily absorbable, to multiple persons | -
| - | Psychological | -Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons | -
| Major -(Any one or more of these conditions hold.) |
-Physical harm | -Physical distress and injuries for users (not operators) of the system | -
| - | Operator -resiliency |
-Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard | -
| - | System -resiliency |
-System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation | -
| - | Environment | -Major externalities (property damage, environmental damage, etc.) imposed on other parties | -
| - | Financial | -Financial losses that likely lead to bankruptcy of multiple persons | -
| - | Psychological | -Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people | -
| Hazardous -(Any one or more of these conditions hold.) |
-Physical harm | -Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures | -
| - | Operator -resiliency |
-Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly | -
| - | System -resiliency |
-Parts of the cyber-physical system break; system’s ability to recover lost functionality remains intact | -
| - | Environment | -Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties | -
| - | Financial | -Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state | -
| - | Psychological | -N/A | -
| Catastrophic (Any one or more of these conditions hold.) | -Physical harm | -Multiple immediate fatalities (Emergency response probably cannot save the victims.) | -
| - | Operator -resiliency |
-Operator incapacitated (includes fatality or otherwise incapacitated) | -
| - | System resiliency | -Total loss of whole cyber-physical system, of which the software is a part | -
| - | Environment | -Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties | -
| - | Financial | -Social systems (elections, financial grid, etc.) supported by the software collapse | -
| - | Psychological | -N/A | -
-
-Figure 1: Proposed Vulnerability Prioritization Decision Tree for Patch
-Supplier
-
-## Deployer Tree
-
-The proposed deployer tree is depicted in Figure 3, Figure 4, and Figure 5. The state of *Exploitation* is the first decision point, but in an effort to make the tree legible, we split the tree into three sub-trees over three pages. We suggest making the decision about *Exploitation* as usual, and then going to the correct subtree.
-
-
-
-Figure 2: Proposed Vulnerability Prioritization Decision Tree for Patch
-Deployers (Continued in Figure 3 and Figure 4)
-
-
-
-Figure 3: Proposed Vulnerability Prioritization Decision Tree for Patch
-Deployers (Continued from Figure 2 and in Figure 4).
-
-
-
-Figure 4: Proposed Vulnerability Prioritization Decision Tree for Patch
-Deployers (Continued from Figure 2 and Figure 3)
-
-## Evidence Gathering Guidance
-
-To answer each of these decision points, a supplier or deployer should, as much as possible, have a repeatable evidence collection and evaluation process. However, we are proposing decisions for humans to make, so evidence collection and evaluation is not totally automatable. That caveat notwithstanding, some automation is possible.
-
-For example, whether exploitation modules are available in ExploitDB, Metasploit, or other sources is straightforward. We hypothesize that searching Github and Pastebin for exploit code should be automatable. A supplier or deployer could then define *Exploitation* **PoC available** to be positive search results for a set of inputs derived from the CVE entry in at least one of these venues. At least, for those vulnerabilities that are not “automatically” PoC-ready, such as on-path attackers for TLS or network replays.
-
-Some of the decision points require some substantial upfront analysis effort to gather risk assessment or organizational data. However, once gathered, this information can be efficiently reused across many vulnerabilities and only refreshed occasionally. An obvious example of this is the mission impact decision point. To answer this, a deployer must analyze their essential functions, how they interrelate, and how they are supported. Exposure is similar; answering that decision point requires an asset inventory, adequate understanding of the network topology, and a view of the enforced security controls. Independently operated scans, such as Shodan or Shadowserver, may play a role in evaluating exposure, but the entire exposure question cannot be reduced to a binary question of whether an organization’s assets appear in such databases. Once the deployer has the situational awareness to understand MEFs or exposure, selecting the answer for each individual vulnerability is usually straightforward.
-
-Stakeholders who use the prioritization method should consider releasing the priority with which they handled the vulnerability. This disclosure has various benefits. For example, if the supplier publishes a priority ranking, then deployers could consider that in their decision-making process. One reasonable way to include it is to break ties for the deployer. If an deployer has three “scheduled” vulnerabilities to patch, they may address them in any order. If two vulnerabilities were produced by the supplier as “scheduled” patches, and one was “out-of-cycle,” then the deployer may want to use that information to favor the latter.
-
-In the case where no information is available or the organization has not yet matured its initial situational analysis, we can suggest something like defaults for some decision points. If the deployer does not know their exposure, that means they do not know where the devices are or how they are controlled, so they should assume *Exposure* is **open**. If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a **major** *Safety Impact*. This position is conservative, but software is thoroughly embedded in daily life now, so we suggest that the decision maker provide evidence that no one’s well-being will suffer. The reach of software exploits is no longer limited to a research network. Similarly, with *Mission Impact*, the deployer should assume that the software is in use at the organization for a reason, and that it supports essential functions unless they have evidence otherwise. With a total lack of information, assume **MEF support crippled** as a default. *Exploitation* needs no special default; if adequate searches are made for exploit code and none is found, the answer is **none**. The decision set {**none**, **open**, **MEF crippled**, **major**} results in a scheduled patch application.
-
-
-## Development Methodology
-
-For this tabletop refinement, we could not select a mathematically representative set of CVEs. The goal was to select a handful of CVEs that would cover diverse types of vulnerabilities. The CVEs that we used for our tabletop exercises are CVE-2017-8083, CVE-2019-2712, CVE-2014-5570, and CVE-2017-5753. We discussed each one from the perspective of supplier and deployer. We evaluated CVE-2017-8083 twice because our understanding and descriptions had changed materially after the first three CVEs (six evaluation exercises). After we were satisfied that the decision trees were clearly defined and captured our intentions, we began the formal evaluation of the draft trees, which we describe in the next section.
diff --git a/doc/version_1/042_treesForVulMgmt_2.md b/doc/version_1/042_treesForVulMgmt_2.md
new file mode 100644
index 00000000..89646512
--- /dev/null
+++ b/doc/version_1/042_treesForVulMgmt_2.md
@@ -0,0 +1,106 @@
+## Likely Decision Points and Relevant Data
+
+We propose the following decision points and associated values should be a factor when making decisions about vulnerability prioritization. Each decision point is tagged with the stakeholder it is relevant to: deployers, suppliers, or both. We emphasize that these descriptions are hypotheses to be further tested and validated. We made every effort to put forward informed and useful decision frameworks with wide applicability, but the goal of this paper is more to solicit feedback than make a declaration. We welcome questions, constructive criticism, refuting evidence, or supporting evidence about any aspect of this proposal.
+
+One important omission from the values for each category is an “unknown” option. Instead, we recommend explicitly identifying an option that is a reasonable assumption based on prior events. Such an option requires reliable historical evidence for what tends to be the case; of course, future events may require changes to these assumptions over time. Therefore, our assumptions require evidence and are open to debate in light of new evidence. Different risk tolerance or risk discounting postures are not addressed in the current work; accommodating such tolerance or discounting explicitly is an area for future work. This flexibility fits into our overall goal of supplying a decision-making framework that is both transparent and fits the needs of different communities. Resisting an “unknown” option discourages the modeler from silently embedding these assumptions in their choices for how the decision tree flows below the selection of any “unknown” option.
+
+We propose satisfactory decision points for vulnerability management in the next sections, in no particular order.
+
+### Exploitation (Supplier, Deployer)
+> Evidence of Active Exploitation of a Vulnerability
+
+The intent of this measure is the present state of exploitation of the vulnerability. The intent is not to predict future exploitation but only to acknowledge the current state of affairs. Predictive systems, such as EPSS, could be used to augment this decision or to notify stakeholders of likely changes [@jacobs2019exploit].
+
+| | Table 4: Exploitation Decision Values |
+| --- | --------------------------------- |
+| None | There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability. |
+| PoC | Safety Impact | +Type of Harm | +Description | +
|---|---|---|
| None | +All | +Does not mean no impact literally; it just means that the effect is below the threshold for all aspects described in Minor | +
| Minor +(Any one or more of these conditions hold.) |
+Physical harm | +Physical discomfort for users (not operators) of the system | +
| + | Operator +resiliency |
+Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard | +
| + | System +resiliency |
+Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation | +
| + | Environment | +Minor externalities (property damage, environmental damage, etc.) imposed on other parties | +
| + | Financial | +Financial losses, which are not readily absorbable, to multiple persons | +
| + | Psychological | +Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons | +
| Major +(Any one or more of these conditions hold.) |
+Physical harm | +Physical distress and injuries for users (not operators) of the system | +
| + | Operator +resiliency |
+Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard | +
| + | System +resiliency |
+System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation | +
| + | Environment | +Major externalities (property damage, environmental damage, etc.) imposed on other parties | +
| + | Financial | +Financial losses that likely lead to bankruptcy of multiple persons | +
| + | Psychological | +Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people | +
| Hazardous +(Any one or more of these conditions hold.) |
+Physical harm | +Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures | +
| + | Operator +resiliency |
+Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly | +
| + | System +resiliency |
+Parts of the cyber-physical system break; system’s ability to recover lost functionality remains intact | +
| + | Environment | +Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties | +
| + | Financial | +Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state | +
| + | Psychological | +N/A | +
| Catastrophic (Any one or more of these conditions hold.) | +Physical harm | +Multiple immediate fatalities (Emergency response probably cannot save the victims.) | +
| + | Operator +resiliency |
+Operator incapacitated (includes fatality or otherwise incapacitated) | +
| + | System resiliency | +Total loss of whole cyber-physical system, of which the software is a part | +
| + | Environment | +Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties | +
| + | Financial | +Social systems (elections, financial grid, etc.) supported by the software collapse | +
| + | Psychological | +N/A | +
+
+Figure 1: Proposed Vulnerability Prioritization Decision Tree for Patch
+Supplier
+
+## Deployer Tree
+
+The proposed deployer tree is depicted in Figure 3, Figure 4, and Figure 5. The state of *Exploitation* is the first decision point, but in an effort to make the tree legible, we split the tree into three sub-trees over three pages. We suggest making the decision about *Exploitation* as usual, and then going to the correct subtree.
+
+
+
+Figure 2: Proposed Vulnerability Prioritization Decision Tree for Patch
+Deployers (Continued in Figure 3 and Figure 4)
+
+
+
+Figure 3: Proposed Vulnerability Prioritization Decision Tree for Patch
+Deployers (Continued from Figure 2 and in Figure 4).
+
+
+
+Figure 4: Proposed Vulnerability Prioritization Decision Tree for Patch
+Deployers (Continued from Figure 2 and Figure 3)
+
+## Evidence Gathering Guidance
+
+To answer each of these decision points, a supplier or deployer should, as much as possible, have a repeatable evidence collection and evaluation process. However, we are proposing decisions for humans to make, so evidence collection and evaluation is not totally automatable. That caveat notwithstanding, some automation is possible.
+
+For example, whether exploitation modules are available in ExploitDB, Metasploit, or other sources is straightforward. We hypothesize that searching Github and Pastebin for exploit code should be automatable. A supplier or deployer could then define *Exploitation* **PoC available** to be positive search results for a set of inputs derived from the CVE entry in at least one of these venues. At least, for those vulnerabilities that are not “automatically” PoC-ready, such as on-path attackers for TLS or network replays.
+
+Some of the decision points require some substantial upfront analysis effort to gather risk assessment or organizational data. However, once gathered, this information can be efficiently reused across many vulnerabilities and only refreshed occasionally. An obvious example of this is the mission impact decision point. To answer this, a deployer must analyze their essential functions, how they interrelate, and how they are supported. Exposure is similar; answering that decision point requires an asset inventory, adequate understanding of the network topology, and a view of the enforced security controls. Independently operated scans, such as Shodan or Shadowserver, may play a role in evaluating exposure, but the entire exposure question cannot be reduced to a binary question of whether an organization’s assets appear in such databases. Once the deployer has the situational awareness to understand MEFs or exposure, selecting the answer for each individual vulnerability is usually straightforward.
+
+Stakeholders who use the prioritization method should consider releasing the priority with which they handled the vulnerability. This disclosure has various benefits. For example, if the supplier publishes a priority ranking, then deployers could consider that in their decision-making process. One reasonable way to include it is to break ties for the deployer. If a deployer has three “scheduled” vulnerabilities to patch, they may address them in any order. If two vulnerabilities were produced by the supplier as “scheduled” patches, and one was “out-of-cycle,” then the deployer may want to use that information to favor the latter.
+
+In the case where no information is available or the organization has not yet matured its initial situational analysis, we can suggest something like defaults for some decision points. If the deployer does not know their exposure, that means they do not know where the devices are or how they are controlled, so they should assume *Exposure* is **open**. If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a **major** *Safety Impact*. This position is conservative, but software is thoroughly embedded in daily life now, so we suggest that the decision maker provide evidence that no one’s well-being will suffer. The reach of software exploits is no longer limited to a research network. Similarly, with *Mission Impact*, the deployer should assume that the software is in use at the organization for a reason, and that it supports essential functions unless they have evidence otherwise. With a total lack of information, assume **MEF support crippled** as a default. *Exploitation* needs no special default; if adequate searches are made for exploit code and none is found, the answer is **none**. The decision set {**none**, **open**, **MEF crippled**, **major**} results in a scheduled patch application.
+
+
+## Development Methodology
+
+For this tabletop refinement, we could not select a mathematically representative set of CVEs. The goal was to select a handful of CVEs that would cover diverse types of vulnerabilities. The CVEs that we used for our tabletop exercises are CVE-2017-8083, CVE-2019-2712, CVE-2014-5570, and CVE-2017-5753. We discussed each one from the perspective of supplier and deployer. We evaluated CVE-2017-8083 twice because our understanding and descriptions had changed materially after the first three CVEs (six evaluation exercises). After we were satisfied that the decision trees were clearly defined and captured our intentions, we began the formal evaluation of the draft trees, which we describe in the next section.
diff --git a/doc/version_1/sources_ssvc.bib b/doc/version_1/sources_ssvc.bib
index 96b40f1d..397d0ad4 100644
--- a/doc/version_1/sources_ssvc.bib
+++ b/doc/version_1/sources_ssvc.bib
@@ -240,7 +240,17 @@ @techreport{caralli2007octave
number={CMU/SEI-2007-TR-012},
institution={Software Engineering Institute, Carnegie Mellon University},
address={Pittsburgh, PA},
- url={http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=8419}
+ url={https://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=8419}
+}
+
+@techreport{cebula2010taxonomy,
+ title={A taxonomy of operational cyber security risks},
+ author={Cebula, James L and Young, Lisa R},
+ year={2010},
+ number={CMU/SEI-2010-TN-028},
+ institution={Software Engineering Institute, Carnegie Mellon University},
+ address={Pittsburgh, PA},
+ url={https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9395}
}
%%%% End miscellaneous tech reports