Come funziona l'analisi del traffico di rete nell'NDR

L'analisi del traffico di rete descrive il modo in cui una piattaforma NDR raccoglie, elabora ed esamina il traffico su una rete aziendale ibrida per rilevare in tempo reale il comportamento degli aggressori. Un'analisi efficace del traffico di rete comprende le modalità di acquisizione del traffico da ambienti on-premise, cloud e remoti; le modalità di elaborazione in metadati rilevanti per la sicurezza; le modalità di analisi delle sessioni crittografate senza necessità di decrittografia; le modalità di derivazione dell'identità dai protocolli di rete; e le modalità di distribuzione e scalabilità dei componenti di analisi. Questa pagina illustra ogni livello per i team di sicurezza che stanno valutando o implementando l'NDR.

Come funziona l'analisi del traffico di rete nell'architettura NDR

L'analisi del traffico di rete nell'NDR si basa su tre livelli interdipendenti: acquisizione del traffico, analisi comportamentale e integrazione delle risposte. I sensori distribuiti nei vari segmenti di rete acquisiscono il traffico grezzo e inoltrano i metadati a un componente di elaborazione — comunemente denominato "Brain appliance" — che analizza tali metadati utilizzando modelli di intelligenza artificiale comportamentale. I risultati del rilevamento vengono visualizzati in un'interfaccia di gestione e trasmessi ai sistemi a valle, quali SIEM e SOAR.

A differenza degli strumenti endpoint, l'NDR opera a livello di rete, il che significa che rileva tutti i dispositivi che comunicano all'interno dell'ambiente, siano essi gestiti, non gestiti, cloud o IoT/OT, indipendentemente dal fatto che sia installato un agente di sicurezza. Ciò garantisce ai team di sicurezza la visibilità sui movimenti laterali, sul traffico est-ovest e sulle attività basate sull'identità che endpoint non sono in grado di rilevare.

L'architettura è progettata per funzionare senza agenti nel punto di acquisizione. I sensori ricevono una copia del traffico di rete tramite porte SPAN, TAP o mirroring cloud e non richiedono un posizionamento in linea né l'intercettazione del traffico. Ciò riduce al minimo la complessità dell'implementazione ed evita di introdurre latenza nei flussi di traffico di produzione.

Monitoraggio del traffico est-ovest rispetto a quello nord-sud

Il monitoraggio del traffico di rete copre due principali direzioni di traffico, ciascuna delle quali rivela una classe distinta di comportamenti degli aggressori. Il traffico nord-sud si muove tra i sistemi interni e le destinazioni esterne: è qui che diventano visibili le comunicazioni di comando e controllo, l'esfiltrazione dei dati e l'attività delle botnet. Il traffico est-ovest si muove lateralmente tra i sistemi interni: è qui che si svolgono le operazioni di ricognizione, l'escalation dei privilegi e i movimenti laterali dopo che un aggressore ha già stabilito un punto d'appoggio.

La maggior parte degli strumenti di sicurezza perimetrale si concentra sul traffico nord-sud ai margini della rete. Ciò lascia in gran parte scoperta la visibilità est-ovest. Quando un aggressore utilizza credenziali valide per spostarsi tra server, carichi di lavoro o sistemi di gestione delle identità, tale attività si svolge in direzione est-ovest e non attiva alcun allarme negli strumenti che controllano solo il traffico in entrata e in uscita.

L'NDR colma questa lacuna acquisendo il traffico nei segmenti di rete interni, all'interno dei data center, cloud e tra le sedi del campus, non solo a livello perimetrale. Ciò consente ai modelli comportamentali di monitorare i movimenti laterali nel momento stesso in cui avvengono, prima che un attacco raggiunga il proprio obiettivo. Per comprendere più a fondo in che modo gli aggressori sfruttano le lacune di copertura al di là degli endpoint, i percorsi di attacco che emergono in tali punti ciechi sono proprio l'ambito in cui l'analisi a livello di rete offre il valore aggiunto più significativo.

