"Waarom patchen jullie niet gewoon?" Het is de vraag die elke OT-engineer minstens eenmaal per kwartaal krijgt van een IT-collega of auditor. De vraag klinkt logisch. In de IT-wereld is patchen de heilige graal van vulnerability management: er komt een CVE uit, de vendor levert een patch, u test en rolt uit. Klaar. Maar in de operationele technologie is deze ogenschijnlijk simpele cyclus een nachtmerrie die productiestoringen, veiligheidsproblemen en miljoenen euro's schade kan veroorzaken.
Dit artikel legt uit waarom het IT-patchmodel fundamenteel niet werkt in OT-omgevingen, en — belangrijker nog — welke compenserende maatregelen u kunt implementeren om uw systemen toch te beschermen.
Patchen in IT
Patchen in OT
De vijf redenen waarom OT niet kan patchen zoals IT
1. Beschikbaarheidseisen die geen compromis dulden. Een productieplant die 24/7 draait, kan niet even een uurtje uit voor een Windows-update. Een geplande stop voor onderhoud kost een gemiddeld chemiebedrijf tussen de 500.000 en 2 miljoen euro. Deze stops worden maanden van tevoren ingepland en elke minuut is zorgvuldig gebudgetteerd. Een patch die een onverwachte reboot vereist of — erger — een systeem instabiel maakt, is simpelweg onacceptabel. De beschikbaarheidseis in OT is niet 99,9% (8,7 uur downtime per jaar, standaard voor IT). Het is 99,99% of hoger: maximaal 52 minuten ongeplande downtime per jaar.
2. Vendor-certificering en garantie. Veel OT-systemen zijn gecertificeerd door de leverancier voor een specifieke softwareconfiguratie. Een Siemens PCS 7 DCS draait op een specifieke versie van Windows met specifieke service packs en hotfixes. Wanneer u een Microsoft-patch installeert die niet door Siemens is goedgekeurd, vervalt de certificering — en daarmee mogelijk uw garantie en ondersteuningscontract. Hetzelfde geldt voor systemen van Honeywell, Emerson, ABB, Yokogawa en vrijwel elke andere grote OT-vendor. Het certificeringsproces duurt typisch 3 tot 18 maanden nadat Microsoft een patch heeft uitgebracht. Bij kritieke kwetsbaarheden is dat een onaanvaardbaar lange blootstelling.
3. Legacy systemen zonder patches. Een aanzienlijk deel van de OT-omgevingen draait op besturingssystemen waarvoor simpelweg geen patches meer beschikbaar zijn. Windows XP Embedded is nog steeds wijdverspreid in HMI-systemen. Windows Server 2003 draait nog op talloze SCADA-servers. Sommige systemen draaien op Windows NT 4.0 of zelfs MS-DOS. Voor deze systemen zijn geen patches meer beschikbaar, ongeacht de kwetsbaarheid. Het vervangen van het besturingssysteem is vaak onmogelijk zonder ook de applicatiesoftware en vaak de hardware te vervangen — een project van honderdduizenden tot miljoenen euro's.
4. Onvoorspelbare bijwerkingen. OT-software is vaak nauw gekoppeld aan specifieke systeemconfiguraties, DLL-versies, driver-stacks en timing-parameters. Een ogenschijnlijk onschuldige patch kan subtiele veranderingen introduceren die pas dagen later manifest worden: een communicatie-timeout die net iets langer wordt, een prioriteitswijziging in de taakplanning die een real-time loop verstoort, een DLL-update die een legacy-driver incompatibel maakt. In IT zijn dit vervelende bugs. In OT kunnen ze leiden tot procesverstoringen met fysieke consequenties.
5. Geen representatieve testomgeving. In IT kunt u een patch testen in een virtuele omgeving die identiek is aan productie. In OT is het fysieke proces — de chemische reactor, de waterzuiveringsinstallatie, de hoogoven — niet te virtualiseren. U kunt de software testen, maar niet de interactie met het daadwerkelijke proces. De enige echte test is de productieomgeving zelf, en dat is een test die u niet wilt doen met een onbewezen patch.
Compenserende maatregelen: wat wél werkt
Het onvermogen om te patchen betekent niet dat u machteloos bent. Er bestaat een uitgebreid arsenaal aan compenserende maatregelen die het risico van ongepatchte systemen substantieel kunnen verlagen. De IEC 62443-standaard erkent expliciet dat patchen niet altijd mogelijk is en biedt een raamwerk voor alternatieve beschermingsmaatregelen.
Netwerksegmentatie is de meest fundamentele en effectieve compenserende maatregel. Door uw OT-netwerk op te delen in zones (gebaseerd op functie en risiconiveau) en de communicatie tussen zones strikt te beperken tot gedefinieerde conduits, beperkt u de bewegingsruimte van een aanvaller drastisch. Zelfs als een ongepatchte HMI wordt gecompromitteerd, kan de aanvaller niet lateraal bewegen naar andere zones als de segmentatie correct is geïmplementeerd. Gebruik industriële firewalls — geen consumentenhardware — die OT-protocollen begrijpen en op applicatieniveau kunnen filteren.
Application whitelisting is bijzonder effectief in OT-omgevingen. Omdat OT-systemen een voorspelbaar en stabiel gedragspatroon hebben (dezelfde applicaties, dezelfde processen, dezelfde communicatiepatronen), is whitelisting hier veel praktischer dan in IT. Configureer uw HMI's en engineering workstations zodat alleen goedgekeurde applicaties kunnen draaien. Elke poging om onbekende software uit te voeren — inclusief ransomware, malware of attackertools — wordt geblokkeerd, ongeacht of het systeem gepatcht is.
OT-specifieke monitoring en anomaliedetectie vormt de ogen en oren van uw verdediging. Passieve netwerkmonitoring met tools als Nozomi Networks, Claroty of Dragos observeert al het verkeer op uw OT-netwerk zonder enig risico voor de productie. Deze tools herkennen OT-protocollen, bouwen automatisch een baseline van normaal gedrag en alarmeren bij afwijkingen: een nieuwe verbinding naar een PLC, een ongebruikelijk commando op het Modbus-protocol, een download van firmware buiten het onderhoudsvenster. Dit compenseert het gebrek aan patches door aanvallen te detecteren voordat ze schade aanrichten.
Strikte toegangscontrole reduceert het aanvalsoppervlak van ongepatchte systemen. Implementeer het principe van least privilege: geen enkele gebruiker of systeem heeft meer rechten dan strikt noodzakelijk. Verwijder onnodige services, sluit ongebruikte poorten, deactiveer standaardaccounts en implementeer multi-factor authenticatie op alle toegangspunten. Veel exploits voor bekende kwetsbaarheden vereisen netwerktoegang of specifieke privileges — door deze te beperken, maakt u de kwetsbaarheid minder exploiteerbaar, zelfs zonder patch.
Removable media control is cruciaal in air-gapped of geïsoleerde omgevingen. USB-sticks en externe harde schijven zijn een van de primaire infectievectoren in OT-netwerken (denk aan Stuxnet). Implementeer strikte controles op alle removable media: scanning op geauthenticeerde kiosken voordat media het OT-netwerk bereikt, technische blokkering van ongeautoriseerde USB-apparaten, en een administratief proces voor het goedkeuren en loggen van elk gebruik van removable media.
Het IEC 62443-raamwerk voor compenserende maatregelen
IEC 62443 biedt een gestructureerde aanpak voor het omgaan met kwetsbaarheden in OT-omgevingen. De standaard definieert Security Levels (SL) van 1 tot 4, en erkent dat niet elke zone hetzelfde beschermingsniveau nodig heeft. Voor systemen die niet gepatcht kunnen worden, schrijft de standaard voor dat het risico via andere maatregelen tot een acceptabel niveau moet worden teruggebracht.
De praktische aanpak is als volgt:
- Identificeer alle ongepatchte systemen en hun kwetsbaarheden (CVE's)
- Classificeer het risico op basis van de kwetsbaarheid (CVSS-score), de bereikbaarheid (netwerktoegang) en de impact (wat kan een aanvaller doen bij exploitatie)
- Selecteer compenserende maatregelen die het risico aantoonbaar reduceren tot onder het acceptabele niveau
- Implementeer de maatregelen en documenteer de rationale
- Monitor continu of de maatregelen effectief blijven en pas aan wanneer het dreigingslandschap verandert
Belangrijk: Compenserende maatregelen zijn geen vervanging voor patchen — ze zijn een aanvulling voor wanneer patchen niet mogelijk is. Waar u kunt patchen, moet u patchen. De kunst is om pragmatisch te bepalen waar de grens ligt en voor de rest een solide set compenserende maatregelen te implementeren.
Een realistisch patchbeleid voor OT
Een volwassen OT-patchbeleid erkent de realiteit en werkt ermee in plaats van ertegen. Categoriseer uw OT-assets in drie groepen:
- Patchbaar: Systemen die kunnen worden gepatcht met aanvaardbaar risico — bijvoorbeeld Windows 10/11 engineering workstations met vendor-goedgekeurde patches. Patch deze systemen volgens een gedefinieerd schema, bij voorkeur tijdens geplande onderhoudsstops.
- Beperkt patchbaar: Systemen waarvoor patches beschikbaar zijn maar waar de vendor-certificering of beschikbaarheidseisen het proces vertragen. Implementeer compenserende maatregelen als tussenoplossing en plan patching in bij de eerstvolgende geplande stop.
- Niet patchbaar: Legacy systemen op end-of-life besturingssystemen of embedded apparaten zonder update-mogelijkheid. Implementeer maximale compenserende maatregelen en neem vervanging op in uw meerjarenplan voor kapitaalinvesteringen.
De weg vooruit
Het "patchen of niet patchen"-vraagstuk in OT is een vals dilemma. De werkelijkheid is genuanceerder: u patcht waar u kunt, compenseert waar u moet en plant vervanging waar geen van beide mogelijk is. Het vergt een nauwe samenwerking tussen IT-security, OT-engineering en management om de juiste balans te vinden tussen cyberveiligheid, productiecontinuïteit en investeringskosten.
Wat niet werkt, is niets doen. Een ongepatchte OT-omgeving zonder compenserende maatregelen is geen geaccepteerd risico — het is een onbeheerst risico. En dat is in geen enkel raamwerk, geen enkele standaard en geen enkele boardroom acceptabel.