Звіт стану кібер безпеки пристроїв інтернету речей у сфері охорони здоров’я у 2022 році

Cynerio, компанія, яка надає закладам охорони здоров’я послуги платформи іінтернету речей в сфері охорони здоров’я, нещодавно опублікувала звіт про поточний стан кібер безпеки підключених медичних пристроїв у лікарнях усіх типів. У дослідницькому звіті компанії щодо галузі охоплюються широкотематичні питання. Звіт також містить підсумування результатів дослідження та його методологію.

«Протягом десятиліть у медичній сфері догляду за пацієнтами завдяки пристроям інтернету речей та їх викоританню спостерігалися покращення в її роботі.
Проте зі збільшенням кількості цих пристроїв зросла і кількість загроз, вразливостей і точок експулуатації комп’ютерних мереж медичних закладів,» — йдеться у доповіді компанії Cynerio.

Статистика безпечності пристроїв інтернету речей у сфері охорони здоров’я

Інформація в цьому звіті базується на аналізі компанією більш ніж 10 мільйонів пристроїв інтернету речей і медичних пристроїв інтернету речей, зібраних із поточних реалізацій продуктів Cynerio у понад 300 лікарнях та інших медичних установах у США та по всьому світі, дані з яких при аналізі були повністю анонімізовані дослідницькою командою компанії.

У вступі до звіту фахівці надали статистичні дані з різних ресурсів щодо поточного стану кібербезпеки в галузі охорони здоров’я. І згідно зібраних статистичних даних:

  • Минулого року атаки програм-вимагачів коштували лікарням майже 21 мільярд доларів США (Компанія Comparitech);
  • Середні збитки лікарень становлять 8 мільйонів доларів США за кожну атаку програми-вимагача, і лікарням потрібно 278 днів, щоб повністю відновити свою роботу після неї. (Звіт Emsisoft: The State of Ransomware in the US);
  • Відсоток порушень кібер безпеки у сфері охорони здоров’я, спричинених підключеними пристроями, прямо пропорційний відсотку таких порушень, спричинених фішинговими атаками (Ponemon Research Report: The Impact of Ransomware on Healthcare during COVID-19 and Beyond);
  • Сфера охорони здоров’я стала лідером серед найбільш прибуткових жертв програм-вимагачів, обігнавши другі місця на 100–200%. Фахівці з кібербезпеки кажуть, що персональна медична інформація (PHI) може бути в 50 разів більш ціннішою з точки зору прибутку для кіберзлочинців, ніж викрадені банківські картки на чорному ринку.

На що націлені кіберзлочинці в галузі охорони здоров’я?

IoT (Інтернет речей). Фахівці використовують цей термін на позначення будь-яких мережевих пристроїв або інших устаткувань, які не можна вважати традиційними інформаційними технологіями (ІТ). Сюди відносяться дверні смарт замки, VOIP-телефони та камери спостереження. Але комп’ютери чи сервери не належать до цієї категорії.

IoMT (Інтернет медичних речей). Такі апарати використовуються в лікарнях в безпосередніх медичних цілях. Найпоширеніші види включають: глюкометри, кардіомонітори, внутрішньовенні насоси та апарати МРТ. Можливо, десять років тому у них не було так багато різноманітних інтернет-з’єднань, але сьогодні їхня кількість значна.

OT (Операційні технології). OT означає апаратне забезпечення, програмне забезпечення та комунікаційні системи, які допомагають керувати великомасштабним промисловим обладнанням та устаткуванням. У лікарнях це зазвичай такі пристрої, як електричні мережі, ліфти, системи HVAC (опалення, вентиляції та кондиціонування).

Підключені пристрої. Пристрої цієї категорії набагато простіші за згадані вище. Приклади включають кавоварку або вимикач світла.

Які найпоширеніші вразливості пристроїв Інтернету речей у сфері охорони здоров’я?

