Načrtovanje aplikacij HMI/SCADA z mislijo na kibernetsko varnost – načela, ki zmanjšujejo tveganje že v fazi načrtovanja

O varnosti aplikacije HMI/SCADA se odloča bistveno prej kot v fazi izbire zaščitnih mehanizmov. Ali bo sistem odporen na napako, zlorabo in nenadzorovano spremembo stanja procesa, je odvisno predvsem od predpostavk, sprejetih v projektu: razdelitve vlog, meja zaupanja, obsega funkcij, dostopnih prek vmesnika, ter načina organizacije servisa in oddaljenega dostopa. Če so ta vprašanja obravnavana kot drugotnega pomena, aplikacija začne utrjevati tveganje, namesto da bi ga omejevala. Zato je treba HMI/SCADA načrtovati z vidika kibernetske varnosti kot inženirsko nalogo: najprej določiti, katere operacije so kritične, kakšne posledice lahko imajo in kdo jih dejansko sme izvajati, šele nato pa oblikovati zaslone, alarme in uporabniško udobje.

Kibernetska varnost se začne v projektu

V sistemih HMI/SCADA kibernetska varnost ni dodatek k že pripravljeni vizualizaciji. Izhaja iz odločitev, sprejetih prej: iz arhitekture aplikacije, modela pravic dostopa, načina komunikacije s krmiljenjem in predpostavk za servis. To je še posebej pomembno, ker je aplikacija HMI/SCADA hkrati stičišče človeka, procesa in infrastrukture. Projektna napaka se zato ne konča pri informacijskem tveganju. Hkrati lahko vpliva na potek operaterjevega odziva, funkcionalno varnost, operativno tveganje in neprekinjenost proizvodnje.

Z vidika projekta zato temeljno vprašanje ni, katero zaščito dodati na koncu, temveč katere odločitve že na začetku omejijo napadalno površino. Največje težave praviloma ne izhajajo iz odsotnosti posameznega mehanizma, ampak iz pretiranega zaupanja, vgrajenega v aplikacijo. V praksi to pomeni skupne uporabniške račune, širok in stalen servisni dostop, pomanjkanje ločitve vlog med operaterjem, vzdrževanjem in integratorjem ter preveč sproščeno komunikacijo med operatersko plastjo in krmiljenjem. V fazi zagona se takšne rešitve zdijo priročne, ker pospešijo delo in olajšajo diagnostiko. Pozneje postanejo trajna značilnost okolja ter povečajo tveganje zlorabe, napake ali nenadzorovane spremembe stanja procesa.

Zato je pred načrtovanjem zaslonov smiselno določiti ne le, kaj mora uporabnik videti, ampak predvsem kje potekajo meje zaupanja, katere operacije so kritične in na katerih mestih lahko vmesnik postane vir napake ali obvod postopka. Takšno zaporedje uredi poznejše odločitve: ali naj bo HMI izključno plast vizualizacije ali tudi mesto za konfiguracijo, diagnostiko in spreminjanje receptur; ali naj servisne funkcije delujejo stalno ali le po zavestni aktivaciji; ali naj ima operater dostop samo do upravljanja procesa ali tudi do operacij, ki spreminjajo parametre in zgodovino podatkov.

Praktični strošek zanemarjanja se običajno pokaže šele takrat, ko je aplikacija že povezana z recepturami, alarmi, poročanjem, arhiviranjem in postopki vzdrževanja. Takrat tudi navidezno preprosta korekcija, kot je ločitev računov, sprememba poti potrjevanja kritične operacije ali omejitev oddaljenega dostopa na občasni način, ni več zgolj sprememba na zaslonih. Zahteva prenovo logike, ponovno testiranje obravnave alarmov, določitev odgovornosti in pogosto tudi organizacijske spremembe v obratu.

