Плейбук реагирования на инциденты по NIST 800-61: разбор учебного кейса по фазам

На последнем табличном учении с командой из шести career switchers — людей, пришедших в ИБ из IT-администрирования и разработки — среднее время от первого алерта SIEM до полной изоляции заражённого сегмента составило 3 часа 48 минут. Из них больше двух часов ушло не на анализ и не на сдерживание атаки. Два часа — на поиск контактов, споры о полномочиях и повторный сбор одних и тех же артефактов после пересменки.

Фреймворк NIST SP 800-61 (Computer Security Incident Handling Guide — федеральное руководство по обработке инцидентов) не устраняет этот хаос автоматически, но делает его видимым. Каждая из четырёх фаз — чек-поинт, где потерю времени можно измерить, зафиксировать и устранить. Ниже — разбор каждой фазы на конкретном учебном сценарии с таймлайном, одиннадцатью точками потери времени и готовыми чек-листами для тех, кто строит свой первый плейбук реагирования на инциденты.

NIST SP 800-61: четыре фазы реагирования на инциденты

NIST SP 800-61 Revision 2 определяет четырёхфазный жизненный цикл реагирования (incident response lifecycle):

1. Preparation — подготовка: политики, инструменты, контакты, тренировки. Всё, что делается до инцидента.
2. Detection & Analysis — обнаружение и анализ: от первого алерта до подтверждения «да, это реальный инцидент, а не ложное срабатывание».
3. Containment, Eradication & Recovery — сдерживание, устранение, восстановление: остановить атаку, убрать её причину, вернуть системы в строй.
4. Post-Incident Activity — пост-инцидентная деятельность: разбор полётов, метрики, обновление плейбука.

В апреле 2025 года NIST официально отозвал Rev 2 и выпустил Revision 3, перестроив модель под CSF 2.0 (Cybersecurity Framework — фреймворк управления кибербезопасностью). Вместо четырёх последовательных фаз Rev 3 использует шесть параллельных функций: Govern, Identify, Protect, Detect, Respond, Recover. По описанию NIST на csrc.nist.gov, Rev 3 фокусируется на интеграции реагирования в общую систему управления рисками, а не на пошаговых инструкциях для конкретных технологий.

Для зрелых SOC-команд это логичное развитие. Но для обучения и построения первого плейбука реагирования на инциденты классическая четырёхфазная модель Rev 2 работает лучше. Она линейна, даёт чёткие чек-поинты и не требует развитой GRC-функции (Governance, Risk, Compliance — управление, риски, соответствие требованиям). Начинать стоит с Rev 2, а переходить на Rev 3 — когда процесс уже живой и появляется потребность в интеграции с управлением рисками.

По ходу статьи я использую идентификаторы MITRE ATT&CK — открытой базы тактик и техник атак. T-коды (T1566, T1059 и т.п.) — уникальные номера конкретных техник. Зачем их знать: SIEM-правила, отчёты об угрозах и плейбуки вашей будущей команды ссылаются именно на эти коды. Говорить «подозрительный PowerShell» — размыто. Говорить «T1059.001» — однозначно.

Учебный кейс: шифровальщик через фишинговое вложение

Типовой сценарий, который встречается на табличных учениях (tabletop exercises) и в учебных лабораториях.

Легенда: компания на 200 сотрудников, Active Directory, Windows-инфраструктура. В 09:12 SIEM (система сбора и корреляции событий безопасности — Splunk, Elastic или QRadar) показывает алерт: подозрительный процесс PowerShell на рабочей станции бухгалтера. Предыстория: бухгалтер открыла вложение из письма якобы от контрагента.

Бизнес-логика атаки и цепочка по MITRE ATT&CK

Прежде чем разбирать фазы реагирования — стоит понять, зачем атакующий делает каждый шаг. Ransomware (шифровальщик) — монетизация через вымогательство: зашифровать как можно больше данных и потребовать выкуп. Бухгалтер выбрана как точка входа неслучайно. У неё доступ к финансовым системам, а через горизонтальное перемещение атакующий добирается до файлового сервера, где лежат документы всей компании. Больше зашифрованных данных — выше давление на жертву.

Цепочка атаки по MITRE ATT&CK:

Теперь пройдём каждую фазу NIST 800-61 на этом кейсе и замерим, где теряется время.

