L1 BIO 13.01.01 ISO A.13.1.1 CIS 6.3

Network Access Deny-By-Default

📅 2025-10-30
•
⏱️ 8 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

Een netwerkbeveiligingsgroep (NSG) vormt in Azure de eerste verdedigingslinie tussen een werkbelasting en alles wat buiten het subnet gebeurt. De Nederlandse Baseline voor Veilige Cloud schrijft daarom voor dat elke NSG standaard uitgaat van blokkeren en alleen verkeer toestaat dat aantoonbaar noodzakelijk is voor de bedrijfsvoering. Een deny-by-default ontwerp dwingt beheerders om per protocol, poort en bron bewust een beslissing te nemen in plaats van generieke allow-all regels over te nemen uit testomgevingen of tijdelijke change requests. Het resultaat is een consistent Zero Trust patroon: elk nieuw inbound- of outboundpad moet expliciet worden aangevraagd, gedocumenteerd en gemonitord voordat er productiegegevens overheen mogen stromen. Deze aanpak sluit aan op BIO-paragraaf 13.01 over netwerksegmentatie en op de verwachtingen van toezichthouders die eisen dat overheidsnetwerken aantoonbaar minimaal geprivilegieerd zijn ingericht.

Aanbeveling
IMPLEMENTEER DENY-BY-DEFAULT
Risico zonder
High
Risk Score
8/10
Implementatie
4u (tech: 3u)
Van toepassing op:
✓ NSGs

Situaties waarin NSG's ontbreken, zwakke prioriteiten hanteren of slechts gedeeltelijk zijn gevuld komen in vrijwel elke audit naar voren. Een vergeten deny-regel maakt laterale beweging tussen workloads mogelijk, waardoor een enkel gecompromitteerde virtuele machine direct door kan springen naar beheernetwerken of databronnen met bijzondere persoonsgegevens. Daarnaast zorgt een open uitgaand profiel ervoor dat malware command-and-control verkeer kan opzetten zonder dat dit wordt gezien door firewalls buiten Azure. Ook vanuit complianceperspectief levert een ontbrekende standaard-deny problemen op: CIS Azure Control 6.3, ISO 27001 A.13.1.1 en de BIO 13.01.01 vragen allemaal om technische maatregelen die ongeautoriseerd netwerkverkeer blokkeren. Door deny-by-default als harde norm vast te leggen, voorkom je interpretatieverschillen tussen beheerafdelingen, breng je de totale hoeveelheid regels per NSG terug tot de strikt noodzakelijke set en verlaag je de Operationele TCO omdat incident response minder tijd kwijt is aan het terugzoeken van vergeten uitzonderingen.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Network

Implementatie

Deze maatregel borgt drie concrete resultaten. Ten eerste wordt elke NSG voorzien van een expliciete high-priority deny-all regel aan het einde van de inbound- en outboundtabellen, zodat de natuurlijke volgorde van Azure-regelverwerking daadwerkelijk resulteert in blokkeren. Ten tweede wordt voor elk toegestaan protocol exact vastgelegd waarom het nodig is, welke bron en bestemming gelden, welke service tag wordt gebruikt en binnen welk change- of architectuurdocument de uitzondering is goedgekeurd. Ten derde wordt logging naar een centrale Log Analytics-workspace verplicht gesteld zodat elk pakket dat door de NSG wordt geweigerd traceerbaar blijft en kan worden gekoppeld aan SOC-playbooks. Het bijbehorende PowerShell-script `code/azure/networking/network-access-deny-by-default.ps1` automatiseert de controles door alle NSG's in te lezen, de aanwezigheid van expliciete deny-regels te valideren, prioriteiten te controleren en afwijkingen direct te rapporteren. Daardoor ontstaat een herhaalbare kwaliteitscontrole voor zowel cloud engineers als auditors.

Monitoring

Gebruik PowerShell-script network-access-deny-by-default.ps1 (functie Invoke-Monitoring) – Het monitoringgedeelte van het script voert een volledige inventarisatie uit van alle NSG's in het geselecteerde abonnement, toetst of er een expliciete deny-all regel met prioriteit 4096 bestaat voor inbound én outbound verkeer en markeert afwijkingen direct met context zoals resourcegroep, gekoppeld subnet of netwerkinterface..

