SIGMA – Uniwersalny Język Reguł Detekcji: Od Podstaw do Integracji z SIEM – Część 2

Wprowadzenie

Sigma stała się „uniwersalnym językiem” opisu reguł detekcji zagrożeń w logach – czymś w rodzaju „SQL dla bezpieczeństwa” pozwalającym zdefiniować wykrywanie raz, a wykorzystywać na wielu platformach SIEM/EDR.

W pierwszej części serii omówiliśmy podstawy tworzenia reguł Sigma i ich składnię. W Części 2 skupiamy się na integracji reguł Sigma z różnymi platformami SIEM i EDR.Pokażemy, jak przekonwertować uniwersalne reguły Sigma na konkretne zapytania w narzędziach takich jak Splunk, Elastic, IBM QRadar, Microsoft Sentinel oraz innych (np. ArcSight, Sumo Logic). Artykuł zawiera praktyczne przykłady (np. wykrywanie pobierania pliku przez PowerShell, użycia EncodedCommand, trwałości w rejestrze systemu Windows itp.), mapowanie nazw pól między Sigma a SIEM, a także wskazówki i przestrogi ułatwiające skuteczną integrację. Dzięki temu dowiesz się, jak wykorzystać reguły Sigma w codziennej pracy analityka bezpieczeństwa (SOC, threat hunting, analiza zagrożeń) niezależnie od używanej platformy. Zaczynajmy!

Narzędzia do konwersji reguł Sigma na zapytania SIEM

Jednym z powodów popularności Sigma jest dostępność narzędzi, które automatycznie konwertują reguły Sigma na zapytania języka SIEM/EDR. Najważniejsze z nich to oficjalne narzędzie wiersza poleceń sigmac (Sigma Converter) oraz nowy Sigma CLI oparty na bibliotece pySigma. Dzięki nim pojedyncza reguła zapisana w formacie Sigma (plik YAML) może zostać przetłumaczona na zapytanie dla wybranej platformy, np. Splunk SPL, Elastic SQL/KQL, IBM QRadar AQL czy Azure Sentinel KQL.

sigmac

Klasyczne narzędzie dostępne po zainstalowaniu pakietu sigmatools (np. poleceniem pip3 install sigmatools). Umożliwia konwersję przez wskazanie typu platformy. Przykład:

sigmac -t splunk path/do/pliku_reguly.yml > wynik_splunk.txt

powyższe polecenie wygeneruje zapytanie SPL na podstawie reguły Sigma. Podobnie -t qradar wygeneruje zapytanie AQL dla QRadar, -t sentinel da KQL dla Microsoft Sentinel itp. Istnieje kilkadziesiąt backendów, więc jednym poleceniem możemy uzyskać regułę dla dowolnego obsługiwanego SIEM.

Sigma CLI (pySigma)

Nowsze narzędzie, które dzięki wtyczkom (tzw. backend dla konkretnej platformy oraz pipeline do mapowania pól) oferuje jeszcze większe możliwości dostosowania. Pozwala instalować pluginy dla poszczególnych SIEM (np. Splunk, Elastic, QRadar) i uwzględniać mapowanie pól oraz specyficzne formaty wyjściowe. Przykładowo, możemy użyć komendy:

sigma convert -t splunk -p windows -r rules/

aby przekonwertować zestaw reguł Sigma do zapytań Splunk, uwzględniając mapowanie pól Windows. Wtyczki pipeline pozwalają dopasować nazwy pól Sigma do nazw pól w naszym środowisku (o czym więcej za chwilę).

Uncoder.io i inne konwertery online

warto wspomnieć o darmowych narzędziach społeczności, takich jak Uncoder.IO od SOC Prime, które umożliwiają wklejenie reguły Sigma i wybranie docelowej platformy. Narzędzie to obsługuje ponad 30 platform (m.in. Splunk, QRadar, Elastic, Sentinel, ArcSight, Sumo Logic), tłumacząc regułę Sigma na żądane zapytanie jednym kliknięciem. Jest to świetny sposób na szybkie eksperymenty z konwersją, bez potrzeby instalacji czegokolwiek.

Dlaczego konwersja jest potrzebna?

