@@ -807,7 +807,7 @@ FIXME add the separate concept of users apart from accounts
**NOTE:** The "TOTAL" field is referenced by but does not define the Risk Tolerance assignments table in clause 6.3 Table 1. It is primarily a consistency check to see if the risk factors sufficiently distinguish the differences in risk tolerance between use cases.
FIXME needs updates
> FIXME: Totals are wrong, risk factors are missing.
@@ -1518,7 +1518,7 @@ The product shall protect data stored on the product from unauthorized access.
* Evidence: Logs of determination of type of data and method of confidentiality and attempts to read confidential data without authorization
Guidance: Data may be protected by the environment, permissons, encryption, salting and hashing, offline storage, or hardware-backed secrets.
Guidance: Data may be protected by the environment, permissions, encryption, salting and hashing, offline storage, or hardware-backed secrets.
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
@@ -1568,6 +1568,58 @@ Guidance: Data transmitted may be protected by the environment or encryption.
> TODO: Rate use cases by sensitivity of data transmitted and update the security profile list above.
#### 5.2.X **TR-IDST**: Integrity of data stored on the product
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.X.x **MI-IDST**: Protect integrity of data stored on the product
The product shall protect the integrity of data stored on the product from unauthorized modification.
* Reference: TR-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.X.x **MI-DCST**: Detect corruption of data stored
The product shall detect corruption of the data stored on the product.
* Reference: TR-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 method of detecting corruption and corruptions of data
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
The manufacturer shall minimize exposed interfaces in the default configuration of the product in all operating modes, including initial configuration, during initialization, while in use, while shutting down or paused, or after reset.
