Первые часы после кибератаки определяют, удастся ли восстановить последовательность событий и подтвердить технические факты. Разбираем, какие данные сохранить до очистки серверов, переустановки систем и восстановления из резервной копии.
Почему первые 24 часа критичны
После обнаружения инцидента команда стремится как можно быстрее вернуть сервис в работу. Это естественная цель, но поспешные действия способны уничтожить цифровые следы. Перезагрузка меняет оперативную память и системные журналы, переустановка удаляет файлы, а восстановление резервной копии перезаписывает состояние диска.
Ситуацию усложняет автоматическая ротация логов. Веб-сервер, межсетевой экран, облачная платформа и корпоративное приложение могут хранить записи разное время. При высокой нагрузке важный период исчезает за часы. Поэтому реагирование должно сочетать ограничение атаки, сохранение доказательств и документирование действий.
Сначала определите границы инцидента
Зафиксируйте, кто и когда обнаружил событие, какие признаки наблюдались и какие системы могли быть затронуты. Отделите подтверждённые факты от предположений. Например, необычный вход в почту является фактом, а вывод о похищении базы требует дополнительной проверки.
Составьте первоначальный перечень активов:
- серверы, рабочие станции и мобильные устройства;
- облачные кабинеты, виртуальные машины и хранилища;
- почтовые системы, VPN, CRM, 1С и личные кабинеты;
- сетевое оборудование, межсетевые экраны и средства защиты;
- учётные записи администраторов, сотрудников и подрядчиков;
- домены, сайты, API и внешние интеграции.
Не ограничивайте проверку первым компьютером, на котором проявилась проблема. Он может быть только одной точкой более длинной цепочки.
Разделите сохранение данных и восстановление работы
У расследования и эксплуатации разные приоритеты. Системному администратору нужно восстановить сервис, специалисту по безопасности - остановить распространение, руководителю - оценить ущерб, а эксперту - сохранить проверяемые источники. Если действия не согласованы, одна команда может уничтожить данные, необходимые другой.
Создайте два параллельных плана. Первый описывает локализацию и восстановление: изоляцию сегмента, переключение на резервный ресурс, блокировку доступа и проверку работоспособности. Второй определяет, что копируется до изменений, кто это делает и где хранятся оригиналы. В журнале отмечайте точное время каждого действия.
Какие данные имеют наивысший приоритет
Начинайте с источников, которые исчезают быстрее всего. К ним относятся оперативная память, текущие сетевые соединения, активные процессы, временные файлы и короткие журналы с автоматической ротацией. Затем сохраняют системные и прикладные логи, снимки виртуальных машин, конфигурации и данные облачного аудита.
Большой объём не всегда означает высокую ценность. Полная копия архива за несколько лет может быть менее полезной, чем небольшой журнал выдачи административных прав за день до инцидента. Приоритет определяют по связи источника с предполагаемой точкой входа, затронутыми данными и временным периодом атаки.
Какие журналы событий сохранить
Логи часто становятся главным источником хронологии. Скопируйте их до ротации и сохраните сведения о системе, из которой они получены. Для каждого файла укажите период, часовой пояс, способ выгрузки и ответственное лицо.
В зависимости от инфраструктуры могут понадобиться:
- журналы операционной системы и служб авторизации;
- логи веб-сервера, приложения, базы данных и API;
- события антивируса, EDR, SIEM и межсетевого экрана;
- история VPN, удалённого рабочего стола и административных подключений;
- аудит облачной платформы и панели управления хостингом;
- почтовые заголовки, журналы доставки и правила переадресации;
- DNS-запросы, прокси-логи и сведения сетевого оборудования;
- журналы изменений прав, ролей и конфигурации.
Полезно сохранить не только события с ошибками. Успешный вход, создание токена, изменение правила или выгрузка архива могут быть важнее явного предупреждения.
Сетевой трафик и соединения
Если организация собирает NetFlow, журналы межсетевого экрана, прокси или полные дампы трафика, зафиксируйте данные за период до обнаружения и после него. Они помогают установить внешние адреса, направления соединений, объём переданных данных и последовательность контактов.
Сам по себе IP-адрес не всегда устанавливает конкретного человека. Он может относиться к VPN, облачному сервису, NAT или скомпрометированному узлу. Вывод строится на сопоставлении сетевых данных с учётными записями, устройствами, временем и другими источниками.
Образы дисков и оперативная память
При серьёзном инциденте логического копирования отдельных файлов может быть недостаточно. Побитовый образ носителя сохраняет файловую систему, удалённые записи и служебные области. Снимок оперативной памяти может содержать сведения о запущенных процессах, сетевых соединениях и фрагментах данных, которые исчезнут после выключения.
Сбор выполняют подготовленными средствами и документируют. Если сотрудники не обладают нужной квалификацией, лучше не запускать на исследуемой системе случайные утилиты: каждая установка и команда меняет её состояние.
Облачная среда и резервные копии
Облачный сервис требует отдельной фиксации. Сохраните аудит входов, действия администраторов, создание ключей и токенов, изменения политик, снимки виртуальных машин, журналы объектного хранилища и историю резервного копирования.
Не считайте резервную копию заведомо безопасной. Она может быть создана после проникновения и содержать изменённые файлы или вредоносный компонент. Нужны дата создания, политика хранения, контроль целостности и сведения о том, кто имел доступ к копиям. Подробнее об этом рассказано в материале об экспертизе облачного хранилища и резервной копии.
Учётные записи и действия пользователей
Сохраните список активных пользователей, роли, группы, сервисные аккаунты, ключи доступа и недавние изменения прав. Зафиксируйте подозрительные входы, новые устройства, сброс паролей, выпуск токенов и отключение многофакторной аутентификации.
После фиксации скомпрометированные доступы необходимо ограничить. Но сначала запишите прежнее состояние: какие права существовали, когда они были выданы и какие действия совершались. Иначе расследование увидит только итоговую конфигурацию после очистки.
Переписка и решения команды реагирования
Сохраните служебные сообщения, заявки поддержки и уведомления мониторинга, связанные с обнаружением и устранением инцидента. Они помогают установить, когда организация узнала о проблеме, какие признаки наблюдали сотрудники и почему были приняты конкретные меры.
Не обсуждайте чувствительные детали в открытых каналах, доступ к которым мог получить нарушитель. Для координации используйте заранее определённый защищённый способ связи. В итоговую хронологию включайте факты и ссылки на первичные данные, а не только пересказ участников.
Как построить единую временную шкалу
Разные системы могут использовать местное время, UTC или неверно настроенные часы. Перед объединением событий определите часовой пояс и расхождение каждого источника. Сохраните сведения о синхронизации времени и настройках NTP.
В таблице хронологии указывают время, источник, идентификатор события, учётную запись, устройство, действие и ссылку на исходный файл. Не изменяйте оригинальные логи ради удобства. Нормализованную таблицу создавайте как отдельный рабочий материал.
Контроль целостности и цепочка хранения
Для каждого файла и образа рассчитайте криптографическую хеш-сумму. В описи укажите имя, размер, источник, дату получения, способ копирования, контрольную сумму и ответственного сотрудника. Исходники храните отдельно от рабочих копий с ограничением доступа.
Если материал передаётся между сотрудниками, подрядчиком, специалистом и экспертом, фиксируйте каждую передачу. Такая цепочка помогает объяснить происхождение данных и подтвердить, что исследовалась неизменённая копия.
Уведомления и правовые обязанности
Компьютерный инцидент может затронуть персональные данные, объекты критической информационной инфраструктуры, банковские операции или договорные обязательства перед клиентами. Сроки и адресаты уведомлений зависят от статуса организации, характера системы и последствий события.
Техническая команда должна своевременно передать руководству и юристу проверенные сведения: момент обнаружения, затронутые ресурсы, предполагаемый период, категории данных и принятые меры. Не откладывайте техническую фиксацию до завершения юридической оценки. При этом не публикуйте неподтверждённые версии и персональные данные в открытом доступе.
Как проверить резерв перед восстановлением
До развёртывания копии уточните дату её создания, источник, полноту и контрольную сумму. Проверьте, не относится ли она к периоду после предполагаемого проникновения. Восстановление лучше выполнять в изолированной среде, где можно исследовать файлы и конфигурацию без риска повторного запуска вредоносного компонента.
Зафиксируйте, какая именно копия использована, кто разрешил восстановление, какие системы были заменены и какие изменения внесены после запуска. Это позволит отличить следы исходного инцидента от событий, появившихся во время аварийных работ.
Чего не следует делать
- не удаляйте подозрительные файлы до создания копии и фиксации их свойств;
- не переустанавливайте систему как первое действие;
- не очищайте журналы и историю входов;
- не изменяйте массово пароли до сохранения состояния учётных записей;
- не пересылайте единственную копию через сервис, который меняет файл;
- не открывайте подозрительный документ на обычном рабочем компьютере;
- не публикуйте индикаторы, содержащие персональные данные или секреты;
- не делайте вывод об источнике атаки только по одному IP-адресу.
Что передать эксперту
Подготовьте краткое описание инцидента, схему инфраструктуры, перечень затронутых систем, хронологию действий и опись сохранённых материалов. Укажите, какие изменения уже были внесены после обнаружения: изоляция узла, блокировка аккаунта, восстановление копии или обновление программного обеспечения.
Вопросы эксперту должны быть технически проверяемыми. Например: имеются ли признаки несанкционированного доступа, какова последовательность событий, с каких учётных записей выполнялись действия, содержат ли материалы признаки удаления или изменения, возможна ли связь между обнаруженными событиями.
Эксперт не определяет виновность и не даёт правовую квалификацию. Он исследует цифровые данные и формулирует выводы в пределах специальных знаний.
Практический чек-лист первых суток
- Назначьте ответственного за фиксацию и журнал действий.
- Запишите время обнаружения и первые наблюдаемые признаки.
- Определите потенциально затронутые системы и аккаунты.
- Сохраните журналы до их автоматической ротации.
- Зафиксируйте сетевые соединения и данные средств защиты.
- Создайте образы критичных носителей и снимки облачных ресурсов.
- Рассчитайте хеш-суммы и составьте опись.
- После фиксации ограничьте скомпрометированные доступы.
- Храните оригиналы отдельно, анализируйте рабочие копии.
- Согласуйте необходимость уведомлений с ответственными специалистами и юристом.
Один универсальный сценарий подходит не для каждого инцидента. При активном распространении вредоносной программы изоляция может быть важнее полного сбора данных с одного узла. Решения нужно принимать с учётом масштаба угрозы, непрерывности бизнеса и требований законодательства.
Нужно сохранить и исследовать цифровые следы?
Проведём предварительную оценку, определим перечень источников и поможем организовать технически корректное исследование.