@@ -904,18 +904,19 @@ We should prefer testable requirement to check-box requirements, but when a requ
The goal is that when the MSA does a “sweep” or otherwise decides to verify a product’s conformance with the CRA, it has enough information that it can do its own independent testing without unnecessary barriers that could be solved by vendor documentation (e.g., does not have to reverse-engineer how to attach a serial console and read logs). Note that the MSAs generally prefer evaluating via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.
How exactly this will be done is yet to be determined, but here is our proposal:
Mitigations are how a technical requirement can be satisfied. Mitigations must be tailored to the use case and take into account the user’s sophistication and the operational environment.
* The vendor’s documentation must include information about each test it ran, including:
* any physical equipment other than the product’s normal operating environment
* any testing software they used, including versions
* documentation for any testing software or hardware used
* the parameters or arguments they used for the software or hardware
* any setup information for the test (load this module, flip this switch, run this script, etc.)
* The standard can include requirements for the tools used in the test itself (features or sensitivity or maybe even source code available?)
* The test should rule out false negatives/positives
Each mitigation is described with the following fields where necessary:
Mitigations are how a technical requirement can be satisfied. Mitigations must be tailored to the use case and take into account the user’s sophistication and the operational environment.
* Test: how to test that the mitigation is implemented
* Result: what result would indicate that the product passed the test
* Output: what output would should be saved
Optional:
* False negative/positive prevention: if necessary, a way to prove that the test distinguishes between conformant and non-conformant products
* Requirements: features of the product as placed on the market necessary to run the test that aren't already required by some other technical requirement
* Documentation: any documentation the manufacturer must save for provision to the MSA in addition to the documentation required for every test
@@ -925,30 +926,33 @@ This section is a list of technical requirements necessary to satisfy the CRA es
Risk may, where appropriate, be transferred to another component of a product or to the entity using the product and mitigated there, rather than using one of the below mitigations.
FIXME previous paragprah is attempting to provide context for reviewers and tell them that CRA says risks may be transferred, however it also needs to make it clear that not all risks can be transferred. More work needs to be done here.
### 5.2.X **TR-TEST**: Enable testing and collection of test output
Each mitigation is described with the following fields where necessary:
### 5.2.X.x Requirement
* Test: how to test that the mitigation is implemented
* Result: what output
* Output: the warning or error message produced by the checker
* False negative/positive prevention: if necessary, a way to prove that the test distinguishes between conformant and non-conformant products
* Requirements: features of the product as placed on the market necessary to run the test
* Documentation: what data the manufacturer must save for provision to the MSA
The operating system shall provide a method of running the tests for technical requirements and outputting the test results in a machine readable format on the product as placed on the market.
#### 5.2.X.x **MI-TEST**: Document enabling of testing and collection of test output
The manufacturer shall document the steps necessary to enable testing and collection of the test output. The manufacturer shall not add unnecessary barriers to activating and collecting test output by MSAs.
### 5.2.X **TR-TOUT**: Test output
Test: follow the instructions to set up testing, run one test for a technical requirement that produces test output, and collect the output
Result: test output matches expected output for that test
Output: the expected output of the test
Documentation: how to enable testing and collection of the test output, why any barrier to doing so is necessary
The operating system shall provide a method of running the tests for technical requirements and outputting the test results in a machine readable format on the product as placed on the market. The manufacturer shall document the steps necessary to enable testing and collection of the test output. The manufacturer shall not add unnecessary barriers to activating and collecting test output by MSAs.
#### 5.2.X.x **MI-TDOC**: Test documentation
Test: Follow the instructions to set up testing, run one test for a technical requirement that produces test output, and collect the output
Result: Test output matches expected output for that test
For any technical requirement which includes a test, the manufacturer shall document the instructions for setting up and running the test in addition to those described in MI-TEST, as well as what output of the test indicates passing of the test. Documentation shall include source code if available and usage documentation for each test, along with the options or inputs necessary to run the tests.
### 5.2.X **TR-TDOC**: Test documentation
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
For any technical requirement which includes a test, the manufacturer shall document the instructions for setting up and running the test, as well as the expected output. Documentation shall include source code and usage documentation for each test, along with the options or inputs necessary to run the tests.
All mitigations for TR-TEST are required for all products.
### 5.2.X **TR-MISO**: Prevent local unauthorized access of memory-addressable security-relevant data
### 5.2.X.x Requirement
The operating system shall protect security-relevant memory addresses from unauthorized access by executables under the operating system's control, including the operating system itself. This includes system memory, storage addressable via memory mapping, memory for I/O devices, and anything else accessible via the memory-related instructions in the platform.
The operating system does not need to protect against unauthorized access by elements of the platform it is running on (e.g. CPU microcode, devices on the system bus, other operating systems in the device, a hypervisor). Future iterations of the standard may add this requirement for appropriate use cases.
@@ -1029,9 +1033,9 @@ The manufacturer shall document on which platforms the operating system mitigate
The manufacturer shall document that the risk of microarchitectural side channel data leaks has been transferred to the user, who must mitigate them sufficiently for their use case.
#### 5.2.X.x Mapping of mitigations to risk factors
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
Mitigations satisfy technical requirements only under when they mitigate the relevant risks appropriately. Risk factors are used to determine this. The below table shows which mitigations are appropriate to which use cases or risk profiles based on the risk factors determined in the risk assessment.
Mitigations satisfy technical requirements only under when they mitigate the relevant risks appropriately. Risk factors are used to determine this. The below table shows which mitigations are appropriate to which use cases or security profiles based on the risk factors determined in the risk assessment.
| Mitigation | Applies if risk factors satisfy |
|------------|----------------------------------|
@@ -1047,8 +1051,6 @@ FIXME change the above mapping to be based on a combination of likelihood and im
FIXME add MMAC being okay with CUSR 3 and low impact
#### 5.2.X.x Mapping of mitigations to security profiles
@@ -1849,12 +1851,14 @@ _List any related ETSI standards and how they interact with the present document
# Annex A (informative): Mapping between the present document and CRA requirements
FIXME should be Annex ZA
> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.
