Microsoft-365-Sichtbarkeit freischalten: Warum Standard-SIEM-Connectoren Sie blind machen

Von Mirko Peters · 2026-08-11

Willkommen zurück im Blog! Wenn Sie den Sicherheitsbetrieb für eine Organisation verantworten, die Microsoft 365 nutzt, wiegen Sie sich wahrscheinlich in falscher Sicherheit. Sie haben auf „en…

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück im Blog! Wenn Sie für eine Organisation mit Microsoft 365 die Sicherheitsoperationen verantworten, wiegen Sie sich vermutlich in falscher Sicherheit. Sie haben den Standard-M365-Connector Ihres SIEM aktiviert, geprüft, dass Protokolle ankommen, und das Compliance-Kästchen abgehakt. Aber sind Sie tatsächlich geschützt? Die unbequeme Wahrheit ist: Standardmäßige SIEM-Connectoren lassen oft große blinde Flecken, weil sie gerade die modernen Cloud-Workloads nicht erfassen, in denen Angreifer besonders gern agieren. Um dieses wichtige Thema vollständig zu verstehen, hören Sie sich unbedingt unsere begleitende Podcast-Folge Send Critical Microsoft 365 Logs to Your SIEM an, in der wir diese Lücken im Detail aufschlüsseln.

In diesem Beitrag gehen wir ausführlich darauf ein, warum Ihre Standardkonfigurationen versagen, wo sich die verborgenen blinden Flecken befinden und wie Sie eine robuste, kosteneffiziente Ingestion-Pipeline aufbauen, die aussagekräftige Erkennungen liefert, mit denen Ihre Analysten tatsächlich arbeiten können.

Die blinden Flecken von Microsoft 365 in gängigen SIEM-Lösungen

Ob Sie Microsoft Sentinel, Splunk oder QRadar einsetzen: Die Standard-Ingestion-Vorlagen konzentrieren sich in der Regel auf grundlegende Azure-Active-Directory-Anmeldungen und einfache Office-365-Aktivitätsprotokolle. Das deckt zwar die absoluten Grundlagen ab, lässt aber kritische Workloads vollständig ungeschützt. Über gängige SIEM-Plattformen hinweg zeigen sich regelmäßig mehrere große blinde Flecken:

• Exchange: Standard-Connectoren übersehen häufig den Zugriff auf fremde Postfächer, das Anlegen verdächtiger Regeln und Weiterleitungen, SendAs- oder SendOnBehalf-Aktivitäten sowie plötzliche Änderungen von Postfachberechtigungen.
• SharePoint und OneDrive: Sie sehen vielleicht Dateidownloads, aber erkennen Sie auch die Erstellung und Nutzung externer und anonymer Freigabelinks, erneute Freigaben von Dateien oder Änderungen privilegierter Berechtigungen auf Websites?
• Teams: Angreifer arbeiten gern in offenen Kanälen. Standardkonfigurationen erfassen selten die externe Freigabe über SharePoint-gestützte Kanäle, das Löschen und Bearbeiten von Nachrichten, Änderungen an Besprechungsrichtlinien oder das unautorisierte Sideloading von Apps.
• Power Platform: Die Verbreitung von Low-Code- und No-Code-Umgebungen bringt versteckte Risiken mit sich. Sprunghaft steigende Erstellungen von Flows und Apps, riskante Connector-Nutzung (etwa Outlook, Teams oder beliebige HTTP-Connectoren) sowie Umgehungen von Richtlinien für Datenverlust-Prävention (DLP) werden häufig nicht erfasst.
• Vertraulichkeitsbezeichnungen und DLP: Ereignisse zur Anwendung und Entfernung von Vertraulichkeitsbezeichnungen, Richtlinientreffer und manuelle Außerkraftsetzungen fehlen oft vollständig, sofern sie nicht gezielt erfasst werden.
• Azure-AD-Kontext: Wichtige Kontextinformationen zu riskanten Anmeldungen, Ergebnissen bedingter Zugriffe sowie Auffälligkeiten bei Geräten oder Standorten fehlen in Standardabfragen häufig.

Ursachen: Warum Ihnen kritische Ereignisse fehlen

Warum fehlen diese wichtigen Telemetriedatenströme? Das geschieht selten zufällig, sondern ist das Ergebnis architektonischer und kommerzieller Entscheidungen, die Plattformanbieter und Unternehmenskäufer gleichermaßen treffen.

Erstens spielen Lizenzvorgaben eine große Rolle. Erweiterte Überwachung, detaillierte Exchange-Telemetrie und umfassende SharePoint-Ereignisprotokollierung sind häufig Funktionen höherer Lizenzstufen wie Microsoft 365 E5 oder Advanced-Audit-Add-ons. Wenn Ihr Mandant auf der Stufe E3 liegt, werden diese Ereignisse schlicht gar nicht erst erzeugt oder aufbewahrt.

Zweitens beschränkt der Umfang der Connectoren die Datenerfassung. Standard-Connectoren lesen in der Regel nur grundlegende „OfficeActivity“-Datenströme und ignorieren erweiterte Workloads. Drittens können Drosselung der API-Durchsatzrate und Batching-Verzögerungen die nativen Collectors in Spitzenzeiten überlasten, sodass Protokolle verloren gehen. Viertens bedeuten Lücken im Parser, dass selbst dann, wenn die rohen JSON-Daten in Ihrem SIEM ankommen, nicht zugeordnete Felder und unbemerkte Schemaänderungen sie wie unlesbaren Datensalat aussehen lassen. Schließlich schließen Kostenkontrollen, die budgetbewusste Teams einführen, laute Kategorien stillschweigend aus, ohne die sicherheitstechnischen Folgen zu bedenken.

Kosten im Griff behalten, ohne blind zu werden

Einer der größten Einwände gegen die Erfassung „vollständiger“ Microsoft-365-Sichtbarkeit sind die Kosten. Jedes einzelne Protokoll eines großen M365-Mandanten zu erfassen, kann Ihr Sicherheitsspeicher-Budget sprengen. Sie müssen sich jedoch nicht zwischen Insolvenz und Blindheit entscheiden. Sie müssen intelligenter filtern, nicht weniger.

Beginnen Sie mit der Filterung am Anfang der Pipeline. Konfigurieren Sie Ihre Erfassungsmechanismen so, dass nur aussagekräftige Vorgänge erfasst werden, etwa New-InboxRule, Add-MailboxPermission oder Ereignisse zur Erstellung und Nutzung anonymer Freigabelinks. Dedupizieren und aggregieren Sie geschwätzige, wenig aussagekräftige Ereignisse wie Hintergrund-Versionsspeicherungen in SharePoint, bevor sie Ihr SIEM überhaupt erreichen.

Setzen Sie auf gestaffelte Speicherstrategien. Halten Sie den Hot Storage kurz (30 bis 60 Tage) für laufende Untersuchungen und leiten Sie kalte oder archivierte Daten in günstigere Objektspeicher weiter, um Compliance-Fristen abzudecken. Modellieren Sie außerdem Ihr Datenvolumen, bevor Sie neue Datenströme aktivieren. Prognostizieren Sie die Gigabyte pro Tag je Quelle und verdoppeln Sie diese Schätzungen, um geschäftliche Lastspitzen, Quartalsprüfungen oder Zeiträume für Legal Discovery abzufangen.

Entwurf einer belastbaren Ingestion-Pipeline

Auf spröde, direkt abfragende Konnektoren zu setzen, führt in stressigen Sicherheitsvorfällen zwangsläufig zu verpassten Warnmeldungen. Entwerfen Sie stattdessen eine belastbare, drosselungsbewusste Pipeline. Ein bewährtes Muster sieht so aus:

• Quelle: Erfassen Sie Daten aus dem einheitlichen Überwachungsprotokoll von Microsoft 365, dem erweiterten Überwachungsprotokoll, Azure AD-Anmeldungen und Risikoprotokollen, Microsoft Information Protection (MIP), DLP-Warnungen und Microsoft Defender-Sicherheitswarnungen.
• Transport: Leiten Sie Daten aus der Graph- oder Management API über Azure Event Hub weiter, das als Puffer und Wiedergabemechanismus dient, bevor die Daten an Ihr SIEM übergeben werden.
• Verarbeitung: Normalisieren und reichern Sie die Daten direkt in der Landing Zone an, etwa mit Benutzerkontext, Abteilungsmerkmalen, VIP-Kennzeichnungen, Gerätestatus und geografischen Daten.
• Governance: Implementieren Sie tägliche Vollständigkeitsprüfungen, Backoff-Handler für 429-Ratenbegrenzungen, Überwachungen auf Schemaänderungen und Warnmeldungen für Dead-Letter-Queues.

