Azure NSG: Standaard Deny Alle Verkeer (Whitelist Benadering)

Een standaard deny-configuratie vormt de basis voor minimaal benodigde rechten bij netwerktoegang. Met een whitelist-benadering wordt alleen expliciet geautoriseerd verkeer doorgelaten, zoals HTTPS-verkeer op poort 443 naar de web-laag of SQL-verkeer op poort 1433 naar de database-laag. Een blacklist-benadering is fundamenteel onveilig, omdat aanvallers eenvoudig niet-standaard poorten kunnen gebruiken om de blacklist te omzeilen. Bovendien zorgt gelaagde beveiliging ervoor dat een verkeerd geconfigureerde allow-regel slechts een beperkte impact heeft, in tegenstelling tot een 'allow all' regel die het gehele netwerk blootstelt.

Implementatie

Een standaard deny NSG-configuratie werkt als volgt: voor inkomend verkeer wordt alles standaard geweigerd, behalve expliciet toegestaan verkeer per service. Voor uitgaand verkeer wordt alles standaard geweigerd, behalve expliciet toegestane bestemmingen, om command-and-control-communicatie van kwaadaardige software te voorkomen. De prioriteit van NSG-regels werkt omgekeerd: een laag nummer betekent een hoge prioriteit, waardoor toestaan-regels altijd eerst worden geëvalueerd. De laatste regel in elke NSG moet een blokkeer alles-regel zijn die alle overige verkeer blokkeert.

Vereisten

Het implementeren van een standaard deny-configuratie in Azure Network Security Groups vereist een grondige voorbereiding en een goed begrip van de netwerkarchitectuur. Deze configuratie vormt de basis voor een Zero Trust-netwerkbenadering waarbij alleen expliciet geautoriseerd verkeer wordt doorgelaten. Voordat organisaties beginnen met de implementatie, moeten zij beschikken over een aantal fundamentele vereisten die essentieel zijn voor een succesvolle en veilige implementatie. De eerste en meest fundamentele vereiste is de beschikbaarheid van Azure Network Security Groups binnen de organisatie. NSG's kunnen worden toegepast op netwerkinterfaces van virtuele machines, op subnetten binnen virtuele netwerken, of op beide niveaus voor gelaagde beveiliging. Deze flexibiliteit maakt het mogelijk om beveiliging toe te passen op verschillende niveaus van de netwerkarchitectuur, afhankelijk van de specifieke vereisten van de organisatie. Organisaties moeten ervoor zorgen dat zij over de juiste Azure-abonnementen en -machtigingen beschikken om NSG's te kunnen maken, configureren en beheren. Dit omvat ook de machtigingen om regels toe te voegen, te wijzigen en te verwijderen, evenals de mogelijkheid om diagnostische instellingen te configureren voor monitoringdoeleinden. Een tweede kritieke vereiste is een diepgaand inzicht in de netwerkarchitectuur en de verkeersstromen binnen de organisatie. Voordat een standaard deny-configuratie kan worden geïmplementeerd, moeten organisaties een uitgebreide analyse uitvoeren van alle services die binnen hun Azure-omgeving draaien en hoe deze services met elkaar communiceren. Dit omvat het identificeren van alle applicaties, databases, opslagaccounts, en andere services die netwerkverkeer genereren of ontvangen. Voor elke service moet worden vastgesteld welke poorten en protocollen worden gebruikt, welke richting het verkeer heeft (inkomend of uitgaand), en welke bron- en doel-IP-adressen betrokken zijn bij de communicatie. Zonder deze gedetailleerde informatie is het onmogelijk om de juiste toestaan-regels te configureren, wat zou leiden tot legitiem verkeer dat onterecht wordt geblokkeerd en tot serviceonderbrekingen die de bedrijfsvoering kunnen verstoren. De analyse van netwerkverkeer moet ook rekening houden met dynamische aspecten van de netwerkarchitectuur. Veel moderne applicaties maken gebruik van load balancers, automatisch schalende groepen, en andere dynamische componenten die kunnen leiden tot veranderende IP-adressen en verkeerspatronen. Organisaties moeten deze dynamische aspecten begrijpen en hun NSG-regels dienovereenkomstig configureren, bijvoorbeeld door gebruik te maken van servicetags of applicatiebeveiligingsgroepen in plaats van specifieke IP-adressen. Dit vereist een goed begrip van Azure-netwerkconcepten en de mogelijkheden die het platform biedt voor flexibele netwerkbeveiliging. Een derde essentiële vereiste is uitgebreide documentatie van de huidige netwerkconfiguratie en de beoogde wijzigingen. Deze documentatie moet een complete inventarisatie bevatten van alle bestaande NSG's en hun huidige regels, inclusief de prioriteiten, bron- en doeladressen, poorten, protocollen, en acties (toestaan of weigeren). Daarnaast moet de documentatie een duidelijk overzicht bevatten van de netwerktopologie, waarbij wordt aangegeven hoe verschillende subnetten, virtuele netwerken, en services met elkaar zijn verbonden. Een visuele weergave van de netwerkarchitectuur kan hierbij zeer waardevol zijn voor het begrijpen van de verkeersstromen en afhankelijkheden. De documentatie moet ook een beschrijving bevatten van alle verkeersstromen tussen verschillende netwerksegmenten, inclusief de reden waarom elk verkeerspatroon nodig is en welke services afhankelijk zijn van deze communicatie. Deze informatie is essentieel voor het plannen van de implementatie en het vermijden van serviceonderbrekingen tijdens de migratie naar een standaard deny-configuratie. Bovendien helpt goede documentatie bij het verkrijgen van goedkeuring van stakeholders, het trainen van nieuwe teamleden, en het uitvoeren van audits en compliance-verificaties. Een vierde belangrijke vereiste is de beschikbaarheid van testomgevingen waarin de nieuwe configuratie eerst kan worden gevalideerd voordat deze wordt doorgevoerd in productieomgevingen. Deze testomgevingen moeten zo veel mogelijk lijken op de productieomgeving, inclusief dezelfde netwerkarchitectuur, services, en verkeerspatronen. Door eerst te testen in een gecontroleerde omgeving kunnen organisaties potentiële problemen identificeren en oplossen zonder impact op de productieomgeving. Dit voorkomt onbedoelde serviceonderbrekingen en stelt beheerders in staat om vertrouwd te raken met het beheer van een whitelist-gebaseerde netwerkconfiguratie. De testomgeving moet ook worden gebruikt voor het valideren van monitoring- en waarschuwingsconfiguraties. Organisaties moeten ervoor zorgen dat zij in staat zijn om verkeerspatronen te monitoren, geblokkeerd verkeer te analyseren, en waarschuwingen te ontvangen wanneer ongeautoriseerde toegangspogingen worden gedetecteerd. Dit vereist de configuratie van diagnostische instellingen, log analytics-werkruimten, en eventueel SIEM-integraties. Door deze configuraties eerst te testen in een testomgeving kunnen organisaties ervoor zorgen dat hun monitoring- en responsprocessen correct functioneren voordat ze worden toegepast in productie. Tot slot moeten organisaties beschikken over de juiste technische expertise en resources om een standaard deny-configuratie te implementeren en te onderhouden. Dit omvat kennis van Azure-netwerkconcepten, NSG-configuratie, en netwerkbeveiligingsprincipes. Organisaties moeten ook beschikken over voldoende tijd en resources om de implementatie zorgvuldig uit te voeren, inclusief uitgebreide testing en validatie. Het is belangrijk om te erkennen dat een standaard deny-configuratie een fundamentele wijziging is in de netwerkbeveiliging die zorgvuldige planning en uitvoering vereist om succesvol te zijn.

Implementatie

