Ein Sicherheitsportal voller Warnungen ist kein Beleg für gute Erkennung. Entscheidend ist, ob aus einem Signal rechtzeitig eine richtige Entscheidung und anschließend eine überprüfbare Reaktion wird.
Microsoft Defender XDR führt Signale aus unterschiedlichen Bereichen zusammen. Dazu können Endgeräte, Identitäten, E-Mail, Kollaborationsinhalte und Cloud-Anwendungen gehören. Das Ziel ist nicht, möglichst viele Einzelwarnungen zu zeigen, sondern zusammengehörige Aktivitäten als Vorfall zu erkennen.
Diese Korrelation ist besonders wertvoll, weil moderne Angriffe selten in einem Dienst bleiben. Eine Phishing-Mail führt zu einer Anmeldung, die Anmeldung zu einem Token-Missbrauch, der Missbrauch zu verdächtigen Dateiaktivitäten. Wer nur ein einzelnes Produkt betrachtet, sieht möglicherweise lediglich einen Ausschnitt.
Ein Incident ist eine Arbeitshypothese
Ein Defender-Incident bündelt Warnungen und betroffene Entitäten. Er liefert eine Ausgangslage für die Untersuchung, ersetzt aber nicht die Bewertung. Analysten müssen klären, ob die Aktivitäten zusammengehören, welche Konten und Geräte betroffen sind und ob bereits geschäftliche Auswirkungen erkennbar sind.
Die Priorität sollte sich deshalb nicht allein an der technischen Schwere orientieren. Ein mittlerer Alarm auf dem Gerät eines globalen Administrators kann dringlicher sein als ein hoher Alarm auf einem isolierten Testsystem. Kritikalität entsteht aus Signal, Identität, Gerät, Daten und Geschäftskontext.
Automatisierung braucht vorher definierte Grenzen
Automated Investigation and Response kann Beweise analysieren und je nach Konfiguration Maßnahmen automatisch oder nach Freigabe ausführen. Beispiele sind das Isolieren eines Geräts, das Stoppen eines Prozesses, das Quarantänisieren einer Datei oder das Blockieren einer URL.
Die richtige Automatisierungsstufe hängt von Geräteklassen und Betriebsrisiken ab. Für Standardarbeitsplätze kann eine automatische Reaktion sinnvoll sein. Ein Produktionsrechner, ein medizinisches Spezialgerät oder ein System mit zeitkritischer Steuerungsfunktion benötigt möglicherweise eine andere Freigabelogik.
E-Mail, Identität und Endpunkt gehören in dasselbe Lagebild
Bei einem verdächtigen Link reicht es nicht, nur die ursprüngliche Nachricht zu löschen. Es muss geprüft werden, wer die Nachricht erhalten und geöffnet hat, welche Anmeldungen danach erfolgten und ob auf dem Endgerät weitere Aktivitäten sichtbar sind.
- Welche Empfänger haben die Nachricht erhalten oder weitergeleitet?
- Wurde ein Link angeklickt oder ein Anhang geöffnet?
- Gab es anschließend ungewöhnliche Anmeldungen oder neue Sitzungen?
- Sind Postfachregeln, Weiterleitungen oder App-Zustimmungen verändert worden?
- Zeigt das Endgerät verdächtige Prozesse, Dateien oder Netzwerkverbindungen?
- Wurden dieselben Indikatoren bei weiteren Benutzern gefunden?
Diese Fragen zeigen den eigentlichen Vorteil von XDR: Nicht mehr jedes Team untersucht sein eigenes Produkt isoliert. Der Vorfall wird als durchgängige Angriffskette betrachtet.
Advanced Hunting ist mehr als eine Expertensuche
Advanced Hunting ermöglicht Abfragen über Sicherheitsdaten, um bekannte Indikatoren zu suchen, Hypothesen zu prüfen oder wiederkehrende Muster zu erkennen. Der größte Nutzen entsteht, wenn erfolgreiche Abfragen dokumentiert und wiederverwendbar gemacht werden.
Aus einer einmaligen Untersuchung kann so eine Erkennungsregel, ein Bericht oder ein standardisierter Prüfschritt werden. Sicherheitsarbeit wird nicht nur reaktiv, sondern verbessert sich nach jedem Vorfall.
Der Action Center braucht klare Verantwortung
Automatisierte Untersuchungen können Maßnahmen vorschlagen oder ausführen. Offene Aktionen dürfen nicht zwischen Betrieb und Security liegen bleiben. Es sollte feststehen, wer den Action Center prüft, wer Freigaben erteilt und wie abgelehnte Maßnahmen dokumentiert werden.
Auch Rückfragen an Fachbereiche gehören in den Prozess. Eine scheinbar ungewöhnliche PowerShell-Aktivität kann Teil eines genehmigten Administrationsvorgangs sein. Umgekehrt kann ein technisch unspektakulärer Login geschäftlich hochkritisch sein. Kontext entscheidet.
Ein Incident-Runbook muss vor dem Ernstfall existieren
- Vorfall triagieren und geschäftliche Kritikalität bestimmen.
- Betroffene Konten, Geräte, Nachrichten, Anwendungen und Dateien abgrenzen.
- Sofortmaßnahmen nach vorab vereinbarten Entscheidungskriterien ausführen.
- Beweise und Zeitachse sichern.
- Zugangsdaten, Sitzungen, App-Berechtigungen und Weiterleitungen kontrollieren.
- Eradikation und Wiederherstellung mit Betrieb und Fachbereich abstimmen.
- Erkenntnisse in Richtlinien, Erkennungen und Schulungen zurückführen.
Kennzahlen dürfen nicht nur Aktivität messen
Die Zahl geschlossener Warnungen sagt wenig über die Qualität des Sicherheitsbetriebs aus. Aussagekräftiger sind beispielsweise die Zeit bis zur Erkennung, die Zeit bis zur Eindämmung, wiederkehrende Ursachen, unbearbeitete hochkritische Vorfälle und der Anteil von Maßnahmen, die innerhalb der vereinbarten Frist umgesetzt wurden.
Ebenso wichtig ist die Datenabdeckung. Geräte, die nicht onboarded sind, Identitäten ohne ausreichende Protokollierung oder Benutzer außerhalb definierter Schutzrichtlinien erzeugen blinde Flecken. Ein ruhiges Portal kann Sicherheit bedeuten – oder fehlende Sichtbarkeit.
Der CloudLights-Grundsatz: Erkennen, entscheiden, lernen
Microsoft Defender XDR ist dann stark, wenn Technik und Prozess zusammenpassen. Korrelation, Automatisierung und Hunting liefern Werkzeuge. Eine belastbare Reaktion entsteht erst durch Rollen, Runbooks, Geschäftskontext und regelmäßiges Üben.
Das Ziel ist kein alarmfreies Dashboard. Das Ziel ist ein Sicherheitsbetrieb, der relevante Signale erkennt, angemessen reagiert und aus jedem Vorfall ein Stück besser wird.
Weiterführende Microsoft-Quellen
- Automated Investigation and Response in Microsoft Defender XDR
- Incidents in Microsoft Defender XDR untersuchen und bearbeiten
- Advanced Hunting in Microsoft Defender XDR
- Action Center in Microsoft Defender XDR
Mit Unterstützung von KI erzeugt.
