De automatisering in de procesindustrie heeft de laatste jaren een belangrijke omwenteling gemaakt van gesloten (proprietary) systemen naar open technologiesystemen. Dit heeft belangrijke voordelen, maar er zijn ook nieuwe uitdagingen door ontstaan. Eén daarvan is security. In dit artikel de problematiek rondom patchmanagement.
Continubedrijven zoals chemiefabrieken, raffinaderijen, energiecentrales en de offshore-industrie zijn de laatste jaren overgestapt van productiebesturingssystemen gebaseerd op leverancierspecifieke automatiseringsoplossingen naar oplossingen gebaseerd op 'open technologie' (Microsoft, Unix). Het grote voordeel van deze stap was dat systemen van verschillende softwareleveranciers veel eenvoudiger met elkaar konden communiceren dan in het verleden mogelijk was. Andere veel gehoorde argumenten zijn dat de kennis makkelijker beschikbaar is, en dat de aanschafkosten lager zijn.
Maar open systemen brachten ook nieuwe problemen en één daarvan was it-security. De oude gesloten systemen waren vaak verbonden met eigen afgesloten netwerken, immuun voor computervirussen omdat deze voor dit type systemen niet werden ontwikkeld (specifieke kennis nodig, klein onbekend doelgebied). De open systemen echter kregen nieuwe verbindingen (gebruikmakend van algemeen toepasbare netwerkapparatuur) bij de invoering van supply chain-toepassingen, asset-managementsystemen, productie-informatiesystemen en het beheer van productierecepten. Een belangrijk gevolg was dat de dynamiek van de 'kantoorautomatisering' daarmee ook de proces-/productie-automatiseringssystemen ging beïnvloeden.
Een belangrijke vraag ontstond; 'wat te doen met al die security patches die maandelijks door de leveranciers zoals Microsoft beschikbaar worden gemaakt?' In een omgeving waar elke wijziging met de grootst mogelijk zorg wordt geanalyseerd op de impact voor de veiligheid en productieconsequenties ontstond er ineens een stroom wijzigingen waar men vaak geen raad mee wist. Enerzijds was het kostbaar om ze te laten inbrengen, anderzijds waren niet alle systemen redundant uitgevoerd waardoor de installatie van de patch ook consequenties kon hebben voor de productiecontinuïteit, en niet elke leverancier van productie/procesbesturingsapplicaties onderzocht de patches op mogelijke negatieve consequenties voor hun applicaties. En natuurlijk speelt er altijd de vraag welk risico groter is, de installatie van de patch of de beveiligingskwetsbaarheid in het systeem.
Meer dan genoeg argumenten voor menig onderhoudsmanager om te besluiten de security patches maar niet te installeren. Dit in combinatie met een gebrekkige virusprotectie leidde nogal eens tot problemen omdat ook malware vaak dankbaar gebruikmaakt van de kwetsbaarheden van het besturingssysteem om zich voort te planten. Amerikaans onderzoek van het NERC beschouwt slecht patchmanagement als de derde oorzaak van de kwetsbaarheid van productie-/procesbesturingssystemen (direct na een ontoereikend veiligheidsbeleid en gebrekkig ontworpen netwerken), dus zeker een belangrijk onderwerp om nader te beschouwen.
Een goed georganiseerd patchmanagement vraagt om kennis van beschikbare patches, impactanalyse op de consequenties voor het productie-/procesbesturingssysteem, implementatie van de patch zonder ongewenste neveneffecten, in acht name van specifieke systeemconfiguratie-eisen, een correcte installatie en tenslotte een observatieperiode of alles wel goed functioneert.
Microsoft- en de Unix-leveranciers publiceren met grote regelmaat de beschikbare security patches, er valt misschien hier en daar een kanttekening te plaatsen over de snelheid (en bereidheid) bepaalde kwetsbaarheden op te lossen, maar dit is zeker niet de zwakste schakel in de patchmanagement-keten. De impactanalyse is wel een belangrijk knelpunt. De grote DCS-/SCADA-leveranciers testen de patches voor compatibiliteit met hun software, dit gebeurt echter niet altijd even snel. Sommige leveranciers doen dit gemiddeld in enkele dagen, anderen hebben een proces dat weken duurt. Maar er zijn ook tal van leveranciers die helemaal geen testprogramma hebben, vooral in de omgeving van ondersteunende apparatuur, zoals procesanalyzers, apparatuurbewaking en andere monitoring-apparatuur ontbreekt het vaak aan een testproces. Daarnaast kan de vraag gesteld worden of testen genoeg is, immers een leverancier zal de patches voor zijn software testen, maar dat hoeft in een open systeem niet de enige software te zijn waar rekening mee gehouden moet worden. Ook zal de test veelal uitgevoerd worden op een recente release van de software, wat in een omgeving waar men terughoudend is met wijzigingen niet overeen hoeft te komen met de geïnstalleerde software.
De volgende complicatie is de installatie van de patch. Wat als er een herstart van de server noodzakelijk is? In het weekend uitvoeren is voor een continubedrijf geen oplossing, eerder een probleem omdat wijzigingen meestal uitgevoerd worden als er voldoende expertise en mankracht aanwezig is om een eventuele verstoring van de productie op te vangen.
Iedereen die regelmatig patches heeft geïnstalleerd weet ook dat het systeem zich nogal eens anders gedraagt dan de patchbeschrijving aangeeft, risico dat zeker meegewogen moet worden. Het advies is hier de patch eerst op minder kritische nodes (bijvoorbeeld redundante node, nodes in een trainings-/engineeringsysteem) te installeren om verrassingen te voorkomen, maar het is niet altijd zo dat een dergelijke node beschikbaar is.
Genoeg (en nog veel meer) problemen rondom patchmanagement in de productieomgeving om hier meer aandacht aan te besteden.
HET Instrument 2008
In samenwerking met het FHI heeft het NICC een dag georganiseerd rondom beveiliging in de procesindustrie. ‘s Ochtends een breed scala aan onderwerpen en ‘s middags een aantal workshops waarbij één gewijd aan patching & hardening. Dit gebeurt 21 mei 2008 tijdens Het Instrument 2008. Een onderwerp dat de procesindustrie nog heel wat uitdagingen biedt om goed opgelost te worden.