Obecnie większość platform SIEM/EDR nie obsługuje natywnie formatu Sigma, więc detekcje musimy zaimplementować w ich rodzimych językach zapytań. Sigma rozwiązuje problem „pisania tych samych reguł od zera” dla różnych systemów. Dzięki konwerterom możemy pisać regułę tylko raz w Sigma (np. wykrywającą podejrzane zachowanie) i automatycznie otrzymać ekwiwalent do Splunka, Elastic czy innego narzędzia. Poniżej przechodzimy do szczegółów integracji z poszczególnymi platformami.

Integracja Sigma ze Splunk (konwersja do SPL)

Splunk to jedna z najpopularniejszych platform SIEM, posiadająca własny język zapytań SPL (Search Processing Language). Konwersja reguł Sigma na SPL jest stosunkowo dobrze dopracowana – istnieje oficjalny backend Sigma dla Splunka oraz wsparcie w narzędziach typu Uncoder. najważniejsze kwestie przy integracji Sigma ze Splunk to odpowiednie mapowanie pól oraz uwzględnienie kontekstu indeksów i źródeł danych.

Mapowanie pól w Splunk: Sigma używa uogólnionych nazw pól, np. Image dla ścieżki procesu, CommandLine dla linii poleceń procesu, UserAgent dla agenta użytkownika w logach WWW itp. W Splunku nazwy pól zależą od źródła danych i modelu CIM (Common Information Model) lub konkretnych sourcetypów. Przykładowo:

• Dla logów Windows Security (zdarzenia 4688 – utworzenie procesu) pole odpowiadające Image to NewProcessName, a pole CommandLine może pojawić się jako Process_Command_Line jeżeli korzystamy z Sysmon lub dodatkowego parsowania.
• Dla zdarzeń Sysmon (proces tworzenia, EventID 1) nazwa ścieżki procesu to Image (zgodnie z oryginalnym polem w zdarzeniu Sysmon), a linia poleceń to CommandLine – tutaj akurat Sigma i Splunk będą mieć podobne nazwy, o ile używamy dodatku TA for Sysmon.
• Inny przykład: Sigma może użyć pola destination.ip, podczas gdy w Splunku w danym sourcetypie pole może nazywać się np. dest_ip albo dIP.

Dlatego istotne jest dostosowanie (mapowanie) pól Sigma do środowiska Splunk. Można to zrobić manualnie lub skorzystać z funkcji Sigma pipelines (w nowym CLI) bądź gotowych mapowań od społeczności.

Przykład konwersji Sigma -> Splunk

Weźmy prostą regułę Sigma wykrywającą próbę dumpingu pamięci procesu LSASS dzięki narzędzia ProcDump (popularna technika ataku, MITRE ATT&CK T1003.001). W formacie Sigma warunki są opisane tak, iż szukamy procesu procdump.exe uruchomionego z parametrami zawierającymi lsass.exe. Po konwersji do Splunk SPL (np. przy użyciu Uncoder.io) otrzymamy zapytanie podobne do:

index=winlogs source="WinEventLog:Security" EventCode=4688 (NewProcessName="*\\procdump.exe" AND CommandLine="*lsass.exe*")

Powyższa kwerenda Splunk wyszukuje w indeksie z logami Windows zdarzeń Security o EventCode 4688, gdzie nowy proces nazywa się procdump.exe (stosujemy wildcard * przed ścieżką, bo może być np. C:\Windows\...procdump.exe) i jednocześnie linia poleceń zawiera ciąg lsass.exe. Dzięki składni Splunk (warunek w nawiasach) zapewniamy, iż oba kryteria dotyczą tego samego zdarzenia.

Tworzenie alertu w Splunk: Mając gotowe zapytanie SPL, analityk może je przetestować w Search Head Splunka na żywych danych. jeżeli wynik jest zgodny z oczekiwaniami, następnym krokiem jest zapisanie wyszukiwania jako alertu (Saved Search z akcją alertową). W Splunku konfigurujemy: nazwę alertu, zakres czasowy (np. co 5 minut w ostatnich 5 minutach), warunek wyzwolenia (np. liczba wyników > 0) oraz akcję (np. wysłanie e-mail lub tworzenie notyfikacji w SOAR). W ten sposób reguła Sigma staje się w pełni funkcjonalną regułą detekcji w Splunk, wyzwalającą alarm przy próbie dumpingu LSASS przez ProcDump.

Wskazówki dla Splunk:

• Upewnij się, iż ograniczasz zapytanie do adekwatnych indeksów i sourcetypów – w powyższym przykładzie użyto index=winlogs i source="WinEventLog:Security" tylko jako przykład. W praktyce wstaw odpowiedni indeks (np. index=main lub inny, gdzie masz logi Windows) albo użyj sourcetype=XmlWinEventLog. Dzięki temu zapytanie będzie wydajniejsze.
• Rozważ wykorzystanie tstats i modeli danych CIM dla bardziej wydajnych wyszukiwań, zwłaszcza jeżeli Sigma reguła dotyczy częstych zdarzeń. Splunkowy backend Sigma umożliwia generowanie zapytań korzystających z tstats dla niektórych reguł (np. z wykorzystaniem datamodel Endpoint dla procesów).
• Sprawdź poprawność escape’owania znaków specjalnych. W Sigma można używać wyrażeń regularnych lub wildcardów, które w Splunk mogą wymagać ucieczki znaków (\). Konwertery zwykle robią to za nas, ale przy bardziej skomplikowanych wzorcach warto zweryfikować zapytanie.
• Dopasuj pola do swojej konfiguracji: o ile np. używasz własnych nazw pól lub inne aplikacje TA, może zajść potrzeba manualnej modyfikacji wygenerowanego SPL. Sigma dostarcza domyślne mapowania, ale każde środowisko Splunk może się nieco różnić.

Integracja Sigma z Elastic Stack (Elasticsearch / Kibana)

Platforma Elastic Stack (Elastic Security) również pozwala wykorzystać reguły Sigma, konwertując je na zapytania w języku zapytań Elasticsearch. Można tu wyróżnić dwa podejścia: użycie KQL (Kibana Query Language) w detekcjach Kibany lub bezpośrednio zapytania Elastic DSL (JSON) w API/Watcher. w tej chwili najwygodniej jest użyć KQL wbudowanego w Kibana Security, gdzie możemy tworzyć reguły detekcji z zapytań.

Mapowanie pól w Elastic: W przypadku Elastica najważniejsze jest zrozumienie, jak logi są zestrukturyzowane. Typowo, integracje (Beats, Elastic Agent) stosują ECS (Elastic Common Schema) – ujednolicony schemat pól. Sigma nie jest ściśle związana z ECS, ale wiele jej reguł dla popularnych źródeł (Windows, Zeek, AWS itp.) zostało tak napisanych, aby pasowały do ECS lub do natywnych pól danego źródła. Np.:

• Windows Event Log (Security 4688) w ECS będzie reprezentowany m.in. przez event.code: 4688, process.name (zamiast NewProcessName) oraz process.command_line. Sigma z kategorii process_creation może odwoływać się do Image i CommandLine – pipeline dla Elastic mapuje to na process.name i process.command_line zgodnie z ECS.
• W logach Sysmon w Elastic (przesyłanych przez Winlogbeat) wiele pól też mapuje się do ECS (process.executable dla pełnej ścieżki procesu odpowiada Sigma Image, itd.).
• Dla logów sieciowych Sigma może używać np. destination.port, co w ECS jest dokładnie destination.port – tu nie ma rozbieżności. Ale np. UserAgent w Sigma może być zmapowany na user_agent.original w ECS.

W praktyce większość konwersji Sigma na Elastic KQL stara się wykorzystywać ECS, ponieważ w tej chwili Kibana Security oczekuje domyślnie pól ECS przy regułach detekcji. jeżeli nasze dane odbiegają od ECS, możemy użyć funkcji przetwarzania (np. ingest pipeline) lub dostosować zapytanie manualnie po konwersji.

Przykład konwersji Sigma -> Elastic (KQL)

Wykorzystajmy ponownie scenariusz z wykrywaniem ProcDump na LSASS. Po konwersji reguły Sigma na zapytanie KQL (np. poprzez sigma CLI z backendem elasticsearch lub przez Uncoder.io) możemy otrzymać wyrażenie:

event.code:4688 and process.name:"procdump.exe" and process.command_line:*lsass.exe*

To zapytanie w Kibanie (w module Detections lub Discover) wyszukuje zdarzeń, gdzie event.code (ID zdarzenia) to 4688, nazwa procesu równa się „procdump.exe”, a linia poleceń zawiera „lsass.exe”. Składnia KQL używa dwukropka do przypisania wartości oraz gwiazdki * jako wildcard dla częściowego dopasowania. W odróżnieniu od Splunk, tutaj nie potrzebujemy operatora AND między warunkami – w KQL kolejne warunki domyślnie znaczą “i” (chyba iż użyjemy OR). Dla czytelności jednak dodano słowo and.

