Design af HMI-/SCADA-applikationer med fokus på cybersikkerhed – principper, der reducerer risikoen allerede i projekteringsfasen

Sikkerheden i HMI/SCADA-applikationer afgøres længe før valget af beskyttelsesmekanismer. Om systemet er robust over for fejl, misbrug og ukontrollerede ændringer i procestilstanden, afhænger først og fremmest af de forudsætninger, der fastlægges i projektet: rollefordeling, tillidsgrænser, omfanget af funktioner, der er tilgængelige via interfacet, samt måden service og fjernadgang organiseres på. Hvis disse forhold behandles som sekundære, vil applikationen begynde at fastholde risiko i stedet for at begrænse den. Derfor skal HMI/SCADA designes med cybersikkerhed for øje som en ingeniøropgave: først skal det fastlægges, hvilke operationer der er kritiske, hvilke konsekvenser de kan have, og hvem der reelt bør kunne udføre dem, og først derefter bør skærmbilleder, alarmer og brugervenlighed udformes.

Cybersikkerhed begynder i projektet

I HMI/SCADA-systemer er cybersikkerhed ikke et tillæg til en færdig visualisering. Den følger af beslutninger, der er truffet tidligere: applikationens arkitektur, rettighedsmodellen, måden kommunikationen med styringen er opbygget på, og forudsætningerne for service. Det er særligt vigtigt, fordi HMI/SCADA-applikationen samtidig er kontaktpunktet mellem menneske, proces og infrastruktur. En projekteringsfejl ender derfor ikke kun som en it-risiko. Den kan samtidig påvirke operatørens reaktion, funktionssikkerhed, driftsrisiko og kontinuiteten i produktions- og proceslinjer.

Set fra projektets perspektiv er det grundlæggende spørgsmål derfor ikke, hvilken sikring der skal tilføjes til sidst, men hvilke beslutninger der allerede fra starten begrænser angrebsfladen. De største problemer skyldes som regel ikke fraværet af én bestemt mekanisme, men for stor tillid indbygget i applikationen. I praksis betyder det fælles brugerkonti, bred og permanent serviceadgang, manglende adskillelse af roller mellem operatør, vedligeholdelse og integrator samt for fri kommunikation mellem operatørlaget og styringen. Ved idriftsættelsen virker sådanne løsninger bekvemme, fordi de fremskynder arbejdet og letter diagnostikken. Senere bliver de en fast del af miljøet og øger risikoen for misbrug, fejl eller ukontrollerede ændringer i procestilstanden.

Derfor er det værd, før skærmbillederne designes, ikke kun at fastlægge, hvad brugeren skal kunne se, men først og fremmest hvor tillidsgrænserne går, hvilke operationer der er kritiske, og hvor interfacet kan blive et redskab til fejl eller omgåelse af procedurer. Denne rækkefølge skaber struktur i de efterfølgende beslutninger: om HMI kun skal være et visualiseringslag, eller også et sted for konfiguration, diagnostik og ændring af recepter; om servicefunktioner skal være aktive permanent eller kun efter bevidst aktivering; om operatøren kun skal have adgang til procesbetjening eller også til operationer, der ændrer parametre og datahistorik.

De praktiske omkostninger ved forsømmelser viser sig som regel først, når applikationen allerede er koblet til recepter, alarmer, rapportering, arkivering og procedurer for vedligeholdelse. På det tidspunkt ophører selv en tilsyneladende enkel korrektion, som f.eks. opdeling af konti, ændring af godkendelsesforløbet for en kritisk operation eller begrænsning af fjernadgang til lejlighedsvis brug, med at være en ændring i skærmbillederne. Det kræver ombygning af logikken, fornyet test af alarmhåndteringen, afklaring af ansvar og ofte også organisatoriske ændringer i virksomheden.

