Update TR description, threat description -> example threat

We should prefer testable requirement to check-box requirements, but when a requirement isn’t testable, we can provide a decision tree where the vendor follows specific instructions to document why they have to use a check-box requirement (something that is documentation-only).

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).

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:

  * 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?)

* Any tests should demonstrate both the failure and success version of the test to rule out false positives or negatives

* The test should rule out false negatives/positives

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.

### 5.2.1 General

This section is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following section will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following section. 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..

This section is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following section will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following section. 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.

Each mitigation is described with the following fields:

For now, each technical requirement includes an example threat to give context for the mitigation. This may be removed in the final version.

Each mitigation is described with the following fields where necessary:

* Mitigation: brief description of the mitigation

* Test: how to test that the mitigation is implemented

The manufacturer 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.

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.

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

### 5.2.X **TR-TDOC**: Test documentation

### 5.2.X **TR-MISO**: Memory isolation

#### 5.2.X.1 Threat description

#### 5.2.X.1 Example threat

Threat: attacker tries to access memory that belongs to another user or the kernel in an unauthorized manner.

Attacker tries to access memory that belongs to another user or the kernel in an unauthorized manner.

#### 5.2.X.x **MI-SSCA**: Static source code analysis for memory protection

FIXME: should all of this be required for executables running with elevated privileges?

#### 5.2.X.1 Threat description

#### 5.2.X.1 Example threat

Threat: attacker uses an operating systems vulnerability to access memory in an unauthorized manner while possessing elevated memory access privileges.

attacker uses an operating systems vulnerability to access memory in an unauthorized manner while possessing elevated memory access privileges.

#### 5.2.X.x **MI-KSED**: Kernel stack exhaustion detection

### 5.2.X **TR-LSRE**: Logging of security-relevant events

#### 5.2.X.1 Threat description

#### 5.2.X.1 Example threat

Threat: attacker's security-relevant changes to systems can't be tracked or audited

Attacker's security-relevant changes to systems can't be tracked or audited

#### 5.2.X.x **MI-LLOG**: Local logging

### 5.2.X **TR-LLTP**: Local log tamper prevention

#### 5.2.X.1 Threat description

#### 5.2.X.1 Example threat

Threat: attacker tampers with log messages

Attacker tampers with log messages

#### 5.2.X.x **MI-LLGA**: Local log file only editable by privileged users

### 5.2.X **TR-RLTP**: Remote log tamper prevention

#### 5.2.X.1 Threat description

#### 5.2.X.1 Example threat

Threat: Attacker intercepts, alters, or replaces log message stream to remote log server

Attacker intercepts, alters, or replaces log message stream to remote log server

#### 5.2.X.x **MI-RLSA**: Remote log server authentication

### 5.2.X **TR-PCFG**: Prevent unauthorized changes of security-relevant configuration

#### 5.2.X.1 Threat description

#### 5.2.X.1 Example threat

Threat: Unauthorized user changes security-relevant configuration

Unauthorized user changes security-relevant configuration

#### 5.2.X.x **MI-CFGA**: Security-relevant configuration not editable by unauthorized user

### 5.2.X **TR-MINI**: Minimize exposed interfaces

#### 5.2.X.1 Threat description

#### 5.2.X.1 Example threat

Threat: An interface unnecessary for the default functioning of the product is exposed and has a vulnerability.

An interface unnecessary for the default functioning of the product is exposed and has a vulnerability.

#### 5.2.X.x **MI-JUST**: List and justify all exposed interfaces

### 5.2.X **TR-XXXX**:

#### 5.2.X.1 Threat description

#### 5.2.X.1 Example threat

Threat:

#### 5.2.X.x **MI-XXXX**: