Changed the term NSM to the product

#### 4.2.4.1 Identifying privileged subjects

As necessary functions as identification and authorisation are, a NMS can still serve traffic without performing an identification routine as long as that traffic is authorised in another way.

As necessary functions as identification and authorisation are, the product can still serve traffic without performing an identification routine as long as that traffic is authorised in another way.

For example, residential routers are often configured in a way that physical access to a local port is sufficient to identify a Service Requesting User (SRU).

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

#### 4.2.4.3 Device management

The connected device’s design can be simple if there is support by the NMS with pushed configuration and firmware update services.

On the other end of the spectrum, the device can be designed to operate as an autonomous agent that requires little or no input from the NMS to manage its functions to run the workload.

The connected device’s design can be simple if there is support by the product with pushed configuration and firmware update services.

On the other end of the spectrum, the device can be designed to operate as an autonomous agent that requires little or no input from the product to manage its functions to run the workload.

The NMS receives its definition through the management needs of the connected devices.

The connected devices are outside the scope of the present document, but the NMS APIs communicating with them are included.

The product receives its definition through the management needs of the connected devices.

The connected devices are outside the scope of the present document, but the product APIs communicating with them are included.

This communication needs a trusted relation which needs to be established and maintained to ensure operational network security.

This trust establishment with the connected elements is a core part of the NMS.

This trust establishment with the connected elements is a core part of the product.

#### 4.2.4.2 Inventory management

The function of a NMS can be to generate, keep, and maintain the inventory of the network.

The function of the product can be to generate, keep, and maintain the inventory of the network.

This inventory holds information about the connectivity, capabilities, and some form of mutual authentication for each networked device.

When new devices are added and a trust is established, the new device extends the network and the inventory is amended.

Managing an accurate inventory is not always needed.

Depending on the business logic, and the purpose of the network, the inventory can be a rolling list of devices the network has communicated during a 24 hour window for example.

Even such a simple list requires that the NMS exercise care when devices are removed from the network.

Even such a simple list requires that the product exercise care when devices are removed from the network.

When a rogue device is identified, it is important to be able to isolate the device, and mitigate the potential impact of its actions.

## 4.3 Operational Environment

#### 4.3.4.4 Trust initialisation

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 elements, and, if present, with the IoT business logic.

The product 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 product, 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 element, as, for instance, the human user of an IoT device can pair his device with the NMS through a wireless pairing mechanism or with a plugged-in wired connection.

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

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 product through a wireless pairing mechanism 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.

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

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.

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

In dependency of the product capabilities and the managed elements configurations, the configuration can reach the managed element either with a pull-request to the product, or the product 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.

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

#### 4.3.4.5 Risk management

The risk management is always use case dependent, and thus dependent on the actual conditions and operational environment.

Therefore, it is essential to understand how an NMS can impact a network operation in its key areas.

Therefore, it is essential to understand how the product can impact a network operation in its key areas.

A not conclusive list as examples are: enrollment of network elements, trust relationships, isolation of control systems, management and depth of management of network element pools.

The relevant areas are determined by the network purpose and the resulting security requirements in relation to the provisions of the operational environment and users.

For illustration, a managed home garden greenhouse monitoring system does not usually have similar high-availability requirements as the managed surveillance systems of an industrial mass production facility.

If RDPS is deployed, outages thereof can - in the home garden case - easily be mitigated by local data storage so that the NMS can retrieve collected data at a later stage when the RDPS resumes.

If RDPS is deployed, outages thereof can - in the home garden case - easily be mitigated by local data storage so that the product can retrieve collected data at a later stage when the RDPS resumes.

This would not be appropriate for the critical infrastructure.

Here the RDPS needs more resilience, for example with redundancy and operation in proximity to the facility and the possibility for quick manual interactions.

Such measures are typically subject for an enterprise use case.

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 a 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.

The product 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.

It is up to the software design whether or not such interruptions can be tolerated.

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 elements, manipulate them, build a bridge to the management network, and be able to orchestrate 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 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.

Following general risks apply if the product can be reached by a DDoS attack: For the product 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 elements, manipulate them, build a bridge to the management network, and be able to orchestrate DDoS on the product.

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

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

The product in these large scenarios are usually also part of the DDoS defense means: The product 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 product 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.

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

Most DDoS scenarios last less than 10 minutes.

However, such an event needs to be notified, reported and logged.

Of course, for forensic analysis of this event, i.e. to identify the source of DDoS orchestration, sources of the flooding etc., a logging of all available data about this event is required.

1. Output samples showing how the information is conveyed for the user.

> NOTE: Whether a modified data set gets accepted or discarded might not be an NMS but an administrator decision.

> NOTE: Whether a modified data set gets accepted or discarded might not be the product's but an administrator decision.

#### 6.14.2.4 MON_METRICS-4