Migrare i Log Collector SVA a Sophos XDR Data Collectors

Durante il passaggio alla soluzione Sophos XDR avanzata, Sophos predispone una nuova configurazione XDR Data Collector per i Log Collector Sophos Security Virtual Appliance (SVA) idonei. Questo non installa né attiva automaticamente la VM nel proprio ambiente. Occorre distribuire il sostituto, trasferire il flusso Syslog e verificare l’arrivo di nuovi eventi. Se si utilizza lo stesso indirizzo IP, il vecchio collector non deve essere in esecuzione quando si avvia quello nuovo.

XDR Data Collector è un ricevitore Syslog virtuale, locale oppure in AWS, Azure o GCP. Inoltra i log acquisiti a Sophos XDR. Un’integrazione API diretta non richiede questo ricevitore Syslog. Il runbook delle integrazioni spiega Data Ingest, Response Actions e questi tipi di connessione.

Se si utilizza già Sophos Next-Gen SIEM, Sophos consiglia di sostituire i collector Syslog SVA esistenti con XDR Data Collectors per usufruire dell’intera conservazione dei dati supportata dal prodotto SIEM. Le integrazioni API esistenti non devono essere riconfigurate per questo cambio di collector Syslog. Ciò non implica né una durata di conservazione specifica né il diritto alla conservazione SIEM per tutti i tenant XDR: restano determinanti le condizioni di conservazione del proprio prodotto SIEM.

Stato verificato all’11 ottobre 2026: la guida alla migrazione del 1 ottobre 2026 integra il rollout di settembre. Il precedente percorso della documentazione EAP indica la provenienza della versione, ma non garantisce che la funzione sia già disponibile in ogni tenant. Verificare prima lo stato dell’upgrade del tenant e il collector effettivamente disponibile in Security Operations > Integrations > Data Collectors. Questo runbook descrive il passaggio Syslog e un deployment locale concreto su vSphere; chiarisce gli indirizzi cloud, ma la creazione delle relative risorse cloud non fa parte dei passaggi vSphere.

Inventariare i carichi di lavoro esistenti e le impostazioni non migrate

Per ogni vecchio collector SVA occorrono piattaforma, nome, hostname, valori di rete statici o lease DHCP, tutte le sorgenti mittenti e le rispettive destinazioni, porte e protocolli Syslog. Annotare anche formato dei dati, selezione degli Event Type, esclusioni di domini e protocolli, impostazioni passthrough e credenziali necessarie. Documentare l’ultimo arrivo di dati verificabile per ciascuna sorgente: dopo il passaggio sarà così possibile distinguere un flusso senza attività da un errore.

Vengono trasferiti automaticamente il nome del collector, l’hostname o il nome derivato da esso, indirizzo IP statico, subnet mask, gateway e DNS oppure l’impostazione DHCP, nonché le associazioni di porte e protocolli Syslog. Le porte sorgente originali vengono mantenute e mappate alle porte Syslog standard UDP/514 o TCP/601. Il tipo di piattaforma determina il nuovo collector cloud o locale.

Non vengono trasferiti automaticamente:

• Integrazioni NDR: NDR non utilizza l’inoltro Syslog. In una SVA con carichi misti viene migrata solo la parte Syslog; una SVA esclusivamente NDR non riceve un XDR Data Collector per questo scopo.
• Filtri Event Type ed elenchi di esclusione di domini e protocolli.
• Impostazioni di formato Syslog e passthrough specifiche della SVA.
• Credenziali delle integrazioni.
• Investigation Consoles, Nessus Scanner e altri tipi di VM diversi dai Log Collector SVA.
• Appliance hardware fisiche: non vengono migrate automaticamente a collector virtuali.

Verificare espressamente quali filtri e formati servono ancora nella nuova integrazione e quali opzioni offre il connettore. Filtri mancanti possono comportare l’acquisizione di più dati del previsto; un formato errato può far elaborare i log solo come eventi generici. Non copiare le credenziali da ticket o vecchi screenshot: fornirle nuovamente attraverso il sistema di gestione dei secret previsto.

