Понедельник, 9:15 утра. Дежурный аналитик видит в Elastic SIEM серию алертов:
svchost.exe на трёх серверах prod-сегмента порождает дочерний cmd.exe (T1059.003, Execution), который запускает vssadmin delete shadows /all (T1490, Inhibit System Recovery). Через двенадцать минут - первые зашифрованные файлы на файловом сервере. Аналитик звонит руководителю ИБ, тот - генеральному. К инциденту подключаются четыре человека, ни у одного нет общего понимания: кто изолирует серверы, кто снимает дампы памяти, кто звонит юристам. Через два часа ransomware - Data Encrypted for Impact (T1486, Impact) - добирается до бэкап-сервера, который стоит в том же VLAN. У компании был антивирус, бэкап-система и четырёхстраничный «план реагирования на инциденты», написанный два года назад для аудита. Ни severity matrix, ни списка ответственных с телефонами, ни конкретных шагов по containment. Бумажка оказалась бесполезна.Ниже - разбор того, как построить IR playbook, который работает в 3 ночи без эскалации к руководству: с severity matrix, detection-правилами, decision tree и шаблоном postmortem.
По данным IBM Cost of a Data Breach Report, организации без формализованного IR-процесса и регулярных учений платят за инциденты на миллионы долларов больше. Цифра мотивирует, но давайте честно - большинство русскоязычных материалов по теме на этом и останавливаются.
Типичная статья про incident response в рунете описывает шесть этапов PICERL, даёт определения терминов - и на этом всё. Для первого знакомства с концепцией сойдёт, но в 9:15 утра при активном шифровании prod от определений толку ноль. Нет готовой severity matrix с SLA на реакцию, нет detection-правил для SIEM, нет decision tree по containment для разных типов инцидентов, нет шаблона postmortem с обязательными полями. А именно эти штуки превращают «план» в «playbook» - живой документ, по которому дежурный аналитик действует автономно, без звонков руководству.
Различие между IR-планом и IR playbook хорошо описано у Palo Alto Networks: план - стратегический документ с политиками и целями, playbook - тактическое руководство с конкретными шагами для каждого типа инцидента, а runbook - операционный чеклист для рутинных процедур. Для рабочего управления инцидентами кибербезопасности нужны все три уровня, но начинать стоит с playbook - он закрывает 80% потребностей SOC-команды.
Severity matrix - фундамент IR playbook для security-команды
Первое, что нужно сделать до написания процедур - определить классификацию инцидентов. Без severity matrix каждый алерт превращается в дискуссию «это серьёзно или нет?», а в 3 ночи такая дискуссия стоит часы. Я видел, как P2-инцидент раздувался до P1 просто потому, что никто не мог решить, нужно ли будить CISO.Ниже - рабочий шаблон severity matrix, который я использовал при построении IR-процесса с нуля. Адаптируйте критерии под свою инфраструктуру, но сохраняйте логику SLA.
| Severity | Критерии | Первичная реакция | Эскалация | Пример TTP |
|---|---|---|---|---|
| P1 Critical | Компрометация данных клиентов, шифрование prod, активный lateral movement в критичных сегментах | 15 мин | CISO + юрист + CEO: 30 мин | Ransomware (T1486), утечка ПДн |
| P2 High | C2-канал обнаружен, компрометация привилегированной учётки, эксплуатация внешнего сервиса | 30 мин | CISO: 1 час | Valid Accounts (T1078) для домен-админа, Exploit Public-Facing Application (T1190) |
| P3 Medium | Malware на одном хосте без lateral movement, фишинг с подтверждённым кликом | 2 часа | Тимлид SOC: 4 часа | Phishing (T1566) с исполненным payload без lateral movement, PowerShell (T1059.001) |
| P4 Low | Подозрительная активность без подтверждения компрометации, нарушение политик | 8 часов (рабочее время) | По необходимости | Аномальный логин из нового региона, отключённый агент EDR |
Ключевой принцип: severity назначается по наибольшему потенциальному ущербу, а не по текущему состоянию. OS Credential Dumping (T1003, Credential Access) на одном хосте - это P2, потому что дампнутые credentials могут уйти в lateral movement в любой момент. Не «пока ничего не произошло», а «что может произойти через 10 минут».
Привязка к российскому правовому контексту: инциденты с утечкой персональных данных (P1) требуют уведомления Роскомнадзора в течение 24 часов с момента выявления, уведомления о результатах внутреннего расследования - в течение 72 часов (ч. 3.1 ст. 21 152-ФЗ в ред. ФЗ-266 от 14.07.2022). Для субъектов КИИ - дополнительно уведомление в ГосСОПКА (НКЦКИ): 3 часа с момента обнаружения для значимых объектов КИИ, 24 часа - для иных (приказ ФСБ России № 367 от 24.07.2018 в актуальной редакции). С учётом введения оборотных штрафов за утечки ПДн задержка с классификацией инцидента буквально стоит процентов от годовой выручки. Severity matrix - не теоретическое упражнение, а финансовая страховка.
Роли в CSIRT: процедуры и ответственные
Второй элемент, без которого playbook мёртв - матрица ролей. Не абстрактная «команда реагирования», а конкретные функции с именами и телефонами.| Роль | Кто исполняет | Обязанности | Когда подключается |
|---|---|---|---|
| Incident Manager (IM) | Дежурный SOC-аналитик L2+ | Координация, containment-решения, ведение timeline | Сразу при P1/P2 |
| Tech Lead | Старший инженер ИБ | Анализ артефактов, forensics (Velociraptor, Volatility), план eradication | 15 мин (P1), 30 мин (P2) |
| Communications Lead | Юрист или руководитель ИТ | Уведомление регуляторов, внутренние коммуникации | 30 мин (P1), по запросу (P2+) |
| Scribe | Любой участник IR-команды | Документирование действий и решений в реальном времени | С начала инцидента |
Для команд из 2–3 человек: Incident Manager совмещает роль Scribe (общий канал в мессенджере как лог), Tech Lead - единственный аналитик. Communications Lead подключается только при P1.
Правило, которое спасает от хаоса: IM принимает решения по containment без согласования с руководством при severity P1. Если дежурный в 3 ночи должен будить CISO, чтобы получить разрешение изолировать хост - вы потеряете час. Ransomware не ждёт. Я разбирал инцидент, где аналитик 40 минут ждал ответа от руководителя, а за это время шифровальщик прошёлся по ещё двум файловым шарам. Полномочия на бумаге - не каприз, а необходимость.
Этапы реагирования на инциденты по PICERL: от подготовки до lessons learned
Фреймворк PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) описан в SANS, его аналог - в NIST SP 800-61 Incident Handling Guide. Ниже - конкретное наполнение каждого этапа для SOC-команды, которая строит процесс с нуля.Preparation - инвентаризация и инструментарий до первого инцидента
Этап, не привязанный к конкретному инциденту. Именно он определяет, выживете вы при P1 или нет.Инвентаризация активов. NIST CSF v2.0 (ID.AM-01) требует ведения актуального реестра оборудования. На практике: у вас должен быть список критичных серверов, сетевых сегментов и их владельцев, обновляемый не реже раза в квартал. Без этого списка при инциденте вы не знаете, что изолировать первым. Звучит банально, но в двух из трёх организаций, где я выстраивал IR-процесс, актуального реестра не было.
Baseline сетевого трафика. NIST CSF v2.0 (DE.AE-01): baseline ожидаемых потоков данных для пользователей и систем должен быть установлен и поддерживаться. На практике: вы должны знать, какой трафик нормален для каждого сегмента. Контроллер домена, обращающийся к внешнему IP каждые 60 секунд - аномалия. Без baseline вы этого не увидите.
Минимальный инструментарий:
- SIEM с настроенными правилами корреляции: Elastic SIEM 8.x, Splunk Enterprise Security или MaxPatrol SIEM
- EDR на эндпоинтах: CrowdStrike Falcon, Elastic Defend, SentinelOne
- Forensics: Velociraptor (live-response, сбор артефактов), Volatility (анализ дампов памяти)
- Канал коммуникации, изолированный от корпоративной инфраструктуры (Telegram-группа, отдельный Mattermost) - если атакующий контролирует AD, корпоративный Teams бесполезен
Detection - правила корреляции и триггеры для SOC-команды
Идентификация инцидента начинается с алертов. NIST CSF v2.0 (RS.AN-01) требует расследования уведомлений от систем обнаружения. Качество расследования зависит от качества правил - мусорные алерты убивают внимание аналитика быстрее любого ransomware.Минимальный набор detection-правил, привязанных к MITRE ATT&CK:
Containment - decision tree по типу угрозы
Containment - этап, где ошибки стоят дороже всего. Неправильный containment (выключение сервера вместо сетевой изоляции) уничтожает forensic-артефакты в оперативной памяти. Я видел, как админ по привычке дёрнул питание на заражённом сервере - и вместе с питанием ушли ключи шифрования из RAM, которые могли бы помочь расшифровать данные.Ransomware (T1486):
- Изолировать заражённые хосты на уровне сети (карантинный VLAN), НЕ выключая питание
- Заблокировать учётные записи, под которыми работает ransomware
- Немедленно отключить бэкап-серверы от сети, если они ещё не затронуты
- Снять дамп памяти через Velociraptor или
winpmemдо eradication
- Сбросить пароль и отозвать все активные сессии (в AD: сброс пароля + purge Kerberos tickets)
- Проверить, какие системы доступны с этой учёткой (Event ID 4624)
- Искать признаки lateral movement: новые logon-сессии, SMB-подключения, RDP
- НЕ изолировать хост немедленно - начать silent monitoring с расширенным логированием
- Привлечь юриста и HR до любых технических действий
- Собрать evidence chain: полный снимок диска, сетевой трафик, журналы DLP
Eradication и Recovery - от зачистки до ввода в продакшн
Eradication - полное удаление присутствия атакующего. Чеклист:- Все скомпрометированные учётные записи сброшены; krbtgt обновлён дважды при компрометации AD
- Persistence-механизмы удалены: scheduled tasks, Run/RunOnce-ключи реестра, WMI subscriptions
- Вредоносные бинари удалены с подтверждением через hash-сверку
- Уязвимость initial access (T1190) закрыта патчем или компенсирующей мерой
Recovery - поэтапный ввод систем в продакшн. Не включать всё одновременно: критичные сервисы → 24 часа усиленного мониторинга → следующая группа. Мониторинг после recovery важнее мониторинга до инцидента - атакующий может иметь запасной канал доступа.
Lessons Learned - шаблон postmortem, который работает
Post-incident activity (NIST CSF v2.0, RC.CO-01) - этап, который все признают нужным и почти никто не проводит систематически. После инцидента команда устала, бизнес давит «давайте забудем и работаем дальше». Знакомо?Обязательные поля postmortem-документа:
- Timeline - хронология с точностью до минуты: кто что сделал, когда.
- Root Cause - техническая первопричина. Не «сотрудник открыл фишинговое письмо», а «отсутствие блокировки макросов + отсутствие правила корреляции Outlook → cmd.exe».
- What Went Well - что сработало. Без этого пункта postmortem превращается в обвинительный приговор, и следующий инцидент никто не захочет документировать.
- What Went Wrong - конкретные провалы процесса, а не имена людей.
- Action Items - задачи с владельцем и дедлайном: «Настроить корреляцию X - Иванов - до 15.02», а не «улучшить мониторинг».
Автоматизация реагирования на инциденты через SOAR
Когда ручной процесс работает (severity matrix + роли + runbook на каждый тип инцидента), следующий шаг - автоматизация рутины через SOAR-платформу.Что имеет смысл автоматизировать: обогащение алертов - автоматический запрос репутации IP/домена/хеша в VirusTotal, AbuseIPDB. В связке TheHive + Cortex это настраивается через analyzers: при создании алерта Cortex запускает набор проверок и добавляет результаты в карточку кейса. Типовой containment - изоляция хоста через API EDR. В CrowdStrike Falcon -
containment через Falcon API, в SentinelOne - endpoint isolation через Management Console API. SOAR сокращает время containment с 15 минут (ручная изоляция) до секунд. Уведомления - автоматическая отправка по матрице эскалации при P1/P2.Чего не автоматизировать на старте: containment при P1 без human-in-the-loop. Ложное срабатывание с автоматической изоляцией продового сервера обойдётся дороже 5 минут ожидания аналитика. И forensics/root cause analysis - это всегда ручная работа, тут никакой SOAR не поможет.
Минимальная SOAR-связка: Elastic SIEM (detection) → webhook в TheHive (создание кейса) → Cortex analyzers (обогащение) → уведомление в Telegram-канал IR-команды. Для настройки достаточно webhook в Elastic и connector в TheHive - это часы работы, не месяц.
JSON:
// Пример шаблона алерта для TheHive webhook
{
"type": "elastic_siem",
"source": "Elastic SIEM",
"sourceRef": "{{alert.id}}",
"title": "{{rule.name}} - {{host.name}}",
"severity": 2,
"tlp": 2,
"tags": ["elastic", "auto-enrichment"],
"description": "Host: {{host.name}} | User: {{user.name}}"
}Detection-чеклист: порядок внедрения правил для SOC
Если вы строите процесс реагирования на инциденты с нуля, вот приоритизированный порядок. Не пытайтесь закрыть всё за неделю - лучше пять рабочих правил, чем пятьдесят шумных.Неделя 1 (блокирующие правила): мониторинг привилегированных учёток - логины domain admins не с выделенных рабочих станций (T1078); обращения к lsass.exe (T1003); очистка журналов событий (T1070, Event ID 1102); остановка security-сервисов (T1562).
Неделя 2 (высокий приоритет): цепочки процессов от email-клиентов - Outlook/Thunderbird → cmd/powershell (T1566 → T1059); массовое шифрование/переименование файлов (T1486); новые scheduled tasks или WMI subscriptions на серверах.
Неделя 3+ (расширение покрытия): baseline исходящего трафика и обнаружение C2-паттернов (beaconing); UEBA-правила для insider threat - доступ к данным вне нормального паттерна; мониторинг DNS-запросов на длинные поддомены как индикатор DNS-tunneling.
Каждое правило тестируется на false positive rate до включения в production. Правило, генерирующее 200 ложных алертов в день, будет игнорироваться аналитиками через неделю - и именно в этот момент прилетит настоящий инцидент.
Я выстраивал IR-процесс в трёх организациях разного масштаба - от 50 до 2000 эндпоинтов. Каждый раз главная проблема была не техническая. SIEM настраивается за неделю, severity matrix рисуется за день. Проблема в том, что руководство воспринимает incident response как «задачу ИБ-отдела», а не как бизнес-процесс. Пока CEO не подпишет severity matrix и не согласится, что при P1 дежурный аналитик имеет полномочия изолировать серверы без его звонка - процесс работает только на бумаге.
Каждый второй инцидент, который я разбирал, стал P1 не потому, что атакующий был особенно хорош, а потому, что containment затянулся на часы из-за согласований.
И ещё один момент, который редко обсуждают: playbook без регулярных учений - художественная литература. Tabletop-учения раз в квартал - минимум. Берёте сценарий (ransomware в prod, утечка через подрядчика, компрометация VPN), проходите его за 2 часа в переговорке. Без реального стресса, но с реальными вопросами: кто звонит юристу, через сколько минут, по какому номеру. После первого такого прогона вы найдёте в playbook минимум пять дыр, которые на бумаге не видны. Проверено.
Если процесс реагирования в вашем SOC строится прямо сейчас и хочется сверить подходы к severity matrix и runbook'ам с практикой других команд - на codeby.net обсуждают построение IR-процессов с конкретными примерами из реальных проектов.
