Het ontwerpen van HMI/SCADA-applicaties met oog voor cyberbeveiliging – principes die het risico al in de ontwerpfase verlagen

Over de veiligheid van HMI/SCADA-applicaties wordt al veel eerder beslist dan bij de keuze van beveiligingsmechanismen. Of een systeem bestand is tegen vergissingen, misbruik en ongecontroleerde veranderingen in de procestoestand, hangt in de eerste plaats af van de uitgangspunten die in het ontwerp zijn vastgelegd: de rolverdeling, de vertrouwensgrenzen, de reikwijdte van functies die via de interface beschikbaar zijn en de manier waarop service en externe toegang zijn georganiseerd. Als deze kwesties als bijzaak worden behandeld, gaat de applicatie risico’s bestendigen in plaats van ze te beperken. Daarom moet HMI/SCADA-ontwerp met cyberbeveiliging in gedachten als een technische ontwerpopgave worden aangepakt: eerst bepalen welke handelingen kritisch zijn, welke gevolgen ze kunnen hebben en wie ze daadwerkelijk mag uitvoeren, en pas daarna schermen, alarmen en bedieningsgemak uitwerken.

Cyberbeveiliging begint in het ontwerp

In HMI/SCADA-systemen is cyberbeveiliging geen toevoeging aan een al gereed visualisatiesysteem. Ze vloeit voort uit eerder genomen beslissingen: uit de applicatiearchitectuur, het autorisatiemodel, de manier van communiceren met de besturing en de uitgangspunten voor service. Dat is des te belangrijker omdat een HMI/SCADA-applicatie tegelijk het raakvlak vormt tussen mens, proces en infrastructuur. Een ontwerpfout blijft daarom niet beperkt tot een IT-risico. Ze kan tegelijk invloed hebben op de reactie van de operator, de functionele veiligheid, het operationele risico en de continuïteit van de productie.

Vanuit ontwerpperspectief is de kernvraag dus niet welke beveiliging je aan het einde nog toevoegt, maar welke beslissingen al aan het begin het aanvalsoppervlak verkleinen. De grootste problemen komen meestal niet voort uit het ontbreken van één afzonderlijk mechanisme, maar uit te veel vertrouwen dat in de applicatie is ingebouwd. In de praktijk betekent dit gedeelde gebruikersaccounts, brede en permanente servicetoegang, geen scheiding van rollen tussen operator, technische dienst en integrator, en te vrije communicatie tussen de bedieningslaag en de besturing. Tijdens de inbedrijfstelling lijken zulke oplossingen handig, omdat ze het werk versnellen en diagnose vereenvoudigen. Later worden ze een blijvend kenmerk van de omgeving en vergroten ze het risico op misbruik, vergissingen of ongecontroleerde veranderingen in de procestoestand.

Daarom is het zinvol om vóór het ontwerpen van schermen niet alleen vast te leggen wat de gebruiker moet zien, maar vooral ook waar de vertrouwensgrenzen lopen, welke handelingen kritisch zijn en op welke punten de interface een bron van fouten of een middel om procedures te omzeilen kan worden. Die volgorde brengt structuur in latere beslissingen: of het HMI uitsluitend een visualisatielaag moet zijn, of ook een plek voor configuratie, diagnose en receptuurwijzigingen; of servicefuncties permanent beschikbaar moeten zijn, of alleen na bewuste activering; of de operator uitsluitend toegang krijgt tot de procesbediening, of ook tot handelingen die parameters en de gegevenshistorie wijzigen.

De praktische kosten van nalatigheid worden meestal pas zichtbaar wanneer de applicatie al is gekoppeld aan recepturen, alarmen, rapportage, archivering en procedures van de technische dienst. Dan is zelfs een ogenschijnlijk eenvoudige correctie, zoals het scheiden van accounts, het aanpassen van de goedkeuringsroute voor een kritische handeling of het beperken van externe toegang tot incidenteel gebruik, niet langer alleen een wijziging in de schermen. Het vraagt om herziening van de logica, opnieuw testen van de alarmafhandeling, het vastleggen van verantwoordelijkheden en vaak ook om organisatorische veranderingen in de fabriek.

