SIGMA – Uniwersalny Język Reguł Detekcji: Od Podstaw Do Integracji Z SIEM – Część 1

Wprowadzenie do detekcji opartej na logach i problemu braku standaryzacji

Detekcja zagrożeń oparta na logach jest fundamentem działania zespołów bezpieczeństwa (SOC) – to dzięki analizie dzienników zdarzeń systemów i aplikacji można wykrywać niepożądane aktywności. Historycznie jednak każde narzędzie SIEM (Security Information and Event Management) czy system analizy logów wprowadzało własny język zapytań lub reguł detekcji.

Przykładowo, Splunk używa składni SPL, Microsoft Sentinel używa Kusto Query Language (KQL), a IBM QRadar – AQL. Brak standaryzacji oznaczał, iż reguła detekcji stworzona dla jednego systemu nie mogła być bezpośrednio wykorzystana w innym. Działy bezpieczeństwa traciły czas na przepisywanie logiki detekcyjnej pod różne platformy, a dzielenie się wiedzą i regułami pomiędzy organizacjami było utrudnione. Z perspektywy całej branży cyberbezpieczeństwa brakowało uniwersalnego języka, który pozwoliłby opisywać scenariusze zagrożeń niezależnie od docelowego systemu analizy logów.

Konsekwencje braku standardu były odczuwalne. Reguły detekcji tworzone w silosach narzędzi vendorowych oznaczały duplikację wysiłku i ryzyko błędów – analitycy musieli znać składnię każdego SIEM z osobna. Co więcej, w świecie ciągle pojawiających się nowych zagrożeń potrzeba szybkiego udostępniania detekcji stała się kluczowa. Społeczność specjalistów bezpieczeństwa zaczęła poszukiwać sposobu, by opisane w jednym miejscu metody wykrywania ataków można było łatwo przenieść do dowolnego środowiska. Tak narodziła się idea uniwersalnego języka reguł detekcji, który działałby jak „język pośredni” pomiędzy ekspertami bezpieczeństwa a różnymi platformami SIEM.

Dlaczego potrzebujemy uniwersalnego języka reguł?

Wyobraźmy sobie, iż chcemy wykrywać określony scenariusz ataku (np. bruteforce – wielokrotne nieudane logowania sugerujące próby łamania haseł) w różnych narzędziach. W Splunku napiszemy zapytanie wyszukujące zdarzenia logowania nieudane (np. EventCode=4625), w Sentinel KQL użyjemy polecenia where EventID == 4625, a w QRadar AQL skonstruujemy zapytanie SQL-podobne z warunkiem EventID = 4625. Logika detekcji jest ta sama – poszukujemy wielu nieudanych logowań – ale musimy ją wyrazić na trzy różne sposoby. Uniwersalny język reguł detekcji eliminuje ten problem, pozwalając zapisać logikę raz, w abstrakcyjny sposób, a następnie automatycznie przekonwertować ją na składnię docelowego systemu. Dzięki temu zespół bezpieczeństwa może dzielić się regułami i „pisać raz, używać wszędzie” – niezależnie od tego, czy używa na co dzień Splunka, Elastic, QRadar, Azure Sentinela czy innej platformy.

Potrzeba takiego uniwersalnego podejścia wynika także z różnorodności schematów logów. W przeciwieństwie do sieci (gdzie pakiety mają ustandaryzowaną strukturę) czy plików binarnych, logi systemowe i aplikacyjne różnią się formatem i polami w zależności od źródła. Każdy dostawca SIEM definiuje własne nazwy pól (np. pole oznaczające nazwę procesu czy użytkownika), przez co reguła przeniesiona wprost między systemami mogłaby nie działać. Uniwersalny język musi więc wprowadzać pewną abstrakcję – wspólny sposób opisania zdarzeń – by potem specjalne konwertery przetłumaczyły go na natywny język zapytań danej platformy.

Dzięki takiemu podejściu zyskujemy kilka kluczowych korzyści:

• Niezależność od technologii: Reguły zapisane w języku uniwersalnym są odłączone od konkretnej składni SIEM. Możemy zmienić platformę (np. migrować z jednego SIEM do innego) bez pisania detekcji od zera.
• Współdzielenie wiedzy: Społeczność może łatwo wymieniać się gotowymi regułami. Istnieją publiczne repozytoria z tysiącami reguł gotowych do użycia – wystarczy je pobrać i przetłumaczyć na swój system, co dramatycznie skraca czas reagowania na nowe zagrożenia.
• Szybsze tworzenie reguł: Analitycy mogą skupić się na logice wykrywania (co chcą wykryć), zamiast na składni. To zwiększa produktywność i obniża próg wejścia dla nowych członków zespołu (nie muszą od razu znać zawiłości języka danego SIEM).
• Jednolite praktyki: Standaryzacja oznacza, iż reguły z różnych źródeł wyglądają podobnie, zawierają podobne elementy (np. opis, odniesienia, tagi MITRE itp.), co ułatwia ich zrozumienie i ocenę jakości.

W efekcie uniwersalny język reguł detekcji stał się naturalną odpowiedzią na problemy współczesnego Threat Huntingu i monitorowania bezpieczeństwa. Taki właśnie język stworzono w ramach projektu Sigma.

Historia i założenia projektu Sigma – geneza, rozwój, założenia projektowe

