#46 remediation/mitigation

doc/version_1/040_treesForVulMgmt.md

@@ -22,6 +22,11 @@ Relatedly, C-level executives and public policy professionals often make, shape,
 
 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.
 
+## Enumerating Vulnerability Management Actions
+In this paper, we model 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 deployer should answer the suggested questions for whatever unit of work they are considering as a whole, single unit. 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 clairify terms, "Remediaton occurs when the vulnerability is eliminated or removed. Mitigation occurs when the impact of the vulnerability is decreased without reducing or eliminating the vulnerability." [@dodi_8531_2020, section 3.5] Examples of remediation includes, applying patches, fixes and upgrades; or removing the vulnerable software or system from operation. Mitigating acions 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.
+
 ### Supplying Patches
 
 
@@ -39,13 +44,11 @@ Table 2: Proposed Meaning for Supplier Priority Outcomes
 ### Deploying Patches
  Whether or not to deploy an available patch 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 a patch is available, usually the action is to apply it. When a patch 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.
-
-In this paper, we model 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 deployer should answer the suggested questions for whatever unit of work they are considering as a whole, single unit. 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. Table 3 displays the action priorities for the deployer, which are similar to the supplier case.
+When a patch is available, usually the action is to apply it. When a patch 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. Table 3 displays the action priorities for the deployer, which are similar to the supplier case.
 
 <!--**Talk about applying other mitigations here** TODO
 -->
-To further clairify terms, "Remediaton occurs when the vulnerability is eliminated or removed. Mitigation occurs when the impact of the vulnerability is decreased without reducing or eliminating the vulnerability." [@dodi_8531_2020, section 3.5] Examples of remediation includes, applying patches, fixes and upgrades; or removing the vulnerable software or system from operation. Mitigating acions 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.
+
 
 Table 3: Proposed Meaning for Deployer Priority Outcomes