Gebruik PowerShell-script network-access-deny-by-default.ps1 (functie Test-Compliance).

Effectieve monitoring van een deny-by-default strategie begint met een actueel overzicht van alle netwerkbeveiligingsgroepen, inclusief verborgen artefacten die uit proof-of-concepts of oude migraties zijn blijven staan. Het monitoringproces controleert niet alleen of een NSG een blokkerende regel heeft, maar beoordeelt ook of de prioriteit logisch is opgebouwd en geen ruimte laat voor impliciete toestemmingen. Bij elke analyse wordt een baseline-lijst gebruikt waarin goedgekeurde services, bronranges en service tags zijn vastgelegd voor de betreffende workloadfamilie. Zodra het script een NSG vindt zonder afsluitende deny-regel, zonder logging of met overlappende allow-regels die effectief hetzelfde doen als een allow-all, wordt er een bevinding opgesteld inclusief remediatieadvies. Deze bevindingen worden opgeslagen in een centraal logboek (bij voorkeur Log Analytics of Defender for Cloud recommendations) zodat het Security Operations Center precies kan volgen waar de grootste risico's zich bevinden. Monitoring stopt niet bij structurele inventarisaties. In een volwassen organisatie wordt deny-by-default gekoppeld aan continue compliancecontroles. Defender for Cloud policies, Azure Policy initiatieven en het PowerShell-script vullen elkaar daarbij aan: policies voorkomen dat nieuwe NSG's zonder logging of zonder afsluitende deny worden aangemaakt, het script valideert periodiek de bestaande omgeving en rapporteert historische trends. SOC-analisten gebruiken de NSG-flowlogs om te bepalen of het aantal geblokkeerde pakketten significant afwijkt van de norm. Een plotselinge stijging kan duiden op een misconfiguratie (legitiem verkeer wordt geblokkeerd) of op een actieve aanval waarbij de NSG juist succesvol blokkeert. Het is daarom belangrijk dat de monitoringrunbooks beschrijven hoe afwijkingen worden geïnterpreteerd, welke dashboards worden gebruikt en welke escalatiepaden gelden richting applicatie-eigenaren. Naast technische signalen moet er ook aandacht zijn voor procesmonitoring. Iedere wijziging aan een NSG hoort gekoppeld te zijn aan een change ticket met een duidelijke motivatie en einddatum. Het monitoringproces controleert deze metadata door tags zoals `ChangeId`, `Owner` en `ExpiryDate` te vergelijken met het configuration management database (CMDB). Wanneer een tijdelijke uitzondering is verstreken krijgt het applicatieteam automatisch een notificatie dat de rule wordt verwijderd, waardoor het principe van tijdelijke toegang ook in het netwerksegment wordt toegepast. Deze combinatie van technische en procesmatige monitoring zorgt ervoor dat deny-by-default niet alleen een intentie is, maar een aantoonbaar werkend controlemechanisme binnen de hele Azure-tenant.

Compliance en Auditing

