Bezpečnosť OT podľa NIS2: mapovanie ISO 27001 a IEC 62443

V pondelok o 02:17 dostane operátor úpravne vody alarm z dávkovacieho systému. Dávkovanie chemikálií je stále v bezpečných medziach, ale jeden PLC hlási nepravidelné príkazy, inžinierska pracovná stanica zobrazuje neúspešné prihlásenia z VPN účtu dodávateľa a službukonajúci analytik SOC kladie otázku, na ktorú nikto nechce odpovedať pod tlakom.

Ide o IT incident, OT incident, bezpečnostnú udalosť alebo významný incident podliehajúci hláseniu podľa NIS2?

Závod má firewally. Má dokumentáciu podľa ISO. Má tabuľkový prehľad dodávateľov. Má dokonca plán reakcie na incidenty. Tento plán však bol napísaný pre kompromitáciu e-mailu a výpadky cloudových služieb, nie pre zastaraný riadiaci systém, ktorý nemožno záplatovať počas výroby, dodávateľa, ktorý potrebuje vzdialený prístup na obnovu služby, a regulátora, ktorý očakáva dôkazy v lehote hlásenia podľa NIS2.

Rovnaký problém sa objavuje aj v zasadacích miestnostiach. CISO u regionálneho poskytovateľa energie môže mať systém manažérstva informačnej bezpečnosti certifikovaný podľa ISO/IEC 27001:2022 pre podnikové IT, zatiaľ čo prostredie prevádzkových technológií zostáva neprehľadnou spleťou PLC, RTU, HMI, historizačných systémov, inžinierskych pracovných staníc, priemyselných prepínačov a prístupových trás dodávateľov. Otázka CEO je jednoduchá: „Máme to pokryté? Vieme to preukázať?“

Pre mnohé základné a dôležité subjekty je úprimná odpoveď nepríjemná. Majú to pokryté len čiastočne. Dokážu to preukázať len čiastočne. Bezpečnosť OT podľa NIS2 však vyžaduje viac než všeobecný IT súlad.

Vyžaduje jednotný prevádzkový model, ktorý prepája správu a riadenie podľa ISO/IEC 27001:2022, jazyk bezpečnostných opatrení ISO/IEC 27002:2022, priemyselné inžinierske postupy IEC 62443, opatrenia riadenia kybernetických rizík podľa NIS2 Article 21 a dôkazy pre hlásenie incidentov podľa NIS2 Article 23.

Práve tento most vytvára tento sprievodca.

Prečo sa bezpečnosť OT podľa NIS2 líši od bežného IT súladu

NIS2 sa vzťahuje na mnohé verejné a súkromné subjekty poskytujúce služby v rozsahu pôsobnosti v EÚ vrátane základných a dôležitých subjektov v sektoroch, ako sú energetika, doprava, bankovníctvo, infraštruktúra finančných trhov, zdravotníctvo, pitná voda, odpadová voda, digitálna infraštruktúra, riadenie služieb IKT, verejná správa, vesmír, poštové služby, odpadové hospodárstvo, výroba, chemický priemysel, potraviny, digitálni poskytovatelia a výskum.

Smernica vyžaduje primerané a úmerné technické, prevádzkové a organizačné opatrenia na riadenie kybernetických rizík, prevenciu alebo minimalizáciu dopadu incidentov a ochranu kontinuity služieb. Article 21 zahŕňa prístup zohľadňujúci všetky hrozby a pokrýva analýzu rizík, bezpečnostné politiky, riešenie incidentov, kontinuitu činností, krízové riadenie, bezpečnosť dodávateľského reťazca, bezpečné obstarávanie a údržbu, riešenie a zverejňovanie zraniteľností, posudzovanie účinnosti, kybernetickú hygienu, školenia, kryptografiu, personálnu bezpečnosť, riadenie prístupu, správu aktív, MFA alebo priebežnú autentifikáciu, bezpečnú komunikáciu a podľa potreby núdzovú komunikáciu.

Tímom ISO/IEC 27001:2022 znejú tieto požiadavky povedome. V OT sa však každá z nich správa odlišne.

Zraniteľnosť vo webovom serveri možno často záplatovať v priebehu dní. Zraniteľnosť v riadiacom systéme turbíny môže vyžadovať validáciu dodávateľom, údržbové okno, bezpečnostné preskúmanie a náhradné prevádzkové postupy. Notebook možno prestavať. Produkčné HMI môže závisieť od zastaraného operačného systému, pretože priemyselná aplikácia nebola certifikovaná pre novšiu platformu. Playbook SOC môže uvádzať „izolovať hostiteľa“, zatiaľ čo OT inžinier odpovie: „nie, kým nevieme, či izolácia ovplyvní riadenie tlaku.“

Rozdiel nie je iba technický. IT spravidla uprednostňuje dôvernosť, integritu a dostupnosť. OT uprednostňuje dostupnosť, integritu procesu a bezpečnosť. Bezpečnostné opatrenie, ktoré zavádza latenciu, vyžaduje reštart alebo prerušuje fyzický proces, môže byť bez inžinierskeho schválenia neprijateľné.

NIS2 nevyňíma OT z riadenia kybernetických rizík. Očakáva, že organizácia preukáže, že opatrenia sú primerané riziku a úmerné prevádzkovej realite.

Súbor opatrení: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 a IEC 62443

Obhájiteľný program bezpečnosti OT podľa NIS2 začína viacvrstvovým súborom opatrení.

ISO/IEC 27001:2022 poskytuje systém manažérstva. Vyžaduje, aby organizácia definovala kontext, zainteresované strany, regulačné povinnosti, rozsah ISMS, rozhrania a závislosti. Vyžaduje aj vlastníctvo zo strany vedenia, Politiku informačnej bezpečnosti, posúdenie rizík, ošetrenie rizík, Vyhlásenie o uplatniteľnosti, zdokumentované informácie, interný audit, preskúmanie manažmentom a neustále zlepšovanie.

ISO/IEC 27002:2022 poskytuje slovník bezpečnostných opatrení. Pre OT medzi najdôležitejšie opatrenia často patria bezpečnosť dodávateľov, riadenie rizík dodávateľského reťazca IKT, plánovanie incidentov, pripravenosť kontinuity činností, právne a zmluvné požiadavky, správa aktív, riadenie prístupu, riadenie zraniteľností, zálohy, logovanie, monitorovanie, bezpečnosť sietí a oddelenie sietí.

IEC 62443 poskytuje model priemyselného bezpečnostného inžinierstva. Pomáha previesť požiadavky systému manažérstva do postupov OT, ako sú zóny, komunikačné kanály, úrovne bezpečnosti, zodpovednosti vlastníka aktíva, zodpovednosti systémového integrátora, očakávania voči dodávateľovi produktu, obmedzenia vzdialeného prístupu, zásada minimálnej funkčnosti, správa účtov, hardening a opatrenia životného cyklu.

Clarysec používa tento súbor preto, že predchádza dvom častým zlyhaniam. Po prvé, zabraňuje tomu, aby sa implementácia ISO stala pre OT príliš všeobecnou. Po druhé, zabraňuje tomu, aby sa inžinierska práca podľa IEC 62443 odpojila od zodpovednosti predstavenstva, povinností hlásenia podľa NIS2 a auditných dôkazov.

Clarysec Politika bezpečnosti IoT / OT definuje tento most priamo:

Zabezpečiť, aby všetky nasadenia boli zosúladené s opatreniami ISO/IEC 27001 a uplatniteľnými odvetvovo špecifickými usmerneniami (napr. IEC 62443, ISO 27019, NIST SP 800-82).

Táto veta je dôležitá. Politika nie je iba kontrolným zoznamom hardeningu zariadení. Prepája správu a riadenie podľa ISO, odvetvové usmernenia pre OT a prevádzkovú bezpečnosť.

Začnite rozsahom: akú OT službu treba chrániť?

Pred mapovaním opatrení definujte OT službu v obchodnom a regulačnom jazyku.

Manažér závodu môže povedať: „Prevádzkujeme baliacu linku.“ Posúdenie podľa NIS2 by malo uviesť: „Tento výrobný proces podporuje základnú alebo dôležitú službu a závisí od PLC, HMI, inžinierskych pracovných staníc, historizačných systémov, priemyselných prepínačov, vzdialeného prístupu dodávateľov, zmluvného dodávateľa údržby, cloudového analytického toku a podnikovej služby identít.“

Kapitoly ISO/IEC 27001:2022 4.1 až 4.4 sú užitočné, pretože nútia organizáciu identifikovať interné a externé otázky, zainteresované strany, zákonné a zmluvné požiadavky, hranice ISMS, rozhrania a závislosti. Pre bezpečnosť OT podľa NIS2 to znamená mapovať nielen sieť centrály, ale aj priemyselné systémy a závislosti služieb, ktoré ovplyvňujú kontinuitu, bezpečnosť a regulované poskytovanie.

NIST CSF 2.0 posilňuje rovnakú logiku. Jeho funkcia GOVERN vyžaduje porozumenie poslaniu, zainteresovaným stranám, závislostiam, právnym a regulačným povinnostiam, kritickým službám a službám, od ktorých organizácia závisí. Organizačné profily poskytujú praktickú metódu na vymedzenie aktuálneho stavu, definovanie cieľového stavu, analýzu medzier a vytvorenie prioritizovaného akčného plánu.

Pre prostredie OT Clarysec zvyčajne začína piatimi otázkami:

1. Ktorú regulovanú alebo kritickú službu toto prostredie OT podporuje?
2. Ktoré OT aktíva, siete, dátové toky a tretie strany sú pre túto službu potrebné?
3. Ktoré bezpečnostné, dostupnostné a prevádzkové obmedzenia ovplyvňujú bezpečnostné opatrenia?
4. Ktoré zákonné, zmluvné a odvetvové povinnosti sa uplatňujú vrátane NIS2, GDPR, DORA tam, kde je to relevantné, zákazníckych zmlúv a vnútroštátnych pravidiel?
5. Ktoré časti prostredia sú v rozsahu ISMS a ktoré sú externými závislosťami vyžadujúcimi dodávateľské opatrenia?

Mnohé programy NIS2 zlyhávajú práve tu. Rozsah vymedzia okolo podnikového IT, pretože sa jednoduchšie inventarizuje. Audítorov a regulátorov nepresvedčí, ak sa najkritickejšia závislosť služby objaví iba ako neurčitá položka „sieť fabriky“.

Praktická mapa opatrení OT podľa NIS2

Nasledujúca tabuľka ukazuje, ako premeniť témy NIS2 Article 21 na dôkazy podľa ISO/IEC 27001:2022, ISO/IEC 27002:2022 a IEC 62443. Nie je náhradou formálneho posúdenia rizík, ale poskytuje CISO, manažérom OT a tímom súladu praktický východiskový bod.

Táto mapa je zámerne orientovaná na dôkazy. Pri NIS2 nestačí povedať „máme segmentáciu“. Musíte preukázať, prečo je segmentácia primeraná, ako je implementovaná, ako sa schvaľujú výnimky a ako návrh znižuje dopad na regulovanú službu.

Segmentácia: prvé opatrenie OT, ktoré audítori preveria

Ak by incident o 02:17 zahŕňal pohyb útočníka z kancelárskeho notebooku na inžiniersku pracovnú stanicu, prvá auditná otázka by bola zrejmá: prečo mohla takáto trasa existovať?

Politika bezpečnosti IoT / OT je explicitná:

OT systémy musia fungovať v samostatných sieťach izolovaných od podnikového IT a systémov dostupných z internetu.

Pre menšie prostredia poskytuje Politika bezpečnosti internetu vecí (IoT) / prevádzkových technológií (OT) - SME praktickú základnú úroveň:

Všetky zariadenia Internet of Things (IoT) a Operational Technology (OT) musia byť umiestnené v samostatnej Wi‑Fi alebo VLAN sieti

Pre vyspelého prevádzkovateľa kritickej infraštruktúry by segmentácia mala byť navrhnutá okolo OT zón a komunikačných kanálov. Podnikoví používatelia by nemali priamo pristupovať k PLC sieťam. Pripojenia dodávateľov by mali končiť v riadených prístupových zónach. Replikácia historizačných systémov by mala používať schválené trasy. Bezpečnostné systémy by mali byť izolované podľa rizika a inžinierskych požiadaviek. Bezdrôtové OT siete by mali byť odôvodnené, hardenované a monitorované.

Zenith Blueprint: 30-kroková cestovná mapa audítora, vo fáze Opatrenia v praxi, krok 20, vysvetľuje princíp bezpečnosti sietí podľa ISO/IEC 27002:2022:

Priemyselné riadiace systémy by mali byť izolované od kancelárskej prevádzky.

Zároveň upozorňuje, že bezpečnosť sietí vyžaduje bezpečnú architektúru, segmentáciu, riadenie prístupu, šifrovanie pri prenose, monitorovanie a obranu do hĺbky.

V Zenith Controls: Sprievodca krížovým súladom sa opatrenie ISO/IEC 27002:2022 8.22, oddelenie sietí, považuje za preventívne opatrenie podporujúce dôvernosť, integritu a dostupnosť, zosúladené s konceptom kybernetickej bezpečnosti Protect, pričom systémová a sieťová bezpečnosť je jeho prevádzkovou schopnosťou a ochrana jeho bezpečnostnou doménou.

Táto klasifikácia je užitočná pre dôkazy NIS2, pretože segmentácia nie je dekoratívny diagram. Je to preventívne opatrenie navrhnuté na zníženie rozsahu dopadu a zachovanie kontinuity základnej služby.

Riadenie zraniteľností, keď OT systémy nemožno jednoducho záplatovať

NIS2 vyžaduje bezpečné obstarávanie, vývoj a údržbu sieťových a informačných systémov vrátane riešenia a zverejňovania zraniteľností. V IT riadenie zraniteľností často znamená skenovať, prioritizovať, záplatovať a overiť. OT pridáva obmedzenia.

Kritické HMI môže byť záplatovateľné iba počas plánovanej odstávky. Aktualizácia firmvéru PLC môže vyžadovať zapojenie dodávateľa. Bezpečnostne certifikovaný systém môže pri nesprávnej úprave stratiť certifikáciu. Niektoré zastarané zariadenia už nemusia mať podporu dodávateľa vôbec.

Zenith Blueprint, fáza Opatrenia v praxi, krok 19, poskytuje správnu auditnú logiku pre technické zraniteľnosti:

Pri systémoch, ktoré nemožno záplatovať okamžite, napríklad z dôvodu zastaraného softvéru alebo obmedzení výpadku, implementujte kompenzačné opatrenia. Môže ísť o izolovanie systému za firewallom, obmedzenie prístupu alebo zvýšenie monitorovania. Vo všetkých prípadoch však problém zaznamenajte a formálne akceptujte zvyškové riziko, aby bolo zrejmé, že sa naň nezabudlo.

Základná úroveň politiky pre SME je podobne praktická:

Inventár sa musí štvrťročne preskúmať s cieľom identifikovať zastarané, nepodporované alebo nezaplátané zariadenia

V Zenith Controls je opatrenie ISO/IEC 27002:2022 8.8, riadenie technických zraniteľností, mapované ako preventívne opatrenie podporujúce dôvernosť, integritu a dostupnosť, zosúladené s Identify a Protect, pričom riadenie hrozieb a zraniteľností je jeho prevádzkovou schopnosťou naprieč doménami Governance, Ecosystem, Protection a Defense.

Silný spis zraniteľnosti OT by mal zahŕňať:

• Identifikátor aktíva, vlastníka, zónu a kritickosť
• Zdroj zraniteľnosti, napríklad bezpečnostné upozornenie dodávateľa, skener, oznámenie integrátora alebo spravodajstvo o hrozbách
• Bezpečnostné a dostupnostné obmedzenia
• Realizovateľnosť záplaty a plánované údržbové okno
• Kompenzačné opatrenia, napríklad izoláciu, zoznamy riadenia prístupu, deaktivované služby alebo zvýšené monitorovanie
• Schválenie vlastníkom rizika a akceptáciu zvyškového rizika
• Dôkazy o overení po náprave alebo implementácii kompenzačného opatrenia

Tým sa výrok „nemôžeme záplatovať“ mení z výhovorky na auditovateľné ošetrenie rizík.

Vzdialený prístup dodávateľov: kritický bod NIS2 a IEC 62443

Väčšina OT incidentov má niekde rozmer tretej strany. Účet dodávateľa. Notebook integrátora. Nástroj vzdialenej údržby. Zdieľané prihlasovacie údaje. Výnimka vo firewalle, ktorá mala byť dočasná pred tromi rokmi.

NIS2 Article 21 výslovne zahŕňa bezpečnosť dodávateľského reťazca, zraniteľnosti špecifické pre dodávateľov, postupy kybernetickej bezpečnosti dodávateľov a postupy bezpečného vývoja. NIST CSF 2.0 je v tejto oblasti tiež podrobný prostredníctvom kritickosti dodávateľov, zmluvných požiadaviek, due diligence, priebežného monitorovania, koordinácie incidentov a ustanovení o ukončení.

Clarysec Politika bezpečnosti tretích strán a dodávateľov - SME vyjadruje princíp jednoduchým jazykom:

Dodávateľom musí byť udelený prístup iba k minimálnym systémom a údajom potrebným na výkon ich funkcie.

Pre OT znamená minimálny prístup viac než prístup na základe rolí v aplikácii. Prístup dodávateľa musí byť:

• vopred schválený na definovaný účel údržby,
• časovo obmedzený a predvolene zakázaný,
• chránený MFA alebo priebežnou autentifikáciou tam, kde je to vhodné,
• smerovaný cez bezpečný bastiónový server alebo riadenú platformu vzdialeného prístupu,
• obmedzený na príslušnú OT zónu alebo aktívum,
• logovaný, monitorovaný a pri vysokorizikovom prístupe zaznamenávaný na úrovni relácie,
• preskúmaný po dokončení,
• pokrytý zmluvnými bezpečnostnými povinnosťami a povinnosťami oznamovania incidentov.

Podniková Politika bezpečnosti IoT / OT obsahuje samostatnú požiadavku na vzdialený prístup:

Vzdialený prístup (na správu alebo servis vykonávaný dodávateľom) musí:

Táto klauzula ukotvuje bod správy a riadenia, zatiaľ čo detailné požiadavky sa musia implementovať v prístupových postupoch, dodávateľských zmluvách, technickej konfigurácii a monitorovacích pracovných tokoch.

V Zenith Controls je opatrenie ISO/IEC 27002:2022 5.21, riadenie informačnej bezpečnosti v dodávateľskom reťazci IKT, klasifikované ako preventívne opatrenie podporujúce dôvernosť, integritu a dostupnosť, zosúladené s konceptom Identify, pričom bezpečnosť vzťahov s dodávateľmi je jeho prevádzkovou schopnosťou a Governance, Ecosystem a Protection jeho doménami.

Pre OT toto mapovanie pomáha vysvetliť, prečo dôkazy o vzdialenom prístupe patria súčasne do súborov dodávateľského rizika, správy identít, sieťovej bezpečnosti, reakcie na incidenty a kontinuity.

Reakcia na incidenty: lehota NIS2 sa stretáva s velínom

Vráťme sa k alarmu o 02:17. Organizácia musí rozhodnúť, či je udalosť významná podľa NIS2. Article 23 vyžaduje bez zbytočného odkladu oznámiť významné incidenty ovplyvňujúce poskytovanie služby. Postup zahŕňa včasné varovanie do 24 hodín od zistenia, oznámenie incidentu do 72 hodín, priebežné aktualizácie, ak sú vyžiadané, a záverečnú správu najneskôr do jedného mesiaca od oznámenia incidentu, alebo správu o pokroku, ak incident stále prebieha.

V OT musí reakcia na incidenty odpovedať na otázky, ktoré IT playbooky často ignorujú:

• Možno postihnuté zariadenie izolovať bez vzniku bezpečnostného rizika?
• Kto má právomoc zastaviť výrobu alebo prepnúť na manuálny režim?
• Ktoré logy sú volatilné a vyžadujú okamžité zachovanie?
• Ktorého dodávateľa alebo integrátora treba kontaktovať?
• Je udalosť škodlivá, náhodná, environmentálna alebo spôsobená chybnou konfiguráciou?
• Môže mať cezhraničný dopad alebo dopad na príjemcov služby?
• Týka sa osobných údajov, napríklad logov preukazov, CCTV, údajov zamestnancov alebo záznamov zákazníckych služieb?

Politika OT pre SME poskytuje jednoduché pravidlo eskalácie anomálií:

Všetky anomálie musia byť okamžite nahlásené generálnemu manažérovi na ďalšie kroky

Zahŕňa aj princíp zamedzenia šírenia s ohľadom na bezpečnosť:

Zariadenie musí byť okamžite odpojené od siete, ak je to bezpečné

Posledných päť slov je kritických. Reakcia OT nemôže slepo kopírovať opatrenia zamedzenia šírenia z IT. „Ak je to bezpečné“ musí byť premietnuté do prevádzkových príručiek obnovy, matíc eskalácie, školení a stolových cvičení.

NIST CSF 2.0 sa sem dobre mapuje. Jeho výsledky Respond a Recover pokrývajú triáž, kategorizáciu, eskaláciu, analýzu koreňovej príčiny, integritu dôkazov, oznamovanie zainteresovaným stranám, zamedzenie šírenia, odstránenie, obnovu, kontroly integrity záloh a komunikáciu pri obnove.

Vytvorte dôkazovú líniu od rizika ku kontrole

Praktický spôsob, ako sa vyhnúť fragmentovanému súladu, je vybudovať jednu dôkazovú líniu od rizika cez predpis a opatrenie až po dôkaz.

Scenár: vzdialený dodávateľ kompresora potrebuje prístup k inžinierskej pracovnej stanici v OT sieti. Pracovná stanica môže meniť logiku PLC. Účet dodávateľa je stále povolený, zdieľaný viacerými inžiniermi dodávateľa a chránený iba heslom. Pracovná stanica používa softvér, ktorý nemožno aktualizovať do ďalšej údržbovej odstávky.

Zapíšte rizikový scenár do registra rizík:

„Neoprávnený alebo kompromitovaný vzdialený prístup dodávateľa k inžinierskej pracovnej stanici OT by mohol viesť k neoprávneným zmenám logiky PLC, prerušeniu výroby, bezpečnostnému dopadu a prerušeniu služby podliehajúcemu hláseniu podľa NIS2.“

Potom zmapujte opatrenia a povinnosti.

Plán ošetrenia má zakázať trvalý prístup dodávateľa, vyžadovať pomenované identity dodávateľa, vynucovať MFA, smerovať prístup cez riadený bastiónový server, obmedziť prístup na inžiniersku pracovnú stanicu, vyžadovať schválenie údržbového ticketu, zaznamenávať privilegované relácie, monitorovať príkazy a abnormálnu prevádzku, zdokumentovať nezaplátanú pracovnú stanicu ako výnimku zo zraniteľnosti a otestovať reakciu na incidenty pri podozrivej aktivite dodávateľa.

Zenith Blueprint, fáza Riadenie rizík, krok 13, poskytuje logiku sledovateľnosti SoA:

Krížovo odkazujte predpisy: Ak sú určité opatrenia implementované osobitne na dosiahnutie súladu s GDPR, NIS2 alebo DORA, môžete to uviesť buď v registri rizík (ako súčasť odôvodnenia dopadu rizika), alebo v poznámkach SoA.

Praktická lekcia je jednoduchá. Neuchovávajte dôkazy NIS2, ISO a inžinierske dôkazy OT v oddelených silách. Do registra rizík a SoA pridajte stĺpce pre tému NIS2 Article 21, opatrenie ISO/IEC 27002:2022, rodinu požiadaviek IEC 62443, vlastníka dôkazov a stav auditu.

Kde GDPR a DORA zapadajú do bezpečnosti OT

Bezpečnosť OT nie je vždy iba o strojoch. Prostredia kritickej infraštruktúry často spracúvajú osobné údaje prostredníctvom CCTV, systémov riadenia prístupu, logov preukazov, systémov bezpečnosti pracovnej sily, údržbových ticketov, sledovania vozidiel, návštevných systémov a platforiem zákazníckych služieb.

GDPR vyžaduje, aby sa osobné údaje spracúvali zákonne, spravodlivo a transparentne, zbierali na určené účely, obmedzovali na nevyhnutný rozsah, udržiavali presné, uchovávali iba tak dlho, ako je potrebné, a chránili primeranými technickými a organizačnými opatreniami. Vyžaduje aj zodpovednosť, čo znamená, že prevádzkovateľ musí byť schopný preukázať súlad.

Pre OT to znamená, že prístupové logy a monitorovacie záznamy sa nemajú stať nekontrolovanými úložiskami sledovacích údajov. Uchovávanie, prístupové práva, obmedzenie účelu a posúdenie porušenia ochrany údajov musia byť navrhnuté priamo do logovania a monitorovania.

DORA sa môže uplatniť tam, kde sú zapojené finančné subjekty, alebo kde externý poskytovateľ IKT podporuje prevádzkovú odolnosť finančného sektora. DORA pokrýva riadenie rizík IKT, hlásenie incidentov, testovanie odolnosti a riziko tretích strán v oblasti IKT. Pre finančné subjekty, ktoré sú zároveň základnými alebo dôležitými subjektmi podľa pravidiel transpozície NIS2, môže DORA pôsobiť ako odvetvový režim pre prekrývajúce sa povinnosti, pričom koordinácia s orgánmi NIS2 môže zostať relevantná.

Uplatňujú sa rovnaké dôkazové disciplíny: identifikácia aktív, ochrana, detekcia, kontinuita, zálohovanie, riziko tretích strán, testovanie, školenie a dohľad manažmentu.

Auditný pohľad: jedno opatrenie, viacero perspektív uistenia

Silná implementácia bezpečnosti OT podľa NIS2 by mala obstáť pri viacerých auditných perspektívach.

Preto Clarysec pristupuje k Zenith Controls ako ku kompasu krížového súladu. Jeho atribúty opatrení pomáhajú vysvetliť účel oficiálnych opatrení ISO/IEC 27002:2022, zatiaľ čo prístup mapovania prepája tieto opatrenia s NIS2, NIST CSF, správou a riadením dodávateľov, kontinuitou a auditnými dôkazmi.

Časté úskalia implementácie OT podľa NIS2

Najčastejšie zlyhania bezpečnosti OT sú zriedka spôsobené nedostatkom dokumentov. Spôsobujú ich dokumenty, ktoré nezodpovedajú závodu.

Úskalie 1: IT vlastní program NIS2, ale OT vlastní riziko. Musia byť zapojené prevádzka, inžiniering, bezpečnosť a údržba.

Úskalie 2: Inventarizácia aktív končí pri serveroch. Inventár OT musí zahŕňať PLC, RTU, HMI, historizačné systémy, inžinierske pracovné stanice, priemyselné prepínače, senzory, brány, zariadenia vzdialeného prístupu a komponenty spravované dodávateľmi.

Úskalie 3: Segmentácia existuje v diagrame, ale nie v pravidlách firewallu. Audítori si vyžiadajú dôkazy o presadzovaní, riadení zmien a monitorovaní.

Úskalie 4: Výnimky zo zraniteľností sú neformálne. Obmedzenia zastaraných systémov sú prijateľné iba vtedy, keď sú zdokumentované, schválené, monitorované a opakovane preskúmavané.

Úskalie 5: Prístup dodávateľov sa považuje iba za dodávateľskú otázku. Je to zároveň otázka riadenia prístupu, logovania, monitorovania, sieťovej bezpečnosti, reakcie na incidenty a kontinuity.

Úskalie 6: Reakcia na incidenty ignoruje bezpečnosť. OT playbooky musia definovať, kto môže izolovať zariadenia, zastaviť procesy, prepnúť režimy alebo kontaktovať regulátorov.

Úskalie 7: Hlásenie podľa NIS2 nie je nacvičené. Rozhodovací proces pre 24-hodinovú a 72-hodinovú lehotu by sa mal otestovať pred skutočnou udalosťou.

Implementačná cesta Clarysec od zodpovednosti predstavenstva po dôkazy OT

Praktická implementácia bezpečnosti OT podľa NIS2 môže postupovať podľa tejto sekvencie:

1. Potvrďte rozsah NIS2, klasifikáciu subjektu a kritickosť služby.
2. Definujte rozsah OT v rámci ISMS vrátane rozhraní a závislostí.
3. Vytvorte inventár OT aktív a dátových tokov.
4. Identifikujte zákonné, zmluvné, bezpečnostné, súkromnostné a odvetvové povinnosti.
5. Realizujte workshopy posúdenia rizík špecifické pre OT s inžinieringom, prevádzkou, IT, SOC, obstarávaním a manažmentom.
6. Zmapujte ošetrenie rizík na opatrenia ISO/IEC 27002:2022, témy NIS2 a implementačné vzory IEC 62443.
7. Aktualizujte Vyhlásenie o uplatniteľnosti o odôvodnenie OT a vlastníkov dôkazov.
8. Implementujte prioritné opatrenia: segmentáciu, prístup dodávateľov, riešenie zraniteľností, monitorovanie, zálohy a reakciu na incidenty.
9. Aktualizujte politiky a postupy vrátane bezpečnosti OT, bezpečnosti dodávateľov, vzdialeného prístupu, reakcie na incidenty a kontinuity činností.
10. Realizujte stolové cvičenia a technické validačné cvičenia.
11. Pripravte auditné balíky pre NIS2, ISO/IEC 27001:2022, uistenie zákazníkov a internú správu a riadenie.
12. Premietnite zistenia do preskúmania manažmentom a neustáleho zlepšovania.

Toto odráža prevádzkový model v Zenith Blueprint, najmä krok 13 pre ošetrenie rizík a sledovateľnosť SoA, krok 14 pre vývoj politík a krížové odkazy na predpisy, krok 19 pre riadenie zraniteľností a krok 20 pre bezpečnosť sietí.

Rovnaký prístup využíva politiky Clarysec na premenu jazyka rámcov na prevádzkové pravidlá. Podniková Politika bezpečnosti IoT / OT vyžaduje preskúmanie bezpečnostnej architektúry pred nasadením:

Všetky nové IoT/OT zariadenia musia pred nasadením prejsť preskúmaním bezpečnostnej architektúry. Toto preskúmanie musí validovať:

Ďalej uvádza:

Všetka prevádzka v rámci IoT/OT sietí a medzi nimi musí byť priebežne monitorovaná pomocou:

Tieto klauzuly vytvárajú kotvy správy a riadenia. Implementačné dôkazy môžu zahŕňať upozornenia OT IDS, logy firewallu, koreláciu SIEM, referenčné profily prevádzky, tickety anomálií a záznamy reakcie.

Ako vyzerajú dobré dôkazy OT podľa NIS2

Balík dôkazov OT podľa NIS2 má byť dostatočne praktický pre inžinierov a dostatočne štruktúrovaný pre audítorov.

Pre segmentáciu zahrňte schválenú architektúru, diagramy zón a komunikačných kanálov, exporty pravidiel firewallu, záznamy o zmenách, pravidelné preskúmania pravidiel, záznamy výnimiek a monitorovacie upozornenia.

Pre prístup dodávateľov zahrňte posúdenie kritickosti dodávateľa, zmluvné doložky, schválený prístupový postup, pomenované účty, dôkazy MFA, prístupové logy, záznamy relácií, pravidelnú revíziu prístupových práv a záznamy offboardingu.

Pre riadenie zraniteľností zahrňte inventár, zdroje bezpečnostných upozornení, výstupy pasívneho zisťovania, tickety zraniteľností, plány záplatovania, kompenzačné opatrenia, akceptáciu rizika a dôkazy uzatvorenia.

Pre reakciu na incidenty zahrňte playbooky, eskalačné kontakty, rozhodovací strom hlásenia podľa NIS2, výsledky stolových cvičení, incidentné tickety, návrhy oznámení orgánom, pravidlá nakladania s dôkazmi a ponaučenia.

Pre kontinuitu zahrňte stratégiu zálohovania OT, offline alebo chránené zálohy, výsledky testov obnovy, zoznam kritických náhradných dielov, manuálne prevádzkové postupy, priority obnovy a plány krízovej komunikácie.

Pre správu a riadenie zahrňte schválenie predstavenstvom alebo manažmentom, priradenie rolí, záznamy o školeniach, výsledky interného auditu, KPI, zápisnice z preskúmania rizík a rozhodnutia z preskúmania manažmentom.

Tento dôkazový model je zosúladený s ISO/IEC 27001:2022, pretože podporuje ošetrenie rizík, zdokumentované informácie, hodnotenie výkonnosti a neustále zlepšovanie. Je zosúladený s NIS2, pretože preukazuje primerané a úmerné opatrenia. Je zosúladený s IEC 62443, pretože ho možno sledovať k architektúre OT a inžinierskym opatreniam.

Premeňte svoj program bezpečnosti OT na auditovateľnú pripravenosť na NIS2

Ak vaše prostredie OT podporuje kritickú alebo regulovanú službu, čakať na regulátora, zákazníka alebo incident, ktorý odhalí medzery, je nesprávna stratégia.

Začnite jedným prípadom použitia s vysokým dopadom: vzdialený prístup dodávateľa do kritickej OT zóny, riešenie zraniteľností nepodporovaných priemyselných aktív alebo segmentácia medzi podnikovým IT a OT. Vytvorte rizikový scenár, zmapujte ho na NIS2 Article 21, vyberte opatrenia ISO/IEC 27002:2022, preveďte ich do implementačných vzorov IEC 62443 a zhromaždite dôkazy.

Clarysec vám môže pomôcť urýchliť túto prácu pomocou Zenith Blueprint, Zenith Controls, Politiky bezpečnosti IoT / OT, Politiky bezpečnosti internetu vecí (IoT) / prevádzkových technológií (OT) - SME a Politiky bezpečnosti tretích strán a dodávateľov - SME.

Váš ďalší krok: vyberte jednu OT službu, zmapujte jej aktíva a závislosti a tento týždeň vytvorte dôkazovú líniu od rizika ku kontrole. Ak chcete štruktúrovanú implementačnú cestu, 30-kroková cestovná mapa Clarysec a nástrojová sada pre krížový súlad môžu túto prvú líniu rozvinúť do úplného programu bezpečnosti OT podľa NIS2.