A behatolási tesztelés helye az informatikabiztonsági stratégiában

Egy rövid szakmai időutazással belepillanthatunk, hogy az elmúlt években hogyan fejlődött (vagy fejlődött vissza) a behatolási tesztelés (penetration testing). Milyen problémák vannak a mai napig a szakmában, és hogyan lehetne ezeket a bajokat kezelni.

A kezdetektől

Az alkalmazásbiztonsági tesztektől eltérően a hálózati behatolás tesztelése témájában már petabájtnyi adat került feldolgozásra a 90-es évek óta, ám ennek az üzleti oldalról való megközelítésében még komoly hiányosságok vannak a megtérülést illetően.

Hogy némi időt spóroljak az olvasónak: ha a biztonságot illetően az aggodalma pusztán megfelelési kényszer, akkor szükségtelen tovább olvasni.

Visszatérve a hálózati tesztelés születésének idejéhez, mint monetizált szolgáltatás, a 90-es évek közepe és vége között egy átmeneti időszakon haladtunk át, ahol jó alapképességekkel rendelkeztek, viszont a management minden más téren értékelhetetlen volt. Ám ez távolról sem tükrözte az egyéni megmozdulások minőségét.

Ebben az időben a modern tesztelési metodikának és körülményeknek köszönhetően a teszteket végző analitikusok nincsenek motiválva, hogy elmélyítsék, bővítsék az analitikai ismereteiket. A managerek esetén pedig az iparág részéről nincs megkövetelve az olyan managerek alkalmazása, akik technika-központú informatikabiztonsági ismeretekkel rendelkeznek. Az iparág még igen fiatal volt, így hibákat is vétett.

Bajok a managementben

Egyvalami azonban tartósan jelen volt az iparág fiatalabb éveiben: a rossz minőségű management. A hálózati behatolási tesztelés révén a minőségi analitikus készségek hanyatlása minden téren jelen volt, eltekintve a nívósabb területektől (és a sötét oldaltól). Ez pedig nagyban köszönhető a rossz managementnek. És mint korábban, itt is a csorda-mentalitás és a hanyatló üzletág tükröződött az egyének helyett.

A managereknek meg kell találniuk a megfelelő egyensúlyt az üzleti éleslátás és a technológiai kockázatok ismerete között, ám a biztonsági területen többségünk úgy vélte, hogy megfelelő olyan managereket alkalmazni, akik a mérleg üzleti része felé hajlanak.

A kétezres évek elején számos változás történt a szolgáltatóiparban. Ezek egyike a tesztelési korlátozások bevezetése volt, mely nagyban csökkentette a tesztelés hatékonyságát. Amikor pedig az analitikusok kifejtették ennek negatív hatásait (mint a limitált IP-tartományok tesztelése, sebezhetőségek korlátozott kihasználási lehetősége éles környezetben, és fix forrású IP-tartományok), akkor a mondandójukat vagy félreértelmezték a managerek, vagy pedig rosszul közvetítették a korlátozásokat bevezető kliensek felé.

Így tehát maradtak a tiltások. És az ilyen szorosan korlátozott behatolási tesztek még csak a közelébe sem érhettek egy szimulált támadásnak, vagy akár egy alapszintű tesztnek.

A másik tényező a fejlesztett tűzfal-konfigurációk voltak. A hálózati biztonság egyik jelentős szegmense, ami a 90-es évek közepétől napjainkig fejlődik, az a tűzfal-konfiguráció. A fejlesztett tűzfal-konfigurációkkal csökkentek a támadási csatornák, ám a tesztelési korlátozásoknak nagy hatása volt a távoli tesztelési szolgáltatások vélt értékére. A fejlettebb tűzfalak részben a korábbi behatolási tesztek eredményei alapján készülhettek el, de a tiltások a tesztelési megbízások elnyerését egy igazságtalan harccá fordították.

Korlátozások

A kétezres évek elején nagyobb erők is munkálkodtak a világban, amik szintén hozzájárultak a behatolási tesztek minőségi romlásához, ám ezek nem jelen cikkbe tartoznak. Minden próbálkozás ellenére a behatolási tesztelés olyan alacsony színvonalú szolgáltatássá vált, hogy a kliensek inkább nem is áldoztak rá, hacsak nem kötelezte őket ilyen vizsgálatok lefolytatására „egy független harmadik fél” – és ezek voltak azok az esetek, ahol a kliens nem sokat adott a minőségre.

Az érdeklődés ilyen mértékű hiánya odáig vezetett, hogy egyes szolgáltatók már megrovásban részesítették az analitikusaikat, mert azok megpróbáltak analitikusan gondolkodni. Mindezt miért? Mert az analitikusság egy alaposabb munka, amihez pedig csökkenteni kell a költségeket, Így váltak a vállalkozások rossz minőségű behatolási tesztek szolgáltatóivá.

Mostanáig már eleget beszéltem a problémákról és azok kialakulásáról. Az igazat megvallva nem én vagyok az egyetlen, akinek feltűntek ezek a problémák, csupán manapság már kevés olyan ember van, aki még behatolási tesztelő volt a 90-es években és tollat ragadna, hogy ezeket a problémákat papírra vesse.

Mostanra már bizonyára világossá vált, hogy a behatolási tesztelés a korlátozások révén pusztán annyi értéket képviselt, ami a vizsgálaton való megfelelésből adódott. És mi is volt ez? Egy portvizsgálat. Ezen kívül? A legtöbb esetben semmi.

Nagymértékű az automatizált eszközök használata, és az ilyen eszközök, mint a sebezhetőségi szkenner, sose volt több egy egekig magasztalt portszkennernél. Ez nem az értékesítők rossz munkájából adódott (bár volt, amikor igen), hanem a távoli ellenőrizetlen sebezhetőségi értékelések természetéből – ahol szinte lehetetlen volt bármit is megtudni a célpontról, a portszkennelést és néhány reklám bannert leszámítva.

De… talán a 2010-ben jelentett incidensek áradatával (amik túlnyomóan már a 2000-es évek óta jelen voltak) már lehet némi motiváció a vizsgálatokon való megfelelésre, és adni emelléi valami mást is a befektetések viszonzásaképpen.

Ehhez a beszélgetéshez utópisztikus állapotokat kell feltételeznünk. Minden, ami nem korlátozás nélküli tesztelés (ami magába foglalja a nulladik napot is – egy terjedelmes téma, amit most félreteszek), és nem magasan képzett tesztelők végzik (szinte hacker szintű készségekkel, de nem feltétlenül hackerek), az mindenkor kivétel nélküli időpocsékolás lesz.

Tudásmenedzsment

A kulcs itt a belső IT és biztonsági személyzet ismerete lesz a tesztelés alatt álló célhálózatot illetően.

Szó szerint mindent tudniuk kell a hálózatukról – ismerniük kell minden zegzugát, minden routerét, tűzfalát, alkalmazását, OS-ét, és ezek együttes kapcsolatot. A behatolási teszt sosem helyettesítheti ezt a tudást. Tapasztalatom szerint a tipikus tesztelési megbízásokat 3-4 analitikus végzi egy maximum 2 hetes intervallumban.

Ez az idő nem elég arra, hogy egy külsős csoportnak megtanítsák mindazt, amit a belső privát hálózatról tudniuk kell. Ilyen esetekben még 1000 ilyen jellegű teszt is elégtelen lenne.

Abban az esetben, ha a kliens és a tesztelők is kellően felkészültek, megvan rá az esély, hogy egy alap szintű vizsgálaton jó eredményt érjenek el.

És egy ilyen körülmények között zajló teszt során talán még a legkisebb rést is megtalálhatjuk a pajzson – olyan területeken, melyek felett a megbízó IT és biztonsági csapata talán elsiklott – egy hibás konfigurációt, nem engedélyezett változást, egy korábban nem észlelt probléma jeleit, egy eddig ismeretlen helyi jogosultsági vektor eszkalációját. De a legfontosabb, hogy a legtöbb esetben nem lesz olyan fehér zaj, amellyel akkor találkozhatunk, ha komoly hiányosságok vannak a hálózatban.

Ez utóbbi körülmények esetén a teszt értéket is hordoz magában, ám az eredmények megtévesztőek lehetnek.

Megváltozott a helyszín

A felhasználói munkaállomások alhálózatait sokan joggal tekinthetik a rossz fiúk által kontrollált területnek, ugyanis immár az RFC 1918 által leírt privát névtérben vagyunk. Így már előtérbe kerülhet a belső munkaállomások alhálózatát érintő kritikus infrastruktúra behatolási tesztelése is. Ám ismételten a belső konfigurációk és szabályozások ismeretének hiányában ez kevés lesz.

Bármilyen erőforrásokat is áldoztak egy külső, harmadik fél általi behatolási tesztre, az pusztán időpocsékolás, ha nincsenek kellően tisztában a tesztalany belső hálózatával. Részletes ismeretekkel kell rendelkezni a rendelkezésre álló OS-t és az adatbázis biztonsági beállításait illetően, és hogy azok milyen szinteken lettek alkalmazva. Alkalmazásbiztonság – egy másik napra való történet, ami nincs is nagy hatással az itt levont következtetésemre.

Na persze akad egy tátongó lyuk a történetben. Említettem a képzettség szintjét, a behatolási teszt analitikust és a tesztalany oldalán dolgozó analitikust illetően. De honnan tudjuk, hogy ki alkalmas, és ki nem?
Nos, ez minden probléma gyökere. E nélkül nincs meg a bizalom. A megfelelő, munkára alkalmas akkreditációs struktúra nélkül a tesztelők semmi érdemlegeset nem fognak találni, minek következtében bohócot csinálnak magukból.
Hiszik vagy sem, van erre egy roppant egyszerű megoldás. De ez túl terjedelmes téma lenne ahhoz, hogy itt kifejtsem. Majd legközelebb!

Szerző: Ian Tibble