Прошлой весной наша DFIR-команда закрыла ransomware-кейс за 52 часа: от первого алерта в SIEM до полного восстановления сервисов из бэкапов. Containment - 4 часа, eradication - сутки, ни один критичный хост не потерян. Блестящее реагирование. А потом начался второй инцидент - оформление результатов.
Executive summary растянулся на 14 страниц. Timeline содержал timestamps в трёх часовых поясах без UTC-привязки. IOC-лист улетел коллегам в Telegram - открытым текстом, без контекста и категоризации. Итог: страховая отклонила компенсацию из-за нечёткой хронологии, регулятор запросил дополнительные разъяснения, а CISO не смог объяснить совету директоров масштаб ущерба. Техническое мастерство обнулилось документацией.
IR отчёт по инциденту - не формальность после закрытия кейса - он завершает полный цикл расследования, который я разобрал в полной карте Incident Response от обнаружения до отчёта. Это артефакт, который определяет, получит ли компания страховую выплату, пройдёт ли аудит и извлечёт ли уроки для hardening инфраструктуры.
Два документа вместо одного: разделяем аудитории
Главная ошибка при составлении incident response документации - попытка написать один универсальный документ. CISO и совет директоров хотят одностраничный executive summary с цифрами ущерба и статусом восстановления. SOC-аналитик и security engineer ожидают хэши, YARA-правила, timestamps с точностью до секунды и маппинг на MITRE ATT&CK. Один документ не закроет обе потребности без потерь.Структура IR отчёта, проверенная на десятках кейсов:
| Документ | Аудитория | Объём | Содержание |
|---|---|---|---|
| Executive Summary | CISO, совет директоров, юристы, регулятор | 1–2 страницы | Что произошло, масштаб ущерба, статус, следующие шаги |
| Технический отчёт | SOC, IR-команда, security engineers | 10–30 страниц + приложения | Timeline, root cause, IOC, TTPs, рекомендации |
Оба документа ссылаются на один incident ID и единый timeline. Разница - в глубине детализации и языке. По требованиям NIST SP 800-53 Rev 5 (контроль IR-1, семейство Incident Response), incident response документация должна покрывать цели, роли и ответственность, а также координацию между подразделениями. На практике это значит: каждое подразделение читает свой слой одного расследования.
Executive summary: отчёт для руководства по инциденту
Executive summary - не сокращённая версия технического отчёта. Это отдельный документ с собственной логикой. Задача: дать decision maker-у достаточно информации для принятия решений за пять минут чтения.Обязательные разделы executive summary
- Incident ID и классификация - уникальный идентификатор, severity (P1–P4), тип инцидента (ransomware, data breach, unauthorized access).
- Хронология в три строки - когда обнаружили, когда сдержали, когда восстановили. Без технических деталей, только даты и длительности.
- Масштаб воздействия - какие бизнес-процессы затронуты, сколько систем и пользователей пострадало, есть ли утечка персональных данных. Последнее критично для уведомления регулятора: по GDPR уведомление требуется в течение 72 часов (как отмечено в материалах Graylog и DataGuard), по российскому законодательству сроки определяются требованиями Роскомнадзора.
- Финансовая оценка - прямые потери (простой, стоимость восстановления) и косвенные (репутационный ущерб, потенциальные штрафы). Оборотные штрафы за утечку ПДн в России могут составлять до 3% от выручки - эта цифра обязана присутствовать в executive summary, если затронуты персональные данные.
- Текущий статус - инцидент закрыт, в процессе, требует дополнительных действий.
- Ключевые рекомендации - три-пять пунктов верхнего уровня. Не «внедрить MFA», а «инвестировать N в проект Y со сроком Z».
Timeline инцидента: хронология от первого алерта до восстановления
Timeline - скелет любого отчёта об инциденте информационной безопасности. Без чёткой хронологии невозможно восстановить причинно-следственные связи, определить dwell time атакующего и оценить скорость реагирования. По моему опыту, именно timeline чаще всего вызывает вопросы при аудите и у страховых компаний.Принципы построения timeline
Единый часовой пояс. Все timestamps - в UTC. Если источник данных использует локальное время (Windows Event Log по умолчанию пишет в локальной зоне), конвертация выполняется явно с указанием исходной зоны. Формат:YYYY-MM-DD HH:MM:SS UTC.Гранулярность зависит от фазы. Для initial access и lateral movement - секунды. Для фазы восстановления - часы. Каждый execution атакующего фиксируется обязательно, каждый перезапуск сервиса - нет.
Источник каждой записи. Каждая строка timeline содержит ссылку на артефакт: лог SIEM, дамп памяти, pcap-файл, скриншот EDR-консоли. Без привязки к артефакту запись - голословное утверждение, которое не выдержит проверки аудитом. Видел отчёты, где в timeline стояло «предположительно в районе 14:00» - такое страховая просто вычёркивает.
Пример timeline для ransomware-инцидента
| Время (UTC) | Событие | Источник | MITRE ATT&CK |
|---|---|---|---|
| 2025-03-10 08:42:15 | Пользователь N открыл вложение из фишингового письма | Exchange logs, EDR | Phishing (T1566, Initial Access) |
| 2025-03-10 08:42:47 | Запуск PowerShell с обфусцированной командой на хосте WS-0142 | EDR telemetry | Command and Scripting Interpreter (T1059, Execution) |
| 2025-03-10 09:15:03 | Создан сервисный аккаунт svc_backup02 | Windows Security Event 4720 | Valid Accounts (T1078, Persistence) |
| 2025-03-10 09:18–14:33 | Lateral movement через RDP с использованием svc_backup02 | Network logs, EDR | - |
| 2025-03-10 14:45:22 | Массовое копирование файлов из \\\\FS01\\Finance | EDR, file audit log | Data from Local System (T1005, Collection) |
| 2025-03-10 15:02:11 | Эксфильтрация ~12 ГБ на внешний IP через HTTPS | Proxy logs, NetFlow | Exfiltration Over C2 Channel (T1041, Exfiltration) |
| 2025-03-10 15:30:00 | Запуск шифровальщика на 47 хостах | EDR, SIEM correlation | Data Encrypted for Impact (T1486, Impact) |
| 2025-03-10 15:31:12 | Первый алерт SIEM - аномалия массового изменения расширений файлов | SIEM | - |
| 2025-03-10 15:45:00 | IR-команда начала containment | IR log | - |
| 2025-03-10 19:50:00 | Все затронутые сегменты изолированы | Network device logs | - |
Между запуском шифровальщика (15:30) и первым алертом (15:31) прошла минута - это detection gap. Между алертом и началом containment - 14 минут. Метрики MTTD (Mean Time to Detect) и MTTR (Mean Time to Respond) выносятся в отчёт отдельным блоком, потому что именно их будут разбирать на postmortem.
Инструменты для построения timeline
Для автоматизированного сбора временных меток подходит Plaso (log2timeline) - парсит десятки форматов артефактов (Windows Event Log, MFT, Registry, browser history) и собирает единую хронологию. Визуализация - через Timesketch: фильтрация событий по источнику, аннотации IR-команды, совместная работа. Оба проекта open-source, развиваются в рамках dfTimewolf.Требования к окружению: Plaso - Linux-хост с минимум 8 ГБ RAM (для образов дисков - 16 ГБ); Timesketch разворачивается в Docker (Docker Compose, 4+ ГБ RAM под контейнеры). На Windows Plaso работает через WSL2, но стабильнее - нативный Linux.
| Инструмент | Задача | Ограничения | Когда использовать |
|---|---|---|---|
| Plaso / log2timeline | Парсинг артефактов в единый timeline | Медленный на больших образах (>500 ГБ); требует ручной фильтрации шума | Полный forensic-анализ, когда есть образ диска |
| Timesketch | Визуализация и аннотирование timeline | Не парсит артефакты - только отображает результат Plaso/других парсеров | Совместная работа IR-команды, презентация результатов |
| DFIR-IRIS | Ведение кейса + timeline + IOC | Требует развёртывания (Docker), кривая обучения ~2 дня | Полный цикл IR: от тикета до отчёта |
Технический отчёт по киберинциденту: тело документа
Технический отчёт - основной рабочий документ расследования. Его читают SOC-аналитики, security engineers, при необходимости - внешние аудиторы и правоохранительные органы. Структура IR отчёта включает несколько обязательных секций, и каждая решает свою задачу.Root Cause Analysis
Задача - определить не «что случилось», а «почему это стало возможным». Методология 5 Whys (описанная в руководствах AccountableHQ и VComply) раскладывает причинную цепочку:- Почему шифровальщик запустился? - Атакующий получил привилегии domain admin.
- Почему получил? - Использовал сервисный аккаунт svc_backup02 с чрезмерными привилегиями.
- Почему аккаунт имел такие привилегии? - Создан для миграции два года назад, не отключён.
- Почему не отключён? - Нет процесса ревизии сервисных учётных записей.
- Почему нет процесса? - Отсутствует владелец задачи и регламент, baseline легитимных аккаунтов не зафиксирован.
Отдельно стоит зафиксировать: скомпрометированный аккаунт - инсайдерская угроза или нет? Использование Valid Accounts (T1078) для persistence требует верификации: аккаунт создан атакующим или скомпрометирован у легитимного сотрудника. Разница влияет и на remediation, и на юридические последствия.
Маппинг на MITRE ATT&CK
Каждая выявленная тактика и техника документируется с T-кодом и тактикой. Маппинг позволяет:- оценить coverage существующих detection правил - какие техники SIEM видел, какие пропустил;
- сравнить TTPs с известными группировками через threat intelligence;
- сформировать задачи на закрытие detection gaps.
Затронутые системы и данные
Раздел документирует перечень скомпрометированных хостов (hostname, IP, роль в инфраструктуре), тип затронутых данных (ПДн, финансовые, интеллектуальная собственность), объём потенциальной утечки и нарушенные бизнес-процессы. Если затронуты персональные данные - этот факт формирует обязательства по уведомлению. Документируйте чётко: какие категории данных, какой объём, есть ли подтверждение эксфильтрации (а не только доступа). «Атакующий имел доступ к шаре» и «атакующий выгрузил 12 ГБ через HTTPS» - принципиально разные формулировки для регулятора.IOC-приложения к отчёту: формат и структура
Индикаторы компрометации выносятся в отдельные приложения к техническому отчёту. Причина проста: IOC-лист - рабочий артефакт, который SOC-команда немедленно загружает в SIEM и EDR для блокировки и мониторинга. IOC, похороненные на 15-й странице текста, - мёртвый груз.Рекомендации после инцидента ИБ: от quick wins до системных изменений
Раздел рекомендаций - самая практически ценная часть post-incident report для организации. Здесь техническое расследование превращается в план действий. По требованиям NIST Cybersecurity Framework v2.0 (функция RECOVER, подкатегория RC.CO-01), организация должна управлять коммуникациями по восстановлению, включая передачу рекомендаций всем заинтересованным сторонам.Приоритизация рекомендаций
Quick wins (1–7 дней):- Блокировка выявленных IOC на периметре и endpoint-уровне
- Сброс паролей скомпрометированных учётных записей
- Отключение сервисных аккаунтов, использованных атакующим
- Развёртывание временных правил корреляции в SIEM для detection повторной активности
- Внедрение мониторинга lateral movement (Sigma-правила на аномальные RDP/SMB-сессии, отклонения от baseline сетевого трафика)
- Ревизия привилегированных учётных записей, внедрение PAM
- Закрытие detection gaps, выявленных при маппинге на MITRE ATT&CK
- Пересмотр playbook по этому типу инцидента
- Пересмотр архитектуры сегментации сети
- Внедрение или обновление EDR на всех endpoint
- Проведение table-top учений по сценарию аналогичного инцидента
Ограничения рекомендаций
Тут нужна честность. Quick wins работают, пока атакующий не сменил инфраструктуру - а C2-адреса ротируются за дни. Sigma-правила на lateral movement дают ложные срабатывания в средах с легитимным RDP-трафиком между серверами (а это почти любая enterprise-сеть). PAM - отличная штука, но внедрение в организации с 500+ сервисных аккаунтов занимает не 3 месяца, а 6–9. Закладывайте реалистичные сроки, иначе рекомендации превращаются в wish list.Lessons learned: что фиксировать
Lessons learned - не «мы должны быть внимательнее». Это конкретные gaps, выявленные при реагировании:- Detection gap: SIEM не имел правила корреляции на массовое создание сервисных аккаунтов. Действие: написать Sigma-правило, протестировать на историческом потоке, внедрить в production.
- Process gap: IR playbook не описывал процедуру изоляции подсети с критичными финансовыми данными. Действие: дополнить playbook, провести dry-run с участием сетевой команды.
- Communication gap: уведомление DPO о возможной утечке ПДн произошло через 18 часов вместо регламентных 4. Действие: включить DPO в escalation-цепочку с первого часа инцидента.
Чеклист: финальная проверка IR отчёта перед передачей
Этот чеклист - контрольный лист перед отправкой документа заказчику, руководству или регулятору. Распечатайте и пройдитесь ручкой.- Incident ID присвоен, используется единообразно во всех документах
- Executive summary не превышает 2 страницы и не содержит технического жаргона
- Timeline приведён к UTC, каждая строка содержит ссылку на источник артефакта
- MTTD и MTTR рассчитаны и вынесены явно
- Root cause сформулирован как процессный или организационный gap, а не как «пользователь кликнул»
- MITRE ATT&CK маппинг покрывает все выявленные техники с T-кодами
- Затронутые системы перечислены с hostname, IP и ролью в инфраструктуре
- Факт утечки ПДн зафиксирован или явно исключён, указаны объём и категории данных
- Инсайдерский вектор верифицирован: скомпрометированный легитимный аккаунт отличён от аккаунта, созданного атакующим
- IOC-приложение оформлено отдельным документом с категоризацией и контекстом
- IOC содержат хэши SHA256, сетевые индикаторы и поведенческие правила (Sigma/YARA)
- Рекомендации разделены на quick wins, среднесрочные и системные
- Каждая рекомендация имеет ответственного, срок и критерий выполнения
- Lessons learned привязаны к конкретным точкам timeline
- Документ проверен вторым членом IR-команды (four-eyes principle)
- Чувствительные данные (пароли, токены, внутренние IP) удалены из финальной версии или замаскированы
- Отчёт передаётся в зашифрованном виде, пароль - по отдельному каналу
За три года в DFIR я видел отчёты от двух десятков внешних IR-команд и внутренних SOC. Закономерность чёткая: качество реагирования и качество отчёта почти никогда не коррелируют. Команды, которые блестяще сдерживают инцидент за часы, регулярно проваливают документирование - timeline без источников, IOC без контекста, recommendations без сроков. И наоборот: бывают посредственные расследования, упакованные в безупречные отчёты, которые проходят аудит без замечаний.
Проблема системная. В индустрии нет единого стандарта IR-отчёта. NIST SP 800-61 описывает процесс реагирования, но не формат финального документа. ISO 27035 задаёт фреймворк, но не шаблон. Каждая команда изобретает свой формат, и каждый следующий заказчик тратит время на «переваривание» уникальной структуры.
Мой прогноз: в ближайшие пару лет индустрия придёт к machine-readable IR-отчётам. Timeline, IOC и рекомендации будут генерироваться из платформы (TheHive, DFIR-IRIS) в стандартизированном формате и автоматически загружаться в SIEM для закрытия detection gaps. Ручное написание 30-страничных документов в Word не масштабируется. Но пока автоматизация не стала нормой - умение структурировать отчёт руками отличает IR-аналитика от человека, который «просто смотрит логи».
Проверьте свой последний IR-отчёт по чеклисту выше. Если набрали меньше 12 из 17 - у вас та же проблема, что и у большинства команд. На форуме codeby.net есть тред, где обсуждают шаблоны IR-отчётов и разбирают типичные ошибки в документировании инцидентов - полезно заглянуть, если собираете собственную базу шаблонов.
Последнее редактирование:
