“Первые 60 минут после взлома, это не время для паники, а время для выполнения чёткого алгоритма. Это не о том, чтобы всё исправить, а о том, чтобы не дать злоумышленнику сделать хуже. Каждое действие здесь, это попытка отрезать его от ресурсов, сохранить улики и начать контролировать ситуацию, которая уже вышла из-под контроля.”

Что делать в первые 60 минут после обнаружения взлома?

Обнаружение взлома в инфраструктуре, это момент, когда время начинает течь иначе. Первый час критичен. Это не период для глубокого анализа причин, а время для действий, которые изолируют угрозу, сохраняют доказательства и позволяют впоследствии восстановить работу с минимальными потерями. План на первые 60 минут должен быть отрепетирован заранее.

Шаг 0: Подготовка до инцидента

Реагирование начинается не в момент обнаружения, а задолго до него. Если у вас нет плана, первые 60 минут превратятся в хаос.

• Имейте контакты для экстренной связи: номера телефонов, мессенджеры ключевых сотрудников (руководитель ИБ, системные администраторы, юрист, PR). Список должен быть доступен в автономном режиме.
• Определите круг лиц, принимающих решения: кто имеет право отключать серверы, блокировать пользователей, информировать руководство и регуляторов? Это должно быть документально зафиксировано.
• Создайте «чемоданчик» с инструментами: подготовьте образы чистых систем, резервные копии конфигураций, дистрибутивы средств защиты. Храните их на изолированном носителе или в сегменте сети, не связанном с основными сервисами.
• Проведите учения: смоделируйте простой инцидент и отработайте коммуникацию и первые действия команды.

Первые 10 минут: Оценка и изоляция

Цель: подтвердить инцидент и не дать угрозе распространиться.

1. Фиксация факта. Не пытайтесь сразу чистить систему. Соберите первоначальные данные: откуда поступил сигнал (СОИБ, пользователь, внешняя организация)? Каковы наблюдаемые признаки (подозрительные процессы, неавторизованные доступы, изменённые файлы)? Зафиксируйте время обнаружения и первые артефакты. Запись в лог-файл или даже скриншот могут стать доказательствами.
2. Изоляция поражённого узла. Самый эффективный способ остановить атаку — физически или логически отключить компрометированную систему от сети. Если это критичный сервер, который нельзя просто выдернуть из розетки, изолируйте его на сетевом уровне:
   • Блокировка на межсетевом экране (все входящие/исходящие соединения).
   • Отключение порта на коммутаторе.
   • Изменение правил маршрутизации.
   • Важно: если злоумышленник уже получил доступ к сетевым устройствам, простой блокировки может быть недостаточно. Нужно быть готовым к отключению целого сегмента.
3. Смена учётных данных. Немедленно смените пароли для учётных записей, которые могли быть скомпрометированы. Начните с привилегированных учётных записей (доменных администраторов, root, учётных записей сервисов). Используйте заранее подготовленные сложные пароли. Если используется единая точка входа (SSO), временно заблокируйте её и инициируйте сброс паролей для ключевых групп.

   Следующие 20 минут: Сохранение доказательств и оповещение

Цель: сохранить «цифровые отпечатки» для расследования и запустить процесс реагирования.

1. Сбор артефактов. Перед любыми попытками «почистить» систему необходимо создать её слепок для последующего forensic-анализа.
   • Дамп памяти (RAM) работающей системы — в нём могут остаться пароли, ключи шифрования и следы вредоносного кода, которого нет на диске. Используйте инструменты вроде WinPMEM для Windows или LiME для Linux.
   • Создание образа диска. Сделайте полную побайтовую копию (bit-by-bit image) диска скомпрометированной системы на внешний носитель. Для этого подойдут FTK Imager, dd в Linux. Важно использовать аппаратный write-blocker, чтобы не изменить оригинальные данные.
   • Сохранение логов. Экспортируйте логи системных событий, журналы приложений, сетевые flow-данные с соседних устройств (коммутаторов, межсетевых экранов) за релевантный период.
2. Оповещение внутренних сторон. Свяжитесь с определённым ранее кругом лиц:
   • Руководство: кратко сообщите о факте, масштабе и предпринимаемых действиях.
   • Команда реагирования на инциденты (CIRT): если она есть, передайте им управление.
   • Юридический отдел: они оценят риски, связанные с утечкой данных, и необходимость уведомления регуляторов.
   • Отдел по работе с клиентами/PR: подготовьте шаблон ответа на возможные запросы.

Следующие 30 минут: Анализ масштаба и начало восстановления

Цель: понять, насколько глубоко проникла угроза, и начать подготовку к восстановлению работоспособности.

1. Первоначальный анализ. Не углубляясь в детали, попытайтесь ответить на ключевые вопросы:
   • Вектор атаки: как злоумышленник попал внутрь? (Фишинг, уязвимость в веб-приложении, слабый пароль?)
   • Цель атаки: что было целью? (Шифрование данных для выкупа, кража информации, использование ресурсов?)
   • Масштаб компрометации: есть ли признаки перемещения по сети (lateral movement)? Проверьте логи аутентификации на других критичных системах (контроллеры домена, серверы БД, системы управления).
   • Состояние резервных копий: не затронуты ли они? Атаки типа ransomware часто сначала шифруют или удаляют бэкапы.
2. Начало восстановления. На основе собранных данных и анализа примите решение о стратегии восстановления.
   • Если система не критична и есть чистые резервные копии, подготовьтесь к её полной переустановке из проверенного образа.
   • Если система критична и её нужно вернуть в строй быстро, но безопасно, рассмотрите вариант «зачистки»: удаление вредоносных файлов, закрытие уязвимостей, смена всех паролей. Это рискованно, так как следы атаки могли остаться.
   • Ключевой принцип: не восстанавливайте систему из резервной копии, сделанной уже после момента потенциального взлома. Нужно найти «золотую» копию, которая гарантированно чиста.
3. Документирование. Ведите хронологию всех действий: кто, что и когда сделал. Это важно для внутреннего расследования, отчёта перед руководством и, возможно, для правоохранительных органов. Используйте простой текстовый файл или специализированные платформы для управления инцидентами.

   Чего делать категорически нельзя в первый час

• Не стирать логи и не «чистить» систему сразу. Это уничтожит доказательства и помешает понять реальный масштаб.
• Не вступать в переговоры с хакерами самостоятельно. Это задача руководства и, возможно, специальных служб.
• Не пытаться сразу вернуть всё в рабочее состояние, пожертвовав анализом. Это может привести к повторному заражению.
• Не игнорировать необходимость уведомления. В зависимости от типа данных и отраслевого регулирования (152-ФЗ, ФСТЭК) промедление с уведомлением может повлечь серьёзные штрафы.

После первых 60 минут

Первые 60 минут заканчиваются, но работа только начинается. Дальнейшие этапы включают:

• Глубокий forensic-анализ собранных образов.
• Полное восстановление систем из проверенных резервных копий.
• Патчинг уязвимостей, которые использовались для взлома.
• Обновление политик и правил безопасности.
• Составление итогового отчёта об инциденте и проведение «разбора полётов».

Главный вывод: эффективность действий в первый час напрямую зависит от подготовки, проведённой в спокойное время. Регламент реагирования на инциденты ИБ, это не бюрократическая бумажка, а инструкция по выживанию в момент кризиса.