Normalisierung und Anreicherung für analysebereite Daten

Rohe M365-Protokolle sind notorisch unübersichtlich, voller verschachtelter JSON-Objekte und mit uneinheitlichen Feldbenennungen über die Workloads hinweg. Wenn Sie Tier-1-Analysten Rohdaten vorlegen, verbringen sie die halbe Schicht damit, Payloads zu entschlüsseln, statt Bedrohungen zu bewerten.

Flachen Sie zentrale Felder bereits zum Zeitpunkt der Aufnahme ab: Actor, Target, Action, ResourcePath, LinkType (anonymous, organization oder specific people), ExternalRecipient und LabelName. Ordnen Sie diese Felder einem einheitlichen Schema zu, etwa dem Azure Monitor Common Security Incident Model (ASIM) oder dem Elastic Common Schema (ECS), damit Ihre Detection Engineering alle Workloads nahtlos abdeckt. Reichern Sie diese Ereignisse abschließend mit HR-Daten (Rolle, Beschäftigungsart, Abteilung), VIP-Listen, Partner-Allowlists, Gerätekonformitätsstatus und Vertraulichkeitsklassifizierungen an.

Aussagekräftige Erkennungen, die Sie jetzt bereitstellen sollten

Sobald Ihre Pipeline läuft und die Daten normalisiert sind, können Sie aussagekräftige Erkennungen bereitstellen, die tatsächlich raffiniertes Angreiferverhalten aufdecken. Hier sind acht grundlegende Erkennungen, die Sie sofort einrichten sollten:

• Postfach-Exfiltration: Erkennen Sie eine neue Posteingangsregel, die Nachrichten extern weiterleitet oder in RSS- bzw. Junk-Ordner verschiebt, und zwar innerhalb einer Stunde nach einer Anmeldung von einem neuen geografischen Standort oder einem unbekannten Gerät.
• Heimlicher Zugriff: Melden Sie den Zugriff eines Nicht-Eigentümers auf ein Postfach eines VIP-Kontos, wenn in den vorangegangenen 24 Stunden ein Ereignis Add-MailboxPermission aufgetreten ist.
• SharePoint Spill: Lösen Sie einen Alarm aus, wenn für Dateien mit der Bezeichnung „Vertraulich“ oder „Eingeschränkt“ anonyme Freigabelinks oder Links für „bestimmte Personen“ erstellt werden.
• Link Abuse: Erkennen Sie ein hohes Volumen externer Downloads innerhalb von 15 Minuten, die von einem neu erstellten Freigabelink mit einer neuen IP-Adresse oder ASN ausgehen.
• Teams Pivot: Erkennen Sie Szenarien, in denen eine Datei extern geteilt wird und derselbe Benutzer innerhalb von zwei Stunden einen externen Gast zum Team hinzufügt.
• Power Automate-Missbrauch: Melden Sie einen plötzlichen Anstieg von drei oder mehr täglich erstellten Flows durch ein Nicht-Entwicklerkonto, insbesondere unter Verwendung der HTTP- oder Outlook-Konnektoren.
• Privilege Creep: Verfolgen Sie wiederholtes Hinzufügen und Entfernen von Mitglieds- oder Administratorrollen auf demselben sensiblen Arbeitsbereich oder derselben Website innerhalb eines Zeitfensters von 24 Stunden.
• Stale Truth: Erkennen Sie, wenn Datasets mit Führungs- oder Finanzinhalten zwei oder mehr Aktualisierungszyklen lang nicht aktualisiert werden, damit Führungskräfte keine Entscheidungen auf veralteten Daten treffen.

Ihr 30-Tage-Plan zum Schließen der Lücken

Die Sichtbarkeit in Microsoft 365 lässt sich in einem Jahr verbessern, aber Sie müssen nicht so lange warten. Innerhalb von 30 Tagen können Sie Ihre Sichtbarkeitslücken systematisch schließen:

