3 Aandachtspunten

Dit hoofdstuk beschrijft een aantal aandachtspunten die gelden voor logging. Zij zijn van toepassing op veel van de beschreven vormen van logging. De aandachtspunten zijn gebaseerd op kennis en ervaring van mensen die hebben bijgedragen aan dit document alsook aan gedocumenteerde bronnen. Een belangrijke bron is de handreiking aanwijzing logging van VNG (2023).

De mate van logging is contextueel en gebaseerd op zaken zoals doelstellingen, behoeften en risico-inschattingen. Meer loggen is niet per definitie beter (en in veel gevallen slechter). Een wildgroei aan logfiles moet worden voorkomen. Het is dan ook belangrijk om in elke context de specifieke eisen die worden gesteld aan logging expliciet te maken, te vertalen naar inrichtingskeuzes en deze af te stemmen met de verantwoordelijke. Deze keuzes moeten expliciet worden meegenomen in het ontwerp van informatiesystemen.
Er kunnen bij bepaalde vormen van logging gevoelige gegevens (zoals persoonsgegevens) worden gelogd. Logging is zelf ook een vorm van gegevensverwerking. Er moeten adequate maatregelen worden genomen om privacy te borgen en ongeoorloofde toegang tot deze gegevens te voorkomen. Denk bijvoorbeeld aan pseudonimisering. Dataminimalisatie zou het uitgangspunt moeten zijn. Het moet ook worden meegenomen bij het opstellen van DPIA’s. Dat geldt uiteraard ook voor logbestanden die worden uitgewisseld met derden, bijvoorbeeld om te helpen bij het detecteren of oplossen van fouten of storingen. Centrale loggingvoorzieningen vragen al snel een DPIA.
Er moet worden voorkomen dat executeerbare code wordt opgenomen in logs, omdat deze per ongeluk zou kunnen worden uitgevoerd. Invoer van gebruikers of externe systemen zou in ieder geval moeten worden gefilterd op ongewenste karakters.
Logregels moeten op een bepaald moment gearchiveerd of verwijderd worden. Het is belangrijk deze termijnen expliciet te maken en bijbehorende mechanismen in te regelen. Daarbij moet naast opslagcapaciteit ook expliciet naar formele bewaar- en vernietigingstermijnen worden gekeken. In geval van incidenten is het noodzakelijk om bepaalde vorming van logging langer te bewaren dan de formele bewaartermijn. Daarnaast is het mogelijk om oudere logdata met een minder hoog detailniveau te bewaren om opslagruimte te beperken.
Het is verstandig om logbestanden op een andere plaats neer te zetten dan het informatiesysteem waar de logs op betrekking hebben (zeker voor audit- en netwerklogs). Daarmee kunnen performance, beschikbaarheid en beveiliging beter worden geborgd. Door binnen een organisatie logs op een centrale plaats vast te leggen is het ook eenvoudiger om integraal door verschillende logs heen te zoeken en kan foutanalyse worden versneld. Anderzijds introduceert een centrale log wel een extra beveiligingsrisico dat gemitigeerd dient te worden; als deze centrale log wordt gecompromitteerd dan meer gegevens geraakt.
Het moet mogelijk zijn om logs over systeem- en organisatiegrenzen aan elkaar te kunnen relateren, zodat logregels met elkaar in samenhang kunnen worden geanalyseerd. Een basisverplichting hiervoor is kloksynchronisatie, maar over de grenzen van organisaties heen is een meer betrouwbaar mechanisme om correlatie-identificaties (zoals transactie-identificaties) op te nemen in logregels.
Het is waardevol om gebeurtenissen in verschillende soorten logs met elkaar te correleren en daarmee een breder zicht te creëren op het gedrag van applicaties en infrastructuur. Dit is onderdeel van observability en stelt organisaties in staat snel te reageren op problematische situaties. Er kunnen ook bepaalde patronen inzichtelijk worden gemaakt (bijv. verdachte patronen). Hiervoor kan gebruik worden gemaakt van de OpenTelemetry standaard. Op basis van deze standaard kunnen gebeurtenissen uit bestaande logs worden gehaald, voorzien van correlatie-identificaties (spans en traces) en worden doorgestuurd naar een centrale server (observability backend).
Naast logs kunnen er ook metrics worden vastgelegd. Dat zijn getallen die het resultaat zijn van een meting en relevant zijn voor het behalen van bepaalde indicatoren. Denk daarbij bijvoorbeeld gerelateerd aan normen in de SLA zoals beschikbaarheid of performance. Genoemde OpenTelemetry standaard kan deze metrics combineren met logs en daarmee een rijker beeld geven van de toestand van applicaties en infrastructuur.
Logging ondersteunt processen. Het is belangrijk de bijbehorende procedures op te stellen en taken en verantwoordelijkheden te definiëren en toe te kennen. Denk bijvoorbeeld aan het regelmatig analyseren van auditlogs op ongebruikelijke activiteiten of afwijkend gedrag.
Het uitvoeren van loganalyses zou expliciet moeten worden vastgelegd, zodat op een later moment kan worden aangetoond dat dit heeft plaatsgevonden.
Het analyseren van logbestanden gebeurt bij voorkeur geautomatiseerd, aangezien het over grote aantallen gegevens gaat. Dit is wel afhankelijk van het type logging. Kunstmatige intelligentie kan daarbij ondersteunen, bijvoorbeeld om afwijkingen te detecteren, waar vervolgens mensen naar kunnen kijken. Daarbij moet uiteraard expliciet rekening worden gehouden met eventuele bias en ligt de uiteindelijke beoordeling altijd bij mensen.
Logs moet in gestructureerde vorm vastgelegd worden, zodat ze eenvoudig geautomatiseerd ingelezen, geanalyseerd en verder verwerkt kunnen worden. Naast analyse zijn logs ook veelal de basis voor geautomatiseerde monitoring en correlatie van gebeurtenissen. Daarnaast kan er allerlei statistische informatie uit logs worden afgeleid.
Verwijs waar mogelijk naar aangewezen bronnen voor gegevens middels de daarbij gebruikte identificaties, zoals bijvoorbeeld naar de CMDB als het gaat over applicaties of infrastructuurcomponenten.
Als gebruik wordt gemaakt van Software as a Service (SaaS) dan is het belangrijk om eisen te stellen aan de SaaS leverancier omtrent logging. Deze eisen zouden moeten gaan over bijvoorbeeld welke logs worden gemaakt, hoe inzicht kan worden verkregen in logbestanden, het formaat van de logbestanden en of logsbestanden automatisch kunnen worden verzonden.
Het is mogelijk dat de logging zelf uitvalt. Dit scenario moet expliciet worden meegenomen bij het ontwerp van informatiesystemen. Er moet worden bepaald in hoeverre het gebruik van het informatiesysteem zonder logging een acceptabel risico oplevert. In het ergste geval kan het zijn dat een applicatie in een dergelijk geval niet meer toegankelijk is in een dergelijk scenario.
Hou in de logging-infastructuur rekening met mogelijke toekomstige verzoeken om loggegevens te delen met externe partijen, zoals een extern Security Operations Center (SOC). De logbronnen die nodig zijn om de contractueel overeengekomen use cases te ondersteunen, moeten op een veilige en gestandaardiseerde wijze toegankelijk gemaakt kunnen worden (bijvoorbeeld via log-forwarding, API’s of beveiligde exports).
Logbronnen zouden moeten worden vastgelegd in een register, waarin per logbron is aangegeven wie de eigenaar is, wat de doelstelling is en wat de bewaartermijnen zijn. Dit geeft overzicht, voorkomt wildgroei, maakt logging beheersbaar en aantoonbaar, en helpt bij compliance.

Volgende hoofdstuk: Bijlage A - Bronnen