Что такое SOAR и как он ускоряет реагирование на инциденты

Понедельник, утро. У аналитика в очереди десятки писем, которые сотрудники переслали с пометкой «подозрительное». Каждое нужно открыть, вытащить ссылки и вложения, проверить по репутационным базам, найти такие же письма в других ящиках, удалить их, заблокировать отправителя и завести заявку. Одни и те же действия в пяти разных консолях — и так до обеда. Именно такую работу забирает SOAR, и ниже разберём, что такое SOAR и как он устроен.

По данным TAdviser, на рутину уходит около 40 % времени инженеров. В ИБ эта рутина особенно дорогая: пока человек копирует IP-⁠адреса между окнами, атакующий продолжает работать.

Что такое SOAR простыми словами

SOAR (Security Orchestration, Automation and Response) — класс систем для оркестрации средств защиты, автоматизации рутинных операций и реагирования на инциденты ИБ. SOAR связывает разрозненные СЗИ и ИТ-⁠системы и выполняет в них действия по заранее описанным сценариям — плейбукам.

Если SIEM — это сигнализация, то SOAR — дежурный, который получает сигнал и действует по инструкции: проверяет, собирает контекст, перекрывает доступ, звонит ответственным и записывает каждый шаг в журнал. Только делает это за секунды и не забывает пункты регламента.

Вторая роль SOAR — единое рабочее место. По оценке IDC, в крупных компаниях работает 20–⁠30 СЗИ, и у каждого своя консоль. SOAR становится местом, где инцидент живёт от первого алерта до закрытия: с карточкой, историей действий, ответственными и сроками.

Чем SOAR не является, тоже важно понимать. Он не заменяет аналитиков и не обнаруживает атаки сам по себе — источником сигналов остаются SIEM, EDR, почтовые шлюзы и другие СЗИ. SOAR не исправит плохо настроенные правила корреляции: если на вход приходит шум, автоматизация просто быстрее его обработает. Его сила — в скорости и повторяемости того, что команда уже умеет делать руками.

Три составляющие SOAR: оркестрация, автоматизация, реагирование

Оркестрация

Интеграция СЗИ и ИТ-⁠систем в одну управляемую схему: SIEM, EDR, межсетевые экраны, почтовые серверы, каталог учётных записей, ITSM, мессенджеры. Одна команда в SOAR превращается в согласованные действия сразу в нескольких системах — без переключения между консолями.

Автоматизация

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

Реагирование

Управление жизненным циклом инцидента: анализ и обогащение, сдерживание, устранение, восстановление, пост-⁠инцидентный разбор. Сюда же относятся карточка инцидента, роли, SLA, эскалации и отчётность для руководства и регуляторов.

На практике три составляющие неразделимы. Оркестрация без автоматизации — это просто удобный пульт с кнопками. Автоматизация без управления инцидентами превращается в набор скриптов, про которые через полгода никто не помнит, кто их написал и что они делают. Ценность появляется, когда все действия происходят внутри карточки инцидента и остаются в её истории.

Как работает плейбук реагирования

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

1. 01

   Триггер

   Сотрудник пересылает подозрительное письмо или почтовый шлюз помечает его. SOAR автоматически создаёт инцидент.

2. 02

   Обогащение

   Из письма извлекаются адрес отправителя, ссылки, IP-⁠адреса и хэши вложений. Они проверяются по репутационным сервисам и базе индикаторов компрометации.

3. 03

   Оценка масштаба

   Система ищет такие же письма в других почтовых ящиках и проверяет, переходил ли кто-⁠то по ссылке.

4. 04

   Решение

   Индикаторы вредоносные — плейбук идёт по ветке сдерживания. Сомнительные — назначает аналитика и ждёт его решения.

5. 05

   Сдерживание

   Аналогичные письма удаляются, отправитель и домены блокируются, пользователю, перешедшему по ссылке, сбрасывается пароль.

6. 06

   Документирование

   Создаётся задача в ITSM, дежурная смена и руководство получают уведомления, все шаги записываются в журнал инцидента.

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

SOAR и SIEM: в чём разница

Самый частый вопрос. Коротко: SIEM находит, SOAR действует. Это не конкуренты, а соседние звенья одной цепочки.

Можно ли обойтись встроенными функциями реагирования в SIEM или EDR? Для одного-двух простых действий — да. Но как только сценарий затрагивает несколько систем и людей из разных отделов, нужен оркестратор. Как SOAR дополняет центр мониторинга — в том числе внешний — разбирает наш генеральный директор в статье «Что такое SOC и почему с ним всё равно нужен SOAR».

Автоматизация реагирования на инциденты: с чего начать

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

