Agentic SOC: что это и зачем готовиться

Понедельник, 9:15 утра. За выходные SIEM накопил 47 000 событий. SOAR-плейбуки автоматически закрыли 12 000 - фишинговые письма, сканирование портов, неудачные логины. Из оставшегося система сформировала 340 алертов для аналитика первой линии. Первый кейс из очереди: учётная запись подрядчика обратилась к S3-бакету с исходным кодом в 2:00 ночи субботы. Права не отозваны после завершения проекта. Правило корреляции не сработало - дормантный аккаунт, нестандартное время, чувствительный актив вне проектного скоупа подрядчика.

Через шесть часов ручного разбора postmortem подтвердил: данные ушли наружу.

Именно такой сценарий должен закрывать Agentic SOC - агент, который видит то, что плейбук не предусмотрел. Но тут же возникает самый опасный побочный эффект: иллюзия, что «система смотрит, значит всё под контролем».

Agentic SOC - не SOAR с приставкой «AI»​

Разница принципиальная. SOAR-плейбук - детерминированная цепочка: «если пришёл алерт типа X - выполни шаги 1, 2, 3». Автономный SOC добавляет слой рассуждения: агент сам определяет, какие данные нужны, какие источники опросить, как обогатить событие и какой сценарий ответа адекватен контексту.

По данным исследования AgentSOC (IEEE, 2026), корпоративные SOC получают свыше 100 000 алертов в день. Около 70% - ложные срабатывания или события низкого приоритета. Аналитики тратят от 2 до 4 часов на ручной триаж, при этом почти 70% алертов остаются без расследования вообще. Глобальный дефицит кадров - 3,5 миллиона незакрытых позиций в кибербезопасности.

Agentic SOC - попытка решить эту проблему делегированием рутинного цикла «собрать контекст → обогатить → классифицировать → предложить действие» ИИ-агентам. IBM в концепции ATOM (Autonomous Threat Operations Machine) проводит аналогию с коммерческой авиацией: машины летают, пилоты вмешиваются при нештатных ситуациях. SOC-аналитик становится «пилотом» - выбирает, когда и куда вмешаться, пока агентная система разгребает стандартные операции.

Пять признаков настоящей агентности​

Не каждая система с LLM - агентный SOC. Вот пять критериев, отличающих агента от chatbot-обёртки:

1. Действует автономно - от алерта до резолюции в заданных границах без ручного управления на каждом шаге
2. Синтезирует контекст - проактивно связывает сигналы от разных источников: пользователи, активы, поведенческие паттерны
3. Принимает решения на основе контекста - знает, когда отклониться от правил, потому что ситуация не вписывается в шаблон
4. Выполняет действия - имеет интеграции и авторизацию для remediation, а не только генерирует рекомендации
5. Обучается - корректирует логику на основе результатов и обратной связи аналитиков

Если система генерирует рекомендации, но не может выполнить ни одного действия - это copilot. Выполняет действия по жёсткому скрипту без адаптации - это SOAR. Разница не в маркетинговом лейбле, а в том, умеет ли система рассуждать в нештатной ситуации.

Архитектура агентного SOC: три слоя​

Исследование AgentSOC (IEEE, 2026) описывает трёхуровневую архитектуру, которая хорошо ложится на практику ИИ в центре мониторинга безопасности.

Perception Layer - восприятие​

Слой нормализации и обогащения. Сюда поступает телеметрия из SIEM, EDR, NDR, IAM, CMDB, TI-фидов. Агент не получает доступ «ко всему» - каждый источник со строго описанными правами и скоупом (PR.AA-01, NIST CSF 2.0).

На этом уровне агент делает работу аналитика Tier-1: нормализация форматов, дедупликация, извлечение контекста из 5–7 консолей. IBM называет это «swivel chair operations» - переключение между окнами, съедающее основное рабочее время. Знакомо каждому, кто дежурил на первой линии. Агент сжимает часы ручного анализа до секунд, автоматически формируя вердикт по severity, confidence и impact.

Reasoning Layer - рассуждение​

Тут начинается отличие от SOAR. В архитектуре AgentSOC здесь работают два механизма:

Narrative Counterfactual Engine (NCE) генерирует несколько гипотез атаки на основе тактик и техник MITRE ATT&CK. Не «этот алерт похож на X», а «если это начало цепочки, следующими шагами будут Y и Z - вот какие артефакты нужно проверить». NCE строит сценарии «а что, если», а не подбирает ближайшее совпадение из библиотеки playbook.

Structural Simulation Engine (SSE) валидирует гипотезы NCE против реальной топологии сети, графа привилегий и организационных политик. Фильтрует невозможные пути атаки - то, чего LLM без привязки к инфраструктуре делать не способен. NCE предположил lateral movement через учётную запись сервиса? SSE проверит, есть ли у этого аккаунта сетевой путь до целевого сегмента.