In de praktijk is het verstandigste vertrekpunt een werkbare kaart van gebruikersrollen en hun bevoegdheden voor kritische handelingen, een lijst van functies die veranderingen veroorzaken in de procestoestand, configuratie of recepturen, en een overzicht van externe verbindingen voor service, rapportage, bovenliggende systemen en externe toegang. Op basis daarvan kan pas zinvol de architectuur van zones en verbindingen worden ontworpen en kan de latere risicoanalyse worden voorbereid. Deze aanpak sluit aan bij zowel de technische praktijk als bij de noodzaak om verantwoordelijkheden te ordenen, functies te scheiden en communicatie te beheersen in industriële omgevingen.

Waar kosten en risico echt toenemen

De grootste kosten en risico’s in een HMI/SCADA-applicatie vloeien niet uitsluitend voort uit het enkele feit dat systemen met elkaar zijn verbonden, maar uit de procesmatige en organisatorische gevolgen die afzonderlijke applicatiefuncties kunnen hebben. Het meest gevoelig zijn die punten waar instellingen snel kunnen worden gewijzigd, een bypass kan worden ingevoerd, een alarm kan worden onderdrukt, een receptuur kan worden aangepast of handmatige besturing kan worden uitgevoerd zonder volledige technologische context. Als het ontwerp zulke handelingen vanaf het productiescherm in de routinematige modus toestaat, neemt het risico toe, omdat één beslissing van een gebruiker of één overgenomen sessie de procestoestand rechtstreeks kan veranderen.

Dat betekent dat de catalogus van kritieke handelingen moet worden behandeld als onderdeel van de veiligheidsarchitectuur, en niet alleen als een kwestie van interface-ergonomie. Hetzelfde geldt voor de toerekenbaarheid van handelingen. Gedeelde logins, accounts die door een hele ploeg worden gebruikt, het ontbreken van een scheiding tussen rechten voor uitlezen, bedienen, configureren en beheren, en gebrekkige gebeurtenisregistratie maken het na een incident moeilijk om betrouwbaar vast te stellen of er sprake was van een vergissing, het omzeilen van een procedure, misbruik van servicetoegang of onbevoegd handelen. Het probleem beperkt zich niet tot het achterhalen van de oorzaak. Zonder een betrouwbaar spoor van gebruikershandelingen is het ook niet mogelijk om de effectiviteit van procedures te beoordelen, autorisaties zinvol te beheren of operationele beslissingen te verantwoorden tegenover een interne audit, klanteisen of vastgestelde beveiligingsbeleidsregels. In de praktijk gaat het hier om toerekenbaarheid van handelingen en een traceerbaarheidspad, en niet alleen om het vastleggen van gebeurtenissen.

Een zeer kostbare ontwerpfout is ook het overbrengen naar de productieomgeving van uitgebreide service- en diagnoseschermen die oorspronkelijk zijn voorbereid voor inbedrijfstelling of ondersteuning van de integrator. Dergelijke schermen geven vaak brede toegang tot interne variabelen, het forceren van toestanden, het wissen van blokkeringen en het wijzigen van parameters, terwijl ze in normaal bedrijf hooguit incidenteel nodig zijn. Als ze niet met extra beperkingen worden afgeschermd, vormen ze de kortste weg naar ingrepen in het proces buiten het normale operatorpad. Een verstandige oplossing is om de diagnostiek die nodig is voor de technische dienst te scheiden van functies waarmee in de werkingslogica kan worden ingegrepen, en daarnaast afzonderlijk te beslissen of de diagnostiek van de machinefabrikant lokaal, op afstand of uitsluitend voorwaardelijk beschikbaar mag zijn, na bewuste activering en met volledige sessieregistratie.

Op dezelfde manier moet worden omgegaan met integratie met databases, rapportage, ondersteuning op afstand en kantoorsystemen. Elke dergelijke koppeling verhoogt het gebruiksgemak, maar vergroot tegelijk het aantal afhankelijkheden die een toegangspad, bron van verstoringen of oorzaak van onduidelijke verantwoordelijkheden kunnen worden. Een storing in een tussenliggende dienst, foutieve tijdsynchronisatie, ongecontroleerde gegevensuitwisseling met een bovenliggend systeem of een open gebleven servicekanaal kunnen niet alleen de beschikbaarheid van rapporten beïnvloeden, maar ook de beslissingen die door de operator worden genomen.

Daarom is het al in de ontwerpfase zinvol om niet alleen de beschikbaarheid van schermen te meten, maar ook eenvoudigere en bruikbaardere indicatoren: het aantal kritieke handelingen dat vanaf het productie-HMI mogelijk is, het aantal actieve externe verbindingen, het aantal geprivilegieerde accounts en de reikwijdte van gebeurtenissen die onder het auditspoor vallen. Zo’n beoordeling brengt later ook structuur in gebeurtenisregistratie, controle op parameterwijzigingen en regels voor toegang op afstand.

Alarmbeheer vraagt om een aparte benadering. In dit gebied maskeert schijnbare volledigheid vaak een werkelijk gebrek aan controle. Slecht ontworpen alarmen en gebeurtenishistorie overbelasten de operator niet alleen, maar ontnemen hem ook het vermogen om kritieke signalen te onderscheiden van technische ruis. Als een alarm eenvoudig zonder onderbouwing kan worden gedempt, kan worden bevestigd zonder verwijzing naar de oorzaak, of verloren raakt in een massa diagnostische meldingen, ondersteunt de applicatie de procesveiligheid niet langer. Daarom moeten alarmprioriteiten voortkomen uit het werkelijke effect voor mensen, machine en productkwaliteit, en gekoppeld blijven aan de regels voor het registreren van bevestigingen, omzeilingen en wijzigingen van instellingen. Dit is precies het moment waarop de risicoanalyse ophoudt een formeel document te zijn en de interface begint vorm te geven.

Hoe ontwerpen om de gevolgen van fouten en misbruik te beperken

Het uitgangspunt is eenvoudig: een HMI/SCADA-applicatie mag er niet van uitgaan dat elke gebruiker altijd correct handelt en zich steeds in de juiste procescontext bevindt. Het ontwerp moet beginnen met functiescheiding, niet met het tekenen van schermen. Het team moet eerst vaststellen wat de operator alleen mag zien, wat hij mag bevestigen, wat hij in de normale gang van zaken mag wijzigen, en welke handelingen naar servicemodus moeten worden verplaatst, onder extra autorisatie moeten vallen of volledig moeten worden ondergebracht in een afzonderlijk hulpmiddel of station.

Zo’n beslissing ordent de volledige toegangsarchitectuur: rollen, reikwijdte van bevoegdheden, de manier van registreren van handelingen en de voorwaarden voor ondersteuning op afstand. In de praktijk werkt een rollenmatrix op basis van werkelijke taken goed, met onderscheid tussen operator, ploegleider, technische dienst, technoloog, integrator en beheerder. Dat is geen formaliteit. Als servicefuncties op hetzelfde scherm en onder hetzelfde account beschikbaar blijven als de procesbediening, creëert de applicatie zelf een route naar vergissingen, het omzeilen van procedures of misbruik van bevoegdheden.

Een goed HMI/SCADA-systeem beperkt de kans dat een gevaarlijke handeling per ongeluk wordt uitgevoerd, maar vertraagt routinematige werkzaamheden niet onnodig. Dat vereist een duidelijke werkcontext: de gebruiker moet zien aan welk object hij werkt, in welke toestand het proces zich bevindt, of hij lokaal of op afstand werkt en of het systeem in automatische, handmatige of servicemodus staat. Bevestigingen moeten in verhouding staan tot het risico en niet voor alle handelingen hetzelfde zijn. Waar de gevolgen van een fout omkeerbaar en beperkt zijn, volstaat meestal één autorisatie. Kritieke handelingen vereisen extra controle: een tweede bevestiging, opnieuw authenticeren, afhankelijkheid van de procestoestand of een fysieke overgang naar een afgeschermde interface.

Ook voorwaardelijke vergrendelingen zijn van groot belang. Als de applicatie toestaat dat een instelling wordt gewijzigd, een signaal wordt geforceerd of naar handbediening wordt overgeschakeld ongeacht de toestand van het object, wordt het risico van het ontwerp naar de operator verschoven. Juist hier blijkt dat een goed ontworpen interface niet alleen draait om bedieningsgemak, maar om het beperken van de gevolgen van fouten door ingebouwde barrières. In veel gevallen sluit deze manier van denken nauw aan bij hoe Poka-Yoke in productielijnen werkt.

Gelaagd toegangsontwerp moet ook omvatten hoe autorisaties in de tijd worden gebruikt. Persoonlijke accounts zijn noodzakelijk overal waar traceerbaarheid van handelingen wordt verwacht. Een gedeeld account maakt het onmogelijk vast te stellen wie de beslissing daadwerkelijk heeft genomen. Het principe van minimale rechten betekent dat een gebruiker alleen die functies krijgt die nodig zijn voor het dagelijkse werk, en dat rechten alleen tijdelijk en onder gecontroleerde voorwaarden worden uitgebreid. Dit geldt in het bijzonder voor de technische dienst, de integrator en ondersteuning op afstand door de fabrikant. Een permanent open servicepad lijkt alleen maar handig, omdat het de natuurlijke vertrouwensgrens tussen exploitatie en service opheft. Een veiliger model is toegang op aanvraag, beperkt in tijd, gekoppeld aan een concrete persoon en vastgelegd in de gebeurtenisgeschiedenis. Deze aanpak sluit goed aan bij het principe van minimale rechten en toegangssegmentatie.