Gebruik PowerShell-script nsg-default-deny-all.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van een standaard deny-configuratie in Azure Network Security Groups is een complex proces dat een systematische en zorgvuldige aanpak vereist. Deze implementatie vormt de basis voor een Zero Trust-netwerkarchitectuur waarbij alleen expliciet geautoriseerd verkeer wordt doorgelaten en alle overige verkeer standaard wordt geblokkeerd. Het succes van de implementatie hangt af van een grondige voorbereiding, een goed begrip van de netwerkarchitectuur, en een methodische benadering waarbij elke stap zorgvuldig wordt gepland en uitgevoerd. Het implementatieproces begint met een uitgebreide analyse van alle legitieme verkeersstromen binnen de organisatie. Deze analyse moet worden uitgevoerd voordat enige wijziging wordt aangebracht aan de NSG-configuratie, om ervoor te zorgen dat alle benodigde verkeerspatronen worden geïdentificeerd en correct worden geconfigureerd. Voor een typische webapplicatie betekent dit bijvoorbeeld dat HTTPS-verkeer op poort 443 van internet naar de weblaag expliciet moet worden toegestaan. Deze regel maakt het mogelijk voor eindgebruikers om via een beveiligde verbinding toegang te krijgen tot de applicatie, terwijl alle andere verkeer vanaf internet wordt geblokkeerd. De analyse moet ook rekening houden met verschillende scenario's, zoals load balancing, failover-situaties, en geografische distributie van services. Tijdens de analyse van verkeersstromen moeten organisaties ook aandacht besteden aan de richting van het verkeer. Inkomend verkeer komt van buiten het netwerksegment en gaat naar services binnen het segment, terwijl uitgaand verkeer van services binnen het segment naar externe bestemmingen gaat. Beide richtingen vereisen specifieke toestaan-regels om ervoor te zorgen dat legitiem verkeer kan plaatsvinden. Voor inkomend verkeer moet worden geïdentificeerd welke services toegankelijk moeten zijn vanaf externe bronnen, zoals internet of andere netwerksegmenten. Voor uitgaand verkeer moet worden vastgesteld welke externe bestemmingen nodig zijn voor de normale werking van services, zoals updates, API-aanroepen, of communicatie met andere cloudservices. Na het identificeren van alle legitieme verkeersstromen moeten de specifieke toestaan-regels worden geconfigureerd. Deze regels moeten worden georganiseerd op basis van prioriteit, waarbij de meest specifieke regels de hoogste prioriteit krijgen en algemene regels een lagere prioriteit. In Azure NSG's werkt de prioriteit omgekeerd: een laag nummer betekent een hoge prioriteit, waardoor regels met lagere nummers eerst worden geëvalueerd. Dit betekent dat specifieke toestaan-regels, zoals verkeer van een specifiek IP-adres naar een specifieke service op een specifieke poort, een lager prioriteitsnummer moeten krijgen dan algemene regels. Voor communicatiepatronen tussen services moeten organisaties zorgvuldig de afhankelijkheden tussen services analyseren en de benodigde verkeersregels configureren. In het voorbeeld van een webapplicatie moet SQL-verkeer op poort 1433 van de weblaag naar de databaselaag worden toegestaan. Belangrijk hierbij is dat deze regel alleen verkeer in de juiste richting toestaat, waardoor de databaselaag beschermd blijft tegen directe toegang vanaf internet of andere onbevoegde bronnen. Organisaties moeten ook rekening houden met dynamische aspecten, zoals automatisch schalende groepen waarbij het aantal virtuele machines kan variëren, of load balancers die verkeer distribueren over meerdere back-endservers. Een belangrijke overweging bij het configureren van toestaan-regels is het gebruik van servicetags en applicatiebeveiligingsgroepen. Servicetags zijn vooraf gedefinieerde labels die groepen van IP-adressen vertegenwoordigen, zoals AzureCloud voor alle Azure-datacenter IP-adressen, of Storage voor Azure Storage-services. Door gebruik te maken van servicetags kunnen organisaties hun NSG-regels vereenvoudigen en onderhoudbaar maken, zonder dat zij alle individuele IP-adressen hoeven te beheren. Applicatiebeveiligingsgroepen maken het mogelijk om netwerkbeveiligingsbeleid toe te passen op groepen van virtuele machines op basis van hun functie, in plaats van individuele IP-adressen. Dit maakt de configuratie flexibeler en gemakkelijker te beheren, vooral in omgevingen met veel virtuele machines. Na het configureren van alle benodigde toestaan-regels moet als laatste regel 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. De implementatie moet worden uitgevoerd in een gefaseerde aanpak, waarbij eerst niet-kritieke omgevingen worden geconfigureerd voordat wordt overgegaan naar productieomgevingen. Dit maakt het mogelijk om ervaring op te doen met de configuratie en eventuele problemen te identificeren en op te lossen voordat kritieke systemen worden beïnvloed. Tijdens elke fase moet de configuratie worden getest om te verifiëren dat alle legitieme verkeersstromen correct functioneren en dat ongeautoriseerd verkeer daadwerkelijk wordt geblokkeerd. Na de implementatie moet uitgebreide testing worden uitgevoerd om te verifiëren dat alle legitieme verkeersstromen correct functioneren. Dit omvat functionele tests van alle services om te controleren of zij nog steeds correct werken na de implementatie van de standaard deny-configuratie. Prestatie tests moeten worden uitgevoerd om te controleren of de NSG-regels geen onbedoelde vertragingen veroorzaken of de doorvoer van verkeer beperken. Beveiligingstests moeten worden uitgevoerd om te bevestigen dat onverwacht verkeer daadwerkelijk wordt geblokkeerd en dat de beveiliging van het netwerk is verbeterd. Eventuele problemen die tijdens deze tests worden geïdentificeerd, moeten worden opgelost door de toestaan-regels aan te passen of aanvullende regels toe te voegen voordat de configuratie volledig in productie wordt genomen. Tijdens de implementatie is continue monitoring essentieel om te verifiëren dat de configuratie correct functioneert en dat geen onbedoelde problemen optreden. Organisaties moeten de NSG-logs nauwlettend volgen na de implementatie, op zoek naar ongebruikelijke patronen of indicatoren dat services niet correct functioneren. Als problemen worden gedetecteerd, moeten zij 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.

