Előző életemben nagy kedvencem volt a gyártói képviseletként forgalmazott Independence Key – egy nagyon jól kitalált, még jobban megcsinált, kulcs-cserés és hardveres fájltitkosító megoldás.

Sajnos a gyártója csődbe ment (hja kérem, Svájcban sem könnyű az élet!), így azóta is kerestem valami fájltitkosító megoldást: kicsit egyszerűbben, főleg olcsóbban, pláne Windows és Mac támogatással. Most végre megvan és itt van: a CipherUSB!

(Ja, tudom, annyi szoftveres megoldás van, ingyenestől a fizetősig, de nekem olyan kell, ahol a titkosítás nem szoftveresen valósul meg).

CipherUSB FLE

Hát első ránézésre nem valami szép, főleg, ha az Independence Key-el kell összehasonlítani, ami a CipherUSB-hez képest olyan, mint „The Rock” Csonka Picihez képest. De nem szabad csak a külsőség alapján ítélni, az Independence Key kipusztult, amíg a CipherUSB már 2012 óta elérhető és továbbra is működik.

A csodálatos és azóta kipusztult Independence Key

A CipherUSB egy USB encryptor dongle, azaz olyan USB eszköz, amelybe egy AES titkosító chip van belepakolva, és amely hardveresen titkosítja a bizalmas és védendő adatainkat.

A működésre egyszerű, a Windows vagy Mac gépen futtatott szoftveres komponens a titkosításra kijelölt fájlokat az USB porton csatlakoztatott dongle-ba küldi, ahol a titkosító chip megrágja és megemészti a fájlokat, majd visszaadja a titkosított változatukat, amelyeket aztán a szoftveres komponens kiír a számítógép diszkjére.

Visszafelé sem más a módszer: a gépen tárolt titkosított állományokat a szoftver komponenssel visszaküldjük a dongle-ba, ott dektriptálódnak, és a titkosítatlan állományok kitárolódnak a munkaállomás diszkjére. Egyszerű, nem?

De miért jó a hardveres titkosítás?

Alapból azt szokták mondani, hogy a hardveres titkosítás gyorsabb, mint a szoftveres. Szerintem ez nem feltétlenül igaz, gép és teljesítmény válogatja, ráadásul a sok pici fájl titkosításával azért a hardveres modulok is meg tudnak küzdeni.

Én inkább azt emelném ki, hogy ami a dongle-ban történik, az a dongle-ban is marad: onnan titkosító kulcs nem jön ki, a titkosítás odabent történik, elvileg hozzáférhetetlenül és zártan.

A CipherUSB AES-256 CBC titkosítással működik (van ECB-vel működő modell, az kicsit olcsóbb), amelyet az első használat során inicializálni kell egy kóddal – ez a kód lesz az, amellyel kvázi bejelentkezhetünk az eszközbe, és amely kód nélkül a fájlok nem visszaállíthatók.

A szoftver komponens

A CipherUSB szoftveres része, mint kezelőfelület jelenik meg, csak ezen a szoftveren keresztül állíthatók vissza a titkosított állományok.

Nagy szívfájdalom, de sajnos nem épül be a Windows-ba, nem lehet jobb egérgombbal kijelölni és titkosításra vagy dekriptálásra küldeni a fájlokat és könyvtárakat. Ezt igazán megcsinálhatták volna! Így kicsit kényelmetlen a használata, mintha egy WinRAR, vagy 7IP felületből kellene dolgozni. Nem vészes, de azért nem kényelmes.

Szintén a felületből lehet beállítani az új Login/Recovery jelszót – ezt kellett beállítani a használat megkezdésekor. Fontos, hogy a Login/Recovery jelszót a CipherUSB felhasználja a titkosításhoz, tehát ha megváltozik, a korábban titkosított állományok nem lesznek dekriptálhatók!

A felület lehetővé teszi az alkalmazásban a jobb egérgombbal történő kijelölést és titkosítást/dekriptálást, vagy lehetőség van a fájlokat drag-and-drop módon, a zárt lakatra húzva titkosítani, vagy a nyitott lakatra húzva dekriptálni.

