SIEM Rules & Detection14. August 2026 · 7 Min. Lesezeit

False Positives reduzieren: Tuning-Strategien für deine SIGMA-Rules

Einleitung

Eine SIGMA-Rule, die 50 Mal pro Tag feuert und in 49 Fällen ein normales Admin-Skript ist, ist schlimmer als gar keine Rule – sie verbrennt Aufmerksamkeit, trainiert Analysten zum Wegklicken und verdeckt den einen echten Treffer. Tuning ist deshalb keine optionale Phase nach dem Rule-Deployment, sondern der eigentliche Kern guter Detection-Engineering. Dieser Artikel zeigt, wie du False Positives systematisch reduzierst, ohne True Positives zu verlieren.

Warum das Thema wichtig ist

Studien aus großen SOCs zeigen, dass über 70 % aller Alerts False Positives sind und Analysten im Schnitt nur 10–30 % davon ernsthaft prüfen können. „Alert Fatigue“ ist nicht nur ein Soft-Faktor, sondern eine harte Sicherheitsschwäche – die Capital-One-Breach 2019 ist nur ein Beispiel von vielen, wo der echte Alert in einer Flut versank. Für KMU mit Ein-Personen-Sicherheits-Setup ist das Problem noch akuter: jede unproduktive Stunde bei der Alert-Triage geht direkt vom Schutzbudget ab. Sauberes Tuning ist keine Politur, sondern Voraussetzung dafür, dass dein Detection-Stack überhaupt funktioniert.

Die zwei Fehlerquellen

Jeder False Positive kommt aus einer von zwei Wurzeln:

Rule zu breit gefasst – die Rule trifft auch legitimes Verhalten
Umgebung hat Eigenheiten – ein bestimmter Admin / Tool / Prozess sieht halt nun mal verdächtig aus

Die Lösungen sind verschieden: Fall 1 erfordert Rule-Verfeinerung, Fall 2 erfordert Allowlists / Filter. Beide gemischt zu behandeln führt zu unhaltbaren Rule-Bibliotheken.

Tuning-Workflow

Ein robustes Vorgehen, das du pro Rule durchläufst:

Schritt 1 – Baseline messen

Wie oft feuert die Rule pro Tag, pro Host, pro User? Beispiel mit Wazuh / Elastic:

SELECT rule.id, COUNT(*) AS hits, COUNT(DISTINCT host.name) AS hosts
FROM alerts
WHERE @timestamp > now() - 7d
GROUP BY rule.id
ORDER BY hits DESC

Faustregel: Eine Rule mit >50 Hits/Tag UND >5 Hosts ist fast immer zu breit. Eine Rule mit <5 Hits/Tag UND meist gleicher Host darf öfter „rauschen“ – das ist meist ein einzelner Edge-Case.

Schritt 2 – Hits klassifizieren

Pro Rule mind. 20–30 Hits manuell prüfen und klassifizieren:

Kategorie	Bedeutung	Reaktion
TP (True Positive)	echter Sicherheitsvorfall	Rule beibehalten / Severity passt
BP (Benign Positive)	technisch korrekt, aber harmlos	Filter / Allowlist
FP (False Positive)	Rule trifft, was sie nicht treffen sollte	Rule verfeinern
TN-Drift	Rule sollte gar nicht gefeuert haben	Bug in Detection-Logik

Diese Klassifizierung dokumentieren – sie ist die Basis für jede weitere Anpassung.

Schritt 3 – Verfeinern oder filtern

Bei FP: Rule schärfer formulieren (siehe unten). Bei BP: Filter-Block hinzufügen.

Schritt 4 – Erneut messen

Nach dem Tuning erneut baselinen. Ziel: <5 Hits/Tag pro Rule und >50 % davon True Positive.

Konkrete Tuning-Techniken in SIGMA

Technik 1 – Negativ-Filter mit Whitelist

Der saubere Weg, BPs auszuschließen, ohne die Detection-Logik zu zerschlagen:

title: PowerShell mit -EncodedCommand-Argument
detection:
  selection:
    EventID: 4688
    NewProcessName|endswith: '\powershell.exe'
    CommandLine|contains: '-EncodedCommand'
  filter_known_admin:
    User|endswith:
      - '\svc-deploy'
      - '\admin-mike'
    CommandLine|contains:
      - 'Update-Module'
  condition: selection and not filter_known_admin
level: high

Wichtig: Filter immer mit Bedacht schreiben. Ein Filter „User contains admin“ filtert auch echte Angriffe, die mit kompromittierten Admin-Accounts laufen.

Technik 2 – ParentImage einbeziehen

Viele Rules werden präziser, wenn du den Eltern-Prozess mit prüfst. Beispiel: PowerShell aus Office heraus ist verdächtig, PowerShell aus winlogon.exe heraus ist normal.

detection:
  selection:
    Image|endswith: '\powershell.exe'
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\outlook.exe'
  condition: selection

Das ist deutlich präziser als „PowerShell wurde gestartet“.

Technik 3 – CommandLine-Pattern statt Image

Generische Tools (cmd.exe, powershell.exe) feuern zu oft. Detection sollte am Verhalten ansetzen, nicht am Tool:

# zu breit:
detection:
  selection:
    Image|endswith: '\cmd.exe'

# besser:
detection:
  selection:
    Image|endswith: '\cmd.exe'
    CommandLine|contains:
      - 'reg add'
      - 'HKLM\Software\Microsoft\Windows\CurrentVersion\Run'

Technik 4 – Schwellwerte / Aggregation

Manche Aktivität ist nur in Häufung verdächtig:

title: Möglicher Password-Spray (5+ failed logons in 5 min)
detection:
  selection:
    EventID: 4625
  condition: selection
  timeframe: 5m
  count(dst_user) by src_ip > 5
level: high

Eine einzelne Failed-Logon-Meldung ist Rauschen, fünf in fünf Minuten von einer IP ist ein Pattern.

Technik 5 – Time-of-Day-Filter

Bestimmte Aktivität ist tagsüber normal, nachts sehr verdächtig:

detection:
  selection:
    EventID: 4624
    LogonType: 10   # RemoteInteractive (RDP)
  filter_business_hours:
    HourOfDay:
      - 7
      - 8
      - ...
      - 18
  condition: selection and not filter_business_hours
level: medium

(Im realen SIGMA hängt das vom Backend ab; in Wazuh / Elastic / Splunk via Pipeline-Anreicherung.)

Allowlists professionell pflegen

Die meisten BPs landen in Allowlists. Drei Regeln dafür:

Allowlist-Einträge sind Code: in Git, mit Review, mit „why“-Kommentar
Allowlist-Einträge haben Ablaufdatum: spätestens nach 6 Monaten erneut prüfen
Allowlist-Einträge werden gemessen: wie viele Hits hat dieser Filter abgefangen? Wenn 0 → vermutlich obsolet

Beispiel-Inventar (CSV oder YAML):

allowlist:
  - id: AL-2026-001
    rule_id: detect_psh_encoded
    field: User
    value: 'CONTOSO\svc-deploy'
    reason: 'Deploy-Service nutzt -EncodedCommand für Argument-Escaping'
    owner: mike@example.com
    review_date: 2026-11-01

Tooling für Tuning

Tool	Funktion
Sigma2EventList	testet eine SIGMA-Rule gegen historische Logs (Backtest)
Atomic Red Team	erzeugt kontrolliert TPs zum Testen, ob Rule überhaupt feuert
Hayabusa	offline SIGMA-Engine auf Windows-EVTX – ideal zum Bulk-Test
EQL / KQL Console	interaktiv Rules verfeinern
Detection Engineering Maturity Matrix (Florian Roth)	Rule-Status klassifizieren: Draft → Tested → Production

Speziell Hayabusa ist Gold: du nimmst eine Woche EVTX-Logs aus Production, feuerst alle SIGMA-Rules drauf und siehst sofort, welche Rules wo wie oft treffen würden – ohne irgendwen mit Alerts zu nerven.

Severity richtig setzen

Tuning ist nicht nur „weniger feuern“, sondern auch „richtige Wichtigkeit“:

Level	Bedeutung	Reaktionszeit
critical	unmittelbarer Sicherheitsvorfall	sofort, 24/7
high	starker Verdacht, schnelle Triage nötig	innerhalb 4h
medium	auffällig, sollte geprüft werden	innerhalb 24h
low / informational	Kontext-Info, Reporting	wöchentlich

Eine Rule, die zu oft feuert, gehört oft eher auf „medium“ runter – nicht entfernt, aber auch nicht prio-1.

Stolperfallen

Zu früh tunen: Tuning braucht Daten. Mind. 2 Wochen Production-Logs ansehen, bevor man eine Rule entschärft
Filter zu offen: „User contains admin“ ist meist falsch – kompromittierte Admin-Accounts sind genau das, was du detektieren willst
Allowlists ohne Review: einmalig hinzugefügt, nie wieder geprüft, decken nach 2 Jahren echte Angriffe ab
Rule löschen statt verfeinern: bei vielen FPs ist der Reflex „weg damit“ – aber dann hast du 0 % Coverage. Erst verfeinern
Tuning ohne Ticket-Workflow: jeder Filter sollte mit Bezug auf einen Vorfall / Ticket dokumentiert werden, sonst weiß in 6 Monaten keiner mehr, warum
Detection-Hits nicht messen: ohne Hit-Count pro Rule kannst du Tuning nicht bewerten

Praxis-Checkliste

Fazit

Detection-Engineering ist 20 % Rule schreiben, 80 % Rules tunen. Wer das verstanden hat, baut Detection-Bibliotheken, die Analysten tatsächlich nutzen können – ohne in Alert-Fatigue zu versinken. Die wichtigste Disziplin: pro Rule nicht aufgeben, sondern verfeinern, bis sie unter 5 Hits/Tag bei >50 % TP-Rate landet. Das ist Arbeit – aber genau diese Arbeit unterscheidet ein effektives Detection-Programm von einem Compliance-Theater.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat konkrete Tuning-Workflows, Allowlist-Patterns und Hayabusa-Setups. Trag dich ein.