NSG Standaard Deny Rules

Deze instelling is essentieel voor het handhaven van een veilige netwerkarchitectuur en voorkomt bekende aanvalsvectoren door het afdwingen van beveiligingsbest practices. Een standaard deny-configuratie vormt de basis voor een Zero Trust-netwerkbenadering waarbij alleen expliciet geautoriseerd verkeer wordt doorgelaten, wat cruciaal is voor het voorkomen van laterale beweging door aanvallers en het beperken van de impact van potentiële beveiligingsincidenten.

Implementatie

Deze regel past de benodigde beveiligingsinstellingen toe via Azure Policy of handmatige configuratie om Network Security Groups te beschermen volgens actuele beveiligingsframeworks zoals CIS Benchmarks, BIO en ISO 27001. De configuratie zorgt ervoor dat alle NSG's een expliciete blokkeer alles-regel bevatten als laatste regel, waardoor alleen verkeer dat expliciet is toegestaan door eerdere regels wordt doorgelaten.

Vereisten

Het implementeren van standaard deny-regels in Azure Network Security Groups vertegenwoordigt een fundamentele paradigmaverschuiving in netwerkbeveiliging die een grondige voorbereiding en een uitgebreid begrip van de netwerkarchitectuur en beveiligingsvereisten vereist. Deze configuratie vormt de basis voor een Zero Trust-netwerkbenadering waarbij alleen expliciet geautoriseerd verkeer wordt doorgelaten en alle overige verkeer standaard wordt geblokkeerd, in tegenstelling tot traditionele netwerkbeveiligingsmodellen waarbij verkeer standaard wordt toegestaan tenzij expliciet wordt geblokkeerd. Deze benadering biedt superieure beveiliging tegen ongeautoriseerde toegang en laterale beweging door aanvallers, maar vereist zorgvuldige planning om ervoor te zorgen dat legitiem verkeer niet onterecht wordt geblokkeerd en dat de bedrijfsvoering niet wordt verstoord. Voordat organisaties beginnen met de implementatie, moeten zij beschikken over een aantal fundamentele vereisten die essentieel zijn voor een succesvolle, veilige en operationeel stabiele implementatie die de gewenste beveiligingsvoordelen realiseert zonder negatieve impact op de bedrijfsvoering. De eerste en meest fundamentele vereiste is de beschikbaarheid van Azure Network Security Groups binnen de organisatie en de bijbehorende beheersrechten die nodig zijn om deze effectief te kunnen configureren en beheren. NSG's kunnen worden toegepast op verschillende niveaus binnen de Azure-netwerkarchitectuur, wat organisaties aanzienlijke flexibiliteit biedt bij het implementeren van netwerkbeveiliging die past bij hun specifieke vereisten en beveiligingsdoelstellingen. Netwerkbeveiligingsgroepen kunnen worden gekoppeld aan netwerkinterfaces van individuele virtuele machines voor granulaire controle op systeemniveau, aan subnetten binnen virtuele netwerken voor gedecentraliseerde beveiliging op subnetniveau, of aan beide niveaus tegelijkertijd voor gelaagde beveiliging die meerdere beveiligingslagen biedt. Deze flexibiliteit maakt het mogelijk om beveiliging toe te passen op verschillende niveaus van de netwerkarchitectuur, afhankelijk van de specifieke vereisten, beveiligingsdoelstellingen, en operationele behoeften van de organisatie. Een gedifferentieerde aanpak waarbij zowel subnet-niveau als netwerkinterface-niveau beveiliging wordt toegepast, biedt verfijnde controle over netwerkverkeer en maakt het mogelijk om verschillende beveiligingsniveaus toe te passen voor verschillende workloads, wat resulteert in een meer veilige en flexibele netwerkarchitectuur. Organisaties moeten ervoor zorgen dat zij over de juiste Azure-abonnementen en -machtigingen beschikken om NSG's te kunnen maken, configureren, beheren, en monitoren. Dit omvat niet alleen de basisbeheersrechten voor netwerkresources, maar ook de machtigingen om regels toe te voegen, te wijzigen en te verwijderen, evenals de mogelijkheid om diagnostische instellingen te configureren voor uitgebreide monitoringdoeleinden die essentieel zijn voor het detecteren van beveiligingsincidenten en het snel reageren op bedreigingen. De vereiste machtigingen variëren afhankelijk van de gekozen implementatiemethode, waarbij Azure Policy implementatie aanvullende rechten vereist voor het beheren van beleidsdefinities en toewijzingen, en waarbij handmatige configuratie basisbeheersrechten vereist voor netwerkresources. Zonder deze basisvereisten is het onmogelijk om een effectieve standaard deny-configuratie te implementeren die voldoet aan de beveiligings- en operationele vereisten van de organisatie en die de gewenste beveiligingsvoordelen realiseert. Een tweede kritieke vereiste is een diepgaand en gedetailleerd inzicht in de netwerkarchitectuur en de verkeersstromen binnen de organisatie, omdat deze kennis de basis vormt voor het correct configureren van toestaan-regels die legitiem verkeer niet blokkeren terwijl ongeautoriseerd verkeer effectief wordt geblokkeerd. Voordat een standaard deny-configuratie kan worden geïmplementeerd, moeten organisaties een uitgebreide, systematische en methodische analyse uitvoeren van alle services die binnen hun Azure-omgeving draaien en hoe deze services met elkaar en met externe systemen communiceren. Deze analyse omvat het identificeren, documenteren en catalogiseren van alle applicaties, databases, opslagaccounts, API-services, container-workloads, serverloze functies, en andere services die netwerkverkeer genereren of ontvangen, evenals de afhankelijkheden tussen deze services. Voor elke service moet worden vastgesteld welke poorten en protocollen worden gebruikt voor communicatie, welke richting het verkeer heeft (inkomend of uitgaand), welke bron- en doel-IP-adressen betrokken zijn bij de communicatie, en welke services afhankelijk zijn van deze communicatie. Daarnaast moet worden geïdentificeerd welke services afhankelijk zijn van externe services, internetconnectiviteit, of andere Azure-services buiten het virtuele netwerk, en welke services alleen intern communiceren binnen het virtuele netwerk of tussen virtuele netwerken via peering-verbindingen. Deze gedetailleerde informatie is essentieel voor het correct configureren van NSG-regels die alleen legitiem verkeer toestaan en die ervoor zorgen dat alle services correct blijven functioneren na de implementatie van een standaard deny-configuratie. Zonder deze gedetailleerde informatie is het onmogelijk om de juiste toestaan-regels te configureren, wat zou leiden tot legitiem verkeer dat onterecht wordt geblokkeerd, serviceonderbrekingen die de bedrijfsvoering kunnen verstoren, gebruikersfrustratie, productiviteitsverlies, en mogelijk zelfs tot het omzeilen van beveiligingsmaatregelen door gefrustreerde teams die hun werk moeten kunnen uitvoeren. De analyse van netwerkverkeer moet ook uitgebreid rekening houden met dynamische aspecten van de netwerkarchitectuur die moderne cloudapplicaties kenmerken, omdat deze dynamische aspecten een uitdaging vormen voor traditionele netwerkbeveiliging die gebaseerd is op statische IP-adressen. Veel hedendaagse applicaties maken gebruik van geavanceerde netwerkcomponenten zoals load balancers, automatisch schalende groepen, containerorchestrators zoals Azure Kubernetes Service, serverloze computing platforms zoals Azure Functions, en andere dynamische componenten die kunnen leiden tot veranderende IP-adressen, fluctuerende verkeerspatronen, en wijzigende netwerktopologieën. Deze dynamische aspecten vereisen moderne aanpakken die flexibel kunnen omgaan met veranderende netwerkconfiguraties zonder dat beveiligingsregels constant moeten worden bijgewerkt. Organisaties moeten deze dynamische aspecten volledig begrijpen en hun NSG-regels dienovereenkomstig configureren om ervoor te zorgen dat services correct blijven functioneren zelfs wanneer IP-adressen of netwerkconfiguraties veranderen als gevolg van automatische schaling, failover-scenario's, of andere operationele wijzigingen. Dit kan worden bereikt door gebruik te maken van Azure-servicetags die logische groepen van IP-adressen vertegenwoordigen die worden gebruikt door specifieke Azure-services zoals Azure Storage of Azure SQL Database, of door gebruik te maken van applicatiebeveiligingsgroepen die logische groeperingen van netwerkinterfaces mogelijk maken ongeacht hun specifieke IP-adressen. Deze moderne aanpakken maken het mogelijk om beveiligingsregels te definiëren op basis van logische groeperingen en servicetypen in plaats van specifieke IP-adressen, wat resulteert in meer flexibele, onderhoudbare en schaalbare netwerkbeveiligingsconfiguraties die meegroeien met de organisatie. Dit vereist een goed begrip van Azure-netwerkconcepten, de mogelijkheden die het platform biedt voor flexibele en schaalbare netwerkbeveiliging, en best practices voor het configureren van NSG-regels in dynamische cloudomgevingen. Zonder dit begrip kunnen organisaties aanzienlijke problemen ondervinden met services die niet correct functioneren na de implementatie van een standaard deny-configuratie, wat kan leiden tot kostbare serviceonderbrekingen, gebruikersfrustratie, productiviteitsverlies, en een negatieve perceptie van beveiligingsmaatregelen die de adoptie van belangrijke beveiligingsinitiatieven kan belemmeren. Een derde essentiële vereiste is uitgebreide en actuele documentatie van de huidige netwerkconfiguratie en de beoogde wijzigingen die zullen worden doorgevoerd tijdens de implementatie van een standaard deny-configuratie, omdat deze documentatie de basis vormt voor effectieve planning, communicatie met stakeholders, en toekomstig onderhoud van de netwerkbeveiligingsconfiguratie. De documentatie moet een complete en gedetailleerde inventarisatie bevatten van alle bestaande NSG's binnen de Azure-omgeving en hun huidige regels, inclusief de prioriteiten, bron- en doeladressen, poorten, protocollen, acties (toestaan of weigeren), en de reden waarom elke regel bestaat, evenals de services en workloads die door elke regel worden beschermd. Daarnaast moet de documentatie een duidelijk en begrijpelijk overzicht bevatten van de netwerktopologie, waarbij wordt aangegeven hoe verschillende subnetten, virtuele netwerken, peering-verbindingen, VPN-gateways, ExpressRoute-verbindingen, en services met elkaar zijn verbonden en hoe verkeer tussen deze componenten stroomt. Een visuele weergave van de netwerkarchitectuur in de vorm van netwerkdiagrammen, architectuurmodellen, of geautomatiseerde netwerkvisualisaties kan hierbij zeer waardevol zijn voor het begrijpen van de verkeersstromen, afhankelijkheden tussen services, en de impact van beveiligingswijzigingen op verschillende delen van de netwerkarchitectuur. Deze documentatie is essentieel voor het plannen van de implementatie, het identificeren van potentiële risico's en uitdagingen, het ontwikkelen van migratiestrategieën, en het vermijden van serviceonderbrekingen tijdens de migratie naar een standaard deny-configuratie. Bovendien helpt uitgebreide documentatie bij het verkrijgen van goedkeuring van stakeholders die moeten begrijpen waarom deze wijzigingen nodig zijn en wat de impact zal zijn op de bedrijfsvoering. De documentatie moet ook een gedetailleerde beschrijving bevatten van alle verkeersstromen tussen verschillende netwerksegmenten en services, inclusief de reden waarom elk verkeerspatroon nodig is voor de bedrijfsvoering, welke services afhankelijk zijn van deze communicatie, wat de gevolgen zouden zijn als deze communicatie wordt geblokkeerd, en welke alternatieve communicatiepaden beschikbaar zijn indien nodig. Deze informatie is essentieel voor het plannen van de implementatie, het configureren van correcte toestaan-regels, het ontwikkelen van testscenario's, en het verkrijgen van goedkeuring van stakeholders die moeten begrijpen waarom bepaalde netwerkverbindingen noodzakelijk zijn en wat de risico's zijn van het blokkeren van deze verbindingen. Bovendien helpt goede en uitgebreide documentatie bij het trainen van nieuwe teamleden die moeten begrijpen hoe de netwerkbeveiliging werkt en hoe deze moet worden onderhouden, het uitvoeren van regelmatige audits en compliance-verificaties die aantonen dat de netwerkbeveiliging voldoet aan relevante standaarden en regelgeving zoals BIO, ISO 27001, en CIS Benchmarks, en het onderhouden van de configuratie op lange termijn wanneer services worden toegevoegd, gewijzigd of verwijderd. Zonder adequate en actuele documentatie kunnen organisaties aanzienlijke problemen ondervinden bij het begrijpen van de impact van wijzigingen, bij het oplossen van problemen wanneer deze zich voordoen, bij het uitvoeren van effectieve audits, en bij het handhaven van een effectieve netwerkbeveiligingsconfiguratie die meegroeit met de organisatie en die blijft voldoen aan veranderende beveiligings- en operationele vereisten. Een vierde belangrijke vereiste is de beschikbaarheid van testomgevingen waarin de nieuwe configuratie eerst uitgebreid kan worden gevalideerd voordat deze wordt doorgevoerd in productieomgevingen waar serviceonderbrekingen aanzienlijke gevolgen kunnen hebben voor de bedrijfsvoering, gebruikerservaring, en bedrijfsresultaten. Deze testomgevingen moeten zo veel mogelijk lijken op de productieomgeving om realistische testresultaten te kunnen verkrijgen die een betrouwbare voorspelling geven van hoe de configuratie zal functioneren in productie, inclusief dezelfde netwerkarchitectuur, services, verkeerspatronen, workload-configuraties, en gebruikersgedrag. Door eerst uitgebreid te testen in een gecontroleerde omgeving kunnen organisaties potentiële problemen identificeren en oplossen zonder impact op de productieomgeving en de gebruikers die afhankelijk zijn van de services, wat resulteert in een soepelere en succesvollere implementatie in productie. Dit voorkomt onbedoelde serviceonderbrekingen die kunnen leiden tot productiviteitsverlies, gebruikersfrustratie, reputatieschade, financiële gevolgen, en mogelijk zelfs tot verlies van vertrouwen in de IT-organisatie en beveiligingsmaatregelen. Bovendien stelt een testomgeving beheerders in staat om vertrouwd te raken met het beheer van een toegestane lijst-gebaseerde netwerkconfiguratie en de bijbehorende uitdagingen, best practices, en oplossingsstrategieën, wat resulteert in meer zelfverzekerde, effectieve, en efficiënte implementaties in productie. De testomgeving moet ook worden gebruikt voor het valideren van monitoring- en waarschuwingsconfiguraties die essentieel zijn voor het detecteren van problemen, het identificeren van beveiligingsincidenten, en het snel reageren op bedreigingen, zodat organisaties ervoor kunnen zorgen dat hun monitoring- en responsprocessen correct functioneren voordat ze worden toegepast in productie waar de impact van problemen en beveiligingsincidenten aanzienlijk groter is en waar snelle detectie en respons cruciaal zijn voor het beperken van schade. Tot slot moeten organisaties beschikken over de juiste technische expertise en voldoende resources om een standaard deny-configuratie effectief te kunnen implementeren en te onderhouden gedurende de levensduur van de netwerkarchitectuur, omdat deze configuratie continue aandacht en onderhoud vereist om effectief te blijven en om te blijven voldoen aan veranderende beveiligings- en operationele vereisten. Dit omvat niet alleen basiskennis van Azure-netwerkconcepten, NSG-configuratie, en netwerkbeveiligingsprincipes, maar ook geavanceerde expertise in netwerkarchitectuur, beveiligingsbest practices, het oplossen van complexe netwerkproblemen, en het ontwikkelen van effectieve monitoring- en responsstrategieën. Organisaties moeten ook beschikken over voldoende tijd en resources om de implementatie zorgvuldig en methodisch uit te voeren, inclusief uitgebreide planning, testing, validatie, documentatie, en training van teamleden die betrokken zijn bij het beheer en onderhoud van de configuratie. Het is belangrijk om te erkennen dat een standaard deny-configuratie een fundamentele wijziging vertegenwoordigt in de netwerkbeveiligingsaanpak die zorgvuldige planning, methodische uitvoering, continue monitoring, regelmatige evaluatie, en voortdurende aandacht vereist om succesvol te zijn en de gewenste beveiligingsvoordelen te realiseren op lange termijn. Zonder de juiste expertise en resources kunnen organisaties aanzienlijke problemen ondervinden die leiden tot serviceonderbrekingen, onvoldoende beveiliging, configuraties die moeilijk te onderhouden zijn, en problemen die op lange termijn de effectiviteit van de beveiligingsmaatregelen kunnen ondermijnen en die de organisatie kunnen blootstellen aan beveiligingsrisico's.

