Erkennung von Identitäts- & Nutzerverhaltensanomalien (UEBA)

Die meisten Sicherheitsvorfälle laufen über ein gültiges Konto: gestohlene Zugangsdaten, gekaperte Sitzungen, missbrauchte Dienstkonten oder ein böswilliger Insider. Signaturregeln können eine legitime Anmeldung nicht von einer gestohlenen unterscheiden. UEBA erstellt statistische und ML-basierte Basislinien je Nutzer, Gerät und Vergleichsgruppe und schlägt bei Abweichungen Alarm (neues Land, ungewöhnliche Datenmenge, erstmalige privilegierte Aktion). Gut eingesetzt verkürzt es die Erkennung von Kontoübernahmen; unbedacht eingesetzt wird es zur Überwachung am Arbeitsplatz — in der EU sind die Gestaltung für Betriebsrat und DSGVO ebenso wichtig wie das Modell.

Problem & Nutzen

• Heute: Identitätsangriffe werden mit statischen Regeln erkannt (unmögliche Reisen, Schwellwerte für fehlgeschlagene Anmeldungen). Diese erzeugen viele Fehlalarme und übersehen langsamen Missbrauch („Low-and-Slow“). Insider-Fälle werden meist erst im Nachhinein durch ein Audit oder einen Hinweis entdeckt.
• KI-Nutzen: Basislinien je Entität und Vergleichsgruppe, Erkennung von erstmaligem und seltenem Verhalten, Sequenz- und Graphanalyse (laterale Bewegung über Konten hinweg), Risikowerte, die schwache Signale bündeln, und von LLMs formulierte Erklärungen, damit Analysten der ersten Stufe schnell entscheiden können.
• Belege: Anbieter veröffentlichen Erkennungszahlen, aber unabhängige, vergleichbare Angaben zu Fehlalarmen sind selten; messen Sie auf Ihren eigenen Daten. Der CMU-CERT-Datensatz zu Insider-Bedrohungen bleibt der gängige Forschungs-Benchmark, ist allerdings synthetisch [5].

Varianten

• KMU: Funktionen zum Identitätsschutz der vorhandenen Suite (Microsoft Entra ID Protection / Defender, Google Workspace, Okta) oder ein verwalteter Erkennungsdienst; kein separates UEBA-Produkt.
• Enterprise-SOC: UEBA innerhalb von SIEM/XDR (Sentinel, Splunk, Elastic, Exabeam, Securonix) mit Modellierung von Vergleichsgruppen und Beobachtungslisten (privilegierte Nutzer, Austretende).
• Cloud / nicht-menschliche Identitäten: Dienstkonten, API-Schlüssel und KI-Agenten — Basislinien für ihre API-Aufrufmuster (Bezug zu SEC-013, SEC-020).
• Öffentlicher Sektor / regulierte Branchen: pseudonymisierte Analysen mit einer kleinen, auditierten Gruppe für die Re-Identifizierung und strikter Zweckbindung.
• Kontoübernahme bei Kunden: dieselben Verfahren für Kundenanmeldungen → siehe ANOM-001, ANOM-014.

So funktioniert es

1. Logquellen (IdP, Cloud-Audit, VPN, Endpunkt, SaaS)
2. Normalisierung & Entitätsauflösung (Nutzer, Host, IP, App, Dienstkonto)
3. Merkmalsbildung (stündliche Zähler, Geo/ASN, Gerät, berührte Ressourcen, Tageszeit)
4. Baselines (je Entität, je Vergleichsgruppe, saisonal) + Modelle (Isolation Forest, Autoencoder, Sequenz-/Graphmodelle, bayessche Seltenheitswerte)
5. Risikoaggregation über ein gleitendes Fenster (z. B. 7–30 Tage)
6. Alarm mit Erklärung + Kontext (Rolle, Austrittskennzeichen, jüngste Änderungen)
7. Prüfung durch Analysten
8. Reaktion (zusätzliche MFA, Sitzung widerrufen, Ticket)
9. Feedback ans Modell

