BIO 14.02

Defender Policy Filtering

📅 2025-10-30
•
⏱️ 18 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

Gerichte Defender-policyfiltering vormt een onmisbaar verdedigingsmechanisme binnen Microsoft 365 omdat het de stroom van inkomende en uitgaande e-mail systematisch controleert op phishing, spoofing en malware en tegelijk ruimte laat voor legitieme communicatie.

Aanbeveling
Implementeer gelaagde Defender-beleidspakketten
Risico zonder
Medium
Risk Score
5/10
Implementatie
24u (tech: 16u)
Van toepassing op:
✓ Defender voor Office 365

Wanneer organisaties vertrouwen op generieke beleidsregels ontstaan blinde vlekken: bestuurders krijgen ofwel te veel blokkades en zoeken onveilige workarounds, of juist te weinig bescherming en lopen daardoor een verhoogd risico op Business Email Compromise, AVG-incidenten en publieke reputatieschade.

PowerShell Modules Vereist
Primary API: Exchange Online PowerShell
Connection: Connect-ExchangeOnline
Required Modules: ExchangeOnlineManagement

Implementatie

Deze maatregel bouwt een gelaagd geheel van beleidsgroepen op waarin risicoprofielen, identiteiten, transportregels en rapportages integraal worden afgestemd, zodat Defender voor Office 365 geautomatiseerde beslissingen neemt die aantoonbaar aansluiten bij BIO- en AVG-eisen.

Vereisten

Het fundament van een robuuste Defender-policyfiltering begint bij heldere licentie- en platformvoorwaarden. Alle betrokken postvakken moeten over Microsoft Defender voor Office 365 Plan 2 beschikken, inclusief serviceaccounts, gedeelde postvakken en resource-mailboxen die vaak worden vergeten maar wel e-mail verwerken. Daarnaast moeten de tenants zijn voorzien van moderne authenticatie, enforced security defaults en een geverifieerd domeinbeleid zodat kwaadwillenden geen gaten kunnen vinden via onvolledig geconfigureerde accepted domains. Zonder deze basis is elke filteringsstrategie fragiel en ontstaat het risico dat berichten alsnog buiten Defender om kunnen worden afgeleverd. Vooral hybride omgevingen moeten verifiëren dat alle on-premises transportservers de nieuwe connectors ondersteunen zodat berichten niet ongecontroleerd worden doorgelust. Een tweede vereiste is een betrouwbare identiteits- en groepsstructuur. Targeted filtering werkt uitsluitend wanneer risicogroepen expliciet kunnen worden aangesproken, bijvoorbeeld executive mailboxes, afdelingen met intensieve partnercommunicatie en externe gastaccounts. Azure AD-groepen moeten dynamische membership rules hebben op basis van functie, locatie of gevoeligheidslabel zodat wijzigingen in HR-systemen automatisch worden doorgevoerd. Verder is een up-to-date inventory van federatiepartners nodig, inclusief SPF-, DKIM- en DMARC-status, om het gedrag van binnenkomende domeinen correct te kunnen beoordelen. Documenteer per partner welke bijlagen, talen en formats zijn toegestaan zodat afwijkingen sneller worden herkend. Koppel deze groepen aan een centraal risicoregister zodat duidelijk is waarom een mailbox onder een bepaald beleid valt en wie de eigenaar is. Ook de gegevensstromen tussen Defender, Exchange-transportregels en eventuele Secure Email Gateway-integraties moeten volledig in kaart zijn gebracht. Dit betekent dat connectors, transportregels en journalingconfiguraties consistent moeten verwijzen naar dezelfde policysets, en dat er geen legacy regels actief mogen zijn die berichten omleiden vóórdat Defender ze beoordeelt. Logging moet worden doorgestuurd naar Microsoft Sentinel of een ander SIEM-platform inclusief Advanced Hunting-events, zodat het effect van nieuwe beleidsregels kwantitatief kan worden aangetoond. Leg in technische documentatie vast hoe uitzonderingsstromen worden afgehandeld en welke audittrails beschikbaar zijn voor forensisch onderzoek. Zonder deze zichtbaarheid kunnen beheerders niet aantonen dat de filtering daadwerkelijk de juiste berichten onderschept. Tot slot is een bestuurlijk kader noodzakelijk. Het CISO-office moet een changekalender bijhouden waarin elk policy-experiment vooraf wordt beoordeeld op risico voor mission critical processen, terwijl communicatieafdelingen verantwoordelijk zijn voor het informeren van sleutelgebruikers over eventuele aanvullende verificatiestappen. Supportprocessen hebben duidelijke escalatiestromen nodig, inclusief runbooks voor het tijdelijk versoepelen van filtering wanneer vitale ketenpartners plotseling worden geblokkeerd. Met periodieke tabletop-oefeningen wordt gecontroleerd of dit kader in de praktijk werkt en of sleutelpersonen hun rol begrijpen. Alleen wanneer governance, communicatie en incidentafhandeling vooraf zijn ingericht kan de organisatie profiteren van strikte filtering zonder de bedrijfscontinuïteit in gevaar te brengen.

