Sophos NDR: scegliere la piattaforma e dimensionare correttamente il sensore

Sophos NDR può essere eseguito come appliance virtuale su VMware ESXi, Microsoft Hyper-V, AWS o Nutanix, nonché su hardware certificato di Dell, NUC e OnLogic. La scelta viene effettuata prima del deployment: i sensori virtuali e cloud vengono dimensionati in base a larghezza di banda, pacchetti e flussi; per l’hardware valgono esclusivamente i modelli certificati e i relativi livelli di capacità.

Decisione rapida: fino a 500 Mbit/s, 70'000 pacchetti al secondo e 1'200 flussi al secondo, per un sensore NDR virtuale dedicato è sufficiente la configurazione standard. Fino a 1 Gbit/s, 300'000 pacchetti al secondo e 4'500 flussi al secondo sono previste 8 vCPU. Se anche un solo valore misurato supera questi limiti, sono necessarie più appliance virtuali nella rete. Per larghezze di banda superiori o per un sensore fisico, si sceglie l’hardware certificato in base al carico continuo e di picco effettivamente misurato.

Licenza e principi di pianificazione

Per l’integrazione è necessario il Sophos Network Detection and Response integration license pack. Sophos calcola la licenza NDR in base al numero complessivo di utenti e server dell’organizzazione. Il software per le appliance virtuali è incluso; nell’ambito della licenza è possibile distribuire tutti i sensori NDR necessari. Questo aspetto è importante quando un ambiente di grandi dimensioni deve essere distribuito su più sensori a causa dei limiti documentati delle VM.

Prima di scegliere la piattaforma, si rilevano i valori seguenti:

• larghezza di banda massima e sostenuta del traffico che deve essere effettivamente sottoposto a mirroring,
• pacchetti al secondo e flussi al secondo per lo stesso periodo,
• capacità dello switch o della porta mirror da cui il sensore riceve il traffico,
• numero e posizione previsti dei sensori,
• ulteriori integrazioni Log Collector da eseguire sulla stessa appliance,
• microarchitettura della CPU, flag della CPU, memoria e storage disponibili,
• piattaforma di virtualizzazione supportata o modello hardware certificato esatto.

Il solo uplink Internet non costituisce una base di dimensionamento sufficiente. Il sensore elabora il traffico sottoposto a mirroring verso di esso. I valori devono quindi essere rilevati nel punto di mirroring previsto e documentati come carico continuo e di picco.

Scegliere la piattaforma

Appliance virtuale o cloud

Un’appliance virtuale è adatta quando una delle piattaforme testate è già disponibile, il carico rientra nei limiti della VM oppure può essere distribuito in modo appropriato su più sensori. Sono supportate le piattaforme seguenti:

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

Per AWS, la specifica tecnica di Sophos NDR indica il tipo di istanza c5n.2xlarge. I meccanismi concreti di distribuzione, le interfacce di rete e le impostazioni di mirroring del traffico sono descritti nella rispettiva guida al deployment e non derivano dalla decisione di dimensionamento.

VMware Cloud non è supportato. Per ESXi e Hyper-V valgono inoltre i requisiti di versione e CPU descritti di seguito. I requisiti disponibili non contengono invece una matrice di versioni comune per AWS e Nutanix; i relativi prerequisiti di deployment devono pertanto essere verificati nella sezione dedicata alla rispettiva piattaforma.

Hardware certificato

L’hardware è una soluzione possibile quando è necessario un sensore fisico dedicato oppure quando un livello di capacità certificato è adatto al carico misurato. Sophos supporta NDR su hardware esclusivamente con sistemi certificati. Non si può quindi dedurre che siano supportati server x86 generici, varianti di modello simili o sistemi assemblati autonomamente.

Sono certificati i sistemi delle famiglie seguenti:

• Dell,
• NUC,
• OnLogic.

Non è determinante soltanto il nome del produttore. Prima dell’acquisto, il modello esatto deve essere confrontato con la versione vigente delle Certified hardware specifications for NDR. L’installazione, l’immagine del disco e i passaggi specifici del produttore vengono affrontati soltanto dopo questa scelta del modello.

Dimensionare i sensori virtuali e cloud

Risorse minime

Per ESXi e Hyper-V si applicano le risorse minime seguenti:

• 4 CPU,
• 16 GB RAM,
• 160 GB di storage.

L’OVA VMware è già preconfigurata con questi valori minimi per Sophos NDR e le integrazioni Log Collector. AWS utilizza il tipo di istanza indicato sopra. Per Nutanix, la fonte dei requisiti qui utilizzata non indica risorse minime specifiche. Le risorse minime non costituiscono tuttavia una garanzia di capacità. Per scegliere tra la configurazione standard, 8 vCPU e più appliance, occorre considerare tutte e tre le metriche di traffico.

I valori limite definiscono congiuntamente una classe di carico. Un sensore con 400 Mbit/s ma 100'000 pacchetti al secondo non rientra più interamente nella classe Media. Se i valori superano quelli della classe Alta, Sophos prevede più appliance virtuali distribuite nella rete; dalle fonti non è possibile dedurre l’uso di una singola VM più grande oltre questo limite.

La specifica tecnica limita un sensore NDR virtuale a un massimo di 1 Gbit/s. Questo valore non annulla i limiti più restrittivi relativi a pacchetti e flussi.

Verificare CPU e hypervisor

I requisiti seguenti relativi alla microarchitettura e ai flag si applicano al sistema su cui viene eseguita la VM. Per ESXi, Hyper-V e altri host VM autogestiti, i flag CPU pdpe1gb e avx2 devono essere disponibili nella VM. pdpe1gb è necessario per l’acquisizione dei pacchetti, avx2 per le funzioni di machine learning. Un numero maggiore di vCPU non compensa l’assenza dei flag.

Per AWS si verificano invece il tipo di istanza supportato e i requisiti di deployment AWS; le appliance fisiche vengono convalidate in base al modello certificato esatto e alla configurazione approvata. Non ne deriva, né per AWS né per l’hardware certificato, la necessità di un’ulteriore verifica manuale dei flag.

Sophos documenta le microarchitetture CPU seguenti:

• Intel: Skylake Generation 6, Kaby Lake Generation 7, Coffee Lake Generation 8, Coffee Lake Refresh e 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 e Raptor Lake/Raptor Cove Generation 13.
• AMD: Naples e Great Horned Owl con Zen 1, Rome con Zen 2, Milan con Zen 3 e Genoa con Zen 4.

È possibile utilizzare anche CPU più recenti, purché siano disponibili entrambi i flag richiesti. Sophos specifica che le CPU introdotte a partire dal primo trimestre del 2015 dovrebbero funzionare; ai fini della convalida resta comunque determinante verificare concretamente i due flag sulla VM prevista.

Per gli hypervisor valgono le versioni minime e i limiti seguenti:

• VMware ESXi: versione 6.7 Update 3 o successiva e VM Hardware Version 11 o superiore. In un cluster EVC deve essere selezionato Skylake generation or later. VMware Cloud non è supportato.
• Microsoft Hyper-V: versione 6.0.6001.18016 su Windows Server 2016 o successivo. Processor Compatibility Mode non è supportato.

Appliance condivisa con Log Collector

I valori VM per le classi Media e Alta si applicano a un’appliance su cui viene eseguito soltanto Sophos NDR. Se vengono ospitate anche integrazioni Log Collector, la pianificazione parte dalle dimensioni di NDR e aggiunge successivamente il loro carico. Sono documentati i limiti e gli effetti seguenti:

• Tutte le integrazioni Log Collector di una VM, complessivamente, possono ricevere al massimo 8'000 eventi al secondo.
• Un’integrazione Log Collector richiede circa 400 MB di RAM in condizioni di carico elevato.
• Con 4 CPU, NDR utilizza 2 CPU; con 8 CPU ne utilizza 3. Altre integrazioni possono comunque utilizzare queste CPU e influire così sul volume di traffico elaborabile da NDR.
• Con 16 GB di RAM, le integrazioni Log Collector possono utilizzare complessivamente non più di 2 GB, affinché NDR disponga di memoria sufficiente.
• Un Log Collector alla massima frequenza di eventi richiede, su una VM con le 4 CPU standard, una potenza di calcolo approssimativamente pari a quella richiesta da NDR con un carico medio.

Per i carichi misti non esiste un’unica dimensione valida in tutti i casi. Se si prevede di superare i limiti NDR o le risorse disponibili, occorre pianificare appliance aggiuntive. Se più integrazioni Log Collector superano complessivamente 8'000 eventi al secondo, vengono utilizzate più VM. Se invece è una singola integrazione a superare tale limite, si cerca innanzitutto di ridurre il volume degli eventi tramite le impostazioni Syslog del sistema di origine. I valori approssimativi documentati non giustificano una sovrallocazione arbitraria.

Dimensionare l’hardware certificato

Sophos ricava il livello hardware dalla capacità dello switch che esegue il mirroring e dal carico continuo e di picco. Il sensore NDR deve avere la stessa capacità dello switch da cui proviene il traffico sottoposto a mirroring. Le raccomandazioni seguenti si basano su un’organizzazione tipica composta per il 20% da Power User, per il 60% da utenti tipici e per il 20% da Light User. Si presuppongono inoltre VoIP, un certo utilizzo dello streaming video, upload e download di grandi dimensioni, nonché server applicativi e web.

Questi nomi e livelli prestazionali servono soltanto per una preselezione. Si può procedere all’acquisto solo se il modello esatto e la configurazione esatta sono riportati nelle Certified hardware specifications for NDR vigenti.

Per ogni riga, Sophos documenta un possibile carico di picco pari a due o tre volte il carico tipico. Questa indicazione del picco non sostituisce una misurazione e non deve essere confusa con il livello di capacità. In presenza di ulteriore streaming video e musicale intenso, può essere necessario il livello immediatamente superiore; la decisione si basa sul carico continuo e di picco misurato e sugli attuali limiti certificati. In caso di utilizzo prevalentemente e-mail, può essere adatto un livello inferiore, purché il carico continuo e di picco misurato e il numero di utenti rimangano entro i relativi valori.

La larghezza di banda e il numero di utenti, da soli, non sono sufficienti per scegliere l’hardware. Nella certificazione attuale occorre verificare anche il numero massimo di connessioni al secondo e la configurazione approvata di CPU, RAM ed eventualmente socket. Ciò è particolarmente importante in caso di traffico con un numero elevato di connessioni. Ad esempio, la scheda tecnica Sophos NDR del 19 dicembre 2024 indica, per due configurazioni R660, lo stesso throughput nominale ma limiti diversi per connessioni e risorse:

Nel dettaglio, queste sono le configurazioni riportate nella scheda tecnica del 19.12.2024:

Dell R660, 2 socket

• Throughput max.: 40 Gbit/s
• Connessioni/s max.: 120'000
• CPU: 64
• RAM: 128 GB

Dell R660, 1 socket

• Throughput max.: 40 Gbit/s
• Connessioni/s max.: 80'000
• CPU: 32
• RAM: 64 GB

Dell R650

• Throughput max.: 20 Gbit/s
• Connessioni/s max.: 40'000
• CPU: 24
• RAM: 64 GB

Dell R450

• Throughput max.: 10 Gbit/s
• Connessioni/s max.: 20'000
• CPU: 16
• RAM: 32 GB

Dell R350

• Throughput max.: 4 Gbit/s
• Connessioni/s max.: 8'000
• CPU: 8
• RAM: 32 GB

Intel NUC 13th Gen

• Throughput max.: 2,5 Gbit/s
• Connessioni/s max.: 4'000
• CPU: 12
• RAM: 32 GB

Questi valori datati mostrano tutti i parametri tecnici rilevanti per il dimensionamento e l’importanza della configurazione esatta, ma non costituiscono una matrice aggiornata per l’acquisto o la certificazione. Per R360, R660xs, OnLogic e ogni variante differente, i valori mancanti non vengono ricavati da modelli simili, bensì esclusivamente dalla specifica di certificazione vigente.

Le raccomandazioni hardware costituiscono un modello di carico, non una garanzia per ogni distribuzione del traffico. Lo streaming e i grandi flussi di backup generano molto volume; Sophos NDR è ottimizzato per questo traffico di streaming e per gli «Elephant Flow», mentre molte minacce vengono rilevate nel normale traffico di navigazione e applicativo. Per questo motivo, il profilo degli utenti e i valori reali della rete vengono valutati congiuntamente.

