M365-zichtbaarheid vrijspelen: waarom standaard SIEM-connectors je blind laten

By Mirko Peters · 2026-08-11

Welkom terug op de blog! Als je de beveiligingsoperaties beheert voor een organisatie die Microsoft 365 gebruikt, heb je waarschijnlijk een vals gevoel van veiligheid. Je klikte op "en…

Automatically translated with AI from the original post. Read the English original

Welkom terug op de blog! Als je beveiligingsoperaties beheert voor een organisatie die Microsoft 365 gebruikt, heb je waarschijnlijk een vals gevoel van veiligheid. Je hebt op "inschakelen" geklikt bij de standaard M365-connector van je SIEM, gecontroleerd of de logs binnenkomen en het vinkje voor compliance gezet. Maar ben je echt beschermd? De ongemakkelijke waarheid is dat standaard SIEM-connectors vaak enorme blinde vlekken laten, en juist de geavanceerde cloudworkloads volledig missen waar moderne aanvallers graag actief zijn. Om dit belangrijke onderwerp grondig uit te diepen, kun je onze bijbehorende podcastaflevering beluisteren, Send Critical Microsoft 365 Logs to Your SIEM, waarin we deze hiaten in detail bespreken.

In dit artikel duiken we diep in waarom je standaardconfiguraties tekortschieten, waar de verborgen blinde vlekken zich bevinden en hoe je een robuuste, kosteneffectieve ingestiepijplijn bouwt die detecties oplevert met een hoge signaalwaarde die je analisten daadwerkelijk kunnen gebruiken.

De blinde vlekken van Microsoft 365 bij populaire SIEM's

Of je nu Microsoft Sentinel, Splunk of QRadar gebruikt, de standaard ingestiesjablonen richten zich meestal op basale Azure Active Directory-aanmeldingen en eenvoudige Office 365-activiteitenlogs. Dat dekt de allereerste basis, maar laat kritieke workloads volledig onbeschermd. Bij populaire SIEM-platforms duiken er een aantal grote blinde vlekken consequent op:

• Exchange: Standaardconnectors missen vaak toegang tot postvakken door anderen dan de eigenaar, het aanmaken van verdachte regels en doorstuurregels, SendAs- of SendOnBehalf-activiteiten en plotselinge wijzigingen in machtigingen op postvakken.
• SharePoint en OneDrive: Je ziet misschien bestandsdownloads, maar zie je ook het aanmaken en gebruiken van externe en anonieme links, het opnieuw delen van bestanden en wijzigingen in machtigingen op sitelevel voor bevoegde gebruikers?
• Teams: Aanvallers werken graag in het open. Standaardconfiguraties leggen zelden externe delingen via SharePoint-gebaseerde kanalen vast, evenmin als berichten die worden verwijderd of bewerkt, wijzigingen in vergaderbeleid of ongeautoriseerd sideloaden van apps.
• Power Platform: De opkomst van low-code- en no-code-omgevingen brengt verborgen risico's met zich mee. Pieken in het aanmaken van flows en apps, riskant gebruik van connectors (zoals Outlook, Teams of willekeurige HTTP-connectors) en omzeilingen van Data Loss Prevention (DLP)-beleid worden vaak weggelaten.
• Vertrouwelijkheid en DLP: Het toepassen en verwijderen van labels, beleidstreffers en handmatige overrides ontbreken vaak volledig, tenzij ze expliciet worden ingesteld.
• Azure AD-context: Cruciale context over risicovolle aanmeldingen, resultaten van voorwaardelijke toegang en afwijkingen in apparaten of locaties wordt in standaardquery's vaak weggelaten.

Grondoorzaken: waarom je kritieke gebeurtenissen mist

Waarom ontbreken deze kritieke telemetriestromen? Dat gebeurt zelden per ongeluk; het is eerder het resultaat van architecturale en commerciële keuzes van zowel platformleveranciers als afnemers in het bedrijfsleven.

Ten eerste spelen licentievoorwaarden een grote rol. Geavanceerde auditing, gedetailleerde Exchange-telemetrie en uitgebreide SharePoint-gebeurtenislogging zitten vaak achter licenties van een hoger niveau, zoals Microsoft 365 E5, of achter add-ons voor Advanced Audit. Als je tenant op het E3-niveau zit, worden die gebeurtenissen simpelweg niet eens gegenereerd of bewaard.

Ten tweede beperken de reikwijdtes van connectors het verzamelen van gegevens. Standaardconnectors halen meestal alleen de basis-"OfficeActivity"-streams op en negeren geavanceerde workloads. Ten derde kunnen beperkingen op de API-doorvoer en batchvertragingen native collectors overbelasten tijdens piekuren, waardoor logs verloren gaan. Ten vierde betekent een gebrek aan parsers dat zelfs als de ruwe JSON-blobs in je SIEM aankomen, niet-gemapte velden en stille schemawijzigingen ze onleesbaar maken. Tot slot worden kostenmaatregelen van budgetbewuste teams soms stilletjes ingezet om luidruchtige categorieën uit te sluiten, zonder dat men de beveiligingsimplicaties begrijpt.

