@@ -244,27 +244,68 @@ The affected Service Requesting Users base is small like in:
**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 buisness 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.
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.
The NMS controls the configuration of the connected devices, and has a two minimum functions:
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.
1. Establishes and maintains a trust-based relation between itself and the devices.
Beyond collecting data from connected devices and preparing data metrics, the NMS controls the configuration of the connected devices, providing two minimum security functions:
To initialize a trust-based relationship between this type of network managment system and connected devices, both of which store credentials, usually in the form of pre-installed keys, identity confirming certificates, or unique serial numbers. These credentials are used during initialisation to create the trusted relationship between the NMS, the devices and, if present, with the IoT device business logic. Credential or key initialisation, and key enrollement or establishment limit the NMS's ability to establish a trusted relationship to the intended devices, an ability further limited as these methods require physical access or close proximity to the IoT device. For example, an IoT devicve user can pair the IoT device and establish a trust-based relationship with the NMS through Bluetooth (tm) mechanisms or with a physical cable connection.
1. Establishes trust between the system and the devices.
2. Maintain an inventory of devices that are part of the managed network.
Once the trust-based relationship has been established, the NMS can provide cryptographically protected configuration and update services to the devices at runtime. Depending on the initial NMS and managed element configurations, the device can either request its configuration from the NMS, or the NMS can push the configuration to the device. The trust-based relationship can also provide for secured identification, authentication, and communication with other applications on a device.
##### Trust initialisation
The IoT network NMS collects the meta traffic data and management related data from networked devices, or forwards it to other systems for data collection and storage. All data transmitted from the devices to the NMS and all data transmitted from the NMS to the devices is cryptographically protected with authentication of the endpoints, and with integrity and confidentiality protection. Independent of any of the host system's capabilities, the NMS can also be remotely accessible.
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.
2. Generates and maintains an inventory of devices that are part of the managed network,
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.
The second primary function of an IoT network NMS is to generate, keep, and maintain a network inventory. This inventory holds information about the connectivity capabilities for each connected device. When new devices are added and a trust-based relationship is established with them, they extend the network and the inventory is amended.
Methods of device enrollement — execution, maintenance, and how the system responds to changes, is one of the key aspect of the NMS.
Users of the IoT device business logic or of managed elements are protected from unauthorised access when interacting with each other or with the NMS. Malicious impact on these communication channels, such as interception, interruption, or inducing data packets is detected and the system creates an event that is recorded, and if applicable, reported.
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.
The above given example architecture of figure 3 can serve as explanation help during the conformity assessment to meet CRA [\[i.1\]](#_ref_i.1) Annex I part 1.
Independent of any of the host system's capabilities, the NMS can also be remotely accessible.
> NOTE: This use case seems to focus on two security functions of IoT products, but make sno distinctions btween large and small IoT networks (with corresponding botnet risks) or products designed for higher risk environments (e.g. home "convienance" devices such as a set of speakers < home essential devices such as lighting < enterprise and industrial deployments such as warehouse or factory lighting and < hiogh risk infrastructural device/environments such as freezer units at a large scale meat storage facitility.) To me these levels of risk reprsent sub use cases and maybe lesser requirements/mitigations for low risk/impace devices? Additionally the degree of remote sertvice involved in the NMS may also create sub clasess (or potentially it could be modelled as a risk factor?)
##### 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.
