CRA mašinų gamintojams pagal 2026 m. liepos 27 d. Komisijos gaires. Ką iš tikrųjų reikia įgyvendinti?

Daugelį metų mašinos kibernetinį saugumą buvo galima aprašyti trimis žingsniais: žinomo gamintojo valdiklis, VPN „nes taip daroma“ ir klasikinis „klientas apsaugos tinklą“. O jei kas nors dar pridėdavo ugniasienę spintoje, tema neretai būdavo laikoma uždaryta — bent jau tol, kol kas nors pabandydavo patikrinti, kas nutinka po realios atakos, o ne prezentacijoje.

Tačiau kibernetinis saugumas PROFINET tinklu tiesiog „neteče“. Komponentai gali turėti sertifikatus, deklaracijas ir „secure by design“ rinkodaros brošiūroje, bet visa mašina vis tiek gali būti nuspėjama taip, kad tai neturi nieko bendra su sauga. Kaip saugos relė pati savaime nepadaro sistemos saugios, jei valdymo logika leidžia ją apeiti, taip ir „saugus“ HMI neišsprendžia architektūros, integracijos, teisių, atnaujinimų ir to, kas vyksta, kai kas nors nustoja prašyti leidimo, problemų.

CRA (Cyber Resilience Act, Europos Parlamento ir Tarybos reglamentas (ES) 2024/2847) nėra priedas IT sričiai. Tai gaminiams taikomas reglamentavimas, kuris į mašinos gyvavimo ciklą įeina neklausdamas automatikos skyriaus sutikimo. Jis apima valdymo projektavimą, rizikos analizę, tiekimo grandinę, konfigūravimą, atnaujinimus, taip pat gaminio priežiūrą dar ilgai po to, kai buvo pasirašytas FAT ir mašina išvažiavo iš cecho. Ir ne, argumentas „mes jos nejungiame prie interneto“ temos neuždaro. Praktikoje pakanka techninės priežiūros nešiojamojo kompiuterio, USB laikmenos, nuotolinės diagnostikos „trumpam“ arba integracijos su gamyklos sistema, kad riba tarp izoliacijos ir atvėrimo išnyktų.

2026 m. liepos 27 d. Komisijos gairės paties reglamento nepakeitė, tačiau veiksmingai susiaurino interpretavimo erdvę, kuri anksčiau leido kibernetinį saugumą traktuoti kaip pasirenkamą sluoksnį. Be kita ko, buvo patikslinta gaminio riba, nuotolinio apdorojimo vaidmuo, atsakomybė už pakeitimus po pristatymo ir tai, kad „po FAT tai jau ne mūsų problema“ nebėra saugi prielaida.

Vis dėlto svarbiausias pokytis yra dar fundamentalesnis: kibernetinė ataka nustoja būti vien IT įvykiu ir tampa scenarijumi, darančiu poveikį mašinos funkcinei saugai. Jei neautorizuotas programos pakeitimas gali sukelti ašies judėjimą, blokavimo apėjimą, proceso parametrų pakeitimą arba saugos funkcijos praradimą, tai jau nėra vien „tinklo incidentas“. Tai kalba apie potencialiai nevaldomą mašinos elgseną — nepriklausomai nuo to, ar priežastis buvo konfigūracijos klaida, programinės įrangos spraga, ar tyčinis įsikišimas.

Šiame kontekste vienkartinis įsiskverbimo testas prieš FAT nustoja būti atitikties įrodymu ir tampa tik sistemos būsenos momentine nuotrauka konkrečiu laiko momentu. CRA reikalauja tęstinio požiūrio: nuo projektavimo, per gamybą ir paleidimą, iki atnaujinimų, pažeidžiamumų valdymo, reagavimo į incidentus ir priežiūros per deklaruotą palaikymo laikotarpį.

Praktikoje tai reiškia atsisakyti mąstymo „padaryta = saugu“ ir pereiti prie „prižiūrima = kontroliuojama“. Be iliuzijos, kad ugniasienė spintoje, VPN ir komponento sertifikatas uždaro temą. Ir be prielaidos, kad kibernetinis saugumas baigiasi pasirašius priėmimo protokolą.

Šiame straipsnyje išnarstome, ką CRA gairės realiai keičia mašinų gamintojams, integratoriams ir modernizuotojams — nesuvedant visos temos į šūkį „pakeiskime slaptažodį ir pridėkime cybersecurity varneles“.

1. Kad mašina nepatektų į CRA taikymo sritį, ji turėtų būti beveik vien ant kontaktorių

Daugelyje projektų CRA taikymo sritis tikrinama vienu klausimu:

Ar mašina bus prijungta prie interneto?

Nebus.

Vadinasi, tema uždaryta.

Schemoje yra PLC, HMI, keli pavarų keitikliai, paskirstytieji įėjimai ir išėjimai, vožtuvų sala, saugos skeneris ir prievadas programai įkelti. Valdiklis su pultu bendrauja per PROFINET, su pavaromis keičiasi valdymo ir būsenos žodžiais, o jutikliai perduoda duomenis per IO-Link.

Tačiau maršrutizatoriaus su SIM kortele nėra.

Kaip žinia, duomenys tampa duomenimis tik tada, kai palieka gamybos cechą.