Kosten beheersen zonder blind te worden

Een van de grootste bezwaren tegen het inlezen van "volledige" Microsoft 365-zichtbaarheid zijn de kosten. Het inlezen van elke log die een grote M365-tenant genereert, kan je beveiligingsopslagbudget opeisen. Je hoeft echter niet te kiezen tussen failliet gaan en blind blijven. Je moet slim filteren, niet minder.

Begin met filteren aan de bron. Configureer je ingestiemechanismen zodat alleen operaties met veel signaalwaarde worden opgenomen, zoals New-InboxRule, Add-MailboxPermission, of gebeurtenissen rond het aanmaken en gebruiken van anonieme links. Ontdubbel en bundel gesprekkige, weinig waardevolle gebeurtenissen, zoals achtergrondopslagen van SharePoint-versies, voordat ze je SIEM bereiken.

Implementeer gelaagde opslagstrategieën. Houd hot storage kort (30 tot 60 dagen) voor actieve onderzoeken, en stuur cold- of archiefopslag naar goedkopere object stores om aan de compliancetermijnen te voldoen. Modelleer bovendien je volume voordat je nieuwe streams inschakelt. Maak een prognose van gigabytes per dag per bron en verdubbel die schattingen om rekening te houden met zakelijke pieken, kwartaalauditperiodes of juridische discovery-periodes.

Een veerkrachtige ingestiepipeline ontwerpen

Vertrouwen op kwetsbare, rechtstreekse polling-connectors is een recept voor gemiste waarschuwingen tijdens stressvolle beveiligingsincidenten. Ontwerp daarom een veerkrachtige pipeline die rekening houdt met throttling. Een robuust patroon ziet er als volgt uit:

• Bron: Haal gegevens op uit het M365 Unified Audit Log, Advanced Audit, Azure AD-aanmeldingen en risicologs, Microsoft Information Protection (MIP), DLP-waarschuwingen en Microsoft Defender-beveiligingswaarschuwingen.
• Transport: Stuur gegevens van de Graph- of Management API naar Azure Event Hub (dat dient als buffer en mechanisme om gegevens opnieuw af te spelen) voordat ze naar je SIEM worden doorgestuurd.
• Verwerking: Normaliseer en verrijk gegevens al in de landingszone, en voeg gebruikerscontext, afdelingsvlaggen, VIP-aanduidingen, apparaatstatussen en geografische gegevens toe.
• Governance: Implementeer dagelijkse volledigheidscontroles, backoff-handlers voor 429-ratelimieten, monitoring op schemawijzigingen en waarschuwingen voor dead-letter queues.

Normalisatie en verrijking voor analistklare gegevens

Ruwe M365-logs zijn berucht rommelig, vol geneste JSON-objecten en inconsistente veldnamen over de verschillende workloads heen. Als je een Tier 1-analist ruwe gegevens geeft, besteedt die de helft van de dienst aan het ontcijferen van payloads in plaats van het triageren van dreigingen.

Vlak belangrijke velden af op het moment van ingestie: Actor, Target, Action, ResourcePath, LinkType (anoniem, organisatie of specifieke personen), ExternalRecipient en LabelName. Koppel deze velden aan een uniform schema, zoals het Azure Monitor Common Security Incident Model (ASIM) of het Elastic Common Schema (ECS), zodat je detectie-engineering alle workloads naadloos overspant. Verrijk ten slotte deze gebeurtenissen met HR-gegevens (functie, dienstverband, afdeling), VIP-lijsten, lijsten met toegestane partners, compliancestatussen van apparaten en vertrouwelijkheidsclassificaties.

Detecties met veel signaalwaarde die je nu moet inrichten

Zodra je pipeline draait en je gegevens zijn genormaliseerd, kun je detecties met veel signaalwaarde inrichten die geavanceerd aanvallersgedrag daadwerkelijk opsporen. Dit zijn acht fundamentele detecties die je meteen moet opzetten:

• Mailbox-exfiltratie: Detecteer een nieuwe inbox-regel die extern doorstuurt of berichten naar RSS/Ongewenste e-mail verplaatst, binnen één uur na een aanmelding vanaf een nieuwe geografische locatie of een onbekend apparaat.
• Stealth Access: Markeer toegang tot een VIP-account in een mailbox door iemand die niet de eigenaar is, wanneer er in de voorafgaande 24 uur een Add-MailboxPermission-gebeurtenis heeft plaatsgevonden.
• SharePoint Spill: Waarschuw bij anonieme of "specifieke personen"-deellinks die zijn aangemaakt op bestanden met het label Confidential of Restricted.
• Link Abuse: Detecteer een groot aantal externe downloads binnen een venster van 15 minuten, afkomstig van een pas aangemaakte deellink, vanaf een nieuw IP-adres of ASN.
• Teams Pivot: Signaleer scenario's waarin een bestand extern wordt gedeeld en dezelfde gebruiker binnen twee uur een externe gast aan het Team toevoegt.
• Power Automate Abuse: Markeer een plotselinge piek van drie of meer dagelijkse flow-aanmaken door een niet-ontwikkelaarsaccount, met name met gebruik van de HTTP- of Outlook-connectors.
• Privilege Creep: Houd herhaalde toevoegingen en verwijderingen van lid- of beheerdersrollen op dezelfde gevoelige werkruimte of site bij binnen een venster van 24 uur.
• Stale Truth: Detecteer wanneer datasets met managementinformatie of financiële content gedurende twee of meer cycli niet worden ververst, zodat leiders geen beslissingen nemen op basis van verouderde gegevens.

