Elk securityverhaal over OT begint tegenwoordig met Zero Trust. En terecht. Het principe is goed: vertrouw niets impliciet, verifieer waar mogelijk, beperk toegang en verklein de blast radius.
Maar probeer dat maar eens uit te leggen aan een Siemens S7-300 uit 2008.
Die PLC heeft geen TLS-stack. Geen certificaatopslag. Geen moderne authenticatie. Hij praat Profinet, MPI of misschien Modbus/TCP. Hij doet al vijftien jaar precies wat hij moet doen. De lijn draait erop. De operators kennen zijn gedrag. De storingstechnicus weet welke lampjes normaal zijn. En ergens draait nog een engineering laptop met software die niemand graag opnieuw installeert.
Je gaat die PLC dus niet zomaar vervangen. Niet omdat security niet belangrijk is. Maar omdat de lijn dan weken stilstaat, de leverancier misschien niet meer bestaat, de documentatie incompleet is en niemand exact weet wat er in dat programma gebeurt.
Dat is de werkelijkheid van OT-security. Niet de whitepaper-versie. De fabriekshalversie.
Het probleem met “gewoon segmenteren”
Segmentatie wordt vaak gepresenteerd alsof het een kwestie is van VLANs aanmaken en firewallregels schrijven. In IT kom je daar soms nog een eind mee. Endpoints spreken TCP/IP, ondersteunen TLS, authenticeren tegen een identity provider en kunnen relatief eenvoudig worden gepatcht.
In OT zit je in een ander universum. Devices die geen moderne beveiliging ondersteunen. Protocollen zonder authenticatie. Firmware die niet gepatcht kan worden. Seriële verbindingen die via converters ineens op het netwerk zitten. Engineering workstations die zowel bij kantoor-IT als bij het procesnetwerk moeten. Leveranciers die remote access willen via TeamViewer op een gedeelde laptop.
Segmentatie in OT is daarom geen netwerkvraagstuk. Het is een ontwerpvraagstuk. Je moet niet alleen weten welke systemen met elkaar praten — je moet begrijpen waarom ze dat doen, en wat er fysiek gebeurt als je die communicatie onderbreekt.
Zones en conduits: IEC 62443 in de praktijk
IEC 62443 geeft hiervoor het juiste denkraam: zones en conduits. Een zone is een groep assets met een vergelijkbaar risicoprofiel en dezelfde functie. Een conduit is de gecontroleerde verbinding tussen zones.
In de praktijk: een groep PLC’s die samen één productielijn aansturen, vormen een zone. De SCADA-server die ze uitleest, zit in een andere zone. Het communicatiepad daartussen is het conduit — en precies daar dwing je controle af.
De sleutel: je hoeft de PLC zelf niet modern te maken. Een oude PLC kan geen TLS spreken, maar het netwerksegment eromheen kun je wel degelijk begrenzen, monitoren en controleren. In OT zit de verdediging niet in het device. De verdediging zit eromheen.
Wat je op de grens doet
Protocol-aware firewalls. Geen standaard enterprise firewall die alleen poorten ziet. Want TCP-poort 502 toestaan is niet hetzelfde als veilig Modbus-verkeer toestaan. Een Modbus read is iets anders dan een Modbus write. Data uitlezen is iets anders dan een coil forceren.
Een goede OT-firewall begrijpt dat verschil. SCADA mag registers lezen. Engineering mag schrijven, maar alleen via een gecontroleerd workstation. Leveranciers komen alleen binnen via een jump host. Onderhoudstoegang is tijdelijk, gelogd en herleidbaar.
Unidirectionele gateways. Als een zone alleen data hoeft te leveren — procesdata naar een historian of cloudplatform — is er geen reden voor bidirectionele communicatie. Een data diode is geen firewallregel. Het is een fysieke beperking. Data kan naar buiten, verkeer kan niet terug. Je hoeft de PLC niet te leren vertrouwen op certificaten. Je zorgt ervoor dat er simpelweg geen retourpad bestaat.
Niet alles hoeft slimmer te worden. Soms moet de architectuur gewoon strenger worden.
Monitoring op het conduit. Niet alles kun je blokkeren — in OT kan een verkeerde firewallregel productie stilleggen. Maar als je verkeer niet kunt versleutelen, kun je het wel inspecteren. Deep packet inspection op OT-protocollen laat zien welke commando’s over de lijn gaan.
Een PLC die al drie jaar niet is gewijzigd en ineens een firmware-upload ontvangt, verdient aandacht. Een engineering workstation dat buiten onderhoudstijd schrijft naar controllers, verdient aandacht. Een onbekend device dat communiceert met een productielijn, verdient aandacht.
In OT gaat security niet alleen over blokkeren. Het gaat over normaal gedrag begrijpen en afwijkingen herkennen.
Het Purdue-model als startpunt
In de praktijk is het Purdue-model nog steeds bruikbaar — niet als dogma, maar als gespreksmodel. Onderaan de fysieke processen en controllers, daarboven SCADA en HMI, daarboven site operations met historians, MES en engineering workstations. Tussen OT en IT een echte DMZ met jump servers, patch proxies en data-export.
Maar de grootste winst zit vaak niet op de IT/OT-grens. Die krijgt meestal wel aandacht. De vergeten grenzen zitten lager: tussen productiecellen onderling, tussen procesnetwerk en safety-netwerk, tussen een oude seriële wereld en een nieuw IP-netwerk.
Juist daar liggen de risico’s die niemand meer ziet, omdat het ooit als één plat netwerk is aangelegd en daarna altijd is blijven werken. Totdat het niet meer werkt.
NIS2 maakt vrijblijvendheid moeilijker
Met NIS2 wordt OT-security minder vrijblijvend. Voor sectoren als energie, water, voedselproductie, industrie en andere vitale of belangrijke processen wordt het steeds belangrijker om passende en evenredige maatregelen te kunnen onderbouwen. “We hebben een firewall tussen IT en OT” is dan niet meer genoeg.
Je moet kunnen uitleggen welke assets je hebt, hoe je OT-omgeving is ingedeeld, welke communicatiestromen noodzakelijk zijn, hoe remote access is geregeld en hoe incidenten worden gedetecteerd.
IEC 62443 helpt daarbij. Niet omdat het alles oplost, maar omdat het een taal geeft die past bij industriële omgevingen. Als je segmentatie kunt uitleggen in termen van zones, conduits en beheersmaatregelen, heb je een verhaal dat technisch klopt én bestuurlijk uitlegbaar is.
Waar je begint
De verleiding is om te beginnen met technologie. Firewalls selecteren, VLANs tekenen, monitoringtools vergelijken.
Begin daar niet.
Begin met een asset inventory. Niet wat er in de documentatie staat — wat er echt staat. Welke PLC’s, switches, converters, engineering laptops, vendor-systemen en oude koppelingen bestaan er werkelijk?
Breng daarna de communicatie in kaart. Welk device praat met welk device, via welk protocol, in welke richting, en waarom? Dat “waarom” is cruciaal. Als niemand kan uitleggen waarom twee systemen met elkaar praten, heb je óf een risico gevonden óf een overbodige verbinding.
Pas dan ga je zones tekenen. Op basis van functie, risico en operationele samenhang — niet op basis van IP-ranges.
En bij elke zone en elk conduit hoort eigenaarschap. Wie mag wijzigingen goedkeuren? Wie controleert de firewallregels? Wie valideert periodiek of de communicatie nog nodig is? Zonder eigenaarschap wordt segmentatie een tekening. Met eigenaarschap wordt het beheersing.
De kern
OT-security faalt zelden omdat mensen Zero Trust of IEC 62443 niet kennen. Het faalt omdat die modellen te vaak blijven hangen boven de fabriekshal.
Een oude PLC gaat geen moderne security ondersteunen. Een Modbus-verbinding wordt niet ineens veilig. Een lijn die al vijftien jaar draait, vervang je niet omdat de securityarchitectuur dat mooier vindt.
Daarom begint OT-security niet met vertrouwen, en ook niet met wantrouwen. Het begint met grenzen.
Je hoeft een Siemens S7-300 niet uit te leggen wat Zero Trust is. Je moet het netwerk eromheen zo ontwerpen dat hij dat ook niet hoeft te begrijpen.