Log Analytics Workspace Geconfigureerd

Zonder een gecentraliseerd Log Analytics Workspace blijven logs verspreid over individuele resources, wat verschillende kritieke problemen veroorzaakt. Allereerst is correlatie tussen gebeurtenissen onmogelijk wanneer logs versnipperd zijn over honderden verschillende resources. Dit betekent dat security teams geen verbanden kunnen leggen tussen verdachte activiteiten die plaatsvinden op verschillende systemen. Ten tweede is de standaardretentie beperkt tot 90 dagen voor activiteitenlogs, terwijl resource-logs helemaal niet standaard worden bewaard. Dit maakt forensische analyses na incidenten onmogelijk, aangezien cruciale data al verloren is gegaan voordat een incident wordt ontdekt. Bovendien ontbreken querymogelijkheden over meerdere resources heen, waardoor threat hunting en incidentonderzoek aanzienlijk worden belemmerd. Zonder een gecentraliseerd systeem kan geen alertingbasis worden gelegd voor het detecteren van patronen die wijzen op aanvallen of misconfiguraties. SIEM-integratie is onmogelijk zonder Log Analytics Workspace, omdat Microsoft Sentinel vereist dat deze workspace als fundament dient voor alle security data. Tot slot leidt het ontbreken van adequate gecentraliseerde logging tot compliance-schendingen, aangezien BIO en NIS2 expliciet vereisen dat organisaties beschikken over gecentraliseerde logging met adequate retentieperiodes. Een Log Analytics Workspace biedt geüniformeerde logging voor alle Azure-resources, inclusief virtuele machines, opslag, netwerken en beveiligingscomponenten. De KQL-querytaal (Kusto Query Language) maakt geavanceerde analyses en threat hunting mogelijk, waardoor security teams proactief kunnen handelen in plaats van reactief. Langetermijnretentie kan worden geconfigureerd van 365 tot 730 dagen, wat essentieel is voor compliance-vereisten en forensische doeleinden. De opslag is kosteneffectief door tiered pricing, waarbij oude data kan worden gearchiveerd naar goedkopere tiers. Integratie met Azure Monitor-alerts maakt het mogelijk om direct te reageren op logpatronen die wijzen op beveiligingsincidenten. Microsoft Sentinel bouwt voort op deze workspace, waardoor het de fundament vormt voor volledige SIEM-functionaliteit. Tot slot maakt compliance-ready logging het mogelijk om tijdens audits te demonstreren dat gecentraliseerd logbeheer adequaat is geïmplementeerd. Voor enterprise Azure-implementaties is Log Analytics Workspace essentiële infrastructuur, vergelijkbaar met de rol die een domain controller speelt in on-premises omgevingen.

Implementatie

Deze controle verifieert dat minimaal één Log Analytics Workspace is geconfigureerd per abonnement, of dat een gedeelde workspace wordt gebruikt over meerdere abonnementen heen voor ultieme centralisatie. Bij het ontwerpen van de workspace-architectuur zijn er twee hoofdstrategieën te overwegen. Een dedicated workspace per abonnement biedt isolatie tussen verschillende omgevingen en maakt gescheiden facturering mogelijk, wat handig is voor kostenallocatie. Een gedeelde workspace over meerdere abonnementen heen biedt ultieme centralisatie en één centraal overzicht voor de gehele organisatie, wat vooral waardevol is voor grote enterprises met complexe multi-abonnement architecturen. De workspaceconfiguratie omvat verschillende kritieke componenten. Retentie moet minimaal 365 dagen bedragen, waarbij 730 dagen wordt aanbevolen voor volledige compliance met auditvereisten. Data sources moeten omvatten: activiteitenlogs voor subscription events, diagnostische instellingen voor resource-logs, VM-agents voor performance- en securitylogs, Azure AD-logs voor sign-ins en audit trails, en Microsoft Defender alerts en aanbevelingen. De workspace moet worden geconfigureerd met passende toegangscontrole en authenticatie via RBAC, waarbij de rol Log Analytics Reader wordt toegewezen aan het security team voor alleen-lezen toegang. Een daily cap kan worden ingesteld voor kostenbeheer, maar dit moet worden vermeden voor security logs om te voorkomen dat cruciale beveiligingsdata verloren gaat. Archive tier biedt kostenoptimalisatie voor oude logs die minder frequent worden geraadpleegd, waarbij de queryperformance iets lager is maar de opslagkosten aanzienlijk dalen. De kosten bedragen ongeveer €2 tot €5 per GB geïngesteerd, waarbij een typische enterprise-organisatie 5 tot 20 GB per dag verwerkt, wat resulteert in maandelijkse kosten tussen €300 en €1500.

Vereisten

Voordat een Log Analytics Workspace kan worden geïmplementeerd, moeten verschillende vereisten worden vervuld. Allereerst is een Azure-abonnement vereist waarbij de gebruiker beschikt over de rol Owner of Contributor. Deze rollen zijn noodzakelijk omdat het maken van een Log Analytics Workspace abonnementsbrede wijzigingen vereist en toegang tot resourcegroepen. De Owner-rol biedt volledige toegang tot alle resources binnen het abonnement, inclusief de mogelijkheid om andere gebruikers toegang te verlenen. De Contributor-rol biedt de mogelijkheid om resources te maken en beheren, maar niet om toegang te verlenen aan anderen. Voor de meeste implementatiescenario's is de Contributor-rol voldoende, maar voor enterprise-implementaties waarbij RBAC-strategieën moeten worden geconfigureerd, is de Owner-rol wenselijk.

Budgetgoedkeuring is een kritieke vereiste voordat de implementatie kan beginnen. De maandelijkse kosten voor een Log Analytics Workspace variëren aanzienlijk afhankelijk van het dataverbruik. Een typische enterprise-organisatie verbruikt tussen de 5 en 20 GB aan logs per dag, wat resulteert in maandelijkse kosten tussen €300 en €1500. Deze kosten worden bepaald door de hoeveelheid data die wordt geïngesteerd, waarbij de eerste 5 GB per maand gratis zijn en daaropvolgende gigabytes worden gefactureerd volgens het pay-as-you-go model. Voor grote organisaties met uitgebreide Azure-implementaties kunnen deze kosten aanzienlijk hoger zijn. Het is daarom essentieel om vooraf een budgetgoedkeuring te verkrijgen van de financiële afdeling of management, inclusief een schatting van de verwachte kosten gebaseerd op het aantal resources en de verwachte logvolume. Daarnaast moeten kostenbeheermaatregelen worden overwogen, zoals het gebruik van archive tiers voor oude data en daily caps voor niet-kritieke logs.

Een gestandaardiseerde naamgevingsconventie voor de workspace is essentieel voor consistentie en beheerbaarheid binnen de organisatie. De naam moet uniek zijn binnen de gehele Azure-omgeving, aangezien Log Analytics Workspaces globaal unieke namen vereisen. Een goede naamgevingsconventie volgt een patroon zoals: law-[omgeving]-[regio]-[volgnummer], bijvoorbeeld law-prod-westeurope-001. Het prefix 'law' maakt duidelijk dat het een Log Analytics Workspace betreft, de omgeving (prod, dev, test) identificeert de doelomgeving, de regio (westeurope, northeurope) geeft aan waar de workspace zich bevindt, en het volgnummer maakt het mogelijk om meerdere workspaces per regio te hebben. Deze naamgevingsconventie vergemakkelijkt het beheer en maakt het mogelijk om snel te identificeren welke workspace voor welke doeleinden wordt gebruikt. Bovendien moet de naam voldoen aan Azure-naamgevingsvereisten: tussen de 4 en 63 karakters, alleen alfanumerieke karakters en hyphens, en geen underscores of andere speciale karakters.

Een resourcegroep moet worden geïdentificeerd of aangemaakt voor de Log Analytics Workspace. Deze resourcegroep kan dedicated zijn, uitsluitend bedoeld voor monitoring resources, of gedeeld worden met andere monitoring- en beveiligingsresources zoals Azure Monitor, Azure Sentinel, of Application Insights. Een dedicated resourcegroep biedt het voordeel van duidelijke scheiding en eenvoudigere kostenallocatie, terwijl een gedeelde resourcegroep met andere monitoring resources efficiënter kan zijn voor resourcemanagement. De keuze hangt af van de organisatiestructuur en voorkeuren voor resourcegroepbeheer. De resourcegroep moet zich in dezelfde regio bevinden als de primaire Azure-resources voor optimale performance en om te voldoen aan vereisten voor data residency indien van toepassing.

