Локальная LLM для классификации SIEM-алертов: что ускорилось, что нельзя делегировать

Весной этого года мы взялись за задачу, которая звучала заманчиво: подключить локальную LLM к потоку SIEM-алертов и посмотреть, справится ли она с первичной классификацией инцидентов. Не заменить аналитика - заменить ту часть его работы, которая сводится к «прочитай алерт, реши, это реальная угроза или шум». К сентябрю у нас есть несколько месяцев эксплуатации и довольно конкретные выводы.

Откуда взялась идея

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

Попробовать LLM на первом слое фильтрации предложили после того, как посмотрели на опыт с агентом в ITSM. Там агент берёт на себя рутину первой линии - логика похожая, только контекст другой.

Что и как запустили

Локальный инференс на GPU-сервере, модель на базе Mistral с дообучением на корпусе наших алертов и разметке аналитиков за предыдущие полгода. Облачные варианты не рассматривали - данные SIEM уходить за периметр не должны, это не обсуждается.

SIEM в проекте - MaxPatrol SIEM. Интеграция через вебхук: новый алерт -> оркестратор -> LLM -> классификация + короткое обоснование -> приоритетная очередь для аналитика.

Модель выдаёт три поля: тип (попытка несанкционированного доступа / аномалия поведения / технический шум / требует уточнения), приоритет (P1-P3) и короткое обоснование - одно-два предложения, почему она так решила. Без обоснования классификация была бы чёрным ящиком, а аналитику нужно понимать, с чем он работает.

Что реально ускорилось

Разгрузка на входе. Примерно 55-60% алертов - технический шум: перезапуски сервисов по расписанию, легитимные скрипты резервного копирования, ротация токенов. LLM распознаёт их надёжно и отправляет в нижний приоритет. Аналитик не тратит на них время утром.

Предобработка контекста. Для каждого алерта модель выдёргивает из сырого лога ключевые атрибуты: IP-источник, учётка, время, тип события, корреляция с предыдущими событиями этого же хоста. Раньше это делал аналитик руками. Сейчас он открывает карточку инцидента, где это уже собрано.

Сортировка очереди. Раньше очередь была хронологической: что пришло позже, то сверху. Теперь сверху то, что модель оценила как высокоприоритетное. Несколько раз это сработало правильно - реальные попытки подбора паролей оказывались в топе, а не терялись под слоем шума.

Что нельзя делегировать

Это важнее, чем то, что ускорилось.

Принятие решений о реагировании. Модель классифицирует - аналитик решает, что делать. Блокировать учётку, изолировать хост, эскалировать - это не автоматика. Слишком много контекста, который не попадает в лог: знание того, что этот IP - тестовый сервер девопсов, что эта учётка сейчас у аудитора снаружи, что именно сегодня ночью было плановое обслуживание.

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

Решения с юридическими последствиями. Если инцидент подпадает под уведомление регулятора - сроки, форма, полнота описания. Здесь ошибка стоит дорого, и перепроверять за моделью всё равно придётся.

Где возникли неожиданные риски

Два момента, которые мы не предусмотрели в полной мере.

Уверенность без оснований. Несколько раз модель выдавала классификацию «технический шум» с коротким обоснованием, которое звучало убедительно, но было неверным. Аналитик, особенно уставший или перегруженный, может не перепроверить то, что модель подала как очевидное. Это дороже, чем если бы классификации вообще не было - тогда аналитик смотрит сам. Решение: ввели обязательный ручной просмотр P1-алертов вне зависимости от оценки модели.

Дрейф качества. Первые две недели модель работала хорошо, потому что мы обучали её на недавних данных. Потом паттерны немного сдвинулись - появились новые легитимные процессы в инфраструктуре клиента, и процент ложных отрицательных вырос. Без мониторинга качества классификации это заметили бы поздно. Сейчас аналитики еженедельно размечают выборку из 50 алертов, с которыми не согласны с оценкой модели, - это и обратная связь, и метрика качества.

Где сейчас

Схема работает в рабочем режиме. Утренний разбор стал заметно короче - по ощущениям аналитиков, часть первичной сортировки действительно ушла. Но ни на каком этапе это не «LLM делает IR вместо нас». Это инструмент предобработки, который убирает шум и структурирует контекст, - аналитик по-прежнему принимает все решения.

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