Az USB dongle gyomrából visszakapott és titkosított fájlok „.addonics” kiterjesztést fognak kapni. Sajnos emiatt nincs lehetőség a transzparens megnyitásra és visszaállításra, csak a felületbe bejelentkezve és az adott könyvtárba belépve lehet a fájlt kititkosítani.

(A CipherUSB az Addonics gyermeke, de eredetileg az ENOVA Enigma nevű találmánya, tőlük licenszeli az Addonics és pl. a BlackSqare Technologies, akik szintén Enigma néven hozzák forgalomba).

Cool ficsör!

A CipherUSB FLE fenekében található egy szabvány USB-A foglalat, amelyhez más USB tároló eszköz csatlakoztatható. Ez ad lehetőséget egy nagyon frankó funkciónak, mégpedig a Write Blocker funkciónak.

Jaj de kerestem már! Hányszor van olyan eset, hogy a saját USB diszkemet vagy pendrive-omat idegen géphez kell csatlakoztatni! Persze vannak olyan pendrive-ok, amelyeken van írásvédettséget biztosító kapcsoló, de speciel nekem nincs olyan, ráadásul a külső USB diszkek esetében még nem is nagyon láttam ilyen kapcsolót. De már nem is kell!

Ha a CipherUSB kezelőfelületén egyszer bekapcsoljuk a Write Protect módot, akkor a továbbiakban bárhol, bármilyen USB adathordozót csatlakoztatunk a CipherUSB-hez, az írásvédetté válik. Ha a dongle nélkül csatlakoztatjuk, természetesen lehet írni az eszközre, de a CipherUSB-n keresztül csatlakoztatva elkerülhetjük a fertőzéseket vagy a nem kívánt adatmódosításokat!

Akartam venni forensic-boltból write blocker eszközt, de már nem kell, a titkosítási funkcióval együtt megvan a CipherUSB-ben – és ezért megbocsátom neki, hogy nem épül be a Windows-ba.

Megosztott működés

Na erről beszéltem, hogy egyszerűen van megoldva a dolog. Ami jó is meg nem is.

A jó, hogy ha van két CipherUSB eszközöm, amelyeknek ugyanaz a Login/Recovery kódja, akkor azok minden gond nélkül képesek az egymás által titkosított állományokat dekriptálni. Ez lehetővé teszi, hogy két külön telephelyen dolgozó személy is képes legyen a titkosított állományokat kibontani és használni.

Nyilván nem jó, mert ez azt mutatja, hogy nincs kulcscsere vagy ilyesmi, bár nagyon egyszerű a használata, szerintem nagyvállalati környezetben kevésbe alkalmazható (na de nem is ilyet kerestem).

Viszont szerintem kisebb munkacsoportokban, vagy akár két szervezet között kiválóan alkalmas a titkosításra, egyszerűen csak a másik fél részére el kell juttatni a Login/Recovery kódot, amelyet aztán egy másik CipherUSB-be beállítva máris kititkosíthatók az állományok.

Ugyanez történhet akkor, ha valaki elveszíti a saját CipherUSB eszközét: vásárol egy újat, és beállítva a régi eszközön használt kódot, máris dolgozhat tovább a titkosított állományokkal.

Hiányosságok (mert vannak)

Sajnos, nem épül be a Windows intézőbe, ezt már mondtam. Sajnos van kellemetlenebb rész is, mégpedig a rekurzív folder titkosítás hiánya. Ki lehet jelölni egy könyvtárat titkosításra – de az csak a könyvtár állományaira lesz érvényes, az alkönyvtárakban tárolt állományokra nem.

Gondolkodtam, hogy ez hiányosság-e vagy fícsör, de aztán arra jutottam, hogy ez arra való, hogy az érzékeny tartalmú fájlokat titkosítsa – ergó csak azt titkosítsuk el, amit valóban kell – nem pedig mindent, ami X mélységig egy könyvtáron belül van. (Gyenge érv?). Kényelmetlennek végül is nem kényelmetlen, én tudom mit akarok titkosítva tárolni akár publikus folderekben is, szóval nem feltétlen kell mindent titkosítani.

Melegedés. Hát igen. Jó munkához idő kell, a jó idő meg jó hőmérsékletet jelent. A beépített titkosító chip aztán termeli a hőt munka közben. Ez már az Independence Key-nél is megfigyelhető volt, csak ott még kellemetlenebbül jelent meg, mert az fémtokozott lévén rendesen vezette a hőt. CipherUSB esetében a fenekébe dugott pendrive csatlakozója rendesen felforrósodik.

