NIS2 OT-biztonság: ISO 27001 és IEC 62443 megfeleltetési térkép

Hétfőn 02:17-kor egy vízkezelő létesítmény operátora riasztást kap egy adagolórendszertől. A vegyszeradagolás még a biztonsági határértékeken belül van, de az egyik PLC rendellenes parancsokat jelez, a mérnöki munkaállomáson sikertelen bejelentkezések láthatók egy beszállítói VPN-fiókból, az ügyeletes SOC-elemző pedig olyan kérdést tesz fel, amelyre nyomás alatt senki sem szeretne válaszolni.

Ez IT-incidens, OT-incidens, biztonsági esemény, vagy a NIS2 szerint bejelentésköteles jelentős incidens?

Az üzemben vannak tűzfalak. Van ISO-dokumentáció. Van beszállítói táblázat. Még incidensreagálási terv is van. A tervet azonban e-mail-fiókok kompromittálódására és felhőszolgáltatási kiesésekre írták, nem olyan örökölt vezérlőre, amelyet termelés közben nem lehet javítani, nem olyan beszállítóra, akinek távoli hozzáférés kell a szolgáltatás helyreállításához, és nem olyan szabályozó hatóságra, amely a NIS2 jelentéstételi határidőin belül bizonyítékokat vár.

Ugyanez a probléma az igazgatósági tárgyalókban is megjelenik. Egy regionális energiaszolgáltató információbiztonsági vezetője rendelkezhet ISO/IEC 27001:2022 szerint tanúsított információbiztonsági irányítási rendszerrel a vállalati IT-re, miközben az operatív technológiai környezet továbbra is PLC-k, RTU-k, HMI-k, historian rendszerek, mérnöki munkaállomások, ipari kapcsolók és beszállítói hozzáférési útvonalak nehezen áttekinthető együttese. A vezérigazgató kérdése egyszerű: „Lefedettek vagyunk? Ezt bizonyítani is tudjuk?”

Sok alapvető és fontos szervezetnél az őszinte válasz kellemetlen. Részben lefedettek. Részben tudják bizonyítani. A NIS2 szerinti OT-biztonság azonban többet igényel, mint általános IT-megfelelést.

Egységes működési modellre van szükség, amely összekapcsolja az ISO/IEC 27001:2022 szerinti irányítást, az ISO/IEC 27002:2022 kontrollnyelvezetét, az IEC 62443 ipari mérnöki gyakorlatait, a NIS2 Article 21 szerinti kiberbiztonsági kockázatkezelési intézkedéseket és a NIS2 Article 23 szerinti incidensbejelentési bizonyítékokat.

Ezt a hidat építi fel ez az útmutató.

Miért különbözik a NIS2 szerinti OT-biztonság a szokásos IT-megfeleléstől

A NIS2 számos olyan köz- és magánszervezetre vonatkozik, amely az EU-ban a hatálya alá tartozó szolgáltatásokat nyújt, beleértve az alapvető és fontos szervezeteket többek között az energia, közlekedés, banki szolgáltatások, pénzügyi piaci infrastruktúrák, egészségügy, ivóvíz, szennyvíz, digitális infrastruktúra, IKT-szolgáltatásmenedzsment, közigazgatás, űrágazat, postai szolgáltatások, hulladékgazdálkodás, gyártás, vegyipar, élelmiszeripar, digitális szolgáltatók és kutatás területén.

Az irányelv megfelelő és arányos műszaki, üzemeltetési és szervezeti intézkedéseket ír elő a kiberkockázatok kezelésére, az incidensek hatásának megelőzésére vagy minimalizálására, valamint a szolgáltatások folytonosságának védelmére. Az Article 21 minden veszélyforrást figyelembe vevő megközelítést tartalmaz: kockázatelemzés, biztonsági szabályzatok, incidenskezelés, üzletmenet-folytonosság, válságkezelés, ellátási lánc biztonsága, biztonságos beszerzés és karbantartás, sérülékenységkezelés és közzététel, eredményességértékelés, kiberhigiénia, képzés, kriptográfia, HR-biztonság, hozzáférés-szabályozás, eszközkezelés, MFA vagy folyamatos hitelesítés, biztonságos kommunikáció és adott esetben vészhelyzeti kommunikáció.

Ezek a követelmények ismerősen hangzanak egy ISO/IEC 27001:2022 szerint működő csapat számára. OT-környezetben azonban mindegyik másként viselkedik.

Egy webszerver sérülékenysége gyakran napokon belül javítható. Egy turbina vezérlőjének sérülékenysége beszállítói ellenőrzést, karbantartási ablakot, biztonsági felülvizsgálatot és tartalék üzemeltetési eljárásokat igényelhet. Egy laptop újratelepíthető. Egy termelési HMI örökölt operációs rendszertől függhet, mert az ipari alkalmazást még nem tanúsították újabb platformra. Egy SOC-forgatókönyv azt mondhatja: „izoláld a hosztot”, miközben az OT-mérnök így válaszol: „addig nem, amíg nem tudjuk, hogy az izolálás érinti-e a nyomásszabályozást”.

