@@ -212,248 +212,6 @@ The primary function of an NMS is to monitor, configure, administer, or otherwis
More about assets in [Annex C.1 Assets](#c1-assets) and [Annex C.2 Data](#c11-data).
## 4.4 Use cases
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 to security profiles.
An NMS is a product controlling at least partially connected devices with network access. Despite its central positioning, an NMS can be an aggregate of several components, including but not limited to: end-to-end management systems, dedicated configuration management systems, or controllers for software-defined networking as described in chapter 1.2.
NMS can be composed of several components or can implement additional functions that are outside the scope of the present standards.
One example of this type of aggregate product design would an implementation where the operating system acts as abstraction layer for the system(s) that host the NMS, or the networking interfaces.
### 4.4.1 Distributed deployment
- 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
The affected Service Requesting Users base is small like in:
1. IoT network elements in a small deployment
1. Single home network deployment
#### 4.4.1.1 IoT network with monitoring data collection
**Figure 4.4.1.1-1: IoT network with monitoring data collection**
An IoT network is a network of devices, each of which almost always has limited computational capabilities and consumes a low amount of power.
The exact purpose of these device varies, but they are all connected to an NMS, and often to each other and to an IoT business logic, which may be a RDPS.
The main focus of an IoT network is almost always data collection, and the NMS in this use case usually visualises the collected data metrics and provides them to the end-user.
The NMS-analysis of the data metrics can be automated, including triggering warnings, alarms, or even taking actions based on discovered abnormal events.
The IoT NMS also collects the meta traffic data and management related data from networked devices, and sometimes forwards it to other systems for processing and storage.
It is not uncommon that the business logic and the NMS in this use case are offered together as a single product, providing a full networking ecosystem.
Even when data collection is the main focus of an IoT network, the network and NMS functions of this use case are not limited is not limited to it.
An IoT network NMS also usually visualises the collected data metrics and provides them to the end-user while offering users ways to make actions based on the data provided.
The NMS analysis of collected metrics can also be automated, including triggering warnings and alarms. In some implementations the NMS may even take actions based on its discovery of abnormal events.
Beyond collecting data from connected devices and preparing data metrics, the NMS controls the configuration of the connected devices, providing two minimum security functions:
1. Establishes trust between the system and the devices.
2. Maintain an inventory of devices that are part of the managed network.
##### 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.
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.
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 enrollement — execution, maintenance, and how the system responds to changes, is one of the key aspect of the NMS.
With trust established the NMS can provide cryptographically protected configuration and update services to the devices at the runtime.
Depending on the NMS architectural design and configuration of the managed elements, the device can either request configuration from the NMS, or the NMS can push the configuration to the device.
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.
##### Inventory management
The secondary function of an IoT network NMS can be to generate, keep, and maintain the inventory of the network.
This inventory holds information about the connectivity capabilities 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 with during a 24 hour window.
Even such a simple list requires that the NMS 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.
##### Device management
The IoT device design can be very simplistic, where the device relies on the system the push for configurations and even update the device firmware.
In the other end of the spectrum, the device can be designed to operate as autonomous agent that requires little or no input from the NMS to manage its functions and run software.
Contemporary advancements in microcontroller features and adjacent platforms used to build IoT devices blur the distinction between a simple device and a complex computation node, often reducing the description of a device as "IoT" to a branding decission from the manufacturer.
This distintion or lack of distinction, makes determining the role of the NMS in the IoT network important to understand as it determines when the device needs to be managed.
IoT devices themeselves are outside the scope of this document, but how a device's API's are designed, and how the trust is established in the connected network needs to be evaluated as a function of its NMS and within limits of this document.
##### Risk management
Key areas to understand when determining how an IoT network management system can affect customers' operations comes from the understanding how enrollment works, how isolated the control systems are, how large pools of devices are managed, and what the device is designed to do.
These variations are determined by the nature of the IoT network, meaning that the appropriate NMS may require different security features depending on the security needs of its operational environment and users as well as functions.
A home garden greenhouse monitoring system does not necessarily require as high-available operation as the freezers at a large scale meat storage facility.
RDPS outages can be mitigated by storing the collected data locally so the the centralised system can respond to the historical events later, when connectivity resumes, but this may not be appropriate for higher security implementations.
Likewise it may be appropriate for a critical infrastrtcuture facility to deploy the controllers closer to the facility, and under surveillance, to assure the highest reliability and operation quality, but this measure that would excessive for a typical enterprise implementation.
#### 4.4.1.2 Home network deployment
**Figure 4.4.1.2-1: Home network deployment**
In this use case, the network manangement system controls the user's home network of devices and often acts as a gateway or an access point providing connectivity for the user's home to outside networks, usually public. Access points are devices such as a router, switch, modem, or other wireless or wired device controlled and governed by the NMS and physically deployed to the service requesting users home.
The device can also make the upstream connection technology transparent to the user. Depending on the available infrastructure in the deployment location, connectivity can be through a variety of alternatives, including a mobile network or fiber optics network.
The NMS in this use case is most often locally installed on the device but may be running on a different device within the same network, or as a remote service, a RDPS.
The devices can actively send metrics to the NMS and can serve multiple devices in the same network. The devices can also provide supporting services like DHCP and DNS caching, but beyond such a minimum they can offer more extensive services such as remote connectivity options like VPN server depending on the product.
Meterics from the devices and other elements within the home network can be forwarded to the NMS, where the user can percieve these meterics and control the configuration of each networked device. In many deployments actual configuration control and review of metrics collected by ther NMS is achieved with an additional service or alternate piece of software, most often a browser, but sometimes is other ways, such as through a command-line interface.
### 4.4.2 Multi-user deployment
- The network connects to a broad variety and large number of devices, including single user devices and a number of distant or local other networks themseles connected to other user devices.
- Users and connected networks are usually distant and outside controlled operational environments.
- Deployment has a high number of elements.
- User base is of significant size, and the number of users and network functions affected by compromise of failure of the NMS is potentially high.
A typical enterprise or office network has multpiple service requesting users connecting simultaneously to a shared infrastructure.
Infrastructure may include multiple sites connected through a vareity of technologies, including but not limited to: public networks, dedicated routing infrastructure like IP-MPLS-tunnel, massive-scale computing and storage systems via data center (cloud systems), or third party service providers, or 5G slicing. An also office network also typically operates for long periods, developing layered history of past versions and functions.
With modern remote working expectations, enterprise networks almost always include remote connectivity options, such as VPNs, that enable remote users to connect to the office network and work with the subset of curated services through a shared intranet environment.
User identity verification, authorization, and the maintenance of a user is needed for each such intranet service or environment. This identity pool can be local for the service, shared within the same intranet, or provided as a service outside of the network context. In office environments, larger indentity pools provide redundancy, but also complicate the administration of credentials, and reduce response time when credentials are rotated, such as when they are leaked and missused.
Whyile it is possible to maintain the identities of all of available intranet services by hand, this is often impractical even with a moderate pool of users. A contemporary enterprise NMS deployment will instead rely on an Identity Provider (IdP) for most or all of its services. IdP's may be part of an NMS or seperate, decoupled from the NMS. Likewise IdP's can be implemented locally or as a remote service, including as an RDPS. In all varieties the nature of the IdP deplyed to the netowrk is relevant to this document as it is a major risk factor, especially if the NMS product does not support a relevant integration methods or IdP technique.
As the importaqace of the operational context rises, so does the level of accuracy needed to securely manage identity.
A larger enterprise has more staff, roles, job, and responsibility rotation, required services, data classes, levels of classified information, and working sites.
The increase in size and complexity contribute to increasing multiple risks that requires more elaborate management structures.
While many small businesses can perform the credential cleanup on former employees by hand, a large enterprise is likely to find this difficult, and see the value of deploying an administrator credential management service.
Additionally, entities within this context may store and work with extremely personal and sensitive data, such as a medical facility's patient records or a bank that needs to secure financial data. The type of deployment and actions of the service requesting users are not important to the NMS, except to the degree that the NMS must ensure that the system has the features, hardware, and security to match operational needs.
A telecom network resembles an enterprise network, with the obvious added complexity throughout.
The telecom NMS will handle a greater load, including more users, devices, and identities. Identity providers (IdPs) are often used to create segmentation and redundancy, and network uses its routers and switches as base sations serving thousands of users simultaneously.
Telecom networks are modlled by division into northbound and southbound abstraction levels or descriptors, where southbound describes traffic from the NMS and hardware controlled by the network. Northbound traffice comes from lower layers of the network such as routers and switches and from the applications and users. Services supporting and the telecom network, both internal and third party, are described has being eastbound or westbound, depending on the objectives of the modelled architecture. In the above figure, SIEM is an example service that is adjacent to the NMS, and is often used in modern deployments.
In telecom deployments of NMS it is common to provide an in-house Public Key Infrastructure (PKI), that declares it's own certificate authority (CA) or authorities deployed to the managed machines within the network. The number of these managed machines, number of CA's, and how the CA's are used is dependent on design of the network. Alternatively, even at telecom scale, and NMS can even provide its own certificates and form an independent and segregated trust domain.
#### 4.4.3 Alternative deployments
As the use of extremely large scale network services, or hyperscalers, becomes increasingly popular and the networked services perform an ever greater number of software functions, how we understand network structures depends on how we model their connectivity. The following two use cases in sub chapters consider such deployment and other complex deployments primarily by focusing two approaches. These complex networks can be modeled by how the functions are virtualised in the network [4.4.3.1 Logical network deployment](#4431-logical-network-deployment) or examining how much RDPS is involved in the design [4.4.3.2 Physical network deployment with RDPS](#4432-physical-network-deployment-with-rdps).
Yet, the protocols used for all network deployments remain consistent. TCP and UDP dominate the network and trasport layers in the OSI-model. DNS root servers are still trusted to point to the desired IP address and browser maintained TLS CA pools builds trust beyond that provided by the DNS.
Encryption can be applied to the transport layer, but is rarely seen as it imposes increased computational requirements, higher cost, and more complex management. Even with the emerging private networks popularised by the 5G slicing features, the transport layer rarely is fully encrypted throughout a private intranet. Only in networks that need greater intergrity assurance, does the network need to be responsible for encrypting its own traffic.
#### 4.4.3.1 Logical network deployment
Early versions of Software Defined Networking (SDN) imitated the physical network structure by replacing the real-world devices with digital counterparts. Such SDNs needed an IP subnetwork definition to provide IP addresses with a DHCP from a switch.
The Virtual Machines uses Virtual Ethernet interface (veth) to transfer information in the same way that other networks would with a physical card. The veth is connected to virtual switch, that handles ARP protocol duties, and relies the DHCP queries to the control layer.
The subnet virtual switch is connected to a virtual router acting as a gateway, enabling the virtual machine to communicate with rest of the connected infrastructure.
All of these virtual devices can be independent instances of virtual machines running OS with a linux kernel.
The virtual imitation of real world devices copies over the same design flaws that we have had for years.
Only after a few iterations of cluster based application development in scale, the network requirements have started to evolve.
The paradigm shift happens, when the application design takes more responsibility from the High-Availability and the application is already expecting faults to happen.
In a fluid, often container based, environment where computational nodes can be dropped unannounced, the application excution context vanishes without warning.
It is often expected, when cluster changes are made, the application can resume it's task only with minimal overhead and loss of progress whe it is relaunched elsewhere.
This elsewhere can be a new node added into the pool, or the old one when it rejoines the cluster after a forced reboot.
When the application changes, the network changes with it, thanks to the flexibility of SDN.
The latest network control structures are utilising low level kernel features.
While the Berkeley Packet Filter has been the stable base for linux Netfilter stack, the extended version of it(eBPF) moves the computational decission making to the kernel.
While the previous OS user level tools are now rendered useless, and the packet routing decision is done before the packet is introduced to the host OS, the eBPF implementations are often built for the cluster use.
Decission, what was previously segregated to different OSI-model layers, is now solved in a single process.
Combining eBPF and cluster application knowledge and control, the cluster becomes the NMS.
The application desribes it's needs as how much distribution it requires, what parts of the different processes can be in the same or different computational context, and even how much capasity it expects from the backend.
The eBPF can provide answer to all of the requests by partially resolving the Session layer and fully implementing the control of Transport-, Network-, Data link- and Physical-layers.
In highly interconnected cluster, where multiple sites are used to host the workloads, this means, that the virtual or physical port definition is made available only in the machine where the corresponding workload is located to.
In an optimal case, there is no need for additional firewall configuration, as the node does not simply accept traffic in for the services it is not hosting.
In reality, multiple layers of firewalling is still used to limit accidental configurations exposing services undesireably.
In theory, the database can be in Portugal, when the business logic is driven in Singaporean datacenter.
These two services are often placed into a single namespace, that often translates direclty to a IP subnet that stays fixed within the cluster.
This subnet is used in the application internal routing and communication, and does not nessearily mind where it is implemented.
The namespace and IP subnet follows seamlesly to the new datacenter location, if the application failover tolerates it and the cluster design makes it possible.
This highly abstract and fluid control scheme can host emergency services critical information, nations polling results or a non-profit organisations read-only website.
Only the implementing entitys risk apetite sets the upper limit on what this structure can be used for.
#### 4.4.3.2 Physical network deployment with RDPS
When almost everything can be software, the minimum sill remains: the user needs to have some form of User Equipment to be able to connect.
This Network Interface can be a radio in the cellphone, a WiFi Access Point in the living room, or router with SFP+ ports serving the local datacenter.
How much the network strcutrue has autonomy on control and local network routing the device has can be modeled in function of how much RDPS is involved in the design.
**Figure 4.4.3.2-1: Maximum RDPS involvement**
In figure the maximum RDPS involvement, the network design follows the hot potato design rule.
The connection is handed over for RDPS as soon as possible.
The local network is used as little as possible, and even the home office routing can take a detour through RDPS in order to provide auditable trail of how the remote working employee is using the network.
With technologies like 5G slicing, the closest point of return in respect to re-routing back to your network could be the nearest basestation or it could be the squid proxy in other side of the world.
These two scenarios results to different user experience where the latter would most likely show as slow and unresponsive service, but both are valid designs that can be deployed.
**Figure 4.4.3.2-2: Medium RDPS involvement**
Medium RDPS involvement is a common hybrid setup, where the company alrady has older assets, that are grown into the enterprise, and are kept around as there is little or no need to change the infrastructure.
Part of the network design is created with virtual assets, that could be the new IT infrastructure for the latest accuired comapany, while the still significant portion of networking assets are tied to the headquarters datacenter.
Control strucures are different, device management strategies are varying, and even the physicality can extend to multiple nations.
The balance of owned assets and bought services is often selected due to ease of deployment, while the partial reliance on headquarters datacenter offers resilience towards major outages in the connectivity.
End result might not be optimal, but often acceptable in the eyes of company risk management.
In a minimal RDPS involvement, all of the relevant infrastructure is not fulfilling the RDPS definition, and can be deployed to an underground infrastructure spannign multiple locations for example.
Interconnection between the sites is either owned, or leased from a provider.
Some links can be through dedicated IP/MPLS tunnels, while some could be implemented through public connectivity with VPN tunnels. The RDPS mainly serves only update packages to the NMS, validates licensing if needed and can collect usage statistics for product development purposes.
While system updates are critical for the product, the installation is fully idenpendent and no functionality is relying on the RDPS connectivity. The system updates can be delivered with a removable medium, if no connectivity to software repositories is available.
## 4.5 Risk Factors
To address the risks of an NMS product prior a manufacturer's placing it on the market this standard encourages the manufacturer to threat model and risk profile of the use of the product, including its foreseeable uses, and considering the interplay between:
