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.