Erstellung von Erkennungsregeln mit Sigma

Was macht Erstellung von Erkennungsregeln mit Sigma?

Verwendung

Verwenden Sie dieses Skill, wenn:

• SOC-Ingenieure portable Erkennungsregeln für mehrere SIEM-Plattformen erstellen müssen
• Threat-Intelligence-Berichte TTPs beschreiben, die eine neue Erkennungsabdeckung erfordern
• Vorhandene herstellerspezifische Regeln in ein teilbares Format standardisiert werden sollen
• Das Team Sigma als Detection-as-Code-Standard in CI/CD-Pipelines übernimmt

Nicht verwenden für Echtzeit-Streaming-Erkennung (Sigma ist für Batch-/geplante Suchvorgänge) oder wenn das Ziel-SIEM native Erkennungsfunktionen hat, die Sigma nicht ausdrücken kann (z.B. Splunk RBA-Risikobewertung).

Voraussetzungen

• Python 3.8+ mit pySigma und passendem Backend (pySigma-backend-splunk, pySigma-backend-elasticsearch, pySigma-backend-microsoft365defender)
• Sigma-Regelrepository geklont: git clone https://github.com/SigmaHQ/sigma.git
• Kenntnisse des MITRE ATT&CK-Frameworks für Technik-Zuordnung
• Verständnis der Feldzuordnungen der Ziel-SIEM-Logquellen

Arbeitsablauf

Schritt 1: Erkennungslogik aus Threat Intelligence definieren

Beginnen Sie mit einem Threat-Bericht oder einer ATT&CK-Technik. Beispiel: Erkennung von Mimikatz Credential Dumping (T1003.001 — LSASS-Speicher):

title: Mimikatz Credential Dumping via LSASS Access
id: 0d894093-71bc-43c3-8d63-bf520e73a7c5
status: stable
level: high
description: Detects process accessing lsass.exe memory, indicative of credential dumping tools like Mimikatz
references:
    - https://attack.mitre.org/techniques/T1003/001/
    - https://github.com/gentilkiwi/mimikatz
author: mahipal
date: 2024/03/15
modified: 2024/03/15
tags:
    - attack.credential_access
    - attack.t1003.001
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1010'
            - '0x1038'
            - '0x1fffff'
            - '0x40'
    filter_main_svchost:
        SourceImage|endswith: '\svchost.exe'
    filter_main_csrss:
        SourceImage|endswith: '\csrss.exe'
    filter_main_wininit:
        SourceImage|endswith: '\wininit.exe'
    condition: selection and not 1 of filter_main_*
falsepositives:
    - Legitimate security tools accessing LSASS
    - Windows Defender scanning
    - CrowdStrike Falcon sensor

Schritt 2: Sigma-Regelsyntax validieren

Verwenden Sie sigma check, um die Regel zu validieren:

# Installieren von pySigma und Validatoren
pip install pySigma pySigma-validators-sigmaHQ

# Regel validieren
sigma check rule.yml

Alternativ mit Python validieren:

from sigma.rule import SigmaRule
from sigma.validators.core import SigmaValidator

rule = SigmaRule.from_yaml(open("rule.yml").read())
validator = SigmaValidator()
issues = validator.validate_rule(rule)
for issue in issues:
    print(f"{issue.severity}: {issue.message}")

Schritt 3: In Ziel-SIEM-Abfrage konvertieren

In Splunk SPL konvertieren:

from sigma.rule import SigmaRule
from sigma.backends.splunk import SplunkBackend
from sigma.pipelines.splunk import splunk_windows_pipeline

pipeline = splunk_windows_pipeline()
backend = SplunkBackend(pipeline)

rule = SigmaRule.from_yaml(open("rule.yml").read())
splunk_query = backend.convert_rule(rule)
print(splunk_query[0])

Ausgabe:

TargetImage="*\\lsass.exe" (GrantedAccess="*0x1010*" OR GrantedAccess="*0x1038*"
OR GrantedAccess="*0x1fffff*" OR GrantedAccess="*0x40*")
NOT (SourceImage="*\\svchost.exe") NOT (SourceImage="*\\csrss.exe")
NOT (SourceImage="*\\wininit.exe")

In Elastic Abfrage (Lucene) konvertieren:

from sigma.backends.elasticsearch import LuceneBackend
from sigma.pipelines.elasticsearch import ecs_windows_pipeline

pipeline = ecs_windows_pipeline()
backend = LuceneBackend(pipeline)
elastic_query = backend.convert_rule(rule)
print(elastic_query[0])

In Microsoft Sentinel KQL konvertieren:

from sigma.backends.microsoft365defender import Microsoft365DefenderBackend

backend = Microsoft365DefenderBackend()
kql_query = backend.convert_rule(rule)
print(kql_query[0])

Schritt 4: Mit MITRE ATT&CK abbilden und Abdeckungsmetadaten hinzufügen

Taggen Sie jede Regel mit ATT&CK-Technik-IDs im Feld tags:

tags:
    - attack.credential_access        # Taktik
    - attack.t1003.001                # Sub-Technik
    - attack.t1003                    # Übergeordnete Technik

Verfolgen Sie die Erkennungsabdeckung mit dem ATT&CK Navigator:

import json

# ATT&CK Navigator-Layer aus Sigma-Regeln generieren
layer = {
    "name": "SOC Detection Coverage",
    "versions": {"attack": "14", "navigator": "4.9", "layer": "4.5"},
    "domain": "enterprise-attack",
    "techniques": []
}

# Sigma-Regelverzeichnis nach Technik-Tags durchsuchen
import os
from sigma.rule import SigmaRule

