Windows Defender Application Control (WDAC) Geconfigureerd

Veel organisaties vertrouwen nog steeds op oplossingsrichtingen die primair signatures en reputatiescores gebruiken om kwaadaardige code te blokkeren. Deze benadering biedt onvoldoende bescherming tegen zero-day ransomware, fileless aanvallen of misbruik van standaardbeheerhulpmiddelen. WDAC draait de logica om: alles wordt geweigerd, tenzij het expliciet is toegestaan via een gevalideerd vertrouwensmodel. De voordelen zijn tastbaar. Nieuwe malwarevarianten die nog niet door beveiligingsleveranciers zijn gecatalogiseerd, krijgen geen kans omdat ze simpelweg niet op de goedkeuringslijst staan. Bestanden zonder digitale handtekening worden niet geladen in kernelmodus, waardoor bootkits en rootkits nauwelijks voet aan de grond krijgen. Aanvallers die PowerShell, WMI of ingebouwde commandline-tools willen inzetten voor laterale verplaatsing, stuiten op beleidsregels die alleen gesigneerde en gecontroleerde scripts doorlaten. Tegelijkertijd helpt WDAC om de softwaresupplychain te controleren: alleen softwarepakketten van vertrouwde uitgevers worden geaccepteerd, waardoor gemanipuleerde updates of schijnbaar legitieme maar gecompromitteerde installers worden gestopt voordat zij operationele schade veroorzaken. De keerzijde is dat de organisatie een volwassen proces moet hebben voor codeondertekening, wijzigingsbeheer en snelle incidentrespons, omdat elke wijziging aan applicaties of drivers effect heeft op het beleid.

Implementatie

Een effectieve WDAC-implementatie binnen Intune vergt een doordachte combinatie van beleidsopbouw, gefaseerde invoering en voortdurend beheer. Teams starten met een grondige inventarisatie van alle toepassingen, inclusief leveranciersinformatie, uitvoeringslocaties en updatecycli. Met de WDAC Wizard of PowerShell-cmdlets wordt een basisbeleid opgesteld dat standaard Microsoft- en WHQL-handtekeningen vertrouwt en vervolgens wordt uitgebreid met aanvullende regels voor bedrijfskritische uitgevers, specifieke bestands-hashes voor maatwerkapplicaties en voorzichtig toegepaste padregels voor geïsoleerde scenario’s. Tijdens de eerste weken draait het beleid in auditmodus, zodat alle overtredingen wel worden vastgelegd maar nog geen bedrijfsprocessen blokkeren. Deze logging wordt gebruikt om ontbrekende goedkeuringen toe te voegen en uitzonderingen strak te onderbouwen. Nadat het beleid stabiel is, wordt overgeschakeld naar afdwingmodus en wordt het via Intune uitgerold naar productionele apparaatgroepen. Via dezelfde beheerlaag worden updates verspreid, aanvullende beleidsbestanden gekoppeld en rapportages over geblokkeerde uitvoeringen verzameld. Organisaties zonder gestandaardiseerde werkplekken of zonder beschikbaar beheerteam kiezen beter voor lichter te beheren alternatieven zoals AppLocker of een combinatie van aanvalsoppervlakreductieregels en EDR, maar voor hoogbeveiligde omgevingen blijft WDAC de meest sluitende aanpak.

