Fix formatting

Author: sei-renae

docs/howto/gathering_info/automatable.md

@@ -1,16 +1,15 @@
 # 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*](automatable.md).
-    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*](automatable.md) 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 [@bano2018scanning].
-    For most vulnerabilities, an open port does not automatically mean that reconnaissance, weaponization, and delivery are automatable.
-    Furthermore, discovery of a vulnerable service is not automatable in a situation where only two hosts are misconfigured to expose the service out of 2 million hosts that are properly configured.
-    As discussed in in [Reasoning Steps Forward](../../topics/scope.md), the analyst should consider *credible* effects based on *known* use cases of the software system to be pragmatic about scope and providing values to decision points.
+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*](automatable.md).
+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*](automatable.md) 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 [@bano2018scanning].
+For most vulnerabilities, an open port does not automatically mean that reconnaissance, weaponization, and delivery are automatable.
+Furthermore, discovery of a vulnerable service is not automatable in a situation where only two hosts are misconfigured to expose the service out of 2 million hosts that are properly configured.
+As discussed in in [Reasoning Steps Forward](../../topics/scope.md), the analyst should consider *credible* effects based on *known* use cases of the software system to be pragmatic about scope and providing values to decision points.

docs/howto/gathering_info/exploitation.md

@@ -1,25 +1,23 @@
 # Gathering Information About Exploitation
 
-    [@householder2020historical] presents a method for searching the GitHub repositories of open-source exploit databases.
-    This method could be employed to gather 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), one approach is to construct a mapping of CWE-IDs which 
-    always represent vulnerabilities with well-known methods of exploitation.
-    We provide a list of possible CWE-IDs for this purpose below.
-   
-    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—for instance, 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 which vulnerability a novel piece of malware uses may be time consuming, requiring reverse engineering and a lot of trial and error.
-    Additionally, capable incident detection and analysis capabilities are required to make reverse engineering possible.
-    Because most organizations do not conduct these processes fully for most incidents, information about which vulnerabilities are being actively exploited generally comes from public reporting by organizations that 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 that there is no **evidence** of *active* exploitation.
-    This framing admits that an analyst may not be able to detect or know about every attack.
-    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](../../howto/bootstrap/use.md)). 
-    An analyst should feel comfortable selecting *none* if they (or their search scripts) have performed searches in the appropriate places for public *PoC*s and *active* exploitation (as described above) and found *none*.
-    Acknowledging that *Exploitation*. 
+[@householder2020historical] presents a method for searching the GitHub repositories of open-source exploit databases.
+This method could be employed to gather 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), one approach is to construct a mapping of CWE-IDs which 
+always represent vulnerabilities with well-known methods of exploitation.
+We provide a list of possible CWE-IDs for this purpose below.
 
+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—for instance, 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 which vulnerability a novel piece of malware uses may be time consuming, requiring reverse engineering and a lot of trial and error.
+Additionally, capable incident detection and analysis capabilities are required to make reverse engineering possible.
+Because most organizations do not conduct these processes fully for most incidents, information about which vulnerabilities are being actively exploited generally comes from public reporting by organizations that 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 that there is no **evidence** of *active* exploitation.
+This framing admits that an analyst may not be able to detect or know about every attack.
+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](../../howto/bootstrap/use.md)). 
+An analyst should feel comfortable selecting *none* if they (or their search scripts) have performed searches in the appropriate places for public *PoC*s and *active* exploitation (as described above) and found *none*.
+Acknowledging that *Exploitation*. 

docs/howto/gathering_info/technical_impact.md

@@ -1,16 +1,16 @@
 # Gathering Information About Technical Impact
 
-    Assessing *Technical Impact* amounts to assessing the degree of control over the vulnerable component the attacker stands to gain by exploiting the vulnerability.
-    One way to approach this analysis is to ask whether the control gained is *total* or not.
-    If it is not total, it is *partial*.
-    If an answer to one of the following questions is _yes_, then control is *total*.
-    After exploiting the vulnerability,
- 
-    - can the attacker install and run arbitrary software?
-    - can the attacker trigger all the actions that the vulnerable component can perform?
-    - does the attacker get an account with full privileges to the vulnerable component (administrator or root user accounts, for example)?
+Assessing *Technical Impact* amounts to assessing the degree of control over the vulnerable component the attacker stands to gain by exploiting the vulnerability.
+One way to approach this analysis is to ask whether the control gained is *total* or not.
+If it is not total, it is *partial*.
+If an answer to one of the following questions is _yes_, then control is *total*.
+After exploiting the vulnerability,
 
-    This list is an evolving set of heuristics.
-    If you find a vulnerability that should have *total* *Technical Impact* but that does not answer yes to any of 
-    these questions, please describe the example and what question we might add to this list in an issue on the
-    [SSVC GitHub](https://github.com/CERTCC/SSVC/issues).
+- can the attacker install and run arbitrary software?
+- can the attacker trigger all the actions that the vulnerable component can perform?
+- does the attacker get an account with full privileges to the vulnerable component (administrator or root user accounts, for example)?
+
+This list is an evolving set of heuristics.
+If you find a vulnerability that should have *total* *Technical Impact* but that does not answer yes to any of 
+these questions, please describe the example and what question we might add to this list in an issue on the
+[SSVC GitHub](https://github.com/CERTCC/SSVC/issues).

docs/howto/gathering_info/value_density.md

@@ -1,15 +1,15 @@
 # Gathering Information About Value Density
 
-    The heuristics presented in the *Value Density* definitions involve whether the system is usually maintained by a dedicated professional, although we have noted some exceptions (such as encrypted mobile messaging applications).
-    If there are additional counterexamples to this heuristic, please describe them and the reasoning why the system should have the alternative decision value in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues).
-    
-    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 having more instances does not mean that the software is a densely valuable target.
-    However, market penetration greater than approximately 75% generally means that the product uniquely serves a particular market segment or purpose.
-    This line of reasoning is what supports a determination that an ubiquitous encrypted mobile messaging application should be considered to have a *concentrated* Value Density.
+The heuristics presented in the *Value Density* definitions involve whether the system is usually maintained by a dedicated professional, although we have noted some exceptions (such as encrypted mobile messaging applications).
+If there are additional counterexamples to this heuristic, please describe them and the reasoning why the system should have the alternative decision value in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues).
+
+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 having more instances does not mean that the software is a densely valuable target.
+However, market penetration greater than approximately 75% generally means that the product uniquely serves a particular market segment or purpose.
+This line of reasoning is what supports a determination that an ubiquitous encrypted mobile messaging application should be considered to have a *concentrated* Value Density.

mkdocs.yml

@@ -8,6 +8,13 @@ nav:
   - SSVC Overview: 'ssvc_overview.md'
   - SSVC How-To:
     - Overview: 'howto/index.md'
+    - Gathering Info about Decision Points:
+      - Automatable: howto/gathering_info/automatable.md
+      - Exploitation: howto/gathering_info/exploitation.md
+      - Mission Impact: howto/gathering_info/mission_impact.md
+      - System Exposure: howto/gathering_info/system_exposure.md
+      - Technical Impact: howto/gathering_info/technical_impact.md
+      - Value Density: howto/gathering_info/value_density.md
     - Getting Started with SSVC:
       - Intro: 'howto/bootstrap/index.md'
       - Prepare: 'howto/bootstrap/prepare.md'