V praksi je najrazumnejše izhodišče delovni zemljevid uporabniških vlog in njihovih pravic za kritične operacije, seznam funkcij, ki povzročajo spremembo stanja procesa, konfiguracije ali receptur, ter pregled zunanjih povezav, ki zajema servis, poročanje, nadrejene sisteme in oddaljeni dostop. Na tej podlagi je mogoče šele smiselno načrtovati arhitekturo con in povezav ter pripraviti poznejšo analizo tveganja. Tak pristop ustreza tako inženirski praksi kot tudi zahtevam po urejanju odgovornosti, ločevanju funkcij in nadzoru komunikacije v industrijskih okoljih.

Kje strošek in tveganje v resnici naraščata

Največji strošek in tveganje v aplikaciji HMI/SCADA ne izhajata zgolj iz samega dejstva, da so sistemi povezani, temveč iz tega, kakšne procesne in organizacijske posledice povzročajo posamezne funkcije aplikacije. Najbolj občutljiva so tista mesta, ki omogočajo hitro spremembo nastavitev, uvedbo obvoda, utišanje alarma, spremembo recepture ali ročno krmiljenje brez celotnega tehnološkega konteksta. Če projekt takšne operacije dopušča z ravni proizvodnega zaslona v rutinskem načinu, tveganje narašča zato, ker lahko ena sama uporabniška odločitev ali ena sama prevzeta seja neposredno spremeni stanje procesa.

To pomeni, da je treba katalog kritičnih operacij obravnavati kot del varnostne arhitekture, ne zgolj kot vprašanje ergonomije vmesnika. Enak mehanizem velja tudi za sledljivost odgovornosti za dejanja. Skupne prijave, računi, ki si jih deli izmena, nerazmejene pravice za ogled, upravljanje, konfiguracijo in administracijo ter pomanjkljivo beleženje dogodkov povzročijo, da je po incidentu težko zanesljivo ugotoviti, ali je šlo za pomoto, obid postopka, zlorabo servisnega dostopa ali nepooblaščeno dejanje. Težava ni omejena le na ugotavljanje vzrokov. Brez verodostojne sledi uporabniških dejanj tudi ni mogoče oceniti učinkovitosti postopkov, smiselno upravljati pravic dostopa ali zagovarjati obratovalnih odločitev pred notranjo presojo, zahtevami naročnika ali sprejetimi varnostnimi politikami. V praksi gre tu za odgovornost za dejanja in sledljivost, ne le za samo beleženje dogodkov.

Zelo draga projektna napaka je tudi prenos obsežnih servisnih in diagnostičnih zaslonov, prvotno pripravljenih za zagon ali podporo integratorju, v produkcijsko okolje. Takšni prikazi pogosto omogočajo širok dostop do notranjih spremenljivk, vsiljevanja stanj, brisanja blokad in spreminjanja parametrov, čeprav so pri običajnem obratovanju potrebni kvečjemu občasno. Če zanje ne veljajo dodatne omejitve, postanejo najkrajša pot do poseganja v proces zunaj običajne operaterske poti. Razumna rešitev je, da se diagnostika, ki jo potrebuje vzdrževanje, loči od funkcij, ki omogočajo posege v logiko delovanja, ter da se posebej odloči, ali bo diagnostika proizvajalca stroja dostopna lokalno, na daljavo ali le pogojno, po zavestni aktivaciji in s popolnim zapisom seje.

Podobno je treba obravnavati tudi integracijo z bazami podatkov, poročanjem, oddaljeno podporo in pisarniškimi sistemi. Vsaka takšna povezava izboljša udobje pri delu, hkrati pa poveča število odvisnosti, ki lahko postanejo vstopna pot, vir motenj ali razlog za izgubo jasne odgovornosti. Okvara posredniške storitve, napačna sinhronizacija časa, nenadzorovana izmenjava podatkov z nadrejenim sistemom ali odprt servisni kanal lahko vplivajo ne le na razpoložljivost poročil, temveč tudi na odločitve, ki jih sprejema operater.

Zato je že v fazi načrtovanja smiselno meriti ne le razpoložljivost zaslonov, temveč tudi preprostejše in uporabnejše kazalnike: število kritičnih operacij, ki jih je mogoče izvesti na produkcijskem HMI, število aktivnih zunanjih povezav, število privilegiranih računov ter obseg dogodkov, zajetih v revizijski sledi. Tak pregled pozneje uredi beleženje dogodkov, nadzor sprememb parametrov in pravila oddaljenega dostopa.

Posebno obravnavo zahteva alarmiranje. Na tem področju navidezna popolnost pogosto prikriva dejansko pomanjkanje nadzora. Slabo zasnovani alarmi in zgodovina dogodkov operaterja ne le preobremenijo, ampak mu tudi odvzamejo sposobnost razlikovanja med kritičnimi signali in tehničnim šumom. Če je alarm mogoče brez utemeljitve preprosto utišati, potrditi brez povezave z vzrokom ali ga izgubiti v množici diagnostičnih sporočil, aplikacija preneha podpirati varnost procesa. Zato morajo prioritete alarmov izhajati iz dejanskih posledic za ljudi, stroj in kakovost proizvodnje ter ostati povezane s pravili beleženja potrditev, obidov in sprememb nastavitev. Prav v tem trenutku analiza tveganja preneha biti formalni dokument in začne oblikovati vmesnik.

Kako načrtovati, da omejimo posledice napake in zlorabe

Izhodišče je preprosto: aplikacija HMI/SCADA ne sme predpostavljati, da vsak uporabnik vedno ravna pravilno in v pravem kontekstu procesa. Projekt je treba začeti z ločevanjem funkcij, ne z risanjem zaslonov. Ekipa mora najprej določiti, kaj operater sme samo videti, kaj lahko potrdi, kaj sme spremeniti v običajnem poteku dela in katera dejanja je treba prenesti v servisni način, zanje zahtevati dodatno avtorizacijo ali jih v celoti ločiti v samostojno orodje ali postajo.

Takšna odločitev uredi celotno arhitekturo dostopa: vloge, obseg pravic, način beleženja dejanj in pogoje oddaljene podpore. V praksi se dobro obnese matrika vlog, ki temelji na dejanskih zadolžitvah in razlikuje med operaterjem, vodjo izmene, vzdrževanjem, tehnologom, integratorjem in administratorjem. To ni formalnost. Če servisne funkcije ostanejo na istem zaslonu in pod istim računom kot upravljanje procesa, aplikacija sama ustvari pot do pomote, obida postopka ali zlorabe pravic.

Dober HMI/SCADA omejuje možnost, da bi se nevarna operacija izvedla po naključju, vendar po nepotrebnem ne upočasnjuje rutinskih opravil. To zahteva jasen delovni kontekst: uporabnik mora videti, na katerem objektu dela, v kakšnem stanju je proces, ali deluje lokalno ali na daljavo ter ali je sistem v samodejnem, ročnem ali servisnem načinu. Potrditve morajo biti sorazmerne s tveganjem, ne pa enake za vsa dejanja. Kjer je posledica napake reverzibilna in omejena, običajno zadostuje enkratna avtorizacija. Kritične operacije zahtevajo dodatni nadzor: drugo potrditev, ponovno preverjanje istovetnosti, odvisnost od stanja procesa ali fizični prehod na ločen vmesnik.

Pomembne so tudi pogojne blokade. Če aplikacija dopušča spremembo nastavitve, vsilitev signala ali prehod v ročni način ne glede na stanje objekta, se tveganje prenese z zasnove na operaterja. Prav tu se pokaže, da pravilno načrtovanje vmesnika ni zgolj vprašanje udobja pri uporabi, temveč omejevanja posledic napake z vgrajenimi pregradami. V številnih primerih je tak način razmišljanja blizu temu, kako deluje Poka-Yoke v proizvodnih linijah.

Večnivojsko načrtovanje dostopa mora zajemati tudi način časovne uporabe pravic. Posamezniški računi so nujni povsod, kjer se pričakuje sledljivost dejanj. Skupni račun onemogoča ugotovitev, kdo je odločitev dejansko sprejel. Najmanjši obseg pravic pomeni, da uporabnik dobi samo tiste funkcije, ki jih potrebuje za tekoče delo, povišanje pravic pa se izvede začasno in pod nadzorovanimi pogoji. To še posebej velja za vzdrževanje, integratorja in oddaljeno podporo proizvajalca. Stalna, odprta servisna pot je le navidezno priročna, saj odpravlja naravno mejo zaupanja med obratovanjem in servisom. Varnejši model je dostop, ki se aktivira na zahtevo, je časovno omejen, dodeljen konkretni osebi in zabeležen v zgodovini dogodkov. Tak pristop se dobro ujema z načelom najmanjših pravic in segmentacijo dostopa.

