Added new requirements with assessments to 5.13 Exploit mitigation

# 5 Technical requirements for the Products

<mark>Editor’s Note: Proposed structure for indexing the requirements in ETSI deliverables:<br>

REQ-PP-[TECHNICAL-FAMILY]-NNN REQ: Used to identify requirement in the text<br>

PP : Product short name added only if relevant when the product category may be divided in sub categories<br>

TECHNICAL FAMILY :Proposed abbreviations referring to the technical domain covered by the requirement<br>

NNN - Incremental and unique sequence of numbers and letters

</mark>

<mark>Editor’s Note: Requirements should be unambiguous regarding the preferred implementation, ensuring that specific security qualities of the product are achieved, the presence of which can be consistently and deterministically tested. Accordingly, vague or contextual requirements such as use of “state-of-the-art techniques” or “authentication mechanism” are not sufficiently granular. Instead, all viable concrete options shall be listed with a clearly indicated prioritisation and potentially a selection process.</mark>

<mark>Editor’s Note: Where integration of components is required to fulfil security functions, technical requirements should explain how to securely integrate these at the immediate architectural boundary, including interactions via interfaces to components and their configuration.</mark>

The technical documentation referenced in this clause is intended to describe the product design, dependencies, and implemented measures relevant to demonstrating conformity with the applicable requirements of the present document.

## 5.1 Introduction - Applicability of the requirements

| UC_ENTERRPISE | IM_SEGMENT      | medium         |

| UC_TELCO      | IM_SEGMENT      | high           |

| all           | MAS_TECH        | all            |

| all           | EM_             | all            |

|               | EMM_ROUTE       | low            |

|               | EMM_ROUTE       | medium         |

|               | EMM_ROUTE       | high           |

|               | MON_LOG         | low            |

|               | MON_LOG         | medium         |

|               | MON_LOG         | high           |

