Статья Расследование кибератаки: полная карта Incident Response от обнаружения до отчёта

По данным Mandiant M-Trends 2025, 57% организаций узнают о компрометации от внешней стороны - партнёра, регулятора или журналиста. Не от своего SIEM, не от SOC-аналитика, не из алерта EDR. Медианное время нахождения атакующего в сети до обнаружения - 11 дней. Это исторический минимум, но за эти 11 дней злоумышленник успевает пройти полный kill chain: от первичного доступа через фишинг (T1566) до выгрузки данных через C2-канал (T1041) или шифрования инфраструктуры (T1486). Расследование кибератаки - это не «поставить антивирус и переустановить Windows». Это управляемый процесс с чёткими фазами, инструментами и артефактами, в котором каждая ошибка стоит доказательств, денег и репутации.

Карта темы: от алерта до отчёта​

#	Подтема	Подробнее
1	Первые 30 минут: triage и изоляция	Реагирование на инциденты ИБ: от алерта до изоляции за 30 минут
2	Полный цикл расследования: triage - анализ - отчёт	IR расследование кибератаки: пошаговый разбор от triage до отчёта
3	Форензика Windows: артефакты	Форензика Windows: пошаговый разбор артефактов при расследовании инцидента
4	Форензика Windows: методика сбора	Методика сбора и анализа артефактов
5	Анализ памяти через Volatility 3	Анализ дампов памяти Volatility 3: обнаружение малвари и инъекций
6	Threat hunting: lateral movement	SIEM-запросы и поиск бокового перемещения во время инцидента
7	IR Playbook: построение процесса	Как построить процесс реагирования на инциденты с нуля
8	Отчёт по инциденту: структура и IOC	IR отчёт: структура, timeline и IOC-приложения
9	Кейс ShinyHunters / Amtrak	Разбор атаки через Salesforce: TTPs и detection-чеклист

Почему 57% компаний узнают о взломе не от своего SOC​

Цифра из Mandiant M-Trends 2025 выглядит как приговор, но за ней стоит системная проблема: разрыв между «мы мониторим» и «мы умеем расследовать». Организация может иметь SIEM, EDR на каждом эндпоинте, SOC с круглосуточной сменой - и всё равно пропустить атакующего, который использует валидные учётные записи (T1078) и легитимные интерпретаторы команд (T1059).

По данным IBM X-Force Threat Intelligence Index 2025, 70% атак затронули критическую инфраструктуру, а самым распространённым типом вредоносного ПО стали инфостилеры (32%), опередив шифровальщиков. Среднее время между публикацией CVE и устранением в организации - 29 месяцев. Атакующим не нужны zero-day, когда окно в 2,5 года открыто для всех.

Реагирование на инциденты информационной безопасности - это не опциональный процесс для «крупных компаний с бюджетом». Это базовая операционная функция, без которой любая инвестиция в защиту превращается в театр безопасности. Incident response процесс определяет, останется ли инцидент локальным эпизодом на одном хосте или превратится в компрометацию всего домена с шифрованием бэкапов.

Практический takeaway: если ваша команда тратит на детект больше 15 минут от момента алерта до начала triage - начните с пересмотра правил корреляции в SIEM. Каждая минута промедления расширяет зону поражения.

Подробный разбор первых действий при алерте: Реагирование на инциденты ИБ: от алерта до изоляции за 30 минут

NIST vs SANS: 2 фреймворка реагирования на инциденты​

Прежде чем разбирать кибератаку руками, нужна методологическая рамка. Два ключевых фреймворка - NIST SP 800-61 Rev.2 и SANS - описывают один и тот же процесс разными словами. (Примечание: NIST SP 800-61 Rev.3, вышедший в 2025 году, пересмотрел модель и интегрировал её с CSF 2.0 функциями GV/ID/PR/DE/RS/RC, однако классические 4 фазы Rev.2 остаются применимы для практических playbooks.)

Этап	NIST	SANS
1	Preparation	Preparation
2	Detection & Analysis	Identification
3	Containment, Eradication & Recovery	Containment
4	Post-Incident Activity	Eradication
5	-	Recovery
6	-	Lessons Learned

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

На практике выбор фреймворка вторичен. Критичен сам факт наличия документированного IR-плана, который команда отрабатывала на учениях. NIST SP 800-53 (контроль IR-1) предписывает разработать, документировать и распространить политику реагирования на инциденты, включая роли, ответственность и координацию между подразделениями. Этот контроль обязателен для федеральных систем США (FISMA), но широко применяется как baseline и в коммерческом секторе.

