Sophos NDR: wybór platformy i prawidłowe wymiarowanie sensora

Sophos NDR można uruchomić jako appliance wirtualny na platformach VMware ESXi, Microsoft Hyper-V, AWS lub Nutanix, a także na certyfikowanym sprzęcie Dell, NUC i OnLogic. Wyboru dokonuje się przed wdrożeniem: sensory wirtualne i chmurowe wymiaruje się na podstawie przepustowości oraz liczby pakietów i przepływów, natomiast w przypadku sprzętu obowiązują wyłącznie certyfikowane modele i przypisane im poziomy wydajności.

Szybka decyzja: W przypadku dedykowanego wirtualnego sensora NDR obsługującego do 500 Mbit/s, 70'000 pakietów na sekundę i 1'200 przepływów na sekundę wystarcza konfiguracja standardowa. Dla wartości do 1 Gbit/s, 300'000 pakietów na sekundę i 4'500 przepływów na sekundę przewidziano 8 vCPU. Jeśli choć jeden parametr przekracza te wartości, ruch trzeba rozdzielić między kilka wirtualnych appliance. Przy większej przepustowości lub gdy wymagany jest sensor fizyczny, certyfikowany sprzęt dobiera się na podstawie faktycznie zmierzonego obciążenia ciągłego i szczytowego.

Licencja i podstawy planowania

Integracja wymaga pakietu licencyjnego Sophos Network Detection and Response integration license pack. Sophos ustala zakres licencji NDR na podstawie łącznej liczby użytkowników i serwerów w organizacji. Oprogramowanie dla appliance wirtualnych jest zawarte w licencji; w jej ramach można wdrożyć tyle sensorów NDR, ile potrzeba. Ma to znaczenie, gdy większe środowisko trzeba rozdzielić między kilka sensorów ze względu na udokumentowane limity maszyn wirtualnych.

Przed wyborem platformy należy zebrać następujące wartości:

• maksymalną i ciągłą przepustowość ruchu, który ma być faktycznie kopiowany,
• liczbę pakietów na sekundę i przepływów na sekundę w tym samym okresie,
• przepustowość przełącznika lub portu lustrzanego, z którego sensor otrzymuje ruch,
• planowaną liczbę i rozmieszczenie sensorów,
• dodatkowe integracje Log Collector, które mają działać na tym samym appliance,
• dostępną mikroarchitekturę CPU, flagi CPU, pamięć RAM i przestrzeń dyskową,
• obsługiwaną platformę wirtualizacji lub dokładny certyfikowany model sprzętu.

Sama przepustowość łącza internetowego nie stanowi wystarczającej podstawy do wymiarowania. Sensor przetwarza ruch, który jest do niego kopiowany. Dlatego pomiary należy wykonać w planowanym punkcie kopiowania ruchu i udokumentować zarówno obciążenie ciągłe, jak i szczytowe.

Wybór platformy

Appliance wirtualny lub chmura

Appliance wirtualny jest odpowiedni, jeśli jedna z przetestowanych platform jest już dostępna, obciążenie mieści się w limitach maszyny wirtualnej lub można je racjonalnie rozdzielić między kilka sensorów. Obsługiwane są:

• VMware ESXi,
• Microsoft Hyper-V,
• Amazon Web Services (AWS),
• Nutanix.

W przypadku AWS specyfikacja techniczna Sophos NDR wskazuje typ instancji c5n.2xlarge. Konkretne mechanizmy wdrażania, interfejsy sieciowe i ustawienia kopiowania ruchu opisano w odpowiedniej instrukcji wdrożenia i nie wynikają one z decyzji dotyczącej doboru rozmiaru.

VMware Cloud nie jest obsługiwany. W przypadku ESXi i Hyper-V obowiązują ponadto opisane niżej wymagania dotyczące wersji i CPU. Dostępne wymagania nie zawierają natomiast wspólnej macierzy wersji dla AWS i Nutanix, dlatego wymagania wdrożeniowe trzeba sprawdzić w dokumentacji odpowiedniej platformy.

Certyfikowany sprzęt

Sprzęt jest właściwym wyborem, gdy potrzebny jest dedykowany sensor fizyczny albo gdy poziom wydajności certyfikowanego urządzenia odpowiada zmierzonemu obciążeniu. Sophos obsługuje NDR na sprzęcie wyłącznie w przypadku certyfikowanych systemów. Nie można na tej podstawie uznać za obsługiwane ogólnych serwerów x86, podobnych wariantów modeli ani samodzielnie złożonych systemów.

Certyfikowane są systemy z następujących rodzin:

• Dell,
• NUC,
• OnLogic.

Znaczenie ma nie tylko nazwa producenta. Przed zakupem dokładny model należy porównać z aktualną specyfikacją Certified hardware specifications for NDR. Instalacja, obraz dysku i czynności właściwe dla producenta następują dopiero po podjęciu decyzji o wyborze modelu.

Wymiarowanie sensorów wirtualnych i chmurowych

Minimalne zasoby

W przypadku ESXi i Hyper-V obowiązują następujące minimalne zasoby:

• 4 CPU,
• 16 GB RAM,
• 160 GB przestrzeni dyskowej.

Plik OVA dla VMware jest wstępnie skonfigurowany z tymi minimalnymi wartościami dla Sophos NDR i integracji Log Collector. AWS korzysta z podanego wyżej typu instancji. Wykorzystane źródło wymagań nie podaje w tym miejscu osobnych minimalnych zasobów dla Nutanix. Minimalne zasoby nie stanowią jednak gwarancji wydajności. Przy wyborze między konfiguracją standardową, 8 vCPU i kilkoma appliance należy uwzględnić wszystkie trzy parametry ruchu.

Wartości graniczne wspólnie definiują klasę obciążenia. Sensor obsługujący 400 Mbit/s, ale 100'000 pakietów na sekundę, nie mieści się już w pełni w klasie Średnia. Jeśli wartości przekraczają limity klasy Wysoka, Sophos przewiduje rozmieszczenie w sieci kilku appliance wirtualnych; źródła nie dają podstaw do użycia pojedynczej, większej maszyny wirtualnej powyżej tego limitu.

Specyfikacja techniczna ogranicza przepustowość wirtualnego sensora NDR do maksymalnie 1 Gbit/s. Wartość ta nie znosi niższych limitów liczby pakietów i przepływów.

Kontrola CPU i hiperwizora

Poniższe wymagania dotyczące mikroarchitektury i flag odnoszą się do systemu, na którym działa maszyna wirtualna. W przypadku ESXi, Hyper-V i innych samodzielnie zarządzanych hostów maszyn wirtualnych flagi CPU pdpe1gb i avx2 muszą być dostępne w maszynie wirtualnej. Flaga pdpe1gb jest wymagana do przechwytywania pakietów, a avx2 do funkcji uczenia maszynowego. Większa liczba vCPU nie rekompensuje braku flag.

W przypadku AWS sprawdza się zamiast tego obsługiwany typ instancji wraz z wymaganiami wdrożeniowymi AWS; appliance fizyczne weryfikuje się na podstawie dokładnego certyfikowanego modelu i jego zatwierdzonej konfiguracji. Nie wynika z tego wymóg dodatkowego ręcznego potwierdzania flag ani dla AWS, ani dla certyfikowanego sprzętu.

Sophos dokumentuje następujące mikroarchitektury CPU:

• Intel: Skylake Generation 6, Kaby Lake Generation 7, Coffee Lake Generation 8, Coffee Lake Refresh i Cascade Lake Generation 9, Comet Lake Generation 10, Cannon Lake/Palm Cove Generation 10, Ice Lake/Sunny Cove Generation 10, Rocket Lake/Cypress Cove Generation 11, Alder Lake/Golden Cove Generation 12 oraz Raptor Lake/Raptor Cove Generation 13.
• AMD: Naples i Great Horned Owl z Zen 1, Rome z Zen 2, Milan z Zen 3 oraz Genoa z Zen 4.

Można również używać nowszych procesorów, o ile udostępniają obie wymagane flagi. Sophos informuje, że procesory wprowadzone na rynek od pierwszego kwartału 2015 roku powinny działać; mimo to o dopuszczeniu decyduje konkretne potwierdzenie obu flag w planowanej maszynie wirtualnej.

Dla hiperwizorów obowiązują następujące minimalne wersje i ograniczenia:

• VMware ESXi: wersja 6.7 Update 3 lub nowsza oraz VM Hardware Version 11 lub wyższa. W klastrze EVC należy wybrać Skylake generation or later. VMware Cloud nie jest obsługiwany.
• Microsoft Hyper-V: wersja 6.0.6001.18016 na Windows Server 2016 lub nowszym. Tryb Processor Compatibility Mode nie jest obsługiwany.

Wspólny appliance z integracjami Log Collector

Wartości maszyn wirtualnych dla klas Średnia i Wysoka dotyczą appliance, na którym działa wyłącznie Sophos NDR. Jeśli na tym samym urządzeniu hostowane są integracje Log Collector, planowanie rozpoczyna się od wymiarowania NDR, a następnie uwzględnia ich obciążenie. Udokumentowano następujące limity i skutki:

• Wszystkie integracje Log Collector na jednej maszynie wirtualnej mogą łącznie przyjmować maksymalnie 8'000 zdarzeń na sekundę.
• Integracja Log Collector przy wysokim obciążeniu wymaga około 400 MB RAM.
• Przy 4 CPU NDR wykorzystuje 2 CPU, a przy 8 CPU — 3 CPU. Inne integracje mogą mimo to korzystać z tych CPU i wpływać w ten sposób na wolumen ruchu, który NDR jest w stanie przetworzyć.
• Przy 16 GB RAM integracje Log Collector mogą łącznie wykorzystywać maksymalnie 2 GB, aby NDR zachował wystarczającą ilość pamięci.
• Log Collector działający z maksymalną częstotliwością zdarzeń wymaga na maszynie wirtualnej ze standardowymi 4 CPU mniej więcej takiej samej mocy obliczeniowej jak NDR przy średnim obciążeniu.

Dla obciążeń mieszanych nie istnieje jeden uniwersalny rozmiar. Jeśli można się spodziewać przekroczenia limitów NDR lub dostępnych zasobów, należy zaplanować dodatkowe appliance. W przypadku kilku integracji Log Collector przekraczających łącznie 8'000 zdarzeń na sekundę używa się kilku maszyn wirtualnych. Jeśli natomiast limit ten przekracza pojedyncza integracja, najpierw należy spróbować zmniejszyć liczbę zdarzeń w ustawieniach Syslog systemu źródłowego. Udokumentowane wartości orientacyjne nie uzasadniają arbitralnego przewymiarowania zasobów.

Wymiarowanie certyfikowanego sprzętu

Sophos określa wariant sprzętowy na podstawie przepustowości przełącznika, który dostarcza kopiowany ruch, oraz obciążenia ciągłego i szczytowego. Sensor NDR powinien mieć taką samą przepustowość jak przełącznik, z którego pochodzi kopiowany ruch. Poniższe zalecenia opierają się na typowej organizacji, w której 20 procent stanowią użytkownicy intensywni, 60 procent — użytkownicy typowi, a 20 procent — użytkownicy sporadyczni. Założono również korzystanie z VoIP, strumieniowania pewnej ilości materiałów wideo, przesyłania i pobierania dużych plików oraz serwerów aplikacyjnych i WWW.

Nazwy i poziomy wydajności służą wyłącznie do wstępnego wyboru. Zakup można zatwierdzić dopiero wtedy, gdy dokładny model i dokładna konfiguracja są wymienione w aktualnej specyfikacji Certified hardware specifications for NDR.

Dla każdego wiersza Sophos dokumentuje możliwe obciążenie szczytowe od dwóch do trzech razy większe od typowego. Ta wartość szczytowa nie zastępuje pomiaru i nie wolno jej mylić z poziomem wydajności. Przy dodatkowym intensywnym strumieniowaniu wideo i muzyki może być wymagany wyższy poziom; decyzję podejmuje się na podstawie zmierzonego obciążenia ciągłego i szczytowego oraz aktualnych limitów certyfikacyjnych. Jeśli użytkownicy korzystają głównie z poczty elektronicznej, odpowiedni może być niższy poziom, o ile zmierzone obciążenie ciągłe i szczytowe oraz liczba użytkowników mieszczą się w przewidzianych dla niego granicach.

