Mit tanultunk az első NIS2-auditokból?

Az első NIS2-auditokon a szervezetek jellemzően a bevezetést mutatták be, vagyis a szabályzatokat, a rendszerbiztonsági terveket és a nyilvántartásokat. A valódi próba a két év múlva esedékes NIS2-audit lesz, amikor a jogosultságok igénylésének, jóváhagyásának és felülvizsgálatának tényleges működését kell igazolni. A szakértők azt javasolták, hogy a szervezetek vegyék elő az auditon bemutatott bizonyítékaikat, és őszintén mérlegeljék, fenntarthatók-e.

Az SZTFH tájékoztatása szerint az auditok mintegy tíz százaléka zárult nem megfelelt eredménnyel. A workshop szakértői szerint alapos vizsgálat mellett ez az arány harminc százalék körül lenne. Egy kilencvenhárom százalékos eredmény után nehéz a vezetést újabb beruházásról meggyőzni, pedig a hamis biztonságérzet veszélyesebb a szigorú hozzáállásnál.

A bizonyításban sokat segít egy feladat- és folyamatkezelő rendszer, mert utólag is előhívható belőle az igénylés, a jóváhagyás és a végrehajtás. Az időbélyeges bejegyzést nehezebb meghamisítani, mint egy aláírt papírt. Ingyenes megoldásként a Redmine, a GLPI és a Mantis került szóba.

Van mini NIS2-audit egy kisvállalkozásnak?

Mini NIS2-audit nem létezik. Az SZTFH nyilvántartásában szereplő auditor nem kötelezett szervezetnél is végezhet önkéntes, de teljes körű NIS2-auditot, a belső audit vagy a tanácsadói felmérés viszont nem jelent hivatalos megfelelést. A szervezet ettől még kommunikálhatja, hogy a NIS2 követelményei szerint építi ki a rendszereit.

Kisvállalkozásoknak két ingyenes kiindulópont ajánlott. Az egyik az ENISA önértékelési keretrendszere, amely konkrét fejlesztési javaslatokat ad. A másik a 7/2024. (VI. 24.) MK rendelet alap biztonsági osztályra vonatkozó követelménylistája, amely a NIST SP 800-53 kontrolljaira épül, ezért bőséges minta érhető el hozzá. Ha a rendszergazdával végigmennek rajta, az már érdemben javítja a biztonságot.

Szoftverfejlesztőknek az önkéntes audit más okból is megérheti. Az új termékfelelősségi irányelv a 2026. december 9. után forgalomba hozott termékekre alkalmazandó, és a szoftvert is terméknek tekinti. A bizonyítási teher nem fordul meg, a bíróság azonban bizonyos esetekben vélelmezi a hibát, így egy független audit jól igazolhatja a biztonságos fejlesztői működést.

Mit fogad el az auditor, ha a rendszert az anyavállalat üzemelteti?

A NIS2-auditon a rendelkezési jog dönti el, mit kell a szervezetnek bizonyítania. Teljes rendelkezésnél a szervertől az alkalmazásig mindenért ő felel, ha pedig semmilyen rendelkezési joga nincs, a rendszert elég felsorolni. Részleges rendelkezésnél a rendszerbiztonsági tervben és az anyavállalattal kötött szerződésben kell rögzíteni, melyik kontrollért ki felel.

A puszta megfelelési nyilatkozat nem elég, konfigurációs bizonyíték is kell, például képernyőkép a jelszókomplexitás beállításáról. Felhőszolgáltatásnál a licenctípus dönti el, mi van a szervezet kezében. Amit maga konfigurál, azt neki kell bizonyítania, a szolgáltatói kontrollokat a közzétett audit- és SOC-jelentések támaszthatják alá. Ebben segít a Nemzeti Kibervédelmi Intézet (NKI) megfeleltetési dokumentuma, amely a rendelet követelményeit az ISO 27001 és a NIST SP 800-53 kontrolljaihoz rendeli.

SecureBot vagy betörési teszt?

Az MKIK SecureBot rendszere regisztráció után térítésmentesen vizsgálja a vállalkozások internetre nyitott szolgáltatásait, elsősorban a honlapokat. Elter András szerint a kkv-knál gyakori az elavult szoftver és a sérülékenységet okozó konfigurációs hiba. A rendszer három részből áll.

• Sérülékenységvizsgáló. Általános vizsgálattal, portszkenneléssel és hibatípusokra szakosodott modulokkal ellenőrzi a webes szolgáltatásokat, az eredmény tételes PDF-jelentés.
• Riasztórendszer. Csak a cég által megjelölt szoftverekről küld értesítést, ha azokban javítható sérülékenység jelenik meg.
• Szállítói adatbázis. Közel nyolcvan hazai szoftverfejlesztő és biztonsági cég szerepel benne.

A vizsgálathoz hozzájárulási nyilatkozatot kell feltölteni, így idegen rendszer nem szkennelhető. Eddig több száz cég vizsgáltatta meg magát, több helyen kritikus hiba is előkerült. A SecureBot dokumentált használatával alap osztályban egy-két, jelentős osztályban hat-hét követelmény teljesítése támasztható alá.

A szkenner a nyilvántartott (CVE) hibákat keresi, ezért ha nem talál semmit, attól még lehetnek komoly hiányosságok. Az elvárás a biztonsági osztállyal nő, a sérülékenységek követésétől a sérülékenységvizsgálaton át a betörési tesztig. Egy infrastruktúrára szabott betörési teszt néhány millió forint, alkalmazásokkal együtt könnyen tízmillió forint fölé megy, ami a legtöbb kkv-nak rendszeresen nem vállalható.

A legtöbb támadás a hozzáféréseknél kezdődik

A workshop második felében a szakértők egy képzeletbeli, 150 fős gyártó középvállalaton, a Buborék Zrt.-n mutatták be, hogyan fordíthatók le a követelménycsaládok technológiai döntésekre.

A hozzáférés-felügyelet a NIS2-megfelelés egyik legtöbb technológiát igénylő területe, mert a szakértők szerint a támadások nagy része a túlzó, felül nem vizsgált hozzáférésekből indul. Egy bizonyos méret felett az LDAP-alapú központi címtár, jellemzően az Active Directory, a reális megoldás, amellyel a jelszóházirend és a fiókzárolás központilag kikényszeríthető. A távoli hozzáférést VPN-en, központilag kezelt fiókkal érdemes adni, külső rendszergazdánál második faktorként a szerződés idejére szóló tanúsítvánnyal. Egy betörési teszten hatvan nyitva felejtett távoli támogatási munkamenet volt elérhető az internet felől.

A többfaktoros hitelesítés a privilegizált fiókoknál alap osztályban is kötelező, a szakértők mégis mindenkinél javasolják, mert jellemzően az átlagfelhasználó kattint az adathalász levélre. A jelszavakat jelszókezelőben (KeePass, Bitwarden) érdemes tárolni, és a NIST SP 800-63B szerint a gyakori kötelező csere helyett hosszú jelmondat ajánlott.

Milyen naplózás és monitorozás kell a NIS2-höz?

Alap biztonsági osztályban a NIS2-naplózás alapja az időszinkron, mert eltérő rendszeridők mellett nem állapítható meg az események sorrendje. A naplót addig kell megőrizni, ameddig egy incidens kivizsgálásához vissza kell tudni menni. A syslog megfelelő, a naplózás leállására viszont riasztás kell, ehhez egy szkript vagy a Zabbix is elég. Jelentős osztályban a naplókat központilag kell gyűjteni és automatikusan feldolgozni, ami gyakorlatilag SIEM-rendszert jelent (például Wazuh, illetve az Elastic és a Graylog ingyenes kiadása).

A rendelet monitorozó rendszert nem ír elő, de bizonyítani kell, hogy valaki ténylegesen figyeli az eszközöket. A nagy tömegű adatletöltésre is érdemes riasztást állítani, egy hazai online kereskedő éppen a szokatlan kimenő forgalomból vette észre az ügyféladatok kiszivárgását.

Hogyan áll talpra egy cég egy zsarolóvírus-támadás után?

Az üzletmenet-folytonosság azt rendezi, mit csinál az üzlet, amíg az informatika áll, és hogyan épül újra az infrastruktúra. Alap osztályban a mentés megléte elegendő, de annak visszaolvashatónak kell lennie, ezért technológiaváltáskor a régi adathordozók olvasóját is meg kell őrizni. Jelentős osztályban alternatív feldolgozási helyszín is kell. A tartalék helyszín kezdeményezze a szinkronizációt, mert ha az elsődleges oldal mindent automatikusan átmásol, a zsarolóvírus is megkettőződik.

A redundáns internetnél a két szolgáltató vonala ne fusson ugyanabban a védőcsőben. Az eseménykezelésben előre rögzíteni kell, ki dönthet szombat hajnalban a bejelentésről, és termelőüzemben ne a helyszíni operátor döntsön az újratelepítésről, mert eltűnhetnek a kivizsgáláshoz szükséges nyomok. A szakértők arra kérték a résztvevőket, gondolják végig, mennyi idő alatt állnának helyre egy teljes támadás után, és kibírnák-e ezt bevétel nélkül.

Régi rendszerek, frissítések és pendrive-ok

A 7/2024. MK rendelet nem tiltja a támogatás nélküli rendszereket, de kockázatként kell kezelni őket. Egy gyárban életszerű, hogy egy SCADA- vagy MES-rendszer csak régi operációs rendszeren fut, ilyenkor tudni kell, hol van, és milyen kiegészítő kontrollok védik. A szakértők a mikroszegmentációt emelték ki. Ha az azonos típusú eszközök, például a nyomtatók vagy a HMI-k külön VLAN-ba kerülnek, egyszerű port- és protokollszabályokkal minden más forgalom tiltható. Az SSL és a TLS 1.2 előtti változatok nem biztonságosak, ezeket le kell tiltani.

A konfigurációkat el kell menteni, ami a hálózati eszközöknél gyakran elmarad, és a felhasználó ne legyen rendszergazda. A frissítéskezelő jelentéseit is át kell nézni, egy ügyfélnél a jól működőnek hitt automatikus frissítés mellett két éve nem frissült gép is akadt. A karbantartók gyakran gyárról gyárra viszik a pendrive-jukat, ezért a szakértők hálózatra nem kötött ellenőrző gépet javasoltak, amelyen minden külső adathordozót legalább két független víruskeresővel átvizsgálnak.

Ki venné át holnap az ERP támogatását?

Az ellátási lánc kockázatkezelésében azt kell feltárni, ki tudná két héten belül átvenni egy kritikus rendszer támogatását, ha a partner holnap megszűnne. Különösen kockázatosak az egyszemélyes szállítók és a kis fejlesztőcégek egyedi szoftverei. A nyílt forráskódú szoftver nem tiltott, de a kockázatelemzésben vizsgálni kell, él-e még a projekt, és képes-e a saját vagy a külső üzemeltető támogatni. Az MI-t tartalmazó rendszereknél a besorolás a rendszer alapfunkciójából és a kezelt adatokból indul, az AI Act kockázati szintjei nem feleltethetők meg a NIS2 biztonsági osztályainak.

Beszerzéskor a rendszerbiztonsági terv kontrolljain kell végigmenni, és szerződésben rögzíteni a szállítóhoz kerülőket, például a sérülékenységek javításának határidejét. Amit nem szüntetnek meg, azt a vezető aláírásával vállalja, hiszen a Kiberbiztonsági törvény a felelősséget a szervezet vezetőjére helyezi. A szakértők a Cyber Resilience Act és az AI Act követelményeire is figyelmeztettek, és magas kockázatú MI-rendszer beszerzésénél érdemes rögzíteni, hogy a gyártó külön díj nélkül megfelel majd.

Mit tegyen most egy kkv?

• Vegye elő az első audit bizonyítékait, és nézze meg, mi tartható fenn két évig.
• Vezessen be jegykezelő rendszert, és rögzítsen benne minden jogosultság-igénylést.
• Kapcsolja be a többfaktoros hitelesítést, legalább a rendszergazdai és a távoli fiókokon.
• Állítson be riasztást a naplózás leállására és a szokatlan adatforgalomra.
• Próbálja ki, visszaállítható-e a mentés, és mérje fel, meddig bírná a cég informatika nélkül.
• Futtasson SecureBot-vizsgálatot a honlapjára.