Amikor egy kisebb önkormányzat, intézmény vagy vállalkozás először találkozik a 7/2024. (VI. 24.) MK rendelet követelményeivel, könnyen az lehet az érzése, hogy a megfeleléshez egy komplett nagyvállalati információbiztonsági szervezetet kell felépítenie.
Már az első követelménycsalád, a Programmenedzsment is 23 követelménypontot tartalmaz.
Adódik tehát a kérdés: egy 8–10 fős szervezetnek húsz külön szabályzatot és ugyanennyi informatikai rendszert kell működtetnie?
Szerencsére nem.
A rendelet azt határozza meg, minek kell működnie, nem azt, hogy minden egyes követelményhez külön dokumentumot, külön szoftvert vagy külön szervezeti egységet kell létrehozni.
Ez a „NIS2 kicsiben” sorozat egyik legfontosabb alapelve.
Mit jelent a Programmenedzsment?
A kifejezés elsőre meglehetősen nagyvállalatinak hangzik, pedig a mögötte lévő gondolat egyszerű.
A szervezetnek tudnia kell: mit véd, mitől védi, ki felel érte, milyen problémái vannak, mit tesz ezek megszüntetésére, és honnan tudja, hogy az intézkedései valóban működnek.
A Programmenedzsment követelményei ezért többek között foglalkoznak az információbiztonsági szabályzattal, az IBF szerepével, a szükséges erőforrásokkal, az elektronikus információs rendszerek nyilvántartásával, a kockázatokkal, a biztonsági teljesítmény mérésével, az ellenőrzésekkel, a beszállítókkal és a folyamatos felügyelettel. A rendelet kockázatmenedzsment keretrendszere azt is előírja, hogy a szervezet dokumentálja a biztonsági szerepköröket, a kockázatmenedzsment stratégiáját és a védelmi intézkedések hatékonyságának folyamatos ellenőrzését. Jogtár
Ez tehát elsősorban irányítási kérdés, és csak másodsorban technológiai.
Nézzünk egy 8 fős szervezetet
Vegyünk egy egyszerű példát.
Van nyolc munkatárs, nyolc-tíz számítógép, egy NAS, egy router vagy tűzfal, internetkapcsolat, valamilyen felhős levelezés, néhány külső szolgáltatás és egy külsős rendszergazda. Nincs külön IT-osztály. Nincs információbiztonsági csapat. Az IBF feladatát akár külső szolgáltató látja el.
Ehhez a környezethez nem életszerű egy nagyvállalati GRC-rendszer felépítése. De ettől még a biztonságot irányítani kell.
Mi egy ilyen szervezetnél a Programmenedzsment követelményeit első megközelítésben az alábbi hét működő elem köré szerveznénk:
| Egyszerű szervezeti elem | Mire használjuk? |
|---|---|
| 1. Információbiztonsági szabályzat | szerepkörök, felelősségek, alapvető működési szabályok |
| 2. EIR- és beszállítói nyilvántartás | tudjuk, milyen rendszereink és kritikus szolgáltatóink vannak |
| 3. Kockázatmenedzsment + kockázati nyilvántartás | tudjuk, milyen veszélyekkel kell számolnunk |
| 4. Intézkedési terv | rögzítjük, mit kell kijavítani, ki végzi el és mikorra |
| 5. Rendszer- és folytonossági dokumentáció | tudjuk, hogyan működik a környezet és mi történik kieséskor |
| 6. Éves biztonsági és ellenőrzési terv | előre meghatározzuk az ellenőrzéseket, képzéseket és teszteket |
| 7. Rendszeres IBF-jelentés | a vezető számára láthatóvá tesszük a biztonsági helyzetet |
Ez természetesen nem jelenti azt, hogy ezzel automatikusan „kipipáltuk” a rendelet minden követelményét. Azt jelenti, hogy a sok egyedi követelményt egy kis szervezet számára is működtethető rendszerbe szervezzük.
Nem kell mindenre külön szabályzat
Ez az egyik leggyakoribb félreértés.
A 7/2024. MK rendelet 1.1. pontja például részletes követelményeket fogalmaz meg az információbiztonsági szabályzattal kapcsolatban: annak át kell fognia a biztonsági követelményeket és intézkedéseket, meg kell határoznia többek között a célokat, szerepköröket és felelősségeket, és vezetői jóváhagyással kell rendelkeznie. Ebből azonban nem következik, hogy minden egyes későbbi követelményhez újabb húszoldalas szabályzatot kell írni. Egy kis szervezet esetében sokkal értelmesebb lehet egy jól strukturált, egységes IBSZ, amelyhez néhány rövid eljárásrend és nyilvántartás kapcsolódik. A cél ugyanis nem a dokumentumok számának növelése.
A cél az, hogy ami le van írva, az valóban működjön is.
Tudjuk egyáltalán, mit védünk?
Ez az egyik legfontosabb kérdés.
Egy szervezet információbiztonságát nagyon nehéz megfelelően irányítani, ha nincs világos kép arról, hogy milyen elektronikus információs rendszereket használ. Egy kis önkormányzatnál például már maga az EIR-ek meghatározása sem mindig egyértelmű.
Mi tartozik össze? A fájlszerver külön rendszer? A NAS? A levelezés? A pénzügyi rendszer? A beléptetőrendszer? A felhős szolgáltatás?
A rendelet kockázatmenedzsment keretrendszere többek között előírja az érintett rendszerek üzleti céljainak, funkcióinak, vagyonelemeinek, technológiai határainak, kezelt adatainak és kockázatainak dokumentálását.
Ezért az első gyakorlati feladat nem feltétlenül egy új szoftver telepítése.
Sokkal inkább: készítsünk egy használható EIR-nyilvántartást.
Egy kis szervezetnél ehhez egy jól kialakított táblázat is tökéletesen használható lehet.
A problémákat is nyilván kell tartani
A megfelelés során szinte biztosan találunk hiányosságokat.
Lehet elavult operációs rendszer, nem megfelelő mentés, túl sok rendszergazdai jogosultság, hiányzó MFA vagy éppen nem dokumentált beszállítói hozzáférés. A valódi probléma nem az, ha találunk hiányosságot. Az a probléma, ha senki nem tudja, mi történik vele ezután.
Ezért kell az intézkedési terv.
Egy egyszerű táblázatban már elegendő lehet rögzíteni:
hiányosság → szükséges intézkedés → felelős → határidő → státusz.
Innentől a biztonság már nem egy évente egyszer elővett szabályzat, hanem irányított folyamat.
Hogyan mérjük a biztonságot egy kis szervezetben?
A Programmenedzsment egyik érdekes követelménye a biztonsági teljesítmény mérése.
A rendelet szerint a szervezetnek ki kell alakítania az EIR-ek biztonsági mérési rendszerét, figyelnie kell a teljesítménymutatókat és rendszeresen jelentést kell készítenie róluk.
Ez első hallásra ismét valamilyen nagyvállalati dashboardot idézhet.
Pedig egy nyolcfős szervezetnél akár öt egyszerű mutatóval is el lehet kezdeni.
Például:
kritikus frissítések teljesülése · sikertelen mentések · nyitott biztonsági intézkedések · lejárt határidejű intézkedések · biztonsági oktatás teljesítési aránya
Ezekből negyedévente készülhet egy egyoldalas IBF-jelentés.
Folyamatos felügyelet ≠ folyamatosan nézni egy monitort
Az 1.23. követelmény szerint a szervezetnek folyamatos felügyeleti stratégiát és programot kell kialakítania. Ebben teljesítménymutatókat, ellenőrzési gyakoriságokat, elemzést, válaszlépéseket és rendszeres jelentést is meg kell határozni.
Egy kis szervezetnél ezt sem kell túlbonyolítani.
A „folyamatos” ebben az összefüggésben nem feltétlenül azt jelenti, hogy valaki a nap 24 órájában egy SOC-központban figyel egy képernyőt.
Jelentheti például azt, hogy kialakítottunk egy előre meghatározott ellenőrzési ciklust: havonta bizonyos technikai ellenőrzések, negyedévente biztonsági állapotértékelés, évente átfogó felülvizsgálat, valamint rendkívüli felülvizsgálat jelentős változás vagy incidens esetén.
A lényeg a rendszeresség és a dokumentálhatóság.
És ehhez milyen szoftvert kell megvenni?
Az első részben talán ez a legfontosabb válasz:
semilyet – csak azért, hogy megfeleljünk ennek a követelménycsaládnak.
Ehhez használhatunk LibreOffice Calc táblázatokat is.
Ha pedig a szervezet később kinövi ezt a megoldást, akkor lehet továbblépni egy komolyabb rendszer irányába.
Nem fordítva.
Ne azért vezessünk be bonyolult rendszert, mert létezik. Akkor vezessük be, amikor a szervezet működése már ténylegesen indokolja.
Mit fog ebből látni az auditor/NKI ellenőr?
A megfelelés egyik legfontosabb kérdése:
tudjuk-e bizonyítani, hogy amit a szabályzatban leírtunk, valóban működik?
A Programmenedzsment esetén egy jól felépített szervezet többek között hatályos IBSZ-szel, dokumentált IBF-szerepkörrel, EIR-nyilvántartással, kockázatelemzéssel, intézkedési tervvel, ellenőrzési dokumentumokkal, képzési nyilvántartással, beszállítói információkkal és rendszeres biztonsági jelentésekkel tudja ezt alátámasztani.
A lényeg itt sem a dokumentumok mennyisége.
Az összhang számít.
Ha a kockázatelemzés szerint problémát jelent a mentés, akkor ennek meg kell jelennie az intézkedési tervben. Ha az intézkedési terv szerint elkészült a javítás, annak legyen bizonyítéka.
Ha a szervezet szerint negyedévente ellenőrzi a mentéseket, legyen nyoma annak, hogy ez valóban megtörtént. Ettől válik egy szabályozási rendszer auditálhatóvá.
A NIS2 kicsiben alapelve: először egyszerűen
A 7/2024. MK rendelet nem tesz külön „kis szervezeti” követelménykatalógust. Egy kis szervezetnek is komolyan kell vennie a rá vonatkozó biztonsági követelményeket. Ez azonban nem jelenti azt, hogy ugyanazzal a technológiai és szervezeti megoldással kell teljesítenie őket, mint egy több ezer fős vállalatnak. A rendelet maga is kockázatmenedzsmentre épül: a szervezetnek értékelnie és kezelnie kell a rendszereit érintő kockázatokat, és ennek megfelelő védelmi intézkedéseket kell kialakítania. Jogtár
A kis szervezet nem kisebb biztonságot igényel. Hanem a méretéhez és kockázataihoz illeszkedő biztonságot.
Ez nagy különbség.
Most Ti jöttök
A „NIS2 kicsiben” sorozatot nem szeretnénk kizárólag egyirányú szakmai tartalomként működtetni.
Kíváncsiak vagyunk a rendszergazdák, IBF-ek, auditorok, informatikusok és érintett szervezetek gyakorlati tapasztalataira is.
Nálatok hogyan működik a Programmenedzsment? Excel, LibreOffice, SharePoint, NAS, saját fejlesztés vagy valamilyen külön rendszer?
Van olyan egyszerű megoldás, amely különösen bevált?
Írjátok meg a bejegyzéshez kapcsolódó közösségi média poszt alatt. A használható ötleteket és tapasztalatokat a későbbi részekben is feldolgozzuk, a sorozat végén pedig ezekből is építkezve szeretnénk elkészíteni a „NIS2 kicsiben – gyakorlati útmutató kis szervezeteknek” című összefoglaló anyagot.
És miért foglalkozunk ezzel a CyberTeamnél?
Mert a gyakorlatban újra és újra azt látjuk, hogy a jó információbiztonsági megoldás nem feltétlenül a legdrágább vagy a legbonyolultabb.
Először azt kell megérteni, hogyan működik az adott szervezet, milyen rendszerektől függ, milyen kockázatai vannak, és mire van valóban szüksége.
Csak ezután érdemes technológiáról, új rendszerekről vagy további költségekről beszélni.
Ezt a szemléletet követjük a CyberTeam Kft. munkájában is.
Mert a kiberbiztonság akkor jó, ha nemcsak az audit napján működik.