In vielen Tenants, die ich mir ansehe, nimmt man die Incident-Response-Vorbereitung erst nach einem echten Sicherheitsvorfall ernst. Dann fehlen plötzlich genau die Logs, die man für die Analyse bräuchte. Oder es zeigt sich, dass grundlegende Abläufe wie Break-Glass-Zugänge oder Kontaktlisten nie ernsthaft getestet wurden. Dabei hängt jede Reaktion auf Sicherheitsvorfälle in Microsoft 365 und Azure an dieser Vorbereitung, von der Log-Aufbewahrung über die Mailbox-Forensik bis zu konkreten Notfallprozeduren.
Viele Protokolle verschwinden nach 30 bis 180 Tagen automatisch
Wie schnell wichtige Protokolle automatisch gelöscht werden, wenn man sie nicht gezielt weiterleitet oder die Aufbewahrung verlängert, wird häufig unterschätzt. Die Anmelde- und Auditprotokolle von Entra ID sind mit P1/P2-Lizenz standardmäßig nur 30 Tage im Portal einsehbar. Bemerkt man einen Angriff erst spät, ist das zu wenig. Das Microsoft 365 Unified Audit Log hält Daten immerhin 180 Tage vor, doch auch das genügt bei gezielten Angriffen oder spät entdeckten Vorfällen oft nicht. Noch knapper bemessen sind die Advanced-Hunting-Daten in Defender XDR, wo je nach Lizenz und Workload meist nur die letzten 30 Tage zur Verfügung stehen. Für Exchange-Postfächer ist Mailbox Audit inzwischen standardmäßig aktiviert. Den entscheidenden MailItemsAccessed-Eintrag kann man allerdings nur mit passender Lizenz und für einen begrenzten Zeitraum abrufen. Ausführlich habe ich das im Beitrag Purview Audit MailItemsAccessed: Einblick nach Storm-0558 beschrieben.
Praxis-Tipp: Verlasst euch nicht auf die Standardwerte. Prüft regelmäßig, welche Protokolle ihr tatsächlich braucht und ob eure Aufbewahrungsfristen zur IR-Strategie passen. Richtet Warnungen ein, bevor wichtige Daten gelöscht werden.
Gute Übersichten zu den Aufbewahrungsrichtlinien stellt Microsoft selbst bereit, etwa im M365 Audit Log Retention Guide und für Entra ID unter Reference Reports Data Retention.
Wichtige Logs gehören in Log Analytics oder Microsoft Sentinel
Wer Incident Response ernst nimmt, leitet wichtige Logs automatisiert an einen zentralen Speicher weiter, in der Regel Log Analytics oder Microsoft Sentinel. Für die Sign-in- und Audit-Logs von Entra ID gibt es dafür im Entra-Portal eine eigene Diagnoseeinstellung (Diagnostic Setting) unter Überwachung → Diagnostische Einstellungen. Von dort schickt man die Logs gezielt an einen Log-Analytics-Workspace. So bleiben sie über die Standardaufbewahrung hinaus erhalten und lassen sich mit KQL auswerten. Auch das Unified Audit Log und Defender XDR bieten Exportmöglichkeiten. Gerade bei Defender und Mailbox Audit setzt das aber die passende Lizenzierung voraus, also E5 oder entsprechende Add-ons.
Das folgende Diagramm zeigt, wie die wichtigsten Protokollquellen typischerweise in eine Logging-Architektur fließen, mit der sich Incident Response sinnvoll betreiben lässt:
flowchart TD
EntraLogs["Entra Logs"] --> LogAnalytics["Log Analytics"]
AuditLog["M365 Audit Log"] --> LogAnalytics
DefenderLogs["Defender XDR Logs"] --> LogAnalytics
MailboxAudit["Mailbox Audit"] --> LogAnalytics
LogAnalytics --> Sentinel["Microsoft Sentinel"]
Abbildung: Typische Weiterleitung und zentrale Sammlung von Logs für Incident Response in Microsoft 365 und Azure.
Mit KQL lässt sich dann etwa in Microsoft Sentinel oder direkt im Log-Analytics-Workspace nach verdächtigen Anmeldungen oder möglichem Token-Diebstahl suchen.
Ohne funktionierende Notfallkonten und Kontaktwege hilft die beste Technik wenig
Neben der technischen Vorbereitung steht die organisatorische. Bei einer Kontoübernahme etwa müssen die Break-Glass-Konten tatsächlich funktionieren. Außerdem braucht es einen aktuellen Kontaktbaum mit Notfallnummern und idealerweise einen Incident-Response-Retainer mit einem spezialisierten Dienstleister. Break-Glass-Konten sind zwar meist eingerichtet, werden aber selten regelmäßig getestet, oder MFA bzw. Conditional Access sperrt sie aus. Dagegen hilft nur eine echte, dokumentierte Notfallübung (Fire Drill) pro Jahr.
Die Kontaktliste muss auch außerhalb der Arbeitszeiten taugen. Neben dem eigenen IT-Team gehören Notfallkontakte für den Microsoft Support hinein, gegebenenfalls externe IR-Partner sowie die Verantwortlichen aus Datenschutz und Geschäftsleitung. Für die Zusammenarbeit mit Microsoft rate ich dazu, den Prozess schon vor einem Vorfall zu kennen. Ablauf und Rollen beschreibt Microsoft in seiner Incident Response Overview.
Eine Tabletop-Übung deckt Lücken auf, bevor ein Angreifer es tut
In den letzten Monaten haben immer mehr Unternehmen Tabletop-Übungen zur Incident Response in Microsoft 365 durchgeführt, und fast jedes Mal sind dabei unerwartete Lücken aufgefallen. Ich halte es für unverzichtbar, mindestens einmal im Jahr mit allen relevanten Beteiligten einen realistischen Angriff durchzuspielen. Folgende Punkte sollten dabei unter anderem vorkommen:
- Ein kompromittiertes Entra-Konto mit privilegierten Rechten
- Für Break-Glass- oder Recovery-Konten steht keine Multi-Faktor-Authentifizierung zur Verfügung
- Logs aus dem Audit Log und Defender XDR werden gebraucht, reichen aber nicht weit genug zurück
- Die Kommunikationswege sind gestört (z. B. lässt sich Teams nicht nutzen)
- Der Microsoft Support muss eingeschaltet bzw. eine Eskalation angestoßen werden
In solchen Übungen zeigt sich schnell, ob die IR-Playbooks auch ohne die gewohnte Infrastruktur tragen und ob jeder weiß, was er zu tun hat.
Gute Vorbereitung verkürzt die Reaktionszeit im Ernstfall deutlich
Wer glaubt, Incident-Response-Vorbereitung sei etwas für Konzerne oder besonders kritische Branchen, liegt falsch. In der Cloud kommt es auf die Reaktionszeit an. Und die hängt unmittelbar davon ab, ob Logs verfügbar und Kontakte erreichbar sind und ob technische wie organisatorische Maßnahmen regelmäßig geübt werden. Ich habe schon zu oft miterlebt, wie viel Zeit und Nerven fehlende Logs, ungetestete Break-Glass-Zugänge oder unklare Rollen kosten. Wer die Grundlagen wie Log-Aufbewahrung, automatische Weiterleitung und Playbooks sauber aufsetzt, hat im Ernstfall einen klaren Vorsprung und kann deutlich früher wieder durchatmen.


