Azure Monitor: Action Groups Configureren Voor Alert Notifications

Azure Monitor-waarschuwingsregels vormen de frontlinie van detectie binnen cloudomgevingen door continu te monitoren op afwijkende omstandigheden die kunnen wijzen op beveiligingsincidenten of operationele problemen. Deze regels zijn geconfigureerd om automatisch te reageren op specifieke drempelwaarden, zoals een ongebruikelijk hoog aantal mislukte authenticatiepogingen die kunnen wijzen op een brute-force-aanval, of een mislukte back-upprocedure die de databeschikbaarheid in gevaar brengt. De kracht van deze detectiemechanismen ligt echter niet alleen in hun vermogen om problemen te identificeren, maar vooral in hun capaciteit om tijdig en effectief te communiceren met de personen die actie kunnen ondernemen. Zonder geconfigureerde actiegroepen blijven deze waarschuwingen echter uitsluitend zichtbaar in het Azure Portal-waarschuwingsdashboard, een omgeving die regelmatig moet worden geraadpleegd door beveiligings- en operationele teams. Deze afhankelijkheid van handmatige controle introduceert kritieke kwetsbaarheden in het incidentresponsemechanisme. Organisaties die vertrouwen op passieve waarschuwingen zonder actiegroepen worden geconfronteerd met aanzienlijke operationele risico's die zich manifesteren in meerdere dimensies van hun beveiligingspostuur. Het primaire risico betreft gemiste waarschuwingen waarbij kritieke beveiligingsincidenten volledig onopgemerkt blijven totdat handmatige portalcontrole plaatsvindt. In een moderne cloudomgeving waar bedreigingen zich 24/7 kunnen ontwikkelen, is afhankelijkheid van geplande controles onvoldoende. Een brute-force-aanval die plaatsvindt buiten kantooruren kan bijvoorbeeld uren of zelfs dagen onopgemerkt blijven wanneer teams alleen tijdens reguliere werkuren de portal controleren. Deze vertraging geeft aanvallers aanzienlijk meer tijd om hun doelen te bereiken voordat detectie en respons plaatsvinden. Bovendien resulteert de afwezigheid van actiegroepen in vertraagde incidentrespons omdat teams pas reageren nadat uren zijn verstreken sinds de waarschuwing oorspronkelijk is geactiveerd. De tijd tussen detectie en respons is een kritieke factor in het beperken van de impact van beveiligingsincidenten. Elke minuut dat verstrijkt zonder respons kan resulteren in verdere compromittering van systemen, verspreiding van malware binnen het netwerk, of verlies van vertrouwelijke gegevens. Zonder automatische meldingen blijven teams volledig afhankelijk van hun vermogen om proactief de portal te controleren, wat in de praktijk zelden consistent gebeurt onder druk van dagelijkse operationele taken. Een derde dimensie van het probleem betreft de ineffectiviteit van waarschuwingsconfiguraties wanneer deze niet resulteren in daadwerkelijke meldingen. Organisaties investeren aanzienlijke tijd en middelen in het configureren van geavanceerde waarschuwingsregels met complexe logica, KQL-queries voor loganalyse, en gedetailleerde drempelwaarden. Zonder actiegroepen die deze waarschuwingen transformeren naar actiegerichte communicatie, blijft deze investering grotendeels onbenut. Het is vergelijkbaar met het installeren van een uitgebreid alarmsysteem zonder het te koppelen aan een meldkamer of telefoonlijn. Actiegroepen fungeren als de cruciale meldingsrouter die waarschuwingen transformeren van passieve dashboardvermeldingen naar actieve, gerichte communicatie die onmiddellijk de aandacht trekt van de juiste personen. Deze transformatie vindt plaats via meerdere communicatiekanalen die elk zijn geoptimaliseerd voor specifieke scenario's. E-mailmeldingen vormen de basis voor continue communicatie naar beveiligingsteamaliassen of operationsgroepen, waarbij distributielijsten zorgen voor redundantie en gedeelde verantwoordelijkheid. SMS-waarschuwingen bieden onmiddellijke aandacht voor engineers die stand-by zijn voor kritieke incidenten buiten kantooruren, wanneer e-mail mogelijk niet onmiddellijk wordt gecontroleerd. Webhookintegraties maken naadloze integratie mogelijk met ticketing- en ITSM-systemen zoals ServiceNow, die automatisch incidenttickets aanmaken en de volledige incidentworkflow activeren zonder handmatige interventie. Pushmeldingen naar mobiele apps zorgen ervoor dat teams real-time worden geïnformeerd zelfs wanneer ze niet achter hun bureau zitten. Azure Automation-runbooktriggers maken geautomatiseerde herstelacties mogelijk, waarbij specifieke problemen automatisch worden opgelost zonder dat menselijke interventie vereist is. Zonder geconfigureerde actiegroepen is de gehele waarschuwingsinfrastructuur effectief nutteloos, ongeacht hoe geavanceerd de onderliggende detectieregels zijn geconfigureerd. Het is een fundamentele architectuurfout om te investeren in detectie zonder te zorgen voor effectieve communicatie en respons. Organisaties moeten daarom actiegroepen beschouwen als een essentiële component van hun beveiligingsarchitectuur, niet als een optionele toevoeging.