Een strikt deny-by-default patroon is onlosmakelijk verbonden met de complianceverplichtingen van Nederlandse publieke organisaties. De CIS Azure Benchmark control 6.3 vereist letterlijk dat alle virtuele netwerken worden beschermd met NSG's die standaard al het verkeer blokkeren, waarna alleen het strikt noodzakelijke verkeer expliciet wordt toegestaan. Auditors toetsen hierbij niet alleen op de aanwezigheid van de regel, maar ook op de wijze waarop uitzonderingen worden beschreven en periodiek worden herbeoordeeld. Binnen de Baseline Informatiebeveiliging Overheid (BIO) sluit deze maatregel aan op maatregel 13.01.01, waarin wordt geëist dat netwerksegmenten logisch zijn afgeschermd en dat er technische componenten aanwezig zijn die ongeautoriseerde verbindingen blokkeren. Zonder aantoonbare deny-regel is aan deze eis niet voldaan en moet een organisatie rekenen op herstelmaatregelen in het auditrapport. Ook ISO 27001, met name controle A.13.1.1 over netwerkbeveiliging, vraagt om formele scheiding tussen netwerken met verschillende vertrouwelijkheidsniveaus. Door NSG's standaard te laten blokkeren kunnen organisaties aantonen dat alleen geautoriseerde verbindingen worden toegestaan en dat er een traceerbaar proces bestaat om uitzonderingen goed te keuren. Deze documentatie is belangrijk voor ISO-audits en voor contractuele verplichtingen richting ketenpartners. Voor organisaties die onder NIS2 of de Wet digitale overheid vallen, telt deny-by-default mee als onderdeel van "state of the art" beveiligingsmaatregelen; toezichthouders verwachten dat een moderne cloudomgeving dit minimaal toepast. Omdat veel Nederlandse overheden werken met gevoelige of bijzondere persoonsgegevens onder de AVG, helpt deny-by-default bovendien om aan artikel 32 (passende technische maatregelen) te voldoen. Door uitsluitend noodzakelijk verkeer toe te staan en al het overige verkeer actief te blokkeren, kan bij een datalek of penetratietest direct worden aangetoond welke verdedigingslagen actief waren en welke verkeersstromen zijn tegengehouden. De logging die onderdeel is van deze maatregel is eveneens een belangrijk auditbewijs: logbestanden tonen aan dat blokkades daadwerkelijk hebben plaatsgevonden en hoe vaak uitzonderingen zijn gebruikt. Het is cruciaal dat deze logs minimaal zeven jaar worden bewaard, in lijn met de archief- en auditverplichtingen voor veel overheidsorganisaties. Auditing richt zich tot slot op de effectiviteit van het beheerproces. In controle-interviews wordt gevraagd hoe vaak regels worden herzien, of er automatische controles lopen (zoals het meegeleverde PowerShell-script of Azure Policy) en hoe bevindingen worden opgevolgd. Door het monitoringrapport periodiek te delen met CISO, proceseigenaren en het auditteam, ontstaat een sluitende PDCA-cyclus waarin bevindingen leiden tot concrete verbeteracties. Zo kan een auditor overtuigend worden aangetoond dat deny-by-default niet slechts een technische configuratie is, maar een doorlopend beheerd controlemechanisme binnen de Nederlandse Baseline voor Veilige Cloud.

Remediatie

Gebruik PowerShell-script network-access-deny-by-default.ps1 (functie Invoke-Remediation) – De remediatiemodus van het script kan geautomatiseerd een ontbrekende deny-all regel toevoegen en tegelijkertijd standaarddiagnostiek inschakelen zodat flowlogs direct naar de afgesproken Log Analytics-workspace worden gestreamd..

