Megjelent a NIS2 – Kibertantv. részletes követelmény tervezet – elemzés

Bizonyára a magyar információbiztonsági piac sok másik szereplője is hozzánk hasonlóan várta a Kibertantv. részletes biztonsági követelményeire vonatkozó híreket. Napi szinten figyeltük a Kormány Dokumentumtárát, ahol 2024. január 31-én reggel megjelent a Biztonsági osztályba sorolás követelményeiről, valamint az egyes biztonsági osztályok esetében alkalmazandó konkrét védelmi intézkedésekről szóló miniszteri rendelet tervezete. Aki követi az iparági híreket és podcastokat, az a Nemzeti Kibervédelmi Intézet (NKI) Kibertámadás! podcast S3E82 adásában már hallhatta az erre vonatkozó utalásokat. Ugyan csak tervezetről beszélünk, de ez már sok alap kérdésre választ ad az érintett szervezeteknek arról, hogy milyen irányba kell elindulniuk, ha eddig ezt nem tették meg.

Az iparági hírek és előadások alapján sejteni lehetett, hogy a Kibertantv. érintetti körére is a közismert 41/2015 BM rendelet követelményei fognak valamilyen formában vonatkozni, amely egyénként a NIST SP 800-53 alapjaira épült. A hivatkozott tervezet a BM rendeletet fogja kiváltani és egységesen fog érvényesülni a Kibertantv. és az Ibtv. érintetti köreire. Ebben a cikkben kívánom bemutatni a tervezet lényegi elemeit.

Kockázatmenedzsment keretrendszer

A tervezet egyik újdonsága az úgynevezett Kockázatmenedzsment keretrendszer, ami átfogóan tartalmazza a PDCA módszer elemeit. A Kibertantv. ugyan az információbiztonsági irányítás rendszerét említi, de úgy gondolom, hogy jelen esetben, lényegében ugyanannak tekinthetjük a két kifejezés lényegét. Ugyanakkor fontos megjegyezni, hogy a Kibertantv.-ben sehol sem említik az ISO 27001-alapú információbiztonsági irányítás rendszert, a kockázatmenedzsment keretrendszer felépítése más, mégis vannak közös pontok.

1. Pillér – Keretrendszer létrehozása és rendszerek meghatározása

A keretrendszer első pillére a keretrendszer, kézenfekvő módon először a szervezet elektronikus információs rendszerek védelmével kapcsolatos szerepköröket, felelősségeiket, feladataikat kell meghatározni és dokumentálni. 

Meg kell alkotni egy kockázatmenedzsment stratégiát is, amely leírja, hogy a szervezet hogyan azonosítja, értékeli, kezeli és felügyeli a biztonsági kockázatokat. Ezen felül egy biztonság-felügyeleti stratégiát is ki kell dolgozni, amely magába foglalja a védelmi intézkedésekhez kapcsolódó tevékenységek ellenőrzésének gyakoriságát, felügyeletének módszereit és eszközeit.

A tervezet is tovább viszi a BM rendelet rendszerfókuszú megközelítését és a követelmények teljesítését, illetve dokumentációját az egyes elektronikus információs rendszerek szintjén írják elő, de még ne szaladjunk előre a biztonsági osztályba sorolásig.

A rendszerekkel kapcsolatban az alábbiakat kell dokumentálni:

• a rendszer által támogatandó üzleti célokat, funkciókat és folyamatokat,
• a tervezésben, fejlesztésben, implementálásban, üzemeltetésben, karbantartásban, használatban és ellenőrzésben érintett személyeket,
• érintett vagyonelemeket,
• a rendszer szervezeti és technológiai határát,
• a rendszer által feldolgozandó, tárolandó és továbbítandó
• adatköröket és azok életciklusát,
• a rendszerrel kapcsolatos fenyegetettségből adódó biztonsági kockázatok értékelését és kezelését,
• a rendszer helyét a szervezeti architektúrában, amennyiben a szervezet rendelkezik vele.

Ha gyakorlati oldalról közelítjük meg ezt az elvárást, akkor a megfeleléshez komoly szervezeti érettség kell, hiszen ehhez több naprakész és teljeskörű nyilvántartással kell rendelkezni, amelyek a valóságban kevés helyen vannak meg megfelelő formában. Pl.: üzleti folyamatok listája, üzleti célok „listája” explicit módon, hardver- és rendszernyilvántartás, IP nyilvántartás, adatvagyonleltár, kockázatnyilvántartás.

2. pillér – Biztonsági osztályba sorolás

