Már előre várom, mikor kapom meg, hogy nem csak a magyar DLP-piac hanem az éppen fejlődésnek induló EDR-piac tönkretétele is személyesen hozzám fűződik. Jó az, ha az ember ott hagyja keze nyomát a világban 🙂

Megjelent egy „cikk” a Sysadmin Fórum hasábján (Már a címe is tetszik: Fizetett belső ellenségek – mit vessünk be ellenük), amely oly mértékben baszta ki nálam a biztosítékot, hogy átütve lustaságom betonbunkerét, arra késztet, hogy kiírjam magamból a mérgemet.

UPDATE: nem az EDR-ről beszél a cikk elsősorban, inkább globálisan az Adaptive Defense-ről és annak egy moduljáról. Szóval inkább úgy olvassátok, hogy az Adaptive Defense és/vagy BÁRMELY más vírusvédelmi megoldás (csak mellé lesz egy kis EDR 🙂

EDR nagyon dióhéjban

Az EDR az Endpoint Detection and Response csodálatos rövidítése, amely gyakran a Next Generation AntiVirus (NextGenAV), vagy a szignatúra-mentes AV néven is említésre kerül.

Az EDR megoldások nem a malware-ek és más, káros kódok, alkalmazások, tartalmak szignatúra-alapú felismerésére teszik a hangsúlyt, azaz nem azért ismernek fel egy káros tartalmat, mert a kód lenyomata (szignatúrája) megtalálható a szignatúra adatbázisukban.

Az EDR nem más, mint egy alacsony erőforrásokat felemésztő (lightweight) modul, amely a munkaállomásokon fut. A modul többféleképpen működik, de a jobb rendszerek esetében a munkaállomáson érdemi felismerő tevékenységet nem végez, hanem a munkaállomáson bekövetkező minden egyes változást elküld a központi menedzsment eszközének, ahol ezek az információk korrelálódnak és tárolódnak.

Endpoint Detect

Nézzünk egy triviális példát. A felhasználó megnéz egy weboldalt.

Változás áll be a munkaállomáson, hiszen beírta a böngészőjébe a weboldal címét, elindult az oldal letöltése, TCP 80/443 hálózati forgalom történik, fájlok töltődnek le a munkaállomásra, a fájlok betöltődnek a böngészőbe és végül megjelenik a weboldal. Ez a folyamat rengeteg változást indikál, a fájlletöltés, a fájlok létrejötte és tárolódása a cache-be, a megjelenő weboldal, az elinduló JS vagy más aktív kódok – mind-mind változást okoznak a munkaállomáson.

De ilyen változás lehet az is, hogy a felhasználó csatlakoztat egy pedrive eszközt, az eszközkezelőben megjelenik az eszköz, felcsatolódik meghajtóként, állományok másolódnak be róla vagy íródnak ki rá.

Az EDR ezeket az adatokat, a változásokat továbbítja a központi feldolgozó eszközének, ahol ezen a rengeteg adaton „big data” elemzések történnek. Az EDR menedzsment központja az agy, ott tárolódnak azok az ismert káros folyamatok tevékenységi listái, hashek, stb.

Szóval koncepcionálisan az EDR tök jó, a folyamatokat, változásokat, processzeket, írás-olvasási műveleteket, API hívásokat, hálózati kommunikációkat korrelálja – tehát sokkal több adatból „jósol”, mint egy hagyományos vírusvédelmi megoldás.

A pendrive-os példát folytatva, ha egy pendrive-ról bemásol egy fájlt valaki a munkaállomására, elindítja, majd a fájl elkezd valamit csinálni viselkedni, akkor azért fog riasztani meg beavatkozni a rendszer, mert látta:

• Felcsatolásra került egy pendrive,
• Egy adott fájlt olvasott a felhasználó Explorer processze,
• Majd ezt a fájlt átírta a munkaállomásra az Explorer,
• A fájl elindult, processzt hozott létre.
• A fájl vagy a processz tallózgatja a hálózatot, elkezd más fájlokhoz hozzáférni,
• Crypto API hívásokat használ,
• Sok írási/módosítási műveletet végez,

ezért ez a fájl gyanús, nagy eséllyel ransomware, riasztás, beavatkozás.

Hogy honnan szedi a menedzsment/központ/brain a gyanús tevékenységek, viselkedések, folyamatok, stb-k jellemzőit?

Természetesen a Cyber Threat Intelligence a megoldás, azaz a CTI! 🙂

A jobb EDR rendszerekben a gyártó beletette amit tudott, viszont hogy a rendszer minél több információval rendelkezzen a kibertér veszélyeiről, ezért más gyártók intelligenciája is becsatornázható az EDR rendszerbe, szóval a tudást nem csak a gyártó, hanem sok gyártó képes átadni az EDR rendszernek.

Az EDR másik nagy területe az R-betű, a Response.

A beavatkozás rengeteg mindent jelenthet az adott EDR megoldás képességeitől függően, gyanús tevékenységek blokkolása, riasztások, a munkaállomás izolációja a hálózattól, a teljes gyanús folyamat root-cause megjelenítése, miből mi következett vagy történt, milyen folyamatok milyen műveleteket csináltak, amelyekből az adott gyanús esemény következett be.

 EDR “root cause”

EDR “root cause”

Szintén kiváló képesség, hogy az EDR rendszerek nagyon sok funkcióval támogatják a gyanús események kivizsgálását, aktivizitálhatják a munkaállomás memóriaképét, a teljes merevlemez képet (online vagy offline), azokon is vizsgálatokat tudnak végezni.

Szóval összefoglalva, az EDR baromi jó dolog. Nem új hanem 4-5-6 éve létező terület (idekívánkozik, hogy a Carbon Black volt az első, tényleg jó használható és sokáig egyeduralkodó EDR megoldás), de önállóan valahogy soha nem tudott megkapaszkodni és elterjedni, talán mert az ezer éve berögzült „Legyen helyi AV/AM a munkaállomáson” elvvel szembe megy, és nem tudta megtörni a hagyományos vírusvédelem dominanciáját.

Most az látszik, hogy a hagyományos vírusvédelem eszi meg a területet, ennek jele, hogy mind a Panda, mind a Bitdefender végponti AV/AM termékek elkezdtek EDR funkciókat beintegrálni a szolgáltatásaikba. Nincs is ezzel semmi baj, sőt, örülök neki.

GDPR és Panda Adaptive Defense

Ami kibaszta nálam a biztosítékot (és ez nem a Panda és nem a Sysadmin Forum hibája, hanem túl sok hasonló, GDPR-t meglovagoló marketing cikk jelenik meg mostanában), hogy a cikk önmagával is ellentmondásos.

Mit mond a cikk ebben a tételblokkban?

• Arányosan kell védekezni (kockázatarányosan)
• Nem azt fogják nagyon megbüntetni, akinél betörés vagy szivárgás történik, hanem aki nem dokumentálja és jelenti le megfelelően az incidenst.

Ebben még igaza is van a cikknek, és tűpontosan rámutat, hogy a GDPR nem technológiai-jellegű elvárásokat fogalmaz meg elsősorban, hanem adminisztratív és jogi folyamatokat.

Nézzük tovább a cikket.

Na most akkor ezzel, hogy?

A cikk saját magával szembe menve, a tökéletes antinómiát megvalósítva jelenti ki, hogy nem csak minden ellen IS jó a Panda, de a Panda-t használva a vállalat sikerrel meg tud felelni a GDPR-nak és nem kell büntetéstől tartani.

Kanttal élve, jelen esetben a tiszta és nem gyakorlati-ész, a transzcendentális analitika és annak a vágya, hogy eladjunk Panda megoldásokat, nemigazán kapcsolódik a szemlélet (személyes adatok védelme) és a fogalom (GDPR) kettőséhez. A cikk szerzője jobban tette volna, ha saját köldökébe tekintve mélyen elgondolkodik és a GDPR – valóság viszonyában dependenciát, inherenciát és kauzalitást keres.

A Panda Adaptive Defense (Akár az EDR, akár a Panda Advanced Reporting Tool) semmiképpen és semmiképpen nem egyedi módon nem járul hozzá ahhoz, hogy egy szervezet megfeleljen a GDPR adminisztratív, jogi és adatkezelési elvárásainak, mivel ezek nem technológiai igényeket vagy védelmeket fogalmaznak meg, tehát nem tapasztalatból és érzékelésből származó, hanem az EU (Isten) létezéséből fakadó priori, szükségszerű és kellően általános ideák.

A Panda Adaptive Defense (EDR vagy Panda Advanced Reporting Tool funkcióval) tehát pontosan annyira illik a GDPR világképébe, mint bármely más Anti-Vírus megoldás.

De hogy a kis eszmefuttatás ne csak a levegőben lógjon, nézzük meg, mi az, amit a vállalatnak vírusvédelem esetén (amellyel amúgy is rendelkezik) GDRP-szempontból „megfelelően” kell tartania.

A “GDPR-ellen védő” vírusvédelmi megoldás, szolgáltatás:

• Rendszeres és automatikus szignatúra-frissítés a végponti AV/AM eszközben,
• Legyen hetenként legalább egyszer full/deep scan a munkaállomásokon végig tolva (Hogy az esetleg bejött, de akkor még nem felismert káros cuccokat is megtalálja, valamint nem minden AV/AM szoftver használja a teljes szignatúra adatbázisát a real-time védelemhez),
• Az üzemeltetők értesüljenek a vírus/malware/egyéb és gyanús tevékenységekről – tehát legyen riasztás, értesítés beállítva!
• Az üzemeltetők legalább hetente egyszer tekintsék át a héten bekövetkező eseményeket (heti riport), és ha kell, akkor további felderítő tevékenységet végezzenek az áttekintés alapján (gyanús esetek vizsgálata, logok összenézése, felhasználó letolása, stb.),
• Vezetés felé készítsenek legalább havonta összefoglaló jelentéseket a vírus- és malware eseményekről, beavatkozásokról, arról, hogy pontosan mit csináltak, stb.
• Lehetőleg a vírusvédelmi eszköz a keletkező logokat és naplóállományokat továbbítsa központi loggyűjtésbe vagy SIEM-be, korrelációra (hopp, nicsak!),
• Legyen mentés J – ez különösen fontos, és lehessen visszaállni belőle,
• Legyen valamilyen terv, eljárásrend, playbook arra az esetre, ha fertőzés, adatvesztés, vagy más, malware-indikált incidens történik, hogy az üzemeltetők tervszerűen, gyakorlatiasan, hatékonyan be tudjanak avatkozni és csökkenteni tudják a keletkezett kárt, majd eltakarítva a romokat, helyre kellő időn belül tudják állítani a kieső szolgáltatásokat, és vissza tudják állítani az adatokat (személyest és nem személyest is).

Szóval, ha termékcsere, bevezetés és plusz költségek NÉLKÜL, egyszerűen csak nem hagyják magára a vírusvédelmet, karbantartják, frissítik, monitorozzák és ellenőrzik – az AntiVírus/AntiMalware oldal tökéletesen meg fog felelni a GDPR technológiákkal kapcsolatosan megfogalmazott minimális elvárásainak.

Nyilván ennél lehet többet is tenni – de ha már ezt biztosítják, túl nagy baj ezzel nem lesz a Hatóság oldaláról, hiszen bizonyíthatóan megfelelő gondossággal jártak el.

Természetesen, ahogy a kockázat arányos védelem szellemében csak abban az esetben kell bármilyen extra védelem (sandbox, APT-védelem, EDR, vagy más „csillagháborús” megoldás), ha azt a kockázat mértéke igazolja, és a kockázat csillapítására bevezetett intézkedések vagy megoldások költsége arányos a kockázattal és annak lehetséges kárértékével.

Forrás: kiber.blog.hu