A sérülékenységvizsgálat és penetrációs teszt vizsgálati paraméterei

Mennyiség

Hosztok

A vizsgálandó fizikai és virtuális hosztok darabszáma jó kiindulási alapnak tekinthető a sérülékenységvizsgálat vagy penetrációs teszt projekt (pénzbeli, időbeli, erőforrásbeli) költségtervezésénél.

Szolgáltatások

Ha csak a hosztok darabszámát vesszük számításba, kellemetlen meglepetések érhetik az érintett feleket, ugyanis nem lehetetlen, hogy egy adott hoszt a vártnál jóval több szolgáltatást teszt elérhetővé akár portonként, akár webes szolgáltatásokként.

Funkciók

Ugyanakkor még a szolgáltatások darabszáma sem tisztázza a vizsgálat hatókörét, ugyanis míg egy egyszerű szolgáltatás maximum 1-2 gyorsan tesztelhető funkciója van, addig egy enterprise szintű megoldás akár több száz-ezer feladatot is elláthat.

Szerepkörök

Ha már tisztában vagyunk a hosztok darabszámával, a rajtuk futó szolgáltatásokkal és azok funkcióival, a következő kulcsfontosságú nyilatkozat az elmúlt hosszú években. Ezért tisztázni kell, hogy milyen felhasználói szerepkörök lettek meghatározva a rendszerben, amiknek megfelelően létre kell hozni különböző jogosultságú tesztfiókokat is.

Módszer

Sérülékenységvizsgálat

A sérülékenységvizsgálat célja, hogy a szervezetek által üzemeltetett és általuk meghatározott rendszerek sebezhetőségei beazonosításra és javításra kerüljenek, ezzel csökkentve egy sikeres hackertámadás bekövetkezésének valószínűségét.

Penetrációs teszt

A sérülékenységvizsgálat és a penetrációs teszt közötti lényegi különbség, hogy míg előbbi a sérülékenységek beazonosításánál megáll, addig az utóbbi már a felfedezett sérülékenységek gyakorlati próbáját, validálását is tartalmazza, aminek eredményei alapján meghatározható a sérülékenységekkel okozható károk típusa és kiterjedése. A penetrációs teszt szigorúan a Megbízó felügyeletével történik.

Mélység

Black-box

A black-box vizsgálat lényege, hogy nem használunk fel semmilyen belsős üzemeltetői és fejlesztői információt (platform, framework, stb.), kizárólag azokkal a lehetőségekkel élünk, amik egy külsős, távoli támadó rendelkezésére állnak: publikusan elérhető felületek, regisztrációs lehetőségek és űrlapok, kint felejtett tesztoldalak, keresőrobotok által indexelt (belsősnek szánt) információk.

Gray-box

A gray-box vizsgálat esetében már ügyfél és admin (kliens, regisztrált felhasználó, adminisztrátor stb.) oldali információkat, technikai részleteket, valamint dokumentációkat is felhasználunk, tehát a vizsgálat tárgyát képző rendszer kapcsolódási pontjaihoz, felületeihez teljes mértékben hozzáférünk – figyelembe véve a megbízó korlátozásait és kritériumait.

White-box

A white-box vizsgálat során már nemcsak ügyfél (kliens, regisztrált felhasználó, stb.) oldali információkat használunk fel, hanem a Megbízó részletes rendszerleírását is, ide értve a futtató infrastruktúrát, felhasznált keretrendszereket, a forráskódokat és a konfigurációs fájlokat is. Ezen ismeretekkel a szakértőink egy belsős kompromittálási kísérletet is megelőzhetnek, megakadályozhatnak.

Static Application Security Testing (SAST)

A szoftver forráskódjának vagy binárisának biztonsági vizsgálata annak aktív futtatása nélkül. Ebben a vizsgálati stratégiában kizárólag azok a sérülékenységek kerülnek beazonosításra, amik a forráskódból, vagy a bináris fájlból kiderül.

Mikor ajánlott: Ha a vizsgált szoftver programozásának és konfigurációjának biztonsági hiányosságait keressük.

Dynamic Application Security Testing (DAST)

Ebben a vizsgálati stratégiában azok a sérülékenységek kerülnek beazonosításra, amik az aktív működésből, használatból derülhetnek ki. A mélyebb rétegeket, esetleg forráskód szintű sebezhetőségek beazonosítására nem mindig megfelelő.

Mikor ajánlott: Ha a vizsgált szoftver éles támadási felületeit akarjuk beazonosítani, külsős támadóként.

Interactive Application Security Testing (IAST)

Ötvözi a statikus és a dinamikus vizsgálatok jellemzőit. Egy kifinomult, célzott támadásnál a felkészült támadók is ennek a stratégiának megfelelően felépített taktikával derítik ki a szoftverek, rendszerek és szolgáltatások támadható sebezhetőségeit.

Mikor ajánlott: Ha a vizsgált szoftver teljes körű biztonsági felülvizsgálatára van szükség, külsős és belsős oldalról.

Tárgy

Hálózati

A hálózati sérülékenységvizsgálat és penetrációs teszt során L3-L4 hálózati rétegeken teszteljük a vizsgálat hatókörébe sorolt hosztokat. Megvizsgáljuk, hogy mely portok vannak nyitva, azokon milyen szolgáltatások futnak, majd szolgáltatásspecifikus tesztekkel és teszteszközökkel azonosítjuk be az potenciális sérülékenységeket.

Oprendszer

Az operációs rendszer és firmware szintű biztonsági audit során ellenőrizzük a rendszerbeállításokat, korlátozásokat, a jogosultságkezelés megfelelőségét, a futtatott szoftvereket, azok frissítési állapotát, konfigurációs hiányosságait, a kártékony kód elleni védelmet, az alkalmazott titkosítási eljárásokat, valamint a futtatott szolgáltatások védettségét a támadásokkal szemben.

Alkalmazás

Ebbe a kategóriába egyaránt sorolhatók a hagyományos szoftverek, a webalkalmazások, webes szolgáltatások, a mobilalkalmazások, kiszolgálói szoftverek, vezérlőrendszoftverek, de esetenként még a beágyazott rendszerek is. A vizsgálat tárgyának megfelelő, nemzetközileg is elfogadott módszertanokat és/vagy ajánlásokat alkalmazunk és tételesen ellenőrizzük a megfelelőséget – statikus és dinamikus módon.

Vezeték nélküli

A fizikai helyszíni vizsgálat részeként a vezeték nélküli hálózatok konfigurációjának biztonsági szemléletű tesztelése, ellenőrzése is elvégzésre kerül.

Fizikai

A fizikai vizsgálat során ellenőrizzük a vizsgálat tárgyának fizikai biztonságát (portok, bontás elleni védelem stb.), annak fizikai környezetét (hozzáférhetőség, tűzvédelem, vízbetörés elleni védelem stb.), valamint a kapcsolódó szabályzásokat és eljárásrendeket.

Social engineering

A social engineeringgel a humán eredetű sérülékenységek beazonosítása a cél. A vizsgálat egyaránt tartalmaz adathalász (phishing), manipuláns és célzott személyi adatgyűjtés technikákat is, amelyeket minden szempontból részletesen mérünk és dokumentálunk.

Kiindulás

Belső hálózaton

Gyakran keverik a gray-box vizsgálattal, de valójában belső hálózaton is lehetséges black-box vizsgálat végrehajtása. A belső hálózati vizsgálat tehát azt jelenti, hogy a vizsgálatot végző rendszer közvetlenül vagy VPN-nel a belső hálózathoz csatlakozik, így nem egy hálózati határ korlátozásai mellett látja a vizsgálat hatókörét.

Külső hálózatról

A külső hálózati (a legtöbb esetben internetes) irányból végzett vizsgálat során a vizsgálatot végző rendszer a hálózati határ korlátozásai és védelme mellett látja a vizsgálat hatókörét.

Helyszínen

A fizikai helyszíni vizsgálat a szervezet kiválasztott telephelyeinek biztonsága kerül ellenőrzésre. Ide tartozik a beléptetés, a tűzvédelem, a vízbetörés elleni védelem, a georedundancia, a menekülési útvonalak, a fizikai hosztok hozzáférhetősége és kompromittálhatósága.

Forráskódon

A forráskód szintű vizsgálat során olyan sebezhetőségek is beazonosításra kerülhetnek egy adott szoftverben, amik dinamikus vizsgálat esetén nem feltétlenül jelenhetnek meg korlátozott időablakban.

Intenzitás

Passzív

Nem minden vizsgálati módnál értelmezhető, de a hagyományos értelemben vett hálózati és alkalmazásszintű sérülékenységvizsgálat, esetleg social engineering vizsgálat szakaszában a vizsgálatot végző szakértő nem kapcsolódik a megbízó szervezet rendszereihez, helyette más forrásokból szerzi az információkat.

Óvatos

Nem minden vizsgálati módnál értelmezhető, de a hagyományos értelemben vett hálózati és alkalmazásszintű sérülékenységvizsgálat, esetleg social engineering vizsgálat szakaszában a vizsgálatot végző szakértő ugyan kapcsolódik a megbízó szervezet rendszereihez, de azt teljesen legitim felhasználói tevékenységgel, nem feltűnő vagy riasztandó módon teszi.

Számító

Számító vizsgálati intenzitás esetén a vizsgálatot végző szakértő már kitapasztalta a védelmi megoldások szabályait, így azok érzékenysége alatt igyekszik maradni.

Agresszív

Az agresszív intenzitás során a vizsgált szervezet tisztában van a vizsgálat tényével és nem cél a védekezőképesség érzékenységének tesztelése, kizárólag a sebezhetőségek beazonosítása.

Megközelítés

Rejtett

A védekezőképesség teszteléséhez az is hozzá tartozik, hogy a vizsgálatot végző szakértő lehető legészrevétlenebb maradjon. Amennyiben a reális óvatosság mellett is lebukik és kitiltásra kerül a rendszerből vagy szolgáltatásból, a védelem megfelelően működik.

Nyílt

A nyílt megközelítésű vizsgálat során minden érintett tisztában van a vizsgálat tényével és szükség esetén támogatják annak lebonyolítását a vizsgálat időablakán belül.

Hatókör

Koncentrált

Koncentrált hatókör esetén a vizsgálat tárgya kizárólag egyetlen rendszerre, szolgáltatásra, funkcióra, helyszínre vagy emberre korlátozódik, minden egyéb komponens vagy környezet figyelmen kívül hagyásra kerül.

Korlátozott

A korlátozott hatókör esetén a vizsgálat tárgya több rendszerre, szolgáltatásra, funkcióra, helyszínre vagy emberre korlátozódik, a kiválasztás lehet teljesen kötetlen vagy technikai és tematikus megközelítésű is.

Teljes

A teljes hatókör esetén nincs semmilyen korlátozás, a vizsgálatot végző szakértők minden lehetőséget kihasználhatnak és eszközt felhasználhatnak.

Kapcsolódó szolgáltatások és termékek