Sama przepustowość i liczba użytkowników nie wystarczają do wyboru sprzętu. W aktualnej specyfikacji certyfikacyjnej należy dodatkowo sprawdzić maksymalną liczbę połączeń na sekundę oraz zatwierdzoną konfigurację CPU, RAM i ewentualnie gniazd procesora. Ma to szczególne znaczenie w przypadku ruchu generującego wiele połączeń. Przykładowo karta katalogowa Sophos NDR z 19 grudnia 2024 r. podaje dla dwóch konfiguracji R660 taką samą przepustowość nominalną, ale różne limity połączeń i zasobów:

Szczegółowe konfiguracje z karty katalogowej według stanu na 19.12.2024:

Dell R660, 2 gniazda

• Maks. przepustowość: 40 Gbit/s
• Maks. połączeń/s: 120'000
• CPU: 64
• RAM: 128 GB

Dell R660, 1 gniazdo

• Maks. przepustowość: 40 Gbit/s
• Maks. połączeń/s: 80'000
• CPU: 32
• RAM: 64 GB

Dell R650

• Maks. przepustowość: 20 Gbit/s
• Maks. połączeń/s: 40'000
• CPU: 24
• RAM: 64 GB

Dell R450

• Maks. przepustowość: 10 Gbit/s
• Maks. połączeń/s: 20'000
• CPU: 16
• RAM: 32 GB

Dell R350

• Maks. przepustowość: 4 Gbit/s
• Maks. połączeń/s: 8'000
• CPU: 8
• RAM: 32 GB

Intel NUC 13th Gen

• Maks. przepustowość: 2,5 Gbit/s
• Maks. połączeń/s: 4'000
• CPU: 12
• RAM: 32 GB

Te datowane wartości przedstawiają wszystkie techniczne parametry wymiarowania i pokazują znaczenie dokładnej konfiguracji, ale nie stanowią aktualnej macierzy zakupowej ani certyfikacyjnej. Brakujących wartości dla R360, R660xs, OnLogic i każdego innego wariantu nie wyprowadza się z podobnych modeli, lecz pobiera wyłącznie z aktualnej specyfikacji certyfikacyjnej.

Zalecenia sprzętowe są modelem obciążenia, a nie gwarancją dla każdego rozkładu ruchu. Strumieniowanie i duże przepływy kopii zapasowych generują znaczny wolumen; Sophos NDR jest zoptymalizowany pod kątem takiego ruchu strumieniowego i typu „Elephant Flow”, podczas gdy wiele zagrożeń jest wykrywanych w zwykłym ruchu przeglądarek i aplikacji. Dlatego profil użytkowników ocenia się razem z rzeczywistymi parametrami sieci.

Wymagania sieciowe przed wdrożeniem

Appliance wymaga połączeń wychodzących do uruchomienia i pobierania aktualizacji. Jeśli firewall obsługuje symbole wieloznaczne, Sophos dokumentuje następujące reguły dostępu:

Dostęp do yum.oracle.com jest opcjonalny; bez niego appliance korzysta z kopii lustrzanej repozytorium Sophos JFrog. Jeśli firewall nie obsługuje symboli wieloznacznych, nie wolno zastępować tej krótkiej tabeli listą domniemanych pojedynczych hostów. Należy wówczas skorzystać z aktualnej listy zależnej od regionu na stronie Sophos Appliance requirements.

Na Integration Appliance nie instaluje się Sophos Agent ani żadnego innego agenta chroniącego przed złośliwym oprogramowaniem. Aktualizacji systemu operacyjnego i zabezpieczeń również nie instaluje się ręcznie; zarządza nimi Sophos.

Weryfikacja i przekazanie decyzji

Przed wdrożeniem protokół planowania powinien zawierać co najmniej następujące punkty:

1. Platforma: ESXi, Hyper-V, AWS, Nutanix lub dokładny certyfikowany model sprzętu.
2. Okno pomiarowe: moment i czas trwania pomiaru oraz ciągłe i szczytowe wartości przepustowości, liczby pakietów i przepływów w planowanym punkcie kopiowania ruchu.
3. Wymiarowanie: wybrana klasa obciążenia lub poziom sprzętowy oraz najbardziej ograniczająca wartość graniczna; w przypadku sprzętu dodatkowo porównanie zmierzonej maksymalnej liczby połączeń na sekundę z aktualnym certyfikowanym limitem.
4. Zasoby zależne od platformy:
   • ESXi, Hyper-V i inne samodzielnie zarządzane hosty maszyn wirtualnych: vCPU, RAM, przestrzeń dyskowa, model CPU oraz widoczne w maszynie wirtualnej flagi pdpe1gb i avx2.
   • AWS: obsługiwany typ instancji c5n.2xlarge i wymagania dokumentacji wdrożeniowej AWS.
   • Certyfikowany sprzęt: dokładny certyfikowany model i zatwierdzona konfiguracja CPU, RAM oraz gniazd procesora.
5. Dodatkowe obciążenie: nazwy i oczekiwana liczba zdarzeń na sekundę dla wszystkich współdzielonych integracji Log Collector.
6. Sieć: planowane połączenia do zarządzania i kopiowania ruchu oraz potwierdzone reguły dostępu wychodzącego dla portów i domen.
7. Skalowanie: liczba i rozmieszczenie dodatkowych sensorów, jeśli jeden sensor wirtualny przekroczyłby limity klasy Wysoka.

Decyzja jest wiarygodna, jeśli każda zmierzona wartość mieści się w wybranym poziomie i spełnione są wymagania właściwe dla platformy. W przypadku samodzielnie zarządzanych hostów maszyn wirtualnych należą do nich hiperwizor, CPU i widoczne w maszynie wirtualnej flagi. W AWS znaczenie ma obsługiwany typ instancji wraz z wymaganiami wdrożeniowymi. W przypadku sprzętu dokładny model, konfiguracja CPU/RAM/gniazd procesora, przepustowość i maksymalna liczba połączeń na sekundę muszą odpowiadać aktualnej certyfikacji. Jeśli appliance jest współdzielony, trzeba dodatkowo uwzględnić liczbę zdarzeń na sekundę, pamięć RAM i wpływ integracji Log Collector na CPU.

Tworzenie obrazu, instalacja, rejestracja, Traffic Mirroring i pierwsza detekcja należą do kolejnych etapów wdrożenia i walidacji. Późniejszy stan Connected lub zielony wskaźnik stanu appliance potwierdza jedynie stan integracji; nie dowodzi ani pełnego pokrycia kopiowanym ruchem, ani prawidłowego działania wykrywania od początku do końca.

Ograniczenia udokumentowanego planowania

Źródła nie podają wzoru umożliwiającego obliczenie na podstawie liczby użytkowników, przepustowości lub zdarzeń niestandardowych zasobów CPU i RAM wykraczających poza wymienione poziomy maszyn wirtualnych. Powyżej limitów klasy Wysoka udokumentowanym rozwiązaniem jest zatem zastosowanie kilku appliance wirtualnych, a nie pojedynczej, spekulacyjnie powiększonej maszyny wirtualnej.

Tabele sprzętowe również nie zastępują aktualnej specyfikacji certyfikacyjnej. Zawierają wartości służące do wstępnego wyboru lub pochodzące z datowanej karty katalogowej, ale nie stanowią zatwierdzenia dla podobnie nazwanych serwerów, innych komponentów ani własnych systemów x86. Jeśli w przypadku sprzętu brakuje dokładnego modelu i zatwierdzonej konfiguracji albo nie ma wiarygodnych wartości ruchu i połączeń, platformy nie można jeszcze zatwierdzić do wdrożenia. To samo dotyczy samodzielnie zarządzanego hosta maszyn wirtualnych, jeśli wymagane flagi CPU nie są dostępne w maszynie wirtualnej.