CRA mašīnu ražotājiem pēc Komisijas 2026. gada 27. jūlija vadlīnijām. Kas patiesībā ir jāievieš?

Ilgus gadus iekārtas kiberdrošību varēja aprakstīt trīs soļos: pazīstama zīmola kontrolieris, VPN “jo tā dara” un klasiskais “klients pats nodrošinās tīklu”. Ja vēl kāds vadības skapī ielika ugunsmūri, tēmu nereti uzskatīja par slēgtu — vismaz līdz brīdim, kad kāds mēģināja pārbaudīt, kas notiek reāla uzbrukuma gadījumā, nevis prezentācijā.

Tomēr kiberdrošība neplūst pa PROFINET. Komponentiem var būt sertifikāti, deklarācijas un mārketinga bukletā ieraksts “secure by design”, taču iekārta kopumā joprojām var būt paredzama tādā veidā, kam ar drošumu nav nekāda sakara. Tāpat kā drošības relejs pats par sevi nepadara sistēmu drošu, ja vadības loģika ļauj to apiet, arī “drošs” HMI neatrisina arhitektūras, integrācijas, piekļuves tiesību, atjauninājumu un tā, kas notiek, kad kāds pārstāj prasīt atļauju, problēmu.

CRA (Cyber Resilience Act, Eiropas Parlamenta un Padomes Regula (ES) 2024/2847) nav IT pielikums. Tā ir produktu regula, kas ienāk iekārtas dzīves ciklā, neprasot atļauju automatizācijas nodaļai. Tā aptver vadības sistēmas projektēšanu, riska analīzi, piegādes ķēdi, konfigurāciju, atjauninājumus, kā arī produkta uzturēšanu vēl ilgi pēc tam, kad FAT ir parakstīts un iekārta ir atstājusi ražošanas halli. Un nē, arguments “mēs to internetam nepieslēdzam” šo jautājumu neatrisina. Praksē pietiek ar servisa klēpjdatoru, USB datu nesēju, attālinātu diagnostiku “uz brīdi” vai integrāciju ar rūpnīcas sistēmu, lai robeža starp izolāciju un ekspozīciju vienkārši izzustu.

Komisijas 2026. gada 27. jūlija vadlīnijas pašu regulu nemainīja, taču tās būtiski sašaurināja interpretācijas telpu, kas iepriekš ļāva kiberdrošību uztvert kā izvēles slāni. Tika precizēta, cita starpā, produkta robeža, attālinātās apstrādes loma, atbildība par izmaiņām pēc piegādes, kā arī tas, ka pieņēmums “pēc FAT tā vairs nav mūsu problēma” vairs nav drošs.

Tomēr svarīgākā izmaiņa ir vēl fundamentālāka: kiberuzbrukums vairs nav tikai IT notikums, bet kļūst par scenāriju, kas ietekmē iekārtas funkcionālo drošību. Ja neatļauta programmas maiņa var izraisīt ass kustību, bloķēšanas apiešanu, procesa parametru izmaiņas vai drošības funkcijas zudumu, tad mēs vairs nerunājam par “tīkla incidentu”. Mēs runājam par potenciāli nekontrolētu iekārtas uzvedību — neatkarīgi no tā, vai cēlonis bija konfigurācijas kļūda, programmatūras ievainojamība vai apzināta iejaukšanās.

Šajā kontekstā vienreizējs pentests pirms FAT vairs nav atbilstības pierādījums, bet tikai sistēmas stāvokļa momentuzņēmums konkrētā brīdī. CRA prasa nepārtrauktu pieeju: no projektēšanas, caur ražošanu un palaišanu, līdz atjauninājumiem, ievainojamību pārvaldībai, reaģēšanai uz incidentiem un uzturēšanai deklarētajā atbalsta periodā.

Praksē tas nozīmē atteikšanos no domāšanas “izdarīts = droši” par labu pieejai “uzturēts = kontrolēts”. Bez ilūzijām, ka ugunsmūris skapī, VPN un komponenta sertifikāts šo jautājumu atrisina. Un bez pieņēmuma, ka kiberdrošība beidzas brīdī, kad ir parakstīts pieņemšanas protokols.

Šajā rakstā aplūkojam, ko CRA vadlīnijas 2026–2027 un praktiska produkta sagatavošana reāli maina iekārtu ražotājiem, integratoriem un modernizētājiem — nesamazinot visu tēmu līdz lozungam “nomainīsim paroli un pieliksim cybersecurity ķeksīti”.

1. Lai iekārta neietilptu CRA tvērumā, tai būtu jābūt gandrīz tikai uz kontaktoriem

Daudzos projektos CRA tvērumu pārbauda ar vienu jautājumu:

Vai iekārta būs pieslēgta internetam?

Nebūs.

Tātad jautājums ir slēgts.

Shēmā ir PLC, HMI, vairākas piedziņas, decentralizētas ieejas un izejas, vārstu sala, drošības skeneris un ports programmas ielādei. Kontrolieris sazinās ar paneli pa PROFINET, ar piedziņām apmainās ar vadības un statusa vārdiem, bet sensori nodod datus pa IO-Link.

Taču maršrutētāja ar SIM karti nav.

Kā zināms, dati kļūst par datiem tikai tad, kad tie atstāj ražošanas halli.

Tomēr CRA nejautā, vai iekārtai ir piekļuve internetam.

Tas jautā, vai tās paredzētais lietojums vai saprātīgi paredzama izmantošana ietver tiešu vai netiešu, loģisku vai fizisku datu savienojumu ar ierīci vai tīklu. Tam nav jābūt savienojumam ar mākoni, ražotāja serveri vai publisko internetu. Tas var notikt pa kabeli, ar radioviļņu starpniecību, caur programmatūras interfeisu vai kā daļa no lielākas sistēmas.

Un te ir galvenais jautājums: kas tipiskā iekārtā patiesībā pārraida datus?

Vai HMI nolasa stāvokļus no PLC un ieraksta iestatījumus?

Vai PLC sūta piedziņai vadības vārdu un pretī saņem ātrumu, statusu un kļūdas kodu?

Vai ieeju un izeju sala pārraida procesa attēlu?

Vai IO-Link sensors sūta mērījuma vērtību, ierīces identifikatoru un diagnostikas datus?

Vai safety PLC sazinās ar moduļiem pa PROFIsafe?

Vai programma, aparatūras konfigurācija vai aparātprogrammatūra tiek ielādēta no servisa klēpjdatora?

Vai receptes, atskaites vai atjauninājumus var pārsūtīt ar USB?

Ja atbilde kaut vienu reizi ir “jā”, tad, visticamāk, mums ir darīšana ar datu savienojumu.

Un to nemaina fakts, ka:

• iekārta darbojas lokālajā tīklā,
• tai nav publiskas IP adreses,
• Ethernet ports tiek izmantots tikai palaišanas laikā,
• klēpjdatoru pieslēdz tikai serviss,
• saziņa notiek tikai vadības sistēmas iekšienē,
• klients ir apsolījis, ka iekārta nekad netiks pieslēgta internetam.

CRA attiecas ne tikai uz lietošanu, kas instrukcijā aprakstīta kā pamatlietojums, bet arī uz saprātīgi paredzamu lietošanu. Tāpēc servisa ports nepārstāj pārraidīt datus tikai tāpēc vien, ka shēmā pie tā ir pieraksts “SERVICE ONLY”.

Tomēr Komisijas 2026. gada 27. jūlija vadlīnijas ievieš būtisku nošķīrumu.

Ne katrs vads un ne katrs elektriskais signāls ir datu savienojums.

Ja signāls kalpo tikai noteiktas funkcijas ieslēgšanai, izslēgšanai vai barošanai un nepārraida digitāli kodētu informāciju, ar pašu divu elektrisko stāvokļu esamību vēl nepietiek, lai to atzītu par datu savienojumu.

Poga, kas padod spriegumu uz kontaktora spoli, nekļūst par digitālu interfeisu tikai tāpēc, ka tās stāvokli var aprakstīt kā nulle vai viens.

Līdzīgi arī klasisks gala slēdzis, kas iekļauts releju-kontaktoru ķēdē, var tikai pārtraukt vai noslēgt ķēdi. Tas nepārraida ierīces numuru, procesa vērtību, diagnostikas kodu, firmware versiju vai telegrammu, kurā ietvertas vairākas informācijas vienības.

Taču, ja tas pats stāvoklis nonāk viedā ierīcē, tiek kodēts, pārraidīts pa kopni, sasaistīts ar diagnostiku un saņēmēja interpretēts kā informācija, situācija jau ir cita.

Tātad robeža nav starp “online” un “offline” iekārtu.

Tā ir starp parastu vadības signālu un digitāli kodētas informācijas apmaiņu.

Tāpēc praksē iekārtai, kas paliktu ārpus CRA tvēruma tikai tāpēc, ka tai nav datu savienojuma, būtu vairāk jāatgādina klasiska shēma ar pogām, gala slēdžiem, relejiem un kontaktoriem, nevis mūsdienīgs projekts, kas tiek atvērts TIA Portal.

Tas, protams, nenozīmē likumā noteiktu izņēmumu kontaktoriem.

Var uzbūvēt vienkāršu iekārtu ar PLC, kas pēc detalizētas analīzes neatbildīs tvēruma kritērijam. Var arī kontaktoru shēmai pievienot digitālu regulatoru, servisa interfeisu vai komunikācijas moduli un nonākt tieši robežas otrajā pusē.

Komponenta nosaukums šo jautājumu neizšķir.

Izšķiroši ir tas, ko produkts faktiski dara un ar ko tas apmainās ar datiem.

Tāpēc, pirms atbildēt uz jautājumu, vai konkrētā iekārta ietilpst CRA tvērumā, ir jānosaka:

• kur atrodas vērtējamā produkta robeža,
• kādas ierīces un programmatūras elementi tajā ietilpst,
• kādi fiziskie un loģiskie interfeisi tam ir,
• kāda informācija pa tiem tiek pārraidīta,
• kuri savienojumi ir tieši, bet kuri notiek caur lielāku sistēmu,
• kuri no tiem pastāv normālas darbības, palaišanas, diagnostikas, atjaunināšanas vai servisa laikā,
• kādi lietošanas veidi ir saprātīgi paredzami, pat ja ražotājs labprātāk tos neparedzētu.

Kamēr uz šiem jautājumiem nav atbildēts, mēs nezinām, vai iekārta paliek ārpus CRA tvēruma.

Mums ir tikai ērts apgalvojums:

“Iekārta nav pieslēgta internetam”.

Taču tā ir atbilde uz jautājumu, ko CRA neuzdod.

PROFINET nav internets. Un CRA vajadzībām tam nemaz nav jābūt internetam.

2. Kiberdrošība neizplatās pa PROFINET

Daudzos projektos jautājums par iekārtas atbilstību sākas jau iepirkuma posmā.

PLC no atzīta ražotāja.
HMI ar aktuālu firmware.
Pārvaldāms switch.
Rūpnieciskais maršrutētājs ar VPN.
Piedziņas ar drošības funkcijām.
Safety PLC ar atbilstošu sertifikātu.

Katrai ierīcei ir atbilstības deklarācija, instrukcija un vairāki dokumenti ar vārdiem “secure”, “encrypted” un “defence in depth”.

Shēmā viss izskatās profesionāli.

Taču joprojām nav zināms, vai pilnā iekārta ir kiberdroša.

Jo kiberdrošība pa PROFINET “nepāriet”.

Tas ir mazliet kā ar durvju slēdzeni:
tev var būt ļoti laba slēdzene katrā telpā — sertificēta, testēta, ar lielisku dokumentāciju un “secure” hologrammu —, bet tas joprojām negarantē drošību, ja kāds ir atstājis ieejas durvis plaši vaļā, “jo tā palaišanas laikā bija ātrāk”.

Un tieši tāpat ir arī šeit: komponenti var būt paraugkārtībā, bet sistēma tik un tā var būt… radoši atvērta.

PLC “nenodod” drošību HMI.
Firewall “neizlabo” lietojumprogrammas loģiku.
Switch “nesakārto” lietotāju piekļuvi.
Un tas, ka katram elementam ir sertifikāts, vēl nenozīmē, ka visa iekārta nav viena liela, pieklājīgi dokumentēta ievainojamība.

PROFINET pārraida datus.

Tas nepārraida atbildību.
Un diemžēl tas nepārraida arī veselo saprātu.

CRA attiecas gan uz pilnīgiem produktiem, gan uz komponentiem, kas tirgū tiek laisti atsevišķi. Tas nozīmē, ka vadības kontrolieris, operatora panelis vai komunikācijas modulis var tikt vērtēti atsevišķi. Taču iekārtas ražotājam joprojām ir jāpierāda, ka kopums darbojas droši reālajā konfigurācijā pie klienta — tātad tajā versijā, kurā kāds “noteikti vairs neko nav mainījis… vai ne?”.

Un tieši šeit parādās visbiežākā kļūda.

Tas ir tieši tas pats mehānisms, ko jau gadiem pazīstam no mašīnbūves drošības jomas.

Aizkaram ir PL e.
Safety PLC ir SIL 3.
Piedziņai ir STO.

Vai tas nozīmē, ka visa iekārta automātiski ir šajā pašā līmenī?

Tas ir tāpat kā ar sastatnēm: tas, ka katrs elements atbilst drošības standartiem, vēl negarantē, ka visa konstrukcija būs stabila.

Nē.

Jo joprojām ir jāpārbauda, kā tas viss darbojas kopā — proti, šis mazāk iecienītais “sistēmiskās domāšanas” posms, kuram diemžēl nav pogas “auto-certify”.

Kiberdrošībā ir tieši tas pats.

Var būt “droši” komponenti, bet praksē:

• operators redz un var mainīt vairāk datu, nekā viņam patiesībā vajag, jo “tā bija ērtāk”,
• viena servisa parole darbojas visām iekārtām, jo “serviss jau zina, ko dara”,
• servisa ports ir pieejams “katram gadījumam”, tātad faktiski jebkuram gadījumam,
• attālinātā piekļuve aptver visu tīklu, jo kāds reiz teica: “tas taču ir tikai diagnostikai”,
• atjauninājumus var ielādēt bez kontroles, jo “nekad taču nekas nav salūzis”,
• ierīces savā starpā “uzticas” bez ierobežojumiem, jo uzticēšanās ir lētāka nekā segmentēšana,
• un integrācija pieņem, ka neviens nekad nekļūdīsies, kas — kā rāda vēsture — ir viens no optimistiskākajiem pieņēmumiem inženierijā.

Katrs elements atsevišķi var būt korekts.

Taču sistēma kopumā no šiem korektajiem elementiem var izveidot kaut ko tādu, kas darbojas… tikai ne obligāti tā, kā bija paredzēts.

Un tas ir būtiski: risks neslēpjas pašās ierīcēs, bet gan to savienojumā, konfigurācijā un leģendārajā “uz laiku atstātajā” piekļuvē.

CRA no iekārtas ražotāja prasa ko vairāk nekā deklarāciju kolekcionēšanu kā trofejas. Tas prasa pārbaudīt, vai no komponentiem saliktais kopums joprojām ir drošs kā veselums — nevis tikai “labi izskatās atbilstības tabulā”.

Praksē tas nozīmē vienkāršus, biznesam svarīgus jautājumus:

• vai katram lietotājam ir tikai tāda piekļuve, kāda viņam patiešām nepieciešama, nevis “varbūt kādreiz noderēs”,
• vai attālinātā piekļuve ir ierobežota līdz minimumam, vai drīzāk līdz maksimālai ērtībai,
• vai servisam nav “pilnas tiesības visur”, jo kāds nolēma, ka tā dzīve rit ātrāk,
• vai tīkls nav viena kopīga plakne, jo segmentēšana “sarežģī projektu”,
• vai atjauninājumi tiek kontrolēti, vai arī drīzāk “ieliekam un ceram uz labāko”,
• vai var ātri noteikt, kuras iekārtas ir pakļautas riskam, vai arī “pārbaudīsim pēc incidenta”,
• vai viena elementa atteice neatver visu sistēmu, jo “tā sanāca integrācijā”.

Tie nav tehniski jautājumi “inženieriem sarežģītām lietām”.

Tie ir jautājumi par biznesa risku: dīkstāvi, izmaksām, atbildību un to mazo detaļu, ka ražošanai tomēr ir jādarbojas.

Tāpēc nepietiek pateikt:

“visi komponenti ir atbilstoši”

Jo tas joprojām neatbild uz jautājumu:

vai visa iekārta ir droša reālā lietošanā, vai tikai PowerPoint prezentācijā projekta pārskatā?

Piegādātāja deklarācija ir svarīga.

Taču tā attiecas tikai uz vienu elementu — to, kas konkrētajā brīdī tika testēts laboratorijas apstākļos, nevis vidē “kaut kur cehā, ar VPN, USB un laika spiedienu”.

Tā neaptver to, kā tas ir izmantots.
Tā neaptver konfigurāciju.
Tā neaptver integrāciju.
Tā neaptver lēmumus, kas pieņemti “steigā palaišanas laikā, jo klients gaidīja”.
Tā neaptver to, kas notiek pēc gadiem ilgas ekspluatācijas, kad neviens vairs neatceras, kāpēc kaut kas bija “uz laiku atvērts”.

Tāpēc novērtējums nevar beigties ar ierīču sarakstu.

Uz sistēmu jāskatās kopumā:

• kam ir piekļuve un kāpēc (nevis “jo vienmēr tā bija”),
• kas patiešām ir nepieciešams un kas tikai “atstāts, jo netraucēja”,
• kur dati var izkļūt ārpus kontroles, jo kāds nolēma, ka “tā ir tikai diagnostika”,
• kas notiks, ja kāds izmantos likumīgu piekļuvi nelikumīgā veidā (tieši tā, kā to dara uzbrukumi),
• cik ātri var reaģēt, kad parādās problēma, nevis tikai “pēc ceturkšņa pārskata”.

Kamēr uz šiem jautājumiem nav atbilžu, mums ir tikai ļoti kārtīgs komponentu komplekts.

Mums vēl nav drošas iekārtas.

Komponentu atbilstība automātiski nerada sistēmas atbilstību. Iekārtas atbilstība ir jāieprojektē, jāpārbauda un — kas ir visgrūtāk — jāuztur, neskatoties uz kārdinājumu “vairs neko neaiztikt, jo strādā”.

3. Nepieraksti kiberuzbrukumu pie apdraudējumu saraksta. Savieno abas analīzes pareizajā vietā

Iekārtu tirgū formāla kiberdrošības riska analīze joprojām drīzāk ir izņēmums, nevis standarta projekta sastāvdaļa.

Visbiežāk ir industriālais maršrutētājs.

Ir VPN.

Ir parole PLC.

Dažkārt ir pārvaldāms komutators, kuru vēlāk neviens vairs nepārvalda.

Ambiciozākā variantā ražotājs no piegādātāja saņem prezentāciju par “defence in depth” un secina, ka ar to tikko ir pabeidzis visas iekārtas kiberdrošības riska analīzi.

Nav pabeidzis.

Viņš ir iegādājies dažus tehniskus aizsardzības līdzekļus.

Tā vēl nav analīze.

Tāpēc nav jēgas aprakstīt problēmu tā, it kā katrā projektā tiktu sagatavoti divi profesionāli novērtējumi — viens saskaņā ar ISO 12100, otrs par kiberdrošību — kuri vienkārši nejauši nav savstarpēji savienoti.

Visbiežāk tiek izveidota viena.

Iekārtas riska analīze.

Bet produkta kiberdrošības analīze netiek izveidota vispār.

Iekārtas riska analīze saskaņā ar ISO 12100 nenozīmē tabulā ierakstīt:

sensora atteice → negaidīta kustība → saspiešana.

Tas var būt konkrēta scenārija fragments, bet ne sākumpunkts.

Vispirms jānosaka iekārtas ierobežojumi.

Kāds ir tās paredzētais lietojums?

Kādas ir dzīves cikla fāzes?

Kas to izmantos?

Kādi uzdevumi tiks veikti transportēšanas, montāžas, palaišanas, ražošanas, regulēšanas, tīrīšanas, iestrēgumu novēršanas, apkopes, diagnostikas un demontāžas laikā?

Kādos režīmos iekārta var darboties?

Kur cilvēks atrodas katras no šīm darbībām laikā?

Kuras iekārtas daļas tajā brīdī paliek zem sprieguma, spiediena, slodzes vai kustībā?