for root, dirs, files in os.walk("sigma/rules/windows/"):
    for f in files:
        if f.endswith(".yml"):
            rule = SigmaRule.from_yaml(open(os.path.join(root, f)).read())
            for tag in rule.tags:
                if str(tag).startswith("attack.t"):
                    technique_id = str(tag).replace("attack.", "").upper()
                    layer["techniques"].append({
                        "techniqueID": technique_id,
                        "color": "#31a354",
                        "score": 1
                    })

with open("coverage_layer.json", "w") as f:
    json.dump(layer, f, indent=2)

Schritt 5: Regel mit Beispieldaten testen

Erstellen Sie Testdaten und validieren Sie, dass die Regel die erwarteten Ereignisse erfasst:

# Sigma-Testframework verwenden
sigma test rule.yml --target splunk --pipeline splunk_windows

# Oder manuell in Splunk mit Beispieldaten testen
# Sysmon process_access-Log mit bekannter Mimikatz-Signatur hochladen

Validieren Sie die False-Positive-Rate, indem Sie die Regel 7 Tage lang gegen Produktionsdaten in einer nicht alarmierenden gespeicherten Suche ausführen.

Schritt 6: In Produktions-SIEM bereitstellen

Stellen Sie die konvertierte Abfrage als geplante Suche oder Korrelationsregel bereit:

Splunk ES-Korrelationssuche:

| tstats summariesonly=true count from datamodel=Endpoint.Processes
  where Processes.process_name="*\\lsass.exe"
  by Processes.src, Processes.user, Processes.process_name, Processes.parent_process_name
| `drop_dm_object_name(Processes)`
| where count > 0

Elastic Security-Regel (TOML-Format):

[rule]
name = "LSASS Memory Access - Credential Dumping"
description = "Detects suspicious access to LSASS process memory"
risk_score = 73
severity = "high"
type = "eql"
query = '''
process where event.action == "access" and
  process.name == "lsass.exe" and
  not process.executable : ("*\\svchost.exe", "*\\csrss.exe")
'''

[rule.threat]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"

Schritt 7: Versionskontrolle und CI/CD-Integration

Speichern Sie Regeln in Git mit automatisierten Tests:

# .github/workflows/sigma-ci.yml
name: Sigma Rule CI
on: [push, pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install pySigma pySigma-validators-sigmaHQ
      - run: sigma check rules/
      - run: sigma convert -t splunk -p splunk_windows rules/ > /dev/null

Schlüsselkonzepte

Begriff	Definition
Sigma	Herstellerneutrales Erkennungsregelformat (YAML-basiert), das mittels Backends in SIEM-spezifische Abfragen kompiliert
pySigma	Python-Bibliothek, die das alte sigmac für Regelkonvertierung, Validierung und Pipeline-Verarbeitung ersetzt
Backend	pySigma-Plugin, das die Sigma-Erkennungslogik in eine Abfragesprache der Zielplattform (SPL, KQL, Lucene) übersetzt
Pipeline	Feldzuordnungskonfiguration, die generische Sigma-Feldnamen in SIEM-spezifische Feldnamen übersetzt
Logsource	Sigma-Regelabschnitt, der die Kategorie (process_creation, network_connection) und das Produkt (windows, linux) der Zieldaten definiert
Detection-as-Code	Praxis der Verwaltung von Erkennungsregeln in der Versionskontrolle mit CI/CD-Tests und automatisierter Bereitstellung

Werkzeuge und Systeme

• SigmaHQ: Offizielles Sigma-Regelrepository mit über 3.000 Community-gepflegten Erkennungsregeln auf GitHub
• pySigma: Python-basiertes Sigma-Regelverarbeitungsframework mit modularen Backends und Pipelines
• ATT&CK Navigator: MITRE-Tool zur Visualisierung der Erkennungsabdeckung, kartiert auf ATT&CK-Techniken
• Uncoder.IO: Webbasierter Sigma-Regelkonverter mit Unterstützung für über 30 SIEM-Plattformen zur schnellen Übersetzung

Häufige Szenarien

• Neue CVE-Erkennung: Sigma-Regel für Exploit-Indikatoren schreiben (z.B. Log4Shell JNDI-Lookup-Muster in Web-Logs)
• Hunting-Regel-Promotion: Ad-hoc Splunk-Hunting-Abfrage in Sigma-Regel für fortlaufende automatisierte Erkennung konvertieren
• Multi-SIEM-Migration: Konvertierung von über 500 Splunk-Korrelationssuchen in Sigma für die Migration zu Elastic Security
• Purple-Team-Output: Red-Team-Ergebnisse in Sigma-Regeln für sofortige defensive Abdeckung konvertieren
• Threat-Intel-Operationalisierung: Transformierung IOC-basierter Threat-Berichte in verhaltensorientierte Sigma-Regeln

Ausgabeformat

SIGMA REGEL-BEREITSTELLUNGSBERICHT
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Regel-ID:      0d894093-71bc-43c3-8d63-bf520e73a7c5
Titel:         Mimikatz Credential Dumping via LSASS Access
ATT&CK:        T1003.001 - LSASS Memory
Schweregrad:   Hoch
Status:        In Produktion bereitgestellt

Konvertierungen:
  Splunk SPL:    BESTANDEN — Gespeicherte Suche "sigma_lsass_access" erstellt
  Elastic EQL:   BESTANDEN — Erkennungsregel-ID elastic-0d894093 aktiviert
  Sentinel KQL:  BESTANDEN — Analytische Regel mittels ARM-Vorlage bereitgestellt

Tests:
  True Positives:    4/4 Testfälle übereinstimmend
  False Positives:   2 im 7-Tage-Backtest (svchost-Grenzfall — Filter hinzugefügt)
  Leistung:          Durchschnittliche Ausführung 3,2 s bei 50 Mio. Ereignissen/Tag