• Фишинг. Самый массовый и хорошо формализуемый сценарий, поэтому отличный кандидат на первый плейбук. Эффект виден сразу: аналитики перестают разбирать одинаковые письма вручную, а пользователи быстрее получают ответ, безопасно ли вложение.
• Блокировка индикаторов компрометации (IoC). Индикатор из TI, от SOC или из расследования автоматически попадает в блок-⁠листы межсетевого экрана, прокси, почтового шлюза и DNS.
• Учётные записи. Подозрительный вход, перебор паролей, вход из нетипичного места: блокировка или сброс пароля, завершение сессий и VPN-⁠подключений, уведомление пользователя и руководителя.
• Заражение конечной точки. Изоляция хоста, остановка процесса, удаление файла, запуск проверки.
• Обогащение любого алерта. Даже без автоматических блокировок: подтянуть владельца актива, его критичность, открытые уязвимости и историю инцидентов. Эти данные удобно брать из систем управления активами и управления уязвимостями.
• Уведомления и отчётность. Задачи в ITSM, оповещение руководства, подготовка сведений для регулятора — например, для уведомления Роскомнадзора об утечке персональных данных, которое по 152-⁠ФЗ нужно направить в течение 24 часов.

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

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

Метрики эффекта: MTTD, MTTR и что ещё считать

Эффект SOAR нужно измерять, иначе через полгода проект превратится в «ну вроде стало удобнее». Базовый набор метрик:

• MTTD (Mean Time To Detect) — среднее время от начала инцидента до его обнаружения. Зависит в первую очередь от SIEM, EDR и качества правил; SOAR влияет косвенно, ускоряя разбор алертов.
• MTTR (Mean Time To Respond) — среднее время от обнаружения до локализации инцидента. Иногда под R понимают Recover или Remediate, поэтому трактовку стоит зафиксировать внутри команды. Именно MTTR — главная метрика SOAR.
• Доля инцидентов, обработанных автоматически — сколько кейсов плейбук закрыл без ручных шагов.
• Нагрузка на аналитика — число алертов на человека в смену и время на один алерт.
• Отсеянные ложные срабатывания — сколько алертов закрыто на этапе обогащения, не дойдя до человека.

Замеряйте состояние «до» по реальным инцидентам — по журналам и тикетам, а не по ощущениям. Тогда разница будет видна и финансовому директору.

Учитывайте и менее заметный эффект: меньше ошибок и меньше зависимости от того, знает ли дежурный каждое СЗИ досконально.

Как выбрать SOAR-⁠систему: чек-⁠лист

Демонстрация любой SOAR-⁠системы выглядит эффектно. Чтобы понять, как она поведёт себя через год, задайте вендору неудобные вопросы:

1. Интеграции. Сколько готовых коннекторов к вашим СЗИ и ИТ-⁠системам и — главное — как быстро делается новый. Готовых коннекторов всегда не хватает, поэтому важно, можете ли вы написать свой без участия вендора.
2. Конструктор плейбуков. Визуальный редактор с ветвлениями, параллельными шагами, эскалацией и подтверждениями, плюс скрипты для сложной логики. Проверьте, как быстро аналитик без навыков программирования меняет существующий сценарий.
3. Гибкость модели данных. Можно ли добавить новый тип сущности, поле, связь или статус без обновления продукта и разработки вендора. Процессы будут меняться — система должна меняться вместе с ними, а не наоборот.
4. Развёртывание в контуре. SOAR управляет СЗИ и хранит чувствительные данные об инцидентах, поэтому должен работать внутри вашего периметра. Проверьте поддержку отечественных ОС и СУБД, наличие в реестре российского ПО, требования к оборудованию и сроки пилота.
5. Ролевая модель и аудит. RBAC/ABAC, SSO, журнал всех действий — и людей, и плейбуков.
6. Лицензирование без лимитов. Если вы платите за каждый актив, пользователя или инцидент, вы начнёте экономить на автоматизации ровно там, где она нужнее всего.
7. Мультиарендность. Для холдингов и MSSP — логическая изоляция юрлиц в одной инсталляции.

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

Как SOAR устроен в Versium

Модуль SOAR платформы Versium принимает инциденты из KUMA, MaxPatrol SIEM, RuSIEM, Smart Monitor, BI.ZONE EDR, KATA, Kaspersky Security Center и PT NAD — без дублей при повторной загрузке, — обогащает карточку и запускает процессы из графического конструктора с ветвлениями, таймерами, задачами и эскалацией по таймауту. Среди готовых действий — изоляция хоста, блокировка учётной записи и сброс пароля в Active Directory, блокировка отправителя, запрет хеша в KATA. Смена получает уведомления в Telegram, VK Teams, DION или по почте, инциденты для регулятора собираются в очередь к уведомлению НКЦКИ, а все действия сохраняются в истории инцидента. AI-⁠аналитик на базе Версиум AI сам обогащает инцидент, а блокировку и изоляцию выполняет только с одобрения аналитика.

Платформа разворачивается в контуре заказчика на Linux x86-64 через Docker Compose — онлайн или из офлайн-архива, с PostgreSQL 17 в составе поставки — и входит в реестр российского ПО (запись №31573). Модель данных динамическая: таблицы, поля и связи меняются в конструкторе без остановки сервиса. Коннекторы пишутся на .NET прямо в редакторе платформы, а лимитов по активам, пользователям и инцидентам нет. Подробнее — на странице платформы, а проверить подход на своих сценариях можно на демонстрации.