Разработка SIEM-системы с AI-детекцией угроз

Почему правила не успевают за атаками: где ломается SIEM

Классическая SIEM-система держится на правилах корреляции: инженер описывает условие — «N неудачных входов за окно T с одного адреса», — и правило срабатывает при совпадении. Модель прозрачная и предсказуемая, пока инфраструктура стабильна, а поток событий однороден. Проблема в том, что оба условия перестают выполняться почти сразу после запуска.

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

Вторая сторона — ложные срабатывания. Чем шире правило перекрывает поведение, тем больше легитимных действий оно задевает: плановые сканирования, миграции, работу автоматизации. Аналитик тонет в очереди однотипных алертов, привыкает закрывать их не глядя — и настоящее срабатывание теряется среди шума. Формально детекция есть, фактически её нет.

Именно здесь нужна AI SIEM разработка: модель учится на нормальном поведении конкретной инфраструктуры и оценивает отклонение, а не совпадение с шаблоном. Правила остаются для известных техник, но перестают быть единственным слоем. Разбираем, как это закрывается.

Что даёт AI-детекция: измеримый эффект для SOC

Ложные срабатывания падают в разы

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

Время реакции SOC сокращается

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

Обнаружение аномалий вместо известных шаблонов

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

Уходит класс отказов «пропустили, потому что не настроили правило»

Ручное сопровождение сотен правил означает, что любое изменение инфраструктуры оставляет слепые зоны — новый сервис, новый сегмент, новая учётная запись. Профиль поведения строится автоматически по фактическому трафику, поэтому покрытие не зависит от того, успел ли инженер дописать правило. Слепые зоны перестают накапливаться между релизами.

Расследование опирается на данные, а не на память

Каждое срабатывание сохраняет срез поведения вокруг события: предшествующие действия, обращения к ресурсам, связи между узлами. Разбор инцидента идёт по восстановленной хронологии, а не по разрозненным выгрузкам из разных систем. Это сокращает время на подтверждение инцидента и делает выводы воспроизводимыми при повторной проверке.

Варианты построения: от собственной разработки до гибрида

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

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

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

Этапы внедрения AI-детекции в контур мониторинга

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

Дальше выстраиваем схему потоков и только потом подключаем детекцию — так результат воспроизводим, а не случаен.

1. Аудит источников. Собираем перечень систем, форматов и частоты событий, отмечаем пробелы в покрытии и источники, которые пишут нестабильно.
2. Схема потоков. Проектируем маршрут событий от источника до хранилища: нормализация, обогащение контекстом, буферизация при пиковых нагрузках и разрывах.
3. Настройка моделей. Обучаем детекторы на исторических данных контура, задаём пороги чувствительности под профиль инфраструктуры, а не по усреднённым шаблонам.
4. Проверка детекций. Прогоняем модели на размеченных инцидентах прошлого: смотрим, сколько реальных атак поймано и сколько ложных срабатываний приходится на смену.
5. Тюнинг правил. Снижаем шум точечно — уточняем условия, добавляем исключения для легитимных сценариев, чтобы аналитик не тонул в очереди.
6. Передача в эксплуатацию. Оформляем регламенты реагирования, обучаем смену, фиксируем метрики качества детекции для последующего контроля.

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

Артефакты на выходе: конфигурации, схемы, регламенты

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

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

Комплект передаётся в вашем репозитории и в вашей инфраструктуре — без привязки к нам. Опишите задачу, и мы вернёмся с оценкой и планом: какие источники подключаем первыми и какие детекции закрывают ваши ключевые сценарии.

Кейс: сокращение ложных срабатываний втрое за один цикл

Заказчик — оператор корпоративной сети с распределённым периметром. До проекта аналитики разбирали порядка 400 предупреждений в сутки, из которых подтверждались единицы: остальное — легитимные административные действия, сканеры уязвимостей по расписанию и обновления внутренних сервисов. Очередь разбора не успевала за потоком, часть событий закрывалась «по сроку», а не по факту проверки.

Что изменили

Собрали поведенческие профили по каждому узлу и учётной записи: типовые окна активности, наборы обращений к внутренним сервисам, объёмы выгрузок. Модель оценивает отклонение от личной нормы, а не от общей сигнатуры, поэтому «необычное для этого узла» перестало теряться среди «обычного для всех».

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

Метрики до и после

MITRE ATT&CK использовали как основу для разметки техник — это дало общий язык между моделью, правилами корреляции и аналитиками при разборе инцидента.

Отдельно настроили обратную связь: каждое закрытое предупреждение возвращается в разметку, и модель дообучается на реальных решениях смены. Через несколько циклов доля ложных срабатываний стабилизировалась на новом уровне, а не откатилась назад.

Чем поведенческая аналитика отличается от корреляции правил

Корреляция правил — это детерминированный слой: аналитик описывает условие вида «событие A, затем B в течение N минут с одного узла», и система ищет точное совпадение. Плюс — предсказуемость и объяснимость: по каждому срабатыванию видно, какое правило и какая цепочка событий его вызвали, ложное срабатывание разбирается за минуты. Минус — правило ловит только то, что в него заложили: любое отклонение в порядке событий, тайминге или источнике логов обходит детект, а число правил растёт быстрее, чем покрытие.

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

Отличия сводятся к трём осям. Что ищем: точное совпадение шаблона против статистического отклонения. Что нужно для запуска: описанное правило против накопленной истории по каждой сущности. Чем платим за ошибку: пропуском при неизвестной тактике против шума при смене нормального поведения.

Выбор метода — не «или-или». Корреляция правил даёт точные, легко проверяемые срабатывания по известным тактикам и служит опорой для разбора. Поведенческая аналитика закрывает слепую зону — неизвестные тактики и медленные отклонения, которые по одному событию не видны. На практике их комбинируют: аномалия от модели не идёт напрямую в очередь инцидентов, а поднимает приоритет связанных событий, которые дальше проверяются правилами и обогащаются контекстом. Так снижается и шум, и число пропусков одновременно.

Отсюда критерий: если у вас уже есть зрелый набор правил и вы упираетесь в пропуски по нетипичному поведению — добавляйте поведенческий слой поверх, не заменяя корреляцию. Если правил почти нет, начинать с модели бессмысленно: нечему давать контекст, и поток срабатываний будет нечем разбирать.

Частые технические сомнения перед стартом работ

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

У нас накоплено мало исторических данных — модели вообще обучатся?

Обучение строится в два слоя. Базовый слой — правила и статистические профили поведения, они работают на коротком окне наблюдений и дают эффект с первых недель. Второй слой — модели, которые уточняются по мере накопления событий: чем больше проходит трафика, тем точнее разделяются норма и аномалия. Если истории мало, стартуем с базового слоя и дообучаем модель на живом потоке, не дожидаясь «идеального» датасета.

Придётся ли закупать новое оборудование под нагрузку?

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

Если остались вопросы по вашему конкретному контуру — опишите задачу, вернёмся с оценкой и планом.

Обсудим вашу задачу и вернёмся с планом

Чтобы вернуться с оценкой и планом, а не с общими словами, нам нужен минимум входных данных от вас. Чем конкретнее вводные, тем точнее оценка сроков и состава работ по AI SIEM разработке — без «уточним по ходу».

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

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