A DLP területet és megoldásokat bemutató sorozat jelen fejezetében egy érdekes játékos kerül a nagyító alá: a magyar fejlesztésű Grayteq DLP melynek atyja, Tari Róbert az alábbi magvas véleményt küldte nekem, nem is olyan régen:

Nem, ezt nem Ő írta, hanem a Török Szultán, de alighanem nem sok különbség van a mondanivalójuk lényege között :). Na de lássuk, mit tud a Grayteq DLP.

Nem is DLP. Vagy mégis?

A Grayteq nem content-aware DLP, hanem fájl-alapú megoldás.

Egyáltalán nem foglalkozik az adatokkal, azaz még csak véletlenül sem néz bele a fájlokba, és lövése sincs arról, hogy pontosan mit is tartalmaznak a fájlok.

Nem azért, mert béndzsó, hanem azért, mert nem így működik: tulajdonképpen nem más, mint egy nagyon jól összerakott hozzáférés és jogosultság-szabályozó rendszer, kiegészítve némi USB adattároló és eszköz menedzsment funkcionalitással, titkosítással, riasztásokkal és blokkolási funkciókkal.

Sokat vitatkozom a gyártóval arról, hogy beszélhetünk-e DLP megoldásról jelen esetben, hiszen az adattal (data) a Grayteq egyáltalán nem foglalkozik. Meglátásom szerint az RM/IRM (rights management) családhoz tartozik, ami erős komplementere a DLP-nek, viszont a másik oldalról nézve valóban azt lehet mondani, hogy adatszivárgás védelmi funkciókat valósít meg.

Infrastruktúra

Végponti agent

Végponti megoldásként egy DLP agent komponens fut a munkaállomásokon, amely ráülve a kernelre minden olvasási és írási műveletet képes monitorozni, logolni és természetesen képes beleavatkozni a műveletekbe.

A végponti DLP agent komponens tehát nem csak figyel, de ő hajtja végre a szabályokat, amelyeket a menedzsment szerveren állíthatunk össze és küldhetünk le a kliensekre.

Menedzsment szerver és menedzsment konzol

Egy Windows-on futó menedzsment szerver (Grayteq Biztonsági Szerver) tárolja központilag a szabályokat, a logokat és az eseményeket.

A Grayteq azon kevés DLP megoldások közé tartozik, aminek nem webes felülete van, hanem egy menedzsment konzol alkalmazása (Grayteq Security Orchestrator), amely telepíthető a menedzsment szerverre, de akár az üzemeltetők munkaállomásaira is.

Dashboard

Komponensként lehet egy Dashboard felületet is telepíteni, akár munkaállomásra, akár a menedzsment szerverre, amely csodálatos színes-szagos grafikonokat és „vezetői” riportokat tud megjeleníteni – már, akinek van gusztusa az ilyesmire, szerintem teljesen használhatatlan, parasztvakító funkció :).

Arra nagyon jó, hogy ki lehet tolni egy plazma TV-re és lehet mutogatni, de mint a legtöbb ilyen „vezetői információs eszköz” esetében, a hétköznapi használhatóság alulmaradt a látványossággal szemben.

Szerencsére a menedzsment konzolból számos használható és akár automatikus riport lekérhető.

Érdekesség

A Grayteq egyedisége a backend adatbázisban is megnyilvánul: nem a hagyományos SQL adatbázist használja, hanem írtak hozzá egy saját adatbázis motort, amelynek a hatékonysága a gyártó szerint erre a felhasználásra sokkal jobb, mintha SQL-t használnának.

Az adatbázisban titkosítottan tárolódnak az események és a logok, ha megerőszakoljuk a rendszert és mégis SQL szervert akarnánk használni, nem csak a performanciát, de a titkosított tárolást máris bebuktuk.  

Funkciók

Hozzáférés és jogosultság kontrol – elérési út és fájlnév alapon

A Grayteq végponti agent mindent lát és hall. Bármilyen alkalmazás indul el, bármilyen írási, olvasási, törlési, módosítási művelet történik a munkaállomáson, azt az agent feldolgozza, lelogolja – és ha szükséges, beleavatkozik a folyamatba.

El lehet képzelni mennyi log keletkezik – szerencsére a rendszerben működnek előszűrési szabályok a zajok kiszűrésére, a zajnak ítélt események nem kerülnek logolásra és nem tárolódnak el a menedzsment szerveren.

Amikor valamilyen művelet történik a munkaállomáson (pl. CREATE – állomány létrehozása), az agent a szabályrendszernek megfelelően engedi, vagy tiltja az adott műveletet.

Példa:

A fresz.famousgrouse.local szerver „Doksik” folderében tárolt dokumentumokat (.docx, .xlsx, .pdf) nem lehet lemásolni vagy átmásolni a munkaállomásokra illetve más tárolókra.

A szabályban szereplő elérési út (source) a \\fresz.famousgrouse.local\Doksik\* (ezen belül is a *.docx, *.xlsx, *.pdf) a target gyakorlatilag bármi lehet (*, azaz nem érdekel minket hova irányul az adott művelet), a műveleteknél pedig CREATE, OVERWRITE, MODIFY, READ, OPEN műveletek engedélyezve vannak, a MOVE, DELETE, COPY műveletek pedig tiltva.

