CRA konevalmistajille komission 27. heinäkuuta 2026 antamien ohjeiden jälkeen. Mitä on todella otettava käyttöön?

Vuosien ajan koneen kyberturvallisuus oli mahdollista kuvata kolmella askeleella: tunnetun valmistajan ohjain, VPN ”koska näin se tehdään” ja klassinen ”asiakas suojaa verkon”. Jos joku vielä lisäsi palomuurin sähkökaappiin, asia katsottiin usein hoidetuksi — ainakin siihen asti, kunnes joku yritti selvittää, mitä oikeassa hyökkäyksessä tapahtuu eikä vain esityskalvoissa.

Mutta kyberturvallisuus ei kulje PROFINETin mukana. Komponenteilla voi olla sertifikaatteja, vaatimustenmukaisuusvakuutuksia ja markkinointiesitteessä maininta ”secure by design”, mutta kone kokonaisuutena voi silti käyttäytyä ennakoitavasti tavalla, jolla ei ole mitään tekemistä turvallisuuden kanssa. Aivan kuten turvarele ei tee järjestelmästä turvallista, jos ohjauslogiikka mahdollistaa sen ohittamisen, myöskään ”turvallinen” HMI ei ratkaise arkkitehtuuriin, integraatioon, käyttöoikeuksiin, päivityksiin eikä siihen liittyviä ongelmia, mitä tapahtuu, kun joku lakkaa kysymästä lupaa.

CRA (Cyber Resilience Act, Euroopan parlamentin ja neuvoston asetus (EU) 2024/2847) ei ole IT:n lisäosa. Se on tuotetta koskeva sääntely, joka tulee osaksi koneen elinkaarta kysymättä automaatio-osaston mielipidettä. Se kattaa ohjauksen suunnittelun, riskianalyysin, toimitusketjun, konfiguroinnin, päivitykset sekä tuotteen ylläpidon vielä pitkään sen jälkeen, kun FAT on allekirjoitettu ja kone on lähtenyt hallista. Eikä väite ”emme altista sitä internetille” sulje asiaa. Käytännössä huoltoläppäri, USB-muisti, hetkellinen etädiagnostiikka tai integraatio tehtaan järjestelmään riittää siihen, että eristämisen ja altistumisen välinen raja lakkaa olemasta.

Komission 27. heinäkuuta 2026 antamat ohjeet eivät muuttaneet itse asetusta, mutta ne kavensivat tehokkaasti tulkintavaraa, jonka ansiosta kyberturvallisuutta voitiin aiemmin käsitellä valinnaisena kerroksena. Niissä täsmennettiin muun muassa tuotteen rajaa, etäkäsittelyn roolia, toimituksen jälkeisten muutosten vastuuta sekä sitä, että ”tämä ei ole enää meidän ongelmamme FAT:n jälkeen” ei ole enää turvallinen oletus.

Tärkein muutos on kuitenkin perustavanlaatuisempi: kyberhyökkäys lakkaa olemasta pelkkä IT-tapahtuma ja siitä tulee skenaario, joka vaikuttaa koneen toiminnalliseen turvallisuuteen. Jos ohjelman luvaton muutos voi aiheuttaa akselin liikkeen, lukituksen ohituksen, prosessiparametrien muutoksen tai turvatoiminnon menetyksen, emme enää puhu ”verkkoincidentistä”. Puhumme koneen mahdollisesti hallitsemattomasta käyttäytymisestä — riippumatta siitä, oliko syynä konfigurointivirhe, ohjelmiston haavoittuvuus vai tahallinen puuttuminen.

Tässä yhteydessä kertaluonteinen penetraatiotesti ennen FAT:ia ei enää ole osoitus vaatimustenmukaisuudesta, vaan ainoastaan tilannekuva järjestelmän tilasta tietyllä hetkellä. CRA edellyttää jatkuvaa lähestymistapaa: suunnittelusta tuotannon ja käyttöönoton kautta päivityksiin, haavoittuvuuksien hallintaan, reagointiin poikkeamiin ja ylläpitoon ilmoitetun tukijakson ajan.

Käytännössä tämä tarkoittaa luopumista ajattelusta ”tehty = turvallinen” ja siirtymistä ajatteluun ”ylläpidetty = hallinnassa”. Ilman harhaa siitä, että sähkökaapin palomuuri, VPN ja komponentin sertifikaatti ratkaisevat asian. Ja ilman oletusta, että kyberturvallisuus päättyy vastaanottopöytäkirjan allekirjoittamiseen.

Tässä artikkelissa käymme läpi, mitä CRA-ohjeet todella muuttavat koneiden valmistajille, integraattoreille ja modernisoijille — pelkistämättä koko aihetta iskulauseeseen ”vaihdetaan salasana ja lisätään cybersecurity-valintaruutu”.

1. Jotta kone ei kuuluisi CRA:n piiriin, sen pitäisi olla lähes pelkkien kontaktorien varassa

Monissa projekteissa CRA:n soveltamisala tarkistetaan yhdellä kysymyksellä:

Liitetäänkö kone internetiin?

Ei liitetä.

Eli asia on loppuun käsitelty.

Kytkentäkaaviossa on PLC, HMI, muutama käyttölaite, hajautetut tulot ja lähdöt, venttiilisaareke, turvaskanneri sekä portti ohjelman lataamista varten. Ohjain kommunikoi paneelin kanssa PROFINETin kautta, vaihtaa käyttöjen kanssa ohjaus- ja tilasanoja, ja anturit välittävät tietoa IO-Linkin kautta.

Mutta reititintä SIM-kortilla ei ole.

