Tietoturva, joka ei pysäytä tuotantoa, vaan pitää sen käynnissä

Kaksi maailmaa, kaksi eri todellisuutta

IT- ja OT-verkot kytkeytyvät toisiinsa kiihtyvällä vauhdilla. Tehdas ei ole enää eristetty saareke, vaan kytkeytyy osaksi liiketoiminnan ohjausjärjestelmiä, pilvipalveluita ja toimittajien etäyhteyksiä. Tuottavuushyödyt ovat kiistattomia, mutta samalla hyökkäyspinta-ala on laajentunut tavalla, johon kumpikaan osapuoli ei yksin ole täysin valmistautunut.

Perusongelma on, että IT ja OT ajattelevat tietoturvaa eri kulmista. Ilman yhteistä kieltä nämä erot johtavat siihen, että tietoturva koetaan tuotannon esteeksi, vaikka todellisuudessa sen pitäisi olla yksi prosessiturvallisuuden kriittisistä edellytyksistä.

IEC 62443: teollisuuden ehdoilla rakennettu standardi

IEC 62443 ei tuo IT-maailman oletuksia sellaisenaan tehdaslattialle, vaan standardi on rakennettu niin, että turvallisuusvaatimukset määritellään teollisuuden omilla ehdoilla. Painopiste siirtyy jäykistä teknisistä säännöistä riskiperusteiseen lähestymistapaan, jossa prosessin jatkuvuus ja fyysinen turvallisuus ovat lähtökohtia, eivät kompromisseja.

Standardi edesauttaa tuomaan tietoturvallisuuden lähemmäs tehtaanlattiaa huomioimalla esimerkiksi seuraavat näkökulmat:

Käytännössä standardi auttaa vastaamaan kysymyksiin, jotka heräävät jokaisessa tietoturvahankkeessa:

• Mitä olemme suojaamassa ja mitkä ovat suurimmat riskit?

• Kuinka vahvaa suojausta kukin järjestelmän osa vaatii?

• Miten järjestelmäarkkitehtuuri tulisi osioida hyökkäyksen leviämisen estämiseksi?

• Mitä teknisiä tietoturvavaatimuksia laitteiden ja järjestelmien on täytettävä?

• Kuka on vastuussa mistäkin turvallisuuden osa-alueesta?

• Miten turvataan elinkaareltaan pitkät ja vanhentuneet (legacy) järjestelmät?

• Miten varmistetaan, että turvallisuus säilyy koko järjestelmän elinkaaren ajan?

Mitä kokonaisuutta ollaan suojaamassa?

Ennen kuin mitään voidaan suojata, on määriteltävä, mitä ollaan suojaamassa. IEC 62443 kutsuu tätä System under Consideration -käsitteellä (SuC).

Määrittely rajaa tarkastelun kohteen: mitkä laitteet, järjestelmät, verkot ja prosessit kuuluvat suojauksen piiriin, ja mitkä jäävät sen ulkopuolelle.

Järjestelmää rajatessa kannattaa pohtia esimerkiksi seuraavia kysymyksiä:

• Mitkä laitteet ja järjestelmät osallistuvat suojattavaan prosessiin?

• Missä kulkevat rajat suojattavan järjestelmän ja ulkomaailman välillä?

• Mitkä ulkoiset yhteydet, kuten toimittajat ja etäyhteydet, vaikuttavat järjestelmään?

• Kuka omistaa järjestelmän eri osat ja vastaa niiden turvallisuudesta?

Tarkan määrittelyn laiminlyöminen on yksi yleisimmistä virheistä OT-tietoturvahankkeissa. Liian laaja rajaus johtaa resurssien haaskaamiseen, liian kapea jättää kriittisiä aukkoja. Hyvin tehty scoping on investointi, joka maksaa itsensä takaisin jo seuraavassa vaiheessa.

Standardi selkeyttää myös vastuunjakoa määrittelemällä kolme toisiaan täydentävää roolia koko järjestelmän elinkaaren ajaksi.

• Järjestelmän omistaja vastaa kokonaisriskistä ja operatiivisesta toiminnasta. Käynnistää prosessin ja hyväksyy tavoitetasot

• Järjestelmäintegraattori suunnittelee ja rakentaa ratkaisun, joka täyttää omistajan asettamat turvallisuustavoitteet.

• Tuoteomistaja kehittää Secure by Design – komponentteja ja vastaa elinkaaren aikaisesta tuesta sekä päivityksistä.

Miten järjestelmä jaetaan loogisiin kokonaisuuksiin?

Kun suojattava järjestelmä on rajattu, sen sisäiset osat ryhmitellään vyöhykkeisiin (Zones) kriittisyyden ja riskiprofiilin mukaan. Vyöhyke kokoaa yhteen laitteet ja järjestelmät, joilla on samankaltaiset turvallisuusvaatimukset. Vyöhyke voi olla fyysinen alue, looginen verkkoalue tai näiden yhdistelmä.

Tämä on vaihe, jossa IT:n ja OT:n välinen yhteistyö konkretisoituu. Enää ei kiistellä siitä, saako kenttäverkkoon viedä tietyn protokollan, vaan määritellään yhdessä, mitä liikennettä väylän yli sallitaan, mihin suuntaan ja kuka valvoo.

Vyöhykkeet eivät ole umpinaisia saarekkeita. Tuotantodata pitää päästä ERP-järjestelmään, huoltoinsinööri tarvitsee etäyhteyden kenttälaitteeseen, ja pilvipalvelu kerää prosessidataa reaaliajassa. Tässä vaiheessa jokainen vyöhykkeiden välinen yhteys tunnistetaan ja sille määritellään tietoväylä selkeine sääntöineen.

IEC 62443 tukee myös Purdue-mallin (PERA, Purdue Enterprise Reference Architecture) käyttöä vyöhykejaon viitekehyksenä. Purdue-malli jakaa teollisuusjärjestelmän kuuteen kerrokseen, jotka kuvaavat tiedonkulkua kenttätasolta yritysverkkoon. Malli auttaa IT-asiantuntijoita ymmärtämään OT-hierarkian logiikan ja OT-insinöörejä hahmottamaan, mihin kohtaan tietoturvarajat on luontevinta vetää.

Vaikka Purdue-malli ei ole pakollinen osa IEC 62443:a, on se käytännössä vakiintunut viitekehys, jota standardi tukee. Se antaa yhteisen kartan, jonka avulla sekä IT- että OT-asiantuntija pystyvät osoittamaan, missä kerroksessa jokin laite tai järjestelmä sijaitsee ja minkä vyöhykkeen piiriin se kuuluu.

Millä tasolla kutakin vyöhykettä suojataan?

Kun vyöhykkeet ja tietoväylät ovat määritelty, jokaiselle vyöhykkeelle tehdään riskiarviointi ja asetetaan tavoitetaso (Target Security Level, SL-T). Tasot perustuvat hyökkääjän kyvykkyyteen, resursseihin ja motivaatioon, ja ne ovat kumulatiivisia: jokainen taso sisältää edellisen kontrollit ja lisää niiden päälle uusia vaatimuksia.

Tavoitetaso (SL-T) on omistajan määrittelemä vaatimus. Sitä verrataan tuotteen sisäänrakennettuun kyvykkyyteen (SL-C) ja todennetaan saavutettu taso (SL-A). Jos kenttälaitteen oma kyvykkyys on matala, tavoitetaso saavutetaan verkkotason kontrolleilla tai fyysisillä rajoituksilla. Asiakas ei joudu vaihtamaan toimivaa kalustoa uuteen vain tietoturvan takia.

Riskiarvioinnin tuloksena syntyvät seitsemän perusvaatimuksen (Foundational Requirements, FR) mukaiset kontrollit, joiden laajuus skaalautuu vyöhykkeen SL-tason mukaan. Standardi (IEC 62443-3-3) määrittelee 110 konkreettista järjestelmävaatimusta, jotka ovat jaettu näihin seitsemään perusvaatimukseen. Perusvaatimuksia ovat:

• Tunnistus- ja todennusvalvonta (IAC)

• Tietojen luottamuksellisuus (DC)

• Käyttövalvonta (UC)

• Rajoitettu tietovirta (RDF)

• Resurssien saatavuus (RA)

• Järjestelmän eheys (SI)

• Ajankohtainen reagointi tapahtumiin (TRE)

Alla esimerkki siitä, miten sama perusvaatimus skaalautuu käytännön kontrolleiksi eri turvallisuustasoilla.

Sama logiikka pätee kaikkiin seitsemään perusvaatimukseen. SL-taso ei määritä vain sitä, kuinka monta kontrollia on käytössä, vaan myös niiden syvyyttä: manuaalisesta automaattiseen, reaktiivisesta ennakoivaan, yksittäisestä kattavaan.

Strategiasta tehdaslattialle ja regulaation vaatimuksiin asti – miten NIS2 hyötyy IEC 62443:sta

IEC 62443 toimii myös siltana ylätason hallinnollisten viitekehysten ja tehdaslattian välillä. Kun ylätason viitekehys vaatii etäyhteyksien suojaamista, standardi ohjeistaa tarkasti, miten teollisuuden etäkäyttö rakennetaan tietoväylien ja monivaiheisen todennuksen avulla niin, ettei se vaaranna reaaliaikaista prosessinohjausta. Vastaus ei ole "asenna VPN ja MFA", vaan arkkitehtuurikuva, jossa etäkäyttö on oma vyöhykkeensä, väylät ovat auditoituja ja todennus on suunniteltu kestämään tavoitetason mukaiset uhkat.

EU:n NIS2-direktiivi asettaa kyberkestävyysvaatimuksia ja toimitusketjun hallintavelvoitteita, mutta jättää yksityiskohdat tarkoituksella avoimiksi. IEC 62443 antaa niille konkreettisen toteutuspolun suoraan tehdastasolla. Asiakas saa yhdellä investoinnilla sekä toimivan tietoturva-arkkitehtuurin että valmiin vastauksen sääntelyn vaatimuksiin, ilman että toinen tulee toisen kustannuksella.

IEC 62443 ei ole pelkkä tekninen standardi. Se on työkalu, joka auttaa IT- ja OT-osapuolia puhumaan samaa kieltä, rakentamaan yhteisen näkemyksen riskienhallinnasta ja tekemään investointipäätöksiä tiedolla.

Tietoturva ei ole tuotannon este. Se on sen edellytys.

Jäivätkö aikaisemmat blogisarjan osat lukematta?
Osa 1: Miksi IT ja OT vaativat eri pelikirjan
Osa 2: Nykyaikaisen OT:n turvallisuus alkaa IT-verkosta: Miksi Zero Trust ja Least Privilege ovat teollisuuden tietoturvan kulmakivi?