Kāda lietošana neatbilst instrukcijai, bet joprojām ir saprātīgi paredzama?

Tikai pēc tam konkrētam uzdevumam vai darbībai cita starpā identificē:

• bīstamības avotu,
• bīstamības veidu,
• bīstamības zonu,
• apdraudēto personu,
• bīstamo situāciju,
• bīstamo notikumu, ja tas attiecīgajā scenārijā pastāv,
• iespējamās sekas un kaitējuma veidu.

Tā izskatās iekārtas riska analīze.

Mēs nesākam ar komponentu.

Mēs sākam ar cilvēku, kurš veic noteiktu uzdevumu pie iekārtas, kas atrodas noteiktā stāvoklī. ISO 12100 tieši šādu metodiku nosaka bīstamību identificēšanai, kā arī riska noteikšanai un novērtēšanai attiecīgajās iekārtas dzīves cikla fāzēs.

Aplūkosim vienkāršu piemēru.

Operators izņem iestrēgušu detaļu no palešu komplektēšanas šūnas iekšpuses.

Tātad mums ir:

Uzdevums: iestrēguma novēršana.

Lietošanas fāze: ekspluatācija, iejaukšanās pēc procesa apturēšanas.

Darba režīms: manuāls vai servisa režīms.

Apdraudētā persona: operators vai uzturēšanas dienesta darbinieks.

Bīstamības zona: šūnas iekšpuse, jo īpaši telpa starp satvērēju, detaļu un iekārtas konstrukciju.

Bīstamības avots: robota, lineārās ass vai pneimatiskā satvērēja mehāniskā enerģija.

Bīstamā situācija: cilvēks atrodas zonā, kamēr kustības izpilde joprojām ir iespējama.

Bīstamais notikums: negaidīta ass kustība, satvērēja aizvēršanās vai uzkrātās enerģijas atbrīvošanās.

Iespējamās sekas: trieciens, saspiešana, lūzums vai amputācija.

Tikai tagad var novērtēt risku un noteikt tā samazināšanas pasākumus.

Var būt nepieciešama aizsarga bloķēšana.

Var būt nepieciešama droša apturēšana.

Var būt nepieciešams novērst negaidītu iedarbināšanu.

Iespējams, jānovada pneimatiskā enerģija.

Iespējams, kustība manuālajā režīmā drīkst notikt tikai ar atļaujošo ierīci un droši ierobežotu ātrumu.

Tā joprojām ir klasiskā iekārtas riska analīze.

Kur šeit parādās kiberdrošība?

Nevis kā jauna pozīcija līdzās mehāniskajai, elektriskajai un termiskajai bīstamībai.

„Hakeris” nav mehāniskās bīstamības avots

Ja ISO 12100 tabulā vienkārši pievieno ierakstu:

Bīstamība: kiberuzbrukums

tas dod maz.

Kiberuzbrukums nav rotējoša vārpsta, asa mala, augsta temperatūra vai pneimatiskā enerģija.

Tā nav arī atsevišķa bīstamības zona.

Operators negūst saspiešanas traumu CVE ievainojamības dēļ.

Viņš to gūst no iekārtas elementa, kas veica kustību brīdī, kad cilvēks atradās nepareizajā vietā.

Taču kiberuzbrukums var mainīt vadības sistēmas stāvokli, datus, programmu, konfigurāciju vai aizsardzības līdzekļa darbības veidu.

Tādēļ tas var kļūt par:

• bīstamā notikuma cēloni,
• papildu ceļu, kas noved pie bīstamas situācijas,
• riska samazināšanas pasākuma efektivitātes zuduma cēloni,
• vai veidu, kā apiet pieņēmumus, kas izmantoti drošības funkcijas projektēšanā.

Un tieši tas ir pareizais saskares punkts.

Nevis bīstamību saraksts.

Bet iekārtas uzvedība.

Kiberdrošības analīze jāizstrādā atsevišķi

Iekārtai vai automatizācijas sistēmai kiberdrošības analīzei būs cita struktūra nekā riska analīzei saskaņā ar ISO 12100.

Visdabiskāko ietvaru rūpnieciskās automatizācijas sistēmai nodrošina IEC 62443-3-2.

Standarts cita starpā prasa:

• definēt analīzei pakļauto sistēmu, t. i., SUC,
• sadalīt sistēmu zonās un komunikācijas kanālos,
• novērtēt risku atsevišķām zonām un kanāliem,
• noteikt mērķa drošības līmeņus SL-T,
• dokumentēt drošības prasības.

Tas ir pilnīgi cits sākumpunkts nekā ISO 12100.

IEC 62443 ietvarā mēs cita starpā jautājam:

Kas tieši ietilpst analizētajā sistēmā?

Kādi aktīvi ir jāaizsargā?

Kādas ierīces, lietotnes un saskarnes atrodas sistēmā?

Kuriem elementiem būtu jāietilpst vienā un tajā pašā zonā?

Kā notiek komunikācija starp zonām?

Kas var iegūt piekļuvi?

No kuras vietas?

Izmantojot kādu saskarni?

Kādas ievainojamības var tikt izmantotas?

Kādi dati, funkcijas vai komponenti var tikt mainīti?

