CRA za proizvajalce strojev po smernicah Komisije z dne 27. julija 2026. Kaj je treba dejansko uvesti?

Leta je bilo kibernetsko varnost stroja mogoče opisati v treh korakih: krmilnik priznane znamke, VPN »ker se tako dela« in klasični stavek »stranka bo zavarovala omrežje«. Če je kdo v omaro dodal še požarni zid, se je tema pogosto štela za zaključeno — vsaj dokler ni nekdo preveril, kaj se zgodi ob dejanskem napadu, ne pa na predstavitvi.

Težava je v tem, da kibernetska varnost ne teče po PROFINET-u. Komponente imajo lahko certifikate, izjave in »secure by design« v marketinški brošuri, vendar je lahko stroj kot celota še vedno predvidljiv na način, ki z varnostjo nima nič skupnega. Tako kot varnostni rele sam po sebi ne naredi sistema varnega, če ga je mogoče obiti z logiko krmiljenja, tudi »varen« HMI ne reši težav arhitekture, integracije, pravic dostopa, posodobitev in tega, kaj se zgodi, ko nekdo preneha spraševati za dovoljenje.

CRA (Cyber Resilience Act, Uredba Evropskega parlamenta in Sveta (EU) 2024/2847) ni dodatek za IT. Gre za produktno regulativo, ki vstopa v življenjski cikel stroja, ne da bi za to spraševala oddelek avtomatizacije. Zajema zasnovo krmiljenja, analizo tveganja v skladu z ISO 12100, dobavno verigo, konfiguracijo, posodobitve ter tudi vzdrževanje izdelka še dolgo po tem, ko je bil FAT podpisan in je stroj zapustil halo. In ne, argument »ne povezujemo ga z internetom« teme ne zaključi. V praksi zadoščajo servisni prenosnik, USB-ključek, oddaljena diagnostika »za kratek čas« ali integracija s tovarniškim sistemom, da meja med izolacijo in izpostavljenostjo preneha obstajati.

Smernice Komisije z dne 27. julija 2026 same uredbe niso spremenile, so pa učinkovito zožile prostor za razlago, ki je prej omogočal obravnavo kibernetske varnosti kot neobvezne plasti. Natančneje so opredelile med drugim mejo izdelka, vlogo oddaljene obdelave, odgovornost za spremembe po dobavi ter dejstvo, da »to po FAT ni več naš problem« ni več varna predpostavka.

Najpomembnejša sprememba pa je še bolj temeljna: kibernetski napad ni več zgolj IT-dogodek, temveč postaja scenarij, ki vpliva na funkcionalno varnost stroja. Če lahko nepooblaščena sprememba programa povzroči gibanje osi, obid blokade, spremembo procesnih parametrov ali izgubo varnostne funkcije, potem ne govorimo več o »omrežnem incidentu«. Govorimo o potencialno nenadzorovanem obnašanju stroja — ne glede na to, ali je bil vzrok napaka v konfiguraciji, ranljivost programske opreme ali nameren poseg.

V tem kontekstu enkraten pentest pred FAT ni več dokaz skladnosti, temveč le posnetek stanja sistema v določenem trenutku. CRA zahteva neprekinjen pristop: od zasnove, prek proizvodnje in zagona, do posodobitev, upravljanja ranljivosti, odzivanja na incidente in vzdrževanja v deklariranem obdobju podpore.

V praksi to pomeni odmik od razmišljanja »narejeno = varno« k pristopu »vzdrževano = pod nadzorom«. Brez iluzije, da požarni zid v omari, VPN in certifikat komponente rešijo vse. In brez predpostavke, da se kibernetska varnost konča v trenutku podpisa prevzemnega zapisnika.

V tem članku razčlenjujemo, kaj smernice CRA dejansko spreminjajo za proizvajalce, integratorje in izvajalce modernizacij strojev — ne da bi celotno temo skrčili na geslo »spremenimo geslo in dodajmo potrditveno polje cybersecurity«.

1. Da stroj ne bi spadal pod CRA, bi moral biti skoraj povsem na kontaktorjih

V številnih projektih se področje uporabe CRA preverja z enim vprašanjem:

Ali bo stroj povezan z internetom?

Ne bo.

Torej je zadeva zaključena.

Na shemi so PLC, HMI, nekaj pogonov, porazdeljeni vhodi in izhodi, ventilski otok, varnostni skener ter priključek za nalaganje programa. Krmilnik komunicira s panelom prek PROFINET, s pogoni izmenjuje krmilne in statusne besede, senzorji pa prenašajo podatke prek IO-Link.

Ni pa usmerjevalnika s kartico SIM.

Kot vemo, podatki postanejo podatki šele takrat, ko zapustijo proizvodno halo.