Projekt Sigma powstał, by zrealizować ideę uniwersalnego języka dla reguł detekcji opartych na logach. Został zapoczątkowany w 2017 roku przez dwóch ekspertów – Floriana Rotha oraz Thomasa Patzke. Obaj inspirowali się wcześniejszymi sukcesami otwartych standardów w innych dziedzinach, takich jak Snort (od 1998 r. standard pisania sygnatur dla ruchu sieciowego) czy YARA (od 2013 r. język opisu wzorców w plikach dla potrzeb analizy malware). Brakowało jednak ekwiwalentu tych rozwiązań w obszarze logów i SIEM – Sigma miała wypełnić tę lukę.

Założenia projektowe Sigmy od początku koncentrowały się na prostocie i elastyczności. Twórcy zdawali sobie sprawę, iż jeden uniwersalny format nie zdoła objąć wszystkich możliwych funkcji oferowanych przez różne SIEM (np. złożonych korelacji między zdarzeniami czy zaawansowanej analizy statystycznej). Dlatego Sigma ogranicza się do podstawowych zapytań i prostych korelacji, które pokrywają jednak >90% codziennych potrzeb detekcyjnych. To świadome uproszczenie miało zagwarantować, iż reguły da się bezstratnie konwertować na praktycznie każdy system. Innymi słowy – Sigma skupia się na najbardziej uniwersalnym wspólnym mianowniku zapytań detekcyjnych.

Sigma została zaprojektowana jako format otwarty i tekstowy (reguły zapisuje się w plikach YAML). Dzięki temu są one łatwe do odczytania dla człowieka oraz dobrze współpracują z narzędziami developerskimi (kontrola wersji Git, CI/CD itp.). Pierwsze wydanie Sigmy obsługiwało głównie logi Windows (szczególnie zdarzenia z Sysmon) – stąd wiele nazw pól wprowadzonych w specyfikacji pochodzi właśnie od konwencji Windows Sysmon. Z czasem jednak projekt rozwinął się, obejmując wsparcie dla Linux, macOS, popularnych aplikacji, usług chmurowych i wielu innych źródeł logów. Rdzeń języka pozostał ten sam, co umożliwia wykorzystywanie reguł Sigma do bardzo szerokiego spektrum przypadków użycia.

Ważnym kamieniem milowym rozwoju stało się zbudowanie wokół Sigmy społeczności i ekosystemu narzędzi. Reguły Sigma gwałtownie zaczęły powstawać i być współdzielone przez analityków na całym świecie. w tej chwili dostępnych jest tysiące gotowych reguł pokrywających rozmaite techniki ataków – od ataków na systemy Windows, przez wykrywanie złośliwych makr Office, po monitorowanie działań w chmurze. Projekt Sigma zyskał też wsparcie komercyjne i open-source’owe w postaci narzędzi konwertujących (o czym powiemy więcej w drugiej części artykułu). Przyjęto, iż format będzie stale rozwijany, aby nadążać za ewolucją technik ataków – pozostając jednak wiernym zasadzie kompatybilności wstecz (stare reguły powinny działać choćby po zmianach w specyfikacji).

W podsumowaniu filozofię Sigmy trafnie oddaje analogia: „Czym Snort jest dla ruchu sieciowego, a YARA dla plików, tym Sigma jest dla logów.”. Sigma stała się otwartym standardem dla dzielenia się inteligencją o zagrożeniach i metodami ich wykrywania w świecie logów SIEM. Dzięki niej społeczność może wspólnie reagować na pojawiające się techniki ataków, gwałtownie tworząc i udostępniając reguły gotowe do użycia na różnych platformach.

Porównanie Sigma z innymi językami reguł (SPL – Splunk, KQL – Sentinel, AQL – QRadar)

Sigma nie jest bezpośrednim zamiennikiem języków zapytań SIEM takich jak SPL, KQL czy AQL – raczej nakładką abstrakcyjną, która następnie jest tłumaczona na te języki. Warto jednak zrozumieć zasadnicze różnice i analogie między nimi:

• Splunk SPL (Search Processing Language): Język zapytań Splunka opiera się na potoku komend przetwarzających strumień zdarzeń. Składnia jest unikalna – zapytania zaczynają się od słowa search lub specyfikacji indeksu, a następnie stosuje się filtry i polecenia (np. stats, eval) rozdzielone pionowymi kreskami. SPL jest bardzo ekspresyjny i pozwala na zaawansowane operacje (agregacje, korelacje w oknach czasowych, wzbogacanie danych). Jego wadą jest znaczna krzywa nauki – składnia bywa zawiła, zwłaszcza dla osób bez doświadczenia ze Splunk. Przykładowe zapytanie SPL wyszukujące nieudane logowania Windows może wyglądać tak:
  index=security_win source="WinEventLog:Security" EventCode=4625
  (Powyżej szukamy w indeksie z logami Windows Security zdarzeń o kodzie 4625 oznaczającym nieudane logowanie.)
