Azure Web Application Firewall: WAF Implementeren Voor Internetgerichte Applicaties

Publieke webapplicaties zijn permanent verbonden met een wereldwijde storm aan geautomatiseerde scans, opportunistische probeeraanvallen en doelgerichte campagne-activiteiten. SOC-teams zien dagelijks miljoenen HTTP-verzoeken binnenkomen waarvan een groot deel gericht is op bekende kwetsbaarheden die jaren geleden al zijn gedocumenteerd. Zonder WAF betekent elk nieuw of opnieuw vrijgegeven exploit dat ontwikkelteams hals over kop codewijzigingen moeten doorvoeren om schade te voorkomen, terwijl ondertussen verkeer ongefilterd binnenkomt. Dat is voor moderne organisaties geen houdbare strategie. Aanvallers combineren vandaag de dag verschillende aanvalsvectoren in één campagne. Een scanner triggert bijvoorbeeld SQL-injecties tegen formulieren, schakelt vervolgens over naar Cross-Site Scripting om sessies te kapen en gebruikt daarna Command Injection om shell-toegang te verkrijgen. Zodra een ingang is gevonden, volgt vaak een geautomatiseerd draaiboek waarin data wordt buitgemaakt, privileges worden verhoogd en de infrastructuur wordt misbruikt voor laterale beweging of nieuwe aanvallen. Dit gebeurt niet alleen bij grote commerciële spelers; ook kleinere gemeenten en uitvoeringsorganisaties worden massaal gescand omdat hun domeinen duidelijk tot de overheid behoren. Veel incidentrapportages tonen dat kwetsbaarheden vaak ontstaan in de lagen waar legacy code naast moderne microservices draait. De combinatie van oude frameworks, versnipperde documentatie en beperkte ontwikkelcapaciteit leidt ertoe dat patches soms weken wachten op acceptatietesten. Gedurende die periode blijft de kwetsbaarheid open. WAF biedt hier een kritieke tussenlaag: zodra een kwetsbaarheid publiek bekend wordt kan een virtuele patch als WAF-regel worden uitgerold binnen minuten, waardoor kostbare tijd wordt gewonnen voor structureel herstel in de applicatie. Bovendien bieden WAF-logboeken een rijke bron aan context. Ze laten zien welke endpoints worden aangevallen, welke payloads worden gebruikt, en of er sprake is van georganiseerde botnets of kleinschalige tests. Deze informatie voedt threat intelligence, ondersteunt forensisch onderzoek en levert bewijs richting toezichthouders dat proactieve maatregelen zijn genomen. Zonder WAF ontbreekt dit zicht: aanvallen worden pas zichtbaar als applicatielogica fouten produceert of gebruikers klagen. Tot slot is er de compliancecomponent. PCI-DSS, BIO, ENSIA en ISO 27001 hebben allemaal expliciete of impliciete eisen voor runtime-bescherming van webapplicaties. Auditors accepteren zelden het argument dat secure coding alleen voldoende is. Zij verwachten een defense-in-depth-benadering waarin WAF een aantoonbare control vormt. Voor Nederlandse overheidsinstellingen betekent het ontbreken van WAF niet alleen veiligheidsrisico's maar ook bestuurlijke aansprakelijkheid, omdat bestuurders moeten kunnen aantonen dat zij redelijke maatregelen hebben genomen. Een goed geconfigureerde Azure WAF is daarom geen luxe maar een basiscontrole.

Implementatie