The identity management is often assessed as part of certification processes, and is outside of this document. [\[i.12\]](#_ref_i.12)

Identity management system design and implementation is outside of the scope of this standard.

Depending on the product design, the identity management referred in [REQ-AUTH-0] can be either part of the deliverable product, part of the deployment context as outside source or both, where redundancy is desirable or necessary.

Depending on the product design, the identity management referred in **AAC_AUTH-1** can be either part of the deliverable product, part of the deployment context as outside source or both, where redundancy is desirable or necessary.

Integration into 3rd party identity management systems is preferred due to the higher likelihood that a dedicated identity management system is part of existing processes, up-to-date and can invalidate subjects credentials when necessary.

The relevance, availability, and correctness of the identity management system or service is crucial for the product and therewith for the entire network security, as it is the basis for the entire sequence from identity, over authentication up to the final user authorization.

#### Generic requirements

All subjects require roles or comparable control structures like Attribute-Based Access Control, to limit individual access credentials to the smallest possible set of requested operations.

This is the reason for the requirement [REQ-AUTH-3], but as the evaluating the fit of the implementation to the intended use, the design validation is only vaguely specified in the requirement [REQ-AUTH-4].

This is the reason for the requirement **AAC_AUTH-1**, but as the evaluating the fit of the implementation to the intended use, the design validation is specified in the requirement **AAC_AUTH-5**.

These requirements apply to the product, regardless of the product's use case and without variation for different tiers or risk.

* **AAC_AUTH-1:** The product shall support identity management through at least one of the following approaches:

* **AAC_AUTH-1** The product shall support identity management through at least one of the following approaches:

   * integration of the product into an external state-of-the-art Identity Management System

   * integration of an external Identity Management System into the product, or

   * a dedicated Identity Management module built into the product.

* **AAC_AUTH-2:** The product shall not implement a design where default credentials or keys are used to identify subjects.

* **AAC_AUTH-3:** Product shall use multi-factor authentication to confirm the identity of a natural user appropriate to the intended and reasonably foreseeable use.

* **AAC_AUTH-4:** Product shall limit a natural user's authorisation validity of a session via a configurable setting that shall be initially limited by factory default of one day.

* **AAC_AUTH-5:** The authorisation model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.

* **AAC_AUTH-6:** All access to privileged interfaces, control functions, and sensitive operations shall be subject to strong authentication of subjects, services, or integrated components.

* **AAC_AUTH-7:** Privileged interfaces shall be protected with [5.7.1 State-of-the-art cryptographic libraries](#571-state-of-the-art-cryptographic-libraries).

* **AAC_AUTH-8:** The product shall report all relevant events related to authorisation including, but not limited to:

* **AAC_AUTH-2** The product shall not implement a design where default credentials or keys are used to identify subjects.

* **AAC_AUTH-3** Product shall use multi-factor authentication to confirm the identity of a natural user appropriate to the intended and reasonably foreseeable use.

* **AAC_AUTH-4** Product shall limit a natural user's authorisation validity of a session via a configurable setting that shall be initially limited by factory default of one day.

* **AAC_AUTH-5** The authorisation model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.

* **AAC_AUTH-6** All access to privileged interfaces, control functions, and sensitive operations shall be subject to strong authentication of subjects, services, or integrated components.

* **AAC_AUTH-7** Privileged interfaces shall be protected with [5.7.1 State-of-the-art cryptographic libraries](#571-state-of-the-art-cryptographic-libraries).

* **AAC_AUTH-8** The product shall report all relevant events related to authorisation including, but not limited to:

  * successful and unsuccessful use of identity

  * object access

  * policy change

  * privileged function use

  * data access and deletions

  * data changes and permission changes.

* **AAC_AUTH-9:** The product shall verify successfully an explicit authorisation decision immediately before execution of any privileged action that can modify, including but not limited to:

* **AAC_AUTH-9** The product shall verify successfully an explicit authorisation decision immediately before execution of any privileged action that can modify, including but not limited to:

  * managed-element configuration

  * control-plane behaviour routing or forwarding state

  * security policy

  * software state

  * availability

  * network reachability.

* **AAC_AUTH-10:** The authorisation decision shall be bound to, and made available in auditable event data, including but not limited to:

* **AAC_AUTH-10** The authorisation decision shall be bound to, and made available in auditable event data, including but not limited to:

  * source of the identity

  * the acting identity

  * whether natural user or machine user

  * material request parameters

  * policy version or rule identifier

  * and validity interval.

* **AAC_AUTH-11:** The product shall prevent execution of such privileged action when the authorisation decision is absent, expired, inconsistent with current policy or context, or cannot be recorded as an auditable event except if the action aims to enable or restore auditability of the product.

* **AAC_AUTH-11** The product shall prevent execution of such privileged action when the authorisation decision is absent, expired, inconsistent with current policy or context, or cannot be recorded as an auditable event except if the action aims to enable or restore auditability of the product.

The requirement **AAC_AUTH-5:** is intentionally vague.

The model can be complex, and there can be multiple different overlapping mechanisms in place that can used to enable the same function.

It can built on top of existing authority structures, or it can re-run some parts of the device initialisation procedures.

How the retake of the authority is implemented is between the product and the device.

* **AAC_MACHINE-1:** The product shall provide passwordless authentication for machine users such as certificates or tokens.

* **AAC_MACHINE-2:** The privileged interfaces like APIs shall support minimal access grants for the machine user.

* **AAC_MACHINE-1** The product shall provide passwordless authentication for machine users such as certificates or tokens.

* **AAC_MACHINE-2** The privileged interfaces like APIs shall support minimal access grants for the machine user.

## 5.7 Confidentiality protection

## 5.13 Exploit mitigation

<mark>_Proposed ESR code: EM_</mark>

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

<mark>Stuff from VPN about memory safety.</mark>

The managed element can be anything from a toaster to a basestation.

This document assumes, that those devices will get compromised.

For **low** risk:

* **EMM_ROUTE-1** The connection to the managed element shall be configurable to enforce granular packet filtering by managed element or server identity, and destination address.

For **medium** risk:

* **EMM_ROUTE-2** The product shall only permit traffic that is validated and explicitly authorized to transit the management connection.

For **high** risk:

* **EMM_ROUTE-3** The product shall emit an auditable event from out-of-place traffic.

## 5.14 Monitoring

* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;

* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

#### 6.14.2.3 REQ-METRICS-3

**Objective:** The product provides the information on the meaning of the metrics data and about their memory and storage consumption.<br/>

**Preparation:**

1.  Have the product initialised and available with the default configuration and required credentials.

**Activities:**

1. Study the monitoring data GUI.

1. Study the provided documentation.

1. Investigate the metrics storage.

**Verdict:**

1. Pass if the metrics collection cadence, accuracy and storage time matches the described use.

1. Fail otherwise.

**Supporting Evidence:**

1. The technical documentation.

1. Metrics storage plan.

## 6.10 Availability protection

### 6.10.1 AP_HA-1

## 6.13 Exploit mitigation

### 6.13.1 EMM_ROUTE-1

**Objective:** Protect the network from compromised devices.<br/>

**Preparation:**

1. Have the product initialised and available with the default configuration and required credentials.

2. Study the technical documentation

**Activities:**

1. Investigate the implementation.

**Verdict:**

1. Pass, if filtering can be implemented based on instructions.

2. Fail otherwise.

**Supporting Evidence:**

* Relevant vendor or design documentation describing the applied measures;

* Test reports showing the steps performed and results obtained;

* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;

* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

### 6.13.2 EMM_ROUTE-2

**Objective:** Protect the network from compromised devices.<br/>

**Preparation:**

1. Have the product initialised and available with the default configuration and required credentials.

2. Study the technical documentation

**Activities:**

1. Investigate the implementation.

**Verdict:**

1. Pass, if only management and control traffic is allowed in the link between the product and the managed device.

2. Fail otherwise.

**Supporting Evidence:**

* Relevant vendor or design documentation describing the applied measures;

* Test reports showing the steps performed and results obtained;

* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;

* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

### 6.13.3 EMM_ROUTE-3

**Objective:** Protect the network from compromised devices.<br/>

**Preparation:**

1. Have the product initialised and available with the default configuration and required credentials.

2. Study the technical documentation

**Activities:**

1. Investigate the implementation.

2. Generate packets or performa actoins that is not classified as management traffic.

**Verdict:**

1. Pass, if an event is emitted summarising the detected rogue traffic.

2. Fail otherwise.

**Supporting Evidence:**

* Relevant vendor or design documentation describing the applied measures;

* Test reports showing the steps performed and results obtained;

* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;

* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

## 6.14 Monitoring

### 6.14.1 Logging tests