Így már a kezdetekkor is érdemes egy kicsivel több munkát beletenni a felkészülésbe és egy hosszútávon fenntartható NIS2 megfelelőségi struktúrát kialakítani annak érdekében, hogy a későbbiekben legalább az alapokhoz ne kelljen hozzányúlni már.
Nézzük, mire is gondoltunk a fenti általános megállapítás mögött valójában, tehát hogy melyek azok a fundamentális, de mégsem triviális megfontolások, amelyek kezdeti megtételével hosszútávon nagymértékben megkönnyíthetjük saját (és céges utódaink) életét.
A NIST 800 ökoszisztémára építkezés
A Kibertan tv. végrehajtási rendeletének tekinthető (és cikkünk megírásakor még mindig csak tervezet formájában létező) MK rendelet tartalmazza a 2. sz mellékletében a kontroll követelményeket, amelyeknek az egyes informatikai rendszereink vonatkozásában meg kell felelnünk. Közismert, hogy ezek a kontroll követelmények a NIST 800-53r5, amerikai szövetségi intézményrendszerre vonatkozó standard, egy az egyben történő fordításai.
Az már viszont kevésbé köztudott, hogy a NIST 800-53r5 csupán csak egy kontroll katalógus, és "önálló életre" nem alkalmas. Ami életképessé teszi, az a teljesen költségmentesen elérhető NIST 800-as ökoszisztéma, amelynek legfontosabb elemeit a teljesség igénye nélkül az alábbi felsorolásban említjük meg. Arra a kérdésre, hogy melyik belépőpontot válasszuk ahhoz, hogy megértsük a NIST 800-53r5 fenntartható alkalmazást, azt javasoljuk, hogy NIST 800-37r2 Risk Management Framework (RMF) gondolatvilágát igyekezzünk elsajátítani. Hogy miért? Mert a kontrollkörnyezetet kiterjeszti a meglévő rendszereken túl a fejlesztés alatt álló rendszerekre is, lefedve a rendszer teljes életciklusát. Segít belátni, hogy a kontrollkörnyezet kialakítása és működtetése nem kizárólag cyber feladat, hanem a teljes szervezet közreműködését igényli. Így a NIST 800-53r5, azaz a NIS2 követelményeinek való megfelelés nem cél lesz, hanem következmény.
Hogyan érhető ez el? A RMF meghatározza azokat a feladatokat, szám szerint 47-et, amelyek maradéktalan végrehajtása hosszútávon garanciát jelent a megfelelőség biztosítására. Az elvégzendő feladatok hét lépésbe vannak sorolva, amelyekből kettőt szeretnénk kiemelni, az elsőt és az utolsót.
Az első lépés a felkészülés. Azért tartjuk fontosnak ennek a lépésnek a nagyvonalú ismeretét még a külső tanácsadót bevonni kívánó cégek számára is, mert ennek segítségével megítélhető a kívülről bevont erőforrás szakmai hozzáértése és a leszállított terjedelem teljeskörűsége is.
Az utolsó lépes a folyamatos felügyelet. A folyamatos felügyeletet megelőzi a rendszerek biztonsági osztályba sorolása, védelmi intézkedések kiválasztása és testre szabása, a védelmi intézkedések (kontrollok) bevezetés, azok értékelése, majd a rendszer engedélyezése. A "nagykönyv" szerint új rendszer csak mindezeket követően kerülhet át az éles környezetbe, ahol életének legnagyobb részét tölti. Ebben a szakaszban a NIST 800-37 szerinti folyamatos felügyelet feladatait kell végezni az alkalmazott védelmi intézkedések folyamatos értékelésével.
A NIS2 szempontjából hasznos NIST publikációk
NIST 800-53A - védelmi intézkedések értékelése
NIST 800-53B - biztonsági osztályok és azok testre szabása
NIST 800-18 - rendszerbiztonsági terv kialakítása
NIST 800-30 - kockázatértékelési segédlet
NIST 800-34 - üzletmenet-folytonossági tervezés
NIST 800-37 - kockázatkezelési keretrendszer kialakítása
NIST 800-39 - információbiztonsági kockázatkezelés
NIST 800-61 - biztonsági incidenskezelés
NIST 800-60 - információ típusok és információs rendszerek osztályba sorolása
NIST 800-137 - Információbiztonság folyamatos felügyelete
NIST 800-160 - rendszerfejlesztési életciklus kialakítása
Ahhoz, hogy használatba vehessük a NIST 800 ökoszisztéma fenti elemeit, nyilvánvalóan szükség van arra, hogy az MK rendelet adott kontrollját hozzá tudjunk rendelni a NIST 800-53 megfelelő eleméhez. A 900-nál is több elemű listák összerendelése egy manuálisan végzendő, hosszadalmas feladat, amit mi már elvégeztünk és az összerendelő táblát kérésre szívesen megosztjuk. Elérhetőségünk a cikk végén található.
Belső kontroll keretrendszer (Internal Control Framework) kialakítása
Egy másik kiemelkedően hasznos és nagy megtérülésű megfontolás, hogy ne közvetlenül a NIS2 (MK rendelet) kontrolljait vezessük be, hanem amennyiben egyéb más külső (pl. PCI-DSS, ISO27001, SoX stb.) vagy belső (saját belső szabályrendszerünk) követelményrendszernek is meg kell felelnünk, akkor a hasonló területet szabályozó kontrollokat vessük össze és definiáljuk azt a közös metszetet, amellyel a minimálisan szükséges szinten mindegyik követelménynek megfelelünk. Így egy saját, származtatott kontroll alkalmazásával egyszerre felelhetünk meg minden egyes követelményrendszernek (Test Once, Comply Many audit alapelv érvényesítése). Erre a célra több eszköz is rendelkezésükre áll, hogy elkerülhessük az összerendeléssel járó folyamatos feladatot, mint pl. a Secure Controls Framework (SCF) vagy a Unified Compliance Framework (UCF).
Általános IT kontrollok (IT General Controls/Common Controls)
Az MK rendelet és a NIST 800-53 is rendszerkategóriánként (alap, jelentős, magas) definiálja a kontrollkövetelmény-csomagokat (control baselines), amelyeknek meg kell felelnünk. Azt azonban egyik sem határozza meg, hogy egy adott kontrollkövetelmény úgynevezett általános kontroll-e (Common Control/IT General Control), vagy alkalmazásspecifikus. Ennek meghatározása ránk, mint megfelelésre kötelezettre vár. Mivel az általános kontrollok üzemeltetése nagyságrendekkel olcsóbb, mint az alkalmazáskontrolloké, így akkor járunk el helyesen, ha az általános kontrollok bevezetésére törekszünk alkalmazáskontrollok helyett. Így egy teszteljárással le tudjuk fedni számos rendszerünket ahelyett, hogy minden egyes rendszerünk esetén egyesével külön kéne kontrollokat tesztelnünk. Tapasztaltunkban az MK rendelet kontrolljainak jelentős része (akár 80% is) "általánosítható".
Folyamatos kontroll monitorozás (Continuous Control Monitoring)
Fentebb már említettük, de visszatérnénk még egy gondolat erejéig a folyamatos kontroll monitorozás témájára. Maga az MK rendelet is megköveteli ezt az 5. Értékelés, engedélyezés és monitorozás szekciójában, de jóval többről van itt szó, mint egy kontrollról a sok százból. A folyamatos kontroll monitorozás tekinthető az IT kockázatkezelés szívének-lelkének. Ugyanis helikopternézetből a kontrollok célja nem más, mint a kockázatcsökkentés, és ha egy kontrollunk nem működik megfelelően, akkor azzal nyilván kockázatot futunk.
Tehát, a NIS2 szempontból nem csupán egy kezdeti kontroll értékelést (gap assessment) kell végeznünk, majd az auditorunkra bízni a kétévenkénti értékelést, hanem mi magunknak kell a bevezetett kontrolljainkat az általunk definiált gyakoriság mentén rendszeresen értékelnünk, ha valóban kockázatot szeretnénk csökkenteni, nem pedig csak a check-box compliance a cél.
A LogicGate GRC platformra épített NIS2 Compliance Automation megoldásunk támogatja az SCF alapú (tehát a NIS2 mellett minden egyéb más követelménynek is eleget tevő) belső kontroll keretrendszer kialakítását, a folyamatos kontroll monitorozást, majd a kontroll hiányosságokból származó kockázatok értékelését és kezelését egyaránt.
A szerzők:
Szabolcs András
CISA, FAIR Risk Analyst
andras.szabolcs@goverwithus.com
Szigetvári Péter
CISM, CBCI, PMP, CGRC, FAIR Risk Analyst
peter.szigetvari@governwithus.com
Cikkünk a ComputerTrends magazin 2024. június 6-ai nyomtatott lapszámában jelent meg.