Фаза 1 — Preparation: что должно быть готово до инцидента

Preparation — не «установили антивирус и забыли». Это конкретный набор артефактов, без которых остальные три фазы превращаются в импровизацию. Причём импровизацию нервную, под давлением, когда атакующий продолжает работать.

Контакт-лист — кому звонить при инциденте. Не «руководитель ИТ-отдела», а конкретный номер телефона с указанием бэкапа на случай недоступности. Сюда же — юрист, PR-менеджер и (для субъектов КИИ по ФЗ-187) контакт НКЦКИ (Национальный координационный центр по компьютерным инцидентам, ФСБ). Сроки уведомления НКЦКИ — от 3 до 24 часов в зависимости от категории объекта. Уже на фазе Preparation нужно знать категорию своих объектов КИИ и иметь готовый шаблон уведомления. Узнавать это в момент инцидента — гарантированный провал по срокам.

Матрица эскалации — при каком типе инцидента кого уведомлять. Шифровальщик на одной рабочей станции — одно дерево решений, шифровальщик на контроллере домена — совсем другое.

Jump kit — «тревожный чемоданчик» аналитика: ноутбук с чистой ОС, загрузочная флешка с forensic-дистрибутивом, кабели, документация. Вопрос из учебных кейсов, который стабильно вызывает паузу: «У вашей команды есть готовый ноутбук с forensic-инструментами, если основная сеть скомпрометирована?» Ответ — почти всегда нет.

Базовые линии (baselines) — как выглядит «нормальное» поведение сети и хостов. Без baseline не отличить аномалию от штатной активности. Связь с OWASP A09:2021 (Security Logging and Monitoring Failures) прямая: без логирования и мониторинга нарушения не обнаружить в принципе.

Где теряется время на подготовке

Потеря №1: контакт-лист не существует или устарел. На учебных кейсах это стабильно 15–30 минут: команда ищет телефон сетевого администратора, который уволился два месяца назад.

Потеря №2: нет заготовленной стратегии containment. Когда алерт уже горит — не время решать «отключаем сервер или изолируем VLAN». Это решение должно быть принято заранее для каждого типа инцидента и записано в плейбуке.

Потеря №3: SIEM не настроен на нужные источники. Если расширенные логи PowerShell (Script Block Logging, Module Logging) не собираются — аналитик узнаёт об этом в момент инцидента, когда искать уже нечего. Категория DE.AE-06 из NIST CSF 2.0 прямо указывает: информация о неблагоприятных событиях должна передаваться уполномоченному персоналу и в информационные системы. Но передавать нечего, если логи не собираются.

Фаза 2 — Detection & Analysis: от алерта до подтверждения инцидента

09:12 — SIEM показывает алерт. Правило сработало на подозрительный PowerShell-процесс с флагом -EncodedCommand (закодированная команда, часто используемая для обфускации — маскировки вредоносного кода).

Задача аналитика — ответить на три вопроса. Это реальный инцидент или ложное срабатывание? Каков масштаб — одна машина или несколько? Какой приоритет — можно подождать или действовать сейчас?

Шаг 1 — Валидация алерта. Проверяем родительский процесс (parent process). Если PowerShell запущен из WINWORD.EXE (Microsoft Word) — это почти наверняка выполнение макроса, а не штатная работа администратора. Пример запроса в Splunk:

index=windows sourcetype=WinEventLog:Sysmon EventCode=1
ParentImage="*\\WINWORD.EXE" Image="*\\powershell.exe"
| table _time, ComputerName, User, CommandLine

Запрос ищет в логах Sysmon (утилита расширенного логирования Windows) события создания процесса (EventCode=1), где родительским процессом был Word, а дочерним — PowerShell. В столбцах — время, имя компьютера, пользователь и полная командная строка. Вернул строки — подтверждение: макрос действительно запустил PowerShell.

Шаг 2 — Scoping (определение масштаба). Берём хэш подозрительного файла-вложения и ищем его на других рабочих станциях. Проверяем признаки T1003.001 (дамп LSASS — процесса, хранящего учётные данные в памяти) или T1021.001 (RDP-подключения с этой машины на другие хосты).

