Портативність правил виявлення між SIEM, EDR та XDR

Переносимість правил виявлення загроз – це практика написання та управління логікою виявлення загроз, яка дозволяє їм пересуватись по платформах SIEM, EDR і XDR без повного переписування.

Що станеться з моїми правилами виявлення, коли я мігрую на нову платформу SIEM?

Правила, написані рідною мовою запитів платформи, не подорожують. SPL залишається в Splunk. KQL залишається в Microsoft Sentinel. YARA-L залишається в Google SecOps. При міграції ці правила повинні бути переписані або перекладені для цільової платформи.

Точність перекладу залежить від конструкції, а не від пари мов. Дві осі деградації визначають, що виживе.

Вісь 1: відображення полів. Таксономії полів джерела (CIM, ASIM, ECS, OCSF, Sysmon) відображаються неповністю. Невідображене або перейменоване поле тихо звужує або ламає правило.

Вісь 2: семантика конструкцій. Семантика агрегації та часових вікон, логіка послідовностей або транзакцій, діалекти регулярних виразів і функції типу eval/lookup/join часто мають лише часткові аналоги на цільовій платформі. Ця ось несе частку переписування.

Sigma правила призначені для перекладу. Вони створюються один раз і перекладаються для кожної бекенд-платформи через pySigma, sigma-cli, або Uncoder.

Переклад – це не збереження. Кожне перекладене правило все ще вимагає специфічної перевірки бекенду проти розпізнаних полів на цільовій платформі перед тим, як воно стане довіреним. Синтаксично правильний переклад може посилатися на поля, яких нова платформа ніколи не заповнює.

Маршрутизація по конвеєру телеметрії – це окремий механізм. Маршрутизація потоку журналів до нового пункту призначення не переносить логіку виявлення, яка працювала на ньому. SPL залишається SPL незалежно від того, де розташовані журнали.

Яка різниця між правилами моніторингу, специфічними для постачальника та незалежними від постачальника?

Правило, специфічне для постачальника, є активом платформи. Правило, незалежне від постачальника, є активом команди.

Вимір	SPL (Splunk)	KQL (Microsoft Sentinel)	YARA-L (Google SecOps)	Sigma
Запускається нативно на	Splunk	Microsoft Sentinel	Google SecOps	Безпосередньо нічого. Перекладається на всі три плюс IBM QRadar, Elastic, CrowdStrike та інші.
Переміщення вимагає	Переписування на мові цільової платформи	Переписування на мові цільової платформи	Переписування на мові цільової платформи	Переклад через pySigma/sigma-cli або Uncoder, потім валідація відображення полів
Хто ним володіє	Розгортання Splunk	Робоче місце Sentinel	Орендар SecOps	Ваша команда, у системі контролю версій
Вартість між платформами	Написання N копій	Написання N копій	Написання N копій	Переклад один раз на кожен бекенд, перевірка один раз на кожен бекенд

Відмінність у вартості з’являється під час міграції та при багатоплатформовій експлуатації. Незалежна від постачальника логіка виявлення залишається портативною в усій вашій стека.

Як я можу мігрувати вміст виявлення з Splunk на Microsoft Sentinel?

Шість кроків. Це одна з найскладніших пар мов, оскільки SPL і KQL відрізняються за моделлю даних, іменуванням полів і семантикою функцій.

Інвентаризація правил SPL. Експортуйте кожен збережений запит, сповіщення та пошук кореляції. Запишіть залежності від моделі даних кожного правила (тип джерела, індекс, імена полів).

Класифікуйте за типом конструкції. Розсортуйте правила в три корзини: звичайна логіка вибору (переноситься чисто), залежна від відображення полів (переноситься з роботою по відображенню) та логіка кореляції/стану (очікує на ручне переписування).

Переклад через Sigma. Конвертуйте правила SPL в Sigma, потім переведіть Sigma в KQL за допомогою pySigma з бекендом Microsoft Sentinel, sigma-cli або Uncoder. Це обробляє синтаксис. Воно не обробляє відображення полів.

Відобразіть поля проти схеми Sentinel. Згармонізуйте імена полів CIM з еквівалентами ASIM. Microsoft документує свою схему на learn.microsoft.com. Кожне поле в перекладеному правилі повинно бути вирішено в стовпчик у таблиці призначення.

Тестуйте на таблицях Sentinel. Запустіть кожне перекладене правило проти реальних завантажених даних. Залиште тестову подію для кожного правила, щоб ви могли перевірити відповідність після будь-якої зміни схеми.

Переключіться з вікном паралельного виконання. Запускайте обидві платформи на тих самих джерелах журналів. Порівняйте вихідні оповіщення. Вийдіть з версії SPL тільки після того, як версія KQL спрацьовує на тих самих подіях.

Перед переключенням відобразіть розгорнуті правила на обох платформах на техніки MITRE ATT&CK та порівняйте карту, щоб техніка, яку міграція опускає, з’явилася до переключення, а не після; SOC Prime’s MITRE ATT&CK Audit відображає розгорнуті виявлення та джерела даних на ATT&CK як сервіс.