Jeśli korzystamy z Sysmon logów w Elastic, analogiczna reguła mogłaby wyglądać nieco inaczej (np. winlog.event_id:1 and process.executable:*\\procdump.exe and process.command_line:*lsass.exe* dla Sysmon EventID 1). Konwerter Sigma zwykle sam dopasuje warunki do adekwatnego źródła na podstawie logsource określonego w regule Sigma.

Wykorzystanie w Elastic Security: Tak wygenerowane zapytanie można wykorzystać przy tworzeniu nowej reguły detekcji w Kibana Security (moduł Detections). W interfejsie wybieramy typ reguły Custom Query i wklejamy nasze zapytanie KQL. Definiujemy następnie zakres indeksów (np. logs-security-windows* lub inne, gdzie są nasze eventy), harmonogram (np. uruchamianie co 5 minut) oraz akcje (alert, sygnalizacja na timeline itd.). Od tego momentu reguła Sigma „żyje” w Elastic, monitorując dane zgodnie z pierwotną logiką.

Wskazówki dla Elastic/KQL:

• Case sensitivity: KQL domyślnie jest case-insensitive dla liter (nie rozróżnia wielkości) w wartościach tekstowych, więc zwykle nie musimy martwić się o różne warianty (np. „lsass.exe” wykryje także „LSASS.EXE”). Jednak warto upewnić się co do ustawień analizatorów tekstowych w Elasticsearch – czasem pola typu keyword wymagają dokładnego dopasowania.
• Wildcards vs regex: Sigma pozwala na regexy (.* itp.), ale Kibana KQL obsługuje tylko wildcards * i ?. jeżeli reguła Sigma używa złożonego wyrażenia regularnego, konwerter może albo przełożyć go na wyrażenie Lucene (poprzez query DSL), albo uprościć do wildcard. W razie potrzeby można użyć zapytania Lucene w Kibana (poprzedzając je / ... /). Np. zamiast CommandLine|contains:-Enc Sigma, w KQL damy process.command_line:* -Enc *.
• Indices: Pamiętaj o wskazaniu adekwatnych indeksów w regule Kibana. jeżeli korzystasz z domyślnych indeksów Beats (np. winlogbeat-*), ustaw je w polu Indices podczas tworzenia reguły. Konwersja Sigma sama w sobie nie zawiera informacji o indeksach – to musimy określić manualnie zgodnie z naszym deploymentem Elastica.
• Testowanie na danych: Podobnie jak w Splunk, przetestuj zapytanie KQL w widoku Discover zanim stworzysz regułę. Upewnisz się, iż składnia jest poprawna i iż faktycznie wychwytuje spodziewane zdarzenia (i nie generuje zbyt wielu false positives).

Integracja Sigma z IBM QRadar (konwersja do AQL)

IBM QRadar używa języka zapytań AQL (Ariel Query Language) do wyszukiwania zdarzeń w swoim magazynie danych (bazie Ariel). Konwersja reguł Sigma na AQL jest możliwa dzięki dedykowanemu backendowi. W praktyce oznacza to, iż mając regułę Sigma, możemy uzyskać zapytanie SELECT ... FROM events WHERE ... spełniające kryteria reguły.

Mapowanie pól w QRadar: W przeciwieństwie do Splunka czy Elastica, gdzie nazwy pól wynikają z konfiguracji parserów lub schematów, w QRadar wiele informacji znajduje się w polu payload (surowa treść logu) oraz w standaryzowanych polach, jeżeli działają tzw. DSM (Device Support Module) dla danego źródła. Na przykład:

• Dla logów Windows Security QRadar posiada DSM, który wyodrębnia takie pola jak EventID (np. 4688), nazwa procesu, nazwa obrazu, użytkownik itp. Pola te mogą nazywać się podobnie do oryginalnych nazw z wydarzeń (np. NewProcessName może być dostępne jako pole w QRadar, a CommandLine raczej nie z Windows Security – bo log 4688 nie zawiera pełnej linii poleceń bez Sysmon). W przypadku Sysmon, jeżeli logi są wysyłane, DSM może wyciągać Process Name, Process CommandLine itp.
• Jeżeli DSM nie wydobywa jakiegoś pola, w zapytaniu AQL często trzeba użyć warunku na payload z operatorem LIKE lub ILIKE (nie rozróżnia wielkości liter) szukając ciągów znaków. Np. payload ILIKE '%procdump.exe%lsass.exe%' (oba ciągi w surowym logu).