Pa kādu ceļu uzbrucējs var nokļūt no servisa maršrutētāja līdz PLC, HMI, piedziņai vai inženieru stacijai?

Kādas sekas radīs konfidencialitātes, integritātes vai pieejamības zudums?

Kādi aizsardzības pasākumi ir nepieciešami?

Drošas produkta izstrādes procesam un prasībām, kas attiecas uz pašiem komponentiem, nozīmīgas ir arī citas šīs sērijas daļas, jo īpaši IEC 62443-4-1 un IEC 62443-4-2. Savukārt IEC 62443-3-3 strukturē tehniskās drošības prasības sistēmas līmenī.

Šobrīd CRA neuzliek ražotājam pienākumu uz analīzes vāka norādīt “izpildīts saskaņā ar IEC 62443”.

IEC 62443 arī neaizstāj atbilstības pierādīšanu CRA prasībām.

Tomēr rūpnieciskai automatizācijas sistēmai tas ir daudz loģiskāks atskaites punkts nekā mēģinājums ISO 12100 tabulai vienkārši pievienot dažus hakeru scenārijus.

Jo abas metodikas atbild uz atšķirīgiem jautājumiem.

ISO 12100:

Kāda uzdevuma laikā, kur, no kāda avota un kāda notikuma rezultātā cilvēks var ciest kaitējumu?

IEC 62443:

Kas, pa kādu ceļu un izmantojot kādu ievainojamību var ietekmēt sistēmu, tās datus vai funkcijas?

Tikai pēc tam jāpārbauda, vai atbilde no otrās analīzes maina scenāriju no pirmās.

Tas pats scenārijs, divas atšķirīgas analīzes

Atgriezīsimies pie operatora, kurš novērš iestrēgušu detaļu.

ISO 12100 riska analīze parādīja, ka cilvēks ieiet zonā, kur viņu var saspiest robota vai satvērēja kustība.

Riska samazināšanas pasākums ir bloķēts aizsargs, drošas apturēšanas funkcija un lokāls atiestatījums, kas novietots ārpus bīstamās zonas.

Tagad veicam sistēmas kiberdrošības analīzi.

Identificējam:

• maršrutētāju, ko izmanto attālinātam servisam,
• servisa kontu,
• inženiera klēpjdatoru,
• HMI,
• standarta PLC,
• drošības PLC,
• piedziņas,
• programmēšanas saskarni,
• PROFINET tīklu un PROFIsafe komunikāciju,
• programmas ielādes un konfigurācijas mehānismus.

Aplūkojam scenāriju:

Servisa konta pārņemšana ļauj attālināti piekļūt standarta PLC un nosūtīt kustības komandu laikā, kad cilvēks atrodas šūnā.

Vai šis scenārijs noved pie bīstama notikuma?

Uz to nevar atbildēt, balstoties tikai uz pašu PLC pārņemšanas faktu.

Jāpārbauda drošības funkcijas arhitektūra.

Ja aizsarga atvēršanu uzrauga drošības PLC, funkcija droši atslēdz piedziņu griezes momentu, atiestatījums ir tikai lokāls un standarta PLC nevar atjaunot kustību neatkarīgi no drošības funkcijas stāvokļa, tad standarta kontroliera pārņemšana var apturēt ražošanu vai sabojāt procesu.

Taču tai nevajadzētu izraisīt kustību pie atvērta aizsarga.

Tādā gadījumā kiberdrošības analīze parāda uzbrukumu.

Iekārtas riska novērtējums parāda mehānisko apdraudējumu.

Tomēr pareizi izstrādāta drošības funkcija pārtrauc ceļu starp tiem.

Un tagad otrais variants.

Servisa režīms tiek izvēlēts no parasta HMI līmeņa.

Ierobežotā ātruma vērtība nāk no standarta PLC.

Attālinātais servisa speciālists var veikt atiestatījumu.

Tas pats inženiera konts ļauj mainīt standarta programmu un drošības konfigurāciju.

Drošības programmas kopija nav piesaistīta konkrētai iekārtas versijai.

Pēc iejaukšanās neviens nepārbauda kontrolsummu.

Piedziņas parametrus var mainīt attālināti.

Šādā arhitektūrā konta pārņemšana vairs nenozīmē tikai konfidencialitātes zudumu vai īsu dīkstāvi.

Tā var mainīt nosacījumus, uz kuriem balstījās riska samazināšana.

Tā var novest pie:

• nepareiza režīma izvēles,
• drošas kustības parametra maiņas,
• neatļauta atiestatījuma,
• neapstiprinātas konfigurācijas ielādes,
• vai tās funkcijas pavājināšanas, kurai bija jānovērš negaidīta iedarbināšana.

Un tad kiberscenārijs jāsasaista ar konkrētu iekārtas drošības scenāriju:

iestrēguma novēršanas uzdevums → cilvēks bīstamajā zonā → neatļauta vadības sistēmas vai aizsargfunkcijas maiņa → negaidīta kustība → saspiešana.

Apdraudējuma avots nav mainījies.

Tā joprojām ir iekārtas mehāniskā enerģija.

Bīstamā zona nav mainījusies.

Tā joprojām atrodas šūnas iekšpusē.

Iespējamās sekas nav mainījušās.