Proof-of-concept на данных аутентификации LANL показал время обработки 506 мс - от нормализации алерта до сформированной гипотезы с рекомендацией. Для сравнения: ручной триаж одного алерта - 15–40 минут. Разница на два порядка.

Action Layer - действие​

Слой исполнения с обязательным контролем политик. AgentSOC использует Risk Scoring and Evaluation Module (RSEM), ранжирующий каждое защитное действие по трём параметрам:

• Эффективность сдерживания - насколько действие снижает угрозу
• Бизнес-импакт - какой ущерб нанесёт само действие (изолировать production-сервер в прайм-тайм - больно)
• Стоимость исполнения - ресурсы и время на выполнение

В контексте российских оборотных штрафов за утечку персональных данных цена ошибки - и пропущенной атаки, и ложной изоляции - измеряется в конкретных процентах от годовой выручки. RSEM формализует тот trade-off, который опытный аналитик держит в голове: «что хуже - пропустить инцидент или положить критичный сервис?»

Автономное реагирование на инциденты: что уже работает​

Автоматический триаж и обогащение​

Триаж - самый зрелый сценарий автоматизации SOC. Агент забирает алерт и за секунды собирает связанные события из SIEM, EDR, IAM, TI-фидов. Вместо сырого «на узле X замечена аномалия» аналитик получает обогащённый кейс:

• Владелец узла и его роль в инфраструктуре
• Аналогичные инциденты за последние 30 дней
• Связь с актуальными фишинговыми кампаниями из TI-фидов
• Маппинг на MITRE ATT&CK с вероятным сценарием развития
• Рекомендация по приоритету и следующему шагу (RS.AN-01, NIST CSF 2.0)

По данным Dropzone AI, автоматический триаж сокращает Mean Time to Conclusion на 90% - с 20–40 минут до 3–10 минут на алерт. При 340 алертах в день это разница между сутками ручной работы и несколькими часами.

Мягкие действия с контролем​

Второй зрелый сценарий - низкорисковые автоматические действия: создание кейса с привязкой артефактов, запрос подтверждения у владельца актива, добавление IOC в блоклист с ограниченным TTL, временное ограничение сессии до ревью аналитиком. Torq заявляет автономное закрытие свыше 90% кейсов, но тут нужна оговорка: это кейсы определённого типа - фишинг, сканирование, известные IOC. Сложные многоступенчатые атаки сюда не входят.

ИИ-агенты в кибербезопасности: новые риски​

Excessive Agency - OWASP LLM06:2025​

OWASP включил Excessive Agency в топ-10 рисков LLM-приложений (LLM06:2025): LLM с избыточными полномочиями или автономией может вызвать непредвиденные действия или нанести ущерб. В SOC это реализуется предельно конкретно.

Ложная корреляция. Агент связывает необычную активность с известным паттерном атаки и инициирует изоляцию хоста. На деле - плановое обновление в нестандартное окно. Если у агента есть полномочия на автоматическую изоляцию без одобрения, бизнес теряет доступ к критичному сервису. Я видел это на тестовом стенде - confidence 0.87, reasoning логичный, результат ложный.

Prompt injection через телеметрию. Атакующий внедряет payload в лог-поток, зная, что LLM-агент его обработает. Не теоретический вектор - MITRE ATT&CK уже отслеживает использование AI атакующими: T1588.007 (Artificial Intelligence, Resource Development) и разведку через публичные AI-сервисы (T1682, Reconnaissance).

Слепая зона на инсайдерах. Агентный SOC хорошо ловит аномалии - нестандартное время, необычные IP, новые процессы. Инсайдер же использует валидные учётные данные в рабочее время с привычных хостов. По данным CrowdStrike, 75% вторжений задействуют действительные credentials. Для агента такая активность выглядит нормальной - baseline не нарушен. Здесь суждение аналитика остаётся незаменимым.

Иллюзия контроля. Дашборд зелёный, агент закрывает кейсы, MTTR падает. Красота. Но если агент систематически ошибается на lateral movement через валидные учётные данные - реальные инциденты проходят незамеченными. По данным Mandiant, медианное время нахождения злоумышленника в сети - 11 дней (исторический минимум), при этом 57% организаций узнают об инциденте от внешней стороны, а не от собственного SOC. Зелёный дашборд - не гарантия безопасности.

Гонка вооружений: ИИ атакующих против ИИ защитников​

Контекст, без которого автоматизация SOC не имеет смысла. По данным IBM X-Force, генерация фишинговых писем через GenAI быстрее в 11,4 раза при сопоставимом качестве. CrowdStrike фиксирует удвоение вредоносного использования GenAI для социальной инженерии в 2024 году.