Якщо ви читали минулорічні заголовки новин з кібербезпеки, вам могло здатися, що найпоширенішими уразливими місцями в таких пристроях є Ripple20 або URGENT/11. Проте все навпаки, найпоширеніші з них набагато очевидніші та пов’язані з поганою елементарною кібергігієною, як-от використання стандартних паролів та налаштувань. Потенційні зловмисники можуть легко знайти в Інтернеті інструкції до пристроїв і, звісно, першою чергою ​​спробувати найочевиднішу річ: паролі та налаштування за замовчуванням. Також у більш ніж половини пристроїв Інтернету речей у сфері охорони здоров’я є одна критична вразливість.

Звіт стану кібер безпеки пристроїв Інтернету речей у сфері охорони здоров’я у 2022 році
Рейтинг найпоширеніших вразливостей в медичних пристроях інтернету речей

Підсумування результатів дослідження

Внутрішньовенні насоси є найпоширенішим пристроєм інтернету речей у сфері охорони здоров’я та мають найвищий ступінь ризику. Насоси для внутрішньовенного введення складають 38% від усіх пристроїв інтернету речей в медичних закладах. І вражаюча кількість в 73% має вразливість, яка може поставити під загрозу доступність послуг, конфіденційність даних або безпеку пацієнтів.

53% пристроїв інтернету речей та медичних пристроїв інтернету речей містять критичні вразливості. Більше половини підключених медичних та інших пристроїв інтернету речей у лікарнях мають одну добре відому критичну вразливість. Факт, що ставить під загрозу конфіденційність даних, доступність послуг та безпеку пацієнтів. Третина приліжкових пристроїв інтернету речей тих, які безпосередньо використовуються у догляді за пацієнтами, і ті, від яких пацієнти найбільше залежать, мають визначений критичний ризик.

Urgent11 та Ripple20 отримали найбільше заголовків, але найпоширеніші ризики для кібер безпеки пристроїв — це проста недбалість до кібергігієни. Найпоширеніші пристрої медичних пристроїв інтернету речей та звичайних пристроїв інтернету речей часто мають паролі та налаштування за замовчуванням, які зловмисники можуть знайти без особливих зусиль. Їм просто потрібно знайти інструкції для конкретних пристроїв онлайн. Також варто додати, що зазначені вразливості Urgent11 і Ripple20 торкнулися лише 10 відсотків пристроїв із векторами атак, експлуатацію яких зазвичай складно проводити.

Звіт стану кібер безпеки пристроїв Інтернету речей у сфері охорони здоров’я у 2022 році
“Найпідключеніші” пристрої в лікарнях (у відсотковому співвідношенні від загальної кількості усіх пристроїв IoT/IoMT)

Деякі критичні пристрої інтернету речей у медичній сфері працюють із застарілими версіями Windows. Хоча пристрої, які працюють під управлінням старішої версії Windows, ніж Windows 10, становлять невелику частину інфраструктури інтернету речей типової лікарні, вони використовуються в одних з найбільш критичних відділах. Оскільки самі версії Windows в таких пристроях вже давно віджили своє, цей факт створює значний ризик для пацієнтів, які ними користуються. Але проблема в тому, що заміна машин, на яких працюють ці версії, у більшості випадків займе надто багато років.

Більшість медичних пристроїв інтернету речей використовуються настільки регулярно, що їх складно вчасно оновлювати. Майже 80% пристроїв інтернету речей у сфері охорони здоров’я щомісяця й навіть частіше використовуються для догляду за пацієнтами, що означає, що у них майже немає часу простою і на те, щоб служба кібер безпеки лікарні проаналізувала їх на предмет ризиків і можливих атак, застосувала останні доступні виправлення та здійснила сегментацію для захисту пристроїв у мережі.

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

Команда Google прояснила ситуацію довкола вразливості Apache Log4j

17 грудня 2021 року у своєму блозі Google Open Source Insights Team прояснили всю ситуацію довкола вразливості Apache Log4j. Вони пояснили, в чому полягає вразливість і який поточний прогрес у виправленні проблем екосистеми з відкритим кодом JVM. Також команда поділилася своїми думками про те, скільки часу може знадобитися, щоб цю вразливість було виправлено в усій екосистемі та на чому слід зосередитися далі.

