A NIS2-re való felkészülés egyik sarkalatos kérdése a szervezeten belül az elektronikus információs rendszerek (EIR) pontos azonosítása. Elég fontos kérdés önmagában is, de az 1/2025. SZTFH rendelet (a kiberbiztonsági audit lefolytatásának rendjéről és a kiberbiztonsági audit legmagasabb díjáról) óta, ez már konkrétan zsebre is megy.

A kötelezett szervezetek audit díjának meghatározásában egyik igen fontos paraméter a szervezet elektronikus információs rendszereinek darabszáma. Öt darab EIR-ig az SZTFH-képlet vonatkozó szorzószáma egyes, hat EIR-nél már 2.5-es. Minden más paraméter (szorzószám) azonossága mellett ez az egy döntés, az audit -egyébként sem olcsó- díját akár 2.5-szeresére is emelheti!

Azaz, érdemes alaposan átgondolni a szervezet elektronikus információs rendszereinek kérdését.

Sajnos ez a cikk sem fogja tudni megmondani a pontos választ minden kérdésre, ez nem is lehet a célunk, hiszen az EIR-ek azonosítása tekintetében is igaz az „attól függ”.

Az elmúlt néhány évtized auditálásai során láttuk is, és el is mondtuk, mondjuk azóta is a legfontosabbat: minden szervezet más! Mindenhol egyedi sajátosságok, paraméterek alapján lehet és kell eldönteni nagyon sok ilyen kérdést. Ezeknek a kérdéseknek a feltevésében próbálunk meg most segítséget nyújtani.

Csak dióhéjban. In nuce…

Definíciók

Először is a jogszabály (2024. évi LXIX. törvény Magyarország kiberbiztonságáról) szerint az elektronikus információs rendszer:

1. az elektronikus hírközlésről szóló törvény szerinti elektronikus hírközlési hálózat,
2. minden olyan eszköz vagy egymással összekapcsolt vagy kapcsolatban álló eszközök csoportja, amelyek közül egy vagy több valamely program alapján digitális adatok automatizált kezelését végzi, ideértve a kiber-fizikai rendszereket, vagy
3. az a) és b) alpontban szereplő elemek által működésük, használatuk, védelmük és karbantartásuk céljából tárolt, kezelt, visszakeresett vagy továbbított digitális adatok.

Csak megjegyzés: az EU 2022/2555-ös (NIS 2) irányelve a „hálózati és információs rendszer” fogalmat használja, többé-kevésbé a fenti hármas definícióval.

Egy igen komoly segítség található Az információbiztonság alapjai kiadvány 1.2. fejezetében, Dr. Muha Lajostól:

„Fontos, hogy összhangban a rendszerelmélettel, valóban rendszerről és ne berendezések, eszközök valamiféle halmazáról beszéljünk. Ludwig von Bertalanffy szerint: „A rendszer egymással kölcsönhatásban álló elemek olyan együttese, amelyre bizonyos rendszertörvények alkalmazhatók. Az elem a rendszer olyan része, összetevője, amelyet az egész vizsgálata érdekében célszerű megkülönböztetni.” Ezek az elemek:

Információs rendszer az adatok, információk kezelésére használt eszközök (környezeti infrastruktúra, hardver, hálózat és adathordozók), eljárások (szabályozás, szoftver és kapcsolódó folyamatok), valamint az ezeket kezelő személyek együttese.

Az információs rendszerekhez tartoznak:

1. a számítástechnikai rendszerek és hálózatok, ideértve az internet szolgáltatást is;
2. a helyhez kötött, mobil és egyéb rádiófrekvenciás, valamint műholdas elektronikus hírközlési hálózatok, szolgáltatások;
3. a vezetékes, a rádiófrekvenciás és műholdas műsorszórás;
4. a rádiós vagy műholdas navigációs rendszerek;
5. az automatizálási, vezérlési és ellenőrzési rendszerek (vezérlő és adatgyűjtő, távmérő, távérzékelő és telemetriai rendszerek stb.);
6. a fentiek felderítéséhez, lehallgatásához vagy zavarásához használható rendszerek.”

Önállóság

Az önálló elektronikus információs rendszer tehát olyan informatikai rendszer, amely önállóan képes bizonyos funkciók ellátására, és amely különáll más rendszerektől biztonsági, szervezeti vagy funkcionális szempontból. Az önállóságot több tényező határozza meg, például a rendeltetés, a tulajdonviszony, a felügyeleti struktúra vagy a technológiai függetlenség, tehát az önálló elektronikus információs rendszer fogalma nem technikai, hanem üzleti-funkcionális és biztonsági szempontból értelmezhető.

Az önálló rendszer jellemzői:

1. Célhoz kötött: Egy meghatározott üzleti célhoz, szolgáltatáshoz, folyamathoz kötődik.
2. Technológiai integráció: A rendszer technikailag összefüggő, közös működési logikát vagy platformot használ.
3. Kockázati szempontból különálló: Ha a rendszer biztonsági kockázatai, fenyegetettségei és sérülékenységei külön kezelendők.
4. Üzemeltetési szempontból elhatárolható: Ha a rendszer önállóan fejleszthető, frissíthető, auditálható, akkor külön veendő.

Mit lehet egyben kezelni?

Több informatikai rendszert egy rendszerként lehet kezelni, ha:

• Ugyanazt a szolgáltatást támogatják (pl. egy webáruház frontendje + backend + adatbázis)
• Együttesen működnek (pl. mikroszolgáltatásos architektúrában több komponens, de ugyanazt a szolgáltatást nyújtják)
• Funkcionálisan összetartozó egységet alkotnak (pl. egy vállalat belső HR rendszere, amely több alrendszerből áll, de együttműködik)
• Ugyanaz a kockázati profiljuk, és egyetlen eseménykezelési rendszer alá esnek (pl. egy e-kereskedelmi platform fizetési rendszere és raktárkezelője, ha ugyanaz a csapat felügyeli)
• Közös biztonsági irányítás alatt állnak (pl. egy felhőalapú ERP rendszer különböző moduljai, egy egészségügyi intézmény betegregisztrációs és receptíró rendszere, ha egy adatvédelmi szabályzat vonatkozik rájuk)
• Ugyanaz a jogi entitás felelős érte (pl. egy bank online banking rendszere és mobilalkalmazása).

Mit kell külön venni?

Külön rendszerként kell kezelni azokat, amelyek:

• Más célú szolgáltatásokat, különálló feladatokat támogatnak (pl. HR rendszer vs. ERP vs. webshop, egy logisztikai nyomkövető rendszer vs. egy termelési tervező szoftver)
• Más felelősségi körhöz tartoznak (pl. külön üzletág vagy szolgáltató kezeli)
• Más biztonsági osztályba tartoznak (pl. egyik nyilvános, másik szigorúan védett)
• Különböző célú, nem összekapcsolt rendszerek, más infrastruktúrán futnak, nincs közvetlen adatcsere (pl. egy kórház betegadat-kezelő rendszere és a pénzügyi szoftvere, két különálló adatbázis, amelyek nem kommunikálnak egymással)
• Függetlenül működnek és külön biztonsági szabályzat vonatkozik rájuk (pl. egy önkormányzat közúti kamerarendszere és a közigazgatási dokumentumkezelője)
• Különböző jogi felelősség alá tartoznak (pl. egy leányvállalat informatikai rendszere és anyavállalaté, egy egyetem hallgatói portálja vs. kutatói adattárháza).

Fontos a NIS2 szempontjából