Le da CRA ne sprašuje, ali ima stroj dostop do interneta.

Sprašuje, ali njegov namen ali razumno predvidljiva uporaba vključujeta neposredno ali posredno, logično ali fizično podatkovno povezavo z napravo ali omrežjem. Ni nujno, da gre za povezavo z oblakom, proizvajalčevim strežnikom ali javnim internetom. Lahko poteka po kablu, prek radijskih valov, programskega vmesnika ali kot del večjega sistema.

In zdaj ključno vprašanje: kaj v tipičnem stroju dejansko prenaša podatke?

Ali HMI bere stanja iz PLC in zapisuje nastavitve?

Ali PLC pošilja pogonu krmilno besedo, v odgovor pa prejema hitrost, status in kodo napake?

Ali vhodno-izhodni otok prenaša sliko procesa?

Ali senzor IO-Link pošilja merilno vrednost, identifikator naprave in diagnostične podatke?

Ali safety PLC komunicira z moduli prek PROFIsafe?

Ali se program, strojna konfiguracija ali firmware nalagajo s servisnega prenosnika?

Ali je mogoče recepte, poročila ali posodobitve prenesti prek USB?

Če je odgovor vsaj enkrat »da«, potem imamo zelo verjetno opravka s podatkovno povezavo.

In tega ne spremeni dejstvo, da:

• stroj deluje v lokalnem omrežju,
• nima javnega naslova IP,
• Ethernetni priključek se uporablja samo med zagonom,
• prenosnik priklaplja izključno servis,
• komunikacija poteka samo znotraj krmilnega sistema,
• naročnik je obljubil, da stroja nikoli ne bo povezal z internetom.

CRA ne zajema le uporabe, ki je v navodilih opisana kot osnovna, temveč tudi razumno predvidljivo uporabo. Servisni priključek torej ne preneha prenašati podatkov samo zato, ker je na shemi ob njem dopisano »SERVICE ONLY«.

Smernice Komisije z dne 27. julija 2026 pa uvajajo pomembno razlikovanje.

Ni vsak vodnik in ni vsak električni signal podatkovna povezava.

Če signal služi izključno za vklop, izklop ali napajanje določene funkcije in ne prenaša digitalno kodirane informacije, sama prisotnost dveh električnih stanj še ne zadostuje, da bi ga šteli za podatkovno povezavo.

Tipkalo, ki dovaja napetost na tuljavo kontaktorja, ne postane digitalni vmesnik samo zato, ker je njegovo stanje mogoče opisati kot nič ali ena.

Podobno lahko klasično končno stikalo, vključeno v relejno-kontaktorski tokokrog, tokokrog le prekine ali sklene. Ne prenaša številke naprave, procesne vrednosti, diagnostične kode, različice firmware’a niti telegrama, ki vsebuje več informacij.

Ko pa isto stanje prispe v inteligentno napravo, se kodira, prenese po vodilu, poveže z diagnostiko in ga sprejemnik razlaga kot informacijo, je položaj že drugačen.

Meja torej ne poteka med strojem »online« in »offline«.

Poteka med navadnim krmilnim signalom in izmenjavo digitalno kodiranih informacij.

Zato bi moral stroj, ki naj bi ostal zunaj področja uporabe CRA izključno zaradi odsotnosti podatkovne povezave, v praksi bolj spominjati na klasičen sistem s tipkali, končnimi stikali, releji in kontaktorji kot pa na sodoben projekt, odprt v TIA Portal.

To seveda ni zakonska izjema za kontaktorje.

Mogoče je izdelati preprost stroj s PLC, ki po podrobni analizi ne bo izpolnjeval merila področja uporabe. Prav tako pa je mogoče kontaktnemu sistemu dodati digitalni regulator, servisni vmesnik ali komunikacijski modul in se znajti natanko na drugi strani meje.

Ime komponente ne odloča o zadevi.

Odloča to, kaj izdelek dejansko počne in s čim izmenjuje podatke.

Zato je treba, preden odgovorimo na vprašanje, ali za določen stroj velja uredba EU 2024/2847 (CRA), ugotoviti:

• kje poteka meja ocenjevane naprave,
• katere naprave in programski elementi jo sestavljajo,
• katere fizične in logične vmesnike ima,
• katere informacije se prek njih prenašajo,
• katere povezave so neposredne in katere potekajo prek večjega sistema,
• katere od njih se pojavljajo med normalnim delovanjem, zagonom, diagnostiko, posodobitvijo ali servisom,
• kateri načini uporabe so razumno predvidljivi, tudi če jih proizvajalec raje ne bi predvidel.

Dokler na ta vprašanja ne odgovorimo, ne vemo, ali stroj ostaja zunaj področja uporabe CRA.