Monitoring

Gebruik PowerShell-script nsg-default-deny-rules.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van Network Security Groups met standaard deny-regels is essentieel voor het behouden van netwerkbeveiliging en het identificeren van potentiële bedreigingen. Een effectief monitoringprogramma voor NSG's omvat continue bewaking van verkeersstromen, regelwijzigingen, en beveiligingsincidenten die kunnen wijzen op pogingen tot ongeautoriseerde toegang of misbruik van netwerkresources. Zonder adequate monitoring kunnen organisaties niet effectief reageren op beveiligingsbedreigingen en kunnen zij niet verifiëren dat hun netwerkbeveiligingsconfiguratie correct functioneert en bescherming biedt tegen zowel bekende als onbekende bedreigingen. Monitoring vormt daarom een kritieke component van een complete netwerkbeveiligingsstrategie en moet worden beschouwd als een continu proces dat regelmatige evaluatie en verbetering vereist. De basis voor monitoring van NSG-configuraties begint met het inschakelen van diagnostische instellingen voor Network Security Groups. Azure biedt uitgebreide loggingmogelijkheden via Network Watcher, waarmee organisaties gedetailleerde informatie kunnen verzamelen over al het verkeer dat door NSG's wordt gefilterd. Deze logs bevatten waardevolle informatie zoals bron- en doel-IP-adressen, poorten, protocollen, en de actie die is ondernomen (toestaan of weigeren). Door deze logs te analyseren kunnen beveiligingsteams patronen identificeren, zoals herhaalde pogingen tot toegang vanaf specifieke IP-adressen, ongebruikelijke verkeersstromen die kunnen wijzen op gecompromitteerde systemen, of pogingen om toegang te krijgen tot services die niet bestaan. Deze analyse vormt de basis voor proactieve beveiligingsmaatregelen en helpt organisaties om bedreigingen te identificeren voordat zij schade kunnen aanrichten. Het is belangrijk om deze logs regelmatig te analyseren en trends te identificeren die kunnen wijzen op opkomende bedreigingen of veranderingen in het aanvalslandschap. Een belangrijk onderdeel van monitoring is het volgen van wijzigingen in NSG-regels. Elke wijziging aan een NSG-configuratie kan de beveiligingspostuur van het netwerk beïnvloeden, en ongeautoriseerde wijzigingen kunnen leiden tot onbedoelde blootstelling van services of het openen van kwetsbaarheden. Organisaties moeten Azure Activity Logs gebruiken om alle wijzigingen aan NSG's te monitoren en waarschuwingen configureren die waarschuwen wanneer regels worden toegevoegd, verwijderd of gewijzigd. Deze waarschuwingen moeten worden geconfigureerd om onmiddellijk te rapporteren aan beveiligingsteams, zodat ongeautoriseerde wijzigingen snel kunnen worden gedetecteerd en teruggedraaid voordat ze schade kunnen aanrichten. Het is belangrijk om een proces te hebben voor het goedkeuren en documenteren van wijzigingen, zodat alle wijzigingen kunnen worden getraceerd en verantwoord kunnen worden. Dit helpt niet alleen bij het voorkomen van ongeautoriseerde wijzigingen, maar ook bij het begrijpen van de impact van wijzigingen op de netwerkbeveiliging en bij het uitvoeren van audits en compliance-verificaties. Het analyseren van geblokkeerd verkeer is eveneens cruciaal voor het identificeren van potentiële bedreigingen. Wanneer een standaard deny-configuratie correct is geïmplementeerd, wordt een aanzienlijk percentage van het verkeer geblokkeerd door de blokkeer alles-regel. Het monitoren van dit geblokkeerde verkeer kan waardevolle inzichten opleveren over aanvalspogingen, gescande poorten, en potentiële kwetsbaarheden die aanvallers proberen te misbruiken. Beveiligingsteams moeten regelmatig analyses uitvoeren van geblokkeerd verkeer om patronen te identificeren, zoals geografische concentraties van aanvalspogingen, veelvuldige scans van specifieke poorten, of herhaalde pogingen vanaf dezelfde IP-adressen. Deze analyses kunnen helpen bij het identificeren van georganiseerde aanvalscampagnes en het ontwikkelen van gerichte verdedigingsstrategieën. Door deze patronen te begrijpen kunnen organisaties hun beveiligingsmaatregelen aanpassen om effectiever te zijn tegen specifieke bedreigingen en kunnen zij proactief maatregelen nemen om toekomstige aanvallen te voorkomen. Voor gedetailleerde informatie over het monitoren van netwerktoegang en standaard deny-configuraties, verwijzen wij naar het artikel over network-access-deny-by-default. Dit artikel bevat uitgebreide informatie over monitoringstrategieën, best practices voor loganalyse, en aanbevelingen voor het configureren van waarschuwingen en responsprocessen. Het artikel behandelt ook geavanceerde monitoringtechnieken, zoals het gebruik van Azure Sentinel of andere SIEM-systemen voor geavanceerde bedreigingsdetectie en correlatie van beveiligingsgebeurtenissen. Door gebruik te maken van deze aanvullende informatie kunnen organisaties hun monitoringstrategie verder versterken en ervoor zorgen dat zij optimaal beschermd zijn tegen netwerkbedreigingen.

