Zabezpečení OT podle NIS2: mapování ISO 27001 a IEC 62443

V pondělí ve 02:17 obdrží operátor úpravny vody alarm z dávkovacího systému. Dávkování chemikálie je stále v bezpečných mezích, jeden PLC však hlásí nepravidelné příkazy, inženýrská pracovní stanice zobrazuje neúspěšná přihlášení z VPN účtu dodavatele a službu konající analytik SOC klade otázku, na kterou nikdo nechce odpovídat pod tlakem.

Jde o IT incident, OT incident, událost ovlivňující bezpečnost provozu, nebo významný incident podléhající hlášení podle NIS2?

Závod má firewally. Má dokumentaci ISO. Má tabulku dodavatelů. Má dokonce plán reakce na incidenty. Jenže plán byl napsán pro kompromitaci e-mailu a výpadky cloudových služeb, nikoli pro zastaralou řídicí jednotku, kterou nelze během výroby záplatovat, dodavatele, který potřebuje vzdálený přístup k obnovení služby, a regulační orgán, který očekává důkazy v oznamovacích lhůtách NIS2.

Stejný problém se objevuje i v zasedacích místnostech vedení. Ředitel informační bezpečnosti u regionálního dodavatele energie může mít pro podnikové IT certifikovaný systém řízení bezpečnosti informací (ISMS) podle ISO/IEC 27001:2022, zatímco prostředí provozních technologií zůstává spletí PLC, RTU, HMI, historizačních systémů, inženýrských pracovních stanic, průmyslových přepínačů a přístupových cest dodavatelů. Otázka generálního ředitele je jednoduchá: „Máme to pokryté? Dokážete to doložit?“

Pro mnoho základních a důležitých subjektů je upřímná odpověď nepříjemná. Částečně pokryté to mají. Částečně to doložit dokážou. Zabezpečení OT podle NIS2 však vyžaduje více než obecnou shodu podnikového IT.

Vyžaduje jednotný provozní model, který propojuje řízení podle ISO/IEC 27001:2022, jazyk opatření ISO/IEC 27002:2022, průmyslové inženýrské postupy IEC 62443, opatření pro řízení kybernetických rizik podle článku 21 NIS2 a důkazy pro hlášení incidentů podle článku 23 NIS2.

Právě tento most tento průvodce buduje.

Proč je zabezpečení OT podle NIS2 jiné než běžná shoda IT

NIS2 se vztahuje na mnoho veřejných a soukromých subjektů, které v EU poskytují služby spadající do působnosti směrnice, včetně základních a důležitých subjektů v odvětvích, jako jsou energetika, doprava, bankovnictví, infrastruktura finančních trhů, zdravotnictví, pitná voda, odpadní voda, digitální infrastruktura, řízení ICT služeb, veřejná správa, vesmír, poštovní služby, nakládání s odpady, výroba, chemický průmysl, potravinářství, digitální poskytovatelé a výzkum.

Směrnice vyžaduje vhodná a přiměřená technická, provozní a organizační opatření pro řízení kybernetických rizik, prevenci nebo minimalizaci dopadů incidentů a ochranu kontinuity služeb. Článek 21 zahrnuje přístup založený na všech hrozbách, který pokrývá analýzu rizik, bezpečnostní politiky, zvládání incidentů, kontinuitu činností, krizové řízení, zabezpečení dodavatelského řetězce, bezpečné pořizování a údržbu, zvládání a oznamování zranitelností, posuzování účinnosti, kybernetickou hygienu, školení, kryptografii, personální bezpečnost, řízení přístupu, správu aktiv, MFA nebo nepřetržité ověřování identity, bezpečnou komunikaci a případně nouzovou komunikaci.

Tyto požadavky znějí týmu ISO/IEC 27001:2022 povědomě. V OT se však každý z nich chová jinak.