Tā joprojām ir operatora trauma.

Ir mainījies ceļš, kas noved pie bīstamā notikuma.

Ne katra ievainojamība nonāk ISO 12100

Šis nošķīrums ir tikpat svarīgs.

Pieņemsim, ka HMI ievainojamība ļauj nolasīt vēsturiskos ražošanas datus.

No CRA 2026–2027 vadlīniju un produkta praktiskas sagatavošanas skatpunkta tā var būt būtiska problēma.

Tā var pārkāpt datu konfidencialitāti.

Tā var prasīt atjauninājumu, ietekmes novērtējumu, rīcību attiecībā uz lietotājiem un noteiktos apstākļos arī ziņošanu.

Taču, ja tā neietekmē iekārtas darbību, nemaina aizsardzības pasākumu un nevar novest pie bīstamas situācijas, nav jēgas to mākslīgi iekļaut riska novērtējumā saskaņā ar ISO 12100.

Līdzīgi arī uzbrukums, kas izraisa tikai ražošanas atskaišu nepieejamību, var radīt uzņēmējdarbības problēmu un atbilstības problēmu saistībā ar CRA.

Tomēr tam nav obligāti jārada risks operatoram.

No otras puses, šķietami nevainīga iespēja mainīt vienu iestatīto vērtību var būt mazsvarīga datu konfidencialitātei, bet ārkārtīgi nozīmīga fiziskajai drošībai.

Piemēram, ja šī vērtība nosaka:

• ass maksimālo ātrumu,
• piespiešanas spēku,
• procesa temperatūru,
• spiedienu,
• apstāšanās pozīciju,
• vārsta atvēršanas laiku,
• vai pieļaujamo robežvērtību darbam ar atvērtu aizsargu.

Tāpēc kiberdraudus neklasificējam pēc tā, cik tehniski tie izklausās.

Mēs vērtējam, ko tie reāli var izdarīt ar iekārtu.

Mašīnu regula prasa šo sasaisti

Šī saikne nav tikai laba inženierprakse.

Mašīnu regulas III pielikuma 1.2.1 punkts nosaka, ka vadības sistēmām jābūt projektētām un izgatavotām tā, lai novērstu bīstamu situāciju rašanos, arī saprātīgi paredzamu trešo personu ļaunprātīgu darbību rezultātā.

Savukārt CRA norāda, ka tā būtiskās kiberdrošības prasības var palīdzēt pierādīt atbilstību cita starpā mašīnu regulas 1.1.9 un 1.2.1 prasībām.

Taču tas nenotiek automātiski.

Ražotājam šī saistība jāpierāda, balstoties uz riska novērtējumu. Atbilstības novērtēšana saskaņā ar CRA un atbilstības novērtēšana saskaņā ar mašīnu regulu joprojām ir divi atsevišķi procesi.

Tas nozīmē, ka nepietiek sagatavot:

• ISO 12100 riska analīzi,
• IEC 62443 analīzi,
• divus atsevišķus ziņojumus,
• un cerēt, ka standartu numuru līdzība pati par sevi izveidos starp tiem audita izsekojamību.

Ir vajadzīga sasaite.

Katram būtiskam kiberscenārijam jānosaka:

1. kuru elementu vai funkciju var pārņemt vai izmainīt,
2. kādu iekārtas uzvedību tas var izraisīt,
3. vai šī uzvedība noved pie bīstamas situācijas vai bīstama notikuma,
4. uz kuru uzdevumu un kuru bīstamo zonu tas attiecas,
5. kādas iespējamās sekas ir norādītas ISO 12100 novērtējumā,
6. kuram riska samazināšanas pasākumam būtu jāpārtrauc šī scenārija attīstība,
7. vai šis pasākums saglabā efektivitāti arī pēc uzbrukumam pakļautā elementa pārņemšanas.

Šis pēdējais punkts ir vissvarīgākais.

Jo, ja uzbrukums un aizsardzība ir atkarīgi no:

• tā paša kontroliera,
• tā paša konta,
• tā paša tīkla,
• tās pašas inženierdarbstacijas,
• vai tās pašas programmas,

tad, iespējams, mums nav divu neatkarīgu aizsardzības slāņu.

Mums ir viens slānis, kas aprakstīts divos dokumentos.

Tāpēc mums nav vajadzīga viena milzīga tabula ar nosaukumu:

“safety & cybersecurity riska novērtējums”.

Mums vajadzīgas divas korekti veiktas analīzes, izmantojot atbilstošas metodes, un kontrolēts saskares punkts starp tām.

ISO 12100 jāapraksta cilvēks, uzdevums, bīstamības avots, zona, bīstamā situācija, bīstamais notikums un iespējamais kaitējums.

IEC 62443 jāpalīdz aprakstīt sistēmu, tās zonas, komunikācijas kanālus, resursus, draudus, ievainojamības, uzbrukuma ceļus un nepieciešamos aizsardzības pasākumus.

Un ražotājam jāpierāda, vai scenārijs no otrās analīzes var iedarbināt scenāriju no pirmās analīzes vai atņemt efektivitāti pasākumam, kam tas bija jāaptur.

Kiberuzbrukumam nav obligāti jārada jauns apdraudējums. Pietiek ar to, ka tas atver jaunu ceļu uz vecu negadījumu.

