Galvenie secinājumi:
- Šajā rakstā aplūkoti galvenie drošības aspekti.
Par HMI/SCADA lietotņu drošību izšķiras daudz agrāk nekā aizsardzības mehānismu izvēles posmā. Tas, vai sistēma būs noturīga pret kļūdu, ļaunprātīgu izmantošanu un nekontrolētu procesa stāvokļa maiņu, galvenokārt ir atkarīgs no projektā pieņemtajiem pamatprincipiem: lomu sadalījuma, uzticēšanās robežām, no saskarnes pieejamo funkciju apjoma, kā arī servisa un attālinātās piekļuves organizēšanas veida. Ja šie jautājumi tiek atstāti otrajā plānā, lietotne sāk nostiprināt risku, nevis to mazināt. Tāpēc HMI/SCADA projektēšana, domājot par kiberdrošību, jāveic kā inženiertehnisks uzdevums: vispirms jānosaka, kuras darbības ir kritiskas, kādas sekas tās var radīt un kam patiesībā būtu jāspēj tās veikt, un tikai pēc tam jāveido ekrāni, trauksmes un lietošanas ērtums.
Kiberdrošība sākas projektā
HMI/SCADA sistēmās kiberdrošība nav papildinājums jau gatavai vizualizācijai. Tā izriet no agrāk pieņemtiem lēmumiem: no lietotnes arhitektūras, piekļuves tiesību modeļa, saziņas veida ar vadības sistēmu un servisa pieņēmumiem. Tas ir īpaši svarīgi, jo HMI/SCADA lietotne vienlaikus ir saskares punkts starp cilvēku, procesu un infrastruktūru. Tāpēc projektēšanas kļūda nebeidzas tikai ar IT risku. Tā vienlaikus var ietekmēt operatora reakcijas gaitu, funkcionālo drošību, operacionālo risku un ražošanas nepārtrauktību.
No projekta skatpunkta pamatjautājums nav, kādu aizsardzības līdzekli pievienot beigās, bet gan kuri lēmumi jau pašā sākumā samazinās uzbrukuma virsmu. Lielākās problēmas parasti neizriet no viena atsevišķa mehānisma trūkuma, bet no pārmērīgas uzticēšanās, kas iestrādāta lietotnē. Praksē tas nozīmē kopīgus lietotāju kontus, plašu un pastāvīgu servisa piekļuvi, lomu nošķīruma trūkumu starp operatoru, tehnisko uzturēšanu un integratoru, kā arī pārāk brīvu saziņu starp operatora slāni un vadības sistēmu. Nodošanas ekspluatācijā posmā šādi risinājumi šķiet ērti, jo paātrina darbus un atvieglo diagnostiku. Vēlāk tie kļūst par pastāvīgu vides iezīmi un palielina ļaunprātīgas izmantošanas, kļūdas vai nekontrolētas procesa stāvokļa maiņas risku.
Tāpēc pirms ekrānu projektēšanas ir vērts noteikt ne tikai to, ko lietotājam jāredz, bet galvenokārt arī to, kur atrodas uzticēšanās robežas, kuras darbības ir kritiskas un kuros punktos saskarne var kļūt par kļūdas vai procedūras apiešanas rīku. Šāda secība sakārto turpmākos lēmumus: vai HMI jābūt tikai vizualizācijas slānim vai arī konfigurēšanas, diagnostikas un recepšu maiņas vietai; vai servisa funkcijām jādarbojas pastāvīgi vai tikai pēc apzinātas aktivizēšanas; vai operatoram jābūt piekļuvei tikai procesa vadīšanai vai arī darbībām, kas maina parametrus un datu vēsturi.
Nepilnību praktiskās izmaksas parasti atklājas tikai tad, kad lietotne jau ir sasaistīta ar receptēm, trauksmēm, atskaišu veidošanu, arhivēšanu un tehniskās uzturēšanas procedūrām. Tad pat šķietami vienkārša korekcija, piemēram, kontu nodalīšana, kritiskas darbības apstiprināšanas ceļa maiņa vai attālinātās piekļuves ierobežošana līdz neregulāram režīmam, vairs nav tikai izmaiņas ekrānos. Tā prasa loģikas pārbūvi, atkārtotu trauksmju apstrādes pārbaudi, atbildību noteikšanu un bieži arī organizatoriskas izmaiņas uzņēmumā.
Praksē visracionālākais sākumpunkts ir darba karte ar lietotāju lomām un to tiesībām veikt kritiskās darbības, to funkciju saraksts, kas izraisa procesa stāvokļa, konfigurācijas vai recepšu maiņu, kā arī ārējo savienojumu pārskats, kas aptver servisu, atskaišu veidošanu, virsvadības sistēmas un attālināto piekļuvi. Tikai uz šī pamata var jēgpilni projektēt zonu un savienojumu arhitektūru un sagatavot turpmāko riska analīzi. Šāda pieeja atbilst gan inženierpraksei, gan prasībām sakārtot atbildību, nodalīt funkcijas un kontrolēt komunikāciju rūpnieciskajā vidē.
Kur patiesībā pieaug izmaksas un risks
Lielākās izmaksas un risks HMI/SCADA lietotnē neizriet tikai no paša sistēmu savienojuma fakta, bet no tā, kādas procesa un organizatoriskās sekas rada atsevišķās lietotnes funkcijas. Visjutīgākās ir tās vietas, kas ļauj ātri mainīt iestatījumus, ieviest apiešanu, apklusināt trauksmi, mainīt recepti vai veikt manuālu vadību bez pilna tehnoloģiskā konteksta. Ja projekts pieļauj šādas darbības no ražošanas ekrāna ikdienas režīmā, risks pieaug tāpēc, ka viens lietotāja lēmums vai viena pārņemta sesija var tieši mainīt procesa stāvokli.
Tas nozīmē, ka kritisko operāciju katalogs jāuztver kā drošības arhitektūras elements, nevis tikai kā interfeisa ergonomikas jautājums. Tas pats attiecas arī uz darbību atbildības izsekojamību. Kopīgi lietotājvārdi, maiņas koplietoti konti, nepietiekama tiesību nodalīšana starp skatīšanu, vadību, konfigurēšanu un administrēšanu, kā arī nepilnīga notikumu reģistrēšana rada situāciju, kurā pēc incidenta ir grūti ticami noteikt, vai notikusi kļūda, procedūras apiešana, servisa piekļuves ļaunprātīga izmantošana vai neatļauta darbība. Problēma neaprobežojas tikai ar cēloņu izmeklēšanu. Bez uzticamas lietotāja darbību pēdas nav iespējams arī novērtēt procedūru efektivitāti, jēgpilni pārvaldīt piekļuves tiesības vai pamatot ekspluatācijas lēmumus iekšējā audita, klienta prasību vai pieņemto drošības politiku priekšā. Praksē šeit runa ir par darbību atbildības izsekojamību un identificējamības ķēdi, nevis tikai par pašu notikumu pierakstu.
Ļoti dārga projektēšanas kļūda ir arī plašu servisa un diagnostikas ekrānu pārcelšana uz ražošanas vidi, ja tie sākotnēji sagatavoti palaišanas darbiem vai integratora atbalstam. Šādi skati bieži nodrošina plašu piekļuvi iekšējiem mainīgajiem, stāvokļu piespiedu iestatīšanai, bloķējumu atiestatīšanai un parametru maiņai, lai gan normālā ekspluatācijā tie ir vajadzīgi tikai atsevišķos gadījumos. Ja tiem netiek piemēroti papildu ierobežojumi, tie kļūst par īsāko ceļu iejaukšanās veikšanai procesā ārpus parastās operatora darbību plūsmas. Saprātīgs risinājums ir nodalīt diagnostiku, kas nepieciešama uzturēšanas dienestam, no funkcijām, kas ļauj iejaukties darbības loģikā, kā arī atsevišķi izlemt, vai iekārtas ražotāja diagnostikai jābūt pieejamai lokāli, attālināti vai tikai ar nosacījumiem — pēc apzinātas aktivizēšanas un ar pilnu sesijas ierakstu.
Līdzīgi jāvērtē arī integrācija ar datubāzēm, atskaišu veidošanu, attālināto atbalstu un biroja sistēmām. Katrs šāds savienojums uzlabo darba ērtumu, bet vienlaikus palielina atkarību skaitu, kas var kļūt par piekļuves ceļu, traucējumu avotu vai atbildības skaidrības zuduma cēloni. Starpniekpakalpojuma atteice, kļūdaina laika sinhronizācija, nekontrolēta datu apmaiņa ar virsvadības sistēmu vai atstāts servisa kanāls var ietekmēt ne tikai atskaišu pieejamību, bet arī operatora pieņemtos lēmumus.
Tāpēc jau projektēšanas posmā ir vērts mērīt ne tikai ekrānu pieejamību, bet arī vienkāršākus un lietderīgākus rādītājus: kritisko operāciju skaitu, ko iespējams veikt no ražošanas HMI līmeņa, aktīvo ārējo savienojumu skaitu, privileģēto kontu skaitu un to notikumu apjomu, uz kuriem attiecas audita pēda. Šāds pārskats vēlāk sakārto notikumu reģistrēšanu, parametru izmaiņu kontroli un attālinātās piekļuves noteikumus.
Atsevišķa pieeja nepieciešama trauksmju signalizācijai. Šajā jomā šķietama pilnība bieži maskē faktisku kontroles trūkumu. Slikti izstrādātas trauksmes un notikumu vēsture ne tikai pārslogo operatoru, bet arī atņem viņam spēju atšķirt kritiskus signālus no tehniska trokšņa. Ja trauksmi var viegli apklusināt bez pamatojuma, apstiprināt bez sasaistes ar cēloni vai pazaudēt diagnostisko paziņojumu masā, lietotne pārstāj atbalstīt procesa drošību. Tāpēc trauksmju prioritātēm jāizriet no reālajām sekām cilvēkiem, iekārtai un ražošanas kvalitātei, un tām jāpaliek saistītām ar apstiprinājumu, apiešanu un iestatījumu izmaiņu reģistrēšanas principiem. Tieši šajā brīdī riska analīze pārstāj būt formāls dokuments un sāk veidot interfeisu.
Kā projektēt, lai ierobežotu kļūdu un ļaunprātīgas izmantošanas sekas
Sākumpunkts ir vienkāršs: HMI/SCADA lietotne nedrīkst pieņemt, ka katrs lietotājs vienmēr rīkojas pareizi un atbilstošā procesa kontekstā. Projektēšana jāsāk ar funkciju nodalīšanu, nevis ar ekrānu zīmēšanu. Komandai vispirms jānosaka, ko operators drīkst tikai redzēt, ko viņš var apstiprināt, ko viņam atļauts mainīt parastajā darba gaitā un kuras darbības jāpārceļ uz servisa režīmu, jāpakļauj papildu autorizācijai vai pilnībā jānodala atsevišķā rīkā vai stacijā.
Šāds lēmums sakārto visu piekļuves arhitektūru: lomas, tiesību apjomu, darbību reģistrēšanas veidu un attālinātā atbalsta nosacījumus. Praksē labi darbojas lomu matrica, kas balstīta uz reālajiem pienākumiem un nošķir operatoru, maiņas vadītāju, uzturēšanas dienestu, tehnologu, integratoru un administratoru. Tā nav formalitāte. Ja servisa funkcijas paliek tajā pašā ekrānā un zem tā paša konta kā procesa vadība, lietotne pati rada ceļu kļūdai, procedūras apiešanai vai tiesību ļaunprātīgai izmantošanai.
Laba HMI/SCADA sistēma ierobežo iespēju nejauši veikt bīstamu operāciju, bet bez vajadzības nepalēnina rutīnas darbības. Tas prasa skaidru darba kontekstu: lietotājam jāredz, ar kuru objektu viņš strādā, kādā stāvoklī ir process, vai viņš darbojas lokāli vai attālināti, kā arī vai sistēma atrodas automātiskajā, manuālajā vai servisa režīmā. Apstiprinājumiem jābūt samērīgiem ar risku, nevis vienādiem visām darbībām. Tur, kur kļūdas sekas ir atgriezeniskas un ierobežotas, parasti pietiek ar vienu autorizāciju. Kritiskām operācijām nepieciešama papildu kontrole: otrs apstiprinājums, atkārtota autentifikācija, atkarība no procesa stāvokļa vai fiziska pāreja uz nodalītu interfeisu.
Svarīgas ir arī nosacījumu bloķēšanas. Ja lietotne pieļauj iestatījuma maiņu, signāla piespiedu aktivizēšanu vai pāreju manuālajā režīmā neatkarīgi no objekta stāvokļa, risks tiek pārcelts no projekta uz operatoru. Tieši šeit redzams, ka pareiza saskarnes projektēšana nav tikai lietošanas ērtums, bet gan kļūdu seku ierobežošana ar iebūvētām barjerām. Daudzos gadījumos šāds domāšanas veids ir tuvs tam, kā darbojas Poka-Yoke ražošanas līnijās.
Daudzslāņu piekļuves projektējumam jāaptver arī tas, kā tiesības tiek izmantotas laikā. Individuāli konti ir nepieciešami visur, kur tiek sagaidīta darbību izsekojamība. Koplietots konts atņem iespēju noteikt, kurš faktiski pieņēma lēmumu. Minimālais tiesību apjoms nozīmē, ka lietotājs saņem tikai tās funkcijas, kas viņam vajadzīgas ikdienas darbam, bet tiesību paaugstināšana notiek uz laiku un kontrolētos apstākļos. Tas īpaši attiecas uz tehnisko uzturēšanu, integratoru un ražotāja attālināto atbalstu. Pastāvīgi atvērts servisa piekļuves ceļš ir ērts tikai šķietami, jo tas nojauc dabisko uzticēšanās robežu starp ekspluatāciju un servisu. Drošāks modelis ir piekļuve pēc pieprasījuma, ar laika ierobežojumu, piesaistīta konkrētai personai un fiksēta notikumu vēsturē. Šī pieeja labi atbilst minimālo tiesību principam un piekļuves segmentēšanai.
Tādā pašā garā jāizlemj, vai servisa funkcijām jābūt pieejamām no darba HMI līmeņa vai tikai no atsevišķas stacijas, kā arī vai atļaut noņemamos datu nesējus un lokālu datu importu vai eksportu no operatora paneļa. Šie lēmumi nav otršķirīgi. No tiem ir atkarīgs, vai sistēmas uzturamība tiks nodrošināta kontrolēti vai arī ar pagaidu apiešanas risinājumiem.
No incidenta vai ekspluatācijas strīda skatpunkta ar pašu saskarni nepietiek. Lietotnei jāatstāj materiāls, kas ļauj atjaunot pieņemto lēmumu gaitu. Notikumu vēsturei, sistēmas žurnāliem un izmaiņu reģistrēšanai kopā jāatbild ne tikai uz jautājumu, kas notika, bet arī kurš, kad, no kuras vietas un kādā procesa stāvoklī veica konkrēto darbību. Minimālais notikumu apjoms, ko parasti ir vērts reģistrēt, ietver pieteikšanos sistēmā, tiesību maiņu, parametru maiņu, pāreju manuālajā režīmā, trauksmes apstiprināšanu un konfigurācijas importu. Izšķiroši svarīgi ir sasaistīt ierakstu ar tehnoloģisko kontekstu, jo pati informācija par izmaiņu bez objekta stāvokļa nereti ir bezjēdzīga.
Labs piemērs ir raksturīgs daudzām ieviešanām: trauksmes sliekšņa maiņa, ko veic tehnologs, var būt pieļaujama, bet tikai pēc pārejas paredzētajā režīmā, fiksējot lietotāju, staciju, laiku, iepriekšējo un jauno vērtību, kā arī apstiprinājumu, ka objekts neatradās kritiskā stāvoklī. Šādai pēdai ir nozīme gan drošībai, gan izmaiņu pārvaldībai rūpnieciskajās lietotnēs.
Pēdējais slānis ir uzturamība bez aizsardzības mehānismu apiešanas. Ja atjaunināšanai, konfigurācijas atjaunošanai vai diagnostikai ir jāatslēdz piekļuves kontrole, jāizmanto kopīga parole vai jāstrādā bez audita pēdas, problēma ir projektā, nevis personāla disciplīnā. Lietotnei jābūt paredzētai izmaiņu gaitai: pieprasījums, ietekmes novērtējums, tests, ieviešana, apstiprinājums un atcelšanas plāns. Tai arī jānodala darba vide no servisa vides vismaz loģiski, bet tur, kur tas ir pamatoti, arī organizatoriski un tehniski. Konfigurācijas kopijām jābūt izveidojamām un atjaunojamām kontrolētā veidā, bez pagaidu eksporta „katram gadījumam” no paneļa līmeņa. Šāda pieeja ir saskanīga ar minimālo tiesību principu OT vidē, kā arī ar prasībām attiecībā uz piekļuves kontroli, darbību izsekojamību un izmaiņu pārvaldību, turklāt to apjoms vienmēr jāattiecina uz sistēmas arhitektūru un pieņemto atbildības sadalījumu.
Ieviešanas prakse un atsauce uz prasībām
Vislielāko ieguvumu dod nevis papildu aizsardzības mehānismu pievienošana projekta beigās, bet gan sakārtota lietotnes pārskatīšana pirms pieņemšanas vai modernizācijas. Tas ir brīdis, kad sistēmas darbības veidu vēl var salīdzinoši lēti koriģēt, nevis vēlāk apbūvēt kļūdainus pieņēmumus ar papildu procedūrām. Šādu pārskatu būtu jāveic jauktai komandai: projekts, tehniskā uzturēšana, ekspluatācija, automātikas speciālists un par drošību atbildīgās personas.
Novērtējuma priekšmets nav tikai tehniskā konfigurācija, bet arī tas, vai lietotne patiešām nodala lomas, aizsargā kritiskās operācijas, ierobežo attālināto piekļuvi līdz pamatotiem gadījumiem, nodrošina skaidru trauksmju apstrādi, saglabā izmaiņu vēsturi un ļauj veikt kopijas un avārijas procedūras, neapejot aizsardzības mehānismus. Tieši no šāda pārskata būtu jāizriet sarakstam FAT/SAT, kā arī prasībām, kas tiek iekļautas pieņemšanā, servisa plānā un izpilddokumentācijā.
Šī pieeja pārvieto uzmanības centru no diskusijām par pašiem aizsardzības līdzekļiem uz projektēšanas lēmumiem, kas vēlāk nosaka cilvēku un iekārtu rīcību. Ja jau projektēšanas posmā nav noteikts, kurš drīkst mainīt recepšu parametrus, kurš apstiprina servisa režīmu, kā tiek fiksēta integratora iejaukšanās un kādos apstākļos ir pieļaujama piekļuve ārpus uzņēmuma, tad pēc sistēmas palaišanas tā balstīsies uz izņēmumiem un mutiskām vienošanām.
Tā paša iemesla dēļ ir vērts izlemt, vai lietojumprogrammas novērtēšanu veikt mašīnas vai līnijas modernizācijas ietvaros, vai kā atsevišķu OT pārskatu. Pirmā pieeja labāk sasaista drošību ar procesa funkciju, otrā atvieglo atkarību starp sistēmām un atbildības sadalījuma noteikšanu par kontiem, piekļuves tiesībām un darbību reģistrēšanu. Tā ir arī dabiska vieta sākotnējai riska analīzei: kritisko operāciju identificēšanai, uzticamības robežu noteikšanai un operatora kļūdas vai ļaunprātīgas izmantošanas seku izvērtēšanai. Praksē šeit noderīga mēdz būt arī riska analīze projektā.
- lietotāju lomas un pieteikšanās kārtība,
- kritiskās operācijas un to apstiprināšanas noteikumi,
- attālinātā piekļuve un servisa funkcijas,
- trauksmes, izmaiņu reģistrēšana un darbību izsekojamība,
- rezerves kopijas, atjaunošana un avārijas procedūras.
Labs rezultāts uzņēmumā reti ir daudzu rīku vienlaicīgas ieviešanas sekas. Parasti lielāka nozīme ir dažu sistēmisku risku novēršanai, kas gadiem ilgi tika uzskatīti par praktiskiem. HMI/SCADA lietojumprogrammas modernizācija var sākties ar koplietojamu kontu likvidēšanu, servisa funkciju nodalīšanu no operatora funkcijām, ārējo savienojumu ierobežošanu līdz kontrolētiem ceļiem un parametru izmaiņu uzskaites ieviešanu, piesaistot tās konkrētai personai vai lomai. Šādām izmaiņām nav obligāti jāpasliktina ekspluatācijas uzturēšanas dienesta vai integratora darbs, ja jau no paša sākuma ir paredzēts servisa režīms, autorizācijas noteikumi un atkārtojama izmaiņu veikšanas kārtība.
Pēc tam ekspluatācijas laikā ir vērts mērīt nevis abstraktu drošības līmeni, bet operatīvi noderīgus rādītājus: sistēmā vēl palikušo koplietojamo kontu skaitu, aktīvās attālinātās piekļuves apjomu, izmaiņu reģistru pilnīgumu, konfigurācijas atjaunošanas laiku un ārpus formālās procedūras veikto iejaukšanos skaitu. Šādi rādītāji ļauj novērtēt, vai projekts patiešām ir samazinājis risku vai tikai pārcēlis to uz ikdienas praksi.
Polijas un Eiropas Savienības apstākļos arvien grūtāk ir pamatot pieeju, kurā HMI/SCADA kiberdrošība ir tikai IT nodaļas jautājums. Atbildība ir sadalīta starp projektēšanu, ekspluatāciju, ekspluatācijas uzturēšanu, piegādātājiem un integratoriem, un nozares vai līgumiskās prasības iegūst nozīmi tikai tad, ja organizācija spēj parādīt konkrētus risinājumus: kādi projektēšanas lēmumi pieņemti, kā tiek piešķirtas piekļuves tiesības, kāda ir darbību izsekojamība un kurš kontrolē izmaiņas. Atsauces vien uz standartiem, politikām vai līguma noteikumiem neaizstās pierādījumu, ka lietojumprogramma ir projektēta un pieņemta tā, lai nodrošinātu drošu ekspluatāciju.
Svarīgākais secinājums ir praktisks. Lētākais un efektīvākais brīdis riska mazināšanai joprojām ir lietojumprogrammas projektēšana un pieņemšana. Tieši tad ar vismazākajām izmaksām tiek noteiktas uzticamības robežas, lomas, piekļuves nosacījumi, darbību izsekojamība un izmaiņu pārvaldības kārtība. Ja šīs prasības tiek pārvērstas pārbaudāmos kritērijos attiecībā uz piegādātāju un integratoru, HMI/SCADA vairs nav ērta, bet pārlieku uzticīga saskarne, bet kļūst par drošas procesa ekspluatācijas rīku.
HMI/SCADA lietotņu projektēšana, domājot par kiberdrošību – BUJ
Jau projektēšanas posmā, nevis tikai aizsardzības līdzekļu izvēles laikā. Izšķiroši ir agrīni lēmumi par arhitektūru, lomām, uzticības robežām un piekļuvi kritiski svarīgām funkcijām.
Īpaši riskantas ir darbības, kas maina procesa stāvokli, iestatījumus, receptūras, trauksmes signālus vai manuālos režīmus. Ja tās ir rutīnā pieejamas no ražošanas ekrāna, palielinās kļūdu, ļaunprātīgas izmantošanas vai nekontrolētas procesa stāvokļa maiņas risks.
Tie apgrūtina darbību izsekojamību un incidenta cēloņu noteikšanu. Ja tiesības nav nodalītas un nav uzticama darbību reģistra, ir grūti izvērtēt, vai notikusi kļūda, procedūras apiešana vai neatļauta rīcība.
Tām nevajadzētu būt pastāvīgi pieejamām bez papildu ierobežojumiem. Ir lietderīgi nodalīt diagnostiku no funkcijām, kas iejaucas darbības loģikā, un servisa piekļuvi aktivizēt apzināti, nosacīti un ar pilnu sesijas ierakstu.
Labs sākumpunkts ir lomu un piekļuves tiesību karte, kritisko darbību saraksts un ārējo savienojumu pārskats, tostarp servisa un attālinātās piekļuves savienojumi. Tikai uz šāda pamata ir vērts projektēt zonu un savienojumu arhitektūru un vēlāk veikt riska analīzi.