@@ -300,12 +300,11 @@ More about assets in [Annex C.1 Assets](#c1-assets) and [Annex C.2 Data](#c11-da
This list of use cases is an informative resource for manufacturers to simplify the selection of a set of security requirements. Each use case is mapped to a security profile, which is a collection of risks and the security requirements necessary to mitigate them.
Manufacturers shall declare the security profile for which their products are intended to be evaluated.
Manufacturers shall declare in the technical documentation security profile for which their products are intended to be evaluated.
As the technical definition of an NMS describes the product as a system [Section 1.2](#12-products-in-scope) with connected elements, such as routers, an NMS is an aggregate product.
Aggregate product can have components, like an OS and ~~virtual~~ networking interfaces, which are evaluated outside of the scope of this standard.
Aggregate product can have components, like OS and networking interfaces, which are evaluated outside of the scope of this standard. More boundaries are listed in the [C3 Assumptions](#c3-assumptions).
Manufacturers shall be responsible for implementing all security measures, regardless of the subcomponents in use.
### 4.4.1 Distributed deployment
@@ -330,11 +329,23 @@ The affected Service Requesting Users base is small like in:
IoT networks main focus is often data collection.
The hadware device can store pre-installed keys, that can be used to
initialize the mutual authentication and authorization between the device and the supporting infrastructure.
IoT networks main focus is often data collection. The collected metrics are often displayed for the end-user and there can be automation, that trickers events based on discovered anomalities in the received data set. The device has limited computational capasity, and consumes a low ammount of power.
The NMS controls the configuration of the device. In minimum, the NMS maintains an inventory of devices that are part of the managed network, and establishes a trust foundation, that is used in other parts of the IoT application design.
The NMS controlling the devices may act as a sink for the collected data or define some other endpoint or mechanism for the data collection. The confidentiality of the transmitted data is protected with state of the art mechanisms for encryption.
If the device capabilities allow, the NMS can offer a remote access for the network administrator.
The hadware device can store pre-installed keys, identies, unique serial numbers, that can be used to initialize the mutual authentication and authorization between the device and the supporting infrastructure.
This key initiliasation can be also done with physical access or with proximity to the IoT device. User can pair the device the device with for the NMS with Bluetooth or with a cable connection establishing the trust foundation used in the operation.
With the established trust foundation, NMS can provision changes to the configuration, and provide signed updates to the device runtime. Depending on the sytem design, the device can pull the configuration the NMS, or the NMS can use provisioned remote connectivity and push the configuration to the device.
Inventory of network devices is maintained in the system. New devices can be attached to the inventory, and the NMS has status information about the IoT device connetivity.
When the IoT device business logic user or the IoT device interracts with the system, the system ensures protection from unauthorised access by appropriate control mechanisms and reports possible unauthorised accesses.
This example architecture can be used as a base when manufacturer demonstrates compatibility to CRA's <ahref="_ref_i.1">[i.1]</a> Annex I part 1 appropriate level of cybersecurity.
User can pair the device to own account, and see the device listed in the application.
