Waarschuwing: NSG Aanmaken/Bijwerken

Wijzigingen aan netwerkbeveiligingsgroepen (NSG's) hebben directe invloed op de netwerkbeveiligingspostuur van een organisatie. Ongeautoriseerde of onbedoelde wijzigingen kunnen leiden tot het openen van poorten, het verruimen van IP-bereiken of het verwijderen van kritieke firewallregels, waardoor de organisatie kwetsbaar wordt voor cyberaanvallen. Daarom moeten alle NSG-wijzigingen worden gemonitord en moet er direct worden gewaarschuwd wanneer dergelijke wijzigingen plaatsvinden.

Implementatie

Deze controle implementeert een Azure Monitor waarschuwingsregel die automatisch een melding genereert wanneer er een aanmaak- of bijwerkoperatie plaatsvindt op een netwerkbeveiligingsgroep. De waarschuwingsregel monitort specifiek de activiteit Microsoft.Network/networkSecurityGroups/write in het Azure Activiteitenlogboek en stuurt een melding naar een vooraf geconfigureerde actiegroep wanneer deze activiteit wordt gedetecteerd. Deze geautomatiseerde monitoring zorgt ervoor dat beveiligingsteams onmiddellijk op de hoogte worden gesteld van alle wijzigingen aan netwerkbeveiligingsconfiguraties, waardoor snelle detectie en respons mogelijk is op ongeautoriseerde of verdachte wijzigingen die de beveiligingspostuur van de organisatie kunnen beïnvloeden.

Vereisten

De implementatie van NSG-wijzigingswaarschuwingen vereist een zorgvuldige voorbereiding en het vervullen van specifieke technische vereisten voordat de waarschuwingsregel daadwerkelijk kan worden geconfigureerd en operationeel kan worden gemaakt. Deze vereisten vormen de fundering waarop het gehele monitoring- en waarschuwingssysteem rust, en zonder een correcte configuratie van deze basiscomponenten zal het systeem niet naar behoren functioneren. De eerste en meest kritieke vereiste betreft de configuratie van het doorsturen van het Azure Activiteitenlogboek naar een Log Analytics-werkruimte. Het Azure Activiteitenlogboek bevat alle beheeractiviteiten die plaatsvinden binnen een Azure-abonnement, inclusief alle wijzigingen aan netwerkbeveiligingsgroepen. Zonder deze loggegevens heeft Azure Monitor geen toegang tot de informatie die nodig is om wijzigingen te detecteren en te analyseren. Het proces van doorsturen van het Activiteitenlogboek zorgt ervoor dat alle relevante activiteitenlogboeken worden doorgestuurd naar een gecentraliseerde Log Analytics-werkruimte, waar ze kunnen worden opgeslagen, geanalyseerd en gebruikt als bron voor waarschuwingsregels. Deze configuratie is niet alleen essentieel voor NSG-wijzigingswaarschuwingen, maar vormt ook de basis voor vele andere beveiligingsmonitoring- en complianceactiviteiten binnen een Azure-omgeving. De configuratie van het doorsturen van het Activiteitenlogboek kan worden uitgevoerd via verschillende methoden, waaronder de Azure Portal-interface, Azure CLI-commando's, of PowerShell-scripts. Ongeacht de gekozen methode, het proces vereist specifieke machtigingen op zowel het Azure-abonnement als de Log Analytics-werkruimte. De gebruiker of service principal die de configuratie uitvoert, moet beschikken over de rol van Log Analytics Contributor of een vergelijkbare rol met schrijfrechten op de Log Analytics-werkruimte. Daarnaast zijn abonnementsniveaumachtigingen vereist om het Activiteitenlogboek te kunnen lezen en door te sturen. Voor Nederlandse overheidsorganisaties is het belangrijk om te overwegen of de Log Analytics-werkruimte zich binnen dezelfde geografische regio bevindt als de primaire Azure-resources, om te voldoen aan data residency-vereisten die mogelijk van toepassing zijn op gevoelige overheidsdata. De tweede kritieke vereiste betreft de configuratie van een actiegroep die functioneert als het ontvangstpunt voor alle meldingen die worden gegenereerd wanneer een NSG-wijziging wordt gedetecteerd. Een actiegroep is een geconfigureerde verzameling van meldingsacties die kunnen worden geactiveerd wanneer een waarschuwingsregel wordt getriggerd. Deze acties kunnen verschillende vormen aannemen, waaronder e-mailnotificaties naar specifieke personen of distributielijsten, SMS-berichten naar mobiele telefoons, webhook-aanroepen naar externe systemen zoals SIEM-platforms of ticketingsystemen, en Azure Functions die geautomatiseerde responsacties kunnen uitvoeren. Voor beveiligingsteams in Nederlandse overheidsorganisaties wordt sterk aanbevolen om een meerkanaalsbenadering te implementeren die redundantie en betrouwbaarheid waarborgt. Een typische configuratie zou kunnen bestaan uit een primair e-mailkanaal naar het beveiligingsoperatiecentrum of het beveiligingsteam, een webhook-integratie met het centrale SIEM-systeem voor automatische opname in beveiligingsincidentmanagementwerkflows, en mogelijk een SMS-kanaal voor kritieke meldingen die buiten kantooruren plaatsvinden of die onmiddellijke aandacht vereisen. Deze meerkanaalsbenadering zorgt ervoor dat meldingen niet verloren gaan als één kanaal tijdelijk niet beschikbaar is, en stelt beveiligingsprofessionals in staat om op de manier te reageren die het meest geschikt is voor de situatie. De actiegroepconfiguratie moet zorgvuldig worden uitgevoerd voordat de waarschuwingsregel wordt aangemaakt, omdat de waarschuwingsregel direct moet kunnen verwijzen naar een bestaande actiegroep. Het testen van de actiegroepconfiguratie is een belangrijke stap die niet overgeslagen mag worden, omdat het verifiëren dat meldingen daadwerkelijk aankomen op alle geconfigureerde kanalen essentieel is voor de effectiviteit van het gehele monitoringsysteem. Daarnaast moet worden overwogen hoe vaak meldingen worden verzonden, omdat een te hoog volume aan meldingen kan leiden tot waarschuwingsmoeheid waarbij beveiligingsprofessionals belangrijke meldingen over het hoofd zien. Het configureren van geschikte beperkings- of aggregatie-instellingen kan helpen om het aantal meldingen te beheren zonder de effectiviteit van de monitoring te verminderen.

Implementatie

Gebruik PowerShell-script alert-nsg-create-update.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van NSG-wijzigingswaarschuwingen vormt een kritieke stap in het opzetten van proactieve netwerkbeveiligingsmonitoring binnen een Azure-omgeving. Het proces begint met het zorgvuldig aanmaken van een Azure Monitor-waarschuwingsregel die specifiek is geconfigureerd om te monitoren op create- en update-operaties die worden uitgevoerd op Network Security Groups. Deze waarschuwingsregel functioneert als een continue bewaker die alle activiteiten binnen het Azure Activiteitenlogboek analyseert en specifiek reageert op wijzigingen die betrekking hebben op netwerkbeveiligingsconfiguraties. De configuratie van de waarschuwingsregel vereist een diepgaand begrip van hoe Azure Activiteitenlogboekgebeurtenissen worden gestructureerd en hoe deze kunnen worden gefilterd om alleen relevante activiteiten te detecteren. De waarschuwingsregel wordt geconfigureerd met een specifieke conditie die filtert op het activiteitstype Microsoft.Network/networkSecurityGroups/write, wat de standaard resource provider-operatie is die wordt geregistreerd wanneer een Network Security Group wordt aangemaakt of bijgewerkt. Deze specifieke filterconditie is van cruciaal belang omdat het ervoor zorgt dat alleen wijzigingen aan NSG's worden gedetecteerd en dat andere netwerkgerelateerde activiteiten, zoals wijzigingen aan virtuele netwerken, load balancers, of andere netwerkcomponenten, niet onnodig waarschuwingen genereren. Wanneer de waarschuwingsregel een dergelijke activiteit detecteert in het Activiteitenlogboek, triggert deze automatisch en initieert het meldingsproces door een signaal te sturen naar de vooraf geconfigureerde actiegroep. Het configureren van de actiegroep met het beveiligingsteam als primaire ontvanger is essentieel om te verzekeren dat beveiligingsprofessionals onmiddellijk op de hoogte worden gesteld wanneer wijzigingen plaatsvinden aan netwerkbeveiligingsregels die de beveiligingspostuur van de organisatie kunnen beïnvloeden. De timing van deze meldingen is kritiek omdat snelle detectie en respons op ongeautoriseerde wijzigingen het verschil kan maken tussen een succesvolle mitigatie van een beveiligingsincident en een volledige compromittering van de netwerkbeveiliging. Het is sterk aanbevolen om de waarschuwingsregel te configureren op abonnementsniveau in plaats van op resourcegroep- of individueel resourceniveau. Deze aanpak zorgt ervoor dat alle NSG-wijzigingen binnen het gehele abonnement worden gemonitord, ongeacht in welke resourcegroep de NSG zich bevindt, in welke Azure-regio deze is geïmplementeerd, of welke naamgevingsconventies worden gebruikt. Deze brede scope is vooral belangrijk voor organisaties die gebruikmaken van complexe meertierarchitecturen waarbij Network Security Groups kunnen worden gebruikt op verschillende lagen van de infrastructuur, zoals op subnetniveau, op netwerkinterfaceniveau, of op virtuele machine-niveau. Door monitoring op abonnementsniveau te implementeren, wordt verzekerd dat geen enkele NSG-wijziging onopgemerkt blijft, zelfs als deze plaatsvindt in minder zichtbare delen van de infrastructuur of in resourcegroepen die mogelijk niet direct worden geassocieerd met kritieke workloads. Voor organisaties die gebruikmaken van meerdere Azure-abonnementen, hetgeen een veelvoorkomende praktijk is in bedrijfsomgevingen en bij Nederlandse overheidsorganisaties die mogelijk verschillende abonnementen gebruiken voor verschillende departementen of projecten, moet de waarschuwingsregel worden geïmplementeerd in elk abonnement waar Network Security Groups worden gebruikt. Deze multi-abonnementen implementatie vereist een gestandaardiseerde aanpak waarbij dezelfde configuratie wordt toegepast op alle relevante abonnementen om consistentie te waarborgen en te voorkomen dat sommige abonnementen beter worden beschermd dan andere. Het beheer van waarschuwingsregels over meerdere abonnementen heen kan worden vereenvoudigd door gebruik te maken van Azure Policy of door geautomatiseerde deployment-scripts die dezelfde configuratie kunnen toepassen op meerdere abonnementen tegelijkertijd. De implementatie van NSG-wijzigingswaarschuwingen kan volledig worden geautomatiseerd met behulp van het bijbehorende PowerShell-script dat specifiek is ontwikkeld voor deze controle. Dit script voert de volledige configuratie uit op een gecontroleerde en reproduceerbare manier, inclusief het aanmaken van de waarschuwingsregel met de juiste naam en beschrijving, het koppelen aan de juiste actiegroep, en het instellen van alle benodigde condities en filters. Het gebruik van geautomatiseerde scripts biedt verschillende voordelen, waaronder het verminderen van menselijke fouten tijdens de configuratie, het waarborgen van consistentie tussen verschillende implementaties, en het mogelijk maken van versiebeheer en documentatie van de exacte configuratie die wordt toegepast. Daarnaast maakt geautomatiseerde implementatie het mogelijk om de configuratie snel te herhalen in nieuwe omgevingen of om wijzigingen door te voeren wanneer de configuratie moet worden bijgewerkt. Het script kan worden uitgevoerd als onderdeel van een bredere infrastructure as code-aanpak, waarbij alle Azure-resources, inclusief monitoring en waarschuwingsconfiguraties, worden beheerd via code in plaats van handmatige configuratie in de Azure Portal.

Compliance en Naleving

De implementatie van NSG-wijzigingswaarschuwingen vertegenwoordigt niet alleen een technische beveiligingsmaatregel, maar vormt ook een verplichte controle volgens verschillende erkende cybersecurity frameworks die van bijzonder belang zijn voor Nederlandse overheidsorganisaties die verantwoordelijk zijn voor het beschermen van gevoelige overheidsdata en kritieke infrastructuren. Deze compliance-vereisten zijn niet optioneel maar vormen een fundamenteel onderdeel van de verantwoordelijkheden die organisaties hebben ten opzichte van hun stakeholders, burgers, en de bredere maatschappij. Volgens de CIS Microsoft Azure Foundations Benchmark versie 2.0, een internationaal erkend framework dat wordt gebruikt door organisaties wereldwijd om hun cloudbeveiligingspostuur te beoordelen en te verbeteren, specifiek controle 5.2.2, moeten organisaties waarschuwingsregels configureren die continu monitoren op wijzigingen aan netwerkbeveiligingsgroepen. Deze controle is geclassificeerd als Level 1, wat betekent dat het wordt beschouwd als een fundamentele beveiligingsmaatregel die door alle organisaties moet worden geïmplementeerd, ongeacht hun grootte, complexiteit, of het type workloads dat ze hosten in de cloud. Level 1-controles worden gekenmerkt door hun lage impact op operationele processen en hun hoge beveiligingswaarde, waardoor ze geschikt zijn voor implementatie in vrijwel elke omgeving zonder significante negatieve gevolgen voor functionaliteit of prestaties. De CIS-controle vereist expliciet dat alle aanmaak-, bijwerk- en verwijderoperaties op netwerkbeveiligingsgroepen worden gemonitord en dat er direct wordt gewaarschuwd wanneer dergelijke wijzigingen plaatsvinden, zonder uitzonderingen of uitsluitingen. Deze brede scope is opzettelijk gekozen omdat elke wijziging aan een netwerkbeveiligingsgroep, ongeacht hoe klein of onschuldig deze lijkt, potentieel kan worden gebruikt door aanvallers om de netwerkbeveiliging te omzeilen en ongeautoriseerde toegang te verkrijgen tot gevoelige systemen en data. Voor Nederlandse overheidsorganisaties heeft deze controle extra gewicht omdat het ook direct relevant is in het kader van de Baseline Informatiebeveiliging Overheid (BIO), het nationale informatiebeveiligingskader dat specifiek is ontwikkeld voor de Nederlandse publieke sector. De BIO-norm 12.04, die betrekking heeft op beveiligingsmonitoring en detectie, vereist dat organisaties proactief monitoren op beveiligingsincidenten en wijzigingen aan kritieke beveiligingsconfiguraties die de integriteit, beschikbaarheid of vertrouwelijkheid van informatie kunnen beïnvloeden. Netwerkbeveiligingsgroep-wijzigingen vallen expliciet onder deze categorie omdat ze directe en onmiddellijke invloed hebben op de netwerkbeveiligingspostuur van een organisatie en kunnen leiden tot onbevoegde toegang tot systemen, data-exfiltratie, of de compromittering van kritieke infrastructuren. De BIO vereist niet alleen dat monitoring wordt geïmplementeerd, maar ook dat organisaties kunnen aantonen dat ze daadwerkelijk gebruikmaken van de gegenereerde informatie om beveiligingsincidenten te detecteren, te onderzoeken en te reageren. Tijdens externe audits, die regelmatig worden uitgevoerd door onafhankelijke auditors of door interne auditafdelingen, moeten organisaties kunnen aantonen dat waarschuwingsregels niet alleen zijn geconfigureerd, maar ook actief zijn en daadwerkelijk functioneren zoals bedoeld. Dit betekent dat auditors niet alleen zullen controleren of de configuratie bestaat, maar ook zullen verifiëren dat meldingen daadwerkelijk worden gegenereerd wanneer wijzigingen plaatsvinden, dat deze meldingen worden ontvangen door de juiste personen of systemen, en dat er een gedocumenteerd proces bestaat voor het verwerken van deze meldingen. Het is daarom van cruciaal belang dat organisaties niet alleen de technische implementatie van de waarschuwingsregel voltooien, maar ook een volledig operationeel proces opzetten dat beschrijft wie de meldingen ontvangt, hoe ze worden verwerkt, welke escalatieprocedures van toepassing zijn, en welke specifieke acties worden ondernomen wanneer een NSG-wijziging wordt gedetecteerd. Deze documentatie moet regelmatig worden bijgewerkt om te reflecteren op wijzigingen in de organisatiestructuur, nieuwe bedreigingen, of lessen die zijn geleerd uit eerdere incidenten. Daarnaast moeten organisaties kunnen aantonen dat ze daadwerkelijk gebruikmaken van de informatie die door de waarschuwingsregels wordt gegenereerd, door bijvoorbeeld te verwijzen naar incidenten waarbij NSG-wijzigingsmeldingen hebben geleid tot de detectie en mitigatie van beveiligingsproblemen. Deze bewijsvoering is essentieel voor het aantonen van compliance en voor het demonstreren aan stakeholders dat de organisatie serieus omgaat met haar beveiligingsverantwoordelijkheden.

Monitoring

Gebruik PowerShell-script alert-nsg-create-update.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van NSG-wijzigingswaarschuwingen vertegenwoordigt een continu en dynamisch proces dat veel verder gaat dan alleen het technisch functioneren van de waarschuwingsregel zelf. Het omvat een breed spectrum van activiteiten die erop gericht zijn te verzekeren dat het gehele monitoring- en waarschuwingssysteem optimaal functioneert, dat alle relevante wijzigingen worden gedetecteerd en correct worden geclassificeerd, en dat beveiligingsteams effectief kunnen reageren op de informatie die door het systeem wordt gegenereerd. Dit monitoringproces begint bij de technische verificatie dat de waarschuwingsregel daadwerkelijk actief is en correct functioneert, maar strekt zich uit tot het analyseren van patronen in de gegenereerde meldingen, het evalueren van de effectiviteit van de responsprocessen, en het continu verbeteren van het systeem op basis van geleerde lessen en veranderende bedreigingslandschappen. Beveiligingsteams moeten periodiek, idealiter wekelijks of minstens maandelijks, controleren of de waarschuwingsregel actief is en of meldingen daadwerkelijk worden gegenereerd en ontvangen wanneer NSG-wijzigingen plaatsvinden. Deze verificatie kan worden uitgevoerd door de status van de waarschuwingsregel te controleren in Azure Monitor, waar de actieve status, de laatste trigger tijd, en eventuele configuratiefouten zichtbaar zijn. Daarnaast moet worden geverifieerd dat de gekoppelde actiegroep correct is geconfigureerd en dat alle geconfigureerde kanalen, zoals e-mail, SMS, webhooks, of andere meldingsmechanismen, daadwerkelijk functioneren zoals bedoeld. Het testen van de meldingskanalen is een kritieke activiteit die regelmatig moet worden uitgevoerd, omdat configuratiewijzigingen, wijzigingen in contactgegevens, of problemen met externe systemen kunnen leiden tot situaties waarin meldingen worden gegenereerd maar niet aankomen bij de beoogde ontvangers. Een effectieve teststrategie omvat het simuleren van een NSG-wijziging in een testomgeving of het handmatig activeren van een testmelding om te verifiëren dat alle kanalen correct functioneren en dat meldingen daadwerkelijk worden ontvangen door het beveiligingsteam. Naast het technisch functioneren van het waarschuwingssysteem, moeten beveiligingsteams een robuust en gedocumenteerd proces hebben voor het verwerken van NSG-wijzigingsmeldingen wanneer deze worden ontvangen. Dit proces moet duidelijk beschrijven welke stappen worden ondernomen wanneer een melding arriveert, wie verantwoordelijk is voor het initiële onderzoek, en hoe de beslissing wordt genomen of een wijziging geautoriseerd was of niet. Wanneer een melding wordt ontvangen, moet onmiddellijk worden gecontroleerd of de wijziging was geautoriseerd door te raadplegen van wijzigingsbeheersystemen, door contact op te nemen met de persoon die de wijziging heeft doorgevoerd, of door te verifiëren of de wijziging overeenkomt met een geplande wijziging die was geregistreerd in het wijzigingsbeheerproces. Daarnaast moet worden geïdentificeerd wie de wijziging heeft doorgevoerd door te analyseren van de Azure Activiteitenlogboek informatie die beschikbaar is in de melding, inclusief de gebruiker of service principal die de wijziging heeft geïnitieerd, het tijdstip waarop de wijziging plaatsvond, en de specifieke details van wat er is gewijzigd. De impactanalyse van de wijziging op de netwerkbeveiligingspostuur is een kritieke stap die moet worden uitgevoerd om te begrijpen of de wijziging de beveiliging van de organisatie heeft verzwakt, welke systemen of data mogelijk zijn blootgesteld, en welke mitigatiemaatregelen mogelijk nodig zijn. Als de wijziging ongeautoriseerd blijkt te zijn of als er twijfel bestaat over de legitimiteit van de wijziging, moet direct actie worden ondernomen om de wijziging terug te draaien en de oorspronkelijke netwerkbeveiligingsconfiguratie te herstellen. Deze respons moet worden uitgevoerd volgens een vooraf gedefinieerd incidentresponsproces dat beschrijft hoe snel actie moet worden ondernomen, wie de autoriteit heeft om wijzigingen terug te draaien, en hoe de situatie moet worden gedocumenteerd voor later onderzoek. Het monitoren van trends in NSG-wijzigingen is een belangrijke activiteit die kan helpen bij het identificeren van bredere problemen of patronen die mogelijk niet zichtbaar zijn wanneer individuele meldingen in isolatie worden bekeken. Als er bijvoorbeeld een significante toename is in het aantal NSG-wijzigingen over een bepaalde periode, kan dit wijzen op een probleem met het wijzigingsbeheerproces waarbij wijzigingen niet correct worden gepland of geautoriseerd, op een mogelijk beveiligingsincident waarbij een aanvaller meerdere wijzigingen probeert door te voeren, of op een organisatorisch probleem waarbij teams niet voldoende zijn getraind in de juiste procedures voor het maken van netwerkbeveiligingswijzigingen. Het analyseren van deze trends vereist het verzamelen en analyseren van historische data over NSG-wijzigingen, het identificeren van patronen zoals bepaalde tijdstippen waarop meer wijzigingen plaatsvinden, of bepaalde gebruikers of service principals die vaker wijzigingen doorvoeren dan anderen. Het bijbehorende PowerShell-script kan worden gebruikt om de status van de waarschuwingsregel te controleren en te verifiëren dat alle configuraties correct zijn ingesteld, maar het kan ook worden uitgebreid om trendanalyse uit te voeren en rapporten te genereren over de effectiviteit van het monitoring systeem.

Remediatie

Gebruik PowerShell-script alert-nsg-create-update.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer een organisatie ontdekt dat NSG-wijzigingswaarschuwingen niet zijn geconfigureerd, niet correct functioneren, of niet langer actief zijn, moet onmiddellijk en systematisch actie worden ondernomen om deze kritieke beveiligingskloof te herstellen. De afwezigheid of het niet functioneren van NSG-wijzigingswaarschuwingen vertegenwoordigt een significant beveiligingsrisico omdat het betekent dat wijzigingen aan netwerkbeveiligingsconfiguraties kunnen plaatsvinden zonder dat het beveiligingsteam hiervan op de hoogte wordt gesteld, waardoor de organisatie kwetsbaar is voor ongeautoriseerde netwerkwijzigingen die kunnen worden gebruikt door aanvallers om de netwerkbeveiliging te omzeilen. De remediatieprocedure moet worden gestart zodra het probleem wordt geïdentificeerd, ongeacht of dit gebeurt tijdens een routinecontrole, een beveiligingsaudit, of na de detectie van een beveiligingsincident waarbij bleek dat ongeautoriseerde NSG-wijzigingen hadden kunnen plaatsvinden zonder detectie. De remediatie begint met een grondige beoordeling van de huidige status van het waarschuwingssysteem, waarbij systematisch wordt gecontroleerd of er waarschuwingsregels zijn geconfigureerd, of deze regels actief zijn en correct functioneren, en of meldingen daadwerkelijk worden gegenereerd en ontvangen wanneer NSG-wijzigingen plaatsvinden. Deze statuscontrole moet worden uitgevoerd voor alle Azure-abonnementen waar netwerkbeveiligingsgroepen worden gebruikt, omdat het probleem mogelijk alleen in bepaalde abonnementen aanwezig is terwijl andere abonnementen correct zijn geconfigureerd. Als de statuscontrole uitwijst dat er helemaal geen waarschuwingsregels zijn geconfigureerd, moet deze onmiddellijk worden aangemaakt volgens de implementatie-instructies die beschikbaar zijn in de implementatiesectie van dit document. Deze implementatie moet worden uitgevoerd met hoge prioriteit omdat elke dag dat de waarschuwingen niet actief zijn, de organisatie blootstelt aan het risico dat ongeautoriseerde wijzigingen onopgemerkt blijven. Tijdens de implementatie moet speciale aandacht worden besteed aan het verifiëren dat alle vereisten zijn vervuld, inclusief de configuratie van het doorsturen van het Activiteitenlogboek naar Log Analytics-werkruimte en de configuratie van een actiegroep met de juiste ontvangers. Als de statuscontrole uitwijst dat er wel waarschuwingsregels zijn geconfigureerd maar dat deze niet actief zijn of zijn uitgeschakeld, moet worden onderzocht waarom ze zijn uitgeschakeld en wat de reden was voor deze deactivering. Mogelijke redenen voor deactivering kunnen zijn dat de regels tijdelijk zijn uitgeschakeld voor onderhoud of probleemoplossing, dat ze zijn uitgeschakeld vanwege een configuratiefout die problemen veroorzaakte, of dat ze mogelijk per ongeluk zijn uitgeschakeld door een gebruiker die niet volledig begreep wat de impact zou zijn. Ongeacht de reden, de waarschuwingsregels moeten zo snel mogelijk opnieuw worden geactiveerd zodra het onderliggende probleem is opgelost, en er moeten maatregelen worden genomen om te voorkomen dat ze in de toekomst opnieuw worden uitgeschakeld zonder goede reden en zonder dat het beveiligingsteam hiervan op de hoogte wordt gesteld. Als de statuscontrole uitwijst dat waarschuwingsregels actief zijn maar dat geen meldingen worden ontvangen wanneer NSG-wijzigingen plaatsvinden, moet een diepgaand onderzoek worden uitgevoerd om te identificeren waar in het meldingsproces het probleem zich voordoet. Dit onderzoek moet beginnen met het verifiëren dat de actiegroep correct is geconfigureerd en dat alle geconfigureerde kanalen, zoals e-mail, SMS, of webhooks, correct zijn ingesteld met de juiste contactgegevens of eindpunten. Daarnaast moet worden gecontroleerd of de ontvangers de juiste contactgegevens hebben en of deze contactgegevens nog actief zijn, omdat personeelswijzigingen of wijzigingen in e-mailadressen kunnen leiden tot situaties waarin meldingen worden verzonden naar niet-bestaande of niet-geverifieerde adressen. Het is ook belangrijk om te controleren of er mogelijk spamfilters, e-mailbeveiligingssystemen, of andere systemen zijn die de meldingen blokkeren voordat ze de beoogde ontvangers bereiken. Deze systemen kunnen soms legitieme beveiligingsmeldingen blokkeren als ze worden geclassificeerd als spam of als verdacht, vooral als de meldingen worden verzonden vanuit geautomatiseerde systemen of als ze bepaalde kenmerken hebben die door spamfilters als verdacht worden beschouwd. In het geval van een beveiligingsincident waarbij een ongeautoriseerde NSG-wijziging is gedetecteerd, moet de remediatie zich niet alleen richten op het herstellen van de technische configuratie, maar ook op het volledig adresseren van de beveiligingsimpact van het incident. De eerste prioriteit moet zijn het onmiddellijk terugdraaien van de ongeautoriseerde wijziging en het herstellen van de oorspronkelijke netwerkbeveiligingsconfiguratie om verdere schade te voorkomen. Daarna moet een grondig onderzoek worden uitgevoerd om te begrijpen hoe de wijziging heeft kunnen plaatsvinden, wie verantwoordelijk was voor de wijziging, en of er aanvullende beveiligingsmaatregelen nodig zijn om te voorkomen dat vergelijkbare incidenten in de toekomst plaatsvinden. Dit onderzoek moet worden uitgevoerd volgens het standaard incidentresponsproces van de organisatie en moet worden gedocumenteerd voor latere analyse en voor het verbeteren van de beveiligingsprocessen. Het bijbehorende PowerShell-script kan worden gebruikt om automatisch de waarschuwingsregel aan te maken of te herstellen wanneer deze ontbreekt of niet correct is geconfigureerd, wat het remediatieproces aanzienlijk kan versnellen en kan helpen om menselijke fouten te voorkomen tijdens de configuratie. Het script kan worden uitgevoerd als onderdeel van een geautomatiseerd remediatieproces dat regelmatig controleert of de waarschuwingsregels correct zijn geconfigureerd en automatisch actie onderneemt wanneer problemen worden gedetecteerd. Voor Nederlandse overheidsorganisaties is het belangrijk om te overwegen dat remediatieactiviteiten mogelijk moeten worden gedocumenteerd voor compliance-doeleinden, vooral wanneer deze worden uitgevoerd als reactie op een beveiligingsincident of wanneer ze worden geïdentificeerd tijdens een externe audit. Deze documentatie moet duidelijk beschrijven wat het probleem was, welke stappen zijn ondernomen om het probleem op te lossen, wie verantwoordelijk was voor de remediatie, en welke maatregelen zijn genomen om te voorkomen dat het probleem in de toekomst opnieuw optreedt. Daarnaast moet worden overwogen of de remediatieactiviteiten moeten worden geëscaleerd naar senior management of naar de CISO, vooral wanneer het probleem heeft geleid tot een beveiligingsincident of wanneer het probleem gedurende een langere periode onopgemerkt is gebleven.

Compliance & Frameworks

• CIS M365: Control 5.2.2 (L1) - Waarschuw bij NSG-wijzigingen
• BIO: 12.04 - Beveiligingsmonitoring

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

NSG-wijzigingswaarschuwingen: Azure Monitor waarschuwingsregel die monitort op wijzigingen aan Network Security Groups (create- en update-operaties). Detecteert ongeautoriseerde firewallwijzigingen. Activeren via: Azure Monitor → Activity Log waarschuwing → NSG write-operaties. Geen extra kosten. Verplicht volgens CIS 5.2.2 en BIO 12.04. Implementatietijd: 1 uur. Detecteert alle netwerkbeveiligingswijzigingen.

• Implementatietijd: 1 uur
• FTE required: 0.02 FTE