In vielen Tenants, die ich mir anschaue, ist immer noch unklar, wie man den Funktionsumfang von Microsoft Defender XDR sinnvoll ausschöpft. Kleine Security-Teams fühlen sich schnell erschlagen, denn sie haben es mit mehreren Einzelprodukten und jeder Menge Alerts aus Endpoint, Office 365, Identitäten und Cloud Apps zu tun. Da fällt es schwer, den Überblick zu behalten und trotzdem zügig zu reagieren. Defender XDR bündelt deshalb alle relevanten Signale unter einem Dach. Die Umbenennung von Microsoft 365 Defender in Defender XDR hat zwar für etwas Verwirrung gesorgt. Am Grundgedanken ändert das aber nichts, denn Bedrohungen sollen möglichst effizient erkannt, korreliert und abgewehrt werden.

Die zentrale Incident Queue verschafft endlich Überblick

Zu den größten Fortschritten zählt die einheitliche Incident Queue in Defender XDR. Früher musste man Alerts einzeln in Defender for Endpoint, Defender for Office 365, Defender for Identity oder Defender for Cloud Apps prüfen. Heute korreliert Defender XDR diese Signale automatisch und stellt sie als zusammenhängende Incidents dar. Das spart viel Zeit, und echte Bedrohungen lassen sich schneller von False Positives unterscheiden. Ohne diese Bündelung sehen Security-Teams nach meiner Erfahrung oft den Wald vor lauter Bäumen nicht, besonders wenn plötzlich eine Flut einzelner Alerts hereinbricht.

Dahinter steckt ein einfaches Prinzip. Geräte, Benutzer und Cloud-Anwendungen gelten als zusammengehörige Entitäten. Erkennt Defender XDR zum Beispiel auf einem Endpoint ein verdächtiges PowerShell-Skript und stellt zugleich beim zugehörigen Benutzerkonto eine ungewöhnliche Anmeldung fest, landet beides in einem gemeinsamen Incident. Im Portal ist der Kontext sofort sichtbar, und man kann gleich einschätzen, ob ein gezielter Angriff vorliegt oder doch nur ein Fehlalarm.

Mein Tipp: Nutzt die Filter- und Gruppierungsfunktionen der Incident Queue ausgiebig. Damit priorisiert ihr schneller und erkennt, welche Incidents mehr Aufmerksamkeit brauchen.

Automatisierte Untersuchungen und Reaktionen (AIR) entlasten kleine Teams

Spürbar entlastet werden kleine Teams durch die Automatisierung, die Defender XDR mitbringt. Mit automatisierten Untersuchungen und Reaktionen (AIR) lassen sich viele wiederkehrende Aufgaben abfangen. Sobald ein Incident erkannt wird, prüft Defender XDR selbstständig, welche Geräte betroffen sind, welche Prozesse laufen und ob verdächtige Verbindungen bestehen. Wo es möglich ist, leitet das System sogar direkt Maßnahmen ein und isoliert etwa einen Endpoint oder setzt gefährdete Konten zurück.

Alles muss man der Automatik aber nicht überlassen. Gerade am Anfang lohnt es sich, die vorgeschlagenen Aktionen genau anzusehen und Automatisierungen nach und nach zu aktivieren. In kleineren Umgebungen zeigt sich oft, dass eine zu aggressive Automatisierung unerwünschte Nebenwirkungen haben kann. Wer schon mit Defender for Endpoint gearbeitet hat, kennt die automatischen Untersuchungen bereits. Neu ist, dass sie jetzt für alle angebundenen Bereiche zur Verfügung stehen.

Advanced Hunting erlaubt den Blick unter die Haube

Wer tiefer einsteigen möchte, greift in Defender XDR zum „Advanced Hunting“. Dahinter steckt ein Abfragewerkzeug auf Basis von KQL (Kusto Query Language), mit dem sich Security-Daten aus verschiedenen Quellen flexibel durchsuchen lassen. Typisch ist etwa die Frage, ob in den letzten 24 Stunden jemand von ungewöhnlichen Standorten aus auf die Cloud zugegriffen hat oder ob die Logdaten Hinweise auf bekannte Angriffsmuster enthalten.

KQL wirkt anfangs komplex und kann abschrecken, im Portal finden sich aber zahlreiche Vorlagen und Beispiele. Ich rate dazu, klein anzufangen, vorhandene Beispiele zu kopieren und sie schrittweise anzupassen. Sehr hilfreich ist dabei die Dokumentation im Überblick über Advanced Hunting.

DeviceLogonEvents
| where RemoteIPCountry != "Germany"
| summarize count() by Account, RemoteIPCountry

Schon mit so einfachen Abfragen sieht man, welche Konten von wo aus zugegriffen haben, und stößt rasch auf Auffälligkeiten.

Eine Mermaid-Grafik zeigt das Zusammenspiel der Komponenten

Damit das Zusammenspiel von Signalerfassung, Incident-Korrelation und automatisierter Reaktion greifbarer wird, habe ich eine einfache Mermaid-Grafik erstellt. Sie zeigt, wie die einzelnen Defender-Komponenten ihre Daten an Defender XDR liefern, wie daraus ein Incident entsteht und welche Reaktionen folgen können:

flowchart TD
  Endpoint["Defender for Endpoint"] --> XDR["Defender XDR"]
  Identity["Defender for Identity"] --> XDR
  Office["Defender for Office 365"] --> XDR
  CloudApps["Defender for Cloud Apps"] --> XDR
  XDR --> Incident["Incident Queue"]
  Incident --> AIR["Automatisierte Reaktion"]

Abbildung: Signalfluss und Incident-Verarbeitung in Defender XDR

Wer sich näher damit beschäftigt, merkt schnell, dass die Plattform die Stärken der Einzelprodukte zusammenführt. Das Geschehen wird dadurch transparenter, Signale lassen sich besser korrelieren, und man reagiert schneller.

Kleine Teams sollten Schritt für Schritt einsteigen

Für kleinere Security-Teams ist der Einstieg oft ein Drahtseilakt zwischen notwendigem Schutz und knappen Ressourcen. Ich würde zuerst prüfen, ob alle Defender-Komponenten angebunden sind, und die Incident Queue als zentrale Arbeitsoberfläche etablieren. Parallel dazu kann man mit den Standard-Automatisierungen beginnen, sollte aber nicht gleich alles scharfschalten. Besser lernt man nach und nach, welche Aktionen in der eigenen Umgebung zuverlässig funktionieren. Beim Hunting hilft es, regelmäßig mit einfachen KQL-Abfragen zu arbeiten. So entwickelt man mit der Zeit ein Gespür dafür, was in den eigenen Logs typischerweise auffällt.

Weiterführende Informationen bieten die Dokumentation zu Defender XDR und der Überblick über Incidents. In meiner Praxis zahlt sich der Aufwand schnell aus. Die Alert-Müdigkeit sinkt, die Übersicht wächst, und vor allem hat man die Gewissheit, auch mit einem kleinen Team souverän reagieren zu können.