Monitorare lo stato e la capacità di Sophos NDR

Uno stato verde di Sophos NDR è un importante controllo intermedio, ma non dimostra ancora né la copertura completa del mirroring né il corretto funzionamento della catena di rilevamento. Per una valutazione affidabile occorre esaminare separatamente sei gruppi di segnali: Sophos Fusion, Appliance Manager, ingresso SPAN, upload, elaborazione e archiviazione e, se presente, l’Investigation Console separata.

Controllo rapido: leggere innanzitutto lo stato NDR in Sophos Fusion. Quindi, in Appliance Manager, nella sezione NDR, controllare i valori di ciascuna porta SPAN prevista, il valore Uploaded e l’andamento dei flussi. Nella sezione Status verificare poi CPU, Memory, Root Disk e Data Disk. Un avviso giallo spanX: packets being dropped indica che viene scartato più del 10% dei pacchetti di rete elaborati da NDR. Una porta SPAN verde soddisfa attualmente il classificatore del prodotto, che richiede almeno il 2% di pacchetti unicast. Nessuna di queste indicazioni dimostra, da sola, che tutte le reti previste siano sottoposte a mirroring o che una detection venga trasmessa end-to-end.

Attribuire correttamente gli indicatori

Appliance Manager si apre da Sophos Fusion tramite Threat Analysis Center > Integrations > Configured > Integration Appliances. Nella riga dell’appliance, selezionare Open Appliance Manager dal menu con i tre puntini. L’intestazione mostra, tra le altre informazioni, Version, K3S Helm Chart version, Uptime e System ID. Questi dati vanno inclusi in ogni documentazione relativa a un malfunzionamento, perché due appliance con sintomi apparentemente simili possono avere versioni software o tempi di attività diversi.

Usare lo stato di Fusion come punto di partenza

Sophos Fusion distingue tre stati:

• Rosso: l’integrazione NDR non funziona. NDR containers not ready, <specific container names> indica applicazioni non pronte. Upload to s3 failed ... riguarda l’upload nel cloud. spanX: unhealthy span riguarda il traffico in ingresso dal dispositivo di rete che esegue il mirroring.
• Giallo: l’integrazione funziona, ma presenta errori. spanX: packets being dropped viene visualizzato quando viene scartato più del 10% dei pacchetti di rete.
• Verde: l’integrazione riceve traffico SPAN ed elabora i dati dei pacchetti senza errori segnalati. Una porta SPAN è attualmente classificata come integra se almeno il 2% dei pacchetti osservati è costituito da pacchetti unicast.

I due valori percentuali hanno denominatori diversi e non devono essere messi in relazione tra loro. La soglia del 2% classifica la composizione del traffico che arriva al sensore. Non significa né che sia sufficiente ricevere il 2% di tutto il traffico aziendale, né che NDR possa perderne il 98%. «Almeno il 2%» include esattamente il 2%. Il messaggio relativo ai pacchetti scartati descrive invece la quota dei pacchetti già arrivati a NDR che il sistema non riesce a elaborare per mancanza di risorse. Sophos documenta l’avviso per più del 10%, non per «il 10% o più».

Importante: la soglia superiore al 10% rappresenta uno stato del prodotto, non un valore obiettivo né una quota accettabile di perdita. Anche un valore inferiore alla soglia di segnalazione può costituire un peggioramento rispetto alla propria baseline. Analogamente, una porta verde può fornire traffico sottoposto a mirroring in modo errato o incompleto, purché la composizione osservata soddisfi il classificatore unicast.

Controllare separatamente l’ingresso SPAN e l’upload

In Appliance Manager, la scheda NDR mostra un valore di acquisizione per ogni porta SPAN configurata. SPAN Port 2 compare solo se è stata configurata una seconda porta. Il grafico complessivo dei Network Flows è visualizzato a intervalli di 30 secondi.

Questi indicatori rispondono a tre domande distinte:

1. Il traffico arriva su ogni porta SPAN prevista? Un valore mancante o improvvisamente molto diverso indirizza il controllo innanzitutto verso lo switch di origine, la sessione mirror o SPAN, l’assegnazione della scheda di rete virtuale e le VLAN o i gruppi di porte modificati di recente.
2. La composizione del traffico è plausibile? Il verde conferma soltanto l’attuale classificatore unicast. L’andamento dei flussi deve inoltre essere coerente con i consueti orari della giornata, le sedi e i picchi di traffico previsti.
3. NDR riesce a elaborare i pacchetti? Il messaggio giallo relativo ai pacchetti scartati indica un collo di bottiglia nell’elaborazione. Non equivale a una porta mirror sovraccarica né a Packet Loss nel percorso di produzione.

La percentuale di upload, anch’essa visibile nella scheda NDR, riguarda una fase successiva. Un ingresso SPAN integro con un upload in calo non indica la stessa categoria di errore di una porta SPAN priva di traffico. In presenza di Upload to s3 failed. Request was received but an error code was returned, controllare l’accesso a Internet in uscita dall’appliance e le regole di firewall e web proxy. NDR carica i dati in un bucket S3 tramite un URL prefirmato. Se l’errore persiste dopo la correzione della rete o del proxy, occorre rivolgersi al supporto Sophos.

Per le integrazioni di raccolta log di terze parti, le schede in Integrations conteggiano Received, Filtered, Accepted e Uploaded. Questi contatori syslog non rappresentano né il valore di upload NDR né il valore di acquisizione SPAN. Sono comunque importanti perché un’integrazione di raccolta log molto impegnativa, eseguita sulla stessa appliance, utilizza CPU e Memory della medesima appliance.

Valutare CPU, Memory e archiviazione

Nella sezione Status, Appliance Manager mostra l’utilizzo di CPU, Memory, Root Disk e Data Disk. In NDR è normale che alcuni core della CPU siano costantemente al massimo: il Data Plane Development Kit (DPDK) opera su core riservati in modalità polling. Su tali core controlla continuamente la presenza di pacchetti, invece di attendere interrupt durante i periodi di inattività.

Sophos fornisce due esempi concreti:

• In una VM con 4 core CPU, un core rimane al 100%.
• In una VM con 8 core CPU, due core rimangono al 100%.

Un simile utilizzo per core non dimostra quindi, da solo, un sovraccarico e non scompare necessariamente in presenza di poco traffico. D’altra parte, il fatto che «DPDK sia normale» non può giustificare qualsiasi utilizzo elevato della CPU. Diventa critica la combinazione di traffico in aumento, ulteriori core saturi, messaggio packets being dropped, upload in calo o andamento dei flussi diverso dalla baseline.

Per le appliance virtuali valgono le seguenti indicazioni di capacità:

Tutte e tre le grandezze devono essere considerate insieme. Un ambiente può rimanere al di sotto del limite di larghezza di banda e produrre comunque molti pacchetti al secondo a causa di pacchetti molto piccoli. Se i valori superano i limiti del profilo High, Sophos consiglia di utilizzare più appliance virtuali nella rete.

I valori indicati si applicano a una VM sulla quale è in esecuzione soltanto NDR. In condizioni di carico elevato, ogni ulteriore integrazione di raccolta log ospitata richiede circa 400 MB di RAM e può utilizzare altra capacità della CPU. Per questo motivo, prima di aumentare le risorse si controllano anche le schede in Integrations. In presenza di un carico misto permanente, distribuire i servizi su più appliance può essere più opportuno che potenziare ripetutamente la stessa VM.

Per Memory, Root Disk e Data Disk, la documentazione del prodotto utilizzata in questo articolo non specifica una soglia di avviso generale. Sarebbe quindi fuorviante considerare una percentuale arbitraria come limite Sophos. Sono determinanti l’andamento, il margine disponibile e gli eventuali sintomi concomitanti. Se lo spazio su disco utilizzato continua a crescere, non eliminare manualmente file o container; documentare prima lo stato e il periodo interessato e, se la causa non è chiara, salvare i log da fornire al supporto Sophos.

Creare una baseline utilizzabile

Un’istantanea non permette di distinguere il normale andamento giornaliero dall’inizio di un sovraccarico. Dopo la messa in funzione e dopo ogni modifica rilevante, registrare quindi punti di misurazione confrontabili:

• data, ora e fuso orario, nonché fase di carico prevista;
• colore in Fusion e testo esatto del messaggio;
• valore di acquisizione per ogni porta SPAN configurata;
• percentuale di upload e forma dell’andamento dei flussi;
• CPU per core e quadro complessivo, Memory, Root Disk e Data Disk;
• vCPU e RAM assegnate alla VM;
• Mbit/s, pacchetti/s e flussi/s stimati o misurati nel sistema di origine;
• integrazioni di terze parti in esecuzione contemporanea e relativa attività;
• modifiche apportate a switch, hypervisor, proxy, firewall o appliance.

È opportuno effettuare le misurazioni durante una fase tranquilla, con il normale carico operativo e in occasione di un picco noto. Lo scopo non è definire un valore obiettivo universale, bensì confrontare la stessa appliance in condizioni simili. In questo modo è possibile rilevare un calo improvviso su una porta SPAN anche se Fusion continua a mostrare lo stato verde. Dopo una modifica della capacità, creare una nuova baseline soltanto quando lo stato si è stabilizzato.

Risolvere i problemi in un ordine sicuro

