Чому результат наступного Log4Shell вирішуватиметься в перші 72 години, і який вигляд має сучасний процес реагування на zero-day.
Кожна команда безпеки добре пам’ятає день, коли з’явився Log4Shell. Тиха п’ятниця після обіду в грудні 2021 року перетворилася на вихідні з кризовими штабами, екстреними виправленнями та звітами для керівництва. Минуло кілька років, але наслідки Log4j досі з’являються у звітах про інциденти. Це вперте нагадування про те, що вразливість нульового дня не закінчується разом із новинним циклом.
Zero-day більше не є рідкістю. Це стало регулярною операційною реальністю, а проміжок між розкриттям інформації та експлуатацією продовжує скорочуватися. Зловмисники регулярно перетворюють нещодавно розкриті CVE на інструмент атаки протягом кількох годин. Це означає, що перші 24–72 години після розкриття інформації (період, коли більшість організацій ще намагаються з’ясувати, чи зачепила їх проблема), саме той проміжок часу, який зловмисники прагнуть використати.
Питання для керівників AppSec полягає не в тому, чи з’явиться наступна вразливість нульового дня. Питання в тому, команда відреагує за години, чи за дні.
Чому zero-day руйнують традиційні робочі процеси AppSec
Звичайний життєвий цикл вразливості рухається в передбачуваному темпі. Публікується CVE, до сканера додається правило виявлення, наступне заплановане сканування знаходить проблему, створюється тікет, а виправлення потрапляє в наступний спринт. Такий ритм працює для переважної більшості вразливостей, які не потребують термінової реакції з повною зупинкою інших завдань.
Zero-day руйнують цю модель через наступні три чинники.
Швидкість. Час від розкриття інформації до експлуатації різко скоротився. Очікування наступного запланованого сканування більше не є прийнятним варіантом.
Мінливість даних. У перші години розвіддані самі по собі є неповними й нестабільними. Уражені версії уточнюються, індикатори компрометації змінюються, а «виправлені» бібліотеки іноді все ще виявляються вразливими. Будь-яке реагування, яке спирається на статичні таблиці, ланцюжки електронних листів або разові PDF-файли, застаріває в момент надсилання.
Масштаб впливу. Питання «де є ризик?» дійсно складне. Одна вразлива бібліотека може бути захована на три рівні вглиб у транзитивній залежності або міститися всередині контейнерного образу, який не перебудовували шість місяців. Щоб відповісти на запитання «чи зачепила проблема організацію?» о другій ночі, потрібно зіставити актуальні розвіддані про загрози з поточним і надійним інвентарем усього, що коли-небудь було випущено.
Який вигляд має сучасне керування zero-day
Команди, які ефективно реагують на zero-day, мають кілька спільних характеристик. Вони не ставляться до вразливості нульового дня як до нового проєкту. Вони сприймають її як відомий робочий процес, який активується за потреби. Зазвичай такий процес складається з чотирьох елементів:
- Актуальне авторитетне джерело даних про zero-day, відокремлене від графіків сканування.
- Автоматична кореляція, яка зіставляє zero-day з наявним інвентарем без потреби в новому скануванні.
- Чіткий життєвий цикл для кожної події: коли вона активна, коли вже не становить негайної загрози та коли «відходить в історію».
- Спільний журнал аудиту, щоб команди безпеки, розробки та комплаєнсу працювали з єдиним джерелом істини.
Саме цю модель реалізовано в платформі Mend.io. Нижче описано, як кожен елемент працює на практиці.
Дані про zero-day як оновлюваний канал даних, а не таблиця
Платформа Mend містить окрему сторінку Zero-Day Data – актуальне подання всіх вразливостей нульового дня, які Mend.io активно відстежує, доступне через інтерфейс користувача та API. Сторінка доступна безпосередньо з меню профілю користувача й, що важливо, не залежить від інвентарю організації. Можна бачити, що саме відстежує Mend.io до, під час і після власних сканувань. Це має значення, оскільки перше запитання під час zero-day зазвичай звучить так: «що насправді відомо?» Відповідь має надходити з єдиного авторитетного потоку даних, а не з набору розрізнених рекомендацій від різних вендорів.
За замовчуванням сторінка показує найновішу активну вразливість нульового дня і дає змогу перемикатися між активними подіями та архівними, які залишаються доступними безстроково. Для кожного запису можна переглянути назву бібліотеки, SHA-1, ідентифікатор вразливості, дату додавання та назву zero-day. Усе подання можна експортувати у CSV або JSON для внутрішньої звітності чи аудиту. Статичні таблиці, які раніше пересилалися під час подій на кшталт Log4Shell, замінюються актуальним джерелом даних, з яким можуть працювати як люди, так і інструменти.
Кореляція події з інвентарем
Знати, що відбувається зовні, – лише половина завдання. Складніше питання «де є ризик?» вирішується одним кліком. Кнопка View Full Exposure на сторінці Zero-Day Data веде безпосередньо до звіту про виявлені zero-day, обмеженого інвентарем конкретної організації.
Логіка кореляції використовує наявні дані сканування як джерело істини, виконуючи зіставлення за MSC ID або назвою бібліотеки. Важливо, що нове сканування автоматично не запускається: Mend.io використовує вже проскановані дані, щоб визначити вплив. Таке рішення є свідомим. Під час zero-day немає потреби чекати повного повторного сканування монорепозиторію. Потрібна негайна відповідь на основі вже наявних знань із можливістю запустити додаткові сканування для компонентів, які справді мають значення.
Визначений життєвий цикл для кожної події
Zero-day також мають часовий вимір, який більшість інструментів ігнорує. У платформі Mend кожна подія проходить дві фази.
Активна фаза (дні 0–30). Там, де це доречно, з’являються банери інформування та порушень, сторінка Zero-Day Data позначає подію як Active, а кореляція з інвентарем виконується на основі наявних сканувань.
Фаза завершення (після 30-го дня). Банери зникають, статус змінюється на Expired, а подія переходить із режиму реагування на інцидент до архівного запису. Дані залишаються доступними безстроково для аудитів і ретроспектив.
Це 30-денне вікно відповідає тому, як вразливості нульового дня фактично поводяться в реальних умовах. Перший місяць – це період пікової уваги, виправлень і зацікавленості керівництва. Після цього проблема або переходить у звичайний процес керування вразливостями, або залишається в архіві як довідковий запис. Вбудований в інструмент життєвий цикл означає, що команді не потрібно здогадуватися, коли можна припинити приділяти події підвищену увагу.
Від реактивності до готовності
Усе це не прибирає стрес, пов’язаний із zero-day, – його не усуне ніщо. Але це змінює характер роботи. Замість того щоб щоразу запускати новий процес, коли CVE потрапляє в новини, команда дотримується відомого плану дій: перевіряє актуальний потік даних, запускає звіт про ризики, відстежує подію протягом її життєвого циклу та надає зацікавленим сторонам узгоджене подання, яке можна експортувати.
Наступний Log4Shell обов’язково з’явиться. Організації, які впораються з ним найкраще, не обов’язково матимуть найбільші бюджети на безпеку. Це будуть організації, у яких реагування на вразливості нульового дня уже є відпрацьованим робочим процесом, а не імпровізацією.
Якщо вас зацікавила платформа Mend.io і ви бажаєте отримати її тестову версію, будь ласка, залиште свій контакт у формі нижче.
