Added controller design and cleaned up network architecture

**Figure 4.3-1: Product overview and architecture**

Network management systems are operated by users or by programs that interface with an API. These programs can be internal or external to the system depending on the product design and deployment context.

Network management systems are operated by system users or by applications that interface with an API.

These programs can be internal or external to the system depending on the product design and deployment context.

The system is often accessed with a browser using an identity outside of the installation context.

Identity Provider (IdP) can be used as base for the users identity.

The Operating System can be part of the deliverable and hense, part of the product.

The OS best practices and requirements are defined outside of this document.

Where relevant to the deployment context, the NMS may interface with external services such as identity, cryptographic, logging, or event management systems, though cybersecurity requirements of these systems, even if integrated into the NMS product, are not addressed by this standard.

Where relevant to the deployment context, the product may interface with external services such as identity, cryptographic, logging, or event management systems, though cybersecurity requirements of these systems, even if integrated into the product, are not addressed by this standard.

The primary function of an NMS is to monitor, configure, administer, or otherwise manage connected network elements.

The primary function of the product is to monitor, configure, administer, or otherwise manage connected network elements.

More about assets in [Annex C.1 Assets](#c1-assets) and [Annex C.2 Data](#c11-data).

### 4.2.x Distributed element and deployment design

### 4.2.1 Network architecture

>Distributed element design

>

>Editor's Note: Unclear and to discuss: what is distributed and where? Are elements also outside a defined operational environment? If so then further security requirements apply.

What kind of network architecture is designed and deployed with the product are interests of this document when evaluating the risk likelihood and impact.

The network can be large with multiple managed devices 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.

-   Distributed element design

-   Insignificant amount of interconnectivity within the network elements

-   Lesser importance by the type of the controlled managed elements in their functionality and role in the deployment context

-   Isolated management system design

-   Pocket deployments with high independency

![Network distribution design](./media/distributed_deployment.drawio.png)

Devices are limited in functionality like:

When evaluating the product deployment operational environment risks, the network architecture, the product design and the product functionality needs to be understood.

Physicality of the product deployment is adressed later in [4.3 Operational environment](#43-operational-environment).

1. Simple low-risk embedded device (coffee machine, fridge)

2. Stationary IoT embedded device (lightbulb, thermostat)

#### 4.2.1.x Controller design

The affected Service Requesting Users base is small like in:

The product is a network controller.

The different user roles are defined later in [4.5 Users](#45-users).

1. IoT network elements in a small deployment

1. Single home network deployment

When deployed into the operational envrionment, the product has a varying degree of inter- and intra-dependencies.

Dependencies can be implemented as Remote Data Processing Solutions [RDPS] which are defined in more detial in the [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) in combination of the related [4.6 Use-cases](#46-use-cases).

![Network distribution design](./media/distributed_deployment.drawio.png)

All of the following affects the risk likeliness and impact:

* How the product is hosted?

  * SaaS, IaaS, PaaS

  * Dedicated infrastructure

    * In cloud

    * On-premises

  * The product is a physical device

* How many product users a single product deployment controls? (system isoloation)

  * Single product user

  * Multiple product users

* What is the product main function?

  * Provide connectivity to Service Requesting Users by [managing the network functions](#411-network-functions-management)

  * [Control the ecosystem](#413-ecosystem-management) by providing configuration to application workloads

  * 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 the managed devices are?

* Is the managed device control complete or partial?

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

#### 4.2.1.x Devices using provided connectivity

Relying on provided connectivity is more common for devices that are part of some [ecosystem](#413-ecosystem-management) where the main function of the device is not to serve Service Requesting Users with connectivity, but to provide the user higher level application features.

The product control therefore does not extent to the surrounding network.

Part of the initialisation of the device is to configure local network access for example when wireless access is used.

The devices can be like:

When evaluating the system deployment risks, the product design and functionality needs to be understood.

1. Simple embedded device (coffee machine, fridge, toaster, lightbulb, thermostat)

2. Commercial system monitors (fridge temperature)

3. Entertainment devices (streaming devices, game consoles)

### 4.2.x Pocket deployment

#### 4.2.1.x Pocket deployment

A pocket deployment is a structure, where the managed device functionality does not degrade, if the connectivity to the centralised command is lost.

A pocket deployment is a special combination of design criteria, where the product serves single product user and the interconnectivity of the network is minimal.

Connected network requires always 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 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 convinience for the user, rather than operational nessecity.

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

The local network does not expect to be connected to other similar remote sites.

It's inter-connectivy requirements are low.

The network user might have VPN services enabled, but expectation is to be connected only to the isolated environment of own home for example.

When a single device is compromised, the exposure is limited to the devices in that small network.

The network is not fully isolated or air-gapped.

When a single device is compromised, the exposure is limited to the devices in that same network.

When management system is deployed on shared resources, the resource hierarchy, dependencies and control boundaries becomes points of interest.

### 4.2.x Applying encryption in RFC 1122

### 4.2.2 Applying encryption in RFC 1122

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

### 4.2.x Inventory and device management

#### 4.2.x.1 Inventory management

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

### 4.3.1 General description

The product is system that interacts with other systems, devices and system users.

### 4.3.2 Physical/Hardware environment

<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>

### 4.3.5 Trust initialisation

To initialize trust between the elements of the IoT network, this type of NMS multiple can use multiple methods including but not limited to: identity confirming certificates, unique serial numbers, or stored credentials, usually in the form of pre-installed keys.

To initialize trust between the elements of the network, this type of NMS multiple can use multiple methods including but not limited to: identity confirming certificates, unique serial numbers, or stored credentials, usually in the form of pre-installed keys.

These credentials are used during initialisation to create the trust between the NMS, the networked devices and, if present, with the IoT device business logic.

Credential or key initialisation and enrollement limit the NMS's ability to establish trust between the intended devices, as does any requirement for physical access or close proximity to the IoT device to perform these actions.

For example, an IoT device user can pair the IoT device and establish a trust with the NMS through Bluetooth(tm) pairing mechanisms or with a physical cable connection.

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

An NMS can be formed by a compilation or collaboration of different subsystems in a local distance but within the same management network and within the equal operational environment.

The security functions may be implemented inside one or more of the subsystems that form the NMS. The NMS can thereby be operated by an OS package manager or other systems which also belong to the NMS and are in scope of the present standard.

The security functions may be implemented inside one or more of the subsystems that form the NMS.

The NMS can thereby be operated by an OS package manager or other systems which also belong to the NMS and are in scope of the present standard.

The NMS documentation shall clarify whether a security requirement is

The NMS documentation shall clarify whether a security requirement is <mark>Note: move this shall to chapter 5</mark>

1. completed fulfilled by the NMS itself,

1. where it relies on support from external services and

NSM can provide the following services to 3rd. party applications and for the connected devices:

* Access to the collected data sets; raw or enriched.

* PKI for the devices acting as Certificate Authority [CA]

* Access credentials and authorisation to the connected devices

* PKI services for the devices acting as Certificate Authority [CA]

* Access credentials and authorisation to the connected devices and system users

* Proxy gateway connectivity to the connected devices

* Mechanism to interract with the connected devices directly or indirectly

<mark>Editor’s Note: Use cases may include the case of critical infrastructure but shall refrain from an explicit link to the NIS 2 Directive.</mark>

This list of use cases is a resource for manufacturers to simplify the selection of a set of cybersecurity requirements.

Manufacturer's technical documentation may benefit from including or refering to these use cases and associated security profiles.