Dane w tranzycie

Specjaliści ds. bezpieczeństwa wyróżniają zwykle trzy stany danych: przechowywane na dysku (dane w spoczynku), otwarte i przetwarzane przez aplikację (dane w użyciu) oraz przesyłane z jednego miejsca do drugiego (dane w tranzycie, nazywane też danymi w ruchu). Ten trzeci stan obejmuje wszystko, od wiadomości do współpracownika po kopię zapasową przenoszoną do innej lokalizacji.

Dane w tranzycie są narażone w szczególny sposób: opuszczają systemy kontrolowane przez organizację i przechodzą przez sieci, dostawców oraz urządzenia, nad którymi nie ma ona władzy. Dlatego programy ochrony danych traktują je jako osobny problem z własnymi zabezpieczeniami, a nie skutek uboczny ochrony nośników.

Dane firmowe wędrują kilkoma kanałami i każdy zawodzi na swój sposób. Najstarszy jest e-mail: wiadomość może przejść przez kilka serwerów, zanim dotrze do adresata, a monitorowanie poczty widzi ją wyraźnie tylko wtedy, gdy znajduje się jeszcze w systemach firmy.

Podstawowym zabezpieczeniem jest TLS, czyli protokół stojący za HTTPS oraz wieloma bezpiecznymi połączeniami poczty i transferu plików. Zastąpił on starszy protokół SSL, a przebieg jest w większości aplikacji taki sam.

1. 1

   Uzgodnienie

   Klient i serwer ustalają wersję protokołu oraz zestaw algorytmów szyfrowania.

2. 2

   Uwierzytelnienie

   Serwer przedstawia certyfikat, a klient sprawdza go w zaufanych urzędach certyfikacji.

3. 3

   Wymiana kluczy

   Obie strony wyznaczają wspólne klucze sesji, nigdy nie wysyłając ich jawnie.

4. 4

   Ochrona ruchu

   Dane są szyfrowane i opatrzone kontrolą integralności, więc każda zmiana po drodze zostanie wykryta.

Anexet obserwuje dane w tranzycie na stacji roboczej dzięki agentom oraz dzięki kontroli ruchu sieciowego i stron internetowych. Ekran profilu pokazuje, które protokoły są przechwytywane i czy obejmuje to ruch szyfrowany, a ekran certyfikatów, jak sesje szyfrowane stają się czytelne do analizy.

1 / 2

• 
• 

Szyfrowanie odpowiada na jedno pytanie: czy ktoś na trasie może odczytać lub zmienić dane? Nie pyta, czy nadawca w ogóle powinien je wysyłać. W tej luce dochodzi do większości przypadków eksfiltracji danych, bo pracownik wgrywający plik przez HTTPS korzysta z całkowicie bezpiecznego połączenia.

Awarie rzadko wynikają ze słabych algorytmów. Wynikają z założeń, a shadow IT pogarsza ostatnie z nich, bo niezatwierdzone usługi dodają miejsca docelowe, których nikt nie sprawdził.

• Zaufanie do sieci wewnętrznej i pozostawianie ruchu między serwerami w postaci jawnej
• Wyłączanie weryfikacji certyfikatów, by pozbyć się błędu, co znosi ochronę przed podszywaniem się
• Utrzymywanie starych protokołów, takich jak FTP czy HTTP bez szyfrowania, bo dotąd nic się nie zepsuło
• Założenie, że poczta jest szyfrowana end-to-end, gdy szyfrują tylko niektóre odcinki trasy
• Uznawanie HTTPS do dowolnego celu za bezpieczne, także do prywatnych usług i usług niezatwierdzonych

Większość ram bezpieczeństwa i ochrony prywatności oczekuje ochrony danych podczas przesyłania, choć każda formułuje to inaczej. RODO wymaga odpowiednich środków technicznych i wymienia szyfrowanie jako przykład, HIPAA Security Rule zawiera standard bezpieczeństwa transmisji, a PCI DSS wymaga silnej kryptografii, gdy dane kart płatniczych przechodzą przez otwarte sieci publiczne.

W audycie liczą się dowody: którymi kanałami płyną dane regulowane, które z nich są szyfrowane i co dzieje się, gdy któryś nie jest. Aktualna mapa przepływów danych i sprawnie działające zarządzanie zgodnością pozwalają odpowiedzieć na te pytania szybko.

Zacznij od ustalenia, którędy naprawdę płyną dane poufne i regulowane, potem zaszyfruj to, co nadal wędruje jawnie, i kontroluj to, co wychodzi kanałami szyfrowanymi. Szyfrowanie zamyka drogę osobom z zewnątrz, a system DLP obejmuje drogę, którą legalnie korzystają pracownicy.