CRA masinatootjatele pärast komisjoni 27. juuli 2026. aasta suuniseid. Mida tuleb tegelikult rakendada?

Aastaid sai masina küberturvalisuse kokku võtta kolme sammuga: tuntud tootja kontroller, VPN „sest nii tehakse” ja klassikaline „klient kindlustab võrgu ise”. Kui keegi lisas elektrikappi veel tulemüüri, peeti teemat sageli lahendatuks — vähemalt seni, kuni keegi proovis vaadata, mis juhtub päris ründe korral, mitte esitlusslaididel.

Aga küberturvalisus ei liigu mööda PROFINETi iseenesest. Komponentidel võivad olla sertifikaadid, deklaratsioonid ja turundusbrošüüris „secure by design”, kuid masin tervikuna võib siiski olla etteaimatav viisil, millel pole turvalisusega midagi pistmist. Nii nagu ohutusrelee ei tee süsteemi ohutuks, kui juhtloogika võimaldab sellest mööda minna, ei lahenda ka „turvaline” HMI arhitektuuri, integratsiooni, õiguste, uuenduste ega selle probleemi, mis juhtub siis, kui keegi enam luba ei küsi.

CRA (Cyber Resilience Act, Euroopa Parlamendi ja nõukogu määrus (EL) 2024/2847) ei ole IT lisakiht. See on tootemäärus, mis siseneb masina elutsüklisse küsimata automaatikaosakonna nõusolekut. See hõlmab juhtimissüsteemi projekteerimist, riskianalüüsi, tarneahelat, konfiguratsiooni, uuendusi ning ka toote hooldust kaua pärast seda, kui FAT on allkirjastatud ja masin on tootmishallist lahkunud. Ja ei, väide „me ei ühenda seda internetti” ei lõpeta seda teemat. Praktikas piisab hoolduslaptopist, USB-mälupulgast, „ajutisest” kaugdiagnostikast või integratsioonist tehase süsteemiga, et piir eraldatuse ja avatuse vahel kaoks.

Komisjoni 27. juuli 2026 suunised ei muutnud määrust ennast, kuid piirasid tõhusalt tõlgendusruumi, mis varem võimaldas käsitleda küberturvalisust valikulise kihina. Täpsustati muu hulgas toote piiri, kaugandmetöötluse rolli, vastutust tarnejärgsete muudatuste eest ning seda, et „see ei ole pärast FAT-i enam meie probleem” ei ole enam turvaline eeldus.

Kõige olulisem muutus on siiski veel põhimõttelisem: küberrünne lakkab olemast pelgalt IT-sündmus ja muutub stsenaariumiks, mis mõjutab masina funktsionaalohutust. Kui programmi volitamata muutmine võib põhjustada telje liikumise, blokeeringust möödahiilimise, protsessiparameetrite muutmise või ohutusfunktsiooni kadumise, siis ei räägi me enam „võrguintsidendist”. Me räägime masina potentsiaalselt kontrollimatust käitumisest — sõltumata sellest, kas põhjuseks oli konfiguratsiooniviga, tarkvara haavatavus või tahtlik sekkumine.

Selles kontekstis lakkab ühekordne pentest enne FAT-i olemast vastavuse tõend ja on vaid hetkepilt süsteemi seisust kindlal ajahetkel. CRA nõuab pidevat lähenemist: alates projekteerimisest, läbi tootmise ja kasutuselevõtu, kuni uuenduste, haavatavuste haldamise, intsidentidele reageerimise ja hoolduseni deklareeritud tugiperioodi jooksul.

Praktikas tähendab see loobumist mõtteviisist „tehtud = turvaline” ja üleminekut põhimõttele „hallatud = kontrolli all”. Ilma illusioonita, et elektrikapis olev tulemüür, VPN ja komponendi sertifikaat lõpetavad teema. Ja ilma eelduseta, et küberturvalisus lõpeb vastuvõtuakti allkirjastamise hetkel.

Selles artiklis võtame lahti, mida CRA suunised tootjate, integraatorite ja masinaid moderniseerivate ettevõtete jaoks tegelikult muudavad — ilma et taandaksime kogu teema loosungile „vahetame parooli ära ja lisame cybersecurity märkeruudu”.

1. Et masin CRA alla ei kuuluks, peaks see olema peaaegu ainult kontaktoritel

Paljudes projektides kontrollitakse CRA kohaldamisala ühe küsimusega:

Kas masin ühendatakse internetti?

Ei ühendata.

Järelikult on teema lõpetatud.

Skeemil on PLC, HMI, mitu ajamit, hajutatud sisendid ja väljundid, ventiilisaar, ohutusskanner ning port programmi laadimiseks. Kontroller suhtleb paneeliga PROFINETi kaudu, vahetab ajamitega juht- ja olekusõnu ning andurid edastavad andmeid IO-Linki kaudu.

Aga SIM-kaardiga ruuterit ei ole.

Nagu teada, muutuvad andmed andmeteks alles siis, kui need tootmishallist välja lähevad.

Aga CRA ei küsi, kas masinal on internetiühendus.

See küsib, kas masina ettenähtud otstarve või mõistlikult ettenähtav kasutus hõlmab otsest või kaudset, loogilist või füüsilist andmesidet seadme või võrguga. See ei pea olema ühendus pilve, tootja serveri ega avaliku internetiga. See võib toimuda kaabli kaudu, raadioside teel, tarkvaraliidese kaudu või suurema süsteemi osana.

Ja nüüd võtmeküsimus: mis tüüpilises masinas tegelikult andmeid edastab?

Kas HMI loeb PLC olekuid ja kirjutab seadistusi?

Kas PLC saadab ajamile juhtsõna ning saab vastuseks kiiruse, oleku ja veakoodi?

Kas sisendite ja väljundite saar edastab protsessipilti?

Kas IO-Linki andur saadab mõõteväärtuse, seadme identifikaatori ja diagnostikaandmed?

Kas safety PLC suhtleb moodulitega PROFIsafe’i kaudu?

Kas programm, riistvarakonfiguratsioon või püsivara laaditakse hoolduslaptopist üles?

Kas retsepte, aruandeid või uuendusi saab üle kanda USB kaudu?

Kui vastus kasvõi ühel korral on „jah”, siis on suure tõenäosusega tegemist andmesidega.

Ja seda ei muuda asjaolu, et:

• masin töötab kohalikus võrgus,
• avalikku IP-aadressi ei ole,
• Etherneti porti kasutatakse ainult kasutuselevõtu ajal,
• sülearvuti ühendab ainult hoolduspersonal,
• side toimub ainult juhtimissüsteemi sees,
• klient lubas, et ei ühenda masinat kunagi internetti.

CRA hõlmab mitte ainult kasutust, mida juhendis on kirjeldatud põhikasutusena, vaid ka mõistlikult ettenähtavat kasutust. Seega ei lakka hooldusport andmeid edastamast ainult sellepärast, et skeemile on selle juurde kirjutatud „SERVICE ONLY”.

Komisjoni 27. juuli 2026 suunised toovad siiski sisse olulise eristuse.

Mitte iga juhe ega iga elektrisignaal ei ole andmesideühendus.

Kui signaal on mõeldud üksnes kindla funktsiooni sisse- või väljalülitamiseks või toitega varustamiseks ega edasta digitaalselt kodeeritud teavet, siis ainuüksi kahe elektrilise oleku olemasolust ei piisa veel selleks, et pidada seda andmesideühenduseks.

Nupp, mis annab pinge kontaktori mähisele, ei muutu digitaalseks liideseks ainult seetõttu, et selle olekut saab kirjeldada nulli või ühena.

Samamoodi võib klassikaline piirlüliti, mis on ühendatud relee-kontaktori ahelasse, üksnes ahela katkestada või sulgeda. See ei edasta seadme numbrit, protsessiväärtust, diagnostikakoodi, firmware’i versiooni ega mitut teavet sisaldavat telegrammi.

Kuid kui sama olek jõuab intelligentsesse seadmesse, kodeeritakse, edastatakse siinivõrgu kaudu, seotakse diagnostikaga ja tõlgendatakse vastuvõtja poolt teabena, on olukord juba teine.

Piir ei jookse seega „online”- ja „offline”-masina vahel.

See jookseb tavalise juhtsignaali ja digitaalselt kodeeritud teabe vahetamise vahel.

Seetõttu peaks masin, mis jääks praktikas CRA kohaldamisalast välja ainult andmesideühenduse puudumise tõttu, sarnanema pigem klassikalise nuppude, piirlülitite, releede ja kontaktoritega lahendusega kui tänapäevase projektiga, mida avatakse TIA Portal’is.

See ei ole muidugi kontaktorite jaoks ette nähtud seaduslik erand.

Võimalik on ehitada lihtne PLC-ga masin, mis pärast üksikasjalikku analüüsi ei vasta kohaldamisala kriteeriumile. Samuti võib kontaktorlahendusele lisada digitaalse regulaatori, hooldusliidese või sidemooduli ja sattuda täpselt teisele poole seda piiri.

Komponendi nimi ei otsusta seda küsimust.

Otsustav on see, mida toode tegelikult teeb ja millega ta andmeid vahetab.

Seetõttu tuleb enne vastamist küsimusele, kas konkreetne masin kuulub CRA alla, kindlaks teha:

• kus jookseb hinnatava toote piir,
• millised seadmed ja tarkvaraelemendid selle koosseisu kuuluvad,
• millised füüsilised ja loogilised liidesed sellel on,
• millist teavet nende kaudu edastatakse,
• millised ühendused on otsesed ja millised toimuvad suurema süsteemi kaudu,
• millised neist esinevad tavapärase töö, kasutuselevõtu, diagnostika, uuendamise või hoolduse ajal,
• millised kasutusviisid on mõistlikult ettenähtavad, isegi kui tootja eelistaks neid mitte ette näha.

