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

Всім привіт! Мене звати Андрій Михалюк, 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).

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

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

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

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

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