76 lines
2.9 KiB
Markdown
76 lines
2.9 KiB
Markdown
# 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
|
|
|
|
```json
|
|
{
|
|
"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.
|