sendnrw/siem-backend

Fork 0

Go to file

jbergner 54aad0bdf6

release-tag / release-image (push) Successful in 2m11s

Details

Anpassungen Produktiv

2026-04-27 09:11:22 +02:00

.gitea/workflows

init

2026-04-23 21:56:44 +02:00

deploy

Neues Dashboard und Lösung für starkes Noise bei UEBA Off-Hours

2026-04-27 07:14:24 +02:00

.env

Anpassungen Produktiv

2026-04-27 09:11:22 +02:00

compose.yml

Anpassungen Produktiv

2026-04-27 09:11:22 +02:00

Dockerfile

fix

2026-04-23 21:59:24 +02:00

dot_env

Anpassung von Prometheus, Grafana und Backend auf Anomalieerkennung.

2026-04-24 21:38:25 +02:00

go.mod

init

2026-04-23 21:56:44 +02:00

go.sum

init

2026-04-23 21:56:44 +02:00

main.go

Neues Dashboard und Lösung für starkes Noise bei UEBA Off-Hours

2026-04-27 07:14:24 +02:00

README.md

Dokumentationen ergänzt

2026-04-27 07:31:55 +02:00

schema.sql

init

2026-04-23 21:56:44 +02:00

README.md

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:

Feste Regeln
- z. B. viele fehlgeschlagene Logons, Reboot-Spikes, Password-Spray.
Dynamische Regeln
- Regeln, die ein Admin in der Weboberfläche selbst anlegt.
Baseline-Regeln
- statistische Erkennung von ungewöhnlich vielen Events im Vergleich zum gelernten Normalzustand.
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:

Host
Channel
EventID
Wochentag
Stunde

Beispiel:

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:

baseline_update

Sie betrachtet das aktuelle Zeitfenster, z. B. 5 Minuten, zählt Events und aktualisiert die Statistik.

Default:

BASELINE_WINDOW=5m

6.5 Wann erzeugt die Baseline einen Alarm?

Die Detection-Regel heißt:

baseline_event_rate_anomaly

Sie erzeugt einen Alarm, wenn die aktuelle Event-Anzahl deutlich vom gelernten Normalwert abweicht.

Vereinfacht:

aktueller Wert deutlich größer als gelernter Durchschnitt

Technisch wird ein Z-Score berechnet:

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:

Benutzer
Host
Quell-IP
Workstation

Beispiel:

max.mustermann
CLIENT042
10.2.40.15
CLIENT042

7.2 Welche Events nutzt UEBA?

UEBA nutzt erfolgreiche Logons:

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:

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:

ueba_update

übernimmt erfolgreiche Logons in die UEBA-Baseline.

Wenn ein Kontext neu ist:

first_seen = jetzt
last_seen = jetzt
seen_count = Anzahl

Wenn ein Kontext bekannt ist:

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:

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:

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:

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:

Security EventID 4672

Event 4672 bedeutet, dass einem neuen Logon besondere Rechte zugewiesen wurden.

Diese Regel braucht eine eigene Baseline:

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:

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:

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:

die SOC-Arbeitsliste,
den Host Risk Score,
die Qualität der Baseline,
die zukünftige Alarmflut,
die Nachvollziehbarkeit für andere Admins,
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:

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:

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

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:

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:

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:

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:

false_positive
suppressed
legitimate
resolved
plausible

Diese Status bleiben relevant:

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:

baseline_exclusions
confirmed_incident
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:

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:

keine Änderung
nicht lernen: 24h
nicht lernen: 7 Tage
nicht lernen: 30 Tage
nicht lernen: dauerhaft

Diese Aktionen erzeugen Einträge in:

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

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

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:

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:

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:

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:

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:

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:

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:

1. Ist das Ereignis technisch korrekt erkannt?

Wenn nein:

false_positive
Regel/Parser korrigieren

Wenn ja:

2. Ist das Verhalten erwartet?

Wenn nein oder unklar:

investigating

Wenn ja:

3. Ist es einmalig/temporär oder dauerhaft normal?

Temporär:

plausible
Notiz setzen
ggf. Baseline nicht lernen 24h/7d

Dauerhaft normal:

legitimate
ggf. Suppression oder Regelanpassung

Wenn bestätigt bösartig:

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:

reboot_spike auf vielen Clients

Analyse:

Zeitpunkt passt zum Patchfenster.
Viele Clients betroffen.
Keine weiteren verdächtigen Events.
Reboots sind erwartet.

Bewertung:

Status: plausible
Notiz: Patchday April 2026, WSUS-Rollout
Baseline: nicht lernen: 24h
Suppression: optional 24h

Nicht verwenden:

false_positive

Warum?

Die Detection war fachlich korrekt. Es war kein Fehlalarm, sondern erwartetes Verhalten.

Detection:

ueba_offhours_login: Benutzer SYSTEM auf SERVER01