Azt, hogy a rendszereket biztonsági osztályba kell sorolni, már a Kibertantv. szövegéből tudni lehetett, ahogy azt is, hogy a megszokott 5 fokozatú biztonsági osztály 3 biztonsági osztályba lett összevonva: Alap, Jelentős, Magas. Az egyes biztonsági osztályokhoz tartozó hatás skálák viszont korábban nem voltak ismertek, erre a tervezet adott választ. A tervezetben részletezett hatás skála alapján úgy látom, hogy egy átlagos szervezetnek viszonylag kevés Magas besorolású rendszere lesz, vagy akár egyáltalán nem is lesz.

Az osztályba sorolást minden elektronikus információs rendszerre el kell végezni, függetlenül attól, hogy az esetleg egy harmadik fél által működtetett rendszer. Ha az érintett szervezet rendelkezési joga az elektronikus információs rendszernek csak egyes elemeire vagy funkcióira terjed ki (pl. egy SaaS alkalmazás hozzáférés kezelésére), akkor az irányadó biztonsági követelményeket ezen elemek és funkciók tekintetében kell teljesítenie az érintett szervezetnek. Ezt a kérdést érdemes lehet a felhős rendszerek felelősségi mátrixához hasonlóan megközelíteni.

3. pillér – Védelmi intézkedések kiválasztása

Főszabály szerint a biztonsági osztályba sorolás alapján kell kiválasztani, majd testre szabni és alkalmazni a kontrollokat a tervezetben található védelmi intézkedés katalógusból, de a Kibertantv.-vel kapcsolódó előadásokban elhangzottak szerint kockázat-alapon van lehetőség némi eltérésre és helyettesítő intézkedések alkalmazására, amelyeket később fejtek ki.

Az alkalmazandó biztonsági követelményeket az adott rendszer rendszerbiztonsági tervében kell dokumentálni, amit a szervezet vezetője, vagy az elektronikus információs rendszer biztonságáért felelős szerepkört betöltő személy hagy jóvá.

Nem elég magában az alkalmazandó biztonsági követelményeket kidolgozni, ezek alkalmazásának az ellenőrzésére is létre kell hozni egy eljárásrendet a biztonság-felügyeleti stratégiával összhangban. Az eljárásrendnek kell választ adnia, hogy ki, milyen védelmi intézkedéseket, milyen eszközökkel, hogyan és mikor kell ellenőriznie. Röviden: kontroll tesztelés.

4. pillér – Védelmi intézkedések alkalmazása

Az egyes védelmi intézkedéseket be kell vezetni vagy ki kell terjeszteni az új rendszerekre. A védelmi intézkedések bevezetésére vonatkozóan a tervezet tartalmaz egy fokozatosságra vonatkozó rendelkezést: „A védelmi intézkedések fokozatosan vezethetők be. A fokozatosságot a védendő elektronikus információs rendszerek biztonsági osztályozása alapján lehet felállítani.” Ennél több útmutatás nincs, ellenben sok kérdést lehet felvetni ezzel kapcsolatban.

Ha egy korábban információbiztonsági szempontból nem szabályozott, alacsony érettségi szinttel rendelkező szervezetnek a Jelentős biztonsági osztályhoz tartozó 302 kontrollt kell alkalmaznia az első kiberbiztonsági auditig, akkor nem lesz egyszerű dolguk. Ha a fokozatosság azt jelenti, hogy először az Alap követelményeket kell teljesíteni, majd az Ibtv-ben jelenleg létező kétéves biztonsági osztály emeléshez hasonló megoldást (Ibtv. 8.§ (3) bekezdés) lehetne alkalmazni, az nagy segítség lenne minden megfelelni akaró érintett szervezetnek. Erre vonatkozóan nincs konkrét információ, de remélhetően a hatályos szabályozásban ez tisztázásra kerül.

5. pillér – Védelmi intézkedések értékelése

A PDCA ciklusból elérkeztünk a C betűhöz, vagyis a Check-hez. A kontrollokat nem elég csak alkalmazni, azok hatékonyságáról rendszeres időközönként meg is kell győződni. Nem csak a Kibertantv. által előírt kétéves auditokkal, mert ez ahhoz  hosszú ciklus.

A biztonság-felügyeleti stratégia és a biztonságértékelési eljárásrend alapján rendszeres időközönként értékelni (tesztelni) kell a kontrollokat és meg kell állapítani, hogy azok megfelelően működnek-e.  Ennek az outputjaként dokumentálni kell az értékelési jelentést, amely tartalmazza az észrevételeket és javaslatokat. Ezek alapján kell – szükség esetén – további intézkedéseket bevezetni a követelmények teljesítése érdekében.

A szervezet vezetőjének – szervezeti szinten az információbiztonság legmagasabb szintű felelőseként – meg kell vizsgálnia rendszer biztonsági állapotára vonatkozó dokumentumokat (pl. értékelési jelentés, vagy inkább ezek vezetői összefoglalóját) és át kell tekintenie a kockázatokat. Ezek alapján kell döntést hoznia az érintett rendszer üzembehelyezésére (értelemszerűen új rendszernél) vagy üzemben tartására (meglévő rendszernél) vonatkozóan.

6. pillér – Folyamatos felügyelet

Ha kialakításra került a keretrendszer, be lettek vezetve a biztonsági kontrollok, akkor ezt a működést és az állapotot fenn is kell tartani. A folyamatos felügyelet keretében elfogadható szinten kell tartani a kockázatokat, lekövetve és alkalmazkodva a szervezeti, technológiai és biztonsági környezet változásaihoz. Ennek érdekében felül kell vizsgálni a rendszerek biztonsági állapotát, továbbra is értékelni kell a védelmi intézkedéseket, átvezetni a változásokat. Ha egy rendszert ki kell vezetni, akkor ezt a kockázatcsökkentő intézkedéseket tartalmazó folyamat vagy terv alapján kell megtenni (pl. hozzáférések megszüntetése, adatok biztonságos törlése).

Védelmi intézkedések katalógusa

Fontos a keretrendszer, de talán mindenki érdekesebbnek tartja a Védelmi intézkedések katalógusát, amely a tervezet 2. mellékletében található. Végső soron ez tartalmazza a megfeleléshez szükséges feladatok nagy részét.

A cikknek nem célja az összes kontroll ismertetése. E helyett inkább az összefüggésekre és a háttérre szeretnék rávilágítani. Aki gyakran használta az Osztályba sorolás és védelmi intézkedés űrlapot, vagyis az OVI táblát, annak sok ismerős kontroll lesz. Ennek az az oka, hogy az NKI podcastjában elhangzottak szerint a NIST SP 800-53 Rev. 5 szabvány előírásai lettek átemelve a tervezetbe, amely korábbi verzióján alapult az OVI tábla is. A biztonsági osztályok 3 szintje is innen eredhet, hiszen a NIST SP 800-53 Rev. 5-nek is 3 security baseline-ja van hasonló céllal. Némi elemzéssel további érdekességekre is bukkanhatunk.

A tervezet védelmi intézkedés katalógus fejezetei megegyeznek a NIST SP 800-53 Rev. 5 Control Family-k angol megfelelőjével.

Tervezet követelmény fejezet	NIST SP800-53 Control Family
Programmenedzsment	Program Management
Hozzáférés-felügyelet	Access Control
Tudatosság és képzés	Awareness and Training
Naplózás és elszámoltathatóság	Audit and Accountability
Értékelés, engedélyezés és monitorozás	Assessment, Authorization, and Monitoring
Konfigurációkezelés	Configuration Management
Készenléti tervezés	Contingency Planning
Azonosítás és hitelesítés	Identification and Authentication
Biztonsági események kezelése	Incident Response
Karbantartás	Maintenance
Adathordozók védelme	Media Protection
Fizikai és környezeti védelem	Physical and Environmental Protection
Tervezés	Planning
Személyi biztonság	Personnel Security
Kockázatelemzés	Risk Assessment
Rendszer- és szolgáltatásbeszerzés	System and Services Acquisition
Rendszer- és kommunikációvédelem	System and Communications Protection
Rendszer- és információsértetlenség	System and Information Integrity
Ellátási lánc kockázatkezelése	Supply Chain Risk Management

Arányukban megegyeznek az egyes forrásokban megtalálható követelmények száma is:

Tervezet biztonsági osztályok	Tervezetben található védelmi intézkedések száma	NIST SP800-53 Rev. 5 védelmi intézkedések száma	NIST SP800-53 Rev. 5 Security Baseline-ok
Alap	164	170	Low
Jelentős	302	308	Moderate
Magas	385	391	High

A tervezetben található táblázatban feltüntetésre kerültek a követelménycsoportok, követelmények, valamint a biztonsági osztályok is. X-szel van jelölve, hogy az adott követelményt melyik biztonsági osztályban kell alkalmazni. Vannak olyan sorok is, amelyekben mindhárom biztonsági osztálynál – jel került feltüntetésre.  Ezek kiegészítő védelmi intézkedések, amelyeket egyik biztonsági osztály esetében sem kötelező alkalmazni, a szervezetek azonban felhasználhatják ezeket a rájuk vonatkozó egyéb követelmények teljesítése érdekében.

Úgy gondolom, hogy továbbra is üdvözlendő az a megközelítés, hogy egy bevált, immár 19 éve létező, világszerte elismert szabványt vesznek alapul a követelmények meghatározásánál. A már hivatkozott podcast adás alapján ezeket a kontrollokat tovább csiszolták a hazai viszonyokra.

Eltérések és helyettesítő védelmi intézkedések

Az eddigi szabályozástól eltérően a tervezetben meghatározott keretek közt el lehet térni a követelményektől, de ehhez megfelelő indoklás és kockázatelemzés kell, tehát senkinek sem érdemes erre alapoznia. Néhány példa: A szervezeti létesítményekkel kapcsolatos védelmi intézkedések csak azokra a létesítményekre alkalmazandók, amelyek közvetlenül nyújtanak védelmet vagy biztonsági támogatást az elektronikus információs rendszernek, vagy kapcsolatosak azzal. Specifikus technológiára [például vezeték nélküli kommunikáció, kriptográfia, nyilvános kulcsú infrastruktúrán (PKI) alapuló hitelesítési eljárás] vonatkozó védelmi intézkedések csak akkor alkalmazandók, ha ezeket a technológiákat használják az elektronikus információs rendszerben, vagy jogszabály, vagy szervezetre vonatkozó szabályozó előírja ezek használatát.

A helyettesítő védelmi intézkedések, ismertebb nevükön kompenzációs kontrollok intézménye sem volt elterjedt jogszabályi szinten, de más keretrendszerek, szabványok régebb óta ismerik és alkalmazzák, pl. PCI-DSS. A PCI-DSS esetében a kompenzációs kontrollok akkor vehetők figyelembe, ha a szervezet nem tud megfelelni az előírt követelményeknek bizonyos technológiai vagy üzleti korlátok miatt, de rendelkezik más védelmi intézkedésekkel, amelyekkel a kockázatot kellőképpen csökkentik. A tervezet is biztosítja a lehetőséget, hogy a szervezet egy adott biztonsági osztályhoz tartozó védelmi intézkedés helyett egyenértékű vagy összemérhető védelmet nyújtson az adott elektronikus információs rendszerre valós fenyegetést jelentő veszélyforrások ellen. Természetesen az eltérésekhez hasonlóan ennek is megvannak a keretei: akkor alkalmazandó, ha a védelmi intézkedések katalógusa nem tartalmaz az adott viszonyok között eredményesen alkalmazható intézkedést, felmérték az ezzel járó kockázatot, dokumentumban bemutatják a körülményeket és jóváhagyta a kockázatok felvállalására jogosult szerepkört betöltő személy.

Kockázatelemzés és a kockázatok kezelése

A tervezet ír a kockázatelemzésről és a kockázatok kezeléséről is. Itt sok újdonság nincs, ezeket a követelményeket egy bevált kockázatkezelési keretrendszer megfelelő átültetésével könnyen lehet teljesíteni, pl. ISO 27005, NIST SP800-30, CIS RAM, FAIR és még folytathatnánk.

Minimálisan négy fokozatú kockázati besorolást kell alkalmazni, amire azért lehet szükség, hogy a szervezetek elkerüljék azt, hogy túl sok közepes besorolású kockázatuk legyen és ezeket nehezen lehessen megközelíteni. A tervezet 3. mellékletében találhatunk egy fenyegetési katalógust is, amellyel kapcsolatban előírják, hogy legalább az abban található elemeket kell figyelembe venni a kockázatelemzések során. Úgy gondolom, hogy a szakmailag megfelelően összeállított kockázatkezelési módszertanok teljesítik a fenti elvárásokat.

Konklúzió és a következő lépések

A jogszabály társadalmi véleményezésének határideje hamarosan lejár, véleményünk szerint nem sok változásra kell számítani. Az előírások gyakorlati alkalmazásánál, különösen az új lehetőségek (pl. fokozatosság, eltérések, helyettesítő intézkedések) esetében biztosan sok kérdés lesz, ezért továbbra is érdemes lesz részt venni a konferenciákon, szakmai előadásokon és meghallgatni az ezzel kapcsolatos podcastokat.

Mi a következő lépés az érintett szervezeteknél? Gap elemzés végrehajtása és a keretrendszer kialakításának megkezdése. Eddig viszonylag kérdéses volt, hogy milyen követelményrendszer alapján érdemes megcsinálni a kezdeti felméréseket, de a tervezet megjelenése óta ez már nem kérdés. Minden érintett szervezetnek továbbra is azt javasoljuk, hogy önállóan vagy külső segítséggel mérje fel a mostani biztonsági szintjét és tervezze meg a feltárt hiányosságok megszüntetéséhez szükséges feladatokat. A cikkben már említett – korábban nem szabályozott, információbiztonsági szempontból alacsony érettségi szintű – szervezeteknek nagyon sok teendőjük lesz, a piac kapacitásai végesek, ezért nem lehet az utolsó pillanatra hagyni a felkészülést.

---