NIS2 sigurnost OT-a: mapa ISO 27001 i IEC 62443

U ponedjeljak u 02:17 operater postrojenja za obradu vode prima alarm iz sustava za doziranje. Doziranje kemikalija i dalje je unutar sigurnih granica, ali jedan PLC prijavljuje nepravilne naredbe, inženjerska radna stanica prikazuje neuspjele prijave s VPN korisničkog računa dobavljača, a dežurni SOC analitičar postavlja pitanje na koje nitko ne želi odgovarati pod pritiskom.

Je li to IT incident, OT incident, sigurnosni događaj ili značajan incident koji se prijavljuje prema NIS2?

Postrojenje ima vatrozide. Ima ISO dokumentaciju. Ima tablicu dobavljača. Ima čak i Plan odgovora na incidente. No plan je pisan za kompromitaciju e-pošte i nedostupnost usluga u oblaku, a ne za naslijeđeni kontroler koji se ne može zakrpati tijekom proizvodnje, dobavljača kojem je potreban udaljeni pristup radi obnove usluge i regulatora koji očekuje dokaze unutar NIS2 rokova za prijavu.

Isti se problem pojavljuje i na razini uprave. CISO regionalnog pružatelja energetskih usluga može imati ISO/IEC 27001:2022 certificiran sustav upravljanja informacijskom sigurnošću za korporativni IT, dok okruženje operativne tehnologije ostaje složena mreža PLC-ova, RTU-ova, HMI-ja, procesnih historian sustava, inženjerskih radnih stanica, industrijskih preklopnika i pristupnih putova dobavljača. Pitanje predsjednika uprave jednostavno je: „Jesmo li pokriveni? Možete li to dokazati?”

Za mnoge ključne i važne subjekte iskren je odgovor neugodan. Djelomično su pokriveni. Djelomično to mogu dokazati. No NIS2 sigurnost OT-a zahtijeva više od generičke IT usklađenosti.

Zahtijeva jedinstven operativni model koji povezuje upravljanje prema ISO/IEC 27001:2022, jezik kontrola iz ISO/IEC 27002:2022, industrijske inženjerske prakse IEC 62443, mjere upravljanja kibernetičkim rizicima iz NIS2 Article 21 i dokaze za prijavu incidenata prema NIS2 Article 23.

To je most koji ovaj vodič uspostavlja.

Zašto se NIS2 sigurnost OT-a razlikuje od uobičajene IT usklađenosti

NIS2 se primjenjuje na mnoge javne i privatne subjekte koji pružaju usluge obuhvaćene područjem primjene u EU, uključujući ključne i važne subjekte u sektorima kao što su energetika, promet, bankarstvo, infrastruktura financijskih tržišta, zdravstvo, pitka voda, otpadne vode, digitalna infrastruktura, upravljanje IKT uslugama, javna uprava, svemir, poštanske usluge, gospodarenje otpadom, proizvodnja, kemikalije, hrana, digitalni pružatelji i istraživanje.

Direktiva zahtijeva primjerene i razmjerne tehničke, operativne i organizacijske mjere za upravljanje kibernetičkim rizicima, sprječavanje ili smanjenje utjecaja incidenata i zaštitu kontinuiteta usluga. Article 21 uključuje pristup koji obuhvaća sve opasnosti, uključujući analizu rizika, sigurnosne politike, postupanje s incidentima, kontinuitet poslovanja, upravljanje krizama, sigurnost opskrbnog lanca, sigurnu nabavu i održavanje, postupanje s ranjivostima i njihovu objavu, procjenu učinkovitosti, kibernetičku higijenu, osposobljavanje, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom, MFA ili kontinuiranu autentikaciju, sigurne komunikacije i hitne komunikacije gdje je primjenjivo.

Ti zahtjevi zvuče poznato timu za ISO/IEC 27001:2022. U OT okruženju svaki se od njih ponaša drukčije.

