@@ -973,103 +973,67 @@ The CRA Draft Guidance 9.2.2 says:
</mark>
### 5.2.5 ER-SDEF: Secure by default configuration
## 5.4 Secure by default configuration
#### 5.2.5.1 Cybersecurity requirement
### 5.4.1 Overview
The product shall operate in a secure configuration by default.
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).
#### 5.2.5.2 MI-ADEF: Authorization required by default to access security-relevant assets
> NOTE: The CRA essential requirement laid out in Annex 1 Part 1 (2) (b) foresees an applicability exception to the secure configuration by default in case there is an agreement between manufacturer and business user in relation to a tailor-made product with digital elements.
>> TODO: This is a blanket mitigation that is too vague and high-level. Public comment or delegate activity is needed 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 the host or the network.
* Reference: ER-SDEF
* Objective: Find any unauthorized access to security relevant assets in default configuration
### 5.4.2 REQ-SBD-01 (MI-PDDI-1): Document how to protect access to debug or management interfaces
* Preparation: List all interfaces allowing access to security-relevant assets
#### 5.4.2.1 Requirement
* Activities: For each interface, attempt to access security-relevant assets without appropriate authorization and record whether access was allowed or not
All debug or management interfaces on the product shall be documented as to how to protect or disable them.
* Verdict: If every interface does not allow access without appropriate authorization => PASS, otherwise => FAIL
#### 5.4.2.2 Applicability
* 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
TODO - probably all use cases.
#### 5.2.5.3 MI-DPAH: Documentation of product assets accessible from host
#### 5.4.2.3 Guidance
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.
### 5.4.3 REQ-SBD-02 (MI-PDDI-2): Protect or disable physical access to debug/management interfaces
Guidance: This cybersecurity 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 cybersecurity requirement does not specify how the host implements access control.
#### 5.4.3.1 Requirement
* Applicability: Physical network interface
* Reference: ER-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
All debug/management interfaces accessible to someone with physical access to the product 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.4 MI-PDDI-1: Document how to protect access to debug/management interfaces
#### 5.4.3.2 Applicability
All debug/management interfaces on the product shall be documented as to how to protect or disable them.
TODO - physical network interfaces in a public setting
Guidance: This is for the use case of selling to an integrator.
#### 5.4.3.3 Guidance
* Applicability: Physical network interface
* Reference: ER-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
This is for the use case of an end user in use cases where physical access is possible for a threat actor.
#### 5.2.5.5 MI-PDDI-2: Protect or disable physical access to debug/management interfaces
### 5.4.4 REQ-SBD-03 (MI-PDDI-3): Protect or disable unauthorized host system software access to debug/management interfaces
All debug/management interfaces accessible to someone with physical access to the product 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.4.4.1 Requirement
Guidance: This is for the use case of an end user in use cases where physical access is possible for a threat actor.
All debug/management interfaces accessible by unauthorized users via software 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.
* Applicability: Physical network interface
* Reference: ER-SDEF
* Objective: Secure by default
* Preparation: Examine the documentation to find the physically accessible debug/management interfaces of the product
* Activities: Examine the product for undocumented physical management interfaces, then attempt to access the documented interfaces without authorization
* Verdict: No undocumented interfaces are found, no documented interfaces can be used 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 examinations, log of attempts to access
#### 5.4.4.2 Applicability
#### 5.2.5.6 MI-PDDI-3: Protect or disable local software access to debug/management interfaces
TODO
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.
#### 5.4.4.3 Guidance
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.
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. Generally, the host system completely controls access to the network interface and no interfaces are available for use by an unauthorized user.
* Reference: ER-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.4.5 REQ-SBD-04 (MI-PDDI-4): Protect or disable network access to debug or management interfaces
#### 5.2.5.7 MI-PDDI-4: Protect or disable network access to debug/management interfaces
#### 5.4.5.1 Requirement
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.
All debug/management interfaces accessible by unauthorized users via the attached 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.
#### 5.4.5.2 Applicability
* Reference: ER-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
TODO
#### 5.2.5.8 Mapping of mitigations to risk factors and security profiles
#### 5.4.5.3 Guidance
See clause 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
This is for the use case of an end user in use cases where network access is possible for a threat actor.
### 5.2.6 ER-SCUD: Secure updates
@@ -2003,6 +1967,134 @@ Otherwise FAIL
* documentation of mitigation, or
* elapsed time since discovery of vulnerability.
## 6.4 Secure by default configuration
### 6.4.1 Overview
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).
### 6.4.2 REQ-SBD-01 (MI-PDDI-1): Document how to protect access to debug or management interfaces
#### 6.4.2.1 Objective
Secure by default configuration
#### 6.4.2.2 Preparation
Examine the product technical documentation to find all debug or management interfaces.
#### 6.4.2.3 Activities
Follow the instructions in the product technical documentation to disable or protect each documented interface, then attempt to use the interface without authorization.
#### 6.4.2.4 Verdict
PASS if:
* All attempts to use debug or management interfaces without authorization fail.
Otherwise FAIL
#### 6.4.2.5 Evidence
* Pictures of the product
* Logs of protecting or disabling interfaces
* Logs of attempts to access interfaces
#### 6.4.2.6 Guidance
This is for the use case of an integrator who will disable or protect interfaces as necessary for the use case of the integrated product.
Authorization may be via a variety of methods: passwords, physical access, host system access, etc. An attempt to access without authorization may involve trying to login without the password, attempting to use a physical interface without physical access to the device, or using an interface available to the host system without authorization on the host system.
### 6.4.3 REQ-SBD-02 (MI-PDDI-2): Protect or disable physical access to debug or management interfaces
#### 6.4.3.1 Objective
Secure by default configuration.
#### 6.4.3.2 Preparation
Examine the product technical documentation to find all physically accessible debug or management interfaces, and which interfaces are necessary for backward compability.
#### 6.4.3.3 Activities
For each debug or management interface that may be physically accessed, attempt to use the interface without authorization. For any interface which is found to be usable without authorization, examine the product technical documentation for documentation of the requirement for backward compatibility.
#### 6.4.3.4 Verdict
PASS if **all** of the following are fulfilled:
* All attempts to use debug or management interfaces not necessary for backward compatibility without authorization fail, and
* Product technical documentation of the necessity for backward compatibility is deemed sufficient
Otherwise FAIL
#### 6.4.3.5 Evidence
* Pictures of the product
* Logs of protecting or disabling interfaces
* Logs of attempts to access interfaces
* Sufficiency analysis of documentation of necessity for any unauthorized access for backward compatibility
### 6.4.4 REQ-SBD-03 (MI-PDDI-3): Protect or disable local software access to debug or management interfaces
#### 6.4.4.1 Objective
Secure by default configuration.
#### 6.4.4.2 Preparation
Examine the product technical documentation to find all debug or management interfaces accessible by unauthorized users on the host system, and which interfaces are necessary for backward compability.
#### 6.4.4.3 Activities
For each debug or management interface that may be accessed by an unauthorized user via software on the host system, attempt to use the interface without authorization. For any interface which is found to be usable without authorization, examine the product technical documentation for documentation of the requirement for backward compatibility.
#### 6.4.4.4 Verdict
PASS if **all** of the following are fulfilled:
* All attempts to use debug or management interfaces not necessary for backward compatibility without authorization fail, and
* Product technical documentation of the necessity for backward compatibility is deemed sufficient
Otherwise FAIL
#### 6.4.4.5 Evidence
* Logs of protecting or disabling interfaces
* Logs of attempts to access interfaces
* Sufficiency analysis of documentation of necessity for any unauthorized access for backward compatibility
### 6.4.5 REQ-SBD-04 (MI-PDDI-4): Protect or disable network access to debug or management interfaces
#### 6.4.5.1 Objective
Secure by default configuration.
#### 6.4.5.2 Preparation
Examine the product technical documentation to find all debug or management interfaces accessible by unauthorized users via the attached network, and which interfaces are necessary for backward compability.
#### 6.4.5.3 Activities
For each debug or management interface that may be accessed by an unauthorized user via the attached network, attempt to use the interface without authorization. For any interface which is found to be usable without authorization, examine the product technical documentation for documentation of the requirement for backward compatibility.
#### 6.4.5.4 Verdict
PASS if **all** of the following are fulfilled:
* All attempts to use debug or management interfaces not necessary for backward compatibility without authorization fail, and
* Product technical documentation of the necessity for backward compatibility is deemed sufficient
Otherwise FAIL
#### 6.4.5.5 Evidence
* Logs of protecting or disabling interfaces
* Logs of attempts to access interfaces
* Sufficiency analysis of documentation of necessity for any unauthorized access for backward compatibility
### 6.2.13.4 MI-FDRP assessment
**[MI-FDRP]** Verify the product performs ordered validity checks on incoming packets and drops invalid packets before further processing.
