Эта проблема хорошо видна в исследованиях автоматизации первичного разбора и приоритизации алертов (triage). Например, авторы Carbon Filter отмечают, что аналитики тратят более половины времени на разбор ложных срабатываний. Предложенный ими подход использует контекст запуска процесса, чтобы автоматически группировать и отделять типичные ложные срабатывания от подозрительного поведения. На данных из реальных внедрений это позволило в шесть раз повысить соотношение полезного сигнала к шуму без снижения качества первичного triage.
Таким образом, эффект автоматизации в SOC определяется не просто количеством автоматизированных действий, а тем, насколько она сокращает объем информации, который аналитик должен обработать вручную. Если система эффективно отсекает шум и расставляет приоритеты, аналитик тратит меньше времени на рутинный разбор и быстрее переходит к расследованию действительно значимых событий.
Этот вывод важен и для понимания роли LLM в SOC. Полевое исследование LLMs in the SOC проанализировало 3 090 запросов 45 аналитиков за 10 месяцев. Авторы обнаружили, что аналитики в первую очередь используют LLM для осмысления происходящего, поиска и структурирования контекста: сопоставляют данные, уточняют информацию и формируют целостную картину инцидента. При этом 93% запросов соответствовали компетенциям, описанным в NICE Framework.
Получается важная закономерность: ИИ приносит наибольшую пользу там, где человеку приходится работать с большим объемом разрозненной информации и самостоятельно связывать ее в единый контекст. Поэтому первый практический сценарий использования LLM в SOC — не автономное принятие решений, а контекстная поддержка аналитика: поиск похожих инцидентов, суммирование информации, сопоставление фактов и подготовка предварительного вывода.
Именно поэтому сегодня ИИ мы рассматриваем не как замену SIEM или playbook, а как следующий уровень развития SOAR. В зрелом SOC именно SOAR становится центром обработки инцидента: здесь собирается карточка, сходятся данные обогащения, фиксируются статусы и действия сценариев реагирования, сохраняются комментарии аналитиков и формируются итоговые выводы. Это делает SOAR естественным контуром для внедрения ИИ: необходимый контекст уже собран, а результат работы с ним становится частью управляемого процесса.
Классический playbook хорошо работает там, где действия можно заранее описать в виде последовательности шагов. Но в ситуациях, когда нужно сопоставить несколько фактов, найти похожий кейс, проанализировать историю инцидента или подготовить объяснимый вывод, одной заранее заданной логики недостаточно. Здесь появляется другая модель автоматизации — работа с контекстом, историей и накопленными знаниями. Именно в этой зоне ИИ может дать наиболее быстрый и понятный практический эффект: не заменить аналитика, а сократить объем ручной работы, необходимой ему для принятия решения.
ИИ внутри рабочего контура SOC
Если ИИ должен помогать аналитику работать с контекстом, логично встраивать его туда, где этот контекст уже собран. В R-Vision SOAR ИИ-сервисы работают непосредственно внутри процесса обработки инцидента и получают доступ к данным карточки, связанным активам и учетным записям, истории похожих инцидентов, результатам обогащения и базе знаний. Поэтому аналитику не нужно вручную переносить информацию из разных систем в отдельный чат — ИИ работает с тем же контекстом, который уже используется при расследовании.
Такой подход позволяет рассматривать ИИ не как отдельный инструмент, а как управляемый слой автоматизации внутри SOAR. Результаты его работы возвращаются в карточку инцидента, чат аналитика или сценарий реагирования, поэтому сохраняются в рабочем контуре и доступны для проверки и аудита. При этом использование предметного контекста помогает снизить риск некорректных выводов: модель опирается на конкретные данные инцидента, а не только на текст запроса.
Архитектура также не привязана к одной LLM. В зависимости от требований заказчика можно использовать локальную модель, корпоративную LLM или внешний API для сценариев, в которых это допустимо. Для работы с чувствительными данными это позволяет выбирать подходящий контур обработки и сохранять контроль над данными и политиками доступа.
На практике ИИ в SOAR может работать в двух основных режимах. Первый — автоматический: ИИ запускается как часть playbook и возвращает результат непосредственно в карточку инцидента. Второй — интерактивный: аналитик обращается к ИИ в чате внутри инцидента, когда ему нужно уточнить информацию, проверить гипотезу или разобраться в нетиповом кейсе.
Какие ИИ-сценарии дают практический эффект в SOC
Само наличие ИИ-компонентов в продукте еще не означает полезной автоматизации. Их нужно собрать в понятный процесс, который ложится на реальную работу SOC и не создает неконтролируемых рисков. Как вендор с многолетним опытом построения корпоративных и ведомственных SOC, мы видим, что на старте лучше выбирать сценарии, которые дают понятную пользу, проверяются по данным инцидента и не дают модели прямого права менять инфраструктуру.
В R‑Vision SOAR собран базовый набор сценариев, который безопасно запускать первым: ранжирование, суммаризация, ретро-справка, поиск цепочек, предварительное заключение и ИИ-ассистент. Это не ограничение возможностей ИИ, а практическая стартовая точка: такие сценарии позволяют получить измеримый эффект, при этом сохраняя решение за аналитиком и оставляя все действия в управляемом контуре SOAR.
Ранжирование: приоритизация в очереди алертов
Ранжирование помогает уйти от обработки инцидентов по принципу FIFO (first in, first out — «первым пришел, первым обработан»). ИИ переоценивает приоритет не только по типу правила, но и по бизнес-критичности актива, связанным учетным записям, историческому контексту и признакам более сложной атаки.
В результате аналитик быстрее получает в работу те карточки, потенциальный ущерб от которых выше. Это особенно важно при высокой нагрузке, когда физически невозможно одновременно детально разбирать весь поток. Внешние исследования автоматизации triage также показывают заметный эффект именно в этой зоне: например, в исследовании AACT автоматизация первичного разбора позволила сократить на 61% число алертов, поступавших аналитикам на рассмотрение, при false negative rate 1,36%.
Суммаризация: быстрый вход в контекст
Даже после автоматического обогащения в SOAR карточка инцидента может содержать большой объем разнородной информации: события, поля, результаты скриптов, телеметрию, комментарии, данные о связанных активах и учетных записях. Суммаризация помогает сократить время на знакомство с этим массивом данных.
ИИ собирает информацию в компактное и логически последовательное (от более важного и общего к менее важным деталям для первого этапа знакомства) описание: что произошло, какие активы затронуты, что