• Woche 1: Aktivieren Sie bei Bedarf das erweiterte Überwachungsprotokoll, erfassen Sie Ihre bestehenden SIEM-Konnektoren und ermitteln Sie die fehlenden Ereigniskategorien.
• Woche 2: Richten Sie Ihre Event-Hub-Pipeline ein. Leiten Sie die Telemetriedaten von Unified Audit Logs, Advanced Audit, Azure AD und Defender weiter und implementieren Sie Ihre vorgelagerten Filter.
• Woche 3: Normalisieren und reichern Sie Ihre Datenströme an, spielen Sie die kritischen Protokolle der letzten 30 Tage nach und stellen Sie die sieben oben genannten aussagekräftigen Erkennungen mit passenden Unterdrückungszeiträumen bereit.
• Woche 4: Optimieren Sie Ihre Kosten, indem Sie verbleibendes Rauschen verwerfen und die Aufbewahrungsstufen anpassen. Ergänzen Sie Vollständigkeitsüberwachungen und führen Sie eine Purple-Team-Tabletop-Übung durch, die Postfachregeln, externe Freigaben und Spitzen bei Flows testet.

Executive-KPIs, um den Erfolg zu belegen

Wenn die Geschäftsleitung fragt, ob sich das Sicherheitsbudget für die Verbesserungen der Pipeline gelohnt hat, brauchen Sie Kennzahlen, die Ihren Erfolg belegen. Verfolgen Sie diese Executive-KPIs:

• Abdeckung: Prozentsatz der angestrebten M365-Ereignisfamilien, die erfolgreich erfasst und geparst werden (Ziel: 95 % oder mehr).
• Geschwindigkeit: Mean Time to Acknowledge (MTTA) und Mean Time to Resolve (MTTR) für M365-bezogene Vorfälle (Tendenz sinkend).
• Rauschen: Verhältnis von Warnungen zu echten Treffern (Tendenz steigend bei der Signalqualität).
• Kosten: Kosten pro aufgenommenem Gigabyte (Tendenz sinkend um etwa 40 % dank vorgelagerter Filterung).
• Zuverlässigkeit: Anzahl der Tage mit Lücken bei der Datenaufnahme (Ziel: null) und SLAs für Schemaänderungen (Parser-Aktualisierungen innerhalb von sieben Tagen nach einer Schemaänderung bei Microsoft).

Typische Stolperfallen und ihre Behebung

Auch die besten Pläne stoßen manchmal auf Hindernisse. Achten Sie auf diese typischen Stolperfallen:

Viele IT-Teams sagen oft: „Wir haben es aktiviert“, doch die Protokolle erscheinen nie, weil Advanced-Audit-Lizenzen oder Basislinien für das Postfachauditing nie ordnungsgemäß geprüft wurden. Ein weiteres häufiges Problem: SIEM-Regeln bleiben bei Angriffen vollständig stumm, weil sie Ereignisse isoliert auswerten, statt Regelerstellungen, geografische Wechsel und externe Freigaben miteinander zu korrelieren.

Kostenexplosionen entstehen, wenn Vorfilter ausgelassen werden. Filtern Sie laute Vorgänge immer vorab und schließen Sie Hintergrund-Synchronisierungsereignisse aus. Parser-Verfall ist ein weiterer stiller Killer; richten Sie daher eine monatliche Schema-Diff-Routine ein und führen Sie Unit-Tests mit Beispiel-Payloads aus. Schließlich ermüden Analysten schnell, wenn Warnungen keinen Kontext haben. Stellen Sie deshalb immer sicher, dass Ihre Warnungen angeben, wer, was, wo und welche Vertraulichkeitsbezeichnungen betroffen sind, und enthalten Sie direkte Links zum Microsoft Compliance Center für die detaillierte Analyse.

Fazit: Compliance allein schützt nicht

Das Fazit ist einfach: Standard-SIEM-Konnektoren halten Sie compliant, aber nicht geschützt. Wenn Sie die richtigen Microsoft-365-Protokolle abrufen, in ein einheitliches Schema normalisieren, mit wichtigem Geschäftskontext anreichern und mit Erkennungen, die auf reales Angreiferverhalten abgestimmt sind, gezielt nach Bedrohungen suchen, können Sie Ihre blinden Flecken vollständig beseitigen. So verpasst Ihr SIEM nicht mehr die Geschichte, sondern schreibt sie selbst. Um tiefer in diese Strategie einzusteigen, hören Sie sich die vollständige Episode unter Send Critical Microsoft 365 Logs to Your SIEM an und beginnen Sie noch heute damit, Ihre Sichtbarkeitslücken zu schließen!