Mennyibe kerül a penetrációs teszt, és mitől függ az ára

„Mennyibe kerül egy penetrációs teszt?” Erre a magyar piac többsége azt feleli, hogy az árazás egyedi. Igaz válasz, csak éppen keretet nem lehet belőle tervezni. Az ajánlatkérő piacterek üzleti modellje pontosan erre a hiányra épül: nem árat adnak, hanem összegyűjtik a kérdést, és szétküldik több szolgáltatónak.

Árlistát mi sem publikálunk, és ez nem kitérés. Két webáruház, amelyet az ajánlatkérésben ugyanaz az egy mondat ír le, a ráfordításban akár háromszorosan is eltérhet. Azt viszont közreadjuk, amiben a munka ténylegesen mérhető, és azt is, mi mozgatja. Ennyiből a saját hatókörét már be tudja árazni, a beérkező ajánlatokat pedig valóban össze tudja hasonlítani.

Miért rossz kérdés az, hogy „mennyibe kerül egy alkalmazás vizsgálata”?

Az „alkalmazás” nem munkamennyiség. Ugyanaz a szó takar egy kapcsolati űrlapos honlapot és egy portált, amelyben háromféle fiók, fizetés, fájlfeltöltés és negyven API-végpont van. Az elsővel két nap alatt végzünk. A másodikra tíznél több embernap kell, és a végén még mindig el kell dönteni, mit nem nézünk meg.

Aki a hatókör ismerete nélkül mond árat, kétféleképpen teheti: vagy beépíti a legrosszabb eset kockázatát, vagy a legjobb esetre számol, és menet közben szűkíti a hatókört. Mindkettő ugyanoda vezet, a projekt felénél a szerződésmódosításról szóló beszélgetéshez.

A megválaszolható kérdés máshogy hangzik: hány embernap kell erre a hatókörre, és mit tartalmaz pontosan ez a hatókör. A cikk további része erről szól.

Az egység az embernap

Az embernap egy tesztelő egy munkanapja – ugyanazt jelenti, mint a szakértői nap. Ebben tervezik a munkát, ebben számol a csapat, és csak ebben lehet két ajánlatot egymás mellé tenni. Az alábbi táblázat tipikus hatókörökhöz ad tájékoztató ráfordítást és átfutási időt.

A két oszlop nem ugyanazt méri, és ezt érdemes szétválasztani. A ráfordítás a tesztelők munkája. Az átfutási idő ezen felül tartalmazza a hatókör rögzítését, a hozzáférések átadását – ez rendszerint a megrendelőn múlik – és a jelentés megírását. Hogy ezekért a napokért pontosan mi jár, azt a penetrációs teszt oldalon szedtük össze.

Mi mozgatja a ráfordítást?

A szerepkörök száma

Alkalmazásnál ez a legsúlyosabb tétel. Háromféle fiók nem ugyanaz az alkalmazás, mint egy: a jogosultsági teszteket szerepkörönként külön kell végigvinni, utána pedig keresztbe is. Három szerepkörnél ez hat hozzáférési irányt jelent – lát-e az egyik felhasználó a másik adataiból, eljut-e a hétköznapi fiók az adminisztrátori funkciókig, marad-e élő hozzáférés kijelentkezés után.

Az ajánlatkérésben ezért a szerepkörök száma többet nyom a latban, mint a képernyőké. Adja meg mindjárt az elején, és készítsen tesztfiókot mindegyikhez.

Az API-végpontok és a funkciók száma

Tíz űrlap nem tízszer annyi munka, mint egy, de nem is ugyanannyi. Az API-knál nem a képernyő az egység, hanem a végpont: mindegyiknek saját metódusai, paraméterei és jogosultsági szabályai vannak.

Itt lehet a legolcsóbban spórolni, méghozzá a hatókör csonkítása nélkül: adja át a dokumentációt. Egy OpenAPI-leírás vagy egy Postman-gyűjtemény órákat vesz le a felderítésből, amelyek egyébként a végpontok kitalálásával telnének. Ugyanaz az idő visszakerül az üzleti logika vizsgálatára, vagyis oda, ahol a legsúlyosabb hibák vannak.

Az IP-címek és az élő rendszerek száma

