@@ -371,7 +371,7 @@ The ecosystem can implement the following functions:
* Device software delivery
* Key distribution
## 4.1.4 Device management
## 4.1.4 ICT device management
Supporting use-cases:
@@ -459,7 +459,9 @@ The local network devices using the connectivity are not affected by outages and
The local network does not expect to be connected to other similar remote sites.
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 management system is deployed on shared resources, the resource hierarchy, dependencies and control boundaries becomes points of interest.
@@ -482,6 +484,37 @@ For example, routing a remote site traffic through satelites can end up in a sit
Considering these and similar scenartios, it is next to impossible to verify how the underlying network is configured when the traffic exits the control region of the product. This is noted later in [REQ-GEN-4] under [General requirements](#51-general).
### 4.2.x Identifying privileged subjects
As necessary functions as identification and authorisation are, a NMS can still serve traffic without perfroming 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.
This does not mean that every access channel should provide authorisation with physical access.
A managed device can have a configuration port, a management API, a firmware update channel, and even a debugging interface, all of them classified as privileged and requiring complex authorisation depending on the device, and its use.
### 4.2.x Inventory and device management
#### 4.2.x.1 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.
#### 4.2.x.2 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.
## 4.3 Operational Environment
@@ -557,14 +590,31 @@ Therfore the operational environement requirements are redused to a single item
<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>
### 4.3.x Identifying privileged subjects
### 4.3.5 Trust initialisation
As necessary functions as identification and authorisation are, a NMS can still serve traffic without perfroming 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).
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.
Authorisation is provided by proximity and a user with physical access becomes the beneficiary of the provisioned configuration.
This does not mean that every access channel should provide authorisation with physical access.
A managed device can have a configuration port, a management API, a firmware update channel, and even a debugging interface, all of them classified as privileged and requiring complex authorisation depending on the device, and its use.
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.
### 4.3.6 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 Distribution of Security Functions
@@ -666,53 +716,6 @@ Beyond collecting data from connected devices and preparing data metrics, the NM
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.6.1.2 Home network deployment
@@ -803,9 +806,9 @@ The virtual imitation of real world devices copies over the same design flaws th
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.
In a fluid, often container based, environment where computational nodes can be dropped un-announced, the application execution 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 when it is relaunched elsewhere.
This elsewhere can be a new node added into the pool, or the old one 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.