A NIS2 kiemelt hangsúlyt fektet a kritikus fontosságú rendszerek azonosítására. Ha egy rendszer önállóan kritikus funkciót lát el (pl. energiaszolgáltató SCADA rendszere), akkor külön kockázatértékelés és biztonsági intézkedések szükségesek, még ha más rendszerekkel együtt is üzemel.

Mindenképpen kiemelendő még, hogy nem csak az EIR-ek szempontjából, de nagyon sok egyéb szempontból is (például GDPR) minden ilyen döntés alapja a kockázatelemzés és az üzleti hatáselemzés. Csak ezek alapján tudunk megalapozott döntéseket hozni (és azt a döntést adott esetben hatékonyan megvédeni!) az elektronikus információs rendszerek besorolásáról (is).

Néhány kérdés az elektronikus információs rendszerek önállóságának értékeléséhez (NIS2 szerint)

Az alábbi kérdések segítenek eldönteni, hogy egy rendszer önálló-e, vagy integráltnak tekinthető más rendszerekkel: 

1. Szervezeti és irányítási szempontok

• Ugyanaz a jogi entitás (pl. vállalat, intézmény) felelős a rendszer üzemeltetéséért? Ha nem, valószínűleg külön rendszer (pl. külső beszállító rendszere).
• Ugyanaz a belső csapat vagy osztály felügyeli a rendszert? Ha külön csapatok kezelik (pl. IT és termelés), inkább önálló.
• Más információbiztonsági osztályba vagy kockázati kategóriába tartozik, mint a többi rendszer? Igen esetén önálló rendszerként kell kezelni.
• Külön biztonsági szabályzat és kockázatkezelési terv vonatkozik rá? Ha igen, önálló rendszernek minősül.

2. Funkcionális és technikai összefüggések

• A rendszer különálló feladatot lát el, vagy szorosan kapcsolódik más rendszerek működéséhez? Pl. egy logisztikai nyomkövető vs. pénzügyi számlázó – eltérő cél = önálló.
• Önállóan is működőképes a rendszer, vagy csak egy másik rendszerrel együtt működik? Ha csak egy másik rendszerrel együtt működőképes, nem biztos, hogy önálló.
• Közvetlen adatcsere történik más rendszerekkel? Ha igen, milyen gyakran és mennyire automatizált? Minél kevésbé integrált, annál inkább önálló (pl. kézi adatátvitel vs. valós időben szinkronizált API).
• Független infrastruktúrán (szerver, hálózat, felhő) fut, vagy megosztott erőforrásokat használ? Pl. két rendszer ugyanazon az AWS-fiókban vs. fizikailag elkülönített adatközpontokban.
• A felhős szolgáltatásunk milyen konstrukcióban van? Pl. IaaS, Paas, SaaS? Mi mennyire lehetünk hatással a konfigurálásokra, hozzáférésekre, mentésekre, üzleti folyamatok beállítására stb.

3. Biztonsági és jogi megfontolások

• A rendszer kockázatai függetlenek más rendszerektől? Pl. egy kórház betegadat-rendszerének megszegése nem érinti a lámpákat vezérlő IoT eszközöket.
• Külön adatvédelmi vagy szabályozási követelmények vonatkoznak rá? Pl. GDPR-ra kötelezett CRM vs. ipari vezérlőrendszer, amelyre más szabványok érvényesek.
• Ha egy rendszer meghibásodik, az hatással van más rendszerekre? A rendszer kiesése önállóan is kockázatot jelent az üzletmenetre? Ha nincs láncreakció (pl. egy e-mail szerver leállása nem befolyásolja a gyártási robotokat), önálló. Ha igen, önállónak értelmezhető.

4. Üzleti folyamatok és tulajdonviszony

• Külön üzleti folyamat része? Ha eltérő üzleti célt szolgál, valószínűleg önálló.Pl. egy webshop rendeléskezelője vs. szállítói beszerzési rendszer – más folyamatok = önálló.
• Külső partner vagy saját fejlesztésű rendszerről van szó? Külső SaaS megoldások (pl. Salesforce) gyakran függetlenek a belső rendszerektől.
• Más-más szolgáltatási szintet (SLA-t) biztosítanak a rendszerekre? Eltérő SLA különállóságra utal.
• Elkülönített frissítési/fenntartási időszakokkal rendelkezik? Ha a karbantartás nem érint más rendszereket (pl. külön karbantartási ablakok), önálló.

Kérdéses

A végére csak néhány kérdés:

• Ha a szervezet alkalmazottja a szervezet elektromos autójával (ami „digitális adatok automatizált kezelését végzi”) szervezeti dokumentumokat szállít, akkor az elektromos autót, azt a szervezet elektronikus információs rendszerei közé kell sorolnunk?
• A céges kamerarendszer a szervezet EIR-jei közé tartozik, akkor is, ha ugyan a szervezet épületében van felszerelve, a szervezet látogatóit, munkatársait rögzíti, de nem a szervezet üzemelteti?
• A Microsoft 365 rendszerei szervezeti EIR-nek minősülnek-e, hiszen igen korlátozottak a beállításaikkal/adatkezeléseikkel kapcsolatos lehetőségei a felhasználó szervezeteknek?

A válasz mindegyikre azonos: attól függ…

nuce.hu

Az Európai Unió Általános Adatvédelmi Rendeletének (GDPR) 32. cikke az adatkezelés biztonságára vonatkozó követelményeket határozza meg. Ez a cikk kulcsfontosságú az adatvédelmi megfelelés szempontjából, mivel előírja, hogy az adatkezelőknek és adatfeldolgozóknak megfelelő technikai és szervezési intézkedéseket kell bevezetniük a személyes adatok védelme érdekében. A GDPR hazai bevezetésében közreműködő jogászok ennek a megvalósításáig általában nem jutnak el, és nem véletlenül.

Kockázatalapú megközelítés

A GDPR 32. cikke kockázatalapú megközelítést alkalmaz. Ez azt jelenti, hogy az adatkezelőknek és adatfeldolgozóknak figyelembe kell venniük többek között:

• a technológia aktuális állását,
• a megvalósítás költségeit,
• az adatkezelés jellegét, hatókörét, körülményeit és céljait,
• valamint a természetes személyek jogaira és szabadságaira jelentett kockázat valószínűségét és súlyosságát.

Ezek alapján kell meghatározniuk és megvalósítaniuk a megfelelő biztonsági intézkedéseket.

Ajánlott technikai és szervezési intézkedések

A 32. cikk példákat is felsorol az alkalmazható intézkedésekre:

• a személyes adatok álnevesítése és titkosítása,
• a feldolgozási rendszerek és szolgáltatások folyamatos bizalmasságának, integritásának, rendelkezésre állásának és ellenálló képességének biztosítása,
• a személyes adatokhoz való hozzáférés és rendelkezésre állás gyors helyreállításának képessége fizikai vagy technikai incidens esetén,
• a biztonsági intézkedések hatékonyságának rendszeres tesztelése, értékelése és felülvizsgálata.

Felelősségi körök

Az adatkezelőnek és az adatfeldolgozónak biztosítania kell, hogy minden olyan természetes személy, aki az ő irányításuk alatt jár el és hozzáfér a személyes adatokhoz, csak az adatkezelő utasításai alapján kezelheti azokat, kivéve, ha az uniós vagy tagállami jog másként írja elő.

Gyakorlati tanácsok a megfeleléshez

A GDPR 32. cikkének való megfelelés érdekében az alábbi lépések ajánlottak:

1. Kockázatértékelés elvégzése: Azonosítsa és értékelje a személyes adatok kezelésével kapcsolatos kockázatokat.
2. Megfelelő intézkedések bevezetése: Alkalmazzon technikai és szervezési intézkedéseket, mint például titkosítás, hozzáférés-szabályozás és rendszeres biztonsági tesztelés.
3. Dokumentáció: Rögzítse az összes biztonsági intézkedést és azok hatékonyságának értékelését.
4. Munkavállalók képzése: Biztosítsa, hogy minden érintett munkatárs tisztában legyen az adatvédelmi kötelezettségekkel és a biztonsági protokollokkal.
5. Rendszeres felülvizsgálat: Évente vagy jelentős változások esetén vizsgálja felül és frissítse a biztonsági intézkedéseket.

A 32. cikk betartása nemcsak jogi kötelezettség, hanem alapvető lépés a személyes adatok védelme és az adatkezelés biztonságának biztosítása érdekében.

nuce.hu

Az Európai Unió 2025 tavaszán nagyszabású felülvizsgálatot indított az Általános Adatvédelmi Rendelet (GDPR) kapcsán, különös tekintettel a kis- és középvállalkozások (KKV-k) adminisztratív terheinek csökkentésére. A változások célja, hogy egyszerűsítsék a jelenlegi szabályokat, amelyek sok vállalkozás szerint túl bonyolultak és költségesek.

A Bizottság javaslata szerint a kevesebb mint 750 alkalmazottat foglalkoztató szervezetek számára enyhítenék a dokumentációs és nyilvántartási kötelezettségeket. Az ígéretek szerint ez csökkentené a vállalkozásokra nehezedő adminisztratív terheket, és javítaná versenyképességüket a globális piacon.

Ugyanakkor a felülvizsgálattal kapcsolatban több aggály is felmerült. Adatvédelmi szakértők és civil szervezetek attól tartanak, hogy a szabályok lazítása gyengítheti a magánszemélyek adatainak védelmét. Felhívják a figyelmet arra, hogy a GDPR épp azért vált nemzetközi szinten is mércévé, mert szigorúan védi az egyének jogait – ennek felvizezése hosszú távon visszaüthet.

További aggodalomra ad okot, hogy az egységes adatvédelmi elveket a tagállamok eltérően értelmezhetik, ami gyengítheti a rendelet egységét. Az Európai Adatvédelmi Testület (EDPB) ezért javasolta, hogy a tagállami adatvédelmi hatóságok gyakorlatát rendszeresen értékeljék, hogy elkerülhetők legyenek a jelentős eltérések.

A változtatással kapcsolatos aggályokat 108 szervezet közös nyílt levélben jelezte. Ezek szerint a javasolt változtatások azzal a kockázattal járnak, hogy nem érik el a valódi egyszerűsítés célját, és ehelyett a kulcsfontosságú elszámoltathatósági biztosítékokat, és velük együtt magát az elszámoltathatósági elvet is visszavonhatják.

Az újratárgyalás után a GDPR sebezhetővé válhat a szélesebb körű deregulációs igényekkel szemben. Számos ilyen nyomás már látható, beleértve a hozzájárulásra vonatkozó szabályok gyengítésére irányuló felhívásokat a felhasználók számára hatékony biztosítékok nélkül, vagy a személyes adatok mesterséges intelligencia-képzéshez való erőszakos felhasználásának legitimálását.

A nyílt levélben a geopolitikai kontextust is megemlítik. Az elmúlt években a külföldi kereskedelmi és politikai szereplők az EU digitális védelmének lazítására irányuló felhívásai következetesen a GDPR gyengítésére irányuló kísérletekkel kezdődtek, amely stratégia mára kiterjedt az egész EU technológiai szabálykönyvére, beleértve a digitális szolgáltatásokról szóló törvényt (DSA), a digitális piacról szóló törvényt (DMA) és a mesterséges intelligencia törvényt (AI Act) – és már folyamatban van a vállalati elszámoltathatóság és a környezeti igazságosság terén.

A GDPR hivatalos újraértékelésére 2027-ben kerül sor, de a 2025-ös reformcsomag már most is jelentős hatással lehet az adatkezelés európai jövőjére. A kihívás az, hogy megtaláljuk az egyensúlyt a vállalkozások adminisztratív terheinek csökkentése és a személyes adatok védelmének szavatolása között.

A változások végleges formája még kérdéses, de az biztos: a GDPR korszakának következő fejezete már elkezdődött.

nuce.hu

Az előttünk álló időszakban a NIS 2 hazai bevezetésével kapcsolatban a legfontosabb kihívások és legsürgősebb feladatok az alábbiak lehetnek:

1. Auditokra való felkészülés

• Határidő: Az első kötelező auditok határideje sok szervezetnél 2025. december 31., így a nyár kulcsidőszak a felkészüléshez.

• Szakemberhiány: Kevés az auditor és a felkészült, hozzáértő tanácsadó, ezért már most nehéz időpontokat foglalni. Akik késlekednek, azok nem biztos, hogy teljesíteni tudják a törvényi határidőt.

2. Rendszer- és folyamatfejlesztés

• Hiányos IT-biztonsági rendszerek: Számos érintett szervezetnél nincsenek megfelelő kockázatkezelési és incidens-reakciós mechanizmusok.

• Dokumentáció hiány: A szabályozás részletes IT-biztonsági dokumentációt vár el, amit sok szervezetnek most kell kialakítania, kiegészítenie.

3. Tudatosság és vezetői felelősség

• Menedzsment felkészítése: A vezetői felelősség hangsúlyosabb lett, így a felsővezetők oktatása, bevonása sürgető feladat.

• Belső oktatás: A munkavállalók kiberbiztonsági tudatossága még mindig alacsony – a nyár ideális időszak lehet belső képzésekre.

4. Kapcsolattartás a hatóságokkal

• SZTFH iránymutatások követése: A Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH) folyamatosan ad ki új tájékoztatókat – ezek nyomon követése és beépítése a gyakorlatba kulcsfontosságú.

• Nyilvántartásba vétel és megfelelés igazolása: Akik még nem regisztráltak, haladéktalanul pótolniuk kell.

Összegzés:

A nyár döntő időszak lesz a megfelelés szempontjából. Aki most nem kezd bele komolyan a felkészülésbe – különösen az audit lebonyolításához szükséges feltételek megteremtésébe – komoly bírságokat és működési kockázatokat vállal.

nuce.hu

Az Európai Unió jelenleg fontolgatja a 2018-ban életbe lépett Általános Adatvédelmi Rendelet (GDPR) jelentős módosítását. Ursula von der Leyen, az Európai Bizottság elnöke vezetésével a Bizottság a GDPR egyszerűsítését célzó javaslat benyújtását tervezi a következő hetekben. Ennek célja az adminisztratív terhek csökkentése és az európai vállalkozások, különösen a kis- és középvállalkozások versenyképességének növelése.

A GDPR-t Európa egyik legösszetettebb jogszabályának tekinti a technológiai szektor, amely a 2018-as bevezetése óta igen komoly felfordulást okozott. Most, hét évvel később Brüsszel előveszi az ollót, hogy finomítsa a híres-hírhedt adatvédelmi törvényét.

Michael McGrath ír EU-biztos megerősítette, hogy a GDPR módosítása szerepel egy közelgő omnibusz jogalkotási csomagban, amelynek célja a szabályozási terhek enyhítése. Kiemelte, hogy különösen a kis- és középvállalkozásokra vonatkozó nyilvántartási kötelezettségek felülvizsgálata van napirenden.

Az elmúlt időszakban egyes kritikusok, mint például Caroline Stage Olsen dán digitális miniszter és Mario Draghi volt olasz miniszterelnök, aggodalmukat fejezték ki a GDPR összetettsége miatt, amely szerintük akadályozza az üzleti hatékonyságot és a gazdasági növekedést. Fontos azonban megjegyezni, hogy a GDPR a személyes adatok védelmének globális mércéjévé vált, így bármilyen gyengítésére irányuló kísérlet erős ellenállásba ütközhet.

"Sok jó dolog van a GDPR-ban, és az adatvédelem teljes mértékben szükséges. De nem kell ostoba módon szabályoznunk. Meg kell könnyítenünk a vállalkozások és a vállalatok számára, hogy megfeleljenek" - mondta Caroline Stage Olsen dán digitális miniszter a múlt héten újságíróknak. 2025 második felében Dánia elnököl az EU Tanácsában, soros elnöksége részeként.

A Bizottság korábban közölte, hogy az egyszerűsítési terv az 500 főnél kevesebbet foglalkoztató szervezetek jelentéstételi követelményeire fog összpontosítani, de nem érinti „a GDPR-rendszer alapvető célkitűzését”.

McGrath a múlt héten megerősítette, hogy a GDPR egyszerűsítésére vonatkozó javaslat az elkövetkező hetekben esedékes. A Bizottság azt tervezte, hogy a Bizottság ütemterve szerint április 16-ra állapodik meg a kis- és középvállalkozások úgynevezett egyszerűsítési csomagjáról, de ezt a dátumot azóta május 21-re tolták.

A módosítások részletei és azok véglegesítése még kidolgozás alatt állnak, és a következő hetekben várhatóak további információk a tervezett változtatásokról.

nuce.hu

A BlackLock ransomware-csoport, más néven "El Dorado" vagy "Eldorado", 2024 márciusában jelent meg a kiberbűnözés színterén. Azóta tevékenységük drámai növekedést mutatott: 2024 utolsó negyedévében 1425%-os emelkedést regisztráltak az adatközlési bejegyzéseik számában az előző negyedévhez képest. Ez a gyors terjeszkedés aggodalmat keltett a kiberbiztonsági szakértők körében, akik attól tartottak, hogy a BlackLock 2025-ben a legdominánsabb ransomware-szolgáltatóvá válhat.

A BlackLock sajátosságai és működési módszerei

A BlackLock egyik fő megkülönböztető jegye, hogy saját fejlesztésű malware-t használ, szemben más csoportokkal, amelyek kiszivárgott ransomware-készítőket alkalmaznak. Ez a megközelítés megnehezíti a biztonsági kutatók számára a kártevő elemzését és az ellene való védekezést. A csoport Windows, VMware ESXi és Linux rendszereket céloz meg, bár a Linux változat kevésbé fejlett.

A BlackLock kettős zsarolási taktikát alkalmaz: nemcsak titkosítja az áldozatok adatait, hanem ellopja azokat, majd a nyilvánosságra hozatallal fenyegetőzik, ha nem teljesítik a váltságdíj követeléseit. Adatközlő oldaluk (Data Leak Site - DLS) fejlett funkciókkal rendelkezik, amelyek megnehezítik a kutatók és az áldozatok számára a kiszivárgott adatokhoz való hozzáférést és azok elemzését. Ez a stratégia fokozza a nyomást az áldozatokon, hogy gyorsan fizessenek, mielőtt teljes mértékben felmérhetnék a károkat.

A Resecurity beavatkozása és eredményei

A Resecurity kiberbiztonsági vállalat szakértői felfedeztek egy sebezhetőséget a BlackLock DLS oldalán a TOR hálózaton. Ezt kihasználva hozzáfértek a csoport belső infrastruktúrájához, és értékes információkat gyűjtöttek tevékenységükről, beleértve a hálózati infrastruktúrát, a bejelentkezési időpontokat, valamint a MEGA fájlmegosztó fiókokat, amelyeket az ellopott adatok tárolására használtak. Ez az áttörés lehetővé tette a szakértők számára, hogy előre jelezzék és megelőzzék a csoport által tervezett támadásokat, valamint figyelmeztessék a potenciális áldozatokat.

2025 február 10-ig a Resecurity 46 áldozatot azonosított, akik különböző szektorokban tevékenykedtek, beleértve az elektronikát, az akadémiai intézményeket, vallási szervezeteket, védelmi ipart, egészségügyet, technológiát, IT/MSP szolgáltatókat és kormányzati ügynökségeket. Az érintett szervezetek olyan országokban működtek, mint Argentína, Aruba, Brazília, Kanada, Kongó, Horvátország, Peru, Franciaország, Olaszország, Spanyolország, Hollandia, Egyesült Államok, Egyesült Királyság és az Egyesült Arab Emírségek.

A BlackLock működési stratégiája és toborzási módszerei

A BlackLock aktívan jelen van a RAMP nevű orosz nyelvű kiberbűnözői fórumon, ahol "traffereket" toboroznak a támadások korai szakaszában való részvételre, beleértve a rosszindulatú forgalom irányítását és a kezdeti hozzáférés megszerzését. A fejlesztői és programozói pozíciók betöltése diszkrétebben történik, ami nagyobb bizalmat és hosszú távú elköteleződést igényel. Érdekes módon az affiliate toborzás gyakran megelőzi a jelentősebb támadási hullámokat, ami tudatos stratégiára utal.

Technikai részletek és támadási módszerek

A BlackLock támadásai több szakaszból állnak:

1. Kezdeti kompromittálás: Adathalász e-mailek, rosszindulatú mellékletek vagy kompromittált RDP hitelesítő adatok segítségével jutnak be a hálózatba.
2. Oldalirányú mozgás: Legális adminisztrációs eszközöket, például PowerShellt és PsExec-et használnak a hálózaton belüli mozgáshoz.
3. Jogosultság kiterjesztése: Hitelesítő adatok ellopásával magasabb szintű hozzáférést szereznek a kritikus rendszerekhez.
4. Adatexfiltráció: Az érzékeny adatok ellopása a titkosítás előtt, hogy növeljék a zsarolás hatékonyságát.

A BlackLock az El Dorado Ransomware márkaváltásaként ismert. A Resecurity szerint ugyanazok a szereplők több más prominens projekthez is köthetők, köztük a Mamona Ransomware-hez. Az utolsó projekt sem tartott sokáig. Karol Paciorek, a CSIRT KNF munkatársa azonosította a Mamona DLS lehetséges clearnet IP-jét, ami pánikot keltett a leányvállalatok körében.

A BlackLock és a Mamona Ransomware is offline állapotba került, és jelenleg nem érhetők el. Nevezetesen egy másik prominens zsarolóvírus-csoport, a DragonForce vette át a vezetést, kihasználva ezeket az eseményeket. A Resecurity kiemelte, hogy lehetséges, hogy a DragonForce átveszi a BlackLock affiliate bázisát, és a csoport sikeresen átáll az új irányítókra.

nuce.hu

NIS2 esettanulmány: Fiktív Gépgyártó Kft.

1. Cég bemutatása A Fiktív Gépgyártó Kft. egy közepes méretű vállalat, amely ipari gépek és alkatrészek gyártásával foglalkozik. A cég ISO 9001 és ISO 27001 tanúsítvánnyal rendelkezik, mely biztosítja a minőségi gyártást és az információbiztonságot. 200 alkalmazottja közül többen az informatikai és biztonsági rendszerek fenntartásért felelősek. A vállalat rendelkezik egy webshoppal is, ahol pótalkatrészeket és kisebb berendezéseket értékesít.
2. GAP elemzés eredményei A NIS2 irányelvnek való megfelelés érdekében a Fiktív Gépgyártó Kft. GAP elemzést végzett, amely során az alábbi fő hiányosságok derültek ki:

• Szabályzatok hiánya: Az információbiztonsági szabályzatok elavultak, és nem fedik le teljes mértékben a kiberbiztonsági fenyegetéseket.
• Oktatás hiánya: Az alkalmazottak nem kapnak rendszeres kiberbiztonsági képzést, ami növeli a belső fenyegetések kockázatát.
• Biztonsági szoftverek frissítésének hiánya: A meglévő végpontvédelmi rendszerek nem mindig naprakészek, ami sebezhetővé teszi a céget.
• Titkosítás gyengeségei: Az adatok titkosítása nem teljeskörű, és nem felel meg a mai biztonsági előírásoknak.

3. Javasolt lépések a megfelelés érdekében A cég vezetése az alábbi cselekvési tervet fogadta el:

• Szabályzatok frissítése: Egy NIS2-kompatibilis információbiztonsági szabályzat-rendszer kidolgozása, amely kiterjed a kockázatelemzésre, incidenskezelésre és adatvédelemre.
• Oktatási program bevezetése: Rendszeres és többrétegű (vezetői/alkalmazotti/informatikai személyzeti) kiberbiztonsági oktatások szervezése minden alkalmazott számára, beleértve a phishing-tesztek és tudatosító kampányok indítását.
• Biztonsági szoftverek frissítése: Naprakész tűzfalak, behatolásvédelmi rendszerek és végpontvédelmi szoftverek beszerzése és telepítése.
• Titkosítás erősítése: Minden érzékeny adat titkosítása erős és hatékony technológiákkal, és a titkosított kommunikáció bevezetése az online tranzakciókhoz.

4. Várt eredmények A fent említett lépések végrehajtásával a Fiktív Gépgyártó Kft.:

• Javítja a kiberbiztonsági megfelelését a NIS2 irányelv szerint.
• Csökkenti az adatszivárgások és kibertámadások kockázatát.
• Erősíti az alkalmazottak tudatosságát a biztonsági kockázatokkal kapcsolatban.
• Biztonságosabb online és belső informatikai rendszert hoz létre.

A fejlesztések és végrehajtott módosítások lehetővé teszik a cég számára, hogy megfeleljen az európai úniós szabályozásoknak, miközben védi üzleti adatait és informatikai rendszereit a mai és jövőbeni fenyegetésekkel szemben.

 nuce.hu

A 2024. évi LXIX. törvény Magyarország kiberbiztonságáról, jogszabályba emelte többek között az adatosztályozás kötelezettségét is.

Most az ehhez kapcsolódó fontosabb feladatokat és folyamatokat próbáljuk meg az alábbiakban dióhéjban (in nuce) áttekinteni.

Először is fontos tisztázni, hogy az adatosztályozás fogalma nem új keletű, de annak jogszabályba emelése nagyon fontos lépés. Adatosztályozás természetesen nagyon sok szempont szerint és metodikával történhet, de amit a hazai jogszabályok megfogalmaznak, azok közül a legfontosabbak az alábbiak:

1. 2024. évi LXIX. törvény Magyarország kiberbiztonságáról,

• „adatosztályozás: a szervezet által az elektronikus információs rendszerben kezelt adatok és információk biztonsági besorolása azok bizalmasságának, sértetlenségének és rendelkezésre állásának szempontjából;”
• „Az adatosztályozás során figyelembe kell venni a logikailag együtt, egységben kezelt elektronikus adatok – ideértve az adatbázist, adattárat, egyedi dokumentumot és egyéb adatállományt – együttes biztonsági igényét.”

2. 418/2024. (XII. 23.) Korm. rendelet Magyarország kiberbiztonságáról szóló törvény végrehajtásáról

• melléklet „Az adatosztályozás végrehajtásához irányadó szempontok”: célok meghatározása, szempontok az adatok bizalmasság szerinti besorolására, az adatok sértetlenség és rendelkezésre állás szerinti értékelésére, és a besorolás utáni legfontosabb teendőkre.

Fontos: „A nemzeti kiberbiztonsági hatóság az adatosztályozást és a biztonsági osztályba sorolást felülbírálhatja, és indokolt esetben magasabb vagy alacsonyabb szintű besorolást is megállapíthat.”

Itt is ki kell emelnünk: minden szervezet más, mindenhol más típusú adatokat kezelnek, rengeteg különböző struktúrában mind technikailag (adatbázisok, nem strukturált adatok, célrendszerek, OT, felhő, stb.), mind szervezetileg (felelősségek, adatgazdák, stb.). Ennek figyelembevételével az alábbiakban megpróbáljuk összefoglalni, hogy nézhet ki az adatosztályozás folyamata, és mik lehetnek a legfontosabb szempontok.

1. Azonosítás és leltárkészítés

• Az összes szervezeti adat azonosítása.
• Adatforrások, rendszerek és adatfolyamok feltérképezése.

2. Osztályozási kritériumok meghatározása

Az adatok osztályozása általában a következő tényezők alapján történik:

• Bizalmasság: Az adatok nyilvánosságra kerülése milyen hatással lehet a szervezetre vagy érintettekre?
• Integritás: Milyen hatással lenne az adatok módosítása vagy megváltoztatása?
• Rendelkezésre állás: Milyen következményei lennének az adatok elvesztésének vagy elérhetetlenné válásának?
• Jogszabályi megfelelés: Milyen jogi vagy szabályozási követelmények vonatkoznak az adatra (pl. GDPR, iparági szabályok)?
• Érzékenység: Az adat tartalmaz-e bizalmas vagy személyes információt?

3. Adatok kategorizálása

A szervezetek gyakran a következő kategóriákat használják az adatok védelmi szintjének meghatározására:

• Nyilvános adatok: Bárki számára elérhető adatok (pl. weboldalak, sajtóközlemények).
• Belső használatra szánt adatok: Csak a szervezet belső munkatársai számára elérhetők (pl. üzleti tervekre vonatkozó információk).
• Bizalmas adatok: Korlátozott hozzáféréssel rendelkező, érzékeny adatok (pl. ügyféladatok, pénzügyi adatok).
• Kritikus/erősen bizalmas adatok: Olyan adatok, amelyek nyilvánosságra kerülése súlyos károkat okozhat (pl. egészségügyi adatok, szerződések, belső fejlesztési dokumentáció, kutatási adatok).

4. Védelmi intézkedések hozzárendelése

Az osztályozás után minden adatkategóriához megfelelő védelmi intézkedéseket kell hozzárendelni:

• Hozzáférés-szabályozás: Ki férhet hozzá az adatokhoz?
• Titkosítás: Adatok tárolása és továbbítása során alkalmazott védelem.
• Biztonsági mentések: Adatok helyreállíthatóságának biztosítása.
• Monitorozás és naplózás: Gyanús tevékenységek észlelése.

5. Folyamatos ellenőrzés és frissítés

Az osztályozást rendszeresen felül kell vizsgálni, és frissíteni kell a változó üzleti és szabályozási környezethez igazodva.

2. Szempontok az adatosztályozás során

Az adatosztályozás során érdemes a következő szempontokat is figyelembe venni:

• Szabályozási megfelelés: Az adatkezelési szabályzatnak összhangban kell lennie a kibertörvény, a NIS2 előírásaival és egyéb vonatkozó jogszabályokkal.
• Kockázatalapú megközelítés: Az adatok értéke és a kockázatok alapján kell meghatározni a védelmi szinteket.
• Incidenskezelés: Az adatvesztési vagy támadási forgatókönyvek elemzése és az ehhez szükséges védelem kialakítása.
• Hozzáférés-kezelés: Biztosítani kell, hogy csak a megfelelő személyek férhessenek hozzá az adatokhoz.
• Adathozzáférési naplózás: A felhasználói tevékenységek nyomon követése, hogy az esetleges incidenseket vissza lehessen vezetni.

Összegzés

Az adatosztályozás egy strukturált folyamat, amely segít az adatok biztonsági védelmének megfelelő kialakításában. Az adatok osztályozását az üzleti kockázatok, a jogszabályi követelmények és az adat érzékenysége alapján kell elvégezni, majd ehhez megfelelő védelmi intézkedéseket rendelni. A folyamatos felülvizsgálat és aktualizálás pedig biztosítja, hogy az adatosztályozási rendszer hatékonyan működjön, a változó környezetben is.

 www.nuce.hu

A NIS2 és főleg a kibertörvény megjelenése óta elég sok beszélgetésen találkozunk, elég sok „észrevétellel”. Az alábbiakban a leggyakoribb kérdések, érvek közül nézünk végig néhányat. Csak dióhéjban (in nuce).

„Biztos, hogy a kibertörvény ránk is vonatkozik?”

Ez talán a leggyakrabb felvetés, és sok helyen felmerül. Minden (hatósági) segítség ellenére, nem mindig egyszerű eldönteni a kérdést. Ráadásul a felkészüléssel járó ráfordítások mind az erőforrások mind a költségek tekintetében, valamint az auditok várható költségei nagyon alapos megfontolást igényelnek.

Azt azért el lehet mondani, hogy ha már egyáltalán felmerült ez a kérdés, akkor könnyen lehet, hogy valóban a törvény hatálya alá tartozunk…

Természetesen az is opció, hogy a NIS2 keretrendszerét, kontrolljait mindenképpen érdemes használni a szervezetek informatikai fejlesztéseiben, akkor is, ha a jogszabály nem vonatkozik valakire. Legfeljebb nem annyira szűkös határidővel kell mindent megvalósítani, és főleg nem kötelező auditáltatni…

„Van ISO minősítésünk, mi rendben vagyunk, felkészültünk.”

Ez így ebben a formában nem teljesen igaz. Az természetesen igen sokat segít, ha valakinek van ISO minősítése, akár például az információbiztonságra vonatkozó ISO 27001-es. Egyrészt ez azt jelenti, hogy a szervezet gondolkodásába, folyamataiba már beivódott a szabálykövetés, a pontos dokumentálás, a megfelelések/auditok rendszere. Ráadásul ilyenkor az informatika is feltehetően jól szabályozott keretek között működik. Ugyanakkor a NIS2 irányelv (EU 2022/2555 irányelve az Unió egész területén egységesen magas szintű kiberbiztonságot biztosító intézkedésekről,…) 21. cikkében („A kiberbiztonsági kockázatkezelési intézkedések”) jelzi ezek használhatóságát: „Figyelembe véve a legkorszerűbb és adott esetben a vonatkozó európai és nemzetközi szabványokat, valamint a végrehajtás költségeit,…”. Ráadásul az irányelv preambulumának 79. pontja nevesíti is az ISO 27000-et.

Az ISO önkéntes, és a NIS2 kötelezően alkalmazandó jellege mellett vannak természetesen egyéb különbségek, eltérések, nem is kevés. Csak néhány példa erejéig: az ISO rendszerhez képest a NIS2, illetve a hazai kibertörvény rendelkezései jóval konkrétabbak, pontosabb feladatokat, kontrollokat írnak elő, konkrét szektorokat, iparágakat neveznek meg kötelezettként, pontos incidens-bejelentési határidőket határoznak meg, hangsúlyosan kitérnek a beszállítókra is, hatósági ellenőrzéseket és szankciókat tesznek lehetővé, vagy például rendszeres kockázatértékelést írnak elő.

Mindenesetre az ISO, vagy más szabvány igen jó alapot jelent a felkészülés indításához, feltehetően jóval kevesebb munkát igényel majd a NIS2-re való felkészülés, mint egy ilyen meglévő rendszer nélkül.

„Nincs még hatósági metodika az elektronikus információs rendszerek biztonsági osztályba sorolására. Addig nem tudunk semmit sem elkezdeni…”

Egyrészt azért elég sok mindent el lehet kezdeni a biztonsági osztályba sorolás nélkül is, hogy mást ne mondjunk egy kockázatelemzést is el lehetne végezni. Az sem kis feladat… Másrészt a biztonsági osztályba sorolás hatósági metodikájáról a jogszabály (7/2024. MK rendelet, 1. melléklet, 2.1.2. pont) azt mondja, hogy „Az elektronikus információs rendszerek biztonsági osztályba sorolását az elektronikus információs rendszerben kezelt adatok és az adott elektronikus információs rendszer funkciói határozzák meg. A besorolást, amelyet a szervezet vezetője hagy jóvá, hatáselemzés alapján kell elvégezni. Az elektronikus információs rendszerek biztonságának felügyeletét ellátó hatóság ajánlásként hatáselemzési módszertanokat ad ki. Ha a szervezet saját hatáselemzési módszertannal nem rendelkezik, az így kiadott ajánlást köteles használni.” Tehát: HA a szervezet rendelkezik saját hatáselemzési módszertannal, akkor nyugodtan elkezdheti a biztonsági osztályba sorolást.

„Nekünk csak egy elektronikus információs rendszerünk van, és az is „alap” biztonsági osztály…”

Ezek a kérdések ugye az audit díjának megállapításánál elég komoly árkülönbségeket jelenthetnek. 1/2025. SZTFH rendelet, 3. melléklet: „A kiberbiztonsági audit – általános forgalmi adó nélkül számított – legmagasabb díja az 1.1., 1.2. és az 1.3. pont szerinti szorzószámok, valamint 1 750 000 forint szorzataként előálló összeg.”

• 1: A szervezet előző üzleti évi nettó árbevétele
• 2: A szervezet elektronikus információs rendszereinek (EIR) darabszáma
• 3: A szervezet elektronikus információs rendszereinek biztonsági osztálya

Azaz, ha például a szervezet előző üzleti évi nettó árbevétele 11 milliárd Ft, akkor ez adott, mérleg leadva, ezzel nem tud a szervezet mit kezdeni (ez esetben a 11 mlrd Ft-hoz tartozó szorzószám a 2,5).

Amivel próbálkoznak a szervezetek, az az EIR-ek darabszáma. A leggyakoribb az „itt minden egy rendszerben fut”. Ezzel az a gond, hogy ezt esetleg majd az auditor másként látja… Ez mondjuk még a kisebbik probléma, mert öt darab EIR-ig a szorzószám egyes, azaz mindegy, hogy egy vagy akár öt EIR-ünk van, a szorzószám egyes. Hat és tizenöt EIR között már pl. 2,5, 16 EIR felett 4 a szorzószám.

Vagy a biztonsági osztályba sorolás. „Nálunk nincsenek annyira fontos EIR-ek, mi mindent (azt az egyet…) „alap” biztonsági osztályba soroltunk.” Mert hogy az „alap” biztonsági osztály szorzószáma egyes. Ezzel ugyanaz a gond, mint az előbb. Az auditornak esetleg más lesz a véleménye. Ráadásul ezt a besorolást érintett hatóság is vizsgálni fogja! 418/2024. évi Kormányrendelet 30.§ szerint: „Az elektronikus információs rendszerek biztonsági osztályba sorolásának vizsgálata a nemzeti kiberbiztonsági hatóságnak megküldött információk alapján, jogszabályban meghatározott szempontok szerint történik.” „A nemzeti kiberbiztonsági hatóság a szervezet által megállapított biztonsági osztályt felülbírálhatja és indokolással magasabb biztonsági osztályba sorolást is megállapíthat.”

Az SZTFH rendelet szerint: „ha a szervezet valamennyi elektronikus információs rendszerének biztonsági osztálya „alap” biztonsági osztály, a szorzószám 1.Ha a szervezet bármely elektronikus információs rendszerének biztonsági osztálya „jelentős” biztonsági osztály, a szorzószám 3, ha a szervezet bármely elektronikus információs rendszerének biztonsági osztálya „magas” biztonsági osztály, a szorzószám 5.”

Tehát mennyi lehet az SZTFH rendelet szerint a kiberbiztonsági audit legmagasabb díja a fenti példa-árbevétellel számolva?

• A számunkra kedvező matek esetén: 1.750.000 x 2,5 x 1 x 1 = 4.375.000,-Ft+ÁFA
• A valósághoz közelebbi állapot esetén (pl. 6db EIR, amiből egy „jelentős”) 1.750.000 x 2,5 x2,5 x 3 = 32.812.500,-Ft+ÁFA.

Hát… Valóban nem mindegy…

A szervezetek döntéshozóinak mások a prioritásai.

Ez is természetes, és jogos. Akikre a kibertörvény NIS2 része vonatkozik, azok elég nagy szervezetek, a vezetőik abból a pozícióból gondolkodnak már hosszú évek óta. Azaz: „mi nem egy két fős Bt vagyunk, elég nagyok vagyunk, ráérünk, megoldjuk valahogy, a hatóság is „enyhébben kezel””,… Ez igaz, de mind a felkészítők, mind az auditorok is csak ilyen nagy cégekkel dolgoznak, csak ilyenekkel találkoznak, ez a piac csak ilyen nagy szervezetekből áll. Mindenki „nagy”, kiemelt, VIP vezető,…

 Ugyanakkor fontos lenne látni azt is, hogy a kibertörvény elég egyértelműen a „szervezet vezetőjére” ró igen sok feladatot. Ezek egy részét természetesen nem ő fogja elvégezni, de a felelősség az övé. 2024. évi LXIX. törvény 30. § (3): „Ha a szervezet vezetője a jogszabályban előírt kötelezettségének nem tesz eleget, a nemzeti kiberbiztonsági hatóság az eset összes körülményének mérlegelésével kormányrendeletben meghatározott mértékű bírsággal sújthatja, ismételt jogsértés esetén sújtani köteles.” A hivatkozott kormányrendelet a 418/2024. Kormányrendelet, ahol a 42.§ foglalkozik a Kiberbiztonsági bírságokkal. A 3. mellékletben elég részletesen le vannak írva a mulasztások és a kapcsolódó bírságok, de csak egy példa egy kategóriában a legmagasabb összegre: „ha a szervezet alapvető szervezetnek minősül 10 millió eurónak megfelelő forintösszeg vagy, ha ez magasabb a szervezet előző pénzügyi évi globális éves forgalma teljes összege 2%-ának megfelelő összeg”.

Ráadásul a Kormányrendelet 44.§ (4) szerint: „A bírság megfizetése nem mentesít a büntetőjogi, valamint a polgári jogi felelősség, valamint a bírság kiszabására okot adó körülmény megszüntetésének kötelezettsége alól.”

Ide kapcsolódik még egy-két „apróság”: 42.§ (4): „Ha a szervezet vezetője a jogszabályban előírt kötelezettségének nem tesz eleget, a nemzeti kiberbiztonsági hatóság 15 millió forintig terjedő bírsággal sújthatja, illetve ismételt jogsértés esetén sújtja.” Azaz, személy szerint a szervezet vezetője is kaphat pénzbírságot.

ÉS az információbiztonsági felügyelő (2024. évi LXIX. törvény 30. §): „Ha a szervezet a jogszabályokban foglalt biztonsági követelményeket és az ehhez kapcsolódó eljárási szabályokat nem teljesíti vagy nem tartja be, a biztonsági hiányosságokat nem hárítja el, a megfeleléshez szükséges intézkedések meghozatalát elmulasztja, vagy a tevékenységet nem hagyja abba, a kiberbiztonsági hatóság… jogosult … a szervezet költségére információbiztonsági felügyelőt kirendelni.”

Na, ez az, amit senki sem szeretne… Az információbiztonsági felügyelőnek igen komoly jogosultságai vannak, például jogosult „azonnali intézkedést javasolni az érintett szervezet vezetőjének a közvetlen fenyegetés elhárításához (működés korlátozása, leállítása)”.

Még egyszer: a jelenlegi gazdasági körülmények között teljesen jogos a szervezetek vezetőinek az a priorizálása, hogy először a túlélés (árbevétel, piacszerzés, stb.), és minden más csak utána következhet. Ugyanakkor a kibertörvény és „környéke” - bár senki sem a „nulláról indul” - szintén elég sok feladatot ró az érintettekre. És nincs rá sem túl sok idő, sem túl sok erőforrás.

 www.nuce.hu

A szokásos felelősségkizárás:

A bejegyzés írója kiemelt figyelmet fordít a jogszabályoknak való megfelelésre, de cégünk egy informatikai biztonsági tanácsadó cég és nem jogi iroda. Ezért az alábbi szövegben található bármely információ, észrevétel, megjegyzés vagy vélemény elsősorban informatikai, technikai, esetleg szabályozási jellegű és az üzleti folyamatok javítását célozza. Ugyanakkor ezek semmilyen formában nem minősülnek sem adótanácsadásnak, sem számviteli-, sem jogi tanácsnak vagy véleménynek! Ilyenekre a bejegyzés írója nem hitelesített és nem is jogosult.

A napokban jelent meg az SZTFH 1/2025-ös rendelet a kiberbiztonsági audit lefolytatásának rendjéről és a kiberbiztonsági audit legmagasabb díjáról, valamint a 2/2025-ös SZTFH rendelet a kiberbiztonsági felügyeleti díjról.

Mivel az 1/2025-ös rendelet írja le az auditori és a hatósági ellenőrzések metodikáját, így ez igen fontos „iránymutatás” a kibertörvény (2024. évi LXIX. trv.), illetve a kapcsolódó végrehajtási rendelet (7/2024. MK rendelet) alkalmazásához.

Az alábbiakban megpróbáljuk dióhéjban (in nuce) összefoglalni az első benyomásainkat.

Pozitív:

• A rendeletben szereplő audit metodika igen részletes, alapos és korrekt. Természetesen lehet másként is auditálni, bizonyítékokat gyűjteni, felmérni egy-egy szervezetet, de az 1/2025-ös egy kodifikált, hatósági rendelet, ami teljes mértékben használható, nagyon is megfelel a kiberbiztonsági törvény céljainak.

Kérdéses:

• Erőforrás: bár időközben a hatóság több céget engedett az auditori körbe, de pont a fenti igen jó és részletes audit metodika miatt erősen kétséges, hogy 2025 december végéig ezek a cégek az érintett szervezeteket a fenti metodika alapján korrektül le tudják ellenőrizni.
• Automatizálás: jelenleg is vannak auditálást támogató szoftverek, mind belső fejlesztésűek, mind „dobozosak”. A CAAT és a CAATT elég régi fogalmak ebben a szakmában… Ezek természetesen segíteni fognak a munkában, de ha a rendelet azt írja elő, hogy „kötelezően alkalmazandó interjú”, vagy „kötelezően alkalmazandó teszt”, akkor azt annak megfelelően kell elvégezni. Azaz például, mivel az SZTFH rendelet auditori módszertani leírása megkülönbözteti az interjút és a személyes interjút, a helyszíni és a távoli interjút (5. melléklet, 1.2.2 pont), így ott pl. lehet a „felhőben” feltett kérdésekre/kérdőívekre online is válaszolni.
• Az audit alanyok jellemzően nem annyira szeretik, ha külsősök (akár auditorok) saját munkájukat megkönnyítendő, saját (audit) szoftvereket telepítenének a cégek rendszereire. Tehát ez jellemzően kézimunka lesz. Nagyjából 3800-4000 szervezetnél…
• Az audit egyik lényeges eleme, hogy bármilyen metodika esetén az auditor tapasztalata és professzionalizmusa erősen befolyásolja az audit menetét. Tehát például az interjúztatás során egy-egy kérdésre adott válasz esetén mennyire lesz alapos az ellenőrzés, milyen mértékig megy tovább azon a kontrollponton. Mennyire akarja az auditor gyorsan és hatékonyan lezárni a kérdőívet/ügyfelet, vagy mennyire tartja fontosnak a megbízó valós érdekét, alaposabban feltárni a hiányosságot, segíteni a kiberbiztonság valódi fejlesztését.

Hogy néz ki a folyamat a gyakorlatban?

Például az incidenskezelés esetében.

A kibertörvény (2024. évi LXIX. trv) annyit mond, hogy (70. § (1)) „Kiberbiztonsági incidens bekövetkezése esetén a szervezet intézkedik az érintett kiberbiztonsági incidens kezelése érdekében.”

A kapcsolódó rendelet (7/2024. MK rendelet) már egy picit részletesebb. A 2. melléklet (Védelmi intézkedések katalógusa) 9.pontja (Biztonsági események kezelése) 38 pontban részletezi a különböző biztonsági osztályba sorolt rendszerekre vonatkozó kontrollokat. Ennek 9.9 pontja a „Biztonsági események kezelése”, amely szerint a szervezet „biztonsági eseménykezelési képességet alakít ki”, „összehangolja a biztonsági eseménykezelési tevékenységeket az üzletmenet-folytonossági tervezési tevékenységekkel”, „beépíti a folyamatos biztonsági eseménykezelési tevékenységekből származó tanulságokat a biztonsági eseménykezelési eljárásokba, képzésbe és tesztelésbe”, és „biztosítja, hogy a biztonsági eseménykezelési tevékenységek összehasonlíthatók és kiszámíthatók legyenek a szervezeten belül”.

A fenti feladatokat az 1/2025 SZTFH rendelet 6. mellékletében felsorolt „a kiberbiztonsági audit során alkalmazandó vizsgálati módszerek” 207. pontja szerint

• szervezeti szinten kell ellenőrizni (tehát nem elektronikus információs rendszer - EIR szinten),
• kötelező az interjúztatáson erre rákérdezni,
• kötelező erre vonatkozó tesztet is alkalmazni a tényleges és az elvárt működés összehasonlítására (ez lehet akár automatizált is),
• ez egy „biztosító” típusú ellenőrzés, és
• „az értékelésből nem kizárható”.

A rendelet 7. melléklete segít a „követelménycsoportok értékelése” tekintetében is. A biztonsági események kezelése esetében ezek az alábbiak:

• az események kezelésére az eseménykezelési tervvel összhangban lévő eseménykezelési képességek kerültek kialakításra
• az eseménykezelési képesség az eseményekre való felkészülést is magában foglalja
• az eseménykezelési képesség magában foglalja az események észlelését és elemzését
• az eseménykezelési képesség magában foglalja az események elszigetelését
• az eseménykezelési képesség magában foglalja az események felszámolását
• az eseménykezelési képesség magában foglalja a helyreállítást
• az eseménykezelési tevékenységeket összehangolták az üzletmenet-folytonossági tervezési tevékenységekkel
• a folyamatban lévő eseménykezelési tevékenységekből levont tanulságokat beépítik az eseménykezelési eljárásokba, a képzésbe és a tesztelésbe
• a beépített tanulságokból eredő változtatásokat annak megfelelően hajtják végre
• az eseménykezelési tevékenységek összehasonlíthatóak és kiszámíthatóak az egész szervezeten belül.

Költségek

Az auditra való felkészülés természetesen egy külön történet, az tényleg minden cégnél más és más, minden szervezet más „érettségi szinten” van, máshonnan indul, más (esetleges) hiányosságokat kell pótolnia.

A kiberbiztonsági audit legmagasabb díját viszont a rendelet 3. melléklete tartalmazza. Ebben meghatároztak egy alap „szorzószámot”, ez nettó 1 750 000 forint, valamint három változó szorzószámot, ami alapján az audit díjat kell kalkulálni. Ezek a paraméterek a szervezet előző üzleti évi nettó árbevétele, a szervezet elektronikus információs rendszereinek (EIR) darabszáma, valamint a szervezet elektronikus információs rendszereinek biztonsági osztálya.

Néhány példa:

• „Alfa” cég:
  • előző üzleti évi nettó árbevétele 250 millió Ft           szorzószám: 0,9
  • egyetlen rendszere esik a törvény hatálya alá,         szorzószám: 1
  • ezt a rendszert „alap” biztonsági osztályba sorolták szorzószám: 1

A fentiek alapján az „Alfa” cég kiberbiztonsági auditálásnak – általános forgalmi adó nélkül számított – legmagasabb díja = 0,9*1*1*1.750.000Ft = 1.575.000,- Ft

• „Béta” cég:
  • előző üzleti évi nettó árbevétele 27.5 milliárd Ft            szorzószám: 3
  • hat rendszere esik a törvény hatálya alá,                       szorzószám: 2,5
  • van egy „magas” biztonsági osztályba sorolt rendszere szorzószám: 5

A fentiek alapján a „Béta” cég kiberbiztonsági auditálásnak – általános forgalmi adó nélkül számított – legmagasabb díja = 3*2,5*5*1.750.000Ft = 65.625.000,- Ft

• „Gamma” cég:
  • előző üzleti évi nettó árbevétele 27.5 milliárd Ft               szorzószám: 3
  • öt rendszere esik a törvény hatálya alá,                           szorzószám: 1
  • van egy „jelentős” biztonsági osztályba sorolt rendszere szorzószám: 3

A fentiek alapján a „Gamma” cég kiberbiztonsági auditálásnak – általános forgalmi adó nélkül számított – legmagasabb díja = 3*1*3*1.750.000Ft = 15.750.000,- Ft

Összegezve: ismételten azt javasoljuk minden érintettnek, hogy vegyék nagyon komolyan a felkészülést, adott esetben igen sok munkával járhat, sok időt és erőforrást igényel, és nincs rá sem sok idő, sem sok valódi szakember.

www.nuce.hu