Sharky szakmai blogja IT biztonság, információvédelem, adatvédelem, GDPR témában

Kiberblog

2017\05\24 snwx 2 komment

Mire jó a DLP és mire nem?

Mire nem jó a DLP?

A DLP jelentése Data Leak Prevention (Protection) – adatszivárgás megelőzés/védelem, és egyre „fontosabb” szerepet kapnak az ilyen rendszerek a hatékony biztonsági infrastruktúrákban (köszönhetően az MNB-nek illetve a GDPR-nak :)).

Számomra a legnagyobb gondot az jelenti, hogy a presales kollégák, illetve maguk a gyártók azt evangelizálják, hogy a DLP rendszer majd megvédi az ügyfel adatait:

  • A belső, szándékos adatlopásoktól, adatszivárgásoktól,
  • A hálózatunkba bejutott támadóktól,
  • A vétlen, gondatlan felhasználástól, hozzáféréstől.

 

forcepoint-screen1.png

forcepoint-screen2.png

Példa: Forcepoint/Websense gyártói weboldal

Ezzel az a probléma, hogy a háromból kettő nem igaz.

  • A DLP rendszer nem fogja megállítani a belső, szándékos adatlopást, adatszivárogtatást.
  • A DLP rendszer nem fogja megállítani a hálózatunkba bejutott támadót.
  • A vétlen, gondatlan felhasználók ellen azonban valóban védelmet jelent.

A DLP technológiák egyáltalán nem csodaszerek.

Teljesen alkalmatlanok a szándékos adatlopási kísérletek megakadályozására, gyakorlatilag elmondható, hogy egy alapfokú felhasználói ismeretekkel rendelkező személy is könnyedén kijátszhatja őket.

Nézzünk egy példát, a content-aware DLP megoldások Achilles-inját:

A content-aware DLP megoldások felismerik a védett adatokat, megtanulják őket, lenyomatot képeznek róluk, amelyeket aztán felismernek az adatfolyamokban, és szabályrendszer-sértés esetén közbe lépnek.

De mi történik akkor, ha az adat visszaállíthatóan eltorzul, és a lenyomata már nem emlékeztet az eredeti védett adat lenyomatára?

Ehhez nem kell más, cserélj ki minden „e” betűt a védett dokumentumban „XX”-re. A szöveg (adat) digitális lenyomata nem fog egyezni a védett adat lenyomatával, tehát a content-aware DLP nem fogja felismerni a kimenő adatot az email vagy web forgalomban.

Kellett ehhez hackernek lenni? Nem, elegendő hozzá egy Word ("advanced theft tactics").

Nézzünk egy másik példát, regulárisan felismerhető és algoritmussal validálható adatokkal kapcsolatban – legyen a példa bankkártya szám.

A kártyaszámok regulárisan felismerhetők, majd a DLP rendszerek a felismert adatobjektumokat algoritmussal validálják (kártyaszámok esetében ez a Luhn-algoritmus).

Az algoritmus a számsor számainak alapján, ellenőrző összeget számolva megállapítja, hogy a regulárisan felismert adat valóban bankkártya szám-e, vagy csak egy számsor, amivel nem kell foglalkoznia.

Ha a felhasználó bankkártya számokat akar kiküldeni, nincs más dolga, mint „elrontani” a kártyaszámokat, mondjuk minden második számhoz hozzáadni egyet. Nyilván amikor majd helyre akarja állítani az adatokat, akkor megfordítva, minden második számból kivon majd egyet.

Kell hozzá hacker-tudás? Nem, elegendő hozzá egy Excel.

A content torzítás egyszerű és hatékony módja a content-aware DLP rendszerek megtévesztésének, a legtöbb gyártó erre csak annyit mond, hogy hát igen, ez már fraud prevention kategória.

Ezzel a két példával csak azt szerettem volna bemutatni, miért túlzó a gyártók állítása, amikor azt mondják, hogy képesek védelmet nyújtani a szándékos adalopás és adatszivárogtatás ellen.

