Make formatting of requirement and mitigation headings consistent

Format:

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

### 5.2.X TR-XXXX:

#### 5.2.X.x Requirement

_Description of high-level requirement in “shall” format._

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

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

_Description of mitigation implementing the requirement in "shall" format._

### 5.2.1 TR-NKEV: No known exploitable vulnerabilities at first use

#### 5.2.1.1 Requirement

#### 5.2.1.1: Requirement

Recognizing that there may be vulnerabilities discovered between the time that a product is placed on the market and the time of that product's first use, and that the product should be free from known vulnerabilities both when first made available and when first used by a consumer, the product shall be able to be updated at the time of first use to address all known exploited vulnerabilities which were discovered after the product's placement on the market and before that first use.

#### 5.2.1.2 MI-KEVD: Documentation for secure update before or during first use

#### 5.2.1.2: MI-KEVD: Documentation for secure update before or during first use

The product shall be accompanied by documentation describing how the product may be securely updated, including how to update the product prior to, or as part of, first use.

  * Evidence: The documentation on why the source code analysis tool is sufficient, how it is run, the source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings

#### 5.2.2.3 MI-FZ95 Runtime code coverage checking with memory access error detection

#### 5.2.2.3 MI-FZ95: Runtime code coverage checking with memory access error detection

The product shall be checked for memory errors by running a tool that exercises the functions of the product in an environment that permits measuring code coverage and detecting memory access errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.

  * Verdict: Code coverage was at least 95%, all reported memory errors are documented and justified => PASS, otherwise FAIL

  * Evidence: Logs of code coverage tool, memory error report, documentation of any memory errors

#### 5.2.2.4 MI-IMSL Implement in a memory-safe language

#### 5.2.2.4 MI-IMSL: Implement in a memory-safe language

The product's firmware and/or software shall be implemented in a memory-safe language. Any use of unsafe memory features shall be documented to explain why they are necessary and do not present a security risk.

  * Verdict: Source code is in a memory-safe language and the documentation of all uses of unsafe memory features convincingly demonstrates that each one of them does not present a security risk => PASS, otherwise FAIL

  * Evidence: Source code, documentation of unsafe memory features

#### 5.2.2.5 MI-BTIN Boundary testing of inputs that may cause memory errors

#### 5.2.2.5 MI-BTIN: Boundary testing of inputs that may cause memory errors

The input fields of the product that may produce memory errors in the firmware or device driver shall be identified. The product shall be boundary tested for all such inputs while monitoring for memory errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.

See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

### 5.2.X **TR-MISO**: Prevent local unauthorized access of memory-addressable security-relevant data

### 5.2.X TR-MISO: Prevent local unauthorized access of memory-addressable security-relevant data

#### 5.2.X.x Requirement

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

#### 5.2.X.x **MI-MMAC**: Memory access control

#### 5.2.X.x MI-MMAC: Memory access control

The product shall implement mandatory hardware-enforced access control to memory to prevent unauthorized access of memory.

  * Verdict: All memory accesses fail => PASS, otherwise FAIL

  * Evidence: List of methods of accessing memory and types of access control, output of tests

#### 5.2.X.x **MI-CCON**: Prevent creation of more than one user account

#### 5.2.X.x MI-CCON: Prevent creation of more than one user account

The product shall prevent the creation of a user account if one already exists.

  * Verdict: Creation of second user account fails and list of user accounts shows one account and is identical before and after test => PASS, otherwise FAIL

  * Evidence: List of user accounts before and after test, output of test

#### 5.2.X.x **MI-UCON**: Prevent concurrent user account usage

#### 5.2.X.x MI-UCON: Prevent concurrent user account usage

The product shall prevent a user account from logging in if another user account is already logged in.

  * Verdict: Login of second user account fails or is not possible, and list of user accounts logged in shows one account and is identical before and after test => PASS, otherwise FAIL

  * Evidence: List of logged in user accounts before and after test, output of each test or evidence proving that logging in as a second user is impossible

#### 5.2.X.x **MI-PMSC** Prevent memory leaks through microarchitectural side channels in provided executables

#### 5.2.X.x MI-PMSC: Prevent memory leaks through microarchitectural side channels in provided executables

The product shall implement mechanisms to prevent the executables it provides from leaking memory data to unauthorized users through known exploitable microarchitectural side channels (MASCs), such as via the observing the time of cache access for various operations including:

  * Verdict: All tests fail to extract data that they do not have authorization to read => PASS, otherwise FAIL

  * Evidence: Output of each test

#### 5.2.X.x **MI-TRMD** Transfer risk of microarchitectural side channel data leaks to user

#### 5.2.X.x MI-TRMD Transfer risk of microarchitectural side channel data leaks to user

The documentation provided to the user shall document the risk of microarchitectural side channel data leaks and give appropriate guidance to the user on how they may mitigate the risk.

See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