Analyse:

SYSTEM ist technischer Account.
Solche Logons sind normal.
Die Regel ist zu breit.

Bewertung:

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:

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

Status: plausible
Notiz: Remotehilfe Ticket #12345 durch adm.max
Baseline: keine Änderung oder nicht lernen 24h

Admin nutzt Client regelmäßig als Admin-Station

Status: legitimate
Notiz: CLIENT099 ist Admin-Workstation von adm.max
Baseline: lernen erlauben

Nicht erklärbar

Status: investigating
Notiz: Admin-Login auf ungewohntem Client, Rückfrage offen

Kompromittierung bestätigt

Status: confirmed_incident
Notiz: adm.max kompromittiert, unautorisierter Login
Baseline: nicht lernen 7d/30d

17.4 Beispiel: Password-Spray

Detection:

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:

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:

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:

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:

Status: investigating
Baseline: nicht lernen 24h

Bei bestätigtem Angriff:

Status: confirmed_incident
Baseline: nicht lernen 7d/30d

Bei bekannter Fehlkonfiguration:

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:

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:

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:

Der Angriff ist ja vorbei, also plausible.

Richtig:

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:

SYSTEM-Noise ist normal, also legitimate.

Besser:

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

Patchday April 2026, WSUS-Rollout auf Clients, Reboots erwartet.

Remotehilfe Ticket #4711, adm.max hat sich auf CLIENT099 angemeldet.

Dienstkonto svc-backup nach Passwortwechsel mit altem Credential, Ticket #4812 zur Korrektur.

Bestätigter Password-Spray von 10.2.50.77, Firewall-Block gesetzt, betroffene Benutzer geprüft.

19.2 Schlechte Beispiele

ok

normal

passt

weg

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

open
acknowledged
investigating
confirmed_incident

20.2 Diese Status zählen nicht weiter

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:

Baseline-Einträge gezielt löschen.
Baseline für bestimmte Kombinationen neu aufbauen.
Baseline-Exclusions setzen.
Regeln schärfen.
technische Accounts ausschließen.
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

Nicht wegklicken. Erst verstehen.

Jede Detection sollte mindestens kurz fachlich eingeordnet werden.

23.2 Goldene Regel 2

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

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

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

Baseline nicht mit Störungen trainieren.

Bei Wartung, Angriffen, Fehlkonfigurationen und Testfluten:

nicht lernen

verwenden.

23.6 Goldene Regel 6

Suppression nur bewusst und möglichst zeitlich begrenzt.

Dauerhafte Suppression nur nach Prüfung.

23.7 Goldene Regel 7

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

SOC Dashboard öffnen.
Top Host Risk Scores prüfen.
Critical/High Detections prüfen.
Neue confirmed_incident prüfen.
Offene investigating weiterverfolgen.
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:

plausible

Notiz:

Wartungsfenster Ticket #12345, Update Exchange Server SE, Reboots erwartet.

Baseline:

nicht lernen: 24h oder 7 Tage

Suppression:

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

Detection als false_positive markieren.
Notiz setzen.
Ursache beschreiben.
Regel anpassen.
Prüfen, ob neue Detections sauberer werden.

32.2 Beispiele

SYSTEM wurde nicht ausgeschlossen.

LogonType 3 erzeugt zu viel Rauschen.

Service Account wird als Benutzer behandelt.

EventID in falschem Channel ausgewertet.

Parser liest TargetUserName falsch.

33. Umgang mit Confirmed Incidents

33.1 Vorgehen

Wenn eine Detection ein echter Vorfall ist:

Status auf confirmed_incident.
Notiz mit Fakten schreiben.
Baseline nicht lernen lassen.
Kein Suppression setzen, solange Angriff aktiv sein könnte.
Betroffene Systeme prüfen.
Benutzer/Account prüfen.
Quell-IP prüfen.
Weitere Detections im gleichen Zeitraum prüfen.
Nach Abschluss Maßnahmen dokumentieren.

33.2 Notizbeispiel

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:

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:

confirmed_incident
Baseline: nicht lernen

35. Beispiel: vollständiger Bewertungsablauf

Detection:

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

Status: plausible
Notiz: Benutzer bestätigt mehrere Fehlversuche nach Passwortwechsel, danach erfolgreicher Login.
Baseline: keine Änderung

Quelle unbekannt, Benutzer bestätigt es nicht

Status: investigating
Notiz: Benutzer bestätigt Login nicht, Quell-IP 10.2.50.77 wird geprüft.
Baseline: nicht lernen 24h

Kompromittierung bestätigt

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:

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

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

Verwenden, wenn das Verhalten dauerhaft bekannt, erwartet und akzeptiert ist. Vorsichtig verwenden, da es aus der Risikobewertung fällt.

37.3 False Positive