• Modelle: überwiegend klassisches unüberwachtes ML (Isolation Forest, Clustering, PCA, Zeitreihen- Prognosen); tiefe Sequenzmodelle und Graph-Embeddings ergänzen die Erkennung lateraler Bewegung. Gelabelte Daten sind selten, daher werden überwachte Modelle nur eingesetzt, wo eine Vorfallshistorie existiert.
• LLM-Schicht: fasst eine Risikozeitleiste zusammen, ordnet Anomalien MITRE-ATT&CK-Techniken zu und beantwortet Fragen der Analysten („Was hat dieses Konto in den 24 Stunden vor dem Alarm getan?“) — siehe SEC-001. LLMs entscheiden nicht; die Werte stammen aus der statistischen Schicht.
• Mensch-in-der-Schleife (Human-in-the-Loop): Analysten bestätigen; das Sperren eines Kontos oder der Zugriff auf die detaillierte Aktivität einzelner Beschäftigter braucht eine dokumentierte Freigabe (Vier-Augen-Prinzip, Zustimmung des Betriebsrats).

Datenaufbereitung

UEBA benötigt Identitäts- und Aktivitätsprotokolle: Anmeldungen in Entra ID/Active Directory, VPN, Proxy, Cloud-Audit-Protokolle, SaaS- und Endpunktereignisse sowie HR-Kontext (Rolle, Abteilung, Austritte). In einem KMU liegen diese im Identitätsanbieter, in den Firewall-Appliances und in den Admin-Portalen für E-Mail und Cloud; oft beträgt die Aufbewahrung nur 30 bis 90 Tage, und niemand hat sie je exportiert.

Typische Lücken: kurze Aufbewahrung der Protokolle, uneinheitliche Zeitstempel und Nutzernamen über Systeme hinweg, geteilte Konten und Dienstkonten ohne Verantwortliche, verwaiste Konten ehemaliger Beschäftigter, keine Definition von Vergleichsgruppen und fehlende HR-Anbindung für Eintritte, Wechsel und Austritte.

Schritte der Aufbereitung: 1. Protokollquellen inventarisieren und die Audit-Protokolle aktivieren, die Sie ohnehin bezahlen (siehe PREP-005, PREP-001). 2. Protokolle mit einem gemeinsamen Schema zentralisieren (Wazuh, OpenSearch, Sentinel) und die Aufbewahrung auf mindestens 6 bis 12 Monate verlängern, damit sich Basislinien bilden können. 3. Identitätsbestand bereinigen: Verantwortliche für Dienstkonten benennen, verwaiste Konten entfernen, Nutzerkennungen systemübergreifend zuordnen. 4. Vergleichsgruppen definieren und Nutzerkennungen für Analysten möglichst pseudonymisieren (PREP-022). 5. Zweck und Rechtsgrundlage klären (PREP-025).

Rechnen Sie damit, dass etwa 50 bis 60 Prozent des Gesamtaufwands in die Anbindung der Protokolle und die Identitätshygiene fließen, nicht in das Modell selbst. Eine Bereitschaftsprüfung ist in GUIDE-003 beschrieben.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A. Verwalteter Identitätsschutz (z. B. Entra ID Protection, Okta ThreatInsight) oder ein MDR-Dienst liefert Basislinien ohne eigenes SOC; der Prozess ist Standard.
• Enterprise: Weg C. Verhaltensprofile von Beschäftigten sind hochsensibel, und die SIEM-/Data-Lake-Plattform wird mit anderen Sicherheits-Anwendungsfällen geteilt; ein eigener Open-Source- oder Eigenbau-Stack behält die Kontrolle.
• Entwickler: Weg C. Open-Source-Werkzeuge (Wazuh, OpenSearch Anomaly Detection, scikit-learn) auf HW1 erlauben es, Erkennungen ohne Herstellerabhängigkeit zu bauen und abzustimmen.
• Öffentlicher Sektor: Weg C. Anforderungen von Personalrat und Souveränität sprechen für einen selbst betriebenen oder Sovereign-Cloud-Betrieb mit transparenter Logik.

Weg A — Kaufen (Standardsoftware) (für die meisten empfohlen)