Apropó, ha már... A CipherUSB nem használható beledugott pendrive nélkül. Ezt nem teljesen értem miért van így, azt hittem, hogy valami két faktor értelme van (a gyártó két faktorról marketingel, de az végül is maga a titkosító eszköz és a login/recovery jelszó J ), de nem. Még nem jöttem rá miért van erre szükség, gyakorlatilag bármilyen USB pendrive beledugható, transzparensen fel fogja csatolni a gépre (ha van write blocker beállítva akkor írásvédetten).

A tamper proof kivitel hiánya. Soha nem szeretem annyira, ha az ilyen eszközök nem bontásbiztosak. Na ez tuti nem az. Ráadásul nem látom annak sem nyomát, hogy lehetne valami olyasmit állítani, hogy 10 sikertelen próbálkozás után felrobbanjon letiltódjon az eszköz. Ez úgy van megcsinálva, hogy a rossz kód megadásakor kiléptet az alkalmazásból, de azért lássuk be ez nem a legtutibb.

Összefoglalva

Aki ragaszkodik a hardveres titkosításhoz, az szeretni fogja. Faék egyszerű a használata, és a hiányosságok mellett is jól használható titkosító megoldás.

Aki szereti a cloud tárolást (Dropbox, Box, stb) annak szerintem különösen javasolt. Nem nagyvállalati megoldás, de magánszemélyeknek, kisebb munkacsoportoknak kézreálló cucc, vagy szervezetek közötti titkosított adatcserékhez is egyszerűen felhasználható.

A Write Blocker funkcionalitás már önmagában is nagy királyság (egy forensic write blocker cucc 50-60ezer ft!), azzal megnyerte a szívemet!

(Bónusz, van egy CipherUSB FDE – Full Disk Encryption eszköz, amely nem fájlokat, hanem a fenekébe dugott USB adattárolókat titkosítja ugyanilyen módon.)

CipherUSB FDE - USB tároló titkosítás

"A kiberbűnözőknél is nagyobb kárt okozhat egy sértett dolgozó" - írja a HVG.

Nem tudom, hogy pontosan mi hangzott el az adott cikkben a szakértők részéről – és ebből mi került bele és hogyan a cikkbe, tippem szerint a szerző és a szerkesztő összemosta a dolgokat, pontosabban mindent beletett, mint Magdi anyus a tökös-mákos rétesbe.

Igazából Krasznay doktorúr mondanivalóját ferdítették el (szerintem) jelentősebben, ugyanis nem hiszem, hogy valóban azt mondta volna (és így), hogy a kiemelt privilégiumú (root, admin, stb.) ill. más, nagyobb hozzáférési körrel rendelkező felhasználók követik el a belső és szándékos adatszivárogtatások többségét.

Ez így ugyanis nem igaz.

Ha az adminisztratív és más kiemelt privilégiummal rendelkező felhasználókat nézzük, teljesen jogos a munkáltatóban az a felmerülő gondolat, hogy ezek a felhasználók és rendszergazdák mindenhez hozzáférnek, ezért nem árt őket kontrollálni és a munkájuk során történő hozzáféréseket és adatfelhasználásokat ellenőrizni.

De a szándékos adatszivárogtatások többségét nem ezek a kiemelt privilégiumú munkatársak követik el, hanem a teljesen hétköznapi felhasználók.

Egyrészt azért, mert az általuk kezelt és használt adatok értékét sokkal jobban ismerik, mint mondjuk egy rendszergazda, másrészt pedig azért, mert arányaiban is sokkal többen vannak egy szervezeten belül, mint a kiemelt privilégiumú személyek.

Ezzel nem azt akarom mondani, hogy rendszergazda nem követhet el szándékos adatszivárogtatást. A cikkben szereplő példa a leggyakoribb indok a kiemelt felhasználók ellenőrzését szolgáló rendszerek bevezetésének: mi van, ha a rendszergazda távozásakor kiskapukat hagy hátra, letöröli az adatokat vagy más módon, bosszúból szabotálja a szervezet működését?

(Hozzáteszem, hogy a rendszergazda pozíció bizalmi-jellegű munkakör, és eleve bármi olyan történik, amelyben elektromossággal működő eszközök rendellenes tevékenysége merül fel mint ok, úgy is a rendszergazdát fogják elővenni.).

A kedvenc legendám a bosszúszomjas fejlesztőről szól, akinek kényszertávozása után irdatlan bűz kezdett terjedni az irodában. A forensic műveletek végül eredményre vezettek és a kirúgott fejlesztő feletti álmennyezet alól előkerült a bűz forrása: egy ötkilós rohadt ponty. De ugyanide tartozik a jó fej, humoros és okos rendszergazdák bosszúja a nagyképű és beképzelt „suttyó” fejlesztőkkel szemben: a programozók napikig fuldoklottak, mire rájöttek, hogy a jó fej, humoros és okos rendszergazdák pálpusztai sajttal kenték be a székeik és asztalaik alját, majd feltolták a fűtést maximumra. (Mondjuk úgy, hogy ez nem legenda :) ).

Fegyelmező eszköz

A szándékos adatszivárogtatást, adatlopást azonban olyan felhasználók követik el, akiknek hozzáférése van (eléri, felhasználja, dolgozik vele, stb.) ahhoz az adathoz, amelynek kiszivárogtatásával az illető valamilyen igényét elégítheti ki (anyagi, bosszúvágy, erkölcsi, stb. ).

Nem kell ehhez magas vagy kiemelt privilégiummal rendelkezni, elegendő csak az adatokhoz való hozzáférés – amelyhez vagy azért jut, mert dolgoznia kell az adattal, vagy azért, mert a jogosultsági rendszer nincsen megfelelően megvalósítva.

A kiemelt privilégiumú felhasználók démonizálása merőben felesleges. A tevékenységük ellenőrzésére valóban szükség van, de szerintem sokkal inkább minőségbiztosítás és visszakereshetőség szempontjából, mintsem adatszivárgás védelmi okokból.

Ettől függetlenül persze a Balabit rendszere biztosan jó :)

Volt szerencsém a napokban résztvenni a Mandiant "Enterprise Incident Rensponse" három napos tréningjén, és ha voltak is illúzióim arról, hogy a hazai vállalatok nyomokban rendelkeznek megfelelő képeségekkel a malware (vagy egyéb biztonsági) események feltárásának és kezelésének a területén, a tréning alatt ez az illúzió kissé elkopott.

És nem műszaki területen van a baj, persze a képesség alapjába véve műszaki területhez tartozik, de magával a hozzáállással van a gond:

És akkor még nem is beszéltünk arról, hogy szervezet legyen a talpán, akinek egyáltalán van megfelelő eljárásrendje arról, kinek és pontosan mit kellene csinálnia ilyen esetben? Én még nem láttam, de persze lehet, hogy nagyon nagy szervezetnél, ahol kivételesen elkötelezett IBIR menedzsment van, ott erre léteznek a megfelelő eljárásrendek – és a végrehajtáshoz szükséges képesség.

A mögöttem ülő tapasztalt SOC-os kollégával, illetve más résztvevőkkel arról beszélgettünk, hogy mit szólna a vállalat, ha a módszertannak megfelelően kezdenénk el eseményt kivizsgálni? – Alighanem egy óra után jönne a felülíró parancs: formázzátok le, nincs ere idő/pénz!

A tréningen az egyik gyakorlati feladat háttérsztorijában volt ennek azért nyoma, nem akármilyen felhasználó gépén, hanem „C-level” – azaz CEO, CIO, stb. felhasználó munkaállomásán kellett feltárni és elemezni a történteket.

Mindenképpen szükséges tehát a megfelelő szabályozás: nem mindegy, hogy Sanyi – a jómunkásembör, vagy Sándor - az ügyvezető kerül bajba. Ahogyan (elvileg) adatosztályozásnak is lennie kell, ugyanúgy létre kell hozni az ezközök/felhasználók besorolását, és a besorolásnak megfelelő IR és remediációs eljárásnak kell életbe lépnie egy biztonsági esemény bekövetkezésekor.

Á, a francba az egésszel, egyszerűbb, ha leformázzuk!

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