Частина 3. Загрози у світі речей інтернету (Методологія тестування безпеки)

IoT загрози: методологія тестування та стратегії оборони

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

За крок до зловмисників: підвищення безпеки у світі IoT

З чого почати, якщо ви хочете перевірити свою систему IoT на вразливості? Якщо поверхня атаки досить мала, як у випадку з одним веб-порталом, який керує камерою безпеки, то налаштувати перевірку безпеки може бути просто. Однак, коли команда тестувальників не дотримується встановленої методології, вона може пропустити критичні точки програми.

У цій главі наведено докладний перелік кроків, яких потрібно дотримуватися при тестуванні для подолання захисту. Для цього ми розділимо поверхню атаки IoT на логічні шари, як показано на рис. 3.1.

Під час тестування систем IoT, вам знадобиться надійна методологія оцінки, як ця, оскільки системи IoT часто складаються з багатьох взаємодіючих компонентів. Давайте розглянемо випадок, коли кардіостимулятор підключений до домашнього пристрою моніторингу. Пристрій моніторингу може відправляти дані пацієнта на хмарний портал через 4G-з’єднання, щоб лікарі могли перевірити наявність відхилень у пацієнта.

Медичний персонал також може налаштувати кардіостимулятор за допомогою програміста, який використовує модуль бездротового зв’язку ближнього поля (NFC) і власний протокол бездротового зв’язку. Ця система складається з багатьох частин, кожна з яких має потенційно значну поверхню атаки, яку сліпа, дезорганізована оцінка безпеки, швидше за все, не зможе успішно ідентифікувати. Щоб забезпечити успішне тестування, ми проведемо пасивне дослідження, а потім обговоримо методи тестування фізичного обладнання, мережі, веб-програми, хоста, мобільного додатка та хмари.

Пасивна розвідка

Пасивний інтелект, також званий  розвідкою з відкритих джерел (OSINT), являє собою процес збору цільових даних без безпосереднього зв’язку з системами. Це один з початкових кроків для будь-якої оцінки; Виконувати його потрібно завжди, щоб отримати уявлення про загальний стан справ. Наприклад, ви можете завантажити та вивчити інструкції до пристроїв та специфікації чіпсета,  Переглядайте онлайн-форуми та соціальні мережі або задавайте навідні запитання користувачам та технічному персоналу. Також можна збирати внутрішні імена хостів із сертифікатів TLS, виданих у результаті прозорості сертифікатів – стандарту, який вимагає від надійних центрів сертифікації записувати всю інформацію про видані сертифікати до публічних журналів, що дає змогу ідентифікувати помилково або зловмисно видані сертифікати.

Посібники та документи

Системні посібники можуть надати величезну кількість інформації про внутрішню роботу пристроїв. Їх зазвичай можна знайти на офіційному сайті виробника пристрою. Якщо це не допомогло, спробуйте розширений пошук у Google PDF-файлів, які містять назву пристрою, наприклад, виконавши пошук пристрою та додавши inurl:pdf до запиту.

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

Якщо ви визначили певні чіпсети, встановлені на апаратній частині, також варто пошукати відповідні паспорти (керівництва по електронним компонентам), так як вони можуть містити інформацію про контакти чіпсетів, використовуваних для налагодження (наприклад, інтерфейси налагодження JTAG, розглянуті в главі 7).

