Waarom elke Azure-onderneming een WAF-analysemethodologie nodig heeft

Als je webapplicaties draait op Azure, is de kans groot dat je een Web Application Firewall ervoor hebt staan. Azure WAF, of het nu op Application Gateway of Front Door draait, is een van de meest voorkomende security controls in enterprise Azure-omgevingen. Het is ook een van de meest verkeerd begrepen.

Te veel organisaties behandelen WAF als een deploy-and-forget afvinklijstje. De managed rule sets worden geactiveerd, detection mode draait een week, en dan schakelt iemand over naar prevention mode. Zes maanden later verdrinkt het security team in alerts die ze niet kunnen interpreteren, en is het applicatieteam gefrustreerd door false positives die legitiem verkeer blokkeren.

Het kan beter. Een gestructureerde WAF-analysemethodologie maakt van je firewall een bruikbare security-laag in plaats van een luidruchtige poortwachter.

Het probleem met “standaard WAF”

Azure WAF wordt geleverd met OWASP Core Rule Set (CRS) managed rules die een breed scala aan aanvalspatronen dekken: SQL injection, cross-site scripting, remote code execution, en meer. Deze regels worden goed onderhouden en regelmatig bijgewerkt door Microsoft.

Maar hier zit het punt: managed rules zijn generiek by design. Ze beschermen tegen veelvoorkomende aanvalsvectoren zonder iets te weten over jouw specifieke applicatie. Deze mismatch creëert twee problemen:

1. False positives die legitieme requests blokkeren. Een content management systeem dat HTML-invoer accepteert, triggert XSS-regels. Een API die Base64-encoded payloads ontvangt, activeert SQL injection-detectie. Dit zijn geen aanvallen: het zijn normale verkeerspatronen die toevallig matchen met brede signatures.

2. Alert fatigue die echte dreigingen bedelft. Wanneer je WAF duizenden detection-mode alerts per dag genereert, waarvan de meeste onschuldig, stopt het security team met kijken. Die ene echte SQL injection-poging verdwijnt in de ruis.

Beide problemen hebben dezelfde oorzaak: de WAF is niet afgestemd op je applicatie, en niemand heeft een systematisch proces om dat op te lossen.

Azure docs: Azure WAF overview · CRS managed rule groups

Hoe een WAF-analysemethodologie eruitziet

Een goede methodologie is niet ingewikkeld, maar vergt wel discipline. Dit zijn de kernfasen die we gebruiken bij enterprise Azure-omgevingen:

Fase 1: Baseline en inventarisatie

Voordat je regels aanraakt, moet je begrijpen wat je beschermt. Dat betekent een inventaris opbouwen van:

• Applicaties achter de WAF: hun technology stacks, verwachte verkeerspatronen en data sensitivity levels
• Huidige WAF-configuratie: welke policy aan welke listener gekoppeld is, in welke mode die draait, welke rule groups aan- of uitgeschakeld zijn
• Verkeersvolumes en -patronen: piekuren, geografische spreiding, API vs. browserverkeer-verhoudingen

Deze fase levert vaak verrassingen op. We vinden regelmatig WAF policies met tientallen per-rule exclusions die niemand kan verklaren, of applicaties die maanden geleden aan een Application Gateway zijn toegevoegd zonder de WAF policy bij te werken.

Fase 2: Loganalyse en rule profiling

Met de baseline op z’n plek ga je aan de slag met de data. Azure WAF logs, of ze nu in Log Analytics staan, in een storage account, of naar Microsoft Sentinel worden gestreamd, bevatten alles wat je nodig hebt om te begrijpen hoe regels interageren met je verkeer.

De sleutel is gestructureerde analyse, niet gewoon door log entries scrollen. Voor elke getriggerde regel wil je antwoord op:

• Is dit een true positive, false positive, of ruis? Een true positive is een echte aanvalspoging. Een false positive is legitiem verkeer dat onterecht wordt geflagd. Ruis is irrelevant verkeer (bots, scanners) dat regels triggert maar geen echte dreiging vormt.
• Wat is de frequentie en het patroon? Een regel die eenmaal per maand afgaat is iets anders dan een die duizend keer per dag afgaat. Frequentie helpt bij het prioriteren van tuning.
• Wat is de bron? Interne gebruikers, externe klanten, bekende partners, of anoniem internetverkeer? Het antwoord verandert de risico-inschatting.

We bouwen doorgaans KQL queries die WAF logs aggregeren per rule ID, action, URI en source IP, en kruisen die dan met input van het applicatieteam om elk patroon te classificeren.

Hier is een startpunt om je meest getriggerde regels in kaart te brengen:

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where TimeGenerated > ago(7d)
| summarize
    HitCount = count(),
    DistinctSources = dcount(clientIp_s),
    SampleURIs = make_set(requestUri_s, 3)
  by ruleId_s, action_s, ruleGroup_s