Implementatie

Deze maatregel richt zich op de implementatie van een robuust en effectief meldingssysteem dat ervoor zorgt dat Azure Monitor-waarschuwingen daadwerkelijk de juiste personen bereiken op het moment dat incidenten plaatsvinden. De implementatie omvat het configureren van minimaal één actiegroep die is uitgerust met diverse meldingsdoelen die zijn afgestemd op de specifieke behoeften en prioriteiten van de organisatie. Het doel is niet alleen om technische configuratie te voltooien, maar om een volledig operationeel systeem te creëren dat naadloos integreert met bestaande workflows en processen. De kern van de implementatie bestaat uit het samenstellen van een actiegroep met meerdere lagen van meldingscapaciteit. De primaire laag bestaat uit e-mailadressen die zijn toegewezen aan beveiligings- en operationele teams. Deze e-mailmeldingen vormen de basis van communicatie en bieden gedetailleerde informatie over waarschuwingen in een formaat dat gemakkelijk kan worden gedeeld, gearchiveerd en gebruikt voor verdere analyse. Voor organisaties die prioriteit geven aan redundantie en beschikbaarheid, wordt aanbevolen om distributielijsten of gedeelde mailboxen te gebruiken in plaats van individuele e-mailadressen, zodat meerdere teamleden tegelijkertijd worden geïnformeerd en er geen enkele point of failure ontstaat wanneer een individuele persoon niet beschikbaar is. Voor kritieke incidenten die onmiddellijke aandacht vereisen, vormen telefoonnummers voor SMS-waarschuwingen een cruciale tweede laag van communicatie. Deze SMS-meldingen zijn specifiek gereserveerd voor de meest ernstige gebeurtenissen, waarbij elke seconde telt en e-mail mogelijk niet snel genoeg wordt gecontroleerd. Het is belangrijk om te beseffen dat SMS-waarschuwingen kosten met zich meebrengen per verzonden bericht, wat betekent dat organisaties een duidelijk beleid moeten hebben dat bepaalt wanneer SMS-meldingen worden gebruikt. In de praktijk betekent dit dat alleen waarschuwingen met ernstniveau 0 of 1, wat staat voor kritieke of foutniveaus, in aanmerking komen voor SMS-meldingen. Deze strategische inzet voorkomt onnodige kosten terwijl het toch waarborgt dat de meest kritieke incidenten onmiddellijke aandacht krijgen. Een derde laag van functionaliteit wordt geboden door webhook-URL's die integratie mogelijk maken met ticketing- en ITSM-systemen zoals ServiceNow, Jira, Azure DevOps, of andere platformen die worden gebruikt voor incidentbeheer en workflowautomatisering. Deze webhookintegraties transformeren waarschuwingen van geïsoleerde gebeurtenissen naar geïntegreerde onderdelen van het incidentbeheerproces. Wanneer een waarschuwing wordt geactiveerd, kunnen webhooks automatisch incidenttickets aanmaken, de juiste teams toewijzen, prioriteiten instellen, en de volledige incidentworkflow activeren zonder dat handmatige interventie vereist is. Deze automatisering verbetert niet alleen de snelheid van respons, maar zorgt ook voor consistente documentatie en traceerbaarheid van alle incidenten. Voor geavanceerde organisaties die streven naar maximale automatisering, biedt Azure Automation-runbooks een vierde laag van functionaliteit die geautomatiseerde responsen mogelijk maakt. Deze runbooks kunnen worden geconfigureerd om specifieke herstelacties uit te voeren wanneer bepaalde waarschuwingen worden geactiveerd, zoals het automatisch herstarten van een mislukte service, het wijzigen van netwerkconfiguraties om bedreigingen te isoleren, of het uitvoeren van vooraf gedefinieerde recoveryprocedures. Deze geautomatiseerde responsen kunnen de impact van incidenten aanzienlijk verminderen door problemen op te lossen voordat menselijke interventie zelfs mogelijk is. De configuratie van actiegroepen vindt plaats via de Azure Portal, waar organisaties navigeren naar Monitor → Waarschuwingen → Actiegroepen → Maken om een nieuwe actiegroep te starten. Het configuratieproces omvat het toevoegen van verschillende acties, waarbij organisaties kunnen kiezen uit e-mail, SMS, webhook, pushmeldingen, en andere beschikbare kanalen. Na het toevoegen van alle gewenste acties is het essentieel om testmeldingen te verzenden naar alle geconfigureerde kanalen om te verifiëren dat de levering correct werkt. Deze verificatiestap is cruciaal omdat het voorkomt dat organisaties denken dat hun waarschuwingssysteem operationeel is, terwijl meldingen in werkelijkheid worden geblokkeerd door spamfilters, firewallregels, of andere beveiligingsmechanismen. De finale stap in de implementatie betreft het koppelen van de actiegroep aan relevante waarschuwingsregels. Deze koppeling zorgt ervoor dat wanneer een waarschuwingsregel wordt geactiveerd, de bijbehorende actiegroep automatisch alle geconfigureerde meldingsacties uitvoert. Organisaties moeten ervoor zorgen dat alle relevante waarschuwingsregels zijn gekoppeld aan de juiste actiegroepen, waarbij het wordt aanbevolen om meerdere actiegroepen te configureren voor verschillende ernstniveaus. Voor waarschuwingen met ernstniveau 0 of 1, wat staat voor kritiek of fout, moeten actiegroepen worden geconfigureerd met zowel SMS als e-mailmeldingen om te waarborgen dat deze kritieke gebeurtenissen onmiddellijk aandacht krijgen. Voor waarschuwingen met ernstniveau 2 tot 4, wat staat voor waarschuwing of informatie, zijn actiegroepen met alleen e-mailmeldingen meestal voldoende, aangezien deze gebeurtenissen minder urgent zijn en niet de kosten van SMS-meldingen rechtvaardigen. De totale implementatietijd bedraagt doorgaans één tot twee uur, afhankelijk van de complexiteit van de organisatie en het aantal te configureren actiegroepen. De kosten zijn grotendeels minimaal, aangezien e-mailmeldingen en webhookintegraties geen extra kosten met zich meebrengen. SMS-meldingen worden gefactureerd per verzonden bericht, maar de kosten blijven laag wanneer deze strategisch worden ingezet voor alleen de meest kritieke gebeurtenissen. De investering in tijd en middelen wordt ruimschoots gecompenseerd door de aanzienlijke verbetering in incidentdetectie en responssnelheid die actiegroepen mogelijk maken. Deze implementatie voldoet aan de vereisten van de Baseline Informatiebeveiliging Overheid (BIO) controle 16.01 voor incidentmelding, die specifiek vereist dat organisaties procedures hebben voor het melden van beveiligingsincidenten aan de juiste personen of teams binnen de organisatie. Daarnaast voldoet de implementatie aan ISO 27001 controle A.16.1.2 voor het rapporteren van beveiligingsgebeurtenissen, die vereist dat organisaties procedures hebben voor het rapporteren van beveiligingsgebeurtenissen en dat deze procedures worden geïmplementeerd en onderhouden. Actiegroepen maken het mogelijk om beide vereisten technisch te implementeren door ervoor te zorgen dat beveiligingsincidenten en -gebeurtenissen automatisch worden gerapporteerd aan de relevante stakeholders via verschillende communicatiekanalen.