Міграція бібліотеки правил? Оцініть Prime Architect SOC Prime для перекладу правил між платформами, дослідження загроз та робочі процеси інженерії виявлення. Prime Architect for cross-platform rule translation, threat research, and detection engineering workflows.

Зв’яжіться з продажним відділом

Які кращі практики для перекладу мов запитів, таких як SPL на KQL?

Перекладайте логіку, а не синтаксис. Порт символ за символом створює тендітні правила, які звертаються до полів, яких цільова платформа може не заповнювати.

Відобразіть поля проти схеми призначення. Не припускайте, що імена полів переносяться. Splunk CIM і Sentinel ASIM – різні контракти. Зусилля з міграції лежать у відображенні між ними.
Тримайте тестову подію для кожного правила. Задіяна відома подія з поганою репутацією пари з подією з доброю репутацією. Якщо перекладене правило не відповідає на погану і не відхиляє добру, щось зламалося під час перекладу.
Перегляньте все, що помітилося перекладачем. Автоматизовані перекладачі добре обробляють звичайну логіку вибору. Правила кореляції, власні функції та складні агрегації потребують перегляду людиною.
Назвіть ваші інструменти. Prime Architect перекладає Sigma на 65 мов виявлення, мігрує між рідними мовами запитів, такими як SPL і KQL, застосовує попередні настройки відображення полів для підключеного вами середовища і розгортає з керованого репозиторію правил у підтримувану цільову платформу. Відкритий вихідний код Uncoder IO охоплює крок перекладу і може працювати з самостійним розміщенням (вихідний код на GitHub). Жоден з трьох не усуває валідацію відображення полів.

Приклад: просте правило створення процесу, що перекладається з EventCode=4688 і New_Process_Name (Splunk CIM) на EventID == 4688 і NewProcessName (таблиця Sentinel SecurityEvent). Той самий факт, різні імена полів для контракту платформи.

Завершальний знак узору SPL стає кінцевим оператором KQL. Ця пара працює, оскільки це одноразове співвідношення полів події. Правила кореляції не перекладаються так чисто.

Скільки часу займає міграція бібліотеки правил і що її визначає?

Три драйвера визначають зусилля.

Кількість правил. Більше правил, більше циклів валідації. Кожне перекладене правило потребує тестового запуску проти завантажених даних цільової платформи.

Користувацькі поля та залежності моделі даних. Правила, які посилаються на поля, специфічні для постачальника, користувацькі витяги або таблиці пошуку, потребують роботи з відображенням кожного поля. Чим більше персоналізації в джерелі, тим більше ручної роботи в міграції.

Зусилля з валідації. Кожне перекладене правило повинно бути перевірено відносно розпізнаних полів цільової платформи. Синтаксично правильний переклад може тихо провалюватися, якщо схема цільової платформи не заповнює вказане поле.

Чесний deliverable з оцінки міграції – це класифікація за правилами: переноситься чисто, переноситься з роботою по відображенню, або вимагає ручного переписування. Єдина оцінка часу для всієї бібліотеки неправильно представляє розподіл зусиль.

Як уникнути блокування в майбутньому?

Три практики.

Автор у Sigma. Напишіть незалежну від постачальника логіку виявлення з самого початку. Правила Sigma перекладаються на всі основні платформи SIEM, EDR і XDR. Вміст виявлення, уже реалізований у Sigma, як-от правила Sigma в SOC Prime’s Core, зберігає портативність бібліотеки з першого правила.

Зберігайте логіку під контролем версій. Зберігайте ваші правила виявлення в Git поряд з відображенням полів і тестовими подіями для кожного цільового бекенду. Правила подорожують разом з командою, а не платформою.

Перекладіть під час розгортання. Використовуйте pySigma, sigma-cli або Uncoder для генерування запитів, специфічних для платформи, під час розгортання. Джерело залишається портативним. Скомпільований вивід – тимчасовий.

Це розподіл означає, що міграція платформи змінює ціль перекладу, а не логіку виявлення.

Чи є маршрутизація телеметрії через конвеєр тим самим, що й перенесення ваших виявлень?

Ні. Телеметричний конвеєр (Cribl та інші подібні інструменти) переміщує дані. Він не переміщує логіку виявлення.

Маршрутизація потоку журналів з Splunk до Microsoft Sentinel через конвеєр доставляє події до нового пункту призначення. Правила SPL, які працювали на тих подіях в Splunk, не слідують. SPL залишається SPL. Логіка виявлення все одно повинна бути перекладена або переписана для цільової платформи.

Маршрутизація по конвеєру вирішує питання доставки даних. Переносимість виявлення вирішує питання перекладу логіки. Вони незалежні. Команда, яка маршрутизує телеметрію до нового SIEM без перенесення своїх виявлень, має дані на новому місці и ніяких правил для їх співставленні.

