Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Управління поверхнею атаки через аналіз прошивки — як це працює

Всім привіт! Мене звати Андрій Михалюк, CEO компанії CoreWin, сертифікований інженер Data Loss Prevention, сертифікований спеціаліст веббезпеки, автор вебхакатону для «білих» хакерів, спікер та автор статей на тему інформаційної безпеки.

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

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

Управління поверхнею атаки через аналіз прошивки

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

Цей запит ринку, схоже, прекрасно зрозуміли люди, що стоять за, на мою думку, напрочуд інноваційним підходом до управління поверхнею атаки. Це фахівці, які багато років самі займались кібербезпекою та бачили всі процеси з середини — Карміт Ядін (Carmit Yadin), доктор науки у сфері управління інформаційною безпекою. Вона є однією з розробників рішення DeviceTotal, яке і втілило в собі новий підхід до забезпечення захисту сучасних систем.

Новий підхід має два основні концептуальні блоки функціонування, про які я розповім далі у статті:

  1. Аналіз прошивки обладнання в мережі.
  2. Управління поверхнею атаки.

Аналіз виконуваного коду обладнання в мережі

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

Постачальник (вендор) підтримує деякі компоненти та бібліотеки через оновлення прошивки, але виробники обладнання часто ними нехтують, сповідуючи підхід «працює — не лізь». Зрозуміло, що такі моменти становлять невідому загрозу для пристрою.

Як ми бачимо, найбільші атаки все частіше відбуваються методом Supply Chain Attack. Прикладом може слугувати резонансна вразливість SolarWinds, про яку стало відомо в кінці 2020 року, і яка скомпрометувала мережі сотні організацій.

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

На момент публікації цієї статті існує близько 183 тисяч поширених вразливостей та ризиків (далі — CVE) в цій базі. Все, що представлено у NVD, має бути відомим і розкритим, але як щодо тих вразливостей, про які знають одиниці, оскільки вони не були широко розголошені?

Часто, коли вразливість розкривається та вже з’являється у NVD, її виправляють протягом кількох місяців.

Наприклад, у серпні 2018 року у NVD була розкрита та призначена нова вразливість Remote Code Execution для бібліотеки Apache Struts. Однак цю вразливість було знайдено та виправлено ще у квітні 2018 року. Якби хтось переглядав логи репозиторію бібліотеки, він міг би знати про цю потенційну вразливість за кілька місяців до того, як громадськість дізналася про неї.

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

Традиційний, наявний підхід до безпеки

Аналіз складу програмного забезпечення (SCA) традиційно працював наступним чином.

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

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

Новий підхід: Contextual Risk Analyzer (CRA)

Складові технології:

  • Сканування бінарних файлів.
  • Визначення застосованих компонентів з відкритим кодом.
  • Збіг з відомими (і розкритими) вразливостями NVD.
  • Доповнення даними з інших ресурсів: сайтів GNU, блогів, закритих чатів, дарквебу, ін.
  • Пошук ще не розкритих шляхів експлуатації (пошук нерозкритих вразливостей).
  • Формування контексту знахідок відповідно до конкретної мережі.
  • Розрахунок ризику відповідно до системи показників CVSS (Common Vulnerability Scoring System).

Управління поверхнею атаки

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

Виходячи з цього, система управління поверхнею атаки (ASM — Attack Surface Management) орієнтується на методології оцінки вразливості поверхні атаки (надалі — ASV — Attack Surface Vulnerability).

ASV використовує рекомендації CVSS для створення спільної мови з поточними базами даних вразливостей і перекладає відомі показники вразливості на рівень пристрою. Цей новий підхід дозволяє отримати чітке уявлення про безпеку пристрою.

Базовий показник ASV ґрунтується на всіх відомих вразливостях, пов’язаних з пристроєм, нерозкритих програмних компонентах, прихованих у програмних елементах пристрою, та їх контекстних вразливостях, а також стані пристрою.

Розберемо, які метрики використовуються в підході та як вони впливають на остаточну оцінку ASV.

Базові метрики

Оцінка вразливості поверхні атаки — це узагальнення оцінки CVSS, розбитої на 8 основних показників:

  • вектор атаки;
  • складність атаки;
  • необхідні привілеї;
  • взаємодія з користувачем;
  • область безпеки;
  • конфіденційність;
  • цілісність;
  • доступність.

Статичний калькулятор ASV об’єднує дані із зовнішніх баз даних про вразливості та файли прошивки, проскановані на наявність внутрішніх програмних компонентів. Ці компоненти потім аналізуються в контексті інших відомих CVE для створення оцінки вразливості.

