Waarom patchen in OT niet werkt (en wat wèl werkt)

"Waarom patchen jullie niet gewoon?" Het is de vraag die iedere OT-engineer met enige regelmaat krijgt van een collega uit de IT of van een auditor. De vraag is begrijpelijk. In de kantooromgeving is patchen het sluitstuk van kwetsbaarhedenbeheer: er verschijnt een kwetsbaarheid, de leverancier levert een patch, u test en rolt uit. In de operationele technologie loopt diezelfde cyclus stuk op eisen die in de IT niet bestaan, en de gevolgen van een mislukte poging zijn er van een andere orde.

Hieronder waarom het IT-patchmodel in OT-omgevingen niet werkt, en welke compenserende maatregelen u kunt treffen om uw systemen desondanks te beschermen.

De vijf redenen waarom OT niet kan patchen zoals IT

1. Beschikbaarheidseisen die geen ruimte laten. Een installatie die continu draait, kan niet een uur uit voor een update. Een geplande onderhoudsstop wordt maanden vooruit ingepland en tot op de minuut begroot, juist omdat elk uur dat de installatie niet draait geld kost. Een patch die een onverwachte herstart vergt, of die een systeem instabiel maakt, past daar niet in. De beschikbaarheidsnorm in OT ligt bovendien hoger dan de 99,9% die in de IT gangbaar is, en dat verschil vertaalt zich naar tientallen minuten in plaats van uren per jaar.

2. Certificering door de leverancier. Veel OT-systemen zijn door de leverancier gecertificeerd voor één specifieke softwareconfiguratie: een bepaalde versie van het besturingssysteem, met bepaalde servicepacks en hotfixes. Installeert u een patch die de leverancier niet heeft goedgekeurd, dan vervalt die certificering en daarmee mogelijk uw garantie en ondersteuningscontract. Dat geldt voor de systemen van vrijwel alle grote leveranciers in deze markt. Het certificeringstraject na uitgifte van een patch neemt in de praktijk maanden in beslag, wat bij een kritieke kwetsbaarheid een lange periode van blootstelling betekent.

3. Legacy systemen zonder patches. Een aanzienlijk deel van de OT-omgevingen draait op besturingssystemen waarvoor geen patches meer verschijnen. Verouderde Windows-versies zijn nog wijdverbreid in bedieningsstations en op SCADA-servers, en incidenteel treffen wij nog oudere platformen aan. Voor die systemen bestaat geen patch, ongeacht de ernst van de kwetsbaarheid. Het besturingssysteem vervangen kan doorgaans niet zonder ook de applicatiesoftware en vaak de hardware te vervangen, waarmee het een investeringsproject wordt in plaats van een beheertaak.

4. Onvoorspelbare bijwerkingen. OT-software is nauw verweven met specifieke systeemconfiguraties, bibliotheekversies, stuurprogramma's en timingparameters. Een ogenschijnlijk onschuldige patch kan verschuivingen introduceren die zich pas dagen later openbaren: een communicatietime-out die net iets langer wordt, een wijziging in de taakplanning die een realtime regelkring verstoort, een bijgewerkte bibliotheek die een ouder stuurprogramma onbruikbaar maakt. In de kantooromgeving zijn dat hinderlijke storingen. In OT kunnen zij het proces zelf raken.

5. Geen representatieve testomgeving. In de IT test u een patch in een virtuele omgeving die gelijk is aan productie. In OT laat het fysieke proces, of dat nu een reactor, een zuiveringsinstallatie of een oven is, zich niet virtualiseren. U kunt de software beproeven, maar niet de wisselwerking met het werkelijke proces. De enige volwaardige test is de productieomgeving zelf, en dat is precies de test die u niet wilt uitvoeren met een onbeproefde patch.

Compenserende maatregelen: wat wél werkt

Niet kunnen patchen betekent niet machteloos zijn. Er bestaat een uitgebreid instrumentarium waarmee het risico van ongepatchte systemen aanzienlijk daalt. IEC 62443 erkent uitdrukkelijk dat patchen niet altijd mogelijk is en biedt een kader voor alternatieve maatregelen.

Netwerksegmentatie is daarvan de meest wezenlijke. Door het OT-netwerk op te delen in zones op basis van functie en risico, en het verkeer tussen die zones te beperken tot gedefinieerde conduits, verkleint u de bewegingsruimte van een aanvaller aanzienlijk. Ook wanneer een ongepatcht bedieningsstation wordt gecompromitteerd, blijft de schade bij een juiste indeling beperkt tot die ene zone. Gebruik daarvoor industriële firewalls die OT-protocollen begrijpen en op applicatieniveau kunnen filteren, geen apparatuur uit het consumentensegment.

Applicatiewhitelisting is in OT-omgevingen bijzonder doeltreffend, en wel om een reden die in de IT ontbreekt: OT-systemen vertonen een voorspelbaar en stabiel gedragspatroon. Dezelfde applicaties, dezelfde processen, dezelfde communicatie. Configureer bedieningsstations en engineering workstations zo dat uitsluitend goedgekeurde software kan draaien. Elke poging om onbekende code uit te voeren wordt dan geblokkeerd, ongeacht de patchstatus van het systeem.

OT-specifieke monitoring vormt de waarneming waarop u uw handelen baseert. Passieve netwerkmonitoring observeert al het verkeer zonder risico voor de productie, herkent industriële protocollen, bouwt een beeld op van normaal gedrag en signaleert afwijkingen daarvan: een nieuwe verbinding naar een besturing, een ongebruikelijk commando, een firmware-overdracht buiten het onderhoudsvenster. Daarmee compenseert u het ontbreken van patches door aanvallen te onderkennen voordat zij effect hebben.

Strikte toegangscontrole verkleint het aanvalsoppervlak van ongepatchte systemen. Ken niemand meer rechten toe dan strikt nodig, verwijder overbodige diensten, sluit ongebruikte poorten, schakel standaardaccounts uit en stel multifactor-authenticatie verplicht op alle toegangspunten. Veel exploits voor bekende kwetsbaarheden vergen netwerktoegang of bepaalde rechten; door beide te beperken maakt u de kwetsbaarheid minder bruikbaar, ook zonder patch.

Beheersing van gegevensdragers is onmisbaar in geïsoleerde omgevingen. USB-apparaten behoren tot de voornaamste infectieroutes in OT-netwerken. Laat elke gegevensdrager scannen op een daarvoor ingerichte kiosk voordat deze het OT-netwerk bereikt, blokkeer ongeautoriseerde apparaten technisch, en leg het gebruik ervan vast.

Het IEC 62443-raamwerk voor compenserende maatregelen

IEC 62443 biedt een geordende benadering van kwetsbaarheden in OT-omgevingen. De norm onderscheidt security levels van 1 tot 4 en gaat ervan uit dat niet iedere zone dezelfde bescherming behoeft. Voor systemen die niet gepatcht kunnen worden, verlangt de norm dat het risico langs andere weg tot een aanvaardbaar niveau wordt teruggebracht.

In de praktijk verloopt dat als volgt:

1. Identificeer alle ongepatchte systemen en de kwetsbaarheden daarin.
2. Classificeer het risico aan de hand van de ernst van de kwetsbaarheid, de bereikbaarheid van het systeem en de gevolgen van misbruik.
3. Selecteer compenserende maatregelen die het risico aantoonbaar tot onder het aanvaardbare niveau brengen.
4. Voer uit en leg vast waarom voor deze maatregelen is gekozen.
5. Toets doorlopend of de maatregelen doeltreffend blijven, en stel bij wanneer het dreigingsbeeld verandert.

Een realistisch patchbeleid voor OT

Een volwassen patchbeleid voor OT gaat uit van de werkelijkheid in plaats van ertegen in te redeneren. Deel uw assets daartoe in drie categorieën in:

• Patchbaar: systemen die met aanvaardbaar risico kunnen worden bijgewerkt, zoals recente engineering workstations met door de leverancier goedgekeurde patches. Werk deze bij volgens een vast schema, bij voorkeur tijdens geplande onderhoudsstops.
• Beperkt patchbaar: systemen waarvoor patches bestaan, maar waar certificering of beschikbaarheidseisen het proces vertragen. Tref compenserende maatregelen als tussenoplossing en plan de patch in bij de eerstvolgende stop.
• Niet patchbaar: systemen buiten ondersteuning of ingebedde apparatuur zonder updatemogelijkheid. Tref hier het volle pakket aan compenserende maatregelen en neem vervanging op in uw meerjarige investeringsplanning.

De weg vooruit

De vraag of u in OT wel of niet moet patchen, is een schijntegenstelling. U patcht waar het kan, compenseert waar het moet en plant vervanging waar geen van beide uitkomst biedt. Dat vraagt om afstemming tussen beveiliging, engineering en directie, omdat de afweging tussen veiligheid, continuïteit en investering nergens anders gemaakt kan worden.

Wat in geen geval werkt, is niets doen. Een ongepatchte OT-omgeving zonder compenserende maatregelen is geen aanvaard risico maar een onbeheerst risico, en dat onderscheid is precies wat een auditor, een verzekeraar en een toezichthouder als eerste zullen maken.