Fedezze Fel a Sebezhetőségeket Mielőtt a Támadók Megteszik. Tanúsított etikus hackereink valós támadásokat szimulálnak az infrastruktúrában, alkalmazásokban és emberekben lévő sebezhetőségek feltárásához, hogy Ön javíthassa azokat elsőként.
Külső és belső hálózati pentesztek az infrastruktúra, hálózati eszközök és szegmentációs vezérlők sebezhetőségeinek azonosítására.
OWASP-alapú értékelések web- és mobilalkalmazásokhoz: injektálási hibák, törött hitelesítés, nem biztonságos deszializálás és egyebek.
Adathalász szimulációk, vishing és fizikai hozzáférési tesztek a szervezet emberi biztonsági rétegének értékelésére.
Hibás konfiguráció-felülvizsgálatok és jogosultság-emelési tesztelés AWS, Azure és Google Cloud környezetekben.
Automatizált és manuális vizsgálat a támadási felületen, tényleges kockázaton alapuló rangsorolt elhárítási útmutatással.
Teljes körű ellenféllel szembeni szimuláció az észlelési és reagálási képességek tesztelésére egy kitartó, célirányos támadóval szemben.
Minden megbízás átfogó jelentést eredményez végrehajtói összefoglalóval, technikai megállapításokkal, CVSS kockázati besorolásokkal és rangsorolt elhárítási lépésekkel, amelyeken a csapat azonnal tud dolgozni.
AjánlatkérésÜzleti szintű kockázatáttekintés a felsővezetők és az igazgatóság számára.
Részletes sebezhetőség-leírások proof-of-concept és CVE hivatkozásokkal.
CVSS-pontszámmal értékelt megállapítások tényleges kihasználhatóság és üzleti hatás szerint rangsorolva.
Opcionális újratesztelés a sebezhetőségek megfelelő elhárításának megerősítésére.
A teszt értéke a hatókör pontosságán és a jelentés használhatóságán múlik. Ezért a munka nem a szkenneléssel kezdődik és nem a jelentés átadásával ér véget.
Meghatározzuk, mit tesztelünk és milyen perspektívából, mi az, ami tilos, és kit értesítünk, ha kritikus hibát találunk a teszt közben. Írásos engedély és kapcsolattartási rend nélkül nem indulunk.
Összegyűjtjük a támadási felületet: elérhető szolgáltatások, technológiák, verziók, nyilvánosan fellelhető információk. Ez adja a támadási hipotéziseket.
Kézi tesztelés, nem szkenner-futtatás. Az egyes hibákat egymásra fűzzük, mert a valódi kockázatot a lánc mutatja meg, nem az elszigetelt találat.
Reprodukálható bizonyítékkal dokumentált találatok, üzleti hatás szerint priorizálva. Átbeszéljük a csapattal, majd a javítások után ellenőrző kört futunk.
Nem ad-hoc módon dolgozunk: elismert módszertanokat követünk, hogy a lefedettség igazolható és a következő teszttel összehasonlítható legyen.
| Terület | Módszertan / keretrendszer | Mit fed le |
|---|---|---|
| Webalkalmazás | OWASP WSTG, OWASP Top 10 | Injektálás, hitelesítés, jogosultság, üzleti logika |
| Belső hálózat | PTES, MITRE ATT&CK | Laterális mozgás, jogosultság-emelés, adatkiszivárgás |
| Külső perem | OSSTMM, NIST SP 800-115 | Kitett szolgáltatások, konfigurációs hibák |
| Social engineering | MITRE ATT&CK (Initial Access) | Phishing-ellenállóság, tudatosság mérése |
| OT / ICS | IEC 62443, passzív felderítés | Szegmentáció-ellenőrzés, zónahatárok |
| Súlyosság-besorolás | CVSS v3.1 + üzleti hatás | Nem csak a pontszám: a kontextus is |
A sérülékenységvizsgálat automatizált szkennelés: listát ad arról, milyen ismert hibák lehetnek a rendszerben, sok téves riasztással. A penetrációs teszt emberi szakértői munka: megmutatja, mit tud egy támadó ténylegesen elérni, és a találatok bizonyítottak. A leglényegesebb különbség a láncépítés, három külön-külön „közepes" hiba egymásra fűzve gyakran tartományi adminisztrátori jogot ad, és ezt csak ember veszi észre. A kettő nem helyettesíti egymást: a szkennelés folyamatos legyen, a teszt rendszeres.
Standard IT-környezetben ennek kockázata alacsony, és a hatókör-egyeztetésnél kizárjuk a veszélyes műveleteket (például a szolgáltatásmegtagadás-tesztelést, ha nem kifejezetten kért). Éles rendszereknél időablakot egyeztetünk, és van egy közvetlen kapcsolattartási csatorna, amin azonnal leállítjuk a tesztet, ha bármi rendellenességet észlelnek. OT-környezetben más a helyzet, ott alapból passzív felderítéssel dolgozunk, az aktív részt pedig laborban vagy tervezett leállás alatt végezzük.
A hatókörtől függ. Egy közepes méretű webalkalmazás jellemzően 5–10 munkanap, egy belső hálózati teszt 5–15 nap, egy teljes körű külső és belső vizsgálat 3–4 hét. Ehhez jön a jelentés összeállítása (3–5 nap) és a javítás utáni újrateszt. A hatókör-egyeztetésnél mindig konkrét napszámot adunk, nem tartományt.
Mindkettőnek van létjogosultsága, de a gyakorlatban a szürkedobozos megközelítés adja a legjobb megtérülést: kapunk alap hozzáférést és dokumentációt, így a tesztelő nem a felderítéssel tölti az idő felét, hanem a valódi hibák keresésével. A teljesen vak (fekete dobozos) teszt drágább és kevesebbet talál ugyanannyi idő alatt. Ha kifejezetten a detektálási képességet akarja mérni, arra a red team gyakorlat való.
A jelentést átbeszéljük a műszaki csapattal, hogy a javítási javaslatok értelmezése ne maradjon kérdés. A javítások után ellenőrző kört futunk, és megerősítő jelentést adunk arról, mely találatok szűntek meg ténylegesen. Ez a lépés az, amit a legtöbben kihagynak: pedig újrateszt nélkül nem tudja, hogy a hiba tényleg megszűnt-e, csak azt, hogy valaki dolgozott rajta.
Igen. A NIS2 ötödik intézkedési területe (beszerzés, fejlesztés, karbantartás biztonsága) és hatodik területe (a biztonsági intézkedések hatékonyságának mérése) gyakorlatilag megköveteli a rendszeres, dokumentált tesztelést. Az ISO 27001 technikai megfelelőségi felülvizsgálati kontrollja szintén ide tartozik. A jelentéshez igény szerint megfelelőségi kivonatot is adunk, ami közvetlenül csatolható az audit-dokumentációhoz.