A szabály azt fogja eredményezni, hogy a „Doksik” folderben a felhasználó tud dolgozni, létre tud hozni állományokat, meg tudja őket nyitni és módosítani is tudja őket – viszont a folderből nem tudja a dokumentumokat lemásolni vagy átmozgatni máshova.

(ez nem az, de hasonló szabály)

Eseménylog: Márpedig abból a mappából nem másolhatsz a gépedre dokumentumot! (Blocked)

Ha nagyon beteg ember lennék, akkor még azt is megadhatnám egy szabályban, hogy az adott műveleteket csak a word.exe vagy excel.exe hajthatja végre – ugyanis még a processzek is szabályozhatók. A fenti screenshoton látszik, hogy az explorer.exe volt a processz, ami a másolási műveletet kezdeményezte.

Miért jó ez? Egyrészt, ha az engedélyezett műveleteknél még az engedélyezett processz is beállításra kerül (pl. word.exe), akkor növeljük a biztonságot, hiszen a felhasználó csak az engedélyezett alkalmazással tud hozzáférni az állományokhoz, másrészt akár még egy ransomware is elblokkolható: hacsak nem word.exe néven kezd el futni, akkor nem tud hozzáférni a folderben tárolt dokumentumokhoz. (Applikáció és processz kontroll esetén nem árt a backup rendszer processzét, alkalmazását engedélyezni).

Jogos a kérdés, hogy mi van akkor, ha a felhasználó megnyit a folderből egy dokumentumot, a tartalmát kirakja vágólapra, majd a saját gépén létrehoz egy új fájlt, és bemásolja a tartalmat. Ez nem fog működni: a Grayteq tudja, hogy egy olyan folderből történt a művelet, amelyre szabály vonatkozik. Pontosabban az fog történni, hogy a felhasználó be tudja másolnia vágólapról a tartalmat – viszont, amikor el akarja menteni az új dokumentumot, egy csúnya nagy tiltó üzenet fog kapni.

Ami az előnye, az a hátránya az elérési út alapú szabályozásnak: egyszerű, de egyszerűen megkerülhető: ha a felhasználó nem FQDN-el hanem mondjuk IP címmel hivatkozik a szerverre: \\1.1.1.1\Doksik - a szabály nem lesz érvényes, hiszen a szabályban definiált elérési út a \\fresz.famousgrouse.local\Doksik-ra mutat. A megoldás, hogy az összes elérhető névkonvenciót meg kell adni a szabályban. Sajnos azonban erről elég könnyű megfeledkezni (pláne, hogy mind FQDN mind IP esetén még a C$ vagy D$ utakat is meg kell adni).

Játék a fájlnevekkel - nekem bejön.

Képzeljük el, hogy a szervezetnél nem szeretnék, ha az USB adathordozókról mindenféle futtatható állomány kerülne behozatalra és a kedves felhasználó ismeretlen eredetű exe állományokkal szórakozna a gépén.

Ezt a jelenséget gyorsan meg lehet szüntetni egy olyan szabállyal, amely kimondja, hogy külső USB eszközről „*.exe” állomány nem indítható el és nem másolható be sehova.

Ilyen esetben a „Removable Media” lesz az esemény kiinduló pontja (source), míg a target (ahova az esemény irányul) pedig egy laza „*” amely a „*.exe”-re vonatkozik, a műveletek pedig amelyeket blokkolni kell az OPEN, EXECUTE, OVERWRITE, COPY és MOVE.

EXE fájlt Te USB-ről oda nem másolhatsz be! Csúnya nagy, piros üzenet.

Persze előfordulhat, hogy a felhasználónak muszáj valahogy a futtatható állományt behozni és sajnos használnia is kell azt. Ilyen esetben jó megoldás, ha EXCEPTION-ben engedélyezzük az előbbi szabályban a felhasználóknak, hogy a \\fresz.famousgrouse.local\Virusellenorzes\ folderbe fel tudják másolni a „*.exe” állományt (COPY) – viszont erre a foldere is beállítjuk a többi művelet tiltását (pl. EXECUTE).

A kis kiegészítésünkkel a felhasználók az USB adathordozóikról exe fájlokat tudnak a szerver megfelelő folderébe felmásolni, ahol az üzemeltetők (akikre természetesen más szabályok vonatkoznak) le tudják ellenőrizni az állomány vírusmentességét, illetve, hogy valóban szüksége van-e a felhasználónak az állományra.

Oké, de a felhasználó az ellenőrzés után még mindig nem tudja lemásolni a szerverről a szívének kedves fájlt, kivéve, ha a szabályban megadjuk, hogy a *-engedelyezve.exe” fájlokra a felhasználó kapjon speciális jogosultságokat (COPY, MOVE, DELETE). Ha tehát az ellenőrzés után az üzemeltetők az ellenőrzött fájlt átnevezik, és a végére biggyesztik a „-engedelyezve” tagot, a felhasználó hozzáférhet az állományhoz, törölheti vagy lemásolhatja a gépére.