• Azure Sentinel KQL (Kusto Query Language): KQL to język zapytań wykorzystywany w chmurowym SIEM Microsoftu (Sentinel) oraz pokrewnych produktach (Defender). Jest składniowo zbliżony do SQL oraz do PowerShella. Zapytania w KQL operują na tabelach (np. SecurityEvent) i używają potoku operatorów poprzedzonych kreską |. W porównaniu do SPL, KQL jest bardziej zwięzły i czytelny, co wynika z relacyjnego podejścia do danych. Dla naszego przykładu nieudanych logowań zapytanie KQL mogłoby wyglądać następująco:
  SecurityEvent
  | where EventID == 4625
  (Tutaj SecurityEvent to tabela z logami bezpieczeństwa Windows w Sentinel, a filtr where wybiera zdarzenia o identyfikatorze 4625.)
• IBM QRadar AQL (Arial Query Language): AQL to język zapytań używany w QRadarze, mający składnię zbliżoną do standardowego SQL. Umożliwia pisanie zapytań typu SELECT-FROM-WHERE na bazie zdarzeń. Przykładowe zapytanie AQL dla wykrycia nieudanych logowań mogłoby wyglądać tak:
  SELECT * FROM events WHERE logsource='WinSecurity' AND EventID = 4625 LAST 1 HOURS
  (To zapytanie przeszukuje zdarzenia z ostatniej godziny, gdzie źródłem logu jest Windows Security, a ID zdarzenia to 4625. Składnia może się różnić w zależności od konfiguracji pól w QRadarze.)

W praktyce każde z powyższych rozwiązań ma swoją specyfikę i możliwości. Sigma natomiast nie jest językiem zapytań w tradycyjnym sensie – to uniwersalny format reguły opisujący co chcemy wykryć, a nie jak konkretnie wyszukać to w danym SIEM. Reguły Sigma zapisane w YAML są następnie konwertowane przez tzw. backendy na zapytania SPL, KQL, AQL lub innego docelowego systemu. Dzięki temu analityk nie musi znać szczegółów składni każdej platformy – może posłużyć się biblioteką lub narzędziem, które przełoży mu regułę Sigma na odpowiednie zapytanie.

Warto zauważyć, iż potęga Sigmy tkwi w jej przenośności, ale pewne różnice języków SIEM mają wpływ na konwersję. Na przykład Sigma ogranicza się do konstrukcji wspólnych dla wielu systemów: filtrowania po wartościach pól, podstawowych operatorów logicznych (AND/OR/NOT) czy prostego zliczania zdarzeń. Bardziej zaawansowane funkcje (np. złączenia między różnymi źródłami danych, skomplikowane agregacje czasowe) mogą nie być bezpośrednio wspierane w standardzie Sigma. Jednak w zdecydowanej większości przypadków reguła opisana w Sigmie da się automatycznie przetłumaczyć na poprawne zapytanie w docelowej platformie.

Dla zobrazowania, jak Sigma ujednolica reguły, spójrzmy na prosty przykład reguły w formacie Sigma i jej konwersje. Załóżmy, iż chcemy wykryć wspomniane wcześniej nieudane logowania (EventID 4625 w logach Windows Security):

Reguła Sigma (YAML): Możemy zapisać ją tak:

title: Wykrywanie nieudanych logowań (Windows) id: fab3c3f1-1234-4dcf-9a8e-111222333444 description: > Wykrywa zdarzenia nieudanego logowania w systemie Windows (EventID 4625). author: Jan Kowalski date: 2025/06/07 logsource: product: windows service: security category: authentication detection: selection: EventID: 4625 condition: selection falsepositives: - Brak (zdarzenie może wystąpić przy wpisaniu błędnego hasła) level: medium tags: - attack.credential_access - attack.t1110

Powyższa reguła Sigma jest niezależna od platformy – określa jedynie, iż szukamy zdarzenia logowania (kategoria authentication) w Windows Security, gdzie pole EventID ma wartość 4625. Mamy też w opisie metadane (tytuł, opis, autora, poziom zagrożenia itp.). Teraz, korzystając z dostępnych narzędzi, możemy ją przełożyć na konkretne zapytania SIEM:

• Splunk SPL (wygenerowane z reguły Sigma):
  index=* source="WinEventLog:Security" EventCode=4625
  (Sigma wie, iż dla logsource Windows Security należy użyć WinEventLog:Security jako źródła w Splunku oraz iż EventID odpowiada polu EventCode.)
• Azure Sentinel KQL:
  SecurityEvent | where EventID == 4625
  (Tutaj konwerter Sigma wykorzystał wiedzę, iż logi Windows trafiają w Sentinel do tabeli SecurityEvent, gdzie istnieje pole EventID.)
• QRadar AQL:
  SELECT * FROM events WHERE EventID = 4625
  (Zakładamy istnienie zmapowanego pola EventID w zdarzeniach QRadar – w praktyce może to wymagać odpowiedniego pipeline konwersji, by dopasować nazwy pól.)

Jak widać, jedna reguła Sigma skutkuje trzema różnymi zapytaniami, każde dostosowane do składni konkretnego systemu. Przy bardziej rozbudowanych regułach różnice byłyby większe – np. Sigma może wygenerować zapytanie KQL z kilkoma where i operatorami has czy contains, podczas gdy w Splunku analogicznie pojawi się kombinacja ... AND ... OR ... itp. najważniejsze jest jednak to, iż twórca reguły nie musi pisać tych zapytań manualnie. Wystarczy, iż poprawnie zdefiniuje logikę w Sigmie, a narzędzie (takie jak skrypt sigma-cli, usługa Uncoder.io, czy inny konwerter) wygeneruje mu odpowiednią składnię docelową.

Struktura reguły Sigma (YAML) – główne pola i format

