Śledź Przenoszenie reguł wykrywania polega na pisaniu i zarządzaniu logiką wykrywania zagrożeń, tak aby przenosiła się między platformami SIEM, EDR a XDR bez konieczności pełnego przepisania.
Co się stanie z moimi regułami wykrywania, gdy migruję do nowej platformy SIEM?
Reguły napisane w natywnym języku zapytań platformy nie przemieszczają się. SPL pozostaje w Splunk. KQL pozostaje w Microsoft Sentinel. YARA-L pozostaje w Google SecOps. Przy migracji te reguły muszą zostać przepisane lub przetłumaczone na platformę docelową.
Wierność tłumaczenia zależy od konstruktu, a nie od pary językowej. Dwa osie degradacji decydują o tym, co przetrwa.
Oś 1: mapowanie pól. Taksonomie pól źródłowych (CIM, ASIM, ECS, OCSF, Sysmon-native, vendor-native) mapują się niekompletnie. Niezamapowane lub przemianowane pole w milczeniu zawęża lub łamie regułę.
Oś 2: semantyka konstrukcji. Semantyka agregacji i okien czasowych, logika sekwencji lub transakcji, dialekt regex, oraz funkcje stylów eval/lookup/join często mają tylko częściowe odpowiedniki na platformie docelowej. Oś ta niesie ze sobą udział w przepisywaniu.
Sigma reguły są zaprojektowane do tłumaczenia. Są tworzone jednokrotnie i tłumaczone per backend za pomocą pySigma, sigma-cli, lub Uncoder.
Tłumaczenie nie jest zachowaniem. Każda przetłumaczona reguła wciąż wymaga walidacji specyficznej dla backendu przeciwko parsowanym polom platformy docelowej, zanim zostanie uznana za zaufane. Syntaktycznie poprawne tłumaczenie może odnosić się do pól, które nowa platforma nigdy nie wypełnia.
Routing potoku telemetrii to oddzielny mechanizm. Przekierowanie strumienia logów na nowy cel nie przenosi logiki wykrywania, która na nim działała. SPL pozostaje SPL niezależnie od tego, gdzie wylądują logi.
Jaka jest różnica między regułami wykrywania specyficznymi dla dostawcy a niezależnymi od dostawcy?
Reguła specyficzna dla dostawcy jest zasobem platformy. Reguła niezależna od dostawcy to zasób zespołu.
| Wymiar | SPL (Splunk) | KQL (Microsoft Sentinel) | YARA-L (Google SecOps) | Sigma |
|---|---|---|---|---|
| Działa natywnie na | Splunk | Microsoft Sentinel | Google SecOps | Żaden bezpośrednio. Tłumaczy się na wszystkie trzy oraz IBM QRadar, Elastic, CrowdStrike i inne. |
| Przeniesienie jej wymaga | Przepisania w języku docelowym | Przepisania w języku docelowym | Przepisania w języku docelowym | Tłumaczenia za pośrednictwem pySigma/sigma-cli lub Uncoder, następnie walidacji mapowania pól |
| Kto to posiada | Deployment Splunk | Przestrzeń robocza Sentinela | Najemca SecOps | Twój zespół w kontroli wersji |
| Koszt wieloplatformowy | Napisz N kopii | Napisz N kopii | Napisz N kopii | Przetłumacz raz na backend, zweryfikuj raz na backend |
Różnica w kosztach pojawia się przy migracji i przy działaniu na wielu platformach. Niezależna od dostawcy logika wykrywania pozostaje przenośna w ramach twojego stosu.
Jak mogę przeprowadzić migrację zawartości wykrywania z Splunk do Microsoft Sentinel?
Sześć kroków. Jest to jedna z bardziej wymagających par językowych, ponieważ SPL i KQL różnią się modelem danych, nazwami pól i semantyką funkcji.
- Inwentarz reguł SPL. Wyeksportuj wszystkie zapisane wyszukiwania, alerty i wyszukiwania korelacyjne. Zarejestruj zależności modelu danych każdej reguły (sourcetype, index, nazwy pól).
- Klasyfikacja według typu konstruktu. Posortuj reguły do trzech koszyków: prosta logika selekcji (przenosi się czysto), zależna od mapowania pól (przenosi się z pracą przy mapowaniu), oraz logika korelacji/stanu (oczekuj ręcznego przepisania).
- Przekładaj przez Sigmę. Przekształć reguły SPL na Sigmę, a następnie przetłumacz Sigmę na KQL za pomocą pySigma z backendem Microsoft Sentinel, sigma-cli lub Uncoder. To obsługuje składnię. Nie obsługuje mapowania pól.
- Mapuj pola względem schematu Sentinela. Dopasuj nazwy pól CIM do odpowiedników ASIM. Microsoft dokumentuje swój schemat na learn.microsoft.com. Każde pole w przetłumaczonej regule musi odpowiadać kolumnie w tabeli docelowej.
- Testowanie na tabelach Sentinela. Uruchom każdą przetłumaczoną regułę na rzeczywistych zaimportowanych danych. Zachowaj zdarzenie testowe na regułę, aby móc zweryfikować dopasowanie po każdej zmianie schematu.
- Przejdź z oknem równoległym. Uruchom obie platformy na tych samych źródłach logów. Porównaj wyniki alertów. Wycofaj wersję SPL tylko wtedy, gdy wersja KQL uruchamia się na tych samych zdarzeniach.
Przed przejściem, mapuj wdrożone reguły na obu platformach do MITRE ATT&CK techniki i porównaj obie mapy, aby technika, którą migracja pomija, pojawiła się przed przejściem, a nie po; SOC Prime’s MITRE ATT&CK Audit mapuje wdrożenia detekcji i źródła danych do ATT&CK jako usługi.
Migrując bibliotekę reguł? Odkryj SOC Prime’s Prime Architect dla tłumaczenia zasad międzyplatformowych, badań zagrożeń i workflow inżynierii wykrywania.
Jakie są najlepsze praktyki tłumaczenia języków zapytań takich jak SPL na KQL?
Tłumacz logikę, a nie składnię. Port znak po znaku produkuje kruche reguły, które odnoszą się do pól, których docelowa platforma może nie wypełniać.
- Mapuj pola względem schematu docelowego. Nie zakładaj, że nazwy pól będą przenosiły się automatycznie. Splunk CIM i Sentinel ASIM to różne kontrakty. Wysiłek migracji leży w mapowaniu między nimi.
- Zachowaj zdarzenie testowe na regułę. Znane złe zdarzenie sparowane z znanym poprawnym. Jeśli przetłumaczona reguła nie dopasowuje się do złego i nie odrzuca poprawnego, coś się zepsuło w tłumaczeniu.
- Przejrzyj wszystko, co wskazuje na przetłumaczoną. Automatyczne tłumacze dobrze radzą sobie z prostą logiką selekcji. Reguły korelacji, funkcje zastrzeżone i złożone agregacje wymagają przeglądu człowieka.
- Nazwij swoje narzędzia. Prime Architect tłumaczy Sigmę na 65 języków wykrywania, migruje między natywnymi językami zapytań takimi jak SPL i KQL, stosuje preselekcje mapowania pól dla środowiska, które podłączasz, i wdraża z zarządzanego repozytorium zasad do obsługiwanej platformy docelowej. Otwarta w… Uncoder IO pokrywa etap tłumaczenia i może działać samodzielnie (źródło na GitHub). Żadne z trzech nie eliminuje walidacji mapowania pól.
Przykład: prosta reguła tworzenia procesu tłumacząca EventCode=4688 i New_Process_Name (Splunk CIM) na EventID == 4688 i NewProcessName (tabela Sentinel SecurityEvent). Ta sama faktura, różna nazwa pola na kontrakcie platformy.
Znak klepsydry na końcu SPL staje się operatorem endswith w KQL. Ta para działa, ponieważ jest to dopasowanie pola pojedynczego zdarzenia. Reguły korelacji nie tłumaczą się tak czysto.
Jak długo trwa migracja biblioteki reguł i co ją napędza?
Trzy czynniki określają wysiłek.
Liczba reguł. Więcej reguł, więcej cykli walidacji. Każda przetłumaczona reguła wymaga testu na danych zaimportowanych przez docelową platformę.
Pola niestandardowe i zależności modelu danych. Reguły odnoszące się do pól specyficznych dla dostawcy, ekstrakcji niestandardowych lub tabel wyszukiwań wymagają pracy z mapowaniem na każdym polu. Im więcej dostosowań w źródle, tym więcej ręcznej pracy przy migracji.
Wysiłek walidacji. Każda przetłumaczona reguła musi być zweryfikowana w stosunku do parsowanych pól platformy docelowej. Syntaktycznie poprawne tłumaczenie może cicho zawieść, jeśli docelowy schemat nie popularyzuje odwołanego pola.
Rzetelna dostawa z oceny migracji to klasyfikacja na regułę: port czysty, port z pracą mapującą, lub wymaga ręcznego przepisania. Jedyna szacowana czasowo dostawa dla całej biblioteki źle przedstawia dystrybucję pracy.
Jak uniknąć blokady następnym razem?
Trzy praktyki.
- Twórz w Sigmie. Pisz od początku niezależną od dostawcy logikę wykrywania. Reguły Sigma tłumaczą się na każdą główną platformę SIEM, EDR i XDR. Zawartość wykrywania źródłowa już w Sigmie, jak reguły Sigma w SOC Prime’s Core, utrzymuje bibliotekę przenośną od pierwszej reguły.
- Trzymaj logikę w kontroli wersji. Przechowuj swoje reguły wykrywania w Git razem z mapowaniami pól i zdarzeniami testowymi dla każdego docelowego backendu. Reguły podróżują z zespołem, a nie z platformą.
- Przekładaj podczas wdrażania. Użyj pySigma, sigma-cli, lub Uncoder do generowania platformowych zapytań natywnych podczas wdrażania. Źródło pozostaje przenośne. Składań wynik jest jednorazowy.
To rozdzielenie oznacza, że migracja platformy zmienia tylko cel tłumaczenia, a nie logikę wykrywania.
Czy przekierowanie telemetrii przez potok to to samo co przeniesienie wykrywania?
Nie. Potok telemetrii (takie jak Cribl i podobne narzędzia) przenosi dane. Nie przenosi logiki wykrywania.
Przekierowanie strumienia logów z Splunk do Microsoft Sentinel przez potok dostarcza zdarzenia do nowego celu. Reguły SPL, które działały na tych zdarzeniach w Splunk, nie podążają. SPL pozostaje SPL. Logika wykrywania nadal musi być przetłumaczona lub przepisana dla platformy docelowej.
Routing przez potok rozwiązuje problem dostarczania danych. Przenoszenie detekcji rozwiązuje problem tłumaczenia logiki. Są one niezależne. Zespół, który przekierowuje telemetrię do nowego SIEM bez przenoszenia jego detekcji, ma dane w nowym miejscu i brak reguł do dopasowania do nich.
Wyjątkiem jest potok, który samodzielnie uruchamia wykrycia: SOC Prime’s Prime Detect stosuje reguły w Sigmie na warstwie potoku przed SIEM, a jego wydanie open-source jest na GitHub.
Gdzie to się nie zgadza
Nie wszystko tłumaczy się, nawet z Sigmą. Cztery klasy konstrukcji wymagają ręcznych przepisów na platformie docelowej.
- Logika korelacji i stanowa. Agregacja liczbowa i wartościowa, sekwencja czasowa, korelacja wielu zdarzeń. Sigma dodała typy reguł korelacyjnych w swojej specyfikacji v2, ale wsparcie backendu różni się w zależności od backendu pySigma. Harmonogram versus wykonanie streamingowe również zmienia, co może wyrazić reguła.
- Funkcje zastrzeżone. Splunk transaction, eval expressions, enrrichment napędzane przez wyszukiwania, makra. Analogi KQL są częściowe.
- Pewne wzorce agregacji. Konstrukty typu progowy nad oknem i statystyki … by … span= tłumaczą się nierówno między platformami.
- Odniesienia do pól zależne od schematu. Ta sama reguła proces_creation w Sigmie ląduje na różnym polu w zależności od potoku. Na Sysmon jest to Image. Na security Splunk Windows jest to New_Process_Name. Tłumaczenie jest poprawne tylko względem faktycznie wdrożonego schematu.
Te konstrukty mają największe znaczenie, kiedy kluczowe jest klasyfikowanie każdej reguły. Oczekuj, że będą wymagać ręcznej walidacji i, w wielu przypadkach, przepisywania od zera.
Lista kontrolna gotowości do migracji
[ ] Pełny inwentarz reguł wyeksportowany (zapisane wyszukiwania, alerty, wyszukiwania korelacyjne)
[ ] Każda reguła sklasyfikowana: czysty port / port z mapowaniem / wymagane przepisanie
[ ] Tabela mapowania pól zbudowana: schemat źródłowy do schematu docelowego
[ ] Wersje Sigma przenośnych reguł utworzone i przechowywane w kontroli wersji
[ ] Wybrane narzędzia do tłumaczenia (pySigma/sigma-cli, Uncoder, lub oba)
[ ] Pary zdarzeń testowych utworzone na regułę (jedna znana zła, jedna znana dobra)
[ ] Przetłumaczone reguły zweryfikowane względem tabel docelowych z rzeczywistymi danymi zaimportowanymi
[ ] Zidentyfikowane reguły korelacji i statusu do ręcznego przepisania
[ ] Skompilowany katalog funkcji zastrzeżonych (transakcje, eval, wyszukiwania, makra)
[ ] Zdefiniowane okno równoległe: obie platformy importujące te same źródła
[ ] Udokumentowanie kryteriów porównania wyników alertów
[ ] Zdefiniowany plan wycofania: warunki powrotu do platformy źródłowej
FAQ
Co się stanie z moimi regułami wykrywania, gdy migruję do nowej platformy SIEM?
Platformowe rodzime reguły nie przemieszczają się. SPL, KQL i YARA-L muszą być przepisane lub przetłumaczone dla platformy docelowej. Reguła stworzona w Sigmie jest tłumaczona raz na backend, a każda przetłumaczona reguła nadal wymaga walidacji względem parsowanych pól platformy docelowej. Logika korelacji, stanowa, funkcje zastrzeżone, i niektóre wzorce agregacji nie tłumaczą się czysto.
Jak mogę przeprowadzić migrację zawartości wykrywania z Splunk do Microsoft Sentinel?
Inwentaryzuj reguły SPL, sklasyfikuj każdą według typu konstrukcji, przetłumacz za pomocą Sigmy przy użyciu pySigma lub Uncoder, mapuj pola z schematu Splunk do schematu Sentinela, przetestuj każdą regułę na rzeczywistych danych importowanych Sentinela, następnie przejdź z oknem równoległym przed wycofaniem wersji SPL. Microsoft dokumentuje schemat Sentinela na learn.microsoft.com.
Jaka jest różnica między regułami wykrywania specyficznymi dla dostawcy a niezależnymi od dostawcy?
Reguła specyficzna dla dostawcy jest zasobem platformy, na której działa. Reguła niezależna od dostawcy utworzona w Sigmie jest zasobem zespołu, przechowywanym w kontroli wersji i tłumaczonym na każde środowisko backendowe. Różnica w kosztach pojawia się przy migracji i przy multi-platformowym działaniu.
Czy przekierowanie telemetrii przez potok sprawia, że moje wykrywania są przenośne?
Nie. Potok telemetrii przenosi dane do nowego celu. Nie przenosi logiki wykrywania, która działała na tych danych. SPL pozostaje SPL, gdziekolwiek logi się znajdą, więc reguły wciąż wymagają tłumaczenia lub przepisania.
Jakie są najlepsze praktyki tłumaczenia języka zapytań takiego jak SPL na KQL?
Tłumacz logikę, a nie składnię. Mapuj każde pole względem schematu docelowego, zachowaj znane złe i znane poprawne zdarzenie testowe na regułę i przejrzyj wszystko, co wskazuje na tłumaczenie, ponieważ reguły korelacji i funkcje zastrzeżone wymagają przeglądu człowieka. pySigma, sigma-cli, i Uncoder obsługują tłumaczenie Sigmy, ale żaden z nich nie usuwa walidacji mapowania pól.
Oceń istniejące pokrycie SIEM i stwórz plan na swoją transformację za pomocą Prime Hunt. Prime Hunt przegląda wszystkie twoje reguły SIEM, identyfikuje luki i prowadzi cię do pełnego pokrycia – kluczowa praca przed migracją SIEM.