Zranitelnost webového serveru lze často záplatovat během několika dnů. Zranitelnost řídicí jednotky turbíny může vyžadovat validaci dodavatelem, okno údržby, přezkum bezpečnosti provozu a záložní provozní postupy. Notebook lze přeinstalovat. Produkční HMI může záviset na zastaralém operačním systému, protože průmyslová aplikace nebyla certifikována pro novější platformu. Postup SOC může říkat „izolujte hostitele“, zatímco inženýr OT odpoví: „ne dříve, než zjistíme, zda izolace neovlivní řízení tlaku.“

Rozdíl není pouze technický. IT obvykle upřednostňuje důvěrnost, integritu a dostupnost. OT upřednostňuje dostupnost, integritu procesu a bezpečnost provozu. Bezpečnostní opatření, které zavádí latenci, vyžaduje restart nebo přerušuje fyzický proces, může být bez schválení inženýringu nepřijatelné.

NIS2 nevyjímá OT z řízení kybernetických rizik. Očekává, že organizace doloží, že opatření jsou přiměřená riziku a odpovídají provozní realitě.

Vrstva opatření: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 a IEC 62443

Obhajitelný program zabezpečení OT podle NIS2 začíná vícevrstvým souborem opatření.

ISO/IEC 27001:2022 poskytuje systém řízení. Vyžaduje, aby organizace definovala kontext, zainteresované strany, regulační povinnosti, rozsah ISMS, rozhraní a závislosti. Vyžaduje také vlastnictví ze strany vedení, politiku bezpečnosti informací, posouzení rizik, ošetření rizik, Prohlášení o aplikovatelnosti, dokumentované informace, interní audit, přezkoumání vedením a neustálé zlepšování.

ISO/IEC 27002:2022 poskytuje slovník opatření. U OT mezi nejdůležitější opatření často patří bezpečnost dodavatelů, řízení rizik dodavatelského řetězce ICT, plánování incidentů, připravenost kontinuity činností, právní a smluvní požadavky, správa aktiv, řízení přístupu, řízení zranitelností, zálohy, protokolování, monitorování, zabezpečení sítí a oddělení sítí.

IEC 62443 poskytuje průmyslový model bezpečnostního inženýrství. Pomáhá převádět požadavky systému řízení do postupů OT, jako jsou zóny, komunikační kanály (conduits), úrovně zabezpečení, odpovědnosti vlastníka aktiva, odpovědnosti systémového integrátora, očekávání vůči dodavatelům produktů, omezení vzdáleného přístupu, princip nejmenší funkčnosti, správa účtů, zpevnění konfigurace a opatření v životním cyklu.

Clarysec používá tuto strukturu, protože předchází dvěma častým selháním. Zaprvé brání tomu, aby se implementace ISO stala pro OT příliš obecnou. Zadruhé brání tomu, aby se inženýrská práce podle IEC 62443 odpojila od odpovědnosti řídicích orgánů, oznamovacích povinností podle NIS2 a auditních důkazů.

Politika zabezpečení IoT / OT společnosti Clarysec tento most vyjadřuje přímo:

Zajistit, aby všechna nasazení byla v souladu s opatřeními ISO/IEC 27001 a použitelnými odvětvově specifickými pokyny (např. IEC 62443, ISO 27019, NIST SP 800-82).

Na této větě záleží. Politika není pouze kontrolním seznamem pro zpevnění konfigurace zařízení. Propojuje řízení podle ISO, odvětvové pokyny pro OT a provozní bezpečnost.

Začněte rozsahem: kterou službu OT je nutné chránit?

Před mapováním opatření definujte službu OT obchodním a regulačním jazykem.

Vedoucí závodu může říci: „Provozujeme balicí linku.“ Posouzení NIS2 by mělo říci: „Tento výrobní proces podporuje základní nebo důležitou službu a závisí na PLC, HMI, inženýrských pracovních stanicích, historizačních systémech, průmyslových přepínačích, vzdáleném přístupu dodavatelů, dodavateli údržby, cloudovém analytickém zdroji a podnikové službě identity.“

Kapitoly 4.1 až 4.4 ISO/IEC 27001:2022 jsou užitečné, protože nutí organizaci identifikovat interní a externí otázky, zainteresované strany, právní a smluvní požadavky, hranice ISMS, rozhraní a závislosti. Pro zabezpečení OT podle NIS2 to znamená mapovat nejen síť centrály, ale také průmyslové systémy a závislosti služeb, které ovlivňují kontinuitu, bezpečnost provozu a regulované poskytování služby.

NIST CSF 2.0 posiluje stejnou logiku. Jeho funkce GOVERN vyžaduje pochopení poslání, zainteresovaných stran, závislostí, právních a regulačních povinností, kritických služeb a služeb, na nichž organizace závisí. Organizační profily poskytují praktickou metodu pro vymezení současného stavu, definování cílového stavu, analýzu mezer a vytvoření prioritizovaného akčního plánu.

U prostředí OT Clarysec obvykle začíná pěti otázkami:

1. Kterou regulovanou nebo kritickou službu toto prostředí OT podporuje?
2. Která aktiva OT, sítě, datové toky a třetí strany jsou pro tuto službu nezbytné?
3. Jaká omezení bezpečnosti provozu, dostupnosti a provozního režimu ovlivňují bezpečnostní opatření?
4. Jaké právní, smluvní a odvětvové povinnosti se uplatní, včetně NIS2, GDPR, DORA tam, kde je to relevantní, zákaznických smluv a národních pravidel?
5. Které části prostředí jsou uvnitř ISMS a které jsou externími závislostmi vyžadujícími opatření vůči dodavatelům?

Mnoho programů NIS2 zde selhává. Vymezí rozsah kolem podnikového IT, protože jeho inventarizace je jednodušší. Auditoři a regulační orgány nebudou přesvědčeni, pokud se nejkritičtější závislost služby objeví pouze jako neurčitá položka „tovární síť“.

Praktická mapa opatření OT podle NIS2

Níže uvedená tabulka ukazuje, jak převést témata článku 21 NIS2 do důkazů podle ISO/IEC 27001:2022, ISO/IEC 27002:2022 a IEC 62443. Nenahrazuje formální posouzení rizik, ale poskytuje ředitelům informační bezpečnosti, manažerům OT a týmům compliance praktický výchozí bod.

Tato mapa je záměrně zaměřena na důkazy. Podle NIS2 nestačí říci „máme segmentaci“. Musíte ukázat, proč je segmentace vhodná, jak je implementována, jak jsou schvalovány výjimky a jak návrh snižuje dopad na regulovanou službu.

Segmentace: první opatření OT, které auditoři ověří

Pokud by incident ve 02:17 zahrnoval pohyb útočníka z kancelářského notebooku na inženýrskou pracovní stanici, první auditní otázka by byla zřejmá: proč taková cesta mohla existovat?

Politika zabezpečení IoT / OT je výslovná:

Systémy OT musí fungovat ve vyhrazených sítích izolovaných od podnikového IT a systémů dostupných z internetu.

Pro menší prostředí poskytuje Politika zabezpečení internetu věcí (IoT) / provozních technologií (OT) pro malé a střední podniky praktický základ:

Všechna zařízení internetu věcí (IoT) a provozních technologií (OT) musí být umístěna v oddělené síti Wi‑Fi nebo VLAN.

U vyspělého provozovatele kritické infrastruktury by segmentace měla být navržena podle zón a komunikačních kanálů OT. Podnikoví uživatelé by neměli mít přímý přístup do sítí PLC. Připojení dodavatelů by měla končit v řízených přístupových zónách. Replikace historizačního systému by měla využívat schválené cesty. Bezpečnostní systémy by měly být izolovány podle rizik a inženýrských požadavků. Bezdrátové sítě OT by měly být odůvodněné, konfiguračně zpevněné a monitorované.

Zenith Blueprint: třicetikrokový plán auditora ve fázi Opatření v praxi, krok 20, vysvětluje princip za zabezpečením sítí podle ISO/IEC 27002:2022:

Průmyslové řídicí systémy mají být izolovány od kancelářského provozu.

Zároveň upozorňuje, že zabezpečení sítí vyžaduje bezpečnou architekturu, segmentaci, řízení přístupu, šifrování při přenosu, monitorování a vícevrstvou ochranu.