La tabella sottostante mette in relazione ciascuna direzione del traffico con i comportamenti di attacco che essa rivela. I team di sicurezza dovrebbero assicurarsi che il posizionamento dei sensori copra entrambi i flussi su tutti i segmenti di rete in cui operano i sistemi sensibili.

Quali tipi di traffico dovrebbe rilevare (ed escludere) l'analisi del traffico di rete?

Un'analisi efficace del traffico di rete rileva i protocolli che rivelano le intenzioni comportamentali, gli eventi di autenticazione, le comunicazioni tra servizi e l'attività a livello di sessione, escludendo al contempo il traffico ad alto volume che aggiunge rumore senza apportare alcun valore in termini di sicurezza. La scelta dei protocolli influisce direttamente sull'accuratezza del rilevamento e sulle prestazioni dell'apparecchio.

Le tabelle riportate di seguito riportano le linee guida operative tratte direttamente dalle specifiche di implementazione di Vectra NDR. È importante leggerle nel loro insieme: ciò che viene acquisito determina la copertura del rilevamento, ciò che viene escluso determina la precisione del modello e l'efficienza dell'appliance, mentre ciò che migliora l'HostID determina l'affidabilità con cui la piattaforma attribuisce le attività a specifici host e identità identificati.

Protocolli da includere vs. traffico da escludere

La colonna di sinistra elenca i protocolli che trasportano segnali comportamentali: autenticazione, chiamate di servizio, dati di sessione. La colonna di destra elenca le categorie di traffico che consumano capacità senza migliorare il rilevamento. L'acquisizione dei tipi di traffico esclusi aumenta il carico dell'apparecchio e introduce rumore che compromette la precisione del modello di IA.

Cosa contribuisce a migliorare l'HostID di Vectra

L'accuratezza nell'identificazione degli host dipende dal rispetto, da parte della piattaforma, dei protocolli che trasportano i segnali relativi alla denominazione dei dispositivi e delle identità. I seguenti input, sia basati sui protocolli che sull'integrazione, migliorano l'affidabilità con cui la piattaforma attribuisce l'attività di rete a specifici host e identità denominati, anche in caso di variazione degli indirizzi IP.

Formati supportati

I sensori Vectra NDR supportano i seguenti formati di incapsulamento di rete, garantendo la compatibilità con le moderne architetture cloud dei data center, dei campus e cloud .

Fonti tipiche di acquisizione del traffico

Il traffico di rete raggiunge i sensori Vectra tramite i seguenti meccanismi di acquisizione. La fonte appropriata dipende dall'architettura di rete, dal tipo di ambiente e dal fatto che l'implementazione si estenda su un'infrastruttura on-premise, cloud o ibrida.

‍

Linee guida per il posizionamento: i sensori devono essere installati sul lato sud di qualsiasi dispositivo proxy o NAT per identificare con precisione l'host di origine. Quando il traffico proveniente da più host viene aggregato dietro un proxy su un unico indirizzo IP, la piattaforma NDR deve essere configurata in modo da riconoscere tale proxy, al fine di preservare l'accuratezza del rilevamento. Le piccole filiali remote in genere non richiedono un sensore dedicato: il traffico proveniente da tali siti è generalmente visibile nelle sedi centrali in cui sono già distribuiti i sensori. Per indicazioni sul dimensionamento delle appliance fisiche e virtuali in base al livello di throughput, consultare le specifiche delle appliance e dei sensori.

Come funziona l'analisi del traffico crittografato in NDR

La stragrande maggioranza dei rilevamenti NDR non richiede la decrittografia del traffico. I modelli di intelligenza artificiale basati sul comportamento analizzano i metadati derivati dalle sessioni crittografate, la temporizzazione dei pacchetti, la dimensione delle sessioni, i modelli di connessione, gli attributi dei certificati e il comportamento dei protocolli, al fine di identificare attività dannose senza ispezionare il contenuto del payload. Ciò rende l'analisi del traffico di rete efficace contro le tecniche utilizzate dagli aggressori per nascondere i canali di comando e controllo all'interno del traffico crittografato, uno dei comportamenti di attacco più spesso non rilevati negli ambienti aziendali.

