Replaced security with cybersecurity where applicable

## 4.4 Use cases

This list of use cases is an informative resource for manufacturers to simplify the selection of a set of security requirements. Each use case is mapped to a security profile, which is a collection of risks and the security requirements necessary to mitigate them.

This list of use cases is an informative resource for manufacturers to simplify the selection of a set of cybersecurity requirements. Each use case is mapped to a security profile, which is a collection of risks and the cybersecurity requirements necessary to mitigate them.

Manufacturer shall declare in the technical documentation the security profile for which their products are intended to be evaluated.

Aggregate product can have components, like an OS and networking interfaces, which are evaluated outside of the scope of the present document.

More boundaries are listed in the [C3 Assumptions](#c3-assumptions).

Manufacturers shall be responsible for implementing all security measures, regardless of the subcomponents in use.

Manufacturers shall be responsible for implementing all cybersecurity measures, regardless of the subcomponents in use.

### 4.4.1 Distributed deployment

-   Security expectations of intented network segment operation

    -   **Rationale:** NIS2 identifies entities that require higher level of protection. The important and essential classificatoins are combined as the NIS2 does't make additional security requirements based on classification.

    -   **Rationale:** NIS2 identifies entities that require higher level of protection. The important and essential classificatoins are combined as the NIS2 does't make additional cybersecurity requirements based on classification.

    -   **[EXP-L-0]** Undefined

    -   **[EXP-L-1]** NIS2 important or essential entity

## 4.6 Security Profile

Security profiles are a resource to the manufacturer. Each security profile is associated with a collection of levels of risk factors.

Risk factors will be mapped to specific mitigations for each security requirements necessary to treat the risk.

Risk factors will be mapped to specific mitigations for each cybersecurity requirements necessary to treat the risk.

All products with digital elements has a common set of requirements that shall be addressed regardless of the system design or intented market. These are defined in the CRA [\[i.1\]](#_ref_i.1).

The risk factors listed in this document meant to help the manufacturer to address specific scenarios which implementation might not be obvious.

## 4.10 Distribution of security functions

A NMS is often a compilation of different subsystems performing the task of the network management. The security functions may be implemented inside of the product as an integral part of the system or with help the of an established structures like OS package manager or logging subsystems.

A NMS is often a compilation of different subsystems performing the task of the network management. The cybersecurity functions may be implemented inside of the product as an integral part of the system or with help the of an established structures like OS package manager or logging subsystems.

For each security requirement, a product may:

For each cybersecurity requirement, a product may:

1. Provide all necessary security functions itself

2. Require security functions be provided by some other part of its context

### 4.10.1 Security functions provided outside the product

The following security functionalities may be handled by other components in the system:

The following cybersecurity functionalities may be handled by other components in the system:

-   Secure update of firmware and/or device driver in the managed element

-   **Identity management systems** that provide mechanisms for authentication or authorisation and that may also provide mechanisms for the lifecycle management of identity credentials  [\[i.2\]](#_ref_i.2)

-   **Virtual Private Network** that provide access to a restricted-use logical computer network that is constructed from the system resources of a physical or virtual network  [\[i.3\]](#_ref_i.3)  [\[i.4\]](#_ref_i.4)

-   **Provision of cryptographic keys** that serve as a management system for asymmetric cryptographic keys, digital certificates or signed or encrypted data created using digital certificates  [\[i.6\]](#_ref_i.6)

-   **Security information and event management systems** that collect data from multiple sources, analyse and correlate that data and present it as actionable information for security-related purposes unless it is considered to be integral part of the NMS product features  [\[i.7\]](#_ref_i.7)

-   **Security information and event management systems** that collect data from multiple sources, analyse and correlate that data and present it as actionable information for cybersecurity-related purposes unless it is considered to be integral part of the NMS product features  [\[i.7\]](#_ref_i.7)

-   **Physical and virtual network interfaces**

-   **Operating systems** that provide an abstract interface of the underlying hardware and control the execution of software  [\[i.5\]](#_ref_i.5)

-   **Routers, modems and switches** that establish and control the flow of data between different networks  [\[i.8\]](#_ref_i.8)

# 5 Requirements specifications

**Technical documentation responsibility** used in the following tables and requirements is a requirement for the manufacturer to specify what actions and designs are supporting the intention to provide similiar, or higher level of security in the context.

**Technical documentation responsibility** used in the following tables and requirements is a requirement for the manufacturer to specify what actions and designs are supporting the intention to provide similiar, or higher level of cybersecurity in the context.

## 5.1 General

<mark>TODO</mark>

## 5.2 Technical security requirements specifications

## 5.2 Technical cybersecurity requirements specifications

> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.

> List technical cybersecurity requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.

This section contains technical security requirements for the product. Each general technical requirement is objectively verifiable on an instance of a product.

This section contains technical cybersecurity requirements for the product. Each general technical requirement is objectively verifiable on an instance of a product.

Each requirement has at least one concrete example that satisfies the requirements of the CRA.

Later [Section 5.3 Risk Mitigations](#53-risk-mitigations) combines these general requirements to [Section 4.5 Risk Factors](#45-risk-factors). The Risk Mitigations can include additional topic specific requirements.

-   **[REQ-TECH-5]** All system components are synchronized to the same time.

-   **[REQ-TECH-6]** All system clocks are monitored.

**Table 5.2-1: Technical security requirements**

**Table 5.2-1: Technical cybersecurity requirements**

| Requirement      | Assesment                                                                                                    |

|:-|:-----|

## 5.3 Risk Mitigations

The following sections describe how technical security requirement in previous [Section 5.2](#52-technical-security-requirements-specifications) are mapped to the risk factors in [Section 4.5 Risk Factors](#45-risk-factors).

The following sections describe how technical cybersecurity requirement in previous [Section 5.2](#52-technical-cybersecurity-requirements-specifications) are mapped to the risk factors in [Section 4.5 Risk Factors](#45-risk-factors).

This section can include topic specific requirements.

### 5.3.1 Mitigations for user identity integrity

> Initially proposed format to define the assessment, to be further finetuned

>

> 1. **Assessment Reference:** Identifies the link to the exact requirement ID(s). (the requirement)

> 1. **Assessment Objective:** Defines the security property or capability that shall be verified, ensuring that the assessment remains focused on the intent of the requirement.

> 1. **Assessment Objective:** Defines the cybersecurity property or capability that shall be verified, ensuring that the assessment remains focused on the intent of the requirement.

> 1. **Assessment Preparation:** Describes the environment, setup, and preconditions required before executing the test. (tool, guidance)

> 1. **Assessment Activities:** Provides execution steps to be performed. Activities are designed to cover the necessary rigor depending on whether the requirement is Basic, Elevated, or Advanced. (test, result)

> 1. **Assignment of Verdict:** Defines the pass/fail criteria. The assessment is considered successful if the requirement’s protection goals are demonstrably met; it fails if unauthorized access, modification, or bypass is possible, or if required security capabilities are unsupported. (treshold)

> 1. **Assignment of Verdict:** Defines the pass/fail criteria. The assessment is considered successful if the requirement’s protection goals are demonstrably met; it fails if unauthorized access, modification, or bypass is possible, or if required cybersecurity capabilities are unsupported. (treshold)

> 1. **Supporting Evidence:** Lists the artefacts to be collected and documented, such as logs, configuration files, screenshots, vendor documentation, and test results. Evidence ensures traceability and allows independent review. (test or assesment output)

## 6.1 General requirements assesments

#### 6.1.1.0 REQ-EXPLOIT-0

**Objective:** NMS dependencies to Operating System essential security capabilities are documented.<br/>

**Objective:** NMS dependencies to Operating System essential cybersecurity capabilities are documented.<br/>

**Preparation:** None<br/>

**Activities:**

1. References to to documentation sections.

## 6.2 Technical security requirement tests and assesments

## 6.2 Technical cybersecurity requirement tests and assesments

### 6.2.5 REQ-TECH-5

# Annex A (informative): Mapping with essential requirements of the CRA

> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.

> Table mapping technical cybersecurity requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical cybersecurity requirements.

**Table A-1: Essential requirements mapping**

| CRA requirement                                 | Technical security requirements(s)                                                      |

| CRA requirement                                 | Technical cybersecurity requirements                                                    |

|:-|:--|

| No known exploitable vulnerabilities            | [5.1.1 No known exploitable vulnerabilities]                                            |

| Secure design, development, production          | [5.1.2 Secure design, development and production], [5.1.3 Product lifecycle management] |

[5.1.2 Secure design, development and production]: #512-secure-design-development-and-production

[5.1.3 Product lifecycle management]: #513-product-lifecycle-management

[5.1.4 Product vulneravility management process]: #514-product-vulneravility-management-process

[5.2 Technical security requirements specifications]: #52-technical-security-requirements-specifications

[5.2 Technical cybersecurity requirements specifications]: #52-technical-cybersecurity-requirements-specifications

[5.2.1 Secure channel definition]: #521-secure-channel-definition

[5.2.2 Cryptographic key intialization and rotation]: #522-cryptographic-key-intialization-and-rotation

[5.2.3 Network segmentation]: #523-network-segmentation

[5.3.7 Data minimization]: #537-data-minimization

[5.3.8 High Availability]: #538-high-availability

> Table mapping status of security requirements in each section. Will be removed form the finalized standard.

> Table mapping status of cybersecurity requirements in each section. Will be removed form the finalized standard.

**Table A-2: Security requirements mapping to sections**

**Table A-2: Cybersecurity requirements mapping to sections**

| Section                                                                            |  Content status                   |  Tests status                   |

|:---|:-|:-|

| [5.1.2 Secure design, development and production]                                  | todo                              | todo                            |

| [5.1.3 Product lifecycle management]                                               | todo                              | todo                            |

| [5.1.4 Product vulneravility management process]                                   | todo                              | todo                            |

| [5.2 Technical security requirements specifications]                               | almost there                      | todo                            |

| [5.2 Technical cybersecurity requirements specifications]                          | almost there                      | todo                            |

| [5.2.1 Secure channel definition]                                                  | idea would need refinement        | todo                            |

| [5.2.2 Cryptographic key intialization and rotation]                               | format needs to be changed        | todo                            |

| [5.2.3 Network segmentation]                                                       | idea would need refinement        | todo                            |

> -   Use for intended purpose or reasonably foreseeable use

> -   When integrated into another product

> Example threats can be found in the same documents suggested in the section on security requirements.

> Example threats can be found in the same documents suggested in the section on cybersecurity requirements.

[Recital 58]  [\[i.1\]](#_ref_i.1)