Detection Drift: как переносить правила между SIEM и не потерять логику обнаружения

На связи Владимир Шнейдмюллер, аналитик-исследователь угроз кибербезопасности R-Vision.

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

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

Для этой задачи мы сделали Detection Drift. Инструмент принимает правила в форматах Sigma, Splunk SPL, MaxPatrol SIEM, Microsoft KQL и других распространенных систем, добавляет доступный контекст и формирует правило .ro для R-Vision SIEM с УМС 2.0. Затем результат проходит автоматические проверки, а пользователь получает само правило и пояснения к конвертации.

На выходе получается подготовленный и автоматически проверенное правило. Его все равно должен принять аналитик, сопоставить с исходной логикой, проверить поля на реальных событиях и протестировать правило в  SIEM.

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

Почему обычного переводчика недостаточно

У переноса правила есть как минимум две независимые задачи.

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

Например, условие «событие A произошло, а событие B не появилось в течение десяти минут» нельзя без потери смысла заменить обычным отрицанием внутри одного события или группировкой с count:1. В целевой системе для этого нужна конструкция, которая действительно умеет ждать второе событие и учитывать его отсутствие.

Вторая задача, это понять, какими полями в SIEM выражается эта логика. Условные Image, process.name и dst_process_name могут описывать один и тот же объект в разных системах, но при этом простым сопоставлением таксономии не обойтись. Нужно знать, какие поля создает нормализация конкретного источника и какие значения в них приходят.

Если совсем коротко:

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

Что получает команда

Detection Drift объединяет основные этапы подготовки правила в одну задачу. Исходное правило, дополнительный контекст, сгенерированный вариант .ro, пояснения и результаты проверок остаются связаны между собой. Благодаря этому конвертацию можно воспроизвести, разобрать вместе с коллегами и при необходимости повторить с уточненными входными данными.

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

При этом граница ответственности остается прозрачной:

Detection Drift автоматизирует первый трудоемкий этап, но не отменяет аналитическую работу.

Как выглядит работа с инструментом

Интерфейс разделен на две части. Слева находятся исходные данные и настройки, справа — состояние задачи, получившееся .ro-правило и замечания.

На скриншоте загружено YAML-правило о разведке с помощью driverquery.exe. В результате видны два возможных источника событий запуска процесса — Windows Security 4688 и Sysmon 1, а исполняемая часть использует CIMv2-поля процесса и родительского процесса. Внешне все выглядит убедительно, но именно здесь начинается ручная проверка: поступают ли оба типа событий в конкретной инфраструктуре, одинаково ли они нормализуются и сохранились ли исходные исключения для легитимных запусков driverquery.exe.

Рабочий сценарий выглядит так.

1. Подключаем собственную базу примеров

Публичная поставка не содержит рабочих правил корреляции, нормализаций, таблиц, активных списков или контента заказчиков. Владелец установки загружает собственный пакет экспертизы R-Vision SIEM .roc через интерфейс или API.

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

База хранится в рабочем каталоге data/knowledge/. Успешный новый импорт атомарно заменяет активную базу, а предыдущая версия сохраняется для возможного отката.

2. Выбираем модель

Для реальной конвертации нужен профиль модели. Поддерживаются OAuth-сессия через OpenCode, облачный API с токеном и локальная модель с OpenAI-совместимым интерфейсом.

3. Загружаем исходное правило

В интерфейсе можно указать Sigma, Splunk SPL, PT MaxPatrol SIEM .co, Microsoft KQL, Elastic, QRadar, ArcSight, Chronicle YARA-L, YARA или другой текстовый формат. Для сложных или редких конструкций полезно явно указать исходную платформу и описать спорную семантику в заметках.

4. Добавляем контекст

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

Отдельное поле принимает нормализованное событие R-Vision. Это один из самых приоритетных источников контекста, потому что показывает, какие поля реально присутствуют после нормализации.

Переключатель дата-модели добавляет справочник допустимых полей и перечислимых значений CIMv2. Он полезен как список разрешенных сущностей.

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

5. Запускаем конвертацию и читаем результат

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

При успешном завершении интерфейс показывает .ro, число итераций и замечания конвертации. Правило можно скопировать или скачать.

Веб-интерфейс здесь не является единственной точкой входа. Тот же сценарий доступен через API: POST /api/conversions создает задачу, а отдельные GET-запросы возвращают состояние, результат, пояснения и трассировку. Это позволяет встроить конвертацию во внутренний процесс команды. Встроенного пакетного режима при этом нет. Одна задача принимает одно основное правило.

Почему хороший контекст важнее длинного запроса

Инструмент работает с несколькими видами материалов, и у каждого своя роль.

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

Что происходит под капотом

На верхнем уровне Detection Drift — однопроцессное приложение на FastAPI со статическим веб-интерфейсом и файловым хранилищем рабочих данных.

Полный путь задачи выглядит так.

1. Web UI передает данные серверной части. В запрос входят исходный файл, выбранный профиль модели, подсказка формата, нормализованное событие, заметки, дополнительные файлы и флаг использования дата-модели.

2. Conversion Service создает рабочую папку. В data/jobs/<job_id>/ сохраняются входные материалы и последующие файлы задачи. Это позволяет восстановить, что именно участвовало в конкретном запуске.

