@@ -1051,7 +1051,62 @@ Security profiles are an informative resource to the assessor. Each security pro
_Table C.6.1 — Security profiles mapped to risk factors_
# Annex D (informative): Change history
# Annex D (informative): Risk evaluation guidance
## D.1 Explanation of Risk Modeling Approach
The risk modeling approach followed in this document can be applied to two situations:
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.
**Methodology**
This clause describes the methodology followed in the current text.
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. Document a comprehensive list of threats. For each threat, create a formula to estimate the risk level using the risk factors.
1. For each threat, document appropriate mitigations which should be present to mitigate the specific risk depending on the risk level. 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. Develop security profiles from the use cases, which are collections of risk factor levels that can be used to fully describe the risk levels of all relevant threats. There may be one use case per security profile or multiple. There should be as many security profiles as are useful to manufacturers.
1. Using the risk factors in the security profiles and the risk formulas and mitigations for all threats, derive the completed list of required mitigations for each security profile.
If the Likelihood and Impact of a risk are already Low or have been reduced to Low by application of mitigations, then the risk is acceptable. Alternatively, the risk may be transferred to the user or the operational environment, given proper justification.
## D.4 Risks not treated by the requirements
For each risk untreated by the product itself, a corresponding mitigation has been created to explicitly permit the risk to be transferred to the user or operational environment. These are:
* MI-DNSL-1
* MI-KEVD
* MI-SUDC
* MI-SUOE
* MI-SUAO
* MI-DOST
* MI-AUTH-6
# Annex E (informative): Change history
The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.