Se NDR funziona sulla stessa SVA, il passaggio Syslog non deve spegnere incidentalmente il sensore. La variante con lo stesso IP richiede lo spegnimento della vecchia SVA e interrompe quindi anche il suo carico NDR. Pianificarne separatamente il funzionamento oppure scegliere un IP diverso per il nuovo collector Syslog, affinché la SVA possa continuare a eseguire NDR. Il runbook operativo NDR tratta questo carico di lavoro; predisporre un sostituto Syslog non equivale a migrare NDR.

Scegliere la variante di indirizzamento prima del download

L’indirizzo di destinazione determina se entrambe le VM possono funzionare contemporaneamente e se occorre modificare le sorgenti.

Con lo stesso IP statico, prevedere una breve fase di passaggio: spegnere la vecchia SVA e poi avviare la nuova VM. Le sorgenti mantengono la destinazione. Questo non garantisce un trasferimento senza perdite: la conservazione degli eventi durante l’interruzione dipende anche dal buffering e dal trasporto del sistema sorgente.

Per un passaggio graduale, definire il nuovo IP statico prima del download dell’ISO. Esempio: il vecchio collector utilizza 192.0.2.10, quello nuovo 192.0.2.20. Non utilizzare questi indirizzi di documentazione in produzione. Scegliere invece un indirizzo libero nella propria rete corretta e verificare subnet, gateway, DNS e raggiungibilità dalle reti sorgente. Un nuovo IP facilita il ripristino e permette di trasferire le sorgenti singolarmente, ma richiede l’adeguamento delle destinazioni e delle regole firewall.

Con DHCP e riutilizzo del vecchio IP, documentare prima del passaggio gli indirizzi MAC della vecchia e della nuova VM, la prenotazione IP esistente e lo stato attuale dei lease. Modificare o creare quindi la prenotazione per assegnare il vecchio IP al MAC della nuova VM, seguendo la procedura documentata per prenotazioni e lease della piattaforma DHCP utilizzata. Spegnere poi la vecchia SVA e solo successivamente avviare il nuovo collector. Verificarne il lease effettivo e l’IP assegnato prima della verifica dei dati. Una prenotazione non impedisce a una vecchia VM ancora accesa di usare lo stesso indirizzo.

Per i collector cloud, l’indirizzo cambia sempre. In AWS con CloudFormation, il valore CTPxCollectorDnsName si trova in Outputs dello stack. È il nome DNS del Network Load Balancer ed è preferibile a un IP impostato staticamente per le sorgenti Syslog. In Azure verificare l’indirizzo dell’interfaccia di rete della VM nel portale Azure; in GCP verificare l’indirizzo interno in Compute Engine > VM instances. Gli indirizzi DHCP si possono individuare nella tabella dei lease tramite il nuovo MAC oppure in Data Collectors. Non confondere questa destinazione delle sorgenti con gli indirizzi regionali di uplink Sophos.

Preparare il percorso di rete e le risorse del collector

Il caricamento dal collector a Sophos XDR utilizza mTLS con TLS 1.3 e TCP/443 in uscita. Questo non significa che non servano porte in ingresso: le proprie sorgenti Syslog devono raggiungere il collector sulla porta e con il protocollo configurati. Le destinazioni standard sono UDP/514 e TCP/601; confrontare inoltre le associazioni di porte migrate con la configurazione precedente. Non creare un’autorizzazione indiscriminata da Internet verso il ricevitore Syslog.

Autorizzare uplink regionale, DNS e sincronizzazione dell’ora

Le seguenti destinazioni di uplink del collector sono un’istantanea verificata all’11 ottobre 2026. L’associazione US1/US2/US3/EU1/EU2 deriva dalla configurazione XDR del collector, non da una presunta equivalenza con una regione AWS di Central. Usare solo la regione effettivamente assegnata. L’elenco IP Sophos esistente per le chiamate API in ingresso presso il fornitore di terze parti è un’altra allowlist.

Se il proprio firewall richiede autorizzazioni basate su IP, questa istantanea comprende i seguenti indirizzi di destinazione. Non unire le regioni:

• US1: 18.217.45.178/32, 3.16.4.173/32, 18.224.219.97/32, 13.59.146.90/32, 3.16.16.254/32, 18.223.74.238/32.
• US2: 52.14.113.127/32, 3.141.73.137/32, 3.136.78.106/32.
• US3: 44.229.101.49, 35.166.77.47, 34.214.135.78.
• EU1: 18.158.143.139/32, 35.159.14.37/32, 52.59.37.234/32.
• EU2: 54.217.251.111/32, 54.194.78.20/32, 52.50.215.147/32.

Prima di una modifica in produzione, confrontare regione e destinazioni con la configurazione corrente del tenant e la safelist del collector mantenuta dal responsabile operativo. Le differenze richiedono un change verificato, non un’autorizzazione preventivamente più ampia. La forma tecnica dell’endpoint secureworks.com rimane invariata.

Il collector richiede inoltre UDP e TCP/53 verso i server DNS indicati durante il provisioning. Per sincronizzare l’ora serve UDP/123 verso i server NTP scelti. In assenza di una propria impostazione NTP, i collector non AWS utilizzano da 0.pool.ntp.org a 3.pool.ntp.org; per AWS la destinazione predefinita è 169.254.169.123. Con NTP locale, il traffico tra collector e server orario deve essere autorizzato in entrambe le direzioni. Per il collector locale, questi valori NTP servono al bootstrap; dopo la connessione, il canale del backend XDR gestisce la sincronizzazione dell’ora. Secondo la guida della piattaforma, i domain controller Windows non sono destinazioni NTP per questo host non appartenente al dominio.

Un forward web proxy si può configurare tramite Host Proxy. La panoramica dei collector esclude i proxy autenticati configurati staticamente, mentre la guida locale mostra anche una sintassi URL con utente e password. Queste indicazioni non coincidono. Non pianificare quindi un percorso di produzione tramite proxy autenticato senza un’autorizzazione chiarita con Sophos; non aggirare il conflitto incorporando credenziali nell’ISO. In presenza di TLS Inspection, lo specifico uplink mTLS deve funzionare senza interventi MITM. Limitare un’eventuale eccezione alle connessioni necessarie del collector.

Non dimensionare la VM locale secondo i vecchi valori SVA

La nuova VM locale richiede 4 vCPU ad almeno 2 GHz, 8 GB di RAM, un disco di sistema da 20 GB e un disco dati da 200 GB. La guida della piattaforma indica come ambienti consigliati vSphere ESXi 6.7 o successivo, Hyper-V 8.0 su Windows Server 2016 o successivo e Nutanix 6.8.x o successivo. La VM deve poter vedere le funzionalità CPU x86-64-v2; una maschera di compatibilità CPU inadeguata può impedirne l’avvio.

Il valore fino a 200'000 EPS è un limite superiore per collector cloud e locali configurati adeguatamente, non una garanzia di throughput con queste risorse minime. Dimensionare in base a numero, dimensione e picchi degli eventi e verificare il flusso effettivo. Non installare sul collector strumenti di terze parti o applicazioni aggiuntive. Gli aggiornamenti avvengono automaticamente, solitamente ogni 24 ore quando la connessione funziona correttamente.

Distribuire su vSphere il collector locale già predisposto

Per una migrazione esistente, utilizzare la relativa configurazione in Security Operations > Integrations > Data Collectors. Confrontare nome, valori di rete e associazioni Syslog con la vecchia SVA. Scaricare l’ISO con la configurazione del collector e l’OVA per la VM. I due file devono corrispondere: un’ISO di un altro collector effettuerebbe il provisioning della configurazione sbagliata. Conservare i file di configurazione con accesso limitato.

Se la configurazione manca, verificare prima le esclusioni e gli errori di rete nella sezione successiva. Per un sostituto deliberatamente creato a mano, l’interfaccia offre Actions > Add Collector > On-Premises > Next. Inserire nome e hostname, eventualmente descrizione, Host Proxy e NTP, quindi DHCP oppure tutti i valori di rete statici e creare con Create Collector. Questo non giustifica la creazione incontrollata di un collector duplicato accanto a una migrazione già presente.

Su vSphere, procedere così:

1. Nella vSphere Web Console aprire Virtual Machines > Create / Register VM e scegliere Deploy a virtual machine from an OVF or OVA file.
2. Assegnare un nome VM univoco, ad esempio sophos-xdr-collector, e selezionare l’OVA scaricata. Il nome è libero: deve distinguere la VM dalla vecchia SVA nell’hypervisor.
3. Scegliere un datastore con almeno 220 GB liberi per i due dischi. Controllare l’associazione di rete e la configurazione dei dischi, verificare il riepilogo e terminare con Finish. Lasciare per il momento la VM spenta.
4. In Storage > Datastore Browser, caricare l’ISO di configurazione corretta.
5. Aprire Edit Settings della VM. Cambiare il CD-ROM da Client Device a Datastore ISO File, selezionare l’ISO caricata e salvare. Prima del primo avvio, verificare che l’ISO sia effettivamente collegata e che la VM raggiunga la rete sorgente corretta.
6. Se si usa lo stesso IP, spegnere ora la vecchia SVA. Solo dopo avviare la nuova VM. Con un nuovo IP, la vecchia SVA può restare accesa; trasferire successivamente le sorgenti una alla volta.
7. In Security Operations > Integrations > Data Collectors, attendere che il nuovo collector mostri Ready. Solo allora è possibile scollegare l’ISO. Ready non conferma ancora la corretta acquisizione di ogni sorgente.

Per Hyper-V, Sophos fornisce un pacchetto VHD invece dell’OVA; per Nutanix, file QCOW2. Restano necessari il secondo disco dati e l’ISO collegata al primo avvio. Non applicare a queste piattaforme la sequenza di clic vSphere. Analogamente, i collector cloud devono essere distribuiti con le risorse della rispettiva piattaforma, non come OVA in vSphere.

Trasferire le sorgenti e verificare il flusso dei dati

Se la destinazione cambia, aggiornare tutti i dispositivi e le applicazioni interessati con il nuovo IP o nome DNS del collector. Cambiare solo la destinazione, non porta, protocollo o formato dei log senza verificarli: queste associazioni devono essere trasferite dalla SVA. Se una sorgente inviava tramite UDP/514, per questa migrazione continua a utilizzare UDP/514. Il passaggio a TCP è un change separato che richiede la verifica del sistema sorgente.

Con IP diversi, trasferire inizialmente una sorgente di portata limitata. Generare un evento innocuo acquisito dal connettore e annotare sorgente, tipo di evento e ora con fuso orario. Cercarlo attraverso il percorso dati o query offerto in XDR per questa integrazione. L’evidenza deve mostrare tenant corretto, sorgente, timestamp e formato dell’evento previsto. Considerare i ritardi attesi del connettore: un evento di test non deve necessariamente generare un case o una detection.

Trasferire le altre sorgenti solo dopo questa verifica. Confrontare per ogni sorgente gli ultimi eventi prima del passaggio e i primi dopo. Non tutte le sorgenti avranno la stessa durata o frequenza di eventi: contano l’attività effettiva e l’assenza di intervalli inspiegati. Evitare l’invio simultaneo non pianificato dello stesso flusso a entrambi i collector, perché può generare duplicati.

La SVA esistente può continuare a funzionare durante la pianificazione. I dati storici SVA già acquisiti rimangono interrogabili in XDR; il sostituto non deve inviarli di nuovo. Questo non costituisce una nuova promessa di conservazione illimitata. Lo spool da 200 GB del nuovo collector memorizza temporaneamente i log quando l’uplink è lento o temporaneamente interrotto. Non sostituisce la verifica della sorgente né garantisce la gestione di interruzioni di durata arbitraria.

La verifica operativa è completata solo quando tutte le sorgenti previste forniscono dati recenti correttamente associati, filtri ed esclusioni sono stati esaminati consapevolmente, DNS, sincronizzazione dell’ora e uplink funzionano ed eventualmente NDR continua a operare separatamente. Documentare l’ora del passaggio e il periodo di osservazione. Fino a quel momento, conservare la vecchia SVA e la sua configurazione per un possibile ripristino; solo dopo decidere come gestirne i carichi residui e la dismissione sicura.

Individuare gli errori e ripristinare senza conflitti IP

Il nuovo collector non è presente: un’appliance hardware, una SVA esclusivamente NDR o una VM non SVA non vengono migrate automaticamente. Per una SVA Syslog attivamente utilizzata, verificare che porta e protocollo siano configurati e che i valori di rete statici siano completi. Gateway o DNS mancanti possono impedire la migrazione. Correggere la configurazione di rete non valida in Fusion e concordare con il supporto una nuova migrazione oppure creare un collector manuale esplicitamente pianificato. Non usare indirizzi segnaposto solo per far accettare un modulo.

La nuova VM non si avvia: verificare associazione dell’ISO, secondo disco, RAM, vCPU e funzionalità x86-64-v2 visibili alla VM. Non installare software di riparazione o monitoraggio sul collector.

Il collector rimane offline: verificare prima l’IP o il lease effettivamente assegnato, gateway, DNS e sincronizzazione dell’ora durante il bootstrap. Controllare poi i log firewall/proxy per l’uplink regionale TCP/443. Una porta in uscita aperta non dimostra da sola il successo del canale mTLS. Nello scenario con lo stesso IP, assicurarsi anche che la vecchia SVA sia davvero spenta.

Il collector è Ready, ma manca una sorgente: verificare destinazione della sorgente, route e porta Syslog in ingresso. Confrontare associazione di porta e formato con la vecchia integrazione. Un log forwarder a monte deve mantenere il formato previsto dall’integrazione; altrimenti i dati possono arrivare come eventi generici anziché nello schema atteso. Verificare prima il percorso dei dati, poi cercare una detection.

Per il ripristino, distinguere indirizzi statici e prenotazioni DHCP:

• Stesso IP statico: spegnere la nuova VM e solo dopo avviare la vecchia SVA con la sua configurazione statica conservata. Le sorgenti mantengono la destinazione precedente. Verificare che la vecchia SVA utilizzi effettivamente questo IP e riceva e inoltri nuovi eventi Syslog. Non accendere mai entrambe le VM con questo indirizzo.
• Prenotazione DHCP sullo stesso IP: spegnere prima la nuova VM. Riassegnare poi la prenotazione del vecchio IP al MAC documentato della vecchia SVA e gestire lo stato dei lease seguendo la procedura documentata della propria piattaforma DHCP. Qui non si presuppone alcun comando universale di eliminazione dei lease. Solo dopo avviare la vecchia SVA, controllarne lease effettivo e IP e dimostrare acquisizione e inoltro con un nuovo evento Syslog. Le sorgenti mantengono la destinazione precedente: il semplice avvio della SVA non dimostra quindi che il ripristino funzioni. Non accendere mai entrambe le VM con questo indirizzo.
• IP diverso o destinazione DNS: riportare al vecchio collector le destinazioni documentate delle sorgenti ed eventualmente le relative regole di rete. Con un nuovo evento, verificare che la vecchia SVA riceva e inoltri di nuovo. Dismettere il nuovo collector solo dopo aver verificato tutte le associazioni.

Il ripristino è verificato solo quando la vecchia SVA detiene in modo dimostrabile l’indirizzo di destinazione previsto e i nuovi eventi Syslog vengono nuovamente acquisiti e inoltrati.

Il ripristino è possibile solo finché la vecchia SVA è disponibile e la sua configurazione è conservata. Non annulla l’upgrade del prodotto effettuato dal fornitore e non garantisce il recupero degli eventi non consegnati. Sophos annuncia una futura fine del supporto per i Log Collector SVA, ma lo stato della migrazione qui verificato non indica una data concreta. Dopo la migrazione, le nuove istanze Log Collector devono essere create come XDR Data Collectors; la vecchia SVA è quindi una possibilità limitata di ripristino dell’esistente, non una strategia di nuova installazione a lungo termine.

Se la causa rimane poco chiara, raccogliere identità del collector e del tenant, piattaforma, valori di rete privi di dati sensibili, sorgente interessata, intervalli temporali esatti, stato e messaggio di errore. Per l’escalation, seguire Aprire un ticket di supporto Sophos. Secret, ISO di configurazione e log non depurati dai dati sensibili non devono finire in ticket o screenshot accessibili liberamente.