Почему результат следующего 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 и вы хотите получить ее тестовую версию, оставьте свой контакт в форме ниже.
