Két NISmeretlenes egyenletek #01 [tl;dr]

A mai részt és alapvetően a sorozatot magát Solymi kollégámmal folytatott beszélgetés ihlette. Van a követelmény-rendszernek egy izgalmas, de nem túl mélyen kifejtett része: a 7/2024. (VI. 24.) MK rendelet 18. fejezete („Rendszer- és információsértetlenség”) rendkívül részletesen taglalja azokat az adminisztratív és technikai elvárásokat, amelyeket a szervezeteknek az audit időpontjára igazolható módon teljesíteniük kell. Ezen belül kiemelt figyelmet érdemel a 18.43-as azonosítójú követelmény, amely a következőképpen fogalmazza meg a védelmi elvárást:

Az EIR meghatározott gyakorisággal sértetlenségellenőrzést végez a meghatározott szoftvereken, firmware-eken és információkon, a rendszer indításakor, az átmeneti rendszerállapotokban vagy a biztonsági szempontból releváns események esetén.

Ezt fogom most elsőként kicsit körbejárni, és nagy örömömre szolgál, ha egyúttal segíthetek is a kedves olvasónak ezzel a kevésbé egyértelmű követelménnyel kapcsolatban.

A szabályozási környezet

kiberbiztonsági paradigmaváltás

Az Európai Unió kiberbiztonsági stratégiájának fundamentumaként megalkotott NIS2 irányelv (Az Európai Parlament és a Tanács (EU) 2022/2555 irányelve) egy egységes, eddig soha nem látott szigorúságú kiberbiztonsági követelményrendszert hozott létre az Unió tizennyolc kritikus ágazatában. A korábbi NIS1 irányelvet felváltó, jóval ambiciózusabb jogszabály nem csupán a hatálya alá tartozó szervezetek körét tágította ki drasztikusan – a becslések szerint mintegy 160 000 európai szervezetre kiterjesztve a megfelelési kötelezettséget –, hanem a szankciók mértékét és a felsővezetői felelősségrevonás intézményét is bevezette. A jogszabálysértés, illetve a megfelelés hiánya esetén a kiszabható szankciók alapvető szervezetek (essential entities) esetében elérhetik a 10 millió eurót, vagy az éves globális forgalom 2%-át, míg fontos szervezetek (important entities) esetében a 7 millió eurót, vagy a forgalom 1,4%-át, amely jelentős pénzügyi és egzisztenciális kockázatot jelent az érintett vállalatok számára. Tovább súlyosbítja a helyzetet, hogy a felsővezetők személyes felelősséggel tartoznak a kiberbiztonsági kockázatkezelési intézkedések végrehajtásáért, és a legrosszabb esetekben a jogszabály lehetővé teszi a vezetői tisztségtől való ideiglenes eltiltást is. Magyarországon a NIS2 irányelv hazai jogrendbe történő átültetése egy transzparens, kétlépcsős jogalkotási folyamat keretében valósult meg, amelynek gerincét a kiberbiztonsági tanúsításról és a kiberbiztonsági felügyeletről szóló 2023. évi XXIII. törvény (Kibertv.), valamint a 2024 decemberében elfogadott, Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény adja. Ezt a jogszabályi keretet hivatottak kiegészíteni a Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH) által kiadott végrehajtási rendeletek, valamint a biztonsági osztályba sorolás követelményeiről és az alkalmazandó konkrét védelmi intézkedésekről szóló, a Miniszterelnöki Kabinetirodát vezető miniszter által kiadott 7/2024. (VI. 24.) MK rendelet. A magyar szabályozás sajátossága, hogy a törvény hatálya alá tartozó szervezeteket nem pusztán ágazati alapon, hanem az elektronikus információs rendszereik (EIR) biztonsági szintje alapján is kategorizálja, „Alap”, „Jelentős” és „Magas” biztonsági osztályokba sorolva azokat. A követelményrendszer teljesítését nem a hatóság ellenőrzi közvetlenül, hanem az SZTFH által nyilvántartásba vett, független auditorok.A technikai megfelelés, valamint a védelmi intézkedések katalógusának egyik legösszetettebb, legmélyrehatóbb infrastrukturális beavatkozást igénylő területe a szoftver-, firmware- és információsértetlenség biztosítása. 

NIS2 és a kiberbiztonság

Mielőtt rátérnék a konkrét követelménypontra fontosnak tartom tisztázni, hogy a NIS2-re sok érintett szervezet úgy tekint mint a szükséges rossz, egy újabb felesleges törvényi előírás amivel újabb bőrt húznak le a hazai szerzvezetekről. A legtöbb tanácsadó aki NIS2 audittámogatást nyújt, a nap végén a szükséges minimum elbálozására törekszik (egy nagyon kedves, volt kollégám korábban némi indulattal a hangjában azt mondta, hogy "egy baltával verném agyon azt aki azt állítja tanácsadóként, hogy a NIS2 auditnak bármi köze van a kiberbiztonsághoz"). Ugyanakkor én szeretem belelátni a NIS2-be a kiberbiztonsági keretrendszert, amit lehet ugyan kritizálni, de egy stabil alapot és iránymutatást tud adni a kiberbiztonság kialakításához gyakorlatilag bármilyen méretű szervezetnél.

Ezért azt gondolom igenis van értelme megemlékeznünk arról, hogy egy-egy követelménypontot hogyan érdemes jól megvalósítani és főleg miért, hogy az ténylegesen a szervezet érdekeit és céljait szolgálja. Hogy a NIS2 megfelelésre elszórt milliók tényleges értékké váljanak a szervezet működése és fennmaradása érdekében. Ezen felül kíméleten fontos számomra – és tudom, hogy a kiberbiztonság területén tevékenykedő megannyi kollégám számára is – társadalmunk kollektív kiberbiztonsági fejlődése, előrehaladása biztonságosabb, nyugodtabb és kiszámíthatóbb körülmények biztosításával.

Kiberbiztonsági paradigmaváltás

Az EIR meghatározott gyakorisággal sértetlenségellenőrzést végez a meghatározott szoftvereken, firmware-eken és információkon, a rendszer indításakor, az átmeneti rendszerállapotokban vagy a biztonsági szempontból releváns események esetén.

Ez a specifikus jogszabályi elvárás rávilágít arra a paradigmaváltásra, miszerint a statikus, időszakos, havonta vagy évente elvégzett sérülékenységvizsgálatok, valamint a hagyományos, szignatúra-alapú vírusirtók korszaka végérvényesen lejárt. A modern kiberfenyegetettségi tájkép – amely magában foglalja az operációs rendszer betöltődése előtt aktiválódó bootkit-eket, a firmware-szintű mély beágyazódásokat (persistence), és a memóriában futó, fájl nélküli (fileless) kártevőket – folyamatos, lehetőleg hardveres bizalmi láncra (Hardware Root of Trust) támaszkodó, dinamikus sértetlenségellenőrzési ökoszisztémát követel meg.