Je implementatieplan van 30 dagen om de kloof te dichten

Het verbeteren van je zichtbaarheid binnen M365 hoeft niet een jaar te duren. Je kunt je zichtbaarheidskloven in slechts 30 dagen systematisch dichten:

• Week 1: Schakel Advanced Audit waar nodig in, inventariseer je huidige SIEM-connectors en breng de ontbrekende gebeurteniscategorieën in kaart.
• Week 2: Richt je Event Hub-pipeline in. Stuur Unified Audit Logs, Advanced Audit, Azure AD- en Defender-telemetrie erheen en pas je filters aan de bron toe.
• Week 3: Normaliseer en verrijk je datastromen, vul de logs van de afgelopen 30 dagen aan voor kritieke logs, en rol de zeven hoogwaardige detecties uit die hierboven zijn genoemd, met de juiste onderdrukkingsvensters.
• Week 4: Verlaag je kosten door de overgebleven ruis weg te filteren en de bewaarlagen aan te passen. Voeg monitors voor volledigheid toe en voer een purple-team-tafeloefening uit waarbij je regels voor mailboxen, externe delen en pieken in flows test.

Belangrijkste KPI's om te bewijzen dat het werkte

Wanneer het management vraagt of het beveiligingsbudget dat aan pipeline-verbeteringen is besteed de moeite waard was, heb je metrics nodig om je succes aan te tonen. Volg deze KPI's voor het management:

• Dekking: Percentage van de beoogde M365-gebeurtenisfamilies die succesvol zijn ingelezen en geparsed (doel 95% of hoger).
• Snelheid: Mean Time to Acknowledge (MTTA) en Mean Time to Resolve (MTTR) voor M365-gerelateerde incidenten (dalende trend).
• Ruis: Verhouding tussen waarschuwingen en echte positieven (stijgende trend in signaalkwaliteit).
• Kosten: Kosten per gigabyte aan ingelezen data (dalende trend van ongeveer 40% dankzij filtering aan de bron).
• Betrouwbaarheid: Aantal dagen met gaten in de inlezing (doel: nul) en SLA's voor schemawijzigingen (parser-updates binnen zeven dagen na een schemawijziging door Microsoft).

Veelvoorkomende valkuilen en hoe je ze oplost

Zelfs de beste plannen lopen soms vast. Let op deze veelvoorkomende valkuilen:

Teams zeggen vaak: "We hebben het ingeschakeld", maar de logs verschijnen nooit, omdat de Advanced Audit-licenties of de basisinstellingen voor mailboxauditing nooit goed zijn gecontroleerd. Een ander veelvoorkomend probleem is dat SIEM-regels tijdens aanvallen volledig stil blijven omdat ze gebeurtenissen los van elkaar beoordelen in plaats van het aanmaken van regels, geografische verschuivingen en externe deling met elkaar te correleren.

Kostenexplosies ontstaan wanneer voorfilters worden overgeslagen. Filter lawaaierige bewerkingen altijd vooraf en sluit achtergrondsynchronisatie-gebeurtenissen uit. Parser-rot is een andere stille killer; richt een maandelijkse routine voor schemavergelijking in en voer unit tests uit op voorbeeldpayloads. Ten slotte treedt analistenmoeheid snel op als waarschuwingen geen context bevatten. Zorg er daarom altijd voor dat je waarschuwingen aangeven wie, wat, waar en welke vertrouwelijkheidslabels er betrokken zijn, inclusief directe links naar het Microsoft Compliance Center voor diepgaand onderzoek.

Conclusie: stop met vertrouwen op compliance voor bescherming

De kern is simpel: standaard SIEM-connectors houden je compliant, maar ze houden je niet beschermd. Door de juiste Microsoft 365-logs op te halen, ze te normaliseren naar een uniform schema, ze te verrijken met belangrijke bedrijfscontext en te jagen met detecties die zijn afgestemd op echt aanvallersgedrag, elimineer je je blinde vlekken volledig. Zo gaat je SIEM niet langer het verhaal missen, maar begint het het zelf te schrijven. Wil je deze strategie nog verder verdiepen? Luister dan naar de volledige aflevering via Send Critical Microsoft 365 Logs to Your SIEM en begin vandaag nog met het dichten van je zichtbaarheidsgaten!