IBM X-Force также отмечает рост атак с использованием валидных credentials на 71% год к году, а в даркнете ежедневно появляется более 6 000 свежих учётных данных. Среднее время между публикацией CVE и устранением в организации - 29 месяцев. Двадцать девять. Атакующие адаптируются быстрее, чем обновляются SOAR-плейбуки. Агентный подход призван сократить этот разрыв - но только при грамотном внедрении.

Detection-чеклист: мониторинг агентных действий​

Если вы внедряете агентный ИИ в ИБ, нужен отдельный слой наблюдаемости - мониторинг самих агентов. Без этого Agentic SOC - чёрный ящик. Минимальный чеклист:

1. Аудит действий агента. Каждое решение логируется с reasoning. Отдельный data source в SIEM с полями: agent_id, action_type, reasoning_summary, confidence_score, target_asset, timestamp.

2. Baseline поведения агента (DE.AE-01, NIST CSF 2.0). Нормальное количество действий в час, распределение по типам решений, среднее время обработки. Аномалия в любой из этих метрик - индикатор сбоя модели или попытки манипуляции.

3. Override rate. Как часто аналитик отменяет решение агента. Выше 15% - пора пересматривать модель или обучающие данные.

4. Miss rate. Как часто агент пропускает то, что ловит аналитик при ручном ревью. Замеряется на выборке из 5–10% кейсов еженедельно.

5. Excessive Agency alerts. Мониторинг попыток агента выполнить действия за пределами разрешённых политик - прямая реализация рекомендаций OWASP LLM06:2025.

6. Версионирование промптов и политик. Неизменяемый журнал всех изменений конфигурации агента. Без него невозможно понять, почему агент повёл себя иначе после очередного обновления (а он поведёт - вопрос времени).

Пример правила корреляции для SIEM:

Дорожная карта внедрения SOC нового поколения​

Этап 3. Мягкие действия (3–6 месяцев). Низкорисковые операции: создание кейса, тегирование, сбор артефактов, уведомление владельца. Метрика: false_action_rate. Порог: ниже 5%.

Этап 4. Ограниченная автономия (по готовности). Containment на некритичных активах с обязательным согласованием для production. Метрика: MTTR автоматизированных кейсов vs ручных.

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

Роль SOC-аналитика в будущем​

Если агент берёт триаж, обогащение и мягкие действия - что остаётся аналитику? Самое сложное.

Threat hunting. Проактивный поиск угроз, не вызвавших алерт. Агент реактивен по природе - обрабатывает входящие события. Гипотезы для hunting требуют знания бизнес-контекста организации (GV.OC-01, NIST CSF 2.0), которого у LLM нет и не будет в обозримом будущем.

Валидация агентных решений. Ревью override rate, анализ miss rate, калибровка порогов confidence. Новая повседневная рутина аналитика, заменяющая копипаст между консолями. Честно говоря, работа интереснее.

Prompt engineering для security-контекста. Настройка агентов, расширение набора инструментов, калибровка политик. Навык, отличающий SOC-аналитика 2026 года от аналитика 2020-го.

Расследование сложных инцидентов. Многоступенчатые атаки, APT-активность, инсайдерские угрозы. По данным Verizon DBIR, 68% утечек включают человеческий фактор - контекст, который агент полноценно интерпретировать не способен.

Governance. Кто отвечает за решение агента? Если агент изолировал production-сервер - ответственность вендора, SOC-команды или CISO? Функция Govern (GV) в NIST CSF 2.0 стоит первой не случайно.

Я внедрял SOAR-платформы трижды за четыре года - Splunk SOAR, Cortex XSOAR, Shuffle. Каждый раз обещания вендоров про «90% автоматизации» разбивались об одно и то же: неполная CMDB, отсутствие identity context, плейбуки, не покрывающие edge cases. Agentic SOC - следующая итерация, но с принципиальным отличием: агент рассуждает там, где плейбук останавливается. Проблема в том, что «умеет рассуждать» не означает «рассуждает правильно». На тестовом стенде LLM-агент уверенно связал плановую миграцию базы данных с паттерном exfiltration и рекомендовал изоляцию - confidence 0.87, reasoning логичный, результат ложный.

Мой прогноз: через 12–18 месяцев агентный SOC станет стандартом для Tier-1 операций в организациях со зрелым SOC. Для сложных расследований и threat hunting человек останется в контуре надолго - не потому что нет технологий, а потому что нет доверия. И это правильно. Пока override rate на реальных данных не опустится ниже 5% устойчиво, полная автономия - маркетинговый нарратив, а не инженерная реальность. Если интересно, как другие SOC-команды строят мониторинг агентных решений и на каких этапах спотыкаются - на codeby.net идёт тред с разбором кейсов внедрения автоматизации в SOC-процессы.