Commit 2cbf3f97 authored by Santeri Toikka's avatar Santeri Toikka
Browse files

Moved scope, references, terms, abbreviations, essential functions, product...

Moved scope, references, terms, abbreviations, essential functions, product functions to the revised structure
parent 5b69ba65
Loading
Loading
Loading
Loading
+0 −144
Original line number Diff line number Diff line
@@ -73,119 +73,18 @@ The present document is created for EU Regulation 2024/2847, the Cyber Resilienc

## 1.2 Products in scope

The implementing regulation [\[i.11\]](#_ref_i.11) defines in section (2) that the core functionality of a product defines what category it should be evaluated under. The regulation continues to define in section (3), that when the product is a composite of other recognised products, the composite product doesn't inherit all other regulations, but is evaluated only in it's own category.


The implementing regulation [\[i.11\]](#_ref_i.11) (ANNEX I, Class I, 6.) defines the following:

> Products with digital elements that manage connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by monitoring them and controlling their network operations and configuration.
>
> This category includes but is not limited to end-to-end management systems and dedicated configuration management systems, such as controllers for software-defined networking.

This quotation is not to be used as a source of the truth, as the definition might change. Refer to the source for the latest description.

The NMS is defined in the implmeneting regulation [\[i.11\]](#_ref_i.11) in Annex I, Class I (6) and is not restricted to only systems that are IP connected. The scope covers all connected elements in the network, that are managed. This includes, but is not limited to, Mobile Device Management systems and Software Defined Networking.

Bluetooth consumer devices are usually not managed by an NMS, however, if they are capable, a NMS management could control them too, as Bluetooth is just a communication media and can be used also for management traffic. Such, NMS’s often control more than just network configuration - e.g., MDM systems.

# 2 References

## 2.1 Normative references

> NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.

The following referenced documents are necessary for the application of the present document.

<span id="_ref_1"></span><a name="_ref_1">[1]</a> ENISA April 2025 (Version 2.0) "Agreed Cryptographic Mechanisms"

<span id="_ref_2"></span><a name="_ref_4">[2]</a> prEN 40000-1-3 "Vulnerability Handling"

## 2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

> NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.

The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding but are not required for conformance to the present document.

<span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> EU 2024/2847 "Cyber Resilience Act"

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> ETSI EN 304 XXX IAM (CEN/TC 224 WG 17 output)

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a> ETSI EN 304 620 "Virtual Private Networks (VPNs)"

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> CEN/CLC EN 50XXX-4 "VPN"

<span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> ETSI EN 304 626 "Essential cybersecurity requirements for operating systems"

<span id="_ref_i.6"></span><a name="_ref_i.6">[i.6]</a> ETSI EN 304 624 "PKIs and certificate issuance software"

<span id="_ref_i.7"></span><a name="_ref_i.7">[i.7]</a> ETSI EN 304 622 "Essential cybersecurity requirements for Security information and event management (SIEM) systems"

<span id="_ref_i.8"></span><a name="_ref_i.8">[i.8]</a> ETSI EN 304 627 "Router, modems and switches"

<span id="_ref_i.9"></span><a name="_ref_i.9">[i.9]</a> ETSI EN 304 642 "Cybersecurity Requirements for Telecommunication Systems"

<span id="_ref_i.10"></span><a name="_ref_i.10">[i.10]</a> [Mitre ATT&CK] framework

<span id="_ref_i.11"></span><a name="_ref_i.11">[i.11]</a> EU 2025/2392 Comission implementing regulation on the technical description of the categories of important and critical products with digital elements pursuant to Regulation EU 2024/2847 (CRA)

<span id="_ref_i.12"></span><a name="_ref_i.12">[i.12]</a> ISO/IEC 27000:2018

<span id="_ref_i.13"></span><a name="_ref_i.13">[i.13]</a> NIST SP 800-63B-4 Authentication & Authenticator Management

<span id="_ref_i.14"></span><a name="_ref_i.14">[i.14]</a> prEN 40000-1-1 "Vocabulary"

<span id="_ref_i.15"></span><a name="_ref_i.15">[i.15]</a> prEN 40000-1-2 "Principles for cyber resilience"

<span id="_ref_i.16"></span><a name="_ref_i.16">[i.16]</a> Directive (EU) 2022/2555 of the European Parliament and the council and (EU) 2024/2690 European Commission implmenting regulation

<span id="_ref_i.17"></span><a name="_ref_i.17">[i.17]</a> Example source for DDoS related threat reports https://radar.cloudflare.com/reports


[Mitre ATT&CK]: (https://attack.mitre.org)

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

This section provides terms and definitions based on CEN/CLC JTC13 WG09's work on terms and definitions, terms and definitions provided by ETSI EN 303 645/TS 103 701 and terms and definitions provided by CEN/CLC EN 18031 series.

For the purposes of the present document, the following terms apply:

1. **Operating System (OS):** software product that provides an abstract interface to the underlying hardware and that controls the execution of software
1. **Identity Provider (IDP):** system maintaining identity information
1. **Service Requesting Users (<span name="_term_.SRU">SRU</span>):** users relying on the correct functioning of the network element
1. **user:** person having the credentials to login to the NMS to operate administrative actions to control and maintain the managed element
1. **machine user:** virtual user used to access the system programming interfaces
1. **component:** software or hardware intended for integration into an electronic information system
1. **Application Programming Interface (API):** interface used to communicate with the running program
1. **log**: record of an operational event
1. **trace**: record of a system status with all relevant data that can be gathered

## 3.2 Abbreviations

For the purposes of the present document, the following abbreviations apply:

`ABAC   Attribute-Based Access Control`
`CRA    Cyber Resilience Act`
`OS     Operating System`
`IDP    Identity Provider`
`VPN    Virtual Private Network`
`SIEM   Security Information and Event Management Systems`
`NMS    Network Management System`
`2FA    Two Factor Authentication`
`CSP    Communication System Provider`
`SDN    Software Defined Networks`
`GUI    Graphical User Interface`
`NE     Network Element`
`MDM    Mobile Device Management`
`IAM    Identity and Access Management`
`OCI    Open Container Initiative`
`SRU    Service Requesting Users`
`PII    Personally Identifiable Information`


# 4 Product context

## 4.1 General
@@ -352,55 +251,12 @@ All products with digital elements have a common set of requirements that shall

## 4.7 Essential functions

Following list of essential functions keep the NMS self-secure and correct functioning during its operation in its intended environment.

-   Network element configuration and change management
-   The NMS will use the appropriate level of access control to maintain identity and actions each system actor can take
-   Collection and evaluation of performance metrics to support monitoring of network operation.
-   Fault detection, reaction and recovery from fail state
-   Functional resilience in terms of maintaining correct operation under abnormal network conditions, e.g., connection loss to managed elements.
-   Functional resilience in the event of
    1.   loss of connectivity to managed elements
    1.   loss of required supporting network services such as time synchronization or backup services
    1.   or loss of power.
-   Dynamic routing and switching control based on requests. Used extensively with Software Defined Networks.
-   Device discovery, inventory building and depending on the use case topology map generation.
-   Produce logs and traces for security and operational analysis

## 4.8 Product functions

<mark>Editor’s Note: Product functions should be clearly defined and granular enough to inform decision-making regarding capability-based applicability of related security controls. The recommended structure for doing this is a hierarchical functional decomposition, wherein each larger functional capability is broken down into its constituent parts. This enables manufacturers to easily derive whether their product supports parts of or all of a specific function.</mark>

<mark>Editor’s Note: If the product category consists of multiple distinct product types, the functions of each product type should be listed separately, possibly following an overall function list up with a mapping to product types.</mark>

<mark>Editor’s Note: Where a product contributes to the delivery of services as part of a system, these services do not constitute functionalities of the product. Identify the product’s role in the delivery of services.</mark>

<mark>Editor’s Note: Configuration functionality is equally in scope.</mark>

## 4.9 Users

## 4.10 Distribution of security functions

### 4.10.1 External security functions, not in scope of the present document

The following cybersecurity functionalities can be handled from components outside the product:

-   From external provided updates on secured channels that the product uses to update the managed managed elements and also itself.
-   **Identity management systems** that provide mechanisms for identification and authentication. The system can include also the lifecycle management for identity credentials [\[i.2\]](#_ref_i.2)
-   **Virtual Private Network** providing access to a physical or virtual established network of managed devices that have strictly controlled access to authorised functions of the product. [\[i.3\]](#_ref_i.3) [\[i.4\]](#_ref_i.4)
-   **Provision of cryptographic keys** coming from a public key infrastructure or other key management system for services of key generation, provision, establishment, and for certificate services such as generation, signing, verification, validation or withdrawal. [\[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 product features [\[i.7\]](#_ref_i.7)
-   **Physical and virtual network interfaces** on the NMS-host and not used or accessed by users for the operation of the NMS.
-   **Operating systems** Operating systems that acting as abstraction layer for the hardware system(s) that host the product and are else not involved in the internal functioning. [\[i.5\]](#_ref_i.5)
-   **Managed devices** Managed devices, including those that are managed by the product, such as routers, modems and switches. [\[i.8\]](#_ref_i.8)

Furthermore, it is essential to detail the generation and establishment of the trust relations between the NMS and the essential external services and systems.

### 4.10.2 Security functions provided to other products

The NMS shall provide the reliable availability of the operative network, while keeping control and providing traffic meta data and metrics for the administrator for verification of the correct network operation.
Example: A listed managed element in the NMS can be enriched with traffic meta data. For example, and inconclusive, when and with what performance there was relevant traffic throughput, when/from/to there was a managed element traffic overload, received failure reporting or similar.

# 5 Requirements specifications

## 5.1 General
+106 −9
Original line number Diff line number Diff line
@@ -93,27 +93,24 @@ Further information on guidance for the application of the present document is p
# 1 Scope

The present document specifies technical requirements and corresponding assessment criteria for [vertical product category name] related to cybersecurity.
The products with digital elements in scope, thereafter "the product_short_name":
The products with digital elements in scope, thereafter "NMS":

are specified within the "technical description" of the "category of product" number "NN" by the Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council. [\[i.2\]](#_ref_i.2) as:

[quoting definition of the product category from the implementing act is permitted here in quotation marks]
> Products with digital elements that manage connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by monitoring them and controlling their network operations and configuration.
>
> This category includes but is not limited to end-to-end management systems and dedicated configuration management systems, such as controllers for software-defined networking.

The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) Annex I Part I under the conditions identified in annex A.

> NOTE: This reduces the scope of the vertical. Full presumption of conformity of the product will be given by complying with both the CRA Vertical standard and PT3, once they are cited in the EUOJ.

<mark>Editor's Note: it is ok to quote the definitions from the CRA legal text  but only definitions, no other parts of the text.</mark>

<mark>Editor’s Note: For products that are part of broader categories, the scope should list the product types that are covered.</mark>

<mark>Editor’s Note: Explain which products are covered by other vertical standards that have an overlap with the product category targeted by this standard.</mark>

Where applicable, the scope could include the following exclusion:
[the product_short_name] intended for use in the industrial OT (Operational Technology) domain are excluded from the scope of the present document, see prEN 50770 series [\[i.x\]](#_ref_i.x).

<mark>Editor’s Note: Avoid paraphrasing the technical description itself, because that risks narrowing down or broadening the product category unintentionally</mark>

The scope covers all connected elements in the network, that are managed. This includes, but is not limited to, Mobile Device Management systems and Software Defined Networking.

# 2 References

@@ -139,6 +136,7 @@ The following referenced documents are necessary for the application of the pres

<span id="_ref_2"></span><a name="_ref_2">[2]</a> prEN 40000-1-3: "Cybersecurity requirements for products with digital elements - Vulnerability Handling"

<span id="_ref_1"></span><a name="_ref_3">[3]</a> ENISA April 2025 (Version 2.0) "Agreed Cryptographic Mechanisms"

## 2.2 Informative references

@@ -158,6 +156,42 @@ The following referenced documents may be useful in implementing an ETSI deliver

<span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> prEN 40000-1-2: “Cybersecurity requirements for products with digital elements – Principles for cyber resilience”

<span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> EU 2024/2847 "Cyber Resilience Act"

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> ETSI EN 304 XXX IAM (CEN/TC 224 WG 17 output)

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a> ETSI EN 304 620 "Virtual Private Networks (VPNs)"

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> CEN/CLC EN 50XXX-4 "VPN"

<span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> ETSI EN 304 626 "Essential cybersecurity requirements for operating systems"

<span id="_ref_i.6"></span><a name="_ref_i.6">[i.6]</a> ETSI EN 304 624 "PKIs and certificate issuance software"

<span id="_ref_i.7"></span><a name="_ref_i.7">[i.7]</a> ETSI EN 304 622 "Essential cybersecurity requirements for Security information and event management (SIEM) systems"

<span id="_ref_i.8"></span><a name="_ref_i.8">[i.8]</a> ETSI EN 304 627 "Router, modems and switches"

<span id="_ref_i.9"></span><a name="_ref_i.9">[i.9]</a> ETSI EN 304 642 "Cybersecurity Requirements for Telecommunication Systems"

<span id="_ref_i.10"></span><a name="_ref_i.10">[i.10]</a> [Mitre ATT&CK](https://attack.mitre.org) framework

<span id="_ref_i.11"></span><a name="_ref_i.11">[i.11]</a> EU 2025/2392 Comission implementing regulation on the technical description of the categories of important and critical products with digital elements pursuant to Regulation EU 2024/2847 (CRA)

<span id="_ref_i.12"></span><a name="_ref_i.12">[i.12]</a> ISO/IEC 27000:2018

<span id="_ref_i.13"></span><a name="_ref_i.13">[i.13]</a> NIST SP 800-63B-4 Authentication & Authenticator Management

<span id="_ref_i.14"></span><a name="_ref_i.14">[i.14]</a> prEN 40000-1-1 "Vocabulary"

<span id="_ref_i.15"></span><a name="_ref_i.15">[i.15]</a> prEN 40000-1-2 "Principles for cyber resilience"

<span id="_ref_i.16"></span><a name="_ref_i.16">[i.16]</a> Directive (EU) 2022/2555 of the European Parliament and the council and (EU) 2024/2690 European Commission implmenting regulation

<span id="_ref_i.17"></span><a name="_ref_i.17">[i.17]</a> Example source for DDoS related threat reports https://radar.cloudflare.com/reports



# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms
@@ -172,6 +206,16 @@ For the purposes of the present document, the terms given in Regulation (EU) 202

<mark>Editor’s Note: The standard should not do legal interpretation by defining some key legal concepts of Regulation (EU) 2024/2847. Notably, the standard should not define “core functionality” or “due diligence”.</mark>

1. **Operating System (OS):** software product that provides an abstract interface to the underlying hardware and that controls the execution of software
1. **Identity Provider (IDP):** system maintaining identity information
1. **Service Requesting Users (<span name="_term_.SRU">SRU</span>):** users relying on the correct functioning of the network element
1. **user:** person having the credentials to login to the NMS to operate administrative actions to control and maintain the managed element
1. **machine user:** virtual user used to access the system programming interfaces
1. **component:** software or hardware intended for integration into an electronic information system
1. **Application Programming Interface (API):** interface used to communicate with the running program
1. **log**: record of an operational event
1. **trace**: record of a system status with all relevant data that can be gathered

## 3.2 Symbols

<mark> Editor's Note: choose one of the three following lines, whichever applies most appropriately. Replace ... with your reference.</mark>
@@ -242,6 +286,24 @@ For the purposes of the present document, the abbreviations given in ... and the
`VPN   Virtual Private Network`
`XDR   Extended Detection and Response`

`ABAC   Attribute-Based Access Control`
`CRA    Cyber Resilience Act`
`OS     Operating System`
`IDP    Identity Provider`
`VPN    Virtual Private Network`
`SIEM   Security Information and Event Management Systems`
`NMS    Network Management System`
`2FA    Two Factor Authentication`
`CSP    Communication System Provider`
`SDN    Software Defined Networks`
`GUI    Graphical User Interface`
`NE     Network Element`
`MDM    Mobile Device Management`
`IAM    Identity and Access Management`
`OCI    Open Container Initiative`
`SRU    Service Requesting Users`
`PII    Personally Identifiable Information`

# 4 Product context

The product context for network managment systems is detailed in the following clause. Product context is descriptive, and clause 4 does not contain normative requirements.
@@ -265,6 +327,22 @@ The information below offers an overview of NMS within the scope of this standar

<mark>Editor’s Note: Configuration functionality is equally in scope.</mark>

Following list of essential functions keep the NMS self-secure and correct functioning during its operation in its intended environment.

-   Network element configuration and change management
-   The NMS will use the appropriate level of access control to maintain identity and actions each system actor can take
-   Collection and evaluation of performance metrics to support monitoring of network operation.
-   Fault detection, reaction and recovery from fail state
-   Functional resilience in terms of maintaining correct operation under abnormal network conditions, e.g., connection loss to managed elements.
-   Functional resilience in the event of
    1.   loss of connectivity to managed elements
    1.   loss of required supporting network services such as time synchronization or backup services
    1.   or loss of power.
-   Dynamic routing and switching control based on requests. Used extensively with Software Defined Networks.
-   Device discovery, inventory building and depending on the use case topology map generation.
-   Produce logs and traces for security and operational analysis


## 4.2 Product Architecture

<mark>Editor’s Note: This clause shall depict reference architectural patterns of products in this category, focusing on the architecture of the product itself and not the product as part of its operational environment or a larger ecosystem. The goal is to clearly indicate components, RDPS and their inter-relationships.</mark>
@@ -440,7 +518,6 @@ Authorisation is provided by proximity and a user with physical access becomes t
This does not mean that every access channel should provide authorisation with physical access.
A managed device can have a configuration port, a management API, a firmware update channel, and even a debugging interface, all of them classified as privileged and requiring complex authorisation depending on the device, and its use.


## 4.4 Distribution of Security Functions

<mark>Editor's Note: The clause should explain how the security functions are distributed among the product and its environment, referencing as appropriate elements of the operational environment defined in prior clauses. This analysis is not limited to which security functions products expect to get but should also explain which functions they themselves provide.</mark>
@@ -454,6 +531,26 @@ The NMS documentation shall clarify whether a security requirement is
1. where it relies on support from external services and
1. to which extent it is dependent on an external service.

### 4.4.1 External security functions, not in scope of the present document

The following cybersecurity functionalities can be handled from components outside the product:

-   From external provided updates on secured channels that the product uses to update the managed managed elements and also itself.
-   **Identity management systems** that provide mechanisms for identification and authentication. The system can include also the lifecycle management for identity credentials [\[i.2\]](#_ref_i.2)
-   **Virtual Private Network** providing access to a physical or virtual established network of managed devices that have strictly controlled access to authorised functions of the product. [\[i.3\]](#_ref_i.3) [\[i.4\]](#_ref_i.4)
-   **Provision of cryptographic keys** coming from a public key infrastructure or other key management system for services of key generation, provision, establishment, and for certificate services such as generation, signing, verification, validation or withdrawal. [\[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 product features [\[i.7\]](#_ref_i.7)
-   **Physical and virtual network interfaces** on the NMS-host and not used or accessed by users for the operation of the NMS.
-   **Operating systems** Operating systems that acting as abstraction layer for the hardware system(s) that host the product and are else not involved in the internal functioning. [\[i.5\]](#_ref_i.5)
-   **Managed devices** Managed devices, including those that are managed by the product, such as routers, modems and switches. [\[i.8\]](#_ref_i.8)

Furthermore, it is essential to detail the generation and establishment of the trust relations between the NMS and the essential external services and systems.

### 4.4.2 Security functions provided to other products

The NMS shall provide the reliable availability of the operative network, while keeping control and providing traffic meta data and metrics for the administrator for verification of the correct network operation.
Example: A listed managed element in the NMS can be enriched with traffic meta data. For example, and inconclusive, when and with what performance there was relevant traffic throughput, when/from/to there was a managed element traffic overload, received failure reporting or similar.

## 4.5 Users

<mark>Editor's Note: Some common definition of user categories are proposed in clause 3.1 above for consistency across vertical standards. Users can include both integrators and end users (individual or group / consumer or organisation), as well as users with privileged rights or professional training such as administrators. Users can be professional users or consumers and may have different levels of cybersecurity knowledge. Both professional and less experienced users may also have disabilities and may be using assistive technology to access the product. In addition, where a product is used in a public space there may be indirect users who are impacted by the device and whose cybersecurity needs should be considered.</mark>