Kuni neile küsimustele ei ole vastatud, ei tea me, kas masin jääb CRA kohaldamisalast välja.

Parimal juhul on meil lihtsalt mugav lause:

„Masin ei ole internetiga ühendatud”.

Aga see on vastus küsimusele, mida CRA ei esita.

PROFINET ei ole internet. CRA jaoks ei peagi see seda olema.

2. Küberturvalisus ei levi mööda PROFINETi

Paljudes projektides algab masina nõuetele vastavuse teema juba hankefaasis.

PLC tunnustatud tootjalt.
HMI ajakohase firmware’iga.
Hallatav switch.
Tööstusruuter VPN-iga.
Ajami(d) ohutusfunktsioonidega.
Safety PLC vastava sertifikaadiga.

Iga seadme juurde kuuluvad vastavusdeklaratsioon, juhend ja mitu dokumenti märksõnadega „secure”, „encrypted” ning „defence in depth”.

Skeemil näeb kõik professionaalne välja.

Aga endiselt ei ole teada, kas terviklik masin on küberturvaline.

Sest küberturvalisus ei „kandu edasi” mööda PROFINETi.

See on natuke nagu ukselukuga:
igal toal võib olla väga hea lukk, sertifitseeritud, testitud, suurepärase dokumentatsiooni ja „secure”-hologrammiga, kuid see ei taga ikkagi turvalisust, kui keegi jättis välisukse pärani lahti, „sest nii oli kasutuselevõtul kiirem”.

Ja täpselt samamoodi on ka siin: komponendid võivad olla eeskujulikud, kuid süsteem ise võib ikkagi olla… loominguliselt avatud.

PLC ei „anna” turvalisust edasi HMI-le.
Firewall ei „paranda” rakendusloogikat.
Switch ei „korrasta” kasutajate juurdepääsu.
Ja see, et igal elemendil on sertifikaat, ei tähenda veel, et kogu masin ei oleks üks suur, viisakalt dokumenteeritud haavatavus.

PROFINET edastab andmeid.

See ei edasta vastutust.
Ja kahjuks ei edasta see ka tervet mõistust.

CRA hõlmab nii terviktooteid kui ka komponente, mis lastakse turule eraldi. See tähendab, et kontrollerit, operaatoripaneeli või sidemoodulit võib hinnata eraldi. Kuid masina tootja peab endiselt tõendama, et tervik toimib ohutult reaalses kliendikonfiguratsioonis — ehk selles versioonis, kus keegi „kindlasti ei muutnud enam midagi… eks?”.

Ja siin ilmneb kõige sagedasem viga.

See on täpselt sama mehhanism, mida me tunneme juba aastaid masinaohutuse riskianalüüsist.

Kardinlülitil on PL e.
Safety PLC-l on SIL 3.
Ajamil on STO.

Kas see tähendab, et kogu masin on automaatselt samal tasemel?

See on umbes sama nagu tellingute puhul: asjaolu, et iga üksik element vastab ohutusnõuetele, ei taga veel, et kogu konstruktsioon oleks stabiilne.

Ei.

Sest endiselt tuleb kontrollida, kuidas see kõik koos töötab — ehk läbida see vähepopulaarne „süsteemse mõtlemise” etapp, millel paraku puudub nupp „auto-certify”.

Küberturvalisuses on täpselt samamoodi.

Võid omada „turvalisi” komponente, kuid praktikas:

• näeb operaator rohkem andmeid ja saab neid rohkem muuta, kui tal tegelikult vaja on, sest „nii oli mugavam”,
• üks hooldusparool töötab kõigil masinatel, sest „hooldus teab niikuinii, mida teeb”,
• hooldusport on ligipääsetav „igaks juhuks”, ehk sisuliselt iga juhu jaoks,
• kaugjuurdepääs hõlmab kogu võrku, sest keegi ütles kunagi „see on ju ainult diagnostika”,
• uuendusi saab laadida sisse ilma kontrollita, sest „midagi pole ju kunagi katki läinud”,
• seadmed „usaldavad üksteist” piiranguteta, sest usaldus on odavam kui segmenteerimine,
• ja integratsioon eeldab, et keegi ei tee kunagi viga, mis on — nagu ajalugu näitab — inseneerias kõige optimistlikum eeldus üldse.

Iga element eraldi võib olla korrektne.

Kuid süsteem tervikuna võib neist korrektsetest elementidest kokku panna midagi, mis töötab… ainult mitte tingimata nii, nagu algselt eeldati.

Ja see ongi oluline: risk ei peitu seadmetes endis, vaid nende ühendamises, konfiguratsioonis ja selles legendaarses „ajutiselt lahti jäetud” ligipääsus.

CRA nõuab masina tootjalt enamat kui deklaratsioonide kogumist nagu trofeesid. See nõuab kontrollimist, kas komponentidest kokku pandud tervik on endiselt ohutu ka süsteemina — mitte ainult seda, et see „näeb vastavustabelis kena välja”.

