Numbering and wording updates for TR-MINI and TR-SDEF

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

* Reference: TR-LMII

* Objective: Mitigate exploits by preventing memory errors

* Activities: For each of kernel and userspace, allocate 2 adjacent memory regions with separate tags. Attempt to read and write memory with a positive offset into trailing region from leading region's tagged pointer. Attempt to read and write with negative offset into leading region using trailing region's tagged pointer. Free a region and read and write to the region using the original tagged pointer.

### 5.2.X TR-MINI: Minimize impact on other devices and services

### 5.2.7 TR-MINI: Minimize impact on other devices and services

#### 5.2.X.1 Requirement

#### 5.2.7.1 Requirement

The product shall implement appropriate mitigations to minimize impact on other devices and services.

> TODO: Manufacturers should contribute more state-of-the-art techniques for minimizing impact.

**Editor's Note:** We hope that there will be additional contributions to this section in the future.

#### 5.2.X.2 MI-MDOC: Document transfer of risk of minimizing impact to operating environment

#### 5.2.7.2 MI-MDOC: Document transfer of risk of minimizing impact to operating environment

The product shall be accompanied by documentation informing the user of the transfer of risk for minimizing impact on other devices and services.

  * 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.7.3 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.7.4 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.

  * Verdict: Every method of sending network data is documented with how its impact on others has been mitigated => 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, calculation of traffic amplification factors

### 5.2.5 TR-SDEF: Secure by default configuration

### 5.2.8 TR-SDEF: Secure by default configuration

#### 5.2.5.1 Requirement

#### 5.2.8.1 Requirement

The product shall operate in a secure configuration by default.

#### 5.2.5.2 MI-ADEF: Authorization required by default to access security-relevant assets

#### 5.2.8.2 MI-ADEF: Authorization required by default to access security-relevant assets

> TODO: This is a blanket mitigation that is too vague and high-level. Manufacturers need to contribute more detailed and specific mitigations.

The product shall require appropriate authorization by default to access security-relevant assets, such as product firmware, security-relevant configuration, sensitive data, and sensitive functions.

Guidance: Appropriate authorization depends on the use case and the asset. For example, if the product's intended purpose is for integration into another product, then authorization is generally not necessary to access assets since the integrator will implement appropriate authorization. Another example would be encryption keys; these should not be readable without authorization such as password-based or pre-shared credentials/secrets from either hte host or the network.

The product's default state shall require appropriate authorization to access all security-relevant assets. Appropriate authorization depends on the use case and the asset. For example, an autogenerated device-specific cryptographic key should not be readable without appropriate authorization.

  * Reference: TR-SDEF

  * Objective: Find any unauthorized access to security relevant assets in default configuration

  * Preparation: List all interfaces allowing access to security-relevant assets

  * Activities: For each interface, attempt to access security-relevant assets without appropriate authorization and record whether access was allowed or not

  * Verdict: If every interface does not allow access without appropriate authorization => PASS, otherwise => FAIL

  * Evidence: List of interfaces allowing access to security-relevant assets, record of activities used to attempt unauthorized access to security-relevant assets, log of results of attempts

  * Applicability: if the product's intended purpose is for integration into another product, this mitigation may be implemented by the integrator

#### 5.2.5.4 MI-PDDI-1: Document how to protect access to debug/management interfaces

All debug/management interfaces on the product shall be documented as to how to protect or disable them.

#### 5.2.8.3 MI-PDDI-1: Document how to protect access to debug and management interfaces

Guidance: This is for the use case of selling to an integrator.

All debug and management interfaces on the product shall be documented, and the documentation shall specify means to protect or disable them.

  * Applicability: This mitigation is for products intended for integration into subsequent products.

  * Reference: TR-SDEF

  * Objective: Secure by default

  * Preparation: Examine the documentation for how to protect or disable the debug/management interfaces of the product

  * Verdict: All debug/management interfaces are documented as to how to disable or protect them, and no interfaces are accessible without authorization after following the documentation to protect or disable them => PASS, otherwise => FAIL

  * Evidence: Pictures of the product, list of discovered interfaces, comparison with documentation, notes as to which are documented how to disable/protect, logs of protect/disable actions, logs of attempts to access interfaces after protected or disabled

#### 5.2.5.6 MI-PDDI-2: Protect or disable local software access to debug/management interfaces

#### 5.2.5.6 MI-PDDI-2: Protect or disable local software access to debug and management interfaces

All debug/management interfaces accessible via unprivileged users on the host system shall be protected or disabled by default, unless necessary for backward compatibility and use by an appropriately sophisticated user who has been sufficiently informed of the risk and how to mitigate it.

Guidance: This is for the use case of an end user in use cases where local host system software access is possible for a threat actor.

All debug and management interfaces which can be accessed by processes running on the system shall be protected or disabled by default, unless necessary for backward compatibility. Documentation regarding the removal of such protections by an appropriately sophisticated user may be provided, and shall include information regarding the risks.

  * Applicability: This mitigation is for products where the system software may be accessed by an untrusted users or processes. This includes products that execute code from untrusted sources or access untrusted network data, for example when browsing the web.

  * Reference: TR-SDEF

  * Objective: Secure by default

  * Preparation: Examine the documentation of the network accessible interfaces of the product and follow the instructions to mitigate the risk of any necessary unprotected or enabled interfaces

  * Activities: Using a network scanner, scan the product for both documented and undocumented debug or remote management interfaces and determine whether they are enabled or protected

  * Preparation: Examine the documentation of the network- and localhost-accessible interfaces of the product and follow the instructions to mitigate the risk of any necessary unprotected or enabled interfaces

  * Activities: As an unprivileged process running on the system, attempt to access the system's local debug and management interfaces and make unauthorized changes. Additionally, scan accessible memory and inter-process-communication mechanisms for undocumented debug and management interfaces.

  * Verdict: No undocumented interfaces are found and no interfaces can be accessed without authorization other than those documented as necessary and the instructions to the user are sufficient => PASS, otherwise => FAIL

  * Evidence: List of interfaces, log of attempts to access

#### 5.2.5.7 MI-PDDI-3: Protect or disable network access to debug/management interfaces

All debug/management interfaces accessible via the network shall be protected or disabled by default, unless necessary for backward compatibility and use by an appropriately sophisticated user who has been sufficiently informed of the risk and how to mitigate it.

#### 5.2.5.7 MI-PDDI-3: Protect or disable network access to debug or management interfaces

Guidance: This is for the use case of an end user in use cases where network access is possible for a threat actor.

All debug and management interfaces accessible via the network shall be protected or disabled by default, unless necessary for backward compatibility. Documentation regarding the removal of such protections by an appropriately sophisticated user may be provided, and shall include information regarding the risks.

  * Applicability: Use cases that include foreseeable network access from untrusted sources.

  * Reference: TR-SDEF

  * Objective: Secure by default

  * Preparation: Examine the documentation of the network accessible interfaces of the product and follow the instructions to mitigate the risk of any necessary unprotected or enabled interfaces

  * Verdict: No undocumented interfaces are found and no interfaces can be accessed without authorization other than those documented as necessary and the instructions to the user are sufficient => PASS, otherwise => FAIL

  * Evidence: List of interfaces, log of attempts to access

#### 5.2.5.8 Mapping of mitigations to risk factors and security profiles

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.x Requirement