Шаг 3 — Документирование. Каждый шаг фиксируется в тикет-системе (TheHive, Jira или хотя бы shared-документ). Время обнаружения, кто обнаружил, какие индикаторы найдены, какие действия предприняты. Без этой записи фаза Post-Incident Activity превратится в гадание по памяти.

Где теряется время на обнаружении

Потеря №4: погоня за false positives по одному. Аналитики-новички часто тратят 30–40 минут на проверку каждого алерта отдельно, вместо того чтобы корреллировать индикаторы. PowerShell из Word + обращение к внешнему IP + нестандартный User-Agent — это не три отдельных алерта. Это цепочка (kill chain), и рассматривать её нужно целиком.

Потеря №5: приоритизация вручную. NIST рекомендует оценивать инцидент по двум осям: Functional Impact (влияние на бизнес-процессы) и Information Impact (чувствительность затронутых данных). Бухгалтерская рабочая станция с доступом к финансовым системам — высокий приоритет по обоим параметрам. Без заготовленной матрицы аналитик обрабатывает алерты в порядке поступления — а не по критичности.

Потеря №6: забыли зафиксировать время. Метрика TTD (Time to Detect — время от начала атаки до обнаружения) — одна из ключевых в post-incident review. Без записи момента первого алерта и подтверждения невозможно измерить прогресс команды. Через полгода вы не сможете показать руководству, что стали быстрее.

Фаза 3 — Containment, Eradication, Recovery: от изоляции до восстановления

09:47 — инцидент подтверждён. Рабочая станция бухгалтера скомпрометирована, есть признаки попытки горизонтального перемещения через RDP (T1021.001).

Ошибки containment и уничтожение улик

Критическое решение: что делать с заражённой машиной?

Решение «выключать или отключать» должно определяться заранее в политике из фазы Preparation. Без заготовки аналитик тратит 20–30 минут на согласование с руководством, пока атакующий продолжает работать. Двадцать минут — это вечность, когда шифровальщик обрабатывает файлы со скоростью нескольких гигабайт в минуту.

Параллельно с изоляцией: — Сбросить пароль скомпрометированной учётной записи. Если атакующий извлёк хэши через T1003.001, он может использовать легитимные credentials (T1078 — Valid Accounts, использование настоящих учётных данных для доступа к другим системам) — Заблокировать внешний IP, к которому обращался PowerShell-скрипт — на файрволе или прокси — Проверить, добрался ли атакующий до файлового сервера через RDP

Eradication (устранение) — удаление вредоносного документа, PowerShell-скриптов, backdoor (если установлен). Recovery (восстановление) — откат систем из бэкапа, проверка целостности данных, поэтапное возвращение в продакшн. Ключевое правило: восстановление начинается только после подтверждения eradication. Поднимать сервер из бэкапа при активном атакующем в сети — отдать ему ещё одну машину.

Потеря №7: «перезагрузи и починится». Рефлекс из IT-поддержки: перезагрузить заражённую машину до снятия дампа памяти. Volatile evidence исчезает, forensic-анализ становится неполным. На учебных кейсах это происходит стабильно — особенно у тех, кто пришёл из сисадминства, где перезагрузка решает 80% проблем. Здесь она создаёт новую.

Потеря №8: общий IR-план вместо плейбука. «При инциденте — изолировать, расследовать, восстановить» — это три слова, а не плейбук. Плейбук для ransomware отличается от плейбука для утечки данных: другие приоритеты containment, другие артефакты для сбора, другие стейкхолдеры.

Потеря №9: нет формата handover между сменами. Если инцидент тянется больше рабочего дня (а большинство тянется), передача без чёткого шаблона приводит к повторному сбору артефактов, которые предыдущая смена уже собрала. Я видел случаи, когда вторая смена заново снимала дамп диска, потому что не знала, что первая это уже сделала.

Фаза 4 — Post-Incident Activity: разбор полётов и обновление плейбука

Системы восстановлены, бизнес работает — и начинается самая недооценённая фаза. Команды, измотанные инцидентом, пропускают разбор и гарантированно повторяют те же ошибки через квартал.

Метрики, которые стоит замерять

Hot wash — встреча в течение 1–3 дней после инцидента, пока детали свежие. Не поиск виноватых, а анализ процесса: что сработало, что нет, что обновить.

Потеря №10: разбор не проводится. Команда считает «и так понятно». Через три месяца — аналогичный инцидент с теми же ошибками. Один в один.