Vereisten

Voordat actiegroepen kunnen worden geconfigureerd, moeten organisaties beschikken over een duidelijk gedefinieerde set vereisten die de basis vormen voor een effectief waarschuwingssysteem. Deze vereisten omvatten zowel technische als organisatorische aspecten die essentieel zijn voor de succesvolle implementatie en het operationele gebruik van actiegroepen binnen de Azure-omgeving. De primaire technische vereiste betreft de beschikbaarheid van geldige contactgegevens voor meldingsdoelen. Organisaties moeten beschikken over e-mailadressen die specifiek zijn toegewezen aan beveiligingsteams, operationele teams of andere relevante stakeholders. Deze e-mailadressen kunnen individuele adressen zijn, maar voor betere schaalbaarheid en beheer wordt aanbevolen om distributielijsten of gedeelde mailboxen te gebruiken. Voor kritieke incidenten die onmiddellijke aandacht vereisen, zijn telefoonnummers nodig voor SMS-waarschuwingen. Het is belangrijk om te beseffen dat SMS-waarschuwingen kosten met zich meebrengen en daarom strategisch moeten worden ingezet voor alleen de meest kritieke gebeurtenissen. Naast contactgegevens moeten organisaties beschikken over geconfigureerde waarschuwingsregels binnen Azure Monitor. Deze regels definiëren de voorwaarden waaronder waarschuwingen worden gegenereerd, zoals drempelwaarden voor metrische gegevens, logqueryresultaten of activiteitenloggebeurtenissen. Zonder bestaande waarschuwingsregels hebben actiegroepen geen waarschuwingen om door te sturen, waardoor de configuratie nutteloos wordt. Organisaties moeten daarom eerst hun waarschuwingsstrategie definiëren en de relevante regels configureren voordat ze actiegroepen implementeren. Een aanvullende technische vereiste betreft de integratie met externe systemen indien webhooks of ITSM-integraties worden gebruikt. Voor webhookintegraties moeten organisaties beschikken over geldige URL-eindpunten die waarschuwingsgegevens kunnen ontvangen en verwerken. Deze eindpunten moeten beveiligd zijn met authenticatiemechanismen zoals API-sleutels of OAuth-tokens om ongeautoriseerde toegang te voorkomen. Voor ITSM-integraties met systemen zoals ServiceNow, Jira of Azure DevOps moeten de juiste connectors en configuraties beschikbaar zijn. Organisatorische vereisten zijn even belangrijk als technische vereisten. Organisaties moeten een duidelijk gedefinieerd escalatiebeleid hebben dat bepaalt welke teams worden gewaarschuwd voor verschillende soorten incidenten en ernstniveaus. Dit beleid moet de verantwoordelijkheden en reactietijden specificeren voor elk team, zodat waarschuwingen worden gerouteerd naar de juiste personen op het juiste moment. Daarnaast moeten organisaties procedures hebben voor het beheren en bijwerken van contactgegevens, aangezien personeelswisselingen en organisatorische veranderingen regelmatige updates vereisen van de actiegroepconfiguraties. Ten slotte moeten organisaties beschikken over de juiste Azure-machtigingen om actiegroepen te kunnen maken en configureren. Dit vereist meestal de rol van Monitoring Contributor of een aangepaste rol met specifieke machtigingen voor Azure Monitor-resources. Organisaties moeten ervoor zorgen dat alleen geautoriseerd personeel toegang heeft tot deze configuraties om te voorkomen dat onbevoegden wijzigingen aanbrengen die de effectiviteit van het waarschuwingssysteem kunnen compromitteren.

