Sérülékenységvizsgálat vagy penetrációs teszt: mi a különbség?

Két ajánlat fekszik az asztalon. Az egyiken sérülékenységvizsgálat szerepel, a másikon penetrációs teszt, a leírásuk az első három sorban szinte azonos, a két ár viszont köszönőviszonyban sincs egymással. A kérdés innen már magától adódik: ha az eszköz úgyis mindent megtalál, miért kell mellé ember?

A szkenner nem rossz eszköz, sőt: a maga feladatát kifogástalanul végzi. Csak nem arra a kérdésre válaszol, amelyet egy incidens után a vezetés fel fog tenni. Alább végigvesszük, meddig ér el az eszköz: mit talál meg biztosan, mit nem talál meg soha, honnan jönnek a téves találatok, hogyan kell olvasni a CVSS-pontszámot, és melyiket mikor érdemes megrendelni. A magyar jogi szóhasználatot külön is kibontjuk, mert az a kettőt fordítva rakja egymásba, mint a piac – és ennek gyakorlati következménye van, amikor valaki egy pályázati kiírást olvas vagy auditra készül.

Mi a különbség a sérülékenységvizsgálat és a penetrációs teszt között?

A rövid válasz egy mondat. A sérülékenységvizsgálat azt keresi, hol van hiba; a penetrációs teszt azt, hogy a megtalált hibákból mi használható ki, és a támadó meddig jut el velük. Az egyik szélességben dolgozik, a másik mélységben.

A hosszabb válaszhoz négy szolgáltatást érdemes szétválasztani, mert a magyar ajánlatokban zavarba ejtően hasonló néven futnak egymás mellett.

Négy szolgáltatás, amelyet a piac egy polcra tesz

A négy tétel kiegészíti egymást, nem helyettesíti. Az audit a folyamatokat és a dokumentumokat nézi, a felderítés a verziókat, a teszt a következményt. Akinek csak auditja van, annál a papír rendben van, a rendszerekhez viszont senki nem nyúlt hozzá. Akinek csak szkennelése van, az hosszú listát kapott, sorrend nélkül. Aki pedig évente egyszer tesztel és közben semmit nem csinál, az a maradék tizenegy hónapban publikált hibákat nem látja.

A megkülönböztetésnek kereskedelmi oldala is van. Egyes árlistákon a „biztonsági audit” a gyakorlatban szkennelés, a szolgáltató logójával a címlapon. Három kérdés dönti el, mit vesz valójában: mekkora benne a kézi munka aránya, ellenőrzi-e valaki az eszköz találatait, és benne van-e az árban az újratesztelés a javítások után. Ha az ajánlat egyikre sem válaszol, akkor szkennelést ír le. Azt, hogy egy teljes IT-biztonsági audit mit takar, külön oldalon vezettük végig.

Miért módszer a behatolásvizsgálat a magyar jogban?

A piac úgy beszél a kettőről, mintha két külön termék volna: az egyik oldalon az olcsó, gépi szkennelés, a másikon a drága, kézi teszt. A magyar jogszabály nem így viszonyítja őket egymáshoz, és ezt érdemes tudni, mielőtt valaki egy kiírásban vagy egy anyavállalati elvárásban találkozik a szavakkal.

A Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény (a továbbiakban: Kiberbiztonsági tv.) 4. § 11. pontja a behatolásvizsgálatot olyan sérülékenységvizsgálati módszerként határozza meg, amely a rendszer „gyenge pontjainak feltárására és kihasználhatóságának ellenőrzésére” irányul, rosszindulatú támadások szimulációjával. A behatolásvizsgálat tehát jogilag nem a sérülékenységvizsgálat ellentéte, hanem az egyik módszere.

A tágabb fogalom meghatározása ugyanott olvasható. A sérülékenységvizsgálat a 4. § 89. pontja szerint olyan „sérülékenységmenedzsment eszköz vagy módszer”, amelynél „az ellenőrzést automatizált eszközökkel és közvetlen, szakértő által végzett vizsgálatokkal hajtják végre”. A jogalkotó mindkettőt beleérti: a gépet is, az embert is. Amit a piac két külön tételként árul, azt a törvény egyetlen fogalom két rétegének tekinti.

Ennek három gyakorlati következménye van:

• A címke nem mondja meg, mit kap. Ha egy kiírásban vagy egy szerződéses elvárásban sérülékenységvizsgálat szerepel, abból még nem derül ki, kérnek-e mellé kézi munkát. A hatókört kell elolvasni, nem a szolgáltatás nevét.
• A pusztán gépi munkának külön neve van. A 418/2024. (XII. 23.) Korm. rendelet 51. § (1) bekezdése „automatizált sérülékenységfelderítés és -elemzés” néven nevezi. Amelyik ajánlat sérülékenységvizsgálatot ígér, de a leírásában egyetlen szó sem esik kézi ellenőrzésről, az ennél a szűkebb fogalomnál marad.
• A „sérülékenységkeresés” nem jogszabályi fogalom. A piaci összefoglalókban felbukkan, a törvény és a végrehajtási rendeletek viszont nem használják. Aki jogszabályi hivatkozás mellé írja, olyan kategóriát nevez meg, amelyik a jogban nem létezik.

A szóhasználatnak van még egy rétege. A Kiberbiztonsági tv. 57. §-a szerinti sérülékenységvizsgálat szabályozott eljárás: azt az NBSZ, a honvédelmi kiberbiztonsági incidenskezelő központ, illetve telephely biztonsági tanúsítvánnyal rendelkező, az SZTFH nyilvántartásában szereplő gazdálkodó szervezet folytathatja le. Ez a rend az 1. § (1) bekezdés a)–c) és f) pontja szerinti szervezetekre terjed ki (1. § (9)), a d)–e) pont alá tartozó cégek kereskedelmi megrendelését pedig a 60. § (1) bekezdése kiveszi alóla. Kereskedelmi sérülékenységvizsgálatot és penetrációs tesztet tehát a magánszektor szabadon rendel – ezt a munkát végezzük mi is. A kérdést külön cikkben bontottuk ki, mert a piacon ez a leggyakoribb félreértés.

Hogyan működik a szkenner?

A menet minden eszközben – Nessus, OpenVAS, Nuclei és a többi – lényegében ugyanaz:

1. Felderítés. Mely hosztok válaszolnak, mely portok nyitottak, milyen szolgáltatás áll mögöttük.
2. Szolgáltatásazonosítás. Melyik porton milyen szoftver, milyen verzióban fut. Minden további lépés ezen áll, és rendszerint ez téved elsőként.
3. Összevetés. Az eszköz összeveti a felismert verziót az ismert, CVE-azonosítóval ellátott sérülékenységek adatbázisával.
4. Pontozás. Minden találat súlyossági szintet kap, jellemzően a CVE-bejegyzésből átvett CVSS-alappontszámot.

Az egész a harmadik lépésen áll vagy bukik. A találatok többségében a hiba a verziószám alapján feltételezett, nem igazolt. Az eszköz lát egy „nginx 1.18.0” bannert, talál hozzá egy illeszkedő CVE-bejegyzést, és jelez. Azt viszont már nem nézi meg, hogy az adott beállításban a sérülékeny kódút egyáltalán elérhető-e.

Mit talál meg biztosan a szkenner?

A korlát ellenére az eszköz a maga terepén verhetetlen, és ez a terep egyáltalán nem szűk:

• Folytonosság. Naponta jelennek meg új CVE-bejegyzések. Egy pénteken tiszta rendszernek hétfőn kritikus sérülékenysége lehet anélkül, hogy bárki hozzányúlt volna. Ezt csak rendszeres felderítés veszi észre.
• Lefedettség. Több száz hoszt néhány óra alatt. Kézzel ezt senki nem járja végig, a próbálkozás pedig kihagyott rendszerekkel végződik.
• Ismételhetőség. A futtatás olcsó, tehát hetente is elindítható, nem csak évente egyszer.
• Sérülékenységmenedzsment. Az előző futtatással összevetve látszik a különbség: mi jött be, mi tűnt el, mi lóg javítatlanul egy negyedéve. Enélkül semmilyen javítási folyamatot nem lehet vezetni.
• Közös nyelv. A CVE-azonosító és a CVSS-pontszám alapján a szoftverszállítóval, a saját csapattal és az auditorral ugyanarról a dologról lehet beszélni.

Biztosan előkerülnek az elavult komponensek ismert CVE-bejegyzéssel, az egyértelműen felismerhető beállítási hibák – nyitva hagyott adminfelület, alapértelmezett jelszó, könyvtárlistázás, bekapcsolt hibakeresési mód –, a gyenge TLS-beállítás és a lejárt tanúsítvány, a hiányzó biztonsági fejlécek, valamint az előző futtatáshoz képesti eltérések.

Ezt a munkát nem embernek találták ki: sok van belőle, egyforma, és kézzel hibázni lehet benne. Ezért kezdődik a mi sérülékenységvizsgálatunk is automatizált felderítéssel. Csak nem ott ér véget.

Mit nem talál meg soha a szkenner?

Az alábbi hibaosztályok nem nehezek az eszköznek. Szerkezetileg elérhetetlenek a számára, mert nem tudja, mi számít az adott alkalmazásban megengedettnek:

• Hibás jogosultságkezelés. Az A felhasználó látja a B felhasználó rendeléseit. A szkennernek ez szabályos, 200-as válasz. Fogalma sincs róla, kihez tartozna a rekord.
• Üzleti logikai hibák. Többször beváltható kedvezménykód. Átugorható kosárlépés. Negatív összeg, amelyet a rendszer jóváírásként könyvel az ügyfél számláján.
• Hibaláncok. Egy ártalmatlan információszivárgás, egy gyenge jelszó-visszaállítási folyamat és egy elfelejtett tesztfiók: együtt az adminfiók átvétele. A szkenner három apróságot jelez alacsony prioritással, a jelentés három különböző pontján, és nem látja köztük az összefüggést.
• A többtényezős hitelesítés megkerülése. Például egy olyan API-n keresztül, amelyik a második tényezőt nem kéri.
• Túl bőbeszédű válaszok. Egy végpont több mezőt ad vissza, mint amennyit a felület megjelenít. Technikailag minden szabályosan működik, a gyakorlatban személyes adat szivárog.

Ezeket a hibaosztályokat az OWASP módszertana írja le, és egyiket sem hozza elő verziószámok összevetése. Az ilyen sebezhetőség megtalálásához valakinek végig kell gondolnia, mit szabad az alkalmazásban és mit nem.

Honnan jönnek a téves találatok?

A gyakorlatban a leggyakoribb eset a visszaportolt javítás. A Debian, a Red Hat és a többi disztribúció beépíti a biztonsági javítást a saját csomagverziójába anélkül, hogy közben a szolgáltatás verziószáma változna. A rés zárva van, a szkenner mégis jelzi, mert csak a számot ismeri.

Ezen felül téves találatot ad:

• Az elérhetetlen kód. A sérülékeny függvény ott van a könyvtárban, csak az alkalmazás soha nem hívja meg.
• A kompenzáló kontroll. Alkalmazásszintű tűzfal, hálózati szegmentálás vagy a szolgáltatás elé tett hitelesítés miatt a támadási út a gyakorlatban nem járható.
• A téves azonosítás. Egy fordított proxy vagy egy szándékosan átírt banner miatt az eszköz egészen más szoftvert azonosít, mint ami valóban fut.

Ezért néz ki mindig ugyanúgy az a szakasz, amelyik az eszköz kimenetéből vizsgálati jelentést csinál: minden komoly találatot kézzel ellenőrzünk, a többit zajként jelöljük meg, és leírjuk, miért. E lépés nélkül a lista hetekre leköti a csapatot lényegtelen ügyekkel, és közben megtanítja rá, hogy a biztonsági jelentéseket nyugodtan félre lehet tenni. Ez kerül a legtöbbe.

Hogyan kell olvasni a CVSS-pontszámot?

A CVSS-pontszámot ösztönösen kockázati szintként olvassuk. Nem az. Magát a sérülékenységet írja le, szabványos feltételezésekkel, a környezet ismerete nélkül.

A 9,8 pontos alapértékelés ennyit jelent: a hiba hálózaton át, hitelesítés nélkül kihasználható, és a bizalmasságot, a sértetlenséget és a rendelkezésre állást is teljesen érinti – feltéve, hogy a rendszer annyira elérhető, amennyire az értékelés feltételezi. Négy kérdés fordítja le a számot tényleges sorrenddé:

A gyakorlatban egy 6,5 pontos hiba az ügyfélportálon szinte mindig sürgetőbb, mint egy 9,8 pontos a lezárt tesztrendszeren. Ennek a sorrendnek a felállítása maga a kockázati besorolás, és ez rendezi sorba a következő negyedév javítási feladatait.

A nyitott port és a valódi bejutás

A szkennelés ténymegállapítással zárul: a port nyitva van, a szolgáltatás verziója elavult, a pontszám 8,1, mellette a CVE-azonosító. A penetrációs teszt pontosan itt kezdődik, és azt kérdezi, mi van a port mögött.

Egy ilyen lánc a gyakorlatban így néz ki: elfelejtett adminfelület az interneten, benne egy fiók a bevezetési dokumentációból származó jelszóval, a felületről kiolvasható konfigurációban egy szolgáltatásfiók hitelesítő adata, azzal a fiókkal elérhető a mentéseket tároló hálózati megosztás, a mentésekben pedig a kiemelt jogosultságú fiókok jelszólenyomatai. Négy apróság egymás után, a végén a tartomány átvétele.

A szkenner itt három közepes prioritású találatot jelezne, a jelentés három különböző fejezetében, és egyik sem hangzana sürgősnek. A tesztelő egyetlen megállapítást ír le: a tartomány átvehető – lépésekkel, bizonyítékkal, és azzal, melyik láncszemet a legolcsóbb elvágni. A különbség egyetlen mondatba fér: a szkennelés azt bizonyítja, hogy nyitva a port, a teszt pedig azt, hogy meddig jut el rajta a támadó.

Innen ered az árkülönbség is: a szkennelés egyszerűbb kérdésre válaszol, és gép csinálja. Hogy magának a tesztnek az árát mi mozgatja, azt külön cikkben szedtük össze; a fogalmakat és a munka menetét pedig a Mi az a penetrációs teszt? című cikk vezeti végig.

Melyiket mikor érdemes megrendelni?

Mit vár el mindebből a magyar szabályozás?

A védelmi intézkedések katalógusát a 7/2024. (VI. 24.) MK rendelet 2. melléklete tartalmazza, biztonsági osztályonként. A tesztelést érintő sorok így néznek ki:

A sorrend beszédes. A sérülékenységek ellenőrzése mindhárom biztonsági osztályban kötelező, a sérülékenységmenedzsment a jelentős osztálytól felfelé. Önálló behatolásvizsgálatot viszont egyik osztály sem ír elő kötelezően; kötelező elemi követelményként egyedül a független szakértő vagy csapat bevonása jelenik meg, és csak a magas osztályban. Vagyis a rendszeres felderítés és a nyomon követett javítás a jogszabályi alapelvárás, a behatolásvizsgálat pedig fölé épül. Aki azt olvassa valahol, hogy a magyar szabályozás minden érintett szervezettől éves penetrációs tesztet vár el, rossz forrásból dolgozik; a kérdést cellánként végigvezettük.

A kétévente esedékes kiberbiztonsági auditon belül más a kép. A Kiberbiztonsági tv. 22. § (1) bekezdés a) pontja szerint az auditor jogosult „belső informatikai biztonsági és távoli sérülékenységvizsgálatot, valamint »jelentős« vagy »magas« biztonsági osztály esetén behatolásvizsgálatot” elvégezni. Két szó számít itt sokat. Az egyik a jogosult: a törvény felhatalmazza az auditort, nem kötelezi. A másik a belső – a széles körben másolt kamarai összefoglaló ezt a szót külsőre cseréli, és a hiba onnan terjedt tovább. Ugyanezt erősíti meg az 1/2025. (I. 31.) SZTFH rendelet 2. § (2) bekezdése is, amely szerint ezek a módszerek alkalmazhatóak.

A pénzügyi szektorban a felügyeleti elvárás konkrétabb. Az MNB 1/2025. (I. 13.) ajánlásának 13.1.4 e)–f) pontja a belső és az elkülönített zónákra évente, a kártyás rendszerekre, a webes ügyfélfelületekre és a mobilalkalmazásokra negyedévente vár el sérülékenységvizsgálatot; az internet felől elérhető alkalmazásoknál penetrációs tesztet a javítások után, az éles indulás előtt, minden biztonsági szempontból lényeges változáskor, azon felül pedig legalább évente. Ez ajánlás és felügyeleti elvárás, nem jogszabály – a gyakoriságokat külön cikkben vettük végig.

Adatvédelmi oldalról az általános adatvédelmi rendelet 32. cikk (1) bekezdés d) pontja „a technikai és szervezési intézkedések hatékonyságának rendszeres tesztelésére, felmérésére és értékelésére szolgáló eljárást” írja elő. Penetrációs tesztet nevesítve nem követel meg; a hatékonyság mérésére a gyakorlatban ez az egyik használt eszköz.

Hogyan álljon össze mindez egy programmá?

Egy közepes méretű szervezetnél az alábbi négy elem működik együtt:

1. Derítsen fel folyamatosan. Az internet felől elérhető rendszereket hetente, a belső hálózatot havonta, ezen felül minden lényeges változás után.
2. Ellenőriztesse negyedévente. Valaki végigmegy a komoly találatokon, kiszűri a téves találatokat, és tényleges kockázat szerint rendezi sorba a listát. Ez a sérülékenységvizsgálat, nem az eszköz kinyomtatott kimenete.
3. Teszteltessen évente és nagy változás után. A penetrációs teszt azokat a hibaosztályokat fedi le, amelyeket egyetlen eszköz sem talál meg, és azt a bizonyítékot állítja elő, amelyet az auditor keres.
4. Nézesse meg a javításokat. Újratesztelés nélkül dokumentált problémája van, nem dokumentált megoldása.

A felderítés és a teszt nem ugyanazért a keretért versenyez, mert másra ügyel. Az egyik arra, hogy két teszt között ne romoljon el csendben semmi. A másik arra, hogy az eszköz listája ne legyen minden, amit a cég a saját rendszereiről tud. Aki csak az egyiket rendeli meg, a válasz felét fizeti ki.

Sérülékenységvizsgálat és penetrációs teszt – gyakori kérdések

Kapcsolódó Haxoris-szolgáltatások: rendszerek és alkalmazások sérülékenységvizsgálata · webalkalmazások és infrastruktúra penetrációs tesztelése