Migracja reguł ze Splunka do Elastic Security w praktyce
Automatic Migration w Elastic Security tłumaczy reguły i dashboardy Splunka. Jak wygląda proces, wymagania i dlaczego każdą regułę trzeba sprawdzić.
Przejście ze Splunka na Elastic Security zwykle zatrzymuje się nie na danych, ale na regułach. Zespół bezpieczeństwa przez lata napisał kilkadziesiąt albo kilkaset zapytań SPL, zapisanych jako wyszukiwania korelacyjne, i nikt nie chce ich przepisywać od zera. Elastic odpowiada na to narzędziem Automatic Migration, które tłumaczy reguły i dashboardy na format Elastic Security. W notatkach do wydania Security 9.1 (29 lipca 2025) funkcja migracji reguł figuruje jako dostępna ogólnie (GA), a w Elastic 9.2 z 23 października 2025 doszły do niej ulepszenia oraz migracja dashboardów w podglądzie technicznym. Poniżej opisujemy, jak to działa w praktyce i gdzie kończy się automat, a zaczyna praca analityka.
Co potrafi narzędzie
Automatic Migration przyjmuje wyeksportowane ze Splunka reguły (zapisane wyszukiwania) oraz, w podglądzie technicznym od 9.2, dashboardy. Dla reguł działa w dwóch trybach, które wybierasz przy uruchomieniu tłumaczenia:
- dopasowanie do reguł Elastic: jeśli istnieje gotowa reguła w bibliotece Elastic o podobnym działaniu, migrowana reguła zostaje zastąpiona przez nią. To zużywa mniej tokenów modelu i daje regułę, którą Elastic sam aktualizuje,
- tłumaczenie na regułę własną: gdy opcja dopasowania jest wyłączona albo nie ma odpowiednika, zapytanie SPL jest przekładane na zapytanie Elastic, a powstała reguła jest „custom” i nie aktualizuje się automatycznie.
Tłumaczenie wykonuje model językowy, który podłączasz przez konektor. To ważna decyzja, bo wybór modelu jest jednocześnie wyborem, dokąd trafiają definicje Twoich reguł.
Wymagania
Według dokumentacji Elastic potrzebujesz:
- działającego konektora do modelu językowego (LLM),
- uprawnień w Kibanie do funkcji Automatic Migration oraz co najmniej odczytu reguł,
- dla klastrów zarządzanych samodzielnie subskrypcji Enterprise i włączonego uczenia maszynowego,
- dla Elastic Cloud: włączonego uczenia maszynowego, z zaleceniem co najmniej 4 GB pamięci na strefę uczenia maszynowego.
Wymagania licencyjne sprawdź na własnej subskrypcji przed zaplanowaniem projektu. Zmieniają się między wydaniami i rodzajami wdrożenia.
Jak wygląda proces
- W sekcji Get started wybierasz konektor modelu.
- Wybierasz tłumaczenie reguł (albo dashboardów) i otwierasz okno wczytywania. Okno podaje zapytanie, którym eksportujesz reguły ze Splunka do pliku JSON. Domyślne zapytanie pobiera wyszukiwania korelacyjne. Dokumentacja radzi nie pobierać wszystkich zapisanych wyszukiwań, bo większość z nich nie jest regułami wykrywania. Możesz użyć własnego zapytania, o ile wynik zapiszesz jako JSON.
- Duży plik można podzielić na części, żeby nie przekroczyć okna kontekstu modelu.
- Narzędzie wykrywa, czy reguły używają makr, wyszukiwań (lookups), list referencyjnych albo odwołań do MITRE. Jeśli tak, prosi o ich wyeksportowanie i wczytanie. Bez tego część reguł dostanie status częściowo przetłumaczonych.
- Klikasz Translate. Postęp widać na stronie, a po zakończeniu przychodzi powiadomienie.
- Na stronie Translated rules przeglądasz wyniki, instalujesz je i włączasz.
Nie musisz mieć wcześniej danych w Elastic. Narzędzie podpowiada integracje, które dostarczają dane potrzebne przetłumaczonym regułom. Dopóki danych nie ma, mogą pojawiać się błędy typu Unknown index, które dokumentacja każe zignorować do czasu dodania źródeł.
Statusy i co z nimi zrobić
Każda reguła dostaje jeden z pięciu statusów:
| Status | Znaczenie | Co robisz |
|---|---|---|
| Installed | Reguła jest już w Elastic SIEM | Sprawdzasz i włączasz |
| Translated | Gotowa do instalacji | Przeglądasz i instalujesz |
| Partially translated | Część zapytania nie została przetłumaczona | Uzupełniasz wzorzec indeksu, makra lub wyszukiwania, poprawiasz składnię |
| Not translated | Nic z zapytania nie udało się przetłumaczyć | Piszesz od nowa albo ponawiasz tłumaczenie innym modelem |
| Failed | Tłumaczenie zakończyło się błędem | Czytasz komunikat i ponawiasz |
Dla reguł częściowo przetłumaczonych, w których brakuje wzorca indeksu, jest przycisk Update missing index pattern. Zmienia on wszystkie migracje zawierające symbol zastępczy [indexPattern], nie tylko te widoczne w tabeli. Reguły, których nie udało się przetłumaczyć, można ponowić, wskazując ten sam lub inny konektor. Poziomy ważności ze Splunka są przekładane na skalę Elastic: 1 i 2 na niski, 3 na średni, 4 na wysoki, 5 na krytyczny.
Dlaczego każdą regułę trzeba sprawdzić
Narzędzie oszczędza dużo pracy, ale nie zastępuje przeglądu. Z naszego punktu widzenia trzeba pilnować czterech rzeczy.
Pierwsza sprawa: czy reguła ma dane. Przetłumaczona reguła na logi, których nie zbierasz, nie wykryje niczego, a będzie wyglądała na działającą. Przed włączeniem sprawdź w liście integracji, jakich źródeł wymaga, i czy je masz.
Druga: czy znaczenie się zgadza. Model przekłada składnię, ale nazwy pól w Splunku i w schemacie ECS Elastic się różnią, a niuanse w SPL (grupowanie, okna czasowe, filtrowanie po makrach) łatwo zmienić o jedno ustawienie. Porównaj w panelu szczegółów regułę źródłową z przetłumaczoną, a na danych historycznych sprawdź, czy daje podobne wyniki.
Trzecia: czy nie powstaje szum. Gdy reguła przeszła z dopasowaniem do biblioteki Elastic, może działać inaczej niż Twój oryginał i dawać inną liczbę alertów. Zaczynaj od kilkunastu najważniejszych reguł i obserwuj alerty przez kilka tygodni, zanim włączysz kolejne.
Czwarta: co dzieje się z resztą środowiska Splunka. Reguły to jedna część migracji. Zostają jeszcze zbieranie danych (forwardery zastępuje się Elastic Agent lub kolektorem), akcje alertów, integracje z systemem zgłoszeń, raporty i uprawnienia. Dashboardy w podglądzie technicznym: według dokumentacji obsługiwane są panele typu wizualizacja, wykres, tabela i pojedyncza wartość, a pozostałe są oznaczane jako nieobsługiwane.
Jak podchodzimy do tego projektu
Zaczynamy od inwentarza: które reguły są używane naprawdę (liczba alertów i reakcji w ostatnim roku), które są martwe i które pokrywają wymagania, na przykład wymagania zgodności. Zbędnych nie migrujemy. Resztę tłumaczymy narzędziem, przeglądamy w parach z analitykiem klienta i testujemy równolegle ze Splunkiem. Dopiero po okresie pracy obu systemów razem wyłączamy stare reguły.
Takie projekty prowadzimy w ramach migracji monitoringu. Jak zacząć z regułami w Elastic Security od zera, pokazuje tekst SIEM na Elastic Security: pierwsze kroki z regułami, a wzbogacanie zdarzeń listami referencyjnymi, które w Splunku robią lookupy, można w Elastic robić podobnie poleceniem LOOKUP JOIN, opisanym w tekście o ES|QL i wzbogacaniu logów.
