Melyik pentest illik a vállalkozásához? Behatolástesztelési stratégiák

A pentest, azaz penetrációs teszt (penetration test) egy engedélyezett, kontrollált keretek között végrehajtott, valós támadást szimuláló vizsgálat. Célja nem egy hibalista összeállítása, hanem annak bemutatása, hogy egy motivált támadó milyen üzleti kockázatot okozhat, és milyen útvonalon jutna el a legértékesebb adatokhoz vagy rendszerekhez. Jól jelzi az iparág súlyát, hogy a globális penetrációstesztelési piac 2024-ben 1,7 milliárd dollár volt, a becslések szerint 2029-re 3,9 milliárd dollárra nőhet, évi 17,1%-os ütemben. A behatolástesztelés többféle stratégiát követhet attól függően, hogy milyen célt szolgál.

Miről olvashat ebben a cikkben?

• Miért nem elegendő önmagában az automatizált sérülékenységvizsgálat, és mi a pentest hozzáadott értéke.

• Három gyakori megközelítés: megfelelés-vezérelt, PTaaS és fenyegetés-vezérelt (TLPT) tesztelés.

• Melyik megközelítés mikor, milyen üzleti helyzetben indokolt, és miért nem zárják ki egymást.

• Hogy néz ki egy kollaboratív, ügyfélre szabott tesztelési modell a gyakorlatban.

Miért nem elég már az automatizált sérülékenységvizsgálat?

Egy vulnerability scanner (automatizált sérülékenységvizsgálat) percek alatt végigfut több ezer ismert hibaminta ellenőrzésén, és rendezett listát ad a kezünkbe. Egyes scannerek biztonságos validációs próbákat is végeznek, de elsődleges céljuk az ismert sérülékenységek automatizált azonosítása, nem a valós kihasználhatóság vagy az üzleti kockázat felmérése.

A pentest ezzel szemben a megállapodott hatókör és tesztelési szabályok keretein belül azt is megvizsgálja, hogy egy hiba valóban kihasználható-e, és összekapcsolható-e más, önmagában jelentéktelen gyengeségekkel.

Az emberi közreműködés különösen az üzleti logikai hibák és a több lépésből felépülő támadási útvonalak feltárásában ad többet. Egy önmagában alacsony súlyosságú konfigurációs hiba egy másik, szintén kis kockázatúnak tűnő jogosultsági problémával összekapcsolva komoly hozzáférési problémát eredményezhet. Ezt egy automatizált eszköz gyakran nem képes megfelelően feltárni vagy üzleti kontextusba helyezni.

Motivációk a pentest mögött

A tapasztalatunk szerint egy vállalat pentestelési igénye majdnem mindig két forrásból ered. Az egyik a külső elvárás: egy audit, egy üzleti partner vagy egy jogszabály várja el a rendszeres tesztelést.

Ilyen lehet a NIS2 (Network and Information Security Directive 2, az EU kiberbiztonsági irányelve), amely előírja a kockázatkezelési intézkedések hatékonyságának rendszeres értékelését. Ennek egyik lehetséges eleme a penetrációs teszt, de a módszert és a gyakoriságot a szervezet kockázatai, valamint az alkalmazandó nemzeti és ágazati követelmények alapján kell meghatározni. Hasonló logika érvényes az ISO 27001-re vagy a SOC 2-re is.

A másik motiváció, amikor a cég valóban szeretné javítani és kezelni a biztonsági hiányosságokat. Ez gyakran egy megtörtént incidens tanulságaiból vagy egy vezetői döntésből fakad: inkább megelőzni, mint reagálni.

Ez a két motiváció vezet el a három gyakori tesztelési megközelítéshez.

Három gyakori pentest megközelítés különböző üzleti helyzetekre

Fontos tisztázni, hogy az alábbi három megközelítés nem azonos szintű és nem egymást kizáró kategória.

• A megfelelés-vezérelt pentest (Compliance-Driven Pentesting) elsősorban egy vizsgálat motivációját és célját jelöli.

• A folyamatos pentest szolgáltatás (Penetration Testing as a Service, PTaaS) egy szolgáltatási és együttműködési modell, amely a tesztelés lebonyolítási formájára vonatkozik.

• A fenyegetés-vezérelt pentest (Threat-Led Penetration Testing, TLPT) ezzel szemben egy fenyegetési információra épülő, szabályozott tesztelési módszertan.

A kategóriák átfedhetik egymást: egy PTaaS-modellben végzett vizsgálat lehet megfelelés-vezérelt, a DORA alapján végzett TLPT pedig egyszerre fenyegetés-vezérelt módszertan és szabályozási kötelezettség.

A három megközelítésről a Hatékony penetrációs tesztelés: az üzleti igényekhez illő megközelítés cikkünkben írtunk, most azonban szélesebb szempontrendszer alapján szeretnénk egymás mellé helyezni ezeket, így segítve a döntéshozók munkáját.

Megfelelés-vezérelt pentest (Compliance-Driven Pentesting)

Ez a leggyakoribb belépési pont a pentest világába: a motiváció jogszabályi vagy iparági elvárás, például a PCI DSS (Payment Card Industry Data Security Standard, a kártyaadatokat kezelő rendszerekre vonatkozó szabvány), az ISO 27001 vagy a SOC 2.

A vizsgálat egy adott keretrendszer hatókörén belül zajlik, célja pedig az, hogy az audit sikeresen záruljon, a bírság, a jogi kockázat és a reputációs kár elkerülhető legyen.

Az ISO/IEC 27001

A.8.8 kontrollja a technikai sérülékenységek kezelésére, az A.8.29 pedig a fejlesztés és átvétel során végzett biztonsági tesztelésre vonatkozik. A penetrációs teszt ezekhez megfelelő bizonyíték vagy kontroll lehet, de a szabvány nem ír elő általánosan éves gyakoriságot. Ezt a szervezet kockázatai, kontrolljai és szerződéses elvárásai határozzák meg.

Ez a megközelítés ideális az adatérzékeny, auditra készülő szervezeteknek, például fintech vagy egészségügyi vállalatoknak, ám korlátja, hogy a hatókör könnyen szűkebb lehet a valós fenyegetéseknél. Egy audit szempontjából megfelelő rendszer nem biztos, hogy ellenáll egy célzott, kreatív támadásnak.

Folyamatos pentest szolgáltatásként (PTaaS)

A PTaaS (Penetration Testing as a Service) abból a felismerésből született, hogy egy évente egyszer elvégzett, pillanatképszerű teszt nem tud lépést tartani egy folyamatosan változó, DevOps-alapú fejlesztési környezettel.

A modell platformalapú visszacsatolást ad, remediation guidance-t (javítási útmutatót) biztosít, és jól skálázódik SaaS-környezetekben.

Van azonban korlátja. Bizonyos szabályozók nem fogadják el önmagában megfelelési bizonyítékként, a jogi felelősség tisztázása kritikus kérdés, és a mély, láncolt támadási forgatókönyveket nem helyettesíti teljesen.

A PTaaS elnevezés önmagában nem garantálja a vizsgálat mélységét. Érdemes ellenőrizni, hogy a szolgáltatás tartalmaz-e manuális tesztelést, üzleti logikai vizsgálatot, retestet és szakértői konzultációt, vagy elsősorban platformalapú sérülékenységkezelést biztosít.

Fenyegetés-vezérelt pentest (Threat-Led Penetration Testing, TLPT)

A TLPT az egyik legösszetettebb és legszigorúbban szabályozott tesztelési forma, amely azt méri, hogy a szervezet túlélne-e egy konkrét, valós támadást. Ez messze túlmutat egy egyszerű hibalista összeállításán. A módszertan valós veszélyforrás-elemzésre (threat intelligence) és a talált TTP-kre (tactics, techniques and procedures) épül.

Az EU-ban a DORA (Digital Operational Resilience Act, digitális működési reziliencia rendelet) 26. cikke kötelezővé teszi a TLPT-t bizonyos pénzügyi szereplők számára, legalább háromévente. Ez nem automatikus kötelezettség minden pénzügyi szervezetre: az illetékes hatóságok a rendeletben rögzített kritériumok alapján azonosítják a TLPT-re kötelezett cégeket.

A módszertan a TIBER-EU keretrendszerre épül, amelyet az Európai Központi Bank dolgozott ki a fenyegetésalapú etikus red teaming harmonizálására. A DORA meghatározott feltételek és hatósági jóváhagyás mellett belső tesztelők bevonását is lehetővé teszi, nem csak külső, akkreditált szakértőkét.

Melyik pentest megközelítést mikor válasszuk?

Gyakori félreértések a pentest körül

“A vulnerability scan és a pentest ugyanaz, csak más néven.”

Ez az egyik legköltségesebb feltételezés, mert könnyen ahhoz vezet, hogy egy vállalat automatizált eszközre bízza azt a kérdést, amit valójában csak ember tud megválaszolni.

“Megvan az ISO 27001 tanúsításunk, tehát nincs szükség további tesztelésre.”

A tanúsítás azt igazolja, hogy a szervezet kialakított és működtet egy irányítási rendszert az információbiztonságra, beleértve a technikai sérülékenységek kezelését is. Ez azonban nem azonos azzal, hogy egy célzott, kreatív támadó ne találna utat a rendszerbe. A tanúsítás és a tényleges ellenállóképesség tehát két külön kérdés, amelyek gyakran összefüggnek, de nem helyettesítik egymást.

“A PTaaS teljesen kiváltja a hagyományos, mélyreható pentestet.”

A folyamatos, platformalapú modell valóban gyorsabb visszacsatolást ad, és jól illik egy állandóan változó fejlesztési környezethez. Ott viszont, ahol a cél egy összetett, több rendszert és emberi tényezőt is bevonó támadási forgatókönyv feltárása, vagy ahol egy szigorú szabályozói elvárás (például a TLPT) írja elő a fenyegetésalapú, mély vizsgálatot, a PTaaS önmagában nem elegendő. A két modell inkább egymást kiegészíti: a PTaaS a folyamatos alapszintű lefedettséget adja, a mélyebb, időszakos vizsgálat pedig a kritikus, összetett kockázatokra fókuszál.

Hogyan dolgozik a Naunet: a kollaboratív modell

A sablonos tesztek jellemző problémája a szűk hatókör és az, hogy egyetlen pillanatképet adnak a rendszer állapotáról. Kisebb, stabil hatókörű rendszereknél ez sok esetben elegendő, és akár célszerűbb is lehet, mint egy nagyobb, folyamatos megbízás.

Nálunk a folyamat teljes infrastruktúra és architektúra elemzésével indul, amelyet közösen végzünk el az ügyféllel, hogy feltárjuk az egyedi környezeti kockázatokat. Nem csak egy általános checklistát futtatunk le. Ha a fejlesztési vagy UAT-környezetben technikai korlátok vannak, például hiányzik a VPN-hozzáférés, a tesztelési fókuszt és a módszereket ehhez igazítjuk, a fontosabb területeket a közös scoping fázisban priorizálva.

Csapatunk eddig 40-nél is több betörési tesztet és több mint 70 projektet zárt le, ebből több mint 6 red team gyakorlatot, így ez rendszeresen alkalmazott, bevált munkamódszer.

Az ügyfél a végén nem csupán egy hibalistát kap: a jelentés vezetői összefoglalót (executive summary) ad üzleti kockázati nyelven, valamint technikai eredményeket CVSS-pontszámmal (Common Vulnerability Scoring System, a sérülékenységek súlyosságát 0-tól 10-ig mérő szabványos skála) és reprodukálási lépésekkel. Ehhez jön egy remediation roadmap, amely priorizálja a javításokat, és egy retest, amely lezárja a ciklust.

Ez a modell különösen jó választás, ha:

• már történt biztonsági incidens,

• a rendszer gyakran változik új modulokkal,

• egyedi architektúra van jelen,

• ismétlődő biztonsági visszacsatolásra van szükség.

Mennyit veszíthet egy vállalat, ha nem tesztel időben?

Az IBM 2026-os adatszivárgási jelentése szerint egy adatszivárgás globális átlagos költsége 4,99 millió dollárra nőtt, 12%-kal az előző évhez képest. Minden negyedik rosszindulatú adatszivárgás MI-támogatott volt, ami 56%-os növekedés az előző évhez képest; az ilyen incidensek átlagos költsége körülbelül 6 millió dollár volt.

Az adatok érzékeltetik a kiberbiztonsági kockázatok üzleti nagyságrendjét. A megfelelő tesztelési stratégia ennek a szélesebb kockázatkezelési rendszernek lehet az egyik eleme.

Nincs egyetlen üdvözítő módszer

Melyik pentest típus illik egy vállalathoz? Attól függ, hogy mi a teszt célja: egy audit lezárása, egy változó rendszer lekövetése, vagy egy fenyegetéssel szembeni ellenállóképesség bizonyítása. Ehhez olyan partner kell, aki ismeri az ügyfél működését, és üzleti kontextusba tudja helyezni a technikai eredményeket.

Nem biztos abban, melyik tesztelési modell illik a rendszereihez? Kérjen ingyenes konzultációt, és közösen kiderítjük, hol van szükség compliance-, fenyegetés-vezérelt vagy folyamatos tesztelésre.

Kérjen ingyenes konzultációt

Gyakran ismételt kérdések pentest témában

Mennyi ideig tart egy pentest?

A hatókör mérete és mélysége határozza meg. Egy szűkebb, egy alkalmazásra fókuszáló teszt néhány hét alatt lezárható, egy teljes infrastruktúrát érintő, kollaboratív vizsgálat hosszabb, ütemezett munkát igényel.

Mennyibe kerül egy pentest, és mitől függ az ár?

Az ár elsősorban a hatókörtől, a választott modelltől és a tesztelés mélységétől függ. Pontos ajánlatot a scoping fázis után lehet adni.

Mit jelent a retest, és miért fontos?

A retest a javítások utóellenőrzése: a tesztelő visszatér a korábban talált hibákhoz, és igazolja, hogy a javítás valóban megszüntette a kockázatot. Ez zárja le a folyamatot, nem a jelentés átadása.

Mi a különbség a NIS2 és a DORA előírásai között?

A NIS2 a kockázatkezelési intézkedések hatékonyságának rendszeres értékelését írja elő, amelynek egyik lehetséges eszköze a penetrációs teszt. A DORA ennél szűkebb kört érint: csak a pénzügyi szektor kijelölt, jelentős szereplőit, de tőlük konkrétan fenyegetés-vezérelt (TLPT) tesztelést vár el, legalább háromévente.