OT vulnerability management is geen IT patch management

“Er staat een 9.8 open. Die moet gepatcht.”

Dat klinkt als daadkracht. Maar het is geen risicobesluit, het is een getal voorlezen. En in een OT-omgeving is dat precies de plek waar het misgaat, en wel twee kanten op tegelijk.

De eerste kant: je patcht iets wat niemand kon bereiken, in een window dat je maar twee keer per jaar hebt, en de echte blootstelling blijft staan. De tweede kant, en die is duurder: je patcht een systeem waarvan de leverancier de update nog niet heeft gevalideerd, de HMI komt niet terug, en je hebt je eigen productie stilgelegd met een securitymaatregel.

De vraag is niet “is er een CVE?”. De vraag is “kan iemand hier realistisch bij, en wat kost het om er iets aan te doen?”

Wat een CVSS-score wel en niet zegt

CVSS beschrijft eigenschappen van een kwetsbaarheid: hoe die te bereiken is, hoe ingewikkeld het misbruik is, welke rechten ervoor nodig zijn en wat de impact op het product is. Dat is nuttig. Het is alleen niet jouw risico, want CVSS weet niets van jouw architectuur, jouw proces en jouw maatregelen.

Wat bijna niemand gebruikt: CVSS v4.0 heeft naast de Base-metrics ook Threat-metrics (is er exploitcode, wordt het misbruikt) en Environmental-metrics (hoe kritiek is dit asset bij jou, welke maatregelen staan er al). De score die in de meeste rapportages staat is alleen de Base-score, en die is bewust context-loos. Dat is geen fout in CVSS. Het is een misverstand over wat je in handen hebt.

Hetzelfde doel, een andere uitvoering

Dit staat niet op zichzelf. Het is één geval van een bredere fout: aannemen dat een maatregel die in IT werkt, ongewijzigd naar een industriële omgeving kan.

Het beveiligingsdoel is meestal identiek. De uitvoering kan dat vaak niet zijn. In IT weegt vertrouwelijkheid zwaar, patch je snel, en zijn endpoints gestandaardiseerd genoeg om ze centraal te beheren. In OT moet hetzelfde besluit ook rekening houden met:

• beschikbaarheid: het proces moet blijven draaien, en stilstand is de schade;
• procesveiligheid: een verkeerde ingreep kan mensen raken, niet alleen data;
• levensduur van apparatuur: een PLC van vijftien jaar oud is geen achterstand maar een investeringsritme;
• certificering door de leverancier: patchen buiten wat de OEM heeft gevalideerd kan je support of je certificaat kosten;
• deterministische communicatie: een paar milliseconden vertraging door een securitymaatregel kan een besturing uit de pas laten lopen;
• onderhoudsvensters: je kunt niet ingrijpen wanneer je wilt, maar wanneer het proces het toelaat;
• herstelbaarheid: kun je terug, en heb je dat ooit geprobeerd.

Dat betekent niet dat OT met minder beveiliging toe kan. Dat is de verkeerde conclusie, en hij wordt vaak getrokken. Het betekent dat de maatregel vertaald moet worden naar de omgeving waarin hij moet werken. Een firewallregel die het aanvalspad sluit, is in OT vaak een betere maatregel dan een patch die het proces stillegt. Niet omdat het minder streng is, maar omdat het risico als geheel kleiner wordt.

Het gaat niet om IT-security tegenover OT-security. Het gaat om beveiliging die standhoudt wanneer de gevolgen fysiek zijn.

Begin met context, niet met de score

Voordat je iets vindt van een kwetsbaarheid, wil je een handvol dingen weten. Niet omdat het hoort, maar omdat elk van deze punten het besluit kan omdraaien:

• asset en zone: waar staat het, en achter welke conduit;
• functie: wat doet dit ding in het proces;
• criticaliteit: voor veiligheid, voor productie, of ondersteunend;
• blootstelling: vanaf waar is het bereikbaar, en door wie;
• aanvalspad: via welke stappen komt iemand er echt bij;
• exploit beschikbaar: theorie, proof of concept, of kant-en-klaar;
• actief misbruik: wordt het nu gebruikt, ergens ter wereld;
• benodigde rechten: anoniem, gebruiker, of al binnen;
• leverancierssteun: is dit product nog ondersteund;
• patch beschikbaar en gevalideerd: door de OEM, voor jouw versie;
• downtime nodig: herstart, revalidatie, of niets;
• bestaande maatregelen: wat vangt het nu al af;
• terugvalpad: kun je terug als het misgaat.

Dertien punten lijkt veel. In de praktijk vul je ze in vijf minuten in als je asset-informatie op orde is, en als dat niet zo is, heb je dat nu ook geleerd. Een kwetsbaarheid waarvan je niet weet in welke zone hij staat, is geen patchvraag maar een architectuurvraag.

Blootstelling vóór patchstatus

De volgorde doet ertoe. De meeste organisaties beginnen bij “is er een patch?” en komen pas daarna toe aan “maakt het uit?”. Draai dat om, want de eerste vraag kost geld en de tweede is gratis.

Kan een aanvaller hier realistisch bij, en dit ook echt misbruiken?

Loop de keten langs, in deze volgorde:

1. Bron: vanaf waar zou een aanval beginnen? Internet, IT-netwerk, leverancierslaptop, USB, een aangrenzende zone?
2. Bereikbaarheid: is er een pad van die bron naar dit asset? Niet in theorie, maar in de firewallregels zoals ze vandaag staan.
3. Kwetsbare service: draait de kwetsbare component eigenlijk wel, en staat de poort open? Bij OT-producten zit de kwetsbare bibliotheek vaak in een functie die je niet gebruikt.
4. Benodigde rechten: moet iemand eerst inloggen, of is het anoniem?
5. Impact: wat gebeurt er als het lukt: verlies van zicht, verlies van sturing, of alleen een dienst die omvalt?

Als het pad ergens breekt, is de urgentie een andere. Dat is geen excuus om niets te doen. Het is de onderbouwing waarom dit ding niet vannacht hoeft.

Wordt het echt misbruikt?

“Er bestaat een exploit” en “dit wordt gebruikt” zijn twee verschillende dingen, en er zijn openbare bronnen die het verschil maken:

• de KEV-catalogus van CISA, met kwetsbaarheden waarvan is vastgesteld dát ze worden misbruikt. Staat je CVE erin, dan is de discussie over waarschijnlijkheid voorbij;
• EPSS, een kansinschatting dat een kwetsbaarheid in de komende dertig dagen wordt misbruikt. Geen zekerheid, wel een veel betere sortering dan CVSS alleen;
• VEX-verklaringen van de leverancier: een expliciete uitspraak of dít product in díe configuratie geraakt wordt. Veel OT-leveranciers publiceren inmiddels machineleesbare advisories in CSAF-formaat met VEX erin. Een *not affected* van de fabrikant is een van de sterkste onderbouwingen die er bestaat, en hij kost je niets.

Dit is ook waar je de meeste ruis wegsnijdt. Een kwart van wat een scanner meldt verdwijnt op een VEX-verklaring of op “die functie draait hier niet”.

De oplossing brengt zelf risico mee

Hier komen die factoren van hierboven samen, want patchen is de maatregel waar ze allemaal tegelijk op drukken. In IT is een patch meestal de veilige keuze. In OT is patchen een wijziging aan een draaiend proces: en een wijziging heeft een eigen risicoprofiel, los van de kwetsbaarheid die je ermee wilde oplossen.

Wat er in de praktijk misgaat is zelden spectaculair: een HMI die na de update niet meer met de besturing praat, een productiestop die meer kost dan het scenario dat je afdekte, of een terugvalpad waarvan iedereen aannam dat het werkte tot het moment dat het nodig was. Een maatregel die je proces stillegt is geen veilige keuze, hoe goed hij op papier ook staat.

En apart daarvan, omdat het echt anders is: een wijziging aan een veiligheidsinstrumentatie is geen patch. Dat valt onder functionele veiligheid (IEC 61511) en vraagt om een management-of-change-traject met revalidatie. Wie een SIS-update op dezelfde lijst zet als een HMI-update, maakt vroeg of laat een dure fout.

IEC 62443-2-3 gaat precies hierover: patchbeheer in een IACS-omgeving, inclusief de rolverdeling tussen jou en je leverancier. De kern ervan is dat een patch pas een optie is als de leverancier hem voor jouw versie heeft gevalideerd, en dat de tijd tussen “CVE gepubliceerd” en “gevalideerde patch beschikbaar” gewoon bestaat. Die periode is geen gat in je proces. Die periode ís je proces.

Het besluit: vier uitkomsten, geen vijfde

Elke kwetsbaarheid eindigt in precies één van vier uitkomsten. Niet in “staat op de lijst”, want dat is geen besluit.

Deze vorm is niet nieuw en dat is juist het punt: het is in de kern SSVC, de beslisboom-aanpak die CISA gebruikt in plaats van sorteren op score. Dat je een erkende methode volgt in plaats van een eigen schema, scheelt een discussie bij de eerste audit.

PATCH

Als er een door de leverancier gevalideerde patch is, de blootstelling ertoe doet, en de operationele impact binnen een beschikbaar window past. Dat is de makkelijke uitkomst, en in OT de minst voorkomende.

MITIGATE

Je haalt de kwetsbaarheid niet weg, je haalt het pad ernaartoe weg. Dit is in de praktijk de meest gebruikte uitkomst, en vaak de beste:

• een firewallregel of ACL die het pad sluit;
• de kwetsbare functie of poort uitzetten als je hem niet gebruikt;
• remote access beperken tot een jump host met sessieopname;
• de zone strakker afbakenen;
• protocolfiltering, zodat alleen de commando's langskomen die nodig zijn;
• application allowlisting op het workstation;
• gerichte detectie op precies dit gedrag, zodat je het merkt als het gebeurt.

Een mitigatie is pas af als je hebt gecontroleerd dat hij doet wat je denkt. Een firewallregel die naast het echte pad ligt, geeft alleen maar een beter gevoel.

MONITOR

Als de blootstelling laag is, misbruik theoretisch, de bestaande maatregelen aantoonbaar werken, en het patchrisico groter is dan het actuele cyberrisico.

Monitor is een besluit, geen wachtstand. Om die uitkomst te mogen gebruiken moet je kunnen zeggen: wat monitoren we precies, waar zou het opvallen, en op welke datum kijken we opnieuw. Ontbreekt een van die drie, dan is het geen monitor maar uitstel.

ACCEPT

Alleen als het restrisico expliciet is begrepen en belegd. Vier voorwaarden, en ze zijn hard:

1. het restrisico staat beschreven in gevolgen, niet in een score;
2. er is een persoon die het draagt, en een afdeling is geen eigenaar;
3. het besluit is vastgelegd, met de onderbouwing erbij;
4. er staat een reviewdatum, en die staat in iemands agenda.

Zo'n vastgelegd accept is bestuurlijk sterker dan een lijst met vijfhonderd open bevindingen. Het laat zien dat er is nagedacht. Een open lijst laat alleen zien dat er is gescand.

De scorekaart: om het gesprek te structureren

Naast de beslisboom helpt het om zeven factoren naast elkaar te leggen. Niet om er een getal uit te rekenen, maar om te zien waar de discussie over gaat.

Bewust geen totaalscore. Een optelsom nodigt uit tot middelen, en juist bij kwetsbaarheden is middelen gevaarlijk: één factor helemaal rechts, bijvoorbeeld “bereikbaar vanaf internet”, weegt zwaarder dan zes gunstige factoren bij elkaar. Gebruik de kaart om het gesprek te structureren, niet om het besluit te automatiseren.

Zeven vragen vóór je patcht

Als je maar één ding uit dit artikel meeneemt naar het volgende overleg, neem dan deze zeven:

1. Kan een aanvaller hier realistisch bij?
2. Is misbruik praktisch of alleen theoretisch?
3. Welk proces ondersteunt dit asset?
4. Wat gebeurt er als misbruik lukt?
5. Welke maatregelen vangen dit nu al af?
6. Welk operationeel risico brengt het patchen zelf mee?
7. Wie draagt het restrisico als we niet patchen?

Die laatste is de belangrijkste, en meestal de enige die niemand beantwoordt.

Waarom dit ook buiten je eigen organisatie standhoudt

NIS2 vraagt in artikel 21 expliciet om het omgaan met kwetsbaarheden als onderdeel van je maatregelen. Wat een toezichthouder of auditor wil zien is niet een lege lijst, want die bestaat niet, maar een navolgbaar besluit per kwetsbaarheid: wat wist je, wat heb je afgewogen, wat heb je besloten, wie is de eigenaar, wanneer kijk je opnieuw.

Dat is precies wat deze aanpak oplevert. Niet als bijproduct van compliance, maar omdat het de manier is waarop je in een OT-omgeving verantwoord kunt werken zonder je eigen productie plat te leggen.

Verder lezen

• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: EPSS: Exploit Prediction Scoring System
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• FIRST: CVSS v4.0
• ISA: ISA/IEC 62443 series of standards
• CyberBusters: Een VLAN is geen IEC 62443-segmentatiestrategie

Wil je dit met je eigen team scherp krijgen, dan gaat de PECB IEC 62443-opleiding in op de risicobenadering waar dit besluitproces op rust.