Verwenden, wenn die Regel falsch oder technisch irreführend ausgelöst hat. Danach sollte die Regel verbessert werden.

37.4 Confirmed Incident

Verwenden, wenn ein echter Sicherheitsvorfall bestätigt wurde. Verhindert, dass entsprechendes Verhalten als normal eingelernt wird.

37.5 Suppressed

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

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

UEBA_ENABLED=true
UEBA_LOOKBACK=720h
UEBA_NEW_CONTEXT_WINDOW=10m

38.3 Detection

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:

für Host + Channel + EventID

Beispiel:

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:

Welche Regel hat ausgelöst?
Welche Daten liegen zugrunde?
Ist das Ereignis technisch korrekt?
Ist es erwartbar?
Ist es einmalig oder dauerhaft?
Soll die Baseline lernen?
Ist Suppression sinnvoll?
Welche Notiz wird geschrieben?
Welcher Status ist korrekt?

Ziel

Der Admin soll nicht nur klicken, sondern begründen.

43. Kurze Checkliste pro Detection

Vor Bewertung prüfen:

[ ] 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:

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:

Die Anlernphase ist kritisch.
Nicht alles am Anfang ist automatisch normal.
Baseline lernt Eventmengen nach Host, Channel, EventID, Wochentag und Stunde.
UEBA lernt Benutzerkontexte.
Dynamic Rules lernen nicht selbst, sondern müssen gepflegt werden.
plausible ist für temporär erklärbare Ereignisse.
legitimate ist für dauerhaft akzeptiertes Verhalten.
false_positive ist für falsche Regeln/Erkennungen.
confirmed_incident ist für echte Vorfälle.
Baseline darf Incidents nicht lernen.
Suppression erzeugt blinde Flecken und muss bewusst eingesetzt werden.
Gute Notizen sind Pflicht.
Host Risk Score hängt stark von korrekter Bewertung ab.
Technische Accounts und LogonTypes müssen sauber gefiltert werden.
Regelmäßige Pflege verbessert die Erkennungsqualität.

Der wichtigste Satz für Admins:

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:

func (s *server) runDetectionsOnce()

Aktuell vorgesehene Regeln:

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:

func severityFromScore(score, low, medium, high, critical float64) string

Beispielaufruf:

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:

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

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:

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

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

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

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

score = count / REBOOT_THRESHOLD

Detection

Feld	Wert
Rule	`reboot_spike`
Channel	`System`
Severity	score-basiert

Beispiel-Summary

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:

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

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

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:

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

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

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:

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

score = 2.0 + log10(success_count + 1)

Severity

Aktuell fest:

high

Detection

Feld	Wert
Rule	`success_after_failures`
Channel	`Security`
EventID	`4624`
Severity	`high`

Beispiel-Summary

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.

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

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

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:

detection_rules

Ausgewertet gegen:

event_logs

Regeltypen

Es gibt zwei Betriebsarten:

Einzelereignis-Regel
Threshold-Regel

12.1 Einzelereignis-Regel

Wird verwendet, wenn:

threshold_count <= 1
ODER
threshold_window_seconds <= 0

Sie prüft Events im aktuellen DETECTION_INTERVAL.

12.2 Threshold-Regel

Wird verwendet, wenn:

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:

dynamic_<Regelname>

Beispiel:

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:

baseline_update
baseline_anomaly

13.1 `baseline_update`

Aktualisiert die Statistik in baseline_event_stats.

Gruppierung:

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

z = (current_count - avg_count) / stddev_count

Voraussetzungen für Alert

Ein Alert entsteht nur, wenn:

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

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:

er in privileged_users aktiviert ist, oder
sein Name einem Admin-Muster entspricht:

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

UEBA: Privilegierter Benutzer adm.max meldet sich erstmals auf Host SERVER01 an

Prometheus-Metriken

Bei neuer Detection wird erhöht:

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:

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

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:

ueba_user_baseline

Quelle:

event_logs

Logik

Erfolgreiche Logons im aktuellen UEBA-Fenster werden in die Baseline übernommen.

Kontext:

username
hostname
src_ip
workstation

Bei neuem Kontext:

INSERT INTO ueba_user_baseline (...)

Bei bekanntem Kontext:

last_seen = UTC_TIMESTAMP(6)
seen_count = seen_count + VALUES(seen_count)

Wichtig

Die Reihenfolge im Detection-Loop ist relevant.

17. Regel: `ueba_offhours_login`

Zweck

Erkennt erfolgreiche Benutzeranmeldungen außerhalb der definierten Arbeitszeit.

Aktuelle Arbeitszeit

06:00 bis 20:00 Uhr

Außerhalb dieser Zeit wird geprüft.

Datenbasis

Tabelle:

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

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

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

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:

Detection erzeugen
Benutzer in Baseline übernehmen

Empfohlene Tabelle

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

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:

detections

Ausgabe:

host_risk_scores

Zeitfenster

Parameter	Default
`RISK_SCORE_WINDOW`	`24h`

Ignorierte Detection-Status

Diese Status werden nicht in den Risk Score einbezogen:

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:

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:

detection_suppressions

Die Funktion:

isDetectionSuppressed(ctx, det)

prüft vor dem Insert, ob eine passende aktive Suppression existiert.

Match-Kriterien:

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:

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:

/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:

adm-*
*-adm
*.adm

Maschinenkonten

Maschinenkonten werden ignoriert:

*$

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.

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:

SYSTEM
NT AUTHORITY\SYSTEM
LOCAL SERVICE
NETWORK SERVICE
ANONYMOUS LOGON
DWM-*
UMFD-*
Maschinenkonten mit $

LogonType

Für echte Benutzeranmeldungen sind meist relevant:

2, 7, 10, 11

Oft rauschanfällig:

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:

06:00 bis 20:00

Empfohlen wäre eine Konfiguration über ENV:

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:

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:

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:

technische Accounts konsequent ausschließen,
LogonTypes sauber filtern,
Baselines nicht mit Incidents trainieren,
Status sauber pflegen,
legitime Wartungsfenster als plausible oder legitimate markieren,
echte Incidents als confirmed_incident markieren,
Dynamic Rules regelmäßig nachschärfen.

Besonders wichtig für die aktuelle runOffHoursLoginRule:

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.

README.md

SIEM-lite Admin-Handbuch: Anlernphase, manuelle Bewertung und Lerneffekt

1. Ziel dieses Dokuments

2. Grundprinzip der Software

3. Was bedeutet „Anlernphase“?

4. Warum ist die Anlernphase kritisch?

5. Welche Lernmechanismen gibt es?

6. Lernmechanismus 1: Event-Rate-Baseline

6.1 Zweck

6.2 Warum nach Wochentag und Stunde?

6.3 Was wird gespeichert?

6.4 Wann lernt die Baseline?

6.5 Wann erzeugt die Baseline einen Alarm?

6.6 Mindestvoraussetzungen für Baseline-Alarme

6.7 Typisches Verhalten während der Anlernphase

6.8 Wie lange sollte die Baseline lernen?

7. Lernmechanismus 2: UEBA-Baseline

7.1 Zweck

7.2 Welche Events nutzt UEBA?

7.3 Welche Tabelle wird genutzt?

7.4 Wie funktioniert UEBA-Lernen?

7.5 Warum ist die Reihenfolge wichtig?

7.6 Was erkennt ueba_new_user_context?

7.7 Was erkennt ueba_admin_new_host?

7.8 Was erkennt ueba_offhours_login?

7.9 Was erkennt ueba_first_privileged_use?

8. Lernmechanismus 3: Dynamic Rules

8.1 Lernen Dynamic Rules?

8.2 Wie beeinflusst Bewertung Dynamic Rules?

9. Was bedeutet manuelle Bewertung?

10. Warum ist manuelle Bewertung wichtig?

11. Statusmodell

11.1 open

Bedeutung

Wann verwenden?

Admin-Aktion

Wirkung

11.2 acknowledged

Bedeutung

Wann verwenden?

Beispiel

Wirkung

11.3 investigating

Bedeutung

Wann verwenden?

Wirkung

11.4 plausible

Bedeutung

Typische Fälle

Beispiel

Wirkung

Wichtig

11.5 legitimate

Bedeutung

Typische Fälle

Wirkung

Vorsicht

11.6 false_positive

Bedeutung

Typische Fälle

Wirkung

Wichtig

11.7 resolved

Bedeutung

Wann verwenden?

Wirkung

11.8 suppressed

Bedeutung

Wann verwenden?

Wirkung

Vorsicht

11.9 confirmed_incident

Bedeutung

Wann verwenden?

Wirkung

Wichtig

12. Welche Bewertung beeinflusst den Lerneffekt?

12.1 Einfluss auf Host Risk Score

12.2 Einfluss auf Baseline-Lernen

12.3 Einfluss auf UEBA-Lernen

7.6 Was erkennt `ueba_new_user_context`?

7.7 Was erkennt `ueba_admin_new_host`?

7.8 Was erkennt `ueba_offhours_login`?

7.9 Was erkennt `ueba_first_privileged_use`?

11.1 `open`

11.2 `acknowledged`

11.3 `investigating`

11.4 `plausible`

11.5 `legitimate`

11.6 `false_positive`

11.7 `resolved`

11.8 `suppressed`

11.9 `confirmed_incident`

13.1 `keine Änderung`

13.2 `nicht lernen: 24h`

13.3 `nicht lernen: 7 Tage`

13.4 `nicht lernen: 30 Tage`

13.5 `nicht lernen: dauerhaft`