Расширение стека средств защиты информации (СЗИ) на предприятиях, и в особенности внедрение SIEM (Security Information and Event Management) систем, неизбежно ведет к кратному увеличению потока событий, поступающих на обработку аналитикам. Как следствие, рост нагрузки на сотрудников вызывает увеличение показателей MTD (среднее время обнаружения) и MTTR (среднее время реагирования).
Впоследствии организация сталкивается с выбором: либо с ростом числа событий нужно наращивать штат аналитиков, что экономически неэффективно, либо переходить к максимальной автоматизации рутинных процессов. Дополнительно подход с ручной обработкой инцидентов приводит к выгоранию персонала и неизбежным ошибкам из-за человеческого фактора. В условиях постоянного роста количества инцидентов такая задержка в реагировании лишает направление информационной безопасности (ИБ) возможности локализовать атаку на ранних этапах, что, как известно, увеличивает возможный ущерб.
Одним из решений этих проблем выступает класс систем SOAR (Security Orchestration, Automation and Response). В отличие от SIEM, задача которой — сбор и корреляция логов, SOAR фокусируется на реагировании и управлении инцидентами. Система становится центральным узлом — оркестратором, объединяющим разрозненные СЗИ в единый технологический стек.
В этой статье мы подробно изучим возможности системы, разберем ее ключевой функционал и продемонстрируем эффективность технологии на реальных практических кейсах.
Для начала разберемся с архитектурой системы.
1. Коннекторы к смежным системам. В основе SOAR лежит двухстороннее взаимодействие со смежными ИТ- и ИБ-системами. Система использует коннекторы различных типов: от классических API и прямых запросов к базам данных о служебных протоколах удаленного управления — SSH, WinRM. Это позволяет SOAR не просто собирать данные, но и реализовывать реагирование, например, блокировку пользователя в Active Directory (AD) или IP-адреса на межсетевом экране.
2. Плейбуки реагирования — алгоритмы, описывающие порядок действий при реагировании на конкретные угрозы. Современные системы предлагают гибкие подходы к их созданию.
-
Low-code конструкторы плейбуков: визуальное проектирование логики в виде блок-схем с ветвлениями и циклами позволяет специалистам разрабатывать собственные сценарии. Использование low-code систем значительно ускоряет разработку типовых сценариев и не требует углубленных знаний языков программирования. Обычно SOAR поставляется с набором «коробочных» плейбуков для базовых операций: обогащения данных из Threat Intelligence (TI) платформ, блокировки учетных записей в AD или изоляции хостов.
-
Кастомные Python-скрипты: для реализации специфической логики или интеграции с проприетарным ПО, где возможностей визуального конструктора явно недостаточно, SOAR позволяет создавать полностью самописные скрипты. Для удобства разработки мы можем загружать необходимые нам библиотеки, что дает неограниченную гибкость в разработке сценариев. В дополнение к этому современные системы интегрируют ассистентов на базе искусственного интеллекта (ИИ) непосредственно в среду разработки, что ускоряет написание и отладку кода.
3. Управление инцидентами и аналитика. SOAR собирает поток инцидентов из различных СЗИ в единый интерфейс управления: аналитик видит всю очередь автоматически назначенных на него инцидентов в одной консоли, где может приоритизировать их, менять критичность и запускать сценарии реагирования. Все данные по инциденту собираются в одну карточку. Система автоматически обогащает инцидент данными: информацией о владельце, геопозицией автоматизированного рабочего места (АРМ), сегментом и критичностью. В последнее время в этот процесс активно внедряется ИИ: нейросети, обучаясь на истории инцидентов компании, предоставляют аналитикам рекомендации по реагированию. Однако система всегда предупреждает, что конечное решение и ответственность всегда остается за оператором.
4. Исполнительные агенты. Для реализации сценариев автоматизации в распределенных инфраструктурах SOAR использует агенты:
-
Серверные агенты функционируют как на основном сервере SOAR, так и в удаленных сегментах сети: DMZ, филиалы компаний.
-
Локальные агенты устанавливаются непосредственно на АРМ пользователей. Функционируя с правами локального администратора, они позволяют обходить ограничения UAC и обеспечивают полный доступ к ресурсам ОС: установке, удалению ПО, выполнению команд в PowerShell от администратора, прямому редактированию реестра, управлению процессами, а также передаче тяжелых данных, например, пакетов обновлений KB.
Общий функционал SOAR-систем:
-
Оркестрация и управление активами. SOAR собирает данные из различных средств защиты в «единое окно» и связывает инцидент с конкретным хостом. Это позволяет аналитику сразу видеть сегмент и критичность узла.
-
Автоматическое назначение инцидентов на аналитиков. Система автоматически назначает ответственного аналитика исходя из информации о его загрузке, смены или профильную группу.
-
Обогащение данных об инцидентах. Автоматический сбор контекста об инциденте при помощи внешних TI-систем и внутренних AD-источников. Аналитика проводится в том числе благодаря ИИ-ассистенту.
-
Ранжирование инцидентов по степени риска. Система определяет критичность на основе собранного контекста, например, атака на контроллер домена гораздо более приоритетна, чем на гостевой Wi-Fi.
-
Автоматическое выполнение рутинных задач аналитика. Система берет на себя типовые проверочные операции: проверки установленного СЗИ и логов почтового сервера. Примеры этих процессов разберем ниже в практических кейсах.
-
Разработка и запуск сценариев реагирования на инциденты ИБ (плейбуки). SOAR позволяет создавать алгоритмы реагирования на угрозы, которые запускаются в автоматическом режиме или по команде оператора. Плейбуки могут выполнять широкий спектр действий: от изоляции АРМ и сброса активных сессий до изменения политик фильтрации на NGFW.
С архитектурой и функционалом системы разобрались — давайте теперь посмотрим, как это работает на практике. Рассмотрим три конкретных кейса.
Кейс-1: почтовый сервер
Почтовый сервер компании регулярно подвергается атакам типа brute-force (перебор данных УЗ). Ручной мониторинг файлов и папок с логами, их анализ и последующая блокировка IP-адресов на межсетевом экране занимают много времени. За этот период злоумышленники успевают совершить тысячи попыток подбора, что создает риск компрометации учетных записей.
Реализация в SOAR
Описание архитектуры плейбука
Плейбук запускается по расписанию, например, дважды в сутки. Сценарий включает следующие этапы:
-
Сбор данных. Кастомный python-скрипт инициирует SSH-сессию с почтовым сервером, выполняет парсинг файлов в директории с логами авторизации, извлекает события неудачных попыток входа и преобразует данные в структурированный JSON-формат (логин, ip-адрес клиента, временная метка).
-
Реагирование. Плейбук обрабатывает массив данных из предыдущего шага. При превышении заданного порога неудачных попыток авторизации (например, более 10 входов за минуту с одного адреса) активируется сценарий блокировки ip-адресов на межсетевом экране.
Результат: переход от ручного управления к полностью автоматизированному сценарию позволил существенно сократить время блокировки атакующих и снизить нагрузку на аналитиков ИБ.
Схема работы представлена ниже
Кейс-2: доставка обновлений KB
В инфраструктуре заказчика присутствуют хосты под управлением Windows 7 и Windows 10. Требуется оперативно доставлять и устанавливать критические обновления безопасности (KB) средствами SOAR, в обход штатных механизмов распространения обновлений Windows.
Реализация в SOAR
Вместо ручного процесса распространения на хосты используется плейбук с применением локальных агентов, постоянно установленных на АРМ пользователей.
Описание архитектуры плейбука
Подготовка плейбука (сборка):
-
Загрузка обновления: оператор системы вручную скачивает необходимый KB-пакет обновления с официального сайта Microsoft.
-
Размещение файла: скачанный файл копируется в директорию файлов плейбука и загружается в SOAR.
Доставка и установка:
-
Работа агента. Агент SOAR устанавливается на АРМ пользователя как системная служба и работает постоянно, с момента включения компьютера.
-
Инициация сценария. Оператор SOAR запускает плейбук, в интерфейсе системы выбирает целевые агенты, например, по имени АРМ или группе хостов, и запускает выполнение.
-
Транспорт и установка. Агент самостоятельно осуществляет доставку файлов и запускает установку обновления, используя утилиту wusa.exe. После завершения установки агент обрабатывает код ответа и передает статус обратно в SOAR.
Результат: плейбук позволяет оперативно доставлять обновления на АРМ пользователей, снижает нагрузку на персонал и уменьшает количество рутинных операций.
Схема работы представлена ниже
Кейс-3: проверка и установка агентов безопасности
В компании на АРМ пользователей, согласно политике безопасности, должно быть установлено обязательное ПО. Необходимо осуществлять контроль за его наличием и актуальностью версий.
Реализация в SOAR
Описание архитектуры плейбука
Плейбук запускается при возникновении инцидента об отсутствии СЗИ на АРМ. Сценарий включает следующие этапы:
-
Сбор данных. SOAR подключается к диапазону IP адресов, который оператор выбирает при запуске плейбука. В зависимости от ОС система подключается к хостам по WinRM или SSH и сверяет список установленного ПО и версии агентов безопасности с версиями, загруженными в SOAR.
-
Реагирование. В случае если агент не установлен, либо его версия не совпадает с той, что загружена в SOAR, происходит установка агента безопасности: осуществляется доставка файла, далее через msiexec.exe (с флагом тихой установки /s ) запускается установка или обновление СЗИ. После завершения статус установки передается оператору в интерфейс SOAR.
Результат: автоматизация контроля комплаенса позволила исключить «слепые зоны» в защите инфраструктуры. Переход от ручных проверок к автоматизированному сценарию сократил время приведения АРМ в соответствие политикам ИБ с нескольких дней до считанных минут, минимизировав риск эксплуатации уязвимостей на незащищенных узлах.
Схема работы представлена ниже
Сложности интеграции и эксплуатации SOAR-систем
-
Зависимость от API сторонних вендоров. Стабильность и функционал SOAR напрямую зависят от смежных систем. Очередное обновление вендора может изменить эндпоинты API (например, с /api/v3.8/ на /api/v4.0/) или формат запросов, что приводит к неработоспособности плейбуков. Это требует постоянного мониторинга документации смежных систем и поддержки коннекторов в актуальном состоянии.
-
Сложность при поддержке плейбуков. Сценарии быстро устаревают при изменениях инфраструктуры сети на предприятии и политик ИБ. Требуется регулярная актуализация логики реагирования.
-
Сложности при масштабировании. Добавление или удаление новых средств защиты в инфраструктуре требует доработки существующих сценариев (скриптов) или разработки/покупки новых коннекторов, что увеличивает стоимость владения системой.
-
Риски при внедрении плейбуков. Неоптимизированные сценарии могут создавать критическую нагрузку на инфраструктуру. Зафиксированы кейсы, когда плейбук при сборе большого объема логов с АРМ пользователя через агент потреблял все доступное ОЗУ на хосте, что подчеркивает необходимость обязательного тестирования плейбуков на тестовом контуре перед внедрением.
Вывод
Приведенные в статье примеры — лишь малая часть того, что можно реализовать с помощью SOAR. Благодаря возможности комбинировать готовые функциональные блоки с гибкостью python-скриптов, горизонт автоматизации ограничен лишь замыслом аналитика и специфическими потребностями инфраструктуры. Это превращает SOAR из узкоспециализированного инструмента в универсальный центр управления ИБ. При этом нововведения в области ИИ позволяют аналитику сразу видеть уровень достоверности угрозы непосредственно в карточке инцидента и мгновенно запускать сценарии реагирования — от блокировки учетной записи в AD до полной изоляции скомпрометированного хоста. А агентская система, устанавливающаяся прямо на хост и работающая как служба, позволяет обходить ограничения операционной системы, которые присутствуют при подключении к хосту по WinRM.
Автор:
Никита Пономаренко, инженер направления автоматизации ИБ
Автор: USSC
