Detection engineering i Sigma: reguły SIEM w praktyce

Detection engineering to proces projektowania, testowania, wdrażania i utrzymywania analityk bezpieczeństwa. Sigma zapewnia przenośny format opisu logiki detekcyjnej, ale sama reguła YAML nie gwarantuje wykrycia. Skuteczność zależy od kompletności danych, mapowania pól, semantyki backendu, jakości testów, obsługi wyjątków, triage oraz reakcji.

Najważniejsza odpowiedź brzmi: reguła SIEM jest produkcyjnym komponentem o kontrakcie danych, właścicielu, testach, wersji, SLO i procedurze wycofania. Powinna zaczynać się od hipotezy o zachowaniu przeciwnika, a kończyć mierzalnym wynikiem operacyjnym. Sigma oddziela intencję detekcji od języka zapytania, lecz translację trzeba zweryfikować dla konkretnego SIEM. „Napisać raz, uruchomić wszędzie” bez testu parsera i danych jest niebezpiecznym uproszczeniem.

Czym detection engineering różni się od pisania alertów

Pojedynczy alert może powstać jako szybka odpowiedź na incydent. Detection engineering buduje cykl życia, który pozwala ten alert powtarzalnie utrzymać. Obejmuje:

1. identyfikację zachowania i skutku, który organizacja chce wykryć;
2. ustalenie wymaganego źródła, schematu i jakości danych;
3. zakodowanie logiki oraz mapowanie do MITRE ATT&CK;
4. testy pozytywne, negatywne i integracyjne;
5. wdrożenie etapowe, obserwację i tuning;
6. playbook triage i reakcję;
7. metryki jakości, pokrycia i kosztu;
8. przegląd po zmianie systemu, parsera lub techniki;
9. deprecjację i bezpieczne wycofanie.

Ten proces łączy cykl Cyber Threat Intelligence z operacjami SOC. CTI dostarcza hipotez i kontekstu, ale analityka musi opierać się na zachowaniu widocznym w danych organizacji, a nie wyłącznie na krótkotrwałym IOC.

Hipoteza detekcyjna przed kodem

Dobra hipoteza ma formę możliwą do sfalsyfikowania:

Jeżeli principal o określonej klasie zaufania wykona nietypową zmianę kontroli bezpieczeństwa, a następnie użyje nowej zdolności w krótkim oknie, to źródła A i B zarejestrują pola X, Y i Z, co pozwoli odróżnić to zachowanie od zatwierdzonej administracji.

Hipoteza powinna zawierać:

Element	Pytanie
Zachowanie	Co przeciwnik lub nadużywający administrator robi?
Cel	Jaki skutek bezpieczeństwa chcemy ograniczyć?
Principal	Które konto, host, workload lub proces inicjuje działanie?
Telemetria	Które źródło widzi zachowanie i z jaką latencją?
Pola	Które wartości są obowiązkowe dla logiki oraz triage?
Baseline	Jak wygląda legalna administracja i automatyzacja?
Okno	Czy liczy się pojedyncze zdarzenie, liczba, sekwencja lub brak zdarzenia?
Reakcja	Co analityk może bezpiecznie zrobić po alercie?

Jeżeli nie da się wskazać danych potwierdzających hipotezę, najpierw trzeba poprawić logowanie. Reguła oparta na polu, którego połowa sensorów nie dostarcza, daje pozorne pokrycie.

Data contract: umowa między źródłem a analityką

Data contract definiuje semantykę zdarzenia, nie tylko nazwę indeksu. Powinien określać:

• właściciela i system źródłowy;
• wersję produktu, konfigurację audytu oraz zakres populacji;
• sposób transportu, parser, normalizację i strefę czasową;
• wymagane pola, typy, dopuszczalne wartości i znaczenie null;
• stabilny identyfikator użytkownika, urządzenia, procesu i sesji;
• oczekiwaną latencję, wolumen, retencję i tolerancję utraty;
• reguły redakcji danych wrażliwych;
• kontrolę zmian oraz komunikację o zmianie schematu;
• test-canary potwierdzający ingest end-to-end.

Kontrakt powinien rozróżniać „pole nie występuje”, „wartość jest pusta” oraz „parser nie rozpoznał formatu”. Dla liczby, adresu IP, listy i tekstu backend może stosować inne operatory. Normalizacja bez zachowania surowego zdarzenia utrudnia debugowanie, dlatego warto przechowywać raw event w kontrolowanej warstwie, jeżeli polityka prywatności na to pozwala.