A sértetlenségellenőrzés dimenziói és a rendeleti követelmények dekonstrukciója

A jogszabály által támasztott, fent idézett követelményrendszer több, technológiailag markánsan eltérő síkon írja elő a védelmi mechanizmusok implementálását. Az információbiztonság alapjait jelentő CIA-triász (Confidentiality, Integrity, Availability – Bizalmasság, Sértetlenség, Rendelkezésre állás) keretrendszerében az integritás, vagyis a sértetlenség annak garantálását jelenti, hogy az adatok, a rendszerleíró állományok, a konfigurációk és a végrehajtható kódok sem rosszindulatú külső vagy belső beavatkozás, sem pedig adminisztrációs hiba folytán nem módosultak jogosulatlanul.A 18.43-as követelménypont egyértelműen meghatározza azokat a konkrét időbeli és rendszerállapoti kritériumokat, amikor ezen ellenőrzési folyamatoknak kötelezően le kell futniuk. Az alábbi táblázat ezen jogszabályi állapotokat és a hozzájuk kapcsolódó informatikai biztonsági koncepciókat, valamint a piacon elérhető technológiai megközelítéseket rendszerezi, megalapozva a későbbi, mélyebb technológiai elemzést.

Ez a négydimenziós, holisztikus megközelítés hivatott biztosítani, hogy a potenciális támadó (legyen az egy külső APT csoport vagy egy rosszindulatú belső munkatárs) ne tudja kihasználni a rendszer állapotváltozásaiból fakadó vakfoltokat. A következőkben részletesen elemezzük a követelményben nevesített egyes kritériumokat, és az azokat kielégítő konkrét technológiai mechanizmusokat, platformokat, kitérve azok implementációs kihívásaira a magyar nagyvállalati és államigazgatási környezetben.

A rendszer indításakor végzett sértetlenségellenőrzés kihívásai és technológiái

A fizikai vagy virtuális számítástechnikai eszközök boot folyamata az informatikai infrastruktúra egyik legkritikusabb sebezhetőségi felülete. Abban az esetben, ha egy rosszindulatú szereplő vagy egy kártékony kód (például egy fejlett bootkit vagy rootkit) képes még az operációs rendszer rendszermagjának (kernel) és a végpontvédelmi szoftvereknek (EDR/XDR) a betöltődése előtt végrehajtódni, akkor a támadó teljes és korlátlan ellenőrzést szerezhet a rendszer felett. Ebben az esetben a hagyományos, magasabb szinten (OS szinten) működő védelmi szoftverek számára a kompromittálódás teljesen láthatatlan marad, mivel a támadó már a védelmi szoftvereket futtató alapokat is kontrollálja. A NIS2 irányelvhez kapcsolódó 18.43-as követelmény, valamint a szorosan hozzá kapcsolódó 18.50-es („Boot folyamat ellenőrzése”) és a 18.51-es („Boot firmware védelme”) követelmények  egyértelműen a hardveres bizalmi gyökéren (Hardware Root of Trust) alapuló, a boot láncot megszakítás nélkül vizsgáló technológiák alkalmazását kényszerítik ki a szervezetekből.

A Secure Boot és a Trusted/Measured Boot mechanizmusok különbségei

A rendszer indításakor történő biztonsági ellenőrzés technológiai evolúciója során két alapvető, de funkciójában eltérő mechanizmus alakult ki: a Verified Boot (Ellenőrzött vagy hitelesített indítás) és a Measured Boot (Mért indítás). A Verified Boot iparágban legismertebb és legelterjedtebb megvalósítása a Unified Extensible Firmware Interface (UEFI) szabványba beépített Secure Boot funkció.A Secure Boot egy lokális, eszközszintű kikényszerítési (enforcement) mechanizmus, amely a boot lánc minden egyes elemét – kezdve a firmware-től a bootloader-en át egészen az operációs rendszer kerneléig – még a memóriába töltés és a végrehajtás előtt ellenőrzi. Az ellenőrzés a kódokhoz csatolt digitális aláírások kriptográfiai hitelesítésén alapul. Amennyiben az aláírás nem érvényes, manipulálták, vagy nem egy a rendszer által előzetesen elfogadott, megbízható hatóságtól (például az eszközt gyártó OEM-től vagy a Microsofttól) származik, a firmware megtagadja a kód végrehajtását, megállítva a boot folyamatot. Linuxos szerverkörnyezetekben, ahol az egyedi kernelmodulok használata mindennapos, a Secure Boot működését gyakran a Machine Owner Key (MOK) adatbázisok bevonásával egészítik ki, amely lehetővé teszi a rendszergazdák számára, hogy saját maguk által aláírt binárisokat futtassanak a Microsoft vagy az OEM hitelesítési láncának megkerülésével.Bár a Secure Boot bekapcsolása alapvető védelmi vonal és a kiberhigiénia elengedhetetlen része, az Egyesült Államok Nemzetbiztonsági Ügynöksége (NSA) által kiadott útmutatók és az elmúlt években nyilvánosságra került kritikus sebezhetőségek (mint a PKFail, a BlackLotus UEFI bootkit, vagy a GRUB2 bootloadert érintő BootHole sebezhetőség) rávilágítottak arra, hogy a statikus tanúsítványokhoz és aláírásokhoz kötött ellenőrzés önmagában nem nyújt megingathatatlan biztonságot az infrastruktúra számára. A támadók egyre gyakrabban alkalmazzák a lejárt, visszavont, de a firmware által mégis elfogadott tanúsítványok kihasználását, vagy a hitelesítési folyamat megkerülését célzó technikákat.A NIS2 szigorú elvárásainak mélyebb, auditbiztos megfeleléséhez, különösen a szerverkörnyezetekben és az adatközpontokban, a Measured Boot és a Trusted Boot architektúrák alkalmazása jelenti a robusztus megoldást. Míg a Secure Boot proaktívan, de sokszor rugalmatlanul meggátolja a futtatást, a Measured Boot önmagában nem állítja meg a boot folyamatot egy anomália észlelésekor. Ehelyett transzparens, megmásíthatatlan bizonyítékot szolgáltat a rendszer állapotáról. A folyamat során a rendszerindítási lánc minden egyes komponensének kriptográfiai lenyomata (SHA-1, SHA-256 hash értéke) a TPM (Trusted Platform Module) speciális, hardveresen védett regisztereibe, az úgynevezett Platform Configuration Register-ekbe (PCR) íródik.A TPM 2.0 egy dedikált, alaplapra integrált (vagy a processzorba tokozott firmware-alapú) biztonsági kriptoprocesszor, amely a modern szerverek és végpontok alapfelszereltsége (a Windows 10/11 minősítési követelményei miatt mára iparági standard). A TPM 2.0 használata elengedhetetlen kelléke a NIS2 szoftver- és firmware-sértetlenségi követelményeinek teljesítéséhez. A TPM kialakítása biztosítja, hogy a PCR regiszterek tartalma nem írható felül tetszőleges adatokkal; a regiszterek csak egy előre definiált, egyirányú kriptográfiai művelettel (az úgynevezett extend művelettel) bővíthetők, így az abban tárolt "mérések" sorrendje és aggregált értéke egy kártékony kód számára manipulálhatatlan marad. Ez a hardveres bizalmi gyökér garantálja, hogy a begyűjtött bizonyítékok integritása nem sérülhet.