• In die Suite integriert: Microsoft Sentinel UEBA und Entra ID Protection (Basislinien für Nutzer, Hosts, IPs und Apps; Tabellen wie BehaviorAnalytics, Schicht der jüngsten Verhaltensweisen und Anomalien bei Verhaltensweisen) [1][2]; Google Security Operations; CrowdStrike Falcon Identity Protection; Okta Identity Threat Protection.
• Spezialisierte UEBA / SIEM der nächsten Generation: Exabeam, Securonix, Splunk (UBA / Enterprise Security), Darktrace, Rapid7 InsightIDR, Varonis (datenzentriert), Stellar Cyber.
• EU-Anbieter / in der EU gehostet: Sekoia.io (FR), Wazuh-basierte verwaltete Dienste, Hornetsecurity, ESET (SK) XDR; prüfen Sie den Datenstandort in der EU.
• Wählen Sie A, wenn: Sie bereits eine Suite von Microsoft/Google/Okta betreiben oder kein ML-Personal haben. Prüfen: Abdeckung der Konnektoren, Erklärbarkeit je Alarm, Konfiguration der Vergleichsgruppen, Pseudonymisierung, Aufbewahrung und Zugriffskontrollen für die Analysedaten.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Plattform-ML: Anomalieerkennungs-Jobs von Elastic Machine Learning auf Identitätsprotokollen [3]; benutzerdefinierte Anomalien in Sentinel; OpenSearch Anomaly Detection; Amazon GuardDuty (Befunde zum Verhalten aus CloudTrail), Google SCC.
• LLM für die Untersuchung: ein LLM in einer EU-Region (Mistral, Azure OpenAI EU, Claude über EU- Endpunkte), um Risikozeitleisten zu erklären — übergeben Sie nur pseudonymisierte Kennungen.
• Wählen Sie B, wenn: ein SIEM vorhanden ist und Sie eigene Erkennungen für Nischensysteme (ERP, PACS) wünschen.

Weg C — Selbst betreiben (Open Source)

• Stack: Wazuh oder Security Onion zur Erfassung, OpenSearch/Elastic für Speicherung und Anomalie-Jobs, PyOD [4], scikit-learn, River (Streaming), PyTorch Geometric für Graphen; Sigma-Regeln als Regelbasis; ein Open-Weight-LLM (Qwen, Llama, Mistral) über vLLM/Ollama für Erklärungen.
• Hardware: HW1 (CPU) für statistische Modelle und einige tausend Entitäten; HW2 nur, wenn Sie das Erklärungs-LLM selbst betreiben. Der Hauptaufwand liegt in Datenengineering und Abstimmung, nicht in der Rechenleistung.

Weg D — Eigenes Training

Lohnt sich für große Organisationen mit ungewöhnlichen Systemen oder hochwertigen Programmen gegen Insider-Risiken: Sequenz-/Graphmodelle auf 6–12 Monaten normalisierter Protokolle trainieren, mit von Red Teams oder Purple Teams eingespielten Szenarien als Evaluierungslabels. Erfordert ein Team aus Data Science und Detection Engineering sowie eine Feedbackschleife mit Labels aus abgeschlossenen Fällen.

Stand der Technik (2026)

