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 are not required 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 protection provided by operational environment
#### 5.8.2.1 Requirement
The product shall provide methods by which the operational environment may protect the integrity of data transmitted by or stored on the product that is necessary to the cybersecurity of 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 are not required 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
@@ -1023,84 +1043,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
@@ -1993,6 +1935,56 @@ Examples of attempts to read data without authorization:
* Attempt to read the memory mapped to the network interface's registers and memory without the necessary memory permissions
* Attempt to decrypt encrypted data sent over the network without the private cryptographic key
## 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 protection 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
Identify methods the product provides for integrity protection of cybersecurity-relevant product assets. Identify an operational environment that permits testing these methods. Identify product assets that require integrity protection. For each identified asset, identify the methods to protect its integrity and any necessary configuration, inputs, or other preparation for testing integrity protection of that product asset. Install the product in the identified operational environment.
#### 6.8.2.3 Activities
For each method and each type of data identified, carry out the identified testing preparations and attempt to modify the integrity protected data without the necessary authorization.
#### 6.8.2.4 Verdict
PASS if every attempt to modify the integrity protected data without the necessary authorization fails or is detected.
Otherwise FAIL
#### 6.8.2.5 Evidence
* Descriptions of types of data requiring integrity protection
* Records of configuration, input, and/or preparation for each test
* Logs of modification attempts and their results
#### 6.8.2.6 Guidance
Many products in the scope of the present document may 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 without further treatment.
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
* Contents of memory in the product
* 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
Examples of attempts to modify data without authorization:
* Use the operating system interface to configure the network interface without the necessary operation system privileges
* Attempt to write to the memory mapped to the network interface's registers and memory without the necessary memory permissions
* Attempt to write to the file containing the virtual network interface's executable without the necessary file system permissions
### 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.
