@@ -1186,16 +1186,20 @@ The product shall be accompanied by documentation informing the user of the tran
See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
### 5.2.X **TR-SDEF**: Secure by default configuration
### 5.2.5 TR-SDEF: Secure by default configuration
#### 5.2.X.x Requirement
#### 5.2.5.1 Requirement
The product shall operate in a secure configuration by default.
#### 5.2.X.x **MI-ADEF**: Authorization required by default to access security-relevant assets
#### 5.2.5.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.
* Reference: TR-SDEF
* Objective: Find any unauthorized access to security relevant assets in default configuration
@@ -1208,17 +1212,63 @@ The product shall require appropriate authorization by default to access securit
* 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
> FIXME: Definition of appropriate authorization is in progress by another group.
#### 5.2.5.3 MI-DPAH: Documentation of product assets accessible from host
#### 5.2.X.x Mapping of mitigations to risk factors and security profiles
The product shall be accompanied by documentation for all interfaces for the product that can be accessed by the host, describing what product assets are accessible from the interface and what type of access is appropriate for representative use cases or risk profiles.
| Risk factors | Requires mitigations |
|---------------------|----------------------|
| any | ADEF |
Guidance: This requirement gives the user or integrator of the product the necessary information they need to implement an appropriate level of access control in the host system. This requirement does not specify how the host implements access control.
| Security Profile | Requires mitigations |
|---------------------|----------------------|
| all | ADEF |
* Applicability: Physical network interface
* Reference: TR-SDEF
* Objective: Secure by default
* Preparation: Define a method that can be used to find all interfaces on the product accessible from the host
* Activities: For each interface, review the documentation to see if it is listed and provides the necessary information
* Verdict: If every interface discovered is listed in the documentation and has the required information => PASS, otherwise => FAIL
* Evidence: Method to list all interfaces accessible from the host, list of interfaces discovered, documentation of assets
#### 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.
Guidance: This is for the use case of selling to an integrator.
* Applicability: Physical network interface
* Reference: TR-SDEF
* Objective: Secure by default
* Preparation: Examine the documentation for how to protect or disable the debug/management interfaces of the product
* Activities: Examine the product for undocumented debug/management interfaces, then follow the instructions in the documentation to disable or protect each documented interface, then attempt to access the interface without authorization
* 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
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.
* 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
* 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.
Guidance: This is for the use case of an end user in use cases where network access is possible for a threat actor.
* 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
* 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-CDST**: Confidentiality of data stored on the product