Kuten tiedetään, tiedosta tulee tietoa vasta silloin, kun se poistuu tuotantohallista.

CRA ei kuitenkaan kysy, onko koneella internetyhteys.

Se kysyy, kuuluuko koneen käyttötarkoitukseen tai kohtuudella ennakoitavaan käyttöön suora tai epäsuora, looginen tai fyysinen datayhteys laitteeseen tai verkkoon. Sen ei tarvitse olla yhteys pilveen, valmistajan palvelimeen tai julkiseen internetiin. Se voi kulkea kaapelia pitkin, radioaaltojen kautta, ohjelmointirajapinnan välityksellä tai osana suurempaa järjestelmää.

Ja nyt olennainen kysymys: mikä tyypillisessä koneessa oikeasti siirtää dataa?

Lukeeko HMI tilatietoja PLC:ltä ja tallentaako se asetusarvoja?

Lähettääkö PLC käytölle ohjaussanan ja saako se vastauksena nopeuden, tilan ja vikakoodin?

Välittääkö tulo- ja lähtösaareke prosessikuvaa?

Lähettääkö IO-Link-anturi mittausarvon, laitetunnisteen ja diagnostiikkatiedot?

Kommunikoiko safety PLC moduulien kanssa PROFIsafen kautta?

Ladataanko ohjelma, laitteistokonfiguraatio tai firmware huoltoläppäriltä?

Voidaanko reseptejä, raportteja tai päivityksiä siirtää USB:n kautta?

Jos vastaus on edes kerran ”kyllä”, kyse on todennäköisesti datayhteydestä.

Eikä tätä muuta se, että:

• kone toimii paikallisverkossa,
• sillä ei ole julkista IP-osoitetta,
• Ethernet-porttia käytetään vain käyttöönoton aikana,
• kannettavan tietokoneen kytkee siihen vain huolto,
• tiedonsiirto tapahtuu ainoastaan ohjausjärjestelmän sisällä,
• asiakas on luvannut, ettei konetta koskaan kytketä internetiin.

CRA ei kata ainoastaan käyttöä, joka on ohjeessa kuvattu peruskäytöksi, vaan myös kohtuudella ennakoitavissa olevan käytön. Huoltoportti ei siis lakkaa siirtämästä tietoa vain siksi, että kaavioon on kirjoitettu sen viereen ”SERVICE ONLY”.

Komission 27. heinäkuuta 2026 antamissa ohjeissa tehdään kuitenkin tärkeä erottelu.

Kaikki johdot eivät ole datayhteyksiä, eivätkä kaikki sähköiset signaalit ole datayhteyksiä.

Jos signaali palvelee yksinomaan tietyn toiminnon kytkemistä päälle, pois päältä tai sen syöttämistä, eikä se välitä digitaalisesti koodattua tietoa, pelkkä kahden sähköisen tilan olemassaolo ei vielä riitä siihen, että sitä pidettäisiin datayhteytenä.

Painike, joka syöttää jännitteen kontaktorin kelalle, ei muutu digitaaliseksi rajapinnaksi vain siksi, että sen tila voidaan kuvata nollana tai ykkösenä.

Samoin perinteinen rajakytkin, joka on kytketty rele-kontaktoripiiriin, voi ainoastaan katkaista tai sulkea piirin. Se ei siirrä laitteen numeroa, prosessiarvoa, diagnostiikkakoodia, firmware-versiota eikä useita tietoja sisältävää telegrammia.

Mutta jos sama tila päätyy älykkääseen laitteeseen, koodataan, siirretään väylän kautta, liitetään diagnostiikkaan ja vastaanotin tulkitsee sen tiedoksi, tilanne on jo toinen.

Raja ei siis kulje ”online”- ja ”offline”-koneen välillä.

Se kulkee tavallisen ohjaussignaalin ja digitaalisesti koodatun tiedon vaihdon välillä.

Siksi käytännössä koneen, joka jäisi CRA:n soveltamisalan ulkopuolelle yksinomaan datayhteyden puuttumisen vuoksi, pitäisi muistuttaa enemmän perinteistä painikkeista, rajakytkimistä, releistä ja kontaktoreista koostuvaa järjestelmää kuin nykyaikaista TIA Portalissa avattavaa suunnitelmaa.

Tämä ei tietenkään ole kontaktoreita koskeva lakisääteinen poikkeus.

On mahdollista rakentaa yksinkertainen PLC-ohjattu kone, joka ei yksityiskohtaisen analyysin jälkeen täytä soveltamisalakriteeriä. Toisaalta kontaktorijärjestelmään voidaan lisätä digitaalinen säädin, huoltorajapinta tai viestintämoduuli, jolloin ollaan täsmälleen rajan toisella puolella.

Komponentin nimi ei ratkaise asiaa.

Ratkaisevaa on se, mitä tuote tosiasiallisesti tekee ja minkä kanssa se vaihtaa tietoa.

Siksi ennen kuin vastataan kysymykseen, kuuluuko tietty kone CRA:n piiriin, on selvitettävä:

• missä arvioitavan tuotteen raja kulkee,
• mitkä laitteet ja ohjelmistoelementit siihen kuuluvat,
• mitä fyysisiä ja loogisia rajapintoja siinä on,
• mitä tietoja niiden kautta siirretään,
• mitkä yhteydet ovat suoria ja mitkä kulkevat laajemman järjestelmän kautta,
• mitkä niistä esiintyvät normaalikäytön, käyttöönoton, diagnostiikan, päivityksen tai huollon aikana,
• mitkä käyttötavat ovat kohtuudella ennakoitavissa, vaikka valmistaja mieluummin jättäisi ne ennakoimatta.