Deze maatregel schrijft voor dat alle internetgerichte workloads worden geplaatst achter Azure Application Gateway met WAF_v2 of Azure Front Door Premium met geïntegreerde WAF. Application Gateway is de juiste keuze voor regionale scenario's waarbij de applicatie dicht bij een beperkt aantal Azure-regio's draait, omdat deze dienst Layer 7-loadbalancing, SSL-terminatie en netwerksegmentatie in één resource combineert. Front Door is ideaal voor diensten met gebruikers verspreid over meerdere continenten: verkeer wordt dicht bij de gebruiker beëindigd op het Microsoft edge-netwerk en profiteert direct van globale failover en caching. Ongeacht het gekozen platform start de implementatie met het ontwerpen van een WAF-beleid dat zowel standaardregels als contextspecifieke maatregelen bevat. OWASP Core Rule Set 3.2 of hoger dient als fundament; deze set dekt SQL-injectie, XSS, SSRF, RCE en andere Top 10-risico's. Daarbovenop worden rate limiting, geo-filtering en botmanagement geactiveerd. Voor citizen-facing portals die bijvoorbeeld DigiD gebruiken, wordt loginverkeer beperkt met adaptive throttling en wordt verkeer uit risicoregio's standaard uitgedaagd of geblokkeerd. Alle instellingen worden eerst uitgerold in Detectiemodus zodat logs inzicht geven in eventuele vals-positieve signalen. De overgang naar Preventiemodus is vervolgens een gecontroleerd proces. Wanneer de loganalyse geen afwijkende patronen meer toont, wordt blokkerend beleid stapsgewijs geactiveerd per applicatie of per route. Elke wijziging wordt begeleid door communicatie naar applicatie-eigenaren en door regressietesten in een stagingomgeving. Mocht tijdens die fase toch legitiem verkeer worden geraakt, dan kunnen uitzonderingsregels op headers, queryparameters of bodyvelden worden toegevoegd zonder de hele bescherming uit te schakelen. Op die manier blijft de controle fijnmazig en beheersbaar. Alle WAF-telemetrie wordt gestreamd naar Log Analytics en gekoppeld aan Microsoft Sentinel of een andere SIEM-oplossing. Hier worden queries en alerts ingericht voor volumetrische detectie (bijvoorbeeld >100 SQLi-pogingen per vijf minuten), gedragspatronen (pogingen op verborgen admin-routes) en compliance-aantoonbaarheid (maandelijkse rapportage van geblokkeerde aanvallen). Operationele runbooks beschrijven hoe SOC-analisten een melding triëren, hoe ze context ophalen en wanneer escalatie naar applicatie-eigenaren of de Chief Information Security Officer noodzakelijk is. Het benodigde inspanningsprofiel blijft overzichtelijk: gemiddeld acht uur technische implementatie voor het platform en beleid, vier uur organisatorische afstemming voor procedures en communicatie, plus een kleine structurele FTE voor beheer. De maandlasten liggen tussen €150 en €300 per instance, afhankelijk van throughput, redundantie-eisen en gekozen tier. Tegenover die investering staat een tastbaar risicoreductie-effect, verplichte naleving van PCI-DSS 6.6 en een blauwdruk die naadloos aansluit op de Nederlandse Baseline voor Veilige Cloud.

Vereisten

