Построение процесса реагирования на инциденты (по NIST)

Первый серьёзный инцидент почти всегда выглядит одинаково: в чате двадцать человек, никто не знает, кто главный, логи кто-то уже «почистил для порядка», а руководство просит ответ на вопрос «что случилось» через час. Хорошая новость: этого можно избежать заранее. Для этого нужен не дорогой продукт, а договорённости, записанные на бумаге и проверенные на практике. В этой статье разберём, как построить процесс реагирования на инциденты на основе рекомендаций NIST SP 800-61 и как приземлить его на небольшую инфраструктуру вроде нашей лабораторной: домен itpages.lab.local, сеть 192.168.10.0/24, SIEM на srv-siem01, контроллер домена srv-dc01.

Это первая статья серии про реагирование и проверку защиты. Дальше будут форензика, purple team, учения, метрики SOC и облачная безопасность. Все примеры оборонительные: мы строим процесс, а не атакуем.

Жизненный цикл по NIST в двух словах

NIST описывает реагирование как цикл из четырёх фаз. Важно, что это именно цикл, а не прямая линия: выводы из последнего инцидента возвращаются в подготовку.

1. Подготовка — люди, инструменты, политики, обучение, контакты.
2. Обнаружение и анализ — как мы узнаём, что что-то не так, и как решаем, инцидент это или шум.
3. Сдерживание, ликвидация и восстановление — остановить распространение, убрать причину, вернуть сервисы.
4. Действия после инцидента — разбор, выводы, улучшения.

Большая часть работы делается в первой фазе. Если подготовка пропущена, остальные три превращаются в хаос с красивыми названиями. Поэтому начнём с неё.

Шаги построения процесса

Шаг 1. Определи, что такое инцидент, и заведи классификацию

Без определения каждый называет инцидентом своё. Запиши коротко: инцидент — это событие, которое нарушило или угрожает нарушить конфиденциальность, целостность или доступность информации либо политику безопасности. Дальше введи уровни серьёзности. Хватит четырёх, больше только запутает.

Уровень 1 (низкий)   : одиночная блокировка вредоносного вложения, реакция по плейбуку, без эскалации
Уровень 2 (средний)  : подозрение на компрометацию одной учётной записи или одного хоста
Уровень 3 (высокий)  : подтверждённая компрометация сервера или привилегированной учётной записи
Уровень 4 (критичный): затронуты контроллер домена, резервные копии или утечка данных клиентов

К каждому уровню привяжи время реакции и того, кого нужно уведомить. Например, для уровней 3 и 4 сразу подключается руководитель ИТ, а для уровня 4 ещё и юрист или ответственный за персональные данные.

Шаг 2. Назначь роли и заведи реестр контактов

В небольшой команде один человек часто совмещает несколько ролей, но сами роли должны быть названы. Минимальный набор:

• Руководитель инцидента — принимает решения и отвечает за ход работ. Он не лезет в консоль, он управляет.
• Аналитик — разбирает данные в SIEM, определяет масштаб.
• Администратор систем — выполняет изменения: изоляция хоста, сброс паролей, восстановление.
• Коммуникатор — общается с руководством, клиентами, регуляторами. Единый голос важнее скорости.
• Писарь — ведёт хронологию. Без него через сутки никто не вспомнит, что и в каком порядке делали.

Контакты храни там, где они доступны, когда лежит почта и домен. Распечатанный лист в сейфе и копия в менеджере паролей, который не зависит от srv-dc01, — нормальная практика. Иначе в момент аварии выяснится, что телефон директора лежит на сервере, который как раз недоступен.

Шаг 3. Подготовь инструменты и видимость

Реагировать можно только на то, что видно. Проверь базовый минимум и запиши результат в чек-лист готовности:

[ ] Журналы Windows Security с srv-dc01 и рабочих станций приходят в srv-siem01
[ ] События создания процессов (Sysmon или аналог) включены на серверах
[ ] Синхронизация времени (NTP) настроена на всех хостах, расхождение < 1 секунды
[ ] Срок хранения журналов в SIEM не меньше 90 дней
[ ] Есть отдельная учётная запись для реагирования, не используемая в повседневной работе
[ ] Резервные копии проверены восстановлением за последние 30 дней
[ ] Есть доступ к srv-forensic01 для снятия образов и анализа

Синхронизация времени кажется мелочью, пока не придётся сопоставлять события с трёх систем, у которых часы расходятся на четыре минуты. Тогда хронология превращается в гадание.

Шаг 4. Напиши плейбуки для типовых сценариев

Плейбук — это короткая инструкция «если случилось X, делай A, B, C». Не пиши романов: один плейбук умещается на одной странице. Начни с трёх-четырёх самых вероятных сценариев: фишинг с вложением, подозрение на компрометацию учётной записи, заражение рабочей станции, потеря устройства. Вот скелет, который подходит почти для всего:

ПЛЕЙБУК: Подозрение на компрометацию учётной записи
1. Зафиксировать время обнаружения и источник сигнала (писарь)
2. Проверить в srv-siem01 входы учётной записи за последние 72 часа
3. Оценить уровень серьёзности (шаг 1) и уведомить по таблице
4. Сдерживание: отключить сессии, сбросить пароль, при необходимости заблокировать учётную запись
5. Проверить, не использовалась ли учётная запись на других хостах
6. Сохранить релевантные журналы до любых изменений
7. Ликвидация: устранить причину (слабый пароль, утёкшие данные, фишинг)
8. Восстановление: вернуть доступ пользователю, усилить контроль (MFA)
9. Передать материалы на разбор

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

Шаг 5. Обнаружение и анализ: от сигнала к решению

Сигналы приходят из SIEM, от пользователей, от внешних сообщений. Для каждого нужен единый путь входа: один почтовый ящик или одна форма, куда можно написать «мне кажется, что-то не так». Дальше аналитик проводит первичную сортировку и отвечает на три вопроса: это реальное событие или ложное срабатывание, какие системы и данные затронуты, насколько срочно действовать.

Заведи простую карточку инцидента. Не нужна сложная система, подойдёт даже таблица, главное — единый формат:

ID: INC-2026-014
Время обнаружения: 2026-10-13 09:42 (UTC+5)
Источник: оповещение srv-siem01, правило «множественные неудачные входы»
Затронуто: учётная запись svc-backup, хост srv-lab01
Уровень: 2
Статус: сдерживание
Ответственный: аналитик смены
Хронология: ...

Шаг 6. Сдерживание, ликвидация, восстановление

Сдерживание бывает краткосрочным и долгосрочным. Краткосрочное — быстро остановить ущерб: отключить хост от сети, заблокировать учётную запись. Долгосрочное — временные меры, позволяющие работать, пока готовится полное исправление. Выбор стратегии зависит от критичности сервиса: сервер, который кормит бизнес, нельзя просто выключить, и это решение должен принимать руководитель инцидента, а не дежурный аналитик в три часа ночи.

Ликвидация означает устранение причины, а не симптомов. Если у тебя «вылечили» один хост, но не закрыли уязвимость, через неделю будет повтор. Восстановление — возврат в рабочее состояние из чистых источников и наблюдение за системой повышенного внимания ещё некоторое время: правила в SIEM на восстановленный хост стоит усилить как минимум на две недели.

Шаг 7. Разбор после инцидента

Через несколько дней после закрытия собери всех участников на встречу без поиска виноватых. Вопросы простые: что произошло, что сработало, что не сработало, что изменим. Результат — список улучшений с владельцами и сроками. Это не формальность: именно здесь цикл замыкается, и подготовка становится лучше. Короткий шаблон отчёта:

1. Краткое описание и итоговый уровень серьёзности
2. Хронология (обнаружение, сдерживание, восстановление)
3. Первопричина
4. Что сработало
5. Что не сработало
6. Действия по улучшению: что, кто, срок

Шаг 8. Коммуникации во время инцидента

Технически безупречная работа легко превращается в провал, если руководство и пользователи узнают о происходящем из слухов. Заранее определи, кому, когда и в каком объёме сообщается информация. Для внутренних уведомлений достаточно трёх вопросов: что известно, что неизвестно, когда следующее обновление. Назначь регулярный интервал отчётов, например каждые два часа для высокого уровня, и придерживайся его, даже когда новостей нет: фраза «ситуация без изменений» тоже информация.

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

Шаг 9. Начни с малого и проверь на практике

Не пытайся внедрить всё сразу. Реалистичный план на первый месяц выглядит так:

1. Неделя 1: определение инцидента, классификация, список ролей, реестр контактов.
2. Неделя 2: проверка видимости из чек-листа готовности и устранение пробелов в журналировании.
3. Неделя 3: два плейбука для самых вероятных сценариев и карточка инцидента.
4. Неделя 4: небольшое учение на выдуманном сценарии, затем правка документов по его итогам.

После этого добавляй по одному плейбуку в месяц. Через полгода у тебя будет живой процесс, который команда знает, а не папка с документами, которую открывают раз в год на аудите. Если инцидент случится раньше, ты всё равно окажешься лучше подготовлен: уже будет понятно, кто руководит и куда писать.

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

И наконец, договорись о критериях закрытия инцидента. Инцидент закрыт не тогда, когда стало тихо, а когда устранена причина, восстановлены сервисы, проверены соседние системы и проведён разбор. Запиши эти условия в процесс, иначе карточки будут висеть открытыми месяцами или закрываться слишком рано.

Частые ошибки и как их избежать

• Начинать чистку до сохранения доказательств. Перезагрузка хоста стирает содержимое памяти, а «быстрая уборка» уничтожает следы. Правило: сначала фиксируем, потом меняем. Включи это прямо в плейбуки.
• Писать процесс и ни разу его не проверять. Документ, который никто не читал, не работает в стрессе. Раз в квартал проводи учения и обновляй плейбуки по их итогам.
• Размытая ответственность. Когда все отвечают за всё, не отвечает никто. Назови руководителя инцидента заранее и укажи заместителя на случай отпуска или болезни.

Автор — Команда IT-Pages