Commit 8e9c2e2e authored by August Bournique's avatar August Bournique
Browse files

Edited IoT use case for flow and English grammar.

Following our April 22, 2026 discussion I believe that this sort of use case definition, while general and long already implies/includes multiple similar use cases in its last paragraph.  While it seems problematic to have a large number of use cases on only the IoT general use case, and the definition makes clear that there will be several risk factors involved (including the RDPS implementation in the deployment), it strikes me that we can break this down into "home greenhouse" (amount/risk of RDPS minimally important, size tiny, complexity minimal, and data transferred/functions performed  general/not valuable), industrial facility (RDPS significant, size medium, complexity medium, data/functions important) and finally critical infrastructure (RDPS risk to be eliminated/minimized, size small/medium, complexity medium, and data/function critical.  
parent 976df377
Loading
Loading
Loading
Loading
+23 −27
Original line number Diff line number Diff line
@@ -248,34 +248,33 @@ An IoT network is a network of devices, each of which almost always has limited
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.
It is not uncommon that the business logic and the NMS for the purpose of this document is offered as a full ecosystem.
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 main focus of an IoT network can be, but is not limited to, data collection.
The NMS in this use case usually visualises the collected data metrics and provides them to the end-user and provides a way to make actions based on the data.
The NMS analysis of the collected metrics can be automated, including triggering warnings, alarms, or even taking actions based on discovered abnormal events.
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.

The NMS controls the configuration of the connected devices, and has often two minimum functions:
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 a trust between actors in this type of NMS and connected devices multiple different methods can be used like: stored credentials, usually in the form of pre-installed keys, identity confirming certificates, or unique serial numbers for example.
These credentials can be used during initialisation to create the trust 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 trust between the intended devices, an ability is further limited if these methods require physical access or close proximity to the IoT device.
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.

Alternatively to preconfigured devices, the manufacturer may install only a single DNS address, that is queried for configuration on the device startup launching a chain of events, that registers the device to a correct 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.

How this new device enrolment is excuted, maintained and how the system responds to changes, is one of the key aspect of the the product.
Methods of device enrollement  execution, maintenance, and how the system responds to changes, is one of the key aspect of the NMS.

Once the trust has been established, the NMS can provide cryptographically protected configuration and update services to the devices at the runtime.
Depending on the NMS architectural design and managed element configurations, the device can either request its configuration from the NMS, or the NMS can push the configuration to the device.
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 established trust may be used for secured identification, authentication, and communication with other applications on a device.

The IoT NMS collects the meta traffic data and management related data from networked devices, or forwards it to other systems for processing and storage.
Independent of any of the host system's capabilities, the NMS can also be remotely accessible.

##### Inventory management
@@ -285,28 +284,25 @@ This inventory holds information about the connectivity capabilities for each ne
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 for example a list of devices communicated within 24 hour rolling window.
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.

Care needs to be administered, when a device needs to be taken out of the network.
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 be able to manage its functions and the running software.
The advancements in the microcontroller features and adjacent platforms used to build IoT devices blurs the line between a simple device and a complex computation node, the IoT remains to be a branding decission from the manufacturer.
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.

What is the role of the NMS in the IoT network is important to understand when the device expects to be managed.
The devices are outside of this document, but how the provided API's are designed, and how the trust is established in the connected network needs to be evaluated within limits of this document.
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 how an IoT network management system can affect the customers operations comes from the understanding how the enrollment works, how isolated the control systems are, how large pools of devices are managed, and what the device is designed to do.

A home garden greenhouse monitoring system does not necessarily require as high-available operation as the freezers at a large scale meat storage facility.
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.

The RDPS outages can be mitigated by storing the collected data locally for longer, so the centralised system can respond to the historical events later, when the connectivity resumes.
It might be adecuate for a critical facility to deploy the controllers closer to the facility under surveilance, if the highest reliability and operation quality is to be assumed.
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