BIO 12.02.01 ISO A.8.7

Microsoft Defender Architecture Design

đź“… 2025-10-30
•
⏱️ 15 minuten lezen
•
đź”´ Must-Have

đź’Ľ Management Samenvatting

De Microsoft Defender XDR-architectuur brengt Defender voor Endpoint, Defender voor Office 365, Defender voor Identity en Defender voor Cloud Apps samen tot één samenhangend beveiligingsplatform dat alle belangrijke aanvalsoppervlakken – identiteiten, e-mail, endpoints, SaaS-applicaties en cloudresources – integraal beschermt. In plaats van losse producten ontstaat een samenhangende beveiligingsarchitectuur waarin signalen worden gekoppeld, risico’s vroegtijdig worden herkend en responsprocessen grotendeels geautomatiseerd kunnen plaatsvinden.

Aanbeveling
IMPLEMENTEER DEFENDER XDR ARCHITECTURE
Risico zonder
Critical
Risk Score
9/10
Implementatie
120u (tech: 80u)
Van toepassing op:
âś“ M365
âś“ Azure
âś“ Endpoints

Een geĂŻntegreerde Defender-architectuur is essentieel voor organisaties in de Nederlandse (semi-)publieke sector die te maken hebben met steeds geavanceerdere dreigingen en strengere eisen vanuit onder andere BIO, ISO 27001 en NIS2. Door signalen uit e-mail, identity, endpoints en cloudapplicaties te correleren, ontstaat Ă©Ă©n uniform beeld van incidenten in plaats van versnipperde meldingen per product. Dit maakt het mogelijk om ketenaanvallen sneller te detecteren, automatisch tegenmaatregelen te laten uitvoeren waar dat verantwoord is, en security-analisten te laten focussen op de meest kritieke dreigingen. Daarnaast biedt een centraal portaal voor Microsoft 365 Defender duidelijke sturing voor het Security Operations Center (SOC), inclusief rapportages richting CISO, CIO en lijnmanagement.

PowerShell Modules Vereist
Primary API: Microsoft Graph / Defender APIs
Connection: Connect-MgGraph
Required Modules: Microsoft.Graph

Implementatie

De Defender XDR-architectuur bestaat uit een aantal kerncomponenten die logisch op elkaar aansluiten: Defender voor Endpoint voor detectie en respons op werkstations en servers; Defender voor Office 365 Plan 2 voor bescherming van e-mail, Teams en andere samenwerkingstools; Defender voor Identity voor het bewaken van on-premises Active Directory-activiteiten; Defender voor Cloud Apps voor inzicht en grip op SaaS- en cloudapplicaties; en integratie met Microsoft Sentinel als centrale SIEM-oplossing. Bovenop deze producten ligt een XDR-laag die signalen verrijkt, correlaties legt en incidenten bundelt. Automated Investigation and Response (AIR) kan vervolgens geautomatiseerde acties uitvoeren, zoals het isoleren van endpoints, het blokkeren van aanmeldingen of het verplaatsen van verdachte e-mail naar quarantaine. Deze architectuur vormt de ruggengraat van een moderne, risico-gebaseerde beveiligingsaanpak binnen de "Nederlandse Baseline voor Veilige Cloud".