Ще одним корисним ресурсом для пристроїв, що використовують радіозв’язок, є  онлайнова база даних FCC ID (https://fccid.io/). Ідентифікатор FCC – це унікальний ідентифікатор, присвоєний пристрою, зареєстрованому у Федеральній комісії зв’язку США. Усі пристрої безпроводового випромінювання, що продаються в США, повинні мати ідентифікатор FCC. Здійснюючи пошук FCC ID конкретного пристрою, можна знайти детальну інформацію про робочу частоту бездротової мережі та потужність обладнання, внутрішні фотографії пристрою, інструкції користувача тощо. Ідентифікатор FCC зазвичай гравірується на корпусі електронного компонента або пристрою (рисунок 3.2).

Патенти

Патенти можуть надати інформацію про внутрішню роботу певних пристроїв. Спробуйте знайти назву постачальника на веб-сайті https://patents.google.com/  і подивіться, що з’явиться. Наприклад, пошук за ключовими словами «medtronic bluetooth» повинен привести вас до опису протоколу імплантованих медичних пристроїв (IMD), опублікованого в 2004 році.

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

Зверніть увагу, що стрілки входять і виходять із стовпця IMD. Віддалена системна дія Patient Action & Advice може ініціювати підключення до пристрою. Простеживши ланцюжок стрілок, зверніть увагу, що дія також може оновити програму пристрою для зміни налаштувань, які можуть завдати шкоди пацієнту. З цієї причини віддалена система створює ризики віддаленого злому, або через незахищений мобільний додаток, або через саму віддалену систему (зазвичай реалізується в хмарі).

Знання користувачів

Дивує те, скільки публічної інформації можна знайти в соціальних мережах, на онлайн-форумах і в чатах. Ви навіть можете використовувати огляди Amazon і eBay як джерела знань. Шукайте користувачів, які скаржаться на певні функції пристрою; Помилки в роботі іноді показують вразливість. Наприклад, ви можете зіткнутися зі скаргою користувача на збій пристрою за багатьох умов. Це вагомий привід для більш детального вивчення ситуації, оскільки це може бути логічна помилка або вразливість безпеки, яка спричиняє пошкодження пам’яті через введення певних даних або команд у пристрій.

Крім того, багато користувачів також публікують детальні огляди товару з характеристиками та зображеннями пристроїв у розібраному вигляді. Також перевірте профілі або публікації в LinkedIn і Twitter. Інженери та ІТ-спеціалісти, які працюють на виробників систем IoT, можуть розкрити цікаві технічні ідеї. Наприклад, якщо особа вказує, що має значний досвід роботи з певною архітектурою процесора, то дуже ймовірно, що багато пристроїв виробника побудовано з використанням цієї архітектури. Якщо інший співробітник описує (або, рідше, хвалить) певний фреймворк, швидше за все, компанія використовуватиме його для розробки програмного забезпечення. Як правило, у кожній галузі IoT є визнані експерти, до яких можна звернутися за корисною інформацією.

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

Фізичний або апаратний рівень

Одним з найважливіших векторів атаки в пристрої IoT є його апаратні компоненти. Отримавши доступ до апаратних компонентів системи, зловмисники часто підвищують свої привілеї користувача, оскільки система майже завжди беззастережно довіряє будь-кому, хто має фізичний доступ. Іншими словами, якщо зловмисник має фізичний доступ до ваших систем, ви можете припустити, що гра закінчена. Припустимо, що найбільш мотивовані суб’єкти загроз (наприклад, фінансовані державою з часом і практично необмеженими ресурсами) мають у своєму розпорядженні фізичну копію пристрою. Навіть коли мова йде про спеціалізовані системи, такі як великі апарати УЗД, зловмисники можуть отримати обладнання з онлайн-ринків, від компаній, які небезпечно утилізують пристрої або навіть крадуть. Їм навіть не потрібна точна версія пристрою.

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

Периферійні інтерфейси

Периферійні інтерфейси –  це фізичні комунікаційні порти, які дозволяють підключати зовнішні пристрої, такі як клавіатури, жорсткі диски і т. Д., А також мережеві карти. Перевірте, чи є активні USB-порти або слоти для PC-карт і чи є вони завантажувальними. Ми отримали доступ адміністратора до різних систем x86, завантаживши на пристрій власну операційну систему,  шляхом монтування незашифрованої файлової системи, вилучення зламаних хешів або паролів та встановлення нашого програмного забезпечення у файлову систему, щоб замінити технічні заходи безпеки. Також можна витягувати жорсткі диски і читати або записувати на них навіть без доступу до завантажувальних USB-портів, хоча цей спосіб менш зручний. Зверніть увагу, що несанкціоноване обладнання для вилучення дисків може призвести до пошкодження компонентів.

Атака може здійснюватися через USB-порти і з іншої причини: деякі пристрої, в основному на базі Windows, мають режим кіоску, в якому інтерфейс користувача має обмежені можливості. Розглянемо банкомат для зняття готівки; навіть якщо на ньому фактично запущена вбудована операційна система Windows XP, користувач бачить лише обмежений графічний інтерфейс з невеликим набором команд. Уявіть, що ви могли б зробити,  якби ви могли підключити USB-клавіатуру до відкритого порту на пристрої. За допомогою певних сполучень клавіш, таких як Ctrl+Alt+Delete або  клавіша Windows, ви можете вийти з режиму кіоску та отримати прямий доступ до решти системи.

Завантажувальне середовище

Для систем, які використовують звичайний BIOS (зазвичай це платформи x86 і x64), перевірте, чи встановлений пароль BIOS при завантаженні і який бажаний порядок завантаження. Якщо система спочатку намагається завантажитися зі знімного носія, ви можете завантажити операційну систему, не вносячи жодних змін до налаштувань BIOS. Крім того, перевірте, чи вмикає система та надає пріоритет Preboot Execution Environment перед завантаженням (PXE), що дозволяє клієнтам завантажувати операційну систему по мережі за допомогою комбінації DHCP і TFTP. Це залишає зловмисникам можливість налаштувати сервери завантаження з мережі-ізгоя. Навіть якщо послідовність завантаження надійно налаштована і всі настройки захищені паролем, ви в цілому можете скинути BIOS до стандартних, чистих і незахищених налаштувань (наприклад, тимчасово вийнявши батарею BIOS).

Якщо ваша система має захищене завантаження з уніфікованого розширюваного інтерфейсу мікропрограми (UEFI), оцініть його реалізацію. UEFI Secure Boot — це стандарт безпеки, який перевіряє, чи програмне забезпечення для завантаження не було змінено (наприклад, шляхом джейлбрейка). Для цього перевіряються підписи прошивки UEFI і драйверів операційної системи. Ви також можете зіткнутися з технологіями Trusted Execution Environment (TEE), такими як TrustZone на платформі Arm або функцією Secure Boot від Qualcomm Technologies, яка допомагає перевіряти безпечні образи завантаження.

Замок

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

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

Запобігання та виявлення несанкціонованого доступу

Переконайтеся, що пристрій захищено від несанкціонованого доступу. Один із способів його захисту – використовувати ярлики з перфорованою стрічкою, які вказують на факт розтину. Інші функції захисту від несанкціонованого доступу включають вкладки, затискачі, спеціальні кришки з епоксидним покриттям або фізичні запобіжники, які можуть стерти конфіденційні дані, якщо пристрій розібрати. Механізми виявлення вторгнень надсилають сповіщення або створюють файли журналу на пристрої, коли виявляють спробу порушити цілісність пристрою. Особливо важливо перевіряти безпеку та виявляти неавторизований доступ під час проведення корпоративного тестування на проникнення IoT. Багато загроз походять ізсередини – від співробітників, підрядників або колишніх співробітників – тому захист від несанкціонованого втручання може допомогти виявити будь-які підроблені пристрої. Зловмиснику буде складно демонтувати антитамперний пристрій.

Мікропрограма

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

Налагодження інтерфейсів

Переконайтеся, що у вас є  налагоджувальні інтерфейси, служби або тестові точки, які виробник може використовувати для спрощення розробки, виробництва та налагодження. Зазвичай ви знайдете ці інтерфейси у вбудованих пристроях і можете використовувати їх, щоб негайно отримати root-доступ. Ми не змогли б повністю зрозуміти багато пристроїв, які ми тестували, якби спочатку не відкрили кореневу оболонку в системах, взаємодіючи з налагоджувальними портами,  Тому що не було можливості отримати доступ і перевірити поточну систему. Спочатку це може вимагати певного знайомства з внутрішньою роботою протоколів зв’язку, що використовуються цими налагоджувальними інтерфейсами, але кінцевий результат, як правило, того вартий. Найпоширеніші типи інтерфейсів налагодження включають UART, JTAG, SPI та I2C.

Фізична стабільність

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

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

Мережевий рівень

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

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

Розвідувальний

Ми вже обговорювали кроки, які ви можете зробити для виконання пасивної розвідки на пристроях IoT в цілому. У цьому розділі ми описуємо активну і пасивну розвідку мереж, зокрема один з перших кроків для будь-якої мережевої атаки. Пасивна розвідка  може припускати прослуховування мережі корисних даних, тоді як активна розвідка (розвідка, що вимагає взаємодії з ціллю) вимагає безпосереднього опитування пристроїв.

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

Відкриття хоста

Виявлення хоста визначає, які системи запущено в мережі, перевіряючи їх різними методами. Ці методи включають відправку пакетів ехо-запитів протоколу управління Інтернетом (ICMP), виконання сканування TCP/UDP на публічних портах, прослуховування широкомовного трафіку в мережі або створення ARP-запиту для перевірки того, що хости знаходяться в одному сегменті L2. (L2 відноситься до рівня 2 моделі OSI комп’ютерної мережі. Це рівень каналу передачі даних, який відповідає за передачу даних між вузлами в одному сегменті мережі на фізичному рівні. Ethernet є загальним протоколом передачі даних.) Для складних систем IoT, таких як сервери, які контролюють камери спостереження, які охоплюють багато різних сегментів мережі, важливо не покладатися на якийсь конкретний метод. Використовуйте різні комбінації, щоб підвищити шанси обійти брандмауери або суворі конфігурації віртуальної локальної мережі (VLAN).

Цей крок може бути найбільш корисним у випадках, коли ми проводимо тест на проникнення IoT, не знаючи IP-адреси систем, що тестуються.

Для визначення версії послуги

Після визначення активних серверів визначте всі служби прослуховування. Почніть зі сканування портів TCP і UDP. Потім виконайте комбінацію захоплення банерів (підключення до мережевої служби та читання результатів, які вона повертає) і зондування за допомогою інструментів зняття відбитків пальців, таких як Amap або параметри -sV у Nmap. Пам’ятайте, що деякі служби, особливо медичні прилади, схильні до помилок навіть при простому тестуванні. Ми бачили, як системи Інтернету речей падають і просто перезавантажуються після їх аналізу за допомогою функції керування версіями Nmap. Цей сканер надсилає пакети, спеціально розроблені для отримання відповідей від певних типів служб, не надсилаючи жодної інформації під час підключення до них. Очевидно, що подібні пакети можуть спричинити нестабільність деяких чутливих пристроїв, оскільки ці пристрої не мають надійного вхідного сигналу для доступу до своїх мережевих служб, що призводить до пошкодження пам’яті та інших проблем. Спробуйте пізніше.

Ідентифікація операційної системи

Вам потрібно буде визначити точну операційну систему, запущену на кожному з хостів, що тестуються, щоб пізніше ви могли розробляти для них експлойти. Принаймні, визначте архітектуру (наприклад, x86, x64 або ARM). В ідеалі слід визначити точний рівень пакета оновлень операційної системи (для Windows) і версію ядра (для систем на базі Linux або Unix в цілому).

Ви можете визначити операційну систему через мережу, проаналізувавши відповіді хоста на спеціально створені пакети TCP, UDP та ICMP, процес, який називається відбитками пальців. Ці відповіді будуть дещо відрізнятися в реалізації мережевого стека TCP/IP в різних операційних системах. Наприклад, деякі старі системи Windows реагують на пакет зондування FIN з відкритим портом пакетом FIN/ACK; інші відповідають RST,  А треті взагалі не відповідають. Вивчивши статистику цих відповідей, можна створити профіль для кожної версії операційної системи, а потім використовувати ці профілі для їх ідентифікації. (Для отримання додаткової інформації див. Методи відбитків пальців TCIP/IP, які підтримуються  Nmap  у документації Nmap.)

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

Складання топологічної карти мережі

Карта топології моделює зв’язки між різними системами в мережі. Цей крок використовується, коли вам потрібно протестувати цілу екосистему пристроїв і систем, деякі з яких можуть бути підключені через маршрутизатори та брандмауери, і не обов’язково на одному сайті L3. (L3 відноситься до рівня 3 моделі комп’ютерних мереж OSI. Це мережевий рівень; він відповідає за передачу та маршрутизацію пакетів. Рівень 3 вступає в дію, коли дані передаються через маршрутизатори.) Створення карти мережі перевірених активів стає корисний для моделювання загроз: він дозволяє побачити, як атака, яка використовує ланцюжок уразливостей на кількох серверах, може призвести до компрометації активів.Наскільки важливим є продукт? У смокінгу. На рисунку 3.4 показана діаграма топології високого рівня.

Ця абстрактна карта мережі показує пацієнта з імплантованим медичним пристроєм, який спілкується з домашнім пристроєм моніторингу. Домашній пристрій, в свою чергу, використовує локальне Wi-Fi з’єднання для відправки діагностичних даних в хмару, де лікар періодично стежить за ним для виявлення аномалій.

Атаки на мережевий протокол і сервіси

Атаки на мережеві протоколи і сервіси складаються з наступних етапів: сканування вразливостей, аналіз мережевого трафіку, реверс-інжиніринг і робота протоколу або служби. Ви також можете виконувати сканування вразливостей незалежно від інших кроків, в іншому випадку вам потрібно виконувати кроки послідовно.

Сканування вразливостей

Почніть із перевірки таких баз даних, як National Vulnerability Database (NVD) або VulnDB, на наявність відомих уразливостей у відкритих мережевих службах. Іноді система настільки застаріла, що звіт автоматичного інструменту виявлення вразливостей займає кілька сторінок. Ви навіть можете використовувати деякі вразливості віддалено без автентифікації. Запустіть принаймні один інструмент сканування, щоб швидко виявити наявні вразливості. Якщо ви виявите серйозну вразливість, наприклад віддалене виконання коду, ви зможете отримати доступ до оболонки командного рядка на пристрої. Завжди контролюйте середовище сканування та уважно стежте за неочікуваним простоєм.

Аналіз мережевого трафіку

На початку процесу оцінки безпеки використовуйте інструмент перехоплення трафіку, такий як Wireshark або tcpdump, щоб працювати деякий час, щоб дати вам уявлення про використовувані протоколи зв’язку. Якщо система IoT включає різні взаємодіючі компоненти, такі як камера спостереження з її сервером або інфузійний насос з електронною медичною карткою (EHR), ви зможете захопити будь-який мережевий трафік між ними. Відомі атаки, такі як отруєння кешем ARP, зазвичай вдається здійснити на одному сегменті L3.

В ідеалі, ви також повинні запускати ці інструменти збору трафіку безпосередньо на пристроях, щоб захопити потенційний трафік міжпроцесної комунікації (IPC) на локальному хості. У вас можуть виникнути труднощі з їх запуском на вбудованих пристроях, на яких зазвичай не встановлено ці інструменти, оскільки немає простого процесу їх налаштування. Але нам часто вдавалося перехресно компілювати та встановлювати такі інструменти, як tcpdump, навіть на пристроях з дуже обмеженими адміністративними ресурсами, таких як домашні системи моніторингу кардіостимуляторів. Ми продемонструємо це в розділі 6.

Після того, як ви підготували репрезентативну вибірку мережевого трафіку, можна приступати до її аналізу. Визначити, чи використовуються незахищені канали зв’язку: протоколи відкритого тексту; Відомі вразливі протоколи, такі як набір мережевих протоколів Universal Plug and Play (UPnP). і власні протоколи, які потребують подальшого вивчення, або можуть бути перероблені (розглянуті в наступному розділі).

Реверс-інжиніринг протоколів зв’язку

Вам потрібно переосмислити (переробити) будь-який власний протокол зв’язку, який ви знайдете. Створення нових протоколів — це завжди палка з двома кінцями; Деяким системам потрібен власний стек протоколів для забезпечення продуктивності, функціональності чи навіть безпеки. Але розробити та розгорнути надійний протокол часто досить важко. Більшість систем Інтернету речей, які ми бачили, використовують TCP або UDP і побудовані на їх основі, часто з використанням деяких варіантів XML, JSON або іншої структурованої мови. У складних випадках ми стикалися з пропрієтарними бездротовими протоколами з невеликою загальнодоступною інформацією, як-от ті, що містяться в імплантованих кардіостимуляторах. У таких випадках легше вивчати протоколи з іншої точки зору. Наприклад, спроба налагодити системні служби, які взаємодіють з рівнем драйвера, відповідальним за передачу радіосигналів. Тому вам не потрібно аналізувати власний бездротовий протокол. Натомість ви можете зрозуміти, як це працює – зрозуміти рівень безпосередньо над ним.

Ми використовували цей метод при оцінці кардіостимулятора. Для цього вони вдавалися до таких інструментів, як траса, прикріплена до процесів, які взаємодіють з шаром водія. Аналізуючи журнали та файли pcap, ми визначили основний канал зв’язку без аналізу радіосигналів або інших трудомістких методів, таких як перетворення Фур’є, що застосовуються до власного бездротового каналу. Перетворення Фур’є розкладає сигнали на складові частоти.

Експлойти за протоколом або службою

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

Тестування бездротового протоколу

Ми присвячуємо цілий розділ цієї глави тестуванню бездротових протоколів, враховуючи поширеність радіопротоколів короткого, середнього та дальнього радіусу дії в екосистемах IoT. Цей рівень може збігатися з тим, що інші видання називають «шаром сприйняття» і включає такі технології розпізнавання, як радіочастотна ідентифікація (RFID), система глобального позиціонування (GPS) і стандарт зв’язку ближнього поля (NFC).

Процес аналізу цих технологій перетинається з діями на мережевому рівні, описаними вище (див. підрозділи «Аналіз мережевого трафіку» і «Протоколи зворотної інженерії»). Аналіз і атака бездротових протоколів зазвичай вимагає спеціального обладнання, включаючи: певні чіпсети Wi-Fi з можливістю введення даних, такі як Atheros; USB-Bluetooth модулі, такі як Ubertooth; Програмно-визначені радіостанції (SDR), такі як HackRF або LimeSDR.

На цьому етапі ви спробуєте конкретні атаки, специфічні для конкретного бездротового протоколу, який ви використовуєте. Наприклад, якщо будь-які компоненти IoT використовують Wi-Fi, тестові атаки на основі підміни користувача або вразливостей у протоколі WEP (Wired Equivalent Privacy) (він буде виділений червоним прапорцем, оскільки його легко зламати) та реалізації незахищеного захищеного доступу Wi-Fi (WPA/WPA2) зі слабкими обліковими даними. WPA3 незабаром може потрапити в цю категорію незахищених протоколів. Ми розглянемо найважливіші атаки на ці протоколи в розділах 10-13. Для користувацьких протоколів слід перевіряти відсутність аутентифікації (включаючи відсутність взаємної аутентифікації) та відсутність шифрування та перевірки цілісності – те, що, на жаль, ми бачимо досить часто, навіть у пристроях критичної інфраструктури.

Оцінка веб-додатків

Веб-додатки, включаючи ті, що використовуються в системах IoT, забезпечують одну з найпростіших точок входу в мережу, оскільки вони часто доступні ззовні і мають багато вразливостей. Оцінка веб-додатків – це величезна тема, і існує величезна кількість ресурсів, які допоможуть вам зробити саме це. Отже, ми зосередимося на методах, які застосовуються саме до веб-додатків, що використовуються в пристроях IoT. Насправді вони істотно не відрізняються від будь-яких інших існуючих Але часто відомо, що ті, що знаходяться на вбудованих пристроях, не мають безпечного життєвого циклу розробки програмного забезпечення, що призводить до очевидних і відомих вразливостей. Ресурси для  тестування веб-додатків включають Довідник хакера веб-додатків та всі проекти OWASP,  які включають Список 10 найкращих ризиків, Стандарт перевірки безпеки додатків (ASVS) та Посібник з тестування OWASP.

Картографування додатків

Щоб зіставити веб-застосунок, спочатку перевірте видимий, прихований і вміст веб-сайту за замовчуванням. Визначте точки введення даних і приховані поля і перерахуйте всі параметри. Засоби автоматизованого сканування (програмне забезпечення для аналізу даних, яке сканує веб-сайти на одну сторінку за раз) можуть допомогти прискорити цей процес, але ви також завжди повинні переглядати сайти вручну. Ви можете використовувати перехоплюючий проксі для пасивного сканування (моніторинг веб-контенту при перегляді вручну) і як  активного сканування  (активне сканування сайту з використанням раніше виявлених URL і вбудованих JavaScript запитів AJAX в якості відправних точок).

Ви можете виявити прихований вміст або кінцеві точки веб-додатків, які зазвичай недоступні через видимі гіперпосилання, спробувавши ввести загальні назви папок і імена/розширення файлів на панелі. Зауважте, що це може бути досить помітною активністю, оскільки всі ці запити створюватимуть багато мережевого трафіку. Наприклад, середній список типових імен папок і файлів для інструмента веб-аналітики DirBuster містить 220 560 записів. Це означає, що якщо ви його використовуєте, він надішле принаймні 220 560 HTTP-запитів до об’єкта в надії виявити приховані URL-адреси. Але цей крок не можна пропускати, особливо якщо оцінка виконується в контрольованому середовищі. Іноді ми бачимо дуже цікаві, часто неавтентифіковані кінцеві точки веб-додатків на пристроях IoT. Наприклад, одного разу ми виявили приховану URL-адресу для популярної моделі камери спостереження, яка дозволяє робити знімки без автентифікації, по суті дозволяючи зловмиснику віддалено контролювати, на що спрямована камера!

Також важливо визначити точки входу, де веб-додаток може отримувати призначені для користувача дані. Більшість вразливостей у веб-додатках виникають через те, що додаток отримує ненадійні вхідні дані від неавтентифікованих віддалених учасників. Ви можете використовувати ці точки входу пізніше для розмивання (автоматичний спосіб надання неправильних випадкових даних як вхідних даних) і протестувати реалізацію.

Елементи керування на боці клієнта

Ви можете використовувати елементи керування на стороні клієнта, тобто все, що обробляється браузером, локальною програмою або мобільним пристроєм. Елементи керування на стороні клієнта можуть бути прихованими полями, файлами cookie та програмами Java. Іншими прикладами є JavaScript, AJAX, ASP.NET ViewState, ActiveX, Flash або Silverlight. Наприклад, ми бачили багато веб-додатків на вбудованих пристроях, які виконують автентифікацію користувача на стороні клієнта, яку зловмисник може обійти, оскільки користувач може контролювати все, що відбувається на стороні клієнта. Пристрої використовували файли JavaScript або .jar, .swf і .xap, які зловмисники могли декомпілювати та змінювати для виконання свого завдання.

Автентифікація

Шукайте уразливості в механізмі аутентифікації програми. Добре відомий факт, що величезна кількість систем IoT поставляється з незахищеними попередньо налаштованими обліковими даними, і що користувачі часто залишають ці облікові дані незмінними. Ці облікові дані можна знайти, звернувшись до посібників або інших онлайн-ресурсів, або просто методом вибору. При тестуванні систем IoT нам доводилося стикатися з парами логін/пароль, починаючи з популярного адмін/адмін і закінчуючи a/a (так, ім’я користувача “a”, пароль “a”!), а іноді аутентифікація взагалі не використовувалася. Щоб зламати нестандартні паролі, виконайте атаки методом грубої сили словника на всі кінцеві точки автентифікації. Такі атаки використовують автоматизовані засоби для перебору паролів з використанням найпоширеніших словникових слів або списків паролів, отриманих в результаті витоків. Майже кожен звіт про оцінку безпеки, який ми складаємо, включає “відсутність захисту грубою силою”, вбудовані пристрої IoT часто мають обмежені апаратні ресурси і можуть не зберегти стан, як повинні програми SaaS.

Крім того, перевірте наявність небезпечної передачі облікових даних (яка зазвичай включає доступ HTTP за замовчуванням, без переспрямування на HTTPS); перевірити всі функції «Забули пароль» і «Запам’ятати мене»; Перерахування імен користувачів (вгадування та список дійсних користувачів). Шукайте умови відкритого збою, які не можуть пройти автентифікацію, але через деякий виняток програма надає публічний доступ.

Управління сесіями

Сеанси веб-додатків – це послідовності транзакцій HTTP, пов’язаних з одним користувачем. Управління сеансом або процес відстеження цих транзакцій HTTP може стати складним, тому перевірте ці процеси на наявність недоліків. Перевірте використання передбачуваних токенів, небезпечну передачу токенів та розкриття токенів у журналах. Ви також можете виявити недостатній час сеансу, вразливості сеансових фіксацій та атаки підробки міжсайтових запитів (CSRF), коли ви Автентифікованими користувачами можна маніпулювати для виконання небажаних дій.

Контроль доступу та авторизація

Далі переконайтеся, що елементи керування доступом застосовано до сайту правильно. Поділ на рівні користувача або практика надання користувачам з різними привілеями доступу до різних даних або функцій є загальною особливістю пристроїв IoT. Інша назва цієї тактики — контроль доступу на основі ролей (RBAC). Особливо часто використовується в складних медичних системах. Наприклад, у системі доступу до електронних медичних записів лікарі отримують більш привілейований доступ, ніж медсестри, яким можна призначити лише доступ для читання. Так само система камери матиме принаймні один обліковий запис адміністратора, уповноважений змінювати параметри конфігурації, і менш привілейований обліковий запис лише для перегляду, який дозволяє оператору пристрою переглядати канал камери. Але щоб ця система працювала, потрібно використовувати відповідний контроль доступу. Ми бачили системи, які можуть запитувати привілейовану дію від непривілейованого облікового запису, просто знаючи правильну URL-адресу або HTTP-запит. Якщо система підтримує кілька облікових записів, перевірте всі обмеження привілеїв. Наприклад, чи можуть облікові записи гостей отримати доступ до функцій веб-програми, якими мають користуватися лише адміністратори? Чи може гостьовий обліковий запис отримати доступ до API адміністратора, яким керує інша структура авторизації?

Перевірка введення

Переконайтеся, що додаток належним чином перевіряє та очищає введені користувачем дані для всіх точок входу. Ця дія має вирішальне значення, оскільки найпопулярнішим типом уразливості веб-додатків є вхідні дані, в яких користувачі можуть надсилати свій власний код до програми під виглядом даних користувача (див. “10 найкращих ризиків IoT” з пакету документації OWASP). Перевірка введення програми може зайняти дуже багато часу, оскільки вона включає в себе тестування всіх типів вхідних атак, включаючи SQL-ін’єкцію, міжсайтові сценарії (XSS), ін’єкцію команд операційної системи та зовнішню ін’єкцію об’єктів XML (XXE).

Логічні помилки

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

Сервер додатків

Переконайтеся, що сервер безпечно розміщує програму. Захищена веб-програма, розміщена на незахищеному сервері програм, втрачає свої можливості безпеки. Тестування безпеки сервера: використовуйте сканери вразливостей для виявлення помилок сервера додатків і відкритих уразливостей. Також слідкуйте за атаками десеріалізації та переконайтеся, що брандмауери веб-додатків надійні. Переконайтеся, що сервер налаштовано правильно, як-от списки каталогів, вміст за замовчуванням і ризиковані методи HTTP. Ви також можете оцінити надійність SSL/TLS, шукаючи слабкі шифри, самопідписані сертифікати та інші поширені вразливості.

Досліджуйте конфігурацію хоста

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

Облікові записи

Перевірте, наскільки безпечно налаштовані облікові записи користувачів у системі. Цей крок включає перевірку наявності облікових записів користувачів за замовчуванням і перевірку стійкості політик облікового запису. Такі політики включають історію паролів (чи можна використовувати старі паролі, і якщо так, то коли їх можна використовувати повторно), термін дії пароля (як часто система змушує користувачів змінювати паролі) і механізми блокування (скільки спроб введення облікових даних дається користувачеві до того, як система заблокує його доступ до облікового запису). Якщо пристрій IoT належить до корпоративної мережі, враховуйте політику безпеки компанії, щоб забезпечити узгодженість облікового запису. Наприклад, якщо політика безпеки організації вимагає від користувачів змінювати свої паролі кожні шість місяців, переконайтеся, що всі облікові записи відповідають цій політиці. В ідеалі, якщо система дозволяє інтеграцію облікового запису з Active Directory або LDAP, компанія зможе централізовано застосовувати ці політики через сервер.

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

Надійність пароля

Перевірте надійність пароля облікового запису користувача. Надійність пароля важлива, оскільки зловмисники можуть вгадати слабкі облікові дані за допомогою автоматичних засобів. Переконайтеся, що вимоги до складності пароля дотримані через локальну або групову політику в Windows і автентифікацію плагіна (PAM) у системах Linux, з одним застереженням: вимоги до автентифікації не будуть виконані. впливає на робочий процес. Розглянемо такий сценарій: хірургічна система використовує складний 16-символьний пароль і блокує користувачеві доступ до облікового запису після трьох неправильних спроб. Це легкий шлях до катастрофи, коли хірург або медсестра опиняються в екстреній ситуації й не мають іншого способу автентифікації в системі. У тих випадках, коли на кону стоїть момент і життя пацієнта, система безпеки не повинна стати непереборною перешкодою.

Привілеї облікового запису

Переконайтеся, що облікові записи та сервіси налаштовані за принципом найменших привілеїв – іншими словами, вони можуть отримати доступ лише до необхідних ресурсів, і не більше того. Зазвичай ми бачимо погано налаштоване програмне забезпечення без детального поділу привілеїв. Наприклад, часто основний процес не скидає підвищені привілеї, коли вони йому більше не потрібні, або система дозволяє запускати різні процеси під одним обліковим записом. Ці процеси, як правило, вимагають доступу лише до обмеженого набору ресурсів, і якщо правило обмеження не дотримується, вони накопичують занадто багато привілеїв; Після компрометації вони дають зловмиснику повний контроль над системою. Ми також часто знаходимо прості служби журналювання, що працюють із правами SYSTEM або root. «Надмірний ризик привілеїв» – це примітка, яку ми робимо майже в кожному звіті про оцінку безпеки, який ми робимо.

Зокрема, в системах Windows проблему можна вирішити за допомогою потужності облікових записів керованих служб, які дозволяють ізолювати облікові записи доменів, що використовуються критичними додатками, і автоматизувати управління їх обліковими даними. У системах Linux використання механізмів безпеки, таких як можливості, seccomp, SELinux та AppArmor, допоможе обмежити привілеї процесу та посилити безпеку операційної системи. Крім того, такі рішення, як Kerberos, OpenLDAP і FreeIPA, корисні для управління обліковими записами.

Рівні патчів

Переконайтеся, що операційна система, програми та всі сторонні бібліотеки оновлені та регулярно оновлюються. Патчі важливі, складні і часто недооцінені. Тестування застарілого програмного забезпечення може здатися рутинним завданням (яке зазвичай можна автоматизувати за допомогою інструментів сканування вразливостей), але повністю оновлену екосистему майже ніде ви не знайдете. Для виявлення компонентів з відкритим вихідним кодом з відомими вразливостями використовуйте інструменти аналізу складу програмного забезпечення, які автоматично перевіряють сторонній код на відсутність патчів. Для виявлення відсутніх патчів для операційної системи ви можете покладатися на аутентифіковані сканування вразливостей або навіть перевіряти їх вручну. Не забудьте перевірити, чи підтримують постачальники пристроїв IoT останню версію ядра Windows або Linux; Ви не раз переконаєтеся, що це не так.

Компоненти системи оновлення є одним з недоліків індустрії інформаційної безпеки і особливо світу Інтернету речей. Одна з головних причин полягає в тому, що вбудовані пристрої за своєю суттю більше піддаються змінам: в них часто використовуються складні, незмінні прошивки. Інша причина полягає в тому, що оновлення та виправлення деяких систем, таких як банкомати, на регулярній основі може бути непомірно дорогим через високу вартість простою (час, коли клієнти не можуть отримати доступ до системи) та обсяг роботи. Для вузькоспеціалізованих систем, таких як медичні пристрої, постачальник повинен спочатку провести ретельне тестування, перш ніж випускати новий патч. Ви не хочете, щоб аналізатор крові давав помилково позитивний результат у тесті на гепатит через помилку з плаваючою комою, спричинену останнім оновленням! А як щодо оновлення імплантованого кардіостимулятора? Оновлення повинно бути буквально питанням життя і смерті, щоб виправдати виклик кожного пацієнта до лікаря для вирішення проблеми.

Під час тестування ми часто бачимо, що стороннє програмне забезпечення використовується без оновлень, навіть якщо основні компоненти актуальні. Типовими прикладами в Windows є Java, деякі продукти Adobe і навіть Wireshark. Застарілі версії OpenSSL поширені на пристроях Linux. Іноді програмне забезпечення встановлюється без певної мети, і краще видалити його, а не намагатися встановити для нього процес виправлення. Навіщо інсталювати Adobe Flash на сервер, який обмінюється даними з апаратом УЗД?

Віддалене обслуговування

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

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

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

Управління доступом до файлової системи

Переконайтеся, що принцип надання найменших привілеїв, згаданий раніше в цій главі, застосовується до ключових файлів і каталогів. Часто користувачі з низькими привілеями можуть читати і записувати важливі каталоги і файли (наприклад, службові виконувані файли), що спрощує атаки ескалації привілеїв. Чи дійсно неадміністраторам потрібен доступ на запис до C:\Program Files? Чи потрібен користувачам доступ до /root? Одного разу ми оцінювали вбудований пристрій з декількома сценаріями запуску, які були доступні для модифікації звичайними користувачами, що дозволило зловмиснику використовувати локальний доступ для запуску власних програм в якості root і отримання повного контролю над системою.

Шифрування даних

Переконайтеся, що конфіденційні дані зашифровано. Спочатку визначте найбільш конфіденційні дані, такі як захищена  медична інформація (PHI) або ідентифікаційна інформація. PHI включає будь-які записи про здоров’я, надання або оплату медичних послуг, тоді як PII (особиста інформація) – це  будь-які  дані, які потенційно можуть ідентифікувати конкретну особу. Переконайтеся, що ці дані зашифровані, перевіривши конфігурацію системи на наявність криптографічних примітивів. Якщо комусь вдалося вкрасти накопичувач пристрою, чи зможе він прочитати дані? Чи застосовується це Повнодискове шифрування, шифрування бази даних або будь-яке інше шифрування, і наскільки воно криптографічно надійне?

Неправильна конфігурація сервера

Неправильно налаштовані служби можуть бути небезпечними. Наприклад, ви все ще можете знайти FTP-сервери, гостьовий доступ до яких увімкнено за замовчуванням, що дозволяє зловмисникам анонімно підключатися та читати або записувати до певних папок. Одного разу ми виявили Oracle Enterprise Manager, що працює як СИСТЕМА і доступний віддалено з обліковими даними за замовчуванням, що дозволяло зловмисникам виконувати команди операційної системи, зловживаючи процедурами, що зберігаються в Java. Ця уразливість дозволила зловмисникам повністю зламати систему через мережу.

Мобільний додаток та хмарне тестування

Перевірте безпеку будь-якого мобільного додатка, пов’язаного з системою IoT. У наші дні розробники часто створюють програми, які працюють на Android та iOS для чого завгодно – навіть для кардіостимуляторів! Для отримання додаткової інформації про тестування безпеки мобільних додатків дивіться Розділ 14. Крім того, ознайомтеся з 10 найкращими мобільними додатками OWASP, посібником з тестування мобільної безпеки  та Стандарт перевірки безпеки мобільних додатків.

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

Також оцініть стан безпеки будь-якого хмарного компонента, пов’язаного з системою Інтернету речей. Дослідіть сумісність між хмарою та компонентами IoT. Зверніть пильну увагу на серверні API та реалізації на хмарних платформах, включаючи, але не обмежуючись ними, AWS, Azure та Google Cloud Platform. Уразливості, пов’язані з незахищеними прямими посиланнями на об’єкти, є загальними(IDOR), які дозволяють будь-кому, хто знає правильну URL-адресу, отримати доступ до конфіденційних даних. Наприклад, AWS іноді дозволяє зловмиснику отримати доступ до так званих сегментів S3, використовуючи URL-адресу, пов’язану з об’єктами даних, які містить сегмент.

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

Нам вдалося виявити ряд хмарних сервісів з уразливостями: жорстко закодовані хмарні токени, ключі API, вбудовані в мобільні додатки та двійкові файли прошивок, відсутність закріплення сертифікатів TLS та вразливість служб інтранету (таких як неавтентифікований сервер кешу Redis або служба метаданих) для громадськості через неправильну конфігурацію. Майте на увазі, що для проведення будь-якого тестування в хмарі вам потрібен дозвіл власника хмарних сервісів.

Висновок

Деякі члени нашої команди працювали у відділах кіберзахисту збройних сил. Там ми дізналися, що due diligence є одним з найважливіших аспектів інформаційної безпеки. Важливо дотримуватися методики тестування безпеки, щоб не пропустити деякі очевидні речі. Легко пропустити наявні вразливості просто тому, що вони здаються занадто простими.

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

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

Ми використовували матеріали з книги “The Definitive Guide to Attacking the Internet of Things ”, яку  написали Фотиос Чанцис, Иоаннис Стаис,
Паулино Кальдерон, Евангелос Деирменцоглу и Бо Вудс.