NIS2:n OT-tietoturva: ISO 27001- ja IEC 62443 -kartoitus

Maanantaina klo 02.17 vedenkäsittelylaitoksen operaattori saa hälytyksen annostelujärjestelmästä. Kemikaalisyöttö on edelleen turvallisuusrajojen sisällä, mutta yksi PLC raportoi epäsäännöllisiä komentoja, suunnittelutyöasemalla näkyy epäonnistuneita kirjautumisia toimittajan VPN-tililtä, ja päivystävä SOC-analyytikko esittää kysymyksen, johon kukaan ei halua vastata paineen alla.

Onko kyse IT-poikkeamasta, OT-poikkeamasta, turvallisuustapahtumasta vai NIS2:n mukaisesti ilmoitettavasta merkittävästä poikkeamasta?

Laitoksella on palomuurit. Sillä on ISO 27001 -dokumentaatio. Sillä on toimittajaluettelo. Sillä on jopa tietoturvapoikkeamien hallintasuunnitelma. Suunnitelma on kuitenkin laadittu sähköpostitilin vaarantumista ja pilvipalvelukatkoksia varten, ei tuotannon aikana paikkauskelvotonta legacy-ohjainta varten, ei toimittajaa varten, joka tarvitsee etäkäyttöä palvelun palauttamiseksi, eikä viranomaista varten, joka odottaa näyttöä NIS2:n ilmoitusmääräaikojen puitteissa.

Sama ongelma näkyy johtoryhmissä. Alueellisen energiayhtiön tietoturvajohtajalla voi olla yritys-IT:tä koskeva ISO/IEC 27001:2022 -sertifioitu tietoturvallisuuden hallintajärjestelmä, samalla kun operatiivisen teknologian kokonaisuus on sekava yhdistelmä PLC-laitteita, RTU-yksiköitä, HMI-käyttöliittymiä, historiatietokantoja, suunnittelutyöasemia, teollisuuskytkimiä ja toimittajien käyttöyhteyksiä. Toimitusjohtajan kysymys on yksinkertainen: ”Olemmeko katettuja? Voitko todistaa sen?”

Monien keskeisten ja tärkeiden toimijoiden rehellinen vastaus on epämukava. Ne ovat osittain katettuja. Ne voivat osoittaa sen osittain. NIS2:n OT-tietoturva edellyttää kuitenkin enemmän kuin yleistä IT-vaatimustenmukaisuutta.

Se edellyttää yhtenäistä toimintamallia, joka yhdistää ISO/IEC 27001:2022 -hallinnoinnin, ISO/IEC 27002:2022 -kontrollikielen, IEC 62443:n teolliset suunnittelukäytännöt, NIS2 Article 21 -artiklan kyberturvallisuuden riskienhallintatoimenpiteet ja NIS2 Article 23 -artiklan poikkeamailmoittamisen näytön.

Tämän sillan tämä opas rakentaa.

Miksi NIS2:n OT-tietoturva eroaa tavanomaisesta IT-vaatimustenmukaisuudesta

NIS2 koskee monia julkisia ja yksityisiä toimijoita, jotka tarjoavat soveltamisalaan kuuluvia palveluja EU:ssa. Näihin sisältyvät keskeiset ja tärkeät toimijat esimerkiksi energia-, liikenne-, pankki-, finanssimarkkinoiden infrastruktuuri-, terveys-, juomavesi-, jätevesi-, digitaalisen infrastruktuurin, ICT-palvelunhallinnan, julkishallinnon, avaruus-, posti-, jätehuolto-, valmistus-, kemikaali-, elintarvike-, digitaalisten palveluntarjoajien ja tutkimuksen sektoreilla.

Direktiivi edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä kyberriskien hallitsemiseksi, poikkeamien vaikutusten ehkäisemiseksi tai minimoimiseksi ja palvelujen jatkuvuuden suojaamiseksi. Article 21 sisältää kaikki vaaratekijät kattavan lähestymistavan, joka kattaa riskianalyysin, tietoturvapolitiikat, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, kriisinhallinnan, toimitusketjun tietoturvan, turvallisen hankinnan ja ylläpidon, haavoittuvuuksien käsittelyn ja julkistamisen, vaikuttavuuden arvioinnin, kyberhygienian, koulutuksen, kryptografian, henkilöstöturvallisuuden, pääsynhallinnan, omaisuudenhallinnan, MFA:n tai jatkuvan todennuksen, turvallisen viestinnän sekä tarvittaessa hätäviestinnän.

Nämä vaatimukset kuulostavat tutuilta ISO/IEC 27001:2022 -tiimille. OT-ympäristössä jokainen niistä käyttäytyy eri tavalla.

Web-palvelimen haavoittuvuus voidaan usein paikata muutamassa päivässä. Turbiiniohjaimen haavoittuvuus voi edellyttää toimittajan validointia, huoltoikkunaa, turvallisuuskatselmointia ja varakäyttömenettelyjä. Kannettava tietokone voidaan asentaa uudelleen. Tuotannon HMI voi olla riippuvainen legacy-käyttöjärjestelmästä, koska teollisuussovellusta ei ole sertifioitu uudemmalle alustalle. SOC:n toimintapelikirja voi ohjeistaa ”eristä isäntä”, kun OT-insinööri vastaa: ”ei ennen kuin tiedämme, vaikuttaako eristäminen paineenhallintaan”.

Ero ei ole vain tekninen. IT priorisoi yleensä luottamuksellisuutta, eheyttä ja saatavuutta. OT priorisoi saatavuutta, prosessin eheyttä ja turvallisuutta. Tietoturvakontrolli, joka lisää viivettä, edellyttää uudelleenkäynnistystä tai keskeyttää fyysisen prosessin, voi olla hyväksymätön ilman teknisen suunnittelun hyväksyntää.

NIS2 ei vapauta OT-ympäristöjä kyberturvallisuuden riskienhallinnasta. Se edellyttää, että organisaatio pystyy osoittamaan kontrollien olevan riskiin nähden asianmukaisia ja operatiiviseen todellisuuteen nähden oikeasuhteisia.

Kontrollipino: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 ja IEC 62443

Puolustettava NIS2:n OT-tietoturvaohjelma alkaa kerroksellisesta kontrollipinosta.

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän. Se edellyttää, että organisaatio määrittää toimintaympäristön, sidosryhmät, sääntelyvelvoitteet, ISMS:n soveltamisalan, rajapinnat ja riippuvuudet. Se edellyttää myös johdon omistajuutta, tietoturvapolitiikkaa, riskien arviointia, riskien käsittelyä, soveltuvuuslausuntoa, dokumentoitua tietoa, sisäistä auditointia, johdon katselmointia ja jatkuvaa parantamista.

ISO/IEC 27002:2022 tarjoaa kontrollisanaston. OT:n kannalta tärkeimpiä kontrolleja ovat usein toimittajaturvallisuus, ICT-toimitusketjun riskienhallinta, poikkeamasuunnittelu, valmius liiketoiminnan jatkuvuuteen, lakisääteiset ja sopimusperusteiset vaatimukset, omaisuudenhallinta, pääsynhallinta, haavoittuvuuksien hallinta, varmuuskopiot, lokitus, seuranta, verkkoturvallisuus ja verkkojen eriyttäminen.

IEC 62443 tarjoaa teollisen tietoturvasuunnittelun mallin. Se auttaa muuntamaan hallintajärjestelmän vaatimukset OT-käytännöiksi, kuten vyöhykkeiksi, kanaviksi, turvallisuustasoiksi, omaisuuserien omistajien vastuiksi, järjestelmäintegraattorien vastuiksi, tuotetoimittajiin kohdistuviksi odotuksiksi, etäkäytön rajoituksiksi, vähimmäistoiminnallisuudeksi, käyttäjätilien hallinnaksi, koventamiseksi ja elinkaarikontrolleiksi.

Clarysec käyttää tätä pinoa, koska se ehkäisee kaksi yleistä epäonnistumista. Ensinnäkin se estää ISO-toteutusta jäämästä OT:n näkökulmasta liian yleiselle tasolle. Toiseksi se estää IEC 62443 -suunnittelutyötä irtoamasta hallituksen osoitusvelvollisuudesta, NIS2-ilmoitusvelvoitteista ja auditointinäytöstä.

Clarysecin IoT-/OT-tietoturvapolitiikka ilmaisee sillan suoraan:

Varmistaa, että kaikki käyttöönotot ovat yhdenmukaisia ISO/IEC 27001 -kontrollien ja sovellettavan sektorikohtaisen ohjeistuksen kanssa (esim. IEC 62443, ISO 27019, NIST SP 800-82).

Tällä lauseella on merkitystä. Politiikka ei ole pelkkä laitteiden koventamisen tarkistuslista. Se yhdistää ISO-hallinnoinnin, OT-sektorin ohjeistuksen ja operatiivisen tietoturvan.

Aloita soveltamisalasta: mitä OT-palvelua on suojattava?

Ennen kontrollien kartoittamista määritä OT-palvelu liiketoiminnan ja sääntelyn kielellä.

Laitospäällikkö voi sanoa: ”Käytämme pakkauslinjaa.” NIS2-arvioinnissa tulisi todeta: ”Tämä tuotantoprosessi tukee keskeistä tai tärkeää palvelua ja on riippuvainen PLC-laitteista, HMI-käyttöliittymistä, suunnittelutyöasemista, historiatietokannoista, teollisuuskytkimistä, toimittajan etäkäytöstä, huoltourakoitsijasta, pilvipohjaisesta analytiikkasyötteestä ja yrityksen identiteettipalvelusta.”