Imamo kvečjemu priročen stavek:

»Stroj ni povezan z internetom.«

Težava je v tem, da je to odgovor na vprašanje, ki ga CRA sploh ne postavlja.

PROFINET ni internet. Za CRA mu to sploh ni treba biti.

2. Kibernetska varnost se ne prenaša po PROFINET

Pri številnih projektih se vprašanje skladnosti stroja začne že v fazi nabave.

PLC priznanega proizvajalca.
HMI z aktualnim firmware’om.
Upravljano stikalo.
Industrijski usmerjevalnik z VPN.
Pogoni z varnostnimi funkcijami.
Safety PLC z ustreznim certifikatom.

Za vsako napravo izjava o skladnosti, navodila in nekaj dokumentov z izrazi »secure«, »encrypted« in »defence in depth«.

Na shemi je vse videti profesionalno.

Vendar še vedno ni jasno, ali je celoten stroj kibernetsko varen.

Kajti kibernetska varnost se ne »prenaša« po PROFINET.

To je podobno kot pri ključavnici na vratih:
lahko imate v vsakem prostoru zelo dobro ključavnico, certificirano, preizkušeno, z odlično dokumentacijo in hologramom »secure«, pa to še vedno ne zagotavlja varnosti, če je nekdo vhodna vrata pustil na stežaj odprta, »ker je bilo tako pri zagonu hitreje«.

In popolnoma enako je tukaj: komponente so lahko zgledne, sistem pa je kljub temu lahko … ustvarjalno odprt.

PLC ne »prenaša« varnosti na HMI.
Požarni zid ne »popravlja« logike aplikacije.
Stikalo ne »ureja« uporabniških dostopov.
In dejstvo, da ima vsak element certifikat, še ne pomeni, da celoten stroj ni ena sama velika, vljudno dokumentirana ranljivost.

PROFINET prenaša podatke.

Ne prenaša odgovornosti.
In žal ne prenaša niti zdrave pameti.

CRA zajema tako celovite izdelke kot tudi komponente, dane na trg ločeno. To pomeni, da se lahko krmilnik, operaterski panel ali komunikacijski modul ocenjujejo ločeno. Vendar mora proizvajalec stroja še vedno dokazati, da celota deluje varno v dejanski konfiguraciji pri naročniku — torej v tisti različici, v kateri »zagotovo nihče ni ničesar več spreminjal … kajne?«.

In tu se pojavi najpogostejša napaka.

To je popolnoma enak mehanizem, ki ga že leta poznamo iz varnosti strojev.

Zavesa ima PL e.
Safety PLC ima SIL 3.
Pogon ima STO.

Ali to pomeni, da je celoten stroj samodejno na tej ravni?

Tako kot dejstvo, da vsak element odra izpolnjuje varnostne standarde, še ne zagotavlja, da bo celotna konstrukcija stabilna.

Ne.

Ker je treba še vedno preveriti, kako vse to deluje skupaj — torej opraviti tisto manj priljubljeno fazo »sistemskega razmišljanja«, ki žal nima gumba »auto-certify«.

Pri kibernetski varnosti je popolnoma enako.

Lahko imate »varne« komponente, vendar v praksi:

• operater vidi in lahko spreminja več podatkov, kot jih dejansko potrebuje, ker je bilo »tako bolj priročno«,
• eno servisno geslo deluje na vseh strojih, ker »servis že ve, kaj dela«,
• servisni port je dostopen »za vsak slučaj«, torej pravzaprav za vsak primer,
• oddaljeni dostop zajema celotno omrežje, ker je nekdo nekoč rekel »saj gre samo za diagnostiko«,
• posodobitve je mogoče naložiti brez nadzora, ker »se še nikoli ni nič pokvarilo«,
• naprave si »zaupajo« brez omejitev, ker je zaupanje cenejše od segmentacije,
• integracija pa predpostavlja, da nihče nikoli ne naredi napake, kar je — kot kaže zgodovina — najbolj optimistična predpostavka v inženirstvu.

Vsak element je lahko sam zase pravilen.

Vendar lahko sistem kot celota iz teh pravilnih elementov sestavi nekaj, kar deluje … le ne nujno tako, kot je bilo predvideno.

In to je bistveno: tveganje ni v napravah, temveč v njihovih povezavah, konfiguraciji in v legendarnem dostopu, ki je bil »začasno puščen odprt«.

CRA od proizvajalca stroja zahteva nekaj več kot le zbiranje izjav kot trofej. Zahteva preverjanje, ali je to, kar je bilo sestavljeno iz komponent, kot celota še vedno varno — in ne le to, da »lepo izgleda v tabeli skladnosti«.

V praksi to pomeni preprosta poslovna vprašanja:

• ali ima vsak uporabnik samo tak dostop, ki ga dejansko potrebuje, in ne zato, ker »bi morda kdaj prišel prav«,
• ali je oddaljeni dostop omejen na minimum ali pa na maksimum udobja,
• ali servis nima »polnih pravic povsod«, ker je nekdo ocenil, da to pospeši delo,
• ali omrežje ni ena sama skupna površina, ker segmentacija »zapleta projekt«,
• ali so posodobitve nadzorovane ali pa se jih preprosto »naloži in upa na najboljše«,
• ali je mogoče hitro ugotoviti, kateri stroji so izpostavljeni, ali pa bomo to »preverili po incidentu«,
• ali okvara enega elementa ne odpre celotnega sistema, ker se je »tako izšlo pri integraciji«.

To niso tehnična vprašanja »za inženirje za zahtevne stvari«.

To so vprašanja poslovnega tveganja: zastojev, stroškov, odgovornosti in tiste malenkosti, da mora proizvodnja vendarle delovati.

Zato ni dovolj reči:

»vse komponente so skladne«

Ker to še vedno ne odgovori na vprašanje:

ali je celoten stroj varen pri dejanski uporabi ali pa samo v PowerPointu s pregleda projekta?

Izjava dobavitelja je pomembna.

Vendar se nanaša le na en element — tisti, ki je bil testiran v laboratorijskih pogojih, ne pa v okolju »nekje v hali, z VPN-om, USB-jem in časovnim pritiskom«.

Ne zajema tega, kako je bil uporabljen.
Ne zajema konfiguracije.
Ne zajema integracije.
Ne zajema odločitev, sprejetih »na hitro med zagonom, ker je stranka čakala«.
Ne zajema tega, kaj se dogaja po letih obratovanja, ko se nihče več ne spomni, zakaj je bilo nekaj »začasno odprto«.

Zato se ocena ne more končati pri seznamu naprav.

Na sistem je treba pogledati kot na celoto:

• kdo ima dostop in zakaj (ne pa »ker ga je vedno imel«),
• kaj je res potrebno in kaj je bilo samo »puščeno, ker ni motilo«,
• kje lahko podatki uidejo izpod nadzora, ker je nekdo ocenil, da »gre samo za diagnostiko«,
• kaj se zgodi, če nekdo zakonit dostop uporabi na nezakonit način (torej natanko tako, kot delujejo napadi),
• kako hitro je mogoče ukrepati, ko se pojavi težava, in ne šele »po četrtletnem pregledu«.

Dokler na ta vprašanja ni odgovorov, imamo le nabor zelo solidnih komponent.

Še nimamo varnega stroja.

Skladnost komponent ne ustvari samodejno skladnosti sistema. Skladnost stroja je treba načrtovati, preveriti in — kar je najtežje — ohranjati kljub skušnjavi, da »se ničesar več ne dotikamo, ker deluje«.

3. Kibernetskega napada ne dodajaj na seznam nevarnosti. Poveži obe analizi na pravem mestu

Na trgu strojev je formalna analiza tveganja kibernetske varnosti še vedno prej izjema kot standardni del projekta.

Najpogosteje je prisoten industrijski usmerjevalnik.

Je VPN.

Je geslo za PLC.

Včasih je tudi upravljano stikalo, ki ga pozneje nihče več ne upravlja.

V bolj ambiciozni različici proizvajalec od dobavitelja prejme predstavitev o »defence in depth« in sklene, da je s tem pravkar zaključil analizo tveganja kibernetske varnosti celotnega stroja.

Ni je zaključil.

Kupil je nekaj tehničnih ukrepov.

To še ni analiza.

Zato nima smisla opisovati problema, kot da bi pri vsakem projektu nastali dve profesionalni oceni — ena v skladu z ISO 12100, druga s področja kibernetske varnosti — ki zgolj po naključju nista bili povezani med seboj.

Najpogosteje nastane ena sama.

Ocena tveganja stroja.

Analiza kibernetske varnosti izdelka pa pogosto sploh ne nastane.

Ocena tveganja stroja v skladu z ISO 12100 ne pomeni, da v tabelo preprosto vpišemo:

okvara senzorja → nepričakovano gibanje → zmečkanje.

To je lahko del konkretnega scenarija, ni pa izhodišče.

Najprej je treba določiti omejitve stroja.

Kakšen je njegov predvideni namen uporabe?

Katere so faze življenjskega cikla?

Kdo ga bo uporabljal?

Katera opravila se bodo izvajala med transportom, montažo, zagonom, proizvodnjo, nastavljanjem, čiščenjem, odpravljanjem zastojev, vzdrževanjem, diagnostiko in demontažo?

V katerih načinih lahko stroj deluje?

Kje se med vsako od teh operacij nahaja človek?

Kateri deli stroja so takrat še vedno pod napetostjo, tlakom, obremenitvijo ali v gibanju?

Katera uporaba ni skladna z navodili, vendar je še vedno razumno predvidljiva?

Šele nato se za konkretno nalogo ali operacijo opredeli med drugim:

• vir nevarnosti,
• vrsta nevarnosti,
• območje nevarnosti,
• izpostavljena oseba,
• nevarna situacija,
• nevaren dogodek, če se v danem scenariju pojavi,
• možne posledice in vrsta poškodbe.

Tako je videti analiza tveganja stroja.

Ne začnemo pri komponenti.

Začnemo pri človeku, ki izvaja določeno nalogo na stroju v določenem stanju. ISO 12100 določa prav takšno metodologijo za prepoznavanje nevarnosti ter za ocenjevanje in vrednotenje tveganja v ustreznih fazah življenjskega cikla stroja.

Vzemimo preprost primer.

Operater odstranjuje zagozden kos iz notranjosti paletizacijske celice.

Torej imamo:

Naloga: odprava zastoja.

Faza uporabe: obratovanje, poseg po zaustavitvi procesa.

Način delovanja: ročni ali servisni.

Izpostavljena oseba: operater ali vzdrževalec.

Območje nevarnosti: notranjost celice, zlasti prostor med prijemalom, kosom in konstrukcijo stroja.

Vir nevarnosti: mehanska energija robota, linearne osi ali pnevmatskega prijemala.

Nevarna situacija: človek se nahaja v območju, medtem ko je izvedba gibanja še vedno mogoča.

Nevaren dogodek: nepričakovano gibanje osi, zapiranje prijemala ali sprostitev akumulirane energije.

Možna posledica: udarec, zmečkanje, zlom ali amputacija.

Šele zdaj je mogoče oceniti tveganje in določiti ukrepe za njegovo zmanjšanje.

Morda bo potrebna blokada varovala.

Morda bo potrebna varna zaustavitev.

Morda bo treba preprečiti nepričakovani zagon.

Morda bo treba odvesti pnevmatsko energijo.

Morda se bo gibanje v ročnem načinu smelo izvajati izključno z omogočitveno napravo in pri varno omejeni hitrosti.

To je še vedno klasična ocena tveganja stroja.

Kje se torej pojavi kibernetska varnost?

Ne kot nova postavka ob mehanski, električni in toplotni nevarnosti.

»Heker« ni vir mehanske nevarnosti

Dopis v tabelo ISO 12100 v obliki:

Nevarnost: kibernetski napad

ne prispeva veliko.

Kibernetski napad ni vrteča se gred, oster rob, visoka temperatura ali pnevmatska energija.

Prav tako ni ločeno območje nevarnosti.

Operater ne utrpi zmečkanja zaradi ranljivosti CVE.

Utrpi ga zaradi elementa stroja, ki se je premaknil, ko je bil človek na napačnem mestu.

Kibernetski napad pa lahko spremeni stanje krmilnega sistema, podatke, program, konfiguracijo ali način delovanja zaščitnega ukrepa.

Zato lahko postane:

• vzrok nevarnega dogodka,
• dodatna pot, ki vodi do nevarne situacije,
• vzrok za izgubo učinkovitosti ukrepa za zmanjšanje tveganja,
• ali način obida predpostavk, sprejetih pri načrtovanju varnostnih funkcij.

In prav tu je pravo stičišče.

Ne seznam nevarnosti.

Temveč obnašanje stroja.

Analiza kibernetske varnosti mora nastati ločeno

Za stroj ali sistem industrijske avtomatizacije bo analiza kibernetske varnosti imela drugačno strukturo kot ocena tveganja po ISO 12100.

Najbolj naravno ogrodje za sistem industrijske avtomatizacije zagotavlja IEC 62443-3-2.

Standard med drugim zahteva:

• opredelitev sistema, ki je predmet analize, torej SUC,
• razdelitev sistema na cone in komunikacijske kanale,
• oceno tveganja za posamezne cone in kanale,
• določitev ciljnih ravni varnosti SL-T,
• dokumentiranje varnostnih zahtev.

To je povsem drugačno izhodišče kot pri ISO 12100.

V IEC 62443 se med drugim sprašujemo:

Kaj natančno spada v analizirani sistem?

Katera sredstva je treba zaščititi?

Katere naprave, aplikacije in vmesniki so v sistemu?

Kateri elementi bi morali spadati v isto cono?

Kako poteka komunikacija med conami?

Kdo lahko pridobi dostop?

S katere lokacije?

Prek katerega vmesnika?

Katere ranljivosti je mogoče izkoristiti?

Kateri podatki, funkcije ali komponente se lahko spremenijo?