| order by HitCount desc
| take 20

Azure docs: WAF log fields and categories · Log Analytics overview · KQL reference

Fase 3: Tuning en exclusion engineering

Gewapend met data kun je nu weloverwogen tuningbeslissingen nemen:

• Regels uitschakelen die fundamenteel incompatibel zijn met je applicatie en niet op te lossen zijn met exclusions. Dit zou zeldzaam moeten zijn en altijd gedocumenteerd.
• Gerichte exclusions aanmaken voor specifieke request fields (headers, cookies, query parameters) die false positives triggeren. Het sleutelwoord is gericht: exclude zo weinig mogelijk scope.
• Custom rules implementeren waar managed rules applicatiespecifieke dreigingen niet dekken. Rate limiting, geo-blocking en URI-gebaseerde access control zijn veelvoorkomende voorbeelden.

Elke wijziging moet gedocumenteerd worden met een onderbouwing. Over zes maanden zal iemand vragen waarom rule 942130 is uitgesloten voor het /api/content endpoint. Als het antwoord is “geen idee, dat stond al zo,” dan heb je een governance-probleem.

Azure docs: WAF exclusion lists · Custom WAF rules

Fase 4: Validatie en promotie

Na het tunen in detection mode valideer je de wijzigingen:

• Laat de getunede policy in detection mode draaien naast productieverkeer voor een afgesproken periode
• Verifieer dat het aantal false positives gedaald is tot een acceptabel niveau
• Bevestig dat er geen nieuwe blinde vlekken zijn geïntroduceerd door te controleren of bekende aanvalspatronen nog steeds alerts triggeren
• Promoveer naar prevention mode met vertrouwen

Fase 5: Doorlopende governance

WAF-analyse is geen eenmalig project. Applicaties veranderen, nieuwe endpoints worden uitgerold, Microsoft werkt managed rule sets bij, en dreigingspatronen evolueren. Een duurzame methodologie omvat:

• Regelmatige review-cadans: maandelijkse of kwartaalgewijze loganalyse om nieuwe false positive-patronen of configuratiedrift op te vangen
• Change-integratie: WAF policy reviews als onderdeel van de applicatie-deploymentpipeline, niet als bijzaak
• Metrics en rapportage: volg false positive rates, rule coverage en mean time to tune als KPI’s

Waarom dit verder gaat dan security

Een goed afgestelde WAF doet meer dan aanvallen blokkeren. Het geeft je operationeel vertrouwen.

Applicatieteams vertrouwen de WAF in plaats van ertegen te vechten. Security teams kunnen zich richten op echte dreigingen in plaats van ruis te triagen. Compliance-auditors zien gedocumenteerde, onderbouwde controls in plaats van standaardconfiguraties met onverklaarde uitzonderingen.

Voor organisaties die onder NIS2 of vergelijkbare regelgevende kaders vallen, is een gedocumenteerde WAF-methodologie precies het soort “passende en evenredige” technische maatregel dat auditors willen zien. Het toont aan dat security controls niet alleen uitgerold zijn: ze worden begrepen, onderhouden en continu verbeterd.

Azure docs: WAF best practices · Microsoft Sentinel overview

Aan de slag

Je hoeft deze methodologie niet from scratch op te bouwen. Begin met wat je hebt:

1. Exporteer je huidige WAF logs uit Log Analytics. Zelfs een week aan data geeft je een startpunt.
2. Identificeer de top 10 meest getriggerde regels. Bepaal voor elke regel of het een true positive, false positive of ruis is.
3. Documenteer je huidige WAF-configuratie. Welke regels zijn ingeschakeld? Welke zijn uitgesloten? Weet iemand waarom?
4. Stel een review-cadans in. Zelfs maandelijkse reviews zijn een enorme verbetering ten opzichte van de deploy-and-forget-aanpak.

Het doel is geen perfectie: het is een herhaalbaar proces dat na verloop van tijd verbetert. Elke onderneming waarmee we werken die een gestructureerde aanpak hanteert, ziet meetbare verbeteringen: minder false positives, snellere tuningcycli en WAF policies die het team daadwerkelijk begrijpt en vertrouwt.

Je WAF is maar zo goed als de methodologie erachter. Maak er werk van.

Meer van de blog

5 september 2024 | 6 min leestijd

Terraform AzureRM 4.0: wat breekt er en hoe migreer je

Azure Terraform DevOps

15 februari 2024 | 7 min leestijd

Bicep vs Terraform, waarom wij standaard voor Terraform kiezen (en wanneer Bicep wint)

Azure Terraform Bicep

1 juni 2022 | 9 min leestijd

Container Apps vs AKS vs App Service: Een Besliskader

Azure Containers AKS