Monitoring

Gebruik PowerShell-script action-groups-alerts-configured.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van actiegroepen is een kritieke activiteit die ervoor zorgt dat het waarschuwingssysteem effectief blijft functioneren en dat teams daadwerkelijk worden gewaarschuwd wanneer incidenten optreden. Regelmatige monitoring helpt organisaties om problemen vroegtijdig te identificeren, zoals ongeldige contactgegevens, mislukte meldingen of configuratiefouten die de effectiviteit van het waarschuwingssysteem kunnen compromitteren. De primaire monitoringactiviteit betreft de verificatie dat actiegroepen daadwerkelijk bestaan en correct zijn geconfigureerd met geldige contactgegevens. Dit omvat het controleren van alle geconfigureerde actiegroepen binnen de Azure-omgeving en het valideren dat elke actiegroep ten minste één geldig meldingsdoel heeft, zoals een e-mailadres, telefoonnummer of webhook-URL. Organisaties moeten regelmatig controleren of de contactgegevens nog steeds actief zijn en of de beoogde ontvangers nog steeds de juiste personen zijn voor de verschillende soorten waarschuwingen. Een belangrijk aspect van monitoring is het verifiëren van de levering van meldingen. Azure Monitor biedt functionaliteit om testmeldingen te verzenden naar alle geconfigureerde acties binnen een actiegroep. Deze testmeldingen moeten regelmatig worden uitgevoerd, bijvoorbeeld maandelijks of na belangrijke configuratiewijzigingen, om te verifiëren dat meldingen daadwerkelijk worden ontvangen door de beoogde ontvangers. Het is essentieel om niet alleen te controleren of meldingen worden verzonden, maar ook of ze daadwerkelijk worden ontvangen en zichtbaar zijn voor de ontvangers, aangezien spamfilters of e-mailbeveiligingsinstellingen meldingen kunnen blokkeren. Monitoring moet ook de koppeling tussen actiegroepen en waarschuwingsregels omvatten. Organisaties moeten regelmatig controleren of alle relevante waarschuwingsregels zijn gekoppeld aan de juiste actiegroepen en of er geen waarschuwingsregels zijn die geen actiegroep hebben, waardoor waarschuwingen onopgemerkt blijven. Dit kan worden gedaan door de configuratie van waarschuwingsregels te controleren en te verifiëren dat elke regel ten minste één actiegroep heeft toegewezen. Daarnaast moeten organisaties de geschiedenis van verzonden meldingen monitoren om patronen te identificeren die kunnen wijzen op problemen. Azure Monitor biedt logboeken die informatie bevatten over wanneer meldingen zijn verzonden, naar welke acties ze zijn gerouteerd, en of de levering succesvol was. Door deze logboeken regelmatig te analyseren, kunnen organisaties problemen identificeren zoals herhaaldelijk mislukte meldingen naar specifieke contactgegevens, ongebruikelijk hoge volumes van waarschuwingen die kunnen wijzen op configuratiefouten, of patronen die suggereren dat bepaalde actiegroepen niet effectief zijn. Een ander belangrijk monitoringaspect betreft de kostenbeheersing, vooral voor SMS- en spraakmeldingen die per bericht worden gefactureerd. Organisaties moeten regelmatig controleren hoeveel meldingen zijn verzonden via betaalde kanalen en of deze volumes binnen verwachte parameters vallen. Ongebruikelijk hoge volumes kunnen wijzen op configuratiefouten, zoals waarschuwingsregels die te gevoelig zijn ingesteld of actiegroepen die onnodig SMS-meldingen gebruiken voor niet-kritieke gebeurtenissen. Ten slotte moeten organisaties een proces hebben voor het regelmatig bijwerken en valideren van contactgegevens. Personeelswisselingen, organisatorische veranderingen en updates aan e-mailadressen of telefoonnummers vereisen dat actiegroepconfiguraties worden bijgewerkt. Monitoring moet daarom ook het identificeren van verouderde of ongeldige contactgegevens omvatten, zodat deze tijdig kunnen worden bijgewerkt voordat ze problemen veroorzaken tijdens kritieke incidenten.