In dezelfde lijn moet worden bepaald of servicefuncties beschikbaar mogen zijn vanaf de werk-HMI of uitsluitend vanaf een apart station, en of verwisselbare media en lokale import of export van gegevens via het bedieningspaneel zijn toegestaan. Dit zijn geen bijzaken. Juist deze keuzes bepalen of de onderhoudbaarheid van het systeem gecontroleerd wordt gerealiseerd of via ad-hocoplossingen.

Vanuit het perspectief van een incident of een operationeel geschil is de interface alleen niet voldoende. De applicatie moet informatie achterlaten waarmee de besluitvorming kan worden gereconstrueerd. Gebeurtenisgeschiedenis, systeemlogboeken en wijzigingsregistratie moeten samen niet alleen antwoord geven op de vraag wat er is gebeurd, maar ook wie, wanneer, vanaf welke locatie en in welke procestoestand de handeling heeft uitgevoerd. De minimale set gebeurtenissen die doorgaans het registreren waard is, omvat inloggen, wijziging van rechten, wijziging van parameters, overschakelen naar handbediening, bevestiging van een alarm en import van configuratie. Doorslaggevend is dat de registratie wordt gekoppeld aan de technologische context, omdat informatie over alleen een wijziging zonder de toestand van het object vaak nutteloos is.

Een goed voorbeeld, dat in veel implementaties voorkomt: het wijzigen van een alarmdrempel door een technoloog kan toelaatbaar zijn, maar alleen na het activeren van de daarvoor voorziene modus, met registratie van de gebruiker, het station, de tijd, de vorige en de nieuwe waarde en de bevestiging dat het object zich niet in een kritieke toestand bevond. Zo’n spoor is van belang voor zowel de veiligheid als het wijzigingsbeheer in industriële applicaties.

De laatste laag is onderhoudbaarheid zonder beveiligingen te omzeilen. Als een update, het terugzetten van configuratie of diagnostiek vereist dat toegangscontrole wordt uitgeschakeld, een gedeeld wachtwoord wordt gebruikt of zonder auditspoor wordt gewerkt, ligt het probleem in het ontwerp en niet in de discipline van het personeel. De applicatie moet een voorzien wijzigingsverloop hebben: aanvraag, impactbeoordeling, test, implementatie, bevestiging en terugvalplan. Ook moet zij de productieomgeving en de serviceomgeving ten minste logisch scheiden, en waar dat gerechtvaardigd is ook organisatorisch en technisch. Configuratiekopieën moeten gecontroleerd kunnen worden gemaakt en teruggezet, zonder ad-hocexport “voor de zekerheid” vanaf het paneel. Deze aanpak is in lijn met het principe van minimale rechten in OT en met de eisen voor toegangscontrole, traceerbaarheid van handelingen en wijzigingsbeheer, waarbij de reikwijdte daarvan altijd moet worden afgestemd op de systeemarchitectuur en de gekozen verdeling van verantwoordelijkheden.

Implementatiepraktijk en relatie tot de eisen

De grootste winst zit niet in het toevoegen van steeds meer beschermingsmechanismen aan het einde van het project, maar in een gestructureerde beoordeling van de applicatie vóór oplevering of modernisering. Dat is het moment waarop de werkwijze van het systeem nog relatief goedkoop kan worden gecorrigeerd, in plaats van later onjuiste uitgangspunten af te schermen met extra procedures. Zo’n beoordeling moet worden uitgevoerd door een gemengd team: ontwerp, technische dienst, exploitatie, automatisering en de personen die verantwoordelijk zijn voor veiligheid.

Bij de beoordeling gaat het niet alleen om de technische configuratie, maar ook om de vraag of de applicatie rollen daadwerkelijk scheidt, kritieke handelingen beschermt, toegang op afstand beperkt tot gerechtvaardigde gevallen, een duidelijke alarmafhandeling biedt, de wijzigingsgeschiedenis bewaart en het mogelijk maakt back-ups en noodprocedures uit te voeren zonder beveiligingen te omzeilen. Juist uit zo’n beoordeling moet de lijst voor FAT/SAT voortkomen, evenals de eisen die worden opgenomen in de oplevering, het serviceplan en de revisiedocumentatie.