Po kateri poti lahko napadalec pride od servisnega usmerjevalnika do PLC, HMI, pogona ali inženirske postaje?

Kakšne bodo posledice izgube zaupnosti, celovitosti ali razpoložljivosti?

Kateri zaščitni ukrepi so potrebni?

Za proces varnega razvoja izdelka ter zahteve, ki veljajo za same komponente, so pomembni tudi drugi deli te serije, zlasti IEC 62443-4-1 in IEC 62443-4-2. IEC 62443-3-3 pa ureja tehnične varnostne zahteve na ravni sistema.

CRA danes proizvajalcu ne nalaga, da bi na naslovnico analize napisal »izvedeno v skladu z IEC 62443«.

IEC 62443 prav tako ne nadomešča dokazovanja skladnosti z zahtevami CRA.

Za industrijski avtomatizacijski sistem pa je to bistveno bolj logično izhodišče kot poskus, da bi v preglednico ISO 12100 dopisali nekaj hekerskih scenarijev.

Ker obe metodologiji odgovarjata na različna vprašanja.

ISO 12100:

Pri kateri nalogi, kje, iz katerega vira in zaradi katerega dogodka lahko človek utrpi škodo?

IEC 62443:

Kdo, po kateri poti in z izkoriščanjem katere ranljivosti lahko vpliva na sistem, njegove podatke ali funkcije?

Šele nato je treba preveriti, ali odgovor iz druge analize spremeni scenarij iz prve.

Isti scenarij, dve različni analizi

Vrnimo se k operaterju, ki odstranjuje zagozden kos.

Analiza tveganja v skladu z ISO 12100 je pokazala, da človek vstopa v območje, kjer ga lahko zmečka gibanje robota ali prijemala.

Ukrepi za zmanjšanje tveganja so zaklenjeno varovalo, funkcija varne zaustavitve ter lokalni reset, nameščen zunaj nevarnega območja.

Zdaj izvedemo analizo kibernetske varnosti sistema.

Prepoznamo:

• usmerjevalnik, ki se uporablja za oddaljeni servis,
• servisni račun,
• inženirski prenosnik,
• HMI,
• standardni PLC,
• varnostni PLC,
• pogone,
• programski vmesnik,
• omrežje PROFINET in komunikacijo PROFIsafe,
• mehanizme za nalaganje programa in konfiguracije.

Obravnavamo scenarij:

Prevzem servisnega računa omogoča oddaljeni dostop do standardnega PLC in pošiljanje ukaza za gibanje, medtem ko je človek prisoten v celici.

Ali ta scenarij vodi do nevarnega dogodka?

Na to ni mogoče odgovoriti zgolj na podlagi dejstva, da je bil PLC prevzet.

Preveriti je treba arhitekturo varnostne funkcije.

Če odpiranje varovala nadzira varnostni PLC, funkcija varno odklopi navor pogonov, je reset mogoč samo lokalno, standardni PLC pa ne more ponovno vzpostaviti gibanja ne glede na stanje varnostne funkcije, potem lahko prevzem standardnega krmilnika ustavi proizvodnjo ali poškoduje proces.

Vendar ne bi smel povzročiti gibanja pri odprtem varovalu.

V tem primeru kibernetska analiza pokaže napad.

Ocena tveganja stroja pokaže mehansko nevarnost.

Pravilno zasnovana varnostna funkcija pa vendarle prekine pot med njima.

Zdaj pa še druga različica.

Servisni način se izbira na ravni običajnega HMI.

Vrednost omejene hitrosti prihaja iz standardnega PLC.

Oddaljeni serviser lahko izvede reset.

Isti inženirski račun omogoča spremembo programa standardnega krmilnika in varnostne konfiguracije.

Kopija varnostnega programa ni povezana s konkretno različico stroja.

Po posegu nihče ne preveri kontrolne vsote.

Parametre pogona je mogoče spreminjati na daljavo.

V takšni arhitekturi prevzem računa ne pomeni več zgolj izgube zaupnosti ali kratkega zastoja.

Lahko spremeni pogoje, na katerih je temeljilo zmanjšanje tveganja.

Lahko privede do:

• izbire napačnega načina,
• spremembe parametra varnega gibanja,
• nepooblaščenega reseta,
• nalaganja neodobrene konfiguracije,
• ali oslabitve funkcije, ki naj bi preprečila nepričakovan zagon.

In takrat je treba kibernetski scenarij povezati s konkretnim scenarijem varnosti stroja:

naloga odstranjevanja zastoja → človek v nevarnem območju → nepooblaščena sprememba krmilnega sistema ali zaščitne funkcije → nepričakovano gibanje → zmečkanje.

Vir nevarnosti se ni spremenil.

Še vedno je to mehanska energija stroja.