Tačiau CRA neklausia, ar mašina turi prieigą prie interneto.

Jis klausia, ar jos paskirtis arba pagrįstai numatomas naudojimas apima tiesioginį arba netiesioginį, loginį arba fizinį duomenų ryšį su įrenginiu ar tinklu. Tai nebūtinai turi būti ryšys su debesija, gamintojo serveriu ar viešuoju internetu. Jis gali būti realizuotas laidu, radijo bangomis, per programinę sąsają arba kaip didesnės sistemos dalis.

Ir dabar esminis klausimas: kas tipinėje mašinoje iš tikrųjų perduoda duomenis?

Ar HMI nuskaito būsenas iš PLC ir įrašo nustatymus?

Ar PLC siunčia pavarai valdymo žodį, o atsakydamas gauna greitį, būseną ir klaidos kodą?

Ar įėjimų ir išėjimų sala perduoda proceso vaizdą?

Ar IO-Link jutiklis siunčia matavimo vertę, įrenginio identifikatorių ir diagnostinius duomenis?

Ar safety PLC bendrauja su moduliais per PROFIsafe?

Ar programa, aparatinės įrangos konfigūracija arba programinė aparatinė įranga įkeliama iš techninės priežiūros nešiojamojo kompiuterio?

Ar receptūras, ataskaitas arba atnaujinimus galima perkelti per USB?

Jei bent kartą atsakymas yra „taip“, tikėtina, kad turime duomenų ryšį.

Ir to nekeičia faktas, kad:

• mašina veikia vietiniame tinkle,
• ji neturi viešo IP adreso,
• Ethernet prievadas naudojamas tik paleidimo metu,
• nešiojamąjį kompiuterį prijungia tik serviso darbuotojai,
• ryšys vyksta tik valdymo sistemos viduje,
• klientas pažadėjo, kad mašinos niekada neprijungs prie interneto.

CRA apima ne tik instrukcijoje kaip pagrindinis aprašytą naudojimą, bet ir pagrįstai numatomą naudojimą. Todėl serviso prievadas nenustoja perduoti duomenų vien dėl to, kad schemoje prie jo parašyta „SERVICE ONLY“.

Vis dėlto 2026 m. liepos 27 d. Komisijos gairėse įvedamas svarbus atskyrimas.

Ne kiekvienas laidas ir ne kiekvienas elektrinis signalas yra duomenų jungtis.

Jei signalas skirtas tik konkrečiai funkcijai įjungti, išjungti arba jai maitinti ir neperduoda skaitmeniniu būdu užkoduotos informacijos, vien to, kad egzistuoja dvi elektrinės būsenos, dar nepakanka laikyti jį duomenų jungtimi.

Mygtukas, paduodantis įtampą į kontaktoriaus ritę, netampa skaitmenine sąsaja vien todėl, kad jo būseną galima aprašyti kaip nulį arba vienetą.

Panašiai ir klasikinis galinis jungiklis, įjungtas į relinę-kontaktorinę grandinę, gali tik nutraukti arba uždaryti grandinę. Jis neperduoda įrenginio numerio, proceso vertės, diagnostikos kodo, programinės aparatinės įrangos versijos ar telegramos, kurioje būtų kelios informacijos dalys.

Tačiau kai ta pati būsena patenka į išmanųjį įrenginį, yra užkoduojama, perduodama magistrale, susiejama su diagnostika ir gavėjo interpretuojama kaip informacija, situacija jau atrodo kitaip.

Taigi riba eina ne tarp „online“ ir „offline“ mašinos.

Ji eina tarp paprasto valdymo signalo ir skaitmeniniu būdu užkoduotos informacijos mainų.

Todėl praktikoje mašina, kuri nepatektų į CRA taikymo sritį vien dėl to, kad neturi duomenų jungties, turėtų labiau priminti klasikinę sistemą su mygtukais, galiniais jungikliais, relėmis ir kontaktoriais, o ne šiuolaikinį projektą, atidaromą TIA Portal aplinkoje.

Žinoma, tai nėra įstatyme numatyta išimtis kontaktoriams.

Galima sukurti paprastą mašiną su PLC, kuri po išsamios analizės neatitiks taikymo srities kriterijaus. Taip pat galima į kontaktorinę sistemą pridėti skaitmeninį reguliatorių, serviso sąsają arba ryšio modulį ir atsidurti tiksliai kitoje ribos pusėje.

Komponento pavadinimas bylos neišsprendžia.

Lemiamą reikšmę turi tai, ką produktas faktiškai daro ir su kuo jis keičiasi duomenimis.

Todėl prieš atsakant į klausimą, ar konkrečiai mašinai taikomas CRA, reikia nustatyti:

• kur eina vertinamo produkto riba,
• kokie įrenginiai ir programinės įrangos elementai į ją įeina,
• kokias fizines ir logines sąsajas jis turi,
• kokia informacija jomis perduodama,
• kurios jungtys yra tiesioginės, o kurios vyksta per didesnę sistemą,
• kurios iš jų naudojamos įprasto veikimo, paleidimo, diagnostikos, atnaujinimo arba serviso metu,
• kokie naudojimo būdai yra pagrįstai numatomi, net jei gamintojas verčiau nenorėtų jų numatyti.

Kol neatsakėme į šiuos klausimus, nežinome, ar mašina lieka už CRA taikymo srities ribų.

Daugiausia turime patogų sakinį:

„Mašina nėra prijungta prie interneto“.

Tik tai yra atsakymas į klausimą, kurio CRA neužduoda.

PROFINET nėra internetas. CRA požiūriu jis visai neprivalo juo būti.

2. Kibernetinis saugumas neplinta per PROFINET

Daugelyje projektų mašinos atitikties tema prasideda jau pirkimų etape.

PLC iš pripažinto gamintojo.
HMI su naujausia programinės aparatinės įrangos versija.
Valdomas komutatorius.
Pramoninis maršrutizatorius su VPN.
Pavaros su saugos funkcijomis.
Safety PLC su atitinkamu sertifikatu.

Prie kiekvieno įrenginio – atitikties deklaracija, instrukcija ir keli dokumentai su žodžiais „secure“, „encrypted“ ir „defence in depth“.

Schemoje viskas atrodo profesionaliai.

Tačiau vis dar nežinoma, ar visa mašina yra kibernetiškai saugi.

Nes kibernetinis saugumas „nepersiduoda“ per PROFINET.

Tai šiek tiek panašu į durų spyną:
galite turėti labai gerą spyną kiekviename kambaryje – sertifikuotą, išbandytą, su puikia dokumentacija ir „secure“ holograma, tačiau tai vis tiek negarantuoja saugumo, jei kas nors paliko plačiai atviras įėjimo duris, „nes paleidimo metu taip buvo greičiau“.

Ir lygiai taip pat yra čia: komponentai gali būti pavyzdiniai, o sistema vis tiek gali būti… kūrybiškai atvira.

PLC „neperduoda“ saugumo HMI.
Ugniasienė „neištaiso“ taikomosios logikos.
Komutatorius „nesutvarko“ naudotojų prieigos.
O tai, kad kiekvienas elementas turi sertifikatą, dar nereiškia, kad visa mašina nėra viena didelė, mandagiai dokumentuota spraga.

PROFINET perduoda duomenis.

Jis neperduoda atsakomybės.
Ir, deja, neperduoda ir sveiko proto.

CRA apima ir užbaigtus produktus, ir atskirai rinkai tiekiamus komponentus. Tai reiškia, kad valdiklis, operatoriaus pultas ar ryšio modulis gali būti vertinami atskirai. Tačiau mašinos gamintojas vis tiek turi įrodyti, kad visuma saugiai veikia realioje kliento konfigūracijoje – tai yra toje versijoje, kurioje kažkas „tikrai jau nieko nebekeitė… tiesa?“.

Ir čia atsiranda dažniausia klaida.

Tai lygiai tas pats mechanizmas, kurį jau daugelį metų žinome iš mašinų saugos ir rizikos analizės pagal LST EN ISO 12100.

Užuolaida turi PL e.
Safety PLC turi SIL 3.
Pavara turi STO.

Ar tai reiškia, kad visa mašina automatiškai atitinka tą patį lygį?

Kaip ir tai, kad kiekvienas pastolių elementas atitinka saugos standartus, dar negarantuoja, jog visa konstrukcija bus stabili.

Ne.

Nes vis tiek reikia patikrinti, kaip visa tai veikia kartu — kitaip tariant, atlikti tą ne itin populiarų „sisteminio mąstymo“ etapą, kuris, deja, neturi mygtuko „auto-certify“.

Kibernetinio saugumo srityje yra lygiai taip pat.

Galite turėti „saugius“ komponentus, bet praktikoje:

• operatorius mato ir gali keisti daugiau duomenų, nei jam reikia, nes „taip buvo patogiau“,
• vienas serviso slaptažodis tinka visoms mašinoms, nes „servisas vis tiek žino, ką daro“,
• serviso prievadas paliktas prieinamas „dėl visa ko“, kitaip tariant — bet kokiam atvejui,
• nuotolinė prieiga apima visą tinklą, nes kažkas kadaise pasakė: „juk tai tik diagnostika“,
• atnaujinimus galima įkelti be kontrolės, nes „niekada niekas nesugedo“,
• įrenginiai „pasitiki vieni kitais“ be jokių apribojimų, nes pasitikėjimas kainuoja mažiau nei segmentavimas,
• o integracija remiasi prielaida, kad niekas niekada nepadarys klaidos, nors istorija rodo, kad tai — bene optimistiškiausia prielaida inžinerijoje.

Kiekvienas elementas atskirai gali būti tinkamas.

Tačiau visa sistema iš tų tinkamų elementų gali sukurti tai, kas veikia… tik nebūtinai taip, kaip buvo numatyta.

Ir tai svarbiausia: rizika slypi ne įrenginiuose, o jų sujungime, konfigūracijoje ir tame legendiniame „laikinai paliktame“ priėjime.

CRA iš mašinos gamintojo reikalauja daugiau nei vien rinkti deklaracijas lyg trofėjus. Jis reikalauja patikrinti, ar tai, kas sudėta iš komponentų, vis dar yra saugu kaip visuma — o ne tik „gražiai atrodo atitikties lentelėje“.

Praktikoje tai reiškia paprastus, verslui svarbius klausimus:

• ar kiekvienas naudotojas turi tik tokią prieigą, kokios jam iš tikrųjų reikia, o ne „gal kada nors pravers“,
• ar nuotolinė prieiga apribota iki būtino minimumo, ar veikiau iki maksimalaus patogumo,
• ar servisas neturi „visų teisių visur“, nes kažkas nusprendė, kad taip gyventi greičiau,
• ar tinklas nėra viena bendra erdvė, nes segmentavimas „apsunkina projektą“,
• ar atnaujinimai yra kontroliuojami, ar veikiau „įkeliame ir meldžiamės“,
• ar galima greitai nustatyti, kurioms mašinoms kyla rizika, ar veikiau „patikrinsime po incidento“,
• ar vieno elemento gedimas neatveria visos sistemos, nes „taip gavosi integruojant“.

Tai nėra techniniai klausimai „inžinieriams, kurie sprendžia sudėtingus dalykus“.

Tai klausimai apie verslo riziką: prastovas, sąnaudas, atsakomybę ir tą smulkią detalę, kad gamyba vis dėlto turi veikti.

Todėl nepakanka pasakyti:

„visi komponentai atitinka reikalavimus“

Nes tai vis dar neatsako į klausimą:

ar visa mašina yra saugi realiomis naudojimo sąlygomis, ar tik PowerPoint skaidrėse per projekto peržiūrą?

Tiekėjo deklaracija yra svarbi.

Tačiau ji taikoma tik vienam elementui — tam, kuris buvo bandomas laboratorinėmis sąlygomis, o ne aplinkoje „kažkur ceche, su VPN, USB ir laiko spaudimu“.

Ji neapima to, kaip jis buvo panaudotas.
Ji neapima konfigūracijos.
Ji neapima integracijos.
Ji neapima sprendimų, priimtų „greitai paleidimo metu, nes klientas laukė“.
Ji neapima to, kas vyksta po daugelio eksploatacijos metų, kai niekas jau nebeprisimena, kodėl kažkas buvo „laikinai palikta atvira“.

Todėl vertinimas negali baigtis ties įrenginių sąrašu.

Į sistemą reikia žiūrėti kaip į visumą:

• kas turi prieigą ir kodėl (o ne „nes visada turėjo“),
• kas iš tikrųjų būtina, o kas tik „palikta, nes netrukdė“,
• kur duomenys gali ištrūkti iš kontrolės, nes kažkas nusprendė, kad „tai tik diagnostika“,
• kas nutiks, jei kas nors teisėtą prieigą panaudos neteisėtu būdu (būtent taip ir veikia atakos),
• kaip greitai galima sureaguoti, kai atsiranda problema, o ne tik „po ketvirtinės peržiūros“.

Kol nėra atsakymų į šiuos klausimus, turime tik labai tvarkingą komponentų rinkinį.

Dar neturime saugios mašinos.

Komponentų atitiktis automatiškai nesukuria sistemos atitikties. Mašinos atitiktį reikia suprojektuoti, patikrinti ir — kas sunkiausia — išlaikyti, nepaisant pagundos „jau nieko nejudinti, nes veikia“.

3. Neįrašyk kibernetinės atakos į pavojų sąrašą. Sujunk dvi analizes tinkamoje vietoje

Mašinų rinkoje formali kibernetinio saugumo rizikos analizė vis dar veikiau yra išimtis nei standartinė projekto dalis.

Dažniausiai yra pramoninis maršrutizatorius.

Yra VPN.

Yra PLC slaptažodis.

Kartais yra valdomas komutatorius, kurio vėliau niekas nebevaldo.

Ambicingesniu variantu gamintojas iš tiekėjo gauna prezentaciją apie „defence in depth“ ir nusprendžia, kad tuo ką tik užbaigė visos mašinos kibernetinio saugumo rizikos analizę.

Ne, neužbaigė.

Jis nusipirko kelias technines priemones.

Tai dar nėra analizė.

Todėl nėra prasmės aprašyti problemos taip, tarsi kiekviename projekte būtų rengiami du profesionalūs vertinimai — vienas pagal ISO 12100, kitas skirtas kibernetiniam saugumui — kurie tik atsitiktinai nebuvo tarpusavyje sujungti.

Dažniausiai parengiama viena.

Mašinos rizikos vertinimas.

O produkto kibernetinio saugumo analizė apskritai neparengiama.

Mašinos rizikos vertinimas pagal ISO 12100 nėra vien įrašas lentelėje:

jutiklio gedimas → netikėtas judesys → sutraiškymas.

Tai gali būti konkretaus scenarijaus dalis, bet ne atskaitos taškas.

Pirmiausia reikia nustatyti mašinos ribas.

Kokia yra jos paskirtis?

Kokios yra gyvavimo ciklo fazės?

Kas ja naudosis?

Kokios užduotys bus atliekamos transportavimo, montavimo, paleidimo, gamybos, reguliavimo, valymo, užstrigimų šalinimo, techninės priežiūros, diagnostikos ir išmontavimo metu?

Kokiais režimais mašina gali veikti?

Kur žmogus yra kiekvienos iš šių operacijų metu?

Kokios mašinos dalys tuo metu lieka įjungtos, veikiamos slėgio, apkrovos arba juda?

Koks naudojimas neatitinka instrukcijos, bet vis dar yra pagrįstai numatomas?

Tik vėliau, konkrečiai užduočiai ar operacijai, nustatoma, be kita ko:

• pavojaus šaltinis,
• pavojaus rūšis,
• pavojingoji zona,
• paveikiamas asmuo,
• pavojingoji situacija,
• pavojingasis įvykis, jei jis pasireiškia konkrečiame scenarijuje,
• galimos pasekmės ir žalos pobūdis.

Taip atrodo mašinos rizikos analizė.

Nepradedame nuo komponento.

Pradedame nuo žmogaus, kuris atlieka konkrečią užduotį prie tam tikros būsenos mašinos. Būtent tokią pavojų nustatymo bei rizikos įvertinimo ir vertinimo metodiką ISO 12100 nustato atitinkamose mašinos gyvavimo ciklo fazėse.

Paimkime paprastą pavyzdį.

Operatorius šalina užstrigusią detalę iš paletavimo celės vidaus.

Taigi turime:

Užduotis: užstrigimo pašalinimas.

Naudojimo fazė: eksploatavimas, įsikišimas sustabdžius procesą.

Darbo režimas: rankinis arba techninės priežiūros.

Paveikiamas asmuo: operatorius arba techninės priežiūros darbuotojas.

Pavojingoji zona: celės vidus, ypač erdvė tarp griebtuvo, detalės ir mašinos konstrukcijos.

Pavojaus šaltinis: roboto, linijinės ašies arba pneumatinio griebtuvo mechaninė energija.

Pavojingoji situacija: žmogus yra zonoje, kai judesio atlikimas vis dar įmanomas.

Pavojingasis įvykis: netikėtas ašies judesys, griebtuvo užsidarymas arba sukauptos energijos išsiskyrimas.

Galima pasekmė: smūgis, sutraiškymas, lūžis arba amputacija.

Tik dabar galima vertinti riziką ir nustatyti jos mažinimo priemones.

Gali prireikti apsauginio gaubto blokavimo.

Gali prireikti saugaus sustabdymo.

Gali būti būtina užkirsti kelią netikėtam paleidimui.

Gali tekti išleisti pneumatinę energiją.

Gali būti, kad judėjimas rankiniu režimu gali vykti tik naudojant leidimo įtaisą ir esant saugiai apribotam greičiui.

Tai vis dar yra klasikinis mašinos rizikos vertinimas.

Kur čia atsiranda kibernetinis saugumas?

Ne kaip nauja pozicija greta mechaninio, elektrinio ir šiluminio pavojaus.

„Hakeris“ nėra mechaninio pavojaus šaltinis

Įrašius į ISO 12100 lentelę tokią poziciją:

Pavojus: kibernetinė ataka

naudos nedaug.

Kibernetinė ataka nėra besisukantis velenas, aštri briauna, aukšta temperatūra ar pneumatinė energija.

Ji taip pat nėra atskira pavojingoji zona.

Operatorius nepatiria sutraiškymo dėl CVE pažeidžiamumo.

Jį sužaloja mašinos elementas, kuris atliko judesį tuo metu, kai žmogus buvo netinkamoje vietoje.

Tačiau kibernetinė ataka gali pakeisti valdymo sistemos būseną, duomenis, programą, konfigūraciją arba apsaugos priemonės veikimo būdą.

Taigi ji gali tapti:

• pavojingojo įvykio priežastimi,
• papildomu keliu, vedančiu į pavojingąją situaciją,
• rizikos mažinimo priemonės veiksmingumo praradimo priežastimi,
• arba būdu apeiti prielaidas, priimtas projektuojant saugos funkciją.

Ir būtent čia yra tikrasis sąlyčio taškas.

Ne pavojų sąraše.

Mašinos elgsenoje.

Kibernetinio saugumo analizė turėtų būti rengiama atskirai

Mašinai ar automatikos sistemai kibernetinio saugumo analizės struktūra bus kitokia nei rizikos vertinimo pagal ISO 12100.

Natūraliausią pramoninės automatikos sistemos karkasą suteikia IEC 62443-3-2.

Standartas, be kita ko, reikalauja:

• apibrėžti analizuojamą sistemą, t. y. SUC,
• suskirstyti sistemą į zonas ir ryšio kanalus,
• įvertinti atskirų zonų ir kanalų riziką,
• nustatyti tikslinius saugumo lygius SL-T,
• dokumentuoti saugumo reikalavimus.

Tai visiškai kitoks atskaitos taškas nei ISO 12100.

IEC 62443 kontekste, be kita ko, klausiame:

Kas tiksliai priklauso analizuojamai sistemai?

Kokius išteklius reikia apsaugoti?

Kokie įrenginiai, programos ir sąsajos yra sistemoje?

Kurie elementai turėtų priklausyti tai pačiai zonai?

Kaip vyksta komunikacija tarp zonų?

Kas gali gauti prieigą?

Iš kurios vietos?

Naudojant kokią sąsają?

Kokie pažeidžiamumai gali būti išnaudoti?

Kokie duomenys, funkcijos ar komponentai gali būti pakeisti?

Kokiu keliu užpuolikas gali patekti nuo techninės priežiūros maršrutizatoriaus iki PLC, HMI, pavaros arba inžinerinės stoties?

Kokios bus konfidencialumo, vientisumo arba prieinamumo praradimo pasekmės?

Kokios apsaugos priemonės reikalingos?

Saugaus produkto kūrimo procesui ir reikalavimams, taikomiems patiems komponentams, svarbios bus ir kitos šios serijos dalys, ypač IEC 62443-4-1 ir IEC 62443-4-2. Tuo tarpu IEC 62443-3-3 susistemina techninius saugumo reikalavimus sistemos lygmeniu.

Šiuo metu CRA nereikalauja, kad gamintojas ant analizės viršelio parašytų „atlikta pagal IEC 62443“.

IEC 62443 taip pat nepakeičia atitikties CRA reikalavimams įrodymo.

Tačiau pramoninei automatikos sistemai tai yra gerokai logiškesnis atskaitos taškas nei bandymas prie ISO 12100 lentelės pridėti kelis įsilaužimo scenarijus.

Nes abi metodikos atsako į skirtingus klausimus.

ISO 12100:

Atliekant kokią užduotį, kur, nuo kokio šaltinio ir dėl kokio įvykio žmogus gali patirti žalą?

IEC 62443:

Kas, kokiu keliu ir pasinaudodamas kokiu pažeidžiamumu gali paveikti sistemą, jos duomenis arba funkcijas?

Tik po to reikia patikrinti, ar atsakymas iš antrosios analizės pakeičia pirmosios analizės scenarijų.

Tas pats scenarijus, dvi skirtingos analizės

Grįžkime prie operatoriaus, šalinančio užstrigusią detalę.

ISO 12100 analizė parodė, kad žmogus patenka į zoną, kurioje jį gali prispausti roboto arba griebtuvo judesys.

Rizikos mažinimo priemonė yra blokuojamas apsauginis gaubtas, saugaus sustabdymo funkcija ir vietinis atstatymas, įrengtas už pavojingos zonos ribų.

Dabar atliekame sistemos kibernetinio saugumo analizę.

Nustatome:

• maršrutizatorių, naudojamą nuotolinei priežiūrai,
• techninės priežiūros paskyrą,
• inžinerinį nešiojamąjį kompiuterį,
• HMI,
• standartinį PLC,
• saugos PLC,
• pavaras,
• programavimo sąsają,
• PROFINET tinklą ir PROFIsafe ryšį,
• programos ir konfigūracijos įkėlimo mechanizmus.

Nagrinėjame scenarijų:

Perėmus techninės priežiūros paskyrą, atsiranda galimybė nuotoliniu būdu pasiekti standartinį PLC ir išsiųsti judesio komandą tuo metu, kai žmogus yra celėje.

Ar šis scenarijus sukelia pavojingą įvykį?

Vien iš PLC perėmimo fakto į tai atsakyti neįmanoma.

Reikia patikrinti saugos funkcijos architektūrą.

Jeigu gaubto atidarymą stebi saugos PLC, funkcija saugiai atjungia pavarų sukimo momentą, atstatymas galimas tik vietoje, o standartinis PLC negali atkurti judesio nepriklausomai nuo saugos funkcijos būsenos, tuomet standartinio valdiklio perėmimas gali sustabdyti gamybą arba sutrikdyti procesą.

Tačiau jis neturėtų sukelti judesio, kai gaubtas atidarytas.

Tokiu atveju kibernetinio saugumo analizė parodo ataką.

Mašinos rizikos vertinimas parodo mechaninį pavojų.

Tačiau tinkamai suprojektuota saugos funkcija nutraukia kelią tarp jų.

O dabar antras variantas.

Techninės priežiūros režimas pasirenkamas iš įprasto HMI lygmens.

Riboto greičio vertė gaunama iš standartinio PLC.

Nuotolinis techninės priežiūros specialistas gali atlikti atstatymą.

Ta pati inžinerinė paskyra leidžia keisti standartinę programą ir saugos konfigūraciją.

Saugos programos kopija nėra susieta su konkrečia mašinos versija.

Po intervencijos niekas netikrina kontrolinės sumos.

Pavaros parametrus galima keisti nuotoliniu būdu.

Tokioje architektūroje paskyros perėmimas jau nebereiškia vien konfidencialumo praradimo arba trumpos prastovos.

Jis gali pakeisti sąlygas, kuriomis buvo grindžiamas rizikos mažinimas.

Jis gali lemti:

• neteisingo režimo pasirinkimą,
• saugaus judesio parametro pakeitimą,
• neteisėtą atstatymą,
• nepatvirtintos konfigūracijos įkėlimą,
• arba funkcijos, kuri turėjo užkirsti kelią netikėtam paleidimui, susilpninimą.

Ir tada kibernetinį scenarijų reikia susieti su konkrečiu mašinos saugos scenarijumi:

užstrigimo šalinimo užduotis → žmogus pavojingoje zonoje → neautorizuotas valdymo sistemos arba apsauginės funkcijos pakeitimas → netikėtas judesys → prispaudimas.

Pavojaus šaltinis nepasikeitė.

Juo ir toliau išlieka mašinos mechaninė energija.

Pavojinga zona nepasikeitė.

Ji ir toliau yra celės viduje.

Galima pasekmė nepasikeitė.

Ja ir toliau išlieka operatoriaus sužalojimas.

Pasikeitė kelias, vedantis į pavojingą įvykį.