CISA wskazuje centralizację i ochronę logów jako podstawę widoczności. Dla każdej reguły trzeba więc znać nie tylko źródło logiczne, ale również odsetek aktywów raportujących, opóźnienie oraz sposób wykrywania przerwy w telemetrii.

Sigma logsource: abstrakcja, którą trzeba zmapować

W Sigma Rules Specification 2.1 sekcja logsource opisuje źródło przez pola takie jak category, product, service i opcjonalne definition. Nie wskazuje automatycznie indeksu, tabeli ani parsera w konkretnym SIEM.

Przykładowo kategoria process_creation określa semantykę zdarzenia utworzenia procesu. Organizacja nadal musi zdecydować, czy dane pochodzą z Windows Security, Sysmon, EDR czy innego sensora, które pole reprezentuje obraz, parent, command line, signer i user oraz które endpointy faktycznie raportują.

Dlatego utrzymujemy mapę:

Sigma logsource
  -> źródło fizyczne i wersja
  -> parser / processing pipeline
  -> schemat znormalizowany
  -> indeks, tabela lub dataset
  -> backend Sigma i wygenerowane zapytanie
  -> reguła/alert w SIEM

Zmiana parsera jest zmianą zależności reguły i powinna uruchamiać testy regresyjne.

Anatomia dobrej reguły Sigma

Reguła zawiera metadane, logsource oraz sekcję detection. Przydatne pola to stabilny UUID id, status, opis, autor, daty, referencje, tagi, poziom oraz znane false positives. Identyfikator nie powinien zmieniać się przy zwykłej aktualizacji logiki; nowy ID jest uzasadniony, gdy powstaje inna analityka.

Sekcja detection składa się z nazwanych selekcji i condition, która łączy je logicznie. Modifiers, na przykład dopasowanie początku, końca, fragmentu, wyrażenia regularnego lub zakresu CIDR, zmieniają semantykę porównania. Ich wsparcie oraz koszt zależą od backendu.

Bezpieczny przykład do testowania pipeline’u może wykorzystywać syntetyczny canary:

title: Detection Pipeline Canary Process
id: 9a0cd600-1ed0-4f0a-8946-10aa7df0bb72
status: test
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\detection-canary.exe'
    CommandLine|contains: '--sigma-validation'
  condition: selection
falsepositives:
  - Approved detection pipeline test
level: informational

To nie jest reguła ataku. Służy do sprawdzenia schematu, translacji i przepływu alertu bez wykonywania niebezpiecznej techniki. Produkcyjna reguła powinna dodatkowo opisać kontekst, ryzyko, ATT&CK, wymagane pola i kroki triage.

Correlation rules: liczba, różnorodność i sekwencja

Pojedyncze zdarzenie często jest legalne. Ryzyko wynika z częstotliwości, liczby unikalnych wartości albo kolejności działań. Sigma Correlation Rules Specification definiuje korelacje odwołujące się do reguł bazowych oraz typy obejmujące między innymi liczbę zdarzeń, liczbę różnych wartości, relację czasową i uporządkowaną sekwencję.

Projektując korelację, określ:

• reguły bazowe i ich stabilne identyfikatory lub nazwy;
• group-by, który reprezentuje tę samą encję, np. user, host albo session;
• timespan uzasadniony zachowaniem i latencją danych;
• próg oraz kierunek porównania;
• tolerancję zdarzeń spóźnionych i duplikatów;
• semantykę braku jednego etapu;
• sposób prezentacji całej sekwencji w alercie.

Korelacja temporalna nie może zakładać idealnej kolejności ingestu. Zdarzenia z endpointu i chmury mogą dotrzeć w różnym czasie. SIEM powinien używać czasu zdarzenia, a pipeline zachować również czas odbioru.

Sigma filters i zarządzanie wyjątkami

Sigma Filters Specification pozwala oddzielić logikę detekcji od filtrów dopasowanych do środowiska. To korzystne, ponieważ globalna reguła pozostaje czytelna, a wyjątek biznesowy ma własnego właściciela i cykl życia.

Każdy filtr powinien mieć:

• konkretny zakres: proces, signer, konto, host, ścieżka lub para zachowań;
• uzasadnienie oraz link do zatwierdzenia;
• właściciela biznesowego i technicznego;
• datę utworzenia oraz wygaśnięcia;
• test negatywny pokazujący, co dokładnie wyklucza;
• monitorowanie, czy wyjątek nie poszerzył się po zmianie danych.