Vereisten

  1. Voor een robuuste Defender XDR-architectuur is een passend licentiemodel een eerste, niet te onderschatten voorwaarde. In de meeste overheids- en grotere MKB-omgevingen betekent dit dat Microsoft 365 E5 of een gelijkwaardige combinatie van afzonderlijke Defender-plannen beschikbaar moet zijn. Met M365 E5 worden onder andere Defender voor Office 365 Plan 2, Defender voor Endpoint, Defender voor Identity en Defender voor Cloud Apps gebundeld, waardoor zowel technisch als financieel een samenhangend fundament ontstaat. Voor kleinere organisaties kan Defender for Business een alternatief zijn, mits duidelijk wordt vastgelegd welke functionaliteiten wel en niet beschikbaar zijn ten opzichte van E5. Het is belangrijk dat de CISO, architect en inkoop samen bepalen welke licenties noodzakelijk zijn om de beveiligingsdoelen en complianceverplichtingen te realiseren, en dat deze keuze wordt vastgelegd in architectuurdocumenten en governance-afspraken.
  2. Naast het licentiemodel moeten alle relevante Defender-werkbelastingen daadwerkelijk worden geactiveerd en op een consistente manier worden ingericht. Dit omvat onder meer het uitrollen van de Defender for Endpoint-agenten naar werkstations, servers en (waar mogelijk) mobiele apparaten, het configureren van Defender voor Office 365 beleidsregels voor phishing, spam en bijlagen, het inschakelen van Defender voor Identity sensoren op domeincontrollers en het koppelen van SaaS- en cloudapplicaties aan Defender voor Cloud Apps. Het is niet voldoende om alleen licenties toe te kennen; instellingen moeten worden afgestemd op de risicoanalyse, de classificatie van informatie en de kritikaliteit van systemen. Documenteer hierbij ook uitzonderingen, bijvoorbeeld voor specialistische systemen die (nog) niet volledig kunnen worden geĂŻntegreerd.
  3. Een effectieve Defender XDR-architectuur staat of valt met de beschikbaarheid van een bekwaam security operations team dat de meldingen kan interpreteren en opvolgen. Dit kan een intern SOC zijn, een gezamenlijk SOC binnen een koepelorganisatie, of een externe dienstverlener (Managed Detection and Response). Belangrijk is dat rollen en verantwoordelijkheden helder zijn: wie bewaakt de incidenten, wie mag containment-acties uitvoeren, wie onderhoudt de detectieregels en wie rapporteert aan bestuur en directie? Daarnaast vraagt het werken met Defender XDR om kennis van zowel Microsoft-cloudtechnologieën als van dreigingsanalyse, forensisch onderzoek en incidentrespons. Training, oefening en het periodiek evalueren van het SOC-proces zijn daarom onmisbare vereisten.
  4. Tot slot is integratie met een Security Information and Event Management-oplossing (SIEM), bij voorkeur Microsoft Sentinel, sterk aanbevolen om te voldoen aan de rapportage- en auditvereisten uit onder andere BIO en NIS2. Via deze integratie kunnen Defender-signalen worden verrijkt met loggegevens uit andere bronnen, zoals firewalls, identity providers van derden of applicatielogs. Dit maakt het mogelijk om organisatiebrede detectieregels te definiëren en samenhangende rapportages te genereren voor auditors en toezichthouders. Het is belangrijk om vooraf na te denken over bewaartermijnen, opslaglocaties (bijvoorbeeld binnen de EU), kosten van logopslag en de wijze waarop incidenten uit Sentinel worden teruggekoppeld naar het operationele team. Zo ontstaat een integraal stelsel van detectie, respons en verantwoording.

Implementatie

Gebruik PowerShell-script defender-architecture.ps1 (functie Invoke-Remediation) – Defender architecture deployment.