• Fase 1 – Strategische planning (week 1-4): catalogiseer alle applicaties, koppel elke titel aan een eigenaar en documenteer welke uitvoerbare bestanden, scripts, drivers en installatiepaden worden gebruikt; stel ondertussen het governance-model vast waarin security de beleidsregels bepaalt, werkplekbeheer de distributie verzorgt en het wijzigingscomité uitzonderingen beoordeelt, zodat elke latere toelating traceerbaar is.
• Fase 2 – Beleidsopbouw (week 5-8): gebruik de WDAC Policy Wizard of PowerShell om een basisbeleid te genereren dat Microsoft-, WHQL- en Intelligent Security Graph-handtekeningen vertrouwt; bouw vervolgens aanvullende policies waarin uitgevers van bedrijfskritische software, digitale certificaten voor maatwerktoepassingen en specifieke hashes voor legacycomponenten zorgvuldig worden toegevoegd.
• Fase 3 – Auditpilot (week 9-16): wijs het beleid in auditmodus toe aan een beperkte populatie van technisch onderlegde gebruikers, verzamel minimaal vier weken lang alle CodeIntegrity-rapportages en analyseer Event ID 3076 en 3077 om vast te stellen welke processen onterecht worden tegengehouden; organiseer wekelijks een triagesessie waarin security en applicatie-eigenaren elke melding beoordelen en beslissen over toelating.
• Fase 4 – Handhavingspilot (week 17-20): schakel de pilotgroep over naar enforced mode, bewaak de bedrijfsimpact via werkstroommonitoring en servicedeskstatistieken, en test het noodproces voor tijdelijke uitzonderingen zodat kritieke werkzaamheden kunnen doorgaan terwijl het whitelistproces de structurele oplossing levert.
• Fase 5 – Productie-uitrol (week 21-28): rol WDAC gefaseerd uit over de organisatie (bijvoorbeeld 10%, 25%, 50%, 100%), automatiseer de aanlevering van beleid via Intune, combineer rapportages uit Endpoint Security, Microsoft Defender en SIEM om blokkades real-time te detecteren, en borg in het changeproces dat elke nieuwe applicatie of update eerst wordt voorzien van een goedgekeurd trustmodel.
• Genereer voor elke release een WDAC-XML-bestand vanuit de wizard of een gecontroleerd PowerShell-script en zorg dat het bestand gepubliceerd wordt in een versiebeheersysteem met tagging op datum en verantwoordelijke.
• Zet het XML-bestand om naar een binair bestand met ConvertFrom-CIPolicy en documenteer de gebruikte parameters, zodat dezelfde instellingen later opnieuw kunnen worden toegepast tijdens audits of herzieningen.
• Maak in Intune een aangepast configuratieprofiel aan waarin de policies worden opgenomen via de Vendor/MSFT/ApplicationControl-namespace, inclusief een duidelijke beschrijving, versienummering en verwijzing naar de verantwoordelijke eigenaar.
• Vul de OMA-URI met het juiste PolicyGUID en plaats het base64-gecodeerde binaire bestand in de waarde, controleer vooraf de groottebeperkingen en splits zo nodig in aanvullende policies.
• Ken het profiel toe aan test-, pilot- en productiegroepen volgens het faseringplan en gebruik dynamische en statische groepen om uitzonderingsapparaten zichtbaar te houden.
• Monitor de naleving via Intune-rapportages, Microsoft Defender for Endpoint console en Windows Event Logs zodat afwijkingen snel worden gedetecteerd en teruggekoppeld naar het wijzigingsproces.
• AppLocker biedt een eenvoudiger te beheren alternatief dat minder diep in het besturingssysteem grijpt en daardoor sneller kan worden aangepast, maar het kent ook meer omzeilingsmogelijkheden en minder rapportagedetail.
• Aanvalsoppervlakreductieregels in Microsoft Defender for Endpoint blokkeren veelvoorkomende aanvalspatronen en vormen een zinvolle tussenstap voor organisaties die al wel een EDR-licentie hebben maar nog niet klaar zijn voor volledige whitelisting.
• Een strak gedisciplineerd applicatiebeheerproces met alleen beheerde distributiekanalen kan bepaalde risico’s verminderen, maar bereikt niet hetzelfde niveau van technische afdwinging als WDAC en vereist daarom aanvullende detectiecontrols.
• WDAC levert de meeste waarde in omgevingen met een gestandaardiseerd werkplekbeeld, een dedicated securityteam en duidelijke compliance-eisen; wanneer aan deze voorwaarden niet wordt voldaan, is een gefaseerde route via bovenstaande alternatieven verstandiger.

Vereisten

WDAC kan alleen succesvol worden ingezet wanneer de organisatie beschikt over een volwassen werkplekomgeving, een duidelijke governance-structuur en voldoende technische expertise. Vanaf de eerste voorbereidingen moet helder zijn dat applicatiecontrole niet werkt als incidentele maatregel, maar als een permanent proces waarin inventarisatie, beoordeling, goedkeuring en herbeoordeling elkaar in een strak ritme opvolgen. De Nederlandse publieke sector kent bovendien strenge compliance-eisen, waardoor elk besluit rond toelating of blokkering van software zorgvuldig moet worden vastgelegd. Deze paragraaf beschrijft welke randvoorwaarden minimaal aanwezig moeten zijn voordat een implementatietraject überhaupt kans van slagen heeft, en geeft context over de benodigde rollen, licenties en ondersteunende voorzieningen.

