Configurare le integrazioni MDR e XDR in Sophos Fusion

Le integrazioni consentono a Sophos Fusion (in precedenza Sophos Central) di riunire nel Sophos Data Lake la telemetria dei prodotti Sophos e di terze parti oppure di mettere a disposizione Response Actions mirate. È essenziale scegliere il tipo di integrazione corretto: Data Ingest fornisce dati per query, detection e indagini, mentre Response Action esegue un’azione nel prodotto collegato. Non tutti i prodotti supportano entrambe le direzioni.

Il punto di accesso dipende dalla soluzione disponibile nel tenant. Per la soluzione XDR/MDR avanzata si utilizza Security Operations > Integrations > Marketplace; le configurazioni Classic esistenti si trovano in Threat Analysis Center > Integrations. Le istruzioni TAC mantenute sotto descrivono questo percorso Classic e non costituiscono una sequenza di clic identica per la nuova interfaccia. La verifica dell’upgrade del tenant aiuta a identificarlo. I soli nomi Fusion visibili non dimostrano che l’upgrade del prodotto sia completato.

Nel percorso di onboarding Endpoint, questo articolo conclude la fase d’integrazione tra prodotti che si colloca fra la configurazione della protezione e l’accettazione operativa.

La procedura consigliata è la seguente: verificare licenza e sistema sorgente, scegliere in Marketplace la scheda del prodotto e la configurazione corrette, stabilire il collegamento con i privilegi minimi necessari, controllarlo in Configured e validarlo con un evento di test previsto. Solo a quel punto l’integrazione può essere considerata operativa.

Verificare separatamente connessione e flusso reale dei dati

Nell’interfaccia attuale aprire Security Operations > Integrations > Configured Integrations. In Data Ingest, lo stato mostra configurazione e connessione dell’integrazione API, syslog o Sophos. Il verde conferma la comunicazione, non eventi già normalizzati correttamente. Può comparire un avviso dopo 20 minuti senza comunicazione o se alcune risorse non segnalano; un errore dopo 60 minuti o autenticazione fallita. Il testo al passaggio del mouse ne precisa la causa.

Per un’integrazione API aprire il nome e API Query Logs. Il periodo predefinito è l’ultimo giorno, con selezione fino a sette giorni. In Details, confrontare i parametri con il tenant fonte corretto. Un’integrazione gerarchica può avere un parent con più endpoint child; un percorso parziale sano non prova che tutti i child funzionino.

Controllare poi Security Operations > Integrations > Configured Data Sources. Questa vista distinta indica se i log arrivano davvero e a quali schemi sono associati. Healthy indica attività entro un’ora, Warning fra una e 24 ore e Unhealthy oltre 24 ore senza attività. Sono criteri diversi dalle soglie di connessione sopra. Una fonte che invia raramente va valutata rispetto all’attività attesa, non dichiarata sana mediante un evento di test inventato.

Un clic sulla fonte mostra i messaggi per schema nelle ultime 24 ore. Per l’accettazione generare un evento autorizzato nel sistema fonte e confrontare orario, fonte, campi obbligatori e schema normalizzato. Advanced Search nei dettagli apre una ricerca predisposta per l’ID sensore sulle ultime 24 ore. La guida alla ricerca spiega ulteriori filtri. Se mancano dati, controllare prima fonte → integrazione/collector → schema; un normale evento di audit non deve necessariamente produrre una detection.

Export All as CSV o Export Selected as CSV salva l’inventario delle fonti tramite Data Exports. L’icona cestino rimuove invece solo il record della fonte, non la telemetria già ricevuta. La rimozione non è annullabile; una fonte che continua a inviare ricompare e la rimozione può richiedere fino a cinque minuti. Eliminare non conferma quindi la cancellazione della telemetria e non è un test di riparazione.

Visibilità, autorizzazioni e allowlist API attuale

Secondo il prodotto, Marketplace mostra schede Ingest e Actions separate. EDR senza XDR non mostra schede Ingest non-endpoint; le response actions possono restare visibili. Admin e Super Admin possono gestire le integrazioni. Help Desk e Read-only vedono solo configurazione e stato. Per Custom Roles assegnare Integration: read e solo i diritti necessari create, update, delete e download. Una funzione assente va verificata rispetto a licenza e ruolo prima di ampliare i permessi.

L’allowlist XDR attuale è distinta dall’istantanea IP Classic conservata sotto e dall’uplink del collector. Identificare la regione geografica XDR reale in Profile icon > Support settings, senza dedurla dal nome del prodotto. L’elenco del produttore del 25 settembre 2026 indica queste reti per chiamate amministrative/API al prodotto terzo:

Consentire solo la rete relativa all’integrazione effettiva, dopo approvazione del change. L’elenco non prova che ogni prodotto sia disponibile in tutte le regioni e non sostituisce la verifica delle destinazioni API attualmente necessarie. Il percorso mTLS in uscita del collector usa altre destinazioni.

Indirizzare precisamente le notifiche Health

Le regole sotto per 24 ore di guasto continuo, azzeramento del conto alla rovescia e ripetizione ogni 30 giorni valgono anche per la guida Fusion attuale del 20 ottobre 2026. L’e-mail non è un allarme immediato dopo i 20 o 60 minuti indicati sopra.

Aprire una regola personalizzata dei destinatari in General Settings > Platform > Notification Settings > Configure email alerts > Custom rules > + Create new rule. Dopo ruolo, amministratori/liste di distribuzione e ambito dispositivi, scegliere in Alert Types i filtri Medium alert, prodotto Sophos Central e categoria Central Integrations Alert. Quindi impostare nome/descrizione e salvare. Pianificare la distribuzione degli altri alert prima di salvare: la prima regola personalizzata disabilita l’invio predefinito di tutte le e-mail di alert a tutti gli amministratori. Mantenere gli altri destinatari necessari con ulteriori regole appropriate; non provocare un guasto su un connector di produzione solo per forzare un’e-mail.

Passi successivi per fonte