Reguły Sigma zapisywane są w formacie YAML, co oznacza, iż mają postać czytelnych dla człowieka plików tekstowych z podziałem na sekcje klucz-wartość. Każda reguła Sigma zawiera zestaw pól (w sumie zdefiniowano kilkanaście możliwych pól top-level), z których część jest obowiązkowa, a część opcjonalna. Strukturę takiej reguły można podzielić na trzy główne komponenty:

Metadane (Metadata)

Tutaj znajdują się pola opisujące informacje o samej regule, jej kontekście i pomocnicze dane. Do metadanych zaliczamy m.in.

• title – tytuł reguły, krótko opisujący jej cel (wymagany).
• id – unikalny identyfikator (najczęściej GUID/UUID) pozwalający jednoznacznie odróżnić regułę. Ułatwia to śledzenie wersji i kolizji nazw.
• description – opis tekstowy, wyjaśniający logikę reguły i jej zastosowanie.
• status – status reguły (np. test – w fazie testów, stable – gotowa do użycia produkcyjnie, deprecated – przestarzała itp.).
• author – autor reguły (np. imię i nazwisko lub alias oraz e-mail/Twitter, co pomaga w kontakcie lub śledzeniu źródła).
• date – data utworzenia reguły.
• modified – data ostatniej modyfikacji (jeśli reguła była aktualizowana).
• references – lista odnośników do źródeł informacji, raportów czy wpisów na blogach, na podstawie których powstała reguła. Pozwala to zrozumieć kontekst (np. link do opisu malware, któremu reguła ma zapobiegać).tags – zestaw tagów kategoryzujących regułę. Zwykle obejmuje tagi MITRE ATT&CK (o nich więcej w kolejnej sekcji), a także inne kategorie, np. nazwę rodziny malware, do której reguła nawiązuje, czy ogólny obszar techniki ataku (np. attack.persistence).
• logsource – (omówiony niżej osobno) wskazuje, do jakich logów reguła jest przeznaczona.
• detection – (omówiony niżej) zawiera adekwatną logikę detekcji.

Metadane pełnią rolę informacyjną – nie wpływają na samo dopasowanie reguły w logach, ale są nieocenione dla analityków. Dobrze uzupełnione pola jak description, falsepositives, level (poziom istotności alarmu: low/medium/high/critical) czy falsepositives (opis znanych sytuacji generujących fałszywe alarmy) pomagają ocenić przydatność reguły i adekwatnie na nią reagować. Na przykład pole falsepositives może ostrzegać, iż dana reguła może zareagować na działania administratorów (legalne, ale podobne do ataku), a level podpowiada priorytet alarmu.

Log Source (Źródło logów)

Sekcja logsource określa, na jakich logach powinna zostać zastosowana reguła. Umożliwia to zawężenie kontekstu – inaczej formułujemy detekcje dla logów Windows, inaczej dla firewalli, a jeszcze inaczej dla np. usługi AWS CloudTrail. Logsource w Sigmie opisuje źródło logów dzięki kilku pól:

• category – ogólny typ zdarzeń lub systemu, np. process_creation (tworzenie procesu), authentication (uwierzytelnienie), network_connection (połączenia sieciowe), filesystem itp. Sigma posiada zdefiniowany standardowy zestaw kategorii, co ułatwia standaryzację.
• product – konkretny produkt lub platforma, z której pochodzą logi, np. windows, linux, okta, aws, azure, zeek itd.
• service – wskazanie konkretnego dziennika lub komponentu w ramach produktu. Przykładowo dla Windows wartości security, sysmon, powershell określą odpowiedni log systemowy; dla aws może to być cloudtrail lub inna usługa.
• definition – pole opcjonalne, pozwalające dodatkowo doprecyzować źródło logu (np. filtrować po nazwie źródła zdarzeń). To pole nie jest automatycznie wykorzystywane przy konwersji na zapytania, ale służy jako wskazówka dla analityków co do zakresu danych.

Poprawne ustawienie logsource jest krytyczne, ponieważ zapewnia, iż reguła zostanie zastosowana do adekwatnych zdarzeń. Przykładowo, o ile produkt to windows i service security, konwerter Sigmy wygeneruje w Splunk zapytanie z source="WinEventLog:Security", a w Sentinel wybierze tabelę SecurityEvent. Gdybyśmy pomylili się i np. dali service: sysmon dla detekcji ataku typu bruteforce (podczas gdy powinniśmy użyć security), reguła mogłaby nie zadziałać – bo Sysmon loguje inne typy zdarzeń (zdarzenia systemowe Sysmon zamiast logowań z bezpieczeństwa).

Detection (Logika detekcji)

To serce reguły Sigma – w tej sekcji definiujemy co dokładnie chcemy wykryć. Sekcja detection składa się zwykle z jednej lub kilku podsekcji (często nazywanych selekcjami), oraz warunku condition określającego, kiedy generować alarm. Przyjrzyjmy się elementom detekcji:

• selection / filters: W obrębie detection możemy zdefiniować jedną lub więcej nazwanych selekcji. Najczęściej spotykana jest po prostu jedna selection, ale możemy użyć dowolnych nazw (np. selection1, selection2, filter1, itp.) – nazewnictwo jest dowolne, chociaż zwyczajowo przyjęto używać selection dla głównych kryteriów oraz filter dla kryteriów wykluczających. W każdej selekcji podajemy warunki, jakie log ma spełniać. Warunki te przyjmują formę par pole: wartość i mogą wykorzystywać dopasowania dokładne lub z użyciem modyfikatorów operatorów. Przykładowo:
  • EventID: 4625 – warunek, iż pole EventID ma dokładnie wartość 4625.
  • CommandLine|contains: "lsass.exe" – warunek, iż w polu CommandLine występuje gdziekolwiek ciąg lsass.exe (modyfikator contains dodaje wildcardy * na początku i końcu ciągu).
  • Można podawać wiele warunków w jednej selekcji; domyślnie interpretowane są one jako logiczne AND (wszystkie muszą wystąpić w jednym zdarzeniu). Np.:

selection: User: "Administrator" EventID: 4720

będzie oznaczało zdarzenie, gdzie User to „Administrator” i EventID to 4720.

• Możemy też przekazać listę wartości dla jednego pola – lista w YAML jest traktowana jako logiczne OR między elementami. Np.:

selection: EventID: - 517 - 1102

oznacza zdarzenie, którego EventID to 517 lub 1102 (oba te kody zdarzeń w Windows oznaczają wyczyszczenie logów systemowych).

• condition: To pole określa finalny warunek alarmowania, łącząc zdefiniowane wyżej selekcje. jeżeli mamy tylko jedną selekcję o nazwie selection, zwykle condition to po prostu selection – co oznacza: wyzwól alarm, gdy wystąpi zdarzenie pasujące do selection. jeżeli mamy wiele sekcji, używamy ich nazw oraz operatorów logicznych. Przykłady:
  • condition: selection – alarm, gdy spełnione kryteria z sekcji „selection”.
  • condition: selection1 and selection2 – alarm, gdy oba zestawy kryteriów (selection1 i selection2) mają swoje dopasowania. Uwaga: domyślnie oznacza to, iż w tym samym zdarzeniu muszą wystąpić cechy z selection1 i jednocześnie cechy z selection2.
  • condition: selection and not filter – klasyczny wzorzec, gdzie selection definiuje potencjalnie złośliwe zdarzenie, a filter zawiera znane wyjątki/bezpieczne przypadki, które chcemy odfiltrować (czyli generujemy alarm tylko jeżeli zdarzenie pasuje do selection i jednocześnie nie pasuje do filtra).
  • condition: selection1 or selection2 – alarm, gdy spełniony jest którykolwiek z zestawów warunków (przydatne, gdy np. mamy kilka różnych sposobów osiągnięcia tego samego efektu przez atakującego).
  • Bardziej złożone warunki potrafią łączyć wiele elementów, np. condition: (selection1 or selection2) and not filter1 and not filter2 – ale warto zachować czytelność i nie komplikować bez potrzeby.

• timeframe: (opcjonalne) – Sigma umożliwia ograniczenie warunku do określonego przedziału czasu, np. timeframe: 1h użyte razem z warunkiem typu selection1 and selection2 mogłoby oznaczać, iż oba zdarzenia muszą wystąpić w ciągu godziny, by zainicjować alarm. Jednak wsparcie zaawansowanych korelacji czasowych jest ograniczone i zależy od implementacji backendu.

W powyższej definicji detekcji najważniejsze jest zrozumienie, iż Sigma operuje na poziomie pojedynczych zdarzeń (log entries), ewentualnie prostych korelacji między zdarzeniami, ale nie zastępuje dedykowanych mechanizmów correlation-rules SIEM, które np. liczą zdarzenia w czasie czy łączą różne typy logów. Pewnym rozszerzeniem możliwości Sigmy są tzw. Sigma Correlations (reguły korelacyjne w Sigmie), które pozwalają definiować warunki łączące wiele reguł bazowych – jest to jednak bardziej zaawansowany temat, wykraczający poza podstawy (i zostanie omówiony w osobnym materiale).

Wracając do struktury reguły: całość formatu została pomyślana tak, aby zarówno ludzie, jak i maszyny mogli efektywnie korzystać z reguł Sigma. Dzięki YAML i logicznemu podziałowi:

• Analityk czytając regułę gwałtownie zrozumie co wykrywa (title + description), gdzie (logsource) i jak (detection).
• Narzędzie automatyczne (skrypt) bez trudu sparsuje plik i wygeneruje na jego podstawie zapytanie do SIEM.

Jak czytać i pisać reguły Sigma – krok po kroku

Pisanie własnych reguł Sigma może wydawać się na początku skomplikowane, ale podejście krok po kroku ułatwia opanowanie tego procesu. Oto przewodnik, jak tworzyć reguły Sigma od podstaw:

1. Określ, co chcesz wykryćZacznij od jasno zdefiniowanej hipotezy detekcyjnej. Może to być konkretna technika ataku (np. uruchomienie mimikatz.exe w systemie) albo podejrzane zachowanie (np. masowe logowanie nieudane, wyczyszczenie logów). Ważne jest, by zrozumieć scenariusz – jakie ślady w logach pozostawia to zdarzenie? Jaki typ logu jest najbardziej odpowiedni? Np. aktywność Mimikatz pozostawi ślad w logach zdarzeń Windows (EventID 4688 – utworzenie nowego procesu, z nazwą procesu mimikatz.exe).