Een volwassen WAF-implementatie begint met harde randvoorwaarden. De organisatie moet exact weten welke webapplicaties internetgericht zijn, welke authenticatiestromen zij hanteren en welke gegevenscategorieën (publiek, intern, vertrouwelijk of geheim) worden verwerkt. Zonder een actuele inventaris, inclusief DNS-namen, backend-architecturen en verantwoordelijke productowners, ontstaat er vroeg in het traject al ruis en worden kritieke endpoints vergeten. Daarom is een eerste vereiste het opstellen van een canonical applicatieregister dat dagelijks wordt bijgewerkt en gekoppeld is aan Azure Resource Graph of CMDB-data. Vervolgens worden technische basiscomponenten klaargezet. Voor Application Gateway betekent dit een dedicated subnet in een virtueel netwerk, minimaal /27 om schaalcapaciteit toe te laten, en de beschikbaarheid van minimaal één statisch publiek IP-adres per gateway. Voor Front Door moeten organisaties beschikken over beheerde domeinen in Azure DNS of een ander platform, zodat CNAME-wijzigingen gecontroleerd kunnen worden uitgevoerd. Certificaatbeheer is een aparte vereiste: alle frontend-domeinen moeten TLS 1.2+ ondersteunen via Azure Key Vault of Front Door managed certificates, inclusief procedures voor automatische vernieuwing en back-out. Identiteits- en autorisatiestromen bepalen welk team wijzigingen mag doorvoeren. Role-Based Access Control in Azure moet daarom zijn ingericht met gescheiden rollen voor netwerkbeheer (voorbeeld: "AppGateway-Netadmin"), beveiliging ("WAF-Policy-Owner") en operations ("WAF-Reader"). Just-in-Time-toegang via Privileged Identity Management is verplicht voor omgevingen met gevoelige gegevens zodat wijzigingen traceerbaar en tijdelijk zijn. Daarnaast moet Azure Policy of een CI/CD-pipeline bewaken dat alleen goedgekeurde WAF-configuraties worden uitgerold. Organisaties die onder Nederlandse wet- en regelgeving vallen moeten aantonen dat zij deze controles borgen in processen. Dat betekent dat er formele wijzigingsprocedures zijn, inclusief impactanalyse en testplan, voordat een nieuwe regel live gaat. Ook is kennis noodzakelijk: minimaal twee engineers moeten gecertificeerd zijn in Az-700 of gelijkwaardig en aantoonbare ervaring hebben met HTTP-analyse, zodat zij effectief kunnen werken met Log Analytics-queries en OWASP-regelsets. Voor grotere organisaties is een dedicated product owner voor WAF aan te bevelen om prioritering en capaciteitsplanning te sturen. Financieel moeten budgetten worden gereserveerd voor platformkosten, logopslag, alerting en eventuele third-party tooling. Voor een gemiddelde overheidsdienst met drie productieomgevingen en twee lagere omgevingen moet rekening worden gehouden met maandelijkse kosten van €600 tot €900 wanneer redundante gateways, Log Analytics (met 30+ GB per maand) en Sentinel-regels worden meegeteld. Deze raming moet worden opgenomen in het meerjarenplan zodat financiering van upgrades (bijvoorbeeld migratie naar Front Door Standard/Premium) niet ad-hoc gebeurt. Tot slot vereist de Baseline voor Veilige Cloud dat er een formeel governancekader bestaat rond operationeel beheer. Er moet een runbook zijn voor onboarding van een nieuwe applicatie, inclusief testcases voor Detectie- en Preventiemodus, een proces voor het evalueren van waarschuwingsdrempels, en een incidentresponsplan waarin WAF een expliciete stap vormt. Zonder documentatie en herhaalbare procedures is het onmogelijk om consistent te voldoen aan BIO 14.02 en CIS 6.6, waardoor de hele control voor auditdoeleinden kan worden afgekeurd.

Monitoring en Controle

Gebruik PowerShell-script waf-web-applications.ps1 (functie Invoke-Monitoring) – Controleren.