9 грудня спільнота інформаційної безпеки дізналася про існування вразливості, яка має великий ступінь серйозності та потенційну широту впливу. Десятки тисяч програмних пакетів (артефактів, як вони називаються в екосистемі Java) і проектів використовують популярний інструмент журналювання, log4j, який, як виявилося, має в собі вразливість. Як пояснюють спеціалісти,вразливість дозволяє віддалено виконувати код, використовуючи функцію пошуку JNDI, відкриту бібліотекою журналювання log4j. У багатьох версіях бібліотеки експлуатована функція існувала за замовчуванням.

Виправлення вразливості Apache Log4j займе трохи часу

Не так давно розкриті вразливості log4j торкнулися понад 35 000 пакетів Java, що становить понад 8% репозиторію Maven Central. Оскільки репозиторій є найбільшим сховищем пакетів Java, це стало значною проблемою для багатьох фахівців індустрії програмного забезпечення. Фахівці зазначають, що 8% є величезним показником для екосистеми, в той час як середнє число для результату консультацій Maven Central складає 2%, з медіаною менше 0,1%. Хоча згадані числа не охоплюють всі пакети Java, наприклад безпосередньо розподілені бінарні файли.

На момент публікації було зафіксовано майже п’ять тисяч виправлених артефактів. І понад 30 000 артефактів, багато з яких залежать від іншого артефакту, і все ще чекають на виправлення. Команда завважує, що вони зараховували артефакт як виправлений, якщо він мав принаймні одну вражену версію, і було випущено більш стабільну виправлену версію (відповідно до семантичних версій). У випадку log4j артефакт вважається виправленим, якщо він був оновлений до версії 2.16.0 або вище і не залежить більше від log4j.

Дві серйозні проблеми заважають процесу виправлення

Хоча в цілому ситуація зрозуміла, фахівці вказують на дві істотні проблеми щодо її усунення. Перше це той факт, що багато артефактів опосередковано залежать від log4j. А ті, що мають пряму залежність, становлять близько 7000 вражених артефактів. В першому факті будь-яка з його версій залежить від ураженої версії log4j-core або log4j-api, описаних в CVE. Тобто це непряма залежність або транзитивна залежність, що означає, тавтологічно сказано, залежності власних залежностей.

Весь цей набір залежностей створює значні перешкоди у виправленні, якщо прослідкувати все це в ланцюжках залежностей. Тоді все стає зрозумілим: чим глибше вразливість, тим більше потрібно перебрати ланцюжків, щоб її усунути. Згідно з гістограмою графіків залежностей у більш ніж 80% пакетів вразливість залягає глибше ніж на один рівень. У більшості це п’ять рівнів нижче, а в деяких – навіть дев’ять. Процес виправлення в таких випадках вимагає спочатку перейти до найглибших залежностей, і далі поступово по всій кроні.

Команда Google прояснила ситуацію довкола вразливості Apache Log4j
Візуалізація прямих та непрямих залежностей

Відкритий діапазон дає можливість вибрати останню версію

Інша складність полягає у виборах на рівні екосистеми в алгоритмі розв’язання залежностей та умовах специфікації вимог. Практика відрізняється від такої, як в npm, де звичайно вказуються відкриті діапазони для вимог залежностей. Відкриті діапазони дають можливість вибрати останню випущену версію, яка задовольняє вимоги залежностей, тим самим виводячи в перший список оновленні версії. Користувачі отримують виправлену версію одразу після випуску виправлення, процес, який генерує залежності швидше.

«В екосистемі Java звичайною практикою є указання вимог до «м’яких» версій — точні версії, які використовуються алгоритмом розділення, якщо жодна інша версія того самого пакета не з’являється раніше на графіку залежностей. Виправлення часто вимагає додаткових дій з боку розробників, щоб оновити вимоги залежностей до виправленої версії», — також писала команда Open Source Insights щодо цього у своєму блозі.

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

