Event Logging Architecture
Een robuuste event logging-architectuur is de ruggengraat van effectieve security monitoring binnen Nederlandse overheidsorganisaties. Zonder betrouwbare, volledige en goed gestructureerde loggegevens is het voor SOC-teams en security-analisten vrijwel onmogelijk om dreigingen tijdig te detecteren, incidenten forensisch te reconstrueren en aan te tonen dat aan wettelijke en normatieve eisen wordt voldaan. In deze sectie wordt stap voor stap uitgewerkt hoe een moderne logging-architectuur eruit ziet, welke bouwblokken nodig zijn en hoe deze aansluiten op de Nederlandse kaders zoals de BIO, NIS2 en de AVG.
De basis van de architectuur wordt gevormd door het systematisch verzamelen van loggegevens uit alle kritieke componenten van de omgeving. Dat betekent dat authenticatie- en autorisatiegebeurtenissen uit identityplatformen zoals Entra ID (Azure AD) en Active Directory consequent worden vastgelegd, inclusief succesvolle en mislukte aanmeldingen, privilege-escalaties en wijzigingen in groepslidmaatschappen. Daarnaast moeten administratieve acties op platformen als Microsoft 365, Azure, on-premises servers en netwerkcomponenten worden gelogd, zodat altijd te herleiden is wie welke configuratie heeft aangepast en wanneer dat is gebeurd. Ook toegang tot gevoelige gegevensbronnen – bijvoorbeeld dossiersystemen, documentmanagement en samenwerkingsomgevingen – dient in voldoende detail te worden geregistreerd om misbruik, datalekken en ongeautoriseerde raadpleging achteraf te kunnen traceren.
Voor Windows-omgevingen is het zinvol om Windows Event Forwarding (WEF) in te zetten. Hiermee worden relevante event logs vanaf servers en werkplekken automatisch doorgestuurd naar één of meerdere verzamelservers, zonder dat op elk systeem afzonderlijk agentsoftware nodig is. Voor Linux-systemen en netwerkapparatuur, zoals firewalls, routers en load balancers, wordt doorgaans gebruikgemaakt van het Syslog-protocol om gebeurtenissen te versturen naar een centrale logcollector. In cloudomgevingen spelen diensten als Azure Monitor, Microsoft Defender en Microsoft 365-auditlogs een vergelijkbare rol: zij vormen de primaire bron van telemetrie over beveiligingsgebeurtenissen, configuratiewijzigingen en gebruikersactiviteiten.
Al deze logstromen komen samen in een gecentraliseerde logomgeving en worden vervolgens doorgeleid naar een Security Information and Event Management-platform (SIEM), bijvoorbeeld Microsoft Sentinel. In dit platform worden gebeurtenissen genormaliseerd, gecorreleerd en verrijkt met context, zoals informatie over bekende dreigingen, kwetsbaarheden of eerdere incidenten. Door correlatieregels toe te passen kunnen patronen worden herkend die wijzen op een aanval, zoals meerdere mislukte aanmeldpogingen gevolgd door een succesvolle login vanaf een ongebruikelijke locatie, of een combinatie van verdachte e-mailactiviteiten en massale datadownloads uit SharePoint of OneDrive. De kwaliteit van deze detecties staat of valt met de volledigheid en consistentie van de aangeleverde logs.
Een ander cruciaal aspect van de architectuur is bewaartermijn en integriteitsbescherming. Voor operationele detectie is een bewaartermijn van ten minste negentig dagen noodzakelijk, zodat langzaam verlopende of zorgvuldig verhulde aanvallen toch zichtbaar worden. Voor forensisch onderzoek of wettelijke bewaarplichten kan een langere retentieperiode vereist zijn, bijvoorbeeld één tot drie jaar, afhankelijk van de aard van de gegevens en sectorale voorschriften. Het is essentieel dat logbestanden tijdens deze periode niet ongemerkt kunnen worden aangepast of verwijderd. Dat vraagt om technische maatregelen zoals write-once opslag, hashing en digitale ondertekening, maar ook om strikte scheiding van functies: beheerders van productieomgevingen mogen loggegevens niet kunnen manipuleren, en toegang tot de loggingomgeving moet sterk zijn beperkt en goed worden gecontroleerd.
Naast techniek vraagt een effectieve logging-architectuur om duidelijke processen en rollen. Er moeten afspraken zijn over welke bronnen minimaal gelogd worden, hoe vaak configuraties worden herzien, wie verantwoordelijk is voor het beoordelen van nieuwe use-cases en detectieregels, en hoe bevindingen uit het SIEM worden doorgezet naar incidentresponsprocessen. SOC-analisten moeten beschikken over heldere playbooks waarin staat hoe zij reageren op specifieke typen meldingen, welke aanvullende logbronnen zij raadplegen en hoe zij hun bevindingen vastleggen voor opvolging en rapportage. Door deze processen expliciet te koppelen aan de eisen uit de BIO en NIS2 wordt geborgd dat logging niet slechts een technische voorziening is, maar een integraal onderdeel van de beveiligings- en governance-structuur.
Tot slot is het belangrijk om de logging-architectuur periodiek te toetsen en te verbeteren. Dit kan door middel van gecontroleerde tests, zoals red teaming, purple teaming of gesimuleerde phishingcampagnes, waarbij wordt gekeken of de relevante gebeurtenissen daadwerkelijk in het SIEM terechtkomen en leiden tot tijdige detectie. Ook audits en interne reviews leveren waardevolle inzichten op in hiaten in de loggingdekking of onvolkomenheden in bewaartermijnen en integriteitsbescherming. Door logging en monitoring continu te zien als een evoluerend geheel – dat meegroeit met nieuwe cloudservices, werkvormen en dreigingen – blijft de organisatie beschikken over de zichtbaarheid die nodig is om cyberrisico’s beheersbaar te houden.