2. Wybierz odpowiednie źródła logów: Mając scenariusz, zastanów się, gdzie takie zdarzenie będzie widoczne. Czy chodzi o log systemowy Windows (Security, System, Application?), logi od EDR/antywirusa, a może logi aplikacyjne? W Sigmie przełoży się to na ustawienie pól w sekcji logsource. Wybierz product i service/category odpowiadające twojemu źródłu. jeżeli nie jesteś pewien, zajrzyj do dokumentacji Sigmy lub istniejących reguł – Sigma definiuje standardowe taksonomie dla popularnych logów (np. dla Windows używamy product: windows i określamy service na odpowiedni dziennik). Poprawne określenie logsource zapewni, iż reguła zadziała tam, gdzie powinna.

3. Zidentyfikuj najważniejsze wskaźniki (IOC/behaviour) w logach: Teraz określ, po czym rozpoznasz interesujące Cię zdarzenie. Czy jest to unikatowa wartość pola (np. Image zawiera mimikatz.exe lub EventID = 4720 dla tworzenia użytkownika w Windows)? A może kombinacja warunków (np. proces cmd.exe uruchomiony przez użytkownika domenowego poza godzinami pracy)? Wypisz sobie te warunki. W Sigmie będziesz je umieszczać w sekcji detection jako jedną lub więcej selection. Na tym etapie warto też pomyśleć o wykluczeniach – czy istnieją legalne sytuacje, które spełniają powyższe kryteria? jeżeli tak, przygotuj dodatkową selekcję filtrującą (np. filter), by odfiltrować znane false positive.

4. Stwórz szkic reguły w YAML: Zacznij od uzupełnienia sekcji metadanych – wpisz title, dodaj description opisujący co reguła robi (np. „Wykrywa próbę zrzutu pamięci procesu LSASS dzięki narzędzia ProcDump”), wpisz siebie jako author, ustaw level (np. high dla groźnych ataków, medium dla podejrzanych aktywności) i dodaj tags (co najmniej odpowiednie tagi MITRE ATT&CK, np. credential_access i t1003.001 dla LSASS dump). id możesz wygenerować jako UUID (ważne, by był unikalny – wiele gotowych reguł Sigma ma swoje ID właśnie jako UUID4). Pola date i modified też są przydatne – wpisz bieżącą datę, aby wiedzieć kiedy reguła powstała.

5. Określ logsource: Wypełnij sekcję logsource zgodnie z ustaleniami z kroku 2. Na przykład:

logsource: product: windows service: security category: process_creation

jeśli nasza reguła dotyczy tworzenia nowych procesów w Windows (Sysmon lub Security log). Dodaj category tylko jeżeli ma to sens i jest wspierane – często samo product+service wystarcza.

6. Zdefiniuj sekcję detection: Teraz wprowadź wybrane warunki z kroku 3. jeżeli masz jedną grupę warunków, użyj selection. jeżeli potrzebujesz wielu, nazwij je sensownie. Wpisz warunki jako pary pole:wartość lub listy. Zwróć uwagę na składnię YAML:

• Wcięcia (indentacja) są istotne – zwykle 2 spacje na każdy poziom zagnieżdżenia.
• Listy wartości zaczynające się od - muszą być wcięte pod kluczem.
• Używaj cudzysłowów jeżeli wartość zawiera spacje lub znaki specjalne.
• Warto rozważyć użycie modyfikatorów dla dopasowań częściowych lub wyrażeń regularnych. Sigma oferuje m.in.:
  • |contains – jak wspomniano, sprawdza czy podciąg występuje gdziekolwiek (dodaje wildcards).
  • |startswith / |endswith – dopasowanie początku/końca ciągu.
  • |re – dopasowanie wyrażeniem regularnym.
  • |base64 – dekoduje wartość z Base64 i wtedy porównuje (przydatne np. do wykrywania ciągów w zaszyfrowanych stringach w logach).
  • |cidr – dopasowanie IP do zakresu.
  • itp.
• Przykład prostej sekcji detection:

detection: selection: Image|endswith: '\procdump.exe' CommandLine|contains: 'lsass.exe' condition: selection

To wykrywa proces ProcDump (procdump.exe) z parametrem lsass.exe – czyli próbę zrzutu LSASS (tak jak w gotowej regule Sigma pokazanej wcześniej). jeżeli chciałbyś wykluczyć np. administratorów wykonujących to świadomie, można dodać sekcję filter z odpowiednim warunkiem (np. User in admin group) i zmienić condition na selection and not filter.

7. Przejrzyj całość i dodaj ostatnie szlify: Sprawdź, czy reguła jest kompletna i zgodna ze specyfikacją:

• Czy ma wymagane pola title, logsource i detection (oraz condition w środku detection)? Bez nich reguła nie będzie prawidłowa.
• Czy składnia YAML jest poprawna (zgadza się wcięcie, dwukropki po kluczach, myślniki przy listach)? Błędy formatowania mogą uniemożliwić parsowanie reguły.
• Czy dodałeś falsepositives? Warto tam opisać, jakie legalne sytuacje mogą wyzwolić regułę. Np. „Administracyjne zrzuty pamięci w ramach backupu”.
• Oceń poziom zagrożenia (level) – czy adekwatny? jeżeli to poważny atak (np. dump haseł), ustaw high lub critical. jeżeli bardziej pod obserwację niż pewny atak – medium.
• Zastanów się nad references – dobrze jest podać np. link do opisu ataku w bazie MITRE lub blogpost, z którego czerpałeś informacje. Inni docenią, a Ty sam po czasie będziesz wiedział skąd to się wzięło.

