Как выстроить процесс реагирования на инциденты с нуля

Почему линейное руководство по NIST не работает

Большинство статей про IR воспроизводят шесть фаз SANS PICERL (Preparation → Identification → Containment → Eradication → Recovery → Lessons learned) или четыре фазы NIST SP 800-61 Rev. 3. После такой статьи у руководителя есть рамка, но нет ни одного готового артефакта, который можно положить в IR-папку и использовать в момент стресса.

Эта статья построена не по фазам, а по сценариям. Для каждого из пяти типовых сценариев — что должно произойти в первые 15 минут, в первые 2 часа, в первые сутки, в первую неделю. Плюс готовый минимальный комплект артефактов: severity-матрица, contact tree, формат уведомления Роскомнадзору. В конце — общая дорожная карта на 90 дней для тех, у кого процесса ещё нет.

Если вам нужна сначала концептуальная рамка — берите NIST или SANS как есть, не изобретайте свою. Аудиторы и регуляторы спрашивают про эти стандарты, а не про вашу методологию.

Минимальная severity-матрица

С этого начинается любой IR-процесс. Без чёткой шкалы команда либо реагирует на всё подряд, либо игнорирует серьёзное.

| Severity | Критерии | SLA первичной реакции | Кто эскалирует | |---|---|---|---| | P0 — критичный | ≥1 зашифрованного хоста в продакшне; или затронут платёжный контур; или утечка ≥10 000 записей PII | 15 минут | Дежурный → CISO + CEO | | P1 — высокий | RCE на внешнем сервисе; компрометация служебной учётки с админ-правами; ≥3 host со следами malware | 1 час | Дежурный → CISO | | P2 — средний | Подозрительный процесс на 1 endpoint; компрометация обычной учётки; фишинговая кампания с попаданием | Рабочий день | SOC-аналитик → дежурный | | P3 — низкий | Аномалия в логах без подтверждения; единичный заблокированный malicious URL | Регистрация в журнале | SOC-аналитик |

Эту таблицу команда подгоняет под себя, но именно она первое, что должно появиться в IR-папке. Без неё все следующие плейбуки бесполезны.

Сценарий 1: Шифровальщик

Самый частый сценарий с самым высоким ущербом. Готовность к нему — отдельный класс зрелости IR.

Первые 15 минут. Подтверждение факта (один зашифрованный hostname в EDR — уже подтверждение). Изоляция всех хостов из того же VLAN через EDR без выключения (важно — память сохраняем для криминалистики). Объявление severity P0, активация полной команды. Блокировка SMB и RDP на periметре. Снятие критичных снапшотов со всех VM в затронутом сегменте, прежде чем что-то менять.

Первые 2 часа. Анализ point of entry: phishing → user → lateral. Снятие образа памяти и диска с patient zero для дальнейшего анализа через Volatility. Проверка immutable backups на доступность и неповреждённость. Решение по communication: внутреннее уведомление сотрудникам, заготовка для клиентов, заготовка для регулятора.

Первые сутки. Локализация подтверждена (нет новых infected hosts за последние 4 часа). Параллельно — restore критичных сервисов из бэкапа на чистом сегменте, а не на тех же машинах. Если есть обоснованные подозрения на утечку PII — запуск 24-часового счётчика для уведомления Роскомнадзора по 152-ФЗ.

Первая неделя. Полное восстановление с проверкой целостности. Усиленный мониторинг на 30–90 дней (вторичные атаки происходят регулярно). Постинцидентный разбор и обновление сегментации.

Подробный разбор пробелов в защите облака, через которые шифровальщики чаще всего распространяются, — в посте «5 ошибок безопасности облака». Связь сценария с выбором между SOC и MDR — в посте «SOC или MDR: как выбрать».

Сценарий 2: Утечка учётной записи с админ-правами

Не визуально драматично, но операционно опаснее шифровальщика — потому что злоумышленник может оставаться внутри неделями.

Первые 15 минут. Принудительная инвалидация всех сессий учётки. Ротация пароля. Отзыв всех access tokens (для облачных провайдеров — IAM access keys, для корпоративных систем — refresh tokens). Включение усиленного логирования по аккаунту.

Первые 2 часа. Аудит активности учётки за последние 30 дней: куда заходила, что выполнила, какие изменения сделала. Список затронутых ресурсов — кандидаты на дополнительный аудит. Проверка на создание backdoor-учёток и API-ключей с её правами.

Первые сутки. Если есть признаки lateral movement — расширение scope расследования. Ротация всех учётных данных, к которым теоретически имел доступ злоумышленник. Уведомление регулятора, если затронуты PII.

Первая неделя. Полный аудит прав учётки и пересмотр модели IAM по принципу least privilege. Если в результате расследования обнаружены backdoor — это уже отдельный сценарий 3 (закладка).

Сценарий 3: RCE на внешнем веб-приложении

Эксплойт публичной уязвимости. Часто связан с supply chain или невовремя пропатченной зависимостью.

Первые 15 минут. Подтверждение: лог веб-сервера + EDR на хосте показывают spawned shell или suspicious process под user веб-приложения. Изоляция хоста от внутренней сети, оставив доступным только команде реагирования. WAF-правило, блокирующее эксплойт, выкатывается параллельно (через minutes, не дней).

Первые 2 часа. Идентификация уязвимости — поиск CVE через NIST NVD или внутренний vulnerability scanner. Снятие artifacts (логи, файлы, память). Проверка lateral movement: запросы из изолированного хоста в backend, обращения к БД, использование service account.

Первые сутки. Патч уязвимости в production. Аудит других экземпляров того же приложения. Если уязвимость была exploited > 24 часов — расширенное расследование на возможное persistence.