Implementatie

Een effectieve implementatie start met een diepgaande analyse van de huidige e-mailstromen. Verzamel minimaal dertig dagen aan Defender-rapportages, Exchange-transportlogs en informatie uit Microsoft Sentinel om te begrijpen welke typen phishing, Business Email Compromise en malware de tenant daadwerkelijk raken. Combineer deze gegevens met interviews met business-eigenaren om te identificeren welke processen gevoelig zijn voor vertraging wanneer berichten in quarantaine terechtkomen. Documenteer tevens welke third-party transportagents actief zijn en of er legacy journalingregels bestaan die berichten dupliceren. Door technische telemetrie te koppelen aan bedrijfscontext ontstaat een prioriteitenlijst met risicoprofielen per gebruikersgroep, wat de basis vormt voor gerichte beleidskeuzes. Vervolgens worden de daadwerkelijke policies opgebouwd in drie lagen: een tenantbrede baseline, gerichte beleidsregels per risicogroep en uitzonderingsprofielen voor vertrouwde partners. De baseline gebruikt bijvoorbeeld het Microsoft-preset "Standard" als startpunt, waarna aanvullende regels worden toegevoegd voor SPF-hard fail, geavanceerde anti-phishing en Safe Links real-time scanning. Voor executives wordt een striktere variant ingericht met aanvullende spoofbeveiliging, zero-day sandboxing en strengere DMARC-evaluatie, terwijl afdelingen die veel klantbijlagen ontvangen een evenwichtige variant krijgen waarin drempelwaardes voor bulk mail worden aangepast. Gebruik sensitivitylabels om automatisch te bepalen welke berichten onder prioriteitsaccounts vallen. Denk daarnaast aan specifieke policies voor gedeelde mailboxen en applicatieve accounts die vanuit ERP-systemen e-mail versturen, zodat zij niet onnodig worden geblokkeerd maar wel aan minimale beveiliging voldoen. Om configuratiefouten te vermijden wordt iedere policy niet handmatig maar via broncode uitgerold. Het PowerShell-script code/design/security/defender-policy-filtering.ps1 bevat herbruikbare functies om policies aan te maken, te koppelen aan Azure AD-groepen en rapportering te activeren. Beheerders vullen het script aan met JSON-configuratiebestanden waarin per groep de gewenste drempelwaardes staan. Tijdens het uitvoeren wordt gebruikgemaakt van Connect-ExchangeOnline met least-privilege-accounts zodat wijzigingen volledig worden gelogd. Door elke wijziging via version control op te slaan kan eenvoudig worden teruggedraaid naar een vorige configuratie wanneer audits daarom vragen. Het script genereert bovendien een CSV-overzicht dat direct kan worden geüpload naar het configuratieregister van de CISO. Na het bouwen volgt een iteratief testtraject. Eerst worden policies in testmodus geplaatst waarbij berichten nog worden afgeleverd, maar Defender wel aangeeft welk verdict zou zijn gegeven; deze schaduwevaluatie loopt minimaal twee weken om seizoensinvloeden op e-mailverkeer mee te nemen. Daarna wordt een pilotgroep geactiveerd waarin gebruikers instructies krijgen hoe zij quarantaineberichten verifiëren en hoe zij valse positieven kunnen melden. Gedurende dit traject worden ook scenario's voor spear-phishing gesimuleerd via Attack Simulation Training om te verifiëren dat de nieuwe regels daadwerkelijk ingrijpen bij geavanceerde campagnes. Resultaten worden gedeeld met de security board zodat besluitvorming transparant verloopt. Wanneer de technische validatie is geslaagd, volgt de gecontroleerde uitrol. Activatie gebeurt in waves per afdeling waarbij telkens wordt gecontroleerd of dashboards en alerts stabiel blijven. Supportteams ontvangen bijgewerkte runbooks inclusief standaardantwoorden voor veelgestelde vragen en instructies hoe gebruik van selfservice-releaseportalen werkt. Waar nodig worden parallelle communicatiecampagnes opgezet richting ketenpartners, bijvoorbeeld wanneer DMARC-instellingen moeten worden aangescherpt. De change wordt afgesloten met een post-implementation review waarin beschermingsniveaus, gebruikersfeedback en operationele kosten worden geëvalueerd. Lessons learned worden gedocumenteerd in het centrale kennisportaal zodat de organisatie wendbaar blijft bij toekomstige updates.