1. Een organisatie moet beschikken over Windows 10 Enterprise E3/E5 of Windows 11 Enterprise licenties zodat alle benodigde code-integriteitsfuncties beschikbaar zijn; lagere edities missen kritische componenten waardoor het beleid niet betrouwbaar kan worden afgedwongen.
2. Een volledige Microsoft Intune-abonnement en bijbehorende tenantconfiguratie zijn nodig om WDAC-beleidsbestanden veilig te distribueren, updates gecontroleerd te uit te rollen en rapportages centraal te verzamelen, inclusief rolgebaseerde toegang en logging.
3. De Endpoint Administrator of Intune Administrator rol moet officieel worden toegewezen aan het kerndepot dat WDAC beheert, zodat beleidswijzigingen, groepstoewijzingen en sleutelmaterialen niet versnipperd raken over meerdere teams.
4. Een actueel en gedetailleerd applicatieregister vormt de basis voor elk whitelistingbeleid: voor elke applicatie is informatie vereist over leverancier, versie, distributiekanaal, ondertekening en afhankelijkheden binnen de keten.
5. Voor maatwerkapplicaties of nichetools is een interne codeondertekeningsvoorziening noodzakelijk, inclusief veilige opslag van certificaten, procedures voor sleutelrotatie en controle op juist gebruik door ontwikkelteams.
6. Er moet minimaal 0,2 tot 0,5 fte aan gespecialiseerde capaciteit beschikbaar zijn om het beleid continu te onderhouden, meldingen te analyseren, wijzigingen in softwareversies te beoordelen en gebruikersvragen te beantwoorden.
7. Een gescheiden acceptatie- of testomgeving met representatieve apparaten en datasets is vereist om nieuwe beleidsversies, aanvullende trustregels of uitzonderingen tenminste enkele weken te laten proef draaien zonder productie-impact.
8. Het projectteam moet vooraf een rollbackplan beschrijven waarmee beleid snel kan worden teruggezet naar auditmodus of tijdelijk kan worden uitgeschakeld indien een bedrijfskritische applicatie toch onterecht wordt geweigerd.
9. Gebruikerscommunicatie en bewustwording zijn cruciaal: medewerkers en leveranciers moeten weten waarom bepaalde applicaties niet langer vrij kunnen worden geïnstalleerd en welke procedure geldt voor uitzonderingsverzoeken.
10. Het wijzigingsbeheerproces van de organisatie moet worden uitgebreid met een formele goedkeuringsstap voor nieuwe software, zodat WDAC-beheer tijdig betrokken wordt en aanpassingen aan de whitelist niet ad-hoc hoeven te gebeuren.
11. Management moet expliciet akkoord gaan met het feit dat WDAC aanzienlijke operationele inspanning vraagt in ruil voor maximale beveiliging, zodat verwachtingen over doorlooptijden, benodigde investeringen en residueel risico realistisch blijven.

Wanneer aan deze randvoorwaarden is voldaan, loont het om aanvullende ondersteunende maatregelen te definiëren. Denk aan het inrichten van een kennisbank waarin standaardantwoorden op veelgestelde vragen worden vastgelegd, het aanwijzen van WDAC-ambassadeurs binnen iedere directie zodat escalaties kort blijven, en het registreren van meetbare doelstellingen zoals “binnen vijf werkdagen reageren op applicatieverzoeken” of “maximaal drie blokkades per duizend apparaten per maand”. Ook moet worden geborgd dat leverancierscontracten beschrijven hoe software-updates worden gesigneerd en hoe vroegtijdig release-informatie wordt gedeeld, zodat het whitelistteam niet telkens worden verrast. Door deze governance- en procesmaatregelen expliciet te maken ontstaat een volwassen fundament waarop de technische configuraties kunnen rusten, en voldoet de organisatie aantoonbaar aan de eisen van de Nederlandse Baseline voor Veilige Cloud.

Implementatie

De implementatie van WDAC vraagt om een planmatig traject waarin technische configuratie, verandermanagement en zorgvuldige communicatie elkaar versterken. Binnen de Nederlandse Baseline voor Veilige Cloud adviseren we een aanpak van minimaal zes maanden, zodat elke stap – van inventarisatie tot uitrol – ruimte biedt voor analyse en validatie. Gedurende het traject moeten security, werkplekbeheer, enterprise-architectuur en servicedesk intensief samenwerken om beleidsaanpassingen te toetsen aan bedrijfsprocessen en om uitzonderingen aantoonbaar te documenteren. Het onderstaande stappenplan beschrijft de belangrijkste mijlpalen en benadrukt hoe elke fase bijdraagt aan een gecontroleerde overgang van auditmodus naar volledige handhaving.

