HMI/SCADA programų projektavimas, atsižvelgiant į kibernetinį saugumą – principai, mažinantys riziką jau projektavimo etape

HMI/SCADA taikomųjų programų sauga nulemiama gerokai anksčiau nei apsaugos priemonių parinkimo etape. Ar sistema bus atspari klaidoms, piktnaudžiavimui ir nekontroliuojamiems proceso būsenos pokyčiams, pirmiausia priklauso nuo projekte priimtų prielaidų: vaidmenų paskirstymo, pasitikėjimo ribų, per sąsają prieinamų funkcijų apimties ir to, kaip organizuojamas aptarnavimas bei nuotolinė prieiga. Jei šie klausimai laikomi antraeiliais, programa pradeda įtvirtinti riziką, o ne ją mažinti. Todėl HMI/SCADA projektavimas, atsižvelgiant į kibernetinį saugumą, turi būti vykdomas kaip inžinerinė užduotis: pirmiausia reikia nustatyti, kurios operacijos yra kritinės, kokias pasekmes jos gali sukelti ir kas iš tikrųjų turėtų galėti jas atlikti, o tik po to kurti ekranus, aliarmus ir patogų valdymą.

Kibernetinis saugumas prasideda projekte

HMI/SCADA sistemose kibernetinis saugumas nėra priedas prie jau parengtos vizualizacijos. Jį lemia anksčiau priimti sprendimai: programos architektūra, teisių modelis, ryšio su valdymo sistema būdas ir aptarnavimo prielaidos. Tai ypač svarbu todėl, kad HMI/SCADA programa kartu yra žmogaus, proceso ir infrastruktūros sąlyčio taškas. Todėl projektavimo klaida nesibaigia vien informacinių technologijų rizika. Ji gali kartu paveikti operatoriaus reakcijos eigą, funkcinę saugą, eksploatacinę riziką ir gamybos tęstinumą.

Žvelgiant iš projektavimo perspektyvos, pagrindinis klausimas yra ne tai, kokią apsaugą pridėti pabaigoje, o kokie sprendimai jau pradžioje sumažins atakos paviršių. Didžiausios problemos paprastai kyla ne dėl vieno konkretaus mechanizmo nebuvimo, bet dėl per didelio pasitikėjimo, įdiegto pačioje programoje. Praktikoje tai reiškia bendras naudotojų paskyras, plačią ir nuolatinę aptarnavimo prieigą, vaidmenų neatskyrimą tarp operatoriaus, techninės priežiūros ir integratoriaus bei pernelyg laisvą ryšį tarp operatoriaus lygmens ir valdymo sistemos. Paleidimo etape tokie sprendimai atrodo patogūs, nes spartina darbus ir palengvina diagnostiką. Vėliau jie tampa nuolatine aplinkos savybe ir didina piktnaudžiavimo, klaidos ar nekontroliuojamo proceso būsenos pakeitimo riziką.

Todėl prieš projektuojant ekranus verta nustatyti ne tik tai, ką naudotojas turi matyti, bet pirmiausia kur eina pasitikėjimo ribos, kurios operacijos yra kritinės ir kuriose vietose sąsaja gali tapti klaidos įrankiu arba procedūros apeities priemone. Tokia seka padeda sutvarkyti vėlesnius sprendimus: ar HMI turi būti tik vizualizacijos sluoksnis, ar ir konfigūravimo, diagnostikos bei receptūrų keitimo vieta; ar aptarnavimo funkcijos turi veikti nuolat, ar tik sąmoningai jas įjungus; ar operatorius turi turėti prieigą tik prie proceso valdymo, ar ir prie operacijų, keičiančių parametrus bei duomenų istoriją.

Praktinė aplaidumo kaina paprastai išryškėja tik tada, kai programa jau būna susieta su receptūromis, aliarmais, ataskaitų teikimu, archyvavimu ir techninės priežiūros procedūromis. Tuomet net ir iš pažiūros paprastas pakeitimas, pavyzdžiui, paskyrų atskyrimas, kritinės operacijos tvirtinimo kelio pakeitimas ar nuotolinės prieigos apribojimas iki pavienių atvejų, nebėra vien ekranų korekcija. Tam reikia pertvarkyti logiką, iš naujo išbandyti aliarmų valdymą, nustatyti atsakomybes ir dažnai taip pat atlikti organizacinius pakeitimus įmonėje.

Praktikoje racionaliausias atspirties taškas yra darbinis naudotojų vaidmenų ir jų teisių atlikti kritines operacijas žemėlapis, funkcijų, sukeliančių proceso būsenos, konfigūracijos ar receptūrų pakeitimą, sąrašas bei išorinių jungčių sąrašas, apimantis aptarnavimą, ataskaitų teikimą, aukštesnio lygmens sistemas ir nuotolinę prieigą. Tik tuo pagrindu galima prasmingai projektuoti zonų ir jungčių architektūrą bei parengti vėlesnę rizikos analizę. Toks požiūris atitinka ir inžinerinę praktiką, ir atsakomybių sutvarkymo, funkcijų atskyrimo bei ryšio kontrolės reikalavimus pramoninėje aplinkoje.

Kur iš tikrųjų auga kaštai ir rizika

Didžiausi kaštai ir rizika HMI/SCADA programoje kyla ne vien dėl paties sistemų sujungimo fakto, bet dėl to, kokias proceso ir organizacines pasekmes sukelia atskiros programos funkcijos. Jautriausios yra tos vietos, kurios leidžia greitai pakeisti nustatymus, įvesti apeitį, nutildyti aliarmą, pakeisti receptūrą arba atlikti rankinį valdymą neturint viso technologinio konteksto. Jei projekte tokios operacijos leidžiamos iš gamybinio ekrano įprastiniu režimu, rizika didėja todėl, kad vienas naudotojo sprendimas arba viena perimta sesija gali tiesiogiai pakeisti proceso būseną.

Tai reiškia, kad kritinių operacijų katalogą reikia laikyti saugos architektūros dalimi, o ne vien naudotojo sąsajos ergonomikos klausimu. Tas pats principas taikomas ir veiksmų atsekamumui. Bendri prisijungimai, pamainai bendros paskyros, neatskirtos skaitymo, valdymo, konfigūravimo ir administravimo teisės bei nepakankamas įvykių registravimas lemia, kad po incidento sunku patikimai nustatyti, ar įvyko klaida, procedūros apėjimas, piktnaudžiavimas prieigos teisėmis techninei priežiūrai, ar neteisėtas veiksmas. Problema neapsiriboja vien priežasčių tyrimu. Neturint patikimo naudotojo veiksmų pėdsako, taip pat neįmanoma įvertinti procedūrų veiksmingumo, prasmingai valdyti teisių ar pagrįsti eksploatacinių sprendimų vidaus auditui, kliento reikalavimams ar taikomoms saugos politikoms. Praktikoje čia kalbama apie veiksmų atsekamumą ir identifikuojamumo grandinę, o ne vien apie patį įvykių įrašymą.

Dar viena labai brangi projektavimo klaida – į gamybinę aplinką perkelti išplėstinius serviso ir diagnostikos ekranus, kurie iš pradžių buvo parengti paleidimo darbams ar integratoriaus pagalbai. Tokie vaizdai dažnai suteikia plačią prieigą prie vidinių kintamųjų, būsenų priverstinio nustatymo, blokavimų panaikinimo ir parametrų keitimo, nors įprasto eksploatavimo metu jų prireikia daugiausia tik pavieniais atvejais. Jei jiems netaikomi papildomi apribojimai, jie tampa trumpiausiu keliu įsikišti į procesą apeinant įprastą operatoriaus veiksmų seką. Pagrįstas sprendimas – atskirti diagnostiką, reikalingą techninei priežiūrai, nuo funkcijų, leidžiančių kištis į veikimo logiką, ir atskirai nuspręsti, ar mašinos gamintojo diagnostika turi būti prieinama vietoje, nuotoliniu būdu, ar tik sąlyginai – ją sąmoningai įjungus ir pilnai registruojant sesiją.

Taip pat reikėtų vertinti integraciją su duomenų bazėmis, ataskaitų teikimu, nuotoline pagalba ir biuro sistemomis. Kiekviena tokia jungtis didina darbo patogumą, tačiau kartu padidina priklausomybių skaičių, kurios gali tapti patekimo keliu, trikdžių šaltiniu arba atsakomybės aiškumo praradimo priežastimi. Tarpinės paslaugos sutrikimas, neteisingas laiko sinchronizavimas, nekontroliuojami duomenų mainai su aukštesnio lygmens sistema ar paliktas serviso kanalas gali paveikti ne tik ataskaitų prieinamumą, bet ir operatoriaus priimamus sprendimus.

Todėl jau projektavimo etape verta matuoti ne tik ekranų prieinamumą, bet ir paprastesnius bei naudingesnius rodiklius: kritinių operacijų, kurias galima atlikti iš gamybinio HMI, skaičių, aktyvių išorinių jungčių skaičių, privilegijuotų paskyrų skaičių ir įvykių, kuriems taikomas audito pėdsakas, apimtį. Tokia peržiūra vėliau padeda sutvarkyti įvykių registravimą, parametrų pakeitimų kontrolę ir nuotolinės prieigos taisykles.

