TL;DR
RulePilot — агентная система, которая генерирует правила кибербезопасности для SIEM-платформ (Splunk, Microsoft Sentinel) из описания на естественном языке. Ключевая идея: вместо прямой генерации сложного синтаксиса — сначала создать промежуточное представление (IR), которое описывает структуру правила в стандартизированном формате, а потом преобразовать его в финальный код.
Проблема, которую решает система: языки правил SIEM (SPL, KQL) — сложные, специфичные для каждого вендора, требуют глубокого понимания логов и систем. LLM «в лоб» генерирует синтаксически похожие, но логически неверные правила. Модель не понимает связи между событиями — например, что логин должен следовать после создания профиля в определённом временном окне, а не просто «считать логины».
RulePilot решает это трёхступенчато: (1) Chain-of-Thought разбивает задачу на шаги — определить источники логов, фильтры, агрегации; (2) Промежуточное представление фиксирует логику в структурированном формате
Схема метода
ШАГ 1: Chain-of-Thought → разбить задачу на подзадачи
[источники логов → фильтры → поля → агрегации → оптимизация]
ШАГ 2: Промежуточное представление (IR)
Для каждого шага: | PARAMS{} | MODULES{}
→ структурированное описание логики правила
ШАГ 3: Генерация правила
IR → конкретный синтаксис целевой SIEM (SPL / KQL)
ШАГ 4: Рефлексия и оптимизация
Проверка: логика ✓ синтаксис ✓ выполнимость ✓
Если ошибки → итеративно исправить через API SIEM Все шаги выполняются автоматически агентом. Человек проверяет только финальный результат.
Пример применения
Контекст: Этот пример демонстрирует принцип промежуточного представления на задаче, которую исследовали авторы.
Задача: Написать правило для Splunk, которое детектирует brute-force атаки — более 10 неудачных попыток входа с одного IP за 30 минут.
Промежуточное представление (IR):
FILTER
| PARAMS {index="auth_logs", source="WinEventLog:Security", earliest=-30m}
| MODULES {"Агрегировать попытки логина", "Детектировать brute-force"}
AGGREGATE
| PARAMS {by=src_ip, function=count}
| MODULES {"Группировать по IP-адресу источника"}
FILTER
| PARAMS {condition="count > 10"}
| MODULES {"Оставить только подозрительные IP"}Финальное правило (SPL):
index="auth_logs" source="WinEventLog:Security" earliest=-30m
| stats count by src_ip
| where count > 10Результат: Модель сначала создаёт структурированное описание логики (IR), где каждый блок — отдельный шаг обработки. Потом преобразует IR в конкретный синтаксис Splunk. Если правило не работает (ошибка синтаксиса или пустой результат) — система автоматически корректирует через API.
Почему это работает
Слабость LLM: Модели хорошо генерируют текст, похожий на примеры из обучения. Но SIEM-правила — редкий формат с нестандартным синтаксисом. Прямая генерация даёт «правдоподобно выглядящий» код, который не работает логически. Например, GPT-4o при генерации правила для детекции атаки просто считает события, игнорируя временные зависимости между ними.
Сильная сторона LLM: Модели хорошо работают с структурированными форматами и пошаговым рассуждением. Если задать явную структуру (KEYWORD | PARAMS | MODULES), модель заполняет её точнее, чем генерирует свободный текст.
Как метод использует это: Промежуточное представление работает как «черновик» — сначала модель думает о логике (что фильтровать, что агрегировать), а не о синтаксисе (какие команды SPL использовать). Это разделение снижает когнитивную нагрузку. Потом отдельный шаг переводит логику в синтаксис. А рефлексия ловит ошибки, которые пропустили первые два шага.
Шаблон промпта
⚠️ Этот шаблон требует специализированных знаний и инфраструктуры (SIEM-системы, API для валидации).
Ты аналитик кибербезопасности. Создай правило детекции для {SIEM_платформа}.
ЗАДАЧА: {описание_угрозы}
ШАГ 1 — Создай промежуточное представление (IR):
Для каждого этапа обработки используй формат:
| PARAMS {ключ=значение}
| MODULES {"что делает этот этап"}
Ключевые слова: FILTER, EXTRACT, AGGREGATE, TRANSFORM, OUTPUT
ШАГ 2 — Преобразуй IR в синтаксис {SIEM_платформа}:
Каждый блок IR → одна команда/pipe.
ШАГ 3 — Проверь результат:
- Логическая консистентность: все условия связаны правильно?
- Синтаксис: нет ошибок в командах?
- Выполнимость: правило сработает на реальных логах?
Если нашёл ошибки — исправь и покажи финальную версию. Плейсхолдеры:
{SIEM_платформа}— Splunk SPL, Microsoft KQL, или другая{описание_угрозы}— что нужно детектировать (brute-force, эксфильтрация данных, подозрительные процессы)
Универсальный принцип: промежуточное представление
Основная идея RulePilot применима шире, чем SIEM-правила:
Когда использовать: Генерация сложного структурированного вывода — код, запросы к базам данных, конфигурации, регулярные выражения.
Как применить:
Вместо: "Напиши [сложный результат]"
Сделай:
1. Сначала опиши СТРУКТУРУ результата:
- Какие блоки/компоненты нужны?
- Какие параметры у каждого блока?
- Какая логика связывает блоки?
2. Потом преобразуй структуру в финальный формат
3. Проверь: логика + синтаксис + работоспособностьПример для SQL-запросов:
Структура:
- ИСТОЧНИК: таблица orders
- ФИЛЬТР: дата > 2024-01-01
- АГРЕГАЦИЯ: сумма по клиентам
- СОРТИРОВКА: по убыванию суммы
→ SELECT customer_id, SUM(amount)
FROM orders
WHERE order_date > '2024-01-01'
GROUP BY customer_id
ORDER BY SUM(amount) DESCНо этот принцип не нов — это вариация Chain-of-Thought с явной структурой. Ценность RulePilot — в детальной реализации для конкретной ниши (SIEM), а не в универсальном прорыве.
Ограничения
⚠️ Узкая ниша: Метод разработан для кибербезопасности. Применение требует знания SIEM-систем, форматов логов, языков SPL/KQL.
⚠️ Нужна инфраструктура: Полноценная работа требует API к SIEM (Splunk, Sentinel) для валидации и итеративной коррекции. Без этого — только ручная проверка.
⚠️ Неявные паттерны атак: Если описание угрозы не содержит ключевых поведенческих индикаторов явно, система не сможет их «угадать». Например, «процесс внедряется в MSBuild.exe» — это process hollowing, но модель не всегда понимает это без явного указания.
⚠️ Человеческая проверка обязательна: Авторы явно указывают, что финальные правила должны проверяться специалистом перед развёртыванием.
Как исследовали
Команда из Национального университета Сингапура и Fudan University протестировала RulePilot на 1627 правилах из официального репозитория Splunk Security Content. Сравнивали с «голыми» GPT-4o, DeepSeek-V3 и LLaMA-3 — без агентного воркфлоу.
Измеряли двумя способами: (1) текстовое сходство с эталонными правилами (BLEU, ROUGE, METEOR) и (2) семантическую корректность через LLM-оценщика по шести параметрам — логика, синтаксис, читаемость, покрытие условий, риск ложных срабатываний, эффективность выполнения.
Результаты убедительные: RulePilot превосходит базовые модели на 20-107% по текстовому сходству. На реальных логах (229 968 записей из 61 атомарного теста MITRE ATT&CK) — достигает F1 до 1.00 по некоторым категориям атак.
Интересная находка: облачные правила генерируются лучше всего — видимо, они более структурированы. Web-правила — хуже всего — слишком много вариаций и неявных паттернов. Без итеративной коррекции через API Splunk базовые модели полностью проваливаются на сложных атаках вроде Privilege Escalation (0% precision и recall у GPT-4o).
Ablation study показал, что оба компонента критичны: без IR падает синтаксис, без CoT-Reflection — логическая консистентность. Вместе они дают синергию.
Ресурсы
Работа: "RulePilot: An LLM-Powered Agent for Security Rule Generation" (ICSE 2026)
Авторы: Hongtai Wang, Ming Xu, Yanpei Guo (National University of Singapore); Weili Han (Fudan University); Hoon Wei Lim (NCS Group); Jin Song Dong (NUS)
Код: https://github.com/LLM4SOC-Topic/RulePilot
Датасет: https://sites.google.com/view/rulepilot/dataset