NIST recommends: building blocks for describing IoT

→ Source

In July 2016, on the National Institute of Standards and Technology (NIST) website, as usual, in the public domain, a new publication NIST Special Publication 800-183, Networks of 'Things', appeared . This document was released in the SP 800 series , Computer Security , which implies its direct relation to information security. However, NIST SP 800-183 focuses primarily on design notation and IoT architecture descriptions.

I decided to deal with the content of this document, since NIST produces more than solid guidelines, including, for example, the world-famous NIST SP 800-53, the NIST SP 800-82, Guide to Industrial Control Systems (ICS) Security and more.
')
Moreover, the author of NIST SP 800-183 is Jeffrey Voas , known since the early 1990s. publications on the theory of evaluation and software testing.

According to the Internet of Things Reference Architecture (IoT-RA) , the IoT Device Layer layer implements the functions of monitoring and managing processes and objects of the real world, including data acquisition from sensors (sensing), information processing (computing), information transfer (communication), and issuing commands to actuators (actuation). In NIST SP 800-183, the term “Network of Things (NoT)” is used because “things” can be networked but not connected to the Internet.

NIST SP 800-183 says that a unique approach is proposed in the IoT description. Five types of primitives are used for this: 1) Sensor , 2) Aggregator , 3) Communication Channel , 4) External Utility (eUtility) , 5) Decision Trigger .

All of them are shown in the title picture, which is an illustration of NIST SP 800-183.

Primitive # 1: Sensor
Sensor is a sensor designed to measure physical parameters (temperature, humidity, pressure, acceleration, etc.).

Primitive # 2: Aggregator
Sensor transmits information to the Aggregator , which is a software implementation of functions (possibly using artificial intelligence) that turn raw data into intermediate aggregate data. For Aggregator , the concepts of actor (Actor) of data processing of two types are introduced: Cluster & Weight . By Cluster is meant a virtual dynamic Cluster of Sensors , which is organized and changes depending on the approach to data aggregation. By Weight is meant a weighting factor (also, possibly, a dynamic one), which is used to process data using the Aggregator .

Primitive # 3: Communication Channel
Communication Channel is a virtual or physical medium that unites all other primitives.

Primitive # 4: eUtility (External Utility)
By eUtility is meant any hardware device, program or service that is a platform for running the Aggregator . In the future, it is intended to concretize this primitive, highlighting several categories.

Primitive # 5: Decision Trigger
Decision Trigger forms the final result necessary to perform the objective function of a specific IoT-based system (NoT).

Next, NIST SP 800-183 details the properties of the primitives, which, for brevity, can be omitted.

To supplement the IoT (NoT) model, six properties are introduced (the term elements are used in publications): Environment , Cost , Geographic Location , Owner , Device_ID , Snapshot . It is understood that these properties affect the assurance (trustworthiness) of the system.

1. Environment - the physical environment of operation of IoT devices (NoT).
2. Cost - the cost, it is the cost.
3. Geographic Location - the geographic location of the physical device.
4. Owner - the physical or legal owner of the primitive; this property also includes the role of the operator.
5. Device_ID - unique identifier of the primitive.
6. Snapshot - time slice of the system, which determines, among other things, the approach to synchronization.

The publication also provides examples related to the provision and violation of the properties of reliability (reliability) and information security (security) for primitives. In my opinion, these examples are not very representative.

Conclusions: what does it give?
In NIST SP 800-183 I liked the universal approach to the description of the IoT design in the form of semi-formal notation. In essence, this is a step towards the standardization of the reference architecture (IoT-RA) at the Device Layer level. Such a description can be an input for the development of an appropriate CAD tool. Perhaps such software is already being developed, but for now, existing editors (for example, MS Visio) can be used to form the IoT specification.

Alarming is, of course, the lack of more complex examples and application information for real projects. Obviously, such information may appear in the future.

In addition, if you dig a little more, you can get a good device for analyzing scenarios for using systems based on IoT (use case scenarios) and, accordingly, for analyzing risks associated with providing properties such as trustworthiness, information security (security ) and dependability. Regarding the latter property, in my opinion, the author “didn’t screw up”, because the term “reliability” is used in NIST SP 800-183, which, although sometimes interpreted as “reliability,” nevertheless means “reliability”, t . the ability to continuously maintain a healthy state for some time (operating time). For IoT, as for other complex systems, it is more appropriate to provide the property "dependability", i.e. reliability in the broad sense, which is described, as a rule, by a set of properties of RAMS (reliability - reliability, availability - availability, maintainability - maintainability, safety - safety).
I also did not find anywhere in the publication an explicit description of such a critical for IoT characteristics as power supply. Perhaps the author meant that the power supply falls into the Environment category, but it would be better to say this in an explicit form.

Despite the simplicity, the notation looks quite thoughtful. At least, for the description of small systems, it just fits. For large dimensions, you can apply a hierarchical representation (a system consisting of subsystems, or "system of systems").
We will try to apply this approach in the practice of IoT design.