1. Registrare l’ambito: documentare l’appliance interessata, la porta SPAN, l’ora di inizio, il testo esatto visualizzato in Fusion e l’ultima modifica. Prima di un riavvio, salvare schermate o valori misurati.
2. Controllare l’ingresso: in caso di unhealthy span, flussi assenti o scostamento dal valore di riferimento della porta, controllare innanzitutto l’origine del mirroring, la porta di destinazione o la scheda di rete virtuale e le reti previste. Aggiungere CPU non risolve la configurazione errata di un’origine SPAN.
3. Controllare l’upload: in caso di errore di upload S3, controllare l’accesso a Internet in uscita, il firewall e il web proxy. Viceversa, un upload riuscito non risolve una copertura di mirroring incompleta.
4. Controllare la capacità: in presenza di più del 10% di pacchetti scartati, confrontare il profilo di traffico, gli altri core saturi, l’assegnazione di vCPU e le integrazioni eseguite sulla stessa appliance. Per una VM, assegnare ulteriori vCPU; il profilo High documentato prevede 8 vCPU. Per l’hardware certificato è possibile predisporre un’ulteriore appliance e suddividere il traffico SPAN. Prima di questa suddivisione è obbligatorio predisporre un piano di copertura approvato, che assegni in modo univoco ogni rete, VLAN e origine mirror prevista all’appliance di destinazione, evitando lacune e duplicazioni involontarie dei flussi in ingresso. Per i carichi di lavoro misti è possibile distribuire NDR e i Log Collectors su appliance separate.
5. Delimitare il riavvio: se, dopo aver eliminato la causa, NDR continua a non funzionare correttamente, si può valutare un riavvio mirato di NDR seguendo la procedura operativa o di risoluzione dei problemi pertinente. Durante il riavvio non avviene la normale elaborazione NDR; un riavvio non sostituisce un intervento correttivo sulla capacità. Il riavvio o lo spegnimento dell’intera VM ha un impatto più ampio e non deve costituire il primo passo della risoluzione dei problemi.

Le modifiche alle vCPU o alla distribuzione del traffico vanno eseguite in una finestra di manutenzione approvata, nel rispetto delle indicazioni della piattaforma di virtualizzazione utilizzata. Apportare una modifica alla volta, in modo che il suo effetto rimanga misurabile. Dopo aver suddiviso il traffico, verificare il piano di copertura rispetto a ogni porta SPAN risultante; convalidare inoltre il percorso di test end-to-end approvato.

Non confondere Investigation Console con l’appliance NDR

Investigation Console è un componente separato. Il suo stato non dimostra né lo stato dell’integrazione NDR, né la completezza delle origini SPAN, né la corretta trasmissione dei dati. Questo articolo si limita pertanto a chiarire tale distinzione: SPAN, upload NDR, DPDK e Packet Drops si controllano nell’integrazione NDR e in Appliance Manager; il controllo e la risoluzione dei problemi di Investigation Console rientrano nella documentazione operativa specifica della console.

Convalidare dopo ogni intervento

Ripetere il controllo con un carico confrontabile con quello della misurazione iniziale. Un intervento correttivo può essere considerato efficace soltanto quando:

• Fusion mostra lo stato previsto senza il precedente messaggio rosso o giallo;
• ogni porta SPAN prevista è visibile e corrisponde nuovamente al proprio andamento di riferimento;
• il classificatore unicast non è stato usato erroneamente come prova della copertura;
• il messaggio relativo a più del 10% di Packet Drops non ricompare;
• upload e Network Flows rimangono stabili per un periodo di osservazione significativo;
• la CPU al di fuori dei core DPDK previsti, Memory, Root Disk e Data Disk mostrano un margine sufficiente;
• le integrazioni di terze parti eseguite sulla stessa appliance continuano a elaborare i dati previsti;
• dopo la suddivisione del traffico, ogni rete, VLAN e origine mirror prevista viene indirizzata esattamente all’appliance stabilita dal piano di copertura approvato e il percorso di test end-to-end approvato funziona.

Questi controlli convalidano lo stato operativo, ma non ancora una catena di rilevamento completa. Per una verifica end-to-end è necessario anche eseguire un test NDR approvato e controllare la detection risultante.

Quando coinvolgere il supporto Sophos

È opportuno coinvolgere il supporto Sophos se i container non diventano pronti, se un errore di upload S3 persiste nonostante la verifica del percorso Internet e proxy, se una porta SPAN rimane unhealthy dopo aver corretto la configurazione dell’origine, se i Packet Drops ricompaiono dopo un adeguato aumento della capacità oppure se le risorse e i messaggi di stato si contraddicono.

Preparare almeno i seguenti dati per l’escalation:

• nome dell’appliance, System ID, Version, K3S Helm Chart version e Uptime;
• testo esatto dello stato e dell’errore, con ora di inizio e fuso orario;
• porta SPAN interessata, valori di acquisizione/upload e andamento dei flussi;
• CPU per core, Memory, Root Disk e Data Disk prima e dopo l’intervento;
• risorse assegnate alla VM, profilo di traffico osservato e integrazioni eseguite sulla stessa appliance;
• ultime modifiche a switch, hypervisor, firewall o proxy;
• interventi eseguiti e relativo risultato misurabile;
• in caso di problemi con un’Investigation Console separata, gli elementi richiesti dalla relativa documentazione operativa.

Password, chiavi private e altre credenziali non devono essere incluse nel ticket. Non eseguire sulla base di semplici supposizioni comandi Kubernetes di basso livello o modifiche manuali ai container; in presenza di NDR containers not ready, raccogliere le osservazioni disponibili e concordare i passi successivi con il supporto Sophos.