# 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.