Przykład konwersji Sigma -> QRadar

Pozostając przy scenariuszu wykrywania ProcDump+LSASS, wygenerowane zapytanie AQL może wyglądać przykładowo tak:

SELECT QIDNAME(qid) AS EventName, logsourcename(logsourceid) AS LogSource, UTF8(payload) FROM events WHERE EventID = 4688 AND UTF8(payload) ILIKE '%\\procdump.exe%' AND UTF8(payload) ILIKE '%lsass.exe%'

Co ono robi? Przeszukuje tabelę events pod kątem zdarzeń o EventID 4688 (proces utworzony) i sprawdza w polu tekstowym payload obecność ciągów „procdump.exe” oraz „lsass.exe”. Użyto ILIKE dla nieczułego na wielkość liter dopasowania oraz UTF8(payload) aby poprawnie przeszukiwać pole tekstowe. Zapytanie selekcjonuje też nazwę zdarzenia (QIDName) i nazwę źródła logów dla kontekstu, ale najważniejsze są warunki WHERE.

Jeśli QRadar ma dokładne pola (np. z DSM Sysmon), zapytanie mogłoby być bardziej precyzyjne: np. WHERE EventName = 'Process Create' AND NewProcessName ILIKE '%procdump.exe' AND CommandLine ILIKE '%lsass.exe%'. Niezależnie od metody, logika Sigma została zachowana: szukamy eventów tworzenia procesu z procdump i parametrem lsass.

Wdrożenie w QRadar

Uzyskane zapytanie AQL można wykorzystać na dwa sposoby:

1. Ad-hoc w wyszukiwarce QRadar (Ariel Search) – analityk może wkleić je w okno zapytań i uruchomić manualnie by znaleźć historyczne zdarzenia.
2. Jako podstawa reguły detekcji QRadar (CRE) – bardziej zaawansowane podejście to stworzenie reguły korelacyjnej (Custom Rule Engine) używającej warunków odpowiadających kryteriom. W QRadar reguły CRE nie wpisuje się jako AQL, ale graficznie buduje warunki (np.: when an event matches filter EventID=4688 AND payload contains 'procdump.exe’ AND payload contains 'lsass.exe’…). Sigma rule może więc posłużyć jako blueprint do zbudowania takiej reguły. Można też wykorzystać mechanizm Sigma to CRE poprzez IBM Cloud Pak for Security, który automatyzuje import reguł Sigma do wspólnej bazy poszukiwań (stąd w przykładzie z bloga IBM wykorzystano Sigma do uruchamiania zapytań w wielu narzędziach jednocześnie).

Wyzwania i wskazówki dla QRadar:

• Performance: Zapytania AQL skanują bazę zdarzeń, więc warunki typu ILIKE '%tekst%' mogą być mniej wydajne. Zawsze staraj się zawęzić zakres czasu (np. ostatnie 15 minut) i podstawowe filtry (EventID, LogSource) zanim użyjesz dopasowań tekstowych.
• Mapowanie pól: Sprawdź w Content Management QRadar, czy istnieją niestandardowe adekwatności wyciągające potrzebne pola. Być może warto stworzyć własne parsowanie (Regex Properties) dla linii poleceń z Sysmon, aby w przyszłości zapytania mogły być prostsze (np. CommandLine ILIKE '%-enc%' dla wykrycia EncodedCommand`).
• Sigma w oficjalnych integracjach: o ile używasz IBM Cloud Pak for Security, możesz skorzystać z tamtejszej integracji Sigma – zawiera ona konwertery do AQL i STIX, umożliwiając jednoczesne szukanie tych samych wzorców w wielu systemach bezpieczeństwa.

Integracja Sigma z Microsoft Sentinel (Azure Log Analytics)

Microsoft Sentinel (dawniej Azure Sentinel) to chmurowy SIEM oparty na Azure Log Analytics. Do formułowania detekcji używa języka zapytań KQL (Kusto Query Language), który jest również wykorzystywany w usługach takich jak Microsoft Defender 365 (Advanced Hunting). Reguły Sigma można przekształcić w zapytania KQL, gotowe do zastosowania w Sentinel jako Analytics Rule.

Mapowanie pól w Sentinel

W Sentinel dane z różnych źródeł trafiają do odpowiednich tabel w Log Analytics. Np. logi Windows Security trafiają do tabeli SecurityEvent, logi Azure AD do AzureActiveDirectory, a logi z Microsoft Defender do DeviceEvents lub DeviceProcessEvents (w zależności od typu zdarzenia). Sigma, definiując logsource (produkt: Windows, usługa: Security) nie „wie” o nazwie tabeli – to musimy określić manualnie przy tworzeniu zapytania. Na szczęście nazwa pola często pokrywa się z tym, co jest w tabeli, ponieważ Microsoft stara się używać przyjaznych nazw (np. NewProcessName, CommandLine w SecurityEvent będą dokładnie takie same). W Advanced Hunting (Defender) z kolei pola mają formę wielbajtową, np. FileName, ProcessCommandLine, itd., ale kontekst jest znany.

Przykład konwersji Sigma -> Sentinel (KQL)

Dla sytuacji ProcDump+LSASS, jeżeli chcemy szukać w logach Windows Security w Sentinel, zapytanie KQL może wyglądać tak:

SecurityEvent | where EventID == 4688 | where NewProcessName endswith @"\\procdump.exe" | where CommandLine contains "lsass.exe"

Tutaj wskazujemy explicite tabelę SecurityEvent (co odpowiada dziennikowi zdarzeń Windows). Następnie kolejnymi operatorami | where nakładamy warunki: EventID równe 4688, pole NewProcessName kończy się na \procdump.exe (użyto funkcji endswith z podwójnym backslash w stringu, aby oznaczyć pojedynczy backslash w wartości), a pole CommandLine zawiera frazę „lsass.exe”. Ten sposób zapisu gwarantuje, iż wszystkie trzy kryteria dotyczą tego samego rekordu (wydarzenia). Wynikowe zapytanie jest czytelne i wykonuje się na danych z ostatnich 24h domyślnie, ale w regule Sentinel ograniczymy okno czasu.

Analogiczne zapytanie można by skonstruować dla danych z Microsoft Defender (Advanced Hunting). Tam np. dla procesów tabela to DeviceProcessEvents, a pole z linią poleceń to ProcessCommandLine. Sigma reguła mogłaby być wykorzystana i przekształcona w:

DeviceProcessEvents | where FileName =~ "procdump.exe" | where ProcessCommandLine contains "lsass.exe"

(tutaj =~ oznacza dopasowanie nieczułe na wielkość liter). Widzimy, iż niezależnie czy to Sentinel czy Defender, Kusto Query Language pozwala wyrazić warunki z Sigma w dość prosty sposób.

Wdrożenie w Microsoft Sentinel

Aby zaimplementować regułę Sigma w Sentinel, tworzymy nową Analytics Rule typu Scheduled Query. W kreatorze wklejamy przygotowane zapytanie KQL, ustawiamy zakres czasu (np. Last 5 minutes) i częstotliwość uruchamiania (np. co 5 minut). Określamy też tzw. Alert threshold – np. gdy liczba wyników >= 1, generuj alert. Warto również uzupełnić detalami jak Tactics/Techniques (MITRE ATT&CK) zgodnie z tagami Sigma (jeśli reguła je zawierała). Po zapisaniu, Sentinel zacznie monitorować wskazaną tabelę pod kątem warunków z naszej reguły.

Wskazówki dla Sentinel/KQL:

• Optymalizacja zapytań: KQL potrafi gwałtownie przeszukiwać duże zbiory danych, ale dobre praktyki to filtrowanie jak najwcześniej. W powyższym przykładzie filtr EventID 4688 jest stosowany przed zawężeniem do nazw procesów – to dobrze. Unikaj wzorców typu contains bez wcześniejszych bardziej selektywnych warunków, aby nie skanować niepotrzebnie całej tabeli.
• Funkcje string vs operator: Zamiast contains można użyć operatora has lub has_cs (case-sensitive) w KQL, który bywa wydajniejszy w pewnych scenariuszach. Konwertery Sigma zwykle używają contains jako uniwersalnego odpowiednika zawierania. Warto wiedzieć, iż contains w KQL jest nieczuły na wielkość liter domyślnie.
• Mapowanie nazw pól: Jak wspomniano, w Sentinel nazwy pól często się pokrywają z Sigma lub są łatwe do ustalenia. W razie wątpliwości, skorzystaj z Schemat (schema) w Log Analytics, by podejrzeć strukturę tabeli i dostępne kolumny dla danego źródła. Przykładowo, dla logów Azure AD, Sigma może odnosić się do UserPrincipalName, co w Sentinel będzie np. TargetUserUpn – takie różnice warto wychwycić i poprawić w zapytaniu.
• Testuj w Log Analytics: Przed zrobieniem reguły, uruchom zapytanie w oknie Log Analytics (lub w Defender Advanced Hunting, jeżeli tam kierujesz) i sprawdź czy daje oczekiwane wyniki. Poprawki w zapytaniu KQL są normalną rzeczą – czasem trzeba dodać np. dodatkowy warunek filtrowania po kolumnie TimeGenerated czy doprecyzować ścieżkę.

Sigma a inne platformy SIEM/EDR (ArcSight, Sumo Logic, itp.)

Jedną z największych zalet Sigma jest jej szeroka adopcja – społeczność opracowała wsparcie dla wielu innych platform poza wymienionymi powyżej. Dzięki temu reguły Sigma można zastosować praktycznie wszędzie. Oto kilka przykładów:

Micro Focus ArcSight ESM

Dla ArcSight istnieje backend Sigma, który konwertuje reguły na warunki filtra ArcSight. Tradycyjnie ArcSight posługuje się filtrami opartymi o pola (tzw. Active Channel filters) i regułami w ramach ESM. Sigma może ułatwić tworzenie takich filtrów: np. reguła Sigma zostanie przekształcona w zestaw warunków (EventName, TargetProcessName itp.) zgodnych z terminologią ArcSight. W efekcie analityk może importować/wdrożyć detekcję bez manualnego pisania od nowa. Trzeba jednak pamiętać, iż ArcSight ma nieco inne nazewnictwo – np. pole FileName w Sigma może odpowiadać File Name w ArcSight (spacja) albo pewnym polom niestandardowym, więc czasem drobna korekta jest potrzebna.

Sumo Logic

Platforma Sumo Logic (chmurowa analiza logów) również może korzystać z Sigma. Konwerter Sigma na Sumo Logic tworzy zapytania w natywnym języku wyszukiwania Sumo (który przypomina pipeline znany ze Splunk czy Elastic). Przykładowo, reguła Sigma wykrywająca wpisy w rejestrze Windows (persystencja Run Keys) może zostać przełożona na zapytanie Sumo Logic używające operatorów typu parse i where w ich query language. Sumo Logic posiada specyficzne funkcje i format (np. wyrażenia w stylu | json auto do rozbijania pól JSON), więc konwersja Sigma stara się dopasować do standardowych wzorców. Dzięki temu choćby jeżeli używasz Sumo, możesz czerpać z publicznych reguł Sigma przy polowaniu na zagrożenia.

Inne platformy

Lista jest długa: m.in. Logpoint, RSA NetWitness, Google Chronicle, CrowdStrike Falcon LogScale, Graylog, InsightIDR, a choćby formaty jak STIX czy prosty grep. Wszędzie tam reguły Sigma mogą zostać wykorzystane. Na przykład, Google Chronicle posiada częściową zgodność z Sigma (pozwala importować niektóre reguły bez konwersji), a SOC Prime oferował integrację Sigma z Chronicle. Dla Graylog istnieje plugin, który umożliwia import reguł Sigma bezpośrednio do detektorów platformy. To pokazuje, iż Sigma jest naprawdę uniwersalnym językiem detekcji – pozwala dzielić się wiedzą między organizacjami niezależnie od używanych narzędzi.

Uwaga: Każda platforma ma własne niuanse, więc jakość konwersji może się różnić. zwykle reguły dotyczące popularnych źródeł (Windows, AWS, Azure, procesy, sieć) są dobrze obsłużone, natomiast bardzo specyficzne logi mogą wymagać własnej modyfikacji po konwersji.

Praktyczne wskazówki i wyzwania integracji Sigma z SIEM/EDR

Na koniec przedstawiamy kilka uniwersalnych porad dla osób wdrażających Sigma w swoich rozwiązaniach SIEM/EDR:

Mapowanie nazw pól

To podstawa udanej integracji. Sprawdź, czy domyślne mapowania Sigma odpowiadają Twoim danym. jeżeli nie, skorzystaj z plików mapujących lub funkcji pipeline Sigma CLI, aby zdefiniować własne odwzorowania. Np. zamień Image na process_path jeżeli Twoje logi używają takiego pola. Bez poprawnego mapowania reguła może nie zadziałać, mimo iż logika jest poprawna.

Dostępność logów

Upewnij się, iż Twój SIEM/EDR w ogóle zbiera logi potrzebne do działania reguły. Sigma może mieć reguły na zdarzenia, których możesz nie kolekcjonować (np. Sysmon, PowerShell Script Block Logging, ETW). Zanim zainwestujesz czas w konwersję, sprawdź pokrycie źródeł. jeżeli brakuje jakiegoś źródła, rozważ jego onboarding, albo dostosuj regułę do dostępnych danych.

Wydajność zapytań

Reguły Sigma z natury starają się być ogólne (uniwersalne). Po konwersji warto ocenić, czy zapytanie w danym SIEM nie jest zbyt „ciężkie”. Przykładowo, bardzo szerokie korelacje lub użycie wielu OR/regex mogą spowodować obciążenie systemu. Często można je zoptymalizować: dodać dodatkowe filtrowanie (czas, host, konkretna wartość), użyć indeksów/kontekstu (np. w Splunk – ograniczyć do określonych sourcetypów, w Sentinel – do konkretnej tabeli i wybranych kolumn). Zawsze testuj zapytania pod kątem wydajności na dużym zbiorze danych.

Fałszywe alarmy vs. brak alarmów

Po wdrożeniu reguły monitoruj jej działanie. Dwa typowe problemy to: false positives (zbyt ogólna reguła alarmuje na legalne aktywności) lub false negatives (reguła nie łapie wszystkiego, bo np. zabrakło jakiegoś warunku albo log jest ciut inny). Sigma daje dobry punkt wyjścia, ale dostosowanie do własnego środowiska (tuning) jest kluczowe. Dodaj wykluczenia (falsepositives w Sigma są opisane tekstowo – Ty musisz je zaimplementować w zapytaniu, np. dodać NOT CommandLine="*LegitProgram.exe*"), albo rozszerz regułę o dodatkowe sygnatury specyficzne dla Twojej infrastruktury.

Aktualizacja reguł

Sigma to żywy ekosystem. Pojawiają się nowe reguły reagujące na świeże zagrożenia, a istniejące są poprawiane. Warto śledzić repozytorium SigmaHQ na GitHub lub platformy takie jak Threat Detection Marketplace (SOC Prime). Integracja Sigma w Twoim SIEM powinna uwzględniać ten cykl życia – np. co pewien czas aktualizować reguły i ponownie je konwertować. Można to choćby zautomatyzować skryptami wykorzystującymi sigma CLI, by mieć zawsze aktualny zestaw detekcji.

Szersze scenariusze

Pamiętaj, iż pojedyncze reguły to nie wszystko. Sigma obsługuje też reguły korelacyjne (metadetections), które opisują sekwencje zdarzeń. w tej chwili nie wszystkie platformy SIEM w pełni wspierają takie zaawansowane reguły (np. Sentinel czy Splunk wymagają własnych mechanizmów do sekwencji), ale warto znać możliwości. Już teraz jednak można łączyć wyemitowane alerty z reguł Sigma w scenariusze śledcze – np. używając mechanizmów SOAR do wiązania alarmów.

Podsumowanie

Sigma zrewolucjonizowała podejście do tworzenia uniwersalnych reguł detekcji zagrożeń. W tej drugiej części naszej terzyczęściowej serii pokazaliśmy, jak przejść od abstrakcyjnej reguły Sigma do konkretnych implementacji w popularnych systemach SIEM (Splunk, Elastic, QRadar, Sentinel) oraz innych narzędziach bezpieczeństwa. Kluczem jest zrozumienie mapowania pól i możliwości oraz ograniczeń każdego silnika zapytań. Dzięki Sigma organizacje mogą szybciej dzielić się detekcjami, prowadzić spójny threat hunting w różnych środowiskach i reagować na zagrożenia niezależnie od używanych platform logowania.

W kolejnej części cyklu zajmiemy się bardziej zaawansowanymi aspektami Sigma, m.in. tworzeniem własnych reguł skrojonych pod specyficzne potrzeby oraz automatyzacją integracji z systemami bezpieczeństwa. Część 2 pokazała praktyczną stronę integracji – teraz czas wykorzystać te informacje w praktyce, by Wasze centrum SOC było krok do przodu przed atakującymi. Powodzenia w implementacji reguł Sigma na swojej platformie SIEM/EDR!

Artykuł ten jak i jego poprzednia i następna część powstały na podstawie autorskiego 113 stronicowego ebooka pełnego wiedzy którego otrzymasz zapisując się na newsletter:

Bibliografia