Si tratta di una distinzione architettonica fondamentale. La decrittografia in linea comporta latenza, problemi di privacy, complessità normativa e costi infrastrutturali significativi. L'NDR evita questi compromessi operando sui metadati anziché sui payload in chiaro — una scelta giustificata dal fatto che le architetture moderne non richiedono più la decrittografia in linea per garantire una copertura significativa del rilevamento comportamentale.

Esistono pochi casi in cui l'accesso ai metadati del traffico decriptato offre un valore aggiunto:

• Squadre che utilizzano funzionalità avanzate di indagine o di recupero dei dati che richiedono il contenuto delle sessioni decriptato ai fini dell'analisi forense
• Implementazioni che utilizzano regole di corrispondenza dei modelli in cui determinate firme si attivano solo quando il contenuto del payload è ispezionabile

Quando è necessaria la decrittografia: l'approccio a pipeline parallela

Quando è necessaria l'analisi sia del traffico crittografato che di quello decrittografato, questa deve essere gestita tramite pipeline di elaborazione parallele, non inviando entrambi i tipi di traffico allo stesso sensore. L'invio di entrambi i flussi a un unico sensore fa sì che la logica di deduplicazione scarti uno dei due flussi (in genere quello decrittografato, poiché la decrittografia comporta un sovraccarico di elaborazione che ne ritarda l'arrivo). L'approccio corretto consiste nell'implementare un sensore dedicato abbinato a un'appliance Brain separata per il flusso di traffico decrittografato. I sensori virtuali e le appliance Brain sono supportati senza costi di licenza aggiuntivi per questo scopo.

Come funziona il rilevamento dell'identità di rete dai metadati del traffico

Il rilevamento delle identità di rete ricava il contesto delle identità direttamente dai protocolli di rete, anziché basarsi esclusivamente sui dati telemetrici forniti dagli agenti o sull'acquisizione dei log. Analizzando il traffico di autenticazione che attraversa la rete, i ticket Kerberos, le query LDAP, gli scambi NTLM e le chiamate DCE/RPC, la piattaforma costruisce un quadro continuo di quali identità sono attive, a quali risorse stanno accedendo e come il loro comportamento si confronta con le linee di base stabilite. Ciò rende l'approccio particolarmente efficace nel rilevare attacchi all'identità basati sui privilegi, in cui gli account compromessi operano entro i limiti di accesso previsti ma si comportano in modo anomalo rispetto ai modelli di autenticazione.

Inoltre, gli account di servizio che effettuano l'autenticazione tra i sistemi, i carichi di lavoro che effettuano chiamate API e gli agenti di intelligenza artificiale che attraversano l'infrastruttura generano tutti traffico di rete tracciabile a livello di identità, anche quando su tali sistemi non è presente alcun endpoint .

La tabella che segue mette in relazione ciascun protocollo rilevante per l'identità con il comportamento dell'autore dell'attacco che esso mette in luce e spiega perché ciò sia importante dal punto di vista operativo.

‍

Il rilevamento dell'identità di rete contribuisce inoltre a migliorare la precisione nell'identificazione degli host. DNS, DNS inverso, Multicast DNS, Kerberos, DHCP e NetBIOS sono i principali segnali utilizzati per associare l'attività di rete a host e identità specifici, garantendo un'attribuzione coerente anche in caso di variazione degli indirizzi IP.

Architettura di Brain e Sensor nelle implementazioni NDR

L'architettura di base di NDR si compone di due tipi principali di dispositivi: il Brain e il Sensor. Ciascuno svolge una funzione specifica e la loro interazione è ciò che trasforma l'analisi del traffico di rete grezzo in rilevamenti di sicurezza classificati per priorità.

I dispositivi di rilevamento acquisiscono il traffico di rete grezzo in punti di acquisizione designati, data center, ambienti campus, cloud e sedi remote. I sensori deduplicano il traffico prima di inoltrare i metadati al Brain. Mantengono un buffer di acquisizione a rotazione che consente il recupero a livello di pacchetto (PCAP) quando necessario per le indagini. Il vSensor è la versione virtuale, implementabile su hypervisor o cloud IaaS.

I dispositivi Brain ricevono i metadati da uno o più sensori accoppiati e li elaborano localmente utilizzando modelli di IA comportamentale per generare rilevamenti. Comprendere in che modo il rilevamento basato sui metadati migliori la visibilità delle minacce è fondamentale per valutare perché questa architettura superi gli approcci incentrati sui log nel monitoraggio del traffico est-ovest e negli scenari di attacchi basati sull'identità. Nelle implementazioni cloud(Respond UX), il Brain invia i dati di rilevamento e i metadati al cloud Vectra cloud la presentazione nell'interfaccia di gestione. Nelle implementazioni on-premise (Quadrant UX), il Brain ospita l'interfaccia utente di gestione localmente.

I dispositivi a modalità mista combinano le funzioni Brain e Sensor in un unico apparecchio, risultando ideali per implementazioni di piccole dimensioni o per ambienti in cui non è giustificata un'architettura a due dispositivi.

‍

Comunicazione e accoppiamento:

• I sensori comunicano con il Brain a cui sono associati tramite TCP/22 (SSH) e TCP/443 (HTTPS)
• I sensori comunicano generalmente solo con il Brain e il DNS, non direttamente con i sistemi esterni
• I dispositivi Brain avviano tutte le connessioni in uscita verso il cloud Vectra
• Gli aggiornamenti vengono inviati dal cloud Vectra cloud Brain e trasmessi automaticamente ai sensori accoppiati
• Sono supportate le implementazioni in modalità air-gapped (solo Quadrant UX), con rilevamenti generati localmente sul Brain
• I sensori fisici possono recuperare l'IP del Brain dal cloud Vectra cloud avvio iniziale tramite TCP/443, consentendo l'accoppiamento automatico con DHCP

Raccomandazioni per l'implementazione: i dispositivi Brain e Sensor devono essere collocati in punti della rete non direttamente visibili dalla rete Internet pubblica. Si consiglia di utilizzare una connessione privata o un tunnel VPN con terminazione esterna ai dispositivi Vectra. I rilevamenti NDR si concentrano sulle comunicazioni in entrata e in uscita; non è consigliabile acquisire il traffico al di fuori dei firewall perimetrali nella DMZ.

‍

Considerazioni relative all'implementazione, al ridimensionamento e alla vista globale

Le implementazioni NDR spaziano da ambienti con un unico sito a grandi aziende globali distribuite. Comprendere la capacità delle appliance e l'architettura multi-istanza è fondamentale per i team che pianificano implementazioni su scala aziendale.

Dimensionamento degli elettrodomestici

La tabella sottostante illustra gli attuali livelli di prestazioni degli appliance. Le prestazioni effettive variano in base alla composizione del traffico: ti invitiamo a rivolgerti al tuo team di account per individuare la combinazione ottimale di appliance fisici e virtuali per il tuo ambiente.

‍

Nota: Vectra rilascia periodicamente nuove configurazioni dell'appliance per supportare i requisiti aggiornati in termini di throughput, gli hypervisor e cloud . Prima di definire le dimensioni di un'implementazione, consultare sempre le specifiche dell'appliance e dei sensori per ottenere indicazioni aggiornate.

Panoramica globale per le imprese distribuite

Le organizzazioni che gestiscono più sedi o unità aziendali possono implementare Global View per ambienti SOC distribuiti, al fine di mantenere una visione unificata dei rilevamenti tra istanze NDR separate. Global View aggrega i dati relativi alle entità, ordinati per priorità, provenienti dalle istanze secondarie di Respond UX in un'istanza di riferimento, fornendo un'unica vista di gestione senza centralizzare i dati archiviati.

‍

L'analisi del traffico di rete nella pratica: risultati dell'implementazione, 2023–2025

L'analisi del traffico di rete produce risultati misurabili se implementata correttamente, ma tali risultati dipendono direttamente dalle scelte architetturali: dove vengono posizionati i sensori, quale traffico viene acquisito, come viene ricavata l'identità dai protocolli e come vengono classificate le rilevazioni in base alla priorità nell'intero ambiente. I casi seguenti illustrano i risultati ottenuti dall'architettura nelle implementazioni in produzione in diversi ambienti di rete.

Goodwood Estate — visibilità est-ovest dal 20% al 95% (2024) Prima di implementare l'NDR, Goodwood Estate disponeva di un monitoraggio del traffico est-ovest che copriva circa il 20% della propria infrastruttura distribuita. I punti ciechi presenti nel campus, nell'IoT e negli ambienti di tecnologia operativa lasciavano senza monitoraggio importanti percorsi di movimento laterale. Dopo l'implementazione dei sensori nei segmenti della rete interna, e non solo nel perimetro, la visibilità est-ovest ha raggiunto il 95%, colmando le lacune di copertura che gli strumenti perimetrali tradizionali non possono affrontare per loro stessa natura.

Schaefer Kalk — Blocco di un attacco ransomware che ha aggirato l'EDR (2023) endpoint di Schaefer Kalk non sono riusciti a intercettare una campagna ransomware attiva che si stava diffondendo lateralmente attraverso la rete. L'analisi del traffico di rete, esaminando i flussi est-ovest che l'EDR non è in grado di monitorare, ha rilevato il movimento laterale e ha contenuto l'attacco prima che raggiungesse i sistemi di produzione.

Globe Telecom — Riduzione del 99% del rumore degli avvisi e risposta più rapida del 75% (2024) Globe Telecom ha ridotto i tempi di risposta agli incidenti da 16 ore a 3,5 ore. Il rumore degli avvisi è diminuito del 99% e gli escalation sono calati del 96%, consentendo agli analisti di concentrarsi su sei incidenti reali anziché su centinaia di migliaia di avvisi di scarso valore. Il fattore alla base: una prioritizzazione basata sul rischio, fondata su un'intelligenza artificiale comportamentale che opera su cloud di rete, identità e cloud , anziché sul confronto delle firme con i singoli avvisi.

Un'organizzazione sanitaria globale — individuazione di abusi di credenziali sfuggiti al SIEM (2024) A pochi giorni dall'implementazione, l'analisi del traffico di rete ha rilevato credenziali rubate, cloud , tentativi di escalation dei privilegi e attività di persistenza su AWS che il SIEM dell'organizzazione non era riuscito a individuare. Il rilevamento delle identità dai protocolli di rete — Kerberos, LDAP, DCE/RPC — ha fornito il segnale che i sistemi basati sui log non erano in grado di ricostruire. Il SOC è intervenuto prima che i dati o le operazioni subissero alcun impatto.

Conclusione chiave: i risultati dipendono dal posizionamento dei sensori lungo i segmenti est-ovest, dalla registrazione del protocollo che includa il traffico di autenticazione e dai modelli comportamentali che analizzano i movimenti degli utenti all'interno della rete, piuttosto che da singoli avvisi provenienti da singoli endpoint.

Come Vectra AI l'analisi del traffico di rete

L'analisi del traffico di rete Vectra AI si basa su quattro livelli ingegneristici che operano in sinergia per trasformare i dati grezzi di telemetria relativi alla rete e alle identità in rilevamenti prioritari e utilizzabili. Non si tratta di funzionalità NDR generiche, bensì delle specifiche scelte architetturali che determinano le prestazioni della piattaforma in produzione in ambienti ibridi,cloud e basati sulle identità.

Livello 1: Modellizzazione del comportamento dell'autore dell'attacco

Ogni rilevamento si basa su ricerche nel campo della sicurezza, non su anomalie statistiche. I modelli sono direttamente correlati alle MITRE ATT&CK e alle tecniche MITRE ATT&CK nei settori della rete, dell'identità, cloud e del SaaS.

Gli ingegneri di rilevamento e i data scientist definiscono tre elementi per ciascuna tecnica di attacco:

• Cosa deve essere rilevato
• Quali dati telemetrici sono necessari per rilevarlo?
• Quale modello di IA/ML è più adatto a quel problema specifico?

I modelli vengono selezionati in base al problema specifico — abuso delle credenziali, spostamento laterale, comando e controllo, persistenza — e non applicati in modo generico. Ciò garantisce che i rilevamenti siano spiegabili, ripetibili e giustificabili, con un chiaro collegamento tra la tecnica dell'autore dell'attacco e il risultato della difesa. Vectra AI contribuito a definire e influenzare il modo in cui le tecniche ATT&CK basate sulla rete e sull'identità vengono comprese e mappate dalla più ampia comunità di sicurezza.

Livello 2: Jetstream — motore di streaming in tempo reale

Jetstream elabora i dati di telemetria relativi alla rete e alle identità in tempo reale, non a posteriori.

A differenza dei sistemi basati su batch e incentrati sui log, che memorizzano il traffico per analizzarlo in un secondo momento, Jetstream acquisisce, arricchisce e correla i dati di telemetria in modo continuo man mano che gli eventi si verificano nell'azienda ibrida. È proprio questo che consente di individuare i modelli comportamentali mentre l'attacco è in corso, anziché minuti o ore dopo.

Soprattutto per il monitoraggio del traffico est-ovest, lo streaming è fondamentale. I movimenti laterali che si sviluppano nell'arco di alcuni minuti non possono essere rilevati in modo affidabile dai sistemi basati su cicli di elaborazione in batch.

Livello 3: Struttura di trasmissione dei metadati

Anziché basarsi sulla cattura completa dei pacchetti o sull'acquisizione dei log grezzi, Vectra AI , normalizza e arricchisce i metadati rilevanti per la sicurezza provenienti dall'intera rete ibrida.

Tra le fonti figurano:

• Flussi di rete
• Eventi relativi all'identità
• Cloud
• Interazioni SaaS
• Telemetria delle infrastrutture

Ogni record di metadati viene costantemente arricchito con informazioni contestuali — identità, ruolo della risorsa, cronologia dei comportamenti, fase dell'attacco e profilo di rischio — creando un livello di intelligence condivisa che abbraccia i flussi di lavoro relativi al rilevamento, all'analisi e alla risposta. Gli analisti ottengono una visibilità approfondita senza i costi di archiviazione e le ripercussioni sulle prestazioni legati alla gestione della cattura completa dei pacchetti su larga scala.

Livello 4: Attribuzione multistrato

In contesti in cui gli aggressori abusano delle identità, si spacciano per servizi e si muovono lateralmente, l'attribuzione deve andare oltre gli indirizzi IP e la correlazione di singoli eventi.

L'attribuzione multilivello Vectra AI collega costantemente le attività tra utenti, account di servizio, carichi di lavoro, host e infrastruttura, combinando il comportamento di rete, il contesto identitario e le informazioni sui privilegi. Tre funzionalità operano in sinergia per rendere possibile tutto ciò:

‍

Nel loro insieme, questi livelli consentono alla piattaforma di stabilire con certezza chi sta facendo cosa, dove e con quale livello di autorizzazione, anche quando gli aggressori utilizzano credenziali valide e si mimetizzano tra i normali flussi di traffico.

Conclusione

Il rilevamento e la risposta in rete non si riducono alla scelta di un singolo prodotto, ma costituiscono un insieme di decisioni tecniche interconnesse che determinano se il vostro team di sicurezza è in grado di individuare i movimenti laterali nel momento stesso in cui avvengono, ricavare il contesto identitario dai protocolli di rete, analizzare il traffico crittografato senza decrittografia e scalare il rilevamento in ambienti distribuiti senza centralizzare i dati archiviati.

I principi fondamentali illustrati in questa pagina si traducono direttamente in risultati operativi: il posizionamento dei sensori in direzione est-ovest determina se i movimenti laterali vengono rilevati o dedotti; le decisioni relative all'acquisizione dei protocolli determinano se gli attacchi basati sull'identità sono visibili o invisibili; la progettazione di una pipeline parallela determina se l'analisi del traffico crittografato compromette l'accuratezza del rilevamento; e l'architettura Global View determina se le implementazioni distribuite garantiscono una visibilità unificata o una copertura frammentata.

Scopri come la piattaforma Vectra AI offre un'analisi del traffico di rete in grado di individuare movimenti laterali, abusi di identità e comunicazioni di comando e controllo crittografate, individuando ciò che sfugge agli strumenti di protezione perimetrale e endpoint .