Een RBAC-strategie moet worden ontwikkeld voordat de workspace wordt geconfigureerd. Deze strategie bepaalt wie toegang heeft tot de logs en welke rechten zij hebben. De belangrijkste rollen zijn Log Analytics Reader, waarmee gebruikers logs kunnen lezen en query's kunnen uitvoeren, en Log Analytics Contributor, waarmee gebruikers ook configuraties kunnen wijzigen. Het security team heeft typisch Log Analytics Reader-rechten nodig voor het uitvoeren van threat hunting en incidentonderzoek. DevOps-teams kunnen Contributor-rechten nodig hebben voor het configureren van diagnostische instellingen. Het is belangrijk om het principe van least privilege toe te passen en alleen de minimale benodigde rechten toe te kennen. Bovendien moet worden overwogen of externe auditors of compliance teams toegang nodig hebben, en hoe deze toegang wordt beheerd en gemonitord.

Retentievereisten moeten worden bepaald in overleg met het compliance team en op basis van relevante regelgeving en standaarden. De CIS Azure Foundations Benchmark vereist minimaal 365 dagen retentie voor diagnostische logs, terwijl BIO en ISO 27001 ook langetermijnretentie vereisen voor auditdoeleinden. Voor veel organisaties is 730 dagen retentie de standaard, wat voldoet aan de meeste compliancevereisten en voldoende data biedt voor forensische analyses. Langere retentieperiodes zijn mogelijk maar leiden tot hogere kosten. Het is belangrijk om een balans te vinden tussen compliancevereisten en kostenbeheer, waarbij wordt overwogen om oudere data naar archive tiers te verplaatsen voor kostenoptimalisatie terwijl de data nog steeds beschikbaar blijft voor query's, zij het met iets langere responsetijden.

Tot slot moet een inventarisatie worden gemaakt van alle data sources die moeten loggen naar de Log Analytics Workspace. Deze inventarisatie moet omvatten: alle Azure-resources zoals virtuele machines, storage accounts, networking resources en security services, Azure AD voor sign-in en audit logs, Microsoft Defender voor security alerts en aanbevelingen, en alle aangepaste applicaties die mogelijk logdata genereren. Deze inventarisatie vormt de basis voor het configureren van diagnostische instellingen en zorgt ervoor dat geen kritieke data sources worden gemist. Bovendien moet worden bepaald welke logcategorieën per resource type moeten worden verzameld, waarbij security-relevante logs altijd prioriteit hebben boven performance- of diagnostic logs. Deze planning voorkomt dat later resources moeten worden hergeconfigureerd en zorgt voor een complete loggingstrategie vanaf het begin.

Implementatie

Gebruik PowerShell-script log-analytics-workspace-configured.ps1 (functie Invoke-Implementation) – Implementeren.

Gebruik PowerShell-script log-analytics-workspace-configured.ps1 (functie Invoke-Monitoring) – PowerShell script voor validatie van Log Analytics Workspace aanwezigheid.

De workspace kan worden aangemaakt via de Azure Portal door te navigeren naar 'Maak een resource aan' en te zoeken naar 'Log Analytics Workspace'. Tijdens het aanmaakproces moeten verschillende belangrijke configuratieopties worden gekozen. Het abonnement moet worden geselecteerd waarbij rekening wordt gehouden met de architectuurkeuze voor dedicated versus gedeelde workspaces. De resourcegroep moet worden geselecteerd of aangemaakt, bijvoorbeeld 'rg-monitoring-prod' voor productieomgevingen of een bestaande resourcegroep die al wordt gebruikt voor monitoring resources. De naam moet uniek zijn binnen de gehele Azure-omgeving en moet voldoen aan de naamgevingsconventies die zijn vastgesteld, bijvoorbeeld law-prod-westeurope-001. De regio moet worden gekozen op basis van de locatie van de primaire Azure-resources, waarbij West Europe typisch wordt gekozen voor Nederlandse organisaties. Het is belangrijk om de workspace in dezelfde regio te plaatsen als de meeste resources voor optimale performance en om te voldoen aan data residency requirements. De pricing tier moet worden ingesteld op Pay-as-you-go, wat flexibiliteit biedt en automatisch schaalt met het gebruik, in plaats van een vaste commitment tier. Na het aanmaken van de workspace moeten verschillende post-creation configuraties worden uitgevoerd.

Na het aanmaken van de workspace moet de retentie worden geconfigureerd via Workspace → Usage en estimated Kosten → Gegevensretentie. De retentie moet worden ingesteld op minimaal 365 dagen, met 730 dagen als aanbevolen waarde voor volledige compliance. Deze retentieperiode bepaalt hoe lang logs beschikbaar blijven voor query's en analyses. Langere retentieperiodes bieden meer data voor forensische analyses en compliance-audits, maar leiden tot hogere opslagkosten. De RBAC-configuratie moet worden uitgevoerd via Workspace → Toegangscontrole en authenticatie (IAM) → Roltoewijzingen toevoegen. De rol Log Analytics Reader moet worden toegewezen aan het security team voor alleen-lezen toegang tot logs, terwijl de rol Log Analytics Contributor kan worden toegewezen aan DevOps-teams die configuraties moeten kunnen wijzigen. VM-agents kunnen worden geïnstalleerd via Workspace → Agents, waarbij automatische installatie kan worden geconfigureerd via Azure Policy in plaats van handmatige installatie op elke virtuele machine. Een daily cap kan optioneel worden geconfigureerd voor kostenbeheer, maar dit moet worden vermeden voor security logs om te voorkomen dat cruciale beveiligingsdata verloren gaat wanneer de daily cap wordt bereikt.

Het configureren van data sources is een kritieke stap in het implementatieproces, omdat zonder correct geconfigureerde data sources de workspace geen logs zal ontvangen. Activiteitenlogs op subscription-niveau moeten worden geconfigureerd via Subscription → Activity log → Export Activiteitenlog → Diagnostische instellingen. Een nieuwe diagnostische instelling moet worden aangemaakt die alle logs doorstuurt naar de Log Analytics Workspace. De logcategorieën die moeten worden geselecteerd zijn Administrative, Security, Alert, Policy en Recommendation. Deze activiteitenlogs bevatten alle belangrijke gebeurtenissen op subscription-niveau, zoals wijzigingen in resources, toegang tot resources en beveiligingsgebeurtenissen. Resource diagnostische instellingen moeten worden geconfigureerd voor elk resource type dat logs genereert, inclusief virtuele machines, storage accounts en networking resources. Voor elk resource type moet via Diagnostische instellingen een instelling worden aangemaakt die alle beschikbare logcategorieën (allLogs) doorstuurt naar de Log Analytics Workspace. Deze resource logs bevatten gedetailleerde informatie over de werking en prestaties van individuele resources.

Azure AD-integratie is essentieel voor complete security monitoring en audit trails. Via Azure AD → Diagnostische instellingen moet een instelling worden aangemaakt die relevante logs doorstuurt naar de workspace. De belangrijkste logcategorieën zijn SignInLogs, die alle aanmeldpogingen bevatten inclusief geslaagde en mislukte pogingen, AuditLogs die alle wijzigingen in Azure AD-objecten vastleggen, RiskyUsers die informatie bevat over gebruikers die mogelijk gecompromitteerd zijn, en UserRiskEvents die specifieke risicogebeurtenissen vastleggen. Deze logs zijn cruciaal voor het detecteren van verdachte activiteiten zoals brute force aanvallen, ongebruikelijke aanmeldlocaties en privilege escalation pogingen. Microsoft Defender-integratie kan worden geconfigureerd via Defender voor Cloud → Environment settings → Continuous export. Deze export stuurt alle security alerts en aanbevelingen door naar de Log Analytics Workspace, waardoor deze data beschikbaar komt voor geavanceerde analyses en correlatie met andere logdata. Deze integratie maakt het mogelijk om een volledig beeld te krijgen van de beveiligingsposture van de Azure-omgeving en om geavanceerde threat hunting queries uit te voeren die data combineren vanuit verschillende bronnen.

Monitoring

Gebruik PowerShell-script log-analytics-workspace-configured.ps1 (functie Invoke-Monitoring) – Controleer aantal workspaces per subscription.

Het monitoren van workspace health is essentieel om ervoor te zorgen dat de Log Analytics Workspace correct functioneert en alle logs ontvangt zoals verwacht. Dagelijkse data-ingestie moet worden gecontroleerd via Workspace → Usage en estimated costs, waarbij de hoeveelheid data die dagelijks wordt geïngesteerd wordt gemonitord. Een typische enterprise-organisatie verbruikt tussen de 100 MB en 20 GB aan logs per dag, afhankelijk van de omvang van de Azure-omgeving, het aantal resources en de gedetailleerdheid van de geconfigureerde diagnostische instellingen. Significante wijzigingen in het dataverbruik kunnen wijzen op nieuwe resources die zijn toegevoegd, misconfiguraties die leiden tot overmatige logging, of mogelijke beveiligingsincidenten die abnormale activiteit veroorzaken. Kostenmonitoring moet maandelijks worden uitgevoerd om ervoor te zorgen dat de kosten binnen budget blijven. Als de kosten excessief zijn, moeten optimalisatiemaatregelen worden overwogen, zoals het reduceren van niet-kritieke logcategorieën, het gebruik van sampling voor high-volume logs, of het configureren van daily caps voor specifieke logcategorieën waarbij dataverlies acceptabel is.