Gebruik PowerShell-script defender-policy-filtering.ps1 (functie Invoke-Monitoring) – Monitoren.

Monitoring

Effectieve monitoring van Defender-policyfiltering draait om het continu inzichtelijk maken van wat policies daadwerkelijk doen met het e-mailverkeer. Start met een uniform datamodel waarin quarantainebesluiten, gebruikersacties en verdict-anomalieën worden samengebracht. Door het percentage berichten per policy, per transportregel en per domein te visualiseren in Microsoft Sentinel ontstaat een helder beeld van waar bescherming te streng of juist te mild uitpakt. Specifieke aandacht gaat uit naar executive mailboxes en andere prioriteitsaccounts; voor hen wordt near-real-time alerting ingericht zodat elke mislukte levering binnen enkele minuten zichtbaar is. Door baseline-statistieken vast te leggen nog voordat policies worden aangescherpt, kan het team elke wijziging vergelijken met de uitgangssituatie en objectief aantonen welke verbetering is gerealiseerd. Deze telemetrie vormt de basis voor zowel operationele sturing als strategische verbeterplannen. Automatisering voorkomt dat monitoring vervalt tot handmatig rapporteren. Het meegeleverde PowerShell-script wordt volgens een vaste planning uitgevoerd en schrijft beleidsconfiguraties, hitcounts en statusinformatie weg naar een centrale Log Analytics-workspace. Via KQL-queries worden KPI's berekend zoals het percentage geblokkeerde Business Email Compromise-pogingen, het aantal gebruikers dat een bericht zelf uit quarantaine heeft vrijgegeven en de doorlooptijd van incidenten. Door alerts te koppelen aan Microsoft Teams-kanalen ontvangen SOC-analisten contextrijke meldingen inclusief policy-id, DMARC-resultaat en het verdachte domein, waardoor zij sneller besluiten kunnen nemen. Eventuele monitoringgaten, zoals ontbrekende data vanuit on-premises transportservers, worden meteen zichtbaar omdat de scriptuitvoer daar health-checks voor bevat. Hetzelfde script valideert bovendien of alle policies nog steeds gekoppeld zijn aan de juiste Azure AD-groepen, zodat onverwachte membershipwijzigingen direct in beeld zijn. Naarmate de dataset groeit, kan gedrag geanalyseerd worden op trends en kwaliteit. Advanced Hunting-query's vergelijken het blokkadepercentage met externe dreigingsfeeds, waardoor afwijkingen vroegtijdig worden vastgesteld. Bijvoorbeeld: wanneer het volumedeel van een nieuw domein binnen één dag verdubbelt maar Defender geen hoge risicoscore afgeeft, markeert het dashboard dit domein voor handmatige review. Ook wordt bijgehouden hoeveel valse positieven door gebruikers zijn gemeld, uitgesplitst naar policytype en bijlagetype. Deze inzichten worden teruggekoppeld naar het beleidsteam zodat zij drempelwaardes kunnen bijsturen of extra awarenesscampagnes kunnen organiseren. Zo ontstaat een gesloten feedbackloop waarin feitelijke gebeurtenissen niet langer pas tijdens audits worden ontdekt maar direct leiden tot bijgestuurde regels. Rapportage aan stakeholders sluit het monitoringsproces af. Elke maand ontvangt het CISO-office een narratief rapport met de belangrijkste bevindingen, inclusief een beoordeling van de beschikbaarheidseffecten op bedrijfsprocessen. Kritieke incidenten worden gekoppeld aan lessons learned en toegewezen verbeteracties met duidelijke eigenaren en deadlines. Het rapport bevat tevens een complianceparagraaf waarin wordt aangetoond hoe langdurige retentie van loggegevens is geborgd en hoe audittrails kunnen worden gedeeld met toezichthouders. Op die manier sluiten technische observaties naadloos aan op risicodialogen binnen directie- en auditcomités. Door monitoringdata niet alleen technisch maar ook bestuurlijk te interpreteren, kan de organisatie aantonen dat Defender-policyfiltering een gecontroleerde en volwassen maatregel is.

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