V Zenith Controls: průvodce napříč požadavky compliance je opatření ISO/IEC 27002:2022 8.22, oddělení sítí, pojato jako preventivní opatření podporující důvěrnost, integritu a dostupnost, sladěné s konceptem kybernetické bezpečnosti Protect, se zabezpečením systémů a sítí jako provozní schopností a ochranou jako bezpečnostní doménou.

Tato klasifikace je pro důkazy NIS2 užitečná, protože segmentace není dekorativní diagram. Je to preventivní opatření navržené ke snížení rozsahu dopadu a zachování kontinuity základní služby.

Řízení zranitelností, když systémy OT nelze prostě záplatovat

NIS2 vyžaduje bezpečné pořizování, vývoj a údržbu sítí a informačních systémů, včetně zvládání a oznamování zranitelností. V IT řízení zranitelností často znamená skenovat, prioritizovat, záplatovat a ověřit. OT přidává omezení.

Kritické HMI může být možné záplatovat pouze během plánované odstávky. Aktualizace firmwaru PLC může vyžadovat zapojení dodavatele. Bezpečnostně certifikovaný systém může při nesprávné úpravě ztratit certifikaci. Některá zastaralá zařízení nemusí mít podporu dodavatele vůbec.

Zenith Blueprint, fáze Opatření v praxi, krok 19, poskytuje správnou auditní logiku pro technické zranitelnosti:

U systémů, které nelze okamžitě záplatovat, například z důvodu zastaralého softwaru nebo omezení odstávek, implementujte kompenzační opatření. To může zahrnovat izolaci systému za firewallem, omezení přístupu nebo zvýšení monitorování. Ve všech případech také zaznamenejte a formálně přijměte zbytkové riziko, aby bylo zřejmé, že problém nebyl opomenut.

Základ politiky pro malé a střední podniky je podobně praktický:

Evidence musí být čtvrtletně přezkoumána za účelem identifikace zastaralých, nepodporovaných nebo nezáplatovaných zařízení.

V Zenith Controls je opatření ISO/IEC 27002:2022 8.8, řízení technických zranitelností, mapováno jako preventivní opatření podporující důvěrnost, integritu a dostupnost, sladěné s Identify a Protect, s řízením hrozeb a zranitelností jako provozní schopností napříč doménami řízení, ekosystému, ochrany a obrany.

Kvalitní složka zranitelnosti OT by měla obsahovat:

• Identifikátor aktiva, vlastníka, zónu a kritičnost
• Zdroj zranitelnosti, například bezpečnostní oznámení dodavatele, skener, oznámení integrátora nebo informace o hrozbách
• Omezení bezpečnosti provozu a dostupnosti
• Proveditelnost záplaty a plánované okno údržby
• Kompenzační opatření, například izolaci, seznamy řízení přístupu, vypnuté služby nebo zvýšené monitorování
• Schválení vlastníkem rizika a přijetí zbytkového rizika
• Ověřovací důkazy po nápravě nebo implementaci kompenzačního opatření

Tím se tvrzení „nemůžeme záplatovat“ mění z výmluvy na auditovatelné ošetření rizika.

Vzdálený přístup dodavatelů: kritický bod NIS2 a IEC 62443

Většina incidentů OT má někde rozměr třetí strany. Účet dodavatele. Notebook integrátora. Nástroj vzdálené údržby. Sdílený přihlašovací údaj. Výjimka ve firewallu, která měla být dočasná před třemi lety.

Článek 21 NIS2 výslovně zahrnuje zabezpečení dodavatelského řetězce, zranitelnosti specifické pro dodavatele, postupy kybernetické bezpečnosti dodavatelů a postupy bezpečného vývoje. NIST CSF 2.0 je v tomto bodě rovněž podrobný prostřednictvím kritičnosti dodavatelů, smluvních požadavků, náležité péče, průběžného monitorování, koordinace incidentů a ustanovení o ukončení spolupráce.

Bezpečnostní politika pro dodavatele a poskytovatele služeb třetích stran pro malé a střední podniky společnosti Clarysec vyjadřuje princip jednoduchým jazykem:

Dodavatelům smí být udělen přístup pouze k minimálním systémům a datům potřebným k plnění jejich funkce.

