2.9 KiB
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_equalscontains,not_containsregexexists,not_existsin
Typische Felder:
channel,provider,event_codehost,user,target_user,subject_usersource_ip,destination_ip,workstationprocess_path,parent_process_path,command_linemessage,category,action,outcomestatus_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.