Prerequisiti di rete prima del deployment

L’appliance richiede connessioni in uscita per l’avvio e gli aggiornamenti. Se il firewall supporta i caratteri jolly, Sophos documenta le regole di accesso seguenti:

yum.oracle.com è facoltativo; senza accesso, l’appliance utilizza il mirror del repository Sophos JFrog. Se il firewall non supporta i caratteri jolly, questa breve tabella non deve essere convertita in singoli host presunti. In tal caso, si adotta l’elenco aggiornato per la regione disponibile nella pagina Sophos Appliance requirements.

Sull’Integration Appliance non viene installato né un Sophos Agent né un altro agente anti-malware. Anche gli aggiornamenti del sistema operativo e di sicurezza non vengono installati manualmente; tali aggiornamenti sono gestiti da Sophos.

Convalidare la decisione e procedere al passaggio di consegne

Prima del deployment, un protocollo di pianificazione dovrebbe includere almeno i punti seguenti:

1. Piattaforma: ESXi, Hyper-V, AWS, Nutanix o modello hardware certificato esatto.
2. Finestra di misurazione: data, ora e durata della misurazione, nonché valori continui e di picco di larghezza di banda, pacchetti e flussi nel punto mirror previsto.
3. Dimensionamento: classe di carico o livello hardware scelto e relativo limite determinante; per l’hardware, anche il confronto tra il numero massimo di connessioni al secondo misurato e il limite certificato corrente.
4. Risorse per piattaforma:
   • ESXi, Hyper-V e altri host VM autogestiti: vCPU, RAM, storage, modello CPU e flag pdpe1gb e avx2 visibili nella VM.
   • AWS: tipo di istanza supportato c5n.2xlarge e requisiti della sezione relativa al deployment AWS.
   • Hardware certificato: modello certificato esatto e configurazione approvata di CPU, RAM e socket.
5. Carico aggiuntivo: nomi ed eventi al secondo previsti per tutte le integrazioni Log Collector ospitate sulla stessa appliance.
6. Rete: connessioni previste per la gestione e il mirroring, nonché autorizzazioni confermate per porte e domini in uscita.
7. Scalabilità: numero e posizione dei sensori aggiuntivi qualora un sensore virtuale superi i limiti della classe Alta.

La decisione è affidabile quando ogni valore misurato rientra nel livello scelto e sono soddisfatti i prerequisiti specifici della piattaforma. Per gli host VM autogestiti, questi comprendono l’hypervisor, la CPU e i flag visibili nella VM. Per AWS sono determinanti il tipo di istanza supportato e i relativi requisiti di deployment. Per l’hardware, il modello esatto, la configurazione di CPU/RAM/socket, il throughput e il numero massimo di connessioni al secondo devono corrispondere alla certificazione corrente. In caso di appliance condivisa, occorre inoltre considerare la frequenza degli eventi, la RAM e l’impatto sulla CPU dei Log Collector.

La creazione dell’immagine, l’installazione, la registrazione, il Traffic Mirroring e la prima Detection rientrano nei successivi passaggi di deployment e convalida. Un successivo stato Connected o uno stato verde dell’appliance conferma soltanto lo stato dell’integrazione; non dimostra né una copertura completa del mirroring né il corretto funzionamento del rilevamento end-to-end.

Limiti della pianificazione documentata

Le fonti non forniscono una formula per calcolare dimensioni individuali arbitrarie di CPU e RAM superiori ai livelli VM indicati a partire dal numero di utenti, dalla larghezza di banda o dagli eventi. Oltre i limiti della classe Alta, la decisione documentata è pertanto più appliance virtuali, non una singola VM più grande dimensionata in modo ipotetico.

Analogamente, le tabelle hardware non sostituiscono la specifica di certificazione vigente. Indicano valori per la preselezione o valori datati delle schede tecniche, ma non costituiscono un’approvazione per server con nomi simili, componenti differenti o sistemi x86 assemblati in proprio. Se per l’hardware mancano il modello esatto e la configurazione approvata, oppure non sono disponibili valori affidabili relativi a traffico e connessioni, la piattaforma non è ancora approvata per il deployment. Lo stesso vale per un host VM autogestito se nella VM mancano i flag CPU richiesti.