De implementatie van de Defender XDR-architectuur start met een heldere ontwerpkeuze: welke onderdelen van de organisatie worden in welke volgorde aangesloten, en hoe wordt de overgang van de huidige naar de gewenste situatie beheerst uitgevoerd? Begin met een inventarisatie van alle identiteiten, endpoints, e-mailstromen en cloudapplicaties die binnen scope vallen, inclusief classificatie van gegevens en kritikaliteit van systemen. Op basis hiervan wordt een gefaseerd implementatieplan opgesteld waarin technische implementatiestappen, communicatie naar eindgebruikers en afstemming met beheer- en securityteams zijn opgenomen. Vervolgens worden de verschillende Defender-werkbelastingen geactiveerd en ingericht. Voor Defender voor Endpoint betekent dit het uitrollen van de agenten via bijvoorbeeld Microsoft Intune of Group Policy, het configureren van beveiligingsprofielen en het testen van isolatie- en remediatieacties in een gecontroleerde testomgeving. Voor Defender voor Office 365 worden anti-phishing-, anti-spam- en antimalwarebeleidsregels geconfigureerd, inclusief veilige bijlagen en veilige koppelingen. Hierbij is het belangrijk om een balans te vinden tussen strenge beveiliging en gebruiksvriendelijkheid, bijvoorbeeld door gefaseerd strengere beleidsniveaus te introduceren. Defender voor Identity vereist het plaatsen van sensoren op domeincontrollers en het configureren van netwerkverbindingen zodat verdachte aanmeldpatronen, laterale bewegingen en privilege escalation-pogingen tijdig worden gesignaleerd. Defender voor Cloud Apps wordt ingericht om schaduw-IT in kaart te brengen, risicovolle applicaties te identificeren en beleidsregels af te dwingen voor data-exfiltratie en toegangsbeheer. Tijdens deze configuratiefase is nauwe samenwerking nodig tussen het identityteam, het netwerkteam, het werkplekteam en het securityteam, zodat alle afhankelijkheden worden meegenomen. Wanneer de afzonderlijke werkbelastingen functioneren, wordt de XDR-laag geconfigureerd. Dit omvat het inschakelen van automatische incidentcorrelatie, het instellen van prioriteringsregels en het definiëren van welke geautomatiseerde acties (via Automated Investigation and Response, AIR) direct mogen worden uitgevoerd en welke eerst menselijke goedkeuring vereisen. Organisaties kiezen vaak voor een conservatieve start, waarbij AIR alleen in observeer- of auditmodus draait, om vervolgens stapsgewijs meer acties te automatiseren naarmate het vertrouwen in de detecties toeneemt. Tot slot wordt de integratie met Microsoft Sentinel of een andere SIEM-oplossing opgezet. Dit maakt het mogelijk om de Defender-signalen te combineren met andere logbronnen en om organisatiebrede detectiescenario’s op te bouwen. Gedurende de hele implementatie is het cruciaal om gedetailleerde documentatie bij te houden, waaronder configuratieoverzichten, beslisdocumenten en testresultaten. Deze documentatie ondersteunt niet alleen beheer en doorontwikkeling, maar vormt ook belangrijke audit-evidence voor toezichthouders en interne of externe auditors.

Monitoring

Gebruik PowerShell-script defender-architecture.ps1 (functie Invoke-Monitoring) – Controleren.

