sendnrw/siem-backend
2
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e0ef00a4ee97eeb3a10360d3cf3f75ff4ca9ed93
siem-backend/README.md
jbergner e0ef00a4ee
All checks were successful
release-tag / release-image (push) Successful in 2m10s
Details
Dokumentationen ergänzt
2026-04-27 07:31:55 +02:00

4549 lines
91 KiB
Markdown
Raw Blame History

# SIEM-lite Admin-Handbuch: Anlernphase, manuelle Bewertung und Lerneffekt
Stand: 2026-04-27
Zielgruppe: Administratoren ohne SIEM-/SOC-Vorerfahrung
Projekt: `siem-backend` / `SIEM-lite Security Operations`
---
## 1. Ziel dieses Dokuments
Dieses Dokument erklärt, wie die Software lernt, wie die Anlernphase funktioniert und wie man Detections manuell bewertet, ohne den Lerneffekt zu verfälschen.
Es richtet sich ausdrücklich an Administratoren, die die Software sicher im Alltag betreiben sollen. Der Fokus liegt nicht auf Go-Code, sondern auf dem praktischen Umgang mit der Oberfläche, den Bewertungen und den Auswirkungen auf Baseline, UEBA und Host-Risiko.
Nach dem Lesen sollte ein Admin verstehen:
- warum am Anfang viele Meldungen entstehen,
- welche Meldungen normal sind,
- welche Meldungen nicht einfach weggeklickt werden dürfen,
- wie die Status `plausible`, `legitimate`, `false_positive`, `suppressed`, `resolved` und `confirmed_incident` zu verwenden sind,
- wann eine Baseline lernen darf,
- wann eine Baseline nicht lernen darf,
- wie man Wartungsfenster, Patchtage und bekannte Sonderfälle korrekt bewertet,
- warum eine falsche Bewertung gefährlich sein kann,
- wie der Host Risk Score beeinflusst wird.
---
## 2. Grundprinzip der Software
SIEM-lite sammelt Windows-Events von Agents, speichert diese zentral und wertet sie regelmäßig über Regeln aus.
Es gibt grob vier Arten von Erkennung:
1. **Feste Regeln**
- z. B. viele fehlgeschlagene Logons, Reboot-Spikes, Password-Spray.
2. **Dynamische Regeln**
- Regeln, die ein Admin in der Weboberfläche selbst anlegt.
3. **Baseline-Regeln**
- statistische Erkennung von ungewöhnlich vielen Events im Vergleich zum gelernten Normalzustand.
4. **UEBA-Regeln**
- verhaltensbasierte Regeln, z. B. neuer Login-Kontext für Benutzer oder privilegierter Benutzer auf neuem Host.
Die Software ist kein fertiges „Wahrheitsorakel“. Sie liefert Hinweise. Ein Mensch muss bewerten, ob ein Hinweis legitim, plausibel, ein Fehlalarm oder ein echter Vorfall ist.
---
## 3. Was bedeutet „Anlernphase“?
Die Anlernphase ist der Zeitraum, in dem SIEM-lite sammelt, was in der Umgebung normal ist.
Beispiele:
- Welche EventIDs sendet ein bestimmter Host normalerweise?
- Wie viele Security-Events erzeugt ein Domain Controller typischerweise pro 5-Minuten-Fenster?
- Welche Benutzer melden sich normalerweise an welchen Hosts an?
- Von welchen Quell-IPs kommt ein Benutzer normalerweise?
- Welche Workstations sind für einen Benutzer bekannt?
- Welche privilegierten Benutzer arbeiten auf welchen Systemen?
Die Software baut daraus Baselines und bekannte Kontexte auf.
---
## 4. Warum ist die Anlernphase kritisch?
Während der Anlernphase entscheidet sich, was später als „normal“ gilt.
Wenn während der Anlernphase ein Sicherheitsvorfall passiert und dieser unkritisch eingelernt wird, kann die Software dieses Verhalten später als normal ansehen.
Beispiel:
Ein Angreifer nutzt nachts einen Admin-Account auf einem ungewöhnlichen Client. Wenn dieses Verhalten als normal eingelernt wird, kann später ein ähnlicher Zugriff weniger auffallen.
Deshalb ist wichtig:
- Die Anlernphase sollte bewusst begleitet werden.
- Auffällige Detections sollten nicht wahllos als legitim markiert werden.
- Confirmed Incidents dürfen nicht in die Baseline einfließen.
- Wartungsfenster sollten dokumentiert und korrekt bewertet werden.
---
## 5. Welche Lernmechanismen gibt es?
SIEM-lite hat mehrere Lernbereiche. Diese müssen getrennt verstanden werden.
---
# 6. Lernmechanismus 1: Event-Rate-Baseline
## 6.1 Zweck
Die Event-Rate-Baseline lernt, wie viele Events eines bestimmten Typs normalerweise auftreten.
Sie betrachtet Kombinationen aus:
```text
Host
Channel
EventID
Wochentag
Stunde
```
Beispiel:
```text
DC01
Security
4625
Montag
08:00 Uhr
```
Die Software lernt also nicht nur: „DC01 hat normalerweise 4625-Events“, sondern genauer: „DC01 hat montags um 08:00 Uhr normalerweise eine bestimmte Menge 4625-Events“.
---
## 6.2 Warum nach Wochentag und Stunde?
Viele Systeme haben zeitabhängige Muster.
Beispiele:
- morgens viele Logons,
- nachts Backup-Jobs,
- montags mehr Fehlversuche nach Passwortänderungen,
- Patchfenster am Mittwochabend,
- GPO-/Softwareverteilung morgens nach dem Einschalten vieler Clients,
- Monitoring-Jobs alle paar Minuten.
Ohne Zeitbezug würde die Baseline zu ungenau.
---
## 6.3 Was wird gespeichert?
In `baseline_event_stats` werden statistische Werte gespeichert:
| Wert | Bedeutung |
|---|---|
| `avg_count` | durchschnittliche Event-Anzahl |
| `stddev_count` | Standardabweichung |
| `sample_count` | Anzahl gelernter Samples |
| `m2_count` | Hilfswert für laufende Varianzberechnung |
| `last_updated` | letzter Lernzeitpunkt |
---
## 6.4 Wann lernt die Baseline?
Die Baseline wird regelmäßig durch diese Regel aktualisiert:
```text
baseline_update
```
Sie betrachtet das aktuelle Zeitfenster, z. B. 5 Minuten, zählt Events und aktualisiert die Statistik.
Default:
```text
BASELINE_WINDOW=5m
```
---
## 6.5 Wann erzeugt die Baseline einen Alarm?
Die Detection-Regel heißt:
```text
baseline_event_rate_anomaly
```
Sie erzeugt einen Alarm, wenn die aktuelle Event-Anzahl deutlich vom gelernten Normalwert abweicht.
Vereinfacht:
```text
aktueller Wert deutlich größer als gelernter Durchschnitt
```
Technisch wird ein Z-Score berechnet:
```text
z = (aktueller Wert - Durchschnitt) / Standardabweichung
```
---
## 6.6 Mindestvoraussetzungen für Baseline-Alarme
Ein Baseline-Alarm entsteht nicht sofort am ersten Tag. Die Software benötigt zuerst Samples.
Default-Werte:
| Parameter | Default | Bedeutung |
|---|---:|---|
| `BASELINE_MIN_SAMPLES` | `24` | mindestens 24 Vergleichswerte |
| `BASELINE_MIN_COUNT` | `10` | mindestens 10 Events im aktuellen Fenster |
| `BASELINE_MEDIUM_Z` | `2.5` | ab hier Medium |
| `BASELINE_HIGH_Z` | `4.0` | ab hier High |
Das bedeutet: Ein Eventtyp muss erst mehrfach beobachtet worden sein, bevor eine zuverlässige Abweichung erkannt werden kann.
---
## 6.7 Typisches Verhalten während der Anlernphase
In den ersten Stunden oder Tagen können folgende Effekte auftreten:
- noch keine Baseline-Alerts, weil `sample_count` zu niedrig ist,
- später plötzlich Baseline-Alerts, weil genug Samples vorhanden sind,
- einzelne Systeme wirken auffällig, obwohl sie nur besondere Aufgaben haben,
- Domain Controller erzeugen viel mehr Events als Clients,
- Patch-/Wartungstage erzeugen Sondermuster,
- neue Software erzeugt neue EventIDs oder neue Mengen.
Das ist normal.
---
## 6.8 Wie lange sollte die Baseline lernen?
Eine sinnvolle Mindestdauer hängt von der Umgebung ab.
Empfehlung:
| Umgebung | Mindest-Anlernzeit |
|---|---:|
| kleine Testumgebung | 2 bis 3 Tage |
| normale Büro-IT | 7 bis 14 Tage |
| größere Umgebung mit Wochenmustern | 14 bis 30 Tage |
| Umgebung mit Monatsjobs | mindestens 30 Tage |
Für produktive Sicherheitsbewertung sind 7 Tage oft das Minimum, weil damit jeder Wochentag einmal gesehen wurde.
Besser sind 14 bis 30 Tage.
---
# 7. Lernmechanismus 2: UEBA-Baseline
## 7.1 Zweck
UEBA steht für User and Entity Behavior Analytics.
SIEM-lite lernt Benutzerkontexte, also welche Benutzer sich normalerweise wie und wo anmelden.
Ein Kontext besteht aus:
```text
Benutzer
Host
Quell-IP
Workstation
```
Beispiel:
```text
max.mustermann
CLIENT042
10.2.40.15
CLIENT042
```
---
## 7.2 Welche Events nutzt UEBA?
UEBA nutzt erfolgreiche Logons:
```text
Security EventID 4624
```
Die Software ignoriert dabei leere Benutzer, `-` und Maschinenkonten.
Empfohlen ist zusätzlich, technische Accounts wie `SYSTEM`, `LOCAL SERVICE`, `NETWORK SERVICE` und ähnliche zu ignorieren.
---
## 7.3 Welche Tabelle wird genutzt?
UEBA schreibt bekannte Kontexte in:
```text
ueba_user_baseline
```
Wichtige Felder:
| Feld | Bedeutung |
|---|---|
| `username` | Benutzer |
| `hostname` | Zielhost |
| `src_ip` | Quell-IP |
| `workstation` | Workstation |
| `first_seen` | erster bekannter Zeitpunkt |
| `last_seen` | letzter bekannter Zeitpunkt |
| `seen_count` | Häufigkeit |
---
## 7.4 Wie funktioniert UEBA-Lernen?
Die Regel:
```text
ueba_update
```
übernimmt erfolgreiche Logons in die UEBA-Baseline.
Wenn ein Kontext neu ist:
```text
first_seen = jetzt
last_seen = jetzt
seen_count = Anzahl
```
Wenn ein Kontext bekannt ist:
```text
last_seen wird aktualisiert
seen_count wird erhöht
```
---
## 7.5 Warum ist die Reihenfolge wichtig?
Im Detection-Loop sollte erst erkannt und danach gelernt werden.
Empfohlene Reihenfolge:
```text
ueba_admin_new_host
ueba_offhours_login
ueba_first_privileged_use
ueba_new_user_context
ueba_update
```
Wenn `ueba_update` zu früh läuft, würde ein neuer Kontext zuerst gelernt und danach nicht mehr als neu erkannt.
---
## 7.6 Was erkennt `ueba_new_user_context`?
Diese Regel erkennt, wenn ein Benutzer sich in einem neuen Kontext anmeldet.
Beispiel:
Benutzer `max.mustermann` arbeitet normalerweise auf `CLIENT042`, meldet sich aber plötzlich per RDP von einer unbekannten Workstation auf `SERVER17` an.
Das kann legitim sein, aber es ist erklärungsbedürftig.
---
## 7.7 Was erkennt `ueba_admin_new_host`?
Diese Regel ist besonders wichtig.
Sie erkennt, wenn ein privilegierter Benutzer sich erstmals auf einem Host anmeldet.
Privilegierte Benutzer werden erkannt über:
- Eintrag in `privileged_users`,
- Namensmuster wie `adm-*`, `*-adm`, `*.adm`.
Beispiel:
```text
adm.max meldet sich erstmals auf CLIENT099 an
```
Das ist oft relevanter als ein normaler Benutzerkontext.
---
## 7.8 Was erkennt `ueba_offhours_login`?
Diese Regel erkennt Anmeldungen außerhalb der Arbeitszeit.
Empfohlene Arbeitszeit im aktuellen Konzept:
```text
06:00 bis 20:00 Uhr
```
Problematisch sind insbesondere:
- Admin-Logins nachts,
- RDP-Logins nach Feierabend,
- neue Quell-IP plus Off-Hours,
- vorherige Fehlversuche plus erfolgreicher Login,
- Logins auf Domain Controllern oder Servern.
Wichtig: Technische Accounts wie `SYSTEM` müssen ausgeschlossen werden, sonst flutet diese Regel.
---
## 7.9 Was erkennt `ueba_first_privileged_use`?
Diese Regel erkennt, wenn ein Benutzer erstmals privilegierte Rechte nutzt.
Basis ist:
```text
Security EventID 4672
```
Event 4672 bedeutet, dass einem neuen Logon besondere Rechte zugewiesen wurden.
Diese Regel braucht eine eigene Baseline:
```text
user_privilege_baseline
```
Ohne diese Baseline würde derselbe Benutzer immer wieder als „erstmals privilegiert“ auffallen.
---
# 8. Lernmechanismus 3: Dynamic Rules
## 8.1 Lernen Dynamic Rules?
Dynamische Regeln lernen nicht im statistischen Sinne.
Sie erkennen nach festen Bedingungen:
- bestimmte EventIDs,
- bestimmte Channels,
- bestimmte Felder,
- bestimmte Schwellenwerte.
Beispiel:
```text
Wenn Security 1102 kommt, melde critical.
```
Dynamic Rules können aber durch Bewertung und Suppression indirekt beeinflusst werden.
---
## 8.2 Wie beeinflusst Bewertung Dynamic Rules?
Wenn eine Detection aus einer dynamischen Regel als `false_positive`, `legitimate`, `plausible`, `resolved` oder `suppressed` bewertet wird, beeinflusst das vor allem:
- Host Risk Score,
- SOC-Übersicht,
- Arbeitsliste der Analysten.
Die Regel selbst wird dadurch nicht geändert.
Wenn eine dynamische Regel dauerhaft zu viele Meldungen erzeugt, muss die Regel angepasst werden:
- EventID einschränken,
- Channel korrigieren,
- Match Field setzen,
- Threshold erhöhen,
- Suppress-Zeit setzen,
- Regel deaktivieren.
---
# 9. Was bedeutet manuelle Bewertung?
Manuelle Bewertung bedeutet: Ein Admin oder Analyst entscheidet, wie eine Detection fachlich einzuordnen ist.
Eine Detection ist zunächst nur ein Hinweis.
Beispiel:
```text
UEBA: Privilegierter Benutzer adm.max meldet sich erstmals auf Host CLIENT099 an
```
Mögliche Bewertungen:
- echter Vorfall,
- legitime Admin-Arbeit,
- plausibel wegen Rollout,
- Fehlalarm,
- bereits erledigt,
- künftig unterdrücken.
---
## 10. Warum ist manuelle Bewertung wichtig?
Die Bewertung beeinflusst:
1. die SOC-Arbeitsliste,
2. den Host Risk Score,
3. die Qualität der Baseline,
4. die zukünftige Alarmflut,
5. die Nachvollziehbarkeit für andere Admins,
6. die Entscheidung, ob Verhalten gelernt oder ausgeschlossen wird.
Eine falsche Bewertung kann gefährlich sein.
Beispiele:
| Falsche Bewertung | Risiko |
|---|---|
| Angriff als `legitimate` markiert | Verhalten verschwindet aus Risk Score |
| Incident nicht als `confirmed_incident` markiert | Baseline lernt möglicherweise bösartiges Verhalten |
| Wartungsfenster nicht dokumentiert | künftige Admins verstehen Detections nicht |
| Alles als `false_positive` markiert | echte Auffälligkeiten werden übersehen |
| Zu viele Suppressions | blinde Flecken entstehen |
---
# 11. Statusmodell
SIEM-lite verwendet mehrere Status. Diese sollten konsequent verwendet werden.
---
## 11.1 `open`
## Bedeutung
Die Detection ist neu und noch nicht bewertet.
## Wann verwenden?
Normalerweise automatisch beim Erzeugen einer Detection.
## Admin-Aktion
Prüfen:
- Welche Regel hat ausgelöst?
- Welcher Host ist betroffen?
- Welcher Benutzer ist betroffen?
- Welche Events liegen zugrunde?
- Gibt es zeitgleichen Kontext?
- Ist es ein Wartungsfenster?
- Gibt es mehrere ähnliche Detections?
## Wirkung
- zählt im Host Risk Score,
- erscheint in offenen Listen,
- bleibt prüfbedürftig.
---
## 11.2 `acknowledged`
## Bedeutung
Die Detection wurde gesehen, aber noch nicht abschließend bewertet.
## Wann verwenden?
Wenn ein Admin signalisiert:
```text
Ich habe es gesehen, prüfe aber später weiter.
```
## Beispiel
Ein Server meldet viele fehlgeschlagene Logons. Der Admin hat gesehen, dass es relevant sein könnte, muss aber erst Logs auf dem Quellsystem prüfen.
## Wirkung
- zählt weiterhin im Host Risk Score,
- zählt schwächer als `investigating`,
- bleibt offen genug für Nachverfolgung.
---
## 11.3 `investigating`
## Bedeutung
Die Detection wird aktiv untersucht.
## Wann verwenden?
Wenn konkrete Prüfung läuft:
- Loganalyse,
- Rückfrage beim Benutzer,
- Prüfung von Quell-IP,
- Prüfung von RDP-/VPN-/Firewall-Logs,
- Prüfung auf kompromittierten Account.
## Wirkung
- zählt stärker im Host Risk Score,
- zeigt im SOC-Dashboard erhöhte Relevanz,
- signalisiert anderen Admins: Nicht ignorieren.
---
## 11.4 `plausible`
## Bedeutung
Die Detection sieht nachvollziehbar aus, ist aber nicht zwingend dauerhaft legitim.
`plausible` bedeutet:
```text
Das passt wahrscheinlich zum Kontext, soll aber nicht als dauerhaft normaler Zustand betrachtet werden.
```
## Typische Fälle
- Patchday,
- Software-Rollout,
- einmalige Migration,
- einmalige Admin-Aktion,
- Inventarisierung,
- Testlauf,
- neue GPO-Verteilung,
- einmaliges Wartungsfenster.
## Beispiel
```text
reboot_spike auf 200 Clients während Patchfenster
```
Das ist plausibel, aber nicht automatisch dauerhaft normal.
## Wirkung
- wird aus Host Risk Score ausgeschlossen,
- bleibt historisch nachvollziehbar,
- sollte mit Notiz versehen werden,
- sollte nicht blind als dauerhafte Legitimität gelten.
## Wichtig
`plausible` ist oft die beste Bewertung für temporäre Sonderlagen.
---
## 11.5 `legitimate`
## Bedeutung
Die Detection ist fachlich korrekt, aber das Verhalten ist dauerhaft oder regelmäßig legitim.
`legitimate` bedeutet:
```text
Dieses Verhalten ist bekannt, erwartet und akzeptiert.
```
## Typische Fälle
- bekannter Admin-Jump-Host,
- legitimer Service-Account,
- regelmäßiger Backup-Job,
- bekannter Monitoring-Login,
- geplanter nächtlicher Wartungsprozess,
- Admin meldet sich regelmäßig auf einem bestimmten Server an.
## Wirkung
- wird aus Host Risk Score ausgeschlossen,
- setzt `is_legitimate = true`,
- kann zusammen mit Suppression oder Baseline-Exclusion genutzt werden.
## Vorsicht
Nicht zu schnell `legitimate` verwenden.
Eine einmalige plausible Aktion ist nicht automatisch dauerhaft legitim.
---
## 11.6 `false_positive`
## Bedeutung
Die Detection ist ein Fehlalarm.
Das heißt:
```text
Die Regel hat fachlich falsch oder irrelevant ausgelöst.
```
## Typische Fälle
- Parser erkennt falsches Feld,
- Event wird falsch interpretiert,
- Regel ist zu breit,
- Testdaten,
- bekannter technischer Account wurde nicht ausgeschlossen,
- LogonType wurde nicht gefiltert,
- Event stammt nicht aus realem Benutzerverhalten.
## Wirkung
- wird aus Host Risk Score ausgeschlossen,
- setzt `is_false_positive = true`,
- sollte Anlass sein, die Regel zu verbessern.
## Wichtig
`false_positive` sollte nicht für echte, aber harmlose Ereignisse verwendet werden.
Für echte, aber harmlose Ereignisse besser:
```text
plausible
oder
legitimate
```
---
## 11.7 `resolved`
## Bedeutung
Die Detection wurde bearbeitet und abgeschlossen.
## Wann verwenden?
Wenn:
- die Ursache gefunden wurde,
- keine weitere Aktion nötig ist,
- ein Incident abgearbeitet wurde,
- eine legitime Ursache dokumentiert wurde,
- technische Korrektur erfolgt ist.
## Wirkung
- wird aus Host Risk Score ausgeschlossen,
- bleibt historisch sichtbar,
- eignet sich für abgeschlossene Einzelfälle.
---
## 11.8 `suppressed`
## Bedeutung
Die Detection wird bewusst unterdrückt oder soll nicht mehr aktiv betrachtet werden.
## Wann verwenden?
Wenn das Verhalten bekannt ist und künftig nicht mehr alarmieren soll.
Beispiele:
- bekannter technischer Prozess,
- bewusst akzeptiertes Rauschen,
- System außerhalb Überwachungsumfang,
- Testhost,
- bestimmte Regel auf bestimmtem Host irrelevant.
## Wirkung
- wird aus Host Risk Score ausgeschlossen,
- kann zusätzlich eine Detection-Suppression erzeugen,
- reduziert künftige Meldungen.
## Vorsicht
Suppression erzeugt blinde Flecken.
Vor Suppression immer prüfen:
- Ist die Regel auf diesem Host wirklich irrelevant?
- Soll nur diese Regel unterdrückt werden?
- Soll nur ein EventID-Typ unterdrückt werden?
- Soll die Suppression zeitlich begrenzt sein?
- Könnte ein Angreifer dieses Verhalten ausnutzen?
---
## 11.9 `confirmed_incident`
## Bedeutung
Die Detection ist ein bestätigter Sicherheitsvorfall.
## Wann verwenden?
Wenn es Hinweise oder Belege gibt für:
- kompromittierten Account,
- erfolgreiche unberechtigte Anmeldung,
- Malware,
- unautorisierte Service-Installation,
- gelöschte Security Logs,
- laterale Bewegung,
- verdächtige Admin-Aktivität,
- echter Password-Spray mit Treffer.
## Wirkung
- erhöht Host Risk Score stark,
- zählt als bestätigter Incident,
- verhindert Baseline-Lernen für passende Events im Fenster,
- erzeugt automatisch Baseline-Exclusion für 7 Tage, sofern keine andere Baseline-Aktion gewählt wird.
## Wichtig
`confirmed_incident` ist der wichtigste Status, um gefährliches Verhalten nicht als normal einzulernen.
---
# 12. Welche Bewertung beeinflusst den Lerneffekt?
Nicht jeder Status beeinflusst Lernen gleich.
## 12.1 Einfluss auf Host Risk Score
Diese Status werden aus dem Host Risk Score ausgeschlossen:
```text
false_positive
suppressed
legitimate
resolved
plausible
```
Diese Status bleiben relevant:
```text
open
acknowledged
investigating
confirmed_incident
```
`confirmed_incident` erhöht den Risk Score besonders stark.
---
## 12.2 Einfluss auf Baseline-Lernen
Baseline-Lernen wird beeinflusst durch:
1. `baseline_exclusions`
2. `confirmed_incident`
3. manuelle Baseline-Aktionen im UI
Wichtig:
Eine Bewertung als `legitimate` oder `plausible` verhindert nicht automatisch immer das zukünftige Lernen aller ähnlichen Events, außer es wird zusätzlich eine Baseline-Exclusion gesetzt.
---
## 12.3 Einfluss auf UEBA-Lernen
UEBA-Lernen passiert über:
```text
ueba_update
```
Dieses lernt erfolgreiche Logon-Kontexte.
Die aktuelle Bewertung einer Detection ändert nicht automatisch rückwirkend die UEBA-Baseline.
Das bedeutet:
Wenn ein verdächtiger Login bereits in `ueba_user_baseline` eingelernt wurde, muss man ihn gegebenenfalls manuell aus der Baseline entfernen oder die Logik erweitern.
---
## 12.4 Einfluss auf Dynamic Rules
Manuelle Bewertung ändert eine Dynamic Rule nicht automatisch.
Wenn eine Dynamic Rule zu breit ist, muss sie angepasst werden.
---
# 13. Baseline-Aktionen im UI
In der Detection-Bewertung gibt es eine Baseline-Auswahl:
```text
keine Änderung
nicht lernen: 24h
nicht lernen: 7 Tage
nicht lernen: 30 Tage
nicht lernen: dauerhaft
```
Diese Aktionen erzeugen Einträge in:
```text
baseline_exclusions
```
---
## 13.1 `keine Änderung`
## Bedeutung
Die Bewertung beeinflusst die Baseline nicht direkt.
## Wann verwenden?
Wenn:
- die Detection nicht aus der Baseline-Regel stammt,
- die Baseline weiter normal lernen soll,
- das Verhalten künftig durchaus als normal gelten darf,
- keine Gefahr besteht, dass ein Incident eingelernt wird.
---
## 13.2 `nicht lernen: 24h`
## Bedeutung
Für passende Host/Channel/EventID-Kombination wird 24 Stunden nicht gelernt.
## Wann verwenden?
- kurzer Test,
- kleines Wartungsfenster,
- einmaliger Rollout,
- temporärer Zustand,
- kurze Störung.
## Beispiel
```text
Ein Client erzeugt wegen Testkonfiguration ungewöhnlich viele Events.
```
---
## 13.3 `nicht lernen: 7 Tage`
## Bedeutung
Die Baseline lernt eine Woche lang nicht für diese Kombination.
## Wann verwenden?
- Patchwoche,
- Migrationsphase,
- bekannter Vorfall,
- größere Umstellung,
- temporäre Fehlkonfiguration.
## Beispiel
```text
Ein neues Login-Script erzeugt eine Woche lang erhöhte Event-Mengen, bis es korrigiert wird.
```
---
## 13.4 `nicht lernen: 30 Tage`
## Bedeutung
Ein Monat lang wird nicht gelernt.
## Wann verwenden?
- längerer Parallelbetrieb,
- größere Migration,
- unsicherer Zustand,
- neue Infrastrukturphase, deren Normalität noch nicht bewertet ist.
## Vorsicht
30 Tage sind lang. Nicht leichtfertig verwenden.
---
## 13.5 `nicht lernen: dauerhaft`
## Bedeutung
Die Kombination wird dauerhaft nicht in die Baseline übernommen.
## Wann verwenden?
Nur wenn klar ist:
- diese Eventklasse ist für Baseline-Lernen ungeeignet,
- der Host erzeugt absichtlich untypisches Verhalten,
- das Ereignis soll nie als Normalzustand betrachtet werden,
- es handelt sich um dauerhaftes Rauschen.
## Vorsicht
Dauerhafte Ausschlüsse können Erkennungsqualität reduzieren.
---
# 14. Detection-Suppression im UI
Neben Baseline-Aktionen gibt es:
```text
künftig unterdrücken
24h
7 Tage
30 Tage
dauerhaft
```
Das betrifft nicht die Baseline, sondern künftige Detections.
---
## 14.1 Unterschied zwischen Suppression und Baseline-Exclusion
| Mechanismus | Wirkung |
|---|---|
| Suppression | verhindert künftige Detections |
| Baseline-Exclusion | verhindert Lernen in der Baseline |
| Status `plausible` | bewertet aktuelle Detection |
| Status `legitimate` | bewertet aktuelle Detection als legitim |
| Status `false_positive` | bewertet aktuelle Detection als Fehlalarm |
Diese Dinge sind nicht identisch.
---
## 14.2 Beispiel
Ein Patchday erzeugt viele `reboot_spike`-Meldungen.
Mögliche Bewertung:
```text
Status: plausible
Notiz: Patchday April 2026
Baseline: nicht lernen: 24h
Suppression: optional 24h
```
Damit wird:
- die aktuelle Detection aus dem Risiko genommen,
- dokumentiert, warum sie auftrat,
- verhindert, dass das Patchday-Verhalten als Normalzustand gelernt wird,
- optional weitere identische Meldungen für 24h reduziert.
---
# 15. Empfohlener Ablauf während der Anlernphase
## 15.1 Phase 0: Vorbereitung
Vor dem produktiven Start prüfen:
- Agents liefern Events?
- Zeiten stimmen?
- Zeitzone ist korrekt?
- Domain Controller, Server und Clients melden?
- Security Channel wird korrekt übertragen?
- Event XML wird korrekt normalisiert?
- `target_user`, `subject_user`, `src_ip`, `logon_type` werden gefüllt?
- technische Accounts werden ausgeschlossen?
- Privileged Users sind gepflegt?
- bekannte Service Accounts sind bekannt?
- Patchfenster sind dokumentiert?
---
## 15.2 Phase 1: Erste 24 Stunden
Ziel:
```text
Datenqualität prüfen, nicht sofort hart alarmieren.
```
Aufgaben:
- `/ui/events` prüfen.
- Sind EventIDs plausibel?
- Sind Hostnamen korrekt?
- Werden Domain Controller anders sichtbar als Clients?
- Gibt es Encoding-Probleme?
- Werden `SYSTEM`-Logons ausgeschlossen?
- Werden Maschinenkonten ignoriert?
- Sind `4624`, `4625`, `4672` sinnvoll befüllt?
- Erste Dynamic Rules vorsichtig aktivieren.
Bewertung:
- technische Fehlalarme als `false_positive`,
- normale Start-/Patch-/Rollout-Effekte als `plausible`,
- echte Auffälligkeiten als `investigating`,
- bestätigte Vorfälle als `confirmed_incident`.
---
## 15.3 Phase 2: Tag 2 bis Tag 7
Ziel:
```text
Normale Tagesmuster verstehen.
```
Aufgaben:
- täglich offene Detections prüfen,
- wiederkehrende False Positives identifizieren,
- Dynamic Rules nachschärfen,
- technische Accounts ergänzen,
- bekannte Wartungsjobs dokumentieren,
- Privileged Users vervollständigen,
- Host Risk Scores beobachten.
Bewertung:
- nicht alles unterdrücken,
- lieber Notizen setzen,
- bei Wartung `plausible`,
- bei dauerhaft bekannten Mustern `legitimate`,
- bei Regelproblemen `false_positive`.
---
## 15.4 Phase 3: Woche 2 bis Woche 4
Ziel:
```text
Wochenmuster stabilisieren.
```
Aufgaben:
- Baseline-Anomalien ernsthaft bewerten,
- wiederkehrende Muster prüfen,
- dauerhafte Ausnahmen bewusst setzen,
- Suppressions aufräumen,
- echte Admin-Jump-Hosts dokumentieren,
- Service Accounts von echten Benutzern trennen,
- kritische Dynamic Rules finalisieren.
Bewertung:
- wiederkehrende legitime Jobs: `legitimate`,
- einmalige Wartung: `plausible`,
- bestätigte Incidents: `confirmed_incident`,
- schlechte Regel: `false_positive` und Regel korrigieren.
---
## 15.5 Phase 4: Regelbetrieb
Ziel:
```text
Tägliche Sicherheitsüberwachung.
```
Aufgaben:
- offene High/Critical Detections prüfen,
- Host Risk Score prüfen,
- confirmed incidents nachverfolgen,
- neue Dynamic Rules bei Bedarf erstellen,
- Baseline-Exclusions regelmäßig prüfen,
- Suppressions regelmäßig prüfen.
---
# 16. Praktische Bewertungsentscheidung
## 16.1 Entscheidungsbaum
Bei jeder Detection fragen:
```text
1. Ist das Ereignis technisch korrekt erkannt?
```
Wenn nein:
```text
false_positive
Regel/Parser korrigieren
```
Wenn ja:
```text
2. Ist das Verhalten erwartet?
```
Wenn nein oder unklar:
```text
investigating
```
Wenn ja:
```text
3. Ist es einmalig/temporär oder dauerhaft normal?
```
Temporär:
```text
plausible
Notiz setzen
ggf. Baseline nicht lernen 24h/7d
```
Dauerhaft normal:
```text
legitimate
ggf. Suppression oder Regelanpassung
```
Wenn bestätigt bösartig:
```text
confirmed_incident
Baseline nicht lernen
Incident-Prozess starten
```
---
## 16.2 Kurzmatrix
| Situation | Status | Baseline-Aktion | Suppression |
|---|---|---|---|
| echter Angriff | `confirmed_incident` | nicht lernen 7d/30d | nein |
| unklar, wird geprüft | `investigating` | keine oder nicht lernen 24h | nein |
| Patchday | `plausible` | nicht lernen 24h | optional 24h |
| geplanter Rollout | `plausible` | nicht lernen 24h/7d | optional |
| dauerhafter Backup-Job | `legitimate` | ggf. dauerhaft nicht lernen | ggf. dauerhaft |
| Parserfehler | `false_positive` | keine | nein, Regel fixen |
| Regel zu breit | `false_positive` | keine | nein, Regel anpassen |
| Testsystem rauscht | `suppressed` | optional | ja |
| Vorfall abgeschlossen | `resolved` | abhängig vom Fall | abhängig vom Fall |
---
# 17. Beispiele aus dem Alltag
---
## 17.1 Beispiel: Patchday erzeugt Reboot-Spikes
Detection:
```text
reboot_spike auf vielen Clients
```
Analyse:
- Zeitpunkt passt zum Patchfenster.
- Viele Clients betroffen.
- Keine weiteren verdächtigen Events.
- Reboots sind erwartet.
Bewertung:
```text
Status: plausible
Notiz: Patchday April 2026, WSUS-Rollout
Baseline: nicht lernen: 24h
Suppression: optional 24h
```
Nicht verwenden:
```text
false_positive
```
Warum?
Die Detection war fachlich korrekt. Es war kein Fehlalarm, sondern erwartetes Verhalten.
---
## 17.2 Beispiel: SYSTEM flutet Off-Hours-Login
Detection:
```text
ueba_offhours_login: Benutzer SYSTEM auf SERVER01
```
Analyse:
- SYSTEM ist technischer Account.
- Solche Logons sind normal.
- Die Regel ist zu breit.
Bewertung:
```text
Status: false_positive
Notiz: Technischer Account SYSTEM, Regel um Noise-Account-Filter erweitern
Baseline: keine Änderung
Suppression: nur kurzfristig, besser Regel fixen
```
Zusätzliche Maßnahme:
- `SYSTEM` in `isNoiseAccount()` ausschließen.
- LogonType auf `2,7,10,11` begrenzen.
---
## 17.3 Beispiel: Admin meldet sich erstmals auf Client an
Detection:
```text
ueba_admin_new_host: adm.max auf CLIENT099
```
Analysefragen:
- Hat der Admin dort gearbeitet?
- Gab es ein Ticket?
- War es Remotehilfe?
- Ist CLIENT099 ein normaler Client?
- Gab es vorher Fehlversuche?
- War es außerhalb Arbeitszeit?
- Von welcher Quell-IP kam der Login?
Mögliche Bewertungen:
### Legitime Remotehilfe
```text
Status: plausible
Notiz: Remotehilfe Ticket #12345 durch adm.max
Baseline: keine Änderung oder nicht lernen 24h
```
### Admin nutzt Client regelmäßig als Admin-Station
```text
Status: legitimate
Notiz: CLIENT099 ist Admin-Workstation von adm.max
Baseline: lernen erlauben
```
### Nicht erklärbar
```text
Status: investigating
Notiz: Admin-Login auf ungewohntem Client, Rückfrage offen
```
### Kompromittierung bestätigt
```text
Status: confirmed_incident
Notiz: adm.max kompromittiert, unautorisierter Login
Baseline: nicht lernen 7d/30d
```
---
## 17.4 Beispiel: Password-Spray
Detection:
```text
password_spray von 10.2.50.77 gegen 18 Benutzer
```
Analyse:
- Quell-IP identifizieren.
- Gehört sie zu VPN, Proxy, Server, Scanner?
- Gab es erfolgreiche Logons danach?
- Sind privilegierte Benutzer betroffen?
- Gibt es Account Lockouts?
Bewertung bei echtem Angriff:
```text
Status: confirmed_incident
Notiz: Password-Spray von 10.2.50.77, mehrere Benutzer betroffen
Baseline: nicht lernen 7d
Suppression: nein
```
Bewertung bei bekanntem Scanner mit falschen Credentials:
```text
Status: legitimate oder plausible
Notiz: Scanner X mit falschem Credential, Ticket zur Korrektur erstellt
Baseline: nicht lernen 24h oder 7d
Suppression: optional kurzzeitig
```
---
## 17.5 Beispiel: Baseline-Anomalie auf Domain Controller
Detection:
```text
baseline_event_rate_anomaly
DC01 Security 4625 kam 200-mal in 5 Minuten
```
Analyse:
- Gibt es zeitgleich `password_spray`?
- Gibt es Account Lockouts?
- Welche Quell-IP?
- Welche Benutzer?
- Patch-/Wartungsfenster?
- Neue Anwendung?
- VPN/RADIUS/LDAP-Fehler?
Bewertung:
Bei unbekannter Ursache:
```text
Status: investigating
Baseline: nicht lernen 24h
```
Bei bestätigtem Angriff:
```text
Status: confirmed_incident
Baseline: nicht lernen 7d/30d
```
Bei bekannter Fehlkonfiguration:
```text
Status: plausible
Notiz: Dienst XY nutzt altes Passwort, Korrektur geplant
Baseline: nicht lernen 7d
```
---
# 18. Was darf während der Anlernphase nicht passieren?
## 18.1 Nicht alles als legitim markieren
Falsch:
```text
Alle Detections der ersten Woche sind bestimmt normal.
```
Warum gefährlich?
- Angriffe können eingelernt werden.
- Host Risk Score wird künstlich reduziert.
- Auffällige Admin-Logins verschwinden aus der Priorisierung.
---
## 18.2 Nicht alles dauerhaft unterdrücken
Falsch:
```text
Diese Regel nervt, also Suppression dauerhaft.
```
Warum gefährlich?
- Künftige echte Vorfälle werden nicht mehr gemeldet.
- Angreifer können Verhalten nutzen, das blindgeschaltet wurde.
- SOC-Übersicht wird scheinbar ruhig, aber weniger sicher.
---
## 18.3 Confirmed Incidents nicht als plausible markieren
Falsch:
```text
Der Angriff ist ja vorbei, also plausible.
```
Richtig:
```text
confirmed_incident
```
Warum?
Nur so wird klar:
- es war ein echter Vorfall,
- der Host Risk Score wird korrekt erhöht,
- Baseline-Lernen wird verhindert,
- spätere Auswertungen bleiben korrekt.
---
## 18.4 Parserfehler nicht als legitimate markieren
Falsch:
```text
SYSTEM-Noise ist normal, also legitimate.
```
Besser:
```text
false_positive
Regel korrigieren
```
Warum?
Wenn die Regel falsch filtert, ist das kein legitimer Sicherheitsfall, sondern ein Regelproblem.
---
# 19. Wie Notizen geschrieben werden sollten
Jede manuelle Bewertung sollte eine brauchbare Notiz enthalten.
Gute Notizen beantworten:
- Was war die Ursache?
- Wer hat es geprüft?
- Gibt es ein Ticket?
- Ist es einmalig oder dauerhaft?
- Welche Maßnahme wurde getroffen?
- Soll das Verhalten künftig gelernt werden?
---
## 19.1 Gute Beispiele
```text
Patchday April 2026, WSUS-Rollout auf Clients, Reboots erwartet.
```
```text
Remotehilfe Ticket #4711, adm.max hat sich auf CLIENT099 angemeldet.
```
```text
Dienstkonto svc-backup nach Passwortwechsel mit altem Credential, Ticket #4812 zur Korrektur.
```
```text
Bestätigter Password-Spray von 10.2.50.77, Firewall-Block gesetzt, betroffene Benutzer geprüft.
```
---
## 19.2 Schlechte Beispiele
```text
ok
```
```text
normal
```
```text
passt
```
```text
weg
```
```text
keine Ahnung
```
Solche Notizen helfen später niemandem.
---
# 20. Auswirkungen auf den Host Risk Score
Der Host Risk Score aggregiert relevante Detections pro Host.
## 20.1 Diese Status zählen weiter
```text
open
acknowledged
investigating
confirmed_incident
```
## 20.2 Diese Status zählen nicht weiter
```text
false_positive
suppressed
legitimate
resolved
plausible
```
## 20.3 Warum ist das wichtig?
Wenn zu viel als `plausible`, `legitimate` oder `false_positive` markiert wird, fällt der Host Risk Score künstlich ab.
Wenn echte Vorfälle als `confirmed_incident` markiert werden, steigt der Host Risk Score deutlich.
---
## 20.4 Beispiel
Host `CLIENT099` hat:
- 1x `ueba_admin_new_host` high open,
- 1x `success_after_failures` high investigating,
- 1x `password_spray` medium open.
Der Host Risk Score ist erhöht.
Wenn alle drei Detections als `plausible` markiert werden, fällt der Host aus der Priorisierung.
Das ist nur korrekt, wenn wirklich alle drei plausibel sind.
---
# 21. Auswirkungen auf Baseline-Qualität
## 21.1 Gute Baseline
Eine gute Baseline entsteht, wenn normale Ereignisse gelernt werden und unnormale Ereignisse nicht gelernt werden.
Normales Verhalten:
- tägliche Anmeldemuster,
- übliche Eventmengen,
- regelmäßige Systemjobs,
- bekannte Wartungsfenster, wenn sie regelmäßig sind.
Nicht lernen:
- Angriffe,
- Fehlkonfigurationen,
- Testfluten,
- einmalige Rollouts,
- Massenfehler,
- außergewöhnliche Störungen.
---
## 21.2 Schlechte Baseline
Eine schlechte Baseline entsteht, wenn außergewöhnliches Verhalten als normal gelernt wird.
Beispiele:
- ein kompromittierter Account während Anlernphase,
- ein falsch konfigurierter Dienst mit tausenden Fehlversuchen,
- Patchday als tägliches Normalverhalten,
- einmalige Migration als Normalzustand,
- SYSTEM-Noise in Benutzerregeln.
---
## 21.3 Symptome einer schlechten Baseline
- echte Auffälligkeiten erzeugen keine Alerts,
- viele irrelevante Alerts,
- Baseline-Werte sind extrem hoch,
- Z-Scores bleiben niedrig trotz auffälligem Verhalten,
- bestimmte Hosts erscheinen nie auffällig,
- andere Hosts sind ständig auffällig.
---
## 21.4 Was tun bei schlechter Baseline?
Möglichkeiten:
1. Baseline-Einträge gezielt löschen.
2. Baseline für bestimmte Kombinationen neu aufbauen.
3. Baseline-Exclusions setzen.
4. Regeln schärfen.
5. technische Accounts ausschließen.
6. Retention/Reset-Konzept einführen.
---
# 22. Auswirkungen auf UEBA-Qualität
## 22.1 Gute UEBA-Baseline
Eine gute UEBA-Baseline enthält echte, normale Benutzerkontexte.
Beispiele:
- Benutzer A arbeitet auf Client A.
- Admin B arbeitet auf Jump Host B.
- Service Account C nutzt Server C.
- VPN-Benutzer haben bekannte Quellbereiche.
---
## 22.2 Schlechte UEBA-Baseline
Eine schlechte UEBA-Baseline enthält verdächtige oder falsche Kontexte.
Beispiele:
- kompromittierter Admin auf fremdem Client,
- SYSTEM als Benutzerkontext,
- Maschinenkonten als normale Benutzer,
- RDP-Lateral-Movement als normaler Kontext,
- einmalige Notfallaktion als dauerhaft normal.
---
## 22.3 Wann UEBA-Kontexte bereinigt werden sollten
Manuell bereinigen oder später Funktion ergänzen, wenn:
- ein Account kompromittiert war,
- ein Admin versehentlich auf vielen Clients angemeldet war,
- ein Dienst falsch lief,
- Testdaten importiert wurden,
- technische Accounts eingelernt wurden,
- VPN-/NAT-Fehler falsche Quell-IPs erzeugt haben.
---
# 23. Empfohlene Bedienregeln für unwissende Admins
## 23.1 Goldene Regel 1
```text
Nicht wegklicken. Erst verstehen.
```
Jede Detection sollte mindestens kurz fachlich eingeordnet werden.
---
## 23.2 Goldene Regel 2
```text
Plausibel ist nicht dasselbe wie legitim.
```
`plausible` ist für temporär erklärbare Ereignisse.
`legitimate` ist für dauerhaft akzeptiertes Verhalten.
---
## 23.3 Goldene Regel 3
```text
False Positive heißt: Die Regel war falsch, nicht das Ereignis war harmlos.
```
Ein echter Patchday-Reboot ist kein False Positive.
---
## 23.4 Goldene Regel 4
```text
Confirmed Incident immer als confirmed_incident markieren.
```
Nicht als `resolved`, nicht als `plausible`, nicht als `legitimate`.
Erst später kann der Vorfall zusätzlich abgeschlossen werden, aber die historische Detection sollte als Incident erkennbar bleiben.
---
## 23.5 Goldene Regel 5
```text
Baseline nicht mit Störungen trainieren.
```
Bei Wartung, Angriffen, Fehlkonfigurationen und Testfluten:
```text
nicht lernen
```
verwenden.
---
## 23.6 Goldene Regel 6
```text
Suppression nur bewusst und möglichst zeitlich begrenzt.
```
Dauerhafte Suppression nur nach Prüfung.
---
## 23.7 Goldene Regel 7
```text
Notizen müssen später verständlich sein.
```
Immer mit Ursache, Kontext und ggf. Ticketnummer dokumentieren.
---
# 24. Empfohlene Rechte- und Rollenverteilung
## 24.1 Viewer
Darf:
- Detections ansehen,
- Events ansehen,
- SOC-Dashboard ansehen.
Darf nicht:
- Detections bewerten,
- Suppressions setzen,
- Baselines ausschließen,
- Regeln ändern.
## 24.2 Analyst
Darf:
- Detections bewerten,
- Notizen setzen,
- Status ändern,
- temporäre Baseline-Exclusions setzen.
Darf vorsichtig:
- temporäre Suppressions setzen.
Darf nicht ohne Freigabe:
- dauerhafte Suppression,
- Dynamic Rules ändern,
- Baseline komplett löschen.
## 24.3 Admin
Darf:
- Regeln pflegen,
- Privileged Users pflegen,
- Suppressions verwalten,
- Baseline-Exclusions verwalten,
- Dynamic Rules anpassen,
- Indizes/DB warten.
## 24.4 Security Lead
Darf entscheiden:
- was als confirmed_incident gilt,
- welche Suppressions dauerhaft sind,
- welche Baselines zurückgesetzt werden,
- welche Regeln kritisch sind,
- welche Betriebsprozesse gelten.
---
# 25. Tagesroutine für Admins
## 25.1 Morgens
1. SOC Dashboard öffnen.
2. Top Host Risk Scores prüfen.
3. Critical/High Detections prüfen.
4. Neue `confirmed_incident` prüfen.
5. Offene `investigating` weiterverfolgen.
6. Patch-/Wartungsereignisse bewerten.
## 25.2 Während des Tages
- Neue High/Critical Detections zeitnah prüfen.
- Bei ungewöhnlichen Admin-Logins Rückfrage halten.
- Bei Password-Spray Quell-IP prüfen.
- Bei Success-after-Failure Benutzer und Quelle prüfen.
- Notizen setzen.
## 25.3 Nachmittags / Tagesabschluss
- Offene Detections nicht unnötig offen lassen.
- Geklärte Fälle bewerten.
- False Positives in Regelverbesserung überführen.
- Suppressions dokumentieren.
- Incidents sauber markieren.
---
# 26. Wochenroutine
Einmal pro Woche:
- häufigste Detections prüfen,
- häufigste False Positives prüfen,
- Suppressions prüfen,
- Baseline-Exclusions prüfen,
- Privileged Users prüfen,
- Dynamic Rules nachschärfen,
- technische Noise-Accounts ergänzen,
- Host Risk Score Trends prüfen.
---
# 27. Monatsroutine
Einmal pro Monat:
- Baseline-Qualität prüfen,
- UEBA-Kontexte stichprobenartig prüfen,
- alte Suppressions entfernen,
- dauerhafte Suppressions rechtfertigen,
- Admin-Konten prüfen,
- Service Accounts prüfen,
- Regelwerk dokumentieren,
- Lessons Learned aus Incidents übernehmen.
---
# 28. Umgang mit Wartungsfenstern
## 28.1 Vor Wartung
Vor größeren Wartungen dokumentieren:
- Zeitraum,
- betroffene Systeme,
- erwartete Events,
- verantwortlicher Admin,
- Ticketnummer,
- erwartete Reboots,
- erwartete Service-Installationen.
## 28.2 Während Wartung
Detections nicht blind löschen.
Bewerten mit:
```text
plausible
```
Notiz:
```text
Wartungsfenster Ticket #12345, Update Exchange Server SE, Reboots erwartet.
```
Baseline:
```text
nicht lernen: 24h oder 7 Tage
```
Suppression:
```text
optional zeitlich begrenzt
```
## 28.3 Nach Wartung
Prüfen:
- treten Detections weiter auf?
- gibt es unerwartete Hosts?
- gab es erfolgreiche Logons nach Fehlversuchen?
- gab es neue Admin-Kontexte?
- sind Services installiert worden?
- sind Security Logs gelöscht worden?
---
# 29. Umgang mit Patchdays
Patchdays erzeugen oft:
- `reboot_spike`,
- `agent_offline`,
- `baseline_event_rate_anomaly`,
- `new_event_id`,
- Service-Events,
- neue Fehler durch defekte Updates.
Empfohlene Bewertung:
| Fall | Bewertung |
|---|---|
| erwartete Reboots | `plausible` |
| Agent kurz offline | `plausible` |
| viele neue EventIDs nach Update | `plausible`, prüfen |
| Security Log gelöscht | nicht automatisch plausibel |
| Admin-Login auf ungewöhnlichem Host | prüfen |
| Password-Spray | nicht mit Patchday erklären |
---
# 30. Umgang mit Service Accounts
Service Accounts können viele Events erzeugen.
Empfehlungen:
- Service Accounts dokumentieren.
- Namensschema verwenden, z. B. `svc-*`.
- Nicht als normale Benutzer bewerten.
- Bei Fehlversuchen Passwort/Secret prüfen.
- Bei Off-Hours-Regeln gesondert behandeln.
- Nicht pauschal alles suppressen.
Bewertung:
| Situation | Status |
|---|---|
| bekannter Backup-Service | `legitimate` |
| Service mit altem Passwort | `plausible` oder `investigating` |
| unbekannter Service Account | `investigating` |
| Service Account meldet sich interaktiv an | verdächtig |
---
# 31. Umgang mit Admin-Konten
Admin-Konten sind besonders kritisch.
Empfehlungen:
- alle bekannten Admin-Konten in `privileged_users` pflegen,
- Admin-Konten nicht für normale Arbeit nutzen,
- Admin-Logins auf Clients prüfen,
- RDP-Logins mit Admin-Konto priorisieren,
- Off-Hours-Admin-Logins prüfen,
- neue Host-Kontexte für Admins immer bewerten.
Bewertung:
| Situation | Status |
|---|---|
| Admin auf bekanntem Jump Host | `legitimate` |
| Admin auf neuem Server mit Ticket | `plausible` |
| Admin auf normalem Client ohne Erklärung | `investigating` |
| Admin nachts auf fremdem Host | mindestens `investigating` |
| kompromittierter Admin | `confirmed_incident` |
---
# 32. Umgang mit False Positives
False Positives sind nützlich, wenn sie zur Regelverbesserung führen.
## 32.1 Vorgehen
1. Detection als `false_positive` markieren.
2. Notiz setzen.
3. Ursache beschreiben.
4. Regel anpassen.
5. Prüfen, ob neue Detections sauberer werden.
## 32.2 Beispiele
```text
SYSTEM wurde nicht ausgeschlossen.
```
```text
LogonType 3 erzeugt zu viel Rauschen.
```
```text
Service Account wird als Benutzer behandelt.
```
```text
EventID in falschem Channel ausgewertet.
```
```text
Parser liest TargetUserName falsch.
```
---
# 33. Umgang mit Confirmed Incidents
## 33.1 Vorgehen
Wenn eine Detection ein echter Vorfall ist:
1. Status auf `confirmed_incident`.
2. Notiz mit Fakten schreiben.
3. Baseline nicht lernen lassen.
4. Kein Suppression setzen, solange Angriff aktiv sein könnte.
5. Betroffene Systeme prüfen.
6. Benutzer/Account prüfen.
7. Quell-IP prüfen.
8. Weitere Detections im gleichen Zeitraum prüfen.
9. Nach Abschluss Maßnahmen dokumentieren.
## 33.2 Notizbeispiel
```text
Confirmed Incident: adm.max kompromittiert. Unautorisierter RDP-Login auf CLIENT099 um 02:14 Uhr. Account deaktiviert, Passwort zurückgesetzt, Host isoliert. Ticket IR-2026-0042.
```
## 33.3 Warum nicht `resolved`?
`resolved` bedeutet abgeschlossen, aber nicht zwingend bösartig.
Ein echter Vorfall sollte historisch als `confirmed_incident` erkennbar bleiben.
Optional kann später zusätzlich ein eigener Incident-Prozess außerhalb der Detection laufen.
---
# 34. Typische Anfängerfehler
## 34.1 Alles auf `resolved` setzen
Problem:
- Host Risk Score sinkt,
- Ursache bleibt unklar,
- spätere Auswertung wertlos.
Besser:
- erst fachlich bewerten,
- dann passenden Status setzen.
## 34.2 `false_positive` für Wartung nutzen
Problem:
- Wartung war echt, nicht falsch erkannt.
Besser:
```text
plausible
```
## 34.3 Dauerhaft suppressen, weil es nervt
Problem:
- blinde Flecken.
Besser:
- Regel verbessern,
- technische Accounts ausschließen,
- Suppression zeitlich begrenzen.
## 34.4 Keine Notizen schreiben
Problem:
- niemand weiß später, warum etwas bewertet wurde.
Besser:
- kurze, klare Ursache plus Ticket.
## 34.5 Baseline während Incident lernen lassen
Problem:
- bösartiges Verhalten wird normalisiert.
Besser:
```text
confirmed_incident
Baseline: nicht lernen
```
---
# 35. Beispiel: vollständiger Bewertungsablauf
Detection:
```text
success_after_failures
Host: CLIENT099
User: max.mustermann
Source IP: 10.2.50.77
Severity: high
```
## Schritt 1: Eventkontext prüfen
- Gab es vorher 4625?
- Wie viele Fehlversuche?
- Welche Quell-IP?
- War der erfolgreiche Login von derselben Quelle?
- Gab es weitere Benutzer?
- Ist die Quelle bekannt?
## Schritt 2: Benutzer prüfen
- Hat der Benutzer zu diesem Zeitpunkt gearbeitet?
- Ist der Benutzer im Urlaub?
- Gab es Passwortänderung?
- Ist MFA/VPN beteiligt?
- Ist es ein Admin?
## Schritt 3: Host prüfen
- Ist CLIENT099 der normale Client?
- Ist der Host ungewöhnlich?
- Gibt es weitere Detections auf dem Host?
- Host Risk Score erhöht?
## Schritt 4: Bewertung
### Benutzer bestätigt eigene Vertipper
```text
Status: plausible
Notiz: Benutzer bestätigt mehrere Fehlversuche nach Passwortwechsel, danach erfolgreicher Login.
Baseline: keine Änderung
```
### Quelle unbekannt, Benutzer bestätigt es nicht
```text
Status: investigating
Notiz: Benutzer bestätigt Login nicht, Quell-IP 10.2.50.77 wird geprüft.
Baseline: nicht lernen 24h
```
### Kompromittierung bestätigt
```text
Status: confirmed_incident
Notiz: Benutzer bestätigt Login nicht, Quell-IP unbekannt, Account gesperrt, Host isoliert, Ticket IR-...
Baseline: nicht lernen 7d
```
---
# 36. Sicherheitsprinzip: Lernen ist Vertrauen
Ein wichtiger Merksatz:
```text
Was gelernt wird, dem vertraut die Software später eher.
```
Deshalb:
- nur normales Verhalten lernen lassen,
- verdächtiges Verhalten untersuchen,
- bösartiges Verhalten ausschließen,
- temporäre Sonderfälle nicht dauerhaft normalisieren.
---
# 37. Empfohlene UI-Texte für Admin-Schulung
## 37.1 Plausible
```text
Verwenden, wenn das Ereignis durch einen bekannten temporären Kontext erklärbar ist, z. B. Wartung, Patchday oder Rollout. Nicht für dauerhaft normales Verhalten.
```
## 37.2 Legitimate
```text
Verwenden, wenn das Verhalten dauerhaft bekannt, erwartet und akzeptiert ist. Vorsichtig verwenden, da es aus der Risikobewertung fällt.
```
## 37.3 False Positive
```text
Verwenden, wenn die Regel falsch oder technisch irreführend ausgelöst hat. Danach sollte die Regel verbessert werden.
```
## 37.4 Confirmed Incident
```text
Verwenden, wenn ein echter Sicherheitsvorfall bestätigt wurde. Verhindert, dass entsprechendes Verhalten als normal eingelernt wird.
```
## 37.5 Suppressed
```text
Verwenden, wenn diese Detection künftig bewusst nicht mehr gemeldet werden soll. Möglichst zeitlich begrenzen.
```
---
# 38. Empfohlene Startkonfiguration für sichere Anlernphase
## 38.1 Baseline
```text
BASELINE_ENABLED=true
BASELINE_WINDOW=5m
BASELINE_MIN_SAMPLES=24
BASELINE_MIN_COUNT=10
BASELINE_MEDIUM_Z=2.5
BASELINE_HIGH_Z=4.0
BASELINE_SUPPRESS_FOR=1h
```
## 38.2 UEBA
```text
UEBA_ENABLED=true
UEBA_LOOKBACK=720h
UEBA_NEW_CONTEXT_WINDOW=10m
```
## 38.3 Detection
```text
DETECTION_INTERVAL=1m
```
## 38.4 Empfehlung
In den ersten 7 Tagen lieber:
- mehr prüfen,
- weniger dauerhaft suppressen,
- gute Notizen schreiben,
- Baseline-Exclusions bei Sonderlagen setzen.
---
# 39. Wann sollte man Baseline zurücksetzen?
Ein kompletter oder teilweiser Reset kann sinnvoll sein nach:
- großem Rollout,
- massiver Fehlkonfiguration,
- längerer Testphase mit falschen Daten,
- Umstellung der Audit Policies,
- Änderung der Agent-Filter,
- Korrektur von Parserfehlern,
- Kompromittierung während Anlernphase.
## 39.1 Teilweiser Reset
Besser als Komplettreset ist oft ein gezieltes Löschen:
```text
für Host + Channel + EventID
```
Beispiel:
```text
DC01 + Security + 4625
```
## 39.2 Komplettreset
Nur wenn die gesamte Baseline unbrauchbar ist.
Vorher klären:
- Warum ist sie unbrauchbar?
- Wurde die Ursache behoben?
- Wird danach sauber neu gelernt?
- Sind Admins informiert?
---
# 40. Wann sollte man UEBA zurücksetzen?
UEBA-Kontexte sollten bereinigt werden, wenn falsche oder gefährliche Kontexte gelernt wurden.
Beispiele:
- kompromittierter Account,
- Testdaten,
- SYSTEM/Service Accounts fälschlich gelernt,
- Admin hat versehentlich viele Clients besucht,
- Jump-Host-Konzept wurde geändert,
- VPN/NAT lieferte falsche Quell-IPs.
Empfehlung:
- gezielt pro Benutzer löschen,
- gezielt pro Host löschen,
- gezielt technische Accounts entfernen,
- nicht pauschal alles löschen, wenn nur einzelne Kontexte falsch sind.
---
# 41. Wichtige technische Qualitätsprüfungen
Admins sollten regelmäßig prüfen:
## 41.1 Zeit
- Sind Client-Zeiten korrekt?
- Ist Server-Zeit korrekt?
- Ist `TZ=Europe/Berlin` gesetzt?
- Sind UTC-Zeiten in DB konsistent?
## 41.2 Eventfelder
- Wird `target_user` korrekt gefüllt?
- Wird `subject_user` korrekt gefüllt?
- Wird `src_ip` korrekt gefüllt?
- Wird `logon_type` korrekt gefüllt?
- Werden Maschinenkonten erkannt?
- Werden Domain-Präfixe normalisiert?
## 41.3 Noise
- Taucht `SYSTEM` als Benutzer-Detection auf?
- Tauchen `DWM-*` oder `UMFD-*` auf?
- Tauchen viele Service-Logons auf?
- Werden LogonType 3 und 5 unnötig alarmiert?
## 41.4 Datenmenge
- Kommen alle Agents?
- Gibt es Hosts ohne Events?
- Gibt es extreme Eventfluten?
- Sind Indizes vorhanden?
- Laufen Queries schnell genug?
---
# 42. Beispielhafte Schulungsübung
Ein neuer Admin soll 10 Detections bewerten.
## Aufgabe
Für jede Detection beantworten:
1. Welche Regel hat ausgelöst?
2. Welche Daten liegen zugrunde?
3. Ist das Ereignis technisch korrekt?
4. Ist es erwartbar?
5. Ist es einmalig oder dauerhaft?
6. Soll die Baseline lernen?
7. Ist Suppression sinnvoll?
8. Welche Notiz wird geschrieben?
9. Welcher Status ist korrekt?
## Ziel
Der Admin soll nicht nur klicken, sondern begründen.
---
# 43. Kurze Checkliste pro Detection
Vor Bewertung prüfen:
```text
[ ] Regel verstanden
[ ] Host geprüft
[ ] Benutzer geprüft
[ ] Quell-IP geprüft
[ ] Zeit geprüft
[ ] Eventdetails geprüft
[ ] ähnliche Detections geprüft
[ ] Wartungsfenster geprüft
[ ] Ticket/Change geprüft
[ ] Status bewusst gewählt
[ ] Notiz geschrieben
[ ] Baseline-Aktion geprüft
[ ] Suppression bewusst entschieden
```
---
# 44. Empfohlene Status-Definition für Betriebsdokumentation
Diese Definitionen sollten intern verbindlich sein:
```text
open:
Neu und ungeprüft.
acknowledged:
Gesehen, aber noch nicht abschließend geprüft.
investigating:
Aktive Untersuchung läuft.
plausible:
Temporär erklärbar, aber nicht dauerhaft als normal bestätigt.
legitimate:
Dauerhaft erwartetes und akzeptiertes Verhalten.
false_positive:
Regel oder Erkennung war fachlich/technisch falsch.
resolved:
Bearbeitet und abgeschlossen, kein weiterer Handlungsbedarf.
suppressed:
Bewusst unterdrückt, künftig nicht mehr oder vorübergehend nicht relevant.
confirmed_incident:
Bestätigter Sicherheitsvorfall.
```
---
# 45. Zusammenfassung
Die Software lernt aus beobachtetem Verhalten. Dadurch wird sie mit der Zeit besser, aber nur, wenn die Daten sauber sind und die Admins korrekt bewerten.
Wichtigste Punkte:
1. Die Anlernphase ist kritisch.
2. Nicht alles am Anfang ist automatisch normal.
3. Baseline lernt Eventmengen nach Host, Channel, EventID, Wochentag und Stunde.
4. UEBA lernt Benutzerkontexte.
5. Dynamic Rules lernen nicht selbst, sondern müssen gepflegt werden.
6. `plausible` ist für temporär erklärbare Ereignisse.
7. `legitimate` ist für dauerhaft akzeptiertes Verhalten.
8. `false_positive` ist für falsche Regeln/Erkennungen.
9. `confirmed_incident` ist für echte Vorfälle.
10. Baseline darf Incidents nicht lernen.
11. Suppression erzeugt blinde Flecken und muss bewusst eingesetzt werden.
12. Gute Notizen sind Pflicht.
13. Host Risk Score hängt stark von korrekter Bewertung ab.
14. Technische Accounts und LogonTypes müssen sauber gefiltert werden.
15. Regelmäßige Pflege verbessert die Erkennungsqualität.
Der wichtigste Satz für Admins:
```text
Bewertung ist Teil der Sicherheit. Falsch bewertete Detections können die Erkennung verschlechtern.
```
# SIEM-lite Regel-Dokumentation
Stand: 2026-04-27
Projekt: `siem-backend` / `SIEM-lite Security Operations`
Diese Dokumentation beschreibt die im Backend implementierten Detection-Regeln, ihre Datenbasis, Schwellenwerte, Statuslogik, Suppression-Mechanismen und empfohlene Bewertung im SOC.
---
## 1. Überblick
Das Backend nimmt Windows Eventlog-Daten von Agents über `/ingest` entgegen, normalisiert wichtige Felder aus dem Event-XML und speichert sie in MySQL. In regelmäßigen Intervallen läuft ein Detection-Loop, der verschiedene statische, dynamische, Baseline- und UEBA-Regeln auswertet.
Der zentrale Detection-Loop befindet sich in:
```go
func (s *server) runDetectionsOnce()
```
Aktuell vorgesehene Regeln:
```go
agent_offline
failed_logon_spike
reboot_spike
new_event_id
password_spray
success_after_failures
new_source_ip_for_user
dynamic_rules
baseline_anomaly
baseline_update
ueba_admin_new_host
ueba_offhours_login
ueba_first_privileged_use
ueba_new_user_context
ueba_update
host_risk_score
```
---
## 2. Datenbasis
### 2.1 Tabelle `event_logs`
Die meisten Regeln basieren auf normalisierten Windows-Events in `event_logs`.
Wichtige Felder:
| Feld | Bedeutung |
|---|---|
| `hostname` | Hostname des meldenden Systems oder aus dem Event-XML |
| `channel_name` | Windows Eventlog-Channel, z. B. `Security`, `System`, `Application` |
| `event_id` | Windows Event ID |
| `target_user` | Zielbenutzer, meist aus `TargetUserName` |
| `subject_user` | ausführender Benutzer, meist aus `SubjectUserName` |
| `src_ip` | Quell-IP aus `IpAddress` |
| `workstation` | Workstation aus `WorkstationName` |
| `logon_type` | Windows LogonType |
| `process_name` | Prozessname, sofern vorhanden |
| `ts` | Event-Zeitpunkt |
| `received_at` | Empfangszeitpunkt |
| `msg` | Rohes Event-XML |
| `msg_sha256` | Hash des Event-XML |
### 2.2 Tabelle `detections`
Alle Regeln schreiben Findings in die Tabelle `detections`.
Wichtige Felder:
| Feld | Bedeutung |
|---|---|
| `rule_name` | Name der Regel |
| `severity` | `info`, `low`, `medium`, `high`, `critical` |
| `hostname` | betroffener Host |
| `channel_name` | Eventlog-Channel |
| `event_id` | relevante Event ID |
| `score` | numerischer Risiko-/Anomalie-Score |
| `window_start` | Beginn des betrachteten Zeitfensters |
| `window_end` | Ende des betrachteten Zeitfensters |
| `summary` | menschenlesbare Zusammenfassung |
| `details_json` | technische Details als JSON |
| `status` | SOC-Bewertung |
| `analyst_note` | Analystenkommentar |
| `reviewed_by` | Bearbeiter |
| `reviewed_at` | Bewertungszeitpunkt |
| `is_false_positive` | Flag für False Positive |
| `is_legitimate` | Flag für legitimes/plausibles Verhalten |
---
## 3. Globale Konfiguration
Die wichtigsten Regelparameter werden per Environment-Variablen gesetzt.
| Variable | Default | Bedeutung |
|---|---:|---|
| `DETECTION_INTERVAL` | `1m` | Intervall des Detection-Loops |
| `OFFLINE_AFTER` | `10m` | Agent gilt nach dieser Zeit als offline |
| `OFFLINE_ALERT_MAX` | `120m` | Maximales Offline-Alter für Offline-Alerts |
| `FAILED_LOGON_WINDOW` | `5m` | Zeitfenster für fehlgeschlagene Logons |
| `FAILED_LOGON_THRESHOLD` | `25` | Mindestanzahl fehlgeschlagener Logons pro Host |
| `REBOOT_WINDOW` | `15m` | Zeitfenster für Reboot-Spikes |
| `REBOOT_THRESHOLD` | `3` | Mindestanzahl Reboot-/Shutdown-Events |
| `PASSWORD_SPRAY_WINDOW` | `5m` | Zeitfenster für Password-Spray |
| `PASSWORD_SPRAY_MIN_USERS` | `5` | Mindestanzahl unterschiedlicher Zielbenutzer |
| `PASSWORD_SPRAY_MIN_ATTEMPTS` | `15` | Mindestanzahl Fehlversuche |
| `SUCCESS_AFTER_FAILURE_WINDOW` | `10m` | Zeitfenster für Erfolg nach Fehlversuchen |
| `NEW_SOURCE_IP_LOOKBACK` | `720h` / 30 Tage | Rückblick für bekannte Quell-IPs |
| `NEW_SOURCE_IP_WINDOW` | `10m` | aktuelles Fenster für neue Quell-IP |
| `BASELINE_ENABLED` | `true` | aktiviert Baseline-Regeln |
| `BASELINE_WINDOW` | `5m` | Baseline-Bucket-Zeitfenster |
| `BASELINE_MIN_SAMPLES` | `24` | Mindestanzahl Baseline-Samples |
| `BASELINE_MIN_COUNT` | `10` | Mindestanzahl Events für Baseline-Alert |
| `BASELINE_MEDIUM_Z` | `2.5` | Z-Score ab Medium |
| `BASELINE_HIGH_Z` | `4.0` | Z-Score ab High |
| `BASELINE_SUPPRESS_FOR` | `1h` | automatische Unterdrückung gleicher Baseline-Findings |
| `UEBA_ENABLED` | `true` | aktiviert UEBA-Regeln |
| `UEBA_LOOKBACK` | `720h` / 30 Tage | UEBA-Rückblick |
| `UEBA_NEW_CONTEXT_WINDOW` | `10m` | Fenster für neue Kontexte |
| `RISK_SCORE_WINDOW` | `24h` | Zeitraum für Host Risk Score |
| `TZ` | `Europe/Berlin` | Anzeige-/Bewertungszeitzone |
---
## 4. Severity-Logik
### 4.1 `severityFromScore`
Mehrere Regeln nutzen diese Score-zu-Severity-Logik:
```go
func severityFromScore(score, low, medium, high, critical float64) string
```
Beispielaufruf:
```go
severityFromScore(score, 1.0, 2.0, 4.0, 8.0)
```
Bedeutung:
| Score | Severity |
|---:|---|
| `>= 8.0` | `critical` |
| `>= 4.0` | `high` |
| `>= 2.0` | `medium` |
| `>= 1.0` | `low` |
| `< 1.0` | `info` |
### 4.2 Host Risk Severity
Der Host Risk Score nutzt eine separate Einteilung:
| Risk Score | Severity |
|---:|---|
| `>= 120` | `critical` |
| `>= 60` | `high` |
| `>= 20` | `medium` |
| `>= 5` | `low` |
| `< 5` | `info` |
---
# 5. Regel: `agent_offline`
## Zweck
Erkennt Agents, die länger als `OFFLINE_AFTER` nicht mehr gesehen wurden, aber noch nicht älter als `OFFLINE_ALERT_MAX` offline sind.
## Datenbasis
Tabelle: `agents`
Relevante Felder:
- `hostname`
- `last_seen`
- `is_enabled`
## Logik
Ein Agent wird gemeldet, wenn:
```sql
is_enabled = 1
AND last_seen < now - OFFLINE_AFTER
AND last_seen >= now - OFFLINE_ALERT_MAX
```
## Default-Werte
| Parameter | Default |
|---|---:|
| `OFFLINE_AFTER` | `10m` |
| `OFFLINE_ALERT_MAX` | `120m` |
## Detection
| Feld | Wert |
|---|---|
| Rule | `agent_offline` |
| Severity | `low` |
| Score | abhängig von Offline-Dauer |
| Channel | leer |
| EventID | `0` |
## Beispiel-Summary
```text
Agent CLIENT01 ist seit 17 Minuten offline
```
## SOC-Bewertung
Empfohlene Bewertung:
- `legitimate`, wenn Gerät heruntergefahren, neu installiert oder absichtlich deaktiviert wurde.
- `investigating`, wenn Server oder kritischer Client unerwartet offline ist.
- `suppressed`, wenn bestimmte Systeme dauerhaft nicht überwacht werden sollen.
---
# 6. Regel: `failed_logon_spike`
## Zweck
Erkennt Hosts mit ungewöhnlich vielen fehlgeschlagenen Logons innerhalb kurzer Zeit.
## Datenbasis
Tabelle: `event_logs`
Windows Event:
| Channel | EventID |
|---|---:|
| `Security` | `4625` |
## Logik
Gruppierung nach Host:
```sql
channel_name = 'Security'
AND event_id = 4625
AND ts >= window_start
AND ts < window_end
GROUP BY hostname
HAVING COUNT(*) >= FAILED_LOGON_THRESHOLD
```
## Default-Werte
| Parameter | Default |
|---|---:|
| `FAILED_LOGON_WINDOW` | `5m` |
| `FAILED_LOGON_THRESHOLD` | `25` |
## Score
```text
score = count / FAILED_LOGON_THRESHOLD
```
Severity wird über `severityFromScore(score, 1.0, 2.0, 4.0, 8.0)` berechnet.
## Detection
| Feld | Wert |
|---|---|
| Rule | `failed_logon_spike` |
| EventID | `4625` |
| Channel | `Security` |
| Severity | score-basiert |
## Beispiel-Summary
```text
Host DC01 hatte 48 fehlgeschlagene Logons in 5 Minuten
```
## Typische Ursachen
- Brute-Force-Versuch
- falsch gespeichertes Passwort in Diensten
- altes Passwort in RDP-/VPN-/Outlook-Sessions
- Scanner oder Monitoring mit falschen Credentials
- Lockout-Situation nach Passwortwechsel
## SOC-Bewertung
- `investigating`, wenn unbekannte Quelle, viele Accounts oder externe IP beteiligt.
- `legitimate`, wenn bekannter Dienst nach Passwortwechsel betroffen ist.
- `false_positive`, wenn Event-Parsing oder Testdaten Ursache sind.
---
# 7. Regel: `reboot_spike`
## Zweck
Erkennt Hosts mit mehreren Reboot-/Shutdown-Events in kurzer Zeit.
## Datenbasis
Tabelle: `event_logs`
Windows Events:
| Channel | EventID | Bedeutung |
|---|---:|---|
| `System` | `1074` | geplanter Neustart/Shutdown |
| `System` | `6005` | Eventlog-Service gestartet |
| `System` | `6006` | Eventlog-Service beendet |
## Logik
```sql
channel_name = 'System'
AND event_id IN (1074, 6005, 6006)
AND ts >= window_start
AND ts < window_end
GROUP BY hostname
HAVING COUNT(*) >= REBOOT_THRESHOLD
```
## Default-Werte
| Parameter | Default |
|---|---:|
| `REBOOT_WINDOW` | `15m` |
| `REBOOT_THRESHOLD` | `3` |
## Score
```text
score = count / REBOOT_THRESHOLD
```
## Detection
| Feld | Wert |
|---|---|
| Rule | `reboot_spike` |
| Channel | `System` |
| Severity | score-basiert |
## Beispiel-Summary
```text
Host CLIENT01 hatte 4 Reboot-/Shutdown-Events in 15 Minuten
```
## Typische Ursachen
- Patchinstallation
- Treiberproblem
- instabiler Client
- Stromproblem
- absichtlicher Neustart durch Admin
- Malware/Manipulation eher selten, aber möglich
---
# 8. Regel: `new_event_id`
## Zweck
Erkennt, wenn ein Host erstmals eine bestimmte EventID in einem bestimmten Channel sendet.
## Datenbasis
Tabelle: `event_logs`
## Logik
Die Regel betrachtet nur das aktuelle Detection-Intervall und prüft, ob es davor für denselben Host, Channel und EventID bereits Events gab.
Vereinfacht:
```sql
WHERE e.ts >= window_start
AND e.ts < window_end
AND NOT EXISTS (
SELECT 1
FROM event_logs old
WHERE old.hostname = e.hostname
AND old.channel_name = e.channel_name
AND old.event_id = e.event_id
AND old.ts < window_start
)
GROUP BY e.hostname, e.channel_name, e.event_id
```
## Default-Werte
| Parameter | Default |
|---|---:|
| `DETECTION_INTERVAL` | `1m` |
## Score
```text
score = 1.0 + log10(count + 1)
```
## Severity
| Bedingung | Severity |
|---|---|
| `count >= 10` | `high` |
| sonst | `medium` |
## Detection
| Feld | Wert |
|---|---|
| Rule | `new_event_id` |
| Channel | aus Event |
| EventID | aus Event |
## Beispiel-Summary
```text
Host CLIENT01 sendet erstmals Event-ID 7045 im Channel System
```
## Typische Ursachen
- neue Software
- neue Windows-Funktion
- neues Audit-Policy-Setting
- Treiberinstallation
- Service-Installation
- sicherheitsrelevante Aktivität, wenn EventID auffällig ist
## SOC-Bewertung
Besonders prüfen bei:
- `System 7045` Service Installation
- `Security 1102` Auditlog gelöscht
- `Security 4720` User erstellt
- `Security 4697` Service installiert
- `Security 4698` Scheduled Task erstellt
---
# 9. Regel: `password_spray`
## Zweck
Erkennt mögliche Password-Spray-Angriffe anhand vieler fehlgeschlagener Logons gegen mehrere verschiedene Benutzer von derselben Quell-IP.
## Datenbasis
Tabelle: `event_logs`
Windows Event:
| Channel | EventID |
|---|---:|
| `Security` | `4625` |
## Logik
Gruppierung nach Host und Quell-IP:
```sql
channel_name = 'Security'
AND event_id = 4625
AND src_ip <> ''
AND src_ip <> '-'
AND src_ip <> '::1'
AND src_ip <> '127.0.0.1'
AND target_user <> ''
AND target_user <> '-'
GROUP BY hostname, src_ip
HAVING COUNT(*) >= PASSWORD_SPRAY_MIN_ATTEMPTS
AND COUNT(DISTINCT target_user) >= PASSWORD_SPRAY_MIN_USERS
```
## Default-Werte
| Parameter | Default |
|---|---:|
| `PASSWORD_SPRAY_WINDOW` | `5m` |
| `PASSWORD_SPRAY_MIN_USERS` | `5` |
| `PASSWORD_SPRAY_MIN_ATTEMPTS` | `15` |
## Score
```text
score = max(
attempts / PASSWORD_SPRAY_MIN_ATTEMPTS,
users / PASSWORD_SPRAY_MIN_USERS
)
```
Severity wird über `severityFromScore(score, 1.0, 2.0, 4.0, 8.0)` berechnet.
## Detection
| Feld | Wert |
|---|---|
| Rule | `password_spray` |
| Channel | `Security` |
| EventID | `4625` |
## Beispiel-Summary
```text
Möglicher Password-Spray auf DC01 von 10.10.10.50: 30 Fehlversuche gegen 12 Benutzer
```
## Typische Ursachen
- echter Password-Spray
- Scanner mit falschem Passwort
- altes Passwort in zentralem Dienst
- falsch konfigurierte Applikation
- VPN-/RADIUS-/LDAP-Fehlversuche
## Empfohlene Prüfung
- Quell-IP identifizieren.
- Prüfen, ob Quell-IP intern, VPN, Server oder extern ist.
- Betroffene Benutzer auf Lockout oder spätere erfolgreiche Logons prüfen.
- In Kombination mit `success_after_failures` hoch priorisieren.
---
# 10. Regel: `success_after_failures`
## Zweck
Erkennt erfolgreiche Logons, denen kurz zuvor fehlgeschlagene Logons für denselben Benutzer vorausgingen.
## Datenbasis
Tabelle: `event_logs`
Windows Events:
| EventID | Bedeutung |
|---:|---|
| `4625` | fehlgeschlagener Logon |
| `4624` | erfolgreicher Logon |
## Logik
Ein erfolgreicher Logon wird verdächtig, wenn vorher im konfigurierten Fenster ein passender fehlgeschlagener Logon existiert.
Vereinfacht:
```sql
s.event_id = 4624
AND EXISTS (
SELECT 1
FROM event_logs f
WHERE f.hostname = s.hostname
AND f.event_id = 4625
AND f.target_user = s.target_user
AND f.ts >= DATE_SUB(s.ts, INTERVAL ? SECOND)
AND f.ts < s.ts
)
```
Die Quell-IP wird berücksichtigt, wenn sie vorhanden ist.
## Default-Wert
| Parameter | Default |
|---|---:|
| `SUCCESS_AFTER_FAILURE_WINDOW` | `10m` |
## Score
```text
score = 2.0 + log10(success_count + 1)
```
## Severity
Aktuell fest:
```text
high
```
## Detection
| Feld | Wert |
|---|---|
| Rule | `success_after_failures` |
| Channel | `Security` |
| EventID | `4624` |
| Severity | `high` |
## Beispiel-Summary
```text
Erfolgreicher Logon nach Fehlversuchen auf CLIENT01 für Benutzer max.mustermann
```
## Typische Ursachen
- Benutzer hat sich vertippt und danach korrekt angemeldet
- Angreifer hat Passwort erraten
- Passwort-Spray mit anschließendem Treffer
- Passwortänderung und gespeicherte Sessions
## Empfohlene Bewertung
Diese Regel sollte priorisiert werden, wenn zusätzlich eines davon zutrifft:
- neue Quell-IP
- ungewöhnlicher Host
- privilegierter Benutzer
- außerhalb Arbeitszeit
- mehrere Zielbenutzer betroffen
- externer oder unbekannter Ursprung
---
# 11. Regel: `new_source_ip_for_user`
## Zweck
Erkennt erfolgreiche Logons eines Benutzers von einer bisher unbekannten Quell-IP.
## Datenbasis
Tabelle: `event_logs`
Windows Event:
| Channel | EventID |
|---|---:|
| `Security` | `4624` |
## Logik
Die Regel betrachtet erfolgreiche Logons im aktuellen Fenster und prüft, ob dieselbe Quell-IP für denselben Benutzer auf demselben Host im Lookback-Zeitraum bereits bekannt war.
```sql
event_id = 4624
AND src_ip NOT IN ('', '-', '::1', '127.0.0.1')
AND NOT EXISTS (
SELECT 1
FROM event_logs old
WHERE old.hostname = e.hostname
AND old.event_id = 4624
AND old.target_user = e.target_user
AND old.src_ip = e.src_ip
AND old.ts >= lookback_start
AND old.ts < window_start
)
```
## Default-Werte
| Parameter | Default |
|---|---:|
| `NEW_SOURCE_IP_WINDOW` | `10m` |
| `NEW_SOURCE_IP_LOOKBACK` | `30d` |
## Score
```text
score = 1.5 + log10(count + 1)
```
## Severity
| Bedingung | Severity |
|---|---|
| `count >= 5` | `high` |
| sonst | `medium` |
## Detection
| Feld | Wert |
|---|---|
| Rule | `new_source_ip_for_user` |
| Channel | `Security` |
| EventID | `4624` |
## Beispiel-Summary
```text
Benutzer max.mustermann meldet sich auf CLIENT01 von neuer Quell-IP 10.10.50.20 an
```
## Typische Ursachen
- neuer Client
- VPN-Wechsel
- DHCP-Wechsel
- RDP von ungewohntem System
- kompromittierter Account
---
# 12. Regel: `dynamic_rules`
## Zweck
Ermöglicht frei konfigurierbare Regeln über die Weboberfläche und Tabelle `detection_rules`.
## Datenbasis
Tabelle:
```text
detection_rules
```
Ausgewertet gegen:
```text
event_logs
```
## Regeltypen
Es gibt zwei Betriebsarten:
1. Einzelereignis-Regel
2. Threshold-Regel
### 12.1 Einzelereignis-Regel
Wird verwendet, wenn:
```text
threshold_count <= 1
ODER
threshold_window_seconds <= 0
```
Sie prüft Events im aktuellen `DETECTION_INTERVAL`.
### 12.2 Threshold-Regel
Wird verwendet, wenn:
```text
threshold_count > 1
UND
threshold_window_seconds > 0
```
Sie zählt passende Events im angegebenen Zeitfenster pro Host.
## Konfigurierbare Felder
| Feld | Bedeutung |
|---|---|
| `name` | Regelname |
| `description` | Beschreibung |
| `severity` | Severity |
| `channel` | ein oder mehrere Channels, kommasepariert |
| `event_ids` | ein oder mehrere EventIDs, kommasepariert |
| `match_field` | optionales Feld für Filter |
| `match_operator` | `eq`, `contains`, `in` |
| `match_value` | Vergleichswert |
| `threshold_count` | Mindestanzahl Events |
| `threshold_window_seconds` | Zeitfenster |
| `suppress_for_seconds` | Suppression-Zeit |
| `enabled` | aktiv/inaktiv |
## Unterstützte Match-Felder
| `match_field` | DB-Spalte |
|---|---|
| `hostname` | `hostname` |
| `channel` | `channel_name` |
| `event_id` | `event_id` |
| `target_user` | `target_user` |
| `subject_user` | `subject_user` |
| `src_ip` | `src_ip` |
| `workstation` | `workstation` |
| `process_name` | `process_name` |
| `msg` | `msg` |
## Unterstützte Operatoren
| Operator | Bedeutung |
|---|---|
| `eq` | exakter Vergleich |
| `contains` | Teilstring-Suche |
| `in` | Wert ist in kommaseparierter Liste enthalten |
## Detection-Name
Dynamische Regeln werden mit Prefix gespeichert:
```text
dynamic_<Regelname>
```
Beispiel:
```text
dynamic_security_log_cleared
```
## Beispiel-Regeln
### Auditlog gelöscht
| Feld | Wert |
|---|---|
| Name | `security_log_cleared` |
| Severity | `critical` |
| Channel | `Security` |
| Event IDs | `1102` |
| Threshold Count | `1` |
| Suppress Seconds | `3600` |
### Neuer lokaler Benutzer
| Feld | Wert |
|---|---|
| Name | `local_user_created` |
| Severity | `high` |
| Channel | `Security` |
| Event IDs | `4720` |
| Threshold Count | `1` |
### Service installiert
| Feld | Wert |
|---|---|
| Name | `service_installed` |
| Severity | `high` |
| Channel | `System,Security` |
| Event IDs | `7045,4697` |
---
# 13. Regel: `baseline_event_rate_anomaly`
## Zweck
Erkennt statistische Abweichungen bei Event-Häufigkeiten je Host, Channel, EventID, Wochentag und Stunde.
## Komponenten
Die Baseline besteht aus zwei Teilen:
1. `baseline_update`
2. `baseline_anomaly`
## 13.1 `baseline_update`
Aktualisiert die Statistik in `baseline_event_stats`.
Gruppierung:
```text
hostname
channel_name
event_id
hour_of_day
day_of_week
```
Es wird ein Online-Mittelwert mit M2/Stddev gepflegt.
## 13.2 `baseline_anomaly`
Vergleicht aktuelle Counts gegen die gespeicherte Baseline.
## Datenbasis
Tabellen:
- `event_logs`
- `baseline_event_stats`
- `baseline_exclusions`
- `detections`
## Default-Werte
| Parameter | Default |
|---|---:|
| `BASELINE_WINDOW` | `5m` |
| `BASELINE_MIN_SAMPLES` | `24` |
| `BASELINE_MIN_COUNT` | `10` |
| `BASELINE_MEDIUM_Z` | `2.5` |
| `BASELINE_HIGH_Z` | `4.0` |
| `BASELINE_SUPPRESS_FOR` | `1h` |
## Berechnung
```text
z = (current_count - avg_count) / stddev_count
```
## Voraussetzungen für Alert
Ein Alert entsteht nur, wenn:
```text
sample_count >= BASELINE_MIN_SAMPLES
count >= BASELINE_MIN_COUNT
stddev_count > 0
z >= BASELINE_MEDIUM_Z
```
## Severity
| Bedingung | Severity |
|---|---|
| `z >= BASELINE_HIGH_Z` | `high` |
| `z >= BASELINE_MEDIUM_Z` | `medium` |
## Detection
| Feld | Wert |
|---|---|
| Rule | `baseline_event_rate_anomaly` |
| Score | Z-Score |
| Severity | z-score-basiert |
## Beispiel-Summary
```text
Baseline-Anomalie auf DC01: Security EventID 4625 kam 80-mal in 5 Minuten, normal 12.40 ± 5.10, z=13.25
```
## Ausschlüsse
Baseline-Lernen wird übersprungen, wenn:
- passender Eintrag in `baseline_exclusions` aktiv ist
- ein `confirmed_incident` im aktuellen Fenster existiert
## UI-Bewertung
In der Detection-UI kann über `Baseline` gesteuert werden:
| Aktion | Effekt |
|---|---|
| `nicht lernen: 24h` | temporärer Baseline-Ausschluss |
| `nicht lernen: 7 Tage` | temporärer Baseline-Ausschluss |
| `nicht lernen: 30 Tage` | temporärer Baseline-Ausschluss |
| `nicht lernen: dauerhaft` | permanenter Baseline-Ausschluss |
Bei `confirmed_incident` wird automatisch ein 7-Tage-Ausschluss erzeugt, sofern keine andere Baseline-Aktion gewählt wurde.
---
# 14. Regel: `ueba_admin_new_host`
## Zweck
Erkennt, wenn sich ein privilegierter Benutzer erstmals auf einem Host anmeldet.
## Datenbasis
Tabellen:
- `event_logs`
- `ueba_user_baseline`
- `privileged_users`
Windows Event:
| Channel | EventID |
|---|---:|
| `Security` | `4624` |
## Privilegierte Benutzer
Ein Benutzer gilt als privilegiert, wenn:
1. er in `privileged_users` aktiviert ist, oder
2. sein Name einem Admin-Muster entspricht:
```text
adm-*
*-adm
*.adm
```
Maschinenkonten werden ignoriert.
## Logik
Es werden erfolgreiche Logons im aktuellen UEBA-Fenster betrachtet. Für Benutzer/Host-Kombinationen wird geprüft, ob es im Lookback bereits einen passenden Baseline-Kontext gab.
## Default-Werte
| Parameter | Default |
|---|---:|
| `UEBA_NEW_CONTEXT_WINDOW` | `10m` |
| `UEBA_LOOKBACK` | `30d` |
## Score und Severity
| Bedingung | Score | Severity |
|---|---:|---|
| `count < 3` | `6.0` | `high` |
| `count >= 3` | `9.0` | `critical` |
## Detection
| Feld | Wert |
|---|---|
| Rule | `ueba_admin_new_host` |
| Channel | `Security` |
| EventID | `4624` |
## Beispiel-Summary
```text
UEBA: Privilegierter Benutzer adm.max meldet sich erstmals auf Host SERVER01 an
```
## Prometheus-Metriken
Bei neuer Detection wird erhöht:
```text
siem_privileged_new_host_total{user,host}
```
## SOC-Bewertung
Diese Regel ist besonders relevant, wenn:
- der Host ein Client statt Admin-Jump-Host ist
- der Login außerhalb Arbeitszeit erfolgt
- vorher Fehlversuche auftraten
- die Quell-IP neu ist
- der Benutzer Domain Admin oder Server Admin ist
---
# 15. Regel: `ueba_new_user_context`
## Zweck
Erkennt neue Login-Kontexte für normale Benutzer.
Ein Kontext besteht aus:
```text
username + hostname + src_ip + workstation
```
## Datenbasis
Tabellen:
- `event_logs`
- `ueba_user_baseline`
Windows Event:
| Channel | EventID |
|---|---:|
| `Security` | `4624` |
## Logik
Ein Alert entsteht, wenn für einen erfolgreichen Logon im aktuellen Fenster kein bekannter Baseline-Kontext im Lookback existiert.
## Default-Werte
| Parameter | Default |
|---|---:|
| `UEBA_NEW_CONTEXT_WINDOW` | `10m` |
| `UEBA_LOOKBACK` | `30d` |
## Score und Severity
| Bedingung | Score | Severity |
|---|---:|---|
| `count < 5` | `2.0` | `medium` |
| `count >= 5` | `4.0` | `high` |
## Detection
| Feld | Wert |
|---|---|
| Rule | `ueba_new_user_context` |
| Channel | `Security` |
| EventID | `4624` |
## Beispiel-Summary
```text
UEBA: Benutzer max.mustermann meldet sich in neuem Kontext an: Host=CLIENT01 IP=10.10.20.30 Workstation=CLIENT99
```
## Typische Ursachen
- neuer Arbeitsplatz
- VPN
- DHCP-Wechsel
- Remotezugriff
- Helpdesk-Anmeldung
- kompromittierter Account
---
# 16. Regel: `ueba_update`
## Zweck
Aktualisiert die UEBA-Baseline für Benutzerkontexte.
## Datenbasis
Tabelle:
```text
ueba_user_baseline
```
Quelle:
```text
event_logs
```
## Logik
Erfolgreiche Logons im aktuellen UEBA-Fenster werden in die Baseline übernommen.
Kontext:
```text
username
hostname
src_ip
workstation
```
Bei neuem Kontext:
```sql
INSERT INTO ueba_user_baseline (...)
```
Bei bekanntem Kontext:
```sql
last_seen = UTC_TIMESTAMP(6)
seen_count = seen_count + VALUES(seen_count)
```
## Wichtig
Die Reihenfolge im Detection-Loop ist relevant.
Empfohlen:
```text
ueba_admin_new_host
ueba_offhours_login
ueba_first_privileged_use
ueba_new_user_context
ueba_update
```
So werden neue Kontexte zuerst erkannt und danach gelernt.
---
# 17. Regel: `ueba_offhours_login`
## Zweck
Erkennt erfolgreiche Benutzeranmeldungen außerhalb der definierten Arbeitszeit.
## Aktuelle Arbeitszeit
```text
06:00 bis 20:00 Uhr
```
Außerhalb dieser Zeit wird geprüft.
## Datenbasis
Tabelle:
```text
event_logs
```
Windows Event:
| Channel | EventID |
|---|---:|
| `Security` | `4624` |
## Empfohlene Filter
Um Rauschen durch technische Accounts zu vermeiden, sollten technische Accounts ausgeschlossen werden.
### Empfohlene Go-Hilfsfunktion
```go
func isNoiseAccount(username string) bool {
u := normalizeUsername(username)
if u == "" || isMachineAccount(u) {
return true
}
switch u {
case "system",
"localsystem",
"local service",
"network service",
"anonymous logon",
"dwm-1",
"dwm-2",
"dwm-3",
"umfd-0",
"umfd-1",
"umfd-2",
"umfd-3":
return true
}
return false
}
```
`NT AUTHORITY\SYSTEM` wird durch `normalizeUsername()` zu `system` und damit sauber ignoriert.
## Empfohlener SQL-Filter
```sql
AND target_user <> ''
AND target_user <> '-'
AND target_user NOT LIKE '%$'
AND logon_type IN ('2', '7', '10', '11')
AND LOWER(target_user) NOT IN (
'system',
'localsystem',
'local service',
'network service',
'anonymous logon'
)
```
## Relevante LogonTypes
| LogonType | Bedeutung | Bewertung |
|---:|---|---|
| `2` | Interactive | relevant |
| `7` | Unlock | meist relevant |
| `10` | RemoteInteractive/RDP | relevant |
| `11` | CachedInteractive | relevant |
| `3` | Network | oft Rauschen |
| `5` | Service | meist Rauschen |
## Score und Severity
Empfohlene Logik:
| Bedingung | Score | Severity |
|---|---:|---|
| `count < 5` | `2.0` | `medium` |
| `count >= 5` | `4.0` | `high` |
## Detection
| Feld | Wert |
|---|---|
| Rule | `ueba_offhours_login` |
| Channel | `Security` |
| EventID | `4624` |
## Beispiel-Summary
```text
UEBA: Login außerhalb der Arbeitszeit: Benutzer max.mustermann auf Host CLIENT01
```
## Typische legitime Ursachen
- Bereitschaftsdienst
- geplante Wartung
- Remote-Arbeit
- automatisierte Admin-Tätigkeit
- Zeitzonen-/Serverzeitproblem
## Typische verdächtige Ursachen
- kompromittierte Zugangsdaten
- RDP-Zugriff nach Feierabend
- laterale Bewegung
- Admin-Account außerhalb normaler Betriebszeit
---
# 18. Regel: `ueba_first_privileged_use`
## Zweck
Erkennt, wenn ein Benutzer erstmals privilegierte Rechte verwendet.
## Datenbasis
Tabellen:
- `event_logs`
- `user_privilege_baseline`
Windows Event:
| Channel | EventID |
|---|---:|
| `Security` | `4672` |
Event `4672` steht für „Special privileges assigned to new logon“.
## Logik
Für jedes `4672`-Event im Fenster wird geprüft, ob der Benutzer bereits in `user_privilege_baseline` existiert.
Wenn nicht:
1. Detection erzeugen
2. Benutzer in Baseline übernehmen
## Empfohlene Tabelle
```sql
CREATE TABLE IF NOT EXISTS user_privilege_baseline (
username VARCHAR(255) NOT NULL PRIMARY KEY,
first_seen DATETIME(6) NOT NULL DEFAULT UTC_TIMESTAMP(6),
last_seen DATETIME(6) NOT NULL DEFAULT UTC_TIMESTAMP(6),
seen_count BIGINT NOT NULL DEFAULT 1
);
```
## Detection
| Feld | Wert |
|---|---|
| Rule | `ueba_first_privileged_use` |
| Channel | `Security` |
| EventID | `4672` |
| Severity | `high` |
| Score | `6.0` |
## Beispiel-Summary
```text
UEBA: Benutzer adm.max nutzt erstmals privilegierte Rechte auf Host SERVER01
```
## Wichtiger Hinweis
Diese Regel ist nur sinnvoll, wenn die Baseline gepflegt wird. Sonst wird derselbe Benutzer immer wieder als „erstmals privilegiert“ erkannt.
---
# 19. Regel: `host_risk_score`
## Zweck
Aggregiert offene Detections pro Host zu einem Host-Risiko-Score.
## Datenbasis
Tabelle:
```text
detections
```
Ausgabe:
```text
host_risk_scores
```
## Zeitfenster
| Parameter | Default |
|---|---:|
| `RISK_SCORE_WINDOW` | `24h` |
## Ignorierte Detection-Status
Diese Status werden nicht in den Risk Score einbezogen:
```text
false_positive
suppressed
legitimate
resolved
plausible
```
## Severity-Gewichte
| Severity | Gewicht |
|---|---:|
| `critical` | `25` |
| `high` | `10` |
| `medium` | `2` |
| `low` | `0.3` |
| `info` | `0.05` |
| sonst | `0.2` |
## Status-Modifikatoren
| Status | Wirkung |
|---|---|
| `confirmed_incident` | `+75` zusätzlich pro Gruppe |
| `investigating` | Gewicht `* 2` |
| `acknowledged` | Gewicht `* 0.5` |
| `open` | Gewicht `* 0.35` |
## Dämpfung
Gleiche Events zählen nicht linear, sondern gedämpft:
```text
score += weight * sqrt(count)
```
Dadurch erzeugen 100 gleiche offene Events nicht 100-faches Risiko.
## Severity aus Risk Score
| Risk Score | Severity |
|---:|---|
| `>= 120` | `critical` |
| `>= 60` | `high` |
| `>= 20` | `medium` |
| `>= 5` | `low` |
| `< 5` | `info` |
## Ausgabe-Felder
| Feld | Bedeutung |
|---|---|
| `hostname` | Host |
| `risk_score` | berechneter Score |
| `severity` | abgeleitete Severity |
| `open_detections` | offene relevante Detections |
| `high_detections` | Anzahl High |
| `critical_detections` | Anzahl Critical |
| `confirmed_incidents` | bestätigte Incidents |
| `last_detection_at` | letzter relevanter Detection-Zeitpunkt |
---
# 20. Suppression-Mechanismen
## 20.1 Detection-Suppression
Tabelle:
```text
detection_suppressions
```
Die Funktion:
```go
isDetectionSuppressed(ctx, det)
```
prüft vor dem Insert, ob eine passende aktive Suppression existiert.
Match-Kriterien:
```text
rule_name
hostname oder leer
channel_name oder leer
event_id oder 0
expires_at IS NULL oder expires_at > now
enabled = 1
```
Wenn Suppression aktiv ist, wird keine Detection erzeugt.
## 20.2 Dynamic Rule Suppression
Dynamische Regeln prüfen zusätzlich `suppress_for_seconds`.
Dadurch wird verhindert, dass dieselbe dynamische Regel pro Host zu oft auslöst.
## 20.3 Baseline-Suppression
Baseline-Anomalien werden über `BASELINE_SUPPRESS_FOR` zeitlich gedämpft.
## 20.4 Baseline-Exclusion
Tabelle:
```text
baseline_exclusions
```
Diese Tabelle verhindert, dass bestimmte Events in die Baseline eingelernt werden.
Nützlich bei:
- bestätigten Incidents
- Wartungsfenstern
- bekannten Ausnahmesituationen
- Testläufen
- Rollouts
---
# 21. Detection-Status
Unterstützte Status:
| Status | Bedeutung |
|---|---|
| `open` | neu/offen |
| `acknowledged` | gesehen, noch nicht untersucht |
| `investigating` | in Untersuchung |
| `plausible` | plausibel, aber nicht unbedingt dauerhaft legitim |
| `legitimate` | legitim/erwartet |
| `false_positive` | Fehlalarm |
| `resolved` | erledigt |
| `suppressed` | bewusst unterdrückt |
| `confirmed_incident` | bestätigter Sicherheitsvorfall |
## Auswirkungen
| Status | Wirkung |
|---|---|
| `false_positive` | `is_false_positive = true`, aus Risk Score ausgeschlossen |
| `legitimate` | `is_legitimate = true`, aus Risk Score ausgeschlossen |
| `plausible` | aus Risk Score ausgeschlossen |
| `resolved` | aus Risk Score ausgeschlossen |
| `suppressed` | aus Risk Score ausgeschlossen |
| `confirmed_incident` | stark erhöhter Risk Score, Baseline-Lernen wird temporär verhindert |
---
# 22. Privileged Users
## Zweck
Die Tabelle `privileged_users` erweitert die automatische Erkennung privilegierter Benutzer.
## UI
Pfad:
```text
/ui/privileged-users
```
Funktionen:
- Benutzer hinzufügen
- Grund dokumentieren
- aktivieren/deaktivieren
## Automatische Erkennung
Auch ohne Tabelle gelten Benutzer als privilegiert, wenn sie folgendem Namensschema entsprechen:
```text
adm-*
*-adm
*.adm
```
## Maschinenkonten
Maschinenkonten werden ignoriert:
```text
*$
```
---
# 23. Empfohlene Dynamic Rules für Windows Security Monitoring
Diese Regeln lassen sich über `/ui/rules` pflegen.
## 23.1 Security Audit Log gelöscht
| Feld | Wert |
|---|---|
| Name | `security_log_cleared` |
| Severity | `critical` |
| Channel | `Security` |
| Event IDs | `1102` |
| Threshold | `1` |
| Suppress | `3600` |
## 23.2 Benutzer erstellt
| Feld | Wert |
|---|---|
| Name | `user_created` |
| Severity | `high` |
| Channel | `Security` |
| Event IDs | `4720` |
## 23.3 Benutzer aktiviert
| Feld | Wert |
|---|---|
| Name | `user_enabled` |
| Severity | `medium` |
| Channel | `Security` |
| Event IDs | `4722` |
## 23.4 Benutzer deaktiviert
| Feld | Wert |
|---|---|
| Name | `user_disabled` |
| Severity | `medium` |
| Channel | `Security` |
| Event IDs | `4725` |
## 23.5 Benutzer gelöscht
| Feld | Wert |
|---|---|
| Name | `user_deleted` |
| Severity | `high` |
| Channel | `Security` |
| Event IDs | `4726` |
## 23.6 Sicherheitsgruppe erstellt
| Feld | Wert |
|---|---|
| Name | `security_group_created` |
| Severity | `medium` |
| Channel | `Security` |
| Event IDs | `4727,4731` |
## 23.7 Mitglied zu Sicherheitsgruppe hinzugefügt
| Feld | Wert |
|---|---|
| Name | `security_group_member_added` |
| Severity | `high` |
| Channel | `Security` |
| Event IDs | `4728,4732,4756` |
## 23.8 Mitglied aus Sicherheitsgruppe entfernt
| Feld | Wert |
|---|---|
| Name | `security_group_member_removed` |
| Severity | `medium` |
| Channel | `Security` |
| Event IDs | `4729,4733,4757` |
## 23.9 Konto gesperrt
| Feld | Wert |
|---|---|
| Name | `account_locked` |
| Severity | `medium` |
| Channel | `Security` |
| Event IDs | `4740` |
## 23.10 Kerberos Pre-Auth fehlgeschlagen
| Feld | Wert |
|---|---|
| Name | `kerberos_preauth_failed` |
| Severity | `low` |
| Channel | `Security` |
| Event IDs | `4771` |
| Threshold Count | `10` |
| Threshold Window Seconds | `300` |
## 23.11 Service installiert
| Feld | Wert |
|---|---|
| Name | `service_installed` |
| Severity | `high` |
| Channel | `System,Security` |
| Event IDs | `7045,4697` |
## 23.12 Scheduled Task erstellt
| Feld | Wert |
|---|---|
| Name | `scheduled_task_created` |
| Severity | `medium` |
| Channel | `Security` |
| Event IDs | `4698` |
## 23.13 Audit Policy geändert
| Feld | Wert |
|---|---|
| Name | `audit_policy_changed` |
| Severity | `high` |
| Channel | `Security` |
| Event IDs | `4719` |
---
# 24. Empfohlene Indizes
Für Performance sollten mindestens diese Indizes vorhanden sein.
```sql
CREATE INDEX idx_event_logs_ts ON event_logs (ts);
CREATE INDEX idx_event_logs_host_ts ON event_logs (hostname, ts);
CREATE INDEX idx_event_logs_channel_event_ts ON event_logs (channel_name, event_id, ts);
CREATE INDEX idx_event_logs_security_logon ON event_logs (channel_name, event_id, target_user, src_ip, ts);
CREATE INDEX idx_event_logs_host_channel_event_ts ON event_logs (hostname, channel_name, event_id, ts);
CREATE INDEX idx_detections_created ON detections (created_at);
CREATE INDEX idx_detections_rule_host_created ON detections (rule_name, hostname, created_at);
CREATE INDEX idx_detections_status_created ON detections (status, created_at);
CREATE INDEX idx_detections_host_status_created ON detections (hostname, status, created_at);
CREATE INDEX idx_agents_enabled_lastseen ON agents (is_enabled, last_seen);
CREATE INDEX idx_ueba_user_baseline_lookup
ON ueba_user_baseline (username, hostname, src_ip, workstation, first_seen, last_seen);
CREATE INDEX idx_baseline_event_stats_lookup
ON baseline_event_stats (hostname, channel_name, event_id, hour_of_day, day_of_week);
CREATE INDEX idx_detection_suppressions_lookup
ON detection_suppressions (enabled, rule_name, hostname, channel_name, event_id, expires_at);
CREATE INDEX idx_baseline_exclusions_lookup
ON baseline_exclusions (enabled, hostname, channel_name, event_id, expires_at);
```
---
# 25. Empfohlene SOC-Priorisierung
## Sofort prüfen
- `confirmed_incident`
- `critical`
- `success_after_failures`
- `password_spray`
- `security_log_cleared`
- `ueba_admin_new_host`
- `ueba_first_privileged_use`
## Hoch priorisieren
- `new_source_ip_for_user` bei privilegierten Benutzern
- `ueba_offhours_login` bei Admin-Konten
- `baseline_event_rate_anomaly` mit hohem Z-Score
- `service_installed` auf Clients oder Domain Controllern
- `scheduled_task_created` außerhalb Wartungsfenster
## Eher Rauschen / Kontextabhängig
- `agent_offline` bei normalen Clients
- `reboot_spike` während Patchfenster
- `new_event_id` direkt nach Audit-Policy-Änderungen
- `ueba_new_user_context` bei VPN-/DHCP-Änderungen
- `ueba_offhours_login` ohne LogonType-Filter
---
# 26. Bekannte Rauschquellen
## SYSTEM / technische Accounts
Besonders bei `4624` können technische Accounts sehr viele Events erzeugen.
Empfohlene Ausschlüsse:
```text
SYSTEM
NT AUTHORITY\SYSTEM
LOCAL SERVICE
NETWORK SERVICE
ANONYMOUS LOGON
DWM-*
UMFD-*
Maschinenkonten mit $
```
## LogonType
Für echte Benutzeranmeldungen sind meist relevant:
```text
2, 7, 10, 11
```
Oft rauschanfällig:
```text
3, 5
```
## Patchfenster
Während Patchfenstern können diese Regeln anschlagen:
- `reboot_spike`
- `new_event_id`
- `baseline_event_rate_anomaly`
- `agent_offline`
Empfehlung:
- Batch-Bewertung auf `plausible`
- temporäre Baseline-Exclusion
- temporäre Suppression für bekannte Regeln
---
# 27. Empfohlene Weiterentwicklung
## 27.1 Regelkonfiguration für Off-Hours
Aktuell ist die Arbeitszeit hart im Code:
```text
06:00 bis 20:00
```
Empfohlen wäre eine Konfiguration über ENV:
```text
OFFHOURS_ENABLED=true
WORK_HOUR_START=6
WORK_HOUR_END=20
OFFHOURS_LOGON_TYPES=2,7,10,11
```
## 27.2 Noise-Accounts in Tabelle auslagern
Statt hartem Code könnte eine Tabelle genutzt werden:
```sql
CREATE TABLE ignored_accounts (
username VARCHAR(255) NOT NULL PRIMARY KEY,
reason VARCHAR(255) NULL,
enabled BOOLEAN NOT NULL DEFAULT TRUE,
created_at DATETIME(6) NOT NULL DEFAULT UTC_TIMESTAMP(6),
updated_at DATETIME(6) NOT NULL DEFAULT UTC_TIMESTAMP(6) ON UPDATE UTC_TIMESTAMP(6)
);
```
## 27.3 Dynamic Rules um Negativfilter erweitern
Nützlich wären:
- `exclude_field`
- `exclude_operator`
- `exclude_value`
Beispiel:
```text
target_user NOT IN system,local service,network service
```
## 27.4 MITRE ATT&CK Mapping
Jede Detection könnte um MITRE-Technik erweitert werden:
| Regel | Mögliche Technik |
|---|---|
| `password_spray` | T1110.003 Password Spraying |
| `success_after_failures` | T1110 Brute Force |
| `service_installed` | T1543.003 Windows Service |
| `scheduled_task_created` | T1053.005 Scheduled Task |
| `security_log_cleared` | T1070.001 Clear Windows Event Logs |
| `ueba_admin_new_host` | T1078 Valid Accounts |
---
# 28. Kurze Betriebscheckliste
## Täglich
- SOC Dashboard prüfen
- Top Host Risk Scores prüfen
- offene `critical` und `high` Detections bewerten
- False Positives markieren
- legitime Wartungsereignisse als `plausible` oder `legitimate` markieren
## Wöchentlich
- häufige False Positives auswerten
- Suppressions prüfen
- Baseline-Exclusions prüfen
- Dynamic Rules nachschärfen
- neue EventIDs bewerten
## Monatlich
- Privileged Users prüfen
- UEBA-Baseline-Qualität prüfen
- Indizes und Query-Laufzeiten prüfen
- Prometheus/Grafana-Dashboards kontrollieren
- Retention-Konzept prüfen
---
# 29. Glossar
| Begriff | Bedeutung |
|---|---|
| Detection | Ein ausgelöster Regel-Treffer |
| Suppression | Unterdrückung bekannter oder akzeptierter Detections |
| Baseline | gelernter Normalzustand |
| UEBA | User and Entity Behavior Analytics |
| Z-Score | statistischer Abstand zum Mittelwert |
| Host Risk Score | aggregierter Risikowert pro Host |
| LogonType | Windows-Klassifikation der Anmeldung |
| `4624` | erfolgreicher Logon |
| `4625` | fehlgeschlagener Logon |
| `4672` | Special Privileges Assigned |
| `1102` | Security Audit Log gelöscht |
| `7045` | Service installiert |
---
# 30. Kurzfazit
Das Regelwerk kombiniert klassische EventID-Regeln, dynamische Regeln, Baseline-Anomalien und UEBA-Kontextregeln.
Die wichtigsten Qualitätshebel sind:
1. technische Accounts konsequent ausschließen,
2. LogonTypes sauber filtern,
3. Baselines nicht mit Incidents trainieren,
4. Status sauber pflegen,
5. legitime Wartungsfenster als `plausible` oder `legitimate` markieren,
6. echte Incidents als `confirmed_incident` markieren,
7. Dynamic Rules regelmäßig nachschärfen.
Besonders wichtig für die aktuelle `runOffHoursLoginRule`:
```text
SYSTEM, LOCAL SERVICE, NETWORK SERVICE, ANONYMOUS LOGON und Maschinenkonten sollten ignoriert werden.
Zusätzlich sollte die Regel auf LogonType 2, 7, 10 und 11 begrenzt werden.
```
Reference in New Issue View Git Blame Copy Permalink