Per fonti personalizzate, HTTP Ingest, S3 e Azure spiegano i distinti percorsi di trasporto. Gestione del collector e deployment cloud completano il runbook di migrazione esistente. Cloud Flow Logs, telemetria di rete e Windows Event Logs trattano formati fonte e limiti di licenza per schema. Non tutta la telemetria di un produttore è automaticamente riservata a SIEM.

Dopo l’upgrade: ripristinare l’operatività delle Response Actions

Stato verificato all’11 ottobre 2026: la soluzione avanzata utilizza un modello diverso per esecuzione e autorizzazioni delle Actions. Le connessioni TAC esistenti e le loro credenziali non vengono semplicemente trasferite per questo scopo. Prima di una modifica, documentare tenant Microsoft interessati, connessioni, azioni attivate e responsabili. L’acquisizione riuscita di dati da un connettore Audit o Graph separato non è un test di risposta.

Collegare nuovamente Microsoft 365 o autorizzare di nuovo le credenziali

Per questi passaggi occorre Admin o Super Admin in Sophos Fusion e un Microsoft 365 administrator sul lato Microsoft. In ogni dialogo di consenso, verificare i diritti effettivamente richiesti e il tenant Microsoft corretto; non adottare senza verifica le autorizzazioni di una vecchia app TAC.

Se la precedente connessione TAC non è ancora configurata nella nuova interfaccia, crearla così:

1. Aprire Security Operations > Integrations > Marketplace e la scheda Actions Microsoft Graph API.
2. Scegliere Add new connection. Nella sezione Add a Connection, scegliere nuovamente Add new connection, inserire Name ed eventualmente Description e Tags, quindi proseguire con Done.
3. Avviare l’autorizzazione guidata Microsoft con Proceed. Un nome come M365-Response-Produktiv è solo un’etichetta liberamente selezionabile; contano il tenant sorgente corretto e i diritti approvati.
4. In Pick an account, scegliere l’account amministrativo previsto. La prima richiesta Permissions requested autorizza l’applicazione master Sophos. Dopo il ritorno a Sophos segue un secondo passaggio Microsoft per la connessione di risposta effettiva. Completare entrambi i dialoghi con Accept dopo aver verificato i diritti. Se uno viene annullato, non viene creata alcuna connessione.
5. Al ritorno, verificare le azioni proposte e salvare con Save solo l’ambito approvato. La nuova connessione deve comparire in Configured Integrations.
6. In Microsoft Entra, in Manage > All applications, utilizzare Refresh per controllare che la nuova applicazione di risposta risulti attivata.

Se una connessione è già presente in Microsoft Graph API > Configured Integrations, aprire il menu a tre punti accanto al nome e scegliere Edit Connection. Selezionare Re-Authorize Credentials e completare l’autorizzazione Microsoft. Il pulsante compare solo quando occorre una nuova autorizzazione e scompare al termine. Ripetere per ogni connessione interessata: ripararne una non basta per tutti i tenant o le configurazioni.

La guida aggiornata del 7 ottobre 2026 distingue espressamente tra protezione che continua a funzionare e azioni di risposta Microsoft che possono fallire fino alla nuova autorizzazione. Indica il 1 ottobre 2027 come scadenza delle credenziali precedenti. Se servono le Actions, non attendere quella data: la verifica del funzionamento deve essere effettuata ora.

La verifica richiede l’applicazione Entra corretta, le connessioni e le azioni attivate previste e un test approvato con un account dedicato. Utilizzare solo una modifica reversibile documentata per l’azione attuale. La coppia Classic Block user sign-in / Allow user sign-in descritta sotto non dimostra che ogni nuova Action abbia lo stesso nome o lo stesso percorso di ripristino. Le sessioni non possono essere ripristinate dopo la revoca. Nei dettagli dell’Action, View Executions > History mostra la cronologia; verificare inoltre lo stato effettivo in Microsoft. Il consenso o una voce di esecuzione riuscita, da soli, non sostituiscono questo controllo incrociato.

Aggiungere Sophos Firewall (Actions) solo se manca la connessione

Dopo l’upgrade del prodotto, aprire prima un case e verificare se sono disponibili le azioni Sophos Firewall. Se lo sono, non serve una nuova connessione. Se mancano:

1. Aprire Security Operations > Integrations > Marketplace.
2. Cercare e aprire Sophos Firewall (Actions).
3. Scegliere Add new connection e salvare con Save.

Questa connessione non richiede credenziali. Diventano poi disponibili dai case le azioni di risposta firewall, ad esempio il blocco di IP, domini o URL dannosi. Gli analisti MDR possono eseguirle nell’ambito delle impostazioni di risposta approvate; gli utenti XDR possono avviarle direttamente dal case. Verificarne la disponibilità senza bloccare destinazioni di produzione. Un test dell’effetto è un change separato e approvato con un percorso di ripristino specifico del prodotto chiarito in anticipo.

Disattivare le nuove Actions in modo mirato, senza eliminare le connessioni alla cieca

Per le Actions della soluzione avanzata esiste un interruttore documentato: in Security Operations > Integrations > Marketplace, Configured > Actions, aprire l’Action interessata e disattivarla nella sezione Enable/disable integration. Non è un interruttore universale per tutti i connettori Data Ingest. La disattivazione non annulla modifiche già eseguite nel sistema sorgente.

Delete Integration rimuove le connessioni e le condizioni associate e riporta la configurazione dell’Action allo stato iniziale. Anche la rimozione dell’unica connessione elimina le condizioni a essa associate. Salvare o documentare quindi prima connessioni e condizioni. Per annullare azioni di test, vale sempre il percorso concreto Microsoft o firewall, non l’eliminazione del connettore.

Automazioni XDR: distinguere Classic REST e GraphQL

Le informazioni sulle API sono un’integrazione del 9 ottobre 2026, non una promessa retroattiva relativa al lancio di settembre. Le nuove integrazioni XDR e i workflow XDR di scrittura su Fusion devono utilizzare le nuove GraphQL APIs. Questo è distinto da una connessione API del Marketplace: le sue chiamate REST possono continuare a essere dirette al fornitore di terze parti.