Compliance en Auditing

De implementatie van standaard deny-regels in Azure Network Security Groups draagt direct en significant bij aan de naleving van verschillende belangrijke beveiligingsstandaarden en frameworks die wereldwijd worden erkend en gebruikt door organisaties in zowel de publieke als private sector. Deze configuratie vormt een fundamentele beveiligingsmaatregel die niet alleen de netwerkbeveiliging verbetert, maar ook aantoont dat organisaties serieus omgaan met hun verantwoordelijkheden op het gebied van informatiebeveiliging en compliance. Door een standaard deny-configuratie te implementeren, maken organisaties duidelijk dat zij bereid zijn om de benodigde beveiligingsmaatregelen te nemen om hun systemen en gegevens te beschermen. Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid (BIO) van groot belang en vormt deze de leidraad voor informatiebeveiliging binnen de Nederlandse publieke sector. De BIO is gebaseerd op de internationale ISO/IEC 27001 en ISO/IEC 27002 standaarden, maar is aangepast aan de specifieke context en vereisten van Nederlandse overheidsorganisaties. BIO maatregel 13.01 specificeert expliciet dat netwerksegmentatie en toegangscontrole moeten worden geïmplementeerd om ongeautoriseerde toegang te voorkomen. Deze maatregel maakt deel uit van het beveiligingsdomein 'Netwerkbeveiliging' en benadrukt het belang van het scheiden van netwerksegmenten en het controleren van verkeer tussen deze segmenten. Een standaard deny-configuratie met een toegestane lijst-benadering voldoet direct aan deze maatregel door ervoor te zorgen dat alleen geautoriseerd verkeer tussen netwerksegmenten kan stromen, wat een essentiële beveiligingsmaatregel is voor het voorkomen van laterale beweging door aanvallers en het beperken van de impact van potentiële beveiligingsincidenten. Organisaties die voldoen aan BIO maatregel 13.01 kunnen aantonen dat zij adequate netwerkbeveiligingsmaatregelen hebben geïmplementeerd die essentieel zijn voor het beschermen van hun cloudomgevingen tegen netwerkbedreigingen. De ISO/IEC 27001 standaard, met name beheerdoelstelling A.8.20 (Netwerkbeveiliging), vereist dat organisaties beveiligingsmaatregelen implementeren voor netwerkbeheer om ervoor te zorgen dat netwerken adequaat worden beheerd en beveiligd. Deze beheerdoelstelling maakt deel uit van het beveiligingsdomein 'Communicatiebeveiliging' en benadrukt het belang van het beheren van netwerkbeveiliging als een integraal onderdeel van de algehele informatiebeveiligingsstrategie. Dit omvat het gebruik van firewalls en netwerksegmentatie om ongeautoriseerde toegang te voorkomen, het monitoren van netwerkverkeer om verdachte activiteiten te detecteren, en het implementeren van netwerkbeveiligingsbeleid dat consistent is met de algehele beveiligingsdoelstellingen van de organisatie. Een standaard deny NSG-configuratie implementeert deze vereiste door netwerkverkeer te controleren en te filteren op basis van expliciete regels, wat een fundamentele beveiligingsmaatregel is voor netwerkbeheer in cloudomgevingen. Organisaties die voldoen aan ISO 27001:2022 A.8.20 kunnen aantonen dat zij adequate netwerkbeveiligingsmaatregelen hebben geïmplementeerd die consistent zijn met internationale best practices voor informatiebeveiliging. Het Zero Trust-principe, ook wel aangeduid als 'nul vertrouwen', vormt de fundamentele filosofie achter een standaard deny-configuratie en is een van de belangrijkste moderne beveiligingsparadigma's. Zero Trust gaat uit van het uitgangspunt dat niets automatisch wordt vertrouwd, ongeacht de locatie binnen of buiten het netwerk, de identiteit van de gebruiker, of de status van het apparaat. Alle verkeer moet expliciet worden geautoriseerd en geverifieerd voordat toegang wordt verleend, en deze autorisatie moet continu worden geëvalueerd op basis van contextuele informatie zoals gebruikersgedrag, apparaatstatus, en netwerklocatie. Een standaard deny NSG-configuratie implementeert dit principe op netwerkniveau door te voorkomen dat onbekend of ongeautoriseerd verkeer automatisch wordt doorgelaten, wat een cruciale eerste stap is in een Zero Trust-architectuur. Door een standaard deny-configuratie te implementeren, maken organisaties duidelijk dat zij het Zero Trust-principe serieus nemen en bereid zijn om de benodigde beveiligingsmaatregelen te implementeren om dit principe in de praktijk te brengen. Naast deze internationale standaarden zijn er ook sector-specifieke compliance-vereisten die relevant kunnen zijn voor organisaties die een standaard deny-configuratie implementeren. Voor organisaties in de financiële sector kunnen bijvoorbeeld de vereisten van de Autoriteit Financiële Markten (AFM) of de Europese Bankautoriteit (EBA) relevant zijn. Voor organisaties in de gezondheidszorg kunnen de vereisten van de NEN 7510 standaard of de AVG relevant zijn. Een standaard deny-configuratie kan bijdragen aan de naleving van deze sector-specifieke vereisten door te zorgen voor een fundamenteel veilige netwerkarchitectuur die bescherming biedt tegen ongeautoriseerde toegang tot gevoelige gegevens. Door het implementeren van een standaard deny-configuratie kunnen organisaties aantonen aan auditors, stakeholders, en regelgevers dat zij serieus omgaan met netwerkbeveiliging en bereid zijn om de benodigde maatregelen te nemen om hun systemen en gegevens te beschermen. Dit kan bijdragen aan het opbouwen van vertrouwen bij klanten, partners, en andere belanghebbenden, wat van groot belang is voor het succes van moderne organisaties in een steeds meer gedigitaliseerde wereld.