Nevarno območje se ni spremenilo.

Še vedno je znotraj celice.

Možna posledica se ni spremenila.

Še vedno gre za poškodbo operaterja.

Spremenila pa se je pot, ki vodi do nevarnega dogodka.

Vsaka ranljivost ne sodi v ISO 12100

Tudi to razlikovanje je enako pomembno.

Predpostavimo, da ranljivost v HMI omogoča branje zgodovinskih proizvodnih podatkov.

To je lahko pomembna težava z vidika CRA.

Lahko pomeni kršitev zaupnosti podatkov.

Lahko zahteva posodobitev, oceno vpliva, ukrepanje do uporabnikov in v določenih okoliščinah tudi poročanje.

Če pa ne vpliva na obnašanje stroja, ne spremeni zaščitnega ukrepa in ne more pripeljati do nevarne situacije, je nima smisla na silo vključevati v oceno tveganja po ISO 12100.

Podobno lahko napad, ki povzroči zgolj nedostopnost proizvodnih poročil, pomeni poslovni problem in problem skladnosti s CRA.

Ni pa nujno, da ustvarja tveganje za operaterja.

Po drugi strani ima lahko na videz nedolžna možnost spremembe ene same nastavljene vrednosti majhen pomen za zaupnost podatkov, a ogromen pomen za fizično varnost.

Na primer takrat, ko ta vrednost določa:

• največjo hitrost osi,
• silo pritiska,
• temperaturo procesa,
• tlak,
• položaj zaustavitve,
• čas odprtja ventila,
• ali dopustno mejo med delovanjem z odprtim varovalom.

Zato kibernetske grožnje ne razvrščamo glede na to, kako tehnično zveni.

Gledamo, kaj lahko dejansko povzroči na stroju.

Uredba o strojih zahteva ta most

Ta povezava ni zgolj dobra inženirska praksa.

Točka 1.2.1 Priloge III k uredbi o strojih zahteva, da so krmilni sistemi zasnovani in izdelani tako, da preprečujejo nastanek nevarnih situacij, tudi zaradi razumno predvidljivih zlonamernih poskusov tretjih oseb.

Po drugi strani CRA navaja, da lahko njegove bistvene zahteve glede kibernetske varnosti podpirajo dokazovanje skladnosti med drugim z zahtevama 1.1.9 in 1.2.1 uredbe o strojih.

Vendar se to ne zgodi samodejno.

Proizvajalec mora to povezavo dokazati na podlagi ocene tveganja. Ugotavljanje skladnosti po CRA in ugotavljanje skladnosti po uredbi o strojih še vedno ostajata ločena postopka.

Torej ni dovolj pripraviti:

• analizo tveganja v skladu z ISO 12100,
• analizo IEC 62443,
• dve ločeni poročili,
• in upati, da bo podobnost številk standardov med njima ustvarila revizijsko sled.

Potrebna je povezava.

Za vsak pomemben kibernetski scenarij je treba določiti:

1. kateri element ali funkcijo je mogoče prevzeti ali spremeniti,
2. kakšno obnašanje stroja lahko to povzroči,
3. ali to obnašanje vodi v nevarno situacijo ali nevaren dogodek,
4. na katero nalogo in katero nevarno območje se nanaša,
5. katera možna posledica je bila navedena v oceni ISO 12100,
6. kateri ukrep za zmanjšanje tveganja mora prekiniti razvoj scenarija,
7. ali ta ukrep ostane učinkovit tudi po prevzemu napadenega elementa.

Ta zadnja točka je najpomembnejša.

Kajti če sta napad in zaščita odvisna od:

• istega krmilnika,
• istega računa,
• istega omrežja,
• iste iste inženirske postaje,
• ali istega programa,

potem morda nimamo dveh neodvisnih zaščitnih plasti.

Imamo eno plast, opisano v dveh dokumentih.

Zato ne potrebujemo ene ogromne tabele z naslovom:

»ocena tveganja safety & cybersecurity«.

Potrebujemo dve pravilno izvedeni analizi, pripravljeni z ustreznimi metodami, ter nadzorovano stičišče med njima.

ISO 12100 mora opisati človeka, nalogo, vir nevarnosti, območje, nevarno situacijo, nevaren dogodek in možno škodo.

IEC 62443 mora pomagati opisati sistem, njegova območja, komunikacijske poti, sredstva, grožnje, ranljivosti, poti napada in zahtevane zaščitne ukrepe.

Proizvajalec pa mora dokazati, ali lahko scenarij iz druge analize sproži scenarij iz prve ali pa odvzame učinkovitost ukrepu, ki bi ga moral zaustaviti.

Kibernetski napad ni nujno, da ustvari novo nevarnost. Dovolj je, da odpre novo pot do stare nesreče.

