С чего начинать автоматизацию SOC с помощью LLM

Автор статьи: Артём Гольцов, Руководитель управления технологий искусственного интеллекта и анализа данных R-Vision

Почему в SOC назрел следующий шаг автоматизации

Одна из главных проблем современного SOC — избыток данных. Такие системы, как SIEM, EDR, TI, NTA и CMDB формируют богатый контекст, за счет чего возрастает и когнитивная нагрузка на аналитика. Чем больше карточка инцидента и чем больше в ней сырых логов, связанных сущностей и исторических материалов, тем дороже обходится первичный разбор. В этой зоне и возникает разрыв между формальной автоматизацией процесса и реальной скоростью принятия решений сменой SOC.

Эта проблема хорошо видна в исследованиях автоматизации первичного разбора и приоритизации алертов (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 карточка инцидента может содержать большой объем разнородной информации: события, поля, результаты скриптов, телеметрию, комментарии, данные о связанных активах и учетных записях. Суммаризация помогает сократить время на знакомство с этим массивом данных.

ИИ собирает информацию в компактное и логически последовательное (от более важного и общего к менее важным деталям для первого этапа знакомства) описание: что произошло, какие активы затронуты, что уже подтверждено и что требует дополнительной проверки. Для L1/L2 это особенно актуально, поскольку позволяет быстрее перейти от чтения карточки к осмысленному действию.

Ретро-справка: использовать накопленную экспертизу

Не каждое расследование нужно начинать с нуля. Ретро-справка позволяет обращаться к историческим кейсам, прошлым решениям аналитиков, известным false positive (ложноположительным кейсам) и внутренним регламентам.

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

Здесь используется RAG (Retrieval-Augmented Generation — генерация с поисковым извлечением из базы знаний): модель не пытается самостоятельно «вспомнить» ответ, а получает для его формирования релевантные материалы из заданного источника.

Поиск цепочек: увидеть инцидент целиком

Отдельные события не всегда выглядят опасными. В low-and-slow сценариях (медленных и малозаметных атаках) несколько действий могут быть распределены во времени и по разным системам, но вместе формировать единую цепочку.

ИИ может подсветить возможные связи между событиями, активами и учетными записями и тем самым помочь аналитику быстрее сформировать гипотезу о происходящем. При этом задача сервиса — не «доказать атаку», а обратить внимание на взаимосвязи, которые легко потерять при анализе отдельных карточек.

Для SOC это напрямую связано с сокращением dwell time — времени присутствия атакующего в инфраструктуре: чем раньше отдельные события объединяются в единую картину, тем быстрее команда может перейти к проверке гипотезы и реагированию.

Предварительное заключение: сформировать проверяемую гипотезу

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

Именно такой подход позволяет перевести вывод ИИ из свободного текста в структурированную гипотезу, которую аналитик может проверить и при необходимости скорректировать.

Это особенно важно с точки зрения объяснимости. В исследовании Moosmann и коллег аналитики правильно выполняли triage в 83% случаев, однако только 39% их объяснений действительно отражали root cause (корневую причину). Для SOC это показывает, что правильного решения недостаточно: важно понимать и уметь обосновать, почему оно было принято. Поэтому предварительное заключение ИИ стоит рассматривать не как замену решения аналитика, а как способ быстрее сформировать evidence-based (основанную на фактах) гипотезу.

ИИ-ассистент: помощь в нестандартных ситуациях

Не все задачи можно заранее описать в playbook. Для таких случаев нужен ad-hoc режим, в котором аналитик сам обращается к ИИ внутри карточки инцидента.

Он может спросить, почему сработало конкретное правило, какие похожие кейсы уже расследовались, какие поля стоит проверить, как интерпретировать фрагмент лога или есть ли в карточке важные артефакты.

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

От автоматизации отдельных действий к изменению работы аналитика

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

Где возникает бизнес-эффект и как его измерить

Для CISO и руководителя SOC важен не сам факт появления ИИ, а то, как он влияет на экономику процесса. Эффект складывается из вполне практичных вещей: аналитик быстрее разбирает карточки инцидентов, не тратит время на повторный анализ знакомых кейсов, точнее расставляет приоритеты, реже переключается между системами и получает стандартизированный первичный вывод. В результате команда высвобождает время для сложных расследований, threat hunting и развития playbook.

Отдельная ценность появляется при онбординге новых L1-аналитиков. ИИ-сервисы помогают быстрее погрузиться в контекст конкретного SOC, понять логику типовых кейсов, увидеть прошлые решения и быстрее начать работать в едином стандарте смены. Именно поэтому ИИ-сервисы в SOAR стоит рассматривать не как отдельную «фичу», а как инструмент освобождения ресурсов SOC и снижения рутинной нагрузки.

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

Показатели фиксируются на двух уровнях:

• отдельная операция: количество применений ИИ, время выполнения без ИИ и с ним, доля результатов, принятых без существенной доработки, точность вердиктов и число повторных действий;
• процесс SOC: среднее время обработки инцидента, производительность смены, размер бэклога, доля нарушений SLA и количество эскалаций.

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

Процент экономии времени рассчитывается отдельно для каждого ИИ-кейса:

Экономия времени по кейсу, % = (время без ИИ − время с ИИ) / время без ИИ × 100%

Затем определяется вклад каждого кейса в общую производительность SOC:

Высвобожденные часы по кейсу = количество операций × фактическая доля использования ИИ × (экономия времени на одной операции в минутах / 60)

Деление на 60 переводит сэкономленные минуты в часы. Если время выполнения операции изначально учитывается в часах, дополнительный перевод не требуется.

Общий эффект пилота складывается из результатов всех протестированных сценариев:

Общий объем высвобожденного времени = сумма высвобожденных часов по всем ИИ-кейсам.

Денежную оценку высвобожденной мощности можно получить через стоимость ресурса команды:

Валовый экономический эффект = общий объем высвобожденного времени × полная стоимость часа специалиста.

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

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

Что нужно подготовить до пилота

Одна из ключевых ошибок при внедрении ИИ в SOC связана с ожиданием, что LLM сможет компенсировать недостаток качественных данных и выстроенных процессов. На практике результат напрямую зависит от контекста, который получает модель. Чем важнее сценарий для расследования, тем выше требования к полноте и качеству входных данных.

Для корректного triage ИИ должен учитывать бизнес-ценность затронутого актива, историю похожих кейсов и результаты предыдущих расследований. Оптимальным источником становится уже нормализованный контур инцидентов в SOAR, где данные из разных систем собраны вокруг конкретного события. Сырой поток EPS (events per second, событий в секунду) из SIEM сам по себе такого контекста не дает.

Для запуска пилота стоит проверить несколько базовых условий:

1. Актуальная ресурсно-сервисная модель. Если в карточке инцидента нет связи с бизнес-критичностью актива, ИИ не сможет адекватно переранжировать очередь.

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

3. Качественная история расследований. Исторические кейсы с корректными TP/FP-вердиктами (true positive/false positive, истинно-положительные и ложноположительные) помогают использовать накопленную экспертизу. Если база содержит большое количество ошибок, RAG рискует воспроизводить накопленный шум и закреплять некорректные выводы.

4. Актуальная база знаний. Регламенты, playbook и внутренняя документация должны регулярно обновляться и поступать в ИИ в актуальной версии. Это снижает вероятность того, что модель будет опираться на устаревшие требования или процедуры.

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

Также стоит учитывать, что ИИ-сервисы в SOAR должны работать на уже структурированном контуре. В нашем инженерном исследовании по локальному инференсу для SOAR подчеркивается, что именно SOAR удобен как точка встраивания LLM: к нему уже как правило подключены SIEM, CMDB, TI и другие источники; в карточке есть события, сведения об активах, их критичность и результаты обогащения, а результат ИИ можно сохранять обратно в процесс расследования. Иными словами, хороший пилот начинается не с выбора модели, а с выбора качественного, уже управляемого контура данных.

Вывод

ИИ в SOAR стоит начинать не с полной автономности, а с понятных, проверяемых и встроенных в процесс сценариев. В R‑Vision SOAR такая база уже появилась: слой оркестрации ИИ-сервисов, единый контур подключения моделей, база знаний и набор рабочих ИИ-сценариев для SOC. В более широком контексте мы развиваем эти возможности как часть продуктовой платформы R-Vision EVO: ИИ-компоненты должны работать не изолированно, а на стыке данных SOAR, SIEM, VM, SGRC и других решений платформы. Это позволяет строить сценарии как внутри одного продукта, так и на уровне сквозных процессов ИБ.

Существует инфраструктурный миф о том, что для старта ИИ-автоматизации ИБ обязательно нужен большой GPU-кластер (кластер графических ускорителей). Практика показывает более прагматичную картину: если правильно выбрать сценарии, ограничить контекст, разделить интерактивные и фоновые задачи и измерять качество пилота, часть SOAR-сценариев можно начинать тестировать локально и постепенно масштабировать. Поэтому ценность ИИ-сервисов R‑Vision не в «нашлепке» рядом с продуктом, а во встроенном управляемом слое, который можно пилотировать в понятном контуре, измерять по операционным метрикам и развивать от read-only поддержки аналитика к более зрелой AI-автоматизации.