Ranjivost web-poslužitelja često se može zakrpati u roku od nekoliko dana. Ranjivost kontrolera turbine može zahtijevati provjeru dobavljača, termin održavanja, sigurnosni pregled i rezervne operativne postupke. Prijenosno računalo može se ponovno izgraditi. Produkcijski HMI može ovisiti o naslijeđenom operativnom sustavu jer industrijska aplikacija nije certificirana za noviju platformu. Operativne upute SOC-a mogu reći „izoliraj host”, dok OT inženjer odgovara: „ne dok ne znamo utječe li izolacija na kontrolu tlaka.”

Razlika nije samo tehnička. IT obično daje prednost povjerljivosti, cjelovitosti i dostupnosti. OT daje prednost dostupnosti, cjelovitosti procesa i sigurnosti ljudi i postrojenja. Sigurnosna kontrola koja uvodi latenciju, zahtijeva ponovno pokretanje ili prekida fizički proces može biti neprihvatljiva bez inženjerskog odobrenja.

NIS2 ne izuzima OT od upravljanja kibernetičkim rizicima. Očekuje da organizacija dokaže da su kontrole primjerene riziku i razmjerne operativnoj stvarnosti.

Sloj kontrola: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 i IEC 62443

Dokaziv program NIS2 sigurnosti OT-a započinje slojevitim skupom kontrola.

ISO/IEC 27001:2022 osigurava sustav upravljanja. Od organizacije zahtijeva definiranje konteksta, zainteresiranih strana, regulatornih obveza, opsega ISMS-a, sučelja i ovisnosti. Također zahtijeva predanost vodstva, Politiku informacijske sigurnosti, Procjenu rizika, Obradu rizika, Izjavu o primjenjivosti, dokumentirane informacije, internu reviziju, preispitivanje od strane uprave i kontinuirano poboljšanje.

ISO/IEC 27002:2022 osigurava rječnik kontrola. Za OT najvažnije kontrole često uključuju sigurnost dobavljača, upravljanje rizicima IKT opskrbnog lanca, planiranje incidenata, spremnost IKT-a za kontinuitet poslovanja, pravne i ugovorne zahtjeve, upravljanje imovinom, kontrolu pristupa, upravljanje ranjivostima, sigurnosne kopije, bilježenje događaja, nadzor, sigurnost mreže i razdvajanje mreža.

IEC 62443 osigurava model industrijskog sigurnosnog inženjerstva. Pomaže prevesti zahtjeve sustava upravljanja u OT prakse kao što su zone, kanali, sigurnosne razine, odgovornosti vlasnika imovine, odgovornosti integratora sustava, očekivanja prema dobavljačima proizvoda, ograničenja udaljenog pristupa, minimalna funkcionalnost, upravljanje računima, sigurnosno očvršćivanje i kontrole životnog ciklusa.

Clarysec koristi taj sloj kontrola jer sprječava dva česta neuspjeha. Prvo, sprječava da implementacija ISO postane previše generička za OT. Drugo, sprječava da se inženjerski rad prema IEC 62443 odvoji od odgovornosti uprave, obveza prijavljivanja prema NIS2 i revizijskih dokaza.

Clarysecova IoT / OT Security Policy izravno opisuje taj most:

Osigurati da su sve implementacije usklađene s kontrolama ISO/IEC 27001 i primjenjivim sektorskim smjernicama (npr. IEC 62443, ISO 27019, NIST SP 800-82).

Ta je rečenica važna. Politika nije samo kontrolni popis za sigurnosno očvršćivanje uređaja. Ona povezuje ISO upravljanje, OT sektorske smjernice i operativnu sigurnost.

Počnite od opsega: koju OT uslugu treba zaštititi?

Prije mapiranja kontrola definirajte OT uslugu poslovnim i regulatornim jezikom.

Voditelj postrojenja može reći: „Upravljamo linijom za pakiranje.” Procjena prema NIS2 trebala bi reći: „Ovaj proizvodni proces podržava ključnu ili važnu uslugu i ovisi o PLC-ovima, HMI-jima, inženjerskim radnim stanicama, procesnim historian sustavima, industrijskim preklopnicima, udaljenom pristupu dobavljača, ugovornom izvođaču održavanja, analitičkom toku iz oblaka i usluzi korporativnog identiteta.”

Točke 4.1 do 4.4 ISO/IEC 27001:2022 korisne su jer prisiljavaju organizaciju da identificira unutarnja i vanjska pitanja, zainteresirane strane, pravne i ugovorne zahtjeve, granice ISMS-a, sučelja i ovisnosti. Za NIS2 sigurnost OT-a to znači mapiranje ne samo mreže sjedišta nego i industrijskih sustava i ovisnosti usluga koje utječu na kontinuitet, sigurnost i reguliranu isporuku.

NIST CSF 2.0 pojačava istu logiku. Njegova funkcija GOVERN zahtijeva razumijevanje misije, dionika, ovisnosti, pravnih i regulatornih obveza, kritičnih usluga i usluga o kojima organizacija ovisi. Organizacijski profili pružaju praktičnu metodu za određivanje opsega trenutačnog stanja, definiranje ciljnog stanja, analizu praznina i izradu prioritetnog akcijskog plana.

Za OT okruženje Clarysec obično počinje s pet pitanja:

1. Koju reguliranu ili kritičnu uslugu podržava ovo OT okruženje?
2. Koja OT imovina, mreže, tokovi podataka i treće strane potrebni su za tu uslugu?
3. Koja sigurnosna, dostupnosna i operativna ograničenja utječu na sigurnosne kontrole?
4. Koje se pravne, ugovorne i sektorske obveze primjenjuju, uključujući NIS2, GDPR, DORA gdje je relevantno, ugovore s klijentima i nacionalna pravila?
5. Koji su dijelovi okruženja unutar ISMS-a, a koji su vanjske ovisnosti koje zahtijevaju kontrole dobavljača?

Mnogi NIS2 programi ovdje ne uspijevaju. Opseg određuju oko korporativnog IT-a jer ga je lakše popisati. Revizori i regulatori neće biti impresionirani ako se najkritičnija ovisnost usluge pojavljuje samo kao nejasna stavka pod nazivom „tvornička mreža”.

Praktična mapa NIS2 OT kontrola

Tablica u nastavku prikazuje kako teme iz NIS2 Article 21 pretvoriti u dokaze prema ISO/IEC 27001:2022, ISO/IEC 27002:2022 i IEC 62443. Ona nije zamjena za formalnu Procjenu rizika, ali CISO-ima, OT rukovoditeljima i timovima za usklađenost daje praktičnu početnu točku.

Ova je mapa namjerno usmjerena na dokaze. Prema NIS2 nije dovoljno reći „imamo segmentaciju”. Treba pokazati zašto je segmentacija primjerena, kako je implementirana, kako se odobravaju iznimke i kako dizajn smanjuje utjecaj na reguliranu uslugu.

Segmentacija: prva OT kontrola koju će revizori testirati

Ako je incident u 02:17 uključivao napadača koji se kretao s uredskog prijenosnog računala prema inženjerskoj radnoj stanici, prvo revizijsko pitanje bilo bi očito: zašto je taj put mogao postojati?

IoT / OT Security Policy je izričita:

OT sustavi moraju raditi unutar namjenskih mreža izoliranih od korporativnog IT-a i sustava izloženih internetu.

Za manja okruženja, Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME daje praktičnu polaznu osnovu:

Svi uređaji Interneta stvari (IoT) i operativne tehnologije (OT) moraju biti smješteni na zasebnu Wi-Fi ili VLAN mrežu

Za zrelog operatora kritične infrastrukture segmentaciju treba dizajnirati oko OT zona i kanala. Korporativni korisnici ne bi trebali imati izravan pristup PLC mrežama. Veze dobavljača trebale bi završavati u kontroliranim pristupnim zonama. Replikacija procesnog historiana trebala bi koristiti odobrene putove. Sigurnosni sustavi trebaju biti izolirani prema riziku i inženjerskim zahtjevima. Bežične OT mreže trebaju biti opravdane, sigurnosno očvrsnute i nadzirane.

Zenith Blueprint: revizorski plan u 30 koraka, u fazi Kontrole u praksi, korak 20, objašnjava načelo iza mrežne sigurnosti prema ISO/IEC 27002:2022:

Industrijski upravljački sustavi trebaju biti izolirani od uredskog prometa.

Također upozorava da mrežna sigurnost zahtijeva sigurnu arhitekturu, segmentaciju, kontrolu pristupa, šifriranje podataka u prijenosu, nadzor i višeslojnu obranu.

U Zenith Controls: vodič za međusobnu usklađenost, kontrola ISO/IEC 27002:2022 8.22, Razdvajanje mreža, tretira se kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost, usklađena s konceptom kibernetičke sigurnosti Protect, uz sigurnost sustava i mreže kao operativnu sposobnost te Protection kao sigurnosnu domenu.

Ta je klasifikacija korisna za NIS2 dokaze jer segmentacija nije dekorativni dijagram. Ona je preventivna kontrola namijenjena smanjenju dosega incidenta i očuvanju kontinuiteta ključne usluge.

Upravljanje ranjivostima kada se OT sustavi ne mogu jednostavno zakrpati

NIS2 zahtijeva sigurnu nabavu, razvoj i održavanje mrežnih i informacijskih sustava, uključujući postupanje s ranjivostima i njihovu objavu. U IT-u upravljanje ranjivostima često znači skenirati, prioritizirati, zakrpati i provjeriti. OT dodaje ograničenja.

Kritični HMI možda se može zakrpati samo tijekom planiranog zastoja. Ažuriranje firmvera PLC-a može zahtijevati sudjelovanje dobavljača. Sigurnosno certificirani sustav može izgubiti certifikaciju ako se nepravilno izmijeni. Neki naslijeđeni uređaji možda uopće nemaju podršku dobavljača.

Zenith Blueprint, faza Kontrole u praksi, korak 19, daje ispravnu revizijsku logiku za tehničke ranjivosti:

Za sustave koji se ne mogu odmah zakrpati, možda zbog naslijeđenog softvera ili ograničenja zastoja, implementirajte kompenzacijske kontrole. To može uključivati izoliranje sustava iza vatrozida, ograničavanje pristupa ili pojačano praćenje. U svim slučajevima zabilježite i formalno prihvatite preostali rizik, čime se pokazuje da problem nije zaboravljen.

Polazna osnova SME politike jednako je praktična:

Popis imovine mora se pregledavati tromjesečno radi identifikacije zastarjelih, nepodržanih ili nezakrpanih uređaja

U Zenith Controls, kontrola ISO/IEC 27002:2022 8.8, Upravljanje tehničkim ranjivostima, mapirana je kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost, usklađena s konceptima Identify i Protect, uz upravljanje prijetnjama i ranjivostima kao operativnu sposobnost kroz domene Governance, Ecosystem, Protection i Defense.

Kvalitetan OT dosje ranjivosti treba uključivati:

• identifikator imovine, vlasnika, zonu i kritičnost
• izvor ranjivosti, kao što su sigurnosna obavijest dobavljača, skener, obavijest integratora ili obavještajni podaci o prijetnjama
• sigurnosna ograničenja i ograničenja dostupnosti
• izvedivost zakrpe i planirani termin održavanja
• kompenzacijske kontrole, kao što su izolacija, liste kontrole pristupa, onemogućene usluge ili pojačani nadzor
• odobrenje vlasnika rizika i prihvaćanje preostalog rizika
• dokaze o provjeri nakon otklanjanja ili implementacije kompenzacijske kontrole

Time se tvrdnja „ne možemo zakrpati” pretvara iz izgovora u revizijski provjerljivu obradu rizika.

Udaljeni pristup dobavljača: kritična točka NIS2 i IEC 62443

Većina OT incidenata negdje ima dimenziju treće strane. Korisnički račun dobavljača. Prijenosno računalo integratora. Alat za udaljeno održavanje. Zajedničke vjerodajnice. Iznimka vatrozida koja je trebala biti privremena prije tri godine.

NIS2 Article 21 izričito uključuje sigurnost opskrbnog lanca, ranjivosti specifične za dobavljače, prakse kibernetičke sigurnosti dobavljača i postupke sigurnog razvoja. NIST CSF 2.0 također je detaljan u tom pogledu kroz kritičnost dobavljača, ugovorne zahtjeve, dubinsku analizu dobavljača, kontinuirani nadzor, koordinaciju incidenata i odredbe o izlasku.

Clarysecova Third-Party and Supplier Security Policy - SME načelo navodi jednostavnim jezikom:

Dobavljačima se smije dodijeliti pristup samo minimalnim sustavima i podacima potrebnima za obavljanje njihove funkcije.

Za OT minimalni pristup znači više od pristupa temeljenog na ulogama u aplikaciji. Pristup dobavljača treba biti:

• prethodno odobren za definiranu svrhu održavanja
• vremenski ograničen i prema zadanim postavkama onemogućen
• zaštićen MFA-om ili kontinuiranom autentikacijom gdje je primjenjivo
• usmjeren kroz siguran posrednički poslužitelj ili kontroliranu platformu za udaljeni pristup
• ograničen na relevantnu OT zonu ili imovinu
• zabilježen, nadziran i, za visokorizični pristup, snimljen na razini sesije
• pregledan nakon dovršetka
• obuhvaćen ugovornim sigurnosnim obvezama i obvezama prijave incidenta

Korporativna IoT / OT Security Policy uključuje poseban zahtjev za udaljeni pristup:

Udaljeni pristup (za upravljanje ili servisiranje od strane dobavljača) mora:

Ta točka uspostavlja uporište upravljanja, dok detaljne zahtjeve treba implementirati u postupcima pristupa, ugovorima s dobavljačima, tehničkoj konfiguraciji i radnim tokovima nadzora.

U Zenith Controls, kontrola ISO/IEC 27002:2022 5.21, Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, klasificirana je kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost, usklađena s konceptom Identify, uz sigurnost odnosa s dobavljačima kao operativnu sposobnost i Governance, Ecosystem i Protection kao domene.

Za OT to mapiranje pomaže objasniti zašto dokazi o udaljenom pristupu istodobno pripadaju u dosjee rizika dobavljača, upravljanja identitetom, mrežne sigurnosti, odgovora na incidente i kontinuiteta poslovanja.

Odgovor na incidente: NIS2 rokovi susreću kontrolnu sobu

Vratimo se alarmu u 02:17. Organizacija mora odlučiti je li događaj značajan prema NIS2. Article 23 zahtijeva obavješćivanje bez nepotrebnog odgađanja o značajnim incidentima koji utječu na pružanje usluge. Slijed uključuje rano upozorenje u roku od 24 sata od saznanja, obavijest o incidentu u roku od 72 sata, međuažuriranja ako se zatraže i završno izvješće najkasnije mjesec dana nakon obavijesti o incidentu, odnosno izvješće o napretku ako je incident još u tijeku.

U OT-u odgovor na incidente mora odgovoriti na pitanja koja IT operativne upute često zanemaruju:

• Može li se zahvaćeni uređaj izolirati bez stvaranja sigurnosnog rizika?
• Tko ima ovlast zaustaviti proizvodnju ili prebaciti sustav u ručni način rada?
• Koji su zapisi hlapljivi i trebaju trenutačno očuvanje?
• Kojeg dobavljača ili integratora treba kontaktirati?
• Je li događaj zlonamjeran, slučajan, okolišni ili uzrokovan pogrešnom konfiguracijom?
• Može li postojati prekogranični utjecaj ili utjecaj na primatelje usluge?
• Jesu li uključeni osobni podaci, kao što su zapisi pristupnih iskaznica, CCTV, podaci o zaposlenicima ili evidencije korisničke službe?

SME OT politika daje jednostavno pravilo eskalacije anomalija:

Sve anomalije moraju se odmah prijaviti glavnom direktoru radi daljnjeg postupanja

Također uključuje načelo sigurnog ograničavanja:

Uređaj se mora odmah odspojiti s mreže, ako je to sigurno učiniti

Posljednjih pet riječi ključno je. OT odgovor ne može slijepo kopirati IT mjere ograničavanja. „Ako je to sigurno učiniti” treba biti odraženo u operativnim uputama za oporavak, matricama eskalacije, obuci i stolnim vježbama.

NIST CSF 2.0 ovdje se dobro mapira. Njegovi ishodi Respond i Recover obuhvaćaju trijažu, kategorizaciju, eskalaciju, analizu temeljnog uzroka, cjelovitost dokaza, obavješćivanje dionika, ograničavanje, uklanjanje prijetnje, vraćanje podataka, provjere cjelovitosti sigurnosnih kopija i komunikacije tijekom oporavka.

Izgradite liniju dokaza od rizika do kontrole

Praktičan način za izbjegavanje fragmentirane usklađenosti jest izgraditi jednu liniju dokaza od rizika preko propisa i kontrole do dokaza.

Scenarij: dobavljaču udaljenog kompresora potreban je pristup inženjerskoj radnoj stanici u OT mreži. Radna stanica može mijenjati PLC logiku. Korisnički račun dobavljača uvijek je omogućen, dijeli ga više inženjera dobavljača i zaštićen je samo lozinkom. Na radnoj stanici radi softver koji se ne može nadograditi do sljedećeg zastoja radi održavanja.

Zapišite scenarij rizika u registar rizika:

„Neovlašteni ili kompromitirani udaljeni pristup dobavljača OT inženjerskoj radnoj stanici mogao bi dovesti do neovlaštenih promjena PLC logike, prekida proizvodnje, sigurnosnog utjecaja i prekida usluge koji se prijavljuje prema NIS2.”

Zatim mapirajte kontrole i obveze.

Plan obrade treba onemogućiti stalni pristup dobavljača, zahtijevati imenovane identitete dobavljača, provoditi MFA, usmjeravati pristup kroz kontrolirani posrednički poslužitelj, ograničiti pristup na inženjersku radnu stanicu, zahtijevati odobrenje zahtjeva za održavanje, snimati privilegirane sesije, nadzirati naredbe i neuobičajen promet, dokumentirati nezakrpanu radnu stanicu kao iznimku ranjivosti i testirati odgovor na incidente za sumnjivu aktivnost dobavljača.

Zenith Blueprint, faza Upravljanje rizicima, korak 13, daje logiku sljedivosti SoA:

Upućivanje na propise: ako se određene kontrole implementiraju posebno radi usklađivanja s GDPR, NIS2 ili DORA, to možete zabilježiti u registru rizika (kao dio obrazloženja utjecaja rizika) ili u napomenama SoA.

Praktična je pouka jednostavna. Ne držite dokaze za NIS2, ISO i OT inženjerstvo u odvojenim silosima. Dodajte stupce u registar rizika i SoA za temu NIS2 Article 21, kontrolu ISO/IEC 27002:2022, obitelj zahtjeva IEC 62443, vlasnika dokaza i status revizije.

Gdje se GDPR i DORA uklapaju u OT sigurnost

OT sigurnost nije uvijek samo pitanje strojeva. Okruženja kritične infrastrukture često obrađuju osobne podatke putem CCTV-a, sustava kontrole pristupa, zapisa pristupnih iskaznica, sustava sigurnosti radnika, prijava održavanja, praćenja vozila, sustava za posjetitelje i platformi korisničke službe.

GDPR zahtijeva da se osobni podaci obrađuju zakonito, pošteno i transparentno, prikupljaju za određene svrhe, ograniče na ono što je nužno, održavaju točnima, zadržavaju samo onoliko dugo koliko je potrebno i štite primjerenim tehničkim i organizacijskim mjerama. Također zahtijeva odgovornost, što znači da voditelj obrade mora moći dokazati usklađenost.

Za OT to znači da zapisi pristupa i zapisi nadzora ne smiju postati nekontrolirana spremišta podataka nadzora. Rokovi zadržavanja, prava pristupa, ograničenje svrhe i procjena povrede moraju biti ugrađeni u bilježenje događaja i nadzor.

DORA se može primjenjivati kada su uključeni financijski subjekti ili kada IKT pružatelj usluga treće strane podržava operativnu otpornost financijskog sektora. DORA obuhvaća upravljanje IKT rizicima, prijavljivanje incidenata, testiranje otpornosti i IKT rizik trećih strana. Za financijske subjekte koji su ujedno ključni ili važni subjekti prema pravilima prijenosa NIS2, DORA može djelovati kao sektorski specifičan režim za preklapajuće obveze, dok koordinacija s NIS2 tijelima može ostati relevantna.

Primjenjuju se iste discipline dokaza: identifikacija imovine, zaštita, detekcija, kontinuitet, sigurnosne kopije, rizik trećih strana, testiranje, osposobljavanje i nadzor uprave.

Revizijska perspektiva: jedna kontrola, više perspektiva osiguranja

Snažna implementacija NIS2 sigurnosti OT-a treba izdržati više revizijskih perspektiva.

Zbog toga Clarysec tretira Zenith Controls kao kompas međusobne usklađenosti. Njegovi atributi kontrola pomažu objasniti svrhu službenih kontrola ISO/IEC 27002:2022, dok pristup mapiranju povezuje te kontrole s NIS2, NIST CSF, upravljanjem dobavljačima, kontinuitetom i revizijskim dokazima.

Česte pogreške u implementaciji NIS2 OT

Najčešći neuspjesi OT sigurnosti rijetko su uzrokovani nedostatkom dokumenata. Uzrokuju ih dokumenti koji ne odgovaraju postrojenju.

Pogreška 1: IT posjeduje NIS2 program, ali OT posjeduje rizik. Operacije, inženjering, sigurnost i održavanje moraju biti uključeni.

Pogreška 2: Popis imovine završava na poslužiteljima. OT popis mora uključivati PLC-ove, RTU-ove, HMI-je, procesne historian sustave, inženjerske radne stanice, industrijske preklopnike, senzore, pristupnike, uređaje za udaljeni pristup i komponente kojima upravljaju dobavljači.

Pogreška 3: Segmentacija postoji na dijagramu, ali ne u pravilima vatrozida. Revizori će tražiti dokaze o provedbi, kontroli promjena i nadzoru.

Pogreška 4: Iznimke ranjivosti su neformalne. Naslijeđena ograničenja prihvatljiva su samo kada su dokumentirana, odobrena, nadzirana i ponovno pregledavana.

Pogreška 5: Pristup dobavljača tretira se samo kao pitanje dobavljača. To je ujedno pitanje kontrole pristupa, bilježenja događaja, nadzora, mrežne sigurnosti, odgovora na incidente i kontinuiteta.

Pogreška 6: Odgovor na incidente zanemaruje sigurnost. OT operativne upute moraju definirati tko smije izolirati uređaje, zaustaviti procese, promijeniti način rada ili kontaktirati regulatore.

Pogreška 7: NIS2 prijavljivanje nije uvježbano. Proces odlučivanja za rokove od 24 sata i 72 sata treba testirati prije stvarnog događaja.

Clarysecov put implementacije od odgovornosti uprave do OT dokaza

Praktična implementacija NIS2 sigurnosti OT-a može slijediti ovaj redoslijed:

1. Potvrditi opseg NIS2, klasifikaciju subjekta i kritičnost usluge.
2. Definirati OT opseg unutar ISMS-a, uključujući sučelja i ovisnosti.
3. Izraditi OT popis imovine i tokova podataka.
4. Identificirati pravne, ugovorne, sigurnosne, privatnosne i sektorske obveze.
5. Provesti OT-specifične radionice Procjene rizika s inženjeringom, operacijama, IT-om, SOC-om, nabavom i upravom.
6. Mapirati obradu rizika na kontrole ISO/IEC 27002:2022, teme NIS2 i obrasce implementacije IEC 62443.
7. Ažurirati Izjavu o primjenjivosti s OT obrazloženjem i vlasnicima dokaza.
8. Implementirati prioritetne kontrole: segmentaciju, pristup dobavljača, postupanje s ranjivostima, nadzor, sigurnosne kopije i odgovor na incidente.
9. Ažurirati politike i postupke, uključujući OT sigurnost, sigurnost dobavljača, udaljeni pristup, odgovor na incidente i kontinuitet poslovanja.
10. Provesti stolne vježbe i tehničke provjere.
11. Pripremiti revizijske pakete za NIS2, ISO/IEC 27001:2022, programe dokazivanja sigurnosti prema zahtjevima klijenata i interno upravljanje.
12. Uključiti nalaze u preispitivanje od strane uprave i kontinuirano poboljšanje.

To odražava operativni model u Zenith Blueprint, osobito korak 13 za obradu rizika i sljedivost SoA, korak 14 za razvoj politika i regulatorna unakrsna upućivanja, korak 19 za upravljanje ranjivostima i korak 20 za mrežnu sigurnost.

Isti pristup koristi Clarysec politike za pretvaranje jezika okvira u operativna pravila. Korporativna IoT / OT Security Policy zahtijeva pregled sigurnosne arhitekture prije implementacije:

Svi novi IoT/OT uređaji moraju proći pregled sigurnosne arhitekture prije implementacije. Taj pregled mora potvrditi:

Također navodi:

Sav promet unutar i između IoT/OT mreža mora se kontinuirano pratiti korištenjem:

Te točke stvaraju uporišta upravljanja. Dokazi implementacije mogu uključivati OT IDS upozorenja, zapise vatrozida, SIEM korelaciju, profile polaznog mrežnog prometa, prijave anomalija i zapise odgovora.

Kako izgledaju dobri NIS2 OT dokazi

Paket dokaza za NIS2 OT treba biti dovoljno praktičan za inženjere i dovoljno strukturiran za revizore.

Za segmentaciju uključite odobrenu arhitekturu, dijagrame zona i kanala, izvoze pravila vatrozida, zapise promjena, periodične preglede pravila, zapise iznimaka i upozorenja nadzora.

Za pristup dobavljača uključite procjenu kritičnosti dobavljača, ugovorne odredbe, odobreni postupak pristupa, imenovane korisničke račune, MFA dokaze, zapise pristupa, snimke sesija, periodični pregled pristupa i zapise izlaznog procesa.

Za upravljanje ranjivostima uključite popis imovine, izvore obavijesti, rezultate pasivnog otkrivanja, prijave ranjivosti, planove zakrpa, kompenzacijske kontrole, prihvaćanje rizika i dokaze zatvaranja.

Za odgovor na incidente uključite operativne upute, kontakte za eskalaciju, stablo odluka za prijavljivanje prema NIS2, rezultate stolnih vježbi, prijave incidenta, nacrte obavijesti nadležnom tijelu, pravila postupanja s dokazima i naučene lekcije.

Za kontinuitet uključite OT strategiju sigurnosnog kopiranja, izvanmrežne ili zaštićene sigurnosne kopije, rezultate testiranja vraćanja, popis kritičnih rezervnih dijelova, ručne operativne postupke, prioritete oporavka i planove krizne komunikacije.

Za upravljanje uključite odobrenje uprave ili odbora, dodjele uloga, zapise o osposobljavanju, rezultate interne revizije, KPI-jeve, zapisnike pregleda rizika i odluke preispitivanja od strane uprave.

Ovaj model dokaza usklađen je s ISO/IEC 27001:2022 jer podržava obradu rizika, dokumentirane informacije, vrednovanje uspješnosti i kontinuirano poboljšanje. Usklađen je s NIS2 jer dokazuje primjerene i razmjerne mjere. Usklađen je s IEC 62443 jer se može povezati s OT arhitekturom i inženjerskim kontrolama.

Pretvorite svoj OT sigurnosni program u dokazivu NIS2 spremnost

Ako vaše OT okruženje podržava kritičnu ili reguliranu uslugu, čekanje da regulator, klijent ili incident otkrije praznine pogrešna je strategija.

Počnite s jednim slučajem uporabe visokog utjecaja: udaljeni pristup dobavljača kritičnoj OT zoni, postupanje s ranjivostima za nepodržanu industrijsku imovinu ili segmentacija između korporativnog IT-a i OT-a. Izradite scenarij rizika, mapirajte ga na NIS2 Article 21, odaberite kontrole ISO/IEC 27002:2022, prevedite ih u obrasce implementacije IEC 62443 i prikupite dokaze.

Clarysec vam može pomoći ubrzati taj rad uz Zenith Blueprint, Zenith Controls, IoT / OT Security Policy, Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME i Third-Party and Supplier Security Policy - SME.

Vaša sljedeća radnja: odaberite jednu OT uslugu, mapirajte njezinu imovinu i ovisnosti te ovaj tjedan izradite liniju dokaza od rizika do kontrole. Ako želite strukturiran put implementacije, Clarysecov plan u 30 koraka i alat za međusobnu usklađenost mogu tu prvu liniju pretvoriti u cjelovit program NIS2 sigurnosti OT-a.