A NIS2 audit akkor lesz stresszmentes, ha nem auditprojektre készülsz, hanem auditálható működést építesz. A különbség óriási. Audit előtt kapkodni drága és bizonytalan. Ezzel szemben a scope, felelősség, leltár és bizonyíthatóság rendbetétele olyan alap, amire a rendszer stabilan felépíthető. Ha ezt a tíz buktatót előre kezeled, akkor a NIS2 audit nem fog meglepetést hozni. Legfeljebb fejlesztési javaslatokat. És ez a legjobb forgatókönyv, mert ott már nem a megfelelésért futsz, hanem a működésedet fejleszted.
Miért nem a tűzfalon bukik el a megfelelés, hanem a működés bizonyíthatóságán?
A NIS2 audit előtt a legtöbb szervezetnél ugyanaz a reflex indul be: gyorsan készítsünk szabályzatokat, írjunk eljárásokat, töltsünk fel dokumentumokat, és legyen „valami” a compliance mappában. Ez érthető, mert a szabályozási nyomás erős, az idő kevés, és sokszor az az érzésünk, hogy a megfelelés elsősorban adminisztratív kérdés.
A valóság azonban ennél egy kicsit kellemetlenebb, ugyanakkor felszabadítóbb is. A NIS2 audit nem azt keresi, hogy van-e egy jó papírhalmod, hanem azt, hogy a szervezet kiberbiztonsági működése auditálhatóan irányított-e. A tanúsító nem a legújabb tűzfal típusodra kíváncsi, és nem is arra, hogy az IT kolléga mennyire ért a szakmájához, hanem arra, hogy van-e rend a scope-ban, a felelősségekben, a kontrollokban és a bizonyítékokban.
Ez az oka annak, hogy a NIS2 audit tipikusan nem „technológiai” hibákon bukik el, hanem szervezeti buktatókon. A következőkben azt a tíz leggyakoribb auditkockázatot mutatom be, amelyek a legtöbbször megjelennek, és azt is elmondom, hogyan tudod ezeket egyszerűen, előrelátóan kezelni. Minden pontnál olyan evidenciákat is kapsz, amelyek ténylegesen auditképes bizonyítékként működnek.
1. A scope nincs rendben, ezért a megfelelés „félrecsúszik”
Az egyik leggyakoribb auditbuktató az, amikor a szervezet nem tudja egyértelműen megmondani, mi tartozik a NIS2 hatálya alá. Ilyenkor a kiberbiztonsági kontrollok esetleg léteznek, de nem ott és nem úgy, ahol kellene, a dokumentáció pedig általános, sablonos és nem kapcsolódik valós rendszerekhez.
Az auditor tipikusan azt fogja kérdezni, hogy mely elektronikus információs rendszerek tartoznak a scope-ba, melyek kritikusak, milyen függőségek vannak, és ezekre milyen kontrollok épülnek. Ha erre nincs tiszta és következetes válasz, akkor az audit már az elején bizonytalanná válik.
A megelőzés kulcsa itt az, hogy legyen egy egyértelmű scope dokumentum, valamint egy naprakész EIR nyilvántartás, amelyben a rendszerek tulajdonosai és kritikus besorolása is látható. Egy jól felépített scope nem adminisztráció, hanem irányítási alap.
2. A NIS2-t IT-projektként kezelik, pedig vezetői felelősség
A NIS2 megfelelés egyik alaplogikája az, hogy a kiberbiztonság vezetői felelősségű megfelelési rendszer. Ehhez képest auditon nagyon gyakran kiderül, hogy a rendszer „az IT-nál fut”, a vezetés pedig legfeljebb jóváhagyott egy-két dokumentumot.
Egy tanúsító audit során a vezetői szerepvállalás nagyon gyorsan láthatóvá válik, mert az auditor nem csak azt kérdezi meg, ki a felelős, hanem azt is, hogyan történik a vezetői kontroll, milyen döntések születnek, milyen erőforrásokat biztosítanak, és hogyan vizsgálják felül a rendszer eredményességét.
A jó megoldás az, ha van kijelölt vezetői sponsor, van projektvezető, és létezik formális felelősségi rend, például RACI mátrixban rögzítve. Ugyanilyen fontos, hogy a vezetői döntéseknek nyoma is legyen, például jegyzőkönyvek, jóváhagyások vagy rendszeres review meetingek formájában.
3. Nincs eszköz- és rendszerleltár, ezért nincs kontroll sem
A NIS2 audit egyik legkegyetlenebb, ugyanakkor leglogikusabb pontja az eszköz- és rendszerleltár kérdése. A kiberbiztonsági kontrollok ugyanis csak akkor működtethetők, ha a szervezet valójában tudja, milyen eszközei vannak, milyen szoftvereket futtat, és hol vannak a kritikus rendszerei.
Auditon sokszor előfordul, hogy egy szervezetnek van patching folyamata, van backup rendszere, van jogosultságkezelése, de közben nincs egyetlen naprakész nyilvántartás sem, ami ezek kezelését ténylegesen lehetővé teszi. Ilyenkor a megfelelés szétesik, mert a kontrollok nem tudnak mire ráülni.
A megelőzés alapja az, hogy legyen hardverleltár, szoftverleltár, admin jogosultság lista, külső hozzáférések listája, valamint távoli hozzáférések nyilvántartása. Ezek nem „adminisztratív papírok”, hanem audit és működés alapfeltételek.
4. A jogosultságkezelés túl laza, és nincs mögötte jóváhagyás
Az egyik legtipikusabb auditmegállapítás a jogosultságkezelés hiányossága. Sok szervezetben túl sok admin jogosultság van, a jogosultságok történetileg „ráépültek” a működésre, és senki nem tudja pontosan, ki miért fér hozzá egy rendszerhez.
Az auditor ilyenkor azt fogja vizsgálni, hogy van-e belépés–kilépés kontroll, van-e hozzáférés jóváhagyási folyamat, dokumentált-e az admin jogosultságok felülvizsgálata, és működik-e a least privilege logika. A legfájóbb itt az, hogy ez a terület jellemzően nem technikai, hanem fegyelmi és folyamatkérdés.
A jó gyakorlat az, ha minden jogosultság mögött van jóváhagyás, az admin jogosultságok külön kezelést kapnak, és rendszeres időközönként történik jogosultság-felülvizsgálat, amelynek nyoma is marad.
5. Van mentés, csak nincs visszaállítási bizonyíték
A mentések kérdése sok szervezetnél „kipipált” terület. Audit során mégis rendszeresen előjön, hogy nincs bizonyíték restore tesztre, vagy a restore teszt ugyan megtörtént, de nem dokumentálták.
A NIS2 logikája szerint a mentés önmagában nem jelent védelmet. A védelem ott kezdődik, hogy a szervezet bizonyítani tudja: kritikus helyzetben vissza tud állni. Ezért az auditor nem csak azt kérdezi, van-e mentés, hanem azt is, mikor történt restore teszt, mi volt az eredmény, és mi lett a javító intézkedés, ha hiba merült fel.
A jó megoldás itt az, ha a restore teszt rendszeres, tervezett, rövid és visszakövethető, és a teszt eredménye auditképes dokumentumként elérhető.
6. A patching ad hoc, és nincs kivételkezelés
A patch management az a terület, ahol a szervezetek gyakran azért csúsznak meg, mert a mindennapi működés felülírja a fegyelmet. „Majd frissítünk, ha lesz idő” – ez a mondat auditon nagyon gyorsan megbukik.
Az auditor ilyenkor a patching folyamatot, a kritikus frissítések határidőkezelését, a kivételek kezelését és a kockázatvállalás dokumentálását fogja keresni. A kivétel ugyanis lehet jogos, például OT rendszereknél, de akkor azt kontrolláltan kell kezelni, nem ösztönösen.
A jó gyakorlat az, ha van patching policy, vannak vállalt határidők (SLA), és minden kivételhez tartozik indoklás, kockázatértékelés és célidő.
7. Van naplózás, csak nincs monitorozás
A naplózás egy tipikus „látszólag kész” terület. Sok helyen működik logolás, de nincs rendszeres eseményértékelés, nincs riasztáskezelés, és gyakorlatilag senki nem nézi a logokat addig, amíg nincs baj.
Auditon itt az a fő kérdés, hogy a naplózás élő kontroll-e, vagy csak adatgyűjtés. Az auditor azt fogja keresni, hogy milyen eseményeket naplóztok, ki és milyen gyakran nézi át ezeket, hogyan történik az eltérések kezelése, és milyen bizonyíték van a monitorozásra.
A megoldás nem feltétlenül egy drága SIEM bevezetése, hanem az, hogy legyen log review rend, legyen riasztáskezelés, és a folyamatnak maradjon auditnyoma.
8. Az incidenskezelés szabályzat szintjén létezik, de nincs gyakorolva
A NIS2 audit egyik lebuktató pontja az incidenskezelés. Sok szervezetnél létezik incidenskezelési szabályzat, de senki sem próbálta ki, nincs gyakorlat és nincs „tanulságlista”.
Az auditor nem azt várja, hogy minden héten incidensed legyen, hanem azt, hogy a szervezet képes legyen reagálni, és ezt tudja is bizonyítani. Ezért egy egyszerű tabletop gyakorlat, jegyzőkönyvvel és lessons learned listával, aranyat ér auditon.
A jó megoldás az, ha legalább évente történik egy incidensgyakorlat, a szerepkörök tiszták, és a bejelentési csatorna is működik.
9. A beszállítói hozzáférések kontrollálatlanok
A beszállítói hozzáférések a NIS2 egyik legnagyobb valós kockázatát jelentik. A tipikus auditbuktató az, amikor a beszállító távoli hozzáférést kap (például TeamViewerrel vagy VPN-nel), admin jogosultsággal dolgozik, de nincs nyilvántartva, nincs jóváhagyva, nincs időkorlátozva, és nincs rendszeres felülvizsgálata.
Az auditor ilyenkor azt vizsgálja, van-e beszállítói nyilvántartás, hogyan történik a kockázati besorolás, milyen szerződéses elvárások vannak, és hogyan kontrolláljátok a beszállítói hozzáférést.
A jó megoldás az, ha a beszállítókhoz kapcsolódó hozzáférések auditálhatóak, jóváhagyottak és visszavonhatóak, továbbá a szerződésekben is megjelennek a security elvárások.
10. Az oktatás „megtörtént”, csak nem bizonyítható
Az emberi tényező minden kiberbiztonsági rendszer legnagyobb gyenge pontja. Mégis sok cégnél az oktatás a leggyengébben dokumentált terület. Az auditor ilyenkor azt fogja kérdezni, kik kaptak képzést, milyen gyakran, milyen tematika alapján, és hogyan mérhető, hogy a tudás beépült.
Különösen fontos a belépő dolgozók oktatása, a kilépők hozzáféréseinek lezárása, és a célzott oktatások, például adminok vagy OT-s kollégák számára. A megfelelés ott bukik el, ahol a tréning csak egy „megtartott alkalom”, de nincs nyoma.
A jó megoldás egy éves oktatási terv, jelenléti ívek vagy LMS exportok, valamint olyan tudatosító programok, mint egy phishing teszt kampány eredményének dokumentálása.