Nehézségek és kihívások

Az elindulás már rögtön eltévedés

Az adatszivárgás-elleni védelem nem csak magát a DLP technológiát jelenti (sőt, elsősorban nem egy DLP termék bevezetését jelenti), hanem olyan adminisztratív, humán és műszaki védelmi intézkedések összességét, amelyek együttesen csökkenthetik az adatszivárgás bekövetkezésének valószínűségét és a lehetséges kár mértékét.

Sajnos, ha valaki DLP technológia bevezetésére szánja el magát, gyakran úgy véli, elegendő egy szuper, modern és a presales szerint minden-ellen-is-védő új technológiát bevezetni és az majd megoldja minden gondját-baját. 

Ez sajnos semmilyen IT biztonsági eszközzel kapcsolatban sincs így, a DLP-vel kapcsolatban pedig pláne nem ez a helyzet. Nincs értelme addig DLP eszközbe beruházni, amíg a szervezet nem tart egy bizonyos IT biztonsági és információvédelmi érettségi szinten, hiányoznak alapvető információvédelmi kontrollok, nem folyamatszerűek az eljárások - és úgy általában véve is sok sebből vérzik a szervezet információvédelme. Ilyen alapra nem lehet várat építeni, akkor sem, ha néhány CISO is  befalazásra kerül. 

A másik alapvetően téves kiindulási pont, hogy a DLP majd megvédi a szervezet adatait attól, hogy ellopják. 

A DLP teljesen alkalmatlan arra, hogy a szándékos, pláne felkészült elkövetővel szemben védelmet jelentsen. A DLP rendszerek ugyanis nem erre vannak kitalálva, hanem a normál üzleti folyamatokban képesek kiváló hatékonysággal megvédeni a szenzitív, klasszifikált és védelemmel ellátott adatok bizalmasságát.

Azt lehet mondani, hogy a szándékos adatszivárgás/adatszivárogtatással szemben ha 20%-os hatékonyságot feltételezünk, akkor egy nagyon jól beállított rendszert van szerencsénk működtetni. Egy átlagos felhasználói tudással rendelkező személy tucatnyi módot találhat arra, hogy a DLP rendszer mellett is el tudjon vinni adatokat. 

A vétlen, illetve az üzleti folyamatok hibájából, helytelen adattovábbításokból fakadó, vagy gondatlan felhasználói magatartásból adódó adatszivárgások esetében egy jól beállított és megfelelően működtetett DLP rendszer nagyon sikeresen képes megakadályozni a szenzitív, klasszifikált és védelemmel ellátott adatok bizalmasságát.

Aki azért vásárol és vezet be DLP rendszert, mert azt hiszi, az majd megakadályozza, hogy a rosszindulatú támadók ellopják a szenzitív adatokat, az súlyosan csalódni fog. 

Közös lónak...

Nagyon megnehezíti a DLP projekt sikerre vitelét, hogy igazából senki nem akar egy ilyen megoldást a nyakába venni. A DLP bevezetése és pláne az üzemben tartása és működtetése nagyon sok erőforrást igényelhet, így amelyik terület vagy vezető megteheti, az nagyon gyorsan fedezékbe bújik és beássa magát, ahogy valaki kimondta hogy "DLP bevezetés".

Már az adatgazdák kijelölése sem egyszerű dolog (ott, ahol ez nem csak fogalomként létezik), kis túlzással azt lehet mondani, hogy azok lesznek adatgazdák, akik késve érkeztek a meetingre. 

A DLP bevezetésen több területnek, közösen kell dolgoznia. A DLP ugyanis nem az IT felelőssége, és nem is csak az IT biztonság felelőssége. A bevezetésben az IT, IT biztonság, információvédelem, belső ellenőrzés, területi vezetők, adatgazdák - és persze külsős tanácsadók vesznek részt, és ha nincsen megfelelően megszervezve a projekt és mindenki elugrik a felelősség elől, vagy az erőforrásait védve hátvédharcot folytat, akkor a projekt egy drága, időrabló és védelmi értékét tekintve a faluvégen, a pestisjárvány ellen földbe szúrt vasvilla hatékonyságával fog felérni. 

Adatvagyonleltár és adatklasszifikáció hiánya

A DLP nem csodaszer. Csak akkor tudja (megfelelő üzemi körülmények között) biztosítani a szenzitív adatok bizalmasságát, ha tudja, milyen adatokat, milyen csatornában, hova, mikor és kinek továbbítva kell megvédenie. 

Ehhez rendelkezésre kell(ene) állnia egy tárolási szintig tartó adatvagyon leltárnak, azaz például egy fájlszerver esetében minden mappa minden állományáról tudni kellene, hogy milyen adatok vannak benne tárolva. Ha ez a leltár nem áll rendelkezésre, a DLP rendszert nagyon nehéz lesz betanítani, rengeteg erőforrást fog a betanítás felemészteni. Ha pedig a DLP rendszer nincs megfelelően betanítva, akkor nem fogja tudni megvédeni az adatokat. 