Le precedenti Cases REST API e Detections REST API si chiamano ora Classic XDR APIs e sono deprecate. La Detections REST API è già read-only. La Cases REST API rimane disponibile per le integrazioni esistenti; anche per questa è previsto il passaggio a read-only. Successivamente entrambe dovrebbero fornire dati storici fino alla loro rimozione. Questo stato non indica una data concreta di dismissione. Non eliminare quindi indiscriminatamente le integrazioni esistenti né riscriverne gli host a causa del nome Fusion.

Per ogni automazione, annotare API, operazioni di lettura e scrittura, periodo dei dati, tenant, diritti e gestione degli errori. Per i client esistenti, verificare separatamente se sono attesi dati attuali o storici e se un workflow di scrittura tenta ancora di accedere a Classic Detections. Per il passaggio a GraphQL, implementare mapping dei campi, paginazione, autenticazione, autorizzazioni e gestione degli errori secondo il nuovo schema concreto e confrontarli in un test isolato. Questo articolo non prescrive deliberatamente endpoint, nomi di mutation o payload inventati. L’inventario è completato quando ogni client ha un owner e una decisione verificabile di continuazione o migrazione; non costituisce ancora un test riuscito della migrazione API.

Quale GraphQL API è adatta al client?

Il rilascio del 18 settembre 2026 comprendeva cinque API GraphQL con compiti diversi:

• Detections v2: cercare e modificare Detections provenienti da endpoint, sensori di rete e altre fonti.
• Cases v2: gestire Cases, Evidence, commenti, file e link.
• Threat Timeline v2: cercare le relazioni tra processi per un massimo di 100 processi in una chiamata.
• Events v1: recuperare i dettagli degli eventi a partire da Event ID noti.
• Live Endpoint Search v1 (LES): eseguire query di tipo osquery sugli endpoint connessi e recuperare risultati e Telemetry.

Live Discover REST non rientra nella deprecazione delle Classic Cases/Detections APIs. Le integrazioni Live Discover REST esistenti possono continuare a funzionare; il passaggio a LES è opzionale. Il percorso live e la XDR Query API per i dati storici svolgono compiti diversi. La distinzione tra le API di Live Discover spiega anche la selezione delle destinazioni LES basata su sessione. Analogamente, l’Endpoint API sotto /endpoint/v1 e la relativa Device Migration non vengono migrate a GraphQL a causa di questa deprecazione XDR.

Dal 12 ottobre 2026 è pubblicata anche la Search GraphQL API v1 per ricerche QL storiche. Offre createSearch, getOrCreateSearch, search e searchResults; Interrogare il Data Lake Sophos Fusion con la Search GraphQL API descrive contratto di richiesta, stato di esecuzione, pagine dei risultati e verifica della migrazione SQL. Data Lake Search rimane il percorso interattivo; XDR Query API resta disponibile. La nuova API non impone un passaggio immediato e non è un flusso LES per endpoint live. Per Assets ed Entity Graph restano aperte le verifiche separate di riferimenti e tenant: la menzione nella guida Cases non autorizza un’implementazione completa.

Verificare il contratto specifico di migrazione

Il passaggio non consiste nel sostituire l’URL lasciando invariato il client. Per Cases, Detections e, opzionalmente, LES si confronta ogni workflow specifico, senza applicare una ricetta REST-GraphQL comune:

• GraphQL restituisce soltanto i campi selezionati. Il client verifica sia lo stato HTTP sia l’array errors e i campi di stato specifici dell’operazione; HTTP 200 può contenere un errore della query. I campi annidati necessari e le informazioni temporali con seconds/nanos vengono selezionati ed elaborati consapevolmente.
• Per Detections, detectionSearch sostituisce la procedura REST composta da avvio della query, interrogazione dello stato e recupero dei risultati. Per insiemi di ricerca piccoli si utilizzano offset/limit, per quelli grandi il valore restituito in search_id con detectionPoll. Confrontare tutte le parti e il conteggio totale. I filtri vengono verificati singolarmente come predicati QL; una ricerca host richiede un ID, non semplicemente il nome del dispositivo. Per un type REST o una reputazione Intelix non è garantito un sostituto identico.
• La Detection Severity di REST e GraphQL valuta dataset distinti secondo modelli distinti. REST utilizza una scala di numeri interi fino a 10, mentre metadata.severity di GraphQL utilizza una scala da 0 a 1. Non convertire mediante divisione. Rivalutare le soglie dal punto di vista operativo sulla base dei rispettivi dati. Case.severity, con 2/4/6/8/10, costituisce un’ulteriore scala diversa.
• Per Cases, il client API utilizza l’UUID id, non il valore leggibile shortId nel formato CSE#####. I vecchi ID dei case REST non vengono tradotti e i vecchi case non diventano disponibili tramite la nuova API. Le evidenze necessarie dei casi precedenti vengono salvate prima del passaggio utilizzando il percorso di recupero precedente confermato; ciò non implica né un pulsante di esportazione universale né il trasferimento della cronologia.
• Tipi di case, stati e Verdicts vengono risolti come dati di riferimento dinamici del tenant, dipendenti dalla licenza, e aggiornati regolarmente. assigneeId richiede una Subject ID o una @mention supportata, non un indirizzo e-mail. Un assigneeSubject non risolvibile può essere null; la visualizzazione richiede quindi un’alternativa scelta esplicitamente.
• caseEvidence restituisce ID di collegamento, non payload Evidence completi. Le Detections vengono recuperate successivamente tramite detectionRetrieveById con l’argomento scritto esattamente come iDs, gli Events tramite i loro Resource Names invariati. Le dipendenze da Asset ed Entity Graph restano aperte fino alla verifica del riferimento appropriato e del tenant. Gli ID di Detection, Event, Asset ed Entity Graph non sono intercambiabili; un punto di accesso a Entity Graph per un case utilizza il suo UUID come INVESTIGATION, non la shortId.
• La paginazione dei case utilizza offset o cursor, non entrambi nella stessa richiesta. Per un elenco che cambia, preferire il cursor e restituirlo senza modifiche. keyFindings è un documento tipizzato e viene fornito nel recupero del singolo case, non nell’elenco dei case. I filtri precedenti overviewContains ed escalated non hanno un sostituto diretto; decidere esplicitamente le funzioni necessarie prima del passaggio.
• Non esiste un deleteCase che sostituisca il DELETE REST. La chiusura, eventualmente con il Verdict richiesto dal tipo di case, e la successiva archiviazione opzionale sono passaggi separati. Nei case MDR gestiti dal provider, i campi effettivamente scrivibili sono più limitati e devono essere verificati in anticipo.

Un progetto pilota deve rispondere alla stessa domanda operativa nel tenant corretto, con ID tracciabili, paginazione completa ed errori valutati. Le funzioni GraphQL aggiuntive, come commenti, file, link, regole, template e Split/Merge, sono estensioni separate, non prerequisiti per ogni passaggio. La mancanza di corrispondenze tra campi o una cronologia non chiarita restano decisioni aperte per il client; non vengono ignorate presumendo un’equivalenza.

Ambito: XDR, MDR e licenze

Un’integrazione non sostituisce una licenza XDR o MDR. XDR mette a disposizione funzioni di analisi con cui il proprio team di sicurezza esamina i dati nel Threat Analysis Center e nel Data Lake. MDR aggiunge il servizio gestito Sophos. Le integrazioni selezionabili nel tenant dipendono dal contratto Sophos, dal prodotto, dal tipo d’integrazione ed eventualmente dalla licenza del prodotto di terze parti.

Per una conservazione più lunga o fonti di dati proprie, Sophos Next-Gen SIEM spiega come verificare il componente aggiuntivo opzionale e creare un inventario della conservazione per ogni fonte.

L’affermazione secondo cui alcune integrazioni sono gratuite non significa che lo sia l’intero Marketplace. Per MSP Flex esistono Integration License Pack separati per categorie come Endpoint, Network, Email e Firewall. La precedente regola MSP Flex indicava che, con una licenza XDR, Sophos NDR, Sophos Cloud Optix, Microsoft Graph Security e Microsoft 365 audit appliance non richiedevano un pack aggiuntivo. Questa regola vale espressamente solo per i clienti MSP Flex. Cloud Optix è ormai solo una voce storica: il suo End of Life del 30 settembre 2026 non permette di pianificare nuovi impieghi in produzione del servizio. Verificare quindi le abilitazioni del proprio tenant e il contratto anziché presupporre una gratuità generale.

Anche il sistema collegato può richiedere licenze. Per Microsoft 365, le pagine Sophos si contraddicono: la pagina di panoramica indica che i log di audit di Management Activity sono disponibili per tutti i clienti Microsoft 365, mentre la pagina di configurazione specifica richiede Purview Audit (Standard o Premium), una delle licenze utente elencate e l’auditing attivo. Per la configurazione valgono questi requisiti specifici. Le detection fornite da Graph Security V2 dipendono inoltre dalle licenze Microsoft e dalle funzioni Defender XDR disponibili. Per Microsoft 365 Response Actions nel percorso Classic/TAC, Sophos non indica requisiti di licenza Microsoft; sono però necessari un amministratore Microsoft 365 e le autorizzazioni Graph indicate più avanti espressamente come Classic. Per le Actions della soluzione avanzata valgono invece i prerequisiti descritti sopra e i diritti effettivamente richiesti dall’autorizzazione in due fasi; l’elenco Classic non definisce il nuovo consenso.

Cloud Optix dopo l’End of Life: distinguere telemetria e CSPM

Sophos Cloud Optix ha raggiunto l’End of Life il 30 settembre 2026. Da quel momento il servizio non raccoglie nuovi dati, non genera riscontri e non inoltra più telemetria a MDR o XDR. All'11 ottobre 2026, la precedente raccomandazione di esportare prima dell’EOL e trasferire in parallelo non è più un passaggio futuro eseguibile.

Verificare ora quali ambienti AWS, Azure, GCP o OCI erano collegati esclusivamente tramite Cloud Optix e quali dispongono già di una connessione diretta alla soluzione XDR/MDR avanzata. Queste integrazioni cloud dirette devono essere configurate per ciascuna piattaforma; l’upgrade del prodotto non lo fa automaticamente. Senza una nuova connessione verificata, non si può affermare una copertura della telemetria senza lacune per il periodo successivo al 30 settembre. Per un tenant non ancora aggiornato o una scheda prodotto mancante, chiarire lo stato con il team account o partner Sophos.

Un’integrazione API cloud diretta non equivale a un Syslog Data Collector in esecuzione in AWS, Azure o GCP. Scegliere nel Marketplace l’integrazione per il flusso cloud richiesto, verificare le autorizzazioni concrete della sorgente e dimostrare poi la presenza dei dati e delle detection attese. L’evidenza deve identificare account cloud, sorgente dati e intervallo temporale; una connessione verde da sola non basta.

Cloud Security Posture Management (CSPM) non viene trasferito: valutazione dello stato delle configurazioni cloud, rapporti di benchmark di compliance e riscontri di configuration drift non sono prestazioni promesse dalle nuove integrazioni di telemetria. Documentare separatamente questa esigenza e chiarire con il team account il sostituto e i diritti contrattuali residui. Anche rapporti Cloud Optix, cronologia dei riscontri, evidenze di compliance e dati di inventario non vengono migrati nel nuovo sistema. Conservare le esportazioni già disponibili e verificarne la completezza; qui non è confermata la possibilità di esportazione successiva o di recupero.

Tipi di integrazione e credenziali necessarie

REST API

Un’integrazione API recupera dati dal servizio cloud del produttore oppure vi invia una Response Action. A seconda del prodotto, la procedura guidata richiede, ad esempio, tenant ID o organization ID, API URL, client ID, client secret, token o certificato. Le integrazioni API non richiedono una Sophos appliance.

