Utformning av HMI/SCADA-applikationer med cybersäkerhet i fokus – principer som minskar risken redan på projekteringsstadiet

Säkerheten i HMI-/SCADA-applikationer avgörs långt tidigare än vid valet av skyddsmekanismer. Om systemet blir robust mot misstag, missbruk och okontrollerade förändringar i processtillståndet beror framför allt på de antaganden som fastställs i projektet: rollfördelning, förtroendegränser, vilka funktioner som ska vara tillgängliga via gränssnittet samt hur service och fjärråtkomst organiseras. Om dessa frågor behandlas som sekundära börjar applikationen befästa risker i stället för att begränsa dem. Därför måste HMI/SCADA utformas med cybersäkerhet i åtanke som en ingenjörsuppgift: först fastställa vilka operationer som är kritiska, vilka konsekvenser de kan få och vem som faktiskt ska kunna utföra dem, och först därefter bygga skärmbilder, larm och användarvänlig drift.

Cybersäkerhet börjar i projektet

I HMI-/SCADA-system är cybersäkerhet inte ett tillägg till en färdig visualisering. Den följer av beslut som fattas tidigare: av applikationsarkitekturen, behörighetsmodellen, sättet att kommunicera med styrsystemet och förutsättningarna för service. Detta är särskilt viktigt eftersom HMI-/SCADA-applikationen samtidigt är gränssnittet mellan människa, process och infrastruktur. Ett konstruktionsfel stannar därför inte vid en IT-risk. Det kan samtidigt påverka operatörens agerande, funktionssäkerheten, den operativa risken och produktionskontinuiteten.

Ur projektsynpunkt är den grundläggande frågan därför inte vilket skydd som ska läggas till i slutet, utan vilka beslut som redan från början begränsar angreppsytan. De största problemen beror vanligtvis inte på att en enskild mekanism saknas, utan på ett alltför stort förtroende som byggts in i applikationen. I praktiken innebär det gemensamma användarkonton, bred och permanent serviceåtkomst, avsaknad av rollseparering mellan operatör, underhåll och integratör samt alltför fri kommunikation mellan operatörslagret och styrningen. Vid idrifttagning kan sådana lösningar verka bekväma, eftersom de påskyndar arbetet och underlättar diagnostik. Senare blir de en bestående egenskap i miljön och ökar risken för missbruk, misstag eller okontrollerad förändring av processtillståndet.

Därför är det klokt att före utformningen av skärmbilderna inte bara fastställa vad användaren ska se, utan framför allt var förtroendegränserna går, vilka operationer som är kritiska och på vilka punkter gränssnittet kan bli ett verktyg för fel eller för att kringgå en procedur. Denna ordning strukturerar senare beslut: om HMI endast ska vara ett visualiseringslager eller också en plats för konfiguration, diagnostik och receptändringar; om servicefunktioner ska vara aktiva permanent eller endast efter medveten aktivering; om operatören endast ska ha tillgång till processdrift eller även till operationer som ändrar parametrar och datahistorik.

Den praktiska kostnaden för försummelser visar sig vanligtvis först när applikationen redan är kopplad till recept, larm, rapportering, arkivering och underhållsprocedurer. Då upphör även en till synes enkel korrigering, som att separera konton, ändra godkännandeflödet för en kritisk operation eller begränsa fjärråtkomst till tillfälliga situationer, att vara en ändring i skärmbilderna. Den kräver ombyggnad av logiken, förnyad testning av larmhanteringen, tydliggörande av ansvar och ofta även organisatoriska förändringar i anläggningen.

I praktiken är den mest rimliga utgångspunkten en arbetskarta över användarroller och deras behörigheter för kritiska operationer, en lista över funktioner som orsakar förändringar i processtillstånd, konfiguration eller recept samt en förteckning över externa anslutningar som omfattar service, rapportering, överordnade system och fjärråtkomst. Först på denna grund går det att på ett meningsfullt sätt utforma arkitekturen för zoner och anslutningar samt förbereda den senare riskanalysen. Ett sådant angreppssätt motsvarar både ingenjörspraxis och kraven på att strukturera ansvar, separera funktioner samt kontrollera kommunikationen i industriella automationsmiljöer.

Var kostnad och risk faktiskt ökar

Den största kostnaden och risken i en HMI-/SCADA-applikation följer inte enbart av att systemen är sammankopplade, utan av vilka processmässiga och organisatoriska konsekvenser applikationens enskilda funktioner medför. Mest känsliga är de punkter som gör det möjligt att snabbt ändra inställningar, införa en förbikoppling, tysta ett larm, ändra ett recept eller utföra manuell styrning utan full teknisk kontext. Om projektet tillåter sådana operationer från produktionsskärmen i rutinläge ökar risken, eftersom ett enda användarbeslut eller en enda kapad session direkt kan förändra processtillståndet.

Det innebär att katalogen över kritiska operationer måste behandlas som en del av säkerhetsarkitekturen, inte enbart som en fråga om gränssnittsergonomi. Samma mekanism gäller för spårbarhet och ansvar i användarnas åtgärder. Gemensamma inloggningar, konton som delas mellan skift, avsaknad av åtskillnad mellan behörigheter för visning, styrning, konfigurering och administration samt bristfällig händelselogging gör att det efter en incident är svårt att på ett tillförlitligt sätt fastställa om det rörde sig om ett misstag, ett avsteg från rutinen, missbruk av serviceåtkomst eller en obehörig åtgärd. Problemet handlar inte bara om att utreda orsaken. Utan ett trovärdigt spår av användarens åtgärder går det inte heller att bedöma hur effektiva rutinerna är, hantera behörigheter på ett meningsfullt sätt eller försvara driftbeslut vid intern revision, kundkrav eller fastställda säkerhetspolicyer. I praktiken handlar det här om ansvarsspårbarhet och en spårbarhetskedja, inte bara om själva registreringen av händelser.

Ett annat mycket kostsamt konstruktionsfel är att föra över omfattande service- och diagnosskärmar till produktionsmiljön, trots att de ursprungligen tagits fram för idrifttagning eller för att stödja integratören. Sådana vyer ger ofta bred åtkomst till interna variabler, tvingande av tillstånd, kvittering av spärrar och ändring av parametrar, även om de under normal drift bara behövs undantagsvis. Om de inte omfattas av ytterligare begränsningar blir de den kortaste vägen till att påverka processen utanför den vanliga operatörsvägen. En rimlig lösning är att skilja den diagnostik som behövs för underhåll från funktioner som gör det möjligt att ingripa i driftlogiken, och att separat besluta om maskintillverkarens diagnostik ska vara tillgänglig lokalt, på distans eller endast villkorat, efter medveten aktivering och med fullständig sessionsloggning.

På samma sätt bör integration med databaser, rapportering, fjärrsupport och kontorssystem hanteras. Varje sådan koppling förbättrar arbetsbekvämligheten, men ökar samtidigt antalet beroenden som kan bli en angreppsväg, en störningskälla eller en orsak till otydligt ansvar. Fel i en mellanliggande tjänst, felaktig tidssynkronisering, okontrollerat datautbyte med överordnat system eller en kvarlämnad servicekanal kan påverka inte bara rapporternas tillgänglighet utan också de beslut som operatören fattar.

Därför är det klokt att redan i projekteringen mäta inte bara skärmarnas tillgänglighet, utan också enklare och mer användbara indikatorer: antalet kritiska operationer som kan utföras från produktions-HMI, antalet aktiva externa anslutningar, antalet privilegierade konton samt omfattningen av de händelser som täcks av revisionsspåret. En sådan genomgång skapar senare ordning i händelseregistrering, kontroll av parameterändringar och regler för fjärråtkomst.

Alarmhantering kräver en separat behandling. Inom detta område döljer skenbar fullständighet ofta en faktisk brist på kontroll. Felaktigt utformade larm och händelsehistorik överbelastar inte bara operatören, utan tar också ifrån honom eller henne förmågan att skilja kritiska signaler från tekniskt brus. Om ett larm enkelt kan tystas utan motivering, kvitteras utan koppling till orsaken eller försvinna i mängden av diagnostiska meddelanden, slutar applikationen att stödja processäkerheten. Därför bör larmprioriteringar utgå från den verkliga konsekvensen för människor, maskinen och produktkvaliteten samt förbli kopplade till reglerna för registrering av kvitteringar, förbikopplingar och ändringar av inställningar. Det är just här som riskanalysen upphör att vara ett formellt dokument och börjar forma gränssnittet.

Hur man projekterar för att begränsa följderna av fel och missbruk

Utgångspunkten är enkel: en HMI/SCADA-applikation kan inte utgå från att varje användare alltid agerar korrekt och i rätt processkontext. Projekteringen måste börja med att skilja funktioner åt, inte med att rita skärmbilder. Teamet bör först fastställa vad operatören endast ska kunna se, vad som får kvitteras, vad som får ändras i det normala arbetsflödet och vilka åtgärder som ska flyttas till serviceläge, omfattas av ytterligare auktorisering eller helt skiljas ut till ett separat verktyg eller en separat station.

Ett sådant beslut skapar ordning i hela åtkomstarkitekturen: roller, behörighetsomfång, hur åtgärder registreras och villkoren för fjärrsupport. I praktiken fungerar en rollmatris väl när den bygger på faktiska arbetsuppgifter och skiljer mellan operatör, arbetsledare, underhåll, processtekniker, integratör och administratör. Det är ingen formalitet. Om servicefunktioner ligger kvar på samma skärm och under samma konto som processhanteringen skapar applikationen själv en väg till misstag, avsteg från rutiner eller missbruk av behörigheter.

Ett bra HMI/SCADA begränsar möjligheten att av misstag utföra en farlig operation, men bromsar inte rutinåtgärder i onödan. Det kräver en tydlig arbetskontext: användaren ska se vilket objekt arbetet gäller, i vilket tillstånd processen befinner sig, om arbetet sker lokalt eller på distans samt om systemet är i automatiskt läge, manuellt läge eller serviceläge. Bekräftelser måste stå i proportion till risken, inte vara likadana för alla åtgärder. Där konsekvensen av ett fel är reversibel och begränsad räcker det vanligtvis med en enkel auktorisering. Kritiska operationer kräver ytterligare kontroll: en andra bekräftelse, ny autentisering, beroende av processtillståndet eller fysisk övergång till ett avskilt gränssnitt.

Villkorade spärrar är också viktiga. Om applikationen tillåter att ett börvärde ändras, en signal tvingas eller manuellt läge aktiveras oberoende av objektets tillstånd, flyttas risken från konstruktionen till operatören. Det är just här det blir tydligt att korrekt utformning av gränssnittet inte bara handlar om användarvänlighet, utan om att begränsa följderna av fel genom inbyggda barriärer. I många fall ligger detta synsätt nära hur Poka-Yoke i produktionslinjer fungerar.

Skiktad utformning av åtkomst bör även omfatta hur behörigheter används över tid. Individuella konton är nödvändiga överallt där man förväntar sig spårbarhet i åtgärder. Ett gemensamt konto gör det omöjligt att fastställa vem som faktiskt fattade beslutet. Minsta behörighet innebär att användaren bara får de funktioner som behövs i det löpande arbetet, och att utökade behörigheter ges tillfälligt och under kontrollerade former. Detta gäller särskilt för underhåll, integratören och tillverkarens fjärrsupport. En permanent öppen serviceväg är bara skenbart bekväm, eftersom den tar bort den naturliga förtroendegränsen mellan drift och service. En säkrare modell är åtkomst som aktiveras vid behov, är tidsbegränsad, knuten till en viss person och registrerad i händelsehistoriken. Detta arbetssätt ligger väl i linje med principen om minsta behörighet och segmentering av åtkomst.

I samma anda måste man avgöra om servicefunktioner ska vara tillgängliga från det ordinarie HMI:t eller endast från en separat station, och om flyttbara medier samt lokal import eller export av data från operatörspanelen ska tillåtas. Dessa beslut är inte av underordnad betydelse. Det är de som avgör om systemets underhållbarhet säkerställs på ett kontrollerat sätt eller genom tillfälliga genvägar.

Ur perspektivet incident eller drifttvist räcker inte själva gränssnittet. Applikationen måste lämna efter sig underlag som gör det möjligt att återskapa beslutsförloppet. Händelsehistorik, systemloggar och ändringsregistrering bör tillsammans ge svar inte bara på vad som hände, utan också på vem som utförde åtgärden, när, från vilken plats och i vilket processtillstånd. Det minsta omfång av händelser som vanligtvis bör registreras omfattar inloggning, ändring av behörigheter, parameterändringar, aktivering av manuellt läge, kvittering av larm samt import av konfiguration. Det är avgörande att koppla registreringen till det tekniska sammanhanget, eftersom enbart information om en ändring utan objektets tillstånd ofta är oanvändbar.

Ett bra exempel är typiskt för många implementationer: en ändring av larmgränsen av en processtekniker kan vara tillåten, men endast efter att avsett läge har aktiverats, med registrering av användare, station, tid, tidigare och nytt värde samt bekräftelse på att objektet inte befann sig i ett kritiskt tillstånd. Ett sådant spår är viktigt både för säkerheten och för ändringshantering i industriella applikationer.

Det sista lagret är underhållbarhet utan att skydden kringgås. Om uppdatering, återställning av konfiguration eller diagnostik kräver att åtkomstkontrollen stängs av, att ett gemensamt lösenord används eller att arbete sker utan revisionsspår, ligger problemet i konstruktionen och inte i personalens disciplin. Applikationen bör ha ett förutsett ändringsförlopp: begäran, konsekvensbedömning, test, införande, bekräftelse och återställningsplan. Den bör också skilja den operativa miljön från servicemiljön åtminstone logiskt och, där det är motiverat, även organisatoriskt och tekniskt. Det måste vara möjligt att skapa och återställa konfigurationskopior på ett kontrollerat sätt, utan tillfällig export “för säkerhets skull” från panelen. Ett sådant angreppssätt är förenligt med principen om minsta behörighet i OT samt med kraven på åtkomstkontroll, spårbarhet i åtgärder och ändringshantering, där omfattningen alltid måste relateras till systemarkitekturen och den ansvarsfördelning som har valts.

Praktiskt genomförande och koppling till krav

Det som ger mest är inte att lägga till fler skyddsmekanismer i slutet av projektet, utan en strukturerad genomgång av applikationen före godkännande eller modernisering. Det är då det fortfarande går att korrigera hur systemet fungerar till relativt låg kostnad, i stället för att senare bygga på felaktiga antaganden med ytterligare procedurer. En sådan genomgång bör utföras av ett blandat team: projekt, underhåll, drift, automationsingenjör och personer med ansvar för säkerhet.

Det som ska bedömas är inte enbart den tekniska konfigurationen, utan om applikationen faktiskt skiljer roller åt, skyddar kritiska operationer, begränsar fjärråtkomst till motiverade fall, säkerställer tydlig larmhantering, bevarar ändringshistorik samt gör det möjligt att utföra säkerhetskopiering och nödprocedurer utan att skydden kringgås. Det är just från en sådan genomgång som listan för FAT/SAT samt de krav som förs in i godkännandet, serviceplanen och slutdokumentationen bör tas fram.

Det här angreppssättet flyttar tyngdpunkten från diskussioner om själva skydden till de konstruktionsbeslut som senare styr hur människor och utrustning beter sig. Om man redan i projekteringsfasen inte har fastställt vem som får ändra receptparametrar, vem som godkänner serviceläge, hur en integratörs ingrepp dokumenteras och under vilka villkor åtkomst utanför anläggningen är tillåten, kommer systemet efter driftsättning att bygga på undantag och muntliga överenskommelser.

Av samma skäl är det värt att avgöra om applikationen ska bedömas inom ramen för en modernisering av maskinen eller linjen, eller som en separat OT-granskning. Det första angreppssättet knyter säkerheten bättre till processens funktion, det andra gör det lättare att fånga beroenden mellan system och fördelningen av ansvar för konton, behörigheter och loggning av aktiviteter. Det här är också en naturlig plats för en inledande riskanalys: identifiering av kritiska operationer, förtroendegränser och konsekvenser av operatörsfel eller missbruk. I praktiken är även riskanalys i projekt ofta till hjälp här.

• roller och hur användare loggar in,
• kritiska operationer och regler för hur de bekräftas,
• fjärråtkomst och servicefunktioner,
• larm, loggning av ändringar samt spårbarhet för åtgärder,
• kopior, återställning och nödprocedurer.

Ett bra resultat i anläggningen beror sällan på att många verktyg införs samtidigt. Vanligtvis är det viktigare att eliminera några systemrisker som under årens lopp har betraktats som praktiska. En modernisering av HMI/SCADA-applikationen kan börja med att gemensamma konton avskaffas, att servicefunktioner skiljs från operatörsfunktioner, att externa anslutningar begränsas till kontrollerade vägar samt att spårning av parameterändringar aktiveras med koppling till en viss person eller roll. En sådan förändring behöver inte försämra arbetet för underhåll eller integratören, förutsatt att serviceläge, regler för auktorisering och ett reproducerbart ändringsförlopp har förutsetts från början.

I driften är det sedan värt att inte mäta en abstrakt säkerhetsnivå, utan indikatorer som är operativt användbara: antalet gemensamma konton som fortfarande finns kvar i systemet, omfattningen av aktiv fjärråtkomst, hur kompletta ändringsloggarna är, tiden för att återställa konfigurationen samt antalet ingrepp som utförs utanför den formella proceduren. Sådana mått gör det möjligt att bedöma om projektet faktiskt har minskat risken eller bara flyttat över den till den dagliga praktiken.

I polska och europeiska förhållanden blir det allt svårare att försvara ett synsätt där cybersäkerheten i HMI/SCADA enbart är IT-avdelningens ansvar. Ansvaret är fördelat mellan projekt, drift, underhåll, leverantörer och integratörer, och branschkrav samt avtalskrav får betydelse först när organisationen kan visa konkreta fakta: vilka konstruktionsbeslut som har fattats, hur behörigheter tilldelas, hur spårbarheten för aktiviteter ser ut och vem som kontrollerar ändringar. Hänvisningar till standarder, policyer eller avtalsbestämmelser ersätter inte bevis på att applikationen har projekterats och godkänts på ett sätt som möjliggör säker drift.

Den viktigaste slutsatsen är praktisk. Den billigaste och mest effektiva tidpunkten för att begränsa risk är fortfarande under projektering och godkännande av applikationen. Det är då man till lägst kostnad fastställer förtroendegränser, roller, åtkomstvillkor, spårbarhet för aktiviteter och hur ändringar ska hanteras. Om dessa krav omsätts till verifierbara kriterier gentemot leverantören och integratören, upphör HMI/SCADA att vara ett bekvämt men alltför godtroget gränssnitt och blir i stället ett verktyg för säker drift av processen.