Ne kiekvienas pažeidžiamumas patenka į ISO 12100

Šis atskyrimas yra ne mažiau svarbus.

Tarkime, kad HMI pažeidžiamumas leidžia nuskaityti istorinius gamybos duomenis.

CRA požiūriu tai gali būti reikšminga problema.

Ji gali pažeisti duomenų konfidencialumą.

Gali reikėti atnaujinimo, poveikio vertinimo, veiksmų naudotojų atžvilgiu, o tam tikromis aplinkybėmis – ir pranešimo. Plačiau apie tai rašoma straipsnyje Reglamentas (ES) 2024/2847 – Kibernetinio atsparumo aktas (CRA).

Tačiau jeigu jis nedaro įtakos mašinos elgsenai, nekeičia apsaugos priemonės ir negali sukelti pavojingos situacijos, nėra prasmės jo per jėgą įtraukti į rizikos vertinimą pagal ISO 12100.

Panašiai ir ataka, sukelianti tik gamybos ataskaitų neprieinamumą, gali reikšti verslo problemą ir atitikties CRA problemą.

Tačiau ji nebūtinai kelia riziką operatoriui.

Kita vertus, iš pažiūros nekalta galimybė pakeisti vieną nustatytąją reikšmę gali turėti menką reikšmę duomenų konfidencialumui, bet milžinišką reikšmę fizinei saugai.

Pavyzdžiui, kai ši reikšmė nustato:

• didžiausią ašies greitį,
• prispaudimo jėgą,
• proceso temperatūrą,
• slėgį,
• sustabdymo padėtį,
• vožtuvo atidarymo laiką,
• arba leistiną ribą dirbant su atidarytu gaubtu.

Taigi kibernetinės grėsmės neklasifikuojame pagal tai, kaip techniškai ji skamba.

Vertiname, ką ji iš tikrųjų gali padaryti mašinai.

Mašinų reglamentas verčia nutiesti šį tiltą

Ši sąsaja nėra vien gera inžinerinė praktika.

Mašinų reglamento III priedo 1.2.1 punktas reikalauja, kad valdymo sistemos būtų suprojektuotos ir pagamintos taip, kad būtų užkirstas kelias pavojingoms situacijoms, taip pat ir dėl racionaliai numatomų piktavališkų trečiųjų asmenų bandymų.

Savo ruožtu CRA nurodo, kad jo esminiai kibernetinio saugumo reikalavimai gali padėti įrodyti atitiktį, be kita ko, mašinų reglamento 1.1.9 ir 1.2.1 reikalavimams.

Tačiau tai nevyksta automatiškai.

Gamintojas turi parodyti šį ryšį remdamasis rizikos vertinimu. Atitikties vertinimas pagal CRA ir atitikties vertinimas pagal mašinų reglamentą ir toliau išlieka atskiri procesai.

Vadinasi, nepakanka parengti:

• rizikos vertinimą pagal ISO 12100,
• IEC 62443 analizę,
• dvi atskiras ataskaitas,
• ir tikėtis, kad normų numerių panašumas sukurs tarp jų audito pėdsaką.

Reikalinga aiški sąsaja.

Kiekvienam reikšmingam kibernetiniam scenarijui reikia nustatyti:

1. kuris elementas arba funkcija gali būti perimta ar pakeista,
2. kokį mašinos elgesį tai gali sukelti,
3. ar toks elgesys lemia pavojingą situaciją arba pavojingą įvykį,
4. su kuria užduotimi ir kuria pavojinga zona tai susiję,
5. kokia galima pasekmė buvo nurodyta ISO 12100 vertinime,
6. kokia rizikos mažinimo priemonė turėtų sustabdyti scenarijaus vystymąsi,
7. ar ši priemonė išlieka veiksminga po to, kai perimamas atakuotas elementas.

Šis paskutinis punktas yra svarbiausias.

Nes jeigu ataka ir apsaugos priemonė priklauso nuo:

• to paties valdiklio,
• tos pačios paskyros,
• to paties tinklo,
• tos pačios inžinerinės stoties,
• arba tos pačios programos,

tuomet gali būti, kad neturime dviejų nepriklausomų apsaugos sluoksnių.

Turime vieną sluoksnį, aprašytą dviejuose dokumentuose.

Taigi mums nereikia vienos milžiniškos lentelės pavadinimu:

„safety & cybersecurity rizikos vertinimas“.

Mums reikia dviejų teisingų analizių, atliktų tinkamais metodais, ir kontroliuojamo sąlyčio taško tarp jų.

ISO 12100 turi aprašyti žmogų, užduotį, pavojaus šaltinį, zoną, pavojingą situaciją, pavojingą įvykį ir galimą žalą.

IEC 62443 turi padėti aprašyti sistemą, jos zonas, ryšio kanalus, išteklius, grėsmes, pažeidžiamumus, atakos kelius ir reikiamas apsaugos priemones.

O gamintojas turi parodyti, ar antrosios analizės scenarijus gali paleisti pirmosios analizės scenarijų arba panaikinti priemonės, kuri turėjo jį sustabdyti, veiksmingumą.

Kibernetinė ataka neprivalo sukurti naujo pavojaus. Pakanka, kad ji atvertų naują kelią į seną nelaimingą atsitikimą.

