Sentinel im Defender-Portal ist in vielen Tenants, die ich betreue, gerade ein großes Thema. Spätestens seit Microsoft die Preview für die Integration von Microsoft Sentinel in die Unified Security Operations Platform, also das Defender-Portal, geöffnet hat, kommt die Frage in fast jedem Projekt auf. Für Security-Operations-Teams verspricht die enge Verzahnung von Sentinel mit Microsoft Defender XDR eine deutliche Erleichterung: eine gemeinsame Oberfläche, zentrales Incident-Handling und einfacheres Hunting. Zwischen der Ankündigung auf der Ignite 2023 und dem produktiven Einsatz liegen allerdings einige Fallstricke und Einschränkungen, und auch an Rollen und Rechte stellt die Integration neue Anforderungen.

Das Onboarding verlangt Adminrechte in Sentinel und im Defender-Portal

Für viele Tenants in der Public Cloud steht das Onboarding von Sentinel ins Defender-Portal inzwischen als Preview bereit. Pro Tenant lässt sich technisch genau ein Sentinel-Workspace mit dem Defender-Portal koppeln – mehrere Workspaces anzubinden oder zwischen ihnen zu wählen, ist bislang nicht vorgesehen. Das eigentliche Onboarding startet ihr über die Defender-Einstellungen, so wie es im Artikel auf Microsoft Learn beschrieben ist. In der Preview braucht ihr für die Verbindung administrative Rechte sowohl in Sentinel als auch im Defender-Portal. Wie eng Rollen und Berechtigungen dabei ineinandergreifen, unterschätzen viele Kunden. Fehlt die passende Zuweisung auf einer der beiden Seiten, bleibt die Integration Stückwerk.

SOC-Teams bearbeiten Sentinel- und Defender-Incidents in einem Portal

Im Kern geht es darum, dass Alerts und Incidents aus Sentinel als Teil der Unified Incidents im Defender-Portal auftauchen. Sie stehen dann direkt neben den XDR-Detektionen aus Microsoft 365, Defender for Endpoint, Identity und den übrigen Defender-Produkten, und das ständige Hin- und Herspringen zwischen den Portalen fällt weg. Wie viel Zeit das spart, sehe ich in Security-Teams immer wieder. Die Incident-Ansicht des Defender-Portals fasst die einzelnen Alerts zusammen, ganz gleich, ob sie aus Sentinel-Analytics oder aus Defender-Detektoren kommen. So werden Zusammenhänge sichtbar, die in getrennten Silos verborgen geblieben wären. Aktionen wie Schließen oder Zuweisen bilden die Plattformen allerdings noch nicht immer einheitlich ab; bei Löschungen oder Statusänderungen kann es in der Preview Abweichungen geben.

Ein Tipp aus der Praxis: Wenn ihr in Sentinel bereits automatisierte Playbooks oder feste Abläufe für Incidents nutzt, prüft die Mappings und Workflows sorgfältig. Doppelt bearbeitete Incidents und übersehene Statusänderungen gehören derzeit noch zu den häufigsten Fehlerquellen.

Wer schon mit Defender XDR arbeitet, sollte die Einführung zu Defender XDR hier im Blog und die offizielle Anleitung zum Sentinel-Onboarding griffbereit haben. Gerade während der Preview bewahren euch diese Quellen vor manchem Stolperstein.

Advanced Hunting durchsucht jetzt Sentinel- und Defender-Tabellen gemeinsam

Dank der Integration greifen Security-Analysten in der Advanced-Hunting-Oberfläche des Defender-Portals nun auf Sentinel- und Defender-Tabellen zugleich zu. Dahinter steckt eine erweiterte KQL-Abfrage-Engine, die native Defender-XDR-Quellen wie DeviceEvents oder EmailEvents ebenso durchsucht wie verbundene Sentinel-Tabellen, etwa SecurityEvent oder CustomLog. Darauf haben viele SOCs lange gewartet, denn Hypothesen lassen sich damit über sämtliche Plattformdaten hinweg prüfen.