Alcune integrazioni acquisiscono le credenziali direttamente nella procedura guidata. Altre richiedono una Integration Credential riutilizzabile. La possibilità di selezionare una credenziale esistente o crearne una nella procedura indica se il connettore supporta la funzione. L’Integration Credential Manager è disponibile solo per un numero limitato di integrazioni API; non tutti i secret possono quindi essere riutilizzati centralmente.

Log Collector

La descrizione dell’appliance seguente vale per il percorso Classic SVA. Nella soluzione XDR avanzata, gli XDR Data Collectors raccolgono dati Syslog e hanno requisiti di risorse e rete propri. Non applicare i vecchi valori minimi SVA alla nuova VM. La migrazione predispone le configurazioni, ma non avvia un sostituto operativo. Passaggio Syslog dalla SVA e gestione di XDR Data Collector spiega varianti di indirizzamento, impostazioni escluse e passaggio sicuro. NDR non viene migrato automaticamente in questo processo.

In un’integrazione Log Collector, il sistema sorgente esporta gli eventi tramite Syslog verso una Sophos appliance. Il Log Collector elabora i dati e li carica nel Sophos Data Lake. L’appliance funziona su ESXi, Hyper-V, AWS o Nutanix, oppure su hardware Dell, NUC o OnLogic idoneo. Per ESXi o Hyper-V assegnare almeno 4 CPU, 16 GB di RAM e 160 GB di spazio; sono supportati ESXi 6.7 Update 3 con hardware VM versione 11 o successiva e Hyper-V su Windows Server 2016 o successivo. Sophos gestisce gli aggiornamenti del sistema operativo e di sicurezza; non installare un altro agente Sophos o antimalware. Aumentare le risorse per volumi elevati o più integrazioni e convalidare DNS, proxy ed esclusioni di porte e domini prima dell’approvazione. Configurare il prodotto di terze parti per inviare a questa appliance, non a un server Syslog qualsiasi.

Più integrazioni possono utilizzare la stessa appliance. Per ogni prodotto occorre tuttavia configurare protocollo, porta, formato e sorgente secondo le relative istruzioni d’integrazione. Il solo stato verde dell’appliance non dimostra che stia arrivando il tipo di evento corretto.

Prodotti Sophos

Prodotti come Sophos Firewall o Sophos NDR prevedono procedure specifiche. Sophos NDR e le integrazioni Log Collector richiedono una Integration Appliance, ma non necessariamente una VM classica. Un’integrazione esclusivamente REST API non richiede appliance. Usare il Marketplace del tenant interessato per verificare la disponibilità: ogni riquadro mostra i metodi offerti e apre la procedura appropriata.

Delimitare in sicurezza il carico di lavoro NDR su un’appliance condivisa

La topologia con appliance condivisa seguente vale per Classic SVA/TAC, non per il nuovo XDR Data Collector. Quest’ultimo sostituisce la parte Syslog; NDR rimane un carico di lavoro appliance gestito separatamente e non viene trasferito al nuovo collector.

Per ogni appliance è consentita una sola integrazione Sophos NDR. La stessa appliance può inoltre ospitare più integrazioni di terze parti basate su appliance come Log Collector. Prima di ogni modifica, espandi quindi la voce dell’appliance in Configured > Integration Appliances e verifica tutte le integrazioni assegnate. Né il valore Integrations né uno stato verde dell’appliance sostituiscono questa verifica.

Un riavvio mirato di NDR interrompe il sensore NDR, mentre i Log Collector continuano a funzionare. Restart o Shutdown dell’intera VM interrompe invece NDR e tutti i Log Collector dell’appliance. Pianifica queste azioni in una finestra di manutenzione, documenta prima lo stato di tutti i carichi di lavoro e verificali singolarmente al termine. La procedura è descritta in Gestire in sicurezza l’appliance e il sensore Sophos NDR.

Delete nel menu dell’appliance non rimuove soltanto una singola integrazione. Non eliminare l’appliance finché le è assegnato NDR o un Log Collector. La voce di menu non indica inoltre né che la VM distribuita verrà rimossa, né che i dati già acquisiti nel Data Lake verranno eliminati. Prima della dismissione, chiarisci le assegnazioni, la conservazione dei dati, la rimozione delle risorse della piattaforma, il percorso di ripristino e il controllo finale. Fino a quel momento, l’appliance deve restare disponibile.

Prima della configurazione

1. Accedere a Sophos Fusion come Admin o Super Admin. Sophos indica questi ruoli come prerequisito per la configurazione generale.
2. Verificare nel prodotto di terze parti la licenza, il ruolo amministrativo, la funzione API o l’output Syslog richiesti.
3. Decidere se servono Data Ingest, Response Action o entrambi. Un’integrazione Response non fornisce automaticamente la telemetria su cui si basa un’indagine.
4. Se possibile, creare per l’accesso API un’app o un account di servizio dedicato. Assegnare solo i diritti richiesti dalle istruzioni del prodotto e documentare proprietario, data di scadenza e procedura di rotazione del secret.
5. Se il prodotto di terze parti richiede una allowlist degli IP sorgente per le chiamate API amministrative, identificare prima la regione Central in My Environment > Installers: passare sul link di download in Endpoint Protection o Server Protection e leggere la regione nell’URL visualizzato, ad esempio eu-central-1. Autorizzare quindi solo gli indirizzi di tale regione nella tabella seguente. Sono sorgenti delle chiamate API Sophos, non destinazioni in uscita dell’Integration Appliance.
6. Per un’integration appliance, verificarne il percorso di rete in uscita, il DNS ed eventualmente il proxy secondo i requisiti dell’appliance.
7. Pianificare un evento di test riproducibile e innocuo. Un accesso o un evento di audit è preferibile a un vero tentativo di infezione malware.

Indirizzi IP sorgente per l’allowlist API