Atskiras dėmesys turi būti skiriamas aliarmams. Šioje srityje tariamas išsamumas dažnai slepia realų kontrolės trūkumą. Netinkamai suprojektuoti aliarmai ir įvykių istorija ne tik perkrauna operatorių, bet ir atima iš jo galimybę atskirti kritinius signalus nuo techninio triukšmo. Jei aliarmą galima lengvai nutildyti be pagrindimo, patvirtinti nesiejant su priežastimi arba pamesti diagnostinių pranešimų gausoje, programa nustoja palaikyti proceso saugą. Todėl aliarmų prioritetai turi būti nustatomi pagal realų poveikį žmonėms, mašinai ir gamybos kokybei bei išlikti susieti su patvirtinimų, apėjimų ir nustatymų pakeitimų registravimo taisyklėmis. Būtent čia rizikos analizė nustoja būti formaliu dokumentu ir pradeda formuoti sąsają.

Kaip projektuoti, kad būtų apribotos klaidų ir piktnaudžiavimo pasekmės

Pradinis principas paprastas: HMI/SCADA programa negali remtis prielaida, kad kiekvienas naudotojas visada veikia teisingai ir tinkamame proceso kontekste. Projektavimą reikia pradėti nuo funkcijų atskyrimo, o ne nuo ekranų braižymo. Komanda pirmiausia turėtų nustatyti, ką operatorius turi tik matyti, ką jis gali patvirtinti, ką jam leidžiama keisti įprasto darbo metu, o kuriuos veiksmus reikia perkelti į serviso režimą, apsaugoti papildomu autorizavimu arba visiškai atskirti į atskirą įrankį ar stotį.

Toks sprendimas sutvarko visą prieigos architektūrą: vaidmenis, teisių apimtį, veiksmų registravimo būdą ir nuotolinės pagalbos sąlygas. Praktikoje gerai veikia vaidmenų matrica, paremta realiomis pareigomis ir atskirianti operatorių, pamainos vadovą, techninę priežiūrą, technologą, integratorių ir administratorių. Tai nėra formalumas. Jei serviso funkcijos lieka tame pačiame ekrane ir po ta pačia paskyra kaip ir proceso valdymas, pati programa sukuria kelią klaidai, procedūros apėjimui arba piktnaudžiavimui teisėmis.

Gera HMI/SCADA sistema riboja galimybę pavojingą operaciją atlikti netyčia, tačiau be reikalo nelėtina rutininių veiksmų. Tam reikia aiškaus darbo konteksto: naudotojas turi matyti, su kuriuo objektu dirba, kokios būsenos yra procesas, ar veikia vietoje, ar nuotoliniu būdu, taip pat ar sistema yra automatiniame, rankiniame, ar serviso režime. Patvirtinimai turi atitikti riziką, o ne būti vienodi visiems veiksmams. Ten, kur klaidos pasekmės yra grįžtamos ir ribotos, paprastai pakanka vieno autorizavimo. Kritinėms operacijoms reikia papildomos kontrolės: antro patvirtinimo, pakartotinio tapatybės patvirtinimo, priklausomybės nuo proceso būsenos arba fizinio perėjimo į atskirtą sąsają.

Svarbūs ir sąlyginiai blokavimai. Jei programa leidžia keisti nustatymą, priverstinai nustatyti signalą arba įjungti rankinį režimą neatsižvelgiant į objekto būseną, rizika iš projekto perkeliama operatoriui. Būtent čia matyti, kad tinkamas sąsajos projektavimas nėra vien tik naudojimo patogumas – jis turi riboti klaidų pasekmes pasitelkiant integruotas apsaugines užtvaras. Daugeliu atvejų toks požiūris artimas tam, kaip veikia Poka-Yoke gamybos linijose.

Sluoksniuotas prieigos projektavimas taip pat turi apimti tai, kaip teisės naudojamos laiko požiūriu. Individualios paskyros būtinos visur, kur tikimasi veiksmų atsekamumo. Bendra paskyra panaikina galimybę nustatyti, kas iš tikrųjų priėmė sprendimą. Minimalios teisės reiškia, kad naudotojas gauna tik tas funkcijas, kurių jam reikia einamajam darbui, o teisių išplėtimas suteikiamas laikinai ir kontroliuojamomis sąlygomis. Tai ypač svarbu techninei priežiūrai, integratoriui ir gamintojo nuotolinei pagalbai. Nuolat atviras aptarnavimo kelias patogus tik iš pirmo žvilgsnio, nes panaikina natūralią pasitikėjimo ribą tarp eksploatavimo ir serviso. Saugesnis modelis – pagal pareikalavimą įjungiama prieiga, apribota laike, priskirta konkrečiam asmeniui ir užfiksuota įvykių istorijoje. Toks požiūris gerai atitinka minimalių teisių principą ir prieigos segmentavimą.

Vadovaujantis ta pačia logika, reikia nuspręsti, ar serviso funkcijos turi būti pasiekiamos iš darbinio HMI lygmens, ar tik iš atskiros stoties, taip pat ar leisti keičiamąsias laikmenas ir vietinį duomenų importą ar eksportą iš operatoriaus pulto. Šie sprendimai nėra antraeiliai. Nuo jų priklauso, ar sistemos prižiūrimumas bus užtikrinamas kontroliuojamai, ar per laikinus apeinamuosius sprendimus.

Vertinant incidentą ar eksploatacinį ginčą, vien sąsajos nepakanka. Programa turi palikti medžiagą, leidžiančią atkurti sprendimų eigą. Įvykių istorija, sistemos žurnalai ir pakeitimų registravimas kartu turi atsakyti ne tik į klausimą, kas įvyko, bet ir kas, kada, iš kurios vietos ir kokios proceso būsenos metu atliko veiksmą. Minimalus įvykių mastas, kurį paprastai verta registruoti, apima prisijungimą, teisių pakeitimą, parametrų keitimą, perėjimą į rankinį režimą, aliarmo patvirtinimą ir konfigūracijos importą. Esminė yra įrašo sąsaja su technologiniu kontekstu, nes vien informacija apie pakeitimą be objekto būsenos neretai būna bevertė.

Geras pavyzdys būdingas daugeliui diegimų: technologo atliktas aliarmo slenksčio pakeitimas gali būti leidžiamas, tačiau tik įėjus į numatytą režimą, užfiksavus naudotoją, stotį, laiką, ankstesnę ir naują reikšmę bei patvirtinus, kad objektas nebuvo kritinės būsenos. Toks pėdsakas svarbus tiek saugai, tiek pakeitimų valdymui pramoninėse programose.

Paskutinis sluoksnis – prižiūrimumas neapeinant apsaugų. Jei atnaujinimui, konfigūracijos atkūrimui ar diagnostikai reikia išjungti prieigos kontrolę, naudoti bendrą slaptažodį arba dirbti be audito pėdsako, problema slypi projekte, o ne personalo drausmėje. Programoje turi būti numatyta pakeitimo eiga: prašymas, poveikio vertinimas, bandymas, diegimas, patvirtinimas ir grąžinimo planas. Ji taip pat turi atskirti darbinę ir serviso aplinką bent jau logiškai, o ten, kur tai pagrįsta, ir organizaciškai bei techniškai. Konfigūracijos kopijos turi būti kuriamos ir atkuriamos kontroliuojamu būdu, be atsitiktinio eksporto „dėl visa ko“ iš pulto lygmens. Toks požiūris dera su minimalių teisių principu OT aplinkoje ir su reikalavimais, susijusiais su prieigos kontrole, veiksmų atsekamumu ir pakeitimų valdymu, tačiau jų apimtį visada reikia vertinti pagal sistemos architektūrą ir priimtą atsakomybių pasidalijimą.

Diegimo praktika ir sąsaja su reikalavimais

Daugiausia naudos duoda ne papildomų apsaugos mechanizmų diegimas projekto pabaigoje, o tvarkinga programos peržiūra prieš priėmimą arba modernizavimą. Tai momentas, kai sistemos veikimo būdą dar galima palyginti nebrangiai pakoreguoti, užuot vėliau klaidingas prielaidas apaugus papildomomis procedūromis. Tokią peržiūrą turėtų atlikti mišri komanda: projektavimo, techninės priežiūros, eksploatavimo, automatikos ir už saugą atsakingi asmenys.

Vertinama ne vien techninė konfigūracija, bet ir tai, ar programa iš tikrųjų atskiria vaidmenis, apsaugo kritines operacijas, apriboja nuotolinę prieigą tik pagrįstais atvejais, užtikrina aiškų aliarmų valdymą, išsaugo pakeitimų istoriją ir leidžia atlikti kopijas bei avarines procedūras neapeinant apsaugų. Būtent iš tokios peržiūros turėtų atsirasti sąrašas, skirtas FAT/SAT, taip pat reikalavimai, įtraukiami į priėmimą, serviso planą ir galutinę dokumentaciją.