Zodra de Defender XDR-architectuur is geïmplementeerd, verschuift de focus naar structurele monitoring en continue verbetering. Het Microsoft 365 Defender-portaal vormt hierbij het primaire werkstation voor het SOC-team. In dit portaal worden incidenten automatisch geclusterd, waardoor een aanvalscampagne niet langer wordt weergegeven als tientallen losse alerts, maar als één samenhangend incident met een duidelijke tijdlijn, betrokken accounts, apparaten, e-mailberichten en cloudactiviteiten. Dit helpt analisten om snel de kern van het probleem te begrijpen en gericht maatregelen te nemen. Naast de incidentweergave biedt het portaal uitgebreide mogelijkheden voor geavanceerde detectie via hunting-query’s. Met behulp van Kusto Query Language (KQL) kunnen securityspecialisten zelf queries opbouwen om verdachte patronen te zoeken, bijvoorbeeld massale aanmeldpogingen vanuit ongewone landen, afwijkend procesgedrag op endpoints of ongebruikelijke downloadvolumes uit SharePoint en OneDrive. Door deze hunting-resultaten te vertalen naar nieuwe detectieregels, groeit de volwassenheid van de monitoringcapaciteit stap voor stap. Het is raadzaam om periodiek jachtcampagnes uit te voeren op basis van actuele dreigingsinformatie (threat intelligence) en lessons learned uit eerdere incidenten. Een ander belangrijk onderdeel van de monitoring is de continue bewaking van de beveiligingsscore (Secure Score) en de aanbevelingen die Defender genereert. Deze aanbevelingen helpen om configuratiegaten te identificeren, bijvoorbeeld ontbrekende MFA voor beheerders, onvoldoende harde configuratie van e-mailbeveiliging of verouderde clients zonder actuele agent. Door deze aanbevelingen structureel op te pakken in een verbeterplan, wordt de beveiligingspositie aantoonbaar versterkt. Hierbij is nauwe samenwerking nodig tussen het securityteam, het identity- en werkplekteam en eventueel leveranciers of dienstverleners. Voor organisaties in de Nederlandse publieke sector is rapportage een wezenlijk onderdeel van monitoring. Denk aan periodieke rapportages richting CISO, FG, CIO en bestuur, waarin trends, significante incidenten, verbeteracties en resterende risico’s worden toegelicht. Door Defender XDR te koppelen aan Microsoft Sentinel of een andere SIEM-oplossing kunnen dashboards worden opgebouwd die aansluiten bij de eisen uit BIO, ISO 27001 en NIS2. Deze dashboards bieden inzicht in aantallen en typen incidenten, responstijden, dekkingsgraad van logging en de status van verbetermaatregelen. Ten slotte hoort bij volwassen monitoring ook het regelmatig testen van de detectie- en responsketen, bijvoorbeeld via table-top-oefeningen en gecontroleerde simulaties van aanvalsscenario’s. Hierbij wordt nagegaan of waarschuwingen op het juiste moment verschijnen, of escalatiepaden werken zoals bedoeld en of management tijdig wordt geïnformeerd. Op basis van de uitkomsten worden playbooks, procedures en configuraties bijgesteld, zodat de Defender XDR-architectuur meegroeit met de dreigingsontwikkeling en de ambities van de organisatie.

Compliance en Auditing

  1. Binnen de Nederlandse overheid en de (semi-)publieke sector vormt de Baseline Informatiebeveiliging Overheid (BIO) het primaire kader voor informatiebeveiliging. BIO-maatregel 12.02 richt zich specifiek op bescherming tegen malware en schrijft voor dat organisaties passende technische en organisatorische maatregelen treffen om schadelijke software te voorkomen, te detecteren en te herstellen. De Defender XDR-architectuur sluit hier direct op aan door geavanceerde antimalwarebescherming te bieden op endpoints, in e-mailstromen en in cloudomgevingen, gecombineerd met gedragsgebaseerde detectie van verdachte activiteiten. Voor auditors is het belangrijk dat organisaties kunnen aantonen welke Defender-componenten zijn ingeschakeld, welke beleidsregels zijn geconfigureerd, hoe updates en definities worden beheerd en hoe wordt omgegaan met uitzonderingen. Documenteer deze keuzes zorgvuldig en leg vast hoe de organisatie periodiek beoordeelt of de getroffen maatregelen nog effectief en proportioneel zijn.
  2. Naast de BIO is ISO/IEC 27001 een veelgebruikt normenkader voor informatiebeveiligingsmanagementsystemen. Control A.8.7 richt zich op bescherming tegen malware en sluit daarmee nauw aan bij de verplichtingen uit de BIO. In het kader van ISO 27001 moeten organisaties kunnen aantonen dat risico’s rond malwarebeveiliging zijn geïdentificeerd, dat passende beheersmaatregelen zijn geselecteerd, geïmplementeerd en geëvalueerd, en dat er een continue verbetercyclus bestaat. De inzet van Defender XDR kan in de Statement of Applicability worden opgenomen als concrete maatregel, waarbij per component wordt beschreven welke rol deze speelt in preventie, detectie en respons. Audit-evidence omvat onder meer configuratieoverzichten, rapportages over incidenten en verbeteracties, en bewijs dat managementperiodiek wordt geïnformeerd over de effectiviteit van de getroffen maatregelen.
  3. Met de inwerkingtreding van de NIS2-richtlijn worden organisaties in essentiële en belangrijke sectoren geconfronteerd met zwaardere zorgplichten op het gebied van netwerk- en informatiebeveiliging. Artikel 21 specificeert dat organisaties passende en evenredige technische, operationele en organisatorische maatregelen moeten nemen om risico’s voor de beveiliging van netwerk- en informatiesystemen te beheersen. De Defender XDR-architectuur kan hier een centrale rol in spelen, doordat zij niet alleen geavanceerde detectie en respons mogelijk maakt, maar ook uitgebreide rapportagemogelijkheden biedt richting bestuur en toezichthouders. Om aan de verwachtingen van NIS2 te voldoen, moeten organisaties kunnen aantonen dat zij op basis van een risicobeoordeling hebben gekozen voor deze architectuur, dat zij maatregelen regelmatig evalueren en actualiseren, en dat incidenten tijdig worden gemeld aan de bevoegde autoriteiten. Heldere documentatie, goed ingerichte logging en transparante governance-structuren zijn hierbij onmisbaar.

