2 Vormen van logging

Dit hoofdstuk beschrijft de verschillende vormen van logging. Het start met een kort overzicht van de verschillende vormen van logging. Het hoofdstuk eindigt met een overzicht van de soorten gegevens die per vorm van logging typisch worden vastgelegd.

2.1 Overzicht

De volgende tabel geeft een overzicht van de verschillende vormen van logging die vaak voorkomen en de belangrijkste doelen die ze nastreven.

Vorm van logging	Primaire doelen
Auditlogging	Auditing, fraudebestrijding, forensische analyse
Logging van verwerkingen van gegevens	Functioneel inzage geven in verwerkingen
Logging van totstandkoming van gegevens	Vertrouwen geven in gegevens, impactanalyse, foutanalyse
Logging van uitwisseling van gegevens	Aantonen van onweerlegbaarheid, onderlinge verrekening
Logging van procesverloop	Begrijpen van de uitvoering van processen, afwijkingen en verbetermogelijkheden identificeren
Technische applicatielogging	Debugging, foutanalyse
Technische infrastructuurlogging	Borgen beschikbaarheid, capaciteitsbeheer, SLA monitoring
Logging van netwerkverkeer	Borgen beschikbaarheid, capaciteitsbeheer, detecteren beveiligingsincidenten en performance monitoring

Tabel 1: Vormen van logging en de belangrijkste doelen die ze ondersteunen

In de volgende paragrafen worden de verschillende vormen van logging verder uitgewerkt. De bijbehorende teksten zijn vooral bedoeld om begrip te creëren, maar zijn zeker geen vervanging van teksten in de brondocumenten. Zo wordt er bijvoorbeeld functioneel beschreven wat voor soort gegevens worden vastgelegd, zonder expliciet te maken welke technische vorm dat aanneemt. Daarnaast zijn deze gegevens slechts een selectie en dus zeker niet volledig en voldoende.

2.2 Auditlogging

Grondslagen: Baseline Informatiebeveiliging Overheid, NEN-ISO/IEC 27002, NEN 7510-2:2024, NEN 7513:2024

Deze vorm van logging is primair gericht op het vastleggen van gebeurtenissen die relevant zijn vanuit het perspectief van informatiebeveiliging. Dat zijn naast fouten en uitzonderingen vooral gevoelige handelingen die zijn uitgevoerd door gebruikers, beheerders of informatiesystemen. Denk bijvoorbeeld aan het aanmaken, wijzigen of wissen van identiteiten, het aanvragen en goedkeuren van autorisaties, geslaagde en geweigerde pogingen om toegang te verkrijgen, systeemconfiguratieveranderingen en het gebruik van speciale bevoegdheden (zoals beheeractiviteiten). Verder zijn ook de individuele gegevensverwerkingen die uitgevoerd worden door informatiesystemen potentieel gevoelig en dus relevant om te loggen. Ook het gebruik, raadpleging of schoning van een logfile zijn zelf gevoelige handelingen die moet worden gelogd. Logbestanden moeten worden geanalyseerd om te bepalen of er sprake is van ongebruikelijke activiteiten of afwijkend gedrag. IT-auditors en compliance officers voeren dit soort analyses achteraf uit.

Voor het real-time detecteren van mogelijke bedreigingen kan gebruik worden gemaakt van een Security Information and Event Management (SIEM) tools. Deze maken gebruik van auditlogs en bieden intelligentie voor bijvoorbeeld het correleren van gebeurtenissen en het detecteren van afwijkingen. Ze kunnen overigens ook gebruik maken van andere soorten logs, zoals applicatielogs en technische infrastructuur logs. Ze kunnen ook gevoed worden vanuit XDR (Extended Detection and Response) systemen, die snel beveiligingsgerelateerde gebeurtenissen kunnen detecteren in bijvoorbeeld netwerken en endpoints. SIEM tools voorzien ook in lange termijn opslag van de verzamelde gegevens en historische analyse. Ze worden gebruikt door technisch beheerders en medewerkers van een Security Operations Center (SOC). Auditlogs of SIEM tools kunnen ook gebruikt worden in forensische analyses. Dat zijn formele onderzoeken die plaatsvinden, vaak in het kader van misdrijven of integriteitskwesties. Daarnaast kunnen ze gebruikt worden in periodieke analyses om patronen van aanvallen of dreigingen te herkennen (Cyber Threat Intelligence).

Specifiek aandachtspunt voor auditlogs is dat reguliere gebruikers en beheerders deze niet mogen kunnen verwijderen of manipuleren. Auditlogging moet zo worden ingericht dat manipulatie direct zichtbaar is; hiervoor zijn cryptografische hashing of HMAC’s geschikt. Door logs append-only op te slaan en entries via hash chaining te koppelen, kan elke wijziging of verwijdering worden gedetecteerd. Gebruik daarbij geen zwakke of verouderde algoritmen.

Relevante standaarden:

Common Event Format (CEF): een standaard ontwikkeld door de leverancier ArcSight die is gericht op het op gestructureerde wijze vastleggen van beveiligingsgebeurtenissen.
Authorization Decision Log: een standaard in ontwikkeling dat voorziet in een logboek voor toegangsbeslissingen als onderdeel van autorisatiemanagement.

Gegevens die typisch worden vastgelegd:

Gebeurtenis die opgetreden is (typisch een handeling)
Moment waarop de gebeurtenis is opgetreden
Gebruiker die de handeling heeft uitgevoerd
Gebruikte apparaat of locatie
Resultaat van de handeling

2.3 Logging van verwerkingen van gegevens

Grondslagen: Algemene Verordening Gegevensbescherming, NEN 7513:2024

Deze vorm van logging is primair bedoeld om functioneel inzicht te geven in welke verwerkingen hebben plaatsgevonden. Dat kan bijvoorbeeld relevant zijn voor burgers, ter ondersteuning van hun recht op inzage in de context van de AVG of in meer algemene zin als algemene verantwoording. Het kan ook relevant zijn voor privacy officers om te bepalen waar gevoelige gegevens worden verwerkt en of deze verwerkingen voldoende zijn afgeschermd. In de zorgsector is de NEN 7513 standaard specifiek gericht op logging van acties op persoonlijke gezondheidsinformatie. De standaard is bedoeld om het mogelijk te maken dat zorgaanbieders en cliënten toegangs-, zoek- en uitwisselings-gebeurtenissen kunnen inzien.

Relevante standaarden:

Logboek dataverwerkingen: een standaard in ontwikkeling die is gericht op het op een uniforme wijze vastleggen van gegevens over verwerkingen, met name van persoonsgegevens.

Gegevens die typisch worden vastgelegd:

Verwerkingsactiviteit (conform register van verwerkingsactiviteiten)
Naam van de specifieke handeling
Moment waarop de verwerking heeft plaatsgevonden
Subject waarover gegevens worden verwerkt
Indicatie of verwerking is geslaagd

2.4 Logging van totstandkoming van gegevens

Deze vorm van logging geeft inzicht in hoe gegevens stromen in ketens en hoe ze daarbij worden worden getransformeerd tot andere gegevens. Het is een kernonderdeel van wat ook wel data lineage of data provenance wordt genoemd. Data lineage is daarbij de overkoepelende term en data provenance verwijst naar de specifieke gegevens over de totstandkoming die zijn vastgelegd. Het geeft gebruikers vertrouwen in de kwaliteit van gegevens. Het ondersteunt data stewards in het signaleren van potentiële problemen in de kwaliteit van gegevens. Het biedt (data) engineers relevante informatie om de impact van wijzigingen in te schatten en om opgetreden fouten te analyseren en op te lossen.

Relevante standaarden:

PROV: een standaard voor het uitdrukken van provenance gegevens, gebaseerd op Linked Data.
Logboek dataverwerkingen – extensie voor objecten: een uitbreiding in ontwikkeling op het logboek dataverwerkingen waarbij expliciet kan worden vastgelegd welke gegevens worden verwerkt in een verwerking.
OpenLineage: een standaard voor het uitdrukken van data lineage, met name gericht op het faciliteren van data pipelines en ETL jobs.

Gegevens die typisch worden vastgelegd:

Activiteit die is uitgevoerd
Moment waarop de activiteit is uitgevoerd
Persoon, organisatie of informatiesysteem die activiteit heeft uitgevoerd
Invoer- en uitvoergegevens van de activiteit
Afleidingsregels, algoritme en/of programmacode die gebruikt zijn in de activiteit

2.5 Logging van uitwisseling van gegevens

Deze vorm van logging betreft metagegevens over uitwisselingen van gegevens, zoals de header van berichten en het tijdstip waarop een uitwisseling heeft plaatsgevonden. Deze gegevens kunnen na afloop worden gebruikt om aan te tonen dat een bepaalde uitwisseling heeft plaatsgevonden, mocht daar een dispuut over ontstaan. Het kan ook worden gebruikt om de uitwisseling en het gebruik van de daarvoor gebruikte middelen financieel te verrekenen. Voor deze vorm van logging kan ook gebruik worden gemaakt van een derde partij, die zowel door aanbieder als afnemer wordt vertrouwd. Een dergelijke partij wordt ook wel een clearing house (IDSA, 2022) of een observability service provider (DSSC, 2025) genoemd.

Het is ook mogelijk om de uitgewisselde gegevens zelf te bewaren, bijvoorbeeld om redenen van onweerlegbaarheid of recovery. Hier dient voorzichtig mee te worden omgegaan, met name als er ook gevoelige gegevens worden uitgewisseld. Naast privacy en informatiebeveiliging gelden er dan ook mogelijk eisen aan bewaar- en vernietigingstermijnen.

Merk verder op dat een uitwisseling zelf ook een verwerking is en dat uitwisselingen van gegevens daarom zelf ook als verwerking zullen moeten worden gelogd (als dat relevant is).

Relevante standaarden:

Federated Service Connectivity (FSC): een uitwisselstandaard die faciliteiten biedt voor het genereren van transactie-identificaties en het vastleggen van gegevensuitwisselingen. De standaard is inmiddels onderdeel van de Digikoppeling koppelvlakstandaard voor REST API’s.

Gegevens die typisch worden vastgelegd:

Header van bericht
Moment van verzending of ontvangst van de gegevens
Transactie-identificatie

2.6 Logging van procesverloop

Deze vorm van logging geeft inzicht in hoe processen in de praktijk precies worden uitgevoerd, los van wat er in een procesbeschrijving is opgenomen. Daarbij worden vooral de momenten in tijd vastgelegd waarop handmatige of geautomatiseerde handelingen worden uitgevoerd. Business activity monitoring tools kunnen de resulterende informatie real-time visualiseren in dashboards. Daaraan gerelateerd is de techniek “process mining”. Het doel daarvan is om processen beter te begrijpen, te bewaken en te verbeteren. Op basis van de vastgelegde procesgegevens ontstaat bijvoorbeeld zicht op doorlooptijden, bottlenecks en welk deel van de uitgevoerde processen een bepaalde route hebben gelopen. Er kan ook inzicht worden gegeven in welke mate de procesuitvoering nog past bij de opgestelde procesdefinitie. Zo kan bijvoorbeeld worden bepaald of functiescheiding heeft plaatsgevonden. Workflow management systemen leggen standaard procesgegevens vast, maar ook applicaties kunnen dit soort procesgegevens expliciet vastleggen.

Relevante standaarden:

eXtensible Event Stream (XES): een standaard voor het transporteren, opslaan en uitwisselen van gebeurtenissen.

Gegevens die typisch worden vastgelegd:

Gebeurtenis die opgetreden is
Handeling die is uitgevoerd
Moment waarop de handeling is uitgevoerd
Zaak
Procesinstantie
Gebruikte middelen

2.7 Technische applicatielogging

Deze vorm van logging betreft foutsituaties of mogelijke foutsituaties die optreden in informatiesystemen. Deze gegevens zijn tijdens de ontwikkeling van informatiesystemen relevant voor ontwikkelaars om te bepalen of programmacode correct werkt, waar eventuele fouten zitten en om deze op te lossen (debuggen). Als informatiesystemen in productie zijn dan zijn de fouten indicaties van situaties waarop een technisch beheerder geattendeerd moet worden. Technische logs zijn daarom typisch de basis voor monitoring en bijbehorende systemen. De focus ligt daarbij op het borgen van de beschikbaarheid.

Relevante standaarden:

Syslog (IETF RFC 5424): een standaard voor het vastleggen van technische logs die veel wordt gebruikt in Unix-achtige omgevingen zoals Linux.
Common Log Format (CLF): een standard format voor logs van web servers.
Extended Log Format (ELF): een verbeterde versie van CLF met extra mogelijkheden om andersoortige gegevens vast te leggen.

Gegevens die typisch worden vastgelegd:

Moment waarop de gebeurtenis is opgetreden
Indicatie van de ernst van de situatie
Omschrijving van de situatie
Applicatiecomponent of functie dat de gebeurtenis genereert
Detailinformatie om foutanalyse mogelijk te maken zoals een exception en stack trace

2.8 Technische infrastructuurlogging

Deze vorm van logging betreft foutsituaties of mogelijke foutsituaties die optreden in infrastructurele componenten zoals servers, databases, middleware of besturingssystemen. De nadruk ligt op het borgen van beschikbaarheid van de infrastructuur. Daarnaast zijn ook andere omstandigheden relevant om te signaleren, zoals veranderingen in de beschikbare capaciteit van bijvoorbeeld processoren, opslag of netwerk. Op basis van dergelijke signalen kan extra capaciteit worden bijgeschakeld om toekomstige onbeschikbaarheid te voorkomen. Technische infrastructuurlogs zijn ook de bron voor monitoring, inclusief het bewaken van serviceniveaus zoals beschreven in SLA’s. Organisaties dienen bij het configureren van de monitoring zelf te bepalen welke gebeurtenissen en grenswaarden op welke wijze moeten worden afgehandeld. Infrastructurele componenten bieden veelal standaard een vorm van logging, die wel nader kan worden geconfigureerd om aan specifieke eisen van een organisatie te voldoen.

Relevante standaarden:

Syslog (IETF RFC 5424): een standaard voor het uitwisselen van berichten over gebeurtenissen, die veel wordt gebruikt als basis voor technische logs in Unix-achtige omgevingen zoals Linux.
Windows logging: dit is niet een open standaard, maar wel de praktische manier waarop veel technische logs worden vastgelegd.

Gegevens die typisch worden vastgelegd:

Moment waarop de gebeurtenis is opgetreden
Indicatie van de ernst van de situatie
Omschrijving van de situatie
Naam of IP-adres van systeem dat de gebeurtenis genereert
Applicatie die de gebeurtenis genereert
Proces dat de gebeurtenis genereert

2.9 Logging van netwerkverkeer

Logging van netwerkverkeer (ook wel: verkeerlogging) is een specifieke vorm van technische infrastructuurlogging. Het betreft het vastleggen van gegevens over het dataverkeer dat door een netwerk gaat. Dit gaat meestal niet om de inhoud van de communicatie zelf, maar alleen om metadata. Het doel van verkeerlogging is om zicht te krijgen op gebruik en patronen in netwerkcommunicatie, bijvoorbeeld voor het borgen van beschikbaarheid, capaciteitsbeheer, detecteren van aanvallen of verdachte verbindingen, performance monitoring, naleving en auditing. Afhankelijk van het doel zullen andersoortige aspecten relevant zijn. Voor beschikbaarheid zijn bijvoorbeeld pakketverlies en herverzendingen relevant. Voor capaciteitsbeheer zijn volumes belangrijk. Er moet zorgvuldig worden omgegaan met verkeerlogging, omdat het indirect informatie kan geven over het gedrag en de relaties van gebruikers.

Relevante standaarden:

IP Flow Information Export (IPFIX): een standaard voor het verzamelen en uitwisselen van netwerkverkeersstatistieken.

Gegevens die typisch worden vastgelegd:

Bron- en bestemmings-IP-adressen
Poorten en protocollen
Tijdstempels van verbindingen
Datavolumes
Sessieduur

2.10 Overzicht van gegevens

	Auditlogging	Logging van verwerkingen van gegevens	Logging van totstandkoming van gegevens	Logging van uitwisseling van gegevens	Logging van procesverloop	Technische applicatie-logging	Technische infrastructuur- logging	Logging van netwerkverkeer
Gebeurtenis	X				X
Moment	X	X	X	X	X	X	X	X
Gebruiker	X
Apparaat	X						X
IP-adres	X						X	X
Locatie	X
Activiteit	X	X	X		X
Resultaat	X
Subject		X
Succes		X
Actor			X
Invoergegevens			X
Uitvoergegevens			X
Regels/algoritme/code			X
Header				X
Transactie				X
Zaak					X
Procesinstantie					X
Middelen					X
Ernst situatie						X	X
Omschrijving situatie						X	X
Applicatiecomponent						X
Foutinformatie						X
Applicatie							X
Technisch proces							X
Netwerkpoort								X
Netwerkprotocol								X
Datavolume								X
Sessieduur								X

Tabel 2: Overzicht van verschillende soorten gegevens die worden vastgelegd bij de verschillende vormen van logging

Volgende hoofdstuk: Hoofdstuk 3 - Aandachtspunten