Snelle samenvatting
In Microsoft 365-omgevingen kunnen incomplete logging en verspreide admin records de effectiviteit van Managed Detection and Response (MDR) aanzienlijk verminderen. Dit artikel biedt een checklist voor het beoordelen van de MDR-readiness, met aandacht voor cruciale configuraties en licentievereisten.
- Incomplete logging belemmert de reconstructie van incidenten, waardoor de oorsprong en omvang van een aanval onduidelijk blijven.
- Verspreide admin records vertragen de respons tijdens incidenten, wat de kans op dataverlies vergroot.
- Unified Audit Log moet geactiveerd zijn om centrale zichtbaarheid over Exchange, SharePoint, OneDrive en Teams te waarborgen.
- Mailbox-auditing moet correct geconfigureerd zijn om zichtbaarheid in gedeelde mailboxen en admin-acties te garanderen.
- Microsoft 365 Business Premium of hoger is vereist voor toegang tot geavanceerde beveiligingslogs, wat de zichtbaarheid en effectiviteit van MDR beïnvloedt.
- Periodieke validatie van logconfiguraties is essentieel om te voorkomen dat monitoring op verouderde gegevens draait.
Waarom onvolledige logging een risico vormt voor MDR in Microsoft 365
Ontbrekende logging breekt de incidentlijn precies op het moment dat MDR historische context nodig heeft. In een Microsoft 365-omgeving betekent dat niet alleen minder zicht op wat er is gebeurd, maar ook dat tijdens een incident niet meer is vast te stellen waar het begon. Als de eerste besmette gebruiker of handeling niet terug te vinden is, blijft de opschoning onvolledig en kan dezelfde omgeving na herstel opnieuw worden geraakt.
Die beperking werkt direct door in de kwaliteit van incidentrespons. MDR draait niet alleen om het zien van een signaal, maar ook om het reconstrueren van de volgorde erachter. Zodra loggegevens ontbreken, valt die reconstructie uiteen: gebeurtenissen zijn niet meer aan elkaar te koppelen en de herkomst van het incident blijft onduidelijk. Dat raakt ook de onderbouwing richting compliance, omdat een organisatie dan minder hard kan maken wat er is gebeurd, wanneer dat gebeurde en welke sporen nog beschikbaar zijn.
Verspreide admin-records veroorzaken een ander, maar net zo praktisch probleem. Als beheergegevens, inloggegevens of admin-informatie niet op één plek beschikbaar zijn, ontstaat vertraging op het moment dat snel handelen nodig is. Tijdens een incident moet eerst worden uitgezocht wie toegang heeft, waar de juiste gegevens staan en welke administratie nog actueel is. Die extra zoektijd vergroot de periode waarin een aanvaller actief kan blijven en verhoogt de kans dat gevoelige bedrijfsdata worden buitgemaakt.
De frictie zit daarbij niet alleen in techniek, maar ook in dagelijkse beheerpraktijk. Admin-wachtwoorden die in losse bestanden of gedeelde notities rondzwerven, maken respons trager en onduidelijker. Een monitoringdienst kan dan wel signalen oppakken, maar de opvolging stokt zodra toegang, eigenaarschap en administratie niet direct kloppen. In zo’n situatie wordt MDR beoordeeld op detectie, terwijl het echte verlies ontstaat in de fase erna: te weinig context om patient zero te vinden en te veel vertraging om snel in te grijpen, met herinfectie of exfiltratie van gevoelige bedrijfsdata als concrete uitkomst.
Essentiële voorwaarden voor effectieve MDR in Microsoft 365
Audit Logging dat niet expliciet is ingeschakeld in Microsoft Purview laat direct een gat vallen in wat een MDR-dienst überhaupt kan zien. Voor oudere Microsoft 365-tenants staat die logging niet altijd standaard aan. Daardoor begint monitoring niet met een volledig beeld, maar met ontbrekende gebeurtenissen. In de praktijk betekent dat dat centrale analyse van activiteiten uit Exchange, SharePoint, OneDrive en Teams pas werkt nadat Unified Audit Log daadwerkelijk is geactiveerd voor externe MDR-ingestie.
Unified Audit Log is daarmee geen extra laag bovenop bestaande monitoring, maar de basis waarop zichtbaarheid uit meerdere Microsoft 365-diensten samenkomt. De configuratievolgorde maakt hier verschil: als de activatie uitblijft, vinden er wel gebruikers- en beheeracties plaats, maar die komen niet centraal beschikbaar voor MDR. Dat geeft een scheef beeld tijdens onderzoek, omdat gebeurtenissen verspreid blijven over losse diensten in plaats van als één auditstroom beschikbaar te zijn. Voor een middelgrote organisatie die monitoring inkoopt, verschuift het gesprek dan al snel van detectie naar de vraag welke gegevens überhaupt aanwezig zijn.
Mailbox-auditing vormt een tweede grens in die zichtbaarheid. Gedeelde mailboxen en admin-acties vallen alleen goed te volgen als mailbox-auditing op individueel niveau correct is geconfigureerd. Juist daar ontstaat vaak verwarring tijdens onboarding: monitoring is besteld, maar toegangshandelingen of beheeracties rond mailboxen blijken niet volledig traceerbaar. Dan ontstaat geen technisch defect in de MDR-dienst zelf, maar een tekort in de onderliggende gegevens waarop detectie en onderzoek steunen.
Ook de licentiestructuur bepaalt of de benodigde beveiligingslogs beschikbaar komen. Voor geavanceerde beveiligingslogs is Microsoft 365 Business Premium of hoger vereist. Dat maakt MDR-readiness niet alleen een configuratievraag, maar ook een afbakening van wat binnen de huidige Microsoft 365-omgeving zichtbaar kan worden gemaakt. Als die licentielaag ontbreekt, blijft een deel van de gewenste logdiepte buiten bereik en verschuift de uitkomst van een monitoringstraject van volledige dekking naar werken met begrensde zichtbaarheid.
Checklist voor MDR-readiness in Microsoft 365
Uitgeschakelde auditregistratie laat gebeurtenissen buiten beeld, waardoor een MDR-dienst wel actief kan zijn maar met onvolledige invoer werkt. Gebruik deze checklist om te beoordelen of de basis in Microsoft 365 voldoende zichtbaar is voor monitoring en opvolging.
- Controleer of Unified Audit Log is geactiveerd. Deze loglaag bundelt gebeurtenissen uit Exchange, SharePoint, OneDrive en Teams in één centrale stroom voor externe MDR-ingestie. In oudere tenants staat Audit Logging niet altijd standaard aan in de Microsoft Purview-omgeving. Daardoor ontstaat een direct verschil tussen wat er in de omgeving gebeurt en wat een MDR-partij daadwerkelijk kan zien.
- Bevestig expliciet dat Audit Logging actief is in oudere Microsoft 365-tenants. Dit is geen administratief detail. Als die instelling nooit is aangezet, ontbreken gebeurtenissen vanaf het begin van de dienstverlening. Dat wordt vaak pas zichtbaar tijdens onboarding, wanneer blijkt dat mailboxtoegang of andere relevante acties niet zijn vastgelegd.
- Beoordeel mailbox-auditing op individueel niveau. Zichtbaarheid in gedeelde mailboxen en admin-acties is alleen gegarandeerd als mailbox-auditing correct per mailbox is geconfigureerd. Zonder die inrichting ontstaat een scheef beeld: de centrale auditlaag is dan wel aanwezig, maar specifieke handelingen in mailboxen blijven buiten het onderzoek.
- Controleer specifiek gedeelde mailboxen en accounts met beheerrechten. Juist daar ontstaat in de praktijk snel onduidelijkheid over wie wat heeft gedaan. Als mailbox-auditing daar niet goed staat, wordt opvolging trager omdat handelingen niet eenduidig terug te leiden zijn naar een account of actie.
- Beoordeel de licentiestructuur voor geavanceerde beveiligingslogs. De effectiviteit van MDR hangt direct samen met de beschikbare licenties. Voor geavanceerde beveiligingslogs is Microsoft 365 Business Premium of hoger vereist. Een dienst kan dus inhoudelijk goed aansluiten, terwijl de onderliggende licenties de benodigde zichtbaarheid nog niet ondersteunen.
- Leg vast waar admin-records en beheergegevens worden beheerd. Verspreide admin-records creëren vertraging op het moment dat opvolging nodig is. In een omgeving waar logging al beperkt is, vergroot die versnippering de kans dat onderzoek stagneert omdat niet direct duidelijk is welke beheeractie bij welk account hoort.
- Controleer of de loggingconfiguratie periodiek wordt gevalideerd. MDR-readiness is niet alleen een eenmalige instelling. Als configuraties later wijzigen of onvolledig blijven, verschuift de zichtbaarheid ongemerkt. Dat geeft een vals gevoel van dekking: monitoring draait door, maar de onderliggende registratie is niet meer volledig.
Veelvoorkomende fouten bij het implementeren van MDR in Microsoft 365
Een MDR-traject verliest snel scherpte zodra de log-configuratie na de eerste inrichting niet meer wordt gecontroleerd.
- 'Set and Forget' bij MDR: Deze fout ontstaat wanneer MDR wel wordt geactiveerd, maar de onderliggende log-configuratie daarna buiten beeld raakt. In de praktijk schuift dat vaak weg tussen beheer, onboarding en dagelijkse drukte. Het gevolg is niet alleen dat instellingen verouderen of onvolledig blijven, maar ook dat de monitoring werkt op een basis die niet meer aansluit op de werkelijke Microsoft 365-omgeving. Daardoor kunnen relevante gebeurtenissen buiten de registratie vallen, terwijl het MDR-proces aan de voorkant wel actief lijkt.
- Periodieke validatie ontbreekt: Bij deze valkuil zit de frictie niet in de aanschaf van MDR, maar in het uitblijven van terugkerende controle. Als die validatie ontbreekt, blijft onduidelijk of alle noodzakelijke gebeurtenissen nog correct worden vastgelegd. Dat maakt de kwaliteit van detectie afhankelijk van aannames in plaats van zichtbare controle. Voor een middelgrote organisatie betekent dat extra onzekerheid tijdens incidentonderzoek, omdat het verschil tussen “MDR is ingericht” en “MDR ziet genoeg” pas zichtbaar wordt zodra er iets onderzocht moet worden.
- Ongecontroleerde admin-accounts zonder MFA: Shadow Admin accounts vormen een tweede veelvoorkomende fout. Het gaat om admin-accounts die niet goed in beeld zijn en zonder MFA blijven bestaan. Daardoor vallen ze buiten het zicht van centrale monitoring. De fout zit hier niet alleen in het account zelf, maar in het gebrek aan samenhang tussen admin-registratie, toegangsbeheer en monitoring. Als zulke accounts actief blijven zonder dat ze centraal worden gevolgd, ontstaat een blinde vlek in een deel van de omgeving waar juist verhoogde rechten aanwezig zijn.
- Verspreide admin-records vertragen respons: De operationele schade wordt groter wanneer admin-gegevens en wachtwoorden verspreid staan, bijvoorbeeld buiten een centraal overzicht. Dan ontstaat tijdens een incident direct vertraging: eerst moet worden uitgezocht welke accounts bestaan, wie er toegang heeft en welke gegevens nog actueel zijn. In combinatie met admin-accounts zonder MFA vergroot dat de kans op ongeautoriseerde toegang en belemmert het de respons op het moment dat snelheid nodig is. MDR kan dan wel signalen oppakken, maar de opvolging wordt afgeremd door onvolledige traceerbaarheid en versnipperde admin-records.
Afwegingen voor het verbeteren van MDR-readiness in Microsoft 365
MDR levert minder op zodra de benodigde beveiligingslogs in Microsoft 365 pas beschikbaar komen na een licentie-upgrade, omdat de zichtbaarheid dan direct afhangt van een terugkerende kostenpost. Die afweging blijft niet beperkt tot een technische voorkeur. Bij middelgrote bedrijven schuift dit door naar budgettering, pakketkeuzes en de vraag of alle accounts binnen dezelfde licentiestructuur vallen. Daardoor ontstaat een praktisch spanningsveld: zonder upgrade blijft de telemetrie beperkt, maar met upgrade nemen de maandelijkse kosten toe. In die situatie wordt MDR geen losstaande dienst, maar een traject waarvan de kwaliteit mede vastzit aan licentieruimte en budgetdiscipline.
De operationele beperking zit niet alleen in toegang tot logs, maar ook in het volhouden van logging en monitoring als doorlopend onderdeel van beheer. Zodra logconfiguratie of retentie niet consequent wordt aangehouden, valt de bruikbaarheid van audit-trails terug op wat op dat moment nog beschikbaar is. Dat werkt door tijdens incidentonderzoek: een gebeurtenis wordt wel opgemerkt, maar de historische context ontbreekt of is te beperkt om de volledige keten te reconstrueren. In omgevingen waar langere bewaartermijnen nodig zijn, levert de standaardretentie van 90 dagen extra druk op, omdat het verschil tussen detectie en bewijs dan niet meer administratief is maar direct merkbaar wordt in onderzoek en verantwoording.
Die twee lijnen versterken elkaar onder echte bedrijfsomstandigheden. Een organisatie kan investeren in hogere Microsoft 365-licenties voor uitgebreidere beveiligingslogs, maar alsnog vastlopen als continue monitoring in de praktijk onvolledig blijft of audit-trails niet lang genoeg beschikbaar zijn. Dan ontstaat een scheve situatie: de maandelijkse kosten stijgen, terwijl de onderzoekskwaliteit achterblijft. Bij een incident betekent dat niet alleen meer onzekerheid over wat er precies is gebeurd, maar ook hogere herstelkosten doordat de volledige omvang van een inbreuk niet kan worden vastgesteld en een volledige systeem-rebuild in beeld komt. Als audit-trails vervolgens niet overlegd kunnen worden tijdens een AVG-onderzoek, blijft de beperking niet technisch maar eindigt die in juridische en financiële sancties door het ontbreken van die audit-trails.