Preset- versus aangepast anti-phishingbeleid in Microsoft Defender for Office 365

By Mirko Peters · 2026-10-29

Leer wanneer je preset- of aangepast anti-phishingbeleid gebruikt in Microsoft Defender for Office 365, vermijd voorrangsvallen en beveilig je cloudtenant.

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

De keuze tussen preset-beveiligingsbeleid en aangepaste configuraties in Microsoft Defender for Office 365 bepaalt hoe effectief je organisatie gerichte phishingaanvallen stopt. Deze gids behandelt de evaluatievolgorde van beleid, verborgen voorrangsvallen en een praktisch kader om te bepalen wanneer aangepaste regels echt gerechtvaardigd zijn boven de ingebouwde aanbevelingen van Microsoft.

Belangrijkste punten

• Microsoft evalueert e-mailbeveiligingsbeleid in een strikte volgorde van boven naar beneden: Strict-preset, Standard-preset, aangepast beleid en tot slot ingebouwde bescherming.
• De evaluatie-engine stopt bij de eerste overeenkomst, wat betekent dat gebruikers in presetscopes elk aangepast anti-phishingbeleid dat je bouwt volledig omzeilen.
• Preset-beveiligingsbeleid neemt onderhoud en het beheer van beleidsafwijkingen van jou over, zodat je basisbeveiliging automatisch wordt bijgewerkt tegen opkomende dreigingen.
• Aangepast beleid kost veel beheerinspanning en moet worden voorbehouden aan echte, gedocumenteerde zakelijke uitzonderingen.
• Hoogrisicogebruikers zoals directieleden, financiële medewerkers en IT-beheerders horen thuis in strikte presetscopes in plaats van in op maat gemaakte isolatieregels.

De voorrangsval: waarom aangepaste regels stilzwijgend falen

Veel beheerders van e-mailbeveiliging besteden dagen aan het opstellen van aangepast anti-phishingbeleid in het Microsoft Defender-portal. Ze stellen zorgvuldig de betrouwbaarheidsniveaus voor phishing af, bouwen uitgebreide lijsten met beschermde gebruikers en wijzen specifieke acties toe voor imitatiepogingen. Het portaal toont een geruststellende status ‘Ingeschakeld’ en de configuratie ziet er op papier foutloos uit. Toch kan het beleid voor geen enkele gebruiker daadwerkelijk worden geactiveerd.

De kern van het probleem zit in hoe Microsoft 365 meerdere overlappende regels verwerkt. De evaluatie-engine combineert instellingen niet en kiest ook niet de strengste regel. In plaats daarvan doorloopt hij een strikte hiërarchie: het Strict-presetbeleid wordt eerst geëvalueerd, gevolgd door het Standard-presetbeleid, dan aangepast beleid en tot slot de ingebouwde bescherming helemaal onderaan. Zodra een ontvanger overeenkomt met een beleid hoger in de keten, stopt de evaluatie definitief. Als je financiële teamleden binnen de scope van het Standard-presetbeleid vallen, wordt je aangepaste financiële anti-phishingregel volledig genegeerd. Er verschijnen geen foutmeldingen en er gaat geen waarschuwing af, waardoor een onzichtbaar beveiligingslek ontstaat dat aanvallers gemakkelijk kunnen misbruiken.

Presets versus aangepast beleid: de administratieve afweging

Het begrijpen van het principiële verschil tussen de preset-beveiligingsbeleidsregels van Microsoft en aangepaste tenantconfiguraties is essentieel voor het langetermijnbeheer van je cloudarchitectuur. Preset-beleid (Standard en Strict) vertegenwoordigt collectieve kennis die is verzameld over miljoenen mailboxen wereldwijd. Microsoft werkt deze instellingen voortdurend bij op basis van realtime dreigingstelemetrie, waardoor je profiteert van inzichten op industrieniveau die individuele tenants nooit zelf zouden kunnen opbouwen.

Daarentegen vertegenwoordigt een aangepast beleid het subjectieve oordeel van één beheerder, toegepast op één organisatie op een specifiek moment. Aangepaste regels bieden weliswaar gedetailleerde controle over specifieke mailstromen of unieke bedrijfsvereisten, maar ze brengen een zware onderhoudslast met zich mee. Wanneer aanvalsmethoden evolueren, blijven aangepaste beleidsregels volledig statisch. Zonder een vaste reviewcyclus raken aangepaste configuraties ongemerkt uit de pas met moderne beveiligingsstandaarden, waardoor kwetsbaarheden ontstaan die na een incident moeilijk te diagnosticeren zijn.

