Commit 6a8572f4 authored by Valerie Aurora's avatar Valerie Aurora
Browse files

Update Clause 5.12/6.12 Attack surface minimisation to revised structure

parent ffeac6d8
Loading
Loading
Loading
Loading
+51 −18
Original line number Diff line number Diff line
@@ -1210,31 +1210,21 @@ The product shall implement methods of detecting and mitigating denial of servic

TODO

### 5.2.14 ER-LMAS: Minimize exposed interfaces
## 5.12 Attack surface minimisation

#### 5.2.14.1 Cybersecurity requirement
### 5.12.1 Overview

The product's exposed interfaces shall be minimized 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.
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (j).

#### 5.2.14.2 MI-JSTY: Document and justify exposed interfaces
### 5.12.2 REQ-ASM-01 (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.

  * Reference: ER-LMAS

  * Objective: Limit attack surface

  * Preparation: List all types of interfaces on the product that may be exposed to an attacker, whether enabled or disabled. For each type of interface, list all exposed interfaces of that type, and document the method or methods used to create and verify these lists. List all states of the product with different exposed interfaces of the product in its secure-by-default configuration, including but not limited to initial configuration, startup, in use, idle, shutdown, and reset, if applicable. For each distinct exposed interface in each state, describe the interface and why it has to be enabled by default.

  * Activities: Using the list of types of interfaces, the list of states of the product, list all exposed interfaces in each state, and document the method or methods used to create and verify this list. Compare the list of exposed interfaces by state to the documented list by type.
#### 5.12.2.1 Requirement

  * Verdict: All discovered interfaces are documented, including rationale => PASS, otherwise => FAIL

  * Evidence: List of types of interfaces, list of product states, documentation of each exposed interface, output of methods to list all exposed interfaces, connection between each discovered interface to its documentation
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.

#### 5.2.14.3 Mapping of mitigations to risk factors and security profiles
#### 5.12.2.2 Applicability

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

### 5.2.15 ER-LOGG: Logging and monitoring

@@ -2364,6 +2354,49 @@ Automated vulnerability scanners, penetration testing tools, or test cases for v

One method of mitigating the attack is to notify the host system in some manner.

## 6.12 Attack surface minimisation

### 6.12.1 Overview

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (j).

### 6.12.2 REQ-ASM-01 (MI-JSTY): Document and justify exposed interfaces

#### 6.12.2.1 Objective

Minimise attack surface.

#### 6.12.2.2 Preparation

Examine the product documentation for interfaces that may pose a unacceptable risk if exposed in the product's secure-by-default configuration in different states of the product, including but not limited to initial configuration, startup, in use, idle, shutdown, and reset, if applicable.

#### 6.11.2.3 Activities

For each identified interface, examine the documented rationale for why exposing the interface is necessary for the functioning of the product in this state. Use appropriate tools and methodology to search for additional interfaces that are undocumented or exposed when they should not be and document the rationale for the search plan.

#### 6.11.2.4 Verdict

PASS if **all** of the following are fulfilled:

* For each identified exposed interface, the documented rationale for exposure of the interface is deemed sufficient, and
* No exposed interface found in the interface search are without a documented rationale, and
* No undocumented exposed interfaces are found.

Otherwise FAIL

#### 6.11.2.5 Evidence

* Documentation accompanying product
* Sufficiency analysis of rationales for interface exposure
* Documentation of the interface search process
* Sufficiency analysis of rationale for interface search process
* Logs of searches for interfaces
* Correlation between interfaces found during search and documented rationales

#### 6.11.2.5 Guidance

A number of tools and techniques may be used to search for exposed interfaces, including network scanners, scanning a device's mapped memory regions on the system bus, penetration testing software suites, packet sniffers, snooping on various busses, and examining source code and configuration. A search plan does not need to be able to find all possible undocumented interfaces, only those that would found by a threat actor under the conditions of the manufacturer's cybersecurity risk assessment. An element of the rationale for an interface search plan might be "This scanning suite is the most complete version used by professional vulnerability researchers."

# Annex A (informative): Relationship between the present document and the requirements of EU Regulation (EU) 2024/2847 - the Cyber Resilience Act

<mark>Editor's Note: Even if informative, this Annex is mandatory in Harmonised Standards.</mark>