Gyorsabb kibertámadások az AI korában: hol rövidíthető a javítás és a reagálás ideje?
Az Egyesült Királyság nemzeti kiberbiztonsági központja, az NCSC 2026. november 3-án tette közzé tizedik éves jelentését, amely a 2025 szeptembere és 2026 augusztusa közötti időszakot tekinti át. A jelentés egyik központi megállapítása, hogy a mesterséges intelligencia valószínűleg nem a támadók céljait változtatja meg, hanem azt, hogy milyen gyorsan, milyen léptékben és milyen hatékonysággal érik el őket. NCSC – az AI hatása a kiberfenyegetésre
Richard Horne, az NCSC vezetője az előszóban úgy fogalmaz, hogy az AI nem létrehozta a gyengeségeket, hanem láthatóvá tette őket: az évek alatt felhalmozott technikai adósságot és az alapvető védelmek hiányát. NCSC – Richard Horne előszava A mérnöki kérdés ebből egyszerű: ha a támadó gyorsabban jut el a hibáig, hol rövidíthető a mi oldalunkon a javítás és a reagálás ideje?
Mit mond pontosan az NCSC?
Az NCSC az értékeléseiben fokozatos valószínűségi kifejezéseket használ (például „szinte biztos”, „nagyon valószínű”), ezért érdemes pontosan idézni őket. A jelentés szerint szinte biztos, hogy az AI erőmegsokszorozóként hat a fenyegetési környezetben: gyorsítja a felderítést, a megtévesztő (social engineering) támadásokat, a sérülékenységek feltárását és az exploitfejlesztést. A legnagyobb hatást a meglévő módszerek felgyorsítása és felskálázása jelenti, nem új támadási utak megjelenése.
Nagyon valószínű, hogy az AI-támogatott sérülékenységfeltárás és exploitfejlesztés jelentős fenyegetést jelent, mert a támadók nagyobb eséllyel érhetnek el egy rendszert, mielőtt a tulajdonos telepíti a javítást. Az NCSC szerint a védekezők és a rendszerek karbantartói versenyfutásra kényszerülnek, hogy lerövidítsék a javítások telepítési idejét, még mielőtt a támadók működő exploitot fejlesztenének. Ugyanez a fejezet rögzíti, hogy a kiberbűnözők AI-használata nagyon valószínűleg növeli a zsarolóvírus-műveletek, a megtévesztő támadások és a sérülékenységkihasználás léptékét és hatékonyságát. NCSC – az AI hatása
Az időtávot a jelentés egy másik fejezete adja meg: nagyon valószínű, hogy 2028-ra Kína, Oroszország és más államok rutinszerűen használnak majd AI-t kiberműveleteikben, és hogy addig egy zsarolóvírus-támadásban AI-alapú kártevőt is bevetnek a brit kritikus infrastruktúra ellen. A jelentés egy kifejezetten pesszimista 2028-as forgatókönyvet is bemutat, de hangsúlyozza, hogy az nem előrejelzés, hanem a tétlenség következményeit szemlélteti. NCSC – a kiberfenyegetés az Egyesült Királyságban · NCSC – az autonóm támadások kora
Fontos ellensúly, hogy az NCSC szerint az emberi irányítás továbbra is nélkülözhetetlen. A támadók nagy valószínűséggel nem végponttól végpontig autonóm támadásokat hajtanak végre, hanem ember irányítja, ellenőrzi és igazítja az AI kimenetét.
A betörések többsége ma is ismert hibán át érkezik
Az NCSC eseménykezelő csapata az időszakban 1831 bejelentést kapott kibertámadásokról. Ezek közül 337 igényelt támogatást, és 80 minősült nemzeti jelentőségűnek. Az Early Warning szolgáltatáson keresztül emellett 8500 szervezetet értesítettek olyan eseményekről, amelyek feltételezett kompromittálódásra utaltak. NCSC – eseménykezelés
A jelentés szerint a sikeres támadások többsége ma is megszokott módszerekre épül: az internet felől elérhető rendszerek ismert sérülékenységeire, ellopott belépési adatokra és megtévesztésre. Az állami hátterű szereplők esetében is előfordult korábban ismeretlen hiba kihasználása, de sokszor olyan sérülékenységről volt szó, amelyre már létezett javítás, csak nem telepítették elég gyorsan. A csapat már látott AI-eszközöket a támadásokban, de ezek egyike sem tett lehetővé új támadási osztályt.
Ebből az következik, hogy a legtöbb szervezetnél nem egy ismeretlen, AI által kitalált támadás a fő kockázat, hanem az az idő, amely egy ismert hiba közzététele és a javítás telepítése között eltelik. Ha az AI ezt az ablakot a támadó oldalán szűkíti, a védekező oldalon is szűkíteni kell.
A javítás útja: hol vész el az idő?
Az NCSC műszaki igazgatója, Ollie Whitehouse 2026 májusában arra figyelmeztetett, hogy a szervezeteknek fel kell készülniük egy „javítási hullámra” (patch wave): az AI-támogatott hibafeltárás miatt minden súlyossági szinten sok frissítés várható, köztük kritikusak is. Ajánlásai sorrendet is adnak: NCSC – Preparing for a vulnerability patch wave
- Először a külső támadási felület. Az internet felől elérhető rendszerek az elsők, majd befelé haladva a felhős és a helyi környezet. Ha nincs kapacitás mindenre, a külső felület és a kritikus biztonsági rendszerek élveznek elsőbbséget.
- Automatikus javítás, ahol lehet. A szolgáltatáskiesés nélküli javítást (hot patching) és az automatikus frissítést – a beágyazott eszközökön is – be kell kapcsolni.
- Rangsorolás, ahol nem lehet. A folyamatoknak és a kockázatvállalásnak gyakori, nagy léptékű frissítést kell lehetővé tenniük; a sorrendhez az SSVC (Stakeholder-Specific Vulnerability Categorization) döntési fa használható.
- Csere, ahol nincs javítás. A támogatás nélküli, életciklusa végén járó eszközt ki kell cserélni, vagy vissza kell hozni a támogatás körébe.
Az NCSC útmutatója arra is figyelmeztet, hogy a szervezetek sokszor azt sem tudják, futtatják-e az érintett szoftvert vagy eszközt. Az idő ezért gyakran már az érintettség megállapításánál elvész, jóval a telepítés előtt. NCSC – aktívan kihasznált sérülékenységek
- Közzététel
- Érintettség
- Rangsorolás
- Telepítés
- Ellenőrzés
Eszközleltár · automatikus frissítés · beszállítói kötelezettség az egész láncon
Hány nap a jó? Az NCSC határidői
Az NCSC sérülékenységkezelési útmutatója az „alapértelmezett frissítés” (update by default) elvét követi: minden frissítést a lehető leghamarabb, lehetőleg automatikusan kell telepíteni, súlyosságtól függetlenül. Kivétel lehet a biztonságkritikus rendszer és az üzemeltetési technológia (OT). A normál üzemi határidők mellett az útmutató rövidebb idősávot ad arra az esetre, ha egy hibát már aktívan kihasználnak. NCSC – frissítési határidők · NCSC – aktívan kihasznált sérülékenységek
| Rendszer vagy helyzet | Telepítés legkésőbb | Megjegyzés |
|---|---|---|
| Internet felől elérhető szolgáltatás és szoftver | 5 nap | Előbb tesztkörnyezet vagy mentés, majd (szükség szerint szakaszos) bevezetés. |
| Operációs rendszer és alkalmazások | 7 nap | Automatikus telepítés, szakaszos bevezetés (például napi 10 százalék), hiba esetén szüneteltetés vagy visszaállás. |
| Belső vagy hálózatról leválasztott rendszer | 14 nap | Előbb tesztkörnyezet vagy mentés, majd bevezetés. |
| Aktívan kihasznált hiba (CISA KEV), internetről elérhető, automatizálható, teljes átvételt enged | Azonnal, 24 órán belül | Minősített incidenskezelő szolgáltató (CIR) bevonásával. |
| Ugyanez, de a kihasználás nem automatizálható | 48 órán belül | Incidenskezelő szolgáltató bevonásával. |
| Ugyanez, de a rendszer nem érhető el az internetről | 72 órán belül | Incidenskezelő szolgáltató bevonásával. |
Hogy ezek a határidők nem elérhetetlenek, azt a jelentés egy kormányzati példával szemlélteti: a brit kormányzati kiberbiztonsági akcióterv keretében a domainekhez kapcsolódó sérülékenységek javításának medián ideje 50 napról 8 napra csökkent. NCSC – A moment of choice
A biztonságtechnikai rendszerekben ez külön figyelmet kíván. Egy rögzítő, kamera vagy beléptető vezérlő gyakran beágyazott eszköz, ahol az automatikus frissítés nem mindig elérhető, a firmware-frissítés pedig próbát és karbantartási ablakot igényel. Az NCSC szerint ahol a frissítés kockázata túl nagy, a rendszert kivétellistára kell venni, a frissítés elmaradásának kockázatát pedig a szervezetnek kell vállalnia. A kamera is számítógép – csak éppen egy oszlop tetején című írásomban egy NVR-sérülékenységi figyelmeztetésen keresztül mutattam be, miért kell a telepített leltárt a közlemény pontos modell- és firmware-hatókörével összevetni.
Amikor a javítás már késő: a reagálás ideje
Ha egy kritikus hiba kihasználása automatizálttá válik, az NCSC szerint minden óra számít, amely frissítés nélkül telik el. Az útmutató ezért gyors reagálási útvonalat javasol, amelyet a meglévő informatikai incidenskezelésbe kell illeszteni. A biztonsági csapat és az informatikai üzemeltetés előre állapodjon meg abban, hogy egy aktívan kihasznált hiba javítása ugyanolyan prioritást kap, mint egy teljes rendszerkompromittálódás (P1). A gyors javítás kötelezettségét a beszállítói szerződésekben is rögzíteni kell. NCSC – aktívan kihasznált sérülékenységek
A rendszeres sérülékenységvizsgálat mellett nem szokványos adatforrásokat is érdemes bevonni, például a levelezési szűrőben a gyártótól érkező levelek keresését, vagy a peremhálózati proxynaplóban a gyártó oldalára irányuló kapcsolatokat. Az árnyék-informatikát (shadow IT), a fejlesztői környezeteket és a beszállítók gépeit is ellenőrizni kell.
Ha kompromittálódás gyanúja merül fel, az NCSC általános elsődleges lépései: a kompromittálódás mértékének felmérése, az érintett rendszer lehetőség szerinti leválasztása és naprakész új rendszerrel való kiváltása – akár szolgáltatáskiesés árán is –, majd a nyomok teljes kivizsgálása, lehetőleg minősített incidenskezelő szolgáltató bevonásával. NCSC – teendők aktív kihasználásnál
A jelentés szerint a védekezés is gépi támogatást kap. Az AI-ügynökök a jövőben segíthetnek a tevékenységek kivizsgálásában és a bizonyítékok összefésülésében, egyes esetekben visszafordítható beavatkozást is végezhetnek. Ezt azonban begyakorolt forgatókönyvekkel, megbízható telemetriával és egyértelmű, korlátok közé szorított beavatkozási jogkörrel együtt kell bevezetni. NCSC – az operatív kibervédelem változása
Az uniós és a magyar keret
Az unióban a sérülékenységkezelés jogi követelmény is. A NIS2-irányelv – (EU) 2022/2555 – 21. cikk (2) bekezdés e) pontja a kockázatkezelési intézkedések között kifejezetten nevesíti a hálózati és információs rendszerek beszerzésének, fejlesztésének és karbantartásának biztonságát, beleértve a sérülékenységek kezelését és közzétételét. A 23. cikk (4) bekezdése szerint jelentős incidensnél indokolatlan késedelem nélkül, de legkésőbb 24 órán belül korai figyelmeztetést, 72 órán belül incidensbejelentést, majd a bejelentést követő egy hónapon belül zárójelentést kell küldeni. EUR-Lex – NIS2-irányelv
Magyarországon a Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvényt az Országgyűlés az uniós irányelvre is figyelemmel alkotta meg. A törvény 66. §-a a szervezetek körétől függően ad bejelentési szabályt: egyes szervezeteknek a fenyegetéseket, incidensközeli helyzeteket és incidenseket haladéktalanul, másoknak a súlyos zavart vagy jelentős kárt okozó eseményeket kell bejelenteniük a nemzeti kiberbiztonsági incidenskezelő központnak, mindkét esetben a kormányrendeletben meghatározottak szerint. 2024. évi LXIX. törvény – Nemzeti Jogszabálytár
A gyártói oldalon 2026. szeptember 11. óta az uniós kiberreziliencia-rendelet (Cyber Resilience Act, CRA) bejelentési kötelezettségei is alkalmazandók. A digitális elemeket tartalmazó termékek gyártóinak az aktívan kihasznált sérülékenységekről 24 órán belül korai figyelmeztetést, 72 órán belül teljes bejelentést, a javító intézkedés elérhetővé válását követő 14 napon belül pedig zárójelentést kell küldeniük. Európai Bizottság – CRA-bejelentések
NIS2 – jelentős incidens
- 24 óra Korai figyelmeztetés
- 72 óra Incidensbejelentés
- 1 hónap Zárójelentés a bejelentés után
CRA – aktívan kihasznált sérülékenység (gyártó)
- 24 óra Korai figyelmeztetés
- 72 óra Teljes bejelentés
- 14 nap Zárójelentés a javítás elérhetővé válása után
Értelmezésem szerint a három szabályozás ugyanarra az alapra épít: arra, hogy a szervezet órákon belül meg tudja mondani, érintett-e. Ehhez ugyanaz az eszközleltár és ugyanaz a döntési útvonal kell, mint a gyors javításhoz. Ez saját következtetésem, nem hatósági álláspont; hogy egy adott szervezetre mely kötelezettségek vonatkoznak, azt a jogszabályok hatálya alapján kell megállapítani.
Az AI a védekező oldalon is gyorsít
A jelentés nem csak a fenyegetésről szól. A DROMOS projekt keretében a brit kormányzat frontier AI-modellekkel vizsgált kormányzati kódbázisokat. Egy négyhetes pilot után a programot kiválasztott kormányzati környezetekre is kiterjesztették, ahol több száz potenciális biztonsági problémát tártak fel, köztük kritikus sérülékenységeket. A program a téves találatok kezelésére és az emberi felügyeletre külön irányítási és eljárási rendet alakított ki. NCSC – Project DROMOS
Hogy egy specializált modell hogyan támogathatja az engedélyezett sérülékenységkutatást, és miért kell minden találatot szakértőnek validálnia, arról a GPT-6 Cyber: gyorsabb hibafeltárás, nagyobb felelősség című írásomban részletesen foglalkoztam.
Az NCSC üzenete végső soron mérnöki: az AI-támogatott támadások elleni védekezés eszközei – a naprakész eszközleltár, az alapértelmezett frissítés, a gyors reagálási útvonal, a megfigyelés és a begyakorolt incidenskezelés – már léteznek, a feladat a gyors és széles körű bevezetésük. A kérdés az, hogy egy szervezet órák, napok vagy hetek alatt jut el a közzétett hibától a telepített javításig. Ezt az időt érdemes most megmérni, mielőtt egy javítási hullám mérné meg helyettünk.
Források: NCSC – The impact of AI on cyber threat · NCSC – The cyber threat to the UK · NCSC – The age of autonomous attack · NCSC – Incident management · NCSC – Foreword: Richard Horne · NCSC – A moment of choice · NCSC – The changing nature of operational cyber defence · NCSC – Project DROMOS · NCSC – Preparing for a vulnerability patch wave · NCSC – Policy to update by default · NCSC – Responding to active exploitation
Jogi források: NIS2-irányelv – (EU) 2022/2555 · 2024. évi LXIX. törvény · Európai Bizottság – CRA-bejelentések
Utoljára felülvizsgálva:
Kérdésed van, vagy átbeszélnéd valamelyik témát?
Legyen szó biztonsági rendszerről, a mögötte lévő informatikai hálózatról vagy egy gondolatról ezekből a cikkekből, szívesen meghallgatlak.
Kapcsolatfelvétel