8. Przetestuj regułę: Zanim uznasz regułę za gotową, warto ją przetestować. Są na to dwa sposoby:

• Statycznie: użyj narzędzia konwertującego (np. sigma-cli albo webowej aplikacji jak Uncoder.io) i przekształć regułę na zapytanie dla swojego SIEM. Sprawdź, czy wygenerowana kwerenda wygląda sensownie i czy nie wymaga drobnych poprawek (czasem nazwy pól mogą się różnić minimalnie od tego, co masz w środowisku – np. EventID vs EventId).
• Dynamicznie: zaimplementuj regułę w SIEM (po konwersji) i sprawdź na danych historycznych, czy faktycznie wyłapuje to, co powinna, oraz czy nie generuje zbyt wielu fałszywych alarmów. Testy pozwalają dopracować warunki (np. może trzeba dodać kolejny filtr wykluczający coś, o czym nie pomyślałeś).

9. Opublikuj lub wdrażaj: jeżeli reguła działa poprawnie, możesz wdrożyć ją wewnętrznie (dodać do swojego zestawu use-case’ów w SIEM) oraz rozważyć podzielenie się nią ze społecznością. Ponieważ Sigma jest standardem otwartym, wiele osób publikuje swoje reguły na GitHubie czy platformach typu SOC Prime TDM. Wspólne repozytoria (np. główne SigmaHQ/sigma na GitHub) zawierają już olbrzymi zbiór reguł – możesz zgłosić Pull Request z nową regułą, by inni też mogli z niej skorzystać. To właśnie dzięki takim działaniom społeczności Sigma rozwija się dynamicznie.

Pisanie reguł Sigma to cenne ćwiczenie łączące wiedzę o atakach z praktyczną umiejętnością analizy logów. Im więcej reguł napiszesz, tym szybciej pójdzie tworzenie kolejnych. Warto też czytać istniejące reguły – to kopalnia wiedzy zarówno o technikach ataków, jak i o sprytnych sposobach ich wykrywania.

Mapa do MITRE ATT&CK – znaczenie tagów i standaryzacja detekcji

Jednym z elementów, które wyróżniają reguły Sigma (podobnie jak wcześniej wspomniane YARA czy Snort), jest silny nacisk na tagowanie detekcji i odniesienie ich do znanych taksonomii ataków. W szczególności, Sigma zachęca do mapowania każdej reguły na framework MITRE ATT&CK poprzez dodanie odpowiednich tagów w polu tags. MITRE ATT&CK to powszechnie uznawana matryca taktyk i technik ataków – służy jako wspólny język opisu sposobów działania adversarzy. Jak to działa w praktyce z Sigmą?

Każda technika w MITRE ATT&CK ma unikalny identyfikator w formacie TXXXX (np. T1003 to Credential Dumping, T1566 to Phishing itd., często z trzeciopoziomowym numerem dla subtechnik, np. T1003.001 oznacza LSASS Memory jako szczególny przypadek zrzucania poświadczeń). Tworząc regułę Sigma, analizujemy, której techniki dotyczy wykrywane zdarzenie i dodajemy odpowiedni tag attack.tXXXX. Dodatkowo często dodaje się tag taktyki, np. attack.credential_access dla technik kradzieży poświadczeń, attack.persistence dla utrwalania obecności, itp. Dzięki temu, gdy ktoś patrzy na regułę, od razu widzi, z jakim typem zagrożenia jest związana.

Na przykład, wspomniana wyżej reguła wykrywająca zrzut LSASS przez ProcDump miała tagi:

tags: - attack.credential_access - attack.t1003.001 - sysinternals

co jednoznacznie wskazuje, iż dotyczy techniki Credential Access (dostęp do poświadczeń), konkretnie podtechniki OS Credential Dumping: LSASS Memory (T1003.001). Dodatkowy tag sysinternals informuje, iż użyto narzędzia z pakietu Sysinternals (co jest kontekstem technicznym).

Dlaczego to ważne? Standaryzacja detekcji poprzez mapowanie na MITRE ATT&CK ma kilka zalet:

• Ułatwia gap analysis: Zespół bezpieczeństwa może przeglądać swoją bibliotekę reguł Sigma i sprawdzić, które techniki MITRE są pokryte detekcjami, a gdzie są luki. jeżeli żadna reguła nie ma tagu z danej taktyki/techniki, to sygnał, iż być może brakuje pokrycia dla pewnego typu ataku.
• Przyspiesza reagowanie na zagrożenia: Gdy pojawia się nowy Threat Intel opisujący np. kampanię ataku wykorzystującą określone techniki, możemy gwałtownie wyszukać w repozytorium Sigma reguły oznaczone tymi technikami. jeżeli ich nie mamy – wiemy, co zaimplementować w pierwszej kolejności.
• Ujednolica nazewnictwo: Zamiast opierać się na wolnym opisie tekstowym, tagi ATT&CK narzucają pewien standard słownictwa. „Użycie Mimikatz do dumpu haseł” może być nazwane różnie, ale tag attack.t1003 jest jednoznaczny. To redukuje zamieszanie i błędne kategoryzacje.
• Integracja z narzędziami raportującymi: Wiele platform (np. SIEM czy dedykowane narzędzia do zarządzania use-case’ami) potrafi wykorzystać te tagi do automatycznych mapowań lub generowania statystyk (np. dashboard, który pokazuje procent pokrycia ATT&CK przez nasze detekcje).