Na jó, csak azért, hogy három legyen az igazság: az említett DLP teszt projektben jó néhány esetben komoly „bmeg!” felkiáltás történt, amikor egy szintén régi, jól bevált trükkel próbálkoztunk, a Wingdings-csavarral.

A trükk lényege, hogy megfogod a védett dokumentumot, és a teljes szöveget átállítod Wingdings fontra. Ilyenkor ugye a képernyőn mindenféle hieroglifák fognak megjelenni, de a túloldalon a Wingdings-ből Arial-ba átállítva visszakapjuk a dokumentumot.

A content-aware DLP-ket nem lenne szabad, hogy ez megzavarja, hiszen a technológia az adattal foglalkozik, nem annak megjelenési formájával, márpedig a tartalom ugyanaz maradt – csak a font, a megjelenés változott.

Eléggé elképedtünk, amikor nem egy content-aware DLP hasalt el ezen a teszten, azaz ebben a formában már nem ismerték fel az adatot és nem tudták a szivárogtatást megakadályozni.

A gyártókkal folytatott konzultációknál a sales/support engineer kollégák is hangosan káromkodtak, ugyanis ez a trükk bevett eleme a DLP demóknak és bemutatóknak: „- Nézzétek, átállítom, elmentem, és így is megfogjuk!” – Minden SE ezerszer elmutatja ezt a panelt, ergó maguk is megdöbbentek, hogy most ez nem működik.

A háttérben - egyelőre - ismeretlen okok/bugok állnak, remélem majd kapok erre a jelenségre valamilyen hivatalos választ.

Az én véleményem, hogy egy jól bevezetett DLP rendszer legfeljebb 20%-ban képes a szándékos szivárogtatás ellen védelmet nyújtani, de akkor még nem beszéltünk azokról a szivárgási csatornákról, amelyre a DLP rendszernek nincs is ráhatása:

  • Lefényképezett monitor,
  • Kinyomtatott adat (nyomtatást lehet a DLP-vel kontrollálni, de a kinyomtatott papír felett már nincs hatalma),
  • Jelszóvédett zip fájl (az botor gondolat, hogy nagyon alapos folyamatfelmérések nélkül elblokkolható a titkosított fájlok kiküldése - műszakilag persze minden további nélkül lehetséges, csak az üzleti folyamat nem fog neki örülni),
  • Autistaként memorizált adatok,
  • Telefonba beolvasott adatok,
  • Lehetne még sorolni.

Akkor mire jó a DLP?

A DLP megoldások kiválóan használhatók a vétlen vagy gondatlan adatszivárogtatások és helytelen adatfelhasználások visszaszorítására.

A vétlen adatszivárogtatásra kedvenc példám az Outlook (de bármilyen más levelező kliens is), amikor én Kovács Lázárnak a Mutyi Kft. képviselőjének szeretnék írni (még rosszabb, amikor ilyet CC-ben csinál az ember), és megbízva az Outlook által feldobott névben, elküldöm a levelet Kovács Lórándnak a Kovács és Társa Kft. képviselőjének. Szerintem ilyen tévesztés már nagyon sokakkal előfordult, és sajnos a levelek visszahívása inkább nem, mintsem működik :).

Nyilván ugyanilyen vétlen vagy gondatlan adatfelhasználás, amikor a személyes adatokat tartalmazó állományt véletlenül egy nyilvánosan elérhető megosztásba menti az ember, vagy akár advanced módban, az SQL dumpot egy olyan szerverre mentik le, amelynek az adott foldere publikus FTP szerverként elérhető (Veszprém).

Sok esetben az USB adathordozók jelentenek szivárgási csatornát, mert nem feltétlenül kell a felhasználónak a „topsecret” besorolású adatokat az egyébként titkosítatlan adathordozójára kimenteni majd hazavinni és otthon dolgozni az adatokkal.  

Ilyen esetekben (számos más példát lehet felhozni) roppant hasznos a DLP megoldás és megmentheti a szervezetet néhány nagyon kellemetlen szituációtól.