Чеклист выбора фреймворка:

• Команда до 5 человек, нет выделенного IR-менеджера - берите SANS (линейная последовательность проще для небольших команд)
• Параллельные процессы, несколько аналитиков на инциденте - NIST (разрешает overlap между фазами)
• Регулируемая отрасль с требованиями по документированию - NIST (лучше ложится на compliance-отчёты)

Как выстроить IR-процесс на основе этих фреймворков мы детально разобрали в гайде IR Playbook для security-команды: как построить процесс реагирования на инциденты с нуля

Подготовка: что должно быть готово до первого инцидента​

Подготовка - самый недооценённый и самый дешёвый этап расследования инцидента ИБ. Каждый рубль, потраченный здесь, экономит десятки тысяч на стадии активного реагирования. Команды с проактивными детект-возможностями существенно сокращают Mean Time to Detect (MTTD).

Команда реагирования​

Минимальная структура IR-команды:

Роль	Задача	Когда нужен
IR-менеджер	Координация, эскалация, коммуникация с руководством	С момента объявления инцидента
SOC-аналитик (L2/L3)	Triage, корреляция событий, анализ алертов	Первые 15 минут
Форензик-аналитик	Сбор и анализ артефактов, цепочка хранения доказательств	Час 1-4
Threat hunter	Проактивный поиск связанной активности в инфраструктуре	Час 2-8
Юрист / compliance	Оценка правовых рисков, уведомление регуляторов	Час 4-12

Инфраструктура мониторинга​

Без определённого стека инструментов обнаружение и расследование инцидента невозможно в принципе. OWASP фиксирует эту проблему в категории A09:2021 - Security Logging and Monitoring Failures: «без логирования и мониторинга утечки не могут быть обнаружены».

Минимально необходимый стек:

• SIEM (Splunk, Elastic Stack, MaxPatrol SIEM) для централизованного сбора и корреляции логов
• EDR на конечных точках для поведенческого анализа процессов
• Сетевой мониторинг (Zeek, Suricata) для анализа трафика
• Forensic toolkit на выделенной станции (подробнее - в разделе «Инструменты»)

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

Обнаружение и triage: первые 30 минут решают всё​

Расследование кибератаки начинается в момент, когда аналитик видит алерт и должен за минуты решить: это ложное срабатывание или начало компрометации?

Источники обнаружения​

Как расследовать кибератаку, если не знаете, откуда ждать сигнал? Типичные каналы:

• SIEM-алерт: корреляция событий выявила цепочку - вход из нетипичной геолокации, массовый доступ к файлам, попытка дампа учётных данных (T1003)
• EDR-детект: процесс powershell.exe (T1059.001) запустил certutil -encode с выгрузкой на внешний хост
• Внешнее уведомление: CERT, партнёр, правоохранительные органы - те самые 57% из статистики Mandiant
• Пользовательская заявка: «у меня все файлы стали .encrypted» - случай, когда расследование начинается постфактум

Workflow первичного triage​

Первые 15 минут после алерта:

1. Оценка масштаба: сколько хостов затронуто, какие сегменты сети, тип данных под угрозой
2. Классификация: false positive, security event или подтверждённый инцидент
3. Приоритизация: не по принципу «первый пришёл - первый обслужен», а по влиянию на бизнес-функции и тип скомпрометированных данных
4. Эскалация: уведомление IR-менеджера, открытие тикета с таймлайном

Вся процедура от получения алерта до принятия решения об изоляции детально описана в нашем гайде Реагирование на инциденты ИБ: от алерта до изоляции за 30 минут, а полный цикл от triage до отчёта - в материале IR расследование кибератаки: пошаговый разбор от triage до отчёта

Сдерживание: 3 стратегии, которые не дают атаке расползтись​

Сдерживание - самый стрессовый этап incident response процесса. Здесь каждое действие имеет побочные эффекты: изоляция сервера может остановить бизнес-процесс, блокировка учётной записи - заблокировать сервисный аккаунт, от которого зависит продуктив.

Краткосрочное сдерживание (минуты)​

• Сетевая изоляция скомпрометированного хоста через EDR или VLAN-сегментацию - хост остаётся включённым, данные в RAM сохраняются
• Блокировка подозрительных IP-адресов на файрволе
• Отключение скомпрометированной учётной записи в Active Directory (но не удаление - она ещё нужна для форензики)

Долгосрочное сдерживание (часы)​