Gebruik PowerShell-script windows-defender-application-control.ps1 (functie Invoke-Monitoring) – PowerShell script voor basic WDAC status Controleer (checks Device Guard registry).

1. Fase 1 – Strategische planning (week 1-4): catalogiseer alle applicaties, koppel elke titel aan een eigenaar en documenteer welke uitvoerbare bestanden, scripts, drivers en installatiepaden worden gebruikt; stel ondertussen het governance-model vast waarin security de beleidsregels bepaalt, werkplekbeheer de distributie verzorgt en het wijzigingscomité uitzonderingen beoordeelt, zodat elke latere toelating traceerbaar is.
2. Fase 2 – Beleidsopbouw (week 5-8): gebruik de WDAC Policy Wizard of PowerShell om een basisbeleid te genereren dat Microsoft-, WHQL- en Intelligent Security Graph-handtekeningen vertrouwt; bouw vervolgens aanvullende policies waarin uitgevers van bedrijfskritische software, digitale certificaten voor maatwerktoepassingen en specifieke hashes voor legacycomponenten zorgvuldig worden toegevoegd.
3. Fase 3 – Auditpilot (week 9-16): wijs het beleid in auditmodus toe aan een beperkte populatie van technisch onderlegde gebruikers, verzamel minimaal vier weken lang alle CodeIntegrity-rapportages en analyseer Event ID 3076 en 3077 om vast te stellen welke processen onterecht worden tegengehouden; organiseer wekelijks een triagesessie waarin security en applicatie-eigenaren elke melding beoordelen en beslissen over toelating.
4. Fase 4 – Handhavingspilot (week 17-20): schakel de pilotgroep over naar enforced mode, bewaak de bedrijfsimpact via werkstroommonitoring en servicedeskstatistieken, en test het noodproces voor tijdelijke uitzonderingen zodat kritieke werkzaamheden kunnen doorgaan terwijl het whitelistproces de structurele oplossing levert.
5. Fase 5 – Productie-uitrol (week 21-28): rol WDAC gefaseerd uit over de organisatie (bijvoorbeeld 10%, 25%, 50%, 100%), automatiseer de aanlevering van beleid via Intune, combineer rapportages uit Endpoint Security, Microsoft Defender en SIEM om blokkades real-time te detecteren, en borg in het changeproces dat elke nieuwe applicatie of update eerst wordt voorzien van een goedgekeurd trustmodel.

Het succes van WDAC valt of staat met een zorgvuldig ingericht distributiepad. Intune vormt hiervoor het primaire platform omdat het zowel moderne werkplekken als serveromgevingen kan voorzien van configuratieprofielen, met inbegrip van aangepaste OMA-URI-instellingen. Het omzetproces van XML naar binair beleid moet worden opgenomen in een herhaalbaar script of DevOps-pijplijn, zodat foutkansen afnemen en auditing eenvoudiger wordt. Ook is het verstandig om per beleidsversie een changelog bij te houden waarin staat welke uitgevers zijn toegevoegd, wanneer hashes zijn ververst en welke risico-acceptaties zijn verleend.

1. Genereer voor elke release een WDAC-XML-bestand vanuit de wizard of een gecontroleerd PowerShell-script en zorg dat het bestand gepubliceerd wordt in een versiebeheersysteem met tagging op datum en verantwoordelijke.
2. Zet het XML-bestand om naar een binair bestand met ConvertFrom-CIPolicy en documenteer de gebruikte parameters, zodat dezelfde instellingen later opnieuw kunnen worden toegepast tijdens audits of herzieningen.
3. Maak in Intune een aangepast configuratieprofiel aan waarin de policies worden opgenomen via de Vendor/MSFT/ApplicationControl-namespace, inclusief een duidelijke beschrijving, versienummering en verwijzing naar de verantwoordelijke eigenaar.
4. Vul de OMA-URI met het juiste PolicyGUID en plaats het base64-gecodeerde binaire bestand in de waarde, controleer vooraf de groottebeperkingen en splits zo nodig in aanvullende policies.
5. Ken het profiel toe aan test-, pilot- en productiegroepen volgens het faseringplan en gebruik dynamische en statische groepen om uitzonderingsapparaten zichtbaar te houden.
6. Monitor de naleving via Intune-rapportages, Microsoft Defender for Endpoint console en Windows Event Logs zodat afwijkingen snel worden gedetecteerd en teruggekoppeld naar het wijzigingsproces.