### 5.2.X **TR-MIME**: Mitigate memory errors

### 5.2.X TR-MIME: Mitigate memory errors

#### 5.2.X.x Requirement

The product shall appropriately mitigate memory errors.

#### 5.2.X.x **MI-ASLR** Address Space Layout Randomization

#### 5.2.X.x MI-ASLR Address Space Layout Randomization

The product shall enable Address Space Layout Randomization (ASLR) by default for all executables, including the kernel, if any.

For each mitigation grouped under requirement TR-MSAF, for each field Preparation, Verdict, or Evidence, if it is not specified for that test, then the above Preparation, Verdict, or Evidence field shall apply.

#### 5.2.X.x **MI-MSAF-1**: Stack exhaustion detection

#### 5.2.X.x MI-MSAF-1: Stack exhaustion detection

Both kernel and userspace threads shall reject writes beyond the end of the stack.

Guidance: Two methods of exhausting stack memory include allocating a very large object on the stack, and performing an unbounded recursive function call.

#### 5.2.X.x **MI-MSAF-2**: Stack linear buffer overflow detection

#### 5.2.X.x MI-MSAF-2: Stack linear buffer overflow detection

Both kernel and userspace threads shall reject stack buffer writes that go beyond the end of the stack frame.

* Objective: Prevent thread from writing beyond end of stack

* Activities: For each of kernel and userspace, write beyond the end of the stack frame

#### 5.2.X.x **MI-MSAF-3**: Array bounds checking

#### 5.2.X.x MI-MSAF-3: Array bounds checking

Both kernel and userspace threads shall reject writes to fixed-size arrays that are beyond the end of the array.

* Objective: Prevent thread from writing beyond the end of a fixed-size array

* Activities: For each of kernel and userspace, write beyond the end of a fixed-size array

#### 5.2.X.x **MI-MSAF-4**: Heap linear buffer overflow detection

#### 5.2.X.x MI-MSAF-4: Heap linear buffer overflow detection

Both kernel and userspace threads shall reject writes beyond the bounds of allocated heap memory.

* Objective: Prevent thread from writing beyond the end of heap memory

* Activities: For each of kernel and userspace, for each type of heap memory, allocate a fixed size from each class of heap memory, write beyond it

#### 5.2.X.x **MI-MSAF-5**: Heap use-after-free access prevention

#### 5.2.X.x MI-MSAF-5: Heap use-after-free access prevention

Both kernel and userspace threads shall reject use of allocated memory that has been freed.

* Objective: Prevent thread from using memory that was allocated then freed

* Activities: For each of kernel and userspace, allocate from heap memory, free it, then try to read it, repeat but with a write

#### 5.2.X.x **MI-MSAF-6**: Heap free checking

#### 5.2.X.x MI-MSAF-6: Heap free checking

Both kernel and userspace threads shall reject freeing of memory that was allocated and previously freed.

* Objective: Prevent thread from freeing memory that is already free

* Activities: For each of kernel and userspace, allocate from heap memory, free it, then free again

#### 5.2.X.x **MI-MZRO-1**: Stack memory zeroing

#### 5.2.X.x MI-MZRO-1: Stack memory zeroing

Both kernel and userspace threads shall zero-initialize all stack memory before use.

* Verdict: stack contents are all zero on second call

* Evidence: contents of stack before the first function return, contents of stack during the second function call

#### 5.2.X.x **MI-MZRO-2**: Heap memory zeroing

#### 5.2.X.x MI-MZRO-2: Heap memory zeroing

Both kernel and userspace threads shall zero-initialize all heap memory before use.

* Verdict: memory contents are all zero on second call

* Evidence: contents of allocated memory before the free, contents of allocated memory after second allocation

#### 5.2.X.x **MI-MRWX-1**: Prevent writes to executable and read-only data memory

#### 5.2.X.x MI-MRWX-1: Prevent writes to executable and read-only data memory

Both kernel and userspace threads shall reject writes to executable and read-only data memory

* Objective: Prevent writes to executable and read-only data memory

* Activities: For each of kernel and userspace, for each portion of executable and non-writable data regions, write to it

#### 5.2.X.x **MI-MRWX-2**: Prevent execution of non-kernel code memory

#### 5.2.X.x MI-MRWX-2: Prevent execution of non-kernel code memory

Kernel threads shall prevent execution of non-kernel code memory.

* Objective: Mitigate exploits that use execution of arbitrary memory

* Activities: For each class of non-code memory in the kernel (e.g. stack, heap, read-only data), copy a trivial return-only function into the memory, and attempt to execute each one

#### 5.2.X.x **MI-NKAM**: Prevent unintentional kernel access to userspace memory

#### 5.2.X.x MI-NKAM: Prevent unintentional kernel access to userspace memory

Kernel threads shall prevent cross-privilege memory access.

Guidance: The most common privilege levels are kernel and userspace.