Praktikas tähendab see lihtsaid, ärilisi küsimusi:

• kas igal kasutajal on ainult selline ligipääs, mida tal päriselt vaja on, mitte „äkki läheb kunagi tarvis”,
• kas kaugjuurdepääs on viidud miinimumini või hoopis maksimaalse mugavuseni,
• kas hooldusel ei ole „täisõigusi kõikjal”, sest keegi arvas, et nii on elu kiirem,
• kas võrk ei ole üks ühine tasapind lihtsalt seetõttu, et segmenteerimine „teeb projekti keerulisemaks”,
• kas uuendused on kontrollitud või pigem „laseme peale ja loodame parimat”,
• kas on võimalik kiiresti tuvastada, millised masinad on ohustatud, või pigem „vaatame pärast intsidenti”,
• kas ühe elemendi rike ei ava kogu süsteemi, sest „integratsioonis lihtsalt kujunes nii”.

Need ei ole tehnilised küsimused „inseneridele, kes tegelevad keeruliste asjadega”.

Need on küsimused äririski kohta: seisakud, kulud, vastutus ja see väike detail, et tootmine peab siiski toimima.

Seetõttu ei piisa sellest, kui öelda:

„kõik komponendid on nõuetele vastavad”

Sest see ei vasta endiselt küsimusele:

kas kogu masin on reaalses kasutuses ohutu või ainult projektiülevaatuse PowerPointis?

Tarnija deklaratsioon on oluline.

Kuid see puudutab ainult üht elementi — seda, mida parasjagu laboritingimustes testiti, mitte keskkonnas „kusagil tootmishallis, koos VPN-i, USB ja ajasurvega”.

See ei hõlma seda, kuidas seda kasutati.
See ei hõlma konfiguratsiooni.
See ei hõlma integratsiooni.
See ei hõlma otsuseid, mis tehti „kiiruga kasutuselevõtu ajal, sest klient ootas”.
See ei hõlma seda, mis juhtub pärast aastatepikkust kasutust, kui keegi enam ei mäleta, miks miski oli „ajutiselt avatud”.

Seetõttu ei saa hindamine lõppeda seadmete nimekirjaga.

Tuleb vaadata süsteemi tervikuna:

• kellel on ligipääs ja miks (mitte „sest tal on see alati olnud”),
• mis on tegelikult vajalik ja mis on lihtsalt „jäetud alles, sest ei seganud”,
• kus võivad andmed kontrolli alt väljuda, sest keegi leidis, et „see on ainult diagnostika”,
• mis juhtub siis, kui keegi kasutab seaduslikku ligipääsu ebaseaduslikul viisil (ehk täpselt nii, nagu ründed toimivad),
• kui kiiresti on võimalik reageerida, kui probleem tekib, mitte alles „pärast kvartaalset ülevaatust”.

Kuni neile küsimustele vastuseid ei ole, on meil ainult komplekt väga korralikke komponente.

Turvalist masinat meil veel ei ole.

Komponentide vastavus ei loo automaatselt süsteemi vastavust. Masina vastavus tuleb kavandada, kontrollida ja — mis on kõige keerulisem — hoida seda alles hoolimata kiusatusest „mitte enam midagi puutuda, sest see ju töötab”.

3. Ära lisa küberrünnakut lihtsalt ohtude nimekirja. Ühenda kaks analüüsi õiges kohas

Masinaturul on küberturvalisuse formaalne riskianalüüs endiselt pigem erand kui projekti tavapärane osa.

Tavaliselt on olemas tööstusruuter.

On olemas VPN.

On olemas PLC parool.

Mõnikord on olemas hallatav switch, mida hiljem keegi enam ei halda.

Ambitsioonikamas variandis saab tootja tarnijalt esitluse teemal „defence in depth” ja järeldab, et sellega on kogu masina küberturvalisuse riskianalüüs tehtud.

Ei ole tehtud.

Ta on ostnud mõned tehnilised meetmed.

See ei ole veel analüüs.

Seega ei ole mõtet kirjeldada probleemi nii, nagu igas projektis valmiks kaks professionaalset hinnangut — üks vastavalt ISO 12100-le, teine küberturvalisuse kohta — mida lihtsalt juhuslikult omavahel ei ühendatud.

Kõige sagedamini koostatakse üks.

Masina riskianalüüs.

Toote küberturvalisuse analüüsi aga ei koostata üldse.

Masina riskianalüüs vastavalt ISO 12100 ei seisne selles, et tabelisse kirjutatakse:

anduri rike → ootamatu liikumine → muljumine.

See võib olla ühe konkreetse stsenaariumi osa, kuid mitte lähtepunkt.

Kõigepealt tuleb määratleda masina piirangud.

Mis on selle ettenähtud kasutus?

Millised on elutsükli etapid?

Kes seda kasutama hakkab?