Часові метрики

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

  • Зрілість коду експлойту: не визначено | Високий | Функціональний | На тестуванні | Недоведений.
  • Рівень відновлення: не визначено | Недоступно | Обхідний шлях | Тимчасове виправлення | Офіційне виправлення.
  • Реальність вразливості: не визначено | Підтверджено | Ймовірно | Невідомо.

Метрики середовища

Ці показники дозволяють проаналізувати та адаптувати оцінку CVSS залежно від важливості відповідного ІТ-активу для організації користувача, що вимірюється з точки зору додаткових/ альтернативних засобів контролю безпеки, конфіденційності, цілісності та доступності. Такі показники є модифікованим еквівалентом базових показників і їм призначаються значення на основі розміщення компонентів в організаційній інфраструктурі.

Описані вище метрики доповнюються інформацією про цілісність систем, доступність систем ззовні та всередині мережі, рівень конфіденційності (таємності) мережі чи підсистеми. Це дозволяє сформувати:

  • Модифікований вектор атаки (MAV).
  • Змінену складність атак (MAC).
  • Модифіковані привілеї, необхідні для атаки (MPR).
  • Змінену взаємодію користувача (MUI).
  • Змінену область застосування (MS) [X,U,C].
  • Змінену конфіденційність (MC) [X,N,L,H].
  • Змінену цілісність (MI) [X,N,L,H].
  • Змінену доступність (MA).

Контекстна оцінка ризику

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

На завершення

Якщо до цього моменту мені не вдалось переконати вас в інноваційності підходу — ось вам останній аргумент. Описане тут рішення — безагентне. Так, взагалі жодних агентів. Не потрібно ніякого додаткового обладнання чи ПЗ. Не потрібно мережевої установки.

А натомість ви отримуєте поглиблений аналіз ризиків на трьох рівнях: пристрій, сайт та організація. Вражає, чи не так?

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Перекладу українською: методика оцінки за поверхнею атаки — це середня температура по лікарні. В середньому у нас 36.6°, а в реальності — два трупи.

Взагалі-то підхід правильний, але за двох умов:
1) Ви постійно відслідковуєте коливання кількісної оцінки показника. Бо вони змінюються з часом, і досить раптово. Приклад: якийсь експлойт став загальнодоступним.
2) Ви таки вмієте створювати формулу, за якою оцінювати вплив конкретного показника на вразливість. Просто їх скласти арифметично — то вселенська тупість. Це може бути коефіцієнт. Це може бути коефіцієнт, якому потрібен свій коефіцієнт впливу. Це може бути показником ступеню сумісно із показником впливу.

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

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

Сам процес оцінки віддати на аутсорс неможливо. Але можливо інсорсити середовище оцінки, тобто, надати сервіс, який таку оцінку дозволятиме.

Технічно можливо аутсорсити й саме відслідковування ризиків — але лише технічно. Людський фактор проти такого аутсорсу. Це лише в ідеальній системі ідеальні люди будуть ідеально виконувати свої обов′язки та не робити шкоди. Реальні люди вимагають жорстких стимулів, інакше будуть усе робити «на від’ї**сь», наймуть найдешевший персонал, та навіть вчити не стануть — і по мірі текучки персоналу процес виродиться в ритуал. А ще у будь-який процес з великою текучкою кадрів легко потрапляють зацікавлені особи — і вуаля, системі оцінки ризику згодували завідомо невірні показники, в той час як «потрібним людям» миттєво полетів сигнал про відкриття 0-денного експлойту.

Не певен що читачам потрібен переклад :)

Дійсно, вся суть підходу в постійному контролі. Наявна реальність диктує таку необхідність. Консенсус спільноти впевнено рухається в сторону постійного моніторингу (навіть в такій сфері, як перевірка безпеки black-box перестала бути разовою річною задачею).

Титул вселенської тупості — це дуже почесне звання, звісно, але ніхто і не складає показники арифметично. Аналіз отриманих показників складаються в вектори атаки, які корелюються з оточенням. Запрошую всіх охочих ознайомитись з системою, хоча і не обіцяю що автор методології поділиться найменшими деталями, але питання надіслані мені — [email protected] — передам автору та поділюсь відповіддю.

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

Attack surface то напевне все-таки площина атаки а не поверхня.

Хм... Та ні, поверхня атаки це загальновживаний термін, приміром, стаття вікіпедії (автор не я) — uk.wikipedia.org/wiki/Поверхня_атаки

Та і площина перекладається як plane чи area.

Підписатись на коментарі