Milyen gyakran kell penetrációs tesztet végezni? Az MNB elvárása

A magyar kiberbiztonsági szabályozás kétévenkénti auditot ír elő, tesztelési naptárt viszont nem ad. Ezért fordul elő, hogy két hasonló méretű intézmény közül az egyik negyedévente, a másik háromévente néz rá ugyanarra a rendszerre, és mindkettő úgy érzi, rendben van. A pénzügyi szektorban ez a bizonytalanság megszűnik: a Magyar Nemzeti Bank informatikai ajánlása számokban mondja meg, mikor kell újra megnézni egy rendszert – külön az éves, külön a negyedéves és külön az eseményhez kötött vizsgálatot. Alább pontról pontra végigvesszük, mit vár el, hol húzódik a határ a sérülékenységvizsgálat és a betörési (penetrációs) teszt között, és mit érdemes még a szerződés aláírása előtt rögzíteni.

Mit mond az MNB 1/2025. (I.13.) ajánlása?

Teljes címén: „A Magyar Nemzeti Bank 1/2025. (I.13.) számú ajánlása az informatikai rendszer védelméről”. Az MNB 2025. január 13-án adta ki a felügyelete alá tartozó pénzügyi intézményeknek, és ez az ajánlás lépett a korábbi 8/2020. (VI.22.) ajánlás helyébe. A tesztelési gyakoriságról a 13.1.4 pont e) és f) alpontja rendelkezik, a független felülvizsgálat ritmusáról pedig a 13.1.3 pont.

Ajánlás vagy jogszabály? A különbség nem formaság

Az ajánlás nem jogszabály. Nem keletkeztet közvetlen kötelezettséget, hanem azt írja le, mit vár el az MNB a felügyeleti munkája során – ezért a helyes megnevezése felügyeleti elvárás. A kötelező erő máshonnan jön: az ágazati törvényekből, a pénzügyi intézmények, a biztosítók és a befektetési vállalkozások informatikai rendszerének védelméről szóló 42/2015. (III. 12.) Korm. rendeletből, valamint a 2025. január 17. óta közvetlenül alkalmazandó DORA rendeletből.

Ez a különbség két irányban is számít. Egy belső szabályzat, amely a negyedéves ciklust „az MNB jogszabálya szerint” írja elő, pontatlan – és a pontatlanság mindig az első, amit egy felügyeleti vizsgálaton szóvá tesznek. Ugyanakkor az ajánlás gyakorlati súlya nagy: a felügyelet a saját elvárásai mentén kérdez, tehát a 13.1.4 pont ciklusait érdemes szó szerint beírni a sérülékenységkezelési folyamatba, és ott meg is jelölni, honnan származik a szám.

A 8/2020. (VI.22.) ajánlás már nem él

Ez a mondat külön bekezdést érdemel, mert a régi hivatkozás makacsul tovább él. Az MNB 2021. június 7-én adott ki egy kérdés-válasz gyűjteményt (GYIK) a sérülékenységvizsgálatokról és a betörési (penetrációs) tesztekről, és ez maga is a 8/2020. ajánlásra hivatkozik – érthető okból, hiszen négy évvel az 1/2025. ajánlás előtt készült. A GYIK gyakorlati része ettől még használható, és lentebb hivatkozunk is rá; a benne szereplő ponthivatkozások viszont a régi dokumentumhoz tartoznak. Ha egy belső szabályzatban vagy egy beérkező ajánlatban a 8/2020. szerepel, azt frissíteni kell, mielőtt bárki bizonyítékként hivatkozna rá.

Milyen gyakran kell sérülékenységvizsgálatot végezni?

A 13.1.4 e) pont két ciklust különböztet meg, és a kettő között a rendszer kitettsége dönt. Szó szerint:

• „a belső és elkülönített hálózati zónákban lévő rendszerekre vonatkozó sérülékenységvizsgálatok az intézmény belső szabályzati rendszerében meghatározott folyamat szerint legkésőbb évente, a bankkártya rendszerek, webes ügyfélkiszolgáló rendszerek, mobilalkalmazások és az azokat kiszolgáló rendszerek vonatkozásában legkésőbb negyedévente ismételve, valamint a kockázatként meghatározott kritikus hibák javítása haladéktalanul, a nem kritikus hibák javítása a kockázatokkal arányos ütemezés szerint megtörténik”

Négy dolgot érdemes kiolvasni belőle.

• A „legkésőbb” szó a maximumot jelöli, nem az ütemet. Az éves és a negyedéves ciklus felső határ: az az intézmény, amely negyedévente egyszer, a negyedév utolsó hetében szkennel, formálisan teljesít, de a két vizsgálat között három hónapig nem tud a saját kitettségéről semmit.


• A negyedéves kör a hátteret is magában foglalja. „Az azokat kiszolgáló rendszerek” fordulatot szokás átugrani, pedig ez viszi be a körbe a mobilalkalmazás mögötti API-kat, az ügyfélkiszolgáló felület háttérszolgáltatásait és az adatbázisokat. A gyakorlatban a negyedéves hatókör így rendszerint nagyobb, mint amekkorára először tervezik.


• A javításnak is van órája. A pont nemcsak a vizsgálatról szól: a kritikus hibát haladéktalanul, a többit a kockázatokkal arányos ütemezés szerint kell javítani. Az a negyedéves ciklus, amelyből minden alkalommal ugyanaz a nyitott megállapítás jön vissza, nem teljesítés, hanem dokumentált elmaradás.


• Az ajánlás írott folyamatot feltételez. „Az intézmény belső szabályzati rendszerében meghatározott folyamat szerint” azt jelenti, hogy a ciklus nem szóbeli megállapodás a szolgáltatóval, hanem szabályzati elem, amelyre hivatkozni lehet.

Milyen gyakran kell penetrációs tesztet végezni?

A 13.1.4 f) pont a másik vizsgálattípusról szól, és tulajdonképpen ez a válasz a cikk címében feltett kérdésre:

• „az Internet felől elérhető alkalmazások penetrációs tesztje a kockázatként meghatározott hibák javítása után, az üzembe állítást megelőzően, illetve bármely a biztonságot érintő változtatás alkalmával, majd legkésőbb évente ismételve megtörténik”

Egyetlen mondat, négy külön kiváltó ok:

• A hibajavítás után. Az újratesztelés nem külön szívesség a szolgáltatótól, hanem az ajánlásból következő lépés. Aki javítás után nem néz rá újra a megállapításra, annak nincs bizonyítéka arra, hogy a javítás megfogott – és arra sem, hogy nem hozott be újat.


• Az üzembe állítás előtt. A teszt így nem az év végi feladat, hanem kapu az élesítés előtt. Ez az a pont, amelyen a fejlesztési ütemterv és a biztonsági ütemterv rendszeresen összeér, ezért érdemes már a projekt tervezésekor időt hagyni rá.


• Minden biztonságot érintő változtatáskor. Ez a legszélesebb feltétel, és ezt hagyják ki a leggyakrabban. A hitelesítési logika átírása, egy új fizetési integráció vagy a jogosultsági modell módosítása mind idetartozik – függetlenül attól, mikor volt az utolsó éves teszt.


• Majd legkésőbb évente. Az éves ismétlés az alsó határ arra az esetre, ha közben semmi nem történt. Egy aktívan fejlesztett ügyfélkiszolgáló alkalmazásnál az ütemezést a harmadik feltétel viszi, nem ez.

Érdemes a hatókör megfogalmazására is figyelni: az f) pont az internet felől elérhető alkalmazásokról beszél. A belső alkalmazások nem esnek ki a képből, csak az e) pont éves sérülékenységvizsgálati ciklusa alá tartoznak.

Az elvárt gyakoriságok egy táblázatban

A 13.1.3 pont hároméves ciklusa a másik kettő fölött áll: nem a technikai vizsgálatot ismétli, hanem azt várja el, hogy a független felülvizsgálat idővel a védelem minden részterületét lefedje. A három ciklus tehát egymásra épül, és nem helyettesíti egymást.

Sérülékenységvizsgálat vagy betörési teszt? Az MNB szóhasználata

Az e) és az f) pont szándékosan két különböző szót használ, és a különbség nem stilisztikai. A GYIK a fogalmat is meghatározza: „A betörési teszt (penetrációs teszt, etikus hackelés) során egy felhatalmazott biztonsági szakértő különböző támadástípusokkal megvizsgálja egy rendszer, szoftver, informatikai környezet biztonságát.” Ugyanez az anyag nevezi meg a black-box, a grey-box és a white-box modellt, vagyis azt, mennyi információt kap előre a tesztelő.

A gyakorlati elválasztás ebből következik. A negyedéves ciklus eszközzel támogatott, ismételhető felderítés: nagy hatókörön fut, gépi ütemezéssel, és a célja az, hogy egyetlen ismert hiba se maradjon hetekig észrevétlenül. Az éves, illetve változtatáshoz kötött penetrációs teszt ezzel szemben kézi munka: a tesztelő nemcsak azonosítja a hibát, hanem igazolja, hogy az adott környezetben ki is használható, és összefűzi az önmagukban ártalmatlan gyengeségeket. A két munka különbségét külön cikkben szedtük össze.

Egy szóhasználati pontosítás idekívánkozik, mert két külön szabályozási világról van szó. A pénzügyi felügyelet nyelvén a betörési (penetrációs) teszt a bevett kifejezés; a Kiberbiztonsági tv. viszont a behatolásvizsgálat szót használja, és a 4. § 11. pontja a sérülékenységvizsgálat egyik módszereként határozza meg. Ugyanazt a munkát tehát a két rendszer másképp nevezi. A belső dokumentációban érdemes megjelölni, melyik szabályozás szótárával dolgozik az adott fejezet.

Mit kell rögzíteni a teszt megrendelésekor?

A GYIK hat dolgot sorol fel, amelyekben a megbízónak és a szolgáltatónak előre meg kell állapodniuk. A lista rövid, és ajánlatértékelő szűrőnek is kiváló: aki nem tudja mind a hatot leírni, az a hatókört sem gondolta végig.

• Milyen rendszerek vizsgálata történik. Nem „a netbank”, hanem a konkrét doménnév, IP-tartomány, alkalmazásverzió és a vizsgált jogosultsági szintek. A negyedéves körnél idetartoznak a kiszolgáló háttérrendszerek és API-k is.


• Milyen típusú penetrációs teszt készül. Black-box, grey-box vagy white-box – és ha grey-box, akkor hány és milyen szerepkörű felhasználóval. Ez a döntés határozza meg, mennyi időt tölt a tesztelő felderítéssel, és mennyit valódi támadási kísérletekkel.


• Mennyi ideig tart a teszt. Konkrét időablakkal, mert a monitorozó csapatnak és az üzemeltetésnek is tudnia kell róla. A ciklus akkor teljesül, amikor a vizsgálat lezárul és a jelentés elkészül, nem amikor megrendelték.


• Ki végzi el a tesztelést. Névvel és tanúsítványokkal, nem csak cégnévvel. A pénzügyi szektorban ez a személyi kör rendszerint titoktartási és háttérellenőrzési feltételekhez is kötött.


• Milyen eszközökkel történik a tesztelés. Itt derül ki az automatizált és a kézi munka aránya. Ha az ajánlat csak eszközneveket sorol, akkor a megrendelő valójában sérülékenységvizsgálatot vásárol penetrációs teszt néven.


• Milyen mélységű a tesztelés. Meddig mehet el a tesztelő: megáll a hiba igazolásánál, vagy kihasználja és tovább lép a környezetben. Ezt előre kell tisztázni, mert utólag nem lehet.

A GYIK két olyan kérdést is rendez, amelyen a szerződések el szoktak akadni. Az egyik, hogy a tesztelő nyithat-e valódi ügyfélszámlát az élesben futó szolgáltatás vizsgálatához – a válasz szerint erre szükség lehet. A másik az éles környezetben végzett teszt: ilyenkor a pénzmosás és a terrorizmus finanszírozása megelőzéséről szóló 2017. évi LIII. törvény szabályai is szóba jönnek, ezért az élesben végzett munkát a megfelelési területtel együtt kell megtervezni.

Mi az a TLPT, és hol a helye ebben a sorban?

A fenyegetés alapú behatolási tesztelés (Threat Led Penetration Testing – TLPT) nem az éves penetrációs teszt nagyobb testvére, hanem másfajta vizsgálat. A DORA vezette be az uniós pénzügyi szektorban, az erre kijelölt szervezetekre vonatkozik, és felügyeleti keretfeltételek mellett zajlik: a hatókör és a folyamat jóváhagyása, valamint a tesztet végző szolgáltatóval szemben támasztott követelmények is a keretrendszer részei. Magyarországon a DORA szerinti illetékes hatóság az MNB.

A gyakorlati következmény egyszerű: a TLPT nem váltja ki a 13.1.4 f) pont szerinti éves vagy változtatáshoz kötött penetrációs tesztet, és fordítva sem. Az ajánlás ciklusai a napi működés szintjén futnak, a TLPT pedig a teljes védelmi és reagálási képességet méri, jóval ritkábban és sokkal nagyobb szervezéssel.

Kiberbiztonsági tv. vagy DORA? Melyik szabály vonatkozik egy pénzügyi intézményre?

A Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény (a továbbiakban: Kiberbiztonsági tv.) 2025. január 1-jén lépett hatályba, és a hatálya alá tartozó szervezetek számára kétévenkénti kiberbiztonsági auditot ír elő (16. § (1)). A DORA hatálya alá tartozó pénzügyi szervezetek azonban kikerültek ebből a körből: az 1. § (1) bekezdés c) pontja és az 1. § (2) bekezdése együtt veszi ki őket a törvény hatálya alól, a felügyeletüket pedig az MNB látja el a DORA alapján.

Ennek két gyakorlati következménye van. Az egyik, hogy egy banknál a tesztelés kérdésére nem a kiberbiztonsági audit rendje adja a választ, hanem a DORA, az ágazati jogszabályok és az MNB elvárásai. A másik, hogy a más ágazatokból ismert szabályok itt nem alkalmazhatók automatikusan – a NIS2 magyar átültetéséhez kötődő kötelező védelmi intézkedésekről külön írtunk, mert azok logikája más. A pénzügyi csoportok esetében a képet tovább árnyalja, hogy egy csoporton belüli, nem felügyelt szolgáltató cég már a Kiberbiztonsági tv. hatálya alá eshet.

Így néz ki egy év a gyakorlatban

Az alábbi váz nem szabályzatminta, hanem az a sorrend, amelyre a ciklusok felfűzhetők anélkül, hogy az év végén torlódnának.

• Negyedévente: sérülékenységvizsgálat a bankkártya rendszereken, a webes ügyfélkiszolgáló felületeken, a mobilalkalmazásokon és az azokat kiszolgáló háttérrendszereken. Ugyanabban a hatókörben, ugyanazzal a módszerrel, hogy a négy futás összehasonlítható legyen.


• Évente: sérülékenységvizsgálat a belső és elkülönített hálózati zónákban, valamint penetrációs teszt az internet felől elérhető alkalmazásokon. Érdemes egymás után ütemezni: a felderítés eredménye adja a kézi teszt kiindulópontját.


• Eseményhez kötve: teszt az üzembe állítás előtt és minden biztonságot érintő változtatás után. Ezt a fejlesztési folyamatba kell beépíteni, mert utólag nem pótolható.


• Javítás után: újratesztelés a kritikus és a magas kockázatú megállapításokra, írásos lezárással.


• Hároméves horizonton: a független felülvizsgálat úgy ütemezve, hogy minden részterület sorra kerüljön.

Hol illeszkedik ebbe a Haxoris?

A negyedéves és az éves ciklus más munkát kíván, ezért mi is kétféle vizsgálatot adunk hozzájuk. Az ismételhető, eszközzel támogatott felderítést a sérülékenységvizsgálat oldalán írtuk le; ez az, ami negyedévente ugyanabban a hatókörben újrafuttatható. A mélységi, kézi munkát a penetrációs teszt, azon belül a webalkalmazások és a mobilalkalmazások oldala írja le – az utóbbinál a vizsgálat a kiszolgáló API-kra is kiterjed, mert az ajánlás negyedéves köre is odáig ér.

Ami ebből a megfelelési oldalon használható:

• Hatókör és időpont a jelentés elején. Melyik rendszert, melyik felületet és melyik jogosultsági szintet vizsgáltuk, mikortól meddig, milyen modellben – vagyis azok az adatok, amelyekben a GYIK szerint előre meg kell állapodni.


• Igazolt megállapítások. Minden tétel mellett ott a reprodukció és a bizonyíték arra, hogy a hiba a gyakorlatban is kihasználható. A hamis riasztásokat előtte kiszűrjük.


• Kockázati besorolás a saját környezetre vetítve. A CVSS-pontszám mellett leírjuk, mit jelent a hiba ebben az intézményben: ügyféladat, szolgáltatáskiesés, pénzügyi veszteség.


• Javítási sorrend. Nem „frissítse a rendszert”, hanem melyik komponenst, melyik verzióra, melyik beállítást hogyan – és mit érdemes a haladéktalan javítási körbe tenni.


• Írásos igazolás az újratesztelésről. A javítások után újra megnézzük a megállapításokat, és leírjuk, melyik zárult le. A 13.1.4 f) pont első fordulatához pontosan ez a bizonyíték kell.

A vizsgálatot elismert módszertanok szerint végezzük, webalkalmazásoknál az OWASP ASVS és a WSTG szerint, és a jelentés megnevezi, mi alapján dolgoztunk. A tesztelőink OSCP-tanúsítvánnyal rendelkeznek, a Haxoris ISO/IEC 27001 tanúsítványát pedig a TÜV SÜD adta ki – a szabvány tehát nálunk nemcsak vizsgálati mérce, hanem a saját működésünk kerete is. A TLPT-t a fentiek szerint felügyeleti keretfeltételek mellett, az arra kijelölt szolgáltatók végzik; a mi munkánk a kereskedelmi penetrációs teszt és sérülékenységvizsgálat, vagyis az, ami a 13.1.4 e) és f) pont szerinti ciklusokat kitölti.

Összefoglalva: negyedév, év, esemény

A „milyen gyakran teszteljünk” kérdésre a magyar pénzügyi szektorban négy ritmus adja a választ, és mindegyik ugyanabból a dokumentumból származik. Negyedévente az ügyfél felé nyitott rendszerek és a mögöttük álló kiszolgálók sérülékenységvizsgálata, évente a belső és elkülönített zónák vizsgálata, valamint az internet felől elérhető alkalmazások penetrációs tesztje, és ezen felül minden biztonságot érintő változtatás után egy külön teszt. A hároméves független felülvizsgálat ezt fogja össze.

Aki ezt a négy ritmust naptárba teszi, egyszerre teljesíti a felügyeleti elvárást és szünteti meg azt az állapotot, amelyben egy éven át senki nem tudja, mi támadható meg kívülről. Kérjen ingyenes konzultációt, és végigvesszük, mely rendszerek tartoznak a negyedéves körbe, mi marad az éves ciklusban, és hogyan illeszthető mindez a fejlesztési ütemtervhez.

Tesztelési gyakoriság az MNB ajánlásában – gyakori kérdések

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