Milliseid ülesandeid tehakse transpordi, paigalduse, kasutuselevõtu, tootmise, seadistamise, puhastamise, kinnikiilumiste kõrvaldamise, hoolduse, diagnostika ja demonteerimise ajal?

Millistes töörežiimides võib masin töötada?

Kus asub inimene iga sellise toimingu ajal?

Millised masina osad jäävad seejuures pinge alla, rõhu alla, koormuse alla või liikumisse?

Milline kasutus ei ole juhendiga kooskõlas, kuid on siiski mõistlikult ettenähtav?

Alles seejärel tuvastatakse konkreetse ülesande või toimingu puhul muu hulgas:

• ohuallikas,
• ohu liik,
• ohuala,
• ohustatud isik,
• ohuolukord,
• ohtlik sündmus, kui see antud stsenaariumis esineb,
• võimalikud tagajärjed ja kahju liik.

Nii näeb välja masina riskianalüüs.

Me ei alusta komponendist.

Alustame inimesest, kes täidab kindlat ülesannet masina juures, mis on kindlas olekus. ISO 12100 kehtestabki sellise metoodika ohtude tuvastamiseks ning riski hindamiseks ja hindamistulemuste analüüsiks masina elutsükli asjakohastes etappides.

Võtame lihtsa näite.

Operaator eemaldab kaubaaluste ladustamise kambri seest kinnikiilunud detaili.

Seega on meil:

Ülesanne: kinnikiilumise kõrvaldamine.

Kasutusetapp: käitamine, sekkumine pärast protsessi seiskamist.

Töörežiim: käsirežiim või hooldusrežiim.

Ohustatud isik: operaator või hooldustehnik.

Ohuala: kambri sisemus, eelkõige haaratsi, detaili ja masina konstruktsiooni vaheline ruum.

Ohuallikas: roboti, lineaarse telje või pneumaatilise haaratsi mehaaniline energia.

Ohuolukord: inimene viibib alas, kus liikumise toimumine on endiselt võimalik.

Ohtlik sündmus: telje ootamatu liikumine, haaratsi sulgumine või salvestunud energia vabanemine.

Võimalik tagajärg: löök, muljumine, luumurd või amputatsioon.

Alles nüüd saab riski hinnata ja määrata selle vähendamise meetmed.

Võib olla vajalik kaitsekatte blokeering.

Võib olla vajalik ohutu seiskamine.

Võib osutuda vajalikuks vältida ootamatut käivitumist.

Võib-olla tuleb pneumaatiline energia välja juhtida.

Võib-olla tohib liikumine käsirežiimis toimuda ainult lubamisseadme ja ohutult piiratud kiiruse korral.

See on endiselt klassikaline masina riskianalüüs.

Kus tuleb mängu küberturvalisus?

Mitte uue kirjena mehaanilise, elektrilise ja termilise ohu kõrval.

„Häkker” ei ole mehaanilise ohu allikas

Kui lisada ISO 12100 tabelisse kirje:

Oht: küberrünnak

siis annab see vähe juurde.

Küberrünnak ei ole pöörlev võll, terav serv, kõrge temperatuur ega pneumaatiline energia.

See ei ole ka eraldi ohuala.

Operaator ei saa muljumisvigastust CVE haavatavuse tõttu.

Ta saab selle masina elemendilt, mis tegi liikumise ajal, kui inimene viibis vales kohas.

Küberrünnak võib aga muuta juhtimissüsteemi olekut, andmeid, programmi, konfiguratsiooni või kaitsemeetme toimimisviisi.

Seega võib see muutuda:

• ohtliku sündmuse põhjuseks,
• täiendavaks teeks, mis viib ohuolukorrani,
• riski vähendamise meetme tõhususe kadumise põhjuseks,
• või viisiks, kuidas ohutusfunktsiooni projekteerimisel tehtud eeldustest mööda minna.

Ja see ongi õige kokkupuutepunkt.

Mitte ohtude loetelu.

Masina käitumine.

Küberturvalisuse analüüs tuleks koostada eraldi

Masina või automaatikasüsteemi puhul on küberturvalisuse analüüs teistsuguse ülesehitusega kui riskianalüüs vastavalt ISO 12100.

Tööstusautomaatika süsteemi jaoks annab kõige loomulikuma raamistiku IEC 62443-3-2.

Standard nõuab muu hulgas:

• analüüsitava süsteemi ehk SUC määratlemist,
• süsteemi jaotamist tsoonideks ja sidekanaliteks,
• üksikute tsoonide ja kanalite riskihindamist,
• sihtturbetasemete SL-T määramist,
• turbenõuete dokumenteerimist.

See on täiesti teistsugune lähtekoht kui ISO 12100 puhul.

IEC 62443 puhul küsime muu hulgas:

Mis täpselt kuulub analüüsitavasse süsteemi?

Milliseid varasid tuleb kaitsta?

Millised seadmed, rakendused ja liidesed süsteemis on?

Millised elemendid peaksid kuuluma samasse tsooni?

