Támadás szimuláció vagy etikus hackelés?

Jobb félni, mint megijedni, ugye? A vállalatok jelentős mennyiségű forrást csoportosítanak a kibervédelmi stratégiájuk felépítésére és tökéletesítésére. A vészhelyzetek, kibertámadások egyre szofisztikáltabb formában való megjelenésével és fejlődésével párhuzamosan a védelmi stratégiákba való befektetések is drasztikusan növekedni kényszerülnek. A Cybersecurity Ventures riportja szerint, világszinten, az információbiztonsági termékekre és szolgáltatásokra költött kiadások, 2017-2021 között, meghaladják majd az 1 trillió dollárt.

Tudjuk, hogy a megelőző és feltáró ellenőrzések nagyon fontosak, ám ezeknek az ellenőrzéseknek a validálása is nélkülözhetetlen. Mivel a biztonsági tesztelések táplálják a gyors növekedést, ezért az ágazat, a piaci becslések alapján, 4 milliárd dolláros piaccá is kinőheti magát.

A cybert is tesztelni kell, mint minden mást!

Egyszerű matek. Minden biztonsági rendszernek, aminek konfigurációs pontjai vannak, valószínűsíthetően van emberi erőforrásból és téves konfigurációból származó hibája. Minden alkalmazás és operációs rendszer rendelkezik sérülékenységgel. Ahogy az IT hálózatok növekednek, bővülnek, növekszik a vezérlők és a sérülékenységek félrekonfigurálásának a lehetősége és az operációs összetettségük is. A CIO-k és a CISO-k elismerik, hogy szükség van biztonsági validálásra, kvázi rá is vannak kényszerülve, hogy rendszeresen teszteljék, teszteltessék a sérülékenységet third-party felek penetrációs tesztjeivel.

2 alternatíva közül is választhatsz, ám egyik sem tökéletes!

A vunerability assessment (VA) és menedzsment (VM) megoldások szoftveresen támogatottak, de a feltárt sérülékenységek priorizálása nélkül nem elég hatékonyak. Több ezernyi sérülékenységet listáznak ki, ám a valóságban ezek nagytöbbsége fals riasztás. A valós sérülékenységek mindössze 5 százaléka fedezhető fel így és ezek közül is csak néhány vezet olyan támadásokhoz, ami kritikus eszközök ellen irányul. Egyszerűbben fogalmazva: egyetlen lehetősége van annak, aki biztosra akar menni és be akarja bizonyítani, hogy a feltárt sebezhetőség valóban kritikus jelentőséggel bír, mégpedig az, hogy a teljes “kill-chain” láncolaton végighalad és bizonyítja, hogy annak része.

A szolgáltatás alapú penetrációs tesztelés egyik ismert jellemzője, hogy miközben teszteli a védelmi rendszert összeveti a  sérülékenységeket a ténylegesen létező exploitokkal, ám teszi mindezt a megfelelő biztonsági ellenőrzés nélküli.

Néhány pentesztelő képes fontos hiányosságokra is rámutatni, olyanokra, amelyek viszont már inaktív támadási vektorokhoz köthetőek. Ám a manapság használt pentesztelési formák sajnos nem méretezhetőek: drágák, erősen függenek attól, hogy aki csinálja mennyire tehetséges benne, ráadásul térben és időben is korlátozott. Ezért fordulhat még ma is elő az, hogy a penteszteket általában csak az infrastruktúrák kisebb részén végzik el, azokon, melyek az üzletmenet szempontjából a legkritikusabbnak bizonyulnak, így hagyva a támadási felület amúgy nagy részét ellenőrizetlenül.

A támadás és feltörés szimuláció (breach and attack simulation – BAS) túlsztárolása

A támadás és feltörés szimulációs technológia 3 évvel ezelőtt robbant be az életünkbe és nagy reményeket fűztek hozzá a folyamatos biztonsági kontrollok validálása kapcsán. Zseniálisan hangzott anno, ám akik már az elsők között alkalmazni kezdték mind arról számoltak be, hogy ebben a rendszerben is új agenteket kellett hozzáadni a hálózathoz, akiknek hatáskörét csökkenteni kell, az ellenőrizhetőség megőrzése érdekében, illetve spéci playbook forgatókönyvekre van szükség a fenntarthatósághoz.

De ennél is lényegesebb az, hogy a felhasználók újra a szimuláció világában találták magukat. A BAS tehát a biztonsági adatok gyűjtéséről és az offline kockázatmodellezési elemzés elvégzéséről és nem a tesztelésről szól. Mivel csak következtetéseket von le, hogy mi történne a valós életben. A felhasználók ismét fals riasztásokat kaphatnak és téves priorizációkat állíthatnak fel ez alapján.

Ha tesztelni akarsz, akkor tesztelj és ne szimulációt csinálj!

Egy igazi biztonsági ellenőrzési folyamat arról kell szóljon, hogy egy hacker szemszögéből nézve és technikájának teljes tárházát felhasználva felmérjük az egész hálózatot a biztonsági rendszer megkérdőjelezésétől kezdve egészen a végpontok vizsgálatáig kiterjedően. Mi lenne, ha olyan penetrációs tesztet tudnánk lefuttatni, ami teljesen automatizált, agent nélküli, mellőzi a manuális forgatókönyveket, nincs benne szimuláció és fals riasztásoktól mentes? Mi lenne, ha egy olyan rendszerben tesztelhetnénk, amit egy hacker is használ, azaz mindent górcső alá vehetnénk és támadás alá vonhatnánk – kezdve a biztonsági ellenőrzésekkel, a sérülékenységekkel, a hitelesítő adatokkal vagy privilegizált hozzáférésekkel? Mi lenne, ha ugyanaz a rendszer térképezné fel a jelszavakat, a hitelesítő adatokat a megosztott mappákban és office dokumentumokban?

Amit valójában keresünk azok a sérülékenységgel összefüggésbe hozható exploitok, amelyek nincsenek átfogó, átlátható kontroll alatt.

Arra kell törekednünk, hogy pontosan ezeket a gyengeségeket fedezzük fel mindenféle rosszindulatú szándék vagy károkozás nélkül. Mindezt persze olyan költségen, ami lehetővé teszi számunkra, hogy naponta vagy hetente tesztelhessünk. Elsőre megugorhatatlannak hangzik, ugye?

Az automatizált pentesztelésé a jövő!

Ez az új technológia magasabb szintre emeli a szoftverekben rejlő erő kiaknázását, miszerint képes elvégezni az etikus hackeri feladatokat a penetrációs tesztelés során. Semmi más nem kell hozzá csak hálózati hozzáférés, mert az új technológia minden olyan folyamatot elvégez, amit egy hacker is tenne, ha behatolást tervez egy rendszerbe: szkennel, felderít, információt gyűjt, hamisít, feltör, (ártalmatlan) malware-eket juttat be, file nélküli expoitokat modellez, utólagos exploitokat, oldalirányú mozgást végez és privilegizált betöréseket hajt végre egészen addig, míg el nem jut az adatok megszerezhetőségéig.

Ennek az új technológiának köszönhetően az információbiztonsági szakemberek rutinjai is megváltoznak. Gondoljatok bele abba a világba, ahol csak hetente kell tesztelni, ráadásul csökken a third-party felektől való függőség, sőt nem kell arra az 1%-os remediációra fókuszálni, ami számítana.

Választás kérdése

Eljött hát végre az ideje a kiberbiztonsági kockázat validációnak. El kell dönteni, hogy milyen módon kezeljük a biztonsági rések felderítését.

Választhatod, hogy különféle eszközökkel és szolgáltatókkal végezteted el a munkát, illetve választhatod azt is, hogy saját magad csinálod egy modern pentesztelő platformmal. Nincs fontosabb a fejlődésnél! Hogy mi kellene legyen a fókusz? 1. Hogy képesek legyünk üzleti szempontból csökkenteni a biztonsági kockázatot egy fejlettebb menedzsment gyakorlattal. 2. Hogy meglegyen a szükséges költségvetésünk a védekezésre. 3. Hogy folyamatos fejlődést járhassunk be kibervédelmi szempontból is.

A Pentera a Psycys-től (itt olvashatsz róla többet) pontosan ezt tudja. Kérdezd meg tőlünk, vagy demózzunk egyet. Kattints az alábbi gombra, hogy egyeztessünk!