Távoli attesztáció (van ilyen szó egyáltalán?! - remote attestation) és a keylime architektúra

A Measured Boot önmagában egy lokális védelmi mechanizmus. Ahhoz, hogy egy szervezet központilag, az EIR egészére vonatkozóan – ahogyan azt a 7/2024. MK rendelet 18.45-ös követelménye („Központilag kezelt sértetlenségellenőrző eszközök”) előírja  – meggyőződhessen az infrastruktúra sértetlenségéről, távoli attesztációra (Remote Attestation) van szükség. Erre a kritikus feladatra az egyik legkiforrottabb, nyílt forráskódú, vállalati környezetben is bizonyított megoldás a Cloud Native Computing Foundation (CNCF) által felkarolt Keylime projekt. A Keylime technológia lehetővé teszi az infrastruktúra állapotának folyamatos, távoli és skálázható ellenőrzését a TPM által biztosított hardveres mérések alapján, kiterjesztve a bizalmi láncot a szerverteremből a központi felügyeleti rendszerekig. Architektúrája két fő logikai rétegből áll: a vizsgált csomóponton (szerveren vagy végponton) futó Agentből, valamint a központilag telepített Verifier és Registrar komponensekből.

A Keylime működési mechanizmusa, amellyel a boot folyamat és az operációs rendszer sértetlensége igazolható, a következőképpen épül fel:

1. A megoldás kihasználja a modern Linux kernelekbe integrált IMA (Integrity Measurement Architecture) alrendszert. Az IMA nem csupán a boot folyamat elemeit, hanem a fájlrendszeren lévő minden végrehajtható fájl és betöltött könyvtár hash-elését elvégzi még a kód tényleges betöltése és végrehajtása előtt.
2. A lokális kernel fenntart egy úgynevezett Measurement List-et (ML), amely egy hozzáfűzés-alapú napló. Ennek a listának az aggregált hash értéke folyamatosan íródik a TPM egyik kijelölt PCR regiszterébe (amely a gyakorlatban leggyakrabban a PCR 10).
3. A központi Keylime Verifier meghatározott időközönként egy kriptográfiai kihívást (challenge, ami egy random nonce) küld a távoli Agentnek. Az Agent válaszként visszaküldi a TPM által a saját privát kulcsával (Attestation Key) digitálisan aláírt PCR értékeket – ezt a csomagot nevezik TPM Quote-nak –, valamint elküldi a részletes, szöveges IMA logot is.
4. A Verifier kriptográfiailag, a korábban regisztrált publikus kulcsok alapján ellenőrzi a TPM Quote hitelességét, ezáltal bizonyítva, hogy a válasz valóban az adott szerver hardveres TPM chipjéből származik.
5. Ezt követően a Verifier lokálisan, a kapott IMA log alapján újraszámolja a hash-értékeket, és az eredményt összeveti a Quote-ban szereplő, hardveresen hitelesített PCR értékkel.
6. Ha a kettő megegyezik, a log tartalma hiteles. Utolsó lépésként a Verifier az egyes naplóbejegyzéseket egy központilag menedzselt engedélyezett listához (whitelist) hasonlítja, így azonnal észlelve minden jogosulatlan szoftver, szkript vagy kernelmodul végrehajtását a távoli gépen.

Ez egy elég jó, hardveresen megtámogatott mechanizmus lefedi a NIS2 18.43-as követelményének "rendszer indításakor" történő szoftver és firmware sértetlenségellenőrzési kritériumát, bizonyíthatóságot teremtve az SZTFH auditorai számára is.

Vállalati firmware felügyeleti megoldások: Eclypsium és a natív eszközök

Míg a Keylime elsősorban a nyílt forráskódú operációs rendszerek és a TPM integrációjára épít, az infrastruktúra legalacsonyabb, hardverspecifikus firmware rétegeinek (például BIOS, hálózati kártyák firmware-e, menedzsment processzorok) ellenőrzésére speciális kereskedelmi platformok nyújthatnak átfogó megoldást. A hagyományos végpontvédelmi rendszerek (EDR) és sérülékenységvizsgálók jellemzően nem rendelkeznek a firmware rétegekig hatoló, regiszter-szintű rálátással. Ezen a területen az egyik vezető platform az Eclypsium, amely folyamatosan ellenőrzi a szerverek, hálózati eszközök (switch-ek, routerek), laptopok és speciális berendezések firmware-ének sértetlenségét.

A platform ereje egy hatalmas, folyamatosan frissülő, több mint 12 millió ismert-jó (known-good) firmware hash-t tartalmazó adatbázisban rejlik. Az eszköz automatizált módon képes detektálni a kompromittált, módosított vagy elavult firmware-eket, és olyan rejtett, hálózat alatti fenyegetéseket, mint a Baseboard Management Controller (BMC) sebezhetőségek (pl. CVE-2025-54085), a HybridPetya ransomeware alacsony szintű komponensei, vagy a már említett BlackLotus UEFI bootkit. A NIS2 különösen szigorú az ellátási lánc biztonságával (Supply Chain Security) kapcsolatban; az Eclypsiumhoz hasonló megoldások biztosítják a szervezetet arról, hogy az újonnan beszerzett hardverek firmware-je a gyártás és a szállítás során nem esett áldozatául manipulációnak.A kereskedelmi platformok mellett léteznek olyan natív, operációs rendszer szintű eszközök, amelyek – különösen Linux szerverkörnyezetben – elengedhetetlenek a firmware sértetlenségének napi szintű vizsgálatához. Az fwupdmgr és az efivar parancssori eszközök lehetővé teszik a rendszergazdák számára a UEFI változók aktuális állapotának lekérdezését, azok kimentését és egy ismert jó (baseline) állapottal való automatizált (például cron jobok segítségével történő) összehasonlítását. Ezek az eszközök képesek igazolni a TPM eszköz működését és jelenlétét is (például a tpm2_getrandom 8 parancs használatával). Haladó szinten a biztonsági csapatok támaszkodhatnak az Intel Security által fejlesztett CHIPSEC keretrendszerre is, amely kifejezetten a PC platformok, a firmware és a hardver interfészek alacsony szintű biztonságának auditálására, a biztonsági beállítások meglétének ellenőrzésére és a firmware sértetlenségének mélyreható vizsgálatára szolgál.

Sértetlenségellenőrzés "átmeneti rendszerállapotokban" (Transient States)

A megfogalmazás és a fordítás is kicsit félrevezető lehet, tegye fel a kezét aki kapásból tudja, hogy mit jelent ez az átmeneti állapot.... :)

A 7/2024. MK rendelet 18.43-as követelményének kétségtelenül a legnagyobb technológiai és értelmezési kihívást jelentő passzusa az „átmeneti rendszerállapotokban” (transient system states) történő sértetlenségellenőrzés előírása. A merevlemezen tárolt statikus fájlok (például binárisok) vagy a rendszer boot fázisának mérése, bármilyen alapos is, önmagában nem fedi le azokat a kifinomult támadásokat, amelyek kizárólag a memóriában zajlanak, fájlt nem hoznak létre a lemezen, vagy a hálózati és folyamatállapotok dinamikus, mikroszekundumok alatt lezajló váltásakor következnek be. Régen ezt "futás időben"-nek neveztük.

Az élő forenzikus analízis (live forensics) és a memória sértetlensége

Az átmeneti állapotok a számítógépes rendszerek olyan dinamikus, gyorsan változó, illékony működési fázisait jelentik, mint a memóriába (RAM) már betöltött és éppen futó folyamatok, az aktív hálózati kapcsolatok és socketek megnyitása és zárása, vagy egy folyamat kontextusváltása a CPU-n. Míg a klasszikus, "halott" (dead forensics) elemzés egy már kikapcsolt, lefoglalt gép merevlemezét vizsgálja egy incidens után, a Live Forensics (élő forenzikus analízis) kifejezetten az illékony adatok valós idejű rögzítésére, megőrzésére és elemzésére fókuszál.

A sértetlenségellenőrzés az átmeneti állapotokban azt követeli meg a rendszerektől, hogy a biztonsági megoldások (mint a fejlett XDR rendszerek) folyamatosan monitorozzák a futó folyamatok integritását. Ellenőrizni kell például azt, hogy a memóriába betöltött kód memóriaképe (memory footprint) nem módosult-e az eredeti, lemezen tárolt lemezképhez képest – ezt a módosítást gyakran process injection, DLL hijacking vagy memóriakorrupciós technikák révén érik el a kártevők. Ennek támogatására a modern SIEM és XDR rendszerek (mint a Wazuh kiterjesztett képességei, vagy dedikált EDR megoldások) rendelkeznek olyan modulokkal, amelyek képesek időszakos memóriaképek (Memory Dump) rögzítésére, a futó alkalmazások által kezelt memóriaszegmensek vizsgálatára, és a tranziens hálózati tranzakciók mélyrétegi megfigyelésére.

Az átmeneti rendszerállapotokhoz kapcsolódó bizonyítékok gyűjtése különösen kritikus a NIS2 szigorú, több fázisú incidensbejelentési kötelezettségei miatt. A jogszabály előírja, hogy jelentős incidens esetén a szervezetnek 24 órán belül korai figyelmeztetést, 72 órán belül pedig részletesebb jelentést kell tennie a hatóságok felé. Ezen jelentések elkészítésekor a puszta naplófájlok (amelyek sokszor csak az esemény bekövetkeztét, de nem annak lefolyását rögzítik) sokszor nem képesek hűen visszaadni a rendszer egy adott pillanatbeli, múlandó állapotát. Ezen "nem-napló típusú artifaktumok" – mint a konfigurációs állapotok pillanatképei, a memóriaképek, vagy az aktív folyamatlisták (process listing) – sértetlenségének megőrzése és ellenőrizhetősége elengedhetetlen a jogi és felügyeleti megfeleléshez, valamint a belső biztonsági csapatok munkájához.

Eseménystream-feldolgozás, iparági sajátosságok és gépi ganulás

A NIS2 hatálya alá tartozó ipari (OT) és kritikus infrastrukturális rendszereknél (például a villamosenergia-szektorban vagy a vízgazdálkodásban) az átmeneti állapotok értelmezése túlmutat az IT eszközök RAM tartalmán. Ezekben a fizikai kiberrendszerekben az átmeneti állapotok a rendszer fizikai stabilitásának megváltozását, például az állandó (steady-state) és a tranziens (dinamikus) fizikai állapotok közötti átmenetet jelentik hálózati zavarok, rövidzárlatok vagy fizikai folyamatokat célzó kibertámadások esetén. Itt az érzékelők, mint például a PMU (Phasor Measurement Unit) által szolgáltatott frekvencia- és feszültségadatok valós idejű figyelése, és a Man-in-the-Middle (MITM) támadások elleni protokollszintű mélyrétegi vizsgálatok (Deep Packet Inspection) jelentik a kommunikációs csatornák sértetlenségellenőrzését.

Mivel ezek az események hatalmas mennyiségű adatot generálnak a másodperc törtrésze alatt, a tranziens események sértetlenségének valós idejű vizsgálatára gyakran Big Data mérnöki technikákat és dedikált stream-feldolgozó motorokat alkalmaznak. A streaming architektúrák – mint például a nyílt forráskódú Apache Flink – kiválóan alkalmasak arra, hogy folyamatosan, alacsony késleltetéssel figyeljék a valós idejű telemetriát, és azonnal, még az esemény lezajlása közben kinyerjék az incidensre utaló bizonyítékokat (evidence) a rendszer gyorsan tovatűnő, átmeneti állapotaiból. A gépi tanulási (ML) modellekkel megtámogatott architektúrák, mint például a Spark RDD-k (Resilient Distributed Datasets), képesek iteratív feladatokat végrehajtani a hálózati forgalmon, prioritást rendelni az ezernyi logbejegyzésből származó anomáliákhoz, és azonnali válaszintézkedéseket kiváltani az EDR vagy a SIEM rendszerekben (azért ezzel csak óvatosan, különösen ipari környezetekben!!!). Ez utóbbi képesség elengedhetetlen ahhoz, hogy a szervezet eleget tegyen a NIS2 18.46-os („Szoftver- és információsértetlenség – Automatikus reagálás”) követelményének, amely kimondja, hogy az EIR-nek automatikusan le kell állnia, újra kell indulnia, vagy végre kell hajtania a meghatározott intézkedéseket, amennyiben a sértetlenségellenőrzés során rendellenességet észlel.

Biztonsági szempontból releváns események észlelése és a FIM megoldások

A NIS2 18.43-as követelményének harmadik technológiai pillére kimondja, hogy a sértetlenségellenőrzéseket a „biztonsági szempontból releváns események esetén” is haladéktalanul le kell futtatni. Ez az előírás a gyakorlatban az úgynevezett eseményvezérelt (Event-driven) működést követeli meg a védelmi architektúrától. Amikor egy rendszerben valamilyen előre definiált, gyanús vagy kritikus biztonsági esemény történik (például:

• sikertelen bejelentkezések sorozata,
• privilegizált adminisztrátori fiókok szokatlan használata,
• új szolgáltatás telepítése, vagy
• egy kritikus rendszerleíró kulcs megváltoztatása),

a védelmi rendszereknek nem szabad megvárniuk a következő ütemezett vizsgálatot, hanem azonnali sértetlenségellenőrzést kell kezdeményezniük az érintett komponenseken.

Ezt a kritikus célt szolgálják a File Integrity Monitoring (FIM), azaz a Fájlsértetlenség-figyelő és ellenőrző megoldások. A FIM folyamatok, szoftverek és beépített kontrollok hivatottak technikai szinten validálni az operációs rendszer érzékeny fájljainak, a szoftveralkalmazások binárisainak, a webkiszolgálók konfigurációs fájljainak, vagy más bizalmas üzleti információt tartalmazó dokumentumoknak a sértetlenségét. A FIM mechanizmus lényege egy "ismert jó" állapot (baseline) előzetes rögzítése, amely során a felügyelni kívánt fájlokról vagy könyvtárakról egy kriptográfiai hash algoritmus (például SHA-256 vagy SHA-3) segítségével lenyomatot készít a rendszer, majd ezt egy biztonságos adatbázisban tárolja. A folyamatos vagy eseményvezérelt megfigyelés során a FIM ágens összeveti az aktuális állapotot a baseline-nal. Ha egy fájl tartalma (és ezáltal a hash értéke), jogosultságai, tulajdonosa, vagy egyéb fájlrendszer-attribútumai megváltoznak, a rendszer azonnal riasztást generál a SIEM (Security Information and Event Management) rendszer irányába, részletezve a változás idejét, jellegét, és ideális esetben a változtatást végrehajtó felhasználó vagy folyamat azonosítóját (Who-data functionality).

A wazuh SIEM/XDR, mint átfogó kiberbiztonsági megoldás

Az egyik legszéleskörűbben alkalmazott, hazai és nemzetközi viszonylatban is bizonyított nyílt forráskódú (open source) eszköz, amely ezen a területen kiemelkedő képességekkel rendelkezik – és amelynek használatát a magyar piacon jelen lévő biztonsági integrátorok és tanácsadók, mint például a Balasys vagy a Tekniska is alkalmazzák vagy hivatkoznak hasonló technológiákra  –, a Wazuh platform.A Wazuh egy Unified XDR (Kiterjesztett Észlelés és Válaszadás) és SIEM rendszer, amelynek egyik legerősebb komponense a natívan integrált FIM modul, amely képes kiszolgálni mind a NIS2 által megkövetelt valós idejű (real-time), mind az ütemezett (scheduled) sértetlenségellenőrzési igényeket.A Wazuh FIM képességei technikai és implementációs szinten a következőképpen elégítik ki a magyar jogszabályi elvárásokat:

1. Valós idejű monitorozás és eseménykövetés: A rendszer adminisztrátorai az agentek konfigurációs fájljában az XML alapú <directories> elemben adhatják meg a kritikus könyvtárakat. A modul az operációs rendszer beépített kernel szintű API-jait (például inotify a Linux rendszereken, vagy a Windows API hívások) használja, így folyamatosan, másodperces késleltetés nélkül, valós időben figyeli a változásokat (real-time attribútum).
2.  Gyakoriság (Frequency) precíz szabályozása: Az xml alapú konfigurációkban a <syscheck> gyökérelemen belül a <frequency> tag segítségével másodperc alapú pontossággal beállítható, hogy a teljes fájlrendszer-bejárás és ellenőrzés milyen időközönként fusson le (például 300 másodperc, vagy 12 óra). Ez a funkció dedikáltan a jogszabály 18.43-as "meghatározott gyakorisággal" kitételét szolgálja ki.
3. Mélyreható naplózás és elszámoltathatóság (Accountability): A report_changes attribútum engedélyezése révén a Wazuh nem pusztán a fájl módosításának száraz tényét rögzíti, hanem a megváltozott tartalmat is képes szöveges fájlok esetében elmenteni (diff formátumban). Ezt a FIM modul a kiterjesztett who-data (ki végezte az adatváltoztatást) funkcióval ötvözi, amely az operációs rendszer audit alrendszeréből kinyerve pontosan azonosítja a felhasználót, a jogosultságot és az azt végrehajtó futtatható állományt, ami kritikus az incidens kivizsgálásához és a NIS2 72 órás jelentéstételi határidejének tartásához.
4. Windows Registry mélyszintű felügyelet: Vállalati végpontok és szerverek esetén a támadások jelentős része a Windows rendszerleíró adatbázist célozza perzisztencia kialakítása céljából. A Wazuh külön <windows_registry> tag-ekkel támogatja a registry kulcsok figyelését (különös tekintettel a HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run és RunOnce kulcsokra), ami alapvető a perzisztens kártevők (APTs) észleléséhez az átmeneti és indítási folyamatok körül.
5. Aktív válaszadás (Active Response) és timeout kezelés: A Wazuh fejlett hálózati képességei révén beállítható a response_timeout paraméter is, amely szabályozza a menedzser szerver és az ágens közötti adatkapcsolat megszakadása esetén a rendszer viselkedését, kikényszerítve az újbóli szinkronizációt. Ezen felül az Active Response modul képes automatikusan blokkolni az IP címeket, vagy leállítani a jogosulatlan módosítást végző folyamatokat (megfelelve a NIS2 18.46-os követelményének).

A Wazuh architektúrájának rugalmassága és nyílt forráskódú mivolta miatt az ipari (OT/ICS) környezetekben is kiemelkedően teljesít. A Tekniska kiberbiztonsági cég esettanulmánya  kiválóan rávilágít, hogy a Wazuh SIEM/XDR képességei hogyan támogatják a NIS2 és az IEC 62443 ipari biztonsági szabványok egyidejű megfelelését a komplex infrastruktúrákban. A platform megszünteti a "vakfoltokat" az IT és az OT infrastruktúra konvergenciája során, és a kereskedelmi licencektől mentes skálázhatóság révén jelentős pénzügyi terheket vesz le az üzemeltetők válláról (egy robusztus konfiguráció, mindössze néhány virtuális géppel képes 2500 végpontot megbízhatóan felügyelni).További Kereskedelmi FIM és Kiberbiztonsági Alternatívák a NIS2 Piacon

Természetesen a nyílt forráskódú megoldások mellett a piacon elérhetőek dedikált kereskedelmi szoftverek is, amelyek a nagyvállalati támogatás (SLA) mellett lefedik a FIM és az információ-sértetlenségi követelményeket, segítve a NIS2 megfelelést :

• Tripwire Enterprise: Az információbiztonsági iparág egyik legkorábbi és legszélesebb körben ismert FIM megoldása. A Tripwire nem csupán a fájlok monitorozására, hanem a teljes informatikai infrastruktúra konfigurációkezelésére (SCM - Security Configuration Management) és a változások szigorú, baseline-alapú kontrolljára fókuszál. Beépített compliance sablonjai (templates) révén nagymértékben megkönnyíti a szabályozói auditokat.
•  Heimdal Security: Moduláris, elsősorban felhőalapú (SaaS) megoldás, amely dedikált eszközkészlettel és központosított vezérléssel segíti a NIS2 megfelelést, integrálva az EDR, a jogosultságkezelés és a patch menedzsment funkciókat.
•  Trend Micro: Erőteljes EDR, XDR és FIM képességekkel rendelkező komplex vállalati megoldás, amely kiterjedt szerver- és hálózatvédelmet biztosít. Bár a rendszer bevezetése és finomhangolása szakértelmet kíván és meredekebb tanulási görbével rendelkezik, az egyik legrobusztusabb kereskedelmi alternatíva.
•  Syteca: Kifejezetten egy fókuszáltabb problémára: a belső fenyegetések (insider threats) megakadályozására és a privilegizált hozzáféréssel (PAM) rendelkező felhasználók tevékenységének videó-alapú és metaszerkesztett ellenőrzésére kiélezett eszköz, amely kiegészítheti a FIM megoldásokat.

Információsértetlenség: az adatbázisok és a kriptográfiai védelem

A magyar NIS2 implementáció (7/2024. MK rendelet) a szoftverek és a firmware-ek mellett nagy hangsúlyt fektet az "információkon" elvégzendő sértetlenségellenőrzésre is. Az elektronikus információs rendszerekben kezelt kritikus üzleti információk, személyes adatok, adatbázisok rekordjai, valamint az alkalmazások működését szabályozó konfigurációs paraméterek jogosulatlan módosítása közvetlen üzletmenet-folytonossági és jogi kockázatot hordoz. A 18.47-es jogszabályi pont (Szoftver- és információsértetlenség – Kriptográfiai védelem) kifejezetten és dedikáltan nevesíti a kriptográfiai mechanizmusok kötelező alkalmazását az információk jogosulatlan módosításainak megelőzésére és észlelésére.

Ezen az érzékeny területen az információvédelemben az elmúlt években az úgynevezett Data-Centric Security (adatközpontú biztonság) filozófiája és architektúrája érvényesül. A hagyományos peremvédelmi (perimeter) eszközök (tűzfalak, VPN-ek) elégtelenek a belső hálózaton mozgó, vagy felhőbe szinkronizált adatok integritásának védelmére. Az adatközpontú védelmi megoldások, mint például a SealPath technológiái, a bizalmas dokumentumokba és adatbázis-kivonatokba épített folyamatos, az adat életciklusát végigkísérő titkosítással (például AES-256) és folyamatos jogosultságkezeléssel (IRM/DRM) biztosítják az információsértetlenséget. Ez a megközelítés garantálja, hogy egy adott fájl vagy adatrekord csak a megfelelő, kriptográfiailag hitelesített felhasználó vagy rendszerfolyamat számára, és kizárólag a központilag engedélyezett módon (például csak olvashatóként) legyen manipulálható, ezáltal őrizve annak sértetlenségét a hálózati tranziton (Data in Transit) és a tárolás során is (Data at Rest).

Az adatok és az információk sértetlensége ugyanakkor nem választható el a megbízható identitás- és jelszókezelési (IAM) gyakorlatoktól, valamint a kötelező többtényezős hitelesítéstől (MFA) sem. A privilegizált adminisztrátorok fiókjainak kompromittálódása esetén a támadó a FIM és az adatközpontú megoldások konfigurációit is képes lenne megváltoztatni. Az ISAE 3402 szolgáltatás-ellenőrzési és az ISO/IEC 27001 információbiztonsági szabványokhoz hasonlóan a NIS2 megfelelés érdekében az információ-sértetlenség egy tágabb irányítási keretbe illeszkedik. Az adatbázis-kezelő rendszereknél az adatbázisok sértetlenségének ellenőrzése történhet beépített integritásvizsgáló lekérdezésekkel, adatbázis tevékenység-monitorozó (DAM) eszközökkel, vagy olyan kriptográfiai technikákkal, mint a TDE (Transparent Data Encryption). A jövőbemutató megoldások között a Blockchain technológia immutábilis (visszamenőlegesen megváltoztathatatlan, elosztott főkönyvi) jellege szintén feltörekvő megoldás az adatok, a rendszerlogok és a kritikus ellátási lánc információinak hitelesítésére és manipulációmentességének garantálására.

A folyamatos és átfogó naplózás nem csupán a technikai hibaelhárítás eszköze, hanem alapkövetelmény az információsértetlenség jogi bizonyíthatóságához (18.49: "Szoftver- és információsértetlenség – Naplózás és riasztás"). A rendszernek minden, a sértetlenség potenciális sérülésére utaló eseményt megmásíthatatlanul naplóznia kell, a SIEM rendszereken keresztül az üzemeltető felhasználóknak és az adminisztrátoroknak valós idejű riasztást kell küldenie, és szükség esetén (a szabályrendszerben meghatározott kritikus fájlok vagy adatbázis-szegmensek érintettsége esetén) a rendszert automatikusan le kell állítania vagy elszeparálnia (18.46-os követelmény).

Szervezeti GRC (Governance, Risk, Compliance) és biztonságmenedzsment eszközök a NIS2 megfelelésben

A technikai megoldások és biztonsági szoftverek implementációja csupán a jéghegy csúcsát jelenti a NIS2 teljes körű megfelelésében. Ahogy a magyar jogszabályok – különösen a 18.1.1-es követelmény – egyértelműen kimondják, a szervezetnek ki kell dolgoznia, dokumentálnia és formálisan kiadnia egy felsővezetői szinten jóváhagyott "rendszer- és információsértetlenségi szabályzatot" és az ehhez kapcsolódó technikai eljárásrendeket. Ezen adminisztratív védelmi intézkedések létrehozása, életciklusuk kezelése és naprakészen tartása különösen a nagyvállalatok és az államigazgatási szervek esetében rendkívül komplex és erőforrás-igényes kihívás.Az adminisztratív keretrendszerek fenntartására és az SZTFH által delegált felügyeleti auditorok  felé történő bizonyítékok (evidence) strukturált, transzparens és könnyen kereshető bemutatására dedikált GRC (Governance, Risk, and Compliance) vállalati szoftverek alkalmazása ajánlott és szinte megkerülhetetlen. Az alábbi, NIS2-re felkészített platformok hivatottak támogatni ezen compliance erőfeszítéseket az európai és a magyar piacon :

• Hyperproof: Vállalati szintű platform, amely valós idejű kockázatfigyelést, testreszabható incidenskezelési munkafolyamatokat és strukturált audit bizonyítékgyűjtést tesz lehetővé, drasztikusan csökkentve a NIS2 megfelelési folyamatok manuális és táblázatkezelőkre épülő adminisztrációs terhét.
• ISMS.online: Kifejezetten a nemzetközi szabványok (pl. ISO 27001) és a NIS2 követelmények együttes összehangolására és menedzselésére alkalmas keretrendszer. Strukturált, verziókövetett dokumentációt, hozzájárulási (sign-off) munkafolyamatokat és teljesítménymutató (KPI) monitorozást biztosít a vezetőség számára. A felületen integráltan kezelhetők a kockázatértékelések, összekapcsolva azokat az üzleti folyamatokkal, és az incidens-dokumentáció egy kattintással exportálható az auditorok számára (CSV, Excel formátumokban).
• 3rdRisk: Kifejezetten az európai kiberbiztonsági szabályozásokra optimalizált, beépített legjobb gyakorlatokat tartalmazó modern felhős platform. Kiemelkedően erős képességekkel rendelkezik a NIS2 által megkövetelt ellátási lánc (Supply Chain) és a külső harmadik felek (third-party) kockázatkezelésében. Intuitív felülettel és beépített munkafolyamatokkal rendelkezik, így hatékonyan támogatja a magyar szervezeteket a kiberbiztonsági beszállítói láncuk átvilágításában, jóllehet a policy-menedzsment modulja kevésbé robusztus.
• Aptien: Főként a dokumentációra, a szoftver/hardver eszközkatalógusokra és a belső szabályzatok nyilvántartására és életciklus-menedzsmentjére fókuszáló rendszer, amely kiegészítheti a szigorúan vett IT biztonsági megoldásokat.

A technikai naplók (SIEM riasztások, FIM logok) önmagukban, a megfelelő adminisztratív keret nélkül nem elégítik ki egy esetleges szigorú felügyeleti hatósági vagy auditori vizsgálatot. Ahogyan az iparági szakirodalom kiemeli, egy "nyers SIEM export" kontextus nélkül, a bizonyítékok sértetlen láncolata (chain of custody) és a vezetői jóváhagyások hiányában nem fogadható el meggyőző bizonyítékként egy jogi felelősséget firtató incidensvizsgálat során. A modern GRC eszközök képesek hidat képezni a nyers technikai mérések (mint a Wazuh riasztásai, a Keylime távoli attesztációs naplói, a TPM PCR logok) és a szükséges emberi kontextus (ki hagyta jóvá a rendszerleíró adatbázis változtatását, mi volt az átmeneti állapot kiváltó oka, hogyan és mikor kezelték le az ehhez kapcsolódó IT ticket-et) között.

Rendszerezett technológiai megoldások: gyakorlati útmutató

Az alábbi összefoglaló táblázatban bemutatok egy példát arra az eszközkészletre és technológiai gyűjteményre, amelyek – egymással ötvözve – alkalmasak a magyar Kibertv. és a 7/2024. MK rendelet 18.43-as követelményének maradéktalan technikai támogatására.

Implementációs kihívások, ütemezés és auditori szemlélet Magyarországon

A magyarországi jogszabályi implementációs idővonal szigorú és feszített tempót diktál. Az érintett (alap, jelentős vagy magas kategóriába sorolt) szervezeteknek legkésőbb 2024. június 30-ig kellett regisztrálniuk az SZTFH nyilvántartásába, és el kellett végezniük elektronikus rendszereik biztonsági osztályba sorolását. A következő kritikus mérföldkő 2024. december 31. volt, ameddig kötelezően szerződést kellett kötniük a kiberbiztonsági audit lefolytatására egy, az SZTFH által hivatalosan nyilvántartásba vett független auditorcéggel (amelyek listáján a 2024-es adatok szerint többek között szerepel az Alverad, az Andrews, a VantaSec, az Ernst & Young, és a HUNGUARD). A 2025. év elején (konkrétan 2025. január 31-én) az SZTFH megjelentette azt a várva várt rendeletet, amely szabályozza a kiberbiztonsági audit eljárásrendjét és meghatározza az eljárás maximalizált díjait is, így a piac jelenleg az éles auditok végrehajtására fókuszál. Magát a teljes felkészülést, a hiányosságok pótlását és az audit sikeres lebonyolítását a jogszabályi elvárások szerint 2025. december 31-ig volt szükséges maradéktalanul lezárni (elvileg).

A sikeres auditori igazolás kritériuma a 7/2024. MK rendeletben foglalt védelmi intézkedéseknek való dokumentált és technológiailag is igazolható megfelelés bizonyítása. A szakértői ellenőrzések során az EIR-ben (Elektronikus Információs Rendszer) alkalmazott szoftverek és a futtatható elemek sértetlensége tekintetében az auditor vizsgálni fogja a „legszűkebb funkcionalitás” (Least Privilege) elvének érvényesülését, valamint az úgynevezett Application Whitelisting („kivétel alapú engedélyezés”) meglétét (6.31-es és 6.32-es követelmények). A biztonsági riasztások és a FIM által detektált sértetlenségi hibák kezelése során az auditor ellenőrizni fogja a riasztások forrásának hitelességét (sérülékenységi információk folyamatos fogadása az NKI-tól, CERT-ektől), illetve az informatikai környezet sérülékenységmenedzsmentjére, hibajavítási folyamataira (patch management, a firmware frissítések rendszeressége például a fwupdmgr használatával) vonatkozó objektív igazolásokat.

Különös figyelmet kell fordítani a hibrid követelmények kezelésére. Olyan esetekben, ahol a rendszer üzemeltetését vagy hosztolását részben vagy egészben egy külső szolgáltató végzi (például felhőalapú szolgáltatások, SaaS, vagy kihelyezett IKT üzemeltetés esetén), az auditor megköveteli az SLA-k (Service Level Agreement) és a biztonsági felelősségmegosztási modellek felülvizsgálatát. Az üzemeltetési szerződésekben kötelemként kell érvényesíteni, hogy a szolgáltató képes legyen biztosítani és az audit során leigazolni a NIS2 sértetlenségellenőrzési (indításkori, átmeneti és eseményvezérelt) kritériumainak teljesítését. A rendszer- és információsértetlenségi feltételrendszerének kialakítása és szerződéses garanciáinak megteremtése minden esetben az információbiztonsági felelős (IBF) dedikált hatásköre és felelőssége.

Az eljárásrendek alkalmazását a szervezeteken belül rendszeres, eseményvezérelt gyakorlatokkal (kiber szimulációk, próbariadók, Red Team tesztek) szükséges visszamérni a kockázatmenedzsment keretében. A gyakorlat azt mutatja, hogy bármilyen magasan fejlett technikai megoldás (például egy jól finomhangolt Wazuh FIM modul riasztása egy megváltozott Windows registry kulcsról) értéktelen marad a vállalat számára, ha arra az eszkalációs és eseménykezelő folyamat (Incident Response plan) nem képes a törvényben meghatározott szűk időablakon belül, szakszerűen reagálni, illetve a menedzsment nem kapja meg a szükséges információkat a hatósági bejelentéshez. A humán kockázatok proaktív minimalizálása, az alkalmazottak biztonságtudatosságának növelése (képzések) és a privilegizált hozzáférések szigorú ellenőrzése ugyanolyan meghatározó, elválaszthatatlan részét képezik a szervezet információsértetlenségének és a NIS2 megfelelésnek, mint a legmodernebb hardveres TPM chipek vagy a komplex kriptográfiai algoritmusok integrációja.

Stratégia, összegzés, lezárás

A magyarországi NIS2 jogszabálycsomag végrehajtási rendelete, és abban is kiemelten a vizsgált 18.43-as követelmény, amely az EIR szoftveres, firmware és információ szintű sértetlenségének többdimenziós (időbeli és rendszerállapoti) ellenőrzését írja elő, valódi paradigma-váltást jelent a hazai kibervédelmi és rendszerüzemeltetési gyakorlatban. A korábban sokszor elhanyagolt, "láthatatlan", az operációs rendszer alatti rétegekben megbúvó infrastrukturális elemek, mint a BIOS/UEFI firmware beállítások és az ezekhez szorosan kapcsolódó alacsony szintű hardveres védelmi funkciók (TPM chipek kihasználása) most az auditori megfelelés és az incidensmegelőzés abszolút fókuszába kerültek.

A megfelelő és jövőálló "eszközkészlet" kiválasztásakor a hazai szervezeteknek túl kell lépniük a tradicionális vírusirtó szoftverek (Legacy AV) telepítésén, és integrált, skálázható, az on-premise, az ipari (OT) és a hibrid felhős infrastruktúrákat egyaránt megbízhatóan átívelő architektúrákban kell gondolkodniuk:

1. A hardver- és boot-biztonság kikezdhetetlen garantálása érdekében elengedhetetlen a TPM 2.0 chipek szervezeti szintű aktiválása és a UEFI Secure Boot szigorú, központilag menedzselt házirendek (GPO, MDM) szerinti konfigurálása. Ezt az alapvető védelmet a fejlettebb környezetekben a távoli attesztációs folyamat (Keylime architektúra) vagy a dedikált vállalati firmware-scannerek (Eclypsium) bevezetése teszi teljessé.
2. Az átmeneti állapotok felügyelete és az eseményvezérelt sértetlenségellenőrzés csak folyamatos, valós idejű, stream-alapú naplófeldolgozással és az élvonalbeli XDR/EDR biztonsági megoldások (mint a Wazuh vagy a Trend Micro) nasználatával oldható meg, amelyek az adatokon, a hálózati forgalmon és a folyamatokon a memóriában is képesek azonnali, automatizált analízist végezni.
3. Az adminisztratív megfelelés, a szabályozói elvárások szigorú dokumentálása és a vezetői felelősségvállalás támogatása okán elengedhetetlen egy specializált GRC szoftverplatform (például az ISMS.online, a Hyperproof, vagy ellátási lánc fókusszal a 3rdRisk) bevezetése a biztonsági kontrollok folyamatos monitorozására és a bizonyítékok transzparens ("chain of custody") kezelésére.

Ezen technológiai, folyamati és szervezeti intézkedések összehangolt, harmonizált megvalósítása biztosítja a jelentős és magas biztonsági osztályba sorolt hazai elektronikus információs rendszerek ellenálló képességét, az adatlopások és a kritikus leállások sikeres megakadályozását. Mindez lehetővé teszi, hogy a magyar vállalatok eleget tegyenek a NIS2 direktíva által támasztott legszigorúbb uniós transzparencia és védelmi elvárásoknak, elkerülve a súlyos bírságokat. Mivel a jogszabályok megkövetelik a biztonsági észleléseknek az automatizált incidenskezelési rendszerekbe történő mély integrálását, az egymástól elszigetelt, pontszerű megoldások (siloed tools) halmozása helyett az egységes biztonsági architektúra kiépítése a fenntartható, auditálható megfelelés egyetlen racionális és járható útja. Ugyanakkor ami ennél is fontosabb, az általam felsorolt technológiák és eszközök, valamint a kapcsolódó folyamatok és szabályozás kialakítása, egyaránt egy jelentős lépés a biztonsági szint emelésének irányába. Nem utolsó sorban, pedig, nem csak a 18.43-as követelményt, de számos más biztonsági itézkedést is kipipálhatunk a megfelelési palettán, vagy máshogy fogalmazva, számos más ajtót és ablakot is bezárunk általuk a támadók előtt. Sikeres felkészülést mindenkinek!