Remediatie

Gebruik PowerShell-script nsg-default-deny-rules.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring aangeeft dat een Network Security Group niet correct is geconfigureerd met standaard deny-regels, is onmiddellijke remediatie noodzakelijk om de netwerkbeveiliging te herstellen. Het remediatieproces voor NSG-configuraties vereist een gestructureerde aanpak waarbij eerst de huidige staat wordt geanalyseerd, vervolgens de vereiste wijzigingen worden geïdentificeerd, en daarna de configuratie wordt bijgewerkt met minimale impact op bedrijfsoperaties. Een effectief remediatieproces zorgt ervoor dat de netwerkbeveiliging snel wordt hersteld zonder onbedoelde serviceonderbrekingen of beveiligingskwetsbaarheden te introduceren. Het remediatieproces begint met een grondige analyse van de huidige NSG-configuratie. Dit omvat het inventariseren van alle NSG's in de Azure-omgeving, het documenteren van de huidige regels voor elke NSG, en het identificeren van ontbrekende of onjuist geconfigureerde weiger-regels. Tijdens deze analyse moet speciale aandacht worden besteed aan NSG's die een impliciete toestaan-alles regel hebben of die geen expliciete blokkeer alles-regel bevatten als laatste regel. Deze configuraties vormen een significant beveiligingsrisico omdat ze ongeautoriseerd verkeer kunnen doorlaten. De analyse moet ook rekening houden met de specifieke vereisten van de services die door elke NSG worden beschermd, om ervoor te zorgen dat remediatie geen negatieve impact heeft op legitieme verkeersstromen. Na het identificeren van afwijkingen moet een remediatieplan worden ontwikkeld dat specifiek is voor elke NSG. Dit plan moet rekening houden met de specifieke vereisten van de services die door de NSG worden beschermd, de verwachte verkeerspatronen, en de afhankelijkheden tussen verschillende netwerksegmenten. Het is belangrijk om tijdens het plannen van remediatie te voorkomen dat legitiem verkeer onterecht wordt geblokkeerd, wat kan leiden tot serviceonderbrekingen en operationele problemen. Daarom moet het remediatieplan eerst worden gevalideerd in een testomgeving voordat het wordt toegepast in productie. Deze validatie helpt bij het identificeren van potentiële problemen en het verzekeren dat alle services correct blijven functioneren na remediatie. De implementatie van remediatie begint met het configureren van de benodigde toestaan-regels voor elk netwerksegment. Deze regels moeten worden gebaseerd op een grondige analyse van legitieme verkeersstromen, waarbij rekening wordt gehouden met zowel de huidige operationele vereisten als toekomstige uitbreidingsmogelijkheden. Het is belangrijk om tijdens deze fase gedetailleerde documentatie bij te houden van alle toestaan-regels, inclusief de reden voor elke regel, de betrokken services, en eventuele afhankelijkheden. Deze documentatie is essentieel voor toekomstig onderhoud en auditdoeleinden. De toestaan-regels moeten worden georganiseerd op basis van prioriteit, waarbij de meest specifieke regels de hoogste prioriteit krijgen en algemene regels een lagere prioriteit. Na het configureren van alle benodigde toestaan-regels moet als laatste stap een blokkeer alles-regel worden toegevoegd met de laagst mogelijke prioriteit. In Azure NSG's is de hoogste prioriteitswaarde 4096, wat betekent dat deze regel als laatste wordt geëvalueerd na alle andere regels. Deze regel moet worden geconfigureerd om al het verkeer te blokkeren, ongeacht bron, bestemming, poort, of protocol. Deze regel zorgt ervoor dat al het verkeer dat niet expliciet door eerdere toestaan-regels wordt toegestaan, standaard wordt geblokkeerd. Het is cruciaal om ervoor te zorgen dat deze regel correct wordt geconfigureerd en dat alle toestaan-regels een lagere prioriteit hebben, zodat zij eerst worden geëvalueerd. Tijdens het implementatieproces is continue monitoring essentieel om te verifiëren dat de remediatie succesvol is en dat legitiem verkeer niet wordt geblokkeerd. Beveiligingsteams moeten de NSG-logs nauwlettend volgen na het toepassen van remediatie, op zoek naar ongebruikelijke patronen of indicatoren dat services niet correct functioneren. Als problemen worden gedetecteerd, moeten ze onmiddellijk worden aangepakt door de toestaan-regels aan te passen of aanvullende regels toe te voegen. Het is belangrijk om een proces te hebben voor het snel oplossen van problemen, zodat serviceonderbrekingen worden geminimaliseerd en de impact op de bedrijfsvoering beperkt blijft. Deze monitoring moet worden voortgezet gedurende een periode na de remediatie om ervoor te zorgen dat alle services correct blijven functioneren en dat geen onbedoelde problemen optreden. In sommige gevallen kan remediatie complexer zijn wanneer meerdere NSG's met elkaar verbonden zijn of wanneer services afhankelijk zijn van specifieke verkeerspatronen die moeilijk te identificeren zijn. In deze situaties kan een gefaseerde aanpak nodig zijn, waarbij eerst kritieke NSG's worden geremedieerd, gevolgd door minder kritieke NSG's. Tijdens elke fase moet de impact worden geëvalueerd en moet worden verzekerd dat alle services correct blijven functioneren voordat wordt overgegaan naar de volgende fase. Deze gefaseerde aanpak helpt bij het minimaliseren van risico's en het verzekeren dat remediatie succesvol wordt uitgevoerd zonder onbedoelde negatieve gevolgen. Na succesvolle remediatie moeten organisaties een validatieproces uitvoeren om te verifiëren dat alle NSG's correct zijn geconfigureerd. Dit omvat het uitvoeren van beveiligingsscans om te controleren dat ongeautoriseerd verkeer daadwerkelijk wordt geblokkeerd, het testen van alle kritieke services om te verifiëren dat ze correct functioneren, en het beoordelen van de NSG-configuraties tegen de oorspronkelijke beveiligingsvereisten. Eventuele afwijkingen die tijdens deze validatie worden geïdentificeerd, moeten onmiddellijk worden gecorrigeerd. Tot slot is het belangrijk om na remediatie een proces op te zetten voor continue verbetering. Dit omvat regelmatige reviews van NSG-configuraties, het bijwerken van regels wanneer services worden gewijzigd of toegevoegd, en het monitoren van nieuwe bedreigingen die mogelijk aanvullende regels vereisen. Door een proactieve benadering te hanteren kunnen organisaties ervoor zorgen dat hun NSG-configuraties effectief blijven en bescherming bieden tegen zowel huidige als toekomstige bedreigingen.

Compliance & Frameworks

• BIO: 13.01 - Standaard deny-configuratie voor netwerkbeveiliging
• ISO 27001:2022: A.8.20 - Netwerkbeveiliging en toegangscontrole

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

Alternatieve verificatie voor NSG standaard deny-configuratie. Zie nsg-default-deny-all.json voor volledige implementatie met een expliciete blokkeer alles-regel. Deze configuratie is verplicht voor Zero Trust-implementatie en vormt de basis voor een veilige netwerkarchitectuur waarbij alleen expliciet geautoriseerd verkeer wordt doorgelaten.

• Implementatietijd: 5 uur
• FTE required: 0.05 FTE