3. Модуль подбора примеров ищет похожие .ro. Текущая реализация использует лексическое совпадение: учитывает термины из исходных материалов, идентификаторы техник MITRE ATT&CK и слова в путях файлов. Найденные документы остаются справочными примерами.

4. Дата-модель предоставляет допустимые поля и значения. Из нее формируется ограниченный фрагмент, который помещается в задание модели.

5. Модуль формирования задания объединяет инструкции и факты. В него входят версионируемые требования к конвертации, стиль .ro, каталог целевых механизмов, исходное правило, пользовательский контекст, дата-модель и выбранные примеры. Для моделей с небольшим контекстным окном предусмотрен сокращенный вариант задания.

6. AgentRunner обращается к модели. В зависимости от профиля это OpenCode либо прямой запрос к OpenAI-совместимому API.

7. Validator извлекает .ro и выполняет статические проверки. Если остаются ошибки, они добавляются в следующую итерацию вместе с предыдущим вариантом правила.

8. Результат сохраняется. Пользователь получает правило и пояснения, а в рабочей папке остается техническая трассировка обработки

У данной схемы строгий формат ответа. Модель должна вернуть отдельно полное .ro-правило и отдельно краткие замечания с допущениями. Это упрощает извлечение результата и снижает риск того, что служебный текст смешается с кодом правила.

Что именно проверяет валидатор

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

Текущий валидатор умеет:

• разобрать результат как YAML с конструкциями, используемыми в .ro;

• проверить наличие обязательных разделов и атрибутов;

• убедиться, что указаны model: cimv2 и type: correlation_rule;

• сопоставить встречающиеся поля с дата-моделью, полями из переданных материалов и собственной базой примеров;

• найти несколько известных проблемных конструкций в VRL;

• в отдельных случаях заметить, что логика отсутствующего последующего события потеряла absent-соединение или временное окно.

Если найдена ошибка уровня error, конвертер может отправить правило на следующую итерацию. Число попыток задается профилем модели. Предупреждения уровня warning не обязательно блокируют успешный статус.

При этом валидатор не компилирует и не исполняет VRL, не запускает блок tests в движке R-Vision SIEM и не доказывает семантическую эквивалентность исходного и целевого правила.

Поэтому статус succeeded означает: «результат прошел предусмотренные автоматические проверки без блокирующих ошибок». Он не означает что правило готово к промышленной эксплуатации.

Что обязательно проверить вручную

Перед импортом результата в рабочую среду стоит пройтись как минимум по следующему списку.

1. Логика исходника. Сохранились ли обязательные условия, альтернативные ветви, исключения и регистронезависимые сравнения?

2. Временная механика. Не превратились ли последовательность, отсутствие события, порог или требование уникальности в более простое, но другое условие?

3. Происхождение полей. Есть ли каждое поле в реальной нормализации этого источника? Что происходит при null и при другом типе значения?

4. Результат корреляции. Передает ли on_correlate полезный аналитический контекст, а не только формально заполняет структуру?

5. Позитивные и негативные примеры. Срабатывает ли правило на репрезентативном событии и не срабатывает ли на минимально отличающемся легитимном сценарии?

6. Ложные срабатывания. Нужны ли дополнительные исключения, корректировка порога или временного окна под конкретную инфраструктуру?

7. Проверка в SIEM. Загружается ли правило без ошибок в R-Vision SIEM?

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

Развертывание и чувствительные данные

Для быстрого запуска нужны Docker Engine и Docker Compose. Репозиторий опубликован на GitVerse:

git clone https://gitverse.ru/rvision/detection-drift.git
cd detection-drift
bash scripts/start.sh

Скрипт создает .env из шаблона, собирает образ и запускает сервис. По умолчанию интерфейс доступен только локально:

http://127.0.0.1:8080

Публиковать сервис в недоверенной сети не следует.

Отдельного внимания требуют данные на диске. В data/jobs/ могут сохраняться исходные правила, контекст, задания модели, сырые ответы и результаты. В data/knowledge/ находится импортированный набор .ro, а пользовательские профили моделей могут содержать токены. Для этих каталогов нужны ограниченные права, шифрованные резервные копии и понятный срок хранения: автоматической политики удаления в сервисе сейчас нет.

Импорт .roc тоже не выполняется вслепую. Сервис проверяет ZIP-сигнатуру, небезопасные пути, символические ссылки, зашифрованные записи, кодировку и ограничения на число и размер файлов. Новая база становится активной только после полной успешной проверки архива.

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

Где инструмент полезен, а где нет

Detection Drift хорошо подходит, когда нужно:

• перенести существующий набор правил в R-Vision SIEM;

• быстро подготовить первый вариант правила из Sigma или языка другой SIEM;

• привести черновики разных аналитиков к более единообразной структуре;

• использовать собственные правила .ro как приватную справочную базу;

• сохранить материалы конвертации для последующей командной проверки.

Важно отметить, что инструмент не исключает этап адаптации правила под конкретную инфраструктуру. Исследование источников событий, контроль нормализации, настройка ложных срабатываний и финальное тестирование в SIEM остаются за специалистом. Кроме того, Detection Drift не может компенсировать недостаток телеметрии: если нужный признак не журналируется или не нормализуется, языковая модель не сделает его доступным только за счет сопоставления полей.

Практические выводы

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

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

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

Исходный код, инструкция по запуску и эксплуатационная документация опубликованы в репозитории Detection Drift на GitVerse.