4. Pentest pred FAT je fotografija. CRA zahteva film

V številnih projektih se kibernetska varnost pojavi dva tedna pred FAT.

Naroči se pentest.

Nastane poročilo.

Kritične ranljivosti se odpravijo, srednje se sprejmejo, dokument pa se odloži v projektno mapo.

Stroj je kibernetsko varen.

Do naslednjega torka.

Pentest je lahko zelo dragocen element preverjanja. Vendar pokaže stanje konkretne različice izdelka, v konkretni konfiguraciji in ob uporabi določenih testnih scenarijev.

Ne odgovori pa na vprašanje, kaj bo proizvajalec storil pozneje.

CRA pa zadeva celoten življenjski cikel izdelka. Ocena tveganja kibernetske varnosti mora vplivati na načrtovanje, zasnovo, razvoj, proizvodnjo, dobavo in vzdrževanje izdelka. Po dajanju na trg mora proizvajalec obravnavati ranljivosti v deklariranem obdobju podpore.

Vrnimo se k stroju za pakiranje zelenjave.

Stroj je uspešno prestal FAT.

Pentest ni pokazal kritičnih ranljivosti.

Osem mesecev pozneje proizvajalec servisnega usmerjevalnika objavi informacijo o ranljivosti, ki omogoča prevzem naprave.

In takrat se začne pravo delo.

Kateri dobavljeni stroji imajo ta model usmerjevalnika?

Katera različica firmware’a je bila nameščena v vsakem primerku?

Ali je oddaljeni dostop aktiven?

Ali je ranljivost mogoče izkoristiti v dejanski konfiguraciji?

Ali prevzem usmerjevalnika omogoča dostop samo do diagnostike ali tudi do HMI, PLC, pogonov in safety PLC?

Ali je mogoč samo vpogled v podatke ali tudi sprememba programa oziroma parametrov?

Ali lahko napad vpliva na varnostno funkcijo?

Ali je dobavitelj objavil popravek?

Ali bo posodobitev usmerjevalnika spremenila certifikate, komunikacijska pravila ali način vzpostavljanja tunela?

Ali je treba po posodobitvi znova preveriti oddaljeni servis, komunikacijo in del varnostnih funkcij?

Katere stranke je treba obvestiti?

In ali položaj izpolnjuje merila za prijavo aktivno izkoriščane ranljivosti ali resnega incidenta?

Poročilo o penetracijskem testu, izvedenem pred FAT-om, ne bo odgovorilo na nobeno od teh vprašanj.

Opisuje stroj, ki ne obstaja več.

Od časa testiranja so se namreč spremenile različice programske opreme, konfiguracije, uporabniško okolje in poznavanje ranljivosti.

Zato proizvajalec ne potrebuje le testa, temveč proces:

• prepoznavanja različic strojne opreme, vdelane programske opreme in programske opreme v vsakem dobavljenem primerku,
• spremljanja informacij o ranljivostih,
• ocenjevanja njihove izkoriščenosti v dejanski arhitekturi,
• preverjanja možnih posledic za proces in varnost stroja,
• priprave in testiranja posodobitev,
• obveščanja uporabnikov,
• dokumentiranja sprejetih odločitev,
• obravnave zahtevanih prijav.

Od 11. septembra 2026 morajo proizvajalci poročati o aktivno izkoriščanih ranljivostih in resnih incidentih, ki vplivajo na varnost proizvodov z digitalnimi elementi. Predhodno opozorilo je treba posredovati v 24 urah, popolno prijavo pa v 72 urah.

To pomeni, da po odkritju težave ne bo časa za to, da bi šele začeli iskati:

»Kdo je pravzaprav izdelal ta usmerjevalnik in kje imamo seznam strojev, v katere smo ga vgradili?«

IEC 62443-4-1 jasno pokaže razliko med enkratno zaščito proizvoda in varnim ciklom njegovega razvoja. Ne zajema le načrtovanja in preverjanja, temveč tudi upravljanje napak, popravkov in konca življenjske dobe proizvoda.

FAT lahko torej zaključi fazo projekta.

Ne zaključi življenjskega cikla proizvoda.

Ne zaključi obdobja podpore.

Ne konča spremljanja ranljivosti.

In ne pomeni, da konfiguracija na dan prevzema ostane zamrznjena za naslednjih petnajst let.

Stroj lahko dolgo časa pakira zelenjavo za supermarkete.

Proizvajalec pa njegove kibernetske varnosti ne more zapakirati skupaj z navodili, oviti v folijo in šteti, da je bila dobavljena enkrat za vselej.

Penetracijski test lahko zapre eno točko na seznamu FAT. CRA pa odpre proces, ki traja do konca obdobja podpore proizvoda.