Generatív AI a kiberbiztonsági elemzők munkájában
Egy kiberbiztonsági elemző napja nagyrészt azzal telik, hogy adatot néz át: eseménynaplót, konfigurációt, sérülékenységi jelentést, kártevőelemzést. A Using Generative AI Models to Support Cybersecurity Analysts című kutatásunkban azt vizsgáltuk, mennyit vesz át ebből egy nagy nyelvi modell (LLM), és hol téved. Két konkrét feladaton mértük: Android-alkalmazások kódján és hálózati biztonsági naplókon. Arról, hogy az AI összességében hol erősíti a védekezést, külön cikkben írtunk: AI a kibervédelemben. Itt egyetlen kutatás eredménye következik.
Mire jó a generatív AI egy biztonsági csapatnak?
A hagyományos eszközök összegyűjtik és előfeldolgozzák az adatot, a döntés viszont az emberé marad: melyik riasztás mögött van valódi támadás, és melyik mekkora kockázat. Ez naponta órákat visz el.
A generatív AI ezen a ponton lép be:
- átnézi a biztonsági naplókat, és előbb jelzi az eltérést,
- gyorsabban megtalálja az alkalmazásokban a kihasználható hibákat,
- a penetrációs teszt során végigveszi, melyik hiba mire használható,
- az OWASP Mobile Top 10 lista és a MITRE ATT&CK keretrendszer szerint helyezi kontextusba a találatokat.
Két esettanulmány a kutatásunkból
Két olyan feladatot választottunk, amelyen egy biztonsági csapat amúgy is naponta dolgozik.
1. Sérülékenységek Android-alkalmazásokban
Építettünk egy rendszert, amely két ismert eszköz – a MobSF (Mobile Security Framework) és a Semgrep – kimenetét egy nagy nyelvi modellel kapcsolja össze. A statikus elemzés önmagában csak a mintát látja, a kód szándékát nem; ezért tettünk mellé kontextuselemzést:
- a forráskód átvizsgálása,
- a biztonsági hibák azonosítása előre megírt szabályok alapján,
- a találatok besorolása az OWASP Mobile Top 10 szerint.
💡 A legfontosabb eredmény: a modell gyorsabban és pontosabban találta meg a hibákat, de téves riasztásokat (angolul false positive) is adott, és azokat embernek kellett kiszűrnie.
2. Naplóelemzés az incidensek felderítéséhez
A második feladat hálózati biztonsági napló volt: a Suricata (IDS/IPS) és a Windows folyamatait figyelő Sysmon kimenete. Azt kértük a modelltől, hogy a riasztásokat kösse össze a valódi támadásokkal, a téves riasztásokat hagyja el, és minden incidenshez rendelje hozzá a MITRE ATT&CK megfelelő technikáját.
💡 A legfontosabb eredmény: sokkal hamarabb kiderült, mi a fenyegetés, és mekkora a súlya. Az erősen obfuszkált vagy több lépésből álló támadásoknál viszont a modell elakadt.
Korlátok és kockázatok
A kutatás sok lehetőséget mutatott, de a nagy nyelvi modellnek ára is van a biztonsági munkában:
- Téves riasztás. A modell félreolvashat egy naplósort vagy egy kódrészletet, és jelezhet olyan fenyegetést, amely nincs.
- Költség. Nagy adathalmazt nagy nyelvi modellel feldolgozni drága, és a számla a bemenet méretével nő.
- A megoldás saját biztonsága. Az AI-val végzett elemzés kérdéseket vet fel az adatok bizalmasságáról, és maguk a modellek is támadhatók.
Mit érdemes ellenőrizni, mielőtt egy ilyen modell éles rendszerbe kerül? Ezt az LLM-integrációk penetrációs tesztelése című cikkben szedtük össze.
Merre tart az AI a kiberbiztonságban?
A korlátok ellenére ez a terület gyorsan fejlődik. A feladatra hangolt (fine-tuned) modellek, a biztonsági célra épített saját modellek és a valós idejű adaptív tanulás átírhatja, hogyan vesszük észre, hogyan értjük meg és hogyan kezeljük a támadásokat.
Ha már fut AI az Ön rendszereiben, azt külön vizsgálati körben nézzük végig: így teszteljük az AI- és LLM-integrációkat.
Gyakori kérdések
Kiváltja-e a nagy nyelvi modell a biztonsági elemzőt?
Nem. A modell az adatfeldolgozást gyorsította fel: átnézte a naplókat és a forráskódot, és megjelölte, mi érdemel figyelmet. A döntés mindkét feladatnál emberi maradt, mert a modell téves riasztásokat is adott, és a bonyolultabb támadásoknál elakadt.
Miért ad a modell téves riasztást?
Mert a naplósort és a kódrészletet is szövegként olvassa, és mintázat alapján következtet. Ha a mintázat egy valódi támadáséra hasonlít, akkor is jelez, ha semmi nem történt. Ez a módszer ára: minden találatot ellenőrizni kell, és a folyamatot úgy érdemes felépíteni, hogy az ellenőrzés gyors legyen.
Milyen keretrendszerekre támaszkodott a kutatás?
Kettőre. Az Android-alkalmazásoknál az OWASP Mobile Top 10 lista adta a besorolás alapját, a naplóelemzésnél pedig a MITRE ATT&CK keretrendszer technikáihoz rendeltük hozzá az incidenseket.
Kell-e külön tesztelni azt a rendszert, amelyben AI fut?
Igen. Egy nagy nyelvi modellt körülvevő alkalmazás a szokásos webes és API-oldali hibák mellett saját támadási felületet is kap: prompt injection (a modell utasításainak eltérítése), az adatforrások megbízhatósága, a modell hozzáférési jogai és a kimenet további feldolgozása.
A teljes eredményt a szakcikkben írtuk meg:
Minél több AI kerül egy biztonsági csapat kezébe, annál többet számít a munkamegosztás: az adatot a gép rágja át, a döntést az ember hozza meg. A védelem gyorsasága és pontossága ezen múlik.
🔐 Éberség, naprakész tudás, AI csak ésszel – ebben a sorrendben.