Implementatie

Gebruik PowerShell-script action-groups-alerts-configured.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van actiegroepen begint met het maken van een nieuwe actiegroep via de Azure Portal. Navigeer naar Monitor → Waarschuwingen → Actiegroepen en klik op de knop Maken om een nieuwe actiegroep te starten. Geef de actiegroep een duidelijke en beschrijvende naam die aangeeft voor welk doel deze wordt gebruikt, zoals "Beveiligingsteam - Kritieke Incidenten" of "Operations Team - Waarschuwingen". Deze naamgeving is belangrijk omdat organisaties vaak meerdere actiegroepen hebben voor verschillende doeleinden en teams. Na het aanmaken van de actiegroep moeten de verschillende acties worden toegevoegd. Voor een beveiligingsteam-actiegroep begint de implementatie meestal met het toevoegen van e-mailacties. Klik op de sectie E-mail/SMS/Push/Spraak en voeg de e-mailadressen toe van de relevante teamleden of gebruik een distributielijst voor betere schaalbaarheid. Het is belangrijk om meerdere e-mailadressen toe te voegen om redundantie te garanderen, zodat als één persoon niet beschikbaar is, anderen nog steeds worden gewaarschuwd. Voor kritieke incidenten die onmiddellijke aandacht vereisen, moeten SMS-acties worden toegevoegd. Selecteer de optie SMS en voer de telefoonnummers in van de personen die stand-by zijn voor kritieke gebeurtenissen. Het is belangrijk om te beseffen dat SMS-meldingen kosten met zich meebrengen en daarom strategisch moeten worden ingezet. Organisaties moeten een duidelijk beleid hebben dat bepaalt wanneer SMS-meldingen worden gebruikt, meestal alleen voor ernstniveau 0 of 1 (kritiek of fout) incidenten die onmiddellijke actie vereisen. Na het toevoegen van alle acties is het essentieel om testmeldingen te verzenden om te verifiëren dat de levering correct werkt. Azure Monitor biedt een functie om testmeldingen te verzenden naar alle geconfigureerde acties binnen een actiegroep. Deze testmeldingen moeten worden verzonden naar alle geconfigureerde kanalen om te verifiëren dat e-mails worden ontvangen, SMS-berichten worden afgeleverd, en webhooks correct worden aangeroepen. Het is belangrijk om niet alleen te controleren of meldingen worden verzonden, maar ook of ze daadwerkelijk zichtbaar zijn voor de ontvangers, aangezien spamfilters of e-mailbeveiligingsinstellingen meldingen kunnen blokkeren. De volgende stap in de implementatie is het koppelen van de actiegroep aan relevante waarschuwingsregels. Dit kan worden gedaan tijdens het maken of bewerken van waarschuwingsregels door de actiegroep te selecteren in de sectie Acties. Organisaties moeten ervoor zorgen dat alle relevante waarschuwingsregels zijn gekoppeld aan de juiste actiegroepen, zodat waarschuwingen worden gerouteerd naar de juiste teams. Het is aanbevolen om meerdere actiegroepen te configureren voor verschillende ernstniveaus, waarbij kritieke waarschuwingen worden gerouteerd naar actiegroepen met SMS-meldingen en minder kritieke waarschuwingen naar actiegroepen met alleen e-mailmeldingen. Voor organisaties die gebruikmaken van ticketing- of ITSM-systemen, moeten webhookacties worden geconfigureerd. Dit vereist het verkrijgen van de juiste webhook-URL van het ticketsysteem en het configureren van eventuele vereiste authenticatieparameters. Webhooks maken het mogelijk om automatisch incidenttickets aan te maken wanneer waarschuwingen worden geactiveerd, wat de efficiëntie van incidentbeheer aanzienlijk verbetert. Na de initiële implementatie moeten organisaties een proces opzetten voor het regelmatig bijwerken en onderhouden van actiegroepconfiguraties. Dit omvat het bijwerken van contactgegevens wanneer personeelswisselingen plaatsvinden, het toevoegen of verwijderen van acties wanneer organisatorische veranderingen optreden, en het regelmatig testen van meldingen om te verifiëren dat alles nog steeds correct werkt. Organisaties moeten ook documentatie bijhouden van de configuratie van elke actiegroep, inclusief welke teams worden gewaarschuwd, voor welke soorten incidenten, en wat de verwachte reactietijden zijn.

