MKIK Kiberbiztonsági program – NIS2 Audit felkészítés


Erre a workshopra már nem lehet jelentkezni.

Mit tegyünk ha (még) nem sikerült a NIS2 audit? Tanácsok a sikeres felkészüléshez II.


A Magyar Kereskedelmi és Iparkamara (MKIK) kiberbiztonsági programjának 2026. július 8-i online workshopján a sikertelen NIS2-audit következményeiről, a határidőt lekéső cégek teendőiről és az auditorok által leggyakrabban kifogásolt hiányosságokról volt szó. Összefoglalónk a legfontosabb gondolatokat és a gyakorlatban is használható tanácsokat gyűjti össze.

Előadók

- Elter András, az MKIK kiberbiztonsági programjának szakmai vezetője, OSCP, CISSP

- Csendes Sándor, szenior IT biztonsági tanácsadó, RESCON Kft.

- Dr. Szakolyi András, CISA, adatvédelmi szakjogász, mesterséges intelligencia és technológiai jogi szakjogász, ISO 27001 és ISO 42001 LA, IBF, DPO

A LEGFONTOSABB ÜZENETEK RÖVIDEN

- A sikertelen NIS2-audit nem jelent azonnali bírságot. A 70 pont alatti SZEKI-eredmény után intézkedési tervet kell benyújtani az SZTFH-nak, és negyedévente beszámolni a teljesítéséről.

- A Kiberbiztonsági törvény hatálya alá későn kerülő cégnek haladéktalanul pótolnia kell a nyilvántartásba vételt az SZTFH-nál, szerződnie kell egy auditorral, és be kell mutatnia egy konkrét audittervet.

- Az elektronikus információs rendszerek (EIR) határainak kijelölése a NIS2-felkészülés egyik legfontosabb döntése. Sem egyetlen óriás EIR, sem harminc apró rendszer nem jó megoldás.

- A NIS2-auditon az a szabályzat bukik el, amely pontos gyakoriság helyett „rendszeres” felülvizsgálatot ír, vagy sablonból, idegen logóval, MI-párbeszéd nyomaival került a dossziéba.

- Az MKIK SecureBot ingyenes sérülékenységvizsgálata olyan jelentést ad, amely a NIS2-auditon bizonyítékként is bemutatható.

Mi történik, ha nem sikerült a NIS2-audit?

Ha a szervezet ellenálló-képességi indexe (SZEKI) 70 alatt marad, a NIS2-audit eredménye „nem megfelelt”. Ez azonban nem jár azonnali szankcióval. A cégnek intézkedési tervet kell készítenie, és jóváhagyásra be kell nyújtania a Szabályozott Tevékenységek Felügyeleti Hatóságának (SZTFH). A jóváhagyás után negyedévente státuszjelentést küld a hatóságnak arról, hogyan halad a terv mérföldköveivel.

Nincs egyedül, aki elakadt. Iparági becslések szerint az első hullámban auditált cégek mintegy harminc százaléka nem felelt meg elsőre, ami az auditorok jelentős leterheltségét vetíti előre. Érdemes tehát időben auditort foglalni.

Kapcsolódó iránymutatások és állásfoglalások

- Sikertelen audit után hogyan készítsünk intézkedési tervet? (iránymutatás)

- Mi történik, ha nem felel meg egy cég az auditon? (állásfoglalás)

- Van-e élet az audit után? Mire figyeljünk, hogy a következő auditon is átmenjünk? Hogyan alakítsunk ki hosszú távon fenntartható IBIR-t? (állásfoglalás)

Lekéste a határidőt? Így zárkózhat fel a későn ébredő cég

A Kiberbiztonsági törvény hatálya alá későn kerülő cégnek a workshop idején (2026. július) jó esélye volt elkerülni a bírságot, ha gyorsan lép. Az SZTFH deklarált célja a jogkövető magatartás elérése, nem a büntetés. Három lépés kell hozzá. A cég haladéktalanul pótolja a nyilvántartásba vételt az SZTFH-nál, szerződjön egy minősített auditorral, és mutasson be egy konkrét dátumot tartalmazó audittervet.