Data freshness moet worden geverifieerd om ervoor te zorgen dat logs realtime arriveren en niet vertraagd zijn. De laatste ingestietijd kan worden gecontroleerd via KQL queries die de meest recente timestamps analyseren, of via de Workspace Overview pagina die realtime metrics toont. Vertragingen in loglevering kunnen wijzen op netwerkproblemen, misconfiguraties in diagnostische instellingen, of capaciteitsproblemen bij de workspace. Het is belangrijk om te monitoren of alle geconfigureerde data sources daadwerkelijk logs leveren, omdat het mogelijk is dat diagnostische instellingen stilzwijgend falen zonder duidelijke foutmeldingen. Query performance moet regelmatig worden geëvalueerd, waarbij langzaam uitvoerende queries worden geïdentificeerd en geoptimaliseerd. Langzame queries kunnen wijzen op inefficient query-syntax, ontbrekende indexes, of het analyseren van te grote datasets. Het is belangrijk om queries te optimaliseren door specifieke tijdsbereiken te gebruiken, waar mogelijk filters toe te passen aan het begin van de query, en aggregaties te gebruiken in plaats van detailrecords te retourneren wanneer alleen statistieken nodig zijn. Opslagcapaciteit moet regelmatig worden geëvalueerd, waarbij oude logs worden gearchiveerd naar goedkopere tiers voor data ouder dan 90 dagen om kosten te optimaliseren terwijl de data nog steeds beschikbaar blijft voor query's, zij het met iets langere responsetijden.

Alerting en incidentdetectie vormen een kritieke component van workspace monitoring. Azure Monitor alerts kunnen worden geconfigureerd op basis van KQL queries, waardoor security teams proactief kunnen reageren op verdachte patronen in de logs. Deze alerts moeten worden geconfigureerd voor verschillende scenario's, zoals ongebruikelijke aanmeldpogingen, privilege escalation pogingen, wijzigingen in kritieke resources, of abnormale netwerkactiviteit. Het is belangrijk om alert fatigue te voorkomen door alleen alerts te configureren voor daadwerkelijk relevante gebeurtenissen en door gebruik te maken van alert grouping en suppression regels. Daarnaast moeten alert response procedures worden gedocumenteerd, waarbij duidelijk is wie verantwoordelijk is voor het onderzoeken van verschillende typen alerts en binnen welke tijdsperiode een response verwacht wordt. Incident response workflows moeten worden geïntegreerd met de Log Analytics Workspace, waarbij security teams gebruik maken van KQL queries om incidenten te onderzoeken en te analyseren. Tijdens een incident is het essentieel dat security analisten snel toegang hebben tot relevante logs en dat query's efficiënt kunnen worden uitgevoerd om de omvang en impact van een incident te bepalen.

Best practices voor workspace monitoring omvatten het regelmatig uitvoeren van compliance checks, waarbij wordt geverifieerd dat alle vereiste data sources correct zijn geconfigureerd en dat retentievereisten worden nageleefd. Maandelijkse reviews moeten worden uitgevoerd om te controleren of nieuwe resources automatisch zijn geconfigureerd om logs te verzenden, of dat handmatige configuratie vereist is. Security teams moeten regelmatig threat hunting queries uitvoeren om proactief te zoeken naar indicatoren van compromittering, zelfs wanneer er geen specifieke alerts zijn gegenereerd. Deze proactieve benadering maakt het mogelijk om bedreigingen te detecteren voordat ze escaleren tot volledige incidenten. Daarnaast moeten regelmatige backups worden gemaakt van kritieke queries en dashboards, zodat deze niet verloren gaan bij wijzigingen in de workspace configuratie. Documentatie van monitoring procedures en query's is essentieel voor kennisoverdracht en voor het kunnen demonstreren van adequate security monitoring tijdens audits. Tot slot moet regelmatig worden geëvalueerd of de huidige workspace configuratie nog steeds voldoet aan de behoeften van de organisatie, waarbij wordt overwogen om de architectuur aan te passen wanneer de omgeving groeit of wanneer nieuwe compliancevereisten worden geïntroduceerd.