Taikant šį požiūrį dėmesys perkeliamas nuo diskusijų vien apie apsaugos priemones prie projektinių sprendimų, kurie vėliau lemia žmonių ir įrenginių elgseną. Jei dar projektavimo etape nenustatyta, kas gali keisti receptūrų parametrus, kas tvirtina techninės priežiūros režimą, kaip fiksuojamas integratoriaus įsikišimas ir kokiomis sąlygomis leidžiama prieiga iš už gamyklos ribų, paleidus sistemą ji remsis išimtimis ir žodiniais susitarimais.

Dėl tos pačios priežasties verta apsispręsti, ar taikomosios sistemos vertinimą atlikti modernizuojant mašiną ar liniją, ar kaip atskirą OT peržiūrą. Pirmasis požiūris geriau susieja saugą su proceso funkcija, antrasis padeda lengviau pastebėti priklausomybes tarp sistemų ir atsakomybių pasidalijimą už paskyras, teises bei veiksmų registravimą. Tai taip pat natūrali vieta pradinei rizikos analizei: kritinių operacijų nustatymui, pasitikėjimo ribų apibrėžimui ir operatoriaus klaidos ar piktnaudžiavimo pasekmių įvertinimui. Praktikoje čia taip pat naudinga rizikos analizė projekte.

• naudotojų vaidmenys ir prisijungimo tvarka,
• kritinės operacijos ir jų patvirtinimo taisyklės,
• nuotolinė prieiga ir techninės priežiūros funkcijos,
• signalai, pakeitimų registravimas ir veiksmų atsekamumas,
• atsarginės kopijos, atkūrimas ir avarinės procedūros.

Geras rezultatas gamykloje retai būna daugelio priemonių diegimo vienu metu pasekmė. Dažniausiai didesnę reikšmę turi kelių sisteminių rizikų, kurios metų metus buvo laikomos praktiškomis, pašalinimas. HMI/SCADA taikomosios sistemos modernizavimas gali prasidėti nuo bendrų paskyrų atsisakymo, techninės priežiūros funkcijų atskyrimo nuo operatoriaus funkcijų, išorinių jungčių apribojimo iki kontroliuojamų kelių ir parametrų pakeitimų istorijos įjungimo, susiejant ją su konkrečiu asmeniu arba vaidmeniu. Toks pakeitimas nebūtinai turi apsunkinti techninės priežiūros padalinio ar integratoriaus darbą, jei nuo pat pradžių numatytas techninės priežiūros režimas, autorizavimo taisyklės ir atkuriama pakeitimų eiga.

Eksploatacijos metu vėliau verta matuoti ne abstraktų saugos lygį, o veiklai naudingus rodiklius: sistemoje likusių bendrų paskyrų skaičių, aktyvios nuotolinės prieigos apimtį, pakeitimų registrų išsamumą, konfigūracijos atkūrimo laiką ir intervencijų, atliktų ne pagal formalią procedūrą, skaičių. Tokie rodikliai leidžia įvertinti, ar projektas iš tiesų sumažino riziką, ar tik perkėlė ją į kasdienę praktiką.

Lenkijos ir Europos Sąjungos realijomis vis sunkiau pagrįsti požiūrį, kad HMI/SCADA kibernetinis saugumas yra išimtinai IT skyriaus reikalas. Atsakomybė pasidalija tarp projektavimo, eksploatacijos, techninės priežiūros, tiekėjų ir integratorių, o šakos ir sutartiniai reikalavimai tampa reikšmingi tik tada, kai organizacija gali parodyti konkrečius dalykus: kokie projektiniai sprendimai priimti, kaip suteikiamos teisės, koks yra veiksmų pėdsakas ir kas kontroliuoja pakeitimus. Vien nuorodos į standartus, politikas ar sutarties nuostatas nepakeis įrodymo, kad taikomoji sistema buvo suprojektuota ir priimta taip, kad leistų ją saugiai eksploatuoti.

Svarbiausia išvada yra praktinė. Pigiausias ir veiksmingiausias rizikos mažinimo etapas išlieka taikomosios sistemos projektavimas ir priėmimas. Būtent tada mažiausiomis sąnaudomis nustatomos pasitikėjimo ribos, vaidmenys, prieigos sąlygos, veiksmų pėdsakas ir pakeitimų valdymo būdas. Jei šie reikalavimai paverčiami patikrinamais kriterijais tiekėjui ir integratoriui, HMI/SCADA nustoja būti patogia, bet pernelyg patiklia sąsaja ir tampa saugaus proceso eksploatavimo priemone.