Compliance en Auditing

De implementatie van actiegroepen is een kritieke vereiste voor naleving van verschillende beveiligings- en compliancekaders die van toepassing zijn op Nederlandse overheidsorganisaties. Deze kaders stellen specifieke eisen aan de manier waarop organisaties incidenten detecteren, melden en reageren, en actiegroepen vormen een essentieel onderdeel van de technische infrastructuur die nodig is om aan deze eisen te voldoen. De Baseline Informatiebeveiliging Overheid (BIO) bevat in controle 16.01 specifieke vereisten voor incidentmelding. Deze controle vereist dat organisaties procedures hebben voor het melden van beveiligingsincidenten aan de juiste personen of teams binnen de organisatie. Actiegroepen maken het mogelijk om deze vereiste technisch te implementeren door ervoor te zorgen dat waarschuwingen over beveiligingsincidenten automatisch worden doorgestuurd naar de bevoegde teams, zoals het beveiligingsteam of het incidentresponseteam. Zonder geconfigureerde actiegroepen kunnen organisaties niet aantonen dat ze voldoen aan deze vereiste, omdat er geen geautomatiseerd mechanisme is om incidenten te melden. De ISO 27001-standaard bevat in controle A.16.1.2 vereisten voor het rapporteren van beveiligingsgebeurtenissen. Deze controle vereist dat organisaties procedures hebben voor het rapporteren van beveiligingsgebeurtenissen en dat deze procedures worden geïmplementeerd en onderhouden. Actiegroepen maken het mogelijk om deze vereiste technisch te implementeren door ervoor te zorgen dat beveiligingsgebeurtenissen automatisch worden gerapporteerd aan de relevante stakeholders via verschillende communicatiekanalen. Dit omvat niet alleen het melden van incidenten, maar ook het documenteren van deze meldingen voor auditdoeleinden. Voor Nederlandse overheidsorganisaties is het belangrijk om te beseffen dat de Algemene Verordening Gegevensbescherming (AVG) ook implicaties heeft voor incidentmelding. Hoewel de AVG niet expliciet vereist dat organisaties actiegroepen configureren, vereist artikel 33 wel dat organisaties datalekken melden aan de Autoriteit Persoonsgegevens binnen 72 uur na ontdekking. Actiegroepen kunnen helpen om deze vereiste te ondersteunen door ervoor te zorgen dat waarschuwingen over mogelijke datalekken onmiddellijk worden doorgestuurd naar de juiste personen, zodat de meldingsprocedure kan worden gestart. Tijdens audits moeten organisaties kunnen aantonen dat actiegroepen correct zijn geconfigureerd en dat ze daadwerkelijk functioneren. Dit vereist dat organisaties documentatie bijhouden van de configuratie van elke actiegroep, inclusief welke teams worden gewaarschuwd, voor welke soorten incidenten, en wat de verwachte reactietijden zijn. Daarnaast moeten organisaties logboeken bijhouden van verzonden meldingen om aan te tonen dat het systeem daadwerkelijk wordt gebruikt en dat meldingen worden ontvangen door de beoogde ontvangers. Auditeurs zullen ook willen verifiëren dat actiegroepen regelmatig worden getest om te verifiëren dat ze nog steeds correct functioneren. Organisaties moeten daarom een proces hebben voor het regelmatig verzenden van testmeldingen en het documenteren van de resultaten van deze tests. Dit proces moet worden gedocumenteerd en de resultaten moeten beschikbaar zijn voor auditeurs tijdens compliance-audits. Ten slotte moeten organisaties ervoor zorgen dat de configuratie van actiegroepen wordt beheerd volgens de principes van least privilege en scheiding van taken. Dit betekent dat alleen geautoriseerd personeel toegang moet hebben tot de configuratie van actiegroepen en dat wijzigingen moeten worden gelogd en gecontroleerd. Dit helpt om te voldoen aan algemene compliancevereisten voor toegangsbeheer en wijzigingsbeheer die worden gesteld door verschillende beveiligingskaders.