U OT znamená minimální přístup více než přístup na základě rolí v aplikaci. Přístup dodavatelů musí být:

• Předem schválen pro definovaný účel údržby
• Časově omezený a ve výchozím stavu vypnutý
• Chráněný MFA nebo nepřetržitým ověřováním identity, kde je to vhodné
• Směrovaný přes zabezpečený bastionový server nebo řízenou platformu vzdáleného přístupu
• Omezený na příslušnou zónu nebo aktivum OT
• Protokolovaný, monitorovaný a u vysoce rizikového přístupu zaznamenávaný na úrovni relace
• Přezkoumaný po dokončení
• Pokrytý smluvními bezpečnostními povinnostmi a povinnostmi oznamování incidentů

Podniková Politika zabezpečení IoT / OT obsahuje samostatný požadavek na vzdálený přístup:

Vzdálený přístup (pro správu nebo servis dodavatelem) musí:

Tato klauzule ukotvuje bod správy a řízení, zatímco podrobné požadavky mají být implementovány v postupech přístupu, smlouvách s dodavateli, technické konfiguraci a pracovních postupech monitorování.

V Zenith Controls je opatření ISO/IEC 27002:2022 5.21, řízení bezpečnosti informací v dodavatelském řetězci ICT, klasifikováno jako preventivní opatření podporující důvěrnost, integritu a dostupnost, sladěné s konceptem Identify, s bezpečností vztahů s dodavateli jako provozní schopností a doménami řízení, ekosystému a ochrany.

Pro OT toto mapování pomáhá vysvětlit, proč důkazy o vzdáleném přístupu patří současně do složek dodavatelského rizika, správy identit, zabezpečení sítí, reakce na incidenty a kontinuity.

Reakce na incidenty: hodiny NIS2 se potkávají s velínem

Vraťme se k alarmu ve 02:17. Organizace musí rozhodnout, zda je událost podle NIS2 významná. Článek 23 vyžaduje oznámení bez zbytečného odkladu u významných incidentů ovlivňujících poskytování služby. Posloupnost zahrnuje včasné varování do 24 hodin od zjištění, oznámení incidentu do 72 hodin, průběžné aktualizace na vyžádání a závěrečnou zprávu nejpozději jeden měsíc po oznámení incidentu, případně průběžnou zprávu, pokud incident stále probíhá.

V OT musí reakce na incidenty odpovědět na otázky, které IT postupy často ignorují:

• Lze dotčené zařízení izolovat bez vytvoření rizika pro bezpečnost provozu?
• Kdo má pravomoc zastavit výrobu nebo přepnout do manuálního režimu?
• Které logy jsou volatilní a vyžadují okamžité zachování?
• Kterého dodavatele nebo integrátora je nutné kontaktovat?
• Je událost škodlivá, náhodná, environmentální nebo způsobená chybnou konfigurací?
• Může dojít k přeshraničnímu dopadu nebo dopadu na příjemce služeb?
• Jsou zapojeny osobní údaje, například logy průkazů, CCTV, údaje zaměstnanců nebo záznamy zákaznických služeb?

Politika OT pro malé a střední podniky poskytuje jednoduché pravidlo eskalace anomálií:

Jakékoli anomálie musí být okamžitě hlášeny generálnímu řediteli k dalšímu postupu.

Obsahuje také zásadu zamezení šíření zohledňující bezpečnost provozu:

Zařízení musí být okamžitě odpojeno od sítě, pokud je to bezpečné.

Těchto posledních pět slov je zásadních. Reakce OT nemůže slepě kopírovat úkony zamezení šíření z IT. „Pokud je to bezpečné“ musí být promítnuto do provozních postupů, eskalačních matic, školení a simulačních cvičení typu tabletop.

NIST CSF 2.0 se zde dobře mapuje. Jeho výstupy Respond a Recover pokrývají triáž, kategorizaci, eskalaci, analýzu kořenové příčiny, integritu důkazů, informování zainteresovaných stran, zamezení šíření, odstranění, obnovení, kontroly integrity záloh a komunikaci při obnově.

Vybudujte důkazní linii od rizika k opatření

Praktický způsob, jak předejít roztříštěné compliance, je vybudovat jednu důkazní linii od rizika přes právní předpis a opatření až k důkazu.

Scénář: vzdálený dodavatel kompresoru potřebuje přístup k inženýrské pracovní stanici v síti OT. Pracovní stanice může měnit logiku PLC. Účet dodavatele je vždy povolen, sdílený více inženýry dodavatele a chráněný pouze heslem. Pracovní stanice provozuje software, který nelze upgradovat do příští odstávky údržby.

Zapište rizikový scénář do registru rizik:

„Neoprávněný nebo kompromitovaný vzdálený přístup dodavatele k inženýrské pracovní stanici OT by mohl vést k neoprávněným změnám logiky PLC, narušení výroby, dopadu na bezpečnost provozu a přerušení služby podléhajícímu hlášení podle NIS2.“

Poté namapujte opatření a povinnosti.

Plán ošetření musí vypnout trvale povolený přístup dodavatele, vyžadovat pojmenované identity dodavatele, vynucovat MFA, směrovat přístup přes řízený bastionový server, omezit přístup na inženýrskou pracovní stanici, vyžadovat schválení tiketu údržby, zaznamenávat privilegované relace, monitorovat příkazy a abnormální provoz, zdokumentovat nezáplatovanou pracovní stanici jako výjimku ze zranitelnosti a otestovat reakci na incidenty při podezřelé aktivitě dodavatele.

Zenith Blueprint, fáze řízení rizik, krok 13, poskytuje logiku dohledatelnosti SoA:

Křížově odkazujte na právní předpisy: Pokud jsou určitá opatření implementována specificky za účelem souladu s GDPR, NIS2 nebo DORA, můžete to uvést buď v registru rizik (jako součást odůvodnění dopadu rizika), nebo v poznámkách SoA.

Praktické poučení je jednoduché. Neudržujte důkazy NIS2, ISO a inženýringu OT v oddělených silech. Přidejte do registru rizik a SoA sloupce pro téma článku 21 NIS2, opatření ISO/IEC 27002:2022, skupinu požadavků IEC 62443, vlastníka důkazů a stav auditu.

Kam do zabezpečení OT zapadají GDPR a DORA

Zabezpečení OT se ne vždy týká pouze strojů. Prostředí kritické infrastruktury často zpracovávají osobní údaje prostřednictvím CCTV, systémů řízení přístupu, logů průkazů, systémů bezpečnosti pracovníků, tiketů údržby, sledování vozidel, návštěvních systémů a platforem zákaznických služeb.

GDPR vyžaduje, aby osobní údaje byly zpracovávány zákonně, korektně a transparentně, shromažďovány pro stanovené účely, omezeny na nezbytný rozsah, udržovány přesné, uchovávány pouze po nezbytnou dobu a chráněny vhodnými technickými a organizačními opatřeními. Vyžaduje také odpovědnost, což znamená, že správce musí být schopen doložit soulad.

Pro OT to znamená, že logy přístupu a monitorovací záznamy se nesmí stát neřízenými úložišti dohledových dat. Uchovávání, přístupová práva, omezení účelu a posouzení porušení zabezpečení musí být navrženy do protokolování a monitorování.

DORA se může uplatnit tam, kde jsou zapojeny finanční subjekty nebo kde poskytovatel ICT služeb třetí strany podporuje provozní odolnost finančního sektoru. DORA pokrývá řízení rizik v oblasti ICT, hlášení incidentů, testování odolnosti a riziko třetích stran v oblasti ICT. U finančních subjektů, které jsou podle transpozičních pravidel NIS2 zároveň základními nebo důležitými subjekty, může DORA působit jako odvětvový režim pro překrývající se povinnosti, přičemž koordinace s orgány NIS2 může zůstat relevantní.

Platí stejné disciplíny důkazů: identifikace aktiv, ochrana, detekce, kontinuita, zálohování, riziko třetích stran, testování, školení a dohled vedení.

Auditní pohled: jedno opatření, více perspektiv ujištění