Compliance

De implementatie van een standaard deny-configuratie 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. De CIS Azure Benchmark Level 1, welke gericht is op essentiële basisbeveiligingsmaatregelen die door alle organisaties zouden moeten worden geïmplementeerd, vereist expliciet dat netwerkbeveiligingsgroepen correct worden geconfigureerd met restrictieve regels. Deze benchmark, ontwikkeld door het Center for Internet Security, biedt een gestructureerde set van beveiligingsaanbevelingen die zijn gebaseerd op best practices en ervaringen uit de praktijk. Een standaard deny-benadering voldoet aan deze vereiste door ervoor te zorgen dat alleen expliciet geautoriseerd verkeer wordt doorgelaten, wat een fundamenteel principe is van defensieve netwerkbeveiliging. Organisaties die voldoen aan de CIS Azure Benchmark Level 1 kunnen aantonen dat zij basisbeveiligingsmaatregelen hebben geïmplementeerd die essentieel zijn voor het beschermen van hun cloudomgevingen tegen veelvoorkomende bedreigingen. 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. 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.02 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 whitelist-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. De ISO/IEC 27001 standaard, met name beheerdoelstelling A.13.1.1 (Netwerkbeheer), 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. Het NIST Cybersecurity Framework, specifiek beveiligingscontrole SC-7 (Boundary Protection), vereist dat organisaties systemen en systemencomponenten beveiligen aan de externe grenzen en belangrijke interne grenzen van organisatiesystemen. Deze controle maakt deel uit van het beveiligingsdomein 'System and Communications Protection' en benadrukt het belang van het definiëren en handhaven van netwerkgrenzen als een essentiële beveiligingsmaatregel. Azure NSG's met een standaard deny-configuratie implementeren deze controle door virtuele netwerkgrenzen te definiëren en te handhaven, waarbij alleen expliciet geautoriseerd verkeer wordt doorgelaten. Dit helpt organisaties om hun systemen te beschermen tegen ongeautoriseerde toegang vanaf externe bronnen en om laterale beweging door aanvallers binnen het netwerk te voorkomen. 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. Samen vormen deze compliance-vereisten een sterke en overtuigende basis voor het implementeren van een standaard deny-configuratie. Organisaties die deze configuratie correct implementeren, voldoen niet alleen aan meerdere beveiligingsstandaarden en frameworks, maar creëren ook een fundamenteel veiligere netwerkarchitectuur die beschermt tegen zowel bekende als onbekende bedreigingen. Bovendien kunnen organisaties door het implementeren van een standaard deny-configuratie 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.

Monitoring

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

