Oldal Kiválasztása

NIS2 Kockázatelemzési Módszertan és Technikai Sebezhetőségvizsgálat

A NIS2 irányelv egyik legkritikusabb, ugyanakkor leggyakrabban félreértett követelménye a kockázatelemzés. Sok szervezet ezt egy egyszeri, dokumentum-alapú feladatnak tekinti, pedig valójában egy folyamatosan működő, strukturált módszertant igényel, amely összeköti a technikai sebezhetőségeket a üzleti kockázatokkal. Ez a cikk bemutatja, hogyan kell felépíteni egy NIS2-kompatibilis kockázatelemzési rendszert, hogyan illeszthető be a CVSS pontozási rendszer a vállalati infrastruktúra védelmébe, és miért elengedhetetlen a logikai és fizikai védelmi szintek szétválasztása.

Miért nem elég egy Excel táblázat?

A NIS2 irányelv (2022/2555 EU direktíva) és a magyar jogharmonizáció (2023. évi XXIII. törvény) explicit módon megköveteli a kockázatalapú megközelítést az információbiztonsági intézkedések kialakításánál. Ez azt jelenti, hogy a szervezet nem választhat tetszőlegesen védelmi intézkedéseket, hanem azoknak arányosnak kell lenniük a feltárt kockázatokkal.

A gyakorlatban ez azt jelenti, hogy egy egyszerű, szubjektív "magas/közepes/alacsony" besorolás alapú táblázat auditon nem állja meg a helyét. Szükség van egy olyan módszertanra, amely:

  • objektív, mérhető pontozási rendszert használ (pl. CVSS),
  • összeköti a technikai sebezhetőségeket az üzleti hatással,
  • dokumentálja a döntési logikát, nem csak a végeredményt,
  • ismételhető és auditálható módon frissíthető.

A kockázatelemzés alapstruktúrája NIS2 kontextusban

Egy formális kockázatelemzés négy fő lépésből épül fel: eszközleltár és -osztályozás, fenyegetés- és sebezhetőségazonosítás, kockázatszámítás, valamint kezelési döntés. Nézzük végig ezeket részletesen.

1. Eszközleltár és kritikussági besorolás

Minden kockázatelemzés alapja egy pontos eszközleltár. Ez nem csupán a szerverek és munkaállomások listázását jelenti, hanem az adatfolyamok, alkalmazások, harmadik féltől származó szolgáltatások és fizikai infrastruktúra elemeinek feltérképezését is. Minden eszközhöz hozzá kell rendelni egy kritikussági besorolást, amely tükrözi, hogy annak kiesése vagy kompromittálódása milyen mértékben veszélyeztetné az alapvető vagy fontos szolgáltatás folytonosságát.

Javasolt kritikussági szempontok:

  • Az eszköz szerepe a szolgáltatás nyújtásában (közvetlen vs. támogató funkció)
  • Az eszközön kezelt adatok bizalmassági szintje
  • Az eszköz kiesésének helyreállítási ideje (RTO)
  • Az eszköz kitettsége külső hálózatok felé

2. Fenyegetés- és sebezhetőségazonosítás

Ebben a lépésben történik a technikai sebezhetőségvizsgálat, amely lehet automatizált (sebezhetőségscanner, pl. Nessus, OpenVAS, Qualys) vagy manuális (penetrációs teszt, kódaudit). A cél nem pusztán a sebezhetőségek listázása, hanem azok kontextusba helyezése: egy adott sebezhetőség kihasználhatósága, az érintett eszköz kritikussága és a fenyegető szereplők valószínű motivációja együttesen határozzák meg a tényleges kockázatot.

A CVSS pontozási rendszer integrálása

A CVSS (Common Vulnerability Scoring System) egy nemzetközileg elismert, szabványosított keretrendszer a szoftversebezhetőségek súlyosságának számszerűsítésére. A jelenleg használt CVSS 3.1 és a fokozatosan terjedő CVSS 4.0 verzió is három fő metrikacsoportra épül:

  • Base Score – a sebezhetőség önmagában vett, környezettől független súlyossága (támadási vektor, komplexitás, szükséges jogosultság, felhasználói interakció, hatás a bizalmasságra/sértetlenségre/rendelkezésre állásra)
  • Temporal Score – időben változó tényezők, mint a kihasználtság elérhetősége (exploit kód léteszik-e), javítás elérhetősége
  • Environmental Score – a konkrét szervezeti környezetre adaptált pontszám, amely figyelembe veszi az adott eszköz üzleti kritikusságát

A NIS2 megfelelés szempontjából kulcsfontosságú, hogy a szervezetek ne csak a Base Score-t vegyék figyelembe, hanem az Environmental Score-t is számítsák ki. Egy 9.8-as CVSS Base Score-ral rendelkező sebezhetőség egy izolált, nem kritikus teszt szerveren lényegesen alacsonyabb tényleges kockázatot jelent, mint egy 6.5-ös pontszámú sebezhetőség egy nyilvánosan elérhető, ügyféladatokat kezelő rendszeren.

Gyakorlati integrációs modell

Egy működőképes CVSS-alapú kockázatkezelési folyamat a következő lépésekből áll:

  1. Rendszeres (havi vagy negyedéves) sebezhetőségvizsgálat futtatása minden eszközosztályon
  2. Az eredmények automatikus összekapcsolása a NVD (National Vulnerability Database) CVSS adataival
  3. Environmental Score számítása az eszközleltárban rögzített kritikussági adatok alapján
  4. Küszöbértékek meghatározása (pl. 7.0 feletti Environmental Score esetén kötelező 30 napon belüli javítás)
  5. Az eredmények bevezetése a szervezeti kockázatnyilvántartásba, felelős és határidő hozzárendelésével

Ez a modell biztosítja, hogy a javítási prioritások ne szubjektív döntések, hanem dokumentált, számszerűsíthető adatok alapján szülessenek – ez az, amit egy NIS2 hatósági ellenőrzés során be kell tudni mutatni.

Logikai és fizikai védelmi szintek elválasztása

A NIS2 irányelv technikai és szervezeti intézkedésekről egyaránt rendelkezik, és sok szervezet hibázik abban, hogy a kockázatelemzés során összemossa a logikai (informatikai) és fizikai védelmi rétegeket. Ez a szétválasztás azért kritikus, mert a két terület kockázatai eltérő jellegűek, eltérő szereplők kezelik, és eltérő kontrollokkal mérséklendők.

Logikai védelmi szint

Ide tartoznak a hálózati szegmentáció, a hozzáférés-kezelés, a titkosítás, a naplózás és monitorozás, valamint maga a szoftveres sebezhetőségkezelés. A kockázatelemzésben ezen a szinten a fő kérdés az, hogy egy támadó milyen úton juthat be a rendszerbe, és onnan milyen mértékben tud oldalirányban mozogni (lateral movement).

Fizikai védelmi szint

A fizikai réteg a szerverterem-hozzáférést, a hardvereszközök fizikai védelmét, a környezeti kockázatokat (tűz, áramkimaradás, elárasztás) és a fizikai behatolás elleni védelmet foglalja magába. Sok szervezet alábecsüli ezt a réteget, pedig egy fizikailag hozzáférhető eszköz esetén a legtöbb logikai védelmi kontroll megkerülhető.

A két réteg elválasztásának gyakorlati előnye, hogy a kockázatnyilvántartásban külön-külön lehet felelősöket, határidőket és kontrollokat hozzárendelni, illetve az auditor számára is világosan bizonyítható, hogy a szervezet mindkét dimenziót tudatosan kezeli – nem csupán az informatikai osztály feladataként tekint a NIS2 megfelelésre.

A kockázatkezelési döntés dokumentálása

A kockázatelemzés végső lépése a kezelési döntés: elfogadás, mérséklés, áthárítás vagy elkerülés. A NIS2 megfelelés szempontjából a legfontosabb elv, hogy minden döntést dokumentálni kell, indoklással együtt. Ha egy szervezet úgy dönt, hogy egy közepes kockázatú sebezhetőséget egyelőre elfogad (mert például a javítás üzleti kockázatot jelentene a szolgáltatás folytonosságára), ezt a döntést és annak indoklását írásban rögzíteni kell, felelős vezető jóváhagyásával.

Összefoglalás döntéshozók számára

A NIS2 kockázatelemzés nem informatikai belügy, hanem üzleti kockázatkezelési feladat, amelyben az informatikai vezetés technikai inputot ad, a szervezet vezetése pedig kockázatvállalási döntéseket hoz. A CVSS-alapú, objektív pontozási rendszer bevezetése nemcsak a megfelelést könnyíti meg, hanem valós védelmi értéket is teremt: a korlátozott erőforrásokat oda irányítja, ahol a tényleges kockázat a legnagyobb. A logikai és fizikai védelmi szintek tudatos szétválasztása pedig biztosítja, hogy egyetlen kritikus terület se maradjon felelős és kontroll nélkül.

Egy jól felépített, rendszeresen frissített kockázatelemzési módszertan nemcsak a NIS2 auditon való megfelelést biztosítja, hanem a szervezet valós kiberbiztonsági ellenállóképességét is jelentősen növeli.