ISO/IEC 27001:2022 -standardin kohdat 4.1–4.4 ovat hyödyllisiä, koska ne pakottavat organisaation tunnistamaan sisäiset ja ulkoiset tekijät, sidosryhmät, lakisääteiset ja sopimusperusteiset vaatimukset, ISMS:n rajat, rajapinnat ja riippuvuudet. NIS2:n OT-tietoturvassa tämä tarkoittaa, ettei kartoiteta vain pääkonttorin verkkoa, vaan myös teolliset järjestelmät ja palveluriippuvuudet, jotka vaikuttavat jatkuvuuteen, turvallisuuteen ja säänneltyyn palvelutuotantoon.

NIST CSF 2.0 vahvistaa samaa logiikkaa. Sen GOVERN-toiminto edellyttää mission, sidosryhmien, riippuvuuksien, lakisääteisten ja sääntelyvelvoitteiden, kriittisten palvelujen sekä organisaation riippuvuuden kohteena olevien palvelujen ymmärtämistä. Organizational Profiles tarjoaa käytännöllisen menetelmän nykytilan rajaamiseen, tavoitetilan määrittämiseen, puutteiden analysointiin ja priorisoidun toimintasuunnitelman tuottamiseen.

OT-ympäristössä Clarysec aloittaa tyypillisesti viidellä kysymyksellä:

1. Mitä säänneltyä tai kriittistä palvelua tämä OT-ympäristö tukee?
2. Mitä OT-omaisuuseriä, verkkoja, tietovirtoja ja kolmansia osapuolia tarvitaan kyseistä palvelua varten?
3. Mitkä turvallisuus-, saatavuus- ja operatiiviset rajoitteet vaikuttavat tietoturvakontrolleihin?
4. Mitkä lakisääteiset, sopimusperusteiset ja sektorikohtaiset velvoitteet soveltuvat, mukaan lukien NIS2, GDPR, DORA soveltuvin osin, asiakassopimukset ja kansalliset säännökset?
5. Mitkä ympäristön osat kuuluvat ISMS:n piiriin, ja mitkä ovat ulkoisia riippuvuuksia, jotka edellyttävät toimittajakontrolleja?

Monet NIS2-ohjelmat epäonnistuvat tässä. Soveltamisala rajataan yritys-IT:n ympärille, koska sen inventointi on helpompaa. Auditoijat ja viranomaiset eivät vakuutu, jos kriittisin palveluriippuvuus näkyy vain epämääräisenä rivinä nimellä ”tehdasverkko”.

Käytännön NIS2:n OT-kontrollikartta

Alla oleva taulukko näyttää, miten NIS2 Article 21 -teemat voidaan muuntaa ISO/IEC 27001:2022-, ISO/IEC 27002:2022- ja IEC 62443 -näytöksi. Se ei korvaa muodollista riskien arviointia, mutta antaa tietoturvajohtajille, OT-päälliköille ja vaatimustenmukaisuustiimeille käytännöllisen lähtökohdan.

Tämä kartta on tarkoituksella näyttökeskeinen. NIS2:n mukaan ei riitä sanoa ”meillä on segmentointi”. On osoitettava, miksi segmentointi on asianmukainen, miten se on toteutettu, miten poikkeukset hyväksytään ja miten suunnittelu vähentää vaikutuksia säänneltyyn palveluun.

Segmentointi: ensimmäinen OT-kontrolli, jonka auditoijat testaavat

Jos klo 02.17 tapahtuneessa poikkeamassa hyökkääjä olisi siirtynyt toimistokannettavalta suunnittelutyöasemalle, ensimmäinen auditointikysymys olisi ilmeinen: miksi tällainen reitti saattoi olla olemassa?

IoT-/OT-tietoturvapolitiikka on tältä osin yksiselitteinen:

OT-järjestelmien on toimittava erillisissä verkoissa, jotka on eristetty yritys-IT:stä ja internetiin avautuvista järjestelmistä.

Pienemmille ympäristöille Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME antaa käytännön perustason:

Kaikki Internet of Things (IoT)- ja Operational Technology (OT) -laitteet on sijoitettava erilliseen Wi-Fi- tai VLAN-verkkoon

Kypsällä kriittisen infrastruktuurin toimijalla segmentointi tulee suunnitella OT-vyöhykkeiden ja -kanavien ympärille. Yrityskäyttäjillä ei tule olla suoraa pääsyä PLC-verkkoihin. Toimittajayhteyksien tulee päättyä hallittuihin pääsyvyöhykkeisiin. Historiatietokannan replikoinnin tulee käyttää hyväksyttyjä reittejä. Turvallisuusjärjestelmät tulee eristää riskien ja teknisen suunnittelun vaatimusten mukaisesti. Langattomat OT-verkot tulee perustella, koventaa ja asettaa seurantaan.

Zenith Blueprint: auditoijan 30-vaiheinen tiekartta selittää Kontrollit käytännössä -vaiheen vaiheessa 20 ISO/IEC 27002:2022 -standardin verkkoturvallisuuden taustaperiaatteen:

Teolliset ohjausjärjestelmät tulee eristää toimistoliikenteestä.

Se myös varoittaa, että verkkoturvallisuus edellyttää turvallista arkkitehtuuria, segmentointia, pääsynhallintaa, siirrettävien tietojen salausta, seurantaa ja kerroksellista puolustusta.