• Verhaltensschichten über den Rohprotokollen: SIEMs fassen heute Protokolle mit hohem Volumen zu lesbaren „Verhaltensweisen“ zusammen und erkennen erstmalige oder ungewöhnlich häufige Verhaltensweisen; generative KI liefert die Beschreibungen [1][2].
• Identitätszentrierte Erkennung: UEBA verschmilzt mit ITDR (Identity Threat Detection & Response): Token-Diebstahl, MFA-Müdigkeit, Missbrauch von OAuth-Zustimmungen und Missbrauch von Service Principals sind heute Kernfälle.
• Agentenbasierte Triage auf UEBA-Alarmen (SEC-001) verkürzt die Prüfzeit, doch Bewertungen beruhen weiterhin auf Basislinien.
• Grenzen: Kaltstart (neue Nutzer und Rollenwechsel haben keine Basislinie), verrauschte Vergleichsgruppen, saisonale Ereignisse (Audits, Monatsabschluss, Ferien), die Fehlalarme auslösen, Concept Drift nach Reorganisationen und Angreifer, die im normalen Verhalten bleiben. Anomal ist nicht bösartig; planen Sie mehrere Wochen Abstimmung ein und das Unterdrücken nach Kontext (Reisen, Projekte).
• Erklärbarkeit zählt: Alarme, die nicht sagen können, warum (welches Merkmal, welche Basislinie), sind gegenüber Arbeitnehmervertretungen und in arbeitsrechtlichen Streitigkeiten schwer zu verteidigen.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (Anomalieerkennung + Zeitreihen + Streaming): SEC-006 Erkennung von Netzwerkangriffen, SEC-015 OT-Überwachung, ANOM-005 industrielle Anomalien, ANOM-001 Betrugsbewertung.
• Kombinierbar mit: SEC-001 (Triage von UEBA-Alarmen), SEC-020 (Zugriffsprüfungen, gespeist aus Befunden zu anomalen Berechtigungen), SEC-008 (Bedrohungsinformationen), SEC-011 (Social Engineering mit Deepfakes geht einer Kontoübernahme oft voraus), SEC-017 (Kontext zu Datenabfluss).
• Gemeinsame Datenpipeline: ein normalisierter Log-Lake (Schema OCSF oder ECS) bedient alle SEC.DETECT-Fälle.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis zur Aktivierung; Kosten sind Lizenz plus Volumen der Protokollaufnahme (oft der größte Posten).
• Weg B: 2–4 Monate für einen abgestimmten Satz an Erkennungen auf einem bestehenden SIEM.
• Weg C: 3–6 Monate inkl. Datenengineering; geringe Lizenzkosten, höhere Personalkosten.
• Weg D: 6+ Monate, spezialisiertes Team.
• Kennzahlen: mittlere Zeit bis zur Erkennung/Eindämmung einer Kontokompromittierung, Alarmpräzision (Anteil echter Treffer nach der Triage), Analystenminuten je Alarm, Abdeckung der Identitätsquellen, Erkennungsrate in Purple-Team-Übungen, Zahl der Beschwerden beim Betriebsrat oder Auskunftsersuchen Betroffener (Tendenz gegen null).

Menschen & Veränderung

UEBA bewertet das Verhalten einzelner Beschäftigter, daher beziehen Sie die Menschen früh ein, vor dem Pilotbetrieb, nicht erst nach dem Vertragsabschluss.

• Betriebsrat: ja. Das System ist objektiv geeignet, Verhalten und Leistung zu überwachen, daher greift die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG (BAG); § 90 Abs. 1 Nr. 3 verlangt rechtzeitige Unterrichtung. Streben Sie eine Betriebsvereinbarung an, die den Zweck (nur Sicherheit), die pseudonymisierte Analyse in der ersten Stufe, die Aufbewahrung und ein Verbot der Leistungsbeurteilung festlegt. Der Betriebsrat kann eine(n) KI-Sachverständige(n) hinzuziehen (§ 80 Abs. 3). In öffentlichen Stellen hat der Personalrat dieselbe Rolle.
• Datenschutzbeauftragte(r) und DSFA: Eine DSFA (Art. 35 DSGVO) ist wegen der systematischen Bewertung von Verhalten sehr wahrscheinlich; schließen Sie mit jedem Anbieter einen AVV (Art. 28 DSGVO).
• IT-Sicherheit, IT und HR legen Datenquellen, Alarmbearbeitung und den Austrittsprozess fest; die Geschäftsleitung verantwortet Entscheidung und Budget.
• KI-Kompetenz: Unterstützen Sie Analysten und Administratoren mit Schulungen zu Fehlalarmen und zur Interpretation der Werte (Art. 4 KI-Verordnung).
• Kommunikation und Pilot: Kommunizieren Sie Zweck und Grenzen offen und beginnen Sie mit den IT-/Admin-Konten als Pilotgruppe.
• Typische Sorge: „Überwachung“. Begegnen Sie ihr mit Transparenz, einer dokumentierten Zweckbindung und der Regel, dass ein Alarm ein Hinweis ist, nie eine automatische Sanktion; über jede Konsequenz entscheiden Menschen.