Jól látható tehát az elérési utakon és fájlneveken alapuló funkciók ereje: egyszerű és hatékony, és akár komplett workflow-k is kialakíthatók csak az által, hogy a fájlneveket állítgatják a felhasználók.

A megoldás gyengesége abban rejlik, hogy mivel a Grayteq az adattal nem foglalkozik, ezért azzal sem, hogy pontosan mit takar a kiterjesztés.

Nem néz bele az állományokba, tehát ha a felhasználó USB adathordozóján .txt kiterjesztéssel szerepel egy futtatható állomány, akkor minden további nélkül képes lesz a hamis kiterjesztésű futtatható állományt bemásolni a gépére, ott visszanevezni .exe-re és...

Ja, nem!

Ha a szabályrendszerünkben szerepel olyan policy, hogy a felhasználók nem tudnak semmit átnevezni .exe-re (RENAME, MOVE), akkor ugyan bemásolhatták a hamis fájlt, de használni nem fogják tudni, az átnevezési kísérletről pedig riasztás fog történi.

 Az elérési utakkal és nevekkel történő manipuláció egyszerűnek és hatékonynak tűnik, de oda kell figyelni a szabályrendszer tervezésekor, mert a Grayteq csak kiterjesztést figyel, tényleges fájlformátumot és típust nem.

Milyen további funkciókról lesz még szó?

HIPS – Host IPS – de csak érintőlegesen fogok írni róla, mivel nem teszteltem, és szerintem ez is parasztvakítás a jelenlegi formájában :)

Titkosítás és DataVault – A Grayteq nagyon vicces funkciója, mármint nem a funkció vicces, hanem a kulcsalapú fájltitkosítás során létrejövő Grayteq Encrypted Content azaz „.GEC” végű állományok J

USB eszközök menedzsmentje – USB és removable media kontroll, azaz ki, mit és hova dughat.

Nyomtatási kontroll – nem, nem kezel nyomtatókat, viszont mivel a nyomatások valamilyen elérési útra történnek (helyi nyomtatóknál is), ezért lehetőség van a nyomtatások szabályozására.

Karantén – védett és zárt folderek kialakítása, mindent lehet az adott folderben csinálni, de onnan fájl már nem kerülhet ki

File audit – Fájl életutak követése, mi történt az adott időszakban az állománnyal vagy állományokkal?

Applikáció kontrol – Milyen alkalmazások indíthatók, illetve milyen alkalmazások milyen fájlokhoz férhetnek hozzá?

Screenshot – események bekövetkeztekor automatikus screenshot készítés

Vágólap – igen egyedi vágólap kontroll 

Előzetes értékelés 

Biztosan fogok egy összefoglaló értékelést is írni, de most is elmondom, a Grayteq DLP jól használható cucc, érteni kell hozzá – viszont tapasztalataim szerint sokkal könnyebben megtanulja egy üzemeltető, mint bármely más DLP rendszert, mivel amúgy is foglalkozik AD-alapú elérési kontrollal, hozzáférési szabályokkal, stb. Sokkal emészthetőbb és üzemeltetés-közelibb a megoldás, mint a „nagy” content-aware DLP-k.

Aki az erős hozzáférés-szabályozás híve, illetve a DLP-t onnan akarja megközelíteni, hogy szabályozni kell, ki mihez férhet hozzá, mi hol tárolható és hol kezelhető – annak igen jó tapasztalatai lesznek a megoldással.

Ami az előnye, az a hátránya is: mivel nem foglalkozik az adatokkal, az adatkör és adatgazda-centrikus szervezetek nehezebben vezetik be.

Ha egy szervezet arra akar lőni, hogy bizonyos adatokkal kapcsolatos folyamatok (pl. kártyaszámok, stb) legyenek szabályozva, akkor nem a Grayteq DLP lesz a barátjuk.

A Data-in-Motion területen a Grayteq nem túl erős (fájlszerver-munkaállomás viszony kezel csak, email, ftp, http, stb. protokollokat nem), viszont Data-at-Rest és Data-in-Use területeken kifejezetten kigyúrt és kemény funkcionalitásokkal bír.  

Nem is az eset politikai vetülete, erkölcsisége, a megvalósítás módja és szakmaisága az érdekes ebben, hanem hogy az Átlátszó milyen szépen, kulturáltan és finoman pellengérezte a külsős IT céget.

Ugyan minden kontakt adatot kitakartak, egyedül a szlogent és a logót nem, hogy azért legalább a céget be lehessen azonosítani.

https://blog.atlatszo.hu/2017/05/lehallgattak-a-munkavallalok-elektronikus-levelezeset-schmidt-maria-figyelojenel/

A masodik levéllel legalább már az aktívan közreműködő ügy- és szakmai vezető is nevesthető.

Szép munka.

(És milyen fontos is, hogy ott legyen a levélben a megfelelő klauzula arra, ha a levél véletlenül illetéktelen kézbe kerül. Hiányolom a felkérést, miszerint ne nyomtassák ki a levelet feleslegesen.)

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.

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 :).

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.

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 :)