Nie wykluczaj całej domeny, produktu, administratorów ani katalogu systemowego tylko dlatego, że pierwsza wersja generuje szum. To przenosi false positives do blind spotu.

Translacja backendowa: Sigma nie usuwa różnic SIEM

Sigma opisuje intencję, a backend oraz processing pipeline tworzą język docelowy. Translacja może zmieniać nazwy pól, wartości, wildcardy, escaping, typy i sposób korelacji. Różne silniki inaczej obsługują case sensitivity, regex, tablice, null, kolejność czasu i optymalizację.

Przed wdrożeniem sprawdź wygenerowane zapytanie:

1. Czy wskazuje właściwy dataset i partycję czasu?
2. Czy pola mają poprawny typ i mapowanie?
3. Czy backslash, wildcard i regex zachowały znaczenie?
4. Czy not nie usuwa zdarzeń z brakującym polem?
5. Czy filtr czasu używa event time, czy ingest time?
6. Czy zapytanie ma akceptowalny koszt i latencję?
7. Czy korelacja grupuje właściwą encję?

Regułę i wygenerowany artefakt warto przechowywać razem z wersją backendu oraz processing pipeline. To ułatwia odtworzenie, dlaczego po migracji SIEM wynik się zmienił. Różnice między platformami wyjaśnia też porównanie SIEM, XDR i EDR.

Testy jednostkowe, integracyjne i negatywne

Testy jednostkowe

Test jednostkowy podaje mały zestaw kontrolowanych zdarzeń i sprawdza, które mają spełnić selekcję. Obejmuje każdą gałąź warunku, modyfikator, brak pola, różną wielkość liter i wartości graniczne. Walidujemy również schema YAML, UUID, status, tagi i linki.

Testy integracyjne

Test integracyjny przepuszcza zdarzenie przez realny collector, parser, normalizację, storage, wygenerowane zapytanie i mechanizm alertowania. Potwierdza czas, mapowanie hosta/usera, wzbogacenie, deduplikację, routing i widoczność w konsoli analityka.

Testy negatywne

Zbiór negatywny zawiera legalną administrację, automatyzację, skanery, wdrożenia, aktualizacje i zdarzenia podobne do techniki, ale pozbawione kluczowego elementu. Near-miss jest cenniejszy niż zupełnie niezwiązany log, bo sprawdza precyzję granicy.

Testy regresyjne

Uruchamiaj wszystkie fixture po zmianie reguły, parsera, providera danych, backendu, allowlisty i wersji SIEM. Regressja powinna porównywać wynik oraz koszt zapytania.

Tuning bez utraty pokrycia

Tuning zaczyna się od klasyfikacji false positive:

• błąd danych lub parsera;
• legalne zachowanie wymagające kontekstu;
• zbyt szeroka hipoteza;
• niewłaściwy próg lub okno;
• brak wzbogacenia asset/user;
• alert duplikowany przez inną analitykę;
• zdarzenie prawidłowo wykryte, lecz o niskim skutku.

Kolejność poprawy ma znaczenie. Najpierw napraw dane i wzbogacenie, potem zawężaj selekcję, dodawaj korelację i dopiero na końcu filtruj konkretne wyjątki. Obniżenie severity nie zmniejsza liczby alertów. Globalna allowlista może poprawić dashboard, ale pogorszyć bezpieczeństwo.

Przeglądaj wyjątki według wieku, liczby dopasowań i właściciela. Wyjątek, który nigdy nie pasuje, może być niepotrzebny; taki, który obejmuje znaczną część ruchu, wymaga ponownego modelowania.

Alert triage jako część projektu reguły

Reguła powinna dostarczyć analitykowi:

• dlaczego zachowanie jest podejrzane;
• principal, host, proces, źródło i cel;
• pełne wartości dopasowane przez selekcję;
• początek, koniec i liczbę zdarzeń;
• baseline oraz podobne aktywa;
• linki do surowych logów i powiązanych alertów;
• kroki weryfikacji i kryteria eskalacji;
• bezpieczne działania containment oraz właściciela systemu.

Jeżeli triage wymaga każdorazowo ręcznego odtworzenia wszystkich danych, koszt operacyjny ukrywa się poza regułą. Integracja z monitoringiem bezpieczeństwa dla MŚP powinna uwzględniać kolejki, priorytety, godziny obsługi i dostęp do kontekstu klienta.