Первая неделя. Post-mortem: как уязвимость попала в production. Обычно ответ — отсутствие SCA в CI или несвоевременное обновление зависимостей. Что закрывать на уровне процесса разработки разобрано в посте «OWASP Top 10 в 2026», раздел про supply chain.

Сценарий 4: Инсайдер

Самый сложный политически. Технически часто простой, юридически — длинный.

Первые 15 минут. НЕ принимаем технических мер до согласования с юридической службой. Любое преждевременное действие может скомпрометировать доказательную базу. Параллельно — усиленный мониторинг подозрительного аккаунта без блокировок.

Первые 2 часа. Совещание: ИБ + HR + юристы + при необходимости внешний consul. Принятие решения о scope: остановить сейчас или продолжить наблюдение для сбора доказательств.

Первые сутки. Если принято решение о действии — параллельная блокировка всех access (физический, логический, сетевой) в одном временном окне. Снятие forensic-образа рабочей станции по процедуре, которая выдержит суд: chain of custody задокументирован, hash образа подписан.

Первая неделя. Дальнейшие действия определяет юридическая служба. Со стороны ИБ — пересмотр контроля доступа сотрудников, особенно для уволенных и переведённых.

Сценарий 5: Фишинговая кампания с компрометацией почты (BEC)

Business Email Compromise — самый недооценённый класс инцидентов в среднем бизнесе.

Первые 15 минут. Принудительная инвалидация сессий, ротация пароля, включение MFA если ещё не было. Просмотр inbox rules — атакующие часто создают auto-forward или delete-rules для скрытия активности.

Первые 2 часа. Поиск отправленных писем за период компрометации. Особое внимание — письма с финансовыми просьбами от имени compromised user. Уведомление контрагентов из истории переписки о возможной компрометации.

Первые сутки. Аудит всех получателей подозрительных писем. Если был запрос на смену реквизитов или платёж — экстренная проверка с контрагентом по telephone (не по email). Документирование инцидента для возможного обращения в правоохранительные органы.

Первая неделя. Security awareness training для всей компании по теме BEC. Внедрение технических контролей: DMARC enforcement, banner для писем извне, явная пометка для писем с финансовыми просьбами.

Outsourcing IR: матрица решения

| Размер компании | Текущая зрелость | Рекомендация | |---|---|---| | До 200 человек, нет SOC | Inhouse IR не окупается | DFIR on-demand + готовый IR-retainer | | 200–2000 человек, есть SOC | Зрелого IR нет, но есть техника | IR-retainer + tabletop-учения от внешнего партнёра | | 200–2000, есть SOC + MDR | Зрелый IR от провайдера | Внешний партнёр для tabletop и аудита плейбуков | | 2000+, есть SOC + MDR + Threat Hunting | Inhouse IR с retainer на overflow | Inhouse-команда + retainer для сложных случаев |

Связь с выбором между SOC и MDR — в посте «SOC или MDR: как выбрать и не переплатить». Связь с threat intelligence — в посте «Что такое Threat Intelligence» — раздел про IOC-feed для проактивного hunting.

Минимальный artifact pack для IR-папки

Это набор документов, который должен лежать в защищённом репозитории с известным каждому члену команды URL.

1. Severity-матрица — таблица выше с дополнениями под ваш бизнес.

2. Contact tree в YAML-формате — машинно-читаемое дерево эскалации:

`yaml on_call: primary: { name: "Иванов И.И.", phone: "+7-...", telegram: "@..." } secondary: { name: "Петров П.П.", phone: "+7-...", telegram: "@..." }

severity_p0: notify: [CISO, CEO, Legal, PR] channels: [signal_group_ir, phone]

severity_p1: notify: [CISO] channels: [signal_group_ir] `

3. Плейбуки на 5 сценариев — по одной странице на каждый, без воды.

4. Шаблон уведомления Роскомнадзору на 24 часа — пред-заполненный, с пустыми полями под инцидент. По требованиям 152-ФЗ после утечки персональных данных уведомление обязательно. Полный разбор требований — в посте «Подготовка к проверке регулятора».

5. Шаблон коммуникации для сотрудников / клиентов / медиа — три варианта в одном документе. Заполняются после согласования с PR.

6. Журнал инцидентов — таблица или система с обязательными полями: дата начала, дата закрытия, severity, scope, точка входа, ущерб, lessons learned, статус действий по улучшению.

7. Чек-лист постинцидентного разбора — шаги, по которым проводится lessons learned.

Дорожная карта на 90 дней

Если у вас нет процесса вообще, минимальный план.

Недели 1–2. Назначьте ответственного. Опишите severity-матрицу и contact tree. Это занимает 2–3 рабочих дня.

Недели 3–4. Напишите один плейбук — берите шифровальщик, он самый частый. Проведите по нему первое настольное учение с командой.

Месяц 2. Допишите плейбуки на остальные 4 сценария. Подключите EDR с возможностью изоляции, если ещё не подключён. Настройте immutable backups для критичных систем.

Месяц 3. Второе настольное учение по другому сценарию. Документирование результатов в формате lessons learned. Согласование IR-retainer с внешним партнёром, если зрелость inhouse недостаточна.

После 90 дней — оценка по MITRE ATT&CK Containment matrix, и из неё уже план на следующие 6 месяцев.

Если нужна помощь

Мы проводим экспресс-аудит готовности к реагированию (5 рабочих дней): где IR-папка, что в ней есть, какой минимальный gap для прохождения проверки регулятора и какие сценарии не закрыты. Без обязательств по последующему контракту.