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:
"Min dék duttam, hotty. Te egy vagy Naggy hüjje. De hogy eggkorra. Vaggy asztt tat. Mékk én? sem duddtam. Ellhicheted! Róllam te. Ne firrgálj! semmid. Mert jövög én. Éés cha meggírom terróladd. Hodjj migget tsináldáll. Aggor jjól besszárnag. Tégedd. Éés ettől függetlenül gaphadsz tőllem a fejedre eggy nagyod a kőzgasszán biszkállóval.”
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.