• Перестройка сетевых ACL для изоляции сегмента
• Ротация credentials для сервисных учётных записей
• Развёртывание дополнительного мониторинга на «чистых» сегментах - атакующий мог закрепиться там, где вы ещё не смотрели

Чего нельзя делать при сдерживании​

Команда Solar 4RAYS в своих расследованиях фиксирует типичные ошибки: перезагрузка системы уничтожает данные оперативной памяти - активные процессы, сетевые соединения, фрагменты команд атакующих. Переустановка Windows без предварительного расследования не решает проблему, если использовались скомпрометированные учётные записи или атакующий проник через другой хост в сети.

Правило: никогда не перезагружайте и не переустанавливайте систему до снятия дампа памяти и создания forensic-образа диска.

Цифровая криминалистика: где искать следы атакующего​

Форензика инцидента - это наукоёмкая часть DFIR-расследования, где аналитик восстанавливает таймлайн атаки по цифровым артефактам. Здесь ошибка в последовательности сбора доказательств может сделать их юридически ничтожными.

Порядок сбора: что пропадёт первым​

Цифровая криминалистика следует принципу волатильности - сначала собираем то, что исчезнет быстрее всего:

1. Оперативная память (RAM) - процессы, сетевые соединения, расшифрованные данные, инъектированный код (T1055). Исчезает при выключении или перезагрузке
2. Сетевые соединения - текущие TCP/UDP-сессии, DNS-кеш
3. Временные файлы и логи - могут быть перезаписаны ротацией
4. Образ диска - наименее волатильный, но нужен bit-by-bit копия до начала любого анализа

Анализ памяти​

Дамп памяти - один из самых ценных артефактов. В нём видно то, что не попадает в логи и на диск: injected DLL в легитимном процессе, расшифрованные C2-адреса, аргументы командной строки уже завершившихся процессов.

Практический workflow анализа дампов через Volatility 3 - включая обнаружение process injection и скрытых вредоносных модулей - мы разбираем в отдельном материале: Анализ дампов памяти Volatility 3: практический workflow обнаружения малвари и инъекций

Артефакты Windows​

Windows-среда генерирует десятки типов артефактов, релевантных для расследования:

Артефакт	Что показывает	Где находится
Windows Event Log (Security)	Входы, выходы, изменения привилегий	%SystemRoot%\System32\winevt\Logs\
Prefetch	Запуск программ с таймстампами	C:\Windows\Prefetch\
Amcache / ShimCache	История запусков исполняемых файлов	Registry hive
$MFT	Метаданные файловой системы	NTFS
USN Journal	Изменения файлов в хронологическом порядке	NTFS
SRUM	Сетевая активность приложений	%SystemRoot%\System32\sru\

Каждый из этих артефактов может подтвердить или опровергнуть гипотезу о действиях атакующего: удалил ли он файлы (T1070), какие инструменты запускал, к каким ресурсам обращался.

Пошаговый разбор работы с этими артефактами описан в двух наших материалах:

• Форензика Windows: пошаговый разбор артефактов при расследовании инцидента
• Форензика Windows при расследовании инцидентов: методика сбора и анализа артефактов

Сетевая форензика​

Анализ сетевого трафика помогает восстановить каналы управления и маршруты эксфильтрации. Ключевые источники:

• PCAP-файлы - полный захват сетевого трафика (Wireshark, tcpdump)
• Логи файрвола - входящие и исходящие соединения с решениями deny/allow
• DNS-логи - запросы к подозрительным доменам, DNS-туннелирование
• Proxy/Web-логи - HTTP-запросы, User-Agent строки, загрузки файлов
• NetFlow/IPFIX - метаданные сетевых потоков для выявления аномальных объёмов передачи данных

Threat hunting во время инцидента: поиск того, что пропустил SIEM​

Когда инцидент подтверждён и начальная зона компрометации определена, возникает главный вопрос: «Где ещё мог быть атакующий?». Стандартные SIEM-правила ловят известные паттерны, но threat hunting во время инцидента - это проактивный поиск активности, которая не вызвала алертов.

Lateral movement: почему это первый приоритет для хантинга​

Боковое перемещение - основной механизм расширения зоны компрометации. Атакующий, получивший доступ к одному хосту, будет перемещаться к контроллерам домена, файловым серверам и серверам бэкапов. Следы этого перемещения - аномальные аутентификации, нетипичные сетевые соединения между рабочими станциями, использование инструментов вроде PsExec, WMI или PowerShell Remoting.

