Penetrációs teszt és sérülékenységvizsgálat

Mit takar konkrétan a teszt

A tesztelés a valós támadási felületből indul ki: bejelentkezési pontok, API-végpontok, feltöltési funkciók, jogosultságkezelés, szerverkonfiguráció. Manuálisan és automatizált eszközökkel is végigmegyünk a rendszeren, minden találatot humán szakértő validál, hogy ne kapj hamis pozitívokkal teli listát. A jelentés CVSS pontszámmal, kihasználhatósági kontextussal és konkrét javítási javaslattal érkezik, majd a javítás után retestet is végzünk ugyanazon a hatókörön. A hatókört előre egyeztetjük veled, hogy pontosan tudd, mely rendszerek kerülnek vizsgálat alá, és a tesztelés ütemezését úgy állítjuk be, hogy az éles forgalmat ne zavarja meg.

• Webalkalmazás- és API-tesztelés az OWASP Top 10 és API Top 10 szerint
• Infrastruktúra- és konfigurációellenőrzés a szervereken
• Jogosultsági és üzletilogika-hibák keresése, nem csak ismert CVE-k
• Retest a javítás után, bizonyítékkal a jegyzőkönyvben

Az AI-kor: gyorsabb támadás, gyorsabb védekezés

A támadók ma automatizált felderítést és LLM-ügynököket futtatnak, amelyek órák alatt feltérképezik egy alkalmazás végpontjait és próbálnak ki ismert sebezhetőségi mintákat egy publikus javítás megjelenése után. Ez lerövidíti azt az időablakot, amíg egy hiba felfedezetlen marad. Ezért nem egyszeri, hanem időszakos tesztelést javaslunk kritikus rendszerekre, és a találatokat EPSS-szel is kiegészítjük, hogy lásd, melyik hibát valószínűsíthetően tényleg kihasználják, nem csak elméletben sebezhető.

Megfelelés és jelentés

A jelentés vezetői összefoglalóval indul, majd technikai részletekkel folytatódik: hatókör, módszertan, találatok CVSS és EPSS szerint rendezve, reprodukálási lépések, javasolt javítás. Ez a formátum használható belső auditra, partneri elvárás igazolására vagy a NIS2 hatálya alá tartozó szervezetek dokumentációjához is, anélkül hogy tanúsító testületként lépnénk fel. A vezetői összefoglaló üzleti nyelven mutatja be a kockázatot a döntéshozóknak, a technikai rész pedig a fejlesztőcsapatnak ad elég részletet a tényleges javításhoz, így egyetlen dokumentum kiszolgálja mindkét célközönséget.

• Vezetői összefoglaló és technikai jelentés egy dokumentumban
• CVSS és EPSS szerinti priorizálás
• Bizonyítékkal alátámasztott retest

Hogyan dolgozunk

1. Hatókör egyeztetése

   Megbeszéljük, mely alkalmazások, API-k vagy szerverek kerülnek a tesztbe, és mikor fut le a vizsgálat anélkül, hogy zavarná az éles forgalmat.

2. Tesztelés

   Manuális és automatizált technikákkal vizsgáljuk a hatókört, minden találatot humán szakértő ellenőriz, mielőtt bekerülne a jelentésbe.

3. Jelentés átadása

   Megkapod a CVSS és EPSS szerint rendezett találatokat, reprodukálási lépésekkel és konkrét javítási javaslattal minden egyes tételhez.

4. Retest

   A javítások után visszaellenőrizzük ugyanazt a hatókört, és bizonyítékkal dokumentáljuk, hogy a talált hibák valóban le lettek zárva.

Felhasználási esetek

Technológiák

• OWASP Top 10
• OWASP API Top 10
• Burp Suite
• Nmap
• Nuclei
• Metasploit
• CVSS
• EPSS

Gyakori kérdések

• Mennyibe kerül egy penetrációs teszt?

  Az ár a hatókörtől függ: hány alkalmazás, API-végpont vagy szerver kerül tesztelésre, és milyen mélységű. Konkrét ajánlatot a hatókör egyeztetése után adunk, prices oldalon nem publikálunk fix díjszabást, mert az igazságtalanul félrevezetné az eltérő méretű projekteket.

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

  A sérülékenységvizsgálat automatizált szkenneléssel listázza az ismert hibákat. A penetrációs teszt ezen túlmegy: humán szakértő próbálja ténylegesen kihasználni a hibákat, és üzleti logikai, jogosultsági problémákat is keres, amiket egy szkenner nem lát.

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

  Kritikus rendszereken évente, illetve minden jelentős kódváltozás vagy új integráció után javasolt. Az automatizált felderítés miatt egy publikus javítás megjelenése után napokon belül megjelennek a próbálkozások, ezért a nagy változások utáni gyors teszt is fontos.

• Kötelező-e a penteszt a NIS2 alatt?

  A NIS2 hatálya alá tartozó szervezeteknek kockázatkezelési intézkedéseket kell dokumentálniuk, amelybe a rendszeres biztonsági tesztelés jellemzően beletartozik. A pontos kötelezettség a szervezet besorolásától függ, ezért ezt mindig a konkrét eset alapján egyeztetjük.

• Mi történik, ha kritikus hibát találunk a teszt közben?

  Kritikus, azonnal kihasználható hibát nem várunk meg a végső jelentésig: azonnal jelezzük, hogy el tudd kezdeni a javítást, majd a végleges dokumentumban is szerepel a teljes leírással és a retest eredményével.

• A teszt zavarja-e az éles rendszert?

  A hatókör egyeztetésekor kizárjuk azokat a technikákat és időablakokat, amelyek leállást okozhatnának, és megbeszéljük, hogy teszt- vagy éles környezeten fut-e a vizsgálat. Célunk a valós kockázat feltárása, nem a szolgáltatás megzavarása.