Monitoring is het zenuwstelsel van de WAF-voorziening: zonder realtime zicht op wat de firewall ziet en doet, blijft het een black box die zowel te weinig als te veel kan blokkeren. Het begint met een baselinecontrole: dagelijks wordt via een geautomatiseerd PowerShell-script (of Azure Policy Guest Assignment) vastgesteld of alle bekende internetapplicaties daadwerkelijk zijn gekoppeld aan een WAF-profiel. Het script vergelijkt Resource Graph-data met het applicatieregister en publiceert afwijkingen in een dashboard. Daarmee wordt voorkomen dat een nieuwe landing zone per ongeluk zonder WAF live gaat. Alle WAF-telemetrie stroomt verplicht naar een centrale Log Analytics-workspace. Hierin worden custom tables gebruikt om onderscheid te maken tussen Application Gateway en Front Door events, zodat queries snel filteren op platform, omgeving en kritikaliteit. De SOC ontwikkelt Kusto-query's die niet alleen kijken naar aantallen, maar juist naar trends: payloads die opeens massaal voorkomen, verzoeken die buiten kantooruren toenemen of IP-ranges die eveneens in andere incidenten zijn genoemd. Deze correlatie wordt vervolgens doorgezet naar Microsoft Sentinel waar analytische regels playbooks starten op basis van severity en confidence. Waarschuwingen zijn alleen effectief als ze nauwkeurig zijn. Daarom hanteert de Nederlandse Baseline voor Veilige Cloud het principe "progressive disclosure": eerst een lage drempel met informational alerts naar een Teams-kanaal, daarna een medium alert bij herhaald gedrag en pas bij structurele of volumetrische aanvallen een high alert die een incidentticket triggert. Iedere alert heeft een runbook met beslisbomen: wordt verkeer geblokkeerd, is er klantimpact, moet er een blokkade op land of ASN worden toegepast, en wanneer wordt escalatie naar het Nationaal Cyber Security Centrum (NCSC) overwogen. Een ander essentieel aspect is beheer van vals-positieve meldingen. Elke blokkade op een legitieme gebruiker wordt behandeld als een incident en krijgt een root-causeanalyse. Analisten leggen de payload vast, toetsen of de applicatie zich aan RFC-standaarden houdt en bepalen of een uitzondering veilig kan worden toegevoegd. Daarbij geldt het principe "narrow, not broad": uitzonderingen worden zo specifiek mogelijk gekoppeld aan URL, parameter of source-IP zodat de beschermingsgraad behouden blijft. Alle wijzigingen worden geregistreerd in een WAF-change log dat beschikbaar is voor auditors. Prestatiebewaking hoort eveneens bij monitoring. Application Gateway en Front Door bieden metrics voor latency, throughput en healthy/unhealthy backend checks. Deze worden gecombineerd met Application Insights-data om vast te stellen of WAF-configuraties extra vertraging veroorzaken. Bij een stijging boven vooraf ingestelde drempels (bijvoorbeeld P95 > 250 ms) wordt onderzocht of er regels zijn die onnodig diepe inspectie uitvoeren of of het platform moet opschalen. Zo blijft de gebruikerservaring onder controle. Tot slot levert monitoring de bewijsvoering richting compliance. Maandelijks genereert het SOC een rapport waarin de aantallen gedetecteerde en geblokkeerde aanvallen, significante incidenten, uitgevoerde wijzigingen en openstaande acties zijn opgenomen. Dit rapport wordt gedeeld met de CISO, lijnmanagers en auditors en vormt onderdeel van ENSIA- en BIO-verantwoording. Door monitoring zo integraal aan te pakken ontstaat een transparante keten waarin detectie, respons, rapportage en governance elkaar versterken.

Implementatie

Gebruik PowerShell-script waf-web-applications.ps1 (functie Invoke-Implementation) – Implementeren.