4. Pentests pirms FAT ir fotogrāfija. CRA prasa filmu

Daudzos projektos kiberdrošība parādās divas nedēļas pirms FAT.

Tiek pasūtīts pentests.

Tiek sagatavots ziņojums.

Kritiskās ievainojamības tiek novērstas, vidējās tiek pieņemtas, un dokuments nonāk projekta mapē.

Iekārta ir kiberdroša.

Līdz nākamajai otrdienai.

Pentests var būt ļoti vērtīgs verifikācijas elements. Tomēr tas parāda konkrētas produkta versijas stāvokli, konkrētā konfigurācijā un izmantojot noteiktus testēšanas scenārijus.

Tas neatbild uz jautājumu, ko ražotājs darīs vēlāk.

Bet CRA attiecas uz visu produkta dzīves ciklu. Kiberdrošības riska novērtējumam jāietekmē produkta plānošana, projektēšana, izstrāde, ražošana, piegāde un uzturēšana. Pēc produkta laišanas tirgū ražotājam jāapstrādā ievainojamības deklarētajā atbalsta periodā.

Atgriezīsimies pie dārzeņu iepakošanas iekārtas.

Iekārta ir izgājusi FAT.

Pentests nekonstatēja kritiskas ievainojamības.

Astoņus mēnešus vēlāk servisa maršrutētāja ražotājs publicē informāciju par ievainojamību, kas ļauj pārņemt ierīci.

Un tieši tad sākas īstais darbs.

Kurām piegādātajām iekārtām ir šis maršrutētāja modelis?

Kura firmware versija ir uzstādīta katrā eksemplārā?

Vai attālinātā piekļuve ir aktīva?

Vai ievainojamību var izmantot reālajā konfigurācijā?

Vai maršrutētāja pārņemšana dod piekļuvi tikai diagnostikai, vai arī HMI, PLC, piedziņām un safety PLC?

Vai ir iespējama tikai datu nolasīšana, vai arī programmas vai parametru maiņa?

Vai uzbrukums var ietekmēt drošības funkciju?

Vai piegādātājs ir nodrošinājis labojumu?

Vai maršrutētāja atjauninājums mainīs sertifikātus, komunikācijas noteikumus vai tuneļa izveides veidu?

Vai pēc atjaunināšanas ir atkārtoti jāpārbauda attālinātais serviss, komunikācija un daļa drošības funkciju?

Kuri klienti ir jāinformē?

Un vai šī situācija atbilst kritērijiem ziņošanai par aktīvi izmantotu ievainojamību vai nopietnu incidentu?

Pentestēšanas ziņojums, kas sagatavots pirms FAT, neatbildēs ne uz vienu no šiem jautājumiem.

Tajā ir aprakstīta iekārta, kas vairs nepastāv.

Jo kopš pārbaudes ir mainījušās programmatūras versijas, konfigurācijas, lietotāja vide un zināšanas par ievainojamībām.

Tāpēc ražotājam ir vajadzīgs ne tikai tests, bet process:

• aparatūras, aparātprogrammatūras un programmatūras versiju identificēšanai katrā piegādātajā eksemplārā,
• informācijas par ievainojamībām uzraudzībai,
• to izmantojamības izvērtēšanai faktiskajā arhitektūrā,
• iespējamo seku pārbaudei procesam un iekārtas drošībai,
• atjauninājumu sagatavošanai un testēšanai,
• lietotāju informēšanai,
• pieņemto lēmumu dokumentēšanai,
• prasīto ziņojumu apstrādei.

No 2026. gada 11. septembra ražotājiem būs pienākums ziņot par aktīvi izmantotām ievainojamībām un nopietniem incidentiem, kas ietekmē to produktu drošību, kuros ir digitāli elementi. Sākotnējais brīdinājums jāsniedz 24 stundu laikā, bet pilns ziņojums — 72 stundu laikā.

Tas nozīmē, ka pēc problēmas atklāšanas vairs nebūs laika sākt meklēt:

“Kas īsti ražoja šo maršrutētāju, un kur mums ir to iekārtu saraksts, kurās mēs to ielikām?”

IEC 62443-4-1 labi parāda atšķirību starp vienreizēju produkta aizsardzību un drošu tā izstrādes ciklu. Tas aptver ne tikai projektēšanu un verifikāciju, bet arī defektu, labojumu un produkta dzīves cikla beigu pārvaldību.

FAT tātad var noslēgt projekta posmu.

Taču tas nenoslēdz produkta dzīves ciklu.

Tas nenoslēdz atbalsta periodu.

Tas neizbeidz ievainojamību uzraudzību.

Un tas nenozīmē, ka pieņemšanas dienas konfigurācija tiek iesaldēta uz nākamajiem piecpadsmit gadiem.

Iekārta ilgu laiku var iepakot dārzeņus lielveikaliem.

Taču ražotājs nevar tās kiberdrošību iepakot kopā ar instrukciju, aizkausēt plēvē un uzskatīt, ka tā ir piegādāta vienreiz un uz visiem laikiem.

Pentests var aizvērt vienu punktu FAT sarakstā. CRA atver procesu, kas turpinās līdz produkta atbalsta perioda beigām.