The product may provide security functions that the operational environment may make use of to provide confidentiality protection for a product that integrates this product as a component. But products in the scope of the present document do not have the capability to provide confidentiality protection independently of their operational environment.
## 5.8 Integrity protection
### 5.8.1 Overview
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (f).
### 5.8.2 REQ-IP-01: Integrity provided by operational environment
#### 5.8.2.1 Requirement
The product shall provide methods by which the operational environment may implement any necessary integrity protection of data transmitted by or stored on the product, and describe these methods in the documentation accompanying the product.
#### 5.8.2.2 Applicability
TODO
#### 5.8.2.3 Guidance
The product may provide security functions that the operational environment may make use of to provide integrity protection for a product that integrates this product as a component. But products in the scope of the present document do not need to provide integrity protection independently of their operational environment to protect their own cybersecurity. Products may choose to implement integrity protection of data stored or transmitted for other reasons, such as to satisfy regulatory requirements by preventing an authorized user on the host system from installing non-conforming firmware.
### 5.2.4 ER-MINI: Minimize impact on other devices and services
#### 5.2.4.1 Cybersecurity requirement
@@ -1122,84 +1142,6 @@ The product shall implement methods of detecting and mitigating denial of servic
See clause 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
### 5.2.10 ER-IDST: Integrity of data stored on the product
#### 5.2.10.1 Cybersecurity requirement
The product shall protect the integrity of data stored on the product from unauthorized modification and report corruption.
Guidance: Integrity may be protected by the environment, permissions, duplication, backups, and/or checksums.
#### 5.2.10.2 MI-IDST: Protect integrity of data stored on the product
>> TODO: This is a blanket mitigation that is too vague and high-level. Public comment or delegate activity is needed to contribute more detailed and specific mitigations.
The product shall protect the integrity of data stored on the product from unauthorized modification.
* Reference: ER-IDST
* Objective: Integrity of data
* Preparation: List all types of data that may be stored on the product that should not be modifiable without authorization, what methods of protecting integrity are appropriate for each type, all methods of modifying that data available to an attacker based on the risk assessment, and what the allowable authorization methods are for that modification method
* Activities: For each type of data and each access mechanism, determine the method of protecting integrity used, and attempt to modify the data without authorization
* Verdict: If all methods of ensuring integrity match the type of the data stored, and all the attempts to modify protected data without authorization fail => PASS, otherwise => FAIL
* Evidence: Logs of determination of type of data and method of integrity and attempts to modify protected data without authorization
#### 5.2.10.3 MI-DCST: Detect corruption of data stored
>> TODO: This is a blanket mitigation that is too vague and high-level. Public comment or delegate activity is needed to contribute more detailed and specific mitigations.
The product shall detect corruption of the data stored on the product.
* Reference: ER-IDST
* Objective: Integrity of data
* Preparation: List all types of data that may be stored on the product whose corruption should be detected and what methods of detecting corruption are appropriate for each type
* Activities: For each type of data and method of detecting corruption, corrupt the data in a way that the method will detect
* Verdict: If all methods of detecting corruption match the type of the data stored, and all the corruptions of data are detected => PASS, otherwise => FAIL
* Evidence: Logs of determination of type of data and corruptions of data
#### 5.2.10.4 Mapping of mitigations to risk factors and security profiles
See clause 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
### 5.2.11 ER-IDTX: Integrity of data transmitted by the product
#### 5.2.11.1 Cybersecurity requirement
The product shall detect corruption of the data transmitted by the product.
Guidance: Integrity may be protected by the environment, permissions, duplication, backups, and/or checksums.
#### 5.2.11.2 MI-DCTX: Detect corruption of data transmitted by the product
>> TODO: This is a blanket mitigation that is too vague and high-level. Public comment or delegate activity is needed to contribute more detailed and specific mitigations.
The product shall detect corruption of the data transmitted by the product.
* Reference: ER-IDTX
* Objective: Integrity of data
* Preparation: List all types of data that may be transmitted by the product whose corruption should be detected and what methods of detecting corruption are appropriate for each type
* Activities: For each type of data and method of detecting corruption, corrupt the data in a way that the method will detect
* Verdict: If all methods of detecting corruption match the type of the data transmitted, and all the corruptions of data are detected => PASS, otherwise => FAIL
* Evidence: Logs of determination of type of data and corruptions of data
#### 5.2.11.3 Mapping of mitigations to risk factors and security profiles
See clause 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
### 5.2.12 ER-DMIN: Data Minimization
#### 5.2.12.1 Cybersecurity requirement
@@ -2149,6 +2091,52 @@ Examples of data that might need to be protected by the operational environment:
* Confidential cryptographic materials stored on the device
* Packet data while it is being copied (transmitted over the system bus) from the host to the network interface, which is then encrypted by the network interface
## 6.8 Integrity protection
### 6.8.1 Overview
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (f).
### 6.8.2 REQ-IP-01: Integrity provided by operational environment
#### 6.8.2.1 Objective
Protect integrity of data transmitted by or stored on the product.
#### 6.8.2.2 Preparation
Examine the documentation accompanying the product.
#### 6.8.2.3 Activities
For each method by which the operational environment may implement any necessary integrity protection for data transmitted by or stored on the product, implement each method and attempt to modify the integrity protected data without the necessary authorization.
#### 6.8.2.4 Verdict
PASS if **all** the following are fulfilled:
* the technical documentation describes how the operational environment can provide any necessary integrity protection for data transmitted by or stored on the product, and
* for every method described, after implementing the method, attempts to modify the integrity protected data without the necessary authorization fail or are detected, as specified in the documentation.
Otherwise FAIL
#### 6.8.2.5 Evidence
* Documentation accompanying product
* Records of enabling the data integrity protection method
* Logs of access attempts
#### 6.8.2.6 Guidance
Many products in the scope of the present document require data integrity protection only on data assets only accessible from the host system. E.g. encryption keys stored on the network interface may only be transmitted to and from the host system over the host system bus. In this situation, a cybersecurity risk assessment may conclude that, for the product integrating the network interface, the risk of an threat actor modifying the data transmitted over the system bus is already low enough to present an acceptable risk.
Examples of data that might need to be protected by the operational environment:
* Firmware on a physical network device
* Software comprising a virtual network device
* Confidential cryptographic materials stored on the device
* Packet data while it is being copied (transmitted over the system bus) from the host to the network interface, which is then encrypted by the network interface
### 6.2.13.4 MI-FDRP assessment
**[MI-FDRP]** Verify the product performs ordered validity checks on incoming packets and drops invalid packets before further processing.