Eine einfache plattformübergreifende Hunting-Query sieht so aus:

union DeviceEvents, SecurityEvent
| where Timestamp > ago(1d)
| where AccountName == "adminuser"
| project Timestamp, AccountName, DeviceName, EventID, ReportId

Mit Abfragen dieser Art untersucht ihr verdächtige Aktivitäten in Endpoint- und Server-Logs beider Welten in einem Rutsch. Welche Tabellen unterstützt werden und wie die Syntax genau aussieht, steht auf Microsoft Learn.

Analytics, Automatisierung und Workbooks bleiben vorerst in Sentinel

In Sentinel arbeiten viele mit umfangreichen Analytics Rules, mit Logic Apps zur Automatisierung und mit Workbooks fürs Reporting. Die Preview im Defender-Portal beschränkt sich jedoch weitgehend auf Incidents und Hunting. Analytics Rules verwaltet ihr weiterhin in Sentinel, und auch die Automatisierung, etwa Playbooks mit Logic Apps, bleibt vorerst dort. Sentinel-Workbooks zeigt das Defender-Portal noch gar nicht an. Wer Regeln oder Automatisierungen feinjustieren will, kommt deshalb um die Sentinel-Oberfläche nicht herum, zumindest solange die Integration im Preview-Status ist. Teams sollten außerdem wissen, dass eine Rollenzuweisung im Defender-Portal allein nicht genügt, um Analytics oder Playbooks in Sentinel zu bearbeiten.

Die Einschränkungen der Preview im Überblick (Stand Juni 2024):

  • Nur ein Sentinel-Workspace pro Tenant
  • Keine Sichtbarkeit von Sentinel-Workbooks im Defender-Portal
  • Analytics Rules und Automatisierung bleiben in Sentinel
  • Rollen müssen in beiden Portalen (Defender + Sentinel) korrekt zugewiesen sein
  • Zuweisung und Bearbeitung von Incidents werden nicht immer konsistent synchronisiert

Bevor ich zu den organisatorischen Folgen komme, lohnt sich ein Blick auf den Ablauf. Das folgende Diagramm zeigt den Weg von der Detektion bis zum Incident im Unified Portal.

flowchart TD
    SentinelRules["Sentinel Analytics"] --> SentinelAlerts["Sentinel Alerts"]
    DefenderDetectors["Defender Detectors"] --> DefenderAlerts["Defender Alerts"]
    SentinelAlerts --> UnifiedIncidents["Unified Incidents"]
    DefenderAlerts --> UnifiedIncidents
    UnifiedIncidents --> PortalView["Defender Portal"]

Abbildung: So gelangen Alerts aus Sentinel und Defender in das Unified Incident Management des Defender-Portals (Preview)

In der Preview lohnt sich zuerst ein Pilot in einer Testumgebung

Mit der Integration von Sentinel ins Defender-Portal hat Microsoft einen wichtigen Schritt gemacht, doch die Preview bringt auch neue Schwierigkeiten mit sich. Vor allem die getrennte Rollenvergabe für Defender und Sentinel sowie die eingeschränkte Sichtbarkeit dürften SOC-Teams anfangs ungewohnt vorkommen. Ich rate derzeit dazu, die Integration zuerst in Testumgebungen zu erproben und dabei genau hinzuschauen, wie Incidents synchronisiert werden, ob die Rollen stimmen und ob die Automatisierung weiter sauber läuft. Wer bisher mit strikt getrennten Teams für Defender XDR und Sentinel gearbeitet hat, sollte Kommunikationswege und Zuständigkeiten überprüfen, damit niemand denselben Incident doppelt bearbeitet. Auf lange Sicht bringt die Integration echten Nutzen. Im Moment braucht es aber noch einiges an Handarbeit und Monitoring, um ihr Potenzial ohne Reibungsverluste auszuschöpfen.