Загрози в сфері Інтернету речей (IoT) представляють потенційні ризики для підключених пристроїв і мереж. Дізнайтеся, які загрози можуть виникнути в контексті IoT та як їм запобігти.
1329 
Моделювання загроз – це процес аналізу та створення віртуальних моделей можливих загроз та ризиків для різних сфер життєдіяльності. Цей підхід дозволяє оцінювати потенційні небезпеки та розробляти стратегії їх запобігання та управління. Моделювання загроз має важливе значення для багатьох галузей, включаючи кібербезпеку, екологію, фінанси та громадську безпеку. Воно дозволяє прогнозувати можливі наслідки небезпеки та приймати належні заходи щодо її управління. Цей підхід вимагає використання спеціалізованих програмних інструментів, статистичного аналізу та інших методів, які допомагають створити точні та надійні моделі загроз. Моделювання загроз є важливим етапом у процесі розробки стратегій безпеки та ризик-менеджменту. Зрозуміння та попередження загроз – це критичні завдання для забезпечення безпеки та стійкості в різних сферах діяльності.
Моделювання загроз передбачає використання різних методів та технологій для створення реалістичних сценаріїв подій, що можуть призвести до загрози або негативного впливу. Це дозволяє оцінити ймовірність та наслідки таких подій, що є важливим для прийняття раціональних та обгрунтованих рішень. Моделювання загроз також використовується для вивчення різних варіантів реакції на загрози та вибору найкращих стратегій захисту. Воно допомагає визначити, які заходи можуть бути найбільш ефективними та вартісними. Один із важливих аспектів моделювання загроз – це оновлення та корекція моделей на основі нової інформації та аналізу змін у середовищі. Завдяки цьому, організації можуть підтримувати своє захисне обладнання та процедури на актуальному рівні. Загрози у світі речей Інтернету є особливо актуальними в сучасному цифровому світі, де все більше пристроїв підключається до мережі. Моделювання таких загроз допомагає покращити безпеку підключених пристроїв та забезпечити їхню захищеність від потенційних атак. Отже, моделювання загроз є важливим інструментом для попередження та управління ризиками в різних галузях діяльності та допомагає забезпечити стабільність та безпеку в цифровому світі.
Створюючи моделі загроз для пристроїв IoT, ви, ймовірно, зіткнетеся з низкою загальних проблем. Причина в тому, що світ Інтернету речей в основному складається з систем з низькою обчислювальною потужністю, енергоспоживанням, пам’яттю і дисковим простором, які розгорнуті в незахищених мережевих середовищах. Багато виробників обладнання зрозуміли, що вони можуть легко перетворити будь-яку недорогу платформу, таку як телефон або планшет Android, Raspberry Pi або плату Arduino, в складний пристрій IoT.
Отже, багато пристроїв IoT фактично працюють під управлінням Android або звичайних дистрибутивів Linux – тих самих операційних систем, які встановлені на мільярди телефонів, планшетів, годинників та телевізорів. Ці ОС добре відомі і часто надають більше функцій, ніж вимагає пристрій, що збільшує можливості зловмисника. Гірше того, розробники IoT розширюють операційні системи, представляючи власні програми, які не мають належних заходів безпеки! Крім того, щоб забезпечити функціонування пристрою, розробникам часто доводиться обходити оригінальні засоби захисту операційної системи. Інші пристрої IoT, засновані на операційній системі реального часу (RTOS), мінімізують час обробки, відмовляючись від впровадження стандартів безпеки більш просунутих платформ.
Крім того, електроніка такого роду зазвичай не оснащується антивірусними або антишкідливими засобами. Його мінімалістичний дизайн, заточений простотою використання, не враховує загальних заходів безпеки, таких як білий список програмного забезпечення, завдяки якому на пристрій дозволено встановлювати тільки певне програмне забезпечення, або рішення для контролю доступу до мережіКонтроль доступу до мережі (NAC) для забезпечення дотримання політики безпеки мережі, яка регулює доступ користувачів і пристроїв. Багато постачальників припиняють пропонувати оновлення системи безпеки незабаром після першого випуску продукту. Крім того, деякі компанії укладають договори з представниками брендів, які беруть на себе поширення сторонньої продукції, і тоді одні й ті ж пристрої надходять на ринок по різних каналах під різними брендами і логотипами, що ускладнює оновлення системи безпеки і програмного забезпечення кожного з них.
Ці обмеження призводять до того, що багато інтернет-пристроїв використовують власні або менш відомі протоколи, які не відповідають стандартам безпеки. Це часто перешкоджає використанню складних методів загартовування, таких як моніторинг цілісності програмного забезпечення, який відстежує стороннє втручання, або атестація пристрою – перевірка за допомогою спеціалізованого обладнання, щоб переконатися, що тестований прилад надійний.
Найпростіший спосіб змоделювати загрози при оцінці безпеки – використовувати модель класифікації загроз STRIDE, яка фокусується на виявленні слабких місць у технології, а не вразливих активів чи потенційних зловмисників. Розроблена Прарітом Гаргом і Лорен Конфельдер в Microsoft, STRIDE є однією з найпопулярніших систем класифікації загроз.
Абревіатура розшифровується як наступні загрози:
Spoofing (спуфінг, підміна) – обхід системи керування доступом за рахунок маскування під іншу систему;
Tampering (втручання) – суб’єкт порушує цілісність системи чи даних;
Repudiation (приховування) – користувач може приховати, що робив певні дії щодо системи;
Information disclosure (витік інформації) – порушена конфіденційність даних у системі (відбувається витік даних, перехоплення);
Denial of Service (D.o.S, атака «відмова в обслуговуванні») – зловмисник створює такі умови, за яких легальні користувачі системи не можуть отримати доступу до її ресурсів;
Elevation of privilege (підвищення привілеїв) – користувач, якому відкрито лише обмежений доступ до системи, може самостійно розширити можливості доступу.
STRIDE включає в себе три кроки: визначення архітектури, розбиття її на компоненти і виявлення загроз для кожного компонента. Розглянемо цю схему на прикладі інфузійного насоса. Припустимо, насос підключений по Wi-Fi до сервера в лікарні. Мережа незахищена і їй не вистачає сегментації, а це означає, що відвідувач лікарні може підключитися до Wi-Fi і пасивно контролювати трафік. Ми будемо використовувати цей сценарій для розробки покрокового плану дій.
Моделювання загроз починається з вивчення архітектури пристрою. Система складається з насоса і сервера управління, який може посилати команди декільком десяткам насосів (рис. 2.1). Сервер обслуговується медсестрами, хоча в деяких випадках до нього можуть отримати доступ уповноважені ІТ-адміністратори.
Іноді потрібно оновити дані на сервері C&C, включаючи бібліотеку ліків та медичні картки пацієнтів. Для цього сервер періодично підключається до Електронної медичної картки (ЕМК) і сервера оновлень. База даних ЕМК містить записи з історії хвороби. Хоча ці два компоненти можуть виходити за рамки показника безпеки, ми включили їх до нашої моделі загроз (рисунок 2.2).
Давайте докладніше розглянемо архітектуру. Інфузійний насос і сервер управління складаються з декількох компонентів, і нам потрібно деталізувати модель, щоб краще розпізнати можливі загрози. На рис. 2.3 Архітектура представлена ще більш детально.
Насосна система складається з апаратної частини (самого насоса), операційної системи, а також програмного забезпечення і мікроконтролера, що працює всередині і насоса. Ми також розглядаємо операційну систему сервера управління, менеджер серверів управління (програма, яка керує сервером) та обмежений інтерфейс користувача, систему, яка обмежує взаємодію користувача з апаратним забезпеченням.
Тепер, коли ми маємо більш чітке уявлення про модель, давайте визначимося з напрямками, в яких інформація передається між компонентами. Таким чином ми знайдемо конфіденційні дані та дізнаємося, які компоненти можуть бути атаковані зловмисником. Також можна виявити приховані шляхи потоку даних, про які ми не знали. В ході вивчення інфраструктури ми прийшли до висновку, що дані передаються в обох напрямках між усіма компонентами. Відзначимо це за допомогою двонаправлених стрілок на рис. 2.3. Запам’ятайте цю деталь.
Продовжимо, додавши межі довіри до нашої схеми (рисунок 2.4). Межі довіри обведені групами з атрибутами безпеки, які можуть допомогти нам визначити точки входу в потенційно вразливі потоки даних.
З цими межами ми намітили насос, сервер управління, локальні та зовнішні компоненти. З практичних міркувань ми також додаємо двох зовнішніх користувачів: пацієнта, який використовує насос, і медсестру, яка обслуговує сервер управління.
Зверніть увагу, що конфіденційна інформація, така як дані пацієнтів з насоса, може надсилатися на сторонній сервер оновлень через C&C-сервер. Наш метод працює: ми вже виявили першу загрозу – незахищений механізм оновлення, який може піддавати дані пацієнта несанкціонованим системам.
Тепер застосуємо модель STRIDE до складових діаграми, що дасть нам більш повний список загроз. Хоча в цій вправі будуть обговорюватися лише деякі з цих компонентів для стислості, ви повинні розглянути їх усі як частину процесу моделювання загроз.
Для початку розберемо загальні вимоги до безпеки продукту. Часто вендор встановлює ці вимоги в процесі розробки. Якщо у нас немає конкретного списку вимог постачальника, ми можемо переглянути документацію до пристрою, щоб ідентифікувати їх самостійно. Наприклад, в якості медичного виробу інфузійний насос повинен забезпечувати безпеку і конфіденційність пацієнта. Крім того, всі медичні вироби повинні бути зареєстровані і сертифіковані за ринковими стандартами країни походження. Наприклад, пристрої, що продаються в Європейській економічній зоні, повинні мати знак сертифікації Conformité Européenne (CE). Ці вимоги ми будемо враховувати при аналізі кожного компонента.
Обмежувальний інтерфейс користувача (RUI) – це програма, яка працює в режимі кіоску і взаємодіє зі службою Management Server. Він істотно обмежує дії користувача і по суті схожий на додаток банкомату: взаємодіяти з програмою можна, але в допустимих межах. Крім загальних вимог безпеки, RUI передбачає дотримання спеціальних стандартів. По-перше, користувач не повинен мати можливість вийти з програми. По-друге, щоб отримати доступ до нього, користувач повинен пройти аутентифікацію, ввівши дійсні облікові дані. Тепер давайте застосуємо модель STRIDE для виявлення загроз крок за кроком.
Спуфінг: RUI аутентифікує користувачів за допомогою слабких чотиризначних пін-кодів, які зловмисники можуть легко вгадати. Якщо зловмисники вгадують пін-код, вони отримують доступ до авторизованих облікових записів і можуть надсилати команди інфузійному насосу від імені власника облікового запису.
Інтерференція: RUI дозволяє інший метод введення, ніж кілька дозволених. Наприклад, введення можна здійснювати через зовнішню клавіатуру. Навіть якщо більшість клавіш відключені, система може дозволити різні комбінації клавіш, такі як гарячі клавіші або навіть спеціальні комбінації клавіш, надані базовою операційною системою (наприклад, закриття вікна натисканням ALT+F4 на Windows). Це може дозволити користувачам обійти режим RUI та вийти з кіоску. Ми опишемо цей тип нападу в розділі 3.
Приховування: RUI підтримує лише один обліковий запис користувача для медичного персоналу, що робить лог-файли, якщо такі є, безглуздими: ви не можете сказати, хто насправді використовував пристрій. Оскільки RUI не може працювати в багатокористувацькому режимі, будь-який член медичної команди може отримати доступ до сервера управління та керувати інфузійним насосом; система не зможе розпізнати, Хто саме цим займається.
Витік інформації: Цілком можливо, що деякі повідомлення про помилки або налагоджувальна інформація, представлена користувачеві, можуть розкрити важливу інформацію про пацієнтів або внутрішню структуру системи. Ніщо не заважає зловмисникам розшифрувати ці повідомлення, виявити технології, що використовуються базовою системою, і з’ясувати, як їх використовувати.
Відмова в обслуговуванні (D.o.S атаки) небезпечна для RUI через механізм захисту від грубої сили (груба сила): доступ користувача до системи блокується після п’яти послідовних неправильних спроб входу. Після спрацьовування захисту від грубої сили всім користувачам деякий час не дозволяється входити в систему. Якщо бригада медиків випадково активує цю функцію, доступ до системи буде заблокований, створення ризиків для пацієнта. Хоча вбудовані функції безпеки захищають від ряду загроз, вони також можуть породити інші. Досягнення балансу між безпекою та зручністю використання є складним завданням.
З точки зору збільшення привілеїв, критично важливі медичні системи часто мають рішення віддаленої підтримки, які дозволяють технікам провайдера миттєво отримати доступ до програмного забезпечення. Наявність цих функцій автоматично збільшує масштаб загрози, оскільки такі сервіси вразливі і зловмисники можуть використовувати їх для отримання віддаленого адміністративного доступу в рамках RUI або служби управління сервером. Навіть якщо ці Функції вимагають аутентифікації, облікові дані можуть бути загальнодоступними або однаковими для всіх продуктів у лінійці. А іноді аутентифікація не передбачена.
Служба Management Server – це програма, яка обслуговує C&C-сервер. Він відповідає за зв’язок з RUI, бібліотекою ліків та інфузійним насосом. Він також зв’язується з електронною медичною карткою (для отримання інформації про пацієнтів) по протоколу HTTPS і з сервером оновлень (для отримання оновлень програмного забезпечення і бібліотеки ліків) по спеціальному протоколу TCP.
Крім загальних вимог безпеки, згаданих вище, важливо, щоб сервер управління міг ідентифікувати і верифікувати інфузійні насоси – щоб уникнути скіммінгових атак, під час яких зловмисник замінює периферійні компоненти системи на аналогічні, але з деякими модифікаціями. Також потрібно переконатися, що «дані в дорозі» захищені – іншими словами, протокол зв’язку між сервером управління і насосом безпечний і не дозволяє атакувати повтор або перехоплення. Атаки повтору викликають критичний запит або запит на сервер, який змінює його стан, на повторну передачу або затримку. Нарешті, ми повинні гарантувати, що зловмисники не можуть порушити контроль безпеки хостингової платформи, який може включати пісочницю програми, дозволи файлової системи та існуючі елементи керування доступом на основі ролей.
Використовуючи STRIDE, ми можемо визначити наступні загрози. Спуфінг: Спуфінг-атаки можуть відбуватися тому, що сервер управління не має надійного методу ідентифікації інфузійних насосів. Якщо хоча б поверхнево проаналізувати протокол зв’язку, можна змоделювати насос і зв’язатися з керуючим сервером, що тягне за собою нові загрози.
Перешкоди: Зловмисник може зламати службу, оскільки сервер управління не має надійного методу перевірки цілісності даних, відправлених інфузійним насосом. Це означає, що командно-керуючий сервер вразливий до атак типу “людина посередині”, де зловмисник змінює дані, що відправляються на сервер, і надає помилкові свідчення. Якщо керуючий сервер засновує свої дії на фальсифікованих показаннях, атака може бути безпосередньо впливають на здоров’я і безпеку пацієнтів.
Сервер управління може дозволити приховувати активність користувачів, оскільки він використовує публічні журнали, які будь-який користувач системи може перезаписати за бажанням. Ці лог-файли можуть бути піддані інсайдерському втручанню зловмисником, який хоче приховати в них певні операції.
Що стосується витоку інформації, C&C сервер без необхідності відправляє конфіденційну інформацію про пацієнта на сервер оновлень або інфузійний насос. Ця інформація може включати результати важливих вимірювань, особисті дані тощо.
Що стосується атаки типу «відмова в обслуговуванні», то зловмисники в безпосередній близькості від C&C сервера можуть заглушити його сигнал і відключити будь-який вид бездротового зв’язку з насосом, в результаті чого вся система прийде в непридатність.
Сервер керування також може бути вразливим до Elevation of privilege, якщо він ненавмисно викриває служби API, які дозволяють зловмисникам, які не пройшли аутентифікацію, виконувати дії з високими привілеями, включаючи зміну налаштувань інфузійного насоса.
Бібліотека ліків є основною базою даних системи. У ньому міститься вся інформація, пов’язана з медикаментами, які використовує насос. У цій базі даних також може працювати система управління користувачами.
Спуфінг: Користувачі, які взаємодіють з базою даних через RUI або насос, можуть видавати себе за користувачів іншої бази даних. Наприклад, вони можуть використовувати вразливість програми за відсутності елементів керування для введення користувачем з RUI.
Інтерференція: бібліотека ліків може бути вразливою, якщо бібліотека не здатна якісно очистити введені користувачем RUI. Це може призвести до атак SQL-ін’єкцій, які дозволяють зловмисникам маніпулювати базою даних або вводити SQL-код.
База даних може бути прихована, якщо запити користувачів, що надходять з інфузійного насоса, через запити агента користувача програмного забезпечення, передані незахищеним способом, дозволяють зловмисникам засмічувати файли журналів бази даних (наприклад, використовуючи канали рядків для вставки підроблених записів журналу).
Розкриття інформації: База даних може містити функції або збережені процедури, які виконують зовнішні запити (наприклад, DNS або HTTP-запити). Зловмисник може використовувати їх для крадіжки даних за допомогою атаки SQL-ін’єкцій. Цей метод надзвичайно корисний для зловмисників, які можуть виконувати лише сліпі атаки SQL-ін’єкційв якому вихід на сервер не містить вихідних даних введеного запиту. Наприклад, зловмисники можуть контрабандою конфіденційних даних, створюючи URL-адреси та розміщуючи ці дані в субдомені, який вони контролюють. Потім вони можуть надати цю URL-адресу одній із цих вразливих функцій і змусити базу даних зробити зовнішній запит до свого сервера.
Атаки типу «відмова в обслуговуванні» також можуть виникати, коли зловмисник використовує переваги системних компонентів, які дозволяють виконувати складні запити. Якщо змусити ці компоненти виконувати непотрібні обчислення, база даних може аварійно завершити роботу, якщо немає доступних ресурсів для виконання запиту.
Збільшення привілеїв: Деякі функції бази даних можуть дозволити користувачам запускати код з найвищими привілеями. Виконуючи певний набір дій через компонент RUI, користувач може викликати ці функції і звести свої привілеї до рівня суперкористувача бази даних.
Операційна система отримує вхідні дані від служби сервера управління, тому будь-які загрози для неї надходять безпосередньо з сервера управління. Операційна система повинна мати механізми цілісності, а її базова конфігурація повинна враховувати певні принципи безпеки: наприклад, захист даних в стані спокою, процедури оновлення, брандмауер (брандмауер) і виявлення шкідливого коду.
Компонент може бути підроблений, якщо зловмисник може завантажити власну користувацьку операційну систему, яка навмисно не підтримує необхідні елементи керування безпекою, такі як пісочниця, дозволи файлової системи та контроль доступу на основі ролей. Потім зловмисник може вивчити додаток і витягти важливу інформацію, яка в іншому випадку була б для нього недоступна.
Втручання: При локальному або віддаленому доступі до системи зловмисник може маніпулювати ОС – наприклад, змінювати поточні параметри безпеки, відключати брандмауер і встановлювати обхідний шлях для виконуваної програми.
Приховування: Ця загроза виникає, якщо системні журнали зберігаються лише локально і якщо зловмисник з високими правами може змінити їх.
Витік інформації: Повідомлення про помилки та налагоджувальні повідомлення можуть розкрити інформацію про операційну систему, дозволяючи зловмисникам проникнути глибше в систему. Повідомлення також можуть містити інформацію про пацієнта, яку не слід передавати третім особам.
Компонент може бути схильний до атак типу «відмова в обслуговуванні», якщо зловмисник ініціює небажане перезавантаження системи (наприклад, під час процесу оновлення) або навмисно вимикає систему, викликаючи збої в роботі пристрою.
Збільшення привілеїв: Зловмисники можуть використовувати функціональні вразливості, дизайн програмного забезпечення або неправильну конфігурацію високопривілейованих служб і додатків, щоб отримати розширений доступ до ресурсів, якими можуть керувати лише користувачі з особливими привілеями.
Далі розглянемо прошивку всіх компонентів пристрою, таких як CD / DVD привід, контролери, дисплей, клавіатура, миша, материнська плата, мережева карта, звукова карта, відеокарта і т. Д. Прошивка – це тип програмного забезпечення, який відповідає за певні низькорівневі операції. Зазвичай він зберігається в енергонезалежній пам’яті компонентів або завантажується в компоненти драйвером при ініціалізації. Виробник пристрою зазвичай розробляє та підтримує власну прошивку. При цьому він повинен підписати прошивку, а пристрій має перевірити цю підпис.
Спуфінг: Зловмисники можуть використовувати логічні помилки, які знижують версію прошивки до більш ранньої версії, яка містить відомі вразливості. Ще один варіант шкідливого впливу – установка спеціальної прошивки, яка маскується під останню доступну від виробника версію, коли система запитує оновлення.
Інтерференція: Встановлення шкідливого програмного забезпечення на прошивку є поширеним методом для атак Advanced Persistent Threat (APT), коли зловмисник намагається залишитися непоміченим протягом тривалого періоду часу і перечекати перевстановлення операційної системи або заміну жорсткого диска. Наприклад, модифікація прошивки жорсткого диска, що містить троян (особливий вид вірусів), дозволяє зберігати дані в місцях, які залишаться неушкодженими навіть при форматуванні або видаленні диска. Пристрої IoT часто не можуть перевірити цілісність цифрових підписів та прошивки, що полегшує такі атаки. Крім того, зміна змінних конфігурації певної мікропрограми (наприклад, BIOS або UEFI) може дозволити зловмисникам вимкнути певні функції безпеки обладнання, такі як безпечне завантаження.
Витік інформації: Будь-яка прошивка, яка встановлює канал зв’язку зі сторонніми серверами (наприклад, для аналітичних цілей або для запиту інформації про оновлення), також може розкривати персональні дані пацієнтів, в тому числі відносяться до категорії конфіденційних даних. Крім того, іноді прошивка надає непотрібні пов’язані з безпекою функції API, якими зловмисники можуть скористатися для вилучення даних або розширення своїх привілеїв. Тут відноситься до витоку вмісту оперативної пам’яті управління системою (SMRAM), що використовується режимом управління системою (SMM), який виконує код з найвищими привілеями та контролює використання процесора.
Відмова в обслуговуванні: Деякі постачальники компонентів пристроїв надають бездротові оновлення (OTA) для розповсюдження мікропрограми та надійного налаштування компонента. Зловмисники можуть заблокувати ці оновлення, залишивши систему в небезпечному або нестабільному стані. Крім того, спроби безпосередньої взаємодії з інтерфейсом зв’язку та пошкодження даних зупиняються експлуатація системи.
Збільшення привілеїв: Можна використовувати відомі вразливості в драйверах і зловживати недокументованими, відкритими інтерфейсами управління, такими як SMM. Крім того, багато компонентів пристрою поставляються з паролями за замовчуванням, вбудованими в прошивку. Зловмисники можуть використовувати ці паролі, щоб отримати привілейований доступ до панелей керування компонентами або до живої хост-системи.
Тепер давайте оцінимо безпеку фізичного обладнання – включаючи шасі, в якому розміщений процесор сервера управління та екран RUI. Як тільки зловмисники отримають фізичний доступ до системи, слід припустити, що вони нададуть собі права адміністратора. Повністю убезпечити себе від цього навряд чи вдасться. Однак можна реалізувати механізми, які значно ускладнять цей процес.
Вимоги до безпеки фізичного обладнання набагато більше, ніж до будь-яких інших елементів системи. По-перше, клініка повинна зберігати контрольний сервер в приміщенні, доступ до якого мають тільки уповноважені співробітники. Кожен компонент повинен підтримувати атестацію обладнання та забезпечувати безпечний процес завантаження на основі ключів, записаних до центрального процесора. На пристрої повинна бути включена захист пам’яті. Він повинен забезпечувати безпечне, апаратно підкріплене управління, зберігання та генерацію ключів, а також безпечні криптографічні операції, такі як генерація випадкових чисел, шифрування даних з відкритим ключем та безпечне підписання. Крім того, всі важливі компоненти повинні бути покриті епоксидною смолою або іншим клейкою речовиною, що не дозволяє легко вивчити схему проектування і ускладнює реверс-інжиніринг (реверс-інжиніринг).
Підміна: зловмисники можуть замінити критично важливі частини обладнання на несправні або небезпечні. Ми називаємо ці атаки атаками на ланцюжок поставок, оскільки вони часто відбуваються на етапах виробництва або доставки продукту.
Перешкоди: користувач може підключити зовнішні USB-пристрої, такі як клавіатура або флеш-накопичувач, щоб надати системі ненадійні дані. Крім того, зловмисник може замінити існуючі фізичні пристрої введення (такі як клавіатури, кнопки управління, порти USB або Ethernet) на шкідливі, які передають дані назовні. Відкриті апаратні інтерфейси програмування, такі як JTAG, також можуть дозволити зловмисникам змінювати поточні налаштування пристрою і Зніміть прошивку або навіть скиньте налаштування, привівши пристрій в небезпечний стан.
Витік інформації: Зловмисники можуть виявити інформацію про систему та її роботу, просто спостерігаючи за нею. Крім того, екран RUI не може захистити систему від фотографій, які фіксують конфіденційну інформацію. Хтось може видалити зовнішні запам’ятовуючі пристрої та отримати збережені дані. Зловмисники також можуть пасивно робити висновки про конфіденційну інформацію про пацієнтів, паролі відкритого тексту та ключі шифрування, використовуючи потенційні витоки з бічного каналу до апаратна реалізація (наприклад, електромагнітні перешкоди або енергоспоживання процесора) або шляхом аналізу розділів пам’яті під час атаки холодного завантаження.
Послуга може бути вразливою до атак типу «відмова в обслуговуванні» у випадках, коли відбувається відключення електроенергії і система перестає функціонувати. Ця загроза безпосередньо впливає на всі компоненти, для функціонування яких потрібен сервер управління. Крім того, зловмисники, які мають фізичний доступ до обладнання, можуть впливати на внутрішні схеми пристрою, викликаючи збої в роботі.
Збільшення привілеїв можливе через вразливості, такі як гонки на краю сигналу та небезпечна обробка помилок. Ці проблеми специфічні для конструкції з вбудованими процесорами і дозволяють зловмиснику читати всю пам’ять або записувати в довільні місця пам’яті, навіть якщо зловмисник не має таких дозволів.
Служба управління насосом (насосна служба) – це програмне забезпечення, яке керує насосом. Він складається з протоколу зв’язку, який підключається до керуючого сервера і мікроконтролера, керуючого насосом. Крім загальних вимог безпеки, насос повинен ідентифікувати і перевірити цілісність служби сервера управління. Протокол зв’язку між сервером управління і інфузійним насосом повинен бути безпечним і запобігати повторним атакам або перехопленню.
Спуфінг: Може вплинути на компонент, якщо насос не використовує перевірки, достатні для підтвердження того, що він дійсно спілкується з законним сервером управління. Ненадійна перевірка також може призвести до втручання, якщо, наприклад, насос приймає несанкціоновані запити на зміну його налаштувань. Що стосується приховування подій, інфузійний насос може використовувати файли журналів користувача – якщо вони не тільки читабельні, можливо неправильне проникнення в них.
Служба насосів витікає інформацію, якщо протокол зв’язку між сервером управління та інфузійним насосом не використовує шифрування. При цьому зловмисники можуть перехопити дані, в тому числі конфіденційну інформацію пацієнта.
Атаки типу «відмова в обслуговуванні » будуть успішними , якщо після ретельного аналізу протоколу зв’язку зловмисник виявить команду відключення. Крім того, якщо насос має root-права на систему і повний контроль над пристроєм, він може опинитися під загрозою збільшення привілеїв.
Можливо, ви виявили більше загроз, ніж ми згадували вище, і, ймовірно, визначили додаткові вимоги безпеки для кожного компонента. Хорошим емпіричним правилом є ідентифікація принаймні однієї або двох загроз за допомогою моделі STRIDE для кожного компонента. Якщо з першої спроби ви не виявили стільки ризиків, перегляньте свою модель загрози кілька разів.
Якщо ви хочете виявити нові загрози або змоделювати існуючі для подальшого аналізу, ви можете використовувати дерево атаки. Це візуальна карта, яка починається з визначення загальної мети атаки, а потім стає більш конкретною в міру розширення дерева. Наприклад, на рисунку 2.5 показано дерево атаки, метою якої є відкриття доступу до служби доставки ліків.
Дерева атак можуть зробити результати дослідження моделі загроз більш наочними; крім того, ми можемо виявляти загрози, які ми пропустили раніше. Зверніть увагу, що кожен вузол містить можливу атаку, яка вимагає однієї або декількох атак, описаних в його дочірніх вузлах. У деяких випадках для атаки можуть знадобитися всі дочірні вузли. Наприклад, проникнення в базу даних інфузійних насосів вимагає, Щоб ви отримали як доступ до бази даних, так і несанкціонований доступ до таблиць бібліотеки ліків. Однак ви можете перешкодити доставці ліків, змінивши швидкість інфузії або перервавши оновлення швидкості інфузії за допомогою DoS-атаки.
Загроза не завжди є реальною небезпекою. Значимість загрози можна оцінити за її впливом. І справжній вплив виявлених нами загроз неможливо визначити, поки ми не подивимося на результати оцінки вразливості. Отже, в якийсь момент потрібно буде прорахувати ризики, пов’язані з кожною загрозою.
Ми покажемо вам, як це зробити за допомогою DREAD, системи оцінки ризиків. DREAD – це абревіатура від назв оцінюваних показників.
Damage (збитки) – наскільки небезпечною є реалізація цієї загрози;
Reproducibility (відтворюваність) – наскільки легко відтворити експлойт;
Exploitability (експлуатація) – наскільки легко скористатися загрозою;
Affected users (зачеплені користувачі) – скільком користувачам зашкодить атака;
Discoverability (Виявлення) – наскільки легко ідентифікувати загрозу.
Ми привласнюємо, що кожен з цих показників оцінюється за шкалою від 0 до 10, і на цій основі виробляємо загальну оцінку ризику.
Як приклад, давайте використаємо DREAD для оцінки загрози, яку становить слабкий чотиризначний метод аутентифікації RUI. По-перше, якщо зловмисники зможуть вгадати чийсь пін-код, вони зможуть отримати доступ до фактичних даних користувача. Оскільки від атаки постраждає тільки один пацієнт, ми будемо оцінювати показники «Збиток» і «Постраждалі користувачі» в половину максимуму, тобто в п’ять балів. Потім, оскільки навіть некваліфікований супротивник може легко виявити, використати та відтворити цю загрозу, я призначу показникам «Виявлення», «Операція» та «Відтворення» максимальний бал 10. Склавши бали і розділивши їх на 5 (кількість показників), отримаємо середній бал ризику 8 з 10 (див. Таблицю 2.1).
У цьому розділі ми представили вам одну можливу структуру моделювання загроз: програмно-центричний підхід, націлений на вразливості кожного компонента програми. Але є й інші можливі схеми, яким ви можете слідувати, такі як підходи, орієнтовані на ресурси та нападника. Ви можете використовувати один з цих альтернативних методів залежно від ваших конкретних потреб.
У ресурсоцентричній моделі загроз спочатку потрібно визначити важливу системну інформацію. Ресурси для інфузійного насоса можуть включати дані пацієнта, облікові дані для автентифікації сервера управління, налаштування конфігурації інфузійного насоса та версію програмного забезпечення. Далі ви проаналізуєте ці ресурси на основі їхніх атрибутів безпеки: іншими словами, що потрібно кожному ресурсу для збереження конфіденційності, цілісності та доступності. Зауважте, що ви, ймовірно, не створите повний список ресурсів, оскільки те, що вважається цінним, залежить від точки зору кожної людини.
Підхід, орієнтований на нападника, спрямований на виявлення потенційних зловмисників. Після цього слід використовувати їх атрибути для розробки базового профілю загрози для кожного ресурсу. Такий підхід має деякі недоліки: він вимагає від вас збору великої кількості інформації про сьогоднішніх суб’єктів загроз, їхню нещодавню діяльність та характеристики. Крім того, не виключено, що вас відведуть в сторону ваші суб’єктивні уявлення про Хто такі нападники і чого вони хочуть. Щоб уникнути хибних уявлень, використовуйте стандартні описи агентів загроз з бібліотеки агентів загроз Intel за адресою https://www.intel.com/content/dam/www/ public/us/uk/documents/solution-briefs/risk-assessments-maximize-securi ty-budgets-brief.pdf. Наприклад, у нашому сценарії список агентів може включати ненавчену медсестру, яка неправильно керує системою, медсестру з недбалістю безпеки, яка нехтує встановити правила, щоб заощадити час, а також злодія, який може вкрасти дрібні компоненти (наприклад, жорсткі диски і SD-карти) або навіть інфузійний насос з лікарні. Більш просунуті агенти можуть включати платформу Data Miner, яка шукає командні сервери, підключені до Інтернету, і збирає дані пацієнтів, або Government Cyber Warrior, яка проводить спонсоровані державою атаки, щоб викликати збої в роботі інфузійних насосів по всій країні.
Також можна вибрати інші параметри моделювання загроз. Крім STRIDE, існують моделі PASTA, Trike, OCTAVE, VAST, Security Cards і Persona non Grata. Ми не будемо їх тут розглядати, але вони можуть бути корисними для певних оцінок. Для моделювання загроз використовуються схеми потоків даних, але можна використовувати й інші типи діаграм, наприклад схеми уніфікованої мови моделювання (UML), схеми відстеження або навіть діаграми станів. Ви самі вирішуєте, яка система має найбільший сенс і найкраще працює для вас.
Давайте розглянемо деякі поширені загрози в системах IoT. Список не є вичерпним, але ви можете використовувати його як основу для власних моделей загроз.
Атаки придушення сигналу
При атаці глушіння сигналу противник заважає зв’язку між двома системами. Системи IoT зазвичай мають власні екосистеми вузлів. Наприклад, система інфузійних насосів має єдиний сервер управління, який обслуговує кілька насосів. За допомогою спеціального обладнання можна ізолювати керуючий сервер і насоси один від одного. У критичних системах, подібних до цієї, така загроза може виявитися фатальною.
Повтор атак
Під час повторної атаки зловмисник повторює операцію або повторно надсилає переданий пакет. У прикладі інфузійного насоса це може означати, що пацієнт отримує кілька доз ліків. Повторні атаки незалежно від того, впливають вони на пристрої IoT чи ні, вони, як правило, досить серйозні.
Хакерські атаки
Під час атак підробки конфігурації зловмисник використовує відсутність цілісності компонента, щоб змінити його налаштування. Для інфузійного насоса ці налаштування можуть включати наступне: заміна сервера управління шкідливим сервером, зміна основного використовуваного препарату або зміна налаштувань мережі для запуску DoS-атаки.
Атаки на цілісність обладнання
Атаки на цілісність обладнання ставлять під загрозу цілісність фізичного пристрою. Наприклад, зловмисник може проникнути через ненадійні замки або легкодоступні USB-порти, особливо якщо вони завантажувальні. Усі системи IoT стикаються з цією загрозою, оскільки жоден захист цілісності пристрою не є ідеальним. Однак деякі способи захисту ускладнюють завдання проникнення. Одного разу, під час оцінки вразливості певного медичного виробу, ми зрозуміли, що якщо не розбирати пристрій дуже акуратно спеціальним обладнанням, то механізм самозахисту, він же запобіжник, спрацює і зруйнує плату. Цей механізм довів, що розробники продукту серйозно поставилися до можливості злому пристрою. Однак ми врешті-решт обійшли механізм захисту.
Клонування вузла
Клонування вузлів – це загроза, яка виникає в рамках атаки Сибіли, при якій зловмисник створює підроблені вузли в мережі, щоб поставити під загрозу її надійність. Системи IoT зазвичай використовують кілька вузлів у своїй екосистемі, наприклад, коли один сервер управління управлінням керує декількома насосами для ліків.
Ми часто виявляємо загрозу клонування вузлів в системах IoT. Одна з причин полягає в тому, що протоколи асоціації, які вузли використовують для зв’язку, не дуже складні, і створення підроблених вузлів іноді досить просте. Іноді ви навіть можете створити підроблений головний вузол (у нашому прикладі сервер управління). Ця загроза може впливати на систему по-різному: чи існує кінцева кількість вузлів, до яких може підключитися сервер управління? Чи може ця загроза призвести до DoS-атаки? Чи призведе це до поширення зловмисниками сфальсифікованої інформації?
Порушення безпеки та конфіденційності
Порушення конфіденційності є однією з найбільших і найстійкіших загроз у системах IoT. Часто конфіденційність даних користувача не сильно захищена, тому знайти цю загрозу можна практично в будь-якому протоколі зв’язку, який передає дані на пристрій і з нього. Картографуйте архітектуру системи, знайдіть компоненти, які можуть містити конфіденційні дані користувачів, і відстежуйте кінцеві точки, які їх передають.
Поінформованість користувачів про безпеку
Навіть якщо вам вдасться пом’якшити всі інші загрози, ви, ймовірно, матимете проблеми з поінформованістю користувачів про безпеку. Деякі не знають, як розпізнати фішингові електронні листи, які можуть скомпрометувати їх робочі станції, інші допускають неавторизованих людей в конфіденційні зони. У людей, які працюють з медичним обладнанням IoT, є приказка: якщо ви шукаєте способи зламати або обійти бізнес-логіку або щось, що прискорить ваші завдання, просто запитайте медсестру, яка працює з системою. Оскільки медсестри використовують цю систему щодня, вони знають всі системні комбінації клавіш управління.
У цьому розділі ви дізналися про моделювання загроз, процесі виявлення і списку можливих атак на досліджувану систему. Розглядаючи модель загроз інфузійного насоса, ми окреслили основні кроки в процесі моделювання загроз та описали деякі основні загрози, з якими стикаються пристрої IoT. Підхід, який ми пояснили, був простим і, можливо, не найкращим для кожної ситуації, тому ми рекомендуємо вам вивчити й інші структури.
Ми використовували матеріали з книги “The Definitive Guide to Attacking the Internet of Things ”, яку написали Фотиос Чанцис, Иоаннис Стаис,
Паулино Кальдерон, Евангелос Деирменцоглу и Бо Вудс.
1329 
1038 
1204 
1005 
1295 
1163 
1149 
1167 
1134 
1126 
1590