Remediatie

Gebruik PowerShell-script defender-architecture.ps1 (functie Invoke-Remediation) – Remediatie binnen de Defender XDR-architectuur draait om het gecontroleerd en aantoonbaar herstellen van de normale situatie na een beveiligingsincident, met minimale impact op bedrijfsvoering en maximale borging van lessons learned. Wanneer een incident wordt gedetecteerd en geprioriteerd, bepaalt het SOC-team – op basis van vooraf vastgelegde playbooks – welke containment- en herstelacties worden uitgevoerd. Denk aan het isoleren van een geïnfecteerd endpoint, het intrekken of resetten van gecompromitteerde accounts, het blokkeren van malafide domeinen of IP-adressen, en het terugdraaien of herstellen van ongeautoriseerde configuratiewijzigingen. De kracht van Defender XDR is dat veel van deze acties geautomatiseerd kunnen worden via Automated Investigation and Response (AIR), mits de organisatie duidelijke kaders heeft gedefinieerd over welke ingrepen zonder menselijke tussenkomst zijn toegestaan. Een volwassen remediatieproces start altijd met een goede diagnostische fase: wat is de vermoedelijke oorzaak, welke systemen en gegevens zijn geraakt, welke dreigingsactor of tactieken, technieken en procedures (TTP’s) lijken te zijn gebruikt, en welke duurzame maatregelen zijn nodig om herhaling te voorkomen? Binnen Defender XDR wordt deze analyse ondersteund door uitgebreide incidenttijdlijnen, correlaties tussen signalen uit verschillende bronnen en integratie met threat intelligence. Op basis hiervan worden zowel korte termijn acties (containment en herstel) als lange termijn maatregelen (structurele hardening, aanvullende monitoring, aanpassing van processen of bewustwordingscampagnes) gedefinieerd. Voor organisaties die vallen onder de "Nederlandse Baseline voor Veilige Cloud" is aantoonbaarheid richting auditors en toezichthouders minstens zo belangrijk als de technische remediatie zelf. Daarom moeten alle uitgevoerde acties goed worden gelogd en gekoppeld aan het betreffende incidentnummer in het ticket- of case-managementsysteem. Defenderscripts, zoals de in dit document genoemde PowerShell-scripts, kunnen worden ingezet om gestandaardiseerde herstelacties consistent en reproduceerbaar uit te voeren. Door deze scripts eerst in een gescheiden test- of acceptatieomgeving te valideren, wordt voorkomen dat herstelmaatregelen zelf nieuwe risico’s introduceren. Tot slot hoort bij een professioneel remediatieproces een expliciete evaluatiefase. Na afronding van een incident wordt met betrokken partijen – bijvoorbeeld SOC, IT-beheer, CISO en eventueel leveranciers – teruggekeken op het verloop: zijn waarschuwingen tijdig gegenereerd, waren playbooks duidelijk, was de besluitvorming transparant en is het management adequaat geïnformeerd? De bevindingen uit deze evaluatie leiden tot concrete verbeteracties in configuratie, processen en training. Op die manier groeit de organisatie stap voor stap naar een hoger volwassenheidsniveau en wordt de Defender XDR-architectuur optimaal benut als fundament voor weerbare en veilige cloudvoorzieningen..

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# .SYNOPSIS Microsoft Defender XDR Architecture Design .DESCRIPTION Implementation for Microsoft Defender XDR Architecture Design .NOTES Filename: defender-architecture.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/design/security/defender-architecture.json #> #Requires -Version 5.1 #Requires -Modules Microsoft.Graph [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Microsoft Defender XDR Architecture Design" $CISControl = "CIS M365 2.x (Email security), 13.x (Defender settings)" $BIOControl = "12.02" function Connect-RequiredServices { # Connection logic based on API } function Test-Compliance { Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "defender-architecture" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() } # Compliance check implementation # Based on: Design Document $result.Details += "Compliance check - implementation required based on control" $result.NonCompliantCount = 1 return $result } function Invoke-Remediation { Write-Host "`nApplying remediation for: $PolicyName..." -ForegroundColor Cyan # Remediation implementation Write-Host " Configuration applied" -ForegroundColor Green Write-Host "`n[OK] Remediation completed" -ForegroundColor Green } function Invoke-Monitoring { $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total: $($result.TotalResources)" -ForegroundColor White Write-Host "Compliant: $($result.CompliantCount)" -ForegroundColor Green $color = if ($result.NonCompliantCount -gt 0) { "Red" } else { "Green" } Write-Host "Non-compliant: $($result.NonCompliantCount)" -ForegroundColor $color return $result } function Invoke-Revert { Write-Host "Revert: Configuration revert not yet implemented" -ForegroundColor Yellow } try { Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Revert) { Invoke-Revert } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red } } } catch { Write-Error $_ }