Wanneer is een aangepast anti-phishingbeleid echt gerechtvaardigd?

Omdat presets de meeste gebruikersscenario's goed afhandelen, moeten aangepaste beleidsregels worden beschouwd als uitzonderingen en niet als standaard uitrolstrategie. Om de voortdurende onderhoudslast van een aangepaste regel te rechtvaardigen, moet die meestal in een van drie specifieke operationele categorieën vallen:

• Handmatig geselecteerde lijsten met beschermde gebruikers: Als je organisatie een zeer specifieke lijst nodig heeft van directieleden, bestuurders of financiële goedkeurders die beschermd worden door op maat gemaakte drempelwaarden voor imitatie, dan kun je met aangepaste anti-phishingbeleidsregels precies die namen opgeven.
• Ongebruikelijke mailstromen: Bedrijfsonderdelen die regelmatig niet-standaard externe bestanden ontvangen of vertrouwen op interne geautomatiseerde systemen die snel valse positieven veroorzaken, hebben mogelijk smal afgebakende aangepaste regels nodig om de bedrijfscontinuïteit te waarborgen.
• E-mailgateways van derden: Organisaties die mail vóór Microsoft 365 via een externe beveiligingsgateway routeren, krijgen vaak te maken met gewijzigde verbindingsgegevens en authenticatieresultaten, waardoor speciale afhandeling binnen de parameters van het aangepaste beleid nodig is.

Als je motivatie om een aangepaste regel te bouwen simpelweg een voorkeur is voor andere gevoeligheidsniveaus, of het vage gevoel dat de standaardinstellingen te zacht zijn, dan rechtvaardigt het beleid waarschijnlijk de langetermijnkosten voor het beheer niet.

Conclusie en volgende stappen

Automatische intelligentie combineren met gerichte aangepaste configuraties is het kenmerk van een volwassen cloudbeveiligingsstrategie. Door te vertrouwen op de presetbeleidsregels van Microsoft voor het brede medewerkersbestand en aangepaste regels uitsluitend te reserveren voor gedocumenteerde uitzonderingen, verminder je de administratieve belasting en maximaliseer je de effectiviteit van dreigingsdetectie. Wil je dieper ingaan op implementatiestrategieën, configuratiecycli en rapportagemetrieken? Luister naar de volledige aflevering van de M365 FM Podcast voor deskundige inzichten en praktische begeleiding om je Microsoft 365-beveiliging vandaag nog te optimaliseren.

Veelgestelde vragen

Wat gebeurt er als een gebruiker zowel in een presetbeleid als in een aangepast beleid is opgenomen?

De evaluatie-engine van Microsoft 365 verwerkt beleidsregels in een strikte volgorde, waarbij presetbeleid (Strikt en daarna Standaard) voorrang krijgt boven aangepast beleid. Als een gebruiker overeenkomt met een presetbeleid, stopt het systeem met evalueren en wordt het aangepaste beleid voor die ontvanger volledig overgeslagen.

Worden de presetbeveiligingsbeleidsregels van Microsoft automatisch bijgewerkt?

Ja. Presetbeleid wordt rechtstreeks door Microsoft onderhouden. Wanneer het dreigingslandschap verandert en aanbevolen basiswaarden wijzigen, werkt Microsoft de onderliggende instellingen binnen de presets Standaard en Strikt automatisch bij, waardoor beheerders geen handmatige reviewcycli hoeven uit te voeren.

Waarom moeten gebruikers met een hoog risico, zoals directieleden, in strikte presets worden geplaatst in plaats van in aangepaste regels?

Rollen met een hoog risico zijn primaire doelwitten voor geavanceerde spear-phishing- en imitatieaanvallen. Strikte presets passen agressieve beschermingsdrempels toe, ondersteund door de wereldwijde telemetrie van Microsoft, en bieden uitgebreide beveiliging zonder dat beheerders complexe lijsten met aangepaste uitzonderingen handmatig hoeven bij te houden.

Hoe kan ik controleren welk beleid daadwerkelijk van toepassing is op de postbus van een specifieke gebruiker?

Je kunt effectieve beleidsregels controleren met de Configuration Analyzer in het Microsoft Defender-portaal, of door geavanceerde hunting-queries uit te voeren op e-mailgebeurtenissen om te traceren welke specifieke detectiemechanismen en beleidsregels acties hebben ondernomen op de binnenkomende berichten van een gebruiker.