Deze benadering verlegt het zwaartepunt van de discussie over beveiligingen op zich naar ontwerpbeslissingen die later het gedrag van mensen en installaties bepalen. Als al in de ontwerpfase niet is vastgelegd wie receptuurparameters mag wijzigen, wie de servicemodus goedkeurt, hoe ingrepen van de integrator worden geregistreerd en onder welke voorwaarden toegang van buiten de fabriek is toegestaan, zal het systeem na ingebruikname steunen op uitzonderingen en mondelinge afspraken.

Om dezelfde reden is het zinvol om te bepalen of de beoordeling van de applicatie plaatsvindt in het kader van de modernisering van een machine of lijn, of als een afzonderlijke OT-review. De eerste aanpak koppelt veiligheid beter aan de procesfunctie, de tweede maakt het eenvoudiger om afhankelijkheden tussen systemen en de verdeling van verantwoordelijkheden voor accounts, rechten en logging van activiteiten in beeld te brengen. Dit is ook de aangewezen plek voor een eerste risicoanalyse: het identificeren van kritische handelingen, vertrouwensgrenzen en de gevolgen van een bedieningsfout of misbruik. In de praktijk kan ook een risicoanalyse in het project hierbij nuttig zijn.

• rollen en de manier waarop gebruikers inloggen,
• kritische handelingen en de regels voor bevestiging daarvan,
• toegang op afstand en servicefuncties,
• alarmen, logging van wijzigingen en herleidbaarheid van handelingen,
• back-ups, herstel en noodprocedures.

Een goed resultaat in een fabriek komt zelden voort uit de gelijktijdige invoering van veel tools. Meestal is het belangrijker om enkele systeemrisico’s weg te nemen die jarenlang als praktisch werden gezien. De modernisering van een HMI/SCADA-applicatie kan beginnen met het opheffen van gedeelde accounts, het scheiden van servicefuncties en operatorfuncties, het beperken van externe verbindingen tot gecontroleerde paden en het activeren van een wijzigingsspoor voor parameters met toewijzing aan een specifieke persoon of rol. Zo’n wijziging hoeft het werk van de technische dienst of de integrator niet te bemoeilijken, mits vanaf het begin is voorzien in een servicemodus, autorisatieregels en een reproduceerbaar verloop van wijzigingen.

In de gebruiksfase is het vervolgens zinvol om niet een abstract veiligheidsniveau te meten, maar operationeel bruikbare indicatoren: het aantal gedeelde accounts dat nog in het systeem aanwezig is, de omvang van actieve toegang op afstand, de volledigheid van wijzigingsregisters, de tijd die nodig is om de configuratie te herstellen en het aantal interventies dat buiten de formele procedure wordt uitgevoerd. Dergelijke indicatoren maken het mogelijk te beoordelen of het project het risico daadwerkelijk heeft beperkt, of het alleen heeft verplaatst naar de dagelijkse praktijk.

In de Nederlandse en Europese praktijk wordt het steeds lastiger om een benadering te verdedigen waarbij de cyberbeveiliging van HMI/SCADA uitsluitend een zaak van de IT-afdeling is. De verantwoordelijkheid is verdeeld over ontwerp, exploitatie, technische dienst, leveranciers en integrators, en branche- en contractuele eisen krijgen pas betekenis wanneer de organisatie concreet kan aantonen welke ontwerpbeslissingen zijn genomen, hoe rechten worden toegekend, welk handelingsspoor beschikbaar is en wie wijzigingen beheerst. Verwijzingen naar normen, beleid of contractbepalingen alleen vervangen niet het bewijs dat de applicatie zo is ontworpen en geaccepteerd dat veilige exploitatie mogelijk is.

De belangrijkste conclusie is praktisch. Het goedkoopste en meest effectieve moment om risico te beperken blijft het ontwerpen en accepteren van de applicatie. Juist dan kunnen met de laagste kosten vertrouwensgrenzen, rollen, toegangsvoorwaarden, het handelingsspoor en de manier waarop wijzigingen worden doorgevoerd worden vastgelegd. Als deze eisen worden vertaald naar verifieerbare criteria voor de leverancier en integrator, houdt HMI/SCADA op een handig maar te goedgelovig interface te zijn en wordt het een hulpmiddel voor een veilige procesvoering.