Sentinel Entity Behavior Analytics: UEBA in Microsoft Sentinel verstehen und nutzen

Definition

User and Entity Behavior Analytics (UEBA) ist eine Analyseschicht in Microsoft Sentinel, die behavior über time für entities wie User, Devices oder IPs modelliert und anomalies erkennt. UEBA ist weder ein SIEM-Ersatz noch EDR/XDR, sondern behavior analytics auf Basis von logs und events zur besseren threat detection und investigation.

Einleitung

Wenn zu viele Alerts reinkommen, wird aus Security schnell „Abarbeiten“. Sentinel Entity Behavior Analytics hilft dir, activity als Muster zu sehen: Was ist normal, was ist ungewöhnlich, und welche entity sollte zuerst geprüft werden.

Wie UEBA Baselines baut und Anomalien erkennt

UEBA verarbeitet behavioral Daten über verschiedene Quellen hinweg und baut daraus eine Baseline bzw. ein Verhaltensprofil pro entity und Peer-Group. Anomalien entstehen, wenn activity deutlich vom üblichen Verhalten abweicht, z. B. bei access zu neuen Ressourcen, ungewöhnlichen Zeiten, neuen Devices oder seltenen Kombinationen aus User, App und Standort.

In Sentinel siehst du Ergebnisse typischerweise als Anomalies, in der BehaviorAnalytics-Tabelle und in verbundenen Insights. Für die Priorisierung werden Scores genutzt (z. B. Anomaly score oder Investigation priority score), damit du nicht jedes Event gleich behandeln musst.

Typische UEBA-Datenquellen, Enrichments und Tabellen

UEBA lebt von sauberen, konsistenten logs. Typische Datenquellen sind Identität, Cloud-Aktivität und Security-Events; Enrichments liefern Kontext, damit Investigations schneller gehen.

• Quellen: SigninLogs (Entra ID), AuditLogs, AzureActivity, Windows Security Events, zusätzlich je nach Umgebung Okta oder AWS CloudTrail.
• Enrichments: IdentityInfo, UserPeerAnalytics, Threat Intelligence und Asset-/User-Kontext (Rolle, Abteilung, Kritikalität).
• Zentrale Tabellen: Anomalies table, BehaviorAnalytics table sowie ActivityInsights (je nach aktivierten Lösungen).

Schritt-für-Schritt: UEBA in Microsoft Sentinel aktivieren

Ein pragmatisches Setup zielt zuerst auf wenige, stabile Quellen und überprüfbare Ergebnisse. Die Aktivierung erfolgt im Microsoft Sentinel-Umfeld (heute typischerweise über das Defender Portal mit Sentinel-Anbindung) und wirkt im Log Analytics workspace.

Setup-Checkliste (vor dem Enable)

• Log Analytics workspace ist angebunden, Daten werden zuverlässig ingestiert (Zeitstempel, Zeitzone, Parser).
• Mindestens Entra ID Sign-in Logs und AuditLogs sind aktiv; Berechtigungen für Sentinel/Defender passen.
• Owner für Betrieb definiert: Wer prüft anomalies, wer entscheidet über incident-Eröffnung.

Aktivierung und Einrichtung

• Microsoft Sentinel öffnen, UEBA bzw. Entity behavior/behavior analytics aktivieren und Quellen verbinden.
• UEBA Essentials solution hinzufügen, um Start-Hunting queries und Content zu bekommen.
• Erste Baseline-Phase abwarten, dann anomalies regelmäßig reviewen und Tuning starten.

Wichtig für den Nutzen: UEBA nicht „einfach einschalten und vergessen“. Ohne feste Reviews wird aus anomalies wieder nur Noise, nur diesmal in neuer Verpackung.

Queries und typische Use-Cases für Analyse

UEBA wird greifbar, wenn du anomalies in Kusto Query Language (KQL) mit weiteren Signalen korrelierst. Drei typische Use-Cases: kompromittierte credentials, laterale Bewegung und ungewöhnliche Admin-Aktivität.

Beispiel-Queries (KQL)

• Hohe UEBA-Anomalien der letzten 24h:
• Anomalies
  | where TimeGenerated > ago(24h)
  | order by AnomalyScore desc
• BehaviorAnalytics nach entity und Score:
• BehaviorAnalytics
  | where TimeGenerated > ago(7d)
  | summarize MaxScore=max(Score) by EntityType, EntityName
  | order by MaxScore desc
• Anomalie + Identitätskontext (IdentityInfo):
• Anomalies
  | where TimeGenerated > ago(48h)
  | join kind=leftouter IdentityInfo on $left.AccountObjectId == $right.AccountObjectId
  | project TimeGenerated, AnomalyName, AnomalyScore, AccountUPN, Department, JobTitle

Mini-Story: Ein User meldet sich „erfolgreich“ an, aber UEBA markiert das Verhalten als anomalous, weil Location, Device und Uhrzeit nicht zur Baseline passen. Im Defender Portal siehst du parallel verwandte sign-ins und Defender-Signale. Statt 20 Einzel-Events entsteht eine kurze Liste prüfbarer Leads.

Integration in Defender Portal, Dashboards und Reporting

Für den Betrieb zählt, dass UEBA-Erkenntnisse dort landen, wo du arbeitest: im Defender Portal für Investigations und in Sentinel für SIEM-Workflows. Für Reporting eignen sich Sentinel Workbooks als Dashboard-Schicht, z. B. Trends zu anomalies, Top entities, häufige behaviors und Zeit bis zur Einordnung.

Messbarkeit entsteht, wenn du zwei Kennzahlen fest definierst: Anteil der anomalies, die zu einem incident führen, und Zeit bis zur Triage. Das zeigt, ob UEBA wirklich hilft oder nur zusätzliche activity erzeugt.

Kosten, Preislogik und Skalierbarkeit (ohne konkrete Beträge)

Budget-Bedenken sind berechtigt: UEBA rechnet zwar „intelligent“, hängt aber am Datenfundament. In der Praxis kommen Kosten vor allem durch ingestierte logs im Log Analytics workspace und durch Aufbewahrung/Retention. Skalierung gelingt, wenn du Quellen priorisierst, unnötige events reduzierst und Queries/Workbooks schlank hältst.

Lohnt sich das? Ja, wenn UEBA weniger manuelle Analysezeit erzeugt und schneller die richtigen investigations priorisiert. Wenn niemand anomalies reviewt oder Enrichments fehlen, ist der ROI klein.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung wird sinnvoll, wenn UEBA nicht nur „enable“ sein soll, sondern als wiederholbarer Prozess funktioniert: Quellenstrategie, Tuning, Hunting queries, Dashboarding und klare Governance. Besonders bei 150+ Usern steigen Volumen, Rollenmodelle, Sonderfälle und damit die Betriebslast schnell.

365SecurityHeroes betreibt Managed Microsoft 365 Security im Microsoft Security-Stack (Entra ID, Defender XDR, Sentinel) und übernimmt Konfiguration, kontinuierliches Tuning, Monitoring und Reporting im vereinbarten Servicefenster. Ziel ist, dass UEBA nicht nur läuft, sondern in Entscheidungen endet.