fixed typos (#146)

doc/md_src_files/040_stakeholders-scope.md

@@ -141,7 +141,7 @@ Table: <a name="table-supplier-outcomes"></a> Proposed Meaning for Supplier Prio
 
 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](#table-deployer-outcomes) displays the action priorities for the deployer, which are similar to the supplier case.
 
-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*](#system-exposure) from open to controlled. Financial well-being, a [*Saftey Impact*](#safety-impact) category, might be reduced with adequate fraud detection and insurance. Physical well-being, also a [*Saftey Impact*](#safety-impact) category, might be reduced by physical barriers that restrict a robot's ability to interact with humans. [*Mission Impact*](#mission-impact) might be reduced by introducing back-up business flows that do not use the vulnerable component. In a later section we combine [Mission and Situated Safety Impact](#table-mission-safety-combined) to reduce the complexity of the tree.
+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*](#system-exposure) from open to controlled. Financial well-being, a [*Safety Impact*](#safety-impact) category, might be reduced with adequate fraud detection and insurance. Physical well-being, also a [*Safety Impact*](#safety-impact) category, might be reduced by physical barriers that restrict a robot's ability to interact with humans. [*Mission Impact*](#mission-impact) might be reduced by introducing back-up business flows that do not use the vulnerable component. In a later section we combine [Mission and Situated Safety Impact](#table-mission-safety-combined) to reduce the complexity of the tree.
 
 However, these mitigation techniques will not always work. For example, the implementation of a firewall or IDS rule to mitigate [*System Exposure*](#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.

doc/md_src_files/050_decision-points_1.md

@@ -69,7 +69,7 @@ Table: Technical Impact Decision Values
 ### Gathering Information About Technical Impact
 
 Assessing [*Technical Impact*](#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 analyiss is to ask whether the control gained is *total* or not.
+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 vulnerablily,

doc/ssvc_v2-0.html

@@ -541,7 +541,7 @@ <h2 id="technical-impact">Technical Impact</h2>
 </tbody>
 </table>
 <h3 id="gathering-information-about-technical-impact">Gathering Information About Technical Impact</h3>
-<p>Assessing <a href="#technical-impact"><em>Technical Impact</em></a> 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 analyiss is to ask whether the control gained is <em>total</em> or not. If it is not total, it is <em>partial</em>. If an answer to one of the following questions is yes, then control is <em>total</em>. After exploiting the vulnerablily,</p>
+<p>Assessing <a href="#technical-impact"><em>Technical Impact</em></a> 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 <em>total</em> or not. If it is not total, it is <em>partial</em>. If an answer to one of the following questions is yes, then control is <em>total</em>. After exploiting the vulnerablily,</p>
 <ul>
 <li>can the attacker install and run arbitrary software?</li>
 <li>can the attacker trigger all the actions that the vulnerable component can perform?</li>