Reguły Sigma: uniwersalna logika detekcji i konwersja SIEM
W świecie cyberbezpieczeństwa defensywnego jednym z najbardziej utrzymujących się problemów zawsze było the fragmentacja języków wykrywania: Każdy SIEM ma swoją własną składnię zastrzeżona, każda platforma wymaga innych zapytań i reguł napisanych dla Splunk nie działają na Elastic, który z kolei nie jest kompatybilny z Microsoft Sentinel. W rezultacie zespoły SOC spędzają ogromną ilość czasu na ich przepisywaniem logika wykrywania dla każdego narzędzia, zamiast skupiać się na tym, co naprawdę ważne: znajdować zagrożenia, zanim spowodują szkody.
Le Zasady Sigmy urodzili się właśnie po to, aby rozwiązać ten problem. Wprowadzony przez Floriana Rotha i Thomasa Patzke, Sigma jest dziś de facto standardowym formatem pisać reguły wykrywania w sposób przenośny i niezależny od platformy. Raz napisana reguła Sigma może zostać automatycznie przekształcona w zapytanie Splunk SPL, Elasticsearch KQL, Microsoft Sentinel KQL, IBM QRadar, Chronicle YARA-L, i ponad 40 innych celów. W tym artykule szczegółowo badamy składnię Sigma, wzorce mapowania źródeł logów, techniki edycji i konwersji oraz sposoby integracji Sigma w nowoczesnym potoku wykrywania jako kodu.
Czego dowiesz się w tym artykule
- Pełna struktura reguły Sigma: tytuł, źródło dziennika, wykrycie, warunek
- Mapowanie źródeł logów: kategoria, produkt, usługa i sposób ich przekładania na SIEM
- Zaawansowane modyfikatory: zawiera, zaczyna się od, kończy się, re, przesunięcie base64
- Warunki agregacji: liczba, suma, min, max dla statystyk wykrywania
- Automatyczna konwersja za pomocą sigma-cli do Splunk, Elastic i Sentinel
- Wzór do wykrywania ruchu bocznego, utrzymywania się, eksfiltracji
- Testowanie i walidacja reguł Sigma z danymi syntetycznymi
- Zarządzanie repozytorium firmy Sigma z najlepszymi praktykami
Czym jest Sigma i dlaczego stała się standardem
Sigma to otwarty format oparty na YAML do opisywania wzorców wykrywania w dziennikach bezpieczeństwa w sposób niezależny od platformy. Pomyśl o tym jako YARA dla dzienników: tak jak YARA pozwala na pisanie reguł w przypadku złośliwych plików, które działają na dowolnym skanerze, Sigma umożliwia zapis reguły wykrywania, które działają na każdym SIEM.
Projekt SigmaHQ gości dziś więcej 3000 zasad społeczności objęte ciągłą konserwacją, zmapowane do frameworka MITRE ATT&CK i gotowe do konwersji. Rozwój był gwałtowny: od narzędzia niszowego do łowcy zagrożeń, Sigma stała się powszechnym językiem inżynierów zajmujących się wykrywaniem profesjonaliści. Główne zalety to trzy:
- Ruchliwość: napisz regułę, wdróż ją w N różnych SIEM
- Współpraca: zasady są czytelne dla każdego, niezależnie od używanego SIEM
- Automatyzacja: konwersja jest całkowicie zautomatyzowana w trybie CI/CD
Anatomia reguły sigma
Reguła Sigma i plik YAML z dobrze zdefiniowanymi polami. Zobaczmy strukturę wraz z prawdziwym przykładem, który odnotowuje użycie mimikatz poprzez Dzienniki zdarzeń systemu Windows:
title: Mimikatz Detection via Windows Security Events
id: 0d82df6e-0e4e-4fbb-a12b-6e7a00a9c7c3
status: stable
description: Detects mimikatz usage patterns via LSASS access events
and command-line indicators
references:
- https://github.com/gentilkiwi/mimikatz
- https://attack.mitre.org/techniques/T1003/001/
author: Federico Calo
date: 2026/03/01
modified: 2026/03/09
tags:
- attack.credential_access
- attack.t1003.001
- attack.defense_evasion
logsource:
category: process_access
product: windows
detection:
selection_lsass:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010'
- '0x1038'
- '0x1400'
- '0x143a'
selection_mimikatz_cli:
CommandLine|contains|all:
- 'sekurlsa'
- 'logonpasswords'
filter_legitimate:
SourceImage|startswith:
- 'C:\Windows\System32\'
- 'C:\Program Files\Windows Defender\'
condition: (selection_lsass and not filter_legitimate) or selection_mimikatz_cli
falsepositives:
- Legitimate security tools performing LSASS inspection
- Antivirus and EDR solutions
level: high
Przeanalizujmy szczegółowo każdą sekcję:
Pola obowiązkowe i metadane
Blok metadanych na początku reguły służy do celów dokumentacyjnych że w przypadku automatyzacji zarządzania:
- tytuł: czytelna nazwa reguły. To musi być wyjątkowe i opisowe. Konwencja: „Czasownik + Podmiot + Kontekst”
- id: Unikalny UUID v4. To nigdy się nie zmienia w czasie, pozwól śledzenie wersji i fałszywych raportów pozytywnych
-
status: cykl życia reguły. Prawidłowe wartości to:
stable,test,experimental,deprecated,unsupported -
poziom: powaga. Wartości:
informational,low,medium,high,critical -
tagi: Lista tagów MITER ATT&CK w formacie .format
attack.t<ID>dla technik lubattack.<tactic>dla taktyki
Źródło logów: serce przenośności
Blok źródło dziennika i magia, która sprawia, że Sigma jest przenośna. Zamiast określać indeks lub strumień danych specyficzny dla SIEM, definiuje typ dziennika abstrakcyjnie poprzez trzy pola:
# Esempio 1: Windows Security Events
logsource:
category: process_creation
product: windows
# Esempio 2: Linux Authentication
logsource:
category: process_creation
product: linux
# Esempio 3: Web Server Logs
logsource:
category: webserver
# nessun product specifico: generico
# Esempio 4: Log specifico di un servizio
logsource:
product: windows
service: security
# Esempio 5: Log di rete
logsource:
category: network_connection
product: windows
# Esempio 6: Cloud Trail
logsource:
product: aws
service: cloudtrail
System potokowy sigma-cli tłumaczy te abstrakcyjne źródła dziennika na plik
konkretne ścieżki każdego SIEM. Na przykład, category: process_creation
su product: windows staje się:
| Cel SIEM | Tłumaczenie źródła logu |
|---|---|
| Splunk | source="WinEventLog:Security" EventCode=4688 |
| Elasticsearch (ECS) | event.category:process AND event.type:start |
| Microsoft Sentinel (KQL) | SecurityEvent | where EventID == 4688 |
| Kronika (YARA-L) | $event.metadata.event_type = "PROCESS_LAUNCH" |
Wykrywanie: selekcje i warunki
Blok wykrywanie i gdzie zdefiniowano logikę wykrywania. Składa się z dwóch części: selekcje (filtry pól dziennika) i stan (Logika boolowska łącząca selekcje).
detection:
# Selection con match esatto su campo singolo
selection_exact:
EventID: 4625
# Selection con lista di valori (OR implicito)
selection_multi_value:
CommandLine|contains:
- 'net user'
- 'net localgroup'
- 'whoami'
# Selection con match su tutti i valori (AND implicito con |all)
selection_and_all:
CommandLine|contains|all:
- '-enc'
- 'powershell'
# Selection con regex
selection_regex:
CommandLine|re: '(?i)(invoke-mimikatz|sekurlsa::)'
# Selection con wildcard
selection_wildcard:
TargetFilename|startswith: 'C:\Users\'
TargetFilename|endswith: '.exe'
# Filter per ridurre i falsi positivi
filter_system_processes:
ParentImage|startswith: 'C:\Windows\System32\'
# Condition: logica booleana
condition: selection_exact and (
selection_multi_value or selection_and_all
) and not filter_system_processes
Zaawansowane modyfikatory
I modyfikatory są to przyrostki dodawane do nazw pól
z charakterem fajki | aby zmienić typ dopasowania.
Znajomość ich wszystkich jest niezbędna do napisania skutecznych zasad:
| Modyfikator | Opis | Przykład |
|---|---|---|
contains |
Dopasowanie podciągu (znak wieloznaczny po obu stronach) | CommandLine|contains: 'mimikatz' |
startswith |
Dopasuj początek wartości | Image|startswith: 'C:\Users\' |
endswith |
Dopasuj koniec wartości | Image|endswith: '\cmd.exe' |
re |
Regex PCRE | CommandLine|re: '(?i)sekurlsa' |
base64offset |
Dekodowanie Base64 z przesunięciem 0,1,2 | CommandLine|base64offset|contains: 'IEX' |
wide |
Dopasuj szerokie ciągi znaków Unicode | CommandLine|wide|contains: 'sekurlsa' |
all |
Wszystkie wartości na liście muszą się zgadzać | CommandLine|contains|all: ['-enc', 'bypass'] |
windash |
Dopasuj kreskę i ukośnik | CommandLine|contains|windash: '-Enc' |
cidr |
Dopasuj zakres CIDR dla adresu IP | DestinationIp|cidr: '10.0.0.0/8' |
lt, lte, gt, gte |
Porównania numeryczne | EventID|gte: 4624 |
Warunki agregacji: wykrywanie statystyczne
Niektóre detekcje wymagają zliczania zdarzeń w określonym przedziale czasu, nie pasować do jednego zdarzenia. obsługuje Sigmę warunki agregacji dla tych przypadków użycia:
# Rilevare brute force: più di 10 login falliti in 60 secondi
title: Windows Brute Force Login Attempt
logsource:
product: windows
service: security
detection:
selection:
EventID: 4625
LogonType: 3
condition: selection | count() > 10
timeframe: 60s
falsepositives:
- Users with expired passwords
level: medium
---
# Rilevare data exfiltration: upload anomalo per destinazione
title: Potential Data Exfiltration by Volume
logsource:
category: network_connection
product: windows
detection:
selection:
Initiated: 'true'
DestinationPort:
- 443
- 80
condition: selection | count(DestinationHostname) by SourceIp > 50
timeframe: 1h
level: high
---
# Port scan detection: molte porte diverse dallo stesso sorgente
title: Network Port Scan Detection
logsource:
category: network_connection
detection:
selection:
EventID: 5156
condition: selection | count(DestinationPort) by SourceAddress > 30
timeframe: 10m
level: medium
Konwersja za pomocą sigma-cli: poradnik praktyczny
sigma-cli oraz oficjalne narzędzie do konwersji reguł Sigma w językach zapytań SIEM. Podstawowa instalacja i użytkowanie:
# Installazione
pip install sigma-cli
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
pip install pySigma-backend-microsoft365defender
# Verifica backend disponibili
sigma list backends
# Conversione base: Sigma -> Splunk SPL
sigma convert -t splunk -p splunk_windows rules/mimikatz.yml
# Output atteso:
# (source="WinEventLog:Microsoft-Windows-Sysmon/Operational"
# EventCode=10 TargetImage="*\\lsass.exe"
# GrantedAccess IN ("0x1010", "0x1038", "0x1400", "0x143a"))
# NOT (SourceImage="C:\\Windows\\System32\\*"
# OR SourceImage="C:\\Program Files\\Windows Defender\\*")
# Conversione con pipeline personalizzata
sigma convert \
-t splunk \
-p splunk_windows \
-p my_custom_field_mapping.yml \
rules/
# Conversione per Elasticsearch con ECS
sigma convert \
-t elasticsearch \
-p ecs_windows \
-f lucene \
rules/credential_access/
# Conversione per Microsoft Sentinel (KQL)
sigma convert \
-t microsoft365defender \
-p microsoft365defender \
rules/lateral_movement/
# Output in formato JSON per automazione
sigma convert \
-t splunk \
-p splunk_windows \
--format-output json \
rules/ > converted_rules.json
Uwaga: mapowanie rurociągów i pól
Każda organizacja ma własną normalizację logów. Jeśli Twoje logi nie kieruj się standardowym wzorcem (np. Sysmon dla Windows), musisz utworzyć plik niestandardowy rurociąg który mapuje pola Sigma na pola prawdziwe dane Twojego SIEM. Bez tego mapowania przekonwertowane reguły nie będą działać.
Twórz niestandardowe potoki
Potoki Sigma definiują sposób mapowania abstrakcyjnych pól Sigma na pola konkretne elementy Twojego SIEM. Poniżej opisano, jak je utworzyć dla używanej infrastruktury niestandardowy format dziennika:
# custom_pipeline.yml
name: Custom Windows Pipeline
priority: 20
transformations:
# Rinominare campo Sigma -> campo reale nel SIEM
- id: field_mapping_process
type: field_name_mapping
mapping:
CommandLine: process.command_line
Image: process.executable
ParentImage: process.parent.executable
User: user.name
TargetImage: target.process.executable
GrantedAccess: target.process.granted_access
rule_conditions:
- type: logsource
category: process_creation
# Aggiungere condizioni all'index di destinazione
- id: index_condition
type: detection_item_keyword
keyword: 'index=windows_events'
rule_conditions:
- type: logsource
product: windows
# Sostituire valori nei campi
- id: winlog_channel_map
type: field_value_mapping
field_name: winlog.channel
mapping:
'Security': 'security'
'System': 'system'
'Application': 'application'
Wzorce wykrywania dla typowych przypadków użycia
Zobaczmy zbiór reguł Sigmy gotowych do zastosowań o wysokim priorytecie, odwzorowane na najczęściej wykorzystywane techniki MITRE ATT&CK:
Ruch boczny: Pass-the-Hash
title: Pass-the-Hash Attack Pattern
id: 6571d552-4c16-4f50-b5f6-11ae9d1b0a38
status: stable
description: Detects Pass-the-Hash attacks via anomalous NTLM authentication
tags:
- attack.lateral_movement
- attack.t1550.002
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 3
AuthenticationPackageName: NTLM
KeyLength: 0
filter_local:
IpAddress:
- '127.0.0.1'
- '::1'
filter_machine:
SubjectUserName|endswith: '