Remediatie

Gebruik PowerShell-script action-groups-alerts-configured.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer wordt vastgesteld dat actiegroepen niet zijn geconfigureerd of niet correct functioneren, moeten organisaties onmiddellijk actie ondernemen om deze kritieke situatie te herstellen. Het ontbreken van functionele actiegroepen vormt een aanzienlijk beveiligingsrisico omdat waarschuwingen niet worden doorgestuurd naar de juiste teams, waardoor kritieke beveiligingsincidenten volledig onopgemerkt kunnen blijven totdat handmatige controles plaatsvinden. Bovendien kunnen organisaties zonder geconfigureerde actiegroepen niet voldoen aan compliancevereisten voor incidentmelding zoals gesteld door de Baseline Informatiebeveiliging Overheid (BIO) controle 16.01 en ISO 27001 controle A.16.1.2, wat kan resulteren in negatieve auditbevindingen en potentiële reputatieschade. De remediatieprocedure begint met een grondige analyse van de huidige situatie om de specifieke problemen te identificeren. Deze analyse omvat het uitvoeren van een volledige inventarisatie van alle actiegroepen die momenteel zijn geconfigureerd binnen de Azure-omgeving. Organisaties moeten systematisch controleren of deze actiegroepen daadwerkelijk bestaan, of ze correct zijn geconfigureerd met geldige contactgegevens, en of alle vereiste meldingskanalen zijn toegevoegd. Daarnaast moeten organisaties verifiëren of waarschuwingsregels daadwerkelijk zijn gekoppeld aan actiegroepen, omdat zelfs bestaande actiegroepen nutteloos zijn wanneer ze niet zijn gekoppeld aan de waarschuwingsregels die daadwerkelijk waarschuwingen genereren. Een belangrijk aandachtspunt betreft het identificeren van waarschuwingsregels die geen actiegroep hebben gekoppeld, waardoor deze waarschuwingen onopgemerkt blijven in het Azure Portal zonder dat teams worden geïnformeerd. Wanneer de analyse uitwijst dat er helemaal geen actiegroepen bestaan, moet onmiddellijk worden begonnen met het maken van minimaal één actiegroep die is gericht op kritieke incidenten. Deze eerste actiegroep moet prioriteit krijgen omdat het de meest urgente beveiligingsbehoefte adresseert. De configuratie moet omvatten e-mailadressen van het beveiligingsteam om te waarborgen dat kritieke waarschuwingen ten minste via dit kanaal worden gecommuniceerd. Indien mogelijk moeten ook SMS-nummers worden toegevoegd voor de meest kritieke gebeurtenissen, zodat teams worden geïnformeerd zelfs buiten kantooruren wanneer e-mail mogelijk niet onmiddellijk wordt gecontroleerd. Het is van cruciaal belang om deze configuratie niet uit te stellen, omdat elke dag zonder functionele actiegroepen betekent dat potentiële beveiligingsincidenten volledig onopgemerkt kunnen blijven en dat organisaties blootgesteld zijn aan onnodige risico's. Voor situaties waarin actiegroepen wel bestaan maar niet correct functioneren, moeten de specifieke problemen worden geïdentificeerd en systematisch worden opgelost. Een veelvoorkomend probleem betreft verouderde of ongeldige contactgegevens, waarbij e-mailadressen of telefoonnummers die oorspronkelijk waren geconfigureerd niet meer actief zijn of niet meer bij de juiste personen horen. Dit kan het gevolg zijn van personeelswisselingen, organisatorische herstructureringen, of verouderde contactinformatie die nooit is bijgewerkt. Dergelijke problemen moeten worden opgelost door alle contactgegevens te valideren en te vervangen door actuele, geldige informatie. Een ander veelvoorkomend probleem betreft ontbrekende koppelingen tussen actiegroepen en waarschuwingsregels, waarbij actiegroepen correct zijn geconfigureerd maar niet zijn gekoppeld aan de relevante waarschuwingsregels. Dit probleem kan worden opgelost door systematisch alle waarschuwingsregels te controleren en te verifiëren dat elk regel ten minste één actiegroep heeft toegewezen. Daarnaast moeten organisaties testmeldingen verzenden om te verifiëren dat de levering daadwerkelijk correct werkt, aangezien configuratiefouten, firewallregels, of spamfilters kunnen voorkomen dat meldingen hun beoogde bestemming bereiken. Voor organisaties die al uitgebreide waarschuwingsregels hebben geconfigureerd maar geen actiegroepen hebben, vormt dit een bijzondere uitdaging omdat deze organisaties reeds hebben geïnvesteerd in geavanceerde detectiemechanismen die echter niet resulteren in daadwerkelijke meldingen. In deze situatie moet onmiddellijk worden begonnen met het koppelen van bestaande waarschuwingsregels aan nieuwe of bestaande actiegroepen. Deze koppeling moet systematisch worden uitgevoerd, waarbij alle waarschuwingsregels worden geëvalueerd op basis van hun prioriteit en ernstniveau, en vervolgens worden gekoppeld aan de juiste actiegroepen. Kritieke waarschuwingsregels die zijn gericht op ernstige beveiligingsincidenten moeten worden gekoppeld aan actiegroepen met meerdere meldingskanalen, inclusief SMS en e-mail, terwijl minder kritieke regels kunnen worden gekoppeld aan actiegroepen met alleen e-mailmeldingen. Deze systematische aanpak zorgt ervoor dat waarschuwingen die al worden gegenereerd ook daadwerkelijk worden doorgestuurd naar de juiste teams, waardoor de investering in waarschuwingsconfiguratie niet verloren gaat en de volledige waarde van de bestaande detectie-infrastructuur wordt gerealiseerd. Na de initiële remediatie moeten organisaties een robuust proces opzetten voor het regelmatig monitoren en onderhouden van actiegroepconfiguraties om te voorkomen dat dezelfde problemen opnieuw optreden. Dit onderhoudsproces moet omvatten het regelmatig testen van meldingen naar alle geconfigureerde kanalen, waarbij testmeldingen minstens maandelijks worden verzonden om te verifiëren dat alle meldingskanalen nog steeds correct functioneren. Daarnaast moeten organisaties procedures hebben voor het bijwerken van contactgegevens wanneer personeelswisselingen plaatsvinden, zodat actiegroepconfiguraties altijd actueel blijven en niet achterlopen bij organisatorische veranderingen. Het proces moet ook het controleren van de koppeling tussen actiegroepen en waarschuwingsregels omvatten wanneer nieuwe regels worden toegevoegd aan de omgeving, zodat nieuwe waarschuwingsregels automatisch worden gekoppeld aan de juiste actiegroepen en niet onopgemerkt blijven. Ten slotte moeten organisaties ervoor zorgen dat de volledige remediatieprocedure wordt gedocumenteerd en dat de configuratie van actiegroepen wordt opgenomen in de standaard configuratieprocedures voor nieuwe Azure-omgevingen. Deze documentatie moet duidelijk beschrijven welke actiegroepen zijn geconfigureerd, welke teams worden gewaarschuwd, voor welke soorten incidenten, en wat de verwachte reactietijden zijn. Daarnaast moeten de standaard configuratieprocedures expliciet vereisen dat actiegroepen worden geconfigureerd als onderdeel van de initiële setup van nieuwe Azure-omgevingen, zodat deze kritieke configuratie niet wordt vergeten of uitgesteld. Deze aanpak helpt om te voorkomen dat hetzelfde probleem optreedt in andere omgevingen of wanneer nieuwe resources worden toegevoegd aan de bestaande omgeving, en zorgt ervoor dat actiegroepen worden beschouwd als een fundamenteel onderdeel van de beveiligingsarchitectuur in plaats van een optionele toevoeging.

Compliance & Frameworks

• BIO: 16.01 - Incidentmelding
• ISO 27001:2022: A.16.1.2 - Rapporteren van beveiligingsgebeurtenissen

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

Actiegroepen: Configureer meldingskanalen voor Azure Monitor-waarschuwingen (e-mail, SMS, webhook, Logic Apps). Routeert waarschuwingen naar beveiligingsteam. Activatie: Azure Monitor → Waarschuwingen → Actiegroepen → Maken. Gratis (SMS/spraak worden gefactureerd). Verplicht BIO 16.01, ISO 27001. Implementatie: 1-2 uur. Essentiële waarschuwingsrouteringsinfrastructuur.

• Implementatietijd: 2 uur
• FTE required: 0.02 FTE