4. Pentestas prieš FAT yra nuotrauka. CRA reikalauja filmo

Daugelyje projektų kibernetinis saugumas atsiranda likus dviem savaitėms iki FAT.

Užsakomas pentestas.

Parengiama ataskaita.

Kritiniai pažeidžiamumai ištaisomi, vidutiniai priimami, o dokumentas patenka į projekto katalogą.

Mašina yra kibernetiškai saugi.

Iki kito antradienio.

Pentestas gali būti labai vertingas verifikavimo elementas. Tačiau jis parodo konkrečios produkto versijos būseną, esant konkrečiai konfigūracijai ir naudojant apibrėžtus testavimo scenarijus.

Jis neatsako į klausimą, ką gamintojas darys vėliau.

O CRA taikomas visam produkto gyvavimo ciklui. Kibernetinio saugumo rizikos vertinimas turi daryti įtaką produkto planavimui, projektavimui, kūrimui, gamybai, tiekimui ir priežiūrai. Pateikęs produktą rinkai, gamintojas turi tvarkyti pažeidžiamumus per deklaruotą palaikymo laikotarpį.

Grįžkime prie daržovių pakavimo mašinos.

Mašina praėjo FAT.

Pentestas neparodė kritinių pažeidžiamumų.

Po aštuonių mėnesių techninės priežiūros maršrutizatoriaus gamintojas paskelbia informaciją apie pažeidžiamumą, leidžiantį perimti įrenginį.

Ir būtent tada prasideda tikrasis darbas.

Kuriuose pristatytuose įrenginiuose yra šis maršrutizatoriaus modelis?

Kokia firmware versija buvo įdiegta kiekviename egzemplioriuje?

Ar nuotolinė prieiga yra aktyvi?

Ar pažeidžiamumą galima išnaudoti realioje konfigūracijoje?

Ar perėmus maršrutizatorių gaunama prieiga tik prie diagnostikos, ar ir prie HMI, PLC, pavarų bei safety PLC?

Ar įmanomas tik duomenų nuskaitymas, ar ir programos arba parametrų keitimas?

Ar ataka gali paveikti saugos funkciją?

Ar tiekėjas pateikė pataisą?

Ar maršrutizatoriaus atnaujinimas pakeis sertifikatus, ryšio taisykles arba tunelio užmezgimo būdą?

Ar po atnaujinimo reikia iš naujo patikrinti nuotolinį aptarnavimą, ryšį ir dalį saugos funkcijų?

Kuriuos klientus reikia informuoti?

Ir ar ši situacija atitinka pranešimo apie aktyviai išnaudojamą pažeidžiamumą arba rimtą incidentą kriterijus?

Prieš FAT atliktos įsiskverbimo testo ataskaitos nepakaks atsakyti nė į vieną iš šių klausimų.

Joje aprašyta mašina, kurios jau nebėra.

Nes nuo tyrimo atlikimo pasikeitė programinės įrangos versijos, konfigūracijos, naudotojo aplinka ir žinios apie pažeidžiamumus.

Todėl gamintojui reikia ne vien testo, o proceso:

• kiekviename pristatytame egzemplioriuje identifikuoti aparatinės įrangos, programinės aparatinės įrangos ir programinės įrangos versijas,
• stebėti informaciją apie pažeidžiamumus,
• vertinti jų išnaudojimą realioje architektūroje,
• tikrinti galimas pasekmes procesui ir mašinos saugai,
• rengti ir testuoti atnaujinimus,
• informuoti naudotojus,
• dokumentuoti priimtus sprendimus,
• tvarkyti privalomus pranešimus.

Nuo 2026 m. rugsėjo 11 d. gamintojai privalo pranešti apie aktyviai išnaudojamus pažeidžiamumus ir rimtus incidentus, darančius poveikį produktų su skaitmeniniais elementais saugai. Pirminį įspėjimą reikia pateikti per 24 valandas, o išsamų pranešimą – per 72 valandas.

Tai reiškia, kad nustačius problemą nebeliks laiko pradėti aiškintis:

„Kas iš tikrųjų gamino šį maršrutizatorių ir kur turime mašinų, į kurias jį įdėjome, sąrašą?“

IEC 62443-4-1 aiškiai parodo skirtumą tarp vienkartinio produkto apsaugojimo ir saugaus jo kūrimo ciklo. Jis apima ne tik projektavimą ir verifikavimą, bet ir defektų, pataisų bei produkto gyvavimo pabaigos valdymą.

Taigi FAT gali užbaigti projekto etapą.

Tačiau jis neužbaigia produkto gyvavimo ciklo.

Jis neužbaigia palaikymo laikotarpio.

Jis nenutraukia pažeidžiamumų stebėsenos.

Ir nereiškia, kad priėmimo dienos konfigūracija užšaldoma kitiems penkiolikai metų.

Mašina ilgą laiką gali pakuoti daržoves prekybos tinklams.

Tačiau gamintojas negali jos kibernetinio saugumo supakuoti kartu su instrukcija, užlydyti plėvele ir laikyti, kad jis buvo pristatytas kartą ir visiems laikams.

Įsiskverbimo testas gali uždaryti punktą FAT sąraše. CRA atveria procesą, kuris tęsiasi iki produkto palaikymo laikotarpio pabaigos.