Команда Google прояснила ситуацію довкола вразливості Apache Log4j
Візуалізація розподілення глибин залягання вразливості

На питання, скільки часу знадобиться, щоб повністю виправити все, команда висловилася неоднозначно. Якщо розглядати всі публічно доступні критичні рекомендації, що впливають на пакети Maven, то процес може зайняти деякий час. Вони кажуть, що менше половини (48%) артефактів, на які вплинула вразливість, було виправлено. Але що стосується log4j, то все здається багатообіцяючим: приблизно 13% було виправлено.

Найбільший тест з кібербезпеки показав, на що вразливі найпоширеніші маршрутизатори Wi-Fi

Наскільки кібербезпечні звичайні маршрутизатори Wi-Fi? У світі, де Інтернет це ще одне середовище існування людини, хто зна, що там може ховатися. А ваш маршрутизатор — це ваша фортеця. Редактори німецького журналу Chip і експерти з IoT Inspector провели тестування на вразливості в найбільш популярних маршрутизаторів. Результати виявилися негативними.

Дослідники протестували дев’ять найпопулярніших виробників маршрутизаторів

Однією з основних проблем, спільною для протестованих маршрутизаторів, стала застаріла операційна система, тобто ядро ​​Linux. Це цілком зрозуміло, оскільки інтеграція нового ядра в прошивку коштує занадто дорого. У кожного перевіреного виробника тут вийшов мінус. Також сюди спеціалісти віднесли програмне забезпечення пристроїв, в якому часто використовувалися такі стандартні інструменти, як BusyBox, що виявлялися застарілими у багатьох пристроях. Крім питань маршрутизації, основну частину негативних результатів також склали додатковий сервіс маршрутизаторів, як наприклад VPN або мультимедійні функції.

«Тест в негативному аспекті перевершив усі очікування щодо безпечності маршрутизаторів для малого бізнесу та домашнього використання. Не всі вразливості є однаково критичними, але на момент тестування всі пристрої виявили значні вразливості у безпеці, які можуть грунтовно полегшити роботу хакерам», – каже Флоріан Лукавський, технічний директор IoT Inspector.

Ретельне тестування безпеки в лабораторних умовах зрезультувало в 226 потенційних вразливостей у безпеці в TP Link, Linksys, Synology, D-Link, Netgear, Edimax, AVM і Asus. TP-Link (TP-Link Archer AX6000) і Synology (Synology RT-2600ac) разом показали 32 вразливості.

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

Дослідницька лабораторія IoT Inspector також додала детальний опис експерименту з вилучення ключів шифрування WI-FI маршрутизаторів

У своєму блозі дослідницька лабораторія IoT Inspector також додала детальний технічний опис того, як вони проводили експеримент з вилученння ключа шифрування для піднабору WI-FI маршрутизаторів D-Link під час тесту. Треба сказати, що це досить цікава річ для ознайомлення, навіть для комп’ютерних аматорів. Для дослідження вони використовували D-Link DIR-X1560, пристрій того ж покоління, що й D-Link DIR-X5460, який IoT Inspector протестував разом з маршрутизаторами інших виробників.

Очевидно, що дослідники не могли одразу вилучити ключ шифрування, тому їм потрібно було знайти певний обхідний шлях. У першому методі дослідники скористалися старішим образом мікропрограми, який ще не було зашифровано. Це версія мікропрограми безпосередньо перед введенням шифрування. Тут можна перевірити, чи можна звідси вилучити ключ.

Інший метод, який вони пропонують, – це безпосереднє зчитування фізичної флеш-пам’яті пристрою. Вони пояснили, що в флеш-прошивці навряд чи буде зашифрована прошивка. Схема працює так, що вони розбирають один із пристроїв, випаюють флеш-пам’ять, відкидають її та зчитують файлову систему. Однак вони додають, що цей метод грунтовно порушує цілісність пристрою, є витратним і дорогим. Повну інформацію про експеримент з вилучення ключів дешифрування для D-Link ви можете знайти за посиланням.