Implementatie start met een discovery- en ontwerpworkshop waarin architecten, security officers en applicatie-eigenaren bepalen welke route wordt gevolgd. Er wordt gekeken naar netwerkarchitectuur, latency-eisen, beschikbaarheidsdoelen en toekomstige roadmap (bijvoorbeeld migratie naar Azure Container Apps). Op basis van deze analyse wordt gekozen voor Application Gateway of Front Door en wordt een high-level design opgesteld met componentdiagrammen, IP-plannen, DNS-scenario's en escalatieroutes. Dit ontwerp wordt formeel goedgekeurd door de architectuurboard voordat uitvoering plaatsvindt. Daarna volgt de bouwfase. Voor Application Gateway wordt via Infrastructure as Code (Bicep of Terraform) een WAF_v2-gateway uitgerold inclusief autoscaling, zone-redundantie en integratie met Key Vault voor certificaatbeheer. Voor Front Door wordt gekozen voor het Premium-profiel waarbij WAF-beleid en botbescherming onderdeel zijn van hetzelfde template. Door IaC te gebruiken blijven omgevingen reproduceerbaar en kunnen wijzigingen worden geversioneerd. Tevens wordt Continuous Integration opgezet zodat elke wijziging in het WAF-beleid een pull request, review en geautomatiseerde validatie doorloopt. Als de infrastructuur staat, wordt het WAF-beleid gevormd. Dit gebeurt iteratief: eerst worden de standaard-OWASP regels geactiveerd, gevolgd door aanvullende maatregelen zoals request-size limits, geo-filters en throttling voor loginroutes. Applicatieteams leveren input over specifieke patronen (bijvoorbeeld grote JSON-payloads of chunked uploads) zodat de regels de bedrijfsprocessen niet verstikken. Het beleid wordt opgesplitst in beleidsonderdelen per applicatie, waardoor uitzonderingen gericht kunnen worden toegepast zonder het centrale framework te verzwakken. Vervolgens wordt Detectiemodus geactiveerd in een gecontroleerde pilot. Testscenario's bestaan uit synthetische OWASP-aanvallen, legitiem gebruikersgedrag en performance-metingen. Gedurende twee tot vier weken analyseert het SOC dagelijks de logs, vergelijkt deze met verwachting en documenteert alle gevonden vals-positieven. Elke wijziging wordt via het changeproces verwerkt en doorloopt opnieuw teststappen. Pas wanneer alle stakeholders hebben bevestigd dat de regels betrouwbaar zijn, wordt Preventiemodus ingeschakeld. Dit gebeurt gefaseerd: eerst voor lagere omgevingen, dan voor één productielandingszone, daarna voor de rest. Implementatie stopt niet bij de technische overgang. De organisatie richt ook operationele processen in: runbooks voor incidenten, procedures voor het toevoegen van nieuwe applicaties, en dashboards met key risk indicators (bijvoorbeeld aantal geblokkeerde kritieke aanvallen per week). Er wordt afgesproken hoe updates van OWASP CRS worden getest en uitgerold, hoe certificaatvernieuwingen plaatsvinden en hoe fallback wordt geregeld. Voor kritieke diensten wordt een rollback-plan beschreven zodat bij problemen snel kan worden teruggeschakeld naar Detectiemodus of een vorige configuratie zonder dat de applicatie onbeschermd raakt. Tot slot vindt een overdrachtsmoment plaats. Operations ontvangt documentatie, diagrammen, export van beleid en een kalender met onderhoudsvensters. Er worden kennissessies gehouden zodat SOC-analisten, ontwikkelaars en beheerders exact weten welke signalen belangrijk zijn en welk handelingsperspectief daarbij hoort. Daarna wordt de implementatie afgesloten met een post-implementation review waarin lessons learned worden vastgelegd en verbeteringen voor de volgende onboarding worden benoemd. Op die manier groeit WAF uit tot een herhaalbare capability binnen de Nederlandse Baseline voor Veilige Cloud.

Compliance en Auditing

