Logging

Wat is logging?

Logging is het automatisch vastleggen van gebeurtenissen in systemen, apparaten en applicaties in logbestanden, met per gebeurtenis wat er gebeurde, wanneer, waar en door wie of wat het werd veroorzaakt. Logs zijn het geheugen van een omgeving: zonder logs is achteraf niet vast te stellen wie een configuratie wijzigde, wanneer een aanvaller binnenkwam of waarom een installatie stilviel. Logging vormt daarmee de basis voor monitoring, foutopsporing, auditing en cybersecurity, zowel in IT als in OT.

🧠 Wat staat er in een logregel?

Een bruikbare logregel beantwoordt de vragen wie, wat, wanneer, waar en met welk resultaat. De vaste velden zijn:

• Tijdstempel - bij voorkeur in UTC en ISO 8601-notatie met milliseconden, bijvoorbeeld 2026-03-12T08:41:07.215Z
• Bron - hostnaam of apparaat-ID van de server, PLC, switch of applicatie
• Gebeurtenistype en ernst - bijvoorbeeld een mislukte login, een gewijzigde configuratie of een foutmelding
• Actor - gebruikersnaam, serviceaccount of proces
• Netwerkgegevens - bron- en doel-IP-adres, poort en protocol
• Resultaat - geslaagd of mislukt, met een uniek event-ID voor correlatie

Logs zijn waardevoller naarmate ze gestructureerder zijn. Velden als key-value-paren of JSON laten zich eenvoudig doorzoeken en correleren; vrije tekst vraagt om foutgevoelige parsers.

📂 Welke gebeurtenissen moet u loggen?

Niet alles loggen, maar het juiste loggen. De volgende categorieën leveren de meeste waarde voor beveiliging en beheer:

IEC 62443-3-3 noemt in eis SR 2.8 dezelfde kern: toegangscontrole, foutieve verzoeken, gebeurtenissen in het besturingssysteem (OS) en in het industriële besturingssysteem, back-up en herstel, configuratiewijzigingen, mogelijke verkenningsactiviteit en gebeurtenissen rond de auditlog zelf.

🏭 Waar komen logs vandaan in een OT-omgeving?

In IT logt vrijwel elk systeem standaard. In OT is dat anders: veel controllers en veldapparaten hebben weinig geheugen en rekenkracht, en een te zware logbelasting kan de besturing zelf hinderen. Oudere PLC’s leggen vaak alleen een diagnosebuffer vast, zonder gebruikers of security-events. De belangrijkste bronnen zijn daarom:

• Engineering stations - hier worden PLC-programma’s gewijzigd en gedownload; Windows-logs en de projectsoftware tonen wie wat deed
• HMI’s en SCADA-servers - operatorhandelingen, logins en alarmen; het audittrail van de SCADA-software is vaak de rijkste OT-bron
• Netwerkapparatuur - switches, routers en industriële firewalls sturen hun logs via syslog naar een centrale collector
• Netwerksensoren - passieve monitoring leest het verkeer mee via een SPAN-poort of TAP en ziet programma-downloads, stopcommando’s en nieuwe verbindingen, ook bij apparaten die zelf niet loggen
• Historians - tijdreeksen van procesdata die bij een onderzoek laten zien wat er fysiek gebeurde
• Windows-servers en domeincontrollers - bijvoorbeeld event-ID 4624 en 4625 (geslaagde en mislukte login), 4688 (nieuw proces) en 1102 (auditlog gewist)

Nieuwere componenten die volgens IEC 62443-4-2 zijn ontwikkeld, kunnen security-events zelf genereren en doorsturen. Bij bestaande installaties is netwerkgebaseerde logging vaak de enige realistische manier om zicht te krijgen op wat er met controllers gebeurt.

🔧 Wat zijn de ernstniveaus van logs?

Het syslog-protocol (RFC 5424) definieert acht ernstniveaus. Hoe lager het getal, hoe ernstiger de melding. Applicatieframeworks gebruiken vaak een vereenvoudigde reeks, die er grofweg als volgt op aansluit:

Let op: het ernstniveau zegt iets over de technische toestand, niet over het beveiligingsbelang. Een geslaagde login op niveau Informational kan voor een security-analist juist de belangrijkste regel van de dag zijn.

🕰️ Waarom is tijdsynchronisatie zo belangrijk?

Logs uit verschillende systemen zijn alleen te correleren als hun klokken gelijk lopen. Een afwijking van enkele minuten maakt een aanvalstijdlijn onleesbaar en kan in een audit de bewijswaarde aantasten.

• NTP haalt op een lokaal netwerk doorgaans een nauwkeurigheid van rond een milliseconde en volstaat voor vrijwel alle logging.
• PTP (IEEE 1588) bereikt met hardware-tijdstempels sub-microseconde nauwkeurigheid en wordt gebruikt waar sequence-of-events, motion control of energie-automatisering dat vereist.
• Eenrichtingsverkeer - internationale richtlijnen adviseren dat OT de tijd van IT overneemt en niet andersom, zodat beide domeinen één consistente tijdlijn delen. Bescherm de tijdbron zelf wel tegen manipulatie, want wie de klok verzet, vervalst de tijdlijn.
• UTC - log in UTC en vertaal pas bij weergave naar lokale tijd; zo ontstaan geen gaten of dubbelingen bij de overgang naar zomer- en wintertijd.

ISO 27001 (beheersmaatregel 8.17) en IEC 62443-3-3 (SR 2.11) eisen beide synchronisatie met een betrouwbare tijdbron.

🛠 Hoe richt u centraal logbeheer in?

Lokale logs worden overschreven, gewist door aanvallers of gaan verloren bij een storing. Centraal logbeheer verzamelt ze daarom op één plek. Een praktische aanpak in vijf stappen:

1. Stel een loggingbeleid op - welke assets, welke gebeurtenissen, hoe lang bewaren en wie de logs beoordeelt. Begin bij de risicoanalyse en de asset-inventaris.
2. Prioriteer de bronnen - de gezamenlijke richtlijn van onder meer ASD, CISA, NCSC-UK en de Nederlandse AIVD en MIVD uit augustus 2024 noemt voor OT als eerste: apparaten die kritiek zijn voor veiligheid en dienstverlening, apparaten met internettoegang en apparaten die via netwerkgrenzen bereikbaar zijn.
3. Verzamel per zone - plaats een logcollector in de OT-DMZ of in elke zone en stuur logs in één richting naar boven, in lijn met netwerksegmentatie. Gebruik syslog over TLS (RFC 5425, TCP-poort 6514) in plaats van onversleuteld syslog over UDP-poort 514.
4. Analyseer en alarmeer - een SIEM correleert gebeurtenissen en een OT SOC beoordeelt de meldingen. Detectieregels als PLC in programmeermodus buiten een wijzigingsvenster, nieuwe engineering-verbinding of gewiste logbestanden leveren in OT snel waarde op, mits gekoppeld aan change management.
5. Test en onderhoud - controleer periodiek of alle bronnen nog aanleveren; een bron die stilvalt is zelf een gebeurtenis die een melding verdient, in de geest van IEC 62443-3-3 SR 2.10 (reactie op het falen van de auditverwerking).

Op de bron leveren onder meer Windows Event Log, journald en syslog de gegevens; bekende tools voor centrale opslag en analyse zijn Splunk, Microsoft Sentinel, Elastic, Graylog en Wazuh, aangevuld met OT-netwerkmonitoring van partijen als Claroty, Nozomi en Dragos.

🔐 Hoe beschermt u logs tegen manipulatie?

Een aanvaller die binnen is, probeert vaak zijn sporen te wissen. Logs hebben daarom alleen bewijswaarde als ze integer en beschikbaar blijven:

• Direct doorsturen - logs verlaten het bronsysteem zo snel mogelijk, zodat wissen achteraf geen effect heeft
• Alleen-lezen toegang - IEC 62443-3-3 SR 6.1 vraagt dat geautoriseerde personen en tools logs uitsluitend lezend kunnen benaderen; SR 3.9 vereist bescherming tegen ongeautoriseerde toegang, wijziging en verwijdering
• Onveranderbare opslag - WORM-opslag, immutable back-ups of hash-ketens maken wijzigingen zichtbaar of onmogelijk
• Scheiding van rollen - beheerders van systemen beheren niet ook het logplatform
• Voldoende capaciteit - volle schijven leiden tot overschreven logs; SR 2.9 vraagt om voldoende auditopslag

⚖️ Welke wet- en regelgeving stelt eisen aan logging?

👤 Wat betekent de AVG voor logging?

Logging van gebruikersactiviteit is verwerking van persoonsgegevens. Beveiliging en wettelijke verplichtingen zijn legitieme grondslagen, maar het doel moet vastliggen en de bewaartermijn mag niet langer zijn dan nodig. Gebruik logs niet stilzwijgend voor prestatiebeoordeling van operators: een systeem dat geschikt is om gedrag of prestaties van werknemers te volgen, valt in Nederland onder het instemmingsrecht van de ondernemingsraad (artikel 27 lid 1 sub l WOR). Pseudonimiseren van gebruikersnamen in rapportages en strikte toegang tot het logplatform helpen de balans te bewaren tussen beveiliging en privacy, in lijn met privacy by design.

❓ Veelgestelde vragen

Hoe lang moet u logs bewaren?

Geen enkele wet schrijft één bewaartermijn voor alle securitylogs voor; de termijn volgt uit risicoanalyse en sectorregels. Internationale richtlijnen wijzen erop dat het ontdekken van een incident tot 18 maanden kan duren, dus security-logs korter dan een jaar bewaren is vaak te kort. Voor machine-ingrepen onder de Machineverordening geldt vijf jaar en voor GMP-audittrails dezelfde termijn als de bijbehorende records.

Loggen PLC’s zelf security-events?

De meeste oudere PLC’s leggen alleen diagnose- en foutmeldingen vast, zonder gebruikers of programmawijzigingen als security-event. Nieuwere controllers die volgens IEC 62443-4-2 zijn ontwikkeld kunnen auditlogs via syslog doorsturen. Voor bestaande PLC’s vult passieve netwerkmonitoring dat gat door programma-downloads en stopcommando’s in het verkeer te herkennen.

Wat is het verschil tussen logging en monitoring?

Logging legt gebeurtenissen vast en bewaart ze als bewijs; monitoring analyseert die gegevens en alarmeert bij afwijkingen. Zonder logging heeft monitoring geen bron, en zonder monitoring blijven logs ongelezen tot na een incident. ISO 27001 behandelt beide daarom als afzonderlijke beheersmaatregelen 8.15 en 8.16.

Is syslog veilig genoeg voor securitylogs?

Klassiek syslog over UDP-poort 514 is onversleuteld, niet geauthenticeerd en kan berichten ongemerkt verliezen. Syslog over TLS volgens RFC 5425 op TCP-poort 6514 beschermt vertrouwelijkheid en integriteit onderweg en gebruikt betrouwbaarder transport via TCP. In OT-netwerken kan een lokale collector per zone oude apparaten via UDP ontvangen en versleuteld doorsturen.

Heeft u een SIEM nodig om te loggen?

Logging kan zonder SIEM, maar een centrale logserver alleen bewaart en doorzoekt; een SIEM correleert gebeurtenissen uit meerdere bronnen en genereert alarmen. Kleinere organisaties beginnen vaak met centrale opslag en een beperkt aantal detectieregels. Voor OT is een SIEM het meest waardevol in combinatie met netwerkmonitoring die OT-protocollen begrijpt.

Mag logging de besturing vertragen?

Logging mag de beschikbaarheid en het tijdgedrag van een besturing nooit in gevaar brengen. Daarom wordt in OT vooral gelogd op engineering stations, servers en netwerkapparatuur, en wordt passief meegeluisterd op het netwerk in plaats van controllers actief te bevragen. Nieuwe logfuncties op controllers worden eerst getest in een testomgeving voordat ze in productie gaan.

📌 Samengevat

Logging legt vast wat er wanneer en door wie in IT- en OT-systemen gebeurt, en is daarmee onmisbaar voor incidentdetectie, forensisch onderzoek en compliance.

In OT vraagt logging extra aandacht: veel controllers loggen nauwelijks, dus engineering stations, HMI’s, netwerkapparatuur en passieve netwerksensoren vullen dat aan. Gesynchroniseerde klokken, centrale en manipulatiebestendige opslag, een bewuste bewaartermijn en aandacht voor privacy maken van losse logregels bruikbaar bewijs voor forensisch onderzoek, incident response en compliance-audits onder NIS2, de Machineverordening en GMP.