Het monitoren van Network Security Groups met een standaard deny-configuratie 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. Naast het monitoren van verkeer en regelwijzigingen, is het ook belangrijk om de effectiviteit van de NSG-configuratie te meten. Dit omvat het bijhouden van metriek zoals het percentage verkeer dat wordt toegestaan versus geblokkeerd, de responsetijden van services na het implementeren van nieuwe regels, en het aantal valse positieven waarbij legitiem verkeer onterecht wordt geblokkeerd. Deze metriek helpen organisaties om te bepalen of de huidige configuratie optimaal is en of aanpassingen nodig zijn om de balans te vinden tussen beveiliging en functionaliteit. Door regelmatig deze metriek te evalueren kunnen organisaties hun netwerkbeveiligingsconfiguratie continu verbeteren en ervoor zorgen dat deze effectief blijft in het beschermen tegen nieuwe en opkomende bedreigingen. Het is belangrijk om deze metriek te gebruiken om geïnformeerde beslissingen te nemen over wijzigingen aan de NSG-configuratie en om te verifiëren dat wijzigingen de beoogde resultaten opleveren zonder onbedoelde negatieve gevolgen. Voor geavanceerde monitoring kunnen organisaties Azure Sentinel of andere Security Information and Event Management (SIEM) systemen integreren met NSG-logs. Deze platforms bieden geavanceerde analysecapaciteiten, zoals machine learning-gebaseerde detectie van anomalieën, correlatie van gebeurtenissen tussen verschillende bronnen, en geautomatiseerde response-acties wanneer specifieke bedreigingen worden gedetecteerd. Door NSG-logs te combineren met andere beveiligingsdatabronnen kunnen organisaties een holistisch beeld krijgen van de netwerkbeveiliging en sneller reageren op incidenten. Deze geavanceerde monitoringmogelijkheden zijn vooral waardevol voor grote organisaties met complexe netwerkarchitecturen en een hoog volume aan verkeer en beveiligingsgebeurtenissen. Ze maken het mogelijk om bedreigingen te identificeren die anders onopgemerkt zouden blijven en om sneller te reageren op beveiligingsincidenten door geautomatiseerde response-acties te configureren. Het instellen van effectieve waarschuwingen is een ander kritisch onderdeel van monitoring. Organisaties moeten waarschuwingen configureren voor verschillende scenario's, zoals wanneer een ongebruikelijk hoog volume verkeer wordt geblokkeerd, wanneer pogingen worden gedetecteerd om toegang te krijgen tot gevoelige services, of wanneer verkeer wordt gedetecteerd vanuit geografische locaties waarvan bekend is dat ze vaak worden gebruikt door aanvallers. Deze waarschuwingen moeten prioriteit krijgen op basis van risiconiveau, waarbij hoogrisico-waarschuwingen onmiddellijke aandacht vereisen en laagrisico-waarschuwingen voor later kunnen worden beoordeeld. Het is belangrijk om waarschuwingen regelmatig te evalueren en aan te passen om ervoor te zorgen dat zij effectief zijn in het identificeren van echte bedreigingen zonder te veel valse positieven te genereren. Te veel valse positieven kunnen leiden tot waarschuwingmoeheid, waarbij beveiligingsteams belangrijke waarschuwingen over het hoofd zien omdat zij overweldigd worden door onbelangrijke meldingen. Tot slot is documentatie een essentieel onderdeel van monitoring. Alle monitoringactiviteiten, inclusief loganalyse, waarschuwingen, en incidenten, moeten worden gedocumenteerd om trends te kunnen identificeren en de effectiviteit van de monitoringstrategie te evalueren. Deze documentatie helpt ook bij audits en compliance-verificatie, waarbij organisaties moeten aantonen dat ze adequate monitoring uitvoeren van hun netwerkbeveiligingsmaatregelen. Goede documentatie maakt het ook mogelijk om kennis te delen binnen het team en om nieuwe teamleden snel op te leiden in de monitoringprocessen en -procedures. Door een gestructureerde aanpak te hanteren voor documentatie kunnen organisaties ervoor zorgen dat hun monitoringactiviteiten effectief en efficiënt blijven, zelfs wanneer teamleden veranderen of wanneer de organisatie groeit. Documentatie moet regelmatig worden bijgewerkt om ervoor te zorgen dat deze actueel blijft en accuraat reflecteert hoe monitoring daadwerkelijk wordt uitgevoerd.

Remediatie

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

Wanneer monitoring aangeeft dat een Network Security Group niet correct is geconfigureerd met een standaard deny-configuratie, 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. 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. 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. 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. Na het configureren van alle benodigde toestaan-regels moet als laatste stap een blokkeer alles-regel worden toegevoegd met de laagst mogelijke prioriteit. Deze regel zorgt ervoor dat alle verkeer dat niet expliciet is toegestaan door eerdere regels, automatisch wordt geblokkeerd. Het is cruciaal om ervoor te zorgen dat deze regel correct wordt geconfigureerd met de juiste prioriteit, zodat alle toestaan-regels eerst worden geëvalueerd voordat de weiger-regel wordt toegepast. 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. 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. 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

• CIS M365: Control Azure - NSG Standaard deny (L1) -
• BIO: 13.01.02 -
• ISO 27001:2022: A.13.1.1 -

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

Azure NSG Standaard Weiger Alles configuratie: Een expliciete weiger-alles regel wordt toegevoegd als laatste regel in de NSG met de laagste prioriteit, waarbij een whitelist-benadering wordt gehanteerd waarbij alleen expliciet toegestaan verkeer wordt doorgelaten. Dit implementeert Zero Trust-principes op netwerkniveau. De implementatie vereist grondige verkeersanalyse en uitgebreide testing. Activering gebeurt via Azure Portal of PowerShell door een weiger-alles regel toe te voegen met de laagste prioriteit. De configuratie zelf is kosteloos, maar vereist technische expertise. Verplicht voor Zero Trust-implementatie en BIO 13.01.02 compliance. Implementatietijd: 20-30 uur vanwege complexiteit en de noodzaak voor diepgaand netwerkbegrip. Verkrijgt een geavanceerde beveiligingspostuur.

• Implementatietijd: 30 uur
• FTE required: 0.2 FTE