Кибербезопасность 2.0: зачем бизнесу внедрять LLM в процессы ИБ

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

Что попадает к аналитику SOC на первичный разбор

На входе у аналитика SOC первой линии не инциденты, а поток из десятков алертов от SIEM или EDR. Каждый из них содержит несколько полей: IP источника, хэш файла, имя пользователя. Задача аналитика за 10–15 минут понять, что это — реальная угроза или информационный «шум».

Одиночный алерт может оказаться легитимным DNS-запросом пользователя, но в связке с обращением к нестандартному порту это уже выглядит как потенциальное C2-соединение.

Рутина складывается из одних и тех же действий. Аналитик обращается к Active Directory, чтобы выяснить, кто этот пользователь, админ ли он, в каком отделе, активна ли его учетная запись. Затем ведется проверка IP-адреса в VirusTotal или коммерческих Threat Intelligence-фидах, и хэша — в песочнице или репутационных базах. А также сравнивает события за последние пять-десять минут с той же машины или тем же аккаунтом.

Этим список контрольных процедур не исчерпывается. Еще ведется поиск информации по запущенному процессу, запланированному заданию, внутренним каналам о плановых работах, просмотр действий СЗИ над объектами и соединениями. И в заключении фиксация вердикта в тикет-системе с обязательным полем «Обоснование». Все эти операции «съедают» до 80% рабочего времени аналитика L-1.

Где LLM приносит наибольшую пользу

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

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

Просто подключить LLM к SIEM или запустить чат-бота будет недостаточно. Модель, у которой нет доступа к API внутренних систем и внешним сервисам, видит только строки логов и не может опросить EDR-агента или проверить доступность хоста из DMZ.

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

Алгоритм его работы предполагает, что агент получает первичный промпт, понимает, чего не хватает, и генерирует SQL-запросы к SIEM или вызов к Threat Intelligence. Затем обрабатывает ответ и только после этого выдает обоснованные рекомендации. Иначе попытка применить LLM в SOC может превратиться в генератор убедительного «шума», который завалит аналитиков десятками ложных срабатываний.

Как работает агент в Agentic SOC

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

Как это работает в Innostage на примере продукта Innostage TDIR: агент исторических инцидентов смотрит, как закрывались похожие сработки раньше. Агент IOC через MCP-инструменты массово опрашивает VirusTotal, Kaspersky OpenTIP, AbuseIPDB, ThreatFox и CyberThreatTech. Агент анализа PowerShell задействует ML-классификаторы для разбора подозрительных команд и генерации запросов к SIEM, чтобы получить окрестности алерта.

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

Но качество вердикта зависит не только от механики. Для корректной работы агенту нужен оперативный доступ к истории инцидентов по конкретному активу за последние 90 дней, уровням критичности хоста и данных, актуальным правилам SIEM и регламентам SOC. Данные EDR дают поведенческую картину, SIEM — корреляцию, Threat Intelligence — внешний контекст.

Важны и принятые исключения. Например, если администратор каждую ночь запускает скрипт резервного копирования с известными параметрами, агент должен знать, что это норма. Чем полнее контекст, тем меньше ложных вердиктов.

Типичные ошибки моделей и граница их автономности

Ошибки первого типа — когда модель классифицирует легитимный скрипт как вредоносный. В практике Innostage был случай, когда агент пометил PowerShell-скрипт инвентаризации как подозрительный из-за Base64 в аргументах и рекомендовал изоляцию хоста. На деле это был плановый скрипт.

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

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

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

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

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

Как оценить эффект

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

Первый — среднее время триажа одного алерта. В проектах, которые мы сопровождали, оно в среднем снижалось с 20 минут до 5–7 минут. Сокращение времени обработки сигналов позволяет аналитикам SOC обрабатывать больший объем алертов, экономя время, которое ранее было затрачено на рутинные операции, а теперь может быть направлено на более сложные стратегические задачи.

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

Четвертый параметр, о котором часто забывают, связан с текучкой аналитиков первой линии. Монотонный триаж «выжигает» людей в среднем за 8–12 месяцев, и снятие рутины напрямую влияет на удержание команды. По данным исследования UK Cyber Defence, 48% аналитиков рассматривают уход в среднем уже через 11 месяцев работы.

Пятый критерий — четкое соответствие регуляторным срокам. Для объектов КИИ по 187-ФЗ на уведомление о значимом инциденте отведены жесткие сроки, и сокращение времени обнаружения с часов до минут снижает риск их нарушения.

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