Zenith Controls: vaatimustenmukaisuuksien välinen opas käsittelee ISO/IEC 27002:2022 -kontrollia 8.22, Segregation of Networks, ennaltaehkäisevänä kontrollina, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta, on linjassa Protect-kyberturvallisuuskäsitteen kanssa, käyttää järjestelmä- ja verkkoturvallisuutta operatiivisena kyvykkyytenä ja kuuluu Protection-tietoturva-alueeseen.

Tämä luokittelu on hyödyllinen NIS2-näytön kannalta, koska segmentointi ei ole koristeellinen kaavio. Se on ennaltaehkäisevä kontrolli, jonka tarkoituksena on vähentää vaikutusaluetta ja säilyttää keskeisen palvelun jatkuvuus.

Haavoittuvuuksien hallinta, kun OT-järjestelmiä ei voida vain paikata

NIS2 edellyttää verkko- ja tietojärjestelmien turvallista hankintaa, kehittämistä ja ylläpitoa, mukaan lukien haavoittuvuuksien käsittely ja julkistaminen. IT:ssä haavoittuvuuksien hallinta tarkoittaa usein havaitsemista, priorisointia, paikkausta ja varmentamista. OT tuo tähän rajoitteita.

Kriittinen HMI voi olla paikattavissa vain suunnitellun käyttökatkon aikana. PLC:n laiteohjelmistopäivitys voi edellyttää toimittajan osallistumista. Turvallisuussertifioitu järjestelmä voi menettää sertifiointinsa, jos sitä muutetaan virheellisesti. Joillekin legacy-laitteille ei välttämättä ole lainkaan toimittajatukea.

Zenith Blueprint, Kontrollit käytännössä -vaihe, vaihe 19, antaa teknisille haavoittuvuuksille oikean auditointilogiikan:

Järjestelmille, joita ei voida paikata välittömästi esimerkiksi legacy-ohjelmiston tai käyttökatkorajoitteiden vuoksi, tulee toteuttaa korvaavat kontrollit. Tämä voi tarkoittaa järjestelmän eristämistä palomuurin taakse, käyttöoikeuksien rajoittamista tai seurannan lisäämistä. Kaikissa tapauksissa asia on kirjattava ja jäännösriski hyväksyttävä muodollisesti, mikä osoittaa, ettei ongelmaa ole unohdettu.

Pk-yrityksen politiikan perustaso on samalla tavoin käytännöllinen:

Omaisuusluettelo on katselmoitava neljännesvuosittain vanhentuneiden, tuettomien tai paikkaamattomien laitteiden tunnistamiseksi

Zenith Controls -oppaassa ISO/IEC 27002:2022 -kontrolli 8.8, Management of Technical Vulnerabilities, on kartoitettu ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta, on linjassa Identify- ja Protect-käsitteiden kanssa ja käyttää uhkien ja haavoittuvuuksien hallintaa operatiivisena kyvykkyytenä Governance-, Ecosystem-, Protection- ja Defense-alueilla.

Vahvan OT-haavoittuvuustiedoston tulee sisältää:

• Omaisuuserän tunniste, omistaja, vyöhyke ja kriittisyys
• Haavoittuvuuden lähde, kuten toimittajan tiedote, skanneri, integraattorin ilmoitus tai uhkatiedustelu
• Turvallisuus- ja saatavuusrajoitteet
• Paikkauskelpoisuus ja suunniteltu huoltoikkuna
• Korvaavat kontrollit, kuten eristäminen, käyttöoikeusluettelot, käytöstä poistetut palvelut tai lisätty seuranta
• Riskinomistajan hyväksyntä ja jäännösriskin hyväksyntä
• Varmennusnäyttö korjaavien toimenpiteiden tai korvaavan kontrollin toteutuksen jälkeen

Näin ”emme voi paikata” muuttuu tekosyystä auditoitavaksi riskien käsittelyksi.

Toimittajan etäkäyttö: NIS2:n ja IEC 62443:n kriittinen kohta

Useimmissa OT-poikkeamissa on jossain kolmannen osapuolen ulottuvuus. Toimittajatili. Integraattorin kannettava. Etähuoltotyökalu. Jaettu tunnus. Palomuuripoikkeus, jonka piti olla väliaikainen kolme vuotta sitten.

NIS2 Article 21 sisältää nimenomaisesti toimitusketjun tietoturvan, toimittajakohtaiset haavoittuvuudet, toimittajien kyberturvallisuuskäytännöt ja turvalliset kehitysmenettelyt. NIST CSF 2.0 käsittelee tätä myös yksityiskohtaisesti toimittajan kriittisyyden, sopimusvaatimusten, huolellisuuden, jatkuvan seurannan, poikkeamien koordinoinnin ja irtautumisehtojen kautta.

Clarysecin Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - SME ilmaisee periaatteen selkeästi:

Toimittajille saa myöntää pääsyn vain niihin vähimmäisjärjestelmiin ja tietoihin, joita heidän tehtävänsä suorittaminen edellyttää.

OT-ympäristössä vähimmäispääsy tarkoittaa enemmän kuin roolipohjaista pääsyä sovelluksessa. Toimittajan pääsyn tulee olla:

• Ennakkohyväksytty määriteltyä huoltotarkoitusta varten
• Aikarajoitettu ja oletusarvoisesti pois käytöstä
• Suojattu MFA:lla tai tarvittaessa jatkuvalla todennuksella
• Reititetty turvallisen hyppypalvelimen tai hallitun etäkäyttöalustan kautta
• Rajattu asianomaiseen OT-vyöhykkeeseen tai omaisuuserään
• Kirjattu lokiin, asetettu seurantaan ja korkean riskin pääsyssä tallennettu istuntotasolla
• Katselmoitu suorituksen jälkeen
• Katettu sopimusperusteisilla tietoturva- ja poikkeamailmoitusvelvoitteilla

Yritystason IoT-/OT-tietoturvapolitiikka sisältää erillisen etäkäyttövaatimuksen:

Etäkäytön (hallintaa tai toimittajan huoltoa varten) on:

Tämä lauseke ankkuroi hallinnointikohdan, kun taas yksityiskohtaiset vaatimukset tulee toteuttaa käyttöoikeusmenettelyissä, toimittajasopimuksissa, teknisissä konfiguraatioissa ja seurannan työnkuluissa.

Zenith Controls -oppaassa ISO/IEC 27002:2022 -kontrolli 5.21, Managing information security in the ICT supply chain, luokitellaan ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta, on linjassa Identify-käsitteen kanssa ja käyttää toimittajasuhteiden turvallisuutta operatiivisena kyvykkyytenä Governance-, Ecosystem- ja Protection-alueilla.

OT:n osalta tämä kartoitus auttaa selittämään, miksi etäkäyttöä koskeva näyttö kuuluu samanaikaisesti toimittajariskin, identiteetinhallinnan, verkkoturvallisuuden, tietoturvapoikkeamien hallinnan ja jatkuvuuden tiedostoihin.

Tietoturvapoikkeamien hallinta: NIS2:n kello kohtaa valvomon

Palataan klo 02.17 hälytykseen. Organisaation on päätettävä, onko tapahtuma NIS2:n mukaisesti merkittävä. Article 23 edellyttää merkittävistä palveluntuotantoon vaikuttavista poikkeamista ilmoittamista ilman aiheetonta viivytystä. Jaksoon sisältyy varhaisvaroitus 24 tunnin kuluessa tietoisuudesta, poikkeamailmoitus 72 tunnin kuluessa, pyydettäessä välipäivitykset sekä loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta tai edistymisraportti, jos poikkeama on edelleen käynnissä.

OT-ympäristössä tietoturvapoikkeamien hallinnan on vastattava kysymyksiin, jotka IT-toimintapelikirjat usein sivuuttavat:

• Voidaanko vaikutuksen kohteena oleva laite eristää aiheuttamatta turvallisuusriskiä?
• Kenellä on toimivalta pysäyttää tuotanto tai siirtyä manuaalitilaan?
• Mitkä lokit ovat haihtuvia ja vaativat välitöntä säilyttämistä?
• Mihin toimittajaan tai integraattoriin on otettava yhteyttä?
• Onko tapahtuma pahantahtoinen, vahingollinen, ympäristöstä johtuva vai virheellisestä konfiguraatiosta aiheutunut?
• Voiko tapahtumalla olla rajat ylittäviä vaikutuksia tai vaikutuksia palvelun vastaanottajiin?
• Liittyykö tapahtumaan henkilötietoja, kuten kulkukorttilokeja, CCTV:tä, työntekijätietoja tai asiakaspalvelutallenteita?

Pk-yrityksen OT-politiikka antaa yksinkertaisen poikkeamien eskalointisäännön:

Kaikista poikkeamista on ilmoitettava välittömästi toimitusjohtajalle jatkotoimia varten

Se sisältää myös turvallisuuden huomioivan rajaamisperiaatteen:

Laite on irrotettava verkosta välittömästi, jos se voidaan tehdä turvallisesti

Nuo viimeiset viisi sanaa ovat kriittisiä. OT-reagointi ei voi kopioida IT:n rajaamistoimia sokeasti. ”Jos se voidaan tehdä turvallisesti” tulee näkyä palautusohjeissa, eskalointimatriiseissa, koulutuksessa ja pöytäharjoituksissa.

NIST CSF 2.0 soveltuu tähän hyvin. Sen Respond- ja Recover-tulokset kattavat luokittelun, kategorisoinnin, eskaloinnin, juurisyyanalyysin, todistusaineiston eheyden, sidosryhmille ilmoittamisen, rajaamisen, hävittämisen, palauttamisen, varmuuskopioiden eheyden tarkastukset ja palautusviestinnän.

Rakenna riskistä kontrolliin ulottuva näyttöketju

Käytännöllinen tapa välttää pirstaloitunut vaatimustenmukaisuus on rakentaa yksi näyttöketju riskistä sääntelyyn, kontrolliin ja todentavaan aineistoon.

Skenaario: etäkompressoritoimittaja tarvitsee pääsyn OT-verkon suunnittelutyöasemalle. Työasema voi muuttaa PLC-logiikkaa. Toimittajatili on aina käytössä, sitä jakaa usea toimittajan insinööri ja se on suojattu vain salasanalla. Työasemassa on ohjelmisto, jota ei voida päivittää ennen seuraavaa huoltoseisokkia.

Kirjaa riskiskenaario riskirekisteriin:

”Luvaton tai vaarantunut toimittajan etäkäyttö OT:n suunnittelutyöasemaan voi johtaa luvattomiin PLC-logiikan muutoksiin, tuotantohäiriöön, turvallisuusvaikutukseen ja NIS2:n mukaisesti ilmoitettavaan palvelukatkokseen.”

Kartoita sen jälkeen kontrollit ja velvoitteet.

Käsittelysuunnitelman tulee poistaa pysyvä toimittajapääsy käytöstä, edellyttää nimettyjä toimittajaidentiteettejä, pakottaa MFA, reitittää käyttö hallitun hyppypalvelimen kautta, rajata pääsy suunnittelutyöasemaan, edellyttää huoltotiketin hyväksyntää, tallentaa etuoikeutetut istunnot, seurata komentoja ja poikkeavaa liikennettä, dokumentoida paikkaamaton työasema haavoittuvuuspoikkeuksena ja testata tietoturvapoikkeamien hallintaa epäilyttävän toimittajatoiminnan varalta.

Zenith Blueprint, Riskienhallinta-vaihe, vaihe 13, antaa SoA-jäljitettävyyslogiikan:

Ristiinviittaa sääntelyyn: Jos tietyt kontrollit on toteutettu nimenomaisesti GDPR:n, NIS2:n tai DORA:n noudattamiseksi, voit merkitä sen joko riskirekisteriin (osana riskivaikutuksen perustelua) tai SoA:n huomautuksiin.

Käytännön opetus on yksinkertainen. Älä säilytä NIS2-, ISO- ja OT-suunnittelunäyttöä erillisissä siiloissa. Lisää riskirekisteriin ja soveltuvuuslausuntoon sarakkeet NIS2 Article 21 -teemalle, ISO/IEC 27002:2022 -kontrollille, IEC 62443 -vaatimusperheelle, näytön omistajalle ja auditointitilalle.

Mihin GDPR ja DORA sijoittuvat OT-tietoturvassa

OT-tietoturva ei aina koske vain koneita. Kriittisen infrastruktuurin ympäristöt käsittelevät usein henkilötietoja CCTV:n, kulunvalvontajärjestelmien, kulkukorttilokien, henkilöstön turvallisuusjärjestelmien, huoltotikettien, ajoneuvoseurannan, vierailijajärjestelmien ja asiakaspalvelualustojen kautta.

GDPR edellyttää, että henkilötietoja käsitellään lainmukaisesti, kohtuullisesti ja läpinäkyvästi, kerätään määriteltyihin tarkoituksiin, rajoitetaan tarpeelliseen, pidetään täsmällisinä, säilytetään vain niin kauan kuin on tarpeen ja suojataan asianmukaisilla teknisillä ja organisatorisilla toimenpiteillä. Se edellyttää myös osoitusvelvollisuutta, eli rekisterinpitäjän on kyettävä osoittamaan vaatimustenmukaisuus.

OT:n osalta tämä tarkoittaa, etteivät käyttölokit ja seurantatallenteet saa muuttua hallitsemattomiksi valvontatietovarastoiksi. Säilytys, käyttöoikeudet, käyttötarkoitussidonnaisuus ja loukkausarviointi on suunniteltava osaksi lokitusta ja seurantaa.

DORA voi soveltua, jos mukana on finanssialan toimijoita tai jos ICT-kolmannen osapuolen palveluntarjoaja tukee finanssisektorin operatiivista häiriönsietokykyä. DORA kattaa ICT-riskien hallinnan, poikkeamien ilmoittamisen, häiriönsietokyvyn testauksen ja ICT-kolmansien osapuolten riskit. Finanssialan toimijoille, jotka ovat myös NIS2:n täytäntöönpanosääntöjen mukaisia keskeisiä tai tärkeitä toimijoita, DORA voi toimia sektorikohtaisena sääntelykehyksenä päällekkäisille velvoitteille, vaikka koordinointi NIS2-viranomaisten kanssa voi edelleen olla merkityksellistä.

Samat näyttöä koskevat käytännöt pätevät: omaisuuserien tunnistaminen, suojaus, havaitseminen, jatkuvuus, varmuuskopiointi, kolmansien osapuolten riski, testaus, koulutus ja johdon valvonta.

Auditointinäkökulma: yksi kontrolli, useita varmentamisnäkökulmia

Vahvan NIS2:n OT-tietoturvatoteutuksen tulee kestää useita auditointinäkökulmia.

Tästä syystä Clarysec käsittelee Zenith Controls -opasta vaatimustenmukaisuuksien välisenä kompassina. Sen kontrolliattribuutit auttavat selittämään virallisten ISO/IEC 27002:2022 -kontrollien tarkoitusta, ja kartoituslähestymistapa yhdistää nämä kontrollit NIS2:een, NIST CSF:ään, toimittajahallinnointiin, jatkuvuuteen ja auditointinäyttöön.

Yleiset NIS2:n OT-toteutuksen sudenkuopat

Yleisimmät OT-tietoturvan epäonnistumiset eivät yleensä johdu dokumenttien puutteesta. Ne johtuvat dokumenteista, jotka eivät vastaa laitoksen todellisuutta.

Sudenkuoppa 1: IT omistaa NIS2-ohjelman, mutta OT omistaa riskin. Operaatioiden, suunnittelutoiminnon, turvallisuuden ja ylläpidon on oltava mukana.

Sudenkuoppa 2: Omaisuusluettelo päättyy palvelimiin. OT-luettelon on sisällettävä PLC:t, RTU:t, HMI:t, historiatietokannat, suunnittelutyöasemat, teollisuuskytkimet, anturit, yhdyskäytävät, etäkäyttölaitteet ja toimittajan hallinnoimat komponentit.

Sudenkuoppa 3: Segmentointi on olemassa kaaviossa mutta ei palomuurisäännöissä. Auditoijat pyytävät näyttöä soveltamisesta, muutoksenhallinnasta ja seurannasta.

Sudenkuoppa 4: Haavoittuvuuspoikkeukset ovat epämuodollisia. Legacy-rajoitteet ovat hyväksyttäviä vain, kun ne on dokumentoitu, hyväksytty, asetettu seurantaan ja katselmoitu uudelleen.

Sudenkuoppa 5: Toimittajan pääsyä käsitellään vain toimittaja-asiana. Se on myös pääsynhallinnan, lokituksen, seurannan, verkkoturvallisuuden, tietoturvapoikkeamien hallinnan ja jatkuvuuden asia.

Sudenkuoppa 6: Tietoturvapoikkeamien hallinta sivuuttaa turvallisuuden. OT-toimintapelikirjojen on määriteltävä, kuka voi eristää laitteita, pysäyttää prosesseja, vaihtaa toimintatilaa tai ottaa yhteyttä viranomaisiin.

Sudenkuoppa 7: NIS2-ilmoittamista ei harjoitella. 24 ja 72 tunnin päätösprosessi tulee testata ennen todellista tapahtumaa.

Clarysecin toteutuspolku hallituksen osoitusvelvollisuudesta OT-näyttöön

Käytännöllinen NIS2:n OT-tietoturvan toteutus voi edetä seuraavasti:

1. Vahvista NIS2:n soveltamisala, toimijaluokitus ja palvelun kriittisyys.
2. Määritä OT:n soveltamisala ISMS:n sisällä, mukaan lukien rajapinnat ja riippuvuudet.
3. Laadi OT-omaisuuden ja tietovirtojen luettelo.
4. Tunnista lakisääteiset, sopimusperusteiset, turvallisuus-, tietosuoja- ja sektorivelvoitteet.
5. Toteuta OT-kohtaiset riskienarviointityöpajat suunnittelutoiminnon, operaatioiden, IT:n, SOC:n, hankinnan ja johdon kanssa.
6. Kartoita riskien käsittely ISO/IEC 27002:2022 -kontrolleihin, NIS2-teemoihin ja IEC 62443 -toteutusmalleihin.
7. Päivitä soveltuvuuslausunto OT-perusteluilla ja näytön omistajilla.
8. Toteuta prioriteettikontrollit: segmentointi, toimittajan pääsy, haavoittuvuuksien käsittely, seuranta, varmuuskopiot ja tietoturvapoikkeamien hallinta.
9. Päivitä politiikat ja menettelyt, mukaan lukien OT-tietoturva, toimittajaturvallisuus, etäkäyttö, tietoturvapoikkeamien hallinta ja liiketoiminnan jatkuvuus.
10. Toteuta pöytäharjoituksia ja teknisiä validointiharjoituksia.
11. Valmistele auditointipaketit NIS2:ta, ISO/IEC 27001:2022 -standardia, asiakkaiden varmentamista ja sisäistä hallinnointia varten.
12. Vie havainnot johdon katselmointiin ja jatkuvaan parantamiseen.

Tämä heijastaa Zenith Blueprint -oppaan toimintamallia, erityisesti vaihetta 13 riskien käsittelystä ja SoA-jäljitettävyydestä, vaihetta 14 politiikkojen kehittämisestä ja sääntelyviittauksista, vaihetta 19 haavoittuvuuksien hallinnasta ja vaihetta 20 verkkoturvallisuudesta.

Sama lähestymistapa käyttää Clarysecin politiikkoja viitekehyskielen muuntamiseen operatiivisiksi säännöiksi. Yritystason IoT-/OT-tietoturvapolitiikka edellyttää tietoturva-arkkitehtuurin katselmointia ennen käyttöönottoa:

Kaikkien uusien IoT/OT-laitteiden on läpäistävä tietoturva-arkkitehtuurin katselmointi ennen käyttöönottoa. Katselmoinnin on validoitava:

Siinä todetaan myös:

Kaikkea IoT/OT-verkkojen sisäistä ja niiden välistä liikennettä on seurattava jatkuvasti käyttäen:

Nämä lausekkeet luovat hallinnointikiinnikkeet. Toteutusnäyttö voi sisältää OT IDS -hälytyksiä, palomuurilokeja, SIEM-korrelointia, perustason liikenneprofiileja, poikkeamatikettejä ja reagointitallenteita.

Miltä hyvä NIS2:n OT-näyttö näyttää

NIS2:n OT-näyttöpaketin tulee olla riittävän käytännöllinen insinööreille ja riittävän jäsennelty auditoijille.

Segmentoinnista tulee sisällyttää hyväksytty arkkitehtuuri, vyöhyke- ja kanavakaaviot, palomuurisääntöjen viennit, muutostallenteet, säännölliset sääntökatselmoinnit, poikkeustallenteet ja seurantahälytykset.

Toimittajan pääsystä tulee sisällyttää toimittajan kriittisyysarviointi, sopimuslausekkeet, hyväksytty käyttöoikeusmenettely, nimetyt tilit, MFA-näyttö, käyttölokit, istuntotallenteet, säännöllinen käyttöoikeuskatselmointi ja poistumismenettelyn tallenteet.

Haavoittuvuuksien hallinnasta tulee sisällyttää omaisuusluettelo, tiedotelähteet, passiivisen havainnoinnin tulokset, haavoittuvuustiketit, paikkaussuunnitelmat, korvaavat kontrollit, riskin hyväksyntä ja sulkemisnäyttö.

Tietoturvapoikkeamien hallinnasta tulee sisällyttää toimintapelikirjat, eskalointiyhteyshenkilöt, NIS2-ilmoittamisen päätöspuu, pöytäharjoitusten tulokset, poikkeamatiketit, viranomaisilmoitusten luonnokset, todistusaineiston käsittelysäännöt ja opit.

Jatkuvuudesta tulee sisällyttää OT-varmuuskopiointistrategia, offline- tai suojatut varmuuskopiot, palautustestien tulokset, kriittisten varaosien luettelo, manuaaliset käyttömenettelyt, palautusprioriteetit ja kriisiviestintäsuunnitelmat.

Hallinnoinnista tulee sisällyttää hallituksen tai johdon hyväksyntä, roolien määritykset, koulutussuoritustiedot, sisäisen auditoinnin tulokset, KPI-mittarit, riskikatselmointien pöytäkirjat ja johdon katselmoinnin päätökset.

Tämä näyttömalli on yhdenmukainen ISO/IEC 27001:2022 -standardin kanssa, koska se tukee riskien käsittelyä, dokumentoitua tietoa, suorituskyvyn arviointia ja jatkuvaa parantamista. Se on yhdenmukainen NIS2:n kanssa, koska se osoittaa asianmukaiset ja oikeasuhteiset toimenpiteet. Se on yhdenmukainen IEC 62443:n kanssa, koska se voidaan jäljittää OT-arkkitehtuuriin ja teknisiin suunnittelukontrolleihin.

Muunna OT-tietoturvaohjelmasi auditoitavaksi NIS2-valmiudeksi

Jos OT-ympäristösi tukee kriittistä tai säänneltyä palvelua, aukkojen paljastumisen odottaminen viranomaisen, asiakkaan tai poikkeaman kautta on väärä strategia.

Aloita yhdestä suuren vaikutuksen käyttötapauksesta: toimittajan etäkäyttö kriittiseen OT-vyöhykkeeseen, haavoittuvuuksien käsittely tuettomille teollisille omaisuuserille tai segmentointi yritys-IT:n ja OT:n välillä. Rakenna riskiskenaario, kartoita se NIS2 Article 21 -artiklaan, valitse ISO/IEC 27002:2022 -kontrollit, muunna ne IEC 62443 -toteutusmalleiksi ja kerää näyttö.

Clarysec voi auttaa nopeuttamaan tätä työtä Zenith Blueprint -oppaalla, Zenith Controls -oppaalla, IoT-/OT-tietoturvapolitiikalla, Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME -politiikalla ja Third-Party and Supplier Security Policy - SME -politiikalla.

Seuraava toimenpiteesi: valitse yksi OT-palvelu, kartoita sen omaisuuserät ja riippuvuudet ja laadi riskistä kontrolliin ulottuva näyttöketju tällä viikolla. Jos haluat jäsennellyn toteutuspolun, Clarysecin 30-vaiheinen tiekartta ja vaatimustenmukaisuuksien välinen työkalupakki voivat muuntaa ensimmäisen ketjun täydelliseksi NIS2:n OT-tietoturvaohjelmaksi.