Nem szoktam olvasni a Piac és Profitot, viszont most a szemem elé került egy cikk a nevezett online médiából, amely azt állítja, hogy „az IT döntéshozók 20 százaléka úgy nyilatkozott, hogy a legutóbbi, szervezetüket ért támadás során a támadók nem hagytak semmilyen nyomot magukról”.

Később Tóth Árpád, a Kaspersky Lab képviselet-vezető szavait idézik: „– A kutatás eredményei alátámasztanak egy másik – a kiberbiztonsági iparág által már régóta hangoztatott – tendenciát is, miszerint a támadók csak nagyon kevés vagy semmilyen nyom hátrahagyásával jutnak be a szervezetbe, és ezzel pedig egyre nehezebbé teszik a vizsgálatokat.”

Ez láthatóan nem lehet igaz, még a Google se tud olyanról, hogy a támadó nem hagy nyomot :) A hekker ugyanis nem rúzs, nem alapozó, és nem gyurma. Még kevésbé úszószemüveg.

Véleményem szerint ezek a kijelentések csak az érme egyik oldalát villantják fel, és tökéletesen alkalmasak a „kíberbűnözők” misztifikálására, elfedik a valóságot: a nyomok „eltüntetéséért” a legtöbb esetben maguk a szervezetek a felelősek.

A volt-nincs naplózás

Sok esetben a nyomokat el sem kell tüntetni, mivel a rendszerek biztonsági naplózása rosszul van beállítva, vagy eleve nem naplózzák, amit kell.

A biztonsági eszközök (tűzfalak, stb.) tartalmaznak valamilyen adattárolót, amelyre mentődnek a naplóesemények – azonban a tárkapacitásuk nem végtelen, ezért a naplóállományok bizonyos időnként, vagy a tárkapacitás függvényében automatikusan törlődnek – pontosabban felülíródnak.

Ez azt jelenti, lehet, hogy az észlelt esemény naplózásra került – csak pl. másnapra már felülíródik, azaz a nyomelemzés (forensic) számára már nem használható forrásként, mivel felülíródott. (Az is lehet, hogy 1 hétig rendelkezésre állnak a naplók az eszközön, csak mire az eseményről tudomást szerez a szervezet, és megkezdené a vizsgálatot, már felülíródtak és nem állnak rendelkezésre.)

A Windows eszközökön is állíthatók a naplóállományok részletessége, méretük, illetve, a megőrzésük rendje, azonban sajnos többnyire ezeket sem állítják be jól, és amikor szükséges lenne belenézni a naplókba, addigra azok már régen törlődtek („ez a sok szar csak foglalja a helyet”). A napló olyan, mint egy jó ügyvéd: ritkán van rá szükség, de akkor viszont nagyon.

Kisvak, nagyvak, félvak

A logolás másik problémája, hogy néha nem logoljuk amit kell. Erre a legjobb példa a tűzfal, ahol a legtöbb esetben csak az olyan eseményeket logolják, amelyeket a tűzfal elhárít, az üzemszerű (vagy látszólag üzemszerű) eseményeket, kommunikációkat nem naplózzák.

Ennek a legfőbb oka megint csak a biztonsági eszközök naplótárolási módszerében kereshető: mivel limitált kapacitással rendelkezik az eszköz, ezért az üzemszerű (ALLOWED) kommunikációt és eseményeket nem naplózzák, mivel pillanatok alatt betelne a tároló. Ez aztán különösen igaz a bentről kiefelé menő, a felhasználói eszközökről történő adatforgalmak naplózására: jellemzően nem logolódik a forgalom, így aztán egy bejutott támadó (szabályrendszerbe nem ütköző) kommunikációja sem kerül mentésre.

Ez nyomvizsgálati oldalról azzal jár, hogy egy sikeres behatolás nyomai (mivel azok végül is üzemszerűnek tűnnek a rendszer számára, mint ALLOWED kommunikáció) nem látszanak, és a rendszer félvak. Vagy optimista szempontból félig látó.

(Egyszerű példa: ha egy bejutott támadó adatokat küld ki FTP-n keresztül, és az FTP kommunikáció engedélyezett, ezért nem naplózott – nem fogjuk látni, hogy adatot vitt el)

De így van ez a belső hálózatban is, ha a rendszerek csak azt naplózzák, amit a szabályrendszer tilt, egy behatolás után a támadó mozgása sem fog látszódni, ha a mozgást olyan módon követi el, amely a rendszer számára üzemszerűnek tűnik (pl. felcsatol egy hálózati mappát, megnyit egy állományt, stb).

Igaz ehhez az is kell, hogy az első pontban kifejtett volt-nincs naplózás szerint a legtöbb szervezet nem kapcsolja be pl. a Windows szerverek audit naplózását, azaz olyan naplózási módját, amellyel a rendszer tényleg minden (vagy a lehető legtöbb) bekövetkező eseményről és műveletről naplóbejegyzést készítene.

Így aztán amikor nyomvizsgálatra kerül a sor, az olyan eseményekről, amelyeket a védelmi rendszerek hárítottak vagy blokkoltak rendelkezésre áll egy csomó adat – azonban arról, hogy valójában mit csinálhatott a támadó a kérdéses időszakban, sajnos nem lesz feldolgozható nyom.

A végpont az új periméter

Nehezíti a szervezetek dolgát, hogy nagyon sok esemény már nem is a határvédelem naplóiban kereshető (bár nyilván a jeleik ott is megjelennek), hanem a végpontokon, a munkaállomásokon, laptopokon, mobil eszközökön (pláne, ha az adott eszköz az esemény idején nem is tartózkodik a céges hálózatban).

Itt is jelen vannak a korábbi hibák, pl. a rosszul beállított naplózás, de tovább súlyosbítja a helyzetet, hogy a végpontvédelmi megoldások naplózása, illetve a végpontokon bekövetkező események monitorozása sem rendesen megoldott.

Sajnos sok esetben az, hogy a végpontvédelem rendelkezik központi menedzsmenttel (ahol még események is megjelennek) nem számít: a cucc tele van vörös jelzések tömegével (amelyek pl. olyan gépeket jelölnek, amelyek már régen nem is léteznek), van 431 riasztás, amelyet a sok false positive, vagy már nem létező gép miatt a rendszergazdák nemigazán ellenőriznek.

A végpontvédelem sok esetben nem küld riasztást (pl. email), mert, ha küldene, a rendszergazdák naponta 431 riasztást kapnának, sőt, akkor se küld riasztást, ha mondjuk valamilyen malware eseményt észlel a rendszer – „naponta van 72 ilyen, ha minddel foglalkoznánk, nem dolgoznánk”.

A fejlettebb támadások esetében néha azonban a hagyományos naplózás sem mindig tud segíteni, bár legalább lesznek nyomok, amiket vizsgálni lehet. Azonban a fejlett támadások rámutattak arra, hogy a klasszikus naplózás mellett szükség van valami erőteljesebb nyomrögzítésre, a terület kapott is egy hárombetűs EDR nevet azon melegében.

Az Endpoint Detect and Response (EDR) rövidítés egy olyan technológiát takar, amely gyakorlatilag minden, a végponton bekövetkező eseményt (processzek indulása, mi mit indít, miért, kinek a kérésére, milyen diszk vagy memória írási műveletek történtek és hova, pontosan milyen címekre indult kommunikáció, honnan érkezett kommunikáció, mi dolgozta ezeket fel, milyen fájlok keletkeztek és hol, stb.) letárol és elküld egy központi elemző rendszernek.

A központi rendszer összesíti, korrelálja a végpontokon bekövetkező eseményeket, mindenféle intelligenciákat (Threat Intell) ráereszt az adatokra és az alapján képes riasztani, hogy nem csak eltárolja hanem fel is dolgozza az eseményeket.

Korábban az EDR rendszerek is „csillagháborús” technológiáknak számítottak, de mára, mint önálló terület elvesztette a szerepét, és átkerült fejlett védelemként a hagyományos végpontvédelmi rendszerek magasabb árú licensz csomagjaiba (pl. a BitDefender, Sophos, Panda – hagyományos végpontvédelemi gyártók már beépítették az EDR-t a rendszereikbe).

Láthatjuk, hogy az EDR alapja egy „logolj le mindent, Isten majd korrelálja” naplózás, és persze az adatok automatikus feldolgozása. Szóval ez sem csodaszer, viszont teljesen láthatóvá és vizsgálhatóvá teszi, hogy mi történt a végpontokon, miért és ki miatt.

Gyűjtsd a logot, ne siránkozz! – mondja a költő

A volt-nincs és félvak naplózás megoldása, ha helyesen állítjuk be a védelmi eszközök, a kiszolgálók és a végpontok naplózását. A határvédelmi eszközök esetén ne csak a blokkolt, hanem az üzemszerűnek tűnő ezért engedélyezett adatforgalmazást is naplózni kell, a szervereken pedig be kell kapcsolni a részletes audit naplózást.

Álmoskönyvek szerint ekkor sem kell túlzásokba esni, az sem jó, ha tényleg MINDENT lenaplózunk  - bár én azon az állásponton vagyok, hogy jobb többet logolni, mint kevesebbet (bár ennek később látjuk, van ára).

A legfontosabb viszont az, hogy a logokat nem hagyjuk az adott eszközökön.

A legtöbb biztonsági szabvány és elvárás kimondja a központi naplógyűjtés (és feldolgozás) szükségességét. Az eszközökről a keletkezett naplóbejegyzéseket továbbítani kell a központi loggyűjtő rendszerbe – ahol ellentétben az eredeti eszközökkel, rendelkezésre áll a megfelelő tárhely a naplók hosszú távú megőrzésére.

Loggyűjtésre a fizetős és csodálatos rendszerek mellett (pl. IBM Qradar, Splunk, AlienVault, Kiwi, stb.) rengeteg ingyenes megoldás létezik (OSSIM, GrayLog, SysLog, SIEMonster, stb) és természetesen teljes iparág épült a területre (SIEM, SOC). Akkor is van megoldás, ha az adott szervezet nem tud erre megfelelő infrastruktúrát építeni: rengeteg cloud-alapú loggyűjtő rendszer létezik (pl. Papertrail és társai).

