Mire jó a DLP és mire nem?

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.

 

forcepoint-screen1.png

forcepoint-screen2.png

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

Kérdés: Ha Te lennél, hogyan probálnál adatot szivárogtatni/lopni a gonosz munkáltatódtól? Milyen ötleteitek vannak?