Compliance is voor Nederlandse organisaties geen vinklijstje maar een wettelijke verantwoordelijkheid. Azure WAF levert tastbaar bewijs dat runtime-bescherming daadwerkelijk is ingericht, iets waar auditors steeds nadrukkelijker naar vragen sinds de BIO en ENSIA zijn aangescherpt. De control sluit direct aan op CIS Azure Benchmark 6.6, waarin expliciet staat dat alle internetgerichte webapplicaties achter een WAF moeten staan. Door het beleid centraal in Azure te beheren, kan bij een auditrapport eenvoudig worden aangetoond welke applicaties zijn gekoppeld, hoe regels worden beheerd en wanneer preventieve maatregelen zijn geactiveerd. Binnen de Baseline Informatiebeveiliging Overheid valt WAF onder cluster 14 (Applicatiebeveiliging). Paragraaf 14.02 verlangt niet alleen technische maatregelen, maar ook aantoonbare procedures voor onderhoud, logging en incidentafhandeling. Een WAF-implementatie voldoet hieraan wanneer er runbooks bestaan, incidenttickets aan logboeken kunnen worden gekoppeld en rapportages beschikbaar zijn waarin het effect van regels inzichtelijk wordt gemaakt. Tijdens ENSIA-verantwoording kan een organisatie bijvoorbeeld de export van het beleid, het logboek met geblokkeerde aanvallen en de goedgekeurde changes overleggen. Daarmee is zichtbaar dat de maatregel "in control" is. ISO/IEC 27001:2022 plaatst WAF in de context van controls A.8.24 (Web filtering) en A.8.33 (Monitoring-activiteiten). Certificerende instellingen vragen expliciet hoe organisaties runtime-monitoring implementeren om kwetsbaarheden te mitigeren die nog niet zijn opgelost in code. Door te verwijzen naar Azure WAF met virtuele patching kan worden aangetoond dat nieuwe kwetsbaarheden onmiddellijk worden geblokkeerd. Documentatie van reviews, bijvoorbeeld ieder kwartaal een health check van beleid en logging, maakt duidelijk dat de control niet statisch is maar continu wordt verbeterd. Voor organisaties die betalingsverkeer faciliteren blijft PCI-DSS requirement 6.6 leidend. Deze eist ofwel een WAF ofwel een periodieke code review door een kwalificatie partij. In de praktijk kiezen Nederlandse instellingen voor WAF omdat deze dagelijks bescherming biedt terwijl codebeheer door meerdere leveranciers loopt. Een PCI-audit vraagt logboeken van minimaal één jaar, bewijs van Preventiemodus en beschrijvingen van hoe wijzigingen worden getest. Azure Log Analytics en Microsoft Sentinel kunnen deze gegevens automatisch archiveren, waardoor de administratieve last beperkt blijft. Ook de AVG speelt een belangrijke rol. Artikel 32 verplicht tot het treffen van passende technische en organisatorische maatregelen. Een WAF is een duidelijke invulling daarvan omdat het gegevenslekken actief voorkomt, incidenten traceerbaar maakt en forensische data oplevert. Wanneer zich een datalek voordoet, kan de organisatie aantonen dat alle redelijke maatregelen zijn genomen: blokkeringslogs tonen precies welk verkeer is tegengehouden en welke payloads zijn gebruikt. Dat ondersteunt zowel meldingen aan de Autoriteit Persoonsgegevens als communicatie naar betrokkenen. Auditing draait tenslotte om bewijs. Organisaties moeten therefore kunnen laten zien dat beleid, logging, alerts en processen aan elkaar zijn gekoppeld. In de praktijk betekent dit een gecontroleerde opslag van WAF-exports, een changelog waarin elke regelwijziging wordt beschreven inclusief reden en risicoanalyse, en dashboards met Key Performance Indicators zoals "aantal geblokkeerde kritieke aanvallen" en "tijd tot mitigatie". Deze artefacten worden opgenomen in het Information Security Management System en jaarlijks herzien. Zo ontstaat een auditpad dat zonder aanvullende uitleg begrijpelijk is voor auditors, bestuurders en toezichthouders.

Remediatie

Gebruik PowerShell-script waf-web-applications.ps1 (functie Invoke-Remediation) – Herstellen.