Questa tabella mostra il set di IP Classic verificato il 14 settembre 2026. Va distinto dall’allowlist XDR attuale riportata sopra e non costituisce da solo un’evidenza sufficiente per modificare un’allowlist di produzione.

Prima di un change, confrontare la generazione dell’integrazione, la regione del tenant e il set completo di IP necessari con le informazioni Sophos attuali. In caso di differenze, non usare valori obsoleti né combinare regioni. Far verificare l’associazione della regione e la modifica secondo il proprio processo di approvazione, consentire solo l’ambito necessario e poi convalidare l’integrazione interessata con una sincronizzazione API o un evento di test innocui. Documentare nel change lo stato iniziale, l’approvazione, i risultati e il percorso di ripristino.

Sophos etichetta attualmente sia la riga São Paulo sia la riga Dubai come sa-east-1. Distinguerle in base alla posizione del tenant e al set di IP; non unire mai le regioni. Registrare la lista approvata nella modifica.

Aggiungere un’integrazione dal Marketplace

1. Aprire Threat Analysis Center > Integrations > Marketplace.
2. Cercare il produttore o il prodotto. Se vi sono voci simili, aprire la pagina del prodotto e controllare categoria, nome del prodotto, tipo di integrazione e finalità. Cisco Meraki e Fortinet FortiAnalyzer, ad esempio, sono disponibili sia come variante API sia come Log Collector.
3. Aprire l’integrazione desiderata.
4. Selezionare il tipo necessario, ad esempio Data Ingest, e fare clic su Add Configuration.
5. Seguire i passaggi di Integration setup. Per le integrazioni API, inserire i dati del sistema sorgente oppure concedere il consenso OAuth. Per le integrazioni Log Collector, creare o selezionare un’appliance e configurare quindi il sistema sorgente affinché esporti i dati Syslog verso tale appliance.
6. Se, alla prima integrazione, Sophos richiede domini interni e intervalli IP, inserire esclusivamente quelli interni alla propria organizzazione. Questi dati identificano gli indirizzi propri, raggruppano gli alert correlati ed evitano ricerche presso terze parti; non vanno confusi con la allowlist degli indirizzi sorgente Sophos.
7. Salvare la configurazione e completare interamente l’eventuale finestra esterna di consenso. Annotare nome dell’integrazione, tenant sorgente, responsabile e data della prossima rotazione delle credenziali.
8. Aprire Threat Analysis Center > Integrations > Configured. La nuova configurazione deve comparire nell’elenco. Da qui può essere monitorata o modificata; Connection Method indica inoltre se, per il troubleshooting, occorre seguire il percorso API o Log Collector.

FortiAnalyzer: gli alert API non comprendono tutti gli eventi Syslog ricevuti

Per Fortinet FortiAnalyzer, il connettore API supporta Appliance e VM Subscription, non FortiAnalyzer Cloud. Legge esclusivamente gli alert generati da FortiAnalyzer da /eventmgmt/adom/<ADOM>/alerts; <ADOM> identifica il dominio amministrativo appropriato del sistema sorgente. Un evento Syslog semplicemente ricevuto da FortiAnalyzer non diventa automaticamente un alert di questo tipo. Se occorre acquisire eventi Syslog, si valuta invece l’integrazione FortiAnalyzer Log Collector o l’integrazione Fortinet Fortigate per la sorgente specifica. La decisione va presa prima di configurare il connettore, non soltanto quando si riscontra una presunta lacuna nei dati.

Il connettore API rimuove i dati non conformi al formato e scarta poi determinati tipi di alert: messaggi sui tunnel VPN (vpntunnel), richieste web bloccate verso destinazioni non valutate, messaggi di scansione IP/porte, connessioni escluse dall’ispezione SSL in base all’allowlist o all’indirizzo, messaggi Link Monitor sulle interfacce disattivate o attivate, avvisi di Memory Log pieno, alert e avvisi sulla quota disco e connessioni SSL non sicure bloccate. L’assenza di un alert di questo tipo non indica quindi automaticamente un errore di autenticazione o di trasporto. Per assegnare il tipo, si utilizza una corrispondenza con i pattern quando message non è vuoto, altrimenti si utilizzano i campi FTNTFGTattack, ad.subtype e cat; in assenza di corrispondenze, il campo message viene ripulito. Il titolo di un alert ricevuto non costituisce automaticamente una mappatura MITRE completa.

Per l’accettazione, scegliere un evento innocuo e autorizzato che dimostri di generare un alert FortiAnalyzer, ad esempio una modifica della configurazione prevista a questo scopo nel proprio Event Handler. Documentare prima l’alert, l’ADOM e l’ora in FortiAnalyzer e assicurarsi che il formato e il tipo di alert non vengano scartati. Quindi dimostrare la presenza dello stesso alert nel tenant corretto attraverso il percorso di ricerca Sophos confermato per questo connettore. Un accesso di test qualsiasi o una riga Syslog inviata senza un alert FortiAnalyzer non costituiscono un test valido di acquisizione API. Se manca l’alert atteso, verificare prima generazione dell’alert, ADOM, formato e filtri per tipo, poi credenziali e connessione; anche in caso di acquisizione riuscita, una detection Sophos o un case non sono garantiti.

Controllare e testare il funzionamento

Il semplice salvataggio della configurazione non ne dimostra il funzionamento. Verificare nell’ordine connessione, flusso dei dati e contenuto:

