«Посмотреть алерт» и «расследовать инцидент» — не одно и то же, даже если начинаются с одного и того же экрана EDR. Просмотр алерта отвечает на вопрос, стоит ли эскалировать конкретное срабатывание. DFIR (digital forensics and incident response) отвечает на гораздо более широкий набор вопросов: как атака началась, что именно сделал атакующий, какие системы и данные затронуты, что нужно сделать, чтобы прекратить воздействие и не допустить повторения.
Разница особенно заметна там, где ее чаще всего теряют — на стыке этапов. Команда быстро проверяет алерт, убеждается, что он не ложный, изолирует хост и на этом останавливается, считая инцидент закрытым. При этом остаются без ответа вопросы о первоначальном векторе, о том, был ли атакующий на других узлах, и о том, какие данные он успел увидеть или забрать. Именно эти вопросы и закрывает полноценное расследование.
Ниже — пошаговый разбор DFIR: из каких этапов состоит расследование, что и в каком порядке собирать с конечной точки, как связывать события в единый таймлайн, какие ошибки чаще всего портят доказательную базу и что тренировать заранее, чтобы не учиться этому во время реального инцидента. Наступательная сторона атаки здесь не разбирается — весь материал построен вокруг того, что видит и фиксирует защищающаяся сторона.
Что входит в DFIR и чем это отличается от просмотра алерта
DFIR — это полный цикл действий вокруг инцидента: от подготовки инфраструктуры к будущему расследованию до разбора после того, как инцидент закрыт. Просмотр алерта — лишь один шаг внутри одного из этапов этого цикла, и он не решает задач восстановления хода атаки, оценки масштаба и извлечения уроков для процесса.
Ключевое отличие в горизонте вопроса. Аналитик, который смотрит алерт, спрашивает «реален ли этот сигнал». Расследование DFIR спрашивает «что произошло целиком, где еще это могло произойти и что нужно изменить, чтобы это не повторилось». Второй вопрос требует данных с нескольких узлов, таймлайна, а не одного события, и итогового отчета, а не вердикта по одному алерту.
Из каких этапов состоит расследование
Полноценное DFIR-расследование проходит через семь этапов. Пропуск любого из них не останавливает работу совсем, но оставляет пробел, который обнаруживается позже — обычно в худший момент.
Подготовка
Расследование начинается не в момент инцидента, а задолго до него: с того, какая телеметрия вообще собирается, как долго она хранится и кто имеет право доступа к ней в момент кризиса. Если эти вопросы не решены заранее, первые часы расследования уходят не на анализ, а на то, чтобы понять, какие данные вообще существуют.
Обнаружение и триаж
На этом этапе решается, что конкретно происходит и насколько это срочно: какой хост и пользователь затронуты, когда началась активность, есть ли похожие признаки на других узлах. Методика быстрого triage подробно разобрана в статье «Расследование инцидента в EDR» — она применима и здесь: тот же набор вопросов задается в первые минуты любого DFIR-разбора, прежде чем переходить к глубокому анализу.
Сдерживание
Задача этапа — остановить дальнейшее распространение и воздействие, не разрушив при этом данные, которые понадобятся для следующих этапов. Сдерживание — это изоляция затронутого узла от сети, блокировка скомпрометированных учетных записей, ограничение сетевых путей, которыми мог воспользоваться атакующий. Здесь легче всего допустить ошибку, которая обесценивает все дальнейшее расследование, — она разобрана отдельно ниже.
Сбор артефактов
С затронутых систем собираются данные, которые понадобятся для восстановления хода событий: процессы, сетевые соединения, журналы, файлы, метаданные. Порядок сбора имеет значение и разобран в отдельном разделе ниже — часть артефактов исчезает быстрее остальных.
Восстановление хода событий
Из собранных артефактов строится связная картина: как атакующий получил первоначальный доступ, что он делал дальше, какие системы затронул, закреплялся ли он и каким образом. Это этап, где отдельные события превращаются в таймлайн — подробнее в соответствующем разделе ниже.
Устранение и восстановление
После того как картина атаки понятна, можно устранить точку присутствия атакующего полностью: удалить закрепление, сменить скомпрометированные учетные данные, закрыть использованный вектор. Восстановление систем до рабочего состояния проводится только после этого — если процессы поменять местами, есть риск восстановить систему в прежнем уязвимом состоянии.
Разбор после инцидента
Завершающий этап — не формальность, а источник изменений для процесса. Здесь фиксируется, что сработало, что не сработало, какие данные оказалось невозможно получить и какие процессы стоит скорректировать. Находки этого этапа — естественный источник гипотез для проактивного поиска: то, что было обнаружено постфактум в одном расследовании, стоит проверить во всей инфраструктуре, не дожидаясь повторения. Подход к такой проверке описан в статье «Threat hunting: с чего начать».
Что собирать с конечной точки и в каком порядке
Ключевой принцип сбора артефактов — «сначала то, что исчезнет первым». Часть данных живет только в оперативной памяти и пропадает при перезагрузке узла, часть — в журналах с ограниченным сроком хранения, часть — на диске и относительно устойчива. Если собирать данные в произвольном порядке, есть риск потерять самое ценное первым же неосторожным действием.
Практический порядок сбора:
- Состояние оперативной памяти и активные сетевые соединения. Это исчезает первым при перезагрузке или выключении узла и часто содержит то, чего уже нет ни в одном журнале.
- Список запущенных процессов и их связи «родитель — потомок». Устойчивее памяти в моменте, но переписывается по мере работы системы.
- Журналы событий узла и телеметрия EDR за нужный период. Живут дольше, но ограничены сроком хранения и ротацией.
- Артефакты закрепления — автозапуск, запланированные задачи, службы, изменения в конфигурации — устойчивы, если атакующий их не удалил при уходе.
- Файловая система и метаданные файлов — временные метки создания, изменения, доступа, которые помогают восстановить, что происходило и в какой последовательности.
- Журналы за пределами узла — сетевого оборудования, почтового шлюза, DNS — самые устойчивые данные, потому что физически лежат вне контроля атакующего на конечной точке.
Порядок важен не только из-за исчезновения данных, но и потому, что каждое действие по сбору само по себе меняет состояние системы. Правило простое: чем более хрупкие данные, тем раньше их нужно зафиксировать и тем осторожнее должно быть последующее вмешательство.
Как строить таймлайн и связывать события из разных источников
Таймлайн — это не хронологический список всех событий подряд, а причинно-следственная цепочка: что привело к чему. Отдельное событие почти никогда не отвечает на вопрос «что произошло» — ответ появляется, когда несколько событий из разных источников выстраиваются в одну последовательность.
Практический способ построения — идти от точки подтверждения в обе стороны по времени. Если известно, что в конкретный момент произошло подозрительное действие, следующий шаг — посмотреть, что предшествовало ему на том же узле: родительский процесс, сетевое соединение, открытие файла или письма. Затем — что произошло после: созданные файлы, новые сетевые соединения, попытки закрепления или перемещения на другие узлы.
Связывание источников — отдельная задача. Телеметрия конечной точки, журнал почтового шлюза и журнал DNS-запросов ведутся разными системами и не совпадают по формату, но описывают один и тот же путь атаки. Общими точками для связывания обычно служат время события, имя хоста или пользователя, домен или IP-адрес, хеш файла. Если DNS-журнал показывает обращение к подозрительному домену в момент, совпадающий с активностью процесса на конечной точке, это не совпадение, а один и тот же эпизод, увиденный с двух сторон.
Итоговый таймлайн должен быть читаем без пояснений автора: любой участник расследования, открыв его позже, должен понимать, что произошло, в каком порядке и на основании каких артефактов сделан каждый вывод.
Типовые ошибки расследования
- Перезагрузили зараженный узел до сбора данных из памяти. Самая частая и самая дорогая ошибка: то, что было в оперативной памяти, исчезает безвозвратно, и часть картины атаки восстановить уже нельзя.
- Начали зачистку до понимания вектора. Удаление вредоносных файлов и сброс учетных записей до того, как понятен способ первоначального доступа, оставляет открытым тот же путь для повторного проникновения — атакующий вернется тем же способом.
- Стерли следы попыткой «навести порядок». Переустановка системы, удаление логов ради экономии места, ручные правки конфигурации до завершения сбора артефактов — каждое такое действие уменьшает объем данных, на основании которых можно сделать вывод.
- Не зафиксировали цепочку хранения доказательств. Если не документировать, кто, когда и каким образом собрал каждый артефакт, итоговые выводы расследования сложно защитить перед руководством, регулятором или в рамках последующего разбирательства — не потому, что выводы неверны, а потому что их нельзя подтвердить.
- Смешали сдерживание с расследованием. Изоляция хоста — правильное действие, но если она проведена без предварительной фиксации состояния системы, часть данных для расследования теряется вместе с самим действием по сдерживанию.
- Закрыли инцидент сразу после первого подтвержденного хоста. Не проверили, есть ли признаки той же активности на других узлах, — и через некоторое время получили «повторный» инцидент, который на самом деле был тем же самым, просто не долечен до конца.
Какие вопросы обязан закрывать отчет
Отчет по итогам DFIR-расследования — не хронология действий аналитика, а документ, который отвечает на конкретный набор вопросов вне зависимости от того, кто и в каком порядке проводил анализ:
- Как атакующий получил первоначальный доступ?
- Какие системы, учетные записи и данные затронуты?
- Какова хронология событий от первоначального доступа до обнаружения?
- Закрепился ли атакующий, и если да — каким способом устранено закрепление?
- Перемещался ли атакующий на другие узлы, и если да — какие?
- Что сделано для сдерживания и устранения, и подтверждено ли, что воздействие прекращено?
- Какие пробелы в данных или процессе обнаружены и что нужно изменить, чтобы не повторить их в следующий раз?
Если отчет не закрывает хотя бы один из этих вопросов, расследование формально завершено, но фактически оставляет открытый риск — либо неустраненный вектор, либо непонятый масштаб.
Что тренировать на стендах
DFIR — это навык, который плохо формируется только чтением документации: разбор реального инцидента требует практики работы с телеметрией под давлением времени и неполноты данных. На стенде стоит отрабатывать именно те действия, которые в реальном инциденте нельзя переиграть: правильный порядок сбора артефактов, построение таймлайна из нескольких источников и написание отчета, который закрывает все обязательные вопросы, а не только очевидные.
Отдельно стоит тренировать различение этапов сдерживания и сбора артефактов — это ошибка, которая на реальном инциденте необратима, а на стенде исправляется без последствий и позволяет один раз прочувствовать, почему порядок действий важен больше, чем скорость.
Практика на стендах BI.ZONE Cybersecurity Labs
Курс «Проектирование и внедрение BI.ZONE EDR» дает практику работы с телеметрией, на основе которой строится реальное расследование: развертывание продукта в распределенной конфигурации, интеграции с инфраструктурой и работа с данными, которые становятся основой любого DFIR-разбора. Это тот же материал, на котором строится чтение телеметрии в статье «Расследование инцидента в EDR», только с фокусом на архитектуру и полноту покрытия, а не на разбор одного алерта.
Если ваша команда пока чаще реагирует на готовые алерты, чем формулирует расследование целиком, вернитесь к материалу «Threat hunting: с чего начать» — многие вопросы, которые обязан закрывать отчет DFIR, совпадают с теми, что задает себе аналитик при проактивном поиске, просто в другом порядке.