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