Ondanks de hoge mate van bescherming is WDAC niet in elke situatie de logischste keuze. Organisaties met zeer diverse softwarelandschappen of veel experimenterende gebruikers (zoals ontwikkelaars) kunnen moeite hebben om het whitelistproces bij te houden. Het is dan zaak om een hybride strategie te overwegen waarbij strikte whitelisting wordt toegepast op kritieke processen, terwijl voor bredere gebruikersgroepen aanvullende detectie- en responsmaatregelen worden verscherpt. Transparante besluitvorming richting bestuur en auditcommissies helpt om verwachtingen te managen en de gekozen risicobehandeling te onderbouwen.

1. AppLocker biedt een eenvoudiger te beheren alternatief dat minder diep in het besturingssysteem grijpt en daardoor sneller kan worden aangepast, maar het kent ook meer omzeilingsmogelijkheden en minder rapportagedetail.
2. Aanvalsoppervlakreductieregels in Microsoft Defender for Endpoint blokkeren veelvoorkomende aanvalspatronen en vormen een zinvolle tussenstap voor organisaties die al wel een EDR-licentie hebben maar nog niet klaar zijn voor volledige whitelisting.
3. Een strak gedisciplineerd applicatiebeheerproces met alleen beheerde distributiekanalen kan bepaalde risico’s verminderen, maar bereikt niet hetzelfde niveau van technische afdwinging als WDAC en vereist daarom aanvullende detectiecontrols.
4. WDAC levert de meeste waarde in omgevingen met een gestandaardiseerd werkplekbeeld, een dedicated securityteam en duidelijke compliance-eisen; wanneer aan deze voorwaarden niet wordt voldaan, is een gefaseerde route via bovenstaande alternatieven verstandiger.

Het implementatietraject moet uiteindelijk resulteren in een duurzaam beheerframework. Leg vast hoe vaak policies worden herzien, welke triggers gelden voor spoedupdates (bijvoorbeeld kritieke kwetsbaarheden of nieuwe softwareversies) en hoe lessons learned uit incidenten worden teruggekoppeld. Combineer technische documentatie (zoals export van policybestanden) met procesdocumenten (zoals workflows en communicatieplannen) zodat auditoren een compleet beeld krijgen. Door deze integrale aanpak blijft WDAC niet beperkt tot een technisch experiment, maar wordt het een kernonderdeel van de beveiligingsarchitectuur.

monitoring

Gebruik PowerShell-script windows-defender-application-control.ps1 (functie Invoke-Monitoring) – Basic WDAC configuration Controleer via Device Guard registry.

Het handhaven van WDAC is geen eenmalige inspanning maar een continu verbeterproces. Elke wijziging in softwareleveringen, elke nieuwe hardwaredriver en elke wijziging in Windows buildniveaus kan impact hebben op de betrouwbaarheid van het beleid. Daarom moeten organisaties een samenhangend monitoringsproces opzetten waarin telemetrie uit endpoints, Intune en SIEM-systemen wordt samengebracht en waarin duidelijke rollen zijn belegd voor analyse, rapportage en escalatie. De servicedesk speelt een sleutelrol bij het herkennen van symptomen van geblokkeerde applicaties, terwijl securityanalisten verantwoordelijk zijn voor patroonherkenning en incidentrespons.

1. Verzamel dagelijks de CodeIntegrity/Operational logs (Event ID 3076, 3077 en 3089) via een centraal logplatform en koppel deze aan apparaat- en gebruikerscontext, zodat trends snel zichtbaar worden en er bewijs beschikbaar is voor auditors.
2. Gebruik het script windows-defender-application-control.ps1 in geplande taken om configuratiedrift te detecteren, bijvoorbeeld wanneer een apparaat onverwacht uit auditmodus valt of wanneer aanvullende policies niet correct worden geladen.
3. Maak een wekelijks rapport waarin de top geblokkeerde applicaties, betrokken businessprocessen en ondernomen acties worden beschreven; bespreek dit rapport in het security change board om prioriteiten te stellen.
4. Verbind de servicedeskworkflow aan het applicatiegoedkeuringsproces, zodat meldingen over blokkades automatisch worden verrijkt met relevante loggegevens en sneller kunnen worden toegewezen aan het WDAC-beheerteam.
5. Evalueer ieder kwartaal de effectiviteit van het beleid door testmalware en beheerde aanvallen te simuleren, zodat aantoonbaar is dat whitelisting nog steeds succes heeft tegen actuele dreigingen en er geen ongewenste gaten zijn ontstaan.

