OT‑securityarchitectuur: van Purdue‑model tot incidentrespons
Een robuuste OT‑securityarchitectuur begint met een helder beeld van de omgeving die beschermd moet worden. In Nederlandse praktijk gaat het vaak om gemengde installaties waarin moderne digitale componenten samenwerken met tientallen jaren oude PLC’s, veldapparatuur en gespecialiseerde systemen van verschillende leveranciers. Veel van deze componenten zijn ooit ontworpen voor gesloten netwerken zonder externe koppelingen. Inmiddels zijn zij via remote onderhoud, rapportage naar centrale systemen of integratie met cloudplatforms toch verbonden geraakt met de buitenwereld. Dat maakt een gestructureerde aanpak onmisbaar.
Het Purdue‑model biedt hiervoor een praktische referentiearchitectuur. Op het laagste niveau (Level 0) bevinden zich de fysieke processen: sensoren, actuatoren, motoren, kleppen en veldapparatuur. Level 1 bevat de intelligente apparaten zoals PLC’s en remote terminal units die de directe besturingslogica uitvoeren. Op Level 2 bevinden zich de SCADA-systemen en HMI’s waarmee operators processen bewaken en aansturen. Level 3 omvat productiebesturing, rapportage en historische dataopslag, terwijl Level 4 het reguliere IT‑domein vormt met kantoorautomatisering, bedrijfsapplicaties en cloudkoppelingen. Een veilige OT‑architectuur brengt strikte netwerksegmentatie aan tussen deze niveaus, met zorgvuldig geconfigureerde firewalls, data diodes of unidirectionele gateways, en duidelijk gedefinieerde datastromen. Ad-hoc VPN‑verbindingen, rechtstreeks beheer vanaf laptops in het kantoordomein of ongecontroleerde remote access zijn in zo’n model expliciet verboden.
Legacy‑systemen vormen in vrijwel elke OT‑omgeving een grote uitdaging. Besturingssystemen die alleen nog Windows XP Embedded of oude firmware ondersteunen, kunnen vaak niet worden gepatcht zonder het proces stil te leggen of de leverancier intensief te betrekken. In plaats van te vertrouwen op klassieke endpointbeveiliging, moeten organisaties daarom compenserende maatregelen inrichten. Dat begint met het isoleren van kwetsbare assets in streng afgeschermde subnetten, met uitsluitend noodzakelijke protocollen en streng gecontroleerde beheerpaden. Aanvullend worden gedetailleerde netwerkmonitoring en “allow‑list” regelframeworks toegepast, zodat alleen voorspelbaar en noodzakelijk verkeer wordt toegestaan. Regelmatige kwetsbaarheidsanalyses, in nauw overleg met de proceseigenaren, maken inzichtelijk welke risico’s bewust worden geaccepteerd en welke aanvullende maatregelen nodig zijn.
Een echte OT‑architectuur is altijd safety‑first. Elke beveiligingsmaatregel – van het aanscherpen van firewallregels tot het inschakelen van inspectie op industriële protocollen – moet worden getest in een representatieve testomgeving of tijdens zorgvuldig voorbereide onderhoudsvensters. Hierbij wordt niet alleen gekeken of de maatregel technisch werkt, maar vooral of procesveiligheid en beschikbaarheid onbeïnvloed blijven. Organisaties leggen testscenario’s vast, definiëren duidelijke rollback‑procedures en zorgen dat operators en engineers vooraf geïnformeerd en betrokken zijn. Pas wanneer aangetoond is dat een wijziging geen negatieve impact heeft op de procesbesturing, wordt deze in productie doorgevoerd.
Specifieke OT‑monitoring is een ander kernelement van de architectuur. In plaats van uitsluitend generieke IT‑logs te verzamelen, maken organisaties gebruik van oplossingen die industriële protocollen zoals Modbus, DNP3, IEC 61850 of PROFINET kunnen interpreteren. Deze oplossingen herkennen bijvoorbeeld ongebruikelijke schrijfcommando’s naar registers, onverwachte wijzigingen in firmwareversies of configuratie, of verbindingen vanuit hosts die nooit eerder op het OT‑netwerk zichtbaar waren. Waar traditionele IT‑monitoring dit verkeer als ‘normale TCP‑communicatie’ zou zien, kan een OT‑bewuste oplossing direct gericht alarm slaan en zo sabotage of misconfiguraties in een vroeg stadium detecteren.
Toegangsbeheer in OT‑omgevingen vraagt eveneens om een strengere discipline dan in traditionele kantooromgevingen. Alleen medewerkers met een aantoonbare operationele rol krijgen toegang tot het OT‑domein, bij voorkeur via jump‑servers met multi‑factor‑authenticatie en uitgebreide sessieregistratie. Tijdelijke toegang voor leveranciers wordt vooraf aangevraagd, beperkt in tijd en scope en zoveel mogelijk begeleid. Waar mogelijk worden changes via geautomatiseerde deployment‑processen doorgevoerd, zodat individuele engineers niet rechtstreeks in PLC‑logica of SCADA‑configuraties wijzigen.
Tot slot moet incidentrespons expliciet rekening houden met OT‑specifieke scenario’s. Klassieke IT‑maatregelen zoals het direct uitschakelen van systemen of het abrupt blokkeren van netwerksegmenten kunnen in OT leiden tot onveilige situaties of langdurige productiestilstand. Daarom werken organisaties met gecombineerde IT‑ en OT‑responsteams die bij een incident eerst een veiligheidsbeoordeling uitvoeren: welke acties zijn technisch mogelijk zonder processen in gevaar te brengen? Soms betekent dit dat een systeem kortdurend onder gecontroleerd risico blijft draaien, terwijl parallel mitigaties worden voorbereid. Forensische onderzoeken worden zodanig ingericht dat logbestanden, netwerkcaptures en configuratieback‑ups beschikbaar blijven, zonder de besturing onnodig te verstoren. Een volwassen OT‑securityarchitectuur verbindt al deze elementen – segmentatie, legacy‑beheer, safety‑first testen, gespecialiseerde monitoring, streng toegangsbeheer en aangepaste incidentrespons – tot één consistent geheel dat zowel veiligheid als continuïteit waarborgt.