Commit 71f4e80b authored by Aeva Black's avatar Aeva Black Committed by Aeva Black
Browse files

Update Annex D Section 1

parent 2151ebf9
Loading
Loading
Loading
Loading
+12 −22
Original line number Diff line number Diff line
@@ -2217,33 +2217,23 @@ Description: Firewall for enterprise network

## D.1 Explanation of Risk Modeling Approach

For any use case, identify and document:
The risk modeling approach followed in this document can be applied to two situations:

- the foreseeable uses and misuses
- the values of each risk factor for these uses
1. _Covered_: For Manufacturers of products with use cases that are present in the text of this document, it states the mitigations which the product shall implement and provides guidance on how to verify that the mitigations are implemented in a product. Furthermore, it describes why that unique set of mitigations is sufficient for the use case.
1. _Not Covered_: For Manufacturers of products whose use case does not precisely match use cases covered in the present document, the methodology used herein may be further used to derive the appropriate set of mitigations for a given product, and to communicate this justification in a structured way. This could inform revisions of this document and the list of use cases over time.

This should result in a predictable set of risk mitigations - i.e. preventative measures.
**Methodology**

Risk is determined by a combination of impact and likelihood. Each risk factor measures impact, likelihood, or a combination of the two.
This section describes the metholodogy followed in the current text.

> TODO: separate Risk Factors into those that affect impact vs likelihood
1. Document a comprehensive range of foreseeable use cases for products of this type.
1. For a particular use case, document the inherent and product-specific risk factors likely to affect products of that type which are not already covered by other relevant standards.
1. For that use case, document environmental risk factors likely to affect products of that type which are not already covered by other relevant standards.
1. For each risk factor identified in the prior two steps, document appropriate mitigations which should be present to mitigate the specific risk. If multiple mitigations relate to a common risk factor, indicate a risk-based prioritization to provide guidance on when each mitigation is appropriate. For each mitigation, also document at least one verification methodology.
1. Create a mapping between each use case and each risk factor, assigning a proportionality score. The scoring range should start from zero, representing the inapplicability of a risk factor to a use case, and increase monotonically based on both the likelihood and severity of potential harm or impact.
1. For each use case, verify that the proportional risk score (relative to other use cases) is informational. For example, use cases that are expected to pose little risk of harm, in the event of a cybersecurity incident, to the end user should have a lower score than use cases which are expected to pose higher risk of harm. This score is subjective and informative only.
1. Combine the output of the prior two steps to derive the completed list of required mitigations for each use case.

> TODO: rewrite Risk Factors to clearly articulate Risk and Foreseeable Mitigation separately

> TODO: Also need to distinguish between
> - device capability
> - mitigations that limit it to the use case

Approach to the whole document:
- start from a (possibly too long) list of product use cases
- articulate risks that emerge from forseeable (mis)uses of products
- map each risk to each use case
- for each use case, combine the risks into an aggregated risk score using likelihood and impact
- articulate mitigations that protect against forseeable risks
- map each risk to one or more mitigations that protect against it
- map each use case to the relevant set of mitigations (by linking through the risk mapping, but hiding the risks in the final mapping)
- verify that there are more mitigations required for use cases that had a higher aggregated risk score
- verify that the risk score of each use cases is proximate to other similarly-risky forseeable use cases, even in different product categories.

## D.2 Mapping of risks to requirements