Naast deze operationele controles is het verstandig om metriekgestuurde doelen op te stellen. Denk aan indicatoren zoals gemiddelde oplostijd voor blokkades, percentage apparaten dat de nieuwste policy draait, aantal nood-uitschakelingen per kwartaal en het aantal goedgekeurde applicatieverzoeken dat binnen de afgesproken termijn is verwerkt. Door deze KPI’s maandelijks te rapporteren aan het CISO-office ontstaat inzicht in de volwassenheid van de WDAC-keten. Combineer dit met periodieke post-incident reviews, waarbij wordt nagegaan of de whitelistingmaatregelen daadwerkelijk hebben bijgedragen aan het stoppen van een aanvalspoging of dat aanvullende detecties nodig zijn. Zo groeit WDAC uit tot een dynamische control die continu wordt aangescherpt in plaats van een statisch projectresultaat.

Compliance en Auditing

Voor Nederlandse overheden is aantoonbare naleving van normen zoals BIO, ISO 27001 en NIS2 essentieel. WDAC helpt om deze eisen concreet invulling te geven omdat het een meetbare beperking van ongeautoriseerde software realiseert en omdat de onderliggende logging precies laat zien welke beslissingen het systeem neemt. Auditors verwachten echter meer dan alleen technische maatregelen: zij willen inzicht in beleid, governance en bewijslast. Daarom moet WDAC worden ingebed in het bredere controlframework waarin beleidsteksten, risicobeoordelingen en operationele procedures elkaar versterken.

1. Het BIO-controlepunt 12.06.02 vraagt om maatregelen die ongeautoriseerde of schadelijke software weren; WDAC biedt hiervoor een direct bewijsstuk doordat elke applicatie expliciet moet worden toegelaten en doordat het beleid centraal kan worden getoond aan auditors.
2. ISO 27001:2022 A.8.8 verlangt dat organisaties technische kwetsbaarheden beheersen en software-installaties reguleren; een WDAC changelog, gekoppeld aan het risicoacceptatieproces, vormt overtuigend bewijs dat deze verplichting structureel wordt ingevuld.
3. NIS2 artikel 21 benoemt toepassing van state-of-the-art maatregelen voor essentiële en belangrijke entiteiten; WDAC wordt in diverse Europese richtlijnen aangehaald als voorbeeld van een hoogwaardige preventieve control op endpoints.
4. De CIS Microsoft Windows Benchmarks beschrijven gedetailleerde instellingen voor applicatiecontrole en beperken van scriptuitvoering; een WDAC-configuratie die hierop is afgestemd maakt het eenvoudiger om conformiteit aan te tonen.
5. Documentatie uit NIST SP 800-167 en richtlijnen van de NSA geven aanvullende best practices rond whitelisting; het naleven van deze richtlijnen en het opnemen ervan in het beveiligingshandboek toont aan dat de organisatie internationaal erkende standaarden volgt.
6. Voor ketenpartijen die met PCI-DSS te maken hebben, ondersteunt WDAC de eis om systeemparameters zo te configureren dat misbruik wordt voorkomen; gecombineerde rapportages van WDAC en Intune laten zien dat deze configuratie permanent wordt gehandhaafd.

Zorg ervoor dat compliance-eisen niet uitsluitend worden gezien als auditmomenten. Bouw een kalender met jaarlijkse toetsingen, kwartaalrapportages en thematische reviews (bijvoorbeeld gericht op privacy, kritieke infrastructuur of financiële processen) zodat WDAC altijd onderdeel is van de bredere governancecyclus. Gebruik het auditdossier – inclusief beleidsbestanden, goedkeuringsbesluiten, incidentverslagen en trainingsmateriaal – als één bron van waarheid. Door deze informatie te koppelen aan het risicoregister kan management aantonen welke resterende risico’s bewust zijn geaccepteerd en welke verbeteracties nog lopen. Dit voorkomt dat applicatiecontrole wordt benaderd als een losstaande maatregel en helpt om de Nederlandse Baseline voor Veilige Cloud structureel in te bedden.