Remediatie

Remediatie begint bij het snel identificeren van het type afwijking dat optreedt binnen Defender-policyfiltering. Iedere melding wordt ingedeeld in categorieën zoals "gebrek aan verificatiegegevens", "onjuiste policykoppeling" of "door gebruiker vrijgegeven bedreiging". Door deze classificatie direct na het incident vast te leggen, kan het team bepalen of er sprake is van een incident dat alleen technische bijsturing vereist of dat er ook organisatorische gevolgen zijn, bijvoorbeeld wanneer medewerkers buiten het proces om whitelistings aanvragen. Indien het incident verband houdt met een specifieke ketenpartner, wordt meteen contact opgenomen met de leverancier zodat zij parallel aan de interne analyse hun eigen logbestanden veiligstellen. Deze structuur verkort de responstijd en zorgt dat het publiek vertrouwen behoudt in de strenge filtering. Wanneer hiaten technisch van aard zijn, wordt een gestandaardiseerd runbook gevolgd. Eerst wordt de relevante policyversie opgehaald uit version control, zodat duidelijk is welke instellingen golden op het moment van het incident. Daarna worden quarantaineberichten, Advanced Hunting-logs en e-mailheaders geanalyseerd om te zien welke regel het bericht heeft doorgelaten of tegengehouden. Indien nodig wordt het PowerShell-script gebruikt om een tijdelijke compensatiemaatregel toe te passen, zoals het verhogen van de phish-threshold voor één specifieke groep of het blokkeren van een malafide domein met een transportregel. Door elke stap te script-automatiseren blijft de audittrail compleet en kan achteraf worden aangetoond dat het principe van least privilege is nageleefd tijdens het uitvoeren van noodmaatregelen. Elke wijziging wordt vooraf goedgekeurd door het changeboard wanneer de impact groter is dan een enkel postvak. Voor structurele verbeteringen richt de organisatie zich niet alleen op techniek maar ook op gedrag. Trainingen voor servicedeskmedewerkers leren hen hoe zij meldingen van valse positieven objectief beoordelen en hoe zij gebruikers begeleiden bij het veilig vrijgeven van berichten. Daarnaast worden leveranciers aangesproken op het up-to-date houden van SPF- en DKIM-records; escalaties naar contractmanagers zijn mogelijk wanneer partners herhaaldelijk onjuist geconfigureerde mailservers inzetten. Regelmatige tabletop-oefeningen met scenario's zoals massale spoofing tegen gemeentelijke loketten toetsen of iedereen weet welke stappen nodig zijn en welke communicatiekanalen gebruikt worden. Deze combinatie van technische en relationele remediatie voorkomt dat het probleem zich verplaatst naar andere organisatieonderdelen of dat politieke druk leidt tot te ruimhartige uitzonderingen. Tot slot wordt iedere remediatie afgerond met meetbare effectiviteitstoetsen. Binnen zeven dagen na een wijziging wordt gecontroleerd of het aantal vergelijkbare incidenten daadwerkelijk is gedaald en of nieuwe neveneffecten, zoals toename van vertragingen, zijn ontstaan. De bevindingen worden opgenomen in het centrale risicoregister en gedeeld met zowel de securityboard als de proceseigenaren van kritieke diensten. Dezelfde feedback wordt gebruikt om het draaiboek te actualiseren, zodat toekomstige incidenten sneller kunnen worden afgehandeld en minder afhankelijk zijn van individuele experts. Door transparant te rapporteren over fouten én verbeteringen ontstaat vertrouwen dat Defender-policyfiltering continu wordt verfijnd, wat essentieel is voor publieke organisaties die onder toezicht staan en zich moeten verantwoorden over elke wijziging in hun beveiligingsketen.

Gebruik PowerShell-script defender-policy-filtering.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance en Auditing