Wersjonowanie i lifecycle analityki

Przechowuj reguły, filtry, fixture, dokumentację i pipeline translacji w kontroli wersji. Pull request powinien pokazywać zmianę logiczną, wynik testów, różnicę zapytania backendowego, koszt, plan wdrożenia i rollback. Status Sigma powinien odzwierciedlać dojrzałość, a nie marketing.

Przykładowe bramy:

• draft/experimental — hipoteza i dane są badane;
• test — reguła ma fixture i działa w środowisku obserwacyjnym;
• stable — ma właściciela, SLO, playbook, testy i historię jakości;
• deprecated — zastąpiona lub bez odpowiedniej telemetrii;
• retired — wyłączona po analizie zależności i pokrycia zastępczego.

Wycofanie wymaga sprawdzenia dashboardów, korelacji, playbooków i raportów korzystających z ID reguły.

Metryki: precision, recall, coverage i health

Precision to TP / (TP + FP) — jaki udział alertów reprezentuje docelowe zachowanie. Recall to TP / (TP + FN) — jaki udział docelowych przypadków wykryto. W produkcji mianownik recall jest zwykle nieznany, dlatego szacujemy go na kontrolowanym zbiorze wariantów, wynikach purple team i incydentach retrospektywnych.

Mierz również:

• odsetek aktywów dostarczających wymagane dane;
• ingest latency i alert latency;
• liczbę alertów, zdarzeń i unikalnych encji;
• medianę oraz percentyle czasu triage;
• alert-to-case i case-to-incident conversion;
• wiek wyjątków i odsetek ruchu przez nie wykluczony;
• koszt wyszukiwania oraz storage;
• czas od zmiany schematu do wykrycia awarii;
• pokrycie ATT&CK z uwzględnieniem jakości, a nie liczby tagów.

Tag ATT&CK nie dowodzi skuteczności. Jedna testowana analityka z pełną telemetrią jest wartościowsza niż dziesięć reguł wskazujących tę samą technikę bez danych. MITRE ATT&CK jest modelem zachowań i wspólnym językiem, nie automatycznym wynikiem ryzyka.

Bezpieczna walidacja purple team

Purple team powinien wspólnie ustalić hipotezę, oczekiwane zdarzenia, zakres, dane wyłączone, rollback i kryteria sukcesu. Walidacja ma kilka poziomów:

1. syntetyczny fixture sprawdza samą logikę;
2. canary generuje legalne, oznaczone zdarzenie przez realny pipeline;
3. kontrolowana symulacja odwzorowuje bezpieczną część zachowania ATT&CK;
4. test end-to-end sprawdza alert, triage, eskalację i containment;
5. retest potwierdza poprawkę oraz brak regresji.

Nie używamy danych klientów, mechanizmów persistence ani destrukcyjnych komend, jeżeli ta sama telemetria może zostać wygenerowana nieszkodliwym zdarzeniem. Gdy realistyczna technika jest potrzebna, wykonujemy ją na dedykowanym aktywie z pisemną zgodą, limitami i obserwacją właściciela.

Wnioski należy przećwiczyć także w ramach tabletop incident response, ponieważ działający alert bez decyzji i komunikacji nie skraca czasu reakcji.

Checklista reguły Sigma dla SIEM

• Hipoteza opisuje zachowanie, skutek, dane i reakcję.
• Data contract określa pola, typy, pokrycie, latencję i właściciela.
• logsource jest zmapowany do konkretnego źródła i parsera.
• Reguła ma stabilne ID, status, opis, tagi, false positives i ownera.
• Processing pipeline i backend są wersjonowane.
• Wygenerowane zapytanie zostało przejrzane w docelowym SIEM.
• Testy obejmują positive, negative, near-miss i brakujące pola.
• Integracja potwierdza ingest, alert, enrichment i routing.
• Filtry mają właściciela, uzasadnienie, zakres i datę wygaśnięcia.
• Triage pokazuje dopasowane dane i kryteria eskalacji.
• Precision, recall testowy, data health, latency i koszt są mierzone.
• Purple-team retest odbywa się bez danych produkcyjnych i weaponized payloadów.

Źródła pierwotne

• Sigma Rules Specification 2.1
• Sigma Correlation Rules Specification
• Sigma Filters Specification
• SigmaHQ — główne repozytorium
• MITRE ATT&CK
• NIST Cybersecurity Framework 2.0
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations
• CISA — Best Practices for Event Logging and Threat Detection