Remediatie

Gebruik PowerShell-script windows-defender-application-control.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer WDAC een applicatie blokkeert die toch noodzakelijk blijkt, moet het herstelproces zowel de directe verstoring oplossen als inzicht geven in de onderliggende oorzaak. Het remediatiescript controleert of de juiste policies zijn geladen, of aanvullende policies ontbreken en of er lokale wijzigingen zijn aangebracht die het handhavingsniveau hebben verlaagd. De uitkomsten worden gedeeld met het WDAC-beheerteam en vormen het startpunt voor een diepere analyse. In deze fase is nauwe samenwerking met applicatie-eigenaren essentieel: zij moeten aangeven welke functies zijn geraakt, welke tijdlijn kritieke bedrijfsprocessen hanteren en welke tijdelijke maatregelen acceptabel zijn om de dienstverlening op peil te houden.

Het structurele herstel volgt een strak gedefinieerde workflow. Eerst wordt vastgesteld of de blokkade terecht is, bijvoorbeeld omdat er sprake is van onbekende software, verdachte wijzigingen of een niet-ondertekende update. Is de blokkade onterecht, dan worden de benodigde vertrouwensregels toegevoegd (bijvoorbeeld door een uitgever te whitelisten of een nieuw certificaat te registreren) en wordt de policy opnieuw opgebouwd. Elke wijziging wordt getest in de acceptatie-omgeving, waarna het beleid via Intune wordt uitgerold volgens het standaardreleaseproces. Gedurende deze periode blijft een tijdelijke uitzondering mogelijk, maar alleen na expliciete goedkeuring van het securityteam en met een harde einddatum. Na volledige uitrol wordt gecontroleerd of de melding verdwijnt en of er geen nieuwe bijwerkingen zijn opgetreden. Tot slot wordt een post-remediation review uitgevoerd waarin wordt bekeken hoe de blokkade sneller had kunnen worden voorkomen, welke documentatie moet worden bijgewerkt en of leveranciersafspraken moeten worden aangescherpt.

1. Start elke remediatie met het verzamelen van relevante telemetrie: WDAC-logboeken, Intune-statussen, Defender-rapporten en eventuele servicedeskcases worden gebundeld zodat alle betrokkenen een eenduidig beeld hebben.
2. Gebruik het script om het apparaat tijdelijk naar auditmodus te schakelen als dat noodzakelijk is voor businesscontinuïteit, maar documenteer deze stap en herstel afdwinging zodra de definitieve oplossing is uitgerold.
3. Werk samen met leveranciers om ontbrekende digitale handtekeningen of verouderde certificaten te repareren; leg vast welke afspraken zijn gemaakt over toekomstige updates en hoe vroegtijdig notificaties worden geleverd.
4. Actualiseer het applicatieregister en het uitzonderingenlogboek direct na elke wijziging, zodat auditsporen volledig blijven en latere herbeoordelingen kunnen teruggrijpen op accurate informatie.
5. Rapporteer remediatieresultaten in het maandelijkse beveiligingsoverleg, inclusief doorlooptijden, lessons learned en eventuele structurele verbeteracties die voortkomen uit de casus.

Compliance & Frameworks

• CIS M365: Control Windows Security - Application Control (L2) - Application whitelisting via WDAC voor high-security environments
• BIO: 12.06.02 - Beperking van software installatie - Application control
• ISO 27001:2022: A.8.8 - Management of technical vulnerabilities - Ungeautoriseerde software prevention
• NIS2: Artikel - Application control voor critical infrastructure bescherming

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).

Risico zonder implementatie

Management Samenvatting

WDAC is application whitelisting. alleen approved software executes. Blokkeert zero-day malware, ungeautoriseerde apps, fileless attacks. maximum security maar HIGH operational overhead. Requires: Windows Enterprise E3+, dedicated security team (0.3 FTE ongoing), 3-6 months implementation, code signing infrastructure. Voldoet aan BIO 12.06, ISO 27001 A.8.8, NSA guidance. Implementatie: 40-80 uur. alleen voor high-security environments. Alternatives: AppLocker (simpler), ASR rules (easier).

• Implementatietijd: 80 uur
• FTE required: 0.5 FTE