Siehe GUIDE-004, GUIDE-005 und GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimal, wenn sie ausschließlich für die Cybersicherheit von IT-Systemen genutzt wird. Sie wird hochriskant (Anhang III, Beschäftigung — Überwachung und Bewertung von Leistung/Verhalten von Beschäftigten), wenn die Werte in HR-Entscheidungen, Disziplinarmaßnahmen oder Leistungsbeurteilungen einfließen. Verbot nach Art. 5: Das Ableiten von Emotionen Beschäftigter aus biometrischen oder Verhaltensdaten am Arbeitsplatz ist verboten — ergänzen Sie UEBA nicht um Stimmungs- oder Stressableitung [6]. Halten Sie das System rein sicherheitsbezogen und technisch getrennt von HR-Analysen.
• DSGVO: Nutzerprotokolle sind personenbezogene Daten; Rechtsgrundlage meist Art. 6 Abs. 1 lit. f berechtigtes Interesse (Netz- und Informationssicherheit, Erwägungsgrund 49) mit dokumentierter Interessenabwägung; eine DSFA (Art. 35) ist bei systematischer Überwachung von Beschäftigten normalerweise erforderlich; Transparenz (Art. 13/14), Zweckbindung, Datenminimierung, rollenbasierter Zugriff auf Rohaktivitäten, kurze Aufbewahrung; Art. 22 greift, wenn Entscheidungen mit Rechtswirkung vollständig automatisiert getroffen werden [7].
• Mitbestimmung der Beschäftigten: In Deutschland gibt § 87 Abs. 1 Nr. 6 BetrVG dem Betriebsrat Mitbestimmung bei technischen Systemen, die Verhalten überwachen können — eine Betriebsvereinbarung ist faktisch Voraussetzung; ähnliche Informations- und Konsultationspflichten bestehen auch anderswo in der EU. Öffentliche Stellen: Entsprechungen des Personalrats.
• Branchenregeln: NIS2 (Art. 21 Risikomanagementmaßnahmen) und DORA für den Finanzsektor drängen auf Erkennungsfähigkeit, was das berechtigte Interesse stützt [8].
• Gegenmaßnahmen: Identitäten in Analysen pseudonymisieren, Re-Identifizierung im Notfall (Break-Glass) mit Protokollierung, besondere Kategorien und Daten zur privaten Nutzung ausschließen, Kriterien für Beobachtungslisten schriftlich festlegen, Modelle auf Verzerrungen zwischen Rollen/Standorten prüfen, im Verzeichnis der Verarbeitungstätigkeiten dokumentieren.

Erste Schritte

1. Identitäts- und Cloud-Protokollquellen inventarisieren; Audit-Protokollierung aktivieren und in ein SIEM/einen Lake leiten.
2. Zuerst Datenschutzbeauftragte(n) und Betriebsrat einbeziehen; Betriebsvereinbarung, Zweck, Aufbewahrung und Zugriffsregeln entwerfen.
3. Die eingebauten Funktionen zu Identitätsschutz/UEBA Ihrer aktuellen Suite im reinen Überwachungsmodus einschalten.
4. 4–6 Wochen laufen lassen, um Basislinien zu bilden; die 50 häufigsten Alarme wöchentlich prüfen und Labels (echt/falsch) erfassen.
5. Kontext ergänzen (Austretende, privilegierte Gruppen, Reisekalender) und freigegebene Reaktionen anbinden (Step-up-MFA, Sitzungssperre); mit einer Purple-Team-Übung testen.

Quellen

1. Microsoft Learn — Advanced threat detection with UEBA in Microsoft Sentinel — https://learn.microsoft.com/en-us/azure/sentinel/identify-threats-with-entity-behavior-analytics
2. Microsoft Learn — Investigate anomalies on UEBA behaviors in Microsoft Sentinel — https://learn.microsoft.com/en-us/azure/sentinel/ueba-anomalies-on-behaviors
3. Elastic — Machine learning anomaly detection overview — https://www.elastic.co/guide/en/machine-learning/current/ml-ad-overview.html
4. PyOD — Python outlier detection toolkit — https://github.com/yzhao062/pyod
5. CMU CERT — Insider Threat Test Dataset — https://kilthub.cmu.edu/articles/dataset/Insider_Threat_Test_Dataset/12841247
6. Regulation (EU) 2024/1689 (AI Act), Art. 5 and Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
8. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj