HMI/SCADA-sovellusten suunnittelu kyberturvallisuus edellä – periaatteet, jotka vähentävät riskiä jo suunnitteluvaiheessa

HMI/SCADA-sovelluksen turvallisuus ratkaistaan jo paljon ennen suojausmekanismien valintaa. Se, kestääkö järjestelmä virheitä, väärinkäyttöä ja prosessin tilan hallitsemattomia muutoksia, riippuu ennen kaikkea suunnittelussa tehdyistä lähtöoletuksista: roolijaosta, luottamusrajoista, käyttöliittymän kautta käytettävissä olevien toimintojen laajuudesta sekä huollon ja etäkäytön järjestämistavasta. Jos nämä asiat jäävät toissijaisiksi, sovellus alkaa vähentämisen sijaan ylläpitää riskiä. Siksi HMI/SCADA-suunnittelu on toteutettava kyberturvallisuus huomioiden insinöörityönä: ensin määritetään, mitkä toiminnot ovat kriittisiä, millaisia seurauksia niillä voi olla ja kenellä niiden suorittamiseen todella tulee olla oikeus, ja vasta sen jälkeen rakennetaan näytöt, hälytykset ja käytön sujuvuus.

Kyberturvallisuus alkaa suunnittelusta

HMI/SCADA-järjestelmissä kyberturvallisuus ei ole valmisvisualisointiin lisättävä lisäominaisuus. Se perustuu aiemmin tehtyihin päätöksiin: sovellusarkkitehtuuriin, käyttöoikeusmalliin, ohjauksen kanssa käytettävään viestintätapaan ja huoltoa koskeviin lähtöoletuksiin. Tämä on erityisen tärkeää, koska HMI/SCADA-sovellus on samalla ihmisen, prosessin ja infrastruktuurin rajapinta. Suunnitteluvirhe ei siis rajoitu tietoturvariskiin. Se voi samanaikaisesti vaikuttaa operaattorin reagointiin, toiminnalliseen turvallisuuteen, operatiiviseen riskiin ja tuotannon jatkuvuuteen.

Suunnittelun näkökulmasta peruskysymys ei siis ole, mikä suojaus lisätään lopuksi, vaan mitkä päätökset pienentävät hyökkäyspintaa jo alussa. Suurimmat ongelmat eivät yleensä johdu yksittäisen mekanismin puuttumisesta, vaan sovellukseen rakennetusta liiallisesta luottamuksesta. Käytännössä tämä tarkoittaa yhteisiä käyttäjätilejä, laajaa ja jatkuvaa huoltoyhteyttä, operaattorin, kunnossapidon ja integraattorin roolien erottelun puutetta sekä liian vapaata tiedonsiirtoa operaattoritason ja ohjauksen välillä. Käyttöönoton vaiheessa tällaiset ratkaisut vaikuttavat käteviltä, koska ne nopeuttavat työtä ja helpottavat diagnostiikkaa. Myöhemmin niistä tulee ympäristön pysyvä ominaisuus, joka lisää väärinkäytön, virheen tai prosessin tilan hallitsemattoman muutoksen riskiä.

Siksi ennen näyttöjen suunnittelua kannattaa määrittää paitsi se, mitä käyttäjän tulee nähdä, ennen kaikkea myös se, missä luottamusrajat kulkevat, mitkä toiminnot ovat kriittisiä ja missä kohdissa käyttöliittymä voi muuttua virheen tai menettelytavan kiertämisen välineeksi. Tällainen etenemisjärjestys selkeyttää myöhempiä päätöksiä: onko HMI tarkoitettu pelkäksi visualisointikerrokseksi vai myös konfiguroinnin, diagnostiikan ja reseptimuutosten paikaksi; toimivatko huoltotoiminnot jatkuvasti vai vain tietoisesti käynnistettyinä; onko operaattorilla pääsy ainoastaan prosessin käyttöön vai myös toimintoihin, joilla muutetaan parametreja ja tietohistoriaa.

Laiminlyöntien käytännön kustannukset tulevat yleensä esiin vasta silloin, kun sovellus on jo sidottu resepteihin, hälytyksiin, raportointiin, arkistointiin ja kunnossapidon menettelyihin. Tällöin jopa näennäisesti yksinkertainen korjaus, kuten tilien erottelu, kriittisen toiminnon hyväksymispolun muuttaminen tai etäkäytön rajaaminen satunnaiseen käyttöön, ei enää ole pelkkä näyttömuutos. Se edellyttää logiikan uudelleenrakentamista, hälytysten käsittelyn uudelleentestausta, vastuiden määrittämistä ja usein myös organisaatiomuutoksia laitoksessa.

Käytännössä järkevin lähtökohta on alustava kartta käyttäjärooleista ja niiden oikeuksista kriittisiin toimintoihin, luettelo toiminnoista, jotka muuttavat prosessin tilaa, asetuksia tai reseptejä, sekä ulkoisten yhteyksien kuvaus, joka kattaa huollon, raportoinnin, ylemmän tason järjestelmät ja etäkäytön. Tämän pohjalta voidaan vasta tarkoituksenmukaisesti suunnitella vyöhykkeiden ja yhteyksien arkkitehtuuri sekä valmistella myöhempi riskianalyysi. Tällainen lähestymistapa vastaa sekä insinöörikäytäntöä että vaatimuksia vastuiden jäsentämisestä, toimintojen erottelusta ja viestinnän hallinnasta teollisuusympäristöissä.

Missä kustannukset ja riskit todella kasvavat

HMI/SCADA-sovelluksen suurimmat kustannukset ja riskit eivät johdu pelkästään järjestelmien yhdistämisestä sinänsä, vaan siitä, millaisia prosessi- ja organisaatiovaikutuksia sovelluksen yksittäiset toiminnot aiheuttavat. Herkimpiä ovat ne kohdat, joissa asetuksia voidaan muuttaa nopeasti, ottaa käyttöön ohitus, vaimentaa hälytys, muuttaa reseptiä tai suorittaa käsiohjaus ilman täyttä teknologista kontekstia. Jos suunnittelu sallii tällaiset toiminnot tuotantonäytöltä rutiinikäytössä, riski kasvaa, koska yksi käyttäjän päätös tai yksi haltuun otettu istunto voi muuttaa prosessin tilaa suoraan.

Tämä tarkoittaa, että kriittisten toimintojen luetteloa on käsiteltävä osana turvallisuusarkkitehtuuria, ei pelkästään käyttöliittymän ergonomiaan liittyvänä kysymyksenä. Sama koskee myös toimien jäljitettävää vastuutusta. Yhteiset kirjautumistunnukset, vuoron kesken jaetut käyttäjätilit, luku-, ohjaus-, konfigurointi- ja ylläpito-oikeuksien puutteellinen erottelu sekä niukka tapahtumakirjaus johtavat siihen, että poikkeaman jälkeen on vaikea luotettavasti selvittää, oliko kyse virheestä, menettelyn ohittamisesta, huolto-oikeuksien väärinkäytöstä vai luvattomasta toiminnasta. Ongelma ei rajoitu pelkästään syiden selvittämiseen. Ilman luotettavaa käyttäjätoimien jälkeä ei voida myöskään arvioida menettelyjen toimivuutta, hallita käyttöoikeuksia järkevästi eikä perustella käyttöön liittyviä päätöksiä sisäisessä auditoinnissa, asiakkaan vaatimusten tai hyväksyttyjen turvallisuuspolitiikkojen näkökulmasta. Käytännössä kyse on toimien vastuutettavuudesta ja jäljitettävyysketjusta, ei vain tapahtumien tallentamisesta.

Erittäin kallis suunnitteluvirhe on myös se, että tuotantoympäristöön siirretään laajoja huolto- ja diagnostiikkanäkymiä, jotka on alun perin tehty käyttöönottoa tai integraattorin tukea varten. Tällaiset näkymät antavat usein laajan pääsyn sisäisiin muuttujiin, tilojen pakottamiseen, lukitusten kuittaamiseen ja parametrien muuttamiseen, vaikka normaalissa käytössä niitä tarvitaan korkeintaan satunnaisesti. Jos niihin ei aseteta lisärajoituksia, niistä tulee nopein reitti puuttua prosessiin tavanomaisen operaattoripolun ulkopuolella. Järkevä ratkaisu on erottaa kunnossapidon tarvitsema diagnostiikka toiminnoista, joilla voidaan vaikuttaa toimintalogiikkaan, sekä päättää erikseen, onko koneen valmistajan diagnostiikka käytettävissä paikallisesti, etänä vai vain ehdollisesti, tietoisesti käynnistettynä ja koko istunnon täydellä tallennuksella.

Samalla tavalla on käsiteltävä myös integraatioita tietokantoihin, raportointiin, etätukeen ja toimistojärjestelmiin. Jokainen tällainen yhteys parantaa työn sujuvuutta, mutta samalla lisää riippuvuuksien määrää, joista voi tulla sisääntuloreitti, häiriöiden lähde tai vastuiden epäselvyyden syy. Välityspalvelun vika, virheellinen ajan synkronointi, hallitsematon tiedonvaihto ylemmän tason järjestelmän kanssa tai avoimeksi jätetty huoltokanava voivat vaikuttaa paitsi raporttien saatavuuteen myös operaattorin tekemiin päätöksiin.

Siksi jo suunnitteluvaiheessa kannattaa mitata paitsi näyttöjen käytettävyyttä myös yksinkertaisempia ja hyödyllisempiä tunnuslukuja: kuinka monta kriittistä toimintoa voidaan tehdä tuotantotason HMI:stä, kuinka monta ulkoista yhteyttä on aktiivisena, kuinka monta etuoikeutettua tiliä on käytössä sekä mitä tapahtumia auditointijälki kattaa. Tällainen tarkastelu jäsentää myöhemmin tapahtumien kirjaamista, parametrimuutosten hallintaa ja etäkäytön periaatteita.

Hälytykset vaativat erillisen käsittelyn. Tällä alueella näennäinen kattavuus peittää usein alleen todellisen hallinnan puutteen. Huonosti suunnitellut hälytykset ja tapahtumahistoria eivät ainoastaan kuormita operaattoria, vaan vievät häneltä myös kyvyn erottaa kriittiset signaalit teknisestä kohinasta. Jos hälytys voidaan helposti vaimentaa ilman perustelua, kuitata ilman yhteyttä syyhyn tai hukata diagnostiikkaviestien massaan, sovellus lakkaa tukemasta prosessin turvallisuutta. Siksi hälytysprioriteettien tulee perustua todellisiin vaikutuksiin ihmisten, koneen ja tuotannon laadun kannalta sekä pysyä sidoksissa kuittausten, ohitusten ja asetusmuutosten kirjaamiskäytäntöihin. Juuri tässä vaiheessa riskianalyysi lakkaa olemasta muodollinen asiakirja ja alkaa muovata käyttöliittymää.

Miten suunnitella niin, että virheen ja väärinkäytön vaikutukset jäävät mahdollisimman vähäisiksi

Lähtökohta on yksinkertainen: HMI/SCADA-sovellus ei voi perustua oletukseen, että jokainen käyttäjä toimii aina oikein ja prosessin kannalta oikeassa tilanteessa. Suunnittelu on aloitettava toimintojen erottelusta, ei näyttöjen piirtämisestä. Tiimin on ensin määriteltävä, mitä operaattori saa vain nähdä, mitä hän voi kuitata, mitä hän saa muuttaa normaalin työnkulun aikana ja mitkä toimet on siirrettävä huoltotilaan, suojattava lisävaltuutuksella tai erotettava kokonaan omaan työkaluunsa tai asemalleen.

Tällainen päätös jäsentää koko käyttöoikeusarkkitehtuurin: roolit, oikeuksien laajuuden, toimien kirjaamistavan ja etätuen ehdot. Käytännössä hyvin toimii roolimatriisi, joka perustuu todellisiin tehtäviin ja erottaa toisistaan operaattorin, työnjohtajan, kunnossapidon, teknologin, integraattorin ja ylläpitäjän. Tämä ei ole muodollisuus. Jos huoltotoiminnot jäävät samalle näytölle ja saman käyttäjätilin alle kuin prosessin käyttö, sovellus itse luo reitin virheelle, menettelyn ohittamiselle tai käyttöoikeuksien väärinkäytölle.

Hyvä HMI/SCADA rajoittaa vaarallisen toiminnon suorittamista vahingossa, mutta ei hidasta tarpeettomasti rutiinitehtäviä. Tämä edellyttää selkeää käyttötilannetta: käyttäjän on nähtävä, minkä kohteen parissa hän työskentelee, missä tilassa prosessi on, toimiiko hän paikallisesti vai etänä sekä onko järjestelmä automaatti-, käsiohjaus- vai huoltotilassa. Kuittausten on oltava riskin mukaisia, ei samanlaisia kaikille toiminnoille. Siellä, missä virheen vaikutus on palautuva ja rajallinen, yksi valtuutus riittää yleensä. Kriittiset toiminnot vaativat lisävalvontaa: toisen vahvistuksen, uudelleentodennuksen, riippuvuuden prosessin tilasta tai fyysisen siirtymisen erilliseen käyttöliittymään.

Tärkeitä ovat myös ehdolliset lukitukset. Jos sovellus sallii asetusarvon muuttamisen, signaalin pakottamisen tai siirtymisen käsikäyttötilaan kohteen tilasta riippumatta, riski siirtyy suunnittelusta operaattorille. Juuri tässä näkyy, ettei käyttöliittymän oikea suunnittelu tarkoita pelkästään käytön helppoutta, vaan virheiden vaikutusten rajaamista sisäänrakennetuilla esteillä. Monissa tapauksissa tällainen ajattelutapa muistuttaa sitä, miten Poka-Yoke tuotantolinjoilla toimii.

Käyttöoikeuksien kerroksittaisen suunnittelun tulee kattaa myös se, miten oikeuksia käytetään ajallisesti. Henkilökohtaiset käyttäjätilit ovat välttämättömiä kaikkialla, missä toimien jäljitettävyyttä edellytetään. Yhteinen tili poistaa mahdollisuuden todeta, kuka päätöksen tosiasiallisesti teki. Vähimmän oikeuden periaate tarkoittaa, että käyttäjä saa vain ne toiminnot, joita hän tarvitsee kulloiseenkin työhönsä, ja oikeuksien korotus tehdään määräajaksi ja valvotuissa olosuhteissa. Tämä koskee erityisesti kunnossapitoa, integraattoria ja valmistajan etätukea. Pysyvä, avoin huoltoreitti on näennäisesti kätevä, koska se poistaa luonnollisen luottamusrajan käytön ja huollon väliltä. Turvallisempi malli on pyynnöstä aktivoitava käyttöoikeus, joka on ajallisesti rajattu, sidottu tiettyyn henkilöön ja kirjattu tapahtumahistoriaan. Tämä lähestymistapa sopii hyvin yhteen vähimpien oikeuksien periaatteen ja käyttöoikeuksien segmentoinnin kanssa.

Samassa hengessä on ratkaistava, ovatko huoltotoiminnot käytettävissä työasemana toimivasta HMI:stä vai ainoastaan erilliseltä asemalta, sekä sallitaanko siirrettävät tallennusvälineet ja paikallinen tietojen tuonti tai vienti operaattoripaneelista. Nämä päätökset eivät ole sivuseikkoja. Niistä riippuu, toteutuuko järjestelmän ylläpidettävyys hallitusti vai tilapäisten kiertoratkaisujen varassa.

Häiriötilanteen tai käyttöön liittyvän kiistan näkökulmasta pelkkä käyttöliittymä ei riitä. Sovelluksen on jätettävä aineisto, jonka avulla päätöksenteon kulku voidaan jälkikäteen rekonstruoida. Tapahtumahistorian, järjestelmälokien ja muutosten kirjaamisen tulee yhdessä vastata paitsi kysymykseen siitä, mitä tapahtui, myös siihen, kuka teki toimenpiteen, milloin, mistä paikasta ja missä prosessin tilassa. Vähimmäistaso tapahtumille, jotka yleensä kannattaa ottaa lokitukseen mukaan, kattaa kirjautumisen, käyttöoikeuksien muutokset, parametrien muutokset, siirtymisen käsikäyttötilaan, hälytyksen kuittauksen sekä konfiguraation tuonnin. Ratkaisevaa on liittää kirjaus teknologiseen kontekstiin, koska pelkkä tieto muutoksesta ilman kohteen tilaa on usein hyödytön.

Hyvä esimerkki on monille käyttöönottohankkeille tyypillinen: teknologiainsinöörin tekemä hälytysrajan muutos voi olla sallittu, mutta vain ennalta määritettyyn tilaan siirtymisen jälkeen, siten että käyttäjä, asema, aika, edellinen ja uusi arvo sekä vahvistus siitä, ettei kohde ollut kriittisessä tilassa, kirjataan. Tällainen jälki on tärkeä sekä turvallisuuden että teollisten sovellusten muutoksenhallinnan kannalta.

Viimeinen kerros on ylläpidettävyys ilman suojausten kiertämistä. Jos päivitys, konfiguraation palautus tai diagnostiikka edellyttävät käyttöoikeuksien valvonnan poistamista käytöstä, yhteisen salasanan käyttöä tai työskentelyä ilman auditointijälkeä, ongelma on suunnittelussa eikä henkilöstön kurinalaisuudessa. Sovellukselle on oltava ennalta määritelty muutoksen kulku: pyyntö, vaikutusten arviointi, testi, käyttöönotto, vahvistus ja palautussuunnitelma. Sen tulee myös erottaa käyttöympäristö huoltoympäristöstä vähintään loogisesti ja siellä, missä se on perusteltua, myös organisatorisesti ja teknisesti. Konfiguraatiovarmuuskopioiden tekemisen ja palauttamisen on oltava mahdollista hallitusti ilman tilapäistä ”varmuuden vuoksi” tehtävää vientiä paneelista. Tällainen lähestymistapa on yhdenmukainen OT-ympäristöjen vähimpien oikeuksien periaatteen sekä käyttöoikeuksien hallintaa, toimien jäljitettävyyttä ja muutoksenhallintaa koskevien vaatimusten kanssa, mutta niiden laajuus on aina suhteutettava järjestelmäarkkitehtuuriin ja omaksuttuun vastuunjakoon.

Käyttöönoton käytäntö ja viittaus vaatimuksiin

Eniten hyötyä saadaan siitä, ettei projektin loppuvaiheessa lisätä yhä uusia suojausmekanismeja, vaan sovellus käydään järjestelmällisesti läpi ennen vastaanottoa tai modernisointia. Tämä on se vaihe, jossa järjestelmän toimintatapaa voidaan vielä korjata suhteellisen pienin kustannuksin sen sijaan, että virheellisiä lähtöoletuksia jouduttaisiin myöhemmin paikkaamaan lisämenettelyillä. Tällaisen tarkastelun tulisi olla yhdistetyn tiimin tehtävä: suunnittelu, kunnossapito, käyttö, automaatioasiantuntija ja työturvallisuudesta vastaavat henkilöt.

Arvioinnin kohteena ei ole pelkästään tekninen konfiguraatio, vaan se, erottaako sovellus todella roolit toisistaan, suojaako se kriittiset toiminnot, rajoittaako etäkäytön perusteltuihin tapauksiin, tarjoaako selkeän hälytysten käsittelyn, säilyttääkö muutoshistorian sekä mahdollistaako varmuuskopioiden ja hätätilamenettelyjen toteuttamisen ilman suojausten kiertämistä. Juuri tällaisesta tarkastelusta pitäisi muodostua luettelo FAT/SAT-vaiheita varten sekä vastaanottoon, huoltosuunnitelmaan ja toteumadokumentaatioon kirjattavat vaatimukset.

Tämä lähestymistapa siirtää painopisteen itse suojausratkaisuista suunnittelupäätöksiin, jotka myöhemmin määrittävät ihmisten ja laitteiden toimintaa. Jos jo suunnitteluvaiheessa ei ole määritelty, kuka saa muuttaa reseptiparametreja, kuka hyväksyy huoltotilan, miten integraattorin tekemät muutokset kirjataan ja millä ehdoilla pääsy tehtaan ulkopuolelta on sallittu, järjestelmä alkaa käyttöönoton jälkeen nojata poikkeuksiin ja suullisiin sopimuksiin.

Samasta syystä kannattaa ratkaista, tehdäänkö sovelluksen arviointi koneen tai linjan modernisoinnin yhteydessä vai erillisenä OT-ympäristön tarkasteluna. Ensimmäinen lähestymistapa kytkee turvallisuuden paremmin prosessin toimintaan, jälkimmäinen taas helpottaa järjestelmien välisten riippuvuuksien sekä käyttäjätilien, käyttöoikeuksien ja tapahtumien kirjaamisen vastuunjaon tunnistamista. Tämä on myös luonteva paikka alustavalle riskianalyysille: kriittisten toimintojen, luottamusrajojen sekä käyttäjän virheen tai väärinkäytön seurausten tunnistamiselle. Käytännössä tässä auttaa myös riskianalyysi projektissa.

• käyttäjäroolit ja kirjautumistapa,
• kriittiset toiminnot ja niiden vahvistamiskäytännöt,
• etäyhteydet ja huoltotoiminnot,
• hälytykset, muutosten kirjaaminen ja toimenpiteiden jäljitettävyys,
• varmuuskopiot, palautus ja poikkeustilamenettelyt.

Hyvä lopputulos tehtaassa syntyy harvoin siitä, että otetaan käyttöön monta työkalua samanaikaisesti. Tavallisesti suurempi merkitys on muutaman sellaisen järjestelmätason riskin poistamisella, joita on vuosien ajan pidetty käytännöllisinä ratkaisuina. HMI/SCADA-sovelluksen modernisointi voi alkaa yhteisten käyttäjätilien poistamisesta, huoltotoimintojen erottamisesta operaattoritoiminnoista, ulkoisten yhteyksien rajaamisesta valvottuihin yhteyspolkuihin sekä parametrimuutosten lokituksen käyttöönotosta niin, että muutos voidaan liittää tiettyyn henkilöön tai rooliin. Tällaisen muutoksen ei tarvitse heikentää kunnossapidon tai integraattorin työtä, kunhan huoltotila, valtuutuskäytännöt ja muutosten toistettavissa oleva toteutustapa on määritelty alusta alkaen.

Käytön aikana kannattaa sen jälkeen mitata ei abstraktia turvallisuustasoa vaan operatiivisesti hyödyllisiä tunnuslukuja: kuinka monta yhteistä käyttäjätiliä järjestelmässä on edelleen käytössä, kuinka laaja aktiivinen etäkäyttö on, kuinka täydellisiä muutoslokit ovat, kuinka kauan konfiguraation palauttaminen kestää sekä kuinka monta toimenpidettä tehdään virallisen menettelyn ulkopuolella. Tällaiset mittarit auttavat arvioimaan, vähensikö projekti todella riskiä vai siirsikö se sitä vain päivittäiseen toimintaan.

Puolan ja EU:n toimintaympäristössä on yhä vaikeampi perustella lähestymistapaa, jossa HMI/SCADA-kyberturvallisuus on yksinomaan IT-osaston asia. Vastuu jakautuu suunnittelun, käytön, kunnossapidon, toimittajien ja integraattorien kesken, ja toimialakohtaisilla sekä sopimusperusteisilla vaatimuksilla on merkitystä vasta silloin, kun organisaatio pystyy osoittamaan konkreettisesti, mitä suunnittelupäätöksiä tehtiin, miten käyttöoikeudet myönnetään, millainen toimenpiteiden jälki jää ja kuka valvoo muutoksia. Pelkät viittaukset standardeihin, politiikkoihin tai sopimusehtoihin eivät korvaa näyttöä siitä, että sovellus on suunniteltu ja hyväksytty tavalla, joka mahdollistaa turvallisen käytön.

Tärkein johtopäätös on käytännöllinen. Edullisin ja tehokkain vaihe riskin vähentämiseen on edelleen sovelluksen suunnittelu ja hyväksyntä. Juuri silloin luottamusrajat, roolit, pääsyn ehdot, toimenpiteiden jäljitettävyys ja muutosten hallintatapa voidaan määrittää pienimmillä kustannuksilla. Jos nämä vaatimukset muunnetaan todennettaviksi kriteereiksi toimittajaa ja integraattoria varten, HMI/SCADA lakkaa olemasta kätevä mutta liian luottavainen käyttöliittymä ja siitä tulee prosessin turvallisen käytön työkalu.