diff --git a/README.md b/README.md
index e8667c4..86bad64 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,4548 @@
-# siem-backend
+# 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.
+```