Naleving van Nederlandse kaders staat centraal bij Defender-policyfiltering omdat e-mail een primair kanaal is voor publieke dienstverlening. De BIO schrijft voor dat organisaties aantoonbaar moeten kunnen uitleggen hoe zij e-mailbescherming inrichten, welke controls worden toegepast en hoe effectiviteit wordt gemeten. Daarom wordt elke policy beschreven in het informatiebeveiligingsplan inclusief doelstelling, scope, verantwoordelijke functionaris en relatie met BIO-maatregelen 12.01 en 14.02. Bovendien worden de instellingen voor SPF, DKIM en DMARC gekoppeld aan het gemeentelijk of rijksbrede domeinbeleid, zodat inspecties direct kunnen verifiëren dat de instellingen overeenkomen met landelijke afspraken. Ook wordt vastgelegd hoe de maatregel aansluit op de Baseline Informatiebeveiliging Waterschappen of andere sectorspecifieke afgeleiden, zodat ketenpartners dezelfde terminologie herkennen. Zonder deze documentatie is het onmogelijk om tijdens audits aan te tonen dat filtering niet willekeurig is maar gebaseerd op risicoanalyse. Voor AVG-conformiteit ligt de nadruk op proportionaliteit en transparantie. Organisaties moeten kunnen uitleggen welke persoonsgegevens door Defender worden verwerkt, hoe lang logs worden bewaard en wie toegang heeft tot quarantainegegevens. Daarom worden privacy impact assessments uitgevoerd waarin wordt beschreven hoe geautomatiseerde besluitvorming in Defender werkt, hoe gebruikers bezwaar kunnen maken en op welke wijze menselijke tussenkomst is georganiseerd bij het vrijgeven van berichten. Verder krijgen medewerkers duidelijke communicatie over welke meldingen worden gelogd en welke beleidsregels van toepassing zijn op privégebruik van zakelijke e-mail. Door deze maatregelen voldoet de filtering aan de beginselen van rechtmatigheid, doelbinding en dataminimalisatie, en kan de Functionaris Gegevensbescherming toezicht houden op de naleving. Auditors verwachten concreet bewijs dat policies bestaan en worden nageleefd. Het auditdossier bevat exports van policyconfiguraties, screenshots van rapportagedashboards en changerequests waarin goedkeuringen zijn vastgelegd. Daarnaast worden de outputs van het PowerShell-script bewaard als objectieve bron voor configuratieoverzichten. Bij elke grote wijziging wordt een sign-off gevraagd van de Functionaris Gegevensbescherming én het proceseigenaarschap binnen de keten. Wanneer toezichthouders aanvullende vragen stellen, kan het team dankzij deze dossiervorming snel borgen dat antwoorden consistent zijn met eerdere rapportages. Daarnaast is naleving een continu proces waarin risicoacceptaties en verbeterplannen worden bijgewerkt. Het CISO-office beoordeelt minstens halfjaarlijks of de filtering nog aansluit op het risicoprofiel van de organisatie, bijvoorbeeld wanneer nieuwe clouddiensten of fusies het e-mailvolume veranderen. Eventuele afwijkingen, zoals tijdelijke versoepeling voor een verkiezingscampagne, worden expliciet geregistreerd met einddatum en compenserende maatregelen. Tot slot wordt de governance rond leverancierscontracten meegenomen: SLA's bevatten bepalingen over e-mailauthenticatie en incidentmeldingen zodat ook externe partijen bijdragen aan de naleving. Door compliance-activiteiten te integreren met dagelijkse operatie blijft Defender-policyfiltering niet alleen technisch effectief maar ook bestuurlijk verdedigbaar.

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 Defender Policy Priority Design .DESCRIPTION Implementation for Defender Policy Priority Design .NOTES Filename: defender-policy-filtering.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/design/security/defender-policy-filtering.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 = "Defender Policy Priority Design" $BIOControl = "12.02" function Connect-RequiredServices { # Connection logic based on API } function Test-Compliance { Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "defender-policy-filtering" 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
Medium: Generieke e-mailbeveiliging leidt onvermijdelijk tot twee schadelijke scenario's: kritieke functies ervaren te strenge blokkades en zoeken risicovolle omwegen, terwijl standaardgebruikers juist onvoldoende bescherming krijgen en kwetsbaar blijven voor Business Email Compromise. Zonder fijnmazige policies blijft de organisatie steken op een middelgroot risiconiveau, stijgt de kans op AVG-incidenten en neemt de druk op servicedesks toe doordat uitzonderingen ad hoc worden toegekend.

Management Samenvatting

Ontwerp voor elke gebruikersgroep een specifiek Defender-beleid: bestuurders krijgen maximale anti-phishing en Safe Attachments in strikt gedrag, reguliere medewerkers een uitgebalanceerd profiel en klantgerichte teams een beleid dat legitieme externe mailstromen respecteert maar wel DMARC en sandboxing afdwingt. Wijs policies toe op basis van Azure AD-groepen, beheer alle instellingen via het PowerShell-script en valideer continu met dashboards en pilots. Zo ontstaat een aantoonbare balans tussen veiligheid en bruikbaarheid binnen Defender voor Office 365.