Wanneer uit monitoring blijkt dat een NSG geen expliciete blokkerende regel bevat, moet de herstelactie dezelfde dag nog worden uitgevoerd. Remediatie start altijd met een korte impactanalyse: welke workloads zijn gekoppeld aan de NSG, welke bedrijfsprocessen draaien erop en bestaan er tijdelijke uitzonderingen die mogelijk worden geraakt? Op basis van deze informatie plannen beheerders een implementatievenster waarin de deny-regel kan worden toegevoegd. Het bijgeleverde PowerShell-script ondersteunt dit proces door per NSG de ontbrekende regels te detecteren en met één opdracht een standaardtemplate te plaatsen waarin inbound- én outboundverkeer op prioriteit 4096 wordt geweigerd. Hierbij worden bestaande allow-regels ongemoeid gelaten, zodat de kans op productie-impact minimaal blijft. Na het toevoegen van de regel wordt direct gecontroleerd of logging is geactiveerd en of de NSG gekoppeld is aan de juiste subnetten en netwerkinterfaces. Elke wijziging wordt vastgelegd in het change management systeem met een verwijzing naar de beleidsmaatregel en een geplande reviewdatum. Vervolgens wordt de applicatie-eigenaar gevraagd om een korte functionele test uit te voeren (bij voorkeur via lokale debuginstellingen) om te verifiëren dat de dienst beschikbaar blijft. Mocht er legitiem verkeer zijn dat onbedoeld wordt geblokkeerd, dan wordt dit niet opgelost door de deny-regel te verwijderen, maar door een nauwkeurig gedefinieerde allow-regel met hogere prioriteit toe te voegen, inclusief documentatie van bron, bestemming en protocol. Een volwassen remediatieproces omvat ook preventieve stappen. Azure Policy definities worden ingezet om te verhinderen dat nieuwe NSG's zonder afsluitende deny worden uitgerold, en een GitOps-achtige aanpak zorgt ervoor dat wijzigingen aan NSG's alleen via versiebeheer plaatsvinden. Hierdoor is altijd inzichtelijk wie welke regel heeft toegevoegd en kan bij incidenten snel worden teruggedraaid. Daarnaast wordt aanbevolen om periodiek een tabletop-oefening te organiseren waarbij een scenario wordt uitgespeeld waarin een aanvaller misbruik maakt van ontbrekende deny-regels. Deze oefening dwingt teams om kritisch naar hun configuraties te kijken en versnelt de verwerking van toekomstige bevindingen. Tot slot moet remediatie worden afgerond met rapportage. Het SOC ontvangt een update waarin wordt uitgelegd welke NSG's zijn aangepast, hoeveel verbindingen nu actief worden geblokkeerd en welke lessons learned er zijn voor toekomstige implementaties. Deze rapportage wordt toegevoegd aan het auditdossier zodat aantoonbaar is dat bevindingen uit monitoring daadwerkelijk tot verbeteringen leiden. Door deze discipline consequent toe te passen, blijft deny-by-default geen eenmalig project maar een doorlopend beheerd onderdeel van de Nederlandse Baseline voor Veilige Cloud.

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
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Network Access Deny By Default .DESCRIPTION CIS Azure Foundations Benchmark - Control 6.3 Controleert deny-by-default network access policies. .NOTES Filename: network-access-deny-by-default.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 6.3 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Network [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Network Access Deny By Default" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } function Test-Compliance { $nsgs = Get-AzNetworkSecurityGroup -ErrorAction SilentlyContinue $result = @{ TotalNSGs = $nsgs.Count; DenyByDefault = 0 } foreach ($nsg in $nsgs) { $hasDefaultDeny = $nsg.SecurityRules | Where-Object { $_.Direction -eq 'Inbound' -and $_.Access -eq 'Deny' -and $_.Priority -ge 4000 } if ($hasDefaultDeny) { $result.DenyByDefault++ } } return $result } try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total NSGs: $($r.TotalNSGs)" -ForegroundColor White Write-Host "With Deny-by-Default: $($r.DenyByDefault)" -ForegroundColor $(if ($r.DenyByDefault -eq $r.TotalNSGs) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nNSGs: $($r.DenyByDefault)/$($r.TotalNSGs) with deny-by-default" } } catch { Write-Error $_; exit 1 } # ================================================================================ # Standaard Invoke-* Functions (Auto-generated) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert de configuratie #> [CmdletBinding()] param() Invoke-Remediation } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices if ($Monitoring) { $r = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total NSGs: $($r.TotalNSGs)" -ForegroundColor White Write-Host "With Deny-by-Default: $($r.DenyByDefault)" -ForegroundColor $(if ($r.DenyByDefault -eq $r.TotalNSGs) { 'Green' } else { 'Yellow' }) } else { $r = Test-Compliance Write-Host "`nNSGs: $($r.DenyByDefault)/$($r.TotalNSGs) with deny-by-default" } } catch { Write-Error $_; exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Dit is een monitoring-only control, remediation delegeert naar monitoring #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoring-only control" -ForegroundColor Yellow Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
High: Geen deny-by-default = over-permissive network. Lateral movement easy, unauthorized access. Compliance: CIS 6.3, Zero Trust, BIO 13.01. Het risico is hoog - network isolation.

Management Samenvatting

Network Access Deny-by-Default: Explicit deny-all NSG rule (whitelist approach - only explicitly allowed passes). Zero Trust network principle. Activatie: NSG → Add deny-all (lowest priority). Gratis. Verplicht CIS 6.3, Zero Trust, BIO 13.01. Implementatie: 3-4 uur. Fundamental Zero Trust network.