Rule-Sets und Detection Engine

Die Detection Engine ist wieder datengetrieben. Eingebaute Rule-Sets liegen als versionierte JSON-Dateien unter deploy/rules/ und werden beim Start des Detectors nach PostgreSQL synchronisiert. Aktivierungszustände, die im UI geändert wurden, bleiben dabei erhalten.

Mitgelieferte Rule-Sets

Rule-Set	Regeln	Schwerpunkt
`windows-core`	5	Audit, Dienste, Scheduled Tasks, Firewall
`windows-authentication`	5	Lockout, Brute Force, Password Spray, Kerberos, NTLM
`windows-account-admin`	5	Benutzer- und Gruppenänderungen
`windows-defender-powershell`	4	Defender und PowerShell

Insgesamt werden 19 Regeln mitgeliefert. Hinzu kommt das PostgreSQL-Rule-Set custom für eigene Regeln aus dem Analysten-UI.

Regeltypen

event: Match auf ein oder mehrere Events im Zeitfenster.
threshold: Mindestanzahl passender Events, optional gruppiert nach Host/User/IP/etc.
distinct: Mindestanzahl unterschiedlicher Werte, z. B. viele Zielbenutzer von derselben Source-IP.

Erlaubte Bedingungen

Die UI beziehungsweise JSON-Regeln dürfen nur freigegebene kanonische Felder verwenden. Beliebiges SQL wird nicht ausgeführt.

Operatoren:

equals, not_equals
contains, not_contains
regex
exists, not_exists
in

Typische Felder:

channel, provider, event_code
host, user, target_user, subject_user
source_ip, destination_ip, workstation
process_path, parent_process_path, command_line
message, category, action, outcome
status_code, failure_reason, logon_type

Beispiel: fehlgeschlagene Logons

{
  "id": "windows-failed-logon-burst",
  "title": "Viele fehlgeschlagene Anmeldungen",
  "severity": "high",
  "score": 75,
  "enabled": true,
  "kind": "threshold",
  "channels": ["Security"],
  "event_codes": [4625],
  "group_by": ["host", "user", "source_ip"],
  "threshold": 20,
  "window_seconds": 300,
  "suppress_seconds": 900,
  "summary": "{count} fehlgeschlagene Logons für {user} auf {host} von {source_ip}",
  "tags": ["authentication", "bruteforce"],
  "mitre": ["T1110"]
}

Suppressions

Suppressions werden separat in PostgreSQL gespeichert und können nach Rule-ID, Host, User und Source-IP eingeschränkt werden. * ist als Wildcard möglich. Eine optionale Ablaufzeit verhindert dauerhafte versehentliche Ausnahmen.

Built-ins versus Custom Rules

Built-in-Regeln werden aus Dateien synchronisiert und können im UI ein-/ausgeschaltet werden, aber nicht durch eine Custom Rule mit derselben ID überschrieben werden. Eigene Regeln landen im Rule-Set custom und können über die UI gepflegt werden.

Sicherheit

Der Rule-Compiler baut selbst ClickHouse-SQL aus einer Feld-/Operator-Allowlist. Rule-JSON enthält kein direkt ausführbares SQL. Zeitfenster und Ergebnisanzahl sind begrenzt; der Detector verwendet zusätzlich einen Query-Timeout.

2.9 KiB Raw Blame History