A központi loggyűjtés előnye, hogy minden bekövetkező eseményről rendelkezésre fog állni log, hiába íródik felül magán az eredeti eszközön. A másik előny, hogy a támadók, ha megfelelő jogosultságot szereztek, a kompromittált szerveren például kitörölhetik a naplókat – viszont ezek akkor is rendelkezésre fognak állni a központi naplógyűjtőben, tehát a támadó végeredményben nem tudja eltüntetni a nyomait (kivéve persze, ha rommá töri a loggyűjtőt, a „ki őrzi az őrzőket” elvet itt is tessék figyelembe venni).

Azt se árt figyelembe kell venni tervezéskor, ha mindent logoulunk, akkor nagy tárkapacitásra van szükség, a feldolgozás és elemzés pedig már-már „bigdata”-szinten lesz. A nagyobb cégek és szervezetek jobb, ha szakértőhöz fordulnak a megfelelő loggyűjtés, elemzés (akár SIEM vagy SOC) kiépítésével, bár ha van rá kompetenciájuk és erőforrásuk, azért nem lehetetlen önerőből megvalósítani legalább a logok begyűjtését. 

Forensic képesség

A forensic vizsgálatok itthon jellemzően nem honosodtak meg, mert viszonylag kevesen űzik ezt az okkult tevékenységet, ritkában van rá szükség, ezért a szervezetek jellemzően erre nem építettek kompetenciát.

Erre a képességre humán oldalról sokat kell költeni (és ritkábban kell ezt a képességet, tudást alkalmazni, tehát „nem gazdaságos”), a megfelelő képzések sokba kerülnek (ámbár vannak nagyon jó online kurzusok), a gyakorlás pedig rengeteg időbe.

A megfelelő szakértő bérlése „gazdaságosabbnak” tűnik, mint saját kompetenciát fenntartani, még akkor is, ha nem csak drága eszközökkel lehet ilyen vizsgálatokat megvalósítani, mert rendelkezésre állnak (többé-kevésbé) működő ingyenes megoldások, mint az AutoPsy, RedLine, stb.

Az is ide tartozik, hogy a szervezetek incidens esetén nem arra törekednek, hogy megfelelően feltárják az eseményeket, ok-okozatokat, érintettségeket keressenek, stb, hanem inkább arra fókuszálnak, hogy minél előbb helyreálljon a működés. A forensic időigényes tevékenység, a nyomok megfelelő rögzítése nagyon sok időbe kerül, amit a szervezetek inkább a helyreállással töltenének.

A lementett nyomokat később offline is lehet vizsgálni, azonban nagyon sok esetben a nyomok rögzítése már ott meghiúsul, hogy a szervezet a helyreállással megsemmisíti ezeket az adatokat (pl. töröli a gyanús eszköz merevlemezét, töröli a virtuális szervert, stb.).

Megértem, de tényleg. Az üzemi működés helyreállása az első, minden más csak utána következik – azonban ez a forensic vizsgálat eredményességét nagyban ronthatja.

Vannak a forensic-nek egészen mély részei, amelyekhez már tényleg olyan kompetencia kell, hogy azt nem hogy fenntartani nem érdemes, de még bérelni se éri meg (kivéve persze, ha jogi bizonyításra kell adatokat összeszedni), de szerintem már valahol a rendszergazdai képzéseknek tartalmaznia kellene olyan forensic eljárások készségszintű elsajátítását, mint (legalább) a logok átnézését, diszk- és memóriaképek lementését, böngészőesemények feldolgozását, MFT elemzést, stb.

(De sajnos abban is nagy igazság van, hogy ha a rendszergazda nyomokat vadászik a helyreállás helyett, akkor tovább sérülnek az üzemi folyamatok.)   

Összefoglalás

Nem osztom a cikkben szereplő állítást, hogy a támadók nyom nélkül tevékenykednek. Ha megfelelő naplóadatok állnak rendelkezésre, nyomok mindig akadnak. Inkább azt mondanám, hogy a szervezetek nagyon kevés erőforrást biztosítanak a nyomrögzítésre, és még kevesebbet a nyomelemzésre.

A támadók nem szellemharcosok, és nem szabad misztifikálni őket, mert legyenek akár milyen ügyesek, egy jól felkészített rendszer esetén mindig marad nyoma a tevékenységüknek.

A támadók valóban sokat tesznek azért, hogy megnehezítsék a reagálást, eltüntessék a tevékenységük digitális nyomait, azonban sok esetben feleslegesen fektetnek ebbe energiát: a szervezetek legtöbbje saját maga gondoskodik arról, hogy ne lehessen feltárni a nyomokat és megállapítani, mi, miért és hogyan történt.    

• Az eredeti cikket itt olvashatjátok.
• A Target-féle breach tanulságos összefoglalóját itt olvashatjátok
• Aki a forensicel szeretne ismerkedni, itt elkezdheti