Collegare i flow log cloud a Sophos XDR e SIEM

I flow log cloud descrivono le connessioni di rete, non l’intero contenuto dei pacchetti. Sophos XDR può acquisirli da AWS VPC Flow Logs, Azure Network Watcher, Google Cloud Platform (GCP) e Oracle Cloud Infrastructure (OCI). Il percorso dipende dalla sorgente: S3 e Lambda per AWS, Azure Storage e una Function per Network Watcher, Pub/Sub per GCP e Streaming per OCI.

La telemetria netflow di queste integrazioni richiede Sophos Next-Gen SIEM. GCP e OCI forniscono anche altri schemi attraverso le stesse integrazioni; ciò non rende SIEM obbligatorio per tutti i dati cloud di audit o sicurezza. Prima verificare categorie necessarie, tenant, aggiornamento Fusion ed entitlement. L’articolo su SIEM e pianificazione della conservazione chiarisce gli aspetti commerciali.

Questi collegamenti diretti sono diversi da un collector syslog ospitato nel cloud. Per quest’ultimo vale il runbook del collector XDR.

Prima della modifica cloud

Servono il riquadro prodotto del tenant corretto in Security Operations > Integrations > Marketplace, permessi amministrativi cloud approvati per le risorse interessate e un team responsabile di costi ricorrenti, chiavi e qualità dei dati. Verificare disponibilità e campi nel proprio tenant; un riquadro mancante non va sostituito con un’integrazione dal nome simile.

Documentare per ogni sorgente account o subscription cloud, regione, categorie desiderate, integrazione di destinazione e inizio acquisizione. Limitare i permessi al percorso previsto. I privilegi amministrativi necessari al deployment non giustificano l’uso permanente di un account amministratore personale come identità dell’integrazione. Lambda, Storage e Pub/Sub possono generare costi cloud separati.

Uno stato verde conferma la comunicazione, non l’acquisizione completa. Il collaudo richiede un evento innocuo autorizzato, evidenza e ora alla sorgente, poi il corrispondente record normalizzato. La guida alle integrazioni spiega permessi, flusso e distinzione dalle azioni di risposta.

AWS VPC Flow Logs tramite il proprio bucket S3

AWS VPC Flow Logs viene acquisito da un proprio bucket Amazon S3. Sophos fornisce un template CloudFormation che crea la funzione Lambda di inoltro. Servono account AWS, bucket con i flow log e permessi per creare le risorse Lambda, CloudFormation e IAM necessarie.

Aprire AWS VPC Flow Logs nel Marketplace Sophos. In Configured integrations > Add new, leggere le informazioni S3, scegliere Next, assegnare un nome riconoscibile e selezionare Done. Scaricare il template CloudFormation generato dopo il provisioning e conservarlo con accesso limitato.
In AWS indirizzare l’export VPC previsto a quel bucket. La destinazione deve essere Amazon S3. Usare solo il formato AWS predefinito; un formato personalizzato può compromettere normalizzazione e rilevamenti.
Nella stessa regione AWS del bucket di log aprire CloudFormation > Create stack, caricare il template e scegliere un nome senza spazi. Impostare IntegrationType su awsvpcflow. In NotificationBucket inserire il nome del bucket, non un URL o URI S3. Se si usa intenzionalmente SNS invece delle notifiche S3, inserire l’ARN in SNSNotificationarn. Verificare gli altri parametri rispetto al percorso pianificato.
Verificare e confermare la creazione delle risorse IAM, creare lo stack e attendere CREATE_COMPLETE. Un bucket separato contenente il template non deve essere reso pubblico.
In Lambda aprire la funzione creata dallo stack. In Function overview > Add Trigger, aggiungere il bucket di log come sorgente S3. Scegliere Event Type: All Object Create Events. Prefix contiene solo il prefisso reale dei log; lasciarlo vuoto se non esiste un prefisso. Lasciare Suffix vuoto. Valutare i costi e aggiungere il trigger.
Generare un flusso di rete innocuo e adeguato nel VPC selezionato. Verificare prima il record nel bucket, poi confrontare intervallo temporale e dettagli di connessione nello schema Sophos netflow.

Il formato predefinito richiesto è:

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

Se i dati non arrivano, confrontare destinazione, nuovi oggetti, regione e prefisso del trigger. Il template imposta Reserved Concurrency a 5 per default: non è una garanzia di dimensionamento. Valutare carico e metriche CloudWatch. Rate Exceeded può indicare una quota di concorrenza AWS; ricreare ripetutamente l’integrazione non risolve quel limite.

Azure Network Watcher tramite Storage e Azure Function

Network Watcher scrive NSG Flow Logs o VNet Flow Logs in un Azure Storage Account. Non è più possibile creare nuovi NSG Flow Logs. Per le nuove sorgenti pianificare VNet Flow Logs. Gli NSG Flow Logs esistenti possono essere collegati fino alla loro sostituzione; Microsoft ritirerà la funzione il 30 settembre 2027. Pianificarne la migrazione a VNet Flow Logs prima di tale data. I due tipi richiedono integrazioni Sophos separate, perché utilizzano container Blob o Data Source Keys differenti.

Servono una subscription Azure attiva, Storage Account con container Blob e flow log abilitati e un piano Azure Function supportato. Sono documentati Basic con B1, B2 o B3, Dynamic con Y1 e specifici codici Premium. Isolated non è supportato. Scegliere un codice Premium dall’elenco attualmente proposto, senza dedurne il supporto dal nome simile di un piano Azure.

In Network Watcher inviare VNet Flow Logs per una nuova sorgente allo Storage Account previsto; usare gli NSG Flow Logs esistenti solo come soluzione transitoria fino alla migrazione. Annotare account e container e verificare che arrivino effettivamente nuovi oggetti.
Nel Marketplace Sophos aprire Microsoft Azure Network Watcher - Azure Storage Account e creare l’integrazione in Azure Storage Accounts > Set Up.
Copiare esattamente Storage Account Name. Function App Name è un nome descrittivo libero, ad esempio NSGFlowLogsForwarder, non un valore fisso del prodotto. Per Data Source Key usare insights-logs-networksecuritygroupflowevent per NSG o insights-logs-flowlogflowevent per VNet.
Scegliere Azure Function Service Plan Type, il relativo Service Plan Code e Num Workers. Il default è un worker. Per Basic B2/B3 è documentato un massimo di tre worker; non estendere questa limitazione agli altri piani.
Con Done generare e scaricare AzureFunction.json. In Azure caricarlo tramite Deploy a custom template > Build your own template in the editor. Verificare Resource Group e parametri, poi scegliere Review + Create e Create.
Storage Account e Function possono appartenere a Subscription IDs o Resource Groups differenti. In tal caso impostare esplicitamente Storage Account Subscription ID e Storage Account Resource Group sulla sorgente reale.
Dopo il deployment verificare un flusso atteso nel container corretto e poi in netflow in Sophos. Collaudare separatamente ogni integrazione se si utilizzano entrambi i tipi.

Se la Function è disponibile ma mancano dati, confrontare container, Data Source Key, associazione Subscription/Resource Group e piano. Una seconda integrazione per lo stesso flusso può creare duplicati: non è una riparazione generica.

GCP tramite Pub/Sub

GCP fornisce cloudaudit, thirdpartyalert e, con SIEM, netflow. Le sorgenti supportate includono Cloud Audit Logs, Security Command Center Findings, VPC Flow Logs e GKE Dataplane V2. Includere soltanto le categorie scelte consapevolmente.

Nel progetto GCP corretto creare un topic in Pub/Sub > Topics, poi una subscription in Subscriptions. Impostare Acknowledgement deadline a 300 secondi.
In Logging > Log router > Create Sink creare un sink verso quel Cloud Pub/Sub topic. Limitare gli inclusion filter alle sorgenti necessarie. I log di organizzazione e cartella richiedono un sink aggregato adeguato; un sink di progetto non li comprende automaticamente.
Creare un service account dedicato. In Add Principal sulla subscription Pub/Sub assegnare al suo ID il ruolo Pub/Sub Subscriber.
Creare anche un ruolo personalizzato contenente monitoring.timeSeries.list e assegnarlo al service account. Un account già usato da Sophos XDR può essere riutilizzato se anche questo permesso necessario è approvato.
Generare una chiave JSON e conservarla in modo protetto. Nel Marketplace Sophos aprire GCP > Configured integrations > Add new, inserire nome, Project ID e Subscription ID Pub/Sub, poi caricare il JSON corretto con Upload Key File.
Abilitare realmente le sorgenti selezionate: per i Data Access audit log occorre selezionare esplicitamente i servizi in IAM & Admin > Audit Logs. I finding SCC usano l’export Pub/Sub dedicato. Abilitare VPC Flow Logs a livello di subnet; il campionamento ne limita la capacità descrittiva rispetto a una cattura completa dei pacchetti.
GKE Dataplane V2 deve essere selezionato durante la creazione del cluster. Verificare poi Network Policy Logging e filtro del sink. Non sostituire senza pianificazione un cluster esistente soltanto per un pilot di logging.
Generare un evento adatto per ogni categoria abilitata e verificare separatamente evidenza alla sorgente, percorso Pub/Sub e schema normalizzato.

Per la rotazione creare prima la nuova chiave JSON e aggiornare l’integrazione Sophos esistente. In API Query Log, secrets cache invalidated. Integration was updated. Restarting. indica l’aggiornamento. Eliminare la vecchia chiave GCP solo dopo aver nuovamente verificato l’acquisizione. Il solo caricamento del file non basta.

OCI tramite Streaming

OCI fornisce cloudaudit, http, nids e, con SIEM, netflow. Servono un OCI stream, i log desiderati e un service connector. L’identità necessita di stream-pull per leggere lo stream; non sono necessari privilegi amministrativi generici per la raccolta continua.

Preparare un utente di logging dedicato e la struttura approvata di gruppi/compartment. Concedere solo la lettura necessaria dello stream previsto.
In OCI Streams > Create Stream, scegliere lo Stream Pool desiderato. Annotare la Stream Pool OCID: non è intercambiabile con un ID qualsiasi di stream o compartment.
Tramite Connector Hub instradare verso lo stream i log approvati di audit, flussi, load balancer, WAF o firewall. Prima di Sophos verificare che il connector trasferisca dati alla corretta destinazione Streaming. Una destinazione differente non alimenta automaticamente questo stream.
Nel Marketplace Sophos aprire OCI > Configured integrations > Add new. Inserire Name, Username dedicato, relativo Auth token, Stream Pool ID, Tenant Name, Topic Name dello stream e Region.
Con compartment annidati, Tenant Name è il nome della tenancy senza la catena dei compartment. Per utenti federati nel caso documentato OracleIdentityCloudService, usare ad esempio acme/OracleIdentityCloudService, dove acme rappresenta la propria tenancy. Non confondere i due casi.
Scegliere Done e verificare un evento adatto in OCI, nel percorso Streaming e nello schema Sophos atteso. Un evento cloud audit non collauda un ulteriore flusso netflow.

Se l’acquisizione manca, controllare prima Stream Pool, nome stream, regione, token e stream-pull. Se manca una sola categoria, esaminare selezione sorgenti e routing del connector prima di ricreare l’intera integrazione.

Verificare qualità e rimozione controllata

Per ogni categoria documentare sorgente, inizio acquisizione, periodo, schema normalizzato e un esempio riproducibile. Confrontare ora e fuso con l’evidenza alla sorgente. Un normale flusso o evento di audit non deve necessariamente generare detection o case MDR. Una connessione verde o un record trovato non prova anni di conservazione.

Prima della rimozione identificare percorso e risorse condivise. Arrestare soltanto export, sink, trigger o connector approvato; non cancellare indiscriminatamente bucket, topic, Storage Account o stream condivisi. Dopo aver verificato che non arrivino nuovi record, rimuovere configurazione Sophos e chiavi o risorse esclusivamente dedicate secondo le decisioni di change e conservazione. Eliminare una connessione non prova la cancellazione della telemetria storica.

Durante un pilot fallito mantenere disponibili i precedenti percorsi necessari. Il rollback consiste nell’annullare la modifica documentata di routing o export e verificarne l’esito. Non annulla automaticamente dati già trasmessi, costi cloud o eventi persi.