Разработка AI SOAR для автоматизации SOC под ключ

Почему AI SOAR пробуксовывает без описанных сценариев

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

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

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

Эффект от автоматизации: скорость реакции и нагрузка на смену

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

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

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

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

AI SOAR: варианты развёртывания и их ограничения

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

Ниже — альтернативы в том виде, как мы их видим в проектах: по применимости, срокам запуска и по ограничениям, которые придётся принять осознанно.

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

Этапы внедрения: от аудита процессов до передачи в эксплуатацию

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

1. Аудит процессов. Собираем источники событий и текущие ручные операции: как приходят оповещения, как классифицируются, где теряется время. На выходе — карта потоков и перечень операций, пригодных для автоматизации.
2. Проектирование реакций. Для каждого класса инцидентов описываем ветку: обогащение данными, изоляция узла, блокировка учётной записи, уведомление ответственного. Согласуем границы — где решение принимает система, а где обязательна ручная проверка.
3. Тестовый контур. Разворачиваем изолированную среду с обезличенными данными, повторяющую рабочую топологию: ошибка в сценарии не уходит в рабочую среду, откат занимает минуты.
4. Настройка сценариев. Подключаем источники событий, настраиваем правила корреляции и пороги срабатывания, собираем ветки обработки. Ложные срабатывания отсекаем на разборе, а не на дежурстве.
5. Проверка на реальных инцидентах. Прогоняем сценарии на исторических журналах и на живом потоке, считаем долю оповещений, закрытых без человека, и время реакции. Найденные пробелы закрываем до передачи.
6. Обучение и передача в эксплуатацию. Отдаём регламенты и инструкции по нетиповым случаям, тренируем смену на тестовом контуре. Дальше — сопровождение и доработка сценариев по накопленной статистике.

Что передаём: конфигурации, сценарии, регламенты и документация

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

• Конфигурации — выгрузка правил корреляции, маршрутизации и приоритизации событий с комментариями: видно, какое правило за что отвечает и что изменится при его отключении.
• Схемы интеграции — карта источников событий и внешних систем: какие протоколы используются, где хранятся учётные данные, какие повторы настроены при недоступности источника.
• Регламенты для смены — пошаговые инструкции на типовые ситуации: первичная сортировка, эскалация, изоляция узла, закрытие инцидента, действия при ложном срабатывании.
• Сценарии реагирования — автоматизации с указанием триггеров, условий и границ: что система делает сама, а где обязательна проверка человеком.
• Политики доступа — матрица ролей: кто видит события, кто меняет правила, кто подтверждает автоматические действия, как выдаются и отзываются права.
• Документация — описание архитектуры, потоков данных, точек отказа и порядка обновления компонентов.
• Порядок проверки — набор тестовых событий, которыми смена подтверждает работоспособность сценариев после изменений, и критерии, при которых обновление откатывается.
• Журнал изменений — история правок правил с автором и причиной: разбор инцидента опирается на факты, а не на память.

Кейс: как сократили время реакции дежурной смены

До внедрения: дежурный как узкое место

На старте кейса внедрения смена получала порядка 4 000 срабатываний в сутки от SIEM — разной достоверности и без общей приоритизации. Аналитик вручную сопоставлял событие с активами, поднимал контекст по почте и заявкам, и на первичный разбор уходило 35–45 минут, а в ночные часы очередь просто дожидалась утра. Передача смены держалась на пересказе в чате: контекст терялся, и один инцидент иногда разбирали дважды.

Что изменили

Собрали библиотеку сценариев реагирования на общей таксономии тактик MITRE ATT&CK: классификация события, автоматическое обогащение данными об активе и учётной записи, изоляция хоста и блокировка учётной записи по заранее согласованным порогам. Обогащение выполняется параллельно — пока аналитик открывает карточку, контекст уже собран.

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

Метрики до и после

Среднее время реакции сократилось с 42 до 7 минут, медиана закрытия однотипных инцидентов — с 6 часов до 40 минут. Доля событий, закрытых без участия человека, выросла до двух третей; ручных действий на инцидент стало меньше в 4 раза. Нагрузка на ночную смену выровнялась: очередь перестала копиться к утру.

Где было сложнее, чем ожидали

Два участка потребовали отдельных итераций. Первый — источники с нестандартными форматами журналов: часть пришлось приводить к общему виду на стороне сбора, иначе классификатор ошибался на однотипных событиях. Второй — доверие аналитиков к автомату: сначала часть сценариев работала в режиме «предложить действие», а не «выполнить», и только после накопленной статистики мы снимали подтверждение по шагам.

Что делать, если своя автоматизация реагирования уже развёрнута?

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

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

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

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

Интеграции с существующими системами и ложные срабатывания

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

Как снижаете долю ложных срабатываний?

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

Что входит в сопровождение и как обновляются сценарии?

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

Обсудим вашу задачу и вернёмся с оценкой и планом

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

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

• карту источников событий и готовности интеграций, с явными пробелами в данных;
• перечень сценариев реагирования, отсортированных по частоте срабатывания и трудозатратам;
• план работ по этапам — от аудита контура до первых автоматизированных сценариев;
• оценку сроков по каждому этапу и состав команды под него;
• описание пилотного этапа: какие сценарии берём первыми и как измеряем результат;
• требования к доступам, тестовым данным и средам, чтобы пилот не встал на согласованиях;
• критерии приёмки: доля инцидентов, закрытых без участия аналитика, и время реакции.

Опишите задачу в свободной форме — вернёмся с оценкой сроков и планом работ.