На что охотиться в первую очередь​

• Аномальные logon-события: Event ID 4624 (тип 3 - сетевой вход) между хостами, которые обычно не взаимодействуют
• Дампинг учётных данных: обращения к lsass.exe, нетипичные процессы, загружающие DLL для дампа (T1003)
• Command & Control: периодические DNS-запросы к одному домену с фиксированным интервалом, нетипично длинные TXT-записи
• Persistence: новые записи в Run/RunOnce, новые scheduled tasks, изменения в GPO

Подробный разбор SIEM-запросов для поиска бокового перемещения - с конкретными Splunk/Elastic-запросами и логикой корреляции - в материале Threat hunting lateral movement: SIEM-запросы и поиск бокового перемещения во время инцидента

Устранение и восстановление: почему «переустановить Windows» не работает​

Устранение угрозы - это не «удалить найденный .exe и забыть». Это систематический процесс ликвидации всех точек присутствия атакующего в инфраструктуре. Если остался один скомпрометированный сервисный аккаунт или одна закладка в GPO - инцидент повторится.

Порядок устранения​

1. Составьте полный список IOC - хеши файлов, IP-адреса C2-серверов, доменные имена, скомпрометированные учётные записи
2. Проверьте все хосты на наличие IOC - через EDR sweep или централизованный поиск по SIEM
3. Ликвидируйте persistence-механизмы - записи реестра, scheduled tasks, WMI-подписки, бэкдоры в web shell'ах
4. Сбросьте credentials - пароли скомпрометированных учётных записей, сервисных аккаунтов, KRBTGT (дважды, с интервалом)
5. Пропатчите вектор входа - уязвимость, через которую атакующий попал в инфраструктуру

Восстановление​

Восстановление из бэкапов требует верификации: если атакующий находился в инфраструктуре недели или месяцы, в резервных копиях могут находиться его закладки. Прежде чем разворачивать бэкап - проведите Compromise Assessment на образе бэкапа.

Контрольный чеклист восстановления:

• Бэкап проверен на наличие IOC из текущего расследования
• Все скомпрометированные учётные записи заблокированы и пересозданы
• Уязвимость входа устранена (патч, изменение конфигурации)
• Усиленный мониторинг развёрнут на восстановленных системах
• Правила детекта обновлены с учётом TTPs из текущего инцидента

Отчёт по инциденту безопасности: 2 отчёта для 2 аудиторий​

Расследование инцидента ИБ не считается завершённым без финального документа. На практике требуются два отчёта: для бизнеса (CISO, руководство, регуляторы) и для техкоманды (SOC, IT, IR-команда).

Структура бизнес-отчёта​

• Executive Summary: масштаб, ущерб, статус в 3-5 предложениях
• Timeline: ключевые события на оси времени - от первичного доступа до полного устранения
• Impact Assessment: затронутые данные, системы, бизнес-процессы
• Root Cause: как атакующий проник и почему защита не сработала
• Рекомендации: конкретные меры по предотвращению повторения

Структура технического отчёта​

• Детальный timeline с Event ID, IP-адресами и hash-значениями
• Kill chain атаки с маппингом на MITRE ATT&CK
• IOC-приложение: полный перечень индикаторов компрометации для загрузки в SIEM/EDR
• Forensic findings: артефакты, снимки, команды, которые использовались для анализа
• Detection gaps: что пропустила текущая система детекта и почему

Полный шаблон отчёта с примерами timeline и IOC-приложений: IR отчёт по инциденту: структура, timeline и IOC-приложения для бизнеса и техкоманды

Post-Incident Review: Lessons Learned​

Post-incident analysis - обязательная встреча после каждого значимого инцидента. Её цель не поиск виноватых, а улучшение процессов:

• Что сработало хорошо в процессе реагирования
• Где были задержки и почему
• Какие данные понадобились, но не были доступны
• Какие правила детекта нужно добавить
• Какие процедуры из IR Playbook нужно обновить

Как увидеть разбор кибератаки на реальном кейсе с конкретными TTPs и detection-чеклистом - в нашем материале ShinyHunters взлом Amtrak: разбор атаки через Salesforce, TTPs и detection-чеклист

Инструменты DFIR-расследования: минимальный и расширенный стек​

Incident response своими руками невозможен без конкретного набора инструментов. Ниже - минимальный стек, на котором можно провести полноценное расследование.

Требования к окружению​

