Inwentaryzacja kryptografii z ruchu sieciowego

Dużą część inwentaryzacji kryptografii można zbudować pasywnie, odczytując handshake'i, które przechodzą przez sieć: jakich wersji TLS i SSH używa każdy serwer i klient, jakie grupy wymiany kluczy oferują i uzgadniają, jakie zestawy szyfrów, a tam, gdzie handshake je pokazuje, jakie algorytmy klucza publicznego i długości kluczy. Nie widać kryptografii, która nigdy nie przechodzi przez monitorowane łącze. Widok z sieci jest więc najszybszym sposobem, żeby objąć każde urządzenie, także te, których nikt nie spisał, i trzeba go uzupełnić inwentaryzacją certyfikatów i odpowiedziami dostawców. Każda postkwantowa mapa drogowa, zaczynając od unijnej, stawia tę inwentaryzację na pierwszym miejscu.

Co zawiera inwentaryzacja kryptografii

Użyteczna inwentaryzacja odpowiada dla każdego systemu: jakimi protokołami i wersjami się posługuje, jakich algorytmów wymiany kluczy i podpisu używa i o jakich długościach kluczy, jakie ma certyfikaty i kto je wydał, która biblioteka lub produkt dostarcza kryptografię, kto odpowiada za system i jak długo dane, które chroni, muszą pozostać tajne. Opublikowana w formie czytelnej dla maszyn nazywana jest często CBOM (cryptography bill of materials); taki format definiuje standard CycloneDX. Nie chodzi o sam dokument, tylko o decyzje, które umożliwia: co migrować najpierw i o co pytać którego dostawcę.

Co pokazuje sieć bez odszyfrowywania

Wersje protokołów. TLS 1.0 i 1.1, SSH 1 i inne przestarzałe wersje widać na początku każdego połączenia.
Oferowana i wybrana wymiana kluczy. W TLS 1.3 ClientHello wymienia obsługiwane przez klienta grupy i udziały kluczy, a ServerHello podaje grupę wybraną przez serwer. Widać więc wprost, czy połączenie użyło grupy klasycznej, takiej jak X25519 czy P-256, czy hybrydowej postkwantowej X25519MLKEM768. SSH w ten sam sposób jawnie ogłasza swoje metody wymiany kluczy.
Zestawy szyfrów. Szyfr symetryczny i funkcja skrótu, na które umawia się każde połączenie, co ujawnia pozostałości takie jak 3DES czy RC4.
Klucze i certyfikaty tam, gdzie idą jawnie. W TLS 1.2 łańcuch certyfikatów serwera jest wysyłany bez szyfrowania, więc widać jego algorytm podpisu i długość klucza. Klucze hosta SSH są wymieniane jawnie. W TLS 1.3 certyfikat jest zaszyfrowany, więc dla takich serwerów potrzebny jest skan albo inwentaryzacja certyfikatów.
Słabe klucze. Klucze publiczne zebrane z handshake'ów można porównać między sobą. Klucze RSA, które mają wspólny czynnik pierwszy, są po prostu złamane i są klasycznym śladem urządzenia ze słabym generatorem liczb losowych, zwykle urządzenia sieciowego albo systemu wbudowanego.
Każde urządzenie w segmencie. Drukarki, kamery, bramy OT, urządzenia sieciowe i stare serwery są objęte tak samo jak zarządzane laptopy, czyli tam, gdzie narzędzia oparte na agentach są ślepe.

Czego nie widać

Kryptografii wewnątrz aplikacji i baz danych, na przykład szyfrowania pól albo wywołania biblioteki we własnym kodzie.
Kluczy i certyfikatów zapisanych na dyskach, w magazynach kluczy albo w modułach HSM.
Podpisywania kodu i aktualizacji oprogramowania, chyba że sprawdzasz sam kanał aktualizacji.
Zaszyfrowanych kopii zapasowych i archiwów.
Ruchu w segmentach, których nie obserwuje żaden czujnik, i połączeń, które nigdy nie przechodzą przez monitorowane łącze.
Certyfikatu w większości połączeń TLS 1.3, jak wspomniano wyżej.

Jak uzupełnić luki

Połącz widok z sieci z trzema innymi źródłami: inwentaryzacją certyfikatów z urzędu certyfikacji, narzędzi zarządzania albo aktywnego skanu; wykazami komponentów oprogramowania (SBOM) i dokumentacją dostawców używanych produktów; oraz ankietami dla dostawców z pytaniem, z datami, kiedy każdy produkt będzie obsługiwał hybrydową postkwantową wymianę kluczy i podpisy postkwantowe. Potem uszereguj systemy według nierówności Moski, jak wyjaśnia przewodnik po kryptografii postkwantowej, i powtarzaj pomiar w sieci po każdej zmianie, żeby potwierdzić, że zadziałała.

Gdzie pasuje NetSenX

To właśnie robi NQCI, inwentaryzacja kryptografii NetSenX. Jest w wersji zapoznawczej, widoczna w każdym planie i aktywna od planu Pro, z włączonym czujnikiem przechwytywania pakietów na agencie Linux albo czujnikiem na porcie SPAN lub TAP; podstawowy tryb macOS nie widzi handshake'ów. Pokazuje, które połączenia w monitorowanym ruchu używają wymiany kluczy podatnej na komputery kwantowe, a które już hybrydowej postkwantowej, oznacza słabe klucze publiczne i zapisuje zmiany w czasie. Nie zmienia żadnej kryptografii i nikomu nie zapewnia zgodności; pokazuje, w jakim miejscu jesteś.

Źródła

Autor: zespół NetSenX, TriStiX S.L. Pytania: info@netsenx.com.