NIST рекомендує: будівельні блоки для опису IoT


Джерело

У липні 2016 на сайті National Institute of Standards and Technology (NIST), як зазвичай, у вільному доступі, з'явилася нова публікація NIST Special Publication 800-183, Networks of 'Things'. Даний документ був випущений в серії SP 800, Computer Security, що означає його безпосереднє відношення до інформаційної безпеки. Тим не менш, NIST SP 800-183 присвячений, в першу чергу, нотації проектування та опису архітектури IoT.

Я вирішив розібратися зі змістом цього документа, оскільки NIST випускає більш ніж солідні керівництва, серед яких, наприклад, всесвітньо відомий NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations або NIST SP 800-82, Guide to Industrial Control Systems (ICS) Security та багато іншого.

Тим більше, що автором NIST SP 800-183 є Jeffrey Voas, відомий ще з початку 1990-х рр. публікаціями з теорії оцінювання і тестування ПЗ.

Згідно референсною архітектурі інтернету речей (IoT-RA), рівень IoT Device Layer реалізує функції моніторингу і управління процесами і об'єктами реального світу, включаючи отримання даних від датчиків (sensing), обробку інформації (computing), передачу інформації (communication) та видачу команд на виконавчі пристрої (actuation). В NIST SP 800-183 застосовується термін «Network of Things (NoT)», оскільки «речі» можуть бути об'єднані в мережу, але при цьому не підключені до Internet.

NIST SP 800-183 говорить про те, що пропонується унікальний підхід в описі IoT. Для цього використовується п'ять типів примітивів: 1) Sensor, 2) Aggregator 3) Communication Channel, 4) External Utility (eUtility), 5) Decision Trigger.

Всі вони представлені на головній картинці, яка є ілюстрацією до NIST SP 800-183.

Primitive #1: Sensor
Sensor – це датчик, призначений для вимірювання фізичних параметрів (температура, вологість, тиск, прискорення і т. д.).

Primitive #2: Aggregator
Sensor передає інформацію в Aggregator, який представляє собою програмну реалізацію функцій (можливо, з використанням штучного інтелекту), які перетворюють вихідні (raw) дані в проміжні агреговані дані. Для Aggregator запроваджено ще й поняття акторів (Actor) обробки даних двох типів: Cluster & Weight. Під Cluster мається на увазі віртуальний динамічний Cluster of Sensors, який організовується і змінюється в залежності від підходу до агрегированию даних. Під Weight мається на увазі ваговий коефіцієнт (також, можливо, динамічний), який застосовується для обробки даних за допомогою Aggregator.

Primitive #3: Communication Channel
Communication Channel представляє собою віртуальну або фізичне середовище передачі даних, що об'єднує всі інші примітиви.

Primitive #4: eUtility (External Utility)
Під eUtility мається на увазі будь-який апаратний пристрій, програма або сервіс, є платформою для виконання Aggregator. У майбутньому передбачається конкретизувати цей примітив, виділивши кілька категорій.

Primitive #5: Decision Trigger
Decision Trigger формує кінцевий результат, необхідний для виконання конкретної цільової функції системи на базі IoT (NoT).

Далі NIST SP 800-183 докладно викладає властивості примітивів, які, для стислості, можна опустити.

Для доповнення моделі IoT (NoT) вводяться шість властивостей (публікації застосовується термін elements): Environment, Cost,Geographic Location, Owner, Device_ID, Snapshot. Мається на увазі, що ці властивості впливають на забезпечення достовірності (trustworthiness) системи.

1. Environment – фізична середа роботи пристроїв IoT (NoT).
2. Cost – вартість, вона і є вартість.
3. Geographic Location – географічне розташування фізичного пристрою.
4. Owner – фізична або юридична власник примітиву; це властивість включає також і роль оператора.
5. Device_ID – унікальний ідентифікатор примітиву.
6. Snapshot – часовий зріз роботи системи, що визначає, в тому числі, підхід до синхронізації.

У публікації також наводяться приклади, що відносяться до забезпечення та порушення властивостей надійності (reliability) та інформаційної безпеки (security) для примітивів. На мій погляд, ці приклади не дуже репрезентативними.

Висновки: що це дає?
В NIST SP 800-183 мені сподобався універсальний підхід до опису дизайну IoT у вигляді полуформальной нотації. По суті, це крок до стандартизації референсною архітектури (IoT-RA) на рівні Device Layer. Такий опис може бути входом для розробки відповідного CAD-інструменту. Можливо, таке вже розробляється, а поки, для формування специфікації IoT можна використовувати існуючі редактори (наприклад, MS Visio).

Насторожує, звичайно, відсутність більш складних прикладів та інформації про застосування для реальних проектів. Очевидно, така інформація може з'явитися в подальшому.

Крім того, якщо ще трохи копнути, то може вийти хороший апарат для аналізу сценаріїв використання систем на базі IoT (use case scenarios) і, відповідно, для аналізу ризиків, пов'язаних з забезпеченням таких властивостей, як достовірність (trustworthiness), інформаційна безпека (security) і надійність (dependability). Щодо останнього властивості, на мій погляд, автор «не докрутив», оскільки в NIST SP 800-183 застосовується термін «reliability», який, хоча і трактується часом, як «надійність», тим не менш, позначає «безвідмовність», тобто здатність безперервно зберігати працездатний стан протягом деякого часу (напрацювання). Для IoT, як і для інших складних систем, більш доречним є забезпечення властивості «dependability», тобто надійності в широкому сенсі, яка описується, як правило, набором властивостей RAMS (reliability – безвідмовність, availability – готовність, maintainability – ремонтопридатність, safety – безпека).
Ще я ніде в публікації не знайшов явного опису такої критичної для IoT характеристики, як електроживлення. Можливо, автор мав на увазі, що електроживлення потрапляє в категорію Environment, але краще б про це сказати в явно вигляді.

Незважаючи на простоту, нотація виглядає досить продуманою. Принаймні, для опису невеликих систем вона точно підійде. Для великої розмірності можна застосувати ієрархічної подання (система, що складається з підсистем, або «system of systems»).
Будемо спробувати застосувати такий підхід у практиці дизайну IoT.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.