• Forensic workstation: Windows 10/11 или Ubuntu 22.04+, минимум 16 ГБ RAM (32 ГБ рекомендуется для работы с дампами памяти > 8 ГБ), SSD от 500 ГБ
• Сеть: изолированная forensic VLAN или offline-режим для анализа образов
• Права: для удалённого сбора артефактов нужны административные привилегии на целевых хостах

Стек по категориям​

Категория	Инструмент	Назначение	Стоимость
Сбор артефактов	KAPE	Быстрый сбор ключевых артефактов Windows	Бесплатно (лицензия для коммерческого использования)
Сбор артефактов	Velociraptor	Агентный сбор с удалённых хостов, VQL-запросы	Open source
Анализ памяти	Volatility 3	Парсинг дампов RAM, обнаружение инъекций	Open source
Образы дисков	FTK Imager	Создание forensic-образов, bit-by-bit копии	Бесплатно
Анализ дисков	Autopsy	Комплексный анализ дисковых образов	Open source
Сетевой анализ	Wireshark	Анализ PCAP, реконструкция сессий	Open source
Корреляция событий	Splunk / Elastic Stack	SIEM, агрегация логов, корреляционные запросы	Community edition / Open source
Threat detection	Hayabusa	Автоматизированный анализ Windows Event Logs на базе Sigma-правил	Open source
Malware analysis	Any.run	Динамический анализ подозрительных файлов в песочнице	Freemium
IOC matching	YARA	Создание правил для поиска известных угроз	Open source
Threat Intel	MISP	Обмен и обогащение IOC	Open source

Платформы расследования​

Для команд, которым нужно покрыть весь цикл одним инструментом, существуют investigation platforms - Cyber Triage, Magnet AXIOM Cyber. Они объединяют сбор, парсинг и анализ артефактов в одном интерфейсе и поддерживают совместную работу нескольких аналитиков над одним кейсом.

Когда хватит бесплатного стека: расследование локального инцидента на 1-10 хостах, аналитик работает один, юридическая значимость доказательств не требуется.

Когда нужна коммерческая платформа: расследование в enterprise-среде (100+ хостов), параллельная работа нескольких аналитиков, требования к chain of custody для суда.

Практическое руководство по развёртыванию DFIR-лаборатории с нуля - настройка Velociraptor, KAPE, EZ Tools и Autopsy, конфигурация агентов и пошаговый сбор артефактов - собрано в отдельном материале: DFIR инструменты 2025: настройка лаборатории и сбор артефактов

7 ошибок, которые уничтожают доказательства при расследовании​

Каждая из этих ошибок встречается в реальных расследованиях, и каждая стоит конкретных доказательств:

1. Перезагрузка скомпрометированного хоста - уничтожает содержимое оперативной памяти: активные процессы, сетевые соединения, расшифрованные данные в памяти малвари
2. Переустановка ОС без forensic-образа - уничтожает все дисковые артефакты, Timeline, MFT, журналы событий
3. Запуск антивирусного сканирования на «живом» хосте - может удалить или изменить вредоносные файлы до их анализа
4. Оплата выкупа без расследования - не гарантирует возврат данных, мотивирует атакующих на повторную атаку, не закрывает вектор входа
5. Включение ранее выключенных машин - вы не знаете, была ли машина заражена до выключения. Без Compromise Assessment любое включение потенциально активирует закладку
6. Отсутствие документирования своих действий - каждая команда, каждый запрос к SIEM, каждый снятый образ должны фиксироваться с таймстампом в журнале инцидента
7. Изоляция без снятия volatile данных - если сначала отключить сеть, а потом снимать дамп памяти, сетевые артефакты уже будут утеряны. Правильный порядок: дамп RAM, затем сетевая изоляция

Маппинг атаки на MITRE ATT&CK: как расследовать кибератаку системно​

Расследование инцидента ИБ пошагово выстраивается вокруг восстановления kill chain атакующего. MITRE ATT&CK предоставляет общий язык для описания TTPs и помогает убедиться, что ни один этап атаки не пропущен.

Типичная цепочка ransomware-атаки в корпоративной AD-среде:

Этап kill chain	Техника MITRE ATT&CK	Что искать
Initial Access	T1566 Phishing	Подозрительные вложения, URL в почте
Execution	T1059 Command and Scripting Interpreter	PowerShell с Base64 (T1059.001), cmd.exe от нетипичного процесса (T1059.003)
Privilege Escalation	T1078 Valid Accounts	Логон с сервисным аккаунтом на рабочую станцию
Credential Access	T1003 OS Credential Dumping	Доступ к lsass.exe, секретам SAM/LSA
Defense Evasion	T1070 Indicator Removal	Очистка журналов событий, удаление файлов
Privilege Escalation	T1055 Process Injection	Инъекция кода в легитимные процессы
Exfiltration	T1041 Exfiltration Over C2 Channel	Аномальный объём исходящего трафика
Impact	T1486 Data Encrypted for Impact	Массовое переименование файлов, появление ransom notes

Маппинг каждого найденного артефакта на конкретную технику ATT&CK - обязательная часть финального отчёта. Это не только структурирует расследование, но и помогает написать detection-правила для предотвращения аналогичных атак.

Куда движется Incident Response в 2025-2026​

Три тенденции, которые меняют расследование кибератак прямо сейчас:

Автоматизация triage через SOAR и AI. По данным CrowdStrike Global Threat Report 2025, вредоносное использование GenAI для социальной инженерии удвоилось за год. IBM фиксирует, что генерация фишинговых писем через GenAI происходит в 11,4 раза быстрее при сопоставимом качестве. Объём атак растёт, и ручной triage каждого алерта больше не масштабируется. Команды, не внедряющие автоматизацию рутинных этапов реагирования, будут тонуть в потоке.

Cloud IR как отдельная дисциплина. Расследование инцидента в облачной среде (AWS, Azure, GCP) принципиально отличается от on-premise: другие источники логов, другая модель доступа, shared responsibility model. Forensic-образы виртуальных машин снимаются через API, а не через FTK Imager на физическом хосте.

Сокращение dwell time обнажает слабость восстановления. Медиана в 11 дней - хорошая новость для детекта. Плохая новость в том, что 23% расследований по данным Mandiant всё ещё связаны с ransomware. Атакующие становятся быстрее, и фокус IR смещается с «как обнаружить» на «как восстановиться за часы, а не за недели».

Чеклист реагирования на инцидент: готовый шаблон для команды​

1. Зафиксировать время обнаружения, источник алерта, затронутые системы
2. Классифицировать инцидент: severity (Low/Medium/High/Critical), тип (malware / unauthorized access / data breach / DoS)
3. Снять дамп оперативной памяти до любых других действий
4. Изолировать скомпрометированные хосты от сети (не выключать)
5. Собрать forensic-образы дисков и сетевые логи
6. Определить вектор первичного проникновения (initial access)
7. Выявить все затронутые учётные записи и системы
8. Составить полный перечень IOC (хеши, IP, домены, пути)
9. Проверить оставшуюся инфраструктуру на наличие IOC
10. Устранить persistence-механизмы на всех скомпрометированных хостах
11. Сбросить пароли скомпрометированных и сервисных аккаунтов
12. Закрыть вектор входа (патч, изменение конфигурации)
13. Восстановить системы из верифицированных бэкапов
14. Развернуть усиленный мониторинг на 30 дней
15. Подготовить отчёт для бизнеса и техкоманды
16. Провести Lessons Learned и обновить IR Playbook

Хотите отработать полный цикл расследования инцидента в легальной среде - от алерта до отчёта? Курсы Codeby Academy по направлению DFIR дают практику на реальных кейсах с полным стеком инструментов.



Большинство IR-команд, с которыми приходится работать, совершают одну и ту же системную ошибку - они строят процесс реагирования вокруг инструментов, а не вокруг артефактов. Покупают Splunk, разворачивают Elastic, ставят EDR на каждый эндпоинт, а потом при реальном инциденте не знают, какой Event ID искать и почему prefetch-файл ценнее десяти SIEM-алертов. Инструмент без понимания, что он должен показать, - это дорогой шум.

За последние годы индустрия сделала серьёзный рывок в обнаружении: медиана dwell time упала до 11 дней, EDR стали ловить то, что пять лет назад пролетало мимо. Но восстановление и post-incident analysis остаются слабым звеном. Компании тратят недели на расследование, составляют отчёт с двадцатью рекомендациями, а через квартал половина из них остаётся невыполненной. Следующий инцидент приходит ровно через ту же дверь.

Incident response - это не проект с началом и концом. Это операционная функция, которая должна работать как мышечная память: алерт - triage - изоляция - артефакты - анализ - отчёт - коррекция. Если хотя бы одно звено этой цепочки отсутствует или зависит от конкретного человека, который «знает, как» - у вас нет процесса, а есть набор героических импровизаций. Героизм не масштабируется. Процесс - масштабируется.