Risico zonder implementatie

Risico zonder implementatie
Critical: Zonder een geĂŻntegreerde bedreigingsbeschermingsarchitectuur blijven beveiligingsmaatregelen vaak versnipperd: e-mailbeveiliging staat los van endpointbescherming, identitybewaking en SaaS-controle, waardoor aanvallen onopgemerkt tussen de kieren kunnen doorglippen. Detectie van ketenaanvallen duurt aanzienlijk langer omdat er geen automatische correlatie plaatsvindt tussen signalen uit verschillende systemen, en analisten veel tijd verliezen aan handmatig onderzoek in losse consoles. Dit vergroot de kans op datalekken, langdurige verstoringen van bedrijfsvoering en niet-naleving van wettelijke verplichtingen uit onder andere BIO, AVG en NIS2. Het risico is daarmee hoog tot kritiek, zeker voor organisaties in vitale of gevoelige sectoren, en rechtvaardigt een structurele investering in een geĂŻntegreerde Defender XDR-architectuur.

Management Samenvatting

De Microsoft Defender XDR-architectuur combineert meerdere beveiligingsproducten tot één samenhangende oplossing: Defender voor Office 365 beschermt e-mail en samenwerkingstools, Defender voor Endpoint biedt geavanceerde endpointdetectie en -respons, Defender voor Identity bewaakt aanmeldingen en activiteiten in on-premises Active Directory, en Defender voor Cloud Apps geeft inzicht en grip op het gebruik van SaaS- en cloudapplicaties. Deze oplossingen worden samengebracht in één XDR-laag die signalen correleert, incidenten bundelt en geautomatiseerde remediatie via Automated Investigation and Response mogelijk maakt. In combinatie met Microsoft Sentinel als SIEM ontstaat een krachtig platform voor detectie, respons en rapportage, passend bij de eisen uit BIO, ISO 27001 en NIS2. Implementatie vergt eenmalig circa 80–120 uur aan technische en organisatorische inspanning, maar levert een structurele versterking op van de weerbaarheid van de organisatie en een duidelijke onderbouwing richting bestuur en toezichthouders waarom deze investering noodzakelijk en proportioneel is.