UDV Group: план реагирования на киберинцидент должен быть коротким

Эксперт UDV Group рассказал, как компаниям выстроить минимально жизнеспособный план реагирования на киберинциденты и избежать хаоса в первые часы после обнаружения атаки.

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

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

«Главное правило: план на три страницы, а не на тридцать. В нем должно остаться только то, что спасает, когда все “горит”. Кто и когда принимает решение об отключении, какие ключевые узлы нужны для сдерживания, какие резервные каналы связи есть у команды, что делает инженер первой линии и кто отвечает за информирование регулятора. Если в компании нет человека или четко обозначенной роли, которая в режиме “здесь и сейчас” может отключить зараженный сегмент, сервер или сеть без бесконечных согласований, наличие даже самого сильного SOC, SIEM или EDR становится бесполезным», - комментирует Иван Бурмистров, пресейл-инженер UDV Group.

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

При этом трафик с хоста-жертвы следует запретить во все направления, оставив связь только с системами наблюдения, например SIEM и NTA. Такой подход дает специалистам возможность видеть события и сетевую активность, но не позволяет злоумышленнику использовать узел для дальнейшего продвижения по сети.

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

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

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

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

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

Для Windows необходимо проверять задачи в планировщике, службы, WMI-подписки, ключи автозагрузки Run и RunOnce, папку Startup и подозрительные исполняемые файлы в пользовательских каталогах. Для Linux, включая Astra Linux, РЕД ОС и Альт СП, важно проверять добавленные SSH-ключи, cron-задачи, юниты systemd и измененные скрипты автозагрузки. Если удалить только вредоносный файл, но оставить бэкдор, атака может повториться.

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

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

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

Еще одна ошибка - запуск исполняемых файлов, библиотек, драйверов или обновлений без проверки в изолированной среде. Даже если файл находится во внутреннем репозитории, он мог быть подменен злоумышленником. Также нельзя возвращать сервисы в онлайн до смены привилегированных паролей в Active Directory, на сетевом оборудовании, гипервизорах и системах резервного копирования.

«Возврат систем в онлайн нельзя воспринимать как простое восстановление из бэкапа. Сначала нужно убедиться, что резервная копия сделана до проникновения, затем проверить хосты EDR и антивирусом, посмотреть сетевой трафик за последние 72 часа после восстановления и вручную проверить ключевые серверы на скрытые механизмы автозапуска. Особенно важно сменить пароли в Active Directory и на сетевом оборудовании до включения сервисов. Если этого не сделать, злоумышленник может вернуться через оставленные учетные данные или бэкдоры», - подчеркивает Иван Бурмистров.

Минимальная проверка после восстановления должна включать полное сканирование хостов с расширенным поиском угроз, анализ сетевого трафика через NTA, межсетевой экран или IDS/IPS, а также ручную проверку критичных серверов. Особое внимание нужно уделять нехарактерным исходящим подключениям, каналам связи с командными серверами и скрытым туннелям, например внутри ICMP-пакетов. Для проверки автозагрузки на Windows-серверах можно использовать доступные инструменты вроде Autoruns из состава Sysinternals.

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

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

В UDV Group подчеркивают, что качество плана реагирования проверяется не количеством страниц, а применимостью в момент атаки. Дежурный инженер должен понимать, какой порт отключить, руководитель ИБ - кому звонить, юрист - какие факты уже подтверждены, а команда восстановления - из какой точки можно безопасно возвращать системы в работу. Такой подход не отменяет сам инцидент, но помогает компании управлять им и снижать ущерб.