V istem duhu je treba odločiti, ali naj bodo servisne funkcije dostopne na delovnem HMI ali izključno z ločene postaje, ter ali dovoliti izmenljive nosilce in lokalni uvoz ali izvoz podatkov z operaterskega panela. Te odločitve niso postranske. Od njih je odvisno, ali bo vzdrževanje sistema potekalo nadzorovano ali prek priložnostnih obvodov.

Z vidika incidenta ali obratovalnega spora sam vmesnik ne zadostuje. Aplikacija mora pustiti gradivo, ki omogoča rekonstrukcijo poteka odločanja. Zgodovina dogodkov, sistemski dnevniki in beleženje sprememb morajo skupaj odgovoriti ne le na vprašanje, kaj se je zgodilo, temveč tudi kdo, kdaj, s katerega mesta in v kakšnem stanju procesa je izvedel operacijo. Najmanjši nabor dogodkov, ki jih je praviloma smiselno beležiti, vključuje prijavo, spremembo pravic, spremembo parametrov, prehod v ročni način, potrditev alarma ter uvoz konfiguracije. Ključno je, da je zapis povezan s tehnološkim kontekstom, saj je sama informacija o spremembi brez stanja objekta lahko neuporabna.

Dober primer je značilen za številne uvedbe: sprememba alarmnega praga, ki jo izvede tehnolog, je lahko dopustna, vendar le po prehodu v predvideni način, z zabeleženim uporabnikom, postajo, časom, prejšnjo in novo vrednostjo ter potrditvijo, da objekt ni bil v kritičnem stanju. Takšna sled je pomembna tako za varnost kot za upravljanje sprememb v industrijskih aplikacijah.

Zadnja plast je vzdrževanje brez obhajanja zaščit. Če posodobitev, obnova konfiguracije ali diagnostika zahtevajo izklop nadzora dostopa, uporabo skupnega gesla ali delo brez revizijske sledi, je težava v zasnovi, ne pa v disciplini osebja. Aplikacija mora imeti predviden potek spremembe: zahtevek, oceno vpliva, preskus, uvedbo, potrditev in načrt povrnitve. Poleg tega mora ločevati delovno in servisno okolje vsaj logično, kjer je to utemeljeno, pa tudi organizacijsko in tehnično. Izdelava in obnova kopij konfiguracije morata biti mogoči na nadzorovan način, brez priložnostnega izvoza »za vsak primer« z operaterskega panela. Tak pristop je skladen z načelom najmanjših pravic v OT ter z zahtevami glede nadzora dostopa, sledljivosti dejanj in upravljanja sprememb, pri čemer je njihov obseg vedno treba presojati glede na arhitekturo sistema in sprejeto delitev odgovornosti.

Praksa uvedbe in navezava na zahteve

Največ koristi ne prinese dodajanje novih zaščitnih mehanizmov na koncu projekta, temveč urejen pregled aplikacije pred prevzemom ali posodobitvijo. To je trenutek, ko je način delovanja sistema še mogoče razmeroma poceni popraviti, namesto da bi se napačne predpostavke pozneje obdajalo z dodatnimi postopki. Tak pregled mora izvesti mešana ekipa: projekt, vzdrževanje, obratovanje, avtomatik in osebe, odgovorne za varnost.

Predmet presoje ni samo tehnična konfiguracija, temveč tudi to, ali aplikacija dejansko ločuje vloge, varuje kritične operacije, omejuje oddaljeni dostop na utemeljene primere, zagotavlja jasno obravnavo alarmov, ohranja zgodovino sprememb ter omogoča izdelavo kopij in izvedbo izrednih postopkov brez obhajanja zaščit. Prav iz takšnega pregleda mora izhajati seznam za FAT/SAT ter zahteve, vključene v prevzem, servisni načrt in izvedbeno dokumentacijo.

