Ruch szyfrowany
Analiza zaszyfrowanego ruchu bez odszyfrowania
Analiza zaszyfrowanego ruchu wykrywa zagrożenia w ruchu sieciowym szyfrowanym TLS bez jego odszyfrowania, na podstawie tego, co pozostaje widoczne: kto z kim się łączy, kiedy, jak często, ile danych przepływa i jakie parametry ma handshake TLS. Pozwala wykryć beaconing C2 i nietypowe transfery danych; nie pozwala zobaczyć treści sesji.
Fakt, od którego warto zacząć
TLS 1.3 (RFC 8446, IETF, sierpień 2018) szyfruje wszystkie komunikaty handshake'u po ServerHello, w tym certyfikat serwera, i usuwa statyczną wymianę kluczy RSA. Pasywny sensor z kopią klucza prywatnego serwera nie odszyfruje już sesji; odszyfrowanie wymaga proxy przechwytującego ruch albo kluczy sesji wyeksportowanych z urządzeń końcowych.
Źródło: RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018 (section 1.2)
Co NetSenX robi już dziś
- Nigdy nie odszyfrowuje ruchu: nie trzeba uruchamiać proxy przechwytującego ani instalować certyfikatu przechwytującego na urządzeniach.
- Wykrywa beaconing C2 i nietypowe transfery wychodzące w ruchu szyfrowanym na podstawie czasu, wolumenu i celów połączeń, a od planu Starter także handshake'u TLS. Handshake jest widoczny tylko tam, gdzie agent przechwytuje pakiety: na Linuksie lub jako czujnik na porcie SPAN albo TAP, nie w trybie podstawowym używanym na macOS.
- Na monitorowanym hoście agent odczytuje nazwę serwera i parametry z handshake'u TLS oraz odpowiedzi na zapytania DNS, aby opisać każde połączenie nazwą usługi, do której prowadzi. Nie odczytuje zaszyfrowanej treści sesji.
- Wyjaśnia każdy alert prostym językiem, wymieniając cechy ruchu, które wpłynęły na jego ocenę, w każdym planie.
Czego NetSenX nie robi
Bez odszyfrowania NetSenX nie widzi, co jest wewnątrz sesji: złośliwego pliku pobranego przez HTTPS, treści e-maila ani zawartości wysyłanego pliku. Ten obszar obejmują ochrona punktów końcowych (EDR) i ochrona poczty. Jeśli wymagana jest inspekcja treści, potrzebne jest narzędzie odszyfrowujące ruch, razem z planem postępowania z odszyfrowanymi danymi.
Pytania kupujących
Czy NDR wykrywa zagrożenia w ruchu szyfrowanym bez odszyfrowania?
Tak, na podstawie metadanych. Czas, wolumen, cele połączeń i handshake TLS pozostają widoczne, gdy treść jest zaszyfrowana, więc beaconing do serwera C2 i nietypowe transfery danych da się wykryć bez łamania szyfrowania. Niewidoczna pozostaje treść sesji.
Co NetSenX odczytuje z zaszyfrowanego połączenia?
Metadane przepływu (kto z kim się łączy, kiedy, jak często i ile danych przepływa) oraz kilka pól protokołów: nazwę serwera i parametry z handshake'u TLS oraz odpowiedzi na zapytania DNS. NetSenX nigdy nie odszyfrowuje sesji i nie odczytuje jej zaszyfrowanej treści.
Dlaczego nie odszyfrowywać ruchu TLS do inspekcji?
Odszyfrowanie daje wgląd w treść, ale oznacza utrzymywanie punktu przechwytywania, który przechowuje klucze, instalację certyfikatu przechwytującego na każdym urządzeniu i przetwarzanie odszyfrowanych treści, które mogą zawierać dane osobowe. Od TLS 1.3 pasywny sensor nie odszyfruje już sesji za pomocą kopii klucza prywatnego serwera.
Czy metadane sieciowe są danymi osobowymi w rozumieniu RODO?
Mogą być. Trybunał Sprawiedliwości UE orzekł w sprawie Breyer (C-582/14, 19 października 2016 r.), że dynamiczny adres IP może stanowić dane osobowe. NetSenX publikuje umowę powierzenia przetwarzania danych (art. 28 RODO) i przechowuje dane klientów w UE.
Źródła
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018 (section 1.2)
- Court of Justice of the EU, Case C-582/14 (Breyer), judgment of 19 October 2016 — EUR-Lex
Ta strona ma charakter ogólnoinformacyjny i nie stanowi porady prawnej. Swoje obowiązki warto potwierdzić we właściwym organie krajowym lub u doradcy prawnego.
Powiązane strony
Wypróbuj NetSenX we własnej sieci
Zacznij od planu Free dla maksymalnie 3 urządzeń albo umów 20-minutowe demo.