Előtte érdemes átnézni a cégkivonatot. Sok vállalkozás egy régen bejegyzett, de évek óta nem gyakorolt tevékenység (például veszélyes hulladék kezelése) miatt kerül a törvény hatálya alá. Ilyenkor a leggyorsabb megoldás a felesleges tevékenységi kör törlése. A szabályok lényegi enyhülésére viszont nem érdemes várni, mert a NIS2-irányelv szigorú keretet ad, a hazai követelmények pedig a NIST SP 800-53 és az ISO 27001 módszertanára épülnek.

Kapcsolódó iránymutatások és állásfoglalások

- Mi a teendő, ha egy cég tevékenységének csak egy része tartozik a Kiberbiztonsági tv. hatálya alá? (állásfoglalás)

- Csökkenti-e a 2025. évi CXXXV. törvény a NIS2 kötelezettek körét? (iránymutatás)

- Elvárások a NIS2 felkészítőkkel szemben, egy felkészítő megbízásának részletei (állásfoglalás)

Hogyan jelöljük ki az EIR-ek határait?

Az EIR-ek logikai határainak kijelölése a NIS2-felkészülés egyik legfontosabb stratégiai döntése. Elektronikus információs rendszer minden olyan eszköz vagy eszközcsoport, amely digitális adatot kezel automatikusan, a munkaállomástól a mobiltelefonon és a vállalatirányítási rendszeren át az ipari vezérlőig. A teljes infrastruktúra egyetlen EIR-be vonása nem jó ötlet, a túlaprózás sem. Az egyik szervezet harminc rendszert definiált, és így harminc rendszerbiztonsági tervet és harminc üzletmenet-folytonossági tervet kellett volna megírnia.

Bevált megoldás a funkció, a biztonsági osztály vagy a technológia szerinti bontás. Külön EIR lehet az általános IT-infrastruktúra, a publikus webes felület, a backoffice (HR, pénzügy), a fejlesztői környezet és az OT. Egy EIR-be átlagosan legfeljebb négy-öt szorosan összefüggő szakrendszer kerüljön. A végeredményt a vizsgált EIR-ek védelmi megfelelőségi indexeiből (VMI) számolt SZEKI adja, így egy jól védett, korszerű rendszer részben ellensúlyozhatja egy elavult rendszer pontveszteségét.

Kapcsolódó állásfoglalások

- Nem támogatott operációs rendszerek NIS2-kompatibilis használata (állásfoglalás)

- EIR-ek változásai auditok között, új rendszer bevezetése, rendszerkivezetés (állásfoglalás)

Miért bukik el a NIS2-auditon a jó szándékú dokumentáció?

A leggyakoribb auditori kifogás a határozatlan, „jolly joker” szavak használata. „A szervezet meghatározott időnként felülvizsgálja a naplófájlokat” mondat nem fogadható el. Senki nem írna alá olyan munkaszerződést, amely „rendszeres, meghatározott összegű fizetést” ígér számok nélkül, és az auditor ugyanígy pontos gyakoriságot vár (hetente, havonta, félévente).

A leírtakat bizonyítani is kell. A jegyzőkönyvből derüljön ki, ki, mikor, melyik rendszeren, milyen eredménnyel végezte a vizsgálatot (például 1800 bejegyzésből négy kritikus riasztás), és ki hagyta jóvá. A „kis cég vagyunk, mindent megbeszélünk” válasz nem bizonyíték, erre jó egy egyszerű jegykezelő rendszer, például a nyílt forráskódú Redmine vagy a Jira. Azonnal elveszíti az auditor bizalmát az a sablonból összeollózott szabályzat, amelynek fejlécében más cég logója maradt, vagy a szövegében benne felejtett MI-kérdés áll („Szeretnéd, hogy a következő bekezdést is szabályzati formában fogalmazzam meg?”).

Kapcsolódó iránymutatások és állásfoglalások

- A jegykezelő rendszer bejegyzései jogilag elfogadhatóak-e audit bizonyítékként? (állásfoglalás)

- IBSZ és egyéb IBIR dokumentumok jóváhagyása és közlése (állásfoglalás)

- IBF szolgáltatás igénybevétele esetén javasolt szervezeti elvárások és az elektronikus információs rendszerek biztonságáért felelős személy megbízásának részletei (iránymutatás)

Felhő és anyavállalat. Ki felel a kontrollokért?

A magyar leányvállalat a rendelkezési joga mértékéig felel a felhőben (például Microsoft 365) vagy az anyavállalatnál (például egy külföldi adatközpontban futó SAP-ban) működő rendszerek kiberbiztonságáért. Azokat a kontrollokat, amelyekre nincs ráhatása, például a szolgáltató szervertermének páratartalom-mérése, helyettesítő vagy kizárt intézkedésként kell dokumentálni. Anyavállalati szolgáltatásnál ehhez az anyavállalat IT-vezetése által aláírt nyilatkozat kell, a szóbeli hivatkozás kevés. Ahol viszont a helyi cégnek adminisztrátori jogai vannak, például a hozzáférések kezelésében, azért ő maga felel.

Kapcsolódó iránymutatások és állásfoglalások

- Anyavállalat, mint EIR beszállító kezelése a NIS2 audit felkészülés során (iránymutatás)

- Rendelkezési jog, avagy egy külföldi székhelyű anyavállalat által üzemeltetett ERP-t fel kell-e venni az EIR-ek közé? (állásfoglalás)

- Cégcsoporton belüli IT szolgáltató cég kiemelten kockázatos tevékenységet végző közreműködőnek vagy kihelyezett szolgáltatónak számít-e? (állásfoglalás)

Hozzáférés, naplózás, konfiguráció. Hol hibáznak a legtöbben?

A 7/2024. (VI. 24.) MK rendelet tizenkilenc követelménycsoportja közül a workshopon néhány visszatérő buktató kapott külön figyelmet.

- Közös fiókok. A több ember által használt fiók megszünteti az egyéni elszámoltathatóságot, ezért csak kivételes esetben, kompenzáló kontrollokkal tűrhető. A rendszergazdának külön adminisztrátori fiók jár, a többtényezős hitelesítés (MFA) pedig az adminisztrátori és a távoli hozzáférésnél alapelvárás.

- Naplózás. Központi naplóelemző (SIEM, például Wazuh vagy Graylog) javasolt, de kisvállalkozásnál a helyi naplózás is elfogadható, ha az IBF a kockázatkezelésben dokumentálja, a vezetés jóváhagyja, és a naplók sértetlensége és rendszeres átnézése biztosított.

- Biztonsági értékelés. Mérhető mutatók kellenek, például a kritikus frissítések telepítési aránya vagy a 90 napja inaktív fiókok száma.

- Alapkonfiguráció. Annyira részletes legyen, hogy a szakértők hasonlatával élve akkor is újraépíthető legyen belőle a rendszer, ha egy meteorit elpusztítja az IT-t, és a Marsról kell hozni egy rendszergazdát. Ha egyszerre 24 switchet frissítenek, elég egy összesítő jegyzőkönyv a sorozatszámokkal és a firmware-verziókkal.

Kapcsolódó állásfoglalások

- Többfaktoros hitelesítés (MFA) milyen esetekben kötelező „Alap” biztonsági osztályban? (állásfoglalás)

- Elavult rendszerek naplózása (állásfoglalás)

- A folyamatos felügyeleti stratégia előírt tartalma és az ajánlott mérőszámok (állásfoglalás)

- Hardening. Mennyire ellenálló a rendszerünk? Hogyan határozzuk meg, vezessük be és tartsuk fenn rendszereink biztonsági alapkonfigurációját? (állásfoglalás)

Mit vár el az auditor az üzletmenet-folytonosságtól és az incidenskezeléstől?

Az üzletmenet-folytonossági terv alapja az üzleti hatáselemzés (BIA), amely kijelöli a kritikus folyamatokat, a kulcsembereket, a tűrhető adatvesztést (RPO) és a helyreállítási időt (RTO). BIA nélkül a terv megalapozatlan. A workshopon elhangzott példában egy autóalkatrész-kereskedő egy zsarolóvírus-támadás miatt egy hónapra megbénult, pedig tesztelt offline mentésekkel ez elkerülhető lett volna. Az auditor a tesztelés jegyzőkönyvét is kéri, ami lehet egy asztali szimulációs gyakorlat is.

A súlyos incidenst 24 órán belül jelezni kell a Nemzeti Kibervédelmi Intézetnek (NKI), amelynek célja a fenyegetés továbbterjedésének megállítása, nem a bírságolás. Ehhez olyan riasztási lánc kell, amely munkaidőn túl, hétvégén és ünnepnapon is működik.

Kapcsolódó állásfoglalások

- Biztonsági eseménykezelés és üzletmenet-folytonosság. Az egyes szabályozási területek eltérő hatóköre és kapcsolódása (állásfoglalás)

- Mikro- és kisvállalkozások számára ajánlott mentési stratégia és mentőeszközök (állásfoglalás)

- Milyen információkat kell a hatóságnak bejelenteni kiberbiztonsági incidens esetén? (állásfoglalás)

Az ember, a papír és a beszállító is auditált terület

A NIS2-audit a munkatársak felkészítését, az adathordozókat és a beszállítókat is vizsgálja. Az általános tudatossági képzés mellett szerepkör szerinti oktatás is kell (például az IT-üzemeltetőknek és az adatgazdáknak), és a megtörténtét jelenléti ívvel vagy e-learning naplóval, az eredményét teszttel vagy szimulált adathalász kampánnyal kell igazolni. Gyakori bukópont az adathordozók kezelése. Az USB-eszközök használatát korlátozni és naplózni kell, és a rendelet a papíralapú iratokat is adathordozónak tekinti, ezért a tiszta asztal elve is vizsgált terület. A kritikus IT-beszállítókat rendszeresen értékelni kell, a kiberbiztonsági követelményeket pedig bele kell írni a szerződésekbe.

Kapcsolódó iránymutatások és állásfoglalások

- Milyen oktatásokat kell elvégezni a NIS2 megfeleléshez és hogyan kell azokat végrehajtani? (iránymutatás)

- Külső adathordozók NIS2-kompatibilis használata (állásfoglalás)

- Biztonságos törlési megoldások (iránymutatás)

- Hogyan ellenőrizheti egy NIS2 kötelezett cég az általa megbízott közreműködő kiberbiztonsági megfelelését? (állásfoglalás)

SecureBot, avagy ingyenes sérülékenységvizsgálat kkv-knak

Az MKIK SecureBot a kkv-k számára térítésmentes kiberbiztonsági szolgáltatáscsomag, amely a NIS2-auditra való felkészülést is segíti. Regisztráció és a jogi nyilatkozatok feltöltése után a cég megadhatja a publikus IP-címeit és weboldalait, a rendszer pedig külső támadói szemmel átvizsgálja őket elavult szoftverek, hibás beállítások és kint felejtett fájlok után kutatva. Az eredmény javítási javaslatokat tartalmazó PDF-jelentés, amely az auditon a sérülékenységvizsgálat bizonyítékaként is bemutatható.

Az automata riasztórendszer (ARR) csak akkor küld e-mailt, ha a cég által megjelölt termékeket (például Cisco, Fortinet vagy Microsoft) kritikus sérülékenység érinti, vagy az NKI célzott figyelmeztetést ad ki. A harmadik elem a megbízható hazai IT-beszállítók adatbázisa.

Kapcsolódó iránymutatás

- A Kiberbiztonsági törvény szerinti sérülékenységvizsgálat, sérülékenységkeresés, behatolásvizsgálat elhatárolása és jogi háttere (iránymutatás)

Mit tegyen most egy kkv?

- Ha nem sikerült a NIS2-audit, készítsen reális határidős intézkedési tervet, és tartsa a negyedéves beszámolást az SZTFH felé.

- Ha későn derült ki az érintettség, nézze át a cégkivonatát, és pótolja haladéktalanul a nyilvántartásba vételt és az auditori szerződést.

- Jelölje ki úgy az EIR-eket, hogy egy-egy rendszerbe legfeljebb négy-öt összetartozó szakrendszer kerüljön.

- Cserélje a szabályzatokban a „rendszeres” szót pontos gyakoriságra, és gyűjtse a bizonyítékokat jegykezelő rendszerben.

- Futtasson SecureBot-vizsgálatot a publikus rendszereire, és tegye a jelentést az audit dossziéjába.

A program iránymutatásai és szakértői állásfoglalásai a nis2.mkik.hu oldalon érhetők el. Egyedi kérdésekben térítésmentes egyéni konzultáció is igénybe vehető.

« Vissza a korábbi workshopokhoz