Remediatie start zodra uit monitoring, pentesten of audits blijkt dat een applicatie zonder WAF draait of dat een bestaand beleid onvoldoende effectief is. De CISO initieert direct een high-priority change. In de intake worden drie zaken vastgelegd: de exacte scope (welke URL's, tenants, backendservices), de reden van tekortschieten (geen WAF gekoppeld, Detectiemodus blijft aan, verkeerde uitzonderingen) en de gewenste eindtoestand. Hiermee kan worden bepaald welke maatregelen nodig zijn en welke teams moeten worden betrokken. Wanneer er nog geen WAF aanwezig is, wordt een spoeddeployment opgezet op basis van gestandaardiseerde IaC-templates. Deze templates bevatten minimale configuraties die voldoen aan BIO en CIS, inclusief logging, OWASP CRS en basis-rate-limiting. Door templategedreven te werken kan binnen enkele uren een functionele WAF voor een applicatie worden geplaatst. Tijdens deze fase wordt verkeer via een blue/green-switch gecontroleerd naar de nieuwe WAF geleid, zodat rollback altijd mogelijk blijft. Bestond er al een WAF maar functioneerde deze niet adequaat, dan ligt de focus op configuratieherstel. Analisten vergelijken de huidige regels met de standaard baseline: ontbreekt CRS, staan regels in logmodus, zijn bypasses te breed of is logging uitgeschakeld? Elk bevindingstype heeft een vast herstelpad. Bijvoorbeeld: ontbrekende logging wordt direct aangezet, gevolgd door een verificatie in Log Analytics; te ruime uitzonderingen worden opgesplitst en getest; Detectiemodus wordt alleen nog toegestaan wanneer er een actief tuningdossier is. Alle stappen worden vastgelegd in het remediatiedossier zodat audits kunnen aantonen wat er precies is hersteld. Tijdens remediatie is communicatie cruciaal. Applicatie-eigenaren moeten weten wanneer verkeer mogelijk wordt beïnvloed en welke testen zij moeten uitvoeren. Daarom wordt voor elke wijziging een dry-run uitgevoerd in een lagere omgeving of door middel van een "custom rule match" waarin verkeer wel wordt gelogd maar nog niet geblokkeerd. Pas als duidelijk is dat de regel geen legitiem verkeer raakt, wordt de blokkade geactiveerd. Mocht er toch impact zijn, dan treedt het incidentresponseplan in werking: blokkade wordt tijdelijk versoepeld, incident wordt geëscaleerd en aanvullende mitigaties (bijvoorbeeld rate limiting of IP-blokkades) worden toegepast. Na technische herstelwerkzaamheden volgt een validatiefase. Het SOC controleert of de nieuwe regels daadwerkelijk hits genereren, of alerts binnenkomen en of dashboards de juiste cijfers tonen. Daarnaast wordt gemeten of performance binnen de gestelde normen blijft. Zodra alle acceptatiecriteria zijn behaald, wordt het remediatiedossier afgesloten met een lessons-learned sectie en worden updates gedeeld met governancefora zoals het Security Change Advisory Board. Remediatie eindigt nooit bij eenmalig herstel. Er wordt een follow-up gepland waarin na 30 en 90 dagen wordt gecontroleerd of de applicatie nog steeds achter de WAF staat, of Preventiemodus actief is en of er geen nieuwe uitzonderingen zijn toegevoegd zonder toetsing. Deze post-remediation checks zorgen ervoor dat de oorzaak structureel wordt aangepakt en dat de WAF-capability volwassen blijft.

Compliance & Frameworks

• CIS M365: Control 6.6 (L2) - WAF voor webapplicaties
• BIO: 14.02 - Applicatiebeveiliging
• ISO 27001:2022: A.14.2.1 - Veilige ontwikkeling

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

WAF Webapplicaties: Azure WAF (Application Gateway of Front Door) met OWASP-regelsets. Blokkeert SQL-injectie, XSS, RCE. Kosten: €200-500 per maand (Application Gateway WAF). Activatie: Implementeer Application Gateway WAF → Configureer OWASP-regels. Verplicht CIS 6.6, BIO 14.02, PCI-DSS 6.6. Implementatie: 8-12 uur. VERPLICHT voor internetgerichte webapplicaties.

• Implementatietijd: 12 uur
• FTE required: 0.2 FTE