Ta pristop težišče premakne z razprave o samih zaščitah na projektne odločitve, ki pozneje določajo ravnanje ljudi in naprav. Če že v fazi načrtovanja ni določeno, kdo lahko spreminja parametre receptur, kdo odobri servisni način, kako se evidentira poseg integratorja in pod kakšnimi pogoji je dopusten dostop zunaj obrata, bo sistem po zagonu temeljil na izjemah in ustnih dogovorih.

Iz istega razloga je smiselno odločiti, ali naj se ocena aplikacije izvede v okviru posodobitve stroja ali linije oziroma kot ločen pregled OT. Prvi pristop bolje poveže varnost s funkcijo procesa, drugi pa olajša prepoznavanje odvisnosti med sistemi ter razmejitev odgovornosti za račune, pravice dostopa in beleženje dejavnosti. To je tudi naravno mesto za začetno analizo tveganja: prepoznavanje kritičnih operacij, meja zaupanja ter posledic napake operaterja ali zlorabe. V praksi je pri tem lahko koristna tudi analiza tveganja v projektu.

• vloge uporabnikov in način prijave,
• kritične operacije in pravila njihove potrditve,
• oddaljeni dostop in servisne funkcije,
• alarmiranje, beleženje sprememb in sledljivost dejanj,
• varnostne kopije, obnova in postopki za izredne razmere.

Dober rezultat v obratu je le redko posledica hkratne uvedbe številnih orodij. Običajno je pomembneje odpraviti nekaj sistemskih tveganj, ki so dolga leta veljala za praktična. Posodobitev aplikacije HMI/SCADA se lahko začne z ukinitvijo skupnih računov, ločitvijo servisnih funkcij od operaterskih, omejitvijo zunanjih povezav na nadzorovane poti ter uvedbo sledi sprememb parametrov z dodelitvijo konkretni osebi ali vlogi. Takšna sprememba ne rabi poslabšati dela vzdrževanja ali integratorja, če so bili od začetka predvideni servisni način, pravila avtorizacije in ponovljiv potek sprememb.

V obratovanju je nato smiselno meriti ne abstraktne ravni varnosti, temveč operativno uporabne kazalnike: število skupnih računov, ki so še vedno v sistemu, obseg aktivnega oddaljenega dostopa, popolnost evidenc sprememb, čas obnove konfiguracije ter število posegov, izvedenih zunaj formalnega postopka. Takšni kazalniki omogočajo oceno, ali je projekt tveganje dejansko zmanjšal ali ga je le prenesel v vsakodnevno prakso.

V poljskih in evropskih razmerah je vse teže zagovarjati pristop, po katerem je kibernetska varnost HMI/SCADA izključno stvar oddelka IT. Odgovornost je porazdeljena med projektiranje, obratovanje, vzdrževanje, dobavitelje in integratorje, zahteve panoge ter pogodbene zahteve pa dobijo pomen šele takrat, ko organizacija zna pokazati konkretne odgovore: katere projektne odločitve so bile sprejete, kako se dodeljujejo pravice, kakšna je sled dejavnosti in kdo nadzira spremembe. Samo sklicevanje na standarde, politike ali pogodbena določila ne more nadomestiti dokaza, da je bila aplikacija načrtovana in prevzeta na način, ki omogoča varno obratovanje.

Najpomembnejši sklep je praktičen. Najcenejši in najučinkovitejši trenutek za omejevanje tveganja ostajata načrtovanje in prevzem aplikacije. Takrat je mogoče z najmanjšimi stroški določiti meje zaupanja, vloge, pogoje dostopa, sled dejavnosti in način izvajanja sprememb. Če se te zahteve prevedejo v preverljiva merila za dobavitelja in integratorja, HMI/SCADA preneha biti priročen, vendar preveč zaupljiv vmesnik, in postane orodje za varno obratovanje procesa.