О чем статья
Рассказываем, какими характеристиками должны обладать автономные SOC и какие наработки уже существуют
Проблемы современных SOC
Наши коллеги из PT ESC IR проанализировали отчеты проектов по расследованию и ретроспективному анализу инцидентов за 2024–2025 гг. Средняя продолжительность инцидента составила 9 дней, самый долгий кейс длился почти 3,5 года, а самый короткий — один день.
Несмотря на положительную динамику по некоторым метрикам (см. рис. 1–3), традиционные SOC сталкиваются с рядом проблем: это ложноположительные срабатывания и нехватка контекста для анализа событий; слепые зоны, возникающие из-за недостаточной видимости инфраструктуры и поверхности возможных атак; зависимость от своевременной доставки/разработки контента обнаружения; неэффективный обмен данными между командами. Кроме того, инструменты в SOC зачастую не интегрированы между собой и с источниками событий ИБ.
При этом скорость и изощренность кибератак растут, что приводит к необходимости ответного совершенствования инструментов и процессов защиты. Рынку необходим автоматизированный SOC нового поколения — давайте разберемся с тем, каким он должен стать.
Каким должен быть беспилотный SOC
Автоматизированная интеграция источников
При внедрении SIEM в SOC возникает проблема интеграции источников событий безопасности. Для сбора данных, приведения их к единому формату и передачи в систему нужны коннекторы и правила нормализации. Зачастую инженеры пишут их вручную, и это отнимает много времени (особенно в крупных инфраструктурах).
Вендоры уже работают над автоматизацией этого процесса. Перед ними стоят две задачи: первая — сбор достаточного, но неизбыточного количества данных, вторая — их конвертация в подходящий для SIEM формат (модель данных). В автономном SOC за эти задачи должен отвечать модуль, который будет самостоятельно анализировать формат событий, размечать данные и передавать их в SIEM.
Подобные решения уже есть: например, Gurucul используют Data Pipeline AI Agent, обеспечивающий интеграцию новых потоков данных с поведенческими моделями без участия аналитиков. Мы, в свою очередь, разрабатываем для MaxPatrol SIEM ИИ-ассистент, способный генерировать экспертный контент на языке XP. Ассистент проводит кластеризацию исходных журналов событий, извлекает и категорирует данные, а затем генерирует правила нормализации и комментарии с применением LLM и файн-тьюнинга метода LORA.
Важный момент: чтобы быстро и структурированно передавать данные в SIEM, также потребуется грамотно настроенный и полностью автоматизированный процесс ETL (см. табл. 1).
Автоматизация подключения источников к мониторингу и общая модернизация ETL-процесса в SIEM стали одними из ключевых трендов 2025 г. Мы ожидаем развития этой темы как в крупных enterprise-решениях, так и среди молодых стартапов, специализирующихся на создании конвейеров данных безопасности (SDPP — Security Data Pipeline).
Обработка ложноположительных сработок и однотипных событий
Следующая задача, которую отрасли предстоит решить на пути к беспилотным SOC, — это обработка ложноположительных и однотипных событий. Исследования показывают, что они составляют до 80% алертов, поступающих в современный SOC. Это связано с тем, что охват сигнатурных правил нередко оказывается шире реальных действий злоумышленников. Кроме того, атакующие активно используют легитимные инструменты, встроенные в целевую систему (атаки типа living-off-the-land), поэтому нормальная активность пользователей попадает в сработки правил корреляции.
Для решения этой проблемы применяются разные подходы: например, подавление правил, генерирующих много срабатываний, группировка однотипных срабатываний по временному окну или использование белых списков. Эти методы закрывают базовые задачи, однако от беспилотных SOC мы ожидаем более эффективного и комплексного подхода.
На фоне развития генеративного и агентского ИИ появляются модули, способные анализировать срабатывания и выявлять неэффективные детектирующие правила:
- ИИ-агент Noise Cancelation Agent от Securonix определяет, какие правила создают много FP.
- Платформа CardinalOps выявляет слепые зоны и нефункционирующие детекты в SIEM/XDR.
- Механизм Insight Trainer от Sumo Logic предлагает рекомендации по изменению правил детектирования.
Внедрение алгоритмов поведенческого анализа
Поведенческий анализ активно внедряется в SIEM- и XDR-продуктах. UEBA-функционал заявлен в большинстве современных решений: ML-алгоритмы уже способны эффективно выявлять отклонения в действиях пользователей и запускаемых процессах. Это позволяет находить аномалии и угрозы, которые пропускают традиционные правила обнаружения.
В MaxPatrol SIEM применяется модуль BAD, который обнаруживает атаки с помощью ML-моделей и фокусирует внимание оператора на самых опасных событиях. Для этого BAD анализирует процессы ОС на предмет аномальности и присваивает всем событиям определенный risk score.
В части развития UEBA/BAD можно выделить следующие тренды:
- Использование модуля поведенческого анализа в качестве второго пилота для контроля и верификации сработок традиционных правил корреляции.
- Масштабирование моделей для выявления аномалий в облачных средах, serverless-вычислениях, SaaS-сервисах, IoT/OT, Edge AI, а также для усиления мониторинга активности машинных учетных записей (включая ИИ-агентов и различные микросервисы).
- Перенос алгоритмов поведенческого анализа на периферийные решения (EDR и легковесные IoT-агенты) для обнаружения угроз на ранних этапах в реальном времени.
- Применение BYOML-подхода, в рамках которого вендор дает клиентам возможность кастомизировать ML-алгоритмы UEBA/BAD с учетом особенностей инфраструктуры и отраслевой специфики. Этот подход будет наиболее востребован в крупных компаниях и у MSSP-провайдеров, поскольку требует наличия ML-специалистов в SOC.
- Применение федеративного обучения. Метод подразумевает обучение модели на материалах из разных источников, но данные при этом не покидают пределов компании.
Детекты как код и внедрение ИИ
Концепция Detection-as-Code постепенно становится стандартом в современных SOC. Процесс написания детектирующей логики превращается в полноценную разработку, где есть контроль версий, многопользовательский режим, тестирование и верификация новых правил и код-ревью. Кроме того, набирают популярность ИИ-ассистенты, которые, к примеру, могут преобразовывать индикаторы компрометации в правила детектирования. В будущем подобные сервисы станут неотъемлемой частью процесса Detection as Code.
Пока детекты в основном пишутся вручную, но уже появляются ИИ-решения, способные улучшать существующие правила и даже выявлять угрозы без их написания. К примеру, в Microsoft Sentinel для решения подобных задач используется механизм многоступенчатого обнаружения атак Fusion, а уже упомянутая Gurucul недавно представила Detection Engineering Agents.
Построение цепочек атак и динамической карты активов
Для автоматического построения цепочек атак современные ИБ-решения используют знания о тактиках/техниках злоумышленников и интегрированные индикаторы компрометации — такие возможности уже реализованы во многих продуктах. Также для этого необходима актуальная информация о топологии сети и защищаемых активах. Автономный SOC должен непрерывно получать данные об инфраструктуре с сенсоров и строить карту активов, динамически перестраивающуюся при любых изменениях. Кроме того, системе необходимы актуальные данные об уязвимостях, которые должны автоматически подтягиваться из VM-решений. Так, MaxPatrol SIEM в связке с MaxPatrol VM позволяют агрегировать информацию из разных источников в едином хранилище и строить запросы на языке PDQL.
Для построения динамической карты активов используются графовые структуры данных. Если мы укажем на графах критичные ресурсы, то сможем оценить, насколько сценарий атаки близок к реализации недопустимого события. Таким образом, автономный SOC будет приоритизировать задачи и предлагать релевантные сценарии реагирования в зависимости от уровня угрозы.
Автоматизация сбора контекста инцидента и расследования с помощью ИИ-агентов
Одно из ключевых направлений развития автопилотных SOC — активная интеграция мультиагентного ИИ, который позволяет распределять задачи между автономными агентами. Фактически мы наблюдаем тенденцию к переходу от AI-assisted- к AI-driven-центрам мониторинга.
Генеративный ИИ и агенты уже применяются для автоматического триажа алертов. Language Action Models (LAM) и специализированные reasoning-модели анализируют события ИБ, собирают контекст инцидентов, а затем сопоставляют новые алерты с историческими сведениями, данными TI, описаниями MITRE и связями между активами. Агенты также могут генерировать скрипты реагирования и выполнять отдельные действия: например, создавать задачи в системе Incident Management, блокировать учетные записи и сетевые порты или останавливать процессы ОС. При этом встраиваемые технологии рассуждения (reasoning) и дообучения (reinforcement learning или RAG-подход) позволяют агентам самообучаться, запоминать результаты ранее принятых решений и обновлять собственные правила и контекст.
Так, к примеру, работает MaxPatrol O2. ИИ-агент позволяет автоматически провести расследование инцидента и собрать весь необходимый контекст, а также установить последовательность шагов злоумышленника. Далее система выносит итоговый вердикт: вредоносна ли выявленная активность.
Генерация и выполнение сценариев реагирования
Традиционно в SOC используются статические плейбуки реагирования, которые вручную создаются вендором либо специалистами центров мониторинга. Однако сейчас этот подход уже не эффективен: в условиях роста инфраструктур, числа защищаемых активов и активных машинных учетных записей SOC требуется динамическая генерация и перестройка плейбуков реагирования. В автономных центрах мониторинга плейбуки должны динамически генерироваться и перестраиваться по мере развития конкретного инцидента.
До полноценной реализации подобных механизмов пока далеко, но уже существуют наработки, позволяющие автоматически проводить изоляцию зараженных устройств, удаление файлов, завершение процессов и блокировку учетных записей. При обнаружении инцидента система на основе анализа исторических данных и текущего контекста автоматически генерирует сценарии реагирования, которые включают в себя последовательность шагов для нейтрализации угрозы.
Вместе с активным управлением атаками появятся и новые метрики для оценки эффективности SOC. Например, Automated Response Rate — процент инцидентов/срабатываний, которые были обработаны без участия человека, или AI Decision Accuracy — доля принятых ИИ-моделями решений, которые признаны корректными. При этом какие-то из привычных показателей, вероятно, потеряют актуальность. К примеру, Queue Wait Time и Time-to-Qualify: поскольку автономный SOC возьмет на себя пласт работ от обнаружения до верификации сработки, считать время, потраченное человеком на анализ, будет нецелесообразно.
Принятие решений
Сейчас мы ждем от инструментов SOC подсказок, но решения принимаем сами: является ли сработка вредоносной, какой контекст нужно собрать, достаточно ли имеющихся данных, как реагировать на угрозу и т. д. В будущем многие из этих решений будут приниматься без участия человека: мы будем выполнять контролирующие функции, верифицировать действия системы и решать нестандартные кейсы.
К слову, автономные аналитики уже существуют: они могут выступать в роли первой и второй линии SOC, планировать расследования, выдвигать гипотезы, собирать контекст и формировать отчеты. Какие решения они будут принимать в беспилотном SOC будущего? Это зависит от встроенной экспертизы и уровня автоматизации в конкретном продукте.
Объяснимость и доверие к ИИ
ML-алгоритмы часто функционируют как черный ящик: нам сложно проследить логику сработки или повторить воспроизведение вывода модели. Это создает риски ошибок классификации, а также потери контроля над процессом расследования и реагирования. Поэтому в автономном SOC способность человека понять, почему модель сделала тот или иной вывод, будет критически важна.
Для решения таких задач применяются методы LIME, SHAP, Anchors и Counterfactual Explanations, которые визуализируют вклад отдельных признаков в итоговое решение модели и позволяют понять, как будет выглядеть результат при изменении входных параметров (мы, к примеру, внедрили в PT Sandbox метод SHAP). Эти подходы уже применяются в модулях поведенческого анализа: объяснение аномалий помогает аналитикам быстрее верифицировать срабатывания и снизить уровень недоверия к решениям системы.
Понятие «достоверный ИИ» будет включать не только прозрачность логики, но и защиту моделей от атак/манипуляций. Например, путем контроля целостности и происхождения данных, а также использования федеративного обучения моделей без раскрытия конфиденциальной информации. По сути, в AI-driven SOC появятся новые критерии эффективности: прозрачность, воспроизводимость и проверяемость решений системы. А степень доверия к ИИ при этом станет подтвержденным свойством архитектуры.
Когда ждать автономный SOC
На данный момент развитию беспилотных SOC препятствуют следующие факторы:
- Технологии. Генеративный ИИ неплохо справляется с рутинными задачами, но не тянет сложные кейсы: комплексные атаки, распределенные и сложные контексты инцидентов и др.
- Доверие и верификация. Автономность требует объяснимости и абсолютной уверенности в корректности действий системы.
- Регуляторика и ответственность. Вопросов будет много, к примеру «Кто ответит за ошибочную изоляцию критичного узла?».
- Экономический стимул. ROI от частичной автоматизации уже высок, но полная автономность требует значительно больших вложений в R&D. При этом крупные вендоры заинтересованы в поэтапном развитии возможностей, а не во «внезапном» прорыве. Кроме того, для эксплуатации AI-driven SOC потребуются специалисты с расширенным стеком знаний и навыков — от написания промптов до администрирования ML-моделей.
- Закрытые разработки. Большинство прорывных решений — это закрытые проприетарные продукты, что заметно ограничивает скорость распространения инноваций.
Продукты с приставкой «автономный» уже существуют, но пока это не полноценные «беспилотники». Мы ожидаем, что первое реальное внедрение произойдет не раньше 2030-го, а массового применения автономных SOC стоит ждать только около 2035 г.