1. Stato della connessione: aprire la voce in Configured oppure, per un’appliance, il relativo stato. Per i Log Collector, rosso indica che l’integrazione non funziona, giallo che funziona con errori e verde che gli eventi vengono ricevuti ed elaborati senza problemi visibili.
2. Evento di test definito: generare nel sistema sorgente un evento innocuo sicuramente acquisito dalla relativa categoria API o Syslog, ad esempio una modifica amministrativa o un accesso di test. Annotare ora, utente e sorgente.
3. Verifica nel Data Lake: trascorso il ritardo specifico del prodotto, cercare in Threat Analysis Center > Live Discover. Usare la categoria o la query Live Discover documentata nella guida specifica del prodotto; se Sophos non ne documenta una per il connettore, questo processo generale non deve promettere una verifica universale tramite query. Il runbook di Live Discover spiega query, limiti del Data Lake e verifica dei risultati. Controllare timestamp, tenant, utente e tipo di evento. Un singolo record dimostra il collegamento; più record recenti nell’arco di un periodo adeguato dimostrano la continuità del flusso.
4. Limite delle detection: non tutti gli eventi acquisiti generano una detection o un case. Data Ingest rende i dati analizzabili; una detection nasce solo quando interviene una logica di rilevamento appropriata. Testare quindi prima l’acquisizione nel Data Lake e non attendersi necessariamente un alert.
5. Response Action: usare un account di prova autorizzato e documentarne lo stato iniziale. Per Microsoft 365, Block user sign-in, seguito da Allow user sign-in, è un test reversibile; Revoke all current sessions non lo è. Tenere inoltre presente che Entra Connect Sync può riattivare in seguito un account ibrido bloccato, che l’impostazione MDR Response limita le azioni degli analisti Sophos e che i nomi delle singole Inbox Rules nelle Response Actions distinguono tra maiuscole e minuscole.

Gli Health Alert non sono un test immediato. Il periodo di 24 ore inizia con il primo errore e genera un alert di severity media solo se il problema persiste ininterrottamente. Il ritorno allo stato verde o la conferma dell’alert azzera il conteggio. Se il problema continua, l’alert ricompare poi una volta ogni 30 giorni.

Microsoft 365: tre integrazioni distinte

«Collegare Microsoft 365» non corrisponde a un’unica opzione. La tabella seguente descrive le attività distinte nel Marketplace Classic/TAC, compreso il limite delle Response Actions di quel percorso. Per la soluzione avanzata vale invece la procedura Microsoft Graph API Actions descritta sopra, con connessioni proprie e nuovo consenso; il limite Classic a un solo ambiente non si applica alla nuova procedura.

Per le Response Actions nel percorso Classic/TAC, Sophos indica le autorizzazioni Microsoft Graph User.ManageIdentities.All, User.EnableDisableAccount.All, User.RevokeSessions.All, MailboxSettings.Readwrite e User.Read. Con MDR, l’opzione di risposta MDR selezionata continua a stabilire se gli analisti possano intervenire senza approvazione. In un ambiente Entra ID ibrido, Microsoft Entra Connect Sync può riattivare in seguito un accesso bloccato da Central.

Esempio: collegare in sicurezza Management Activity

1. Accertarsi che l’auditing sia attivo in Microsoft 365. Il collegamento deve essere autorizzato da un amministratore Microsoft 365.
2. Aprire Threat Analysis Center > Integrations > Marketplace e selezionare Microsoft - Office 365 Management Activity API.
3. In Data Ingest (Security Alerts), fare clic su Add Configuration.
4. Controllare l’avviso relativo all’auditing, fare clic su Save and continue, quindi su Proceed in Connect to Microsoft 365.
5. Accedere con l’account amministratore Microsoft previsto, controllare le autorizzazioni richieste e confermare con Accept. Chiudere la conferma con Close.
6. Controllare la voce in Sophos Fusion. In Live Discover > Query deve comparire la categoria Microsoft 365 audit data. Generare quindi un evento di audit riconoscibile e cercarlo tramite una query fornita.

Microsoft non garantisce un intervallo fisso entro cui i singoli eventi compaiono nel log di audit. Una riga in ritardo non indica quindi automaticamente un errore dell’integrazione. Dopo la prima attivazione dell’auditing, possono trascorrere fino a 12 ore prima che i dati diventino visibili.

Per Graph Security V2, la prima sincronizzazione avviene circa cinque minuti dopo la disponibilità dei dati nel Microsoft Defender Security Center. Se è prima necessario effettuare il provisioning del servizio Alerts and Incidents, questo solo passaggio Microsoft può richiedere circa un’ora.

Disattivare o rimuovere un’integrazione

Non esiste un unico interruttore Disable per tutti i tipi d’integrazione. Le azioni disponibili variano in base al prodotto e alla Connection Method. Non affidarsi quindi all’esistenza di un comando universale:

1. Aprire Threat Analysis Center > Integrations > Configured, selezionare la configurazione e documentarne stato, nome, tenant sorgente, appliance e credenziale.
2. Per un’integrazione API, interrompere prima in modo controllato l’acquisizione dei dati oppure usare l’azione Disable o Delete, se disponibile nella pagina del prodotto specifico. Revocare quindi il consenso OAuth nel sistema sorgente oppure disabilitare l’app o il token dedicato. Per le Response Actions, questo passaggio impedisce ulteriori azioni da Central.
3. Per un’integrazione Log Collector, rimuovere la destinazione Syslog dal sistema sorgente. Non eliminare una Sophos appliance condivisa finché è utilizzata da altre integrazioni.
4. Rimuovere la configurazione da Central solo dopo aver soddisfatto i requisiti di conservazione, audit e change management. La rimozione di una configurazione non garantisce l’eliminazione dei dati già acquisiti nel Data Lake; chiarire quindi in anticipo conservazione ed eliminazione in base ai requisiti del Data Lake e di compliance applicabili al tenant.
5. Verificare che non arrivino nuovi eventi e che non sia più possibile eseguire Response Actions impreviste. Rimuovere quindi secret, certificati, account di servizio e voci allowlist non più necessari.

Per una breve interruzione di manutenzione di un’integrazione Log Collector, fermare l’esportazione Syslog senza eliminare un’appliance condivisa. Per le integrazioni API e Response è possibile bloccare una credenziale come pausa di manutenzione solo se la riattivazione della medesima configurazione è stata verificata in precedenza; in caso contrario, usare esclusivamente la procedura Disable, Delete o Reconnect disponibile per il connettore. Una credenziale bloccata o scaduta non è un rollback universale e genera errori di sincronizzazione.

Individuare sistematicamente gli errori più comuni

