Как создать эффективный план реагирования на инциденты?

Большинство организаций терпят неудачу в реагировании на инциденты не потому, что им не хватает инструментов. Они терпят неудачу, потому что заранее никто не согласовал, кто что делает, и первый реальный инцидент превращается в совещание вместо скоординированного ответа.

Начните с этапов, а не с сценариев

NIST SP 800-61 определяет четыре этапа: подготовка, обнаружение и анализ, локализация/искоренение/восстановление и постинцидентная деятельность. Этот порядок имеет значение. Команды любят сразу переходить к локализации, потому что это кажется продуктивным, но если вы не проделали подготовительную работу, вы недостаточно хорошо знаете собственную сеть, чтобы что-либо эффективно локализовать.

Подготовка означает актуальные реестры активов, а не таблицу из 2022 года. Это означает знание окна хранения логов (если оно составляет 7 дней, а злоумышленник находился в системе 30 дней, вы уже потеряли временную шкалу). Это означает предварительно развёрнутый инструментарий для форензики — Velociraptor, KAPE или даже документированная процедура tar/dd для образов диска — чтобы никто не загружал инструменты на скомпрометированный хост во время активного инцидента.

Определите уровни серьёзности, прежде чем они вам понадобятся

SEV1 (активная экфильтрация данных, запуск программы-шифровальщика, компрометация учётной записи администратора домена) требует другого ответа, чем SEV3 (изолированный вредонос на одной рабочей станции без прав). Запишите это в виде матрицы: влияние vs. масштаб vs. уверенность. Назначьте каждому уровню серьёзности требуемое время ответа и путь эскалации. Если ваш руководитель инцидента для SEV1 — это тот же человек, который должен одобрять каждый ордер на покупку за 500 долларов, вы встроили узкое место прямо в свой аварийный процесс.

Роль руководителя инцидента не является опциональной

Один человек управляет инцидентом. Не обязательно самый старший инженер — человек, который лучше всего способен координировать, делегировать и принимать решения о локализации под давлением. Этот человек не обязательно пользуется клавиатурой во время ответа; он отслеживает временную шкалу, управляет коммуникацией с юристами и руководством, и решает, когда перейти к изоляции сегмента или отключению системы.

Без этой роли получается, что пять человек входят через SSH на один хост, не разговаривая друг с другом, и никто не захватывает оперативную память перед тем, как кто-то перезагружает машину, чтобы "проверить, поможет ли это".

Решения о локализации, которые действительно имеют значение

Самое сложное решение в большинстве инцидентов: изолировать сейчас или ещё немного наблюдать, чтобы понять масштаб? Отключение доступа в сеть слишком рано предупредит злоумышленника, который всё ещё движется по сети, и уничтожит ваш шанс увидеть его следующий ход. Слишком долгое ожидание позволит программе-шифровальщику закончить шифрование ресурсов.

Разумный компромисс: использовать сегментацию сети и изоляцию EDR (CrowdStrike, Defender for Endpoint, SentinelOne — все это поддерживают) для отключения хоста от бокового движения при сохранении его включённого состояния для захвата памяти. Полное отключение должно быть крайней мерой — оно уничтожает оперативные доказательства и, в случае программ-шифровальщиков, может спровоцировать антифорензическое поведение, встроенное в некоторые вредоносные программы.

Пропуски в логировании, о которых вы пожалеете во время инцидента, но не раньше

Параметры Windows Event Log по умолчанию недостаточны. Если у вас не развёрнут Sysmon с приличной конфигурацией (базовые конфигурации SwiftOnSecurity или Olaf Hartong — хорошая отправная точка), вы будете восстанавливать деревья процессов из фрагментов. На стороне сети логи NetFlow или Zeek имеют большее значение, чем большинство организаций понимают, пока им не потребуется ответить