Szerverfirmware és NIS2: miért válik az elmaradt patch konkrét auditakadállyá?

Ez a cikk a NIS2 megfelelés hardver szempontból sorozat negyedik része. Az előző részekben az EOL/EOS auditakadályokat és az iDRAC/iLO menedzsment interfész lezárásának lépéseit vizsgáltuk. Ebben a részben a firmware patch menedzsment NIS2-elvárásait és a konkrét megvalósítást mutatjuk be.

A NIS2-megfelelési felkészülés legtöbbször három területen indul el: a hálózat biztonsága, a hozzáférés-kezelés, az incidens jelentése. A firmware patch menedzsment ezzel szemben az a terület, amelyről a legtöbb szervezetnél nincs dokumentáció, a frissítési ciklus esetleges, és az auditor mégis pontosan erről kérdezi a rendszergazdát. Ez a cikk bemutatja, mit vár el tőled konkrétan a szabályozás, milyen valós CVE-példák igazolják a kockázatot, és hogyan épül fel egy NIS2-kompatibilis firmware patch menedzsment folyamat Dell PowerEdge és HPE ProLiant környezetben.

A sorozat korábbi részeiben az EOL/EOS szerverek auditakadályait, illetve az iDRAC/iLO menedzsment interfész lezárásának lépéseit jártuk végig. A firmware patch menedzsment mindkét területhez szorosan kapcsolódik: egy EOL eszközre a gyártó már nem ad ki biztonsági javítást, egy gondosan lezárt iDRAC interfész pedig csak addig nyújt valódi védelmet, amíg maga az iDRAC firmware naprakész.

Mit vár el tőled a NIS2 a firmware-frissítések terén?

A NIS2 irányelv 21. cikke kötelezővé teszi a sérülékenységkezelést mint szervezeti biztonsági intézkedést. A hazai implementáció – a 2024. évi LXIX. törvény és a 418/2024. (XII. 23.) kormányrendelet – ezt a kötelezettséget konkrét auditorelvárásokra bontja le: a szervezetnek dokumentált folyamattal kell rendelkeznie arra, hogyan azonosítja, priorizálja és zárja le az IT rendszereiben felfedezett sérülékenységeket.

A firmware-frissítések itt különleges helyet foglalnak el. Az operációs rendszer szintű patch menedzsmentet sok helyen valamilyen szinten kezelik – WSUS, Ansible, manuális ütemterv. A szerver BIOS-a, iDRAC-je, PERC RAID vezérlője és hálózati kártyájának firmware-je ezzel szemben az esetek túlnyomó részében dokumentálatlan és évek óta érintetlen. Az SZTFH és az MKIK közös kezdeményezésére a kiberbiztonsági audit határideje 2026. június 30-ra tolódott – ez az egyetlen halasztás, amelyre számíthattok. A 4000–7500 érintett magyarországi szervezet nagy részénél a firmware patch menedzsment a legkönnyebben azonosítható – és a legritkábban kezelt – hiányosságok egyike.

Egy elmaradt frissítés, 369 nap észrevétlenül

A kockázat mértékét valós incidensek mutatják meg legjobban. A CISA, az NSA és a Kanadai Kiberbiztonsági Központ közös elemzése szerint kínai állami hátterű támadók a BRICKSTORM nevű kártékony szoftverrel fertőztek meg VMware vCenter és ESXi szervereket, és átlagosan 369 napig maradtak észrevétlenek az áldozatok hálózatán. Az egyik vizsgált esetben a fertőzés másfél évig volt aktív, miközben az IT-csapat semmilyen rendellenességet nem érzékelt.

A BRICKSTORM belépési pontja minden esetben egy patcheletlen, internet-felé néző szerver volt. A malware virtualizációs környezet-tudatos módon települt, VSOCK-interfészen kommunikált, és a hagyományos hálózati monitoring eszközök nem észlelték. A javítás elérhető volt – egyszerűen nem alkalmazták.

A 2021-es HAFNIUM Exchange-incidens ugyanezt a mintát mutatja. A Microsoft által dokumentált négy CVE-t – CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065 – kínai állami hátterű szereplők exploitálták azoknál a szervezeteknél, ahol a biztonsági frissítés napokig vagy hetekig maradt alkalmazatlanul a közzététel után. A CISA a VMware vCenter sérülékenységeket is felvette az aktívan kihasznált sérülékenységek katalógusába – jelezve, hogy a virtualizációs réteg firmware- és szoftverfrissítési hiányosságai kiemelten célzott belépési ponttá váltak.

Az IBM X-Force 2026-os fenyegetéselemzése számszerűsíti a trendet: a sérülékenység-exploitálás az incidensek vezető okává vált, az összes vizsgált eset 40%-ában ez volt a belépési pont. A nyilvánosan elérhető alkalmazások elleni támadások 44%-kal nőttek, nagyrészt AI-alapú sérülékenység-felderítő eszközök és patcheletlen firmware kombinációja miatt.

Amikor a patch ciklus maga a probléma

Nem minden firmware-sérülékenység az adminisztrátor mulasztásán múlik. A Cisco Catalyst 9300 sorozatú switchek négy sérülékenységét – köztük a CVE-2026-20114 és CVE-2026-20110 láncolatát – a kutató 2025 júliusában jelezte a gyártónak. A Cisco csak 2026 márciusában, a következő féléves patch ablakban javította. Ez nyolc hónap nyitott sérülékenységet jelent – a láncolat privilege escalation útján teljes denial-of-service állapotot tesz lehetővé.

Ugyanebben az időszakban a Cisco SD-WAN Manager három kritikus javítást kapott, köztük egy CVSS 9.8-as besorolásút (CVE-2026-20122, CVE-2026-20126, CVE-2026-20128), amelyek root szintű jogosultság-kiterjesztést tesznek lehetővé, workaround nélkül. A Cisco Talos 2025-ös éves elemzése ezzel összefüggésben állapítja meg, hogy a top célpontok közel 40%-a EOL eszköz volt, amelyre patch már nem érkezett – és hogy az új sérülékenységek fegyveresítése szinte azonnal, a közzététel után megtörténik. A React2Shell CVE-t (CVE-2025-55182) decemberben publikálták, és az egész 2025-ös év legtöbbet célzott sérülékenységévé vált, mert az automatizált exploitáló eszközök szinte azonnal megjelentek.

Mindez azt jelenti, hogy a firmware patch menedzsment önmagában reaktív szemlélettel már nem elegendő: egy NIS2-kompatibilis folyamathoz proaktív CVE-figyelési és priorizálási rendszer is szükséges.

Dell PowerEdge firmware: mit kell frissíteni és milyen sorrendben?

Dell PowerEdge szerverek esetén a firmware stack több rétegből áll, és a frissítési sorrend nem tetszőleges. Ha rossz sorrendben hajtod végre, az iDRAC és a BIOS közötti kommunikáció meghiúsulhat, vagy a frissítési folyamat félbe marad.

1. iDRAC firmware – ez kezeli az összes többi komponens frissítési folyamatát, ezért mindig ezt frissítsd először. Letölthető a Dell Support oldaláról Express Service Code alapján, szervizszerződéstől függetlenül.

2. BIOS – az iDRAC frissítése után következik. A BIOS-frissítés Dell Update Package (DUP) formátumból élő rendszeren is elvégezhető, de tervezett újraindítást igényel. Kritikus szervereknél ezt karbantartási ablakban tervezd.

3. PERC RAID vezérlő firmware – különösen fontos terület, mert elavult PERC firmware ismert kompatibilitási hibákat és adatvesztési kockázatokat hordoz. A PERC 9 (13–14. generáció), PERC 10 (14–15. generáció) és PERC 11 (16. generáció) mindegyike önálló frissítési útvonallal rendelkezik; generációk között a frissítési csomag nem felcserélhető.

4. Hálózati kártyák (NIC) és HBA – a leggyakrabban kihagyott elem. A NIC firmware-sérülékenységek közvetlen hálózati szintű exploitálást tesznek lehetővé; a sorozat első cikkében részletezett hálózati szegmentáció csak akkor nyújt valódi védelmet, ha a NIC firmware maga sem sérülékeny.

Dell OpenManage Enterprise vagy iDRAC REST API segítségével a teljes firmware verzió térképe automatikusan lekérdezhető és exportálható. Ez az audit során felhasználható leltár alapja. HPE ProLiant esetén az iLO RESTful API és az SPP (Service Pack for ProLiant) biztosít hasonló, automatizálható frissítési útvonalat.

A patch menedzsment folyamata NIS2-kompatibilis módon

Egy auditálható firmware patch menedzsment folyamat öt elemből áll:

Leltár és verziótérkép – minden szerver esetén rögzíteni kell az iDRAC, BIOS, PERC és NIC firmware aktuális verzióját. Ez az alap; nélküle priorizálás nem végezhető, és az auditor előtt sem igazolható, hogy tisztában vagytok az infrastruktúra állapotával.

CVE-figyelés és priorizálás – a Dell Security Advisories és az NKI riasztások legalább havi rendszerességű ellenőrzése szükséges. Kritikus besorolású (CVSS ≥ 9.0) sérülékenységek esetén a javítási határidő auditorelvárás szerint 24–72 óra, nem hetek. Az NKI 2026 márciusában Microsoft termékeket érintő riasztást adott ki – hasonló közlemények heti szinten jelennek meg, és a szerverinfrastruktúrát érintők közvetlen cselekvést igényelnek.

Tesztelés és staging – ha van dedikált teszt szerver, az első alkalmazás mindig ott történjen. Ha nincs, a frissítést karbantartási ablakon belül, visszaállítási tervvel kell végrehajtani. A BIOS- és PERC-frissítések esetén a sikertelen frissítés szerver-leállást okozhat; az előkészítés elhagyása érdemi kockázatot jelent.

Dokumentált deployment – minden frissítési művelet rögzítendő: dátum, érintett eszköz azonosítója, korábbi és új firmware verzió, végrehajtó személy neve. Ez a négy adat az, amelyet az auditor bekér.

Ellenőrzés és auditnapló – a frissítés után az iDRAC System Event Log-ból exportálható a változásnapló, amely az audit során felhasználható bizonyítékként. HPE ProLiant esetén az iLO Integrated Management Log tölti be ugyanezt a szerepet.

Amit az auditor tényleg megnéz

Az SZTFH kiberbiztonsági audit során a firmware patch menedzsment területen jellemzően az alábbi kérdések merülnek fel: van-e dokumentált eszközleltár firmware verziókkal? Hogyan értesültök a sérülékenységekről, és mekkora a javítási átfutási idő? Mikor volt az utolsó firmware-frissítési ciklus, és mi volt a legrégebben frissítetlen eszköz?

Ha ezekre nincs dokumentált válasz – csupán a rendszergazda emlékezete –, az megfeleltethető a NIS2 21. cikke szerinti sérülékenységkezelési hiányosságnak. A sorozat első cikkében részletesen tárgyaltuk, hogy az auditor a papíralapú megfelelés helyett a tényleges kontrollokat keresi: firmware frissítések esetén ez konkrétan verziószámokat, dátumokat és felelőst jelent.

Az iDRAC/iLO menedzsment interfész lezárása csak akkor jelent teljes értékű kontrollintézkedést, ha maga az iDRAC firmware is naprakész. Egy patcheletlen iDRAC ismert sérülékenységekkel fut – a legbiztonságosabban konfigurált dedikált menedzsment VLAN sem kompenzálja a firmware szintű exploitálhatóságot.

Összefoglalás és következő lépések

A firmware patch menedzsment a NIS2-megfelelés egyik legjobban dokumentálható területe – ha van folyamat. Ha nincs, az audit szempontjából ez az egyik legkönnyebben azonosítható hiányosság: a verziószámok ellenőrizhetők, a frissítési előzmények vagy azok hiánya lekérdezhető.

Az audit előtt elvégzendő minimális lépések: firmware verzióleltár minden szerverre, dokumentált CVE-figyelési folyamat a Dell Security Advisories és az NKI riasztások alapján, az elmúlt 12 hónap frissítési naplója, és egy írott patch menedzsment policy, amely meghatározza a javítási határidőket súlyosság szerint.

Mi jön a sorozat következő részében?

Az eddig tárgyalt területek – EOL eszközök, iDRAC/iLO konfiguráció, firmware patch menedzsment – mind a szoftver és konfiguráció oldalát fedik le. De a NIS2 az üzletmenet-folytonosságot is konkrétan elvárja: dokumentált bizonyítéka kell annak, hogy egyetlen meghibásodás nem okoz leállást. A sorozat ötödik részében a fizikai redundancia – dual PSU, RAID, UPS – auditkövetelményeit és a Dell PowerEdge-specifikus megvalósítást mutatjuk be.
→ 05. rész: Fizikai redundancia és NIS2 – dual PSU, RAID és UPS

Ha bizonytalanok vagytok abban, hogy a meglévő szerverinfrastruktúra firmware szintje hol áll az audit előtt, a szerverdokk.hu csapata segít az értékelésben és a megfelelő frissítési útvonal meghatározásában.