Можно ли построить автономный SOC?

Идея полностью автономного центра мониторинга кибербезопасности (Security Operations Center), в котором без участия людей проходят сбор данных, анализ подозрительных событий, расследование и реагирование, крайне привлекательна для компаний, сталкивающихся с хронической нехваткой ИБ-специалистов и постоянным ускорением и усложнением киберугроз. Все были бы рады, если бы автоматизация помогла разгрузить аналитиков, ускорить обработку оповещений и наконец уничтожить феномен вообще не обработанных событий, доля которых, по некоторым данным, достигает в среднестатистическом корпоративном SOC 67% из общего числа.

Многие компании уже предлагают свои решения в этой сфере, но их практическое внедрение сталкивается с многочисленными трудностями. Хотя практики отмечают реальную пользу в обогащении оповещений (алертов) и уменьшении числа ложных/маловажных событий, мало где удается получить ощутимую выгоду от автономного принятия решений и реагирования.

Фундаментальные проблемы автономного SOC: за пределами ИИ

Хотя использование ИИ для анализа данных и принятия решений в SOC звучит как логичная и относительно несложная в реализации идея, попытка ее внедрить ставит и обостряет проблемы, с которыми организации столкнулись при внедрении SIEM, XDR и SOAR:

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

Консолидация данных и интеграция инструментов. Проблема, для решения которой когда-то изобрели SIEM, остается нерешенной во многих организациях. Кстати, в рекламе агентского SOC часто звучит тезис, что «SIEM будет не нужен», потому что «агент сам сходит в EDR за нужной телеметрией». Но на самом деле даже в идеальном сценарии это означает исчезновение SIEM как интерфейса при сохранении его основных функций в «субстрате данных» агентского SOC.

Доверие аналитиков. Даже когда роль ИИ сводится к предварительному сбору данных и рекомендациям, аналитики зачастую не доверяют данным и тратят время на их повторный сбор и анализ. При этом регулярно упоминаются несколько проблем в текущих реализациях AI SOC: непроработанная реализация «промежуточных» вердиктов (подозрительно, но не факт, что вредоносно), отсутствие сценариев безопасной эскалации, отсутствие самообучения на исправлениях вердиктов, которые поправил живой аналитик.

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

Проблемы ИИ, критичные для SOC

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

Галлюцинации и промпт-инъекции. В контексте SOC подделанное поле лога — это правдоподобный вектор воздействия непосредственно на агента. Если в «полуавтономном SOC» каждая галлюцинация лишь отвлекает живого аналитика и понижает доверие к системе, то в автономном SOC она может приводить к молниеносным и вредным действиям одновременно на сотнях и тысячах компьютеров. Пример про ИИ-агента в компании из списка Fortune 50, который самовольно переписал политики доступа, ярко это иллюстрирует.

Необходимость контроля. Проблему галлюцинаций и избыточного реагирования обычно решает одобряющий действия агента человек (Human-in-the-Loop, HITL). Но это хотя и повышает безопасность эксплуатации, обнуляет ключевое преимущество агентского ИИ — скорость.

Регуляторика, аудит и вопросы отчетности. Стохастические ответы LLM затрудняют журналирование, в них зачастую нет объяснимости и воспроизводимости. Поэтому с автономным SOC будет проблематично пройти аудиты на соответствие требованиям регуляторов. Текущие регуляторные фреймворки не проектировались под непредсказуемое поведение нескольких взаимодействующих агентов.

Подходы к решению проблем автономного SOC

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

Детальное управление контекстом (context engineering). При наличии корректных и качественно обогащенных данных (!) частоту галлюцинаций можно снизить, а качество решений агента значительно улучшить, структурированно подавая в языковую модель необходимые слои контекста: алерты, учетные записи, данные об активе, данные обогащения.

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

Нейросимволические проверки и ограничения действий агента. Конвейер Agent-Lock очищает недоверенные поля логов, верифицирует плановые действия по политикам CMDB/IAM, поддерживает соблюдение ключевых требований (например, недопустимость отключения телеметрии) и контролирует «бюджеты автономии».

Многоуровневая автономия вместо «есть/нет». Фреймворк доверенной автономности (Trusted Autonomy) предлагает пять уровней автономии ИИ, сопоставленных ролям HITL и порогам доверия для задач мониторинга, детектирования и реагирования. Низкорисковые операции (обогащение, дедупликация) выполняются автономно, а действия с высоким «радиусом поражения» требуют обязательной проверки человеком.

Архитектура, изначально построенная на базе соблюдения правил и регулирования (governance). Примером здесь служит платформа LanG (заявленная иерархия Governance → MCP → Agentic AI → Security) с двумя обязательными проверками живого аналитика, что соответствует требованиям NIST SP 800‑61. Правда, это значительно сужает автономность решения.

Детерминированное исполнение для критических действий. Приоритизация и расследование проводятся вероятностной ИИ-моделью, но конкретные действия (принятие решений об изоляции хоста или блокировке сессии) основаны на детерминированном коде. Этот подход удовлетворяет требованиям SOC 2 и других важных регуляторных фреймворков.

Проверки с учетом предыдущих состояний (stateful admission control). Например, недавно предложенный протокол ACP контролирует поведенческие свойства в журналах исполнения задач и таким образом позволяет ловить агентов, которые делают множество по отдельности безобидных запросов, суммарно складывающихся во вредоносную активность.

Выводы и подводные камни

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

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

Для зрелых SOC основная гипотеза на ближайшие 1–2 года такова: «автономный SOC» стоит воспринимать как вектор движения, а не конечное состояние. Осязаемая польза от ИИ есть уже сейчас (в корреляции, обогащении, черновиках правил и реконструкции атак) — при условии, что каждая такая способность обернута в защитные механизмы, включая адекватно сбалансированные проверки человеком для любых действий, затрагивающих основную инфраструктуру (production). Команды, которые уже сейчас вкладываются в структурированный и проверяемый подход, учитывающий соблюдение постепенно появляющейся регуляторики, смогут поэтапно встраивать в свой конвейер SOC новые агентские функции. Те, кто этот слой пропустит, с высокой вероятностью столкнутся с проблемами и, возможно, будут строить системы и процессы заново.