Виняток – це конвеєр, що запускає виявлення самостійно: Prime Detect SOC Prime застосовує правила в Sigma на рівні конвеєра перед SIEM, і його видання з відкритим вихідним кодом знаходиться на GitHub.

Де це не застосовується

Не все перекладається, навіть за допомогою Sigma. Чотири конструкційні класи потребують ручного переписування на цільовій платформі.

Кореляція і стан логіки. Агрегація числень і значень, часові послідовності, кореляція багатоподій. Sigma додала типи правил кореляції в своїй специфікації v2, але підтримка бекенду відрізняється по кожному бекенду pySigma. Планувальне проти потокового виконання також змінює те, що може висловити правило.
Пропрієтарні функції. Транзакції Splunk, вирази eval, збагачення, кероване пошуком, макроси. Аналоги KQL є частковими.
Деякі паттерни агрегації. Конструкції з порогом у вікні та патерни stats … by … span= перекладаються нерівномірно по платформах.
Посилання на поля, що залежать від схеми. Те саме правило process_creation Sigma потрапляє на різне поле залежно від конвеєра. На Sysmon це Image. На Splunk Windows Security це New_Process_Name. Переклад є правильним лише відносно фактично розгорнутої схеми.

Ці конструкції є найважливішими для класифікації за правилами. Очікуйте, що вони вимагатимуть ручної валідації і, в багатьох випадках, переписування з нуля.

Контрольний список готовності до міграції

[ ] Повна інвентаризація правил експортована (збережені пошуки, сповіщення, пошуки кореляції)

[ ] Кожне правило класифіковано: переноситься чисто / переноситься з відображенням / вимагає переписування

[ ] Таблиця відображення полів побудована: джерелодоповідна схема до цільової схеми

[ ] Версії Sigma портативних правил створені та збережені у контролі версій

[ ] Вибрані інструменти перекладу (pySigma/sigma-cli, Uncoder або обидва)

[ ] Тестові події створені для кожного правила (одна зі знаком, одна беззаперечна)

[ ] Перекладені правила перевірені проти таблиць призначення з реальними завантаженими даними

[ ] Кореляція та стан правил ідентифіковані для ручного переписування

[ ] Каталогізовано пропрієтарні функції (транзакція, оцінка, пошуки, макроси)

[ ] Вікно паралельного виконання визначено: обидві платформи завантажують ті самі джерела

[ ] Документовано критерії порівняння результатів сповіщення

[ ] Визначено план відкату: умови для повернення до платформи джерела

FAQ

Що станеться з моїми правилами виявлення, коли я мігрую на нову платформу SIEM?

Нативні для платформи правила не подорожують. SPL, KQL і YARA-L повинні бути переписані або перекладені для цільової платформи. Правило, створене в Sigma, перекладається один раз на бекенд, і кожне переведене правило все ще потребує перевірки проти розпізнаних полів призначення. Кореляція, логіка стану, власні функції та деякі моделі агрегації не перекладаються чисто.

Як я можу мігрувати вміст виявлення з Splunk на Microsoft Sentinel?

Інвентаризуйте правила SPL, класифікуйте кожне за типом конструкції, перекладіть через Sigma з pySigma або Uncoder, відобразіть поля зі схеми Splunk на схему Sentinel, протестуйте кожне правило проти реальних завантажених даних Sentinel, потім переключіться з вікном паралельного виконання перед припиненням версії SPL. Microsoft документує схему Sentinel на learn.microsoft.com.

Яка різниця між правилами моніторингу, специфічними для постачальника та незалежними від постачальника?

Специфічне для постачальника правило є активом платформи, на якій воно працює. Незалежне від постачальника правило, створене в Sigma, є активом команди, що зберігається під контролем версій і перекладається на кожен бекенд. Різниця у вартості проявляється під час міграції та у багатоплатформовій експлуатації.

Чи робить маршрутизація телеметрії через конвеєр мої виявлення портативними?

Ні. Телеметричний конвеєр переміщує дані до нової цілі. Він не переміщує логіку виявлення, яка працювала на них. SPL залишається SPL, де б журнали не оселились, тому правила все одно потрібно перекласти або переписати.

Які найкращі практики для перекладу мови запитів з SPL на KQL?

Перекладайте логіку, а не синтаксис. Відобразіть кожне поле проти схеми призначення, зберігайте відомий поганий і відомий добрий тестовий захід для кожного правила, і перегляньте все, що помітило перекладач, оскільки правила кореляції та власні функції потребують перегляду людського ока. pySigma, sigma-cli і Uncoder обробляють переклад Sigma, і жоден з них не усуває перевірку відображення поля.

Оцініть вашу існуючу покритість SIEM і створіть план для вашого переходу за допомогою Prime Hunt. Prime Hunt переглядає всі ваші правила SIEM, виявляє прогалини і направляє ваш курс до повного покриття – критична робота перед міграцією SIEM.