Szintén nagyon fontos input az adattovábbítási leltár. A személyes adatokkal kapcsolatban ennek egyébként is rendelkezésre kellene állnia, már csak a GDPR miatt is, de hasonlóan fel kell mérni és dokumentálni kell az üzleti adatok továbbításait, azaz meghatározni, hogy milyen adatokat, milyen csatornában, hova, mikor és kinek továbbít a szervezet az üzleti folyamataiban. 

Ez a két pont ugyan nagyon hasonló, de a fájlszerver esetében ez data-at-rest, míg az adattovábbítások esetében data-in-motion állapotot jelent, amelyek ebből a tekintetből a DLP számára két külön metódus. 

Kidolgozatlan eseménykezelés

Ha a bevezetés alatt a szervezet nem fordít kellő gondosságot arra, hogy megtervezze, mi fog történni a DLP rendszerben keletkező eseményekkel, akkor a rendszer védelmi értéke súlyosan degradálódik. 

A DLP rendszerek a felügyelt csatornákban (email, web, USB, nyomtatás, stb) monitorozzák az adatforgalmat, és eseményt generálnak, ha olyan adatmozgást észlelnek, amely ütközik a szabályrendszerrel. Ez az ütközés nem feltétlenül jelent adatszivárgási incidenst. 

Megkülönböztethető a rendszerben az esemény és az incidens. Esemény lehet bármi, amelyre szabály illeszkedik, például, a felhasználó kiküld egy olyan levelet egy gmail.com címre, amelyben bankkártya adat, bankszámlaszám, ügyfél azonosító adatok  vannak. Ez nem feltétlenül incidens, hiszen az ügyintéző kiküldhetett egy dokumentumot az ügyfélnek, amelyben ezek az adatok megtalálhatók. Ez lehet egy üzleti folyamatból eredő, legitim adatmozgás. Ha ugyanez a felhasználó 22 olyan levelet küld ki, amelyben ugyanilyen adatok vannak, az sem feltétlenül incidens, hiszen ez a munkája, küldi a felhasználóknak a különféle értesítéseket. Azonban ha ezeket a leveleket hajnali három órakor küldi, az már nem feltétlenül üzleti folyamat, ezért ha a rendszer erre be van állítva, ezt az eseményt incidensnek fogja értékelni és riasztást ad, a leveleket blokkolja, stb. 

Látható, hogy csak annak ismeretében lehet valamit incidensnek nyilvánítani, ha ismerjük az üzleti folyamatokat és ezeket a folyamatokat leképezzük a DLP eszköz szabályrendszerébe. Ez a bevezetéskor nagyon alapos felmérést igényel, ha ez azonban nem történik meg, a DLP rendszerben nem események, hanem incidensek ezrei fognak minden nap megjelenni. 

A DLP rendszerek képessége, hogy bizonyos eseményeket automatikusan minősíthetnek különféle súlyú incidensnek. Azonban mi történik azokkal az eseményekkel, amelyekre nem készültek ilyen automatikus kiértékelő szabályok? Azokat bizony valakinek időnként (lehetőleg minél gyakrabban) ellenőriznie kell, meg kell vizsgálnia az eseményeket és ha szükséges, azokat manuálisan kell incidensnek jelölni és elindítani az incidenskezelési folyamatot. 

Egy DLP audit során az első, hogy betekintünk a DLP rendszerbe, és sajnos sok esetben ezernyi, akár százezernyi lekezeletlen eseményt szoktunk találni. Ez megmutatja az auditor számára, hogy az adatszivárgás-elleni védelem menedzseletlen és a DLP rendszer védelmi értéke megkérdőjelezhető, hiszen hiába jelez a rendszer, hiába riaszt, ha nem történik meg a beavatkozás, az esemény- vagy incidenskezelés. 

A bevezetéskor meg kell határozni, hogy milyen eseményeket kinek kell kezelnie és adott esetben incidensnek nyilvánítania, hogyan történik a helyettesítése az eseménykezelőknek, illetve hogyan történik az incidensek kivizsgálása és kezelése. 

Rögös az út

Ez tényleg csak néhány alapvető probléma, amelyektől azonban jelentősen függ a DLP bevezetés és fenntartás sikere. Egy DLP rendszert nem lehet magára hagyni, erőforrást kell áldozni a működtetésre - amely azonban nem az IT-jellegű üzemeltetést jelenti. A DLP rendszerrel a legtöbb esetben az adatgazdáknak kell foglalkozniuk, mert a leggyakrabban ők a megfelelő személyek arra, hogy eldöntsék, a jelzett esemény csak egy üzemszerű folyamat eredménye, vagy pedig adatszivárgási incidensre figyelmeztet a rendszer. 

Az eseménykezelőknek napi szinten foglalkoznia kell a rendszerrel, át kell tekinteni az eseményeket, ez pedig nem az IT feladata és nem is az IT biztonság tevékenysége. Olyan személyeknek kell tehát működtetnie a rendszert, akik ismerik a saját területük adatait, tisztában vannak az üzemi folyamatokkal és el tudják dönteni, hogy amit látnak, az normális, vagy egy olyan anomália, amelyet ki kell vizsgálni.