Silná implementace zabezpečení OT podle NIS2 musí obstát z více auditních perspektiv.

Proto Clarysec zachází s Zenith Controls jako s kompasem napříč požadavky compliance. Jeho atributy opatření pomáhají vysvětlit účel oficiálních opatření ISO/IEC 27002:2022, zatímco mapovací přístup propojuje tato opatření s NIS2, NIST CSF, správou dodavatelů, kontinuitou a auditními důkazy.

Časté chyby při implementaci OT podle NIS2

Nejčastější selhání zabezpečení OT jsou jen zřídka způsobena nedostatkem dokumentů. Způsobují je dokumenty, které neodpovídají závodu.

Chyba 1: Program NIS2 vlastní IT, ale riziko vlastní OT. Musí být zapojeny provoz, inženýring, bezpečnost provozu a údržba.

Chyba 2: Evidence aktiv končí u serverů. Evidence OT musí zahrnovat PLC, RTU, HMI, historizační systémy, inženýrské pracovní stanice, průmyslové přepínače, senzory, brány, zařízení vzdáleného přístupu a komponenty spravované dodavateli.

Chyba 3: Segmentace existuje na diagramu, ale nikoli v pravidlech firewallu. Auditoři si vyžádají důkazy o vynucování, řízení změn a monitorování.

Chyba 4: Výjimky ze zranitelností jsou neformální. Omezení zastaralých systémů jsou přijatelná pouze tehdy, jsou-li zdokumentována, schválena, monitorována a pravidelně přezkoumávána.

Chyba 5: Přístup dodavatelů je vnímán pouze jako dodavatelské téma. Je to také téma řízení přístupu, protokolování, monitorování, zabezpečení sítí, reakce na incidenty a kontinuity.

Chyba 6: Reakce na incidenty ignoruje bezpečnost provozu. Postupy OT musí definovat, kdo může izolovat zařízení, zastavit procesy, přepnout režimy nebo kontaktovat regulační orgány.

Chyba 7: Hlášení NIS2 není nacvičeno. Rozhodovací proces pro 24hodinovou a 72hodinovou lhůtu musí být otestován před reálnou událostí.

Implementační cesta Clarysec od odpovědnosti řídicích orgánů k důkazům OT

Praktická implementace zabezpečení OT podle NIS2 může postupovat v tomto pořadí:

1. Potvrdit rozsah NIS2, klasifikaci subjektu a kritičnost služby.
2. Definovat rozsah OT v rámci ISMS, včetně rozhraní a závislostí.
3. Vytvořit evidenci aktiv OT a datových toků.
4. Identifikovat právní, smluvní, bezpečnostní, soukromí a odvětvové povinnosti.
5. Uspořádat workshopy posouzení rizik specifické pro OT s inženýringem, provozem, IT, SOC, nákupem a vedením.
6. Namapovat ošetření rizik na opatření ISO/IEC 27002:2022, témata NIS2 a implementační vzorce IEC 62443.
7. Aktualizovat Prohlášení o aplikovatelnosti s odůvodněním OT a vlastníky důkazů.
8. Implementovat prioritní opatření: segmentaci, přístup dodavatelů, zvládání zranitelností, monitorování, zálohy a reakci na incidenty.
9. Aktualizovat politiky a postupy, včetně zabezpečení OT, bezpečnosti dodavatelů, vzdáleného přístupu, reakce na incidenty a kontinuity činností.
10. Provést simulační cvičení typu tabletop a technická validační cvičení.
11. Připravit auditní balíčky pro NIS2, ISO/IEC 27001:2022, ujištění zákazníků a interní řízení.
12. Promítnout zjištění do přezkoumání vedením a neustálého zlepšování.

To odráží provozní model v Zenith Blueprint, zejména krok 13 pro ošetření rizik a dohledatelnost SoA, krok 14 pro vývoj politik a regulační křížové odkazy, krok 19 pro řízení zranitelností a krok 20 pro zabezpečení sítí.

Stejný přístup používá politiky Clarysec k převodu jazyka rámců do provozních pravidel. Podniková Politika zabezpečení IoT / OT vyžaduje přezkum bezpečnostní architektury před nasazením:

Všechna nová zařízení IoT/OT musí před nasazením projít přezkumem bezpečnostní architektury. Tento přezkum musí ověřit:

Dále uvádí:

Veškerý provoz uvnitř sítí IoT/OT a mezi nimi musí být průběžně monitorován pomocí:

Tyto klauzule vytvářejí kotvy správy a řízení. Důkazy implementace mohou zahrnovat upozornění OT IDS, logy firewallu, korelaci SIEM, profily výchozího provozu, tikety anomálií a záznamy reakce.

Jak vypadají kvalitní důkazy OT podle NIS2

Balíček důkazů OT podle NIS2 musí být dostatečně praktický pro inženýry a dostatečně strukturovaný pro auditory.

U segmentace zahrňte schválenou architekturu, diagramy zón a komunikačních kanálů, exporty pravidel firewallu, záznamy změn, pravidelné přezkumy pravidel, záznamy výjimek a monitorovací upozornění.

U přístupu dodavatelů zahrňte posouzení kritičnosti dodavatele, smluvní doložky, schválený postup přístupu, pojmenované účty, důkazy MFA, logy přístupu, záznamy relací, pravidelný přezkum přístupových práv a záznamy o odebrání přístupů při ukončení spolupráce.

U řízení zranitelností zahrňte evidenci, zdroje bezpečnostních oznámení, výstupy pasivního zjišťování aktiv, tikety zranitelností, plány záplatování, kompenzační opatření, přijetí rizika a důkazy uzavření.

U reakce na incidenty zahrňte postupy reakce, eskalační kontakty, rozhodovací strom hlášení NIS2, výsledky simulačních cvičení typu tabletop, incidentní tikety, návrhy oznámení orgánům, pravidla nakládání s důkazy a získané poznatky.

U kontinuity zahrňte strategii zálohování OT, offline nebo chráněné zálohy, výsledky testů obnovy, seznam kritických náhradních dílů, manuální provozní postupy, priority obnovy a plány krizové komunikace.

U řízení zahrňte schválení řídicími orgány nebo vedením, přiřazení rolí, záznamy o školení, výsledky interního auditu, KPI, zápisy z přezkumu rizik a rozhodnutí z přezkoumání vedením.

Tento model důkazů je v souladu s ISO/IEC 27001:2022, protože podporuje ošetření rizik, dokumentované informace, hodnocení výkonnosti a neustálé zlepšování. Je v souladu s NIS2, protože dokládá vhodná a přiměřená opatření. Je v souladu s IEC 62443, protože jej lze dohledat k architektuře OT a inženýrským opatřením.

Přeměňte svůj program zabezpečení OT na auditovatelnou připravenost podle NIS2

Pokud vaše prostředí OT podporuje kritickou nebo regulovanou službu, čekat na regulační orgán, zákazníka nebo incident, který odhalí mezery, je nesprávná strategie.

Začněte jedním případem použití s vysokým dopadem: vzdálený přístup dodavatelů do kritické zóny OT, zvládání zranitelností nepodporovaných průmyslových aktiv nebo segmentace mezi podnikovým IT a OT. Vytvořte rizikový scénář, namapujte jej na článek 21 NIS2, vyberte opatření ISO/IEC 27002:2022, převeďte je do implementačních vzorců IEC 62443 a shromážděte důkazy.

Clarysec vám může tuto práci urychlit pomocí Zenith Blueprint, Zenith Controls, Politiky zabezpečení IoT / OT, Politiky zabezpečení internetu věcí (IoT) / provozních technologií (OT) pro malé a střední podniky a Bezpečnostní politiky pro dodavatele a poskytovatele služeb třetích stran pro malé a střední podniky.

Váš další krok: vyberte jednu službu OT, namapujte její aktiva a závislosti a ještě tento týden vytvořte důkazní linii od rizika k opatření. Pokud chcete strukturovanou cestu implementace, třicetikrokový plán a sada nástrojů Clarysec pro compliance napříč předpisy mohou tuto první linii proměnit v kompletní program zabezpečení OT podle NIS2.