Niin kauan kuin näihin kysymyksiin ei ole vastattu, emme tiedä, jääkö kone CRA:n soveltamisalan ulkopuolelle.

Meillä on korkeintaan mukava toteamus:

”Konetta ei ole kytketty internetiin”.

Ongelma vain on, että se on vastaus kysymykseen, jota CRA ei esitä.

PROFINET ei ole internet. CRA:n kannalta sen ei tarvitsekaan olla sitä.

2. Kyberturvallisuus ei siirry PROFINETin mukana

Monissa projekteissa koneen vaatimustenmukaisuuden teema alkaa jo hankintavaiheessa.

PLC tunnetulta valmistajalta.
HMI ajantasaisella firmwarella.
Hallittava kytkin.
Teollisuusreititin VPN:llä.
Käytöt turvatoiminnoilla.
Safety PLC asianmukaisella sertifikaatilla.

Jokaiselle laitteelle vaatimustenmukaisuusvakuutus, ohje ja muutama asiakirja, joissa toistuvat sanat ”secure”, ”encrypted” ja ”defence in depth”.

Kaaviossa kaikki näyttää ammattimaiselta.

Silti ei vieläkään tiedetä, onko valmis kone kyberturvallinen.

Sillä kyberturvallisuus ei ”kulje mukana” PROFINETissä.

Tilanne on vähän sama kuin oven lukon kanssa:
sinulla voi olla jokaisessa huoneessa erittäin hyvä lukko, sertifioitu, testattu, hienosti dokumentoitu ja ”secure”-hologrammilla varustettu, mutta se ei silti takaa turvallisuutta, jos joku on jättänyt ulko-oven selälleen ”koska näin käyttöönotto sujui nopeammin”.

Juuri näin on tässäkin: komponentit voivat olla esimerkillisiä, ja silti järjestelmä voi olla… luovasti avoin.

PLC ei ”siirrä” turvallisuutta HMI:lle.
Palomuuri ei ”korjaa” sovelluslogiikkaa.
Kytkin ei ”järjestä” käyttäjäoikeuksia.
Se, että jokaisella osalla on sertifikaatti, ei vielä tarkoita, ettei koko kone olisi yksi suuri, kohteliaasti dokumentoitu haavoittuvuus.

PROFINET siirtää dataa.

Se ei siirrä vastuuta.
Eikä valitettavasti myöskään tervettä järkeä.

CRA kattaa sekä valmiit tuotteet että erikseen markkinoille saatettavat komponentit. Tämä tarkoittaa, että ohjain, operaattoripaneeli tai viestintämoduuli voidaan arvioida erikseen. Koneen valmistajan on kuitenkin edelleen osoitettava, että kokonaisuus toimii turvallisesti asiakkaan todellisessa kokoonpanossa — siis siinä versiossa, jossa joku ”ihan varmasti ei enää muuttanut mitään… vai mitä?”.

Tässä kohtaa tulee vastaan yleisin virhe.

Tämä on täsmälleen sama mekanismi, jonka tunnemme jo vuosien ajalta koneiden vaatimustenmukaisuuden arvioinnista ja CE-merkinnästä.

Valoverholla on PL e.
Safety PLC:llä on SIL 3.
Käytöllä on STO.

Tarkoittaako tämä, että koko kone on automaattisesti samalla tasolla?

Samalla logiikalla se, että jokainen telineen osa täyttää turvallisuusvaatimukset, ei vielä takaa, että koko rakenne on vakaa.

Ei.

Sillä edelleen on varmistettava, miten kaikki toimii yhdessä — eli tehtävä se vähemmän suosittu vaihe, ”järjestelmätason ajattelu”, johon ei valitettavasti ole ”auto-certify”-painiketta.

Kyberturvallisuudessa tilanne on täsmälleen sama.

Sinulla voi olla ”turvallisia” komponentteja, mutta käytännössä:

• operaattori näkee ja voi muuttaa enemmän tietoja kuin hänen oikeasti tarvitsee, koska ”näin oli helpompaa”,
• yksi huoltosalasana toimii kaikissa koneissa, koska ”huolto kyllä tietää mitä tekee”,
• huoltoportti on käytettävissä ”varmuuden vuoksi”, eli käytännössä kaiken varalta,
• etäyhteys kattaa koko verkon, koska joku sanoi joskus ”sehän on vain diagnostiikkaa”,
• päivityksiä voidaan asentaa ilman valvontaa, koska ”eihän tästä ole koskaan tullut ongelmaa”,
• laitteet ”luottavat toisiinsa” ilman rajoituksia, koska luottamus on halvempi kuin segmentointi,
• ja integraatio perustuu oletukseen, ettei kukaan koskaan tee virhettä, mikä on — kuten historia osoittaa — insinööritieteiden optimistisin oletus.

Jokainen yksittäinen osa voi olla sinänsä kunnossa.

Mutta järjestelmä kokonaisuutena voi rakentaa näistä oikeista osista jotain, joka toimii… mutta ei välttämättä niin kuin oli tarkoitus.

Ja tämä on olennaista: riski ei ole laitteissa itsessään, vaan niiden kytkennöissä, konfiguraatiossa ja siinä legendaarisessa ”väliaikaisesti jätetyssä” käyttöoikeudessa.

CRA edellyttää koneen valmistajalta muutakin kuin vaatimustenmukaisuusvakuutusten keräämistä pokaalien tapaan. Se edellyttää varmistamaan, että komponenteista koottu kokonaisuus on edelleen turvallinen kokonaisuutena — eikä vain ”näytä hyvältä vaatimustenmukaisuustaulukossa”.