A DLP rendszerek szerintem fontos és szükséges részei a modern adat- és információvédelemnek, de tudni kell őket a helyükön kezelni, és tudni kell, hogy mire akarjuk felhasználni őket. Aki azt hiszi, hogy a DLP rendszer majd megvédi az adatait a szándékos és rosszindulatú szivárogtatásoktól, azt később súlyos (és költséges) csalódások fogják érni.

Tudd, mit veszel, tudd, mire akarod használni, tudd, mit akarsz megvédeni, hol, mi ellen – és akkor mindjárt közelebb kerülsz egy sikeres DLP bevezetéshez :).

Kérdés: Ha Te lennél, hogyan probálnál adatot szivárogtatni/lopni a gonosz munkáltatódtól? Milyen ötleteitek vannak?

DLP megoldások a kínpadon

adatszivárgás védelmi rendszerek tesztelése

Amikor megcsináltam a saját cégemet, abban biztos voltam, soha a büdös életben nem lesz ebből rendes cég (HR, PR, menedzsment, dolgozók, stratégia, tervezés, stb.) – sok mindenre teljesen alkalmatlan vagyok, többek között a cégvezetésre IS.

Azért addig már eljutottam, hogy az AFA időben be van fizetve, valamint a járulékok és fizetések is időre el vannak utalva – de azt hiszem ez a legtöbb, amire cégvezetésben én képes vagyok.

Viszont pontosan azért szakítottam előző kényelmes életemmel, mert olyan munkákat akartam csinálni, amelyek szakmailag kihívással járnak – és nem utolsó sorban még érdekesek és változatosak is.

Az egyik ilyen „legjobb” projekt egy bank megbízásából érkezett, és aligha lehetett volna testre szabottabb: a cél az itthon elérhető összes adatszivárgás védelmi rendszer (DLP) helyszíni tesztelése, kipróbálása és a tapasztalatok dokumentálása volt, egy olyan műszaki anyag előállítása, amely segítséget nyújt a bank belső szakembereinek a megfelelő DLP megoldás kiválasztásához.

DLP rendszerek nagyító alatt

Amikor elindult a projekt persze minden létező gyártó megjelent, így lehetőségem volt alaposan meggyötörni a

  • Symantec DLP
  • McAfee DLP
  • Grayteq DLP
  • Forcepoint/Websense DLP
  • DeviceLock DLP
  • GTB DLP (nem ebben a projektben, de ugyanezen a helyen korábban) megoldásokat.

Bónuszként a Microsoft is bejelentkezett a DLP termékével, de több okból ez már nem került tesztelésre, viszont hamarosan lehetőségem lesz egy kicsit jobban megismerni, mit tud a Microsoft ezen a területen (az RMS rendszerükkel volt korábban tapasztalatom, most ez lett kicsit feltupírozva a Secure Island nevű gyártó megoldásának felvásárlásával és integrálásával).

A projekt mindenképpen sikerese volt, egyrészt számos bugot sikerült a rendszerekben felfedezni, másrészt meg született egy több, mint 100 oldalas dokumentum, amely részletesen bemutatja az egyes gyártók aktuális verzióinak funkcióit, lehetőségeit és természetesen hiányosságait.

Elég régen foglalkozom DLP technológiákkal (Csinos Tamás ex-RRC/Clico véleménye szerint egyszemélyban vagyok felelős a magyar DLP biznisz bedöntéséért J - örök hála az eposzi jelzőért!), ennek ellenére sem volt egyszerű felállítani egy olyan szempontrendszert, amely valamennyire lehetővé teszi a DLP megoldások összehasonlítását.

Almát a traktorral, cseresznyét a szilvával

Azért mondom, hogy valamennyire, mert a felsorolt technológiák nem azonos tőről valók: három teljesen különböző technológiai irányvonalat képviselnek, ezért összehasonlításuk sem egyszerű.

Content-aware DLP

Ebbe a kategóriába tartoznak azok a megoldások, amelyek első sorban az adatokkal foglalkoznak. Számukra az adat megjelenési formája (fájlban, adatbázisban, SharePointban, Exchnage-ben, stb.) irreleváns.