#### 5.2.X.x **MI-PLLC**: Prevent linked list corruption

#### 5.2.X.x MI-PLLC: Prevent linked list corruption

Both kernel and userspace threads shall check the consistency of the previous and next pointers it manipulates when adding or deleting an item to or from a linked list and reject the operation if they are not consistent.

* Objective: Prevent linked list corruption

* Activities: For each of kernel and userspace, add or delete an item to an uninitialized list

#### 5.2.X.x **MI-MRCO**: Mitigate reference counter overflow

#### 5.2.X.x MI-MRCO: Mitigate reference counter overflow

Both kernel and userspace threads shall mitigate the effects of reference counter overflows

* Verdict: reference counter does not overflow and resource is permanently pinned (no longer can be freed)

* Evidence: test output showing reference counter values before and after the operation, allocation status of the resources

#### 5.2.X.x **MI-CFIN**: Control flow integrity

#### 5.2.X.x MI-CFIN: Control flow integrity

Both kernel and userspace threads shall protect saved function and return pointers from overwrite

Guidance: This mitigation can be implemented via software (e.g. ASan) or hardware (e.g. Pointer Authentication), or validating transitions of expected control flow graph (e.g. KCFI, Shadow Stack).

#### 5.2.X.x **MI-MPMT**: Memory protection using memory tagging

#### 5.2.X.x MI-MPMT: Memory protection using memory tagging

Both kernel and userspace threads shall use hardware-supported memory tagging to reject erroneous memory accesses.

  * Verdict: Transfer of risk documented in a manner appropriate to the user => PASS, otherwise FAIL

  * Evidence: Documentation, analysis of documentation

#### 5.2.X.x **MI-MNET**: Minimize negative impact of network transmission

#### 5.2.X.x MI-MNET: Minimize negative impact of network transmission

The product shall minimise its negative impact on other products or services via the data it transmits on the network. Each source of network data shall be documented, along with the ways it can interfere with other products or services, and methods the product uses to minimise that interference.

  * Verdict: Every method of sending network data is documented with ways it can interface and methods used to minimise => PASS, otherwise FAIL

  * Evidence: All configuration files for network services, documentation of network services and their impact and methods to minimise it, internal lists of listening ports, results of an external port scan

#### 5.2.X.x **MI-MAMP**: Minimize negative impact of network traffic amplification

#### 5.2.X.x MI-MAMP: Minimize negative impact of network traffic amplification

The product shall mitigate abuse of network services that amplify network traffic in manner that can be used to attack other devices. Each network service and its associated mitigations shall be documented.

See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

### 5.2.X **TR-SCUD**: Secure updates

### 5.2.X TR-SCUD: Secure updates

#### 5.2.X.x Requirement

> TODO: Waiting on completion of ETSI membership process to include detailed secure update text from an ETSI delegate. The following text is for update by the operational environment (other OS, human process, etc.).

#### 5.2.X.x **MI-SCHL**: Low security updates provided by operational environment

#### 5.2.X.x MI-SCHL: Low security updates provided by operational environment

The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "Low" security level for the product supplying it.

  * Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL

  * Evidence: Documentation and analysis of completeness

#### 5.2.X.x **MI-SCHM**: Medium security updates provided by operational environment

#### 5.2.X.x MI-SCHM: Medium security updates provided by operational environment

The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "Medium" security level for the product supplying it.

  * Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL

  * Evidence: Documentation and analysis of completeness

#### 5.2.X.x **MI-SCHH**: High security updates provided by operational environment

#### 5.2.X.x MI-SCHH: High security updates provided by operational environment

The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the "High" security level for the product supplying it.

> TODO: Write mitigation documenting that the operational environment must provide denial of service protection, such as an external or internal firewall, fair queueing or filtering, a proxy, etc.

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

### 5.2.X TR-LMAS: Minimize exposed interfaces

#### 5.2.X.x Requirement

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.

#### 5.2.X.x **MI-JSTY**: Document and justify exposed interfaces

#### 5.2.X.x MI-JSTY: Document and justify exposed interfaces

All exposed interfaces on the product in any state that is part of its reasonably foreseeable use or misuse in its secure-by-default configuration shall be documented. Every interface shall have a documented rationale for why its exposure is necessary for the functioning of the product in its secure-by-default configuration.

See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

### 5.2.X **TR-LOGG**: Logging and monitoring

### 5.2.X TR-LOGG: Logging and monitoring

#### 5.2.X.x Requirement

The product shall record security-relevant internal events, including but not limited to changes to configuration and access or modification of data and functions. The product shall provide an opt-out mechanism.

#### 5.2.X.x **MI-LOGG**: Logging

#### 5.2.X.x MI-LOGG: Logging

The product shall record log messages indicating security-relevant internal events in an internal or external log. The log messages shall not include any confidential information such as PII, secrets, or credentials, or any information which might reasonably be expected to include such items.