@@ -152,9 +152,9 @@ Network management systems (“NMS”) have been identified as “important prod
## 1.2 Products in scope
The implementing regulation <ahref="_ref_i.11">[i.11]</a> 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 recognized products, the composite product doesn't inherit all other regulations, but is evaluated only in it's own category.
The implementing regulation <ahref="#_ref_i.11">[i.11]</a> 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 recognized products, the composite product doesn't inherit all other regulations, but is evaluated only in it's own category.
The NMS is defined in the implmenting regulation <ahref="_ref_i.11">[i.11]</a> 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 somehow managed. This includes, but is not limited to, Mobilde Device Managent systems and Software Defined Networking.
The NMS is defined in the implmenting regulation <ahref="#_ref_i.11">[i.11]</a> 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 somehow managed. This includes, but is not limited to, Mobilde Device Managent 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.
@@ -198,6 +198,8 @@ The following referenced documents may be useful in implementing an ETSI deliver
-<spanid="_ref_i.9"></span><aname="_ref_i.9">[i.9]</a> ETSI EN 304 642 \"Cybersecurity Requirements for Telecommunication Systems\"
-<spanid="_ref_i.11"></span><aname="_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)
@@ -577,12 +579,12 @@ The following cybersecurity functionalities can be handled from components outsi
- From external provided updates on secured channels that the NMS uses to update the managed NEs 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 connected NEs that have strictly controlled access to authorized functions of the NMS. [\[i.3\]](#_ref_i.3)[\[i.4\]](#_ref_i.4)
-**Virtual Private Network** providing access to a physical or virtual established network of managed devices that have strictly controlled access to authorized functions of the NMS. [\[i.3\]](#_ref_i.3)[\[i.4\]](#_ref_i.4)
-**Provision of cryptographic keys** 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 NMS product features [\[i.7\]](#_ref_i.7)
-**Physical and virtual network interfaces**
-**Operating systems** Operating systems that act as abstraction layer for the hardware system(s) that host the NMS and are else not involved in the NMS internal functioning. [\[i.5\]](#_ref_i.5)
-**All connected NEs** All connected NEs including those that are managed by the NMS, such as routers, modems and switches. [\[i.8\]](#_ref_i.8)
-**Managed devicess** Managed devices, including those that are managed by the NMS, such as routers, modems and switches. [\[i.8\]](#_ref_i.8)
The manufacturers technical documentation shall describe the external services and systems that are required for the NMS operation. Furthermore, it is essential to detail the generation and establishment of the trust relations between the NMS and the essential external services and systems.
@@ -648,7 +650,7 @@ Later [Section 5.3 Risk Mitigations](#53-risk-mitigations) combines these genera
Technical requirements:
-**[REQ-TECH-0]** An network management system shall implement appropriate cryptographic libraries to allow the protection to the requirements of the forseeable use.
-**[REQ-TECH-0]** An network management system shall implement [5.2.4 State-of-the-art cryptographic libraries] to allow the protection to the requirements of the forseeable use.
-**[REQ-TECH-1]** The product is shipped without undocumented interfaces.
-**[REQ-TECH-2]** Any administrative action shall be recorded for audit purposes.
-**[REQ-TECH-3]** A secure channel is used in transport.
@@ -660,12 +662,12 @@ Technical requirements:
**Table 5.2-1: Technical cybersecurity assesments and details**
Manufacturer shall enable by default only the recommended designs that are fit for use-case. Any designs that are not fit for use-case may only be enabled after the user has been sufficiently informed of the security consequences in a manner that takes the use-case into account.
@@ -752,7 +754,53 @@ For backwards compatibility, use of other combinations of options other what is
-**[REQ-SBOM-1a]:** Unique, unambiguous, and machine-readable identification of all components and dependencies are provided in the SBOM.
-**[REQ-SBOM-1b]:** The SBOM identifier format is consistent with common vulnerability handling standards.
### 5.2.6 Remote Data Processing Systems
### 5.2.6 Role based authorisation
The identity management is a corner piece in the large puzzle of cybersecurity.
All performed authoritative actions needs to be identified. If the system fails to identify authoritative actions, or doesn't keep a track who executed the commands, the system can fall into a state of chaos. Like a void pointer without boundaries.
An identity management system provides an authentication of an user. It provides the assurance of correctness that the entity's provided information is corret.<ahref="#_ref_i.12">[i.12]</a> To have a functional authentication, the trusted source needs to be well maintained.
If the source authentication is a company internal directory, the content needs to be up to date and reflect the status of persons current access grants.
-**[REQ-AUTH-0]:** The product is integrated into a state of the art identity mangement system.
-**[REQ-AUTH-1]:** 2-factor authentication is used to confirm the identity of a natural user.
-**[REQ-AUTH-2]:** Authenticated natural users's authorization validity is no longer than a two days.
When the identity of a user is established, the system grants the user access rights based on the users role.
The system can have multiple different roles, that are tailored to the users perceived needs.
These roles can be, for example, monitoring data reader, interconnectivity admin, or just admin, if there deployment context calls for an all-powerfull superuser, and there is no real need to split the responsibility to a smaller chunks.
The identity information often comes with a group assignment, that can be matched to a role inside the system.
The Role Based Access Control design and depth is outside of the scope of this standard, but it needs to exists.
Both natural users, and machine users or eqvivalent structures needs those roles, but they are often different.
Machine can often have more exact limits on what funtions can be called. <ahref="#_ref_i.13">[i.13]</a>
The product can serve traffic, that is not meant to be identified.
A router in home often trusts that the physical access to a port is enough to identify the subscriber line.
In addition, the managed device can have a configuration port, management API, firmware update channel, or debugging access, which are classified as privileged.
-**[REQ-AUTH-3]:** RBAC design shall follow the best practices of the deployment context.
-**[REQ-AUTH-4]:** The RBAC design and application in the product shall be documented.
-**[REQ-AUTH-5]:** All privileged interfaces shall implement RBAC.
-**[REQ-AUTH-6]:** All access to administrative interfaces, control functions, and sensitive operations shall be subject to strong authentication of users, services, or integrated components.
-**[REQ-AUTH-7]:** Priviledged interfaces shall be protected with [5.2.4 State-of-the-art cryptographic libraries].
@@ -972,17 +1019,13 @@ Matching tests for these requirements are listed in [6.3.8 High availability tes
# 6 Conformity assesments and tests
> This section should not add requirements that are not already specified in 5. Requirements Specifications.
> Section shall define how the requirements in section 5 can be assessed objectively and repeatedly.
> There shall be at least one assessment per requirement, there can be more than one per requirement.
> 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 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 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)
<mark>TODO: make general</mark>
Conceptual assessment, where documentation on the products assets and external access/communication capabilities and claimed authentication mechanisms is compared with the applicability requirement’s text.
Functional completeness assessment, Verification that the claimed authentication mechanisms cover all interfaces and functions where authentication is required by the standard and the product’s use case (e.g., are all remote administration functions authenticated?).
Functional sufficiency assessment, “not necessary of a pure applicability requirement”, it is addressed in the assessment of appropriateness to evaluate whether the authentication mechanisms are adequate for their intended purpose.
## 6.1 General requirements assesments
@@ -1520,7 +1563,7 @@ Matching tests for these requirements are listed in [6.3.8 High availability tes
