UDV Group: Золотой час и ловушка восстановления: два момента, где проигрывают инциденты

Инцидент редко проигрывают в момент обнаружения: сигнал уже есть, проблема видна, команда понимает, что происходит что-то нештатное. Гораздо чаще сбой начинается в первый час реагирования и повторяется на этапе восстановления: когда вместо локализации начинают расследование, преждевременно возвращают сервисы в работу или поднимают резервную копию вместе с бэкдором. О том, как CISO выстроить первые действия после сигнала, кто должен говорить с бизнесом и регуляторами и какие проверки нельзя пропускать перед запуском систем, рассказывает Иван Бурмистров, пресейл-инженер UDV Group.

Инцидент проигрывают не в момент обнаружения. Его проигрывают в первый час после сигнала и на этапе возврата систем в строй. Именно в этих двух точках команда чаще всего делает то, что кажется правильным, но в итоге ухудшает последствия.

Начнем с первого часа. Атаку заметили, масштаб еще не ясен, и первая реакция почти у всех одинаковая: разобраться, что произошло. Это ошибка. В первый час расследование может подождать. Сначала нужно остановить распространение, диагноз ставят потом.

На практике это означает три действия.

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

Второе: блокировка учетных записей, попавших под подозрение. Немедленный сброс паролей и завершение сессий для администраторов, сервисных аккаунтов и учетных записей с доступом к резервным копиям лишают злоумышленника возможности двигаться дальше по сети.

Третье: работа по периметру. На NGFW включают геоблокировку, а исходящий трафик в страны, с которыми у компании нет бизнес-связей, закрывают. Если есть EDR, песочница или средства контроля приложений, хосты переводят в режим, где запрещено все, что не разрешено явно. Если EDR нет, через прокси блокируют передачу исполняемых файлов в исходящем трафике.

Параллельно с этим, а не вместо этого, нужно снять дамп оперативной памяти с зараженной машины. Это слепок текущего состояния: какие процессы запущены, какие соединения открыты, какие учетные данные могли оказаться в памяти, какой вредоносный код уже загружен. Именно поэтому машину нельзя просто выключать. Выключение стирает оперативную память вместе с частью улик.

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

Очередность лучше расписать заранее, буквально по часам. В первые 15 минут ситуацию оценивает один человек: руководитель ИБ или ответственный за реагирование. Он же решает, нужна ли дальнейшая эскалация. На этом этапе больше никто никого не оповещает.

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

Ближе к третьему часу параллельно подключаются две группы. Техническая команда отвечает за локализацию, эрадикацию и восстановление. PR готовит два сценария внешних заявлений: либо компания воздерживается от комментариев до уточнения ситуации, либо сообщает только подтвержденный факт с оговоркой, что расследование продолжается и данные уточняются. Технические детали во внешние сообщения не выносятся.

С четвертого часа, если происшествие подтверждено, готовятся уведомления регулятору, если затронуты объекты КИИ или произошла утечка персональных данных. Клиентам и партнерам информация уходит только после юридической проверки формулировок. Преждевременное публичное заявление почти всегда усиливает тревогу, провоцирует слухи и создает дополнительные претензии к компании.

Смысл такой матрицы в том, чтобы заранее зафиксировать роли и границы ответственности. PR не определяет, какая система была скомпрометирована. Генеральный директор не обещает компенсаций без согласования с юристом. Юрист не рассуждает о технических сроках восстановления. Инженеры не общаются с клиентами и регуляторами напрямую, только через PR или юриста. Каждый выход за эти границы в разгаре инцидента обходится дорого.

Вторая точка, где все часто рушится, это восстановление. Кажется, что худшее уже позади, но именно здесь компании совершают ошибки, которые возвращают злоумышленника обратно.

Первая ошибка: восстановление из резервной копии, снятой уже после проникновения. В такой копии бэкдор может быть аккуратно сохранен вместе с остальной системой. Спасает только ротация резервных копий и восстановление из самой ранней заведомо чистой точки.

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

Третья ошибка: включение сервисов до того, как сменены все пароли в Active Directory и на сетевом оборудовании. Если старые учетные данные остались действующими, восстановленная система снова становится доступной для атакующего.

Убедиться, что инфраструктура действительно чистая, помогает минимальный набор проверок. Нужно провести полное сканирование всех хостов с расширенным поиском угроз средствами EDR и антивируса. Затем разобрать сетевой трафик за первые 72 часа после восстановления с помощью NTA, межсетевого экрана и IDS/IPS. Смотреть нужно прежде всего на нехарактерные исходящие соединения, скрытые каналы связи с командными серверами и попытки туннелирования, в том числе внутри ICMP-пакетов.

Отдельно проверяются ключевые серверы: контроллеры домена, серверы резервного копирования и SQL-серверы. На них ищут скрытые механизмы автозапуска, незнакомые или недавно созданные задачи в планировщике, подозрительные службы и другие способы закрепления. Для части такой работы достаточно бесплатных утилит, например Autoruns из состава Sysinternals.

Вывод простой и неудобный. Инцидент не заканчивается в момент, когда система снова выходит в строй. Он заканчивается только тогда, когда команда проверила, что злоумышленнику некуда вернуться. Исход решают два момента: как компания провела первый час после сигнала и что она проверила в последнюю минуту перед возвращением бизнеса в онлайн.