Harmonised terminology to use managed element consistently

8. **log**: record of an operational event

9. **trace**: record of a system status with all relevant data that can be gathered

10. **squid proxy server**: an open-source-proxy server, often with intelligent web-caching and improvements of accelerating data transmissions combined with access controls

11. **manage element**: a physical or virtual device managed by the product

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.

Device management inherits the essential functions listed [4.1 Product functions](#41-product-functions), can implement functions listed in [4.1.3 Ecosystem management](#413-ecosystem-management), but are characterised by the following functions:

* Installed software reporting or in control in the managed device

* Installed software reporting or in control in the managed element

* Full or partial remote removal of data

* Device tracking and compliance control

* Remote control of device application features

### 4.2.1 Network architecture

The network architecture operating with the NMS is in scope of the present standard when evaluating the threats, risks and their impact on the network.

The network can be large with multiple managed devices or there can be multiple networks, with varying degrees of inter- and intra-connections.

The network can be large with multiple managed elements or there can be multiple networks, with varying degrees of inter- and intra-connections.

The product can be deployed into the network it controls, or it can be outside of the managed network.

Depending on the design, the local network can have a local controller complimenting the control of the product while providing higher availability of supporting services.

A connected network always requires at least one upstream gateway where to send packets to.

Without that at least one upstream connection in the network, it is an air-gabbed network.

The managed device functionality does not degrade, if the connectivity to the centralised command is lost.

The managed element functionality does not degrade, if the connectivity to the centralised command is lost.

The device is placed in a network that is independent and self-sufficient.

The local network devices using the connectivity are not affected by outages and the product's role is more like a convenience for the product user, rather than operational necessity.

  * Manage connected [ICT devices](#414-ict-device-management)

  * [Dynamically control](#412-software-defined-networks) the application execution environment or other connectivity

* How many devices are managed for a single product user?

* How complex are the managed devices?

* Is the managed device control complete or partial?

* How complex are the managed elements?

* Is the managed element control complete or partial?

* What is the role of services that are [implemented as RDPS](#44-distribution-of-security-functions) and therefore partially external to this document?

### 4.2.3 Applying encryption in RFC 1122

![Figure 4.8.x-1: OSI-model and RFC 1122](./media/ops_env_OSI_model.drawio.png)

A product's Service Requesting Users are often identified from the ability to communicate with the managed device in the link layer.

A product's Service Requesting Users are often identified from the ability to communicate with the managed element in the link layer.

When considering the need for encryption, it is notable that encryption is often unavailable for fixed access network protocols operating in lower levels of the networking stack.

For example, subscriber line traffic is forwarded to the network without modifying the content or wrapping the traffic with layers of encryption.

Likewise, when a managed device is a router, it can often be configured to send and receive traffic from a Virtual Private Network.

Likewise, when a managed element is a router, it can often be configured to send and receive traffic from a Virtual Private Network.

Addressing the VPN security is outside of this document.

Encryption may also be beyond the control of the manufacturer.

Authorisation is provided by proximity and a user with physical access becomes the beneficiary of the provisioned configuration.

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.

A managed element 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.2.4.3 Device management

Also the product’s shipment and delivery procedures usually follow the system users’s needs and may also need to be conformant with critical infrastructure rules and requirements.

These responsibilities can be implemented with varying degrees of third party involvement in respected layers.

Local delivery integration customisations could be also explored as an East-West integration plane, but for the purpose of this document, all integration targets, apart from the managed devices, are addressed as RDPS.

Local delivery integration customisations could be also explored as an East-West integration plane, but for the purpose of this document, all integration targets, apart from the managed elements, are addressed as RDPS.

> Example: SIEM system operation requires access grants from the product Application-layer to be able to collect information from devices in the Networking and facilities-layer.

Secure network communication needs trust establishment among the communicating entities.

The NMS initiates and establishes that trust and can operate multiple methods for this, including but not limited to: identity confirming certificates, unique serial numbers or stored credentials, usually in the form of pre-installed keys.

These methods comprise credentials assigned to each entity, and those are used during the initialization to create the trust relation between the NMS, the managed devices, and, if present, with the IoT business logic.

These methods comprise credentials assigned to each entity, and those are used during the initialization to create the trust relation between the NMS, the managed elements, and, if present, with the IoT business logic.

Secure procedures to generate and enroll the credentials enable the NMS to initialize the trust relations.

These procedures usually require physical access or proximity to the managed device, as, for instance, the human user of an IoT device can pair his device with the NMS through a wireless pairing mechanisms or with a plugged-in wired connection.

These procedures usually require physical access or proximity to the managed element, as, for instance, the human user of an IoT device can pair his device with the NMS through a wireless pairing mechanisms or with a plugged-in wired connection.

As an alternative to preconfigured devices the manufacturer may provide devices with a single DNS address that the device queries for configuration on device startup to launch a chain of events that registers the device to the correct network.

Methods of device enrollment — execution, maintenance, and how the system responds to changes, is one of the key aspects of the NMS.

On the basis of trusted relationships the NMS can provide cryptographically protected configuration and update services to the managed devices at runtime.

In dependency of the NMS capabilities and the managed devices configurations, the configuration can reach the managed element either with a pull-request to the NMS, or the NMS can push the configurations to the managed devices.

On the basis of trusted relationships the NMS can provide cryptographically protected configuration and update services to the managed elements at runtime.

In dependency of the NMS capabilities and the managed elements configurations, the configuration can reach the managed element either with a pull-request to the NMS, or the NMS can push the configurations to the managed elements.

Once configured, the same channel and trusted status is used for secured identification, authentication, and communication with other applications on a device.

Independent of any of the host system's capabilities, the NMS can also be remotely accessible.

### 4.4.2 Related core functionalities

* **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)

* **Virtual Private Network** providing access to a physical or virtual established network of managed elements that have strictly controlled access to authorised functions of the product. [\[i.3\]](#_ref_i.3) [\[i.4\]](#_ref_i.4)

* **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 act as abstraction layer for the hardware system(s) that host the product and are otherwise not involved in the internal functioning. [\[i.5\]](#_ref_i.5)

* **Managed devices** Device management system for managed elements such as, but not limited to, routers, modems, and switches. [\[i.8\]](#_ref_i.8)

* **Managed elements** Device management system for managed elements such as, but not limited to, 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.

* **SU_UPDATES-8:** If the product supports intentional rollback, invoking action shall require explicit authorisation and an auditable event is emitted with rollback metadata.

* **SU_UPDATES-9:** The product shall automatically recover from a failed update and resume operation if applicable.

* **SU_UPDATES-10:** The product shall inform the system user about update availability if applicable.

* **SU_UPDATES-11:** The product shall track the relevant component versions of the product and the managed devices if applicable.

* **SU_UPDATES-11:** The product shall track the relevant component versions of the product and the managed elements if applicable.

* **SU_UPDATES-12:** The product shall log start and finish of the update download if applicable.

* **SU_UPDATES-13:** The product shall perform an automatic update of the product and the managed devices if the operative context and the application design allows this to happen within the defined availability targets.

* **SU_UPDATES-13:** The product shall perform an automatic update of the product and the managed elements if the operative context and the application design allows this to happen within the defined availability targets.

* **SU_UPDATES-14:** Automatic updates shall be on by default if applicable.

Applying automatic updates is subject to the operative environment design.

The product can serve traffic that is not meant to be identified.

For example, an in-home router often trusts that the physical access to its 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.

In addition, the managed element can have a configuration port, management API, firmware update channel, or debugging access, which are classified as privileged.

The operative context is described in more detail in the section [4.8 Operational Environment](#48-operational-environment).

#### Identity management

* **CON_CHANNEL-1** The product shall ensure that the channel uses cryptographic functions and configuration according to the **CON_CRYPTO-1**.

* **CON_CHANNEL-2** All endpoints in a secure channel shall cryptographically verify others through mutual auhentication.

![Figure 5.7.2-1: Secure channel example with TLS originated by managed device](./media/52_secure_channel_example.drawio.png)

![Figure 5.7.2-1: Secure channel example with TLS originated by managed element](./media/52_secure_channel_example.drawio.png)

**Figure 5.7.2-1: Secure channel example with TLS**

The figure 5.7.2-1 is an illustration of a simple TLS protected communication between product and the managed device, where the device initiates the connection towards reachable endpoint based on a DNS address configured into the managed device.

The figure 5.7.2-1 is an illustration of a simple TLS protected communication between product and the managed element, where the device initiates the connection towards reachable endpoint based on a DNS address configured into the managed element.

The device validates the provided public certificate and logs in with machine credentials.

NMS authorises the query based on the role and identity of the device.

Conformity with this clause does not require use of DNS, TLS, certificate-based authentication, where equivalent security outcomes are achieved by other means appropriate to the product design and foreseeable use.

Other approaches are possible, including where the product is responsible for initiating the TLS connection towards the managed device and logging into the managed device.

In this case, the managed device is responsible for authorizing the product based on the identity of the product.

Other approaches are possible, including where the product is responsible for initiating the TLS connection towards the managed element and logging into the managed element.

In this case, the managed element is responsible for authorizing the product based on the identity of the product.

## 5.8 Integrity protection

### 5.8.1 Configuration integrity

* **INT_CONF-2** Where the product distributes or makes available configuration to managed devices the product shall ensure that

* **INT_CONF-2** Where the product distributes or makes available configuration to managed elements the product shall ensure that

  * the configuration is protected against unauthorized modification and disclosure;

  * only the intended managed device can obtain the relevant configuration;

  * only the intended managed element can obtain the relevant configuration;

  * the device can verify the integrity of the configuration.

* **INT_CONF-3** The configuration interfacing design shall enable the managed device to cryptographically verify the authenticity of the product.

* **INT_CONF-3** The configuration interfacing design shall enable the managed element to cryptographically verify the authenticity of the product.

### 5.8.2 Cryptographic key intialisation and rotation

Modern design is often distributed, but depending on the implementation and runtime context, a singular process can also provide the targeted service availability, if the process was implemented correctly, and a self-healing system can launch a replacement within a given time window.

Following general risks apply if the NMS can be reached by a DDoS attack: For an NMS in large deployment scenarios, e.g. telecom or enterprise use cases, a DDoS is not practical due to the physical separation of payload network and management network.

An attacker would need to physically access a high number of the managed devices, manipulate them, build a bridge to the management network, and be able to orchestrate then DDoS on the NMS.

An attacker would need to physically access a high number of the managed elements, manipulate them, build a bridge to the management network, and be able to orchestrate then DDoS on the NMS.

As this is considered not practical in real scenarios, such an NMS itself will not be affected by DDoS.

Of course, such NMS are able to detect DDoS scenarios on its managed devices.

NMS in these large scenarios are usually also part of the DDoS defense means: The NMS gets input from defense systems and executes then mitigating configurations on the managed devices affected by the DDoS attack.

Of course, such NMS are able to detect DDoS scenarios on its managed elements.

NMS in these large scenarios are usually also part of the DDoS defense means: The NMS gets input from defense systems and executes then mitigating configurations on the managed elements affected by the DDoS attack.

In these scenarios and for the CRA conformity, the NMS manufacturer can argue: a DDoS is not applicable.

For other scenarios, where the NMS itself can be affected by DDoS, the NMS may cease services for a configurable timeframe, apply predefined mitigation means, such as a reset, and return then to normal operation.

  * policy changes

  * credential changes

  * events described by [5.5 Security updates](#55-security-updates)

  * installation successes and failures in the managed devices, if that information can be extracted from the targets

  * installation successes and failures in the managed elements, if that information can be extracted from the targets

  * installation successes and failures in the product itself.

* **MON_LOG-7** The product shall log boot or initialisation events including but not limited to:

  * timestamped boot stage progression

**Verdict:**

1. Pass, all tests pass without issues

2. and keys are replaced with provided ones in the managed device.

2. and keys are replaced with provided ones in the managed element.

3. Fail otherwise.

**Supporting Evidence:**

**Activities:**

1.  Set a node or a system to a wrong time that is off by at leat an hour;

2.  Set a managed device or connected service to a wrong time that deviates from real time by at least one hour.

2.  Set a managed element or connected service to a wrong time that deviates from real time by at least one hour.

**Verdict:**

**Verdict:**

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

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

2. Fail otherwise.

**Supporting Evidence:**

#### 6.14.1.5 MON_LOG-5

**Objective:** Make it possible to systemically analyse managed device behavior.<br/>

**Objective:** Make it possible to systemically analyse managed element behavior.<br/>

**Preparation:**

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

1. Have the product initialised and available with the default configuration;

2. Create required authentication credentials for the test;

3. Prepare an import data set that represents normal operational metric data from a managed device;

3. Prepare an import data set that represents normal operational metric data from a managed element;

4. Create a copy of the import data set and modify the data to change also related integrity protection values.

**Activities:**

3. and if the connection loss to the managed element is recognized

4. and if by observing the metrics a baseline of the system operation can be established

5. and if anomalities like load spikes after a restart can be observed

6. and if the product detects and displays or reports the test event on the managed device

7. and if the product monitoring data shows the expected operation statuses where applicable for both, the product and for the managed devices:

6. and if the product detects and displays or reports the test event on the managed element

7. and if the product monitoring data shows the expected operation statuses where applicable for both, the product and for the managed elements:

    * success rate

    * operation failure rate

    * query execution time

- Managed network includes multiple interconnected sites

risk **impact** is **low**, if:

- Managed devices have limited capabilities

- managed elements have limited capabilities

- The product uses idempotent design

**impact** is **high**, if: