Hálózati forgalmon alapuló threat hunting: így vadásszuk le a támadóinkat

Biztosan mindenki szeme előtt ott lebegnek a különféle “hackeres” filmek jelenetei, ahol a furfangos kiberbűnözők a képernyőn villámgyorsan tovaszaladó parancssori utasítások és IP címek előtt görnyedve igyekeznek bejutni a több ezer bites titkosítással védett kormányzati és hadászati giga rendszerekbe, hogy hozzáférjenek a világpusztító csodafegyvert működésbe hozó piros Start gombhoz a képernyő közepén. Aztán a főhős az egész folyamatot megszakítja pár villámgyors billentyű leütéssel, de előtte azért percekig nézhetjük a folyamatjelzőt és a visszaszámlálást, ami persze mindig az utolsó másodpercnél áll le.
Dacára annak, hogy Hollywood általában erősen eltúlozza a kiberbiztonsággal kapcsolatos jeleneteket, azért a valóságban is akadnak izgalmak. Nem kell, hogy csodafegyverek tervrajzairól legyen szó. Elég, ha egy átlagos vállalat érzékeny adatait szerzik meg a kevésbé dörzsölt, viszont a filmes rossz fiúhoz hasonlóan pénzéhes bűnözők. Olykor egy ilyen hétköznapinak tűnő esetben is virtuális vadászat indulhat, s olykor ez is hasonlóan izgalmas tud lenni, mint a filmeken. A vállalatok számára pedig arányait tekintve lehet olyan mértékű a tét, mintha a világ összeomlását kellene megakadályozni.

Threat hunting: virtuális vadászat

Arra gondoltam, ezúttal nem merülünk el a technikai megoldások mélységes bugyraiban, inkább csak pár példán keresztül megvilágítom, miért is olyan fontos a threat hunting egy SOC és egy vállalat szempontjából. Miként segíthet az üzletmenet-folytonosság fenntartásában.
Kezdjük ott, hogy a threat hunting a SOC-ok detekciós funkcionalitását képes erősíteni, fejleszteni, elősegíteve ezzel a kockázatkezelést. Ez egyszerű ok okozati összefüggés: ahhoz, hogy biztosíthassuk az üzletmenet-folytonosságot, tisztában kell lennünk a kockázatokkal.
Ez két irányból közelíthető meg. Az egyik a detektálás, vagyis a kiberbiztonsági események észlelése, felkutatása a rendszerben. A másik a válaszadás, vagyis annak módja, ahogyan az adott eseményekre reagálunk. Ezúttal a detektálási folyamattal szeretnék foglalkozni.

Nyomozzunk megfelelő módszerrel

A biztonsági problémák detektálása történhet proaktív vagy reaktív módon. Utóbbi esetében egy már korábbról ismert fenyegetést igyekszünk megtalálni a rendszerben. Ez általában azt jelenti, hogy már ismert szignatúrák, mintázatok birtokában vizsgáljuk a rendszert, ami ugyebár nagyrészt automatizálható a SOC-on belül. Nyilván a fals pozitív riasztások esetében nem ússzuk meg a humán erőforrás bevetését ilyenkor sem, hiszen azokat ki kell elemezni és tisztázni, hogy valódi fenyegetést jelentenek-e.
Ha egy támadó kihasznál egy “zero day” sérülékenységet, amiről nem tudtunk, akkor jó esélye van, hogy észrevétlenül beköltözzön a rendszerünkbe, s ellakjon ott egy ideig hívatlan albérlőként. Mivel nem ismertük a támadási lehetőséget, így nem sikerült kivédenünk. Ráadásul amíg nem tudunk róla, a támadó kedvére ténykedhet a rendszerben.
Ilyenkor jöhet jól a proaktív technika, amely nem megelőzni próbálja a bajt, hanem – kicsit paranoiás módon – úgy veszi, hogy már megtörtént. Vagyis van egy-két kéretlen vendégünk, akiket be kell azonosítani, majd ha bebizonyosodott, hogy senki nem hívta őket és csak kárt okoznak, akkor azonnal kipaterolni. Ilyenkor jön a threat hunting, ami a nevéhez hűen tényleg a vadászatra emlékeztet: rátermett vadászként nem a csapda mellett üldögélünk és várjuk a zsákmányt, hanem felkerekedünk és elkezdjük átkutatni az odúkat, ahová bevackolhatta magát.

A kiberbiztonság nyelvére fordítva ez annyit tesz, hogy fogjuk az összes adatot, amelyeket a rendszer begyűjtött (hálózati forgalom, naplók, végpontvédelmi adatok stb.) és elkezdjük ezeket szisztematikusan átfésülni. Protokollról protokollra, forgalom irányától függően kifelé-befelé, átnézve a technikai aspektusokat, igyekszünk észrevenni az olyan anomáliákat, mint mondjuk egy furán festő domain név. Például ha feltűnik egy G00gle nevű domain, van okunk gyanakodni, hogy valaki a Google utánzásával igyekszik elrejtőzni a szemünk elől.
A másik eset, amikor feltételezünk egy konkrét támadási technikát, és annak jellemzőit kezdjük felkutatni a hálózatban. Egy webshell esetében például tudhatjuk, hogy milyen árulkodó jeleket kell keresnünk a logokban, a hálózati forgalomban, a végpontokon.
Ha nem találunk semmit, akkor sem felesleges az ilyen típusú keresés, mert menet közben seregnyi elrontott konfigurációba, rossz beállításba ütközhetünk, amelyek esetleg elkerülhették a mérnökök, rendszerépítők figyelmét, így legalább nekik tudjuk jelezni a beazonosított konfigurációs problémákat. Ez is van olyan fontos, mint a védekezés, s amúgy sem árt, ha támogatjuk egymást a cégen belül. Ezzel is erősítjük a teljes infrastruktúrát.

Maga a folyamat amúgy nem feltétlenül olyan izgalmas, mint a filmeken: az ember felállítja a kis hipotéziseit, majd ennek megfelelően elkezdi a kutatást, és menet közben minden gyanús vagy szokatlan dolgot feljegyez: IP címek, domain nevek, toolok stb. Az ilyen feljegyzésekre lehet aztán ráépíteni később a reaktív védelmi mechanizmusokat, s javítani a rendszer detekciós képességeit. Ily módon a proaktív folyamat fejlesztheti a reaktív folyamatokat is.
Kicsit olyan ez, mint a régi aranyásók módszere: merítünk a folyó egyes részein, míg végül az aranyrögök fennakadnak a rostán. Ha nem találunk semmit egy helyen, megyünk a következőre. Szisztematikusan végignézzük az egészet.
Bár egyhangúan hangzik, megvan a maga szépsége és izgalma a dolognak, még akkor is, ha az ember – szerencsére – nem akad minden nap bele valamilyen WannaCry-szerű fenyegetésbe. Nekem legutóbb egy WordPress sérülékenységet kihasználni igyekvő támadás került a célkeresztbe. Feltűnt egy mintázat, ami gyanús volt, s egyszerűen a Google-ban sikerült rátalálnom, milyen próbálkozásról van szó, majd befoltozni a rést a pajzson. Ilyenekből jellemzően több is előfordulhat, mert sok cégnél nem igazán adnak a WordPress és kiegészítőinek naprakészen tartására, a hibajavítások, biztonsági frissítések telepítésére.

Naplók ellenőrzése vagy folyamatos figyelés

Eszembe jut ezzel kapcsolatban még egy példa. Ha egy bank elé felszerelünk egy CCTV kamerát, amely a nap 24 órájában rögzíti az eseményeket, jó esélyünk van rá, hogy ha bankrablás történik, a felvételek visszanézésével felgöngyölíthessük az ügyet. Ez a fajta odafigyelés a kiberbiztonság területén is célravezetőbb, mintha mindig csak a log fájlokat elemeznénk utólag, hiszen azokba nem mindig kerül bele minden esemény. Van, hogy a rendszert konfigurálók kapcsolják ki bizonyos – számukra lényegtelennek tűnő – események naplózását, s van, hogy egy-egy program hiányosságai miatt nem kerülnek rögzítésre dolgok. Ha minden eseményt rögzítünk, pontos képet kapunk utólag is a kritikus történésekről.
Ha például a támadók küldenek egy adathalász levelet benne egy dokumentummal, amelyet a felhasználó gyanútlanul megnyit, s amely elindít egy szkripet, ami letölt és telepít egy malware-t, akkor egy komplett, rendszerszintű folyamaton vagyunk túl. Ha ezt teljes egészében sikerült rögzítenünk, akkor még ha – bármilyen okból – nem is sikerült megakadályoznunk a támadást, de legalább van esélyünk időben felfedezni a nyomait, és megtenni a szükséges intézkedéseket.

Szignatúra vs viselkedéselemzés

Lassan a végére érek a példabeszédnek, de azért egy valamit még érdemes tudni: a végpontvédelem esetében a hagyományos vírusirtók szignatúra és mintázat azonosítási megoldása teljesen más hatásfokkal működik, mintha viselkedés alapon monitorozzuk az esetleges kártevőket. Ezt is érdemes mérlegelni a védelem rétegeinek felépítésekor.

Összegzésül

Mindent egybevetve tehát a threat hunting egy igen értékes, hasznos folyamat, amelynek bevezetését mi minden vállalat esetében javasoljuk. Éppúgy segíthet a megelőzésben, mint a baj megtörténte utáni kármentésben. A folyamatos vadászat az ismeretlen támadások után, és az ismert mintázatok beazonosítása együtt jóval nagyobb védelmet nyújt, mintha csak az egyik eszközzel élünk a védelem kialakításakor.