Poza MITRE ATT&CK, Sigma wykorzystuje też inne formy standaryzacji w tagach. Często dodawane są tagi wskazujące np. na rodzaj ataku (attack.), ale również na rodzaj zagrożenia (np. tool.mimikatz jeżeli reguła dotyczy konkretnego narzędzia, os.windows jeżeli specyficzna dla Windows, itp.). Istnieje choćby oficjalny Sigma Tagging Appendix, w którym zdefiniowano konwencje nazywania tagów, by społeczność stosowała wspólny schemat. To wszystko sprawia, iż detekcje stają się bardziej przenośne semantycznie – nie tylko przenosimy zapytania między systemami, ale też przenosimy kontekst i klasyfikację tych zapytań.

Standaryzacja detekcji w Sigmie przejawia się również w spójności formatów. Na przykład pola logsource mają określone słowniki wartości (kategorie, nazwy produktów), co ułatwia zrozumienie reguły bez zaglądania w specyfikę danej infrastruktury. Wiadomo, iż product: windows oznacza system Windows, a np. service: security to dziennik zdarzeń bezpieczeństwa Windows – i tak samo będzie to interpretowane przez każdego, kto czyta regułę, niezależnie od firmy/instytucji. Taka unifikacja języka detekcji jest ogromnym krokiem naprzód w profesjonalizacji obszaru Threat Detection & Response.

Podsumowując, mapowanie reguł Sigma do MITRE ATT&CK i konsekwentne tagowanie zwiększa wartość każdej reguły. Daje analitykom kontekst ataku, pozwala szybciej zrozumieć, co adekwatnie wykryto (np. „to alert z kategorii Lateral Movement” – inaczej potraktujemy go niż alert z kategorii Credential Access), a menedżerom bezpieczeństwa i architektom – wgląd w pokrycie obszarów ataku przez obecne mechanizmy obronne. W świecie, gdzie współdzielenie informacji jest kluczowe, takie standardy są nieocenione. Sigma nie tylko ujednolica składnię reguł, ale również ujednolica język opisu zagrożeń, którym posługują się zespoły SOC i narzędzia bezpieczeństwa.

Podsumowanie i dalsze kroki

Sigma zrewolucjonizowała podejście do tworzenia i dzielenia się regułami detekcji – rozwiązując problem braku standaryzacji i zamykając lukę między wiedzą o zagrożeniach a praktycznymi wdrożeniami w narzędziach bezpieczeństwa. Dzięki czytelnemu formatowi YAML i uniwersalnej strukturze, analitycy mogą efektywnie opisywać zagrożenia w sposób zrozumiały zarówno dla ludzi, jak i maszyn. Przekonaliśmy się, iż Sigma jest prosta w podstawach, a jednocześnie na tyle elastyczna, by objąć większość codziennych scenariuszy wykrywania ataków. Jej siła tkwi w technologicznej agnostyczności – reguły nie zależą od konkretnego silnika SIEM – oraz w społecznościowym wsparciu, które dostarczyło już ogrom biblioteki gotowych detekcji do wykorzystania od zaraz.

W pierwszej części przyjrzeliśmy się fundamentom: od genezy potrzeby uniwersalnego języka, przez strukturę reguł Sigma i sposoby ich tworzenia, aż po znaczenie standaryzacji tagów (MITRE ATT&CK) dla jakości detekcji. Jednak stworzenie reguły to dopiero początek drogi. Jak z niej zrobić realne, działające rozwiązanie w naszym środowisku? Tu wkraczają narzędzia i integracje, które spajają Sigmę z ekosystemem Security Operations.

W drugiej części artykułu skupimy się właśnie na praktycznym wykorzystaniu Sigmy w organizacji. Omówimy dostępne narzędzia konwertujące (m.in. nowe oficjalne sigma-cli oparte na bibliotece pySigma), sposoby automatyzacji wdrożeń reguł poprzez CI/CD i integrację z systemami kontroli wersji, a także metody sprawdzania jakości i testowania reguł. Zajrzymy, jak Sigma współpracuje z popularnymi platformami SIEM i EDR – czy to poprzez natywne wsparcie, czy przez zewnętrzne skrypty. Nie zabraknie dyskusji o wersjonowaniu detekcji (bo reguły też wymagają utrzymania i ulepszania z czasem) oraz o tym, jak zorganizować pipeline od pomysłu na regułę, przez jej test, po automatyczne wdrożenie i monitorowanie skuteczności.

Sigma otwiera drzwi do bardziej zwinnego i kooperacyjnego podejścia do cyberobrony. Mając solidne podstawy teoretyczne z części pierwszej, w drugiej przejdziemy do konkretów, tak aby każdy SOC mógł w pełni wykorzystać możliwości, jakie daje ten uniwersalny język detekcji. Pozostańcie na nasłuchu! Detekcja oparta na Sigmie dopiero nabiera rozpędu, a jej integracja z narzędziami bezpieczeństwa może stać się Waszym kolejnym asem w rękawie w walce z zagrożeniami.

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

Bibliografia