Потеря №11: метрики не фиксируются. Без TTD и TTR невозможно доказать руководству, что инвестиции в SIEM или SOAR (платформу автоматизации реагирования — Cortex XSOAR, Shuffle) окупаются. Невозможно понять, становится ли команда быстрее. А без цифр разговор с руководством превращается в «нам нужен бюджет» — «зачем?» — «ну… нужен».

Сводная таблица потерь времени по фазам NIST 800-61

Практический блок: собираем минимальный плейбук реагирования на инциденты

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

Предпосылки: доступ к SIEM (подойдёт бесплатный Elastic/OpenSearch), тикет-система (TheHive, Jira или shared document), базовое понимание сетевой инфраструктуры организации.

Шаг 1 — Создайте контакт-лист. Откройте таблицу со столбцами: Роль, ФИО, Телефон, Email, Бэкап-контакт, Когда уведомлять. Минимальные роли: IR Lead, сетевой администратор, владелец бизнес-системы, юрист, PR. Для субъектов КИИ добавьте контакт НКЦКИ (ГосСОПКА) и шаблон уведомления. Поставьте календарное напоминание на ежемесячную проверку. Ожидаемый результат: при объявлении учебной тревоги любой член команды за 60 секунд находит нужный номер.

Шаг 2 — Напишите decision tree для трёх типов инцидентов. Начните с ransomware, фишинга и компрометации учётной записи. Для каждого зафиксируйте: критерии подтверждения (что делает алерт инцидентом), действия по containment (конкретно: «изолировать VLAN X» или «отключить кабель и снять дамп RAM»), порядок уведомления, список артефактов для сбора. Ожидаемый результат: текстовый документ на 2–3 страницы, который можно распечатать и повесить на стену в SOC.

Шаг 3 — Настройте минимальные правила детекции в SIEM. Для старта достаточно двух правил: PowerShell, запущенный из Office-приложений (индикатор макроса), и массовое переименование файлов за короткий период (индикатор шифровальщика). В Elastic Security это настраивается через раздел Detection Rules → Custom Query. Ожидаемый результат: при срабатывании правила вы получаете алерт с именем хоста, пользователем и командной строкой процесса.

Шаг 4 — Проведите tabletop exercise. Соберите команду, зачитайте сценарий из учебного кейса выше и пройдите по своему плейбуку. Засеките время на каждой фазе. Запишите, где застряли. Ожидаемый результат: список конкретных точек, где плейбук не работает. Обновите его по итогам.

Шаг 5 — Заведите шаблон post-incident report. Минимальные поля: дата/время обнаружения, дата/время containment, затронутые системы, root cause (первопричина), предпринятые действия, что обновить в плейбуке. Ожидаемый результат: после каждого инцидента или учения остаётся документ, который делает следующий цикл быстрее.

Разбирая учебные кейсы с людьми, пришедшими в ИБ из смежных областей, я вижу устойчивый паттерн: техническая часть — запросы в SIEM, анализ процессов, работа с артефактами — занимает 30–40% времени инцидента. Остальные 60% — организационный хаос. Ни один SOAR и ни один AI-копилот не решает проблему отсутствующего контакт-листа или не заготовленного decision tree.

NIST 800-61 ценен не как «ещё один стандарт для комплаенса», а как рентген: он показывает, где именно в процессе образуются пустоты. Rev 3 сделал модель гибче, встроив реагирование в систему управления рисками через CSF 2.0, но для построения первого плейбука четырёхфазная структура Rev 2 остаётся лучшей стартовой точкой — она прямолинейна и не требует зрелой GRC-функции.

Ещё одно наблюдение, которое может показаться неочевидным: самая недооценённая фаза — Post-Incident Activity. Большинство новых аналитиков воспринимают её как «разбор полётов с начальством» и стараются проскочить. В реальности это единственная фаза, которая превращает плейбук из одноразового документа в живой инструмент. Без метрик TTD и TTR у вас нет аргументов для бюджета на инструменты. Без hot wash нет информации о том, какие шаги плейбука не работают в стрессе. Без обновлённого контакт-листа по итогам — через квартал вы снова будете звонить уволившемуся сотруднику. На IB Basics учим не «что такое CIA-triad», а как делать первые задачи в SOC и blue team — включая построение именно такого плейбука с нуля.