Compliance en Auditing

Log Analytics Workspace vormt het fundament voor Azure logging compliance en is een kritieke component voor het voldoen aan verschillende compliance-vereisten en security frameworks. Zonder adequate gecentraliseerde logging kunnen organisaties niet voldoen aan de vereisten die worden gesteld door internationale standaarden en Nederlandse regelgeving. Tijdens security audits is de Log Analytics Workspace-configuratie vaak een van de eerste vragen die worden gesteld, omdat het de basis vormt voor alle andere beveiligings- en compliance-initiatieven. Een correct geconfigureerde workspace demonstreert dat de organisatie serieus omgaat met security monitoring en dat zij in staat is om incidenten te detecteren en te onderzoeken.

De CIS Azure Foundations Benchmark v3.0.0 stelt in control 5.24 expliciet dat diagnostische logging moet zijn ingeschakeld en moet worden doorgestuurd naar een Log Analytics Workspace. Deze controle vereist dat alle Azure-resources diagnostische instellingen hebben geconfigureerd die relevante logs doorsturen naar de workspace. Tijdens compliance-audits zal worden geverifieerd dat alle kritieke resources, inclusief virtuele machines, storage accounts, networking resources en security services, correct zijn geconfigureerd om logs te genereren en door te sturen. Het ontbreken van een Log Analytics Workspace of het ontbreken van correct geconfigureerde diagnostische instellingen resulteert in een falende score voor deze controle, wat kan leiden tot het niet voldoen aan de CIS Benchmark vereisten.

BIO Thema 12.04.01 stelt vereisten voor gebeurtenisregistratie en gecentraliseerde logging. Deze norm vereist dat organisaties beschikken over gecentraliseerde logging waarbij alle relevante gebeurtenissen worden vastgelegd en bewaard voor een adequate periode. De Log Analytics Workspace voldoet aan deze vereiste door logs vanuit alle Azure-resources te verzamelen en op te slaan in een gecentraliseerde repository. Tijdens BIO-audits zal worden geverifieerd dat de organisatie beschikt over adequate logging capabilities en dat logs beschikbaar zijn voor analyses en incidentonderzoek. De retentieperiode moet voldoen aan de BIO-vereisten, waarbij minimaal 365 dagen wordt aanbevolen en 730 dagen wordt vereist voor organisaties met specifieke auditvereisten. Bovendien moet de organisatie kunnen demonstreren dat logs worden gebruikt voor security monitoring en dat procedures bestaan voor het analyseren van logs en het detecteren van beveiligingsincidenten.

ISO 27001:2022 controle A.12.4.1 stelt vereisten voor gebeurtenissen logging en audit trails, waarbij gecentraliseerd logbeheer wordt vereist. Deze controle vereist dat organisaties alle relevante beveiligingsgebeurtenissen vastleggen en dat logs worden bewaard voor een adequate periode voor auditdoeleinden. De Log Analytics Workspace voldoet aan deze vereiste door alle Azure logs te verzamelen en op te slaan in een gecentraliseerde omgeving die toegankelijk is voor security teams en auditors. Tijdens ISO 27001 audits zal worden geverifieerd dat de logging-implementatie voldoet aan de vereisten en dat procedures bestaan voor het beheren, analyseren en archiveren van logs. Bovendien moet de organisatie kunnen demonstreren dat logs worden gebruikt voor het detecteren van beveiligingsincidenten en dat adequate maatregelen zijn genomen om logs te beschermen tegen ongeautoriseerde toegang of wijziging.

De NIS2-richtlijn stelt in Artikel 21 vereisten voor logging en monitoring infrastructuur. Deze richtlijn vereist dat essentiële en belangrijke entiteiten beschikken over adequate monitoring en logging capabilities om cyberdreigingen te detecteren en te reageren op beveiligingsincidenten. De Log Analytics Workspace voldoet aan deze vereiste door een gecentraliseerde logging-infrastructuur te bieden die alle Azure-gerelateerde gebeurtenissen vastlegt. Tijdens NIS2-compliance verificaties zal worden geverifieerd dat de organisatie beschikt over adequate logging capabilities en dat deze worden gebruikt voor security monitoring. Bovendien vereist NIS2 dat organisaties beschikken over procedures voor het delen van incidentinformatie, waarbij logs kunnen worden gebruikt om incidentdetails te verzamelen en te delen met relevante autoriteiten wanneer vereist.

Tijdens Azure security audits is de Log Analytics Workspace-configuratie vaak een van de eerste vragen die worden gesteld door auditors, omdat het de basis vormt voor alle andere security en compliance activiteiten. Auditors zullen verifiëren dat de workspace correct is geconfigureerd, dat alle relevante data sources logs leveren, dat retentievereisten worden nageleefd, en dat toegangscontrole adequaat is geïmplementeerd. Bovendien zullen auditors willen zien dat de organisatie daadwerkelijk gebruik maakt van de logs voor security monitoring en incident detection, niet alleen dat de logs worden verzameld. Het is daarom belangrijk om niet alleen de workspace te configureren, maar ook te demonstreren dat security teams regelmatig queries uitvoeren, alerts configureren en logs analyseren als onderdeel van de dagelijkse security operations.

Remediatie

Gebruik PowerShell-script log-analytics-workspace-configured.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer een controle aangeeft dat er geen Log Analytics Workspace is geconfigureerd, of dat de bestaande workspace niet voldoet aan de vereisten, moet onmiddellijk actie worden ondernomen om deze kritieke beveiligingsinfrastructuur te implementeren. Remediatie begint met een grondige analyse van de huidige situatie om te bepalen wat er precies ontbreekt en welke stappen nodig zijn om de workspace correct te configureren. Het is belangrijk om te begrijpen dat zonder een Log Analytics Workspace organisaties niet kunnen voldoen aan fundamentele beveiligings- en compliancevereisten, waardoor het risico op niet-detecteerbare beveiligingsincidenten en compliance-schendingen aanzienlijk toeneemt.

De eerste stap in het remediatieproces is het identificeren van de exacte oorzaak van het probleem. Dit kan verschillende vormen aannemen: er is helemaal geen Log Analytics Workspace aangemaakt, er is wel een workspace maar deze is niet correct geconfigureerd met de vereiste retentieperiode, er zijn geen diagnostische instellingen geconfigureerd waardoor de workspace geen logs ontvangt, of de workspace bestaat wel maar er is geen toegang geconfigureerd voor het security team. Elke situatie vereist een specifieke aanpak, maar de basisstappen blijven hetzelfde: het aanmaken of bijwerken van de workspace, het configureren van retentie, het instellen van diagnostische instellingen voor alle relevante resources, en het configureren van toegangscontrole.

Voor organisaties die helemaal geen Log Analytics Workspace hebben, begint het remediatieproces met het aanmaken van een nieuwe workspace via de Azure Portal of via PowerShell. Tijdens het aanmaakproces moeten alle configuratieopties zorgvuldig worden gekozen om te voldoen aan de vereisten. De workspace moet worden aangemaakt in de juiste resourcegroep, met een unieke naam die voldoet aan de naamgevingsconventies, en in de juiste Azure-regio voor optimale performance en data residency compliance. Direct na het aanmaken moet de retentieperiode worden ingesteld op minimaal 365 dagen, bij voorkeur 730 dagen voor volledige compliance. Het is belangrijk om deze instellingen direct correct te configureren, omdat het later wijzigen van retentie-instellingen kan leiden tot dataverlies voor logs die al zijn opgeslagen.

Voor organisaties die wel een Log Analytics Workspace hebben maar waarbij de configuratie niet voldoet aan de vereisten, moet het remediatieproces zich richten op het bijwerken van de bestaande configuratie. Als de retentieperiode te kort is ingesteld, moet deze worden verhoogd naar minimaal 365 dagen. Het is belangrijk om te realiseren dat het verhogen van de retentieperiode alleen van invloed is op nieuwe logs die worden ontvangen na de wijziging; bestaande logs die al zijn opgeslagen met een kortere retentieperiode zullen nog steeds worden verwijderd volgens de oorspronkelijke instelling. Daarom is het essentieel om deze wijziging zo snel mogelijk door te voeren om te voorkomen dat toekomstige logs verloren gaan. Als de toegangscontrole niet correct is geconfigureerd, moeten de juiste RBAC-rollen worden toegewezen aan het security team en andere relevante teams. De rol Log Analytics Reader moet worden toegewezen aan het security team voor alleen-lezen toegang, terwijl DevOps-teams mogelijk de rol Log Analytics Contributor nodig hebben voor het configureren van diagnostische instellingen.