Kuidas toimub side tsoonide vahel?

Kes võib saada juurdepääsu?

Millisest kohast?

Millise liidese kaudu?

Milliseid haavatavusi võidakse ära kasutada?

Milliseid andmeid, funktsioone või komponente saab muuta?

Millist teed pidi võib ründaja liikuda hooldusruuterist PLC, HMI, ajami või insenerijaamani?

Millised tagajärjed on konfidentsiaalsuse, tervikluse või käideldavuse kaol?

Milliseid kaitsemeetmeid on vaja?

Toote turvalise arendamise protsessi ning komponentidele endile esitatavate nõuete puhul on olulised ka selle seeria teised osad, eelkõige IEC 62443-4-1 ja IEC 62443-4-2. IEC 62443-3-3 seevastu korrastab süsteemitasandi tehnilised turbenõuded.

CRA ei kohusta tootjat praegu kirjutama analüüsi kaanele „tehtud vastavalt IEC 62443-le”.

IEC 62443 ei asenda ka CRA nõuetele vastavuse tõendamist.

Tööstusliku automaatikasüsteemi puhul on see siiski märksa loogilisem lähtekoht kui püüda lisada ISO 12100 tabelisse mõni häkkerirünnaku stsenaarium.

Sest need kaks metoodikat vastavad erinevatele küsimustele.

ISO 12100:

Millise tööülesande ajal, kus, millisest allikast ja millise sündmuse tagajärjel võib inimene kahju saada?

IEC 62443:

Kes, millist teed pidi ja millist haavatavust kasutades võib mõjutada süsteemi, selle andmeid või funktsioone?

Alles seejärel tuleb kontrollida, kas teise analüüsi vastus muudab esimeses kirjeldatud stsenaariumi.

Sama stsenaarium, kaks erinevat analüüsi

Tuleme tagasi operaatori juurde, kes eemaldab kinnikiilunud detaili.

ISO 12100 analüüs näitas, et inimene siseneb tsooni, kus robot või haarats võib ta purustada.

Riski vähendamise meetmeks on lukustusega kaitsepiire, ohutu seiskamise funktsioon ning ohualast väljapoole paigutatud kohalik lähtestus.

Nüüd teeme süsteemi küberturvalisuse analüüsi.

Tuvastame:

• kaugteeninduseks kasutatava ruuteri,
• hoolduskonto,
• inseneri sülearvuti,
• HMI,
• tavalise PLC,
• safety PLC,
• ajamid,
• programmeerimisliidese,
• PROFINET-võrgu ja PROFIsafe-side,
• programmi üleslaadimise ja seadistamise mehhanismid.

Vaatleme järgmist stsenaariumi:

Hoolduskonto ülevõtmine võimaldab kaugjuurdepääsu tavalisele PLC-le ja liikumiskäsu saatmist ajal, kui inimene viibib rakus.

Kas see stsenaarium viib ohtliku sündmuseni?

Ainuüksi PLC ülevõtmise fakti põhjal sellele vastata ei saa.

Tuleb kontrollida ohutusfunktsiooni arhitektuuri.

Kui kaitsepiirde avamist jälgib safety PLC, funktsioon katkestab ajamite pöördemomendi ohutult, lähtestus on ainult kohalik ning tavaline PLC ei saa liikumist taastada sõltumata ohutusfunktsiooni olekust, siis võib tavalise kontrolleri ülevõtmine peatada tootmise või kahjustada protsessi.

Kuid see ei tohiks põhjustada liikumist avatud kaitsepiirde korral.

Sel juhul näitab küberanalüüs rünnakut.

Masina riskihindamine näitab mehaanilist ohtu.

Õigesti projekteeritud ohutusfunktsioon katkestab siiski nendevahelise tee.

Ja nüüd teine variant.

Hooldusrežiim valitakse tavalise HMI kaudu.

Piiratud kiiruse väärtus tuleb tavalisest PLC-st.

Kaughooldaja saab teha lähtestuse.

Sama insenerikonto võimaldab muuta nii tavaprogrammi kui ka safety-konfiguratsiooni.

Safety-programmi koopia ei ole seotud konkreetse masina versiooniga.

Pärast sekkumist ei kontrolli keegi kontrollsummat.

Ajami parameetreid saab kaugelt muuta.

Selles arhitektuuris ei tähenda konto ülevõtmine enam ainult konfidentsiaalsuse kadu või lühikest seisakut.

See võib muuta tingimusi, millele riski vähendamine tugines.

See võib viia:

• vale režiimi valikuni,
• ohutu liikumise parameetri muutmiseni,
• volitamata lähtestuseni,
• kinnitamata konfiguratsiooni üleslaadimiseni,
• või sellise funktsiooni nõrgenemiseni, mis pidi vältima ootamatut käivitumist.

Ja siis tuleb küberstsenaarium siduda masina konkreetse ohutusstsenaariumiga:

kinnikiilumise eemaldamise ülesanne → inimene ohualas → juhtimissüsteemi või kaitsefunktsiooni volitamata muutmine → ootamatu liikumine → purustamine.

Ohu allikas ei ole muutunud.

See on endiselt masina mehaaniline energia.

Ohuala ei ole muutunud.

See asub endiselt raku sees.

Võimalik tagajärg ei ole muutunud.

See on endiselt operaatori vigastus.

Muutunud on tee, mis viib ohtliku sündmuseni.

Mitte iga haavatavus ei kuulu ISO 12100 alla

See eristus on sama oluline.

Oletame, et HMI haavatavus võimaldab lugeda ajaloolisi tootmisandmeid.

See võib olla oluline probleem CRA vaates.

See võib rikkuda andmete konfidentsiaalsust.

See võib nõuda uuendust, mõju hindamist, tegevust kasutajate suhtes ning teatud asjaoludel ka raporteerimist.

Kuid kui see ei mõjuta masina käitumist, ei muuda kaitsemeedet ega saa viia ohuolukorrani, siis ei ole mõtet seda suruda ISO 12100 kohasesse riskihindamisse.

Sarnaselt võib ka rünnak, mis põhjustab üksnes tootmisaruannete kättesaamatuse, tähendada ärilist probleemi ja CRA nõuetele vastavuse probleemi.

See ei pruugi aga tekitada ohtu operaatorile.

Teisalt võib pealtnäha süütu võimalus muuta ühtainsat seadeväärtust olla andmete konfidentsiaalsuse seisukohalt vähetähtis, kuid füüsilise ohutuse seisukohalt ülioluline.

Näiteks siis, kui see väärtus määrab:

• telje maksimaalse kiiruse,
• survejõu,
• protsessi temperatuuri,
• rõhu,
• seiskamisasendi,
• klapi avanemisaja,
• või lubatud piiri avatud kaitsekattega töötamisel.

Seega ei liigita me küberohtu selle järgi, kui tehniliselt see kõlab.

Vaatame, mida see masinaga tegelikult teha võib.

Masinamäärus nõuab seda silda

See seos ei ole ainult hea inseneritava.

Masinamääruse III lisa punkt 1.2.1 nõuab, et juhtimissüsteemid oleksid projekteeritud ja valmistatud nii, et need hoiaksid ära ohuolukordade tekkimise, sealhulgas mõistlikult ettenähtavate pahatahtlike kolmandate isikute katsete tagajärjel.

CRA omakorda osutab, et selle küberturvalisuse põhinõuded võivad toetada muu hulgas masinamääruse nõuete 1.1.9 ja 1.2.1 täitmise tõendamist.

Kuid see ei toimu automaatselt.

Tootja peab selle seose tõendama riskihindamise alusel. CRA kohane vastavushindamine ja masinamääruse kohane vastavushindamine jäävad endiselt eraldi protsessideks.

See tähendab, et ei piisa sellest, kui koostada:

• ISO 12100 riskianalüüs,
• IEC 62443 analüüs,
• kaks eraldi aruannet,
• ja loota, et standardite numbrite sarnasus loob nende vahele auditijälje.

Vaja on seostamist.

Iga olulise küberstsenaariumi puhul tuleb kindlaks teha:

1. millist elementi või funktsiooni saab üle võtta või muuta,
2. millise masina käitumise see võib esile kutsuda,
3. kas see käitumine viib ohuolukorra või ohtliku sündmuseni,
4. millist ülesannet ja millist ohuala see puudutab,
5. milline võimalik tagajärg on ISO 12100 hindamises välja toodud,
6. milline riskivähendusmeede peaks stsenaariumi arengu katkestama,
7. kas see meede jääb tõhusaks ka pärast rünnatud elemendi ülevõtmist.

See viimane punkt on kõige olulisem.

Sest kui rünnak ja kaitse sõltuvad:

• samast kontrollerist,
• samast kontost,
• samast võrgust,
• samast inseneritööjaamast,
• või samast programmist,

siis ei pruugi meil olla kahte sõltumatut kaitsekihti.

Meil on üks kiht, mida on kirjeldatud kahes dokumendis.

Seega ei vaja me üht hiiglaslikku tabelit nimega:

„safety & cybersecurity riskihindamine”.

Vajame kahte korrektset analüüsi, mis on tehtud sobivate meetoditega, ning nende vahele kontrollitud kokkupuutepunkti.

ISO 12100 peab kirjeldama inimest, ülesannet, ohuallikat, ala, ohuolukorda, ohtlikku sündmust ja võimalikku kahju.

IEC 62443 peab aitama kirjeldada süsteemi, selle tsoone, sidekanaleid, varasid, ohte, haavatavusi, ründeteid ja nõutavaid kaitsemeetmeid.

Ja tootja peab tõendama, kas teise analüüsi stsenaarium võib käivitada esimese analüüsi stsenaariumi või võtta tõhususe meetmelt, mis pidi selle peatama.

Küberrünnak ei pea looma uut ohtu. Piisab sellest, kui see avab vana õnnetuseni uue tee.