A content-aware DLP megoldások kinyerik (extraktálják) az adatokat a tárolási helyükből, feldolgozzák, megtanulják, értelmezik, stb. azokat, majd ezek után képesek felismerni az adatokat az adatfolyamokban és kommunikációs csatornákban.

Játékosok:

  • a Symantec,
  • a Forcepoint/Websense
  • a GTB
  • a DeviceLock

File-based DLP

Személy szerint nem nagyon találkoztam ezzel a megoldással, csak IRM (rights management) oldalon, de mindenképpen érdemes megemlíteni, hogy nem ördögtől való koncepció, és ha jól működik, akkor a DLP-ből a „P” betű nem a marketingesek elmeszüleménye.

 Az ilyen DLP cuccok magukkal a védendő fájlokkal, nevükkel, elérési útjukkal, mozgásukkal, hozzáférésükkel (copy, move, read, write, etc.) foglalkoznak. (A gyártó képviselőjével művéres szócsatákat folytattam, egyáltalán ez DLP termék-e, véleményem szerint inkább IRM mint DLP, de abban kiegyezhetünk, hogy DLP funkciókat tartalmazó eszköz :)).

 Játékos:

  • a Grayteq DLP

 Tag/label-based DLP

Korábban nem rajongtam az ilyen megoldásokért, a klasszifikáció és labeling terület kiterjesztéseként az eszközök belenyúlnak/hozzányúlnak a fájlokhoz és megtaggelik őket. Később a szabályrendszer a tag-eket felismerve mondhatja azt, hogy ebben a fájlban a tag szerint szenzitív adat van, ezért nem engedem, hogy emailben elküldje a felhasználó házon kívülre.

A tagek hozzáadása az állományokhoz lehet manuális (a felhasználó saját mega megjelöli, hogy védett adat van benne) vagy lehet automatikus: ilyen esetben valamilyen crawler processz megtalálja a fájlt, megpróbálja értelmezni a tartalmát, és a tartalomnak megfelelően ráhelyez egy vagy több taget.

Hopp...tartalom alapján?! – Na akkor ez nem content aware DLP? De lehet, például ilyen

versenyző:

  • a McAfee DLP

Nehezíti a besorolást, hogy a McAfee DLP bizony fájl és elérési út alapján is dolgozhat, szóval jelen esetben inkább a hibrid jelölés lenne rá érvényben. Mivel azonban a legtöbb funkciója taggingre épül, ezért mégis a harmadik kategória mohikánjaként érdemes megjegyezni.

A következő részben arról lesz szó, hogy egyáltalán mire jó a DLP és mire nem – csak azért, mert a drága marketingesek előszeretettel puffogtatják, hogy a DLP bevezetése majd megakadályozza, hogy ellenséges/imperialista/konkurentalista/rosszinulatúista felhasználók ellopják a szervezet védett és féltve őrzött adatait.  

Hát nem.

Arra pont nem jó, de majd megnézzük ezt kicsit közelebbről.

Az egész a hackerfeleseg.hu miatt van

Alapjába véve rettenetesen lusta vagyok, ez nálunk valami felvételi követelmény vagy ilyesmi, mert tényleg szeretünk dolgozni, viszont nagyon nehezen vesszük rá magunkat (de akkor meg leállni nem tudunk).

Pontosabban, ha meló van, akkor arra nem kell rávenni magunkat, viszont bármi, ami plussz erőforrást éget el, már nehezen megy, ezért nem volt eddig blogunk sem.

Viszont annyira megtettszett a hackerfeleseg.hu blog (amit igen jó barátom - kódnevén Elithekker) hites felesége visz és annyi sok jó meg rossz dologgal találkoztam mostanában, hogy csak bele kell vágni valami céges blog létrehozásába.

A blog belső kódneve Titanik - mert házon belüli vélekedés az, hogy úgy is elsüllyed. Meglátjuk :)

Címkék: jss
süti beállítások módosítása