Средства мониторинга инцидентов, включая SIEM, незаменимы при обнаружении атак, но без выстроенного реагирования — бесполезны. Рассмотрим, как составлять сценарии последующих действий и почему не стоит прибегать к тотальной автоматизации.
Формальный регламент реагирования нужен, но сам по себе он не обеспечивает управляемую и быструю реакцию на инциденты. В реальной инфраструктуре реагирование опирается на набор сценариев — описанных и протестированных цепочек действий под конкретные типы атак и источники детектов.
Сценарий — это «живой» документ: его приходится пересматривать после учений, кибериспытаний, реальных инцидентов, изменений в ИТ-ландшафте и модели угроз. Набор сценариев и их глубина зависят от поверхности атаки, зрелости средств мониторинга (SIEM, EDR, NDR, почтовые шлюзы, облачные сервисы) и технических возможностей по принудительному воздействию на инфраструктуру.
Хороший сценарий опирается на три фактора: какое событие его запускает, какими контролируемыми точками инфраструктуры можно воспользоваться и до какого уровня допустимо воздействовать на сервисы, не поднимая эскалацию. Уже после этого имеет смысл решать, какие части сценария автоматизировать в SOAR, а какие оставить на ручном контроле.
С чего начинать автоматизацию: точки входа
Опыт кибериспытаний и реальных атак показывает: максимальный эффект реагирования достигается в первые минуты, пока злоумышленник закрепляется в инфраструктуре и наращивает привилегии. Поэтому в приоритете автоматизации должны быть сценарии вокруг точек входа — внешнего периметра и конечных устройств.
Для большинства компаний типовые точки входа — внешние веб-сервисы и VPN-шлюзы, почта, пользовательские рабочие станции и ноутбуки. Логика приоритизации проста: чем ближе контрольная точка к первому шагу цепочки атаки, тем больше ценность ее быстрой, желательно автоматизированной активации.
Базовые меры на внешнем периметре
Для периметра в сценариях и SOAR-интеграциях должны быть реализованы как минимум следующие действия:
- Блокировка входящих соединений по IP или подсети на межсетевом экране или WAF (временные блоки, динамические списки репутаций, интеграция с TI-фидами).
- Принудительный разрыв клиентских сессий на уровне приложения или reverse-proxy (отключение конкретного токена или cookie, сброс websocket/HTTP-сессий).
Эти операции хорошо подходят для автоматизации: они обратимы, локальны и не затрагивают бизнес-логику приложения. Важно, чтобы их можно было выполнять точечно по конкретному индикатору компрометации (например, отдельному IP-адресу, цифровому отпечатку устройства или сессии), а не по целому пулу клиентов.
Базовые меры для рабочих станций и серверов
Для конечных точек и серверов приоритетны следующие действия:
- Блокировка запуска файлов по хэшу через EDR/antimalware-движок.
- Остановка процесса по PID/имени с фиксацией артефактов для детального технического расследования инцидента по цифровым следам (форензики).
- Изоляция хоста от сети на уровне ОС (host-based firewall, отключение сетевых интерфейсов, ограничение маршрутов).
- Изоляция хоста на уровне сетевого оборудования (динамическое помещение в карантинный VLAN, применение ACL на порт).
- Блокировка доступа в интернет по IP и URL (web-proxy, NGFW, DNS-фильтрация) для отсечения C2 и фишинговых ресурсов.
Пока на рабочей станции или сервере корректно работает агент защиты и он способен выполнять команды, изоляцию можно реализовать на уровне самой операционной системы — например, с помощью локального файрвола.
Если же есть признаки, что агент отключен, скомпрометирован или ему нельзя доверять, изоляцию необходимо выполнять на уровне сети: переводить устройство в карантинный VLAN, ограничивать трафик на коммутаторе или межсетевом экране.
При этом для массовых инцидентов, особенно на пользовательских ПК, обычно используются два режима изоляции. «Мягкий карантин» ограничивает доступ к внешним ресурсам, а «жесткий карантин» практически полностью изолирует хост от сети, сохраняя только минимальный доступ для специалистов SOC, необходимый для сбора артефактов и проведения расследования.
Учётные записи и инфраструктурные сервисы
Учетка — еще одна классическая точка входа, особенно в сценариях фишинга, подбора паролей, компрометации SaaS. Набор обязательных операций для сценариев и SOAR-интеграций:
- Блокировка учетной записи и принудительный сброс пароля в AD/IdP.
- Блокировка приема писем с определенных доменов и отправителей на почтовом шлюзе.
- Удаление уже доставленных писем из ящиков пользователей (EWS/Graph API, административные инструменты почтового сервиса).
- Принудительный разрыв сессии пользователя на VPN-шлюзе.
- Принудительная деаутентификация пользователя из внешних облачных сервисов (OIDC/SAML, revoke tokens, logout sessions).
С точки зрения риска все эти действия нужно заранее классифицировать: где допускается полная автоматизация по одному сигналу, а где обязательно участие человека (ручное подтверждение ключевых шагов). Например, если система фиксирует подозрительный вход в аккаунт (необычная страна или IP-адрес с плохой репутацией), она может автоматически завершить сессию пользователя без участия аналитика. Блокировку учетной записи доменного администратора лучше проводить только по заранее настроенной процедуре с ручным подтверждением в SOAR
Как собирать сценарии в единое полотно
Перечень элементарных действий сам по себе не дает управляемости — нужна связка в логические сценарии с учетом источников детектов и типа атаки. Например, фишинг, массовое вредоносное ПО на рабочих станциях, подозрительные логины, атаки на внешние веб-сервисы.
Сценарий должен описывать: стартовое событие (какой сигнал его запускает в SIEM/EDR/почтовом шлюзе), шаги по обогащению данных (какой дополнительный контекст подтягиваем), последовательность сдерживающих действий, точки принятия решений человеком и условия завершения. Важно замыкать сценарии на пост-инцидентные активности: техническое расследование инцидента, улучшение правил обнаружения, корректировку сценариев реагирования и обучение пользователей.
За период кибериспытаний мы убедились на практике, что когда не получается «сломать» технику, первоочередной целью становятся люди. Поэтому разберем пример атаки с использованием социальной инженерии.
Злоумышленник запускает рассылку, ее цель — заставить пользователя перейти по ссылке, ввести доменные учетные данные, затем скачать и запустить обфусцированный вредонос. После запуска файл устанавливает реверс-соединение на C&C. При корректной настройке мониторинга (почтовый шлюз, web-proxy, EDR, TI-фиды) детекты появляются на нескольких этапах. Логичный сценарий реагирования может выглядеть так:
- Заблокировать прием писем с домена отправителя на почтовом шлюзе.
- Добавить фишинговый URL в блок-лист web-proxy/DNS-фильтрации.
- Для пользователей, уже перешедших по ссылке, инициировать принудительный сброс пароля и пересоздание сессий в критичных системах.
- Добавить хэш загруженного файла в блок-лист EDR/antimalware по всей инфраструктуре.
- Для тех, кто успел запустить файл, остановить процесс и изолировать хост.
- URL или IP C&C внести в черный список на межсетевом экране/proxy/DNS.
Дальше начинается детальное расследование: анализ логов аутентификации, поиск горизонтального перемещения злоумышленника по сети, проверка фактов утечки данных, очистка и восстановление хостов. Ключевой смысл сценария — успеть автоматически или полуавтоматически выполнить все шаги по локализации и сдерживанию атаки для большого количества хостов и учетных записей, пока она не вышла за пределы изначального сегмента.
Роль SOAR: оркестрация против хаоса
Часто современная ИБ-инфраструктура представляет собой набор разрозненных систем: SIEM, EDR/XDR, NGFW, WAF, почтовые шлюзы, CASB, облачные консоли, тикет-системы. Координировать ручное выполнение десятков действий в правильном порядке, да ещё в сжатые сроки, сложно даже для сплоченной команды.
SOAR решает эту проблему за счет оркестрации и частичной автоматизации: из единого интерфейса аналитик запускает сценарий реагирования, который сам обращается к нужным интеграциям по API, собирает контекст, предлагает следующий шаг и фиксирует все действия. Это снижает вероятность ошибок, исключает неформальные согласования при эскалации задач администраторам и ускоряет реакцию.
Главный вопрос: можно ли сказать, что чем больше автоматизации в SOAR — тем лучше? Исходя из собственного опыта, отвечу — не всегда. Потому что тотальная автоматизация возможна при полном исключении ложноположительных срабатываний системы мониторинга, чего очень сложно добиться.
Поставщики решений любят демонстрировать полностью автоматические сценарии реагирования. В реальности даже хорошие модели и корреляционные правила периодически дают «шум», а бизнес-сервисы чувствительны к радикальным действиям вроде блокировки учеток или изоляции серверов.
Практический компромисс, к которому приходят опытные команды, выглядит так:
- Автоматизировать до конца только простые, хорошо формализуемые сценарии, не трогающие критичные узлы и сервисы (например, блокировка URL, IP, домена-отправителя, добавление хэша в блок-лист, создание тикета).
- Для действий с высоким бизнес-риском следует использовать режим с участием человека: система SOAR собирает контекст, предлагает действие, но требует явного подтверждения аналитика или ответственного специалиста по ИБ.
- Сложные инциденты с несколькими ветками развития вести вручную, но через SOAR-интерфейс, используя его для оркестрации и протоколирования.
Такой подход хорошо защищает от сценариев, когда утренний сбой в критичном сервисе оказывается следствием ночного ложноположительного срабатывания и агрессивного реагирования. При этом SOC получает предсказуемое поведение системы и возможность постепенно расширять зону доверенной автоматизации по мере накопления статистики и обкатки сценариев на киберучениях.
Каждая команда в итоге вырабатывает свой профиль автоматизации: кто-то смелее автоматизирует изоляцию рабочих станций и серверов, но осторожно относится к блокировке учетных записей; кто-то, наоборот, предпочитает быстро разрывать сессии и блокировать учетку, но минимизировать воздействие на инфраструктурные узлы. Важно, чтобы это решение было осознанным, опиралось на реальные кибериспытания и регулярно пересматривалось вместе с моделью угроз и архитектурой ИБ.
