DLP systémy lze kvalifikovat z řady nejrůznějších pohledů, jedním z těch základních je rozdělení na síťová DLP (Network DLP) a DLP koncových bodů (Host based DLP).
Síťová DLP
Tyto produkty jsou často označovány jako bránové systémy a obvykle představují samostatné zařízení, instalované v podnikové síti u připojení do internetu. Provádějí analýzu procházející komunikace a vyhledávají transakce, které obsahují předem označené informace. Typicky sledovanou komunikací je elektronická pošta, popřípadě komunikace prostřednictvím protokolů ftp, http nebo https.
Síťové DLP systémy jsou relativně jednodušší na instalaci a obvykle nabízejí nižší TCO náklady na vlastnictví než řešení DLP koncových bodů. Jistou nevýhodou některých komerčních řešení je nutnost kombinace s proxy systémy pro blokování DLP incidentů: síťové DLP funguje jako detekční mechanismus, vlastní zablokování transakce, klasifikované jako neoprávněné, musí pak provést připojená proxy, což zvyšuje celkové nutné náklady. Již dnes ovšem existují systémy, které se integrují s bezpečnostními branami ve formě softwarového modulu.
DLP koncových bodů
V tomto případě se jedná o klienty běžící na koncových stanicích – počítačích a serverech. DLP systémy koncových bodů, stejně jako síťové verze DLP, kontrolují komunikaci mezi interními skupinami uživatelů a mezi interními a externími subjekty. Mohou kontrolovat e-mailovou komunikaci, instant messaging atd.
Další výhodou DLP systémů koncových bodů je schopnost kontroly přístupu na fyzická zařízení (externí disky, CD-DVD mechaniky, flash disky, mobilní komunikační zařízení a přehrávače médií s vlastní pamětí), stejně jako schopnost kontrolovat fyzické komunikační porty koncových stanic. Patří mezi ně také řešení pro šifrování disků (Full Disk Encryption) či souborů a složek na pevných discích (File and Folder Encryption).
Zatímco u síťových DLP systémů administrátoři spravují obvykle jednotky zařízení, u řešení pro koncové stanice to jsou obvykle stovky až tisíce počítačů. Naprostou nutností u tedy takových systému efektivní centralizovaná správa.
Čeho je vhodné se vyvarovat
1. Administrativní náročnost řešení DLP incidentů
Počítačové systémy jsou velmi dobré ve vyhledávání specifických dat, ale mají značné problémy s identifikováním dat v odpovídajícím kontextu. Tradiční DLP systémy generují mnoho incidentů a vystavují bezpečnostní administrátory nutnosti procházet citlivá interní data, která mohou obsahovat osobní údaje, údaje o platech zaměstnanců, o kontraktech a podobně.
Řešení DLP incidentů obvykle představuje komplikovaný administrativní proces složený z řady časově náročných kroků (viz tabulka ukazující řešení takového incidentu). Je nutné si uvědomit, že typické DLP řešení generuje desítky až stovky incidentů týdně.
Důsledkem je, že většina velkých podnikových implementací končí po určité době v monitorovacím módu a pouze sbírá informace pro potřeby pozdější forenzní analýzy.
Z uvedených informací vyplývá, že možným zapojením koncových uživatelů do procesu identifikace DLP incidentů lze velmi efektivně snížit počet tzv. falešných poplachů a tím výrazně ulehčit práci bezpečnostních administrátorů. Současně tak lze odstranit nutnost vystavení administrátorů citlivým datům.
Příkladem může být technologie, jež umožňuje poslat informace odesílateli při identifikaci DLP události a požádat ho o validaci, zda se jedná o legitimní přenos interních dat, nebo zda došlo skutečně k omylu. Uživatel třeba v rychlosti zadává adresu do e-mailové zprávy a funkce automatického doplňování mu nabídne dříve použité adresy - může snadno vybrat omylem jinou adresu, která začíná podobně jako původně zamýšlená. Tento častý omyl se jistě stal už prakticky každému; jeho dopad může ovšem být kritický.
Následující případ se stal v září 2009. Zaměstnanec společnosti Rocky Mountain Bank byl požádán klientem o zaslání svých klientských dat na svou veřejnou e-mailovou adresu na Googlu. Zaměstnanec omylem odeslal data na jinou e-mailovou adresu a navíc mimoděk vložil do zprávy soubor s daty dalších 1 325 zákazníků. Rocky Mountain Bank pak žádala firmu Google o zveřejnění identity majitele dané e-mailové adresy, ale nebylo jí vyhověno. Celá kauza tak nakonec skončila u soudu.
Celý případ by ale mohl vypadat jinak. Zaměstnanec by odeslal e-mail na externí adresu, což by bylo identifikováno jako DLP incident, zároveň by systém identifikoval, že zpráva obsahuje přílohu, dokument s větším počtem zákaznických záznamů. Odesílaná zpráva by byla uložena do karantény a zaměstnanec by dostal zprávu o tomto incidentu se zvýrazněnými informacemi o tom, co není v souladu s bezpečnostní politikou. Po kontrole obsahu by se mohl rozhodnout zprávu smazat nebo potvrdit její odeslání.
Zapojení uživatelů do rozhodovacího procesu DLP technologie nemá jen dopad na snížení počtu incidentů, které musí řešit bezpečnostní administrátor, ale má i školící účinek. Naprostá většina DLP incidentů je neúmyslných. V mnoha případech zaměstnanci nejsou schopni správně identifikovat citlivost odesílaných dat. Jejich zapojení do procesu rozhodování umožňuje poskytnout jim informace o tom, že jejich jednání není v souladu s firemní bezpečnostní politikou. Navíc budou vědět, že jejich rozhodnutí data odeslat bude zaznamenáno v logu – a tedy být použito v případě řešení bezpečnostního incidentu a vést k postihu.
2. Časová náročnost implementace
Řada klasických DLP systémů nabízí kvalitní technologie, ale dodává se ve formě rámcového řešení (framework) bez definované bezpečnostní politiky. Takové řešení je vhodné pro skutečně velké organizace, které mají specializované týmy bezpečnostních pracovníků, schopných definovat bezpečnostní politiku.
Ve většině případů však stejně nastupuje časově náročná a nákladná fáze integrace do podnikového prostředí formou externího integrátora, kdy délka implemntačníého procesu bývá často v rozmezí 12-24 měsíců. Některé DLP systémy také mají problémy s lokalizací a nedají se vhodně implementovat do neanglického prostředí.
Produkty vhodné pro rychlé a finančně nenáročné nasazení by měly obsahovat předdefinovanou politiku na bázi tzv. „best practises“, zejména politiky vycházející z požadavků norem jako SOX, HIPPA nebo PCI DSS a možnost jednoduché adaptace na cizojazyčná prostředí.
Důležitá je i flexibilita při tvorbě datových struktur (datové typy představující informace, které jsou vyhledávány v přenášených zprávách a slouží k identifikaci chráněných dat), která přináší velkou nezávislost na dodavateli technologie a externích integrátorech.
3. Minimalizace falešných poplachů
Falešný poplach je incident, který ve skutečnosti není bezpečnostním incidentem. DLP systémy, které generují velké množství takovýchto událostí, jsou velmi náročné na správu a ve většině případů končí dříve nebo později ve stavu monitoringu, protože velmi často dochází k blokování legitimní komunikace.
Moderní DLP řešení nabízejí analýzu založenou na více faktorech, možnost definice logických operátorů a podmínek a možnost skriptovacích jazyků pro definici specifických datových struktur (například identifikace rodných čísel). Taková řešení umožňují mnohem lépe definovat pravidla pro identifikaci DLP incidentů a tím minimalizovat právě takovéto falešné poplachy. Zde je opět nutnost podpory adaptace na lokální specifické datové struktury.
Závěrem
Problematika ochrany před ztrátou dat (DLP) je velmi rozsáhlá a obsahuje řadu technologických řešení. Vhodným doporučením je začít se síťovým DLP řešením a na koncových bodech začít s implementačně jednoduššími technologiemi, kam spadá enkrypce dat na pevných discích (Full Disk Encryption), enkrypce souborů a složek, enkrypce externích médií a ochrana komunikačních portů (Media Encryption).
Pro potřeby externích spolupracovníků a kontraktorů již dnes existuje velmi efektivní řešení bezpečného úložiště podnikových dat na kryptovaném USB disku s aplikací virtuální pracovní plochy, bezpečně oddělené od hostitelského počítače, a s integrovaným VPN klientem pro přístup do podnikové sítě. Podniková bezpečnostní politika tak může být efektivně implementovaná i na počítače, které nejsou v přímé správě podnikového IT, čímž se docílí požadované ochrany dat v lokálním i externím prostředí.
Autor pracuje jako Security Engineer Eastern Europe, Check Point Software Technologies.
Tento text vyšel v tištěném SecurityWorldu 2/2010.
PŘEDPLATNÉ
ČLÁNKY DO MAILU