4. Pentest enne FAT-i on foto. CRA nõuab filmi

Paljudes projektides ilmub küberturvalisus mängu kaks nädalat enne FAT-i.

Tellitakse pentest.

Valmib aruanne.

Kriitilised haavatavused parandatakse, keskmised aktsepteeritakse ja dokument läheb projekti kausta.

Masin on küberturvaline.

Järgmise teisipäevani.

Pentest võib olla väga väärtuslik kontrolli element. Kuid see näitab konkreetse tooteversiooni seisu, konkreetses konfiguratsioonis ja kindlate testistsenaariumide alusel.

See ei vasta küsimusele, mida tootja teeb hiljem.

CRA puudutab aga toote kogu elutsüklit. Küberturvalisuse riskihindamine peab mõjutama toote planeerimist, projekteerimist, arendust, tootmist, tarnet ja hooldust. Pärast turule laskmist peab tootja haldama haavatavusi deklareeritud tugiperioodi jooksul.

Tuleme tagasi köögivilju pakendava masina juurde.

Masin läbis FAT-i.

Pentest ei tuvastanud kriitilisi haavatavusi.

Kaheksa kuud hiljem avaldab hooldusruuteri tootja teabe haavatavuse kohta, mis võimaldab seadme üle võtta.

Ja nüüd algab päris töö.

Millistel tarnitud masinatel on see ruuteri mudel?

Milline püsivara versioon on igale eksemplarile paigaldatud?

Kas kaugjuurdepääs on aktiivne?

Kas haavatavust saab tegelikus konfiguratsioonis ära kasutada?

Kas ruuteri ülevõtmine annab ligipääsu ainult diagnostikale või ka HMI-le, PLC-le, ajamitele ja safety PLC-le?

Kas võimalik on ainult andmete lugemine või ka programmi või parameetrite muutmine?

Kas rünnak võib mõjutada ohutusfunktsiooni?

Kas tarnija on avaldanud paranduse?

Kas ruuteri uuendus muudab sertifikaate, side-eeskirju või tunneli loomise viisi?

Kas pärast uuendust tuleb kaugteenindus, side ja osa ohutusfunktsioonidest uuesti üle kontrollida?

Milliseid kliente tuleb teavitada?

Ja kas olukord vastab aktiivselt ärakasutatava haavatavuse või tõsise intsidendi teatamise kriteeriumidele?

Enne FAT-i tehtud pentesti aruanne ei anna vastust ühelegi neist küsimustest.

See kirjeldab masinat, mida enam sellisel kujul ei eksisteeri.

Sest pärast testimist on muutunud tarkvaraversioonid, konfiguratsioonid, kasutuskeskkond ja teadmised haavatavustest.

Seetõttu ei vaja tootja mitte ainult testi, vaid protsessi:

• riistvara, püsivara ja tarkvara versioonide tuvastamiseks igas tarnitud eksemplaris,
• haavatavuste kohta käiva teabe jälgimiseks,
• nende ärakasutatavuse hindamiseks tegelikus arhitektuuris,
• võimalike mõjude kontrollimiseks protsessile ja masina ohutusele,
• uuenduste ettevalmistamiseks ja testimiseks,
• kasutajate teavitamiseks,
• tehtud otsuste dokumenteerimiseks,
• nõutavate teadete käsitlemiseks.

Alates 11. septembrist 2026 on tootjad kohustatud teatama aktiivselt ärakasutatavatest haavatavustest ja tõsistest intsidentidest, mis mõjutavad digitaalsete elementidega toodete turvalisust. Esialgne hoiatus tuleb edastada 24 tunni jooksul ja täielik teatis 72 tunni jooksul.

See tähendab, et pärast probleemi avastamist ei ole enam aega alles siis otsinguid alustada:

„Kes selle ruuteri üldse valmistas ja kus on meil nimekiri masinatest, kuhu me selle paigaldasime?”

IEC 62443-4-1 näitab hästi erinevust toote ühekordse kaitsmise ja selle turvalise arendustsükli vahel. See hõlmab mitte ainult projekteerimist ja verifitseerimist, vaid ka defektide, paranduste ja toote elutsükli lõpu haldamist.

Seega võib FAT projekti etapi lõpetada.

See ei lõpeta toote elutsüklit.

See ei lõpeta tugiperioodi.

See ei lõpeta haavatavuste seiret.

Ja see ei tähenda, et vastuvõtu päeva konfiguratsioon külmutatakse järgmiseks viieteistkümneks aastaks.

Masin võib pikka aega pakendada köögivilju supermarketite jaoks.

Kuid tootja ei saa selle küberturvalisust koos kasutusjuhendiga pakki panna, kilesse sulgeda ja eeldada, et see on lõplikult ja jäädavalt tarnitud.

Pentest võib FAT-i nimekirjas ühe punkti sulgeda. CRA avab protsessi, mis kestab kuni toote tugiperioodi lõpuni.