Het configureren van diagnostische instellingen is een kritieke stap in het remediatieproces, omdat een Log Analytics Workspace zonder geconfigureerde data sources geen logs zal ontvangen en dus geen waarde heeft voor security monitoring of compliance. De remediatie moet beginnen met het configureren van subscription-level activiteitenlogs, gevolgd door resource-level diagnostische instellingen voor alle kritieke resources. Dit omvat virtuele machines, storage accounts, networking resources, en alle security services. Voor elke resource moet een diagnostische instelling worden aangemaakt die alle relevante logcategorieën doorstuurt naar de Log Analytics Workspace. Het is belangrijk om een systematische aanpak te volgen en een inventarisatie te maken van alle resources die logs moeten genereren, om te voorkomen dat resources worden gemist. Azure Policy kan worden gebruikt om automatisch diagnostische instellingen te configureren voor nieuwe resources, wat voorkomt dat dit probleem in de toekomst opnieuw optreedt.

Azure AD-integratie is een essentieel onderdeel van het remediatieproces, omdat sign-in logs en audit logs cruciaal zijn voor security monitoring. Als deze integratie ontbreekt, moet via Azure AD → Diagnostische instellingen een instelling worden aangemaakt die SignInLogs, AuditLogs, RiskyUsers en UserRiskEvents doorstuurt naar de Log Analytics Workspace. Deze logs zijn onmisbaar voor het detecteren van verdachte activiteiten zoals brute force aanvallen, ongebruikelijke aanmeldlocaties en privilege escalation pogingen. Microsoft Defender-integratie moet ook worden geconfigureerd via Defender voor Cloud → Environment settings → Continuous export, zodat alle security alerts en aanbevelingen beschikbaar komen in de workspace voor geavanceerde analyses en correlatie met andere logdata.

Na het voltooien van de technische remediatie moet verificatie worden uitgevoerd om te bevestigen dat de workspace correct functioneert en logs ontvangt. Dit kan worden gedaan door KQL queries uit te voeren om te controleren of logs daadwerkelijk arriveren, door de Usage en estimated costs pagina te controleren om data-ingestie te verifiëren, en door te testen of alerts correct worden gegenereerd op basis van logpatronen. Het is belangrijk om niet alleen te verifiëren dat de workspace bestaat, maar ook dat deze daadwerkelijk wordt gebruikt en dat security teams toegang hebben om queries uit te voeren en logs te analyseren. Documentatie van het remediatieproces is essentieel voor auditdoeleinden en voor het kunnen demonstreren dat de organisatie proactief heeft gehandeld om beveiligingsrisico's te mitigeren.

Preventieve maatregelen moeten worden geïmplementeerd om te voorkomen dat dit probleem in de toekomst opnieuw optreedt. Azure Policy kan worden gebruikt om automatisch te controleren dat alle nieuwe abonnementen een Log Analytics Workspace hebben en dat diagnostische instellingen correct zijn geconfigureerd. Automatisering via Infrastructure as Code (IaC) met bijvoorbeeld ARM templates of Terraform zorgt ervoor dat nieuwe omgevingen automatisch worden voorzien van correct geconfigureerde workspaces. Regelmatige compliance checks moeten worden uitgevoerd om te verifiëren dat bestaande workspaces nog steeds voldoen aan de vereisten en dat nieuwe resources automatisch zijn geconfigureerd om logs te verzenden. Door deze preventieve maatregelen te implementeren, wordt het risico op toekomstige compliance-schendingen en beveiligingsgaten aanzienlijk verminderd.

Compliance & Frameworks

• CIS M365: Control 5.24 (L1) - Zorg ervoor dat diagnostische logs worden doorgestuurd naar Log Analytics Workspace
• BIO: 12.04.01 - Gecentraliseerde gebeurtenisregistratie
• ISO 27001:2022: A.12.4.1 - Gebeurtenisregistratie en audittrails - Gecentraliseerd logbeheer
• NIS2: Artikel - Gecentraliseerde logging-infrastructuur

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

Log Analytics Workspace: Gecentraliseerde loggingrepository voor ALLE Azure logs inclusief Activity logs, Diagnostic logs, VM logs en Entra ID logs. Retentie van 365-730 dagen. SIEM-fundament. Activatie: Maak Log Analytics Workspace per abonnement aan → Configureer retentie → Stuur alle logs door naar de workspace. Kosten: €300-1500 per maand typisch. Verplicht voor CIS 5.24, BIO 12.04, ISO 27001. Implementatie: 2-4 uur. KRITIEKE logginginfrastructuur.

• Implementatietijd: 4 uur
• FTE required: 0.05 FTE