From 35cbd03916b6babe964b104645589431bc0433e1 Mon Sep 17 00:00:00 2001
From: Jan <git@send.nrw>
Date: Mon, 27 Apr 2026 05:30:48 +0000
Subject: [PATCH] =?UTF-8?q?Home=20hinzugef=C3=BCgt?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Home.md | 2582 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2582 insertions(+)
 create mode 100644 Home.md

diff --git a/Home.md b/Home.md
new file mode 100644
index 0000000..4578cf7
--- /dev/null
+++ b/Home.md
@@ -0,0 +1,2582 @@
+# 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.
+```