Käytännössä tämä tarkoittaa yksinkertaisia, liiketoiminnan kannalta olennaisia kysymyksiä:

• onko jokaisella käyttäjällä vain sellaiset käyttöoikeudet, joita hän todella tarvitsee, eikä oikeuksia ”jos niille joskus olisi käyttöä”,
• onko etäyhteys rajattu minimiin vai pikemminkin maksimaalisen mukavuuden mukaan,
• onko huollolla ”täydet oikeudet kaikkialle”, koska jonkun mielestä se nopeuttaa asioita,
• onko verkko yksi yhteinen taso, koska segmentointi ”monimutkaistaa projektia”,
• hallitaanko päivityksiä vai mennäänkö mallilla ”asennetaan ja toivotaan parasta”,
• voidaanko nopeasti tunnistaa, mitkä koneet ovat altistuneita, vai mennäänkö linjalla ”selvitämme sen vasta poikkeaman jälkeen”,
• avaako yhden osan vika koko järjestelmän, koska ”integraatiossa siitä tuli tällainen”.

Nämä eivät ole teknisiä kysymyksiä ”vaikeiden asioiden insinööreille”.

Nämä ovat liiketoimintariskin kysymyksiä: seisokit, kustannukset, vastuu ja se pieni yksityiskohta, että tuotannon on kuitenkin toimittava.

Siksi ei riitä, että sanotaan:

”kaikki komponentit ovat vaatimustenmukaisia”

Koska se ei vieläkään vastaa kysymykseen:

onko koko kone turvallinen todellisessa käytössä vai vain projektikatselmuksen PowerPointissa?

Toimittajan vakuutus on tärkeä.

Mutta se koskee vain yhtä osaa — sitä, joka juuri testattiin laboratorio-olosuhteissa, ei ympäristössä ”jossain tuotantohallissa, VPN:n, USB:n ja aikapaineen keskellä”.

Se ei kata sitä, miten osaa on käytetty.
Se ei kata konfiguraatiota.
Se ei kata integraatiota.
Se ei kata päätöksiä, jotka tehtiin ”nopeasti käyttöönoton aikana, koska asiakas odotti”.
Se ei kata sitä, mitä tapahtuu vuosien käytön jälkeen, kun kukaan ei enää muista, miksi jokin oli ”väliaikaisesti auki”.

Siksi arviointi ei voi päättyä laiteluetteloon.

Järjestelmää on tarkasteltava kokonaisuutena:

• kenellä on pääsy ja miksi (eikä ”koska on aina ollut”),
• mikä on oikeasti tarpeen ja mikä on vain ”jätetty paikoilleen, koska siitä ei ollut haittaa”,
• missä tiedot voivat vuotaa hallinnan ulkopuolelle, koska jonkun mielestä ”sehän on vain diagnostiikkaa”,
• mitä tapahtuu, jos joku käyttää laillista pääsyä laittomalla tavalla (eli juuri niin kuin hyökkäyksissä tehdään),
• kuinka nopeasti voidaan reagoida, kun ongelma ilmenee, eikä vasta ”kvartaalikatselmuksen jälkeen”.

Niin kauan kuin näihin kysymyksiin ei ole vastauksia, meillä on vain joukko erittäin kunnollisia komponentteja.

Meillä ei vielä ole turvallista konetta.

Komponenttien vaatimustenmukaisuus ei automaattisesti tarkoita järjestelmän vaatimustenmukaisuutta. Koneen vaatimustenmukaisuus on suunniteltava, varmistettava ja — kaikkein vaikeimpana — ylläpidettävä siitä huolimatta, että houkutus sanoa ”ei kosketa enää mihinkään, koska tämä toimii” on suuri.

3. Älä lisää kyberhyökkäystä vain vaaraluetteloon. Yhdistä kaksi analyysiä oikeassa kohdassa

Konealalla muodollinen kyberturvallisuuden riskianalyysi on edelleen pikemminkin poikkeus kuin projektin vakiintunut osa.

Useimmiten mukana on teollisuusreititin.

On VPN.

On salasana PLC:lle.

Joskus mukana on hallittava kytkin, jota kukaan ei myöhemmin hallinnoi.

Kunnianhimoisemmassa versiossa valmistaja saa toimittajalta esityksen ”defence in depth” -mallista ja katsoo juuri saaneensa valmiiksi koko koneen kyberturvallisuuden riskianalyysin.

Ei saanut.

Hän osti muutaman teknisen suojatoimen.

Se ei vielä ole analyysi.

Siksi ei ole mielekästä kuvata ongelmaa niin, kuin jokaisessa projektissa laadittaisiin kaksi ammattimaista arviointia — yksi ISO 12100:n mukaisesti, toinen kyberturvallisuudesta — joita ei vain sattumalta olisi yhdistetty toisiinsa.

Useimmiten laaditaan vain yksi.

Koneen riskin arviointi.

Tuotteen kyberturvallisuusanalyysiä ei sen sijaan usein tehdä lainkaan.

Koneen riskin arviointi ISO 12100:n mukaisesti ei tarkoita sitä, että taulukkoon kirjoitetaan:

anturin vika → odottamaton liike → murskautuminen.

Tämä voi olla osa tiettyä skenaariota, mutta ei lähtökohta.

Ensin on määriteltävä koneen rajat.

Mikä on sen käyttötarkoitus?

Mitkä ovat sen elinkaaren vaiheet?

Kuka sitä käyttää?

Mitä tehtäviä suoritetaan kuljetuksen, asennuksen, käyttöönoton, tuotannon, säädön, puhdistuksen, tukosten poistamisen, kunnossapidon, diagnostiikan ja purkamisen aikana?

Missä käyttötiloissa kone voi toimia?

Missä ihminen sijaitsee kunkin näistä toimenpiteistä aikana?

Mitkä koneen osat ovat silloin edelleen jännitteellisiä, paineenalaisia, kuormitettuja tai liikkeessä?

Mikä käyttö ei ole ohjeen mukaista, mutta on silti kohtuudella ennakoitavissa?

Vasta tämän jälkeen tunnistetaan tiettyä tehtävää tai toimenpidettä varten muun muassa:

• vaaran lähde,
• vaaran tyyppi,
• vaara-alue,
• altistuva henkilö,
• vaaratilanne,
• vaarallinen tapahtuma, jos sellainen esiintyy kyseisessä skenaariossa,
• mahdolliset seuraukset ja vahingon laji.

Tältä koneen riskianalyysi näyttää.

Emme aloita komponentista.

Aloitamme ihmisestä, joka suorittaa tiettyä tehtävää koneella, joka on tietyssä tilassa. ISO 12100 määrittelee juuri tällaisen menetelmän vaarojen tunnistamiseen sekä riskin arviointiin ja riskin merkityksen arviointiin koneen elinkaaren asianmukaisissa vaiheissa.

Otetaan yksinkertainen esimerkki.

Operaattori poistaa juuttuneen kappaleen lavaukseen tarkoitetun solun sisältä.

Meillä on siis:

Tehtävä: tukoksen poistaminen.

Käytön vaihe: käyttö, toimenpide prosessin pysäyttämisen jälkeen.

Käyttötila: käsikäyttö tai huoltotila.

Altistuva henkilö: operaattori tai kunnossapitotyöntekijä.

Vaara-alue: solun sisätila, erityisesti tarttujan, kappaleen ja koneen rakenteen välinen alue.

Vaaran lähde: robotin, lineaariakselin tai pneumaattisen tarttujan mekaaninen energia.

Vaaratilanne: ihminen on vaara-alueella samaan aikaan, kun liikkeen toteutuminen on edelleen mahdollista.

Vaarallinen tapahtuma: akselin odottamaton liike, tarttujan sulkeutuminen tai varastoituneen energian vapautuminen.

Mahdollinen seuraus: isku, murskautuminen, murtuma tai amputaatio.

Vasta nyt voidaan arvioida riskiä ja määrittää toimenpiteet sen pienentämiseksi.

Suojuksen lukitus voi olla tarpeen.

Turvallinen pysäytys voi olla tarpeen.

Odottamaton käynnistyminen voi olla estettävä.

Pneumaattinen energia voi olla tarpeen poistaa hallitusti.

Voi myös olla, että liike käsikäyttötilassa saa tapahtua vain sallintalaitetta käyttäen ja turvallisesti rajoitetulla nopeudella.

Tämä on edelleen klassista koneen riskin arviointia.

Missä kohtaa kyberturvallisuus tulee mukaan?

Ei uutena kohtana mekaanisen, sähköisen ja lämpöön liittyvän vaaran rinnalle.

”Hakkeri” ei ole mekaanisen vaaran lähde

Se, että ISO 12100 -taulukkoon lisätään kohta:

Vaara: kyberhyökkäys

ei tuo juuri mitään lisäarvoa.

Kyberhyökkäys ei ole pyörivä akseli, terävä reuna, korkea lämpötila eikä pneumaattinen energia.

Se ei myöskään ole erillinen vaara-alue.

Operaattori ei murskaannu CVE-haavoittuvuuden vuoksi.

Hän murskautuu koneen osan vuoksi, joka teki liikkeen silloin, kun ihminen oli väärässä paikassa.

Kyberhyökkäys voi kuitenkin muuttaa ohjausjärjestelmän tilaa, tietoja, ohjelmaa, konfiguraatiota tai suojaustoimen toimintatapaa.

Se voi siis olla:

• vaarallisen tapahtuman syy,
• lisäreitti, joka johtaa vaaratilanteeseen,
• riskin pienentämistoimen tehon menettämisen syy,
• tai tapa kiertää turvallisuustoiminnon suunnittelussa tehdyt oletukset.

Juuri tässä on oikea liittymäkohta.

Ei vaaraluettelossa.

Vaan koneen käyttäytymisessä.

Kyberturvallisuusanalyysi on laadittava erikseen

Koneen tai automaatiojärjestelmän kyberturvallisuusanalyysin rakenne on erilainen kuin ISO 12100:n mukaisen riskin arvioinnin.

Teollisuusautomaation järjestelmälle luontevimman rungon antaa IEC 62443-3-2.

Standardi edellyttää muun muassa:

• analysoitavan järjestelmän eli SUC:n määrittelyä,
• järjestelmän jakamista vyöhykkeisiin ja viestintäkanaviin,
• riskin arviointia yksittäisille vyöhykkeille ja kanaville,
• tavoiteltujen turvallisuustasojen SL-T määrittämistä,
• turvallisuusvaatimusten dokumentointia.

Tämä on täysin eri lähtökohta kuin ISO 12100:ssa.

IEC 62443:ssa kysymme muun muassa:

Mitä analysoitavaan järjestelmään tarkalleen kuuluu?

Mitä resursseja on suojattava?

Mitä laitteita, sovelluksia ja rajapintoja järjestelmässä on?

Mitkä elementit pitäisi kuulua samaan vyöhykkeeseen?

Miten viestintä vyöhykkeiden välillä kulkee?

Kuka voi saada pääsyn?

Mistä sijainnista?

Minkä rajapinnan kautta?

Mitä haavoittuvuuksia voidaan hyödyntää?

Mitä tietoja, toimintoja tai komponentteja voidaan muuttaa?

Mitkä reitit hyökkääjällä on käytettävissään siirtyäkseen huoltoreitittimestä PLC:hen, HMI:hin, taajuusmuuttajaan tai suunnitteluasemaan?

Millaisia seurauksia luottamuksellisuuden, eheyden tai saatavuuden menetyksellä on?

Mitä suojaustoimenpiteitä tarvitaan?

Tuotteen turvallisen kehitysprosessin sekä itse komponentteihin kohdistuvien vaatimusten kannalta merkityksellisiä ovat myös sarjan muut osat, erityisesti IEC 62443-4-1 ja IEC 62443-4-2. IEC 62443-3-3 puolestaan jäsentää tekniset turvallisuusvaatimukset järjestelmätasolla.

CRA ei tällä hetkellä edellytä, että valmistaja kirjoittaa analyysin kanteen ”tehty IEC 62443:n mukaisesti”.

IEC 62443 ei myöskään korvaa CRA:n vaatimustenmukaisuuden osoittamista.

Teollisessa automaatiojärjestelmässä se on kuitenkin huomattavasti loogisempi viitekehys kuin yritys lisätä muutama hakkerointiskenaario ISO 12100 -taulukkoon.

Koska nämä kaksi menetelmää vastaavat eri kysymyksiin.

ISO 12100:

Minkä tehtävän aikana, missä, mistä lähteestä ja minkä tapahtuman seurauksena ihminen voi vahingoittua?

IEC 62443:

Kuka voi, mitä reittiä ja mitä haavoittuvuutta hyödyntäen vaikuttaa järjestelmään, sen tietoihin tai toimintoihin?

Vasta tämän jälkeen on tarkistettava, muuttaako toisen analyysin vastaus ensimmäisen analyysin skenaariota.

Sama skenaario, kaksi eri analyysiä

Palataan käyttäjään, joka poistaa juuttunutta kappaletta.

ISO 12100 -analyysi osoitti, että ihminen menee alueelle, jossa robotti tai tarttuja voi murskata hänet liikkeensä seurauksena.

Riskin pienentämiskeinona on lukittava suojus, turvallinen pysäytystoiminto sekä vaaravyöhykkeen ulkopuolelle sijoitettu paikallinen kuittaus.

Seuraavaksi tehdään järjestelmän kyberturvallisuusanalyysi.

Tunnistamme:

• etähuoltoon käytettävän reitittimen,
• huoltotilin,
• suunnitteluläppärin,
• HMI:n,
• tavallisen PLC:n,
• safety PLC:n,
• taajuusmuuttajat,
• ohjelmointirajapinnan,
• PROFINET-verkon ja PROFIsafe-tiedonsiirron,
• ohjelman lataus- ja konfigurointimekanismit.

Tarkasteltava skenaario on seuraava:

Huoltotilin haltuunotto mahdollistaa etäyhteyden tavalliseen PLC:hen ja liikeohjauksen lähettämisen silloin, kun ihminen on solun sisällä.

Johtaako tämä skenaario vaaratilanteeseen?

Siihen ei voi vastata pelkästään sen perusteella, että PLC on otettu haltuun.

Turvatoimintojen arkkitehtuuri on tarkistettava.

Jos suojuksen avaamista valvoo safety PLC, toiminto katkaisee turvallisesti taajuusmuuttajien momentin, kuittaus on vain paikallinen eikä tavallinen PLC voi palauttaa liikettä riippumatta turvatoiminnon tilasta, tavallisen ohjaimen haltuunotto voi pysäyttää tuotannon tai häiritä prosessia.

Sen ei kuitenkaan pitäisi aiheuttaa liikettä suojuksen ollessa auki.

Tällöin kyberanalyysi osoittaa hyökkäyksen.

Koneen riskinarviointi osoittaa mekaanisen vaaran.

Oikein suunniteltu turvatoiminto kuitenkin katkaisee niiden välisen yhteyden.

Ja nyt toinen vaihtoehto.

Huoltotila valitaan tavallisen HMI:n kautta.

Rajoitetun nopeuden arvo tulee tavallisesta PLC:stä.

Etähuoltaja voi tehdä kuittauksen.

Sama suunnittelutili mahdollistaa sekä tavallisen ohjelman että safety-konfiguraation muuttamisen.

Safety-ohjelman kopio ei ole sidottu tiettyyn koneversioon.

Kukaan ei tarkista tarkistussummaa toimenpiteen jälkeen.

Taajuusmuuttajan parametreja voidaan muuttaa etänä.

Tässä arkkitehtuurissa tilin haltuunotto ei enää tarkoita pelkästään luottamuksellisuuden menetystä tai lyhyttä seisokkia.

Se voi muuttaa niitä edellytyksiä, joihin riskin pienentäminen perustui.

Se voi johtaa:

• väärän toimintatilan valintaan,
• turvallisen liikkeen parametrin muuttamiseen,
• luvattomaan kuittaukseen,
• hyväksymättömän konfiguraation lataamiseen,
• tai sellaisen toiminnon heikentämiseen, jonka tarkoituksena oli estää odottamaton käynnistyminen.

Ja silloin kyberskenaario on kytkettävä koneen konkreettiseen turvallisuusskenaarioon:

juuttuman poistotehtävä → ihminen vaaravyöhykkeellä → ohjausjärjestelmän tai suojatoiminnon luvaton muutos → odottamaton liike → murskautuminen.

Vaaran lähde ei ole muuttunut.

Se on edelleen koneen mekaaninen energia.

Vaaravyöhyke ei ole muuttunut.

Se sijaitsee edelleen solun sisällä.

Mahdollinen seuraus ei ole muuttunut.

Se on edelleen käyttäjän vammautuminen.

Se, mikä on muuttunut, on vaaratilanteeseen johtava reitti.

Kaikki haavoittuvuudet eivät kuulu ISO 12100:aan

Tämä erottelu on yhtä tärkeä.

Oletetaan, että HMI:n haavoittuvuus mahdollistaa historiallisten tuotantotietojen lukemisen.

Tämä voi olla merkittävä ongelma CRA:n näkökulmasta.

Se voi loukata tietojen luottamuksellisuutta.

Se voi edellyttää päivitystä, vaikutusten arviointia, toimenpiteitä käyttäjiä kohtaan ja tietyissä olosuhteissa myös raportointia.

Mutta jos se ei vaikuta koneen käyttäytymiseen, ei muuta suojatoimenpidettä eikä voi johtaa vaaratilanteeseen, sitä ei ole järkevää väkisin sisällyttää ISO 12100:n mukaiseen riskinarviointiin.

Vastaavasti hyökkäys, joka aiheuttaa ainoastaan tuotantoraporttien saatavuuden menetyksen, voi merkitä liiketoimintaongelmaa ja CRA:n mukaisuuteen liittyvää ongelmaa.

Se ei kuitenkaan välttämättä aiheuta riskiä koneen käyttäjälle.

Toisaalta näennäisen harmiton mahdollisuus muuttaa yhtä asetusarvoa voi olla tietojen luottamuksellisuuden kannalta vähäinen, mutta fyysisen turvallisuuden kannalta erittäin merkittävä.

Esimerkiksi silloin, kun arvo määrittää:

• akselin enimmäisnopeuden,
• puristusvoiman,
• prosessin lämpötilan,
• paineen,
• pysäytysasennon,
• venttiilin aukioloajan,
• tai sallitun raja-arvon käytettäessä konetta suojuksen ollessa auki.

Kyberuhkaa ei siis luokitella sen perusteella, miltä se teknisesti kuulostaa.

Ratkaisevaa on se, mitä se voi todellisuudessa tehdä koneelle.

Koneasetus pakottaa rakentamaan tämän sillan

Tämä yhteys ei ole pelkästään hyvää insinöörikäytäntöä.

Koneasetuksen liitteen III kohta 1.2.1 edellyttää, että ohjausjärjestelmät suunnitellaan ja toteutetaan siten, että vaaratilanteiden syntyminen estetään myös kolmansien osapuolten kohtuudella ennakoitavissa olevien, pahantahtoisten yritysten seurauksena.

CRA puolestaan osoittaa, että sen olennaiset kyberturvallisuusvaatimukset voivat tukea vaatimustenmukaisuuden osoittamista muun muassa koneasetuksen vaatimusten 1.1.9 ja 1.2.1 osalta.

Mutta tämä ei tapahdu automaattisesti.

Valmistajan on osoitettava tämä yhteys riskinarvioinnin perusteella. CRA:n mukainen vaatimustenmukaisuuden arviointi ja koneasetuksen mukainen vaatimustenmukaisuuden arviointi ovat edelleen erillisiä prosesseja.

Eli ei riitä, että laaditaan:

• ISO 12100:n mukainen riskinarviointi,
• IEC 62443 -analyysi,
• kaksi erillistä raporttia,
• ja oletetaan, että standardinumeroiden samankaltaisuus muodostaa niiden välille auditointijäljen.

Tarvitaan kytkentä niiden välille.

Jokaiselle olennaiselle kyberskenaariolle on määritettävä:

1. mikä osa tai toiminto voidaan ottaa haltuun tai muuttaa,
2. millaista koneen käyttäytymistä tämä voi aiheuttaa,
3. johtaako tämä käyttäytyminen vaaratilanteeseen tai vaaralliseen tapahtumaan,
4. mihin tehtävään ja mihin vaara-alueeseen se liittyy,
5. mikä mahdollinen seuraus on tunnistettu ISO 12100 -arvioinnissa,
6. mikä riskin pienentämistoimenpide katkaisee skenaarion etenemisen,
7. säilyykö tämä toimenpide tehokkaana myös sen jälkeen, kun hyökkäyksen kohteena ollut osa on otettu haltuun.

Tämä viimeinen kohta on tärkein.

Sillä jos hyökkäys ja suojaus riippuvat:

• samasta ohjaimesta,
• samasta käyttäjätilistä,
• samasta verkosta,
• samasta suunnittelutyöasemasta,
• tai samasta ohjelmasta,

meillä ei ehkä ole kahta toisistaan riippumatonta suojakerrosta.

Meillä on yksi kerros, joka on kuvattu kahdessa asiakirjassa.

Emme siis tarvitse yhtä valtavaa taulukkoa nimeltä:

”safety & cybersecurity -riskinarviointi”.

Tarvitsemme kaksi asianmukaisesti tehtyä analyysiä oikeilla menetelmillä sekä hallitun rajapinnan niiden välille.

ISO 12100:n tehtävänä on kuvata ihminen, tehtävä, vaaran lähde, alue, vaaratilanne, vaarallinen tapahtuma ja mahdollinen vahinko.

IEC 62443:n tehtävänä on auttaa kuvaamaan järjestelmä, sen vyöhykkeet, viestintäkanavat, resurssit, uhat, haavoittuvuudet, hyökkäyspolut ja tarvittavat suojaukset.

Ja valmistajan on osoitettava, voiko toisen analyysin skenaario käynnistää ensimmäisen analyysin skenaarion tai heikentää sen pysäyttämiseksi tarkoitetun toimenpiteen tehokkuutta.

Kyberhyökkäyksen ei tarvitse synnyttää uutta vaaraa. Riittää, että se avaa uuden reitin vanhaan onnettomuuteen.

4. Penetraatiotesti ennen FAT:ia on valokuva. CRA vaatii elokuvan

Monissa projekteissa kyberturvallisuus tulee mukaan kaksi viikkoa ennen FAT:ia.

Tilataan penetraatiotesti.

Laaditaan raportti.

Kriittiset haavoittuvuudet korjataan, keskitasoiset hyväksytään, ja asiakirja päätyy projektikansioon.

Kone on kyberturvallinen.

Seuraavaan tiistaihin asti.

Penetraatiotesti voi olla erittäin arvokas osa todentamista. Se näyttää kuitenkin tietyn tuoteversion tilan, tietyssä kokoonpanossa ja tietyillä testiskenaarioilla.

Se ei vastaa kysymykseen siitä, mitä valmistaja tekee myöhemmin.

Ja CRA koskee tuotteen koko elinkaarta. Kyberturvallisuuden riskinarvioinnin on vaikutettava tuotteen suunnitteluun, kehitykseen, valmistukseen, toimitukseen ja ylläpitoon. Markkinoille saattamisen jälkeen valmistajan on hallittava haavoittuvuuksia ilmoitetun tukijakson ajan.

Palataan vihannesten pakkauskoneeseen.

Kone on läpäissyt FAT:n.

Penetraatiotestissä ei havaittu kriittisiä haavoittuvuuksia.

Kahdeksan kuukautta myöhemmin huoltorouterin valmistaja julkaisee tiedon haavoittuvuudesta, joka mahdollistaa laitteen haltuunoton.

Ja nyt alkaa varsinainen työ.

Missä toimitetuissa koneissa on tämä kyseinen reititinmalli?

Mikä firmware-versio on asennettu kuhunkin yksilöön?

Onko etäyhteys käytössä?

Voidaanko haavoittuvuutta hyödyntää todellisessa kokoonpanossa?

Antaako reitittimen haltuunotto pääsyn vain diagnostiikkaan vai myös HMI:hin, PLC:hen, käyttöihin ja safety PLC:hen?

Onko mahdollista vain lukea tietoja vai myös muuttaa ohjelmaa tai parametreja?

Voiko hyökkäys vaikuttaa turvallisuustoimintoon?

Onko toimittaja julkaissut korjauksen?

Muuttaako reitittimen päivitys varmenteita, tiedonsiirtosääntöjä tai tunnelin muodostamistapaa?

Onko päivityksen jälkeen tarkistettava uudelleen etähuolto, tiedonsiirto ja osa turvallisuustoiminnoista?

Kenelle asiakkaille on ilmoitettava?

Ja täyttääkö tilanne aktiivisesti hyväksikäytetyn haavoittuvuuden tai vakavan poikkeaman ilmoituskriteerit?

Ennen FAT:ia tehty pentestiraportti ei vastaa yhteenkään näistä kysymyksistä.

Se kuvaa konetta, jota ei enää ole olemassa.

Koska arvioinnin jälkeen ovat muuttuneet ohjelmistoversiot, asetukset, käyttöympäristö ja tieto haavoittuvuuksista.

Siksi valmistaja ei tarvitse pelkkää testiä vaan prosessin:

• laitteiston, firmware’n ja ohjelmiston versioiden tunnistamiseen jokaisessa toimitetussa kappaleessa,
• haavoittuvuustiedon seurantaan,
• niiden hyödyntämismahdollisuuksien arviointiin todellisessa arkkitehtuurissa,
• mahdollisten vaikutusten tarkistamiseen prosessille ja koneen turvallisuudelle,
• päivitysten valmisteluun ja testaamiseen,
• käyttäjien tiedottamiseen,
• tehtyjen päätösten dokumentointiin,
• vaadittujen ilmoitusten käsittelyyn.

11. syyskuuta 2026 alkaen valmistajilla on velvollisuus raportoida aktiivisesti hyväksikäytetyt haavoittuvuudet sekä vakavat poikkeamat, jotka vaikuttavat digitaalielementtejä sisältävien tuotteiden turvallisuuteen. Alustava varoitus on toimitettava 24 tunnin kuluessa ja täydellinen ilmoitus 72 tunnin kuluessa.

Tämä tarkoittaa, että ongelman havaitsemisen jälkeen ei ole aikaa aloittaa selvittelyä:

”Kuka tämän reitittimen oikeastaan teki, ja missä meillä on luettelo koneista, joihin se asennettiin?”

IEC 62443-4-1 havainnollistaa hyvin eron tuotteen kertaluonteisen suojaamisen ja sen turvallisen kehityselinkaaren välillä. Se kattaa suunnittelun ja verifioinnin lisäksi myös vikojen, korjausten ja tuotteen elinkaaren päättymisen hallinnan.

FAT voi siis päättää projektivaiheen.

Se ei päätä tuotteen elinkaarta.

Se ei päätä tukijaksoa.

Se ei lopeta haavoittuvuuksien seurantaa.

Eikä se tarkoita, että vastaanottopäivän kokoonpano jäädytetään seuraaviksi viideksitoista vuodeksi.

Kone voi pakata vihanneksia supermarketeille pitkän aikaa.

Valmistaja ei kuitenkaan voi pakata sen kyberturvallisuutta käyttöohjeen mukaan, sinetöidä sitä kalvoon ja katsoa, että se on toimitettu lopullisesti yhdellä kertaa.

Pentest voi sulkea kohdan FAT-listalla. CRA avaa prosessin, joka jatkuu tuotteen tukijakson loppuun asti.