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

12.4 Einfluss auf Dynamic Rules

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`