Infrastruktúránál nem a címtartomány mérete számít, hanem az, hány gép válaszol, és mi fut rajtuk. Egy /24-es tartomány tizenkét működő kiszolgálóval kevesebb munka, mint hatvan gép három telephelyen szétszórva.

Az ajánlatkérésbe tehát az IP-címek és a tartományok listája kerüljön, külön jelezve, mi áll rajtuk. A tartományvezérlő, a levelezőkiszolgáló és az ipari rendszer háromféle óvatosságot és háromféle ráfordítást jelent.

A teszt modellje és a forráskód

Itt csal a legtöbbet az intuíció: minél kevesebbet tudunk induláskor a rendszerről, annál drágább a munka.

• Black-box. A legdrágább. A tesztelő nulláról indul, így a felderítés viszi el a keret egy részét, mielőtt bárki hozzáérne a tényleges vizsgálathoz.
• Grey-box. A leggyakoribb választás. Felhasználói fiókok és egy rövid rendszerleírás elég ahhoz, hogy rögtön a lényegnél kezdjünk.
• White-box. Ez adja a legtöbb megállapítást embernaponként. Forráskóddal, architektúrarajzzal és adminisztrátori fiókkal olyan hibákig jutunk el, amelyekig kívülről csak egy hét alatt vagy egyáltalán nem jutnánk el.

A modellt ahhoz érdemes igazítani, amitől a szervezet tart, nem a kerethez – a három megközelítést a mi az a penetrációs teszt cikkben bontottuk ki.

Éles környezet vagy tesztkörnyezet

Az éles rendszeren óvatosan kell dolgozni, és az óvatosság idő: csúcsidőn kívüli időablak, egyeztetés az üzemeltetéssel, bizonyos technikák kihagyása, visszaállítási terv. A tesztkörnyezet ezek nagy részét leveszi – egyetlen feltétellel: az élesnek a másolata legyen, ne egy fél éve lemaradt változat kikapcsolt fizetési integrációval. Az élessel nem egyező környezet vizsgálata olcsóbb és értéktelen.

A kézi munka aránya

Két ajánlat itt tér el a legjobban, és itt a legnehezebb összevetni őket.

Az automatizált eszköz végigmegy a rendszeren, és kiírja, amit az adatbázisában megtalál. Olcsó, gyors, és az ismert hibákat elkapja. Az alkalmazás logikáját viszont nem érti: nem tűnik fel neki, hogy az egyik fiók látja a másik megrendeléseit, mert nem tudja, hogy nem kellene.

A kézi vizsgálatot ember végzi, aki érti ezt a logikát, és szándékosan próbálja megkerülni. Ő találja meg a jogosultsági és az üzleti szabályokban rejlő hibákat, és ő fűzi egyetlen komoly forgatókönyvbe a külön-külön jelentéktelen apróságokat. Sokszorosába kerül, mert sokszoros munka. A két megközelítést külön cikkben állítottuk egymás mellé.

Ha az egyik ajánlat feltűnően olcsóbb a többinél, az első kérdés adott: ebből mennyi a kézi munka?

A jelentés formája és a megfelelési elvárás

A jelentés termék, nem melléktermék. Az eszközből kiexportált lista még nem az: attól a dokumentumtól, amelyből javítási terv készíthető, több embernap munka választja el – és éppen ez a különbség dönti el, elfogadja-e az auditor bizonyítéknak.

A ráfordítást növeli az is, ha a megállapításokat konkrét követelményekhez kell rendelni: az ISO/IEC 27001 szabvány A. mellékletéhez, a PCI DSS előírásaihoz vagy a 7/2024. (VI. 24.) MK rendelet 2. mellékletében szereplő védelmi intézkedésekhez. Ez a hozzárendelés nem formaság: ettől lesz a jelentésből bizonyíték.

Újratesztelés és ismételhetőség

A javítások után ellenőrizni kell, hogy tényleg működnek. Az újratesztelés nem a teljes vizsgálat megismétlése: csak azokat a pontokat nézi meg újra, ahol megállapítás született. Nálunk ez a munka része, nem külön tétel – és minden más szolgáltatónál is érdemes rákérdezni, mert gyakran önálló sor az ajánlatban.

Az ismételhetőség a többi tényezővel ellentétes irányba hat: csökkenti a ráfordítást. Ugyanannak a környezetnek a második és harmadik vizsgálatánál rövidebb a felderítés, a csapat pedig ismeri az architektúrát és a korábbi megállapításokat. Egy több körre szóló megállapodás olcsóbb, mint három külön megrendelés ugyanarra a három évre.

Hogyan számolja ki a saját hatókörét?

Tegyük fel, hogy egy webáruházról van szó: három szerepkör (vendég, ügyfél, adminisztrátor), nagyjából negyven API-végpont, fizetési integráció, grey-box modell, és a vizsgálat az éles rendszer másolatán zajlik. Így oszlik el a munka.

Ez 2–3 hét átfutást jelent. A számok tájékoztató jellegűek: ugyanaz a hatókör más csapatnál másképp oszlik el, a nagyságrend viszont ellenőrizhető. Innentől a saját hatókörét is végig tudja gondolni, mert azt is látja, mi mozdítja el a végösszeget:

• két további szerepkör: +1–1,5 embernap, mert a keresztirányú vizsgálat négyzetesen nő;
• black-box modell grey-box helyett: +1–2 embernap felderítés;
• éles környezet a másolat helyett: +0,5–1 embernap egyeztetés és időablak;
• hiányzó API-dokumentáció: +0,5–1 embernap találgatás;
• forráskód átadása: nem növeli a ráfordítást, hanem átcsoportosítja a felderítésről a mélyebb vizsgálatra.

Mi nem mozgatja az árat?

A cég mérete. Rendszert vizsgálunk, nem beszámolót. A kis cég összetett portállal többet fizet, mint a nagy egy egyszerű honlapért.

A talált sérülékenységek száma. A munkáért fizet, nem az eredményért. Aki találatonként számláz, annak érdeke a súlyosság felnagyítása.

Az, hogy „vonzó célpont”-e. Ez értékesítési érv, nem tervezési szempont. A támadók a legkisebb ellenállás irányába indulnak, nem cégméret szerint válogatnak.

Mennyi ideig tart egy penetrációs teszt?

A projekt három szakaszból áll, és csak a középső a vizsgálat.

1. Előkészítés – a hatókör, a tesztelési szabályok és a kizárások írásba foglalása, a fiókok és a hozzáférések átadása. Néhány nap, jellemzően a megrendelőnél.
2. Vizsgálat – hatókörtől függően 3–15 embernap.
3. Jelentés – nagyjából a projektidő ötöde. A tesztek után készül, nem közben.

Az indulástól a jelentésig ez összesen 1–3 hét. Az újratesztelés később jön, a javítások átadása után, és az eredeti ráfordítás töredékébe kerül.

A gyakorlatban gyakran nem a vizsgálat tart a legtovább, hanem a kezdésre való várakozás. A jó csapatok naptára hetekre előre tele van, tehát ha a jelentés egy auditra vagy egy pályázatra kell, a hatókörről szóló beszélgetést időben érdemes elkezdeni.

Van-e jogszabályban rögzített ára a tesztelésnek?

A kereskedelmi penetrációs tesztnek nincs hatósági ára: a felek állapodnak meg. Egy szomszédos tevékenység díjának viszont van jogszabályi felső határa, és ezen a területen ez a magyar piac egyetlen olyan száma, amely nem a szolgáltatóktól származik.

A Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény (a továbbiakban: Kiberbiztonsági tv.) 16. § (1) bekezdése szerint az érintett szervezet kétévente köteles kiberbiztonsági auditot végeztetni. Ennek az auditnak a legmagasabb díját az 1/2025. (I. 31.) SZTFH rendelet rögzíti, méghozzá képlettel: egy 1 750 000 Ft-os alapdíjat – áfa nélkül – három szorzó módosít.

A képlet két szélső értéke adja a keretet. A legkisebb kötelezett szervezetnél 1 750 000 × 0,9 × 1 × 1, vagyis 1 575 000 Ft; a legnagyobbnál 1 750 000 × 4 × 4 × 5, vagyis 140 000 000 Ft. Mindkettő áfa nélkül értendő, és mindkettő legmagasabb díj, nem árlista: a rendelet a felső határt szabja meg, a tényleges díjról az auditorral kell megállapodni. Az 1 750 000 Ft-ot önmagában idézni ezért félrevezető – az csak a képlet alapegysége. A pontos sávhatárokat a rendelet melléklete tartalmazza.

Két dolgot érdemes ehhez hozzátenni. Az egyik: ez a díj az audité, nem a penetrációs teszté. A kiberbiztonsági auditot nyilvántartásba vett auditor folytatja le, és a Kiberbiztonsági tv. 21. § (2) bekezdése összekapcsolja a két nyilvántartást: az auditornak az 57. § (1) bekezdés c) pontja szerinti, sérülékenységvizsgálatra jogosult szervezetek között is szerepelnie kell. Kereskedelmi penetrációs tesztet végzünk, és ehhez az eljáráshoz a technikai bizonyítékot adjuk hozzá: a vizsgálati jelentést, a megállapításokhoz tartozó bizonyítékokat, a CVSS szerinti kockázati besorolást és az újratesztelés írásos eredményét. Hogy az auditor mit fog kérni, és mi legyen készen előtte, azt a kiberbiztonsági auditra való felkészülésről szóló cikkben írtuk le.

A másik: a képlet a szervezet paramétereiből számol, nem a vizsgálat mélységéből. Az auditdíj tehát nem viszonyítási alap egy penetrációs teszt árához. Arra viszont jó, hogy lássa, mekkora nagyságrend a kétévente esedékes kötelező audit – és hogy az audit előtti technikai felkészülést ehhez képest hová tegye a költségvetésben.

Amikor nem a megrendelőt terheli a számla

Egy kör van, ahol a vizsgálat nem kerül pénzbe. A Kiberbiztonsági tv. 57. § (5) bekezdése szerint az 1. melléklet 1–9., 11., 14. és 15. pontja szerinti szervezeteknél a sérülékenységvizsgálat a Nemzeti Kiberbiztonsági Intézet (NKI) kizárólagos hatásköre, és az NKI a saját oldalán térítésmentesnek nevezi ezt a szolgáltatását. A kör viszont zárt: a 12–13. pont szerinti önkormányzatok és az 1. § (1) bekezdés b) pontja szerinti állami többségi tulajdonú társaságok kívül esnek rajta. Aki tehát a közszférában tervez keretet, annak érdemes előbb megnéznie, melyik pont alá tartozik. Hogy pontosan ki végezheti el a vizsgálatot, azt külön cikkben vezettük végig.

Az ajánlatkérés, amelyet be lehet árazni

Hatókör nélkül az ár találgatás, két találgatás összevetése pedig semmit nem mond. Az az ajánlatkérés kap összehasonlítható válaszokat, amelyben benne van:

• a célpontok listája: doménnevek, IP-címek és tartományok, alkalmazásnevek, mobilverziók;
• a szerepkörök száma és tesztfiók mindegyikhez;
• az API-végpontok száma a dokumentációval együtt (OpenAPI-leírás, Postman-gyűjtemény);
• a teszt modellje: black-box, grey-box vagy white-box, és hogy jár-e hozzá forráskód;
• a környezet: éles rendszer vagy másolat, időablakok, a vizsgálatból kizárt technikák;
• a módszertan és az elvárt lefedettség – az OWASP WSTG, az ASVS és a többi szabvány konkrétan és ellenőrizhetően írja le a mélységet;
• a jelentés elvárt formája és nyelve;
• az újratesztelés: benne van-e, és a javítások átadása után meddig hívható le;
• a határidő és a munka közbeni kapcsolattartás módja.

Ezzel a listával összevethető ajánlatokat kap. Enélkül kétszeres eltéréseket – és egyik ajánlat sem lesz hibás.

Hogyan hasonlítson össze két ajánlatot?

Ha két szám van az asztalon, és az egyik a kétszerese a másiknak, akkor szinte biztosan nem ugyanazt a munkát kapja meg. Öt kérdés eldönti:

1. Hány embernap? Ha az ajánlat ezt a számot nem tartalmazza, nincs mit összehasonlítani.
2. Mekkora a kézi munka aránya? Kérdezze meg egyenesen; a szakmában ez szokásos kérdés.
3. Milyen módszertan szerint és milyen mélységig? Az OWASP Top 10 más lefedettség, mint az OWASP ASVS második szintje.
4. Ki végzi a vizsgálatot, és milyen tanúsítványa van? A technikai munkában a tapasztalt és a kezdő tesztelő között abban van a különbség, mit találnak meg, nem abban, mennyi idő alatt. A vállalkozó ellenőrzéséről külön cikkben írtunk.
5. Benne van-e az újratesztelés, és meddig hívható le? Ha nincs, számolja hozzá.

Két embernap egy ötszerepkörös alkalmazásra nem megtakarítás. Az egy másik hatókör, ugyanazzal a mondattal leírva.

Mikor nem a penetrációs teszt a jó válasz?

Az őszinte válasz az, hogy néha nem penetrációs tesztre van szükség.

• Ha az ismert hibák folyamatos követése a cél, sok rendszeren egyszerre, akkor a rendszeresen ismételt sérülékenységvizsgálat a jobb eszköz.
• Ha a kérdés az, hogy felismerik-e a munkatársak az adathalászatot, akkor social engineering vizsgálat kell, nem alkalmazásteszt.
• Ha arra kíváncsi, végigmenne-e egy valódi támadó az adatokig, és észrevenné-e bárki, akkor a Red Teamingről beszélünk. Más műfaj, más keret, és akkor van értelme, ha a kézenfekvő hibák már nincsenek meg.

A legdrágább teszt az, amelyet rossz célra rendeltek meg.

Drágább-e a megfelelés miatt rendelt teszt?

Maga a vizsgálat nem. Az árat a hatókör adja, nem az ok, amiért a teszt készül. A bizonyíték formája változik: a jelentés felépítése, a megállapítások hozzárendelése a konkrét követelményekhez és az újratesztelés írásos visszaigazolása, amely lezárja a szálat. Ez nálunk a szolgáltatás része, nem felár.

Érdemes viszont tudni, mit ír elő valójában a magyar szabályozás, mert ezen a ponton sok a téves állítás. A védelmi intézkedések katalógusa a 7/2024. (VI. 24.) MK rendelet 2. melléklete: az 5.21 behatolásvizsgálat egyik biztonsági osztályban sem kötelező, kizárólag az 5.22, vagyis a független szakértő vagy csapat bevonása az, és csak a magas osztályban. Évenkénti penetrációs tesztet tehát nem ír elő jogszabály – a rácsot cellánként külön cikkben jártuk végig. A kétévente esedékes auditon belül más a helyzet: 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” alkalmazni. Két szó számít itt sokat: jogosult, tehát a törvény felhatalmazza az auditort, nem kötelezi – és belső, amelyet a széles körben másolt kamarai összefoglaló külsőre cserél.

A pénzügyi szervezeteknél más a viszonyítási pont, és ott a gyakoriság közvetlenül a keretre hat. A Magyar Nemzeti Bank 1/2025. (I.13.) számú ajánlása a kártyarendszerekre, az ügyfélkiszolgáló webes rendszerekre és a mobilalkalmazásokra negyedéves sérülékenységvizsgálatot vár el; ez felügyeleti elvárás, nem jogszabály. A gyakoriságokat külön cikkben szedtük össze. Hogy egy meglévő ISO 27001 tanúsítvány mit zár le és mit nem, azt itt vezettük végig; a megfelelési célú tesztelés kereteit pedig a NIS2 penetrációs teszt és az ISO 27001 penetrációs teszt oldalon írtuk le.

Mit tartalmaz nálunk a munka?

• Hatókörről szóló egyeztetés és írásba foglalt tesztelési szabályok.
• Kézi vizsgálat elismert módszertanok szerint, nem pusztán automatizált futtatás.
• Vizsgálati jelentés vezetői összefoglalóval és bizonyítékokkal alátámasztott technikai résszel.
• Konkrét javítási javaslatok, nem gyártói dokumentációra mutató hivatkozások.
• Újratesztelés a javítások elvégzése után.
• Zárókonzultáció azzal a tesztelővel, aki a vizsgálatot végezte.

Konkrét, kötöttség nélküli ajánlatot egy rövid, hatókörről szóló beszélgetés után adunk – kérje itt.

A penetrációs teszt ára – gyakori kérdések

Kapcsolódó Haxoris-szolgáltatások: webalkalmazások és infrastruktúra penetrációs tesztelése