@@ -898,103 +898,41 @@ 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
* 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
#### 5.2.5.3 MI-DPAH: Documentation of product assets accessible from host
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.
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.
* 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
#### 5.2.5.4 MI-PDDI-1: Document how to protect access to debug/management interfaces
### 5.4.2 REQ-SBD-01 (MI-PDDI-1): Provide methods to protect or disable interfaces
All debug/management interfaces on the product shall be documented as to how to protect or disable them.
#### 5.4.2.1 Requirement
Guidance: This is for the use case of selling to an integrator.
The product shall provide methods to disable or protect all debug or management interfaces on the product that are exposed to unauthorized users, unless doing so would prevent 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 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.4.2.2 Applicability
#### 5.2.5.5 MI-PDDI-2: Protect or disable physical access to debug/management interfaces
TODO - for integrators and other use cases with sophisticated users and protected environments
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.2.3 Guidance
Guidance: This is for the use case of an end user in use cases where physical access is possible for a threat actor.
The exposure of interfaces to unauthorized users is determined by the intended purpose of the product as specified by the manufacturer and the manufacturer's cybersecurity risk assessment.
* 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.3 REQ-SBD-02 (MI-PDDI-2): Protect or disable access to debug or management interfaces
#### 5.2.5.6 MI-PDDI-3: Protect or disable local software access to debug/management interfaces
#### 5.4.3.1 Requirement
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.
All debug or management interfaces accessible to unauthorized users 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.
#### 5.4.3.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
#### 5.2.5.7 MI-PDDI-4: 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: 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.3.3 Guidance
See clause 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.
Only interfaces that would be exposed to unauthorized users need be disabled or protected. Which interfaces are determined by the intended purpose and reasonably foreseeble use specified by the manufacturer, and the manufacturer's risk assessment.
### 5.2.6 ER-SCUD: Secure updates
@@ -1912,6 +1850,89 @@ To demonstrate compliance, the manufacturer may rely on manual security testing
If the product had no known exploitable vulnerabilities before the placement of the tested product on the market (or ever), it should pass this assessment.
## 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): Provide methods to protect or disable interfaces
#### 6.4.2.1 Objective
Secure by default configuration.
#### 6.4.2.2 Preparation
Identify all debug or management interfaces in the product. Categorize them into those that can be protected or disabled and those that cannot. For those that can be protected or disabled, identify methods to do so, using as necessary or available:
Identify an operational environment that permits testing these methods. Identify any necessary configuration, inputs, or other preparation for attempting to access these interfaces without authorization. Install the product in the identified operational environment.
#### 6.4.2.3 Activities
For each identified interface that can be disabled or protected, and for each method, disable or protect each interface, carry out the identified testing preparations, then attempt to use the interface without authorization. For each identified interface that cannot be disabled or protected, analyse whether backwards compatibility prevents the interface from being disabled.
#### 6.4.2.4 Verdict
PASS if **all** of the following are fulfilled:
* All attempts to use debug or management interfaces without authorization fail, and
* For all debug or management interfaces that cannot be disabled or protected, the necessity for backward compatibility and the instructions to the user to mitigate the risk are deemed sufficient.
Otherwise FAIL
#### 6.4.2.5 Evidence
* Documentation of and rationale for search process for interfaces
* Logs of searches for interfaces
* List of identified interfaces
* Sufficiency analysis of rationale for interface search process
* List of methods for protecting or disabling interfaces
* Logs or records of protecting or disabling interfaces
* Logs or records of attempts to access interfaces
* Sufficiency analysis of documentation of necessity for exposing interfaces for backward compatibility, if any
#### 6.4.2.6 Guidance
See Clause \[6.1.2\] "Guidance for identifying interfaces or data processing."
This requirement is intended for the use case of an integrator or distributor who may disable or protect interfaces as necessary for the use case of product in the next step of the supply chain. The initial use for the integrator is often in an operational environment in which no unauthorized users have access to the product.
Authorization may be via a variety of methods: passwords, physical access to the product, 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 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 accessible debug or management interfaces, and which interfaces are necessary for backward compability. Identify which are accessible to unauthorized users in the product's intended purpose and reasonably foreseeable use.
#### 6.4.3.3 Activities
For each debug or management interface identified in the previous step, 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 and the instructions for the user to mitigate the risks.
#### 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
* Analysis of the necessity for backward compatibility of interfaces that cannot be disabled or protected, if any, is deemed sufficient, and
* Mitigation and information for the user for any such interfaces is deemed sufficient
Otherwise FAIL
#### 6.4.3.5 Evidence
* Pictures of physical interfaces to the product, if applicable
* Descriptions of identified debug or management interfaces
* Logs or records of protecting or disabling interfaces
* Logs or records of attempts to access interfaces
* Sufficiency analysis of documentation of necessity for any unauthorized access for backward compatibility, if any
* Sufficiency analysis of instructions to user for mitigating risks, if any
### 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.