L’integrazione API non si sincronizza

Aprire Configured, verificare Connection Method e leggere l’errore specifico. Correggere prima nel prodotto di terze parti Invalid credentials, insufficient permission ed expired credentials, controllando ID, secret, durata dei token, certificati e autorizzazioni API. Network not reachable e invalid domain richiedono anche controlli di DNS, proxy, firewall e stato del servizio. Con request throttling il provider limita l’API; salvataggi immediati ripetuti possono peggiorare il problema. Per Microsoft, HTTP 401 indica autenticazione non valida; 429 e 509 indicano limitazione.

Log Collector rimane rosso o giallo

Rosso significa non operativo, giallo operativo con errori. Controllare risorse della VM, rete e DNS, raggiungibilità in uscita e percorso Syslog dal sistema sorgente all’appliance. Il messaggio no events received since last container restart segnala che non sono arrivati eventi Syslog dal riavvio del container; no received events in last 10 mins può indicare un’esportazione interrotta oppure una sorgente che invia eventi di rado. In caso di errori di caricamento, l’appliance memorizza temporaneamente i dati su disco. Se il caricamento resta bloccato e lo spazio si esaurisce, i dati più vecchi possono essere eliminati.

Microsoft 365 non fornisce dati

Per Management Activity devono essere attivi l’auditing di Microsoft 365 e la proprietà Enabled for users to sign-in? = Yes in Office 365 Management APIs. Considerare il tempo di avvio, fino a 12 ore dopo l’attivazione dell’auditing. Per Graph Security V2, controllare accesso a Defender XDR, consenso, provisioning del servizio Alerts e licenze Microsoft disponibili. La precedente Graph Security API non è più un’opzione di ripiego.

Nessun Health Alert nonostante l’interruzione

Verificare innanzitutto che sia un’integrazione Data Ingest e che siano trascorse 24 ore ininterrotte dal primo errore. Un temporaneo stato verde o la conferma dell’alert azzera il conteggio. Per impostazione predefinita, tutti gli amministratori Central ricevono l’e-mail; regole di notifica personalizzate possono modificare questa distribuzione.

Regole di sicurezza e operative

• Usare app e secret dedicati invece di account amministratore personali.
• Concedere solo le autorizzazioni API richieste dall’integrazione specifica. Le integrazioni Response necessitano per loro natura di diritti di scrittura e richiedono un’approvazione più rigorosa rispetto alla sola acquisizione dei dati.
• Non salvare i secret in ticket, screenshot o articoli della Knowledge Base. Registrare proprietario e scadenza nel sistema di gestione delle password o dei secret.
• Pianificare la rotazione delle credenziali prima della scadenza. Sophos segnala le credenziali scadute come errori di sincronizzazione.
• Autorizzare gli indirizzi IP Sophos solo quando il provider richiede una allowlist delle sorgenti e usare l’elenco della propria regione Central.
• Attivare le notifiche di integrità per il team responsabile. Quando si crea una Custom Notification Rule, tenere presente che la distribuzione predefinita di tutti gli alert via e-mail a tutti gli amministratori viene disabilitata e le regole necessarie devono essere ricreate separatamente.
• Documentare per ogni integrazione origine dati, scopo, classificazione dei dati, conservazione, autorizzazioni, test, owner e procedura di rimozione.

Criteri di accettazione

L’integrazione è completata solo quando compare in Configured con il metodo previsto, un evento di test definito è dimostrabile nella destinazione prevista, timestamp e tenant sorgente sono corretti e un owner è responsabile della rotazione delle credenziali e degli Health Alert. Per le Response Actions è inoltre necessario un test autorizzato e documentato; si ripristina lo stato iniziale soltanto per le azioni reversibili, mentre le azioni irreversibili, come la revoca delle sessioni, non devono essere usate come test di rollback. Documentare nel registro operativo i ritardi inevitabili, ad esempio quelli dell’auditing di Microsoft 365.

Domande frequenti

Ogni integrazione invia dati al Sophos Data Lake?

No. Data Ingest invia dati al Data Lake. Response Action permette di eseguire un’azione nel prodotto di terze parti. Alcuni prodotti offrono un solo tipo, altri configurazioni distinte per entrambe le direzioni.

Le integrazioni di terze parti sono gratuite con XDR?

Non in generale. Per MSP Flex, Sophos indica alcune integrazioni della categoria Sophos XDR utilizzabili con XDR senza un Integration License Pack aggiuntivo. Altre categorie richiedono i pack Flex appropriati. Possono inoltre essere necessarie licenze del provider di terze parti.

Perché vedo dati ma nessuna detection?

Acquisizione e rilevamento sono fasi distinte. Un connettore Data Ingest può scrivere correttamente eventi nel Data Lake senza che ogni evento generi una Sophos detection o un case. Verificare prima il flusso dei dati grezzi con la query Live Discover prevista.

Posso usare la stessa appliance per più integrazioni Syslog?

Sì, nel percorso Classic SVA, Sophos consente più integrazioni di terze parti e una integrazione Sophos NDR sulla stessa appliance. Ogni sorgente deve comunque essere configurata con i dati corretti di collegamento e formato. Il nuovo XDR Data Collector è invece il sostituto Syslog e non trasferisce né ospita questo carico NDR. Per il passaggio vale la procedura di migrazione del collector collegata sopra; NDR viene gestito separatamente secondo il runbook operativo NDR.

Perché l’integrazione Response di Microsoft 365 non è sufficiente?

Mette a disposizione azioni, ma non acquisisce automaticamente gli audit o gli alert di Defender. Aggiungere Microsoft 365 Management Activity e Microsoft Graph Security API V2, affinché siano disponibili detection e contesto per le indagini.

La rimozione di un’integrazione elimina i dati storici dal Data Lake?

La rimozione non garantisce l’eliminazione immediata dei dati già acquisiti. Considerare quindi la rimozione come un arresto del flusso futuro e chiarire separatamente i requisiti di conservazione o eliminazione prima di indicare una scadenza vincolante.