I praksis er det mest fornuftige udgangspunkt et foreløbigt kort over brugerroller og deres rettigheder til kritiske operationer, en liste over funktioner, der medfører ændring af procestilstand, konfiguration eller recepter, samt en oversigt over eksterne forbindelser, herunder service, rapportering, overordnede systemer og fjernadgang. Først på det grundlag kan man meningsfuldt designe arkitekturen for zoner og forbindelser i industriel automatisering samt forberede den efterfølgende risikovurdering. En sådan tilgang svarer både til ingeniørpraksis og til kravene om klar ansvarsfordeling, funktionsadskillelse og kontrol med kommunikation i industrielle miljøer.

Hvor omkostninger og risiko reelt vokser

De største omkostninger og den største risiko i en HMI/SCADA-applikation skyldes ikke alene det forhold, at systemer er forbundet, men hvilke procesmæssige og organisatoriske konsekvenser de enkelte applikationsfunktioner udløser. De mest følsomme punkter er dem, der gør det muligt hurtigt at ændre indstillinger, indføre en omgåelse, undertrykke en alarm, ændre en recept eller udføre manuel styring uden fuld teknologisk kontekst. Hvis projektet tillader sådanne operationer fra produktionsskærmen som en rutinemæssig funktion, vokser risikoen, fordi én brugerbeslutning eller én overtaget session direkte kan ændre procestilstanden.

Det betyder, at kataloget over kritiske operationer skal behandles som en del af sikkerhedsarkitekturen og ikke kun som et spørgsmål om grænsefladens ergonomi. Den samme mekanisme gælder for ansvarssporing af handlinger. Fælles logins, konti delt mellem skift, manglende adskillelse af rettigheder til visning, styring, konfiguration og administration samt mangelfuld hændelseslogning gør det vanskeligt efter en hændelse pålideligt at fastslå, om der var tale om en fejl, en omgåelse af proceduren, misbrug af serviceadgang eller en uautoriseret handling. Problemet handler ikke kun om selve årsagsundersøgelsen. Uden et troværdigt spor af brugerhandlinger kan man heller ikke vurdere procedurernes effektivitet, forvalte rettigheder på en meningsfuld måde eller forsvare driftsmæssige beslutninger over for intern audit, kundekrav eller vedtagne sikkerhedspolitikker. I praksis handler det her om ansvarssporing af handlinger og et spor for sporbarhed, ikke kun om registrering af hændelser.

En meget kostbar projekteringsfejl er også at overføre omfattende service- og diagnosebilleder til produktionsmiljøet, når de oprindeligt er udarbejdet til idriftsættelse eller support til integratoren. Sådanne visninger giver ofte bred adgang til interne variabler, tvungen ændring af tilstande, nulstilling af blokeringer og ændring af parametre, selv om de under normal drift højst er nødvendige lejlighedsvis. Hvis de ikke underlægges yderligere begrænsninger, bliver de den korteste vej til indgreb i processen uden for den normale operatørvej. En fornuftig løsning er at adskille den diagnostik, som er nødvendig for vedligehold, fra funktioner, der gør det muligt at gribe ind i driftslogikken, og samtidig træffe en særskilt beslutning om, hvorvidt maskinproducentens diagnostik skal være tilgængelig lokalt, eksternt eller kun betinget, efter bevidst aktivering og med fuld registrering af sessionen.

Det samme gælder integration med databaser, rapportering, fjernsupport og kontorsystemer. Hver sådan forbindelse gør arbejdet mere bekvemt, men øger samtidig antallet af afhængigheder, som kan blive en adgangsvej, en kilde til forstyrrelser eller årsag til uklarhed om ansvar. Fejl i en mellemliggende tjeneste, forkert tidssynkronisering, ukontrolleret dataudveksling med et overordnet system eller en efterladt servicekanal kan påvirke ikke kun tilgængeligheden af rapporter, men også de beslutninger, som operatøren træffer.

Derfor er det værd allerede i projektfasen ikke kun at måle skærmenes tilgængelighed, men også enklere og mere anvendelige indikatorer: antallet af kritiske operationer, der kan udføres fra produktions-HMI’et, antallet af aktive eksterne forbindelser, antallet af privilegerede konti samt omfanget af hændelser, der er dækket af auditsporet. En sådan gennemgang skaber senere struktur i hændelseslogning, kontrol af parameterændringer og regler for fjernadgang.

Alarmering kræver en særskilt behandling. På dette område skjuler en tilsyneladende fuldstændighed ofte et reelt fravær af kontrol. Dårligt udformede alarmer og hændelseshistorik overbelaster ikke kun operatøren, men fratager også vedkommende evnen til at skelne kritiske signaler fra teknisk støj. Hvis en alarm let kan slås fra uden begrundelse, kvitteres uden relation til årsagen eller forsvinde i mængden af diagnostiske meddelelser, ophører applikationen med at understøtte processikkerheden. Derfor bør alarmprioriteterne tage udgangspunkt i den reelle konsekvens for mennesker, maskinen og produktkvaliteten og fortsat være knyttet til reglerne for registrering af kvitteringer, omgåelser og ændringer af indstillinger. Det er netop her, risikoanalysen ophører med at være et formelt dokument og begynder at forme grænsefladen.

Sådan projekterer man for at begrænse konsekvenserne af fejl og misbrug

Udgangspunktet er enkelt: En HMI/SCADA-applikation kan ikke bygge på den antagelse, at enhver bruger altid handler korrekt og i den rette proceskontekst. Projektet skal begynde med funktionsadskillelse og ikke med at tegne skærmbilleder. Teamet bør først fastlægge, hvad operatøren kun skal kunne se, hvad der må kvitteres, hvad der må ændres i det normale arbejdsforløb, og hvilke handlinger der skal flyttes til servicetilstand, underlægges ekstra autorisation eller helt udskilles til et separat værktøj eller en særskilt station.

En sådan beslutning skaber orden i hele adgangsarkitekturen: roller, rettighedsomfang, måden handlinger registreres på og betingelserne for fjernsupport. I praksis fungerer en rollematrice baseret på faktiske arbejdsopgaver godt, hvor der skelnes mellem operatør, teamleder, vedligehold, teknolog, integrator og administrator. Det er ikke en formalitet. Hvis servicefunktioner ligger på samme skærm og under samme konto som procesbetjeningen, skaber applikationen selv en vej til fejl, omgåelse af procedurer eller misbrug af rettigheder.

Et godt HMI/SCADA begrænser muligheden for ved et uheld at udføre en farlig operation, men forsinker ikke rutineopgaver unødigt. Det kræver en tydelig arbejdskontekst: Brugeren skal kunne se, hvilket objekt der arbejdes på, hvilken tilstand processen er i, om arbejdet sker lokalt eller eksternt, og om systemet er i automatisk, manuel eller servicefunktion. Kvitteringer skal stå mål med risikoen og ikke være ens for alle handlinger. Hvor konsekvensen af en fejl er reversibel og begrænset, er en enkelt autorisation som regel tilstrækkelig. Kritiske operationer kræver yderligere kontrol: en ekstra bekræftelse, fornyet autentifikation, afhængighed af procestilstanden eller fysisk skift til en adskilt grænseflade.

Også betingede spærringer er vigtige. Hvis applikationen tillader ændring af en indstilling, tvangssætning af et signal eller skift til manuel drift uanset anlæggets tilstand, flyttes risikoen fra projektet over på operatøren. Netop her bliver det tydeligt, at korrekt design af brugergrænsefladen ikke kun handler om brugervenlighed, men om at begrænse konsekvenserne af fejl gennem indbyggede barrierer. I mange tilfælde ligger denne tankegang tæt op ad den måde, Poka-Yoke i produktionslinjer fungerer på.

Lagdelt design af adgang bør også omfatte, hvordan rettigheder bruges over tid. Individuelle konti er nødvendige alle steder, hvor der forventes sporbarhed af handlinger. En fælles konto fjerner muligheden for at fastslå, hvem der faktisk traf beslutningen. Mindste nødvendige rettigheder betyder, at brugeren kun får de funktioner, der er nødvendige for det aktuelle arbejde, og at forhøjede rettigheder kun gives midlertidigt og under kontrollerede forhold. Det gælder især for vedligeholdelse, integratoren og producentens fjernsupport. En permanent åben serviceadgang er kun tilsyneladende bekvem, fordi den ophæver den naturlige tillidsgrænse mellem drift og service. En mere sikker model er adgang, der aktiveres efter behov, er tidsbegrænset, knyttet til en bestemt person og registreret i hændelseshistorikken. Denne tilgang passer godt til princippet om mindste rettigheder og segmentering af adgang.

I samme ånd skal det afklares, om servicefunktioner skal være tilgængelige fra det operative HMI-niveau eller kun fra en separat station, og om der skal tillades flytbare medier samt lokal import eller eksport af data fra operatørpanelet. Disse beslutninger er ikke sekundære. Det er dem, der afgør, om systemets vedligeholdelighed bliver håndteret kontrolleret eller via midlertidige omgåelser.

Set i lyset af en hændelse eller en driftsmæssig tvist er selve grænsefladen ikke nok. Applikationen skal efterlade materiale, der gør det muligt at genskabe beslutningsforløbet. Hændelseshistorik, systemlogfiler og registrering af ændringer bør tilsammen ikke kun besvare spørgsmålet om, hvad der skete, men også hvem der udførte handlingen, hvornår, fra hvilket sted og i hvilken procestilstand. Det minimale omfang af hændelser, som det normalt er værd at registrere, omfatter login, ændring af rettigheder, ændring af parametre, skift til manuel drift, kvittering af alarm samt import af konfiguration. Det afgørende er at koble registreringen til den teknologiske kontekst, fordi information om en ændring alene ofte er ubrugelig uden anlæggets tilstand.

Et godt eksempel er typisk for mange implementeringer: ændring af alarmgrænsen foretaget af en procesteknolog kan være tilladt, men kun efter skift til den forudsatte tilstand, med registrering af bruger, station, tidspunkt, tidligere og ny værdi samt bekræftelse af, at anlægget ikke var i en kritisk tilstand. Et sådant spor er vigtigt både for sikkerheden og for ændringsstyring i industrielle applikationer.

Det sidste lag er vedligeholdelighed uden at omgå beskyttelsesforanstaltninger. Hvis opdatering, gendannelse af konfiguration eller diagnostik kræver, at adgangskontrollen slås fra, at der bruges et fælles password, eller at arbejdet udføres uden revisionsspor, ligger problemet i projektet og ikke i personalets disciplin. Applikationen bør have et fastlagt ændringsforløb: anmodning, vurdering af påvirkning, test, implementering, bekræftelse og plan for tilbagerulning. Den bør også adskille driftsmiljøet fra servicemiljøet mindst logisk og, hvor det er begrundet, også organisatorisk og teknisk. Sikkerhedskopier af konfigurationen skal kunne oprettes og gendannes på en kontrolleret måde uden ad hoc-eksport “for en sikkerheds skyld” fra panelet. Denne tilgang er i tråd med princippet om mindste rettigheder i OT samt kravene til adgangskontrol, sporbarhed af handlinger og ændringsstyring, men deres omfang skal altid vurderes i forhold til systemarkitekturen og den valgte ansvarsfordeling.

Implementeringspraksis og henvisning til krav

Det giver mest ikke at tilføje flere beskyttelsesmekanismer til sidst i projektet, men at gennemføre en struktureret gennemgang af applikationen før overtagelse eller modernisering. Det er det tidspunkt, hvor systemets arbejdsform stadig kan korrigeres forholdsvis billigt, i stedet for senere at bygge ekstra procedurer oven på fejlagtige forudsætninger. En sådan gennemgang bør udføres af et tværfagligt team: projekt, vedligeholdelse, drift, automationsingeniør og personer med ansvar for sikkerhed.

Det, der skal vurderes, er ikke kun den tekniske konfiguration, men også om applikationen faktisk adskiller roller, beskytter kritiske operationer, begrænser fjernadgang til begrundede tilfælde, sikrer tydelig alarmhåndtering, bevarer ændringshistorik og gør det muligt at udføre sikkerhedskopier og nødprocedurer uden at omgå beskyttelsen. Det er netop på baggrund af en sådan gennemgang, at listen til FAT/SAT samt de krav, der indskrives i overtagelsen, serviceplanen og as-built-dokumentationen, bør udarbejdes.

Denne tilgang flytter fokus fra diskussionen om selve beskyttelsesforanstaltningerne til de designbeslutninger, som senere bestemmer, hvordan mennesker og udstyr agerer. Hvis man allerede i projekteringsfasen ikke har fastlagt, hvem der må ændre opskriftsparametre, hvem der godkender servicetilstand, hvordan integratorens indgreb registreres, og under hvilke betingelser adgang uden for anlægget er tilladt, vil systemet efter idriftsættelsen bygge på undtagelser og mundtlige aftaler.

Af samme grund er det værd at afklare, om vurderingen af applikationen skal gennemføres som led i modernisering af en maskine eller linje, eller som et særskilt OT-review. Den første tilgang kobler sikkerheden bedre til procesfunktionen, mens den anden gør det lettere at identificere afhængigheder mellem systemer og fordelingen af ansvar for konti, rettigheder og registrering af handlinger. Det er også et naturligt sted at foretage en indledende risikoanalyse: identifikation af kritiske operationer, tillidsgrænser og konsekvenserne af operatørfejl eller misbrug. I praksis kan også en risikoanalyse i projektet være nyttig her.

• roller og måden, brugerne logger ind på,
• kritiske operationer og reglerne for bekræftelse af dem,
• fjernadgang og servicefunktioner,
• alarmer, registrering af ændringer samt sporbarhed for handlinger,
• backup, gendannelse og nødprocedurer.

Et godt resultat i anlægget skyldes sjældent, at mange værktøjer indføres på én gang. Som regel er det vigtigere at fjerne nogle få systemiske risici, som i årevis er blevet opfattet som praktiske. Modernisering af en HMI/SCADA-applikation kan begynde med at afskaffe fælles konti, adskille servicefunktioner fra operatørfunktioner, begrænse eksterne forbindelser til kontrollerede adgangsveje og aktivere et ændringsspor for parametre med tilknytning til en konkret person eller rolle. En sådan ændring behøver ikke at forringe arbejdet i vedligeholdelsen eller for integratoren, hvis der fra starten er taget højde for servicetilstand, autorisationsregler og et reproducerbart forløb for ændringer.

I driften er det derefter værd at måle ikke et abstrakt sikkerhedsniveau, men indikatorer, der er operationelt anvendelige: antallet af fælles konti, der stadig findes i systemet, omfanget af aktiv fjernadgang, fuldstændigheden af ændringsloggene, tiden til gendannelse af konfigurationen samt antallet af indgreb udført uden for den formelle procedure. Sådanne målepunkter gør det muligt at vurdere, om projektet reelt har reduceret risikoen, eller blot flyttet den over i den daglige praksis.

I en polsk og europæisk kontekst bliver det stadig sværere at forsvare en tilgang, hvor cybersikkerhed i HMI/SCADA udelukkende er IT-afdelingens ansvar. Ansvaret er fordelt mellem projekt, drift, vedligeholdelse, leverandører og integratorer, og branchekrav samt kontraktkrav får først betydning, når organisationen kan vise noget konkret: hvilke designbeslutninger der er truffet, hvordan rettigheder tildeles, hvilket handlingsspor der findes, og hvem der kontrollerer ændringerne. Henvisninger til standarder, politikker eller kontraktbestemmelser kan ikke i sig selv erstatte dokumentation for, at applikationen er designet og godkendt på en måde, der muliggør sikker drift.

Den vigtigste konklusion er praktisk. Det billigste og mest effektive tidspunkt at begrænse risiko på er fortsat under projektering og godkendelse af applikationen. Det er her, man med de laveste omkostninger fastlægger tillidsgrænser, roller, adgangsbetingelser, handlingsspor og måden, ændringer gennemføres på. Hvis disse krav omsættes til verificerbare kriterier over for leverandøren og integratoren, ophører HMI/SCADA med at være en bekvem, men alt for tillidsfuld grænseflade og bliver i stedet et værktøj til sikker drift af processen.