Merge remote-tracking branch 'gh_pub/copilot/refactor-default-exploitation-values' into copilot/refactor-default-exploitation-values

Author: ahouseholder

docs/_includes/default_mission_impact_values.md

@@ -0,0 +1,5 @@
+!!! tip "Default Mission Impact Values"
+
+    Similarly, with [*Mission Impact*](/reference/decision_points/mission_impact.md), 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 [*support crippled*](/reference/decision_points/mission_impact.md) as a default.

docs/_includes/default_safety_values.md

@@ -0,0 +1,6 @@
+!!! tip "Default Safety Values"
+
+    If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a
+    [*marginal*](../reference/decision_points/safety_impact.md) [*Safety Impact*](../reference/decision_points/safety_impact.md).
+    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.

docs/_includes/default_system_exposure_values.md

@@ -0,0 +1,5 @@
+!!! tip "Default System Exposure Values"
+
+    If the deployer does not know their exposure,<!--lowercase exposure on purpose, this is the general concept--> that
+    means they do not know where the devices are or how they are controlled, so they should assume
+    [*System Exposure*](../reference/decision_points/system_exposure.md) is [*open*](../reference/decision_points/system_exposure.md).

docs/howto/bootstrap/collect.md

@@ -96,30 +96,17 @@ we can suggest something like defaults for some decision points.
 
 {% include-markdown "../../_includes/default_exploitation_values.md" %}
 
-!!! tip "Default System Exposure Values"
-
-    If the deployer does not know their exposure,<!--lowercase exposure on purpose, this is the general concept--> that
-    means they do not know where the devices are or how they are controlled, so they should assume
-    [*System Exposure*](../../reference/decision_points/system_exposure.md) is [*open*](../../reference/decision_points/system_exposure.md).
+{% include-markdown "../../_includes/default_system_exposure_values.md" %}
 
 !!! tip "Default Automatable Values"
 
     If nothing is known about [*Automatable*](../../reference/decision_points/automatable.md), the safer answer to assume is [*yes*](../../reference/decision_points/automatable.md).
     [*Value Density*](../../reference/decision_points/value_density.md) should always be answerable; if the product is uncommon, it is probably
     [*diffuse*](../../reference/decision_points/value_density.md).
 
-!!! tip "Default Safety Values"
-
-    If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a
-    [*marginal*](../../reference/decision_points/safety_impact.md) [*Safety Impact*](../../reference/decision_points/safety_impact.md).
-    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.
-
-!!! tip "Default Mission Impact Values"
+{% include-markdown "../../_includes/default_safety_values.md" %}
 
-    Similarly, with [*Mission Impact*](../../reference/decision_points/mission_impact.md), 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 [*support crippled*](../../reference/decision_points/mission_impact.md) as a default.
+{% include-markdown "../../_includes/default_mission_impact_values.md" %}
 
 !!! example "Using Defaults"
 

docs/howto/gathering_info/mission_impact.md

@@ -12,3 +12,5 @@ At a minimum, understanding mission impact should include gathering information
 There are various sources of guidance on how to gather this information; see for example the FEMA guidance in [Continuity Directive 2](https://www.fema.gov/sites/default/files/2020-07/Federal_Continuity_Directive-2_June132017.pdf) or [OCTAVE FORTE](https://insights.sei.cmu.edu/insider-threat/2018/06/octave-forte-and-fair-connect-cyber-risk-practitioners-with-the-boardroom.html).
 This is part of risk management more broadly.
 It should require the vulnerability management team to interact with more senior management to understand mission priorities and other aspects of risk mitigation.
+
+{% include-markdown "../../_includes/default_mission_impact_values.md" %}

docs/howto/gathering_info/system_exposure.md

@@ -7,6 +7,8 @@ from ssvc.doc_helpers import example_block
 print(example_block(LATEST))
 ```
 
+{% include-markdown "../../_includes/default_system_exposure_values.md" %}
+
 *System Exposure* is primarily used by [Deployers](../../deployer_tree), so the question is about whether some specific system is in fact exposed, not a hypothetical or aggregate question about systems of that type.
 Therefore, it generally has a concrete answer, even though it may vary from vulnerable component to vulnerable component, based on their respective configurations.
 

docs/reference/decision_points/mission_impact.md

@@ -11,6 +11,8 @@ print(example_block(LATEST))
 
       See this [HowTo](../../howto/gathering_info/mission_impact.md) for advice on gathering information about the Mission Impact decision point.
 
+{% include-markdown "../../_includes/default_mission_impact_values.md" %}
+
 !!! tip "See also"
 
     Mission Impact combines with [Safety Impact](./safety_impact.md) to inform 

docs/reference/decision_points/safety_impact.md

@@ -47,6 +47,8 @@ Aggregation suggests that the stakeholder’s response to this decision point ca
 
 ## Gathering Information About Safety Impact
 
+{% include-markdown "../../_includes/default_safety_values.md" %}
+
 The factors that influence the safety impact level are diverse.
 This paper does not exhaustively discuss how a stakeholder should answer a question; that is a topic for future work.
 At a minimum, understanding safety impact should include gathering information about survivability of the vulnerable component, determining available operator actions to compensate for the vulnerable component, understanding relevant insurance, and determining the viability of existing backup measures.

docs/reference/decision_points/system_exposure.md

@@ -11,6 +11,8 @@ print(example_block(LATEST))
 
       See this [HowTo](../../howto/gathering_info/system_exposure.md) for advice on gathering information about the System Exposure decision point.
 
+{% include-markdown "../../_includes/default_system_exposure_values.md" %}
+
 Measuring the 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.