A különbség nem kizárólag műszaki. Az IT jellemzően a bizalmasságot, a sértetlenséget és a rendelkezésre állást priorizálja. Az OT a rendelkezésre állást, a folyamatok sértetlenségét és a munkabiztonságot helyezi előtérbe. Egy olyan biztonsági kontroll, amely késleltetést okoz, újraindítást igényel vagy megszakít egy fizikai folyamatot, mérnöki jóváhagyás nélkül elfogadhatatlan lehet.

A NIS2 nem mentesíti az OT-t a kiberbiztonsági kockázatkezelés alól. Elvárja, hogy a szervezet bizonyítsa: a kontrollok a kockázathoz mérten megfelelőek, és arányosak az üzemeltetési valósággal.

A kontrollréteg: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 és IEC 62443

Egy igazolható NIS2 OT-biztonsági program többrétegű kontrollrendszerrel kezdődik.

Az ISO/IEC 27001:2022 biztosítja az irányítási rendszert. Megköveteli, hogy a szervezet meghatározza a kontextust, az érdekelt feleket, a szabályozási kötelezettségeket, az IBIR alkalmazási területét, az interfészeket és a függőségeket. Emellett vezetői felelősséget, információbiztonsági szabályzatot, kockázatértékelést, kockázatkezelést, alkalmazhatósági nyilatkozatot, dokumentált információkat, belső auditot, vezetőségi átvizsgálást és folyamatos fejlesztést ír elő.

Az ISO/IEC 27002:2022 biztosítja a kontrollszókészletet. OT-környezetben a legfontosabb kontrollok gyakran a beszállítói biztonságot, az IKT-ellátási lánc kockázatkezelését, az incidens-tervezést, az üzletmenet-folytonossági felkészültséget, a jogi és szerződéses követelményeket, az eszközkezelést, a hozzáférés-szabályozást, a sérülékenységkezelést, a biztonsági mentéseket, a naplózást, a felügyeletet, a hálózatbiztonságot és a hálózatok elkülönítését fedik le.

Az IEC 62443 biztosítja az ipari biztonságmérnöki modellt. Segít az irányítási rendszer követelményeit OT-gyakorlatokká alakítani, például zónákra, kommunikációs csatornákra, biztonsági szintekre, eszközfelelősi kötelezettségekre, rendszerintegrátori felelősségekre, termékbeszállítói elvárásokra, távoli hozzáférési korlátozásokra, minimálisan szükséges funkcionalitásra, fiókkezelésre, rendszerkeményítésre és életciklus-kontrollokra.

A Clarysec azért használja ezt a rétegzést, mert két gyakori hibát kerül el vele. Először megakadályozza, hogy az ISO bevezetése túl általános maradjon az OT számára. Másodszor megakadályozza, hogy az IEC 62443 szerinti mérnöki munka elszakadjon az igazgatósági elszámoltathatóságtól, a NIS2 szerinti jelentéstételi kötelezettségektől és az auditbizonyítékoktól.

A Clarysec IoT / OT biztonsági szabályzata közvetlenül kimondja ezt a kapcsolatot:

Annak biztosítása, hogy minden bevezetés összhangban legyen az ISO/IEC 27001 kontrollokkal és az alkalmazandó ágazatspecifikus iránymutatásokkal (pl. IEC 62443, ISO 27019, NIST SP 800-82).

Ez a mondat fontos. A szabályzat nem pusztán eszközkeményítési ellenőrzőlista. Összekapcsolja az ISO szerinti irányítást, az OT ágazati iránymutatásokat és az üzemeltetési biztonságot.

Kezdés a hatállyal: melyik OT-szolgáltatást kell védeni?

A kontrollok megfeleltetése előtt üzleti és szabályozási nyelven kell meghatározni az OT-szolgáltatást.

Egy üzemvezető mondhatja azt, hogy „a csomagolósort üzemeltetjük”. Egy NIS2-értékelésben ennek így kell megjelennie: „Ez a termelési folyamat alapvető vagy fontos szolgáltatást támogat, és PLC-ktől, HMI-ktől, mérnöki munkaállomásoktól, historian rendszerektől, ipari kapcsolóktól, távoli beszállítói hozzáféréstől, karbantartó vállalkozótól, felhőalapú analitikai adatfolyamtól és vállalati identitásszolgáltatástól függ.”

