Расследование инцидента информационной безопасности — это последовательная работа по ответу на четыре вопроса: что произошло, как злоумышленник попал в систему, что он успел сделать и как не допустить повторения. Расследование отличается от простого устранения последствий. Перезагрузка зараженного компьютера возвращает рабочее место, но не объясняет, как атака началась и не осталась ли она в других системах.
Статья рассчитана на специалиста по информационной безопасности (ИБ), который впервые ведет расследование, и на руководителя, который выстраивает процесс в команде. Здесь собраны этапы, роли, перечень данных, которые нужно сохранить, и типичные ошибки. В конце описано, как тренировать навык на практике.
Чем расследование отличается от реагирования
| Понятие | Главный вопрос | Результат |
|---|---|---|
| Реагирование | Как остановить атаку прямо сейчас | Угроза локализована, работа восстановлена |
| Расследование | Что произошло и почему | Хронология, причина, масштаб, выводы |
| Цифровая криминалистика (DFIR) | Что можно доказать по следам | Сохраненные и описанные артефакты |
На практике процессы идут параллельно: пока одни изолируют узел, другие собирают данные. Для бизнеса различие важно в одном: без расследования вы вернете системы в работу, но не узнаете, через какую дверь вошел злоумышленник, и он может вернуться тем же путем. Криминалистическую часть подробно описывает статья «DFIR: как расследовать инцидент пошагово».
Этапы расследования
1. Получение сигнала и первичная оценка
Сигнал приходит из системы мониторинга, от пользователя, от внешней организации или из журналов. На этом этапе нужно решить, инцидент это или ложное срабатывание, и присвоить приоритет. Для приоритета достаточно трех вопросов: затронуты ли критичные системы, затронуты ли данные, есть ли признаки продолжающейся атаки. Центры мониторинга принимают сигналы по такой схеме ежедневно, см. статью «Что такое SOC».
2. Локализация
Цель — остановить распространение, не уничтожив следы. Изолируйте узел от сети и оставьте его включенным: в оперативной памяти остаются данные, которые пропадут после перезагрузки. Заблокируйте скомпрометированные учетные записи и сохраните их историю входов.
3. Сбор данных
Соберите данные до того, как они изменятся. Порядок сбора идет от самых недолговечных к самым устойчивым: память и сетевые соединения, процессы, журналы системы, файлы, образ диска. Фиксируйте, кто, когда и с какого узла копировал данные: это пригодится, если материалы потребуются юристам или регулятору.
4. Анализ и построение хронологии
Из собранных фрагментов складывается последовательность событий: первичный доступ, закрепление, перемещение по сети, действия с данными. Хронология должна опираться на метки времени, приведенные к одному часовому поясу, иначе события из разных систем не сложатся.
5. Определение масштаба
Кроме узла, с которого началось расследование, проверьте другие: те же учетные записи, те же индикаторы, те же каналы связи. Цель — получить полный список затронутых систем. Для поиска по большому числу источников помогает система корреляции, принцип ее работы разобран в статье «Что такое SIEM».
6. Устранение и восстановление
Удалите механизмы закрепления, смените пароли и ключи, закройте уязвимость, через которую зашел злоумышленник. Восстановление без устранения причины приводит к повторному заражению.
7. Отчет и выводы
Отчет должен быть понятен двум аудиториям: техническим специалистам и руководству. Руководству нужны хронология, причина, ущерб, принятые меры и рекомендации. Выводы возвращаются в процесс: правила обнаружения, настройки, регламенты.
Какие данные нужно собрать
| Источник | Что ищем |
|---|---|
| Оперативная память | Запущенные процессы, сетевые соединения, внедренный код |
| Журналы операционной системы | Входы, создание процессов, запуск служб |
| Журналы сетевых средств | Необычные обращения вовне, передача больших объемов |
| Журналы почты | Исходное письмо, список получателей, открывшие вложение |
| Данные средств защиты рабочих мест | Цепочка процессов, блокировки, изолированные файлы |
| Журналы учетных записей | Нетипичные входы по времени и месту, смена прав |
| Записи привилегированных сессий | Действия администраторов в критичных системах |
Данные средств защиты рабочих мест особенно ценны: они хранят цепочку запуска процессов и позволяют восстановить ход атаки без полного образа диска. Как это выглядит на примере, показано в статье «Расследование инцидента в EDR». Если злоумышленник действовал под административной учетной записью, пригодятся записи сессий, о них рассказывает материал «Запись привилегированных сессий».
Пример: от входа до закрепления
Ночью система мониторинга фиксирует вход администратора с необычного адреса, а через несколько минут в каталоге появляется новая учетная запись с правами администратора. Аналитик сверяет вход с графиком работы: владелец учетной записи в отпуске. Он блокирует вход и новую учетную запись, затем поднимает историю действий по журналам каталога и записям сессий. Хронология показывает, что вход выполнен через удаленный доступ с украденным паролем, а новая учетная запись создана для закрепления. Инженеры меняют пароли, закрывают доступ из внешней сети без второго фактора и добавляют правило на создание привилегированных учетных записей. Через неделю команда разбирает случай и дополняет регламент.
Как оформить отчет
Отчет читают разные люди, поэтому структура помогает каждому найти свое.
| Раздел | Что в нем | Кому нужен |
|---|---|---|
| Краткое резюме | Что случилось, какой ущерб, что сделано, что осталось | Руководству |
| Хронология | События по времени с источниками | Аналитикам и инженерам |
| Причина | Через какую уязвимость или ошибку началась атака | Всем, кто отвечает за исправление |
| Затронутые системы и данные | Перечень узлов, учетных записей и категорий данных | Юристам и владельцам систем |
| Принятые меры | Что остановлено, исправлено, восстановлено | Руководству и аудиту |
| Рекомендации | Что изменить в настройках, правилах и регламентах, с владельцем и сроком | Командам, которые будут исправлять |
Рекомендация без владельца и срока остается пожеланием. Через месяц проверьте, что исправления внесены, иначе похожий инцидент повторится.
Цепочка хранения
Если расследование может дойти до суда или проверки регулятора, фиксируйте путь каждого артефакта: кто снял, когда, с какого узла, где хранится и кто имел к нему доступ. Копию данных делайте на отдельном носителе, а к оригиналу не прикасайтесь. Для каждого файла считайте контрольную сумму, чтобы позже доказать, что он не менялся. Эти правила пригодятся даже без суда: они дисциплинируют команду и уменьшают число спорных вопросов.
Роли в команде
- Руководитель расследования принимает решения, отвечает за хронологию и общение с руководством.
- Аналитик разбирает данные, формулирует гипотезы и проверяет их.
- Инженер изолирует узлы, меняет настройки, восстанавливает системы.
- Представитель бизнеса подтверждает критичность систем и допустимое время простоя.
- Юрист или специалист по комплаенсу подключается, если затронуты персональные данные или требуется уведомление регулятора.
В небольшой команде роли совмещают, но разделять их по ответственности полезно в любом случае.
Типичные ошибки
- Перезагрузить или переустановить систему до сбора данных.
- Запускать на зараженном узле случайные программы: каждый запуск меняет следы. Для снятия памяти используйте проверенные инструменты с внешнего носителя.
- Вести заметки в разных местах, из-за чего потом не получается собрать хронологию.
- Не написать отчет, потому что «и так всем понятно».
Как получить практику
Расследованию учатся на практике: читать документацию мало, нужно самому пройти путь от тревоги до вывода. Хороший формат — лабораторная работа, в которой задан сценарий, есть набор данных и автоматическая проверка итога. Участник ищет следы, отвечает на вопросы и получает обратную связь без риска для настоящей инфраструктуры. Такой формат используется в лабораторных работах BI.ZONE Education на изолированных стендах:
- Данные с рабочего места. Курс уровня BCE «Внедрение и администрирование BI.ZONE EDR» занимает 36 часов и включает подключение агентов, настройку политик и диагностику: вы знакомитесь с телеметрией, на которой строится расследование. Курс уровня BCS «Работа с BI.ZONE EDR» со сценарными лабораториями для аналитиков SOC занимает 16 часов и готовится к запуску осенью 2026 года.
- Почта и карантин. Курс «Внедрение и администрирование BI.ZONE Mail Security» занимает 40 часов и включает защиту от фишинга, работу с карантином и диагностику.
- Записи сессий. Курс «Установка и администрирование BI.ZONE PAM» занимает 40 часов и включает контроль и запись привилегированных сессий.
Формат практики описан на странице «Практика на киберполигоне», а общий ориентир по направлениям — на странице «Курсы информационной безопасности».
Читайте также
- Кто такой аналитик SOC: обязанности, навыки и как им стать
- Threat hunting: с чего начать и как встроить в работу SOC
- Как вырастить SOC-аналитика: программа от L1 до L2
- Как защитить электронную почту: угрозы, уровни и чек-лист
Частые вопросы
С чего начать расследование?
С фиксации того, что известно: время сигнала, источник, затронутые узлы. Затем нужно изолировать узел и собрать данные, начиная с наименее устойчивых.
Можно ли выключить зараженный компьютер?
Лучше изолировать его от сети и оставить включенным, пока не снят дамп памяти. Выключение стирает данные, которые могут объяснить ход атаки.
Сколько времени занимает расследование?
Зависит от масштаба. Срок зависит от масштаба и числа затронутых систем. Точные сроки заранее назвать нельзя.
Чем отличается расследование в EDR от расследования по журналам?
EDR хранит цепочку процессов и событий на рабочем месте и позволяет быстро получить картину. Журналы дают более широкий контекст по сети и учетным записям. Лучше использовать оба источника.
Нужны ли для расследования специальные сертификаты?
Обязательных сертификатов нет. Работодатели обращают внимание на практический опыт и на подтвержденное владение инструментами.