Самописный AI SOC команды Medici Lab обслуживал 150 хостов на двух ядрах CPU, а языковая модель на 9 млрд параметров давала 96–97% полезных ответов на узкой задаче триажа. Это не история о том, что ИИ заменил аналитика SOC: архитектура, напротив, показывает, сколько инженерной работы нужно сделать до того, как модель вообще можно подпускать к безопасности.
Об устройстве системы и её внутренних замерах рассказывает Habr / Карьера со слов Александра Кельчина, CTO и CISO Medici Lab. Команда сначала проверила более амбициозный сценарий: поручить модели разбор событий второй линии SOC — собрать контекст, связать сигналы и решить, является ли ситуация инцидентом. Даже в удобных условиях верными оказались около 60% решений. Для автоматического реагирования это плохой результат: остальные 40% превращаются либо в ложные тревоги, либо в пропущенные атаки.
Меньше контекста — меньше иллюзий
Такой результат не выглядит аномалией. В статье приводится ориентир Microsoft ExCyTIn-Bench: в этом бенчмарке LLM-агенты расследуют угрозы по данным Microsoft Sentinel и связанных сервисов; лучшая модель получила 0,606 по используемой там метрике. Сравнивать показатель напрямую с внутренними 60% нельзя — различаются данные и задания, — но общий вывод совпадает: отдать второй уровень SOC модели целиком пока нельзя. Причём проблема начинается ещё до LLM. Корреляционные правила в SOC нередко годами производят шум, а на их пересмотр не хватает отдельной команды и бюджета. Модель, которой скормили такой поток, не исправляет качество входа магическим промптом.
Вместо центрального сервера, куда свозят всё сырое телеметрическое богатство, Medici Lab перенесла первичную обработку на конечные устройства. Агент на C и C++ весом около 60 КБ применяет локальные правила и передаёт коллектору только события, прошедшие фильтрацию. По словам Кельчина, этой схемы хватало для 150 хостов при двух ядрах CPU. Важнее экономии ресурсов другое следствие: коллектор получает не бесконечный нормализованный лог, а компактный сигнал известного формата. В обычной централизованной SIEM попытка передать модели полный поток быстро упирается в цену контекстного окна, задержки и потерю точности на длинных входах.
После локального правила на обработку приходит примерно 200 токенов контекста. Диспетчер знает, какое именно правило сработало, и направляет событие в модель, дообученную на соответствующей группе правил. Базовая Qwen на 9 млрд параметров без дообучения уже показывала приемлемый результат на простой постановке; на сервере она разбирала около трёх событий в секунду. Ключевой прирост дали не увеличение модели до 27 млрд параметров и не обращение к облачным фронтирным моделям, а специализация. После дообучения, по внутренним замерам команды, качество выросло до 96–97% хороших ответов.
Не автопилот, а конвейер для аналитика
Эти 96–97% не означают, что маленькая LLM научилась выполнять всю работу второй линии SOC. Она отвечает на существенно более узкий вопрос: похоже ли конкретное срабатывание конкретного правила на реальную проблему при заранее ограниченном контексте. Это полезное разграничение для команд, которые планируют AI SOC. Самый реалистичный путь внедрения — не просить модель расследовать всё подряд, а сделать её проверяющим звеном: подготовить стабильный вход, разложить правила на группы, измерить ошибки и оставить аналитика последней инстанцией. На выходе специалист получает не поток сырых алертов, а карточки с предварительным вердиктом и объяснением.
У архитектуры есть и неприятные компромиссы. Если хост недоступен, локальная обработка на нём не работает, хотя центральный сборщик в такой ситуации тоже теряет источник данных. Поэтому отсутствие телеметрии должно само становиться событием. Серьёзнее риск реверс-инжиниринга: правила находятся на машине, которой потенциально уже управляет атакующий. Шифрование и обфускация могут усложнить анализ, но не решают фундаментальную проблему — заказчику нужно менять правила, а скрыть их от администратора или злоумышленника на скомпрометированном узле невозможно.
Для разработчиков SIEM и руководителей ИБ здесь есть практический урок: эффективность AI SOC определяется не размером модели, а границами задачи и качеством маршрутизации событий. Небольшая команда может снизить требования к инфраструктуре и не покупать отдельную GPU, но ей всё равно придётся доказать заказчику надёжность, поддержку и управляемость решения. Именно это, по оценке Кельчина, осложняет продажи: крупный бизнес неохотно становится зависимым от небольшой команды, а малый бизнес часто выбирает знакомый управляемый SIEM. Следующий вопрос для рынка — кто сумеет превратить узкие, проверяемые AI-модули в продукт, которому службы безопасности доверят не только триаж, но и часть реакции.