Az ISO/IEC 27001:2022 4.1–4.4 pontjai hasznosak, mert rákényszerítik a szervezetet a belső és külső tényezők, az érdekelt felek, a jogi és szerződéses követelmények, az IBIR határai, az interfészek és a függőségek azonosítására. A NIS2 OT-biztonság szempontjából ez nemcsak a központi irodai hálózat feltérképezését jelenti, hanem azoknak az ipari rendszereknek és szolgáltatási függőségeknek a feltárását is, amelyek hatással vannak a folytonosságra, a biztonságra és a szabályozott szolgáltatásnyújtásra.

A NIST CSF 2.0 ugyanezt a logikát erősíti. A GOVERN funkció megköveteli a küldetés, az érdekelt felek, a függőségek, a jogi és szabályozási kötelezettségek, a kritikus szolgáltatások és a szervezet által igénybe vett szolgáltatások megértését. A szervezeti profilok gyakorlati módszert adnak a jelenlegi állapot körülhatárolására, a célállapot meghatározására, a hiányosságok elemzésére és egy priorizált cselekvési terv elkészítésére.

OT-környezet esetén a Clarysec jellemzően öt kérdéssel kezd:

1. Mely szabályozott vagy kritikus szolgáltatást támogatja ez az OT-környezet?
2. Mely OT-eszközök, hálózatok, adatáramlások és harmadik felek szükségesek ehhez a szolgáltatáshoz?
3. Mely biztonsági, rendelkezésre állási és üzemeltetési korlátok érintik a biztonsági kontrollokat?
4. Mely jogi, szerződéses és ágazati kötelezettségek vonatkoznak rá, beleértve adott esetben a NIS2-t, a GDPR-t, a DORA-t, az ügyfélszerződéseket és a nemzeti szabályokat?
5. A környezet mely részei tartoznak az IBIR hatálya alá, és melyek azok a külső függőségek, amelyek beszállítói kontrollokat igényelnek?

Sok NIS2-program itt bukik el. A hatályt a vállalati IT köré rajzolják, mert azt könnyebb leltározni. Az auditorokat és a szabályozó hatóságokat nem fogja meggyőzni, ha a legkritikusabb szolgáltatási függőség csupán egy homályos „gyári hálózat” sorban jelenik meg.

Gyakorlati NIS2 OT-kontrolltérkép

Az alábbi táblázat bemutatja, hogyan alakíthatók a NIS2 Article 21 témái ISO/IEC 27001:2022, ISO/IEC 27002:2022 és IEC 62443 szerinti bizonyítékokká. Nem helyettesíti a formális kockázatértékelést, de gyakorlati kiindulópontot ad a CISO-k, OT-vezetők és megfelelési csapatok számára.

Ez a térkép szándékosan bizonyítékközpontú. A NIS2 alatt nem elég azt mondani, hogy „van szegmentálásunk”. Meg kell mutatni, miért megfelelő a szegmentálás, hogyan valósították meg, hogyan hagyják jóvá a kivételeket, és hogyan csökkenti a kialakítás a szabályozott szolgáltatásra gyakorolt hatást.

Szegmentálás: az első OT-kontroll, amelyet az auditorok tesztelni fognak

Ha a 02:17-es incidens során egy támadó egy irodai laptopról egy mérnöki munkaállomásra mozdult volna tovább, az első auditkérdés nyilvánvaló lenne: miért létezhetett ilyen útvonal?

Az IoT / OT biztonsági szabályzat egyértelmű:

Az OT-rendszereknek a vállalati IT-tól és az internet felől elérhető rendszerektől elkülönített, dedikált hálózatokon kell működniük.

Kisebb környezetek esetén az Internet of Things (IoT) / Operational Technology (OT) biztonsági szabályzat - SME gyakorlati alapkövetelményt ad:

Minden Internet of Things (IoT) és Operational Technology (OT) eszközt külön Wi-Fi- vagy VLAN-hálózatra kell helyezni.

Egy érett kritikusinfrastruktúra-üzemeltetőnél a szegmentálást OT-zónák és kommunikációs csatornák köré kell tervezni. A vállalati felhasználók nem férhetnek hozzá közvetlenül a PLC-hálózatokhoz. A beszállítói kapcsolatoknak kontrollált hozzáférési zónákban kell végződniük. A historian replikációnak jóváhagyott útvonalakat kell használnia. A biztonsági rendszereket a kockázati és mérnöki követelmények szerint kell elkülöníteni. A vezeték nélküli OT-hálózatokat indokolni, keményíteni és felügyelni kell.

A Zenith Blueprint: Egy auditor 30 lépéses ütemterve a Kontrollok működésben szakasz 20. lépésében ismerteti az ISO/IEC 27002:2022 hálózatbiztonsága mögötti elvet:

Az ipari vezérlőrendszereket el kell különíteni az irodai forgalomtól.

Arra is figyelmeztet, hogy a hálózatbiztonság biztonságos architektúrát, szegmentálást, hozzáférés-szabályozást, továbbított adatok titkosítását, felügyeletet és többrétegű védelmet igényel.

A Zenith Controls: A keresztmegfelelési útmutató az ISO/IEC 27002:2022 8.22 kontrollját, a hálózatok elkülönítését, megelőző kontrollként kezeli, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, összhangban áll a Protect kiberbiztonsági koncepcióval, működési képességeként a rendszer- és hálózatbiztonsággal, biztonsági területeként pedig a védelemmel.

Ez a besorolás hasznos a NIS2 bizonyítékaihoz, mert a szegmentálás nem dekoratív diagram. Megelőző kontroll, amelynek célja a hatókör csökkentése és az alapvető szolgáltatás folytonosságának megőrzése.

Sérülékenységkezelés, amikor az OT-rendszerek nem javíthatók egyszerűen

A NIS2 előírja a hálózati és információs rendszerek biztonságos beszerzését, fejlesztését és karbantartását, beleértve a sérülékenységek kezelését és közzétételét. IT-környezetben a sérülékenységkezelés gyakran azt jelenti: vizsgálat, priorizálás, javítás és ellenőrzés. Az OT további korlátokat hoz.

Egy kritikus HMI csak tervezett leállás során lehet javítható. Egy PLC firmware-frissítés beszállítói közreműködést igényelhet. Egy biztonsági tanúsítással rendelkező rendszer elveszítheti a tanúsítását, ha nem megfelelően módosítják. Egyes örökölt eszközökhöz pedig már egyáltalán nincs beszállítói támogatás.

A Zenith Blueprint Kontrollok működésben szakaszának 19. lépése a technikai sérülékenységekhez megfelelő auditlogikát ad:

Azoknál a rendszereknél, amelyeket nem lehet azonnal javítani – például örökölt szoftver vagy leállási korlátozások miatt –, kompenzáló kontrollokat kell bevezetni. Ez magában foglalhatja a rendszer tűzfal mögötti elkülönítését, a hozzáférés korlátozását vagy a felügyelet fokozását. Minden esetben rögzíteni kell és formálisan el kell fogadni a maradványkockázatot, bizonyítva, hogy a problémát nem felejtették el.

Az SME szabályzati alapkövetelmény hasonlóan gyakorlati:

A nyilvántartást negyedévente felül kell vizsgálni az elavult, nem támogatott vagy nem javított eszközök azonosítása érdekében.

A Zenith Controls az ISO/IEC 27002:2022 8.8 kontrollját, a technikai sérülékenységek kezelését, megelőző kontrollként képezi le, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, összhangban áll az Identify és Protect területekkel, működési képességeként a fenyegetés- és sérülékenységkezeléssel a Governance, Ecosystem, Protection és Defense domainekben.

Egy erős OT-sérülékenységi dokumentáció tartalmazza:

• eszközazonosító, tulajdonos, zóna és kritikusság;
• sérülékenységi forrás, például beszállítói tájékoztató, vizsgálóeszköz, integrátori értesítés vagy fenyegetettségi információ;
• biztonsági és rendelkezésre állási korlátok;
• javítás megvalósíthatósága és tervezett karbantartási ablak;
• kompenzáló kontrollok, például elkülönítés, hozzáférés-vezérlési listák, letiltott szolgáltatások vagy fokozott felügyelet;
• kockázatgazdai jóváhagyás és maradványkockázat elfogadása;
• ellenőrzési bizonyíték a helyesbítő intézkedés vagy a kompenzáló kontroll bevezetése után.

Ez a „nem tudjuk javítani” állítást kifogásból auditálható kockázatkezeléssé alakítja.

Távoli beszállítói hozzáférés: a NIS2 és az IEC 62443 kritikus pontja

A legtöbb OT-incidensnek valahol van harmadik félhez kapcsolódó dimenziója. Egy beszállítói fiók. Egy integrátori laptop. Egy távoli karbantartási eszköz. Egy megosztott hitelesítő adat. Egy tűzfalkivétel, amely három éve még ideiglenes volt.

A NIS2 Article 21 kifejezetten tartalmazza az ellátási lánc biztonságát, a beszállítóspecifikus sérülékenységeket, a beszállítók kiberbiztonsági gyakorlatait és a biztonságos fejlesztési eljárásokat. A NIST CSF 2.0 szintén részletesen kezeli ezt a témát a beszállítói kritikusság, a szerződéses követelmények, a kellő gondosság, a folyamatos felügyelet, az incidenskoordináció és a kilépési rendelkezések révén.

A Clarysec Harmadik fél és beszállítói biztonsági szabályzat - SME egyszerűen fogalmazza meg az elvet:

A beszállítók csak a feladatuk ellátásához szükséges minimális rendszerekhez és adatokhoz kaphatnak hozzáférést.

OT-környezetben a minimális hozzáférés többet jelent, mint szerepköralapú hozzáférést egy alkalmazásban. A beszállítói hozzáférésnek:

• előzetesen jóváhagyottnak kell lennie meghatározott karbantartási célra;
• időkorlátosnak és alapértelmezetten letiltottnak kell lennie;
• megfelelő esetben MFA-val vagy folyamatos hitelesítéssel kell védettnek lennie;
• biztonságos ugrószerveren vagy kontrollált távoli hozzáférési platformon keresztül kell haladnia;
• az érintett OT-zónára vagy eszközre kell korlátozódnia;
• naplózottnak, felügyeltnek és magas kockázatú hozzáférés esetén munkamenet-rögzítettnek kell lennie;
• lezárás után felül kell vizsgálni;
• szerződéses biztonsági és incidensbejelentési kötelezettségekkel kell lefedettnek lennie.

A vállalati IoT / OT biztonsági szabályzat külön távoli hozzáférési követelményt tartalmaz:

A távoli hozzáférésnek (menedzsment vagy beszállítói kiszolgálás céljából) a következőknek kell megfelelnie:

Ez a záradék rögzíti az irányítási pontot, míg a részletes követelményeket hozzáférési eljárásokban, beszállítói megállapodásokban, technikai konfigurációban és felügyeleti munkafolyamatokban kell végrehajtani.

A Zenith Controls az ISO/IEC 27002:2022 5.21 kontrollját, az információbiztonság kezelését az IKT-ellátási láncban, megelőző kontrollként sorolja be, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, összhangban áll az Identify koncepcióval, működési képességeként a beszállítói kapcsolatok biztonságával, domainekként pedig a Governance, Ecosystem és Protection területekkel.

OT esetén ez a megfeleltetés segít megmagyarázni, miért tartoznak a távoli hozzáférés bizonyítékai egyszerre a beszállítói kockázat, az identitásirányítás, a hálózatbiztonság, az incidensreagálás és a folytonossági dokumentáció körébe.

Incidensreagálás: a NIS2 órája találkozik az irányítóteremmel

Térjünk vissza a 02:17-es riasztáshoz. A szervezetnek el kell döntenie, hogy az esemény jelentős-e a NIS2 szerint. Az Article 23 indokolatlan késedelem nélküli értesítést ír elő a szolgáltatásnyújtást érintő jelentős incidensekről. A folyamat része az észleléstől számított 24 órán belüli korai figyelmeztetés, a 72 órán belüli incidensbejelentés, kérés esetén köztes frissítések, valamint az incidensbejelentéstől számított legfeljebb egy hónapon belüli zárójelentés, vagy folyamatban lévő incidens esetén előrehaladási jelentés.

OT-környezetben az incidensreagálásnak olyan kérdésekre kell választ adnia, amelyeket az IT-forgatókönyvek gyakran figyelmen kívül hagynak:

• El lehet-e különíteni az érintett eszközt biztonsági kockázat létrehozása nélkül?
• Ki jogosult a termelés leállítására vagy kézi üzemmódra kapcsolására?
• Mely naplók illékonyak és igényelnek azonnali megőrzést?
• Mely beszállítót vagy integrátort kell értesíteni?
• Az esemény rosszindulatú, véletlen, környezeti eredetű vagy hibás konfiguráció okozta?
• Lehet-e határokon átnyúló hatás vagy hatás a szolgáltatást igénybe vevőkre?
• Érintett-e személyes adat, például belépőkártya-napló, CCTV, munkavállalói adat vagy ügyfélszolgálati nyilvántartás?

Az SME OT-szabályzat egyszerű anomália-eszkalációs szabályt ad:

Minden anomáliát haladéktalanul jelenteni kell az ügyvezetőnek további intézkedés céljából.

Biztonságtudatos elszigetelési elvet is tartalmaz:

Az eszközt azonnal le kell választani a hálózatról, amennyiben ez biztonságosan megtehető.

Az utolsó öt szó kritikus. Az OT-reagálás nem másolhatja vakon az IT elhatárolási lépéseket. Az „amennyiben ez biztonságosan megtehető” elvet helyreállítási forgatókönyvekben, eszkalációs mátrixokban, képzésekben és asztali gyakorlatokban is tükrözni kell.

A NIST CSF 2.0 jól illeszkedik ide. Respond és Recover eredményei lefedik a triage-t, a kategorizálást, az eszkalációt, a gyökérok-elemzést, a bizonyíték sértetlenségét, az érdekelt felek értesítését, az elszigetelést, az eltávolítást, a helyreállítást, a biztonsági mentések sértetlenségi ellenőrzéseit és a helyreállítási kommunikációt.

Kockázat–kontroll bizonyítéklánc felépítése

A töredezett megfelelés elkerülésének gyakorlati módja, ha egyetlen bizonyítékláncot építünk fel a kockázattól a szabályozáson és kontrollon át a bizonyítékig.

Forgatókönyv: egy távoli kompresszorbeszállítónak hozzáférésre van szüksége az OT-hálózat egyik mérnöki munkaállomásához. A munkaállomás módosítani tudja a PLC-logikát. A beszállítói fiók mindig engedélyezett, több beszállítói mérnök használja közösen, és csak jelszó védi. A munkaállomáson olyan szoftver fut, amelyet a következő karbantartási leállásig nem lehet frissíteni.

A kockázati forgatókönyvet így kell rögzíteni a kockázati nyilvántartásban:

„Jogosulatlan vagy kompromittálódott beszállítói távoli hozzáférés az OT mérnöki munkaállomáshoz jogosulatlan PLC-logikamódosításhoz, termelési zavarhoz, biztonsági hatáshoz és NIS2 szerint bejelentésköteles szolgáltatáskimaradáshoz vezethet.”

Ezután meg kell feleltetni a kontrollokat és kötelezettségeket.

A kezelési tervnek le kell tiltania az állandó beszállítói hozzáférést, névre szóló beszállítói identitásokat kell előírnia, ki kell kényszerítenie az MFA-t, kontrollált ugrószerveren keresztül kell irányítania a hozzáférést, a mérnöki munkaállomásra kell korlátoznia azt, karbantartási jegy jóváhagyását kell megkövetelnie, rögzítenie kell az emelt jogosultságú munkameneteket, felügyelnie kell a parancsokat és a rendellenes forgalmat, sérülékenységi kivételként kell dokumentálnia a nem javított munkaállomást, és tesztelnie kell az incidensreagálást gyanús beszállítói tevékenység esetére.

A Zenith Blueprint Kockázatkezelés szakaszának 13. lépése adja meg a SoA visszakövethetőségi logikáját:

Kereszthivatkozások a szabályozásokra: ha bizonyos kontrollokat kifejezetten a GDPR, a NIS2 vagy a DORA szerinti megfelelés érdekében vezettek be, ezt rögzítheti akár a kockázati nyilvántartásban (a kockázati hatás indokolásának részeként), akár a SoA megjegyzéseiben.

A gyakorlati tanulság egyszerű. Ne tartsa külön silókban a NIS2, az ISO és az OT-mérnöki bizonyítékokat. A kockázati nyilvántartásban és a SoA-ban adjon hozzá oszlopokat a NIS2 Article 21 témájához, az ISO/IEC 27002:2022 kontrollhoz, az IEC 62443 követelménycsaládhoz, a bizonyítékgazdához és az auditstátuszhoz.

Hol illeszkedik a GDPR és a DORA az OT-biztonságba?

Az OT-biztonság nem mindig csak gépekről szól. A kritikus infrastruktúra környezetei gyakran kezelnek személyes adatokat CCTV-n, hozzáférés-szabályozási rendszereken, belépőkártya-naplókon, munkavédelmi rendszereken, karbantartási jegyeken, járműkövetésen, látogatói rendszereken és ügyfélszolgálati platformokon keresztül.

A GDPR előírja, hogy a személyes adatokat jogszerűen, tisztességesen és átláthatóan kell kezelni, meghatározott célokra kell gyűjteni, a szükséges mértékre kell korlátozni, pontosan kell tartani, csak a szükséges ideig kell megőrizni, és megfelelő technikai és szervezési intézkedésekkel kell védeni. Elszámoltathatóságot is előír, vagyis az adatkezelőnek képesnek kell lennie a megfelelés bizonyítására.

OT esetén ez azt jelenti, hogy a hozzáférési naplók és a felügyeleti nyilvántartások nem válhatnak kontrollálatlan megfigyelési adattárakká. A megőrzést, a hozzáférési jogosultságokat, a célhoz kötöttséget és az adatvédelmi incidens értékelését be kell építeni a naplózásba és a felügyeletbe.

A DORA akkor lehet alkalmazandó, ha pénzügyi szervezetek érintettek, vagy ha egy IKT harmadik fél szolgáltató a pénzügyi szektor operatív rezilienciáját támogatja. A DORA lefedi az IKT-kockázatkezelést, az incidensjelentést, a rezilienciatesztelést és az IKT harmadik fél kockázatát. Azoknál a pénzügyi szervezeteknél, amelyek a NIS2 átültetési szabályai szerint is alapvető vagy fontos szervezetek, a DORA ágazatspecifikus rendszerként működhet az átfedő kötelezettségekre, miközben a NIS2 hatóságokkal való koordináció továbbra is releváns lehet.

Ugyanazok a bizonyítékképzési fegyelmi szabályok alkalmazandók: eszközazonosítás, védelem, észlelés, folytonosság, biztonsági mentés, harmadik fél kockázat, tesztelés, képzés és vezetői felügyelet.

Auditnézőpont: egy kontroll, több bizonyossági perspektíva

Egy erős NIS2 OT-biztonsági bevezetésnek több auditperspektívát is ki kell állnia.

Ezért kezeli a Clarysec a Zenith Controls megoldást keresztmegfelelési iránytűként. Kontrollattribútumai segítenek megmagyarázni a hivatalos ISO/IEC 27002:2022 kontrollok célját, miközben a megfeleltetési megközelítés összekapcsolja ezeket a kontrollokat a NIS2-vel, a NIST CSF-fel, a beszállítói irányítással, a folytonossággal és az auditbizonyítékokkal.

Gyakori NIS2 OT-bevezetési buktatók

A leggyakoribb OT-biztonsági hibákat ritkán a dokumentumok hiánya okozza. Inkább az okozza őket, hogy a dokumentumok nem tükrözik az üzem valóságát.

1. buktató: az IT birtokolja a NIS2-programot, de a kockázat az OT-nál van. A műveleteket, a mérnökséget, a munkabiztonságot és a karbantartást be kell vonni.

2. buktató: az eszköznyilvántartás megáll a szervereknél. Egy OT-nyilvántartásnak tartalmaznia kell a PLC-ket, RTU-kat, HMI-ket, historian rendszereket, mérnöki munkaállomásokat, ipari kapcsolókat, érzékelőket, átjárókat, távoli hozzáférési eszközöket és beszállító által kezelt komponenseket.

3. buktató: a szegmentálás létezik a diagramon, de nem a tűzfalszabályokban. Az auditorok kérni fogják a kikényszerítés, a változáskezelés és a felügyelet bizonyítékait.

4. buktató: a sérülékenységi kivételek informálisak. Az örökölt korlátok csak akkor elfogadhatók, ha dokumentáltak, jóváhagyottak, felügyeltek és rendszeresen felülvizsgáltak.

5. buktató: a beszállítói hozzáférést kizárólag beszállítói kérdésként kezelik. Ez egyben hozzáférés-szabályozási, naplózási, felügyeleti, hálózatbiztonsági, incidensreagálási és folytonossági kérdés is.

6. buktató: az incidensreagálás figyelmen kívül hagyja a biztonságot. Az OT-forgatókönyveknek meg kell határozniuk, ki különíthet el eszközöket, állíthat le folyamatokat, kapcsolhat üzemmódot vagy léphet kapcsolatba a szabályozó hatóságokkal.

7. buktató: a NIS2 jelentéstételt nem gyakorolják. A 24 órás és 72 órás döntési folyamatot valós esemény előtt tesztelni kell.

A Clarysec bevezetési útja az igazgatósági elszámoltathatóságtól az OT-bizonyítékokig

Egy gyakorlati NIS2 OT-biztonsági bevezetés az alábbi sorrendet követheti:

1. A NIS2-hatály, a szervezeti besorolás és a szolgáltatáskritikusság megerősítése.
2. Az OT-hatály meghatározása az IBIR-en belül, beleértve az interfészeket és függőségeket.
3. OT-eszköz- és adatáramlási nyilvántartás kialakítása.
4. Jogi, szerződéses, biztonsági, adatvédelmi és ágazati kötelezettségek azonosítása.
5. OT-specifikus kockázatértékelési workshopok lebonyolítása a mérnökség, üzemeltetés, IT, SOC, beszerzés és vezetőség bevonásával.
6. A kockázatkezelés megfeleltetése ISO/IEC 27002:2022 kontrollokhoz, NIS2-témákhoz és IEC 62443 bevezetési mintákhoz.
7. Az alkalmazhatósági nyilatkozat frissítése OT-indokolással és bizonyítékgazdákkal.
8. Prioritásos kontrollok bevezetése: szegmentálás, beszállítói hozzáférés, sérülékenységkezelés, felügyelet, biztonsági mentések és incidensreagálás.
9. Szabályzatok és eljárások frissítése, beleértve az OT-biztonságot, beszállítói biztonságot, távoli hozzáférést, incidensreagálást és üzletmenet-folytonosságot.
10. Asztali és technikai ellenőrzési gyakorlatok végrehajtása.
11. Auditcsomagok előkészítése NIS2, ISO/IEC 27001:2022, ügyfélbizonyosság és belső irányítás céljára.
12. A megállapítások beépítése a vezetőségi átvizsgálásba és a folyamatos fejlesztésbe.

Ez tükrözi a Zenith Blueprint működési modelljét, különösen a 13. lépést a kockázatkezeléshez és a SoA visszakövethetőségéhez, a 14. lépést a szabályzatfejlesztéshez és szabályozási kereszthivatkozásokhoz, a 19. lépést a sérülékenységkezeléshez és a 20. lépést a hálózatbiztonsághoz.

Ugyanez a megközelítés a Clarysec szabályzatait használja arra, hogy a keretrendszerek nyelvezetét operatív szabályokká alakítsa. A vállalati IoT / OT biztonsági szabályzat a bevezetés előtt biztonsági architektúra-felülvizsgálatot ír elő:

Minden új IoT/OT-eszköznek a bevezetés előtt biztonsági architektúra-felülvizsgálaton kell átesnie. Ennek a felülvizsgálatnak ellenőriznie kell:

A szabályzat azt is kimondja:

Az IoT/OT-hálózatokon belüli és azok közötti teljes forgalmat folyamatosan felügyelni kell a következők használatával:

Ezek a záradékok irányítási horgonyokat hoznak létre. A bevezetési bizonyítékok közé tartozhatnak OT IDS-riasztások, tűzfalnaplók, SIEM-korreláció, alapállapoti forgalmi profilok, anomáliajegyek és reagálási bejegyzések.

Milyen a jó NIS2 OT-bizonyíték?

Egy NIS2 OT-bizonyítékcsomagnak elég gyakorlatiasnak kell lennie a mérnökök számára, és elég strukturáltnak az auditorok számára.

Szegmentálás esetén tartalmazzon jóváhagyott architektúrát, zóna- és kommunikációs csatorna diagramokat, tűzfalszabály-exportokat, változásbejegyzéseket, időszakos szabályfelülvizsgálatokat, kivételbejegyzéseket és felügyeleti riasztásokat.

Beszállítói hozzáférés esetén tartalmazzon beszállítói kritikussági értékelést, szerződéses záradékokat, jóváhagyott hozzáférési eljárást, névre szóló fiókokat, MFA-bizonyítékokat, hozzáférési naplókat, munkamenet-felvételeket, időszakos hozzáférés-felülvizsgálatot és kiléptetési nyilvántartásokat.

Sérülékenységkezelés esetén tartalmazzon nyilvántartást, tájékoztató forrásokat, passzív feltárási kimeneteket, sérülékenységi jegyeket, javítási terveket, kompenzáló kontrollokat, kockázatelfogadást és lezárási bizonyítékokat.

Incidensreagálás esetén tartalmazzon forgatókönyveket, eszkalációs kapcsolattartókat, NIS2 jelentéstételi döntési fát, asztali gyakorlatok eredményeit, incidensjegyeket, hatósági értesítési tervezeteket, bizonyítékkezelési szabályokat és tanulságokat.

Folytonosság esetén tartalmazzon OT biztonsági mentési stratégiát, offline vagy védett biztonsági mentéseket, helyreállítási teszteredményeket, kritikus pótalkatrész-listát, kézi üzemeltetési eljárásokat, helyreállítási prioritásokat és válságkommunikációs terveket.

Irányítás esetén tartalmazzon igazgatósági vagy vezetői jóváhagyást, szerepkör-hozzárendeléseket, képzési nyilvántartásokat, belső audit eredményeket, KPI-ket, kockázati felülvizsgálati jegyzőkönyveket és vezetőségi átvizsgálási döntéseket.

Ez a bizonyítékmodell összhangban áll az ISO/IEC 27001:2022-vel, mert támogatja a kockázatkezelést, a dokumentált információkat, a teljesítményértékelést és a folyamatos fejlesztést. Összhangban áll a NIS2-vel, mert igazolja a megfelelő és arányos intézkedéseket. Összhangban áll az IEC 62443-mal, mert visszakövethető az OT-architektúrához és a mérnöki kontrollokhoz.

Alakítsa OT-biztonsági programját auditálható NIS2-felkészültséggé

Ha az OT-környezete kritikus vagy szabályozott szolgáltatást támogat, rossz stratégia arra várni, hogy egy szabályozó hatóság, ügyfél vagy incidens tárja fel a hiányosságokat.

Kezdjen egy nagy hatású használati esettel: távoli beszállítói hozzáférés egy kritikus OT-zónához, sérülékenységkezelés nem támogatott ipari eszközökhöz, vagy szegmentálás a vállalati IT és OT között. Építse fel a kockázati forgatókönyvet, feleltesse meg a NIS2 Article 21 követelményeinek, válassza ki az ISO/IEC 27002:2022 kontrollokat, fordítsa le őket IEC 62443 szerinti bevezetési mintákra, és gyűjtse össze a bizonyítékokat.

A Clarysec segíthet felgyorsítani ezt a munkát a Zenith Blueprint, a Zenith Controls, az IoT / OT biztonsági szabályzat, az Internet of Things (IoT) / Operational Technology (OT) biztonsági szabályzat - SME és a Harmadik fél és beszállítói biztonsági szabályzat - SME segítségével.

Következő lépésként válasszon ki egy OT-szolgáltatást, térképezze fel annak eszközeit és függőségeit, és hozzon létre ezen a héten egy kockázat–kontroll bizonyítékláncot. Ha strukturált bevezetési útvonalra van szüksége, a Clarysec 30 lépéses ütemterve és keresztmegfelelési eszköztára ezt az első láncot teljes NIS2 OT-biztonsági programmá alakíthatja.