SIEM на двух ядрах для 150 хостов и 9B-модель на триаже: как устроен самописный AI SOC

Представьте SOC, где языковая модель разбирает каждое сработавшее правило. В идеальных условиях она верно обрабатывает около 60% событий второй линии. Оставшиеся 40% — ложные срабатывания и пропуски, и автоматически реагировать на такой выход нельзя. Команда Александра Кельчина, CTO и CISO Medici Lab, пришла к этой цифре на собственных экспериментах. Потом они перестроили SIEM так, что модель на 9 миллиардов параметров стала давать 96–97% хороших ответов, а вся система держала 150 хостов на двух ядрах CPU.

Мы с Александром разбирали эту архитектуру в часовом разговоре; полная запись есть на YouTube, аудиоверсия — на всех подкаст-площадках. В статье я собрал инженерную часть: как устроена обработка, где схема ломается и что из неё можно взять себе, даже если свой SIEM вы писать не собираетесь. Цифры ниже — из рассказа Александра и внутренних замеров его команды, методику они не публиковали. Где есть публичный ориентир, я его дам ниже.

Откуда 60% и почему это плохая новость для автоматизации

На второй линии SOC аналитик расследует: собирает контекст, связывает события, решает, инцидент это или нет, и реагирует. Александр проверял, как с этим справляется ИИ, при максимально удобных для модели условиях, с автоматизированным реагированием. Средняя доля правильно обработанных событий получилась около 60%.

Это хороший процент, но всё равно отвратительный. Шестьдесят правильных и сорок неправильных: либо ложноположительные, либо ложноотрицательные. А если полностью отдать L2 автоматическое реагирование — ну невозможно.

Публичный ориентир того же порядка дал Microsoft. В бенчмарке ExCyTIn-Bench LLM-агенты расследуют угрозы по 57 таблицам логов Microsoft Sentinel и смежных сервисов, вопросов там 7 542. Лучшая модель на момент публикации набрала награду 0,606. Метрики разные, задачи разные, но вывод совпадает: целиком вторую линию модель пока не закрывает.

Ошибается при этом не только модель. Правила корреляции в типичном SOC годами дают ложные срабатывания, и их никто не исправляет: поток событий огромный, а держать отдельного человека под переписывание правил бизнес не хочет. Если поставить ИИ читать выход таких правил, он унаследует весь их шум. У команды Александра качество входа для модели определил собственный SIEM, и с него стоит начать.

Классическая схема: всё сырьё на один сервер

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

Для AI SOC у этой схемы есть ещё одна проблема. Если нормализованный поток отправить в LLM, вы упираетесь в контекстное окно. Расширение окна стоит кратно дороже, а на длинном контексте качество ответа на конкретный вопрос падает. Александр проверял модели на 27B и пробовал фронтирные по подписке на тестовом стенде. Метрики качества росли, но скорость падала очень сильно, а на длинном контексте выигрыш размывался.

Обработка на агенте: 60 КБ кода на C и C++

Команда Александра перенесла основную обработку на конечные хосты. Агент на каждом хосте применяет правила локально и отправляет в коллектор только очищенные события. Ориентиром Александр назвал концепцию Microsoft Sentinel, где SIEM наполовину становится EDR.

У нас на двух ядрах CPU спокойно держалось 150 хостов. Моя гордость в том, что агент весил 60 килобайт.

Агент написан на C и C++, правила собственные. Отсюда главное следствие для AI SOC: событиям не нужна нормализация. Формат задаёт свой движок правил, поэтому модель на коллекторе всегда видит короткий и предсказуемый вход. Упрощённо поток выглядит так:

хост: события ОС → агент (60 КБ, свои правила) → сработало правило X
        │
        ▼  только очищенные события
коллектор: диспетчер смотрит, какое правило сработало
        │
        ▼  ~200 токенов контекста
модель, дообученная на группе правил X → вердикт + объяснение
        │
        ▼
аналитик SOC читает готовые проверенные карточки

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

Маленькая модель на узкой задаче

Сначала команда взяла Qwen на 9B параметров без дообучения и измерила базовую линию. На простой постановке — «вот правило, оно сработало, вот минимальный контекст» — модель работала неожиданно хорошо. Контекст при этом был около 200 токенов. По словам Александра, на их сервере модель успевала разбирать примерно три события в секунду, а события к этому моменту уже прошли фильтрацию на хостах.

Скачок дало дообучение. Модели дообучили под конкретные группы правил, а перед ними поставили диспетчер: он видит, какое правило сработало, и отправляет событие в соответствующую модель. После этого доля хороших ответов, по внутренним замерам команды, дошла до 96–97%. Аналитик на выходе получает уже разобранные и проверенные события вместо сырого потока.

Сравнивать эти 96–97% с 60% из начала статьи напрямую нельзя. Там модель делала работу второй линии целиком, здесь — проверяет одно сработавшее правило с крошечным контекстом. Ровно в этом и состоит инженерный ход: уменьшить задачу до размера, на котором маленькая модель надёжна.

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

Три возражения к схеме

Александр рассказал, что за эту архитектуру ему доставалось в спорах. Возражения разумные, разберу их по очереди.

Хост отвалился — обработки нет. Ответ Александра: в классическом SIEM при потере хоста вы точно так же остаётесь без сборщика. Агент не делает эту проблему хуже. Тишина от хоста в любой схеме должна сама по себе становиться событием для коллектора.

Агент легко реверсить. Это самое серьёзное возражение, и Александр его признаёт: «когда хакер знает, какие у тебя правила работают в системе, ему легче их обходить». В 60 килобайтах правила видны почти сразу. Команда долго думала над антиреверсом и пробовала шифровать правила. Я предлагал Rust с обфускацией, но это только поднимает стоимость анализа. Правила всё равно лежат на хосте, которым атакующий уже может управлять.

Заказчикам нужно менять правила. Обычно это YAML, и спрятать его от того, кто сидит на хосте, не получится. Здесь компромисс между управляемостью и скрытностью неизбежен.

Почему такое трудно продать

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

Бизнес боится брать то, что он не сможет контролировать. Это всегда база, и это абсолютно логично. Он вникнет и поймёт, что становится заложником команды.

Изначально продукт задумывался для малого и среднего бизнеса, который не может себе позволить тяжёлый SIEM. Позже Александр пришёл к другому выводу: малому бизнесу сейчас не до ИБ, он хочет выжить. А для большей части такого бизнеса, управляемый SIEM который давно известен и понятен — гораздо важнее чем рискованная гипотетическая прибыль.

Что взять себе, даже без своего SIEM

1. Измерьте качество модели отдельно по каждому правилу. Средняя точность по всему потоку прячет правила, на которых модель стабильно ошибается.

2. Режьте контекст до сработавшего правила. 200 токенов с нужными полями работают лучше, чем «вот весь лог за час».

3. Маршрутизируйте по правилам. Несколько маленьких дообученных моделей под группы правил дешевле и предсказуемее одной большой.

4. Почистите корреляции до того, как ставить ИИ. Модель не исправит правило, которое годами шумит.

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

6. Если переносите логику на хосты, считайте её публичной. Правила в агенте — это документация для атакующего, планируйте детекты с учётом того, что их прочитают.

У меня к вам два вопроса. Ставили ли вы LLM на триаж в своём SOC, и какую долю верных вердиктов она давала на ваших правилах? И где, по-вашему, граница, после которой модели можно отдать автоматическое реагирование? Если принесёте цифры, разберу их в комментариях.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.