Co w sieci?

Najmniej inwazyjną metodą, która jest często stosowana w pierwszej fazie wdrożenia DLP lub podczas testowania,- jest uruchomienie sniffera sieciowego. Zwykle podłączany jest on do SPAN portu na przełączniku lub w wielu przełącznikach, w zależności od ilości danych do przetworzenia. W mniejszych instalacjach sensor umieszczany jest tuż przed urządzeniem realizującym funkcje NAT w taki sposób, aby oprócz wychwycenia wycieku informacji można było ustalić jego źródło. Błędem jest zatem wpinanie sensora na przykład za firewallem a przed routerem brzegowym. Wówczas otrzymujemy zakłócony obraz, w którym jedynym źródłem wycieku jest sam firewall. Wpinanie do SPAN portu nie jest jedyną dostępną możliwością - SPAN port daje tylko możliwość podsłuchu, a o blokowaniu raczej nie może być mowy. Dlatego część rozwiązań może pracować w trybie inline - wpięte między monitorowane segmenty sieci. W ten sposób jest w stanie blokować ruch, który przez nie płynie, niemalże w czasie rzeczywistym.

Jak zwykle problemem w przypadku korzystania tylko i wyłącznie z sensorów sieciowych jest szyfrowanie ruchu. Stąd część producentów umożliwia zintegrowanie swojego sniffera ze standardowym serwerem proxy lub SSL proxy wykorzystywanym w organizacji. Dzięki temu otrzymujemy możliwość wglądu w ruch szyfrowany i nie musimy wprowadzać zmian w infrastrukturze.

Warto również upewnić się, że monitoringiem objęty został także ruch komunikatorów. Niektóre proxy mają wbudowaną obsługę IM, ale warto to zweryfikować. Także niektóre systemy ochrony poczty (np. Symantec Brightmail) mogą pełnić rolę proxy dla komunikatorów.

Sniffer sieciowy jest najczęściej dostarczany w postaci zwykłego Linuksa lub Windowsa z zainstalowaną odpowiednią biblioteką (np. WinPcap) i kartą sieciową pracującą w trybie "promiscuous". Niektórzy dają gotowe urządzenia, inni tylko oprogramowanie. W przypadku rozwiązań programowych warto pamiętać o dokładnym sprawdzeniu wymagań dotyczących sprzętu. Może się okazać, że są one dość egzotyczne i w zasadzie pasują tylko do kilku modeli serwerów. To z kolei może generować dodatkowe koszty związane z zakupem sprzętu, których chcieliśmy uniknąć, kupując oprogramowanie. Podsłuchane informacje są poddawane obróbce i procesowi dekodowania. Im więcej protokołów jesteśmy w stanie zdekodować, tym pełniejszy obraz ruchu uzyskamy. Najczęściej monitoringowi poddawany jest ruch HTTP, FTP i SMTP. Są także protokoły niestandardowe, których opisu narzędzie nie potrafi samo z siebie zdekodować. Dlatego też dobrze jest sprawdzić, czy będziemy mieli możliwość zdefiniowania własnych protokołów. Jeżeli nie mamy żadnego IM proxy, zapewne jednym z pierwszych kroków będzie uruchomienie obsługi GG, który jak na razie w standardowym kliencie nie jest szyfrowany.

Skoro jesteśmy przy ruchu sieciowym, warto też zaznaczyć, że niektóre rozwiązania DLP umożliwiają "nakarmienie" systemu danymi historycznymi, np. w postaci zapisanych wcześniej w Wireshark czy tcpdump sesji w formacie ".pcap".

Co poza siecią?

W bardziej rozbudowanych zastosowaniach, nie ograniczających się jedynie do ruchu sieciowego, rozwiązanie DLP musi objąć monitoringiem także bazy danych, udziały sieciowe, serwery, macierze czy komputery użytkowników. Tutaj sprawa znacznie się komplikuje. Skoro chcemy coś chronić nie opierając się jedynie na prostych metodach analizy, należy najpierw zindeksować wszystkie dokumenty.

Podstawowym problemem jest odnalezienie wszystkich miejsc, w których są one przechowywane. Stąd część produktów DLP jest wyposażonych w specjalizowane moduły, służące do wyszukiwania danych (najczęściej mają w nazwie słowo "discovery"). W przypadku części zasobów do zindeksowania wystarczą techniki zdalne, np. wskazanie udziału sieciowego, podłączenie do bazy za pośrednictwem konektora ODBC. Takie podejście ma zalety i wady. Niewątpliwą korzyścią jest brak konieczności instalacji jakiegokolwiek dodatkowego oprogramowania na zasobach. Niemniej jednak należy liczyć się z sytuacją, kiedy nie wszystkie informacje, pomimo dostępności zasobu, dadzą się zindeksować. Zdecydowaną wadą skanowania zdalnego jest również wzrost obciążenia sieci. Część rozwiązań pozwala na szczęście sterować intensywnością indeksowania, co z kolei może spowodować, że "obsłużenie" udziału z kilkoma TB danych potrwa tydzień.