Comprendere Sophos Next-Gen SIEM e pianificare la conservazione

Sophos Next-Gen SIEM è un componente aggiuntivo opzionale per Sophos XDR Powered by Secureworks e Sophos MDR. Prima dell’utilizzo, l’account deve essere stato aggiornato a Sophos Fusion. La guida tecnica per amministratori descrive 13 mesi di conservazione dei dati come standard e la possibilità di estenderla fino a 10 anni. Si aggiungono telemetria delle minacce e della conformità e integrazioni personalizzate, oltre alle integrazioni XDR/MDR preconfigurate. Questa valutazione è stata verificata al 28 ottobre 2026; l’indicazione diversa di un anno nella pagina del prodotto viene contestualizzata sotto ai fini dell’acquisto.

Per decidere, occorre prima censire le fonti di dati e i periodi di conservazione necessari. Si fa poi confermare l’ambito preciso del componente aggiuntivo per il proprio tenant e, con una piccola fonte pilota, si verifica che gli eventi previsti vengano effettivamente acquisiti e siano reperibili. Una licenza XDR o MDR esistente, da sola, non dimostra che il componente aggiuntivo opzionale sia abilitato.

Quando Next-Gen SIEM è adatto all’esigenza

SIEM significa Security Information and Event Management: i dati degli eventi vengono raccolti centralmente e resi disponibili per l’analisi. Next-Gen SIEM amplia l’architettura dati condivisa di XDR/MDR per una conservazione più lunga e per le analisi di conformità. È particolarmente utile valutarlo quando servono eventi storici relativi a periodi prolungati o si vuole acquisire una fonte tramite un’integrazione propria.

Se l’esigenza iniziale è configurare un’integrazione di prodotto esistente, si parte dalle integrazioni MDR e XDR in Sophos Fusion. L’articolo ne spiega il flusso di dati e le verifiche operative. Il collegamento syslog di Sophos Firewall riguarda il trasporto dei log del firewall a un destinatario. Non chiarisce quale ambito di Next-Gen SIEM sia stato acquistato o attivato per una fonte.

Sophos XDR rimane la piattaforma principale per rilevamento, indagine, risposta e automazione. Next-Gen SIEM integra questi flussi con raccolta di dati orientata alla conformità, evidenze storiche e conservazione più lunga. Il componente aggiuntivo SIEM non è quindi un prerequisito generale per le funzioni XDR di rilevamento o risposta già coperte da licenza; viceversa, XDR da solo non abilita le funzionalità SIEM aggiuntive.

Avanet consiglia di non scegliere il componente aggiuntivo soltanto per ottenere la retention più lunga possibile. Qui retention significa conservazione dei dati. Conta capire quali eventi serviranno in seguito, per rispondere a quali domande, chi li analizzerà e per quanto tempo dovranno restare disponibili. Conservarli più a lungo serve a poco se la categoria di eventi necessaria non viene trasmessa o mancano campi importanti.

Sophos descrive anche dashboard di conformità preconfigurate. Queste analisi aiutano a raccogliere evidenze, ma non sostituiscono la verifica della copertura dei dati, una valutazione giuridica o una certificazione. Dal componente aggiuntivo non si può dedurre una conformità soddisfatta automaticamente.

Chiarire tenant e offerta prima dell’implementazione

Prima dell’acquisto si documentano il tenant corretto, il prodotto XDR/MDR utilizzato e lo stato effettivo dell’aggiornamento a Fusion. Un annuncio o una data di aggiornamento prevista non bastano ad autorizzare l’uso operativo. Si chiede quindi al partner Sophos di confermare se Next-Gen SIEM sia disponibile per quell’account e quali servizi di conservazione e integrazione includa l’offerta specifica.

Sophos descrive un modello di prezzo basato su utenti e server, senza costi di ingestione, ossia senza una tariffa legata al volume di dati acquisiti. Questa è una descrizione del modello di prezzo, non un preventivo né una promessa di capacità tecnica illimitata. Prima dell’ordine vanno chiariti il metodo di conteggio, la durata del contratto, l’estensione della conservazione desiderata, l’ambito delle integrazioni e gli eventuali prerequisiti del prodotto di terze parti. In particolare, dalla descrizione non si possono dedurre licenze di terze parti gratuite né limiti garantiti di throughput o di eventi.

Per le integrazioni personalizzate è confermata la possibilità di creare proprie integrazioni di dati. Ciò non dimostra però l’esistenza di una procedura di configurazione verificata per ogni fonte. Prima del progetto pilota serve quindi una descrizione adatta alla fonte specifica di trasmissione, autenticazione, formato degli eventi, mappatura dei campi e analisi supportate. I menu o le query dei connettori esistenti non vanno applicati a un’integrazione personalizzata senza verificarli. Il punto di accesso alla dashboard è descritto di seguito; da questo non si deduce una procedura di configurazione universale per ogni fonte personalizzata.

Confermare esplicitamente il numero di licenze e il percorso del collector

Next-Gen SIEM non è acquistabile come prodotto autonomo. Il numero dei suoi abbonamenti deve corrispondere al numero totale di utenti e server con licenza XDR e MDR; i server non devono essere esclusi dal conteggio. Confrontare con il partner l’inventario effettivo e l’offerta, anziché considerare soltanto un gruppo pilota o il volume dei dati come quantità da licenziare. Oltre ai 13 mesi standard, le estensioni della conservazione a tre, cinque, sette o 10 anni sono opzioni acquistabili, non abilitazioni automatiche derivanti da una licenza XDR/MDR esistente. Non ripristinano retroattivamente lo storico scaduto e non dimostrano la conformità legale.

Le linee guida di licenza in vigore dal 16 ottobre 2026 indicano anche un limite d’uso di 1 GB di dati grezzi acquisiti al giorno, aggregati su tutte le fonti. La tabella prevede licenze per utenti e server, ma la frase sul volume non specifica se la quantità valga per subscription o per tenant. Non calcolare quindi 1 GB × utenti e server né presumere un limite fisso di 1 GB per tenant. Prima del dimensionamento o dell’ordine occorre una conferma vincolante dell’unità di riferimento, dell’aggregazione e del comportamento in caso di superamento. Un prezzo privo di costi di ingestion basati sul volume non significa uso illimitato.

Anche il numero di subscriptions Retention Add-on deve corrispondere al totale delle subscriptions NG-SIEM. Non se ne deduce una conservazione estesa per un sottoinsieme arbitrario o una singola fonte.

Per le integrazioni Syslog, i vecchi Sophos Log Collector non supportano l’intero ambito di conservazione di Next-Gen SIEM. A questo scopo Sophos consiglia il passaggio agli XDR Data Collectors; il runbook esistente per la migrazione dei collector spiega provisioning, deployment, passaggio delle fonti e accettazione. Le integrazioni API esistenti non richiedono una riconfigurazione soltanto a causa di questo cambio di collector. Su una SVA condivisa, NDR rimane un carico di lavoro separato e non deve essere disattivato involontariamente durante il passaggio Syslog. Il nuovo collector non sostituisce la verifica del diritto di utilizzo del componente aggiuntivo, del formato della fonte e della conservazione effettiva.

L’hub SIEM organizza le guide esistenti per pianificazione, acquisizione delle fonti, trasporto e verifica dei parser. L’esempio pratico HTTP/parser collega questi passaggi con una fonte di laboratorio sintetica; la sua accettazione pratica nel tenant è ancora aperta.

Dati personalizzati: distinguere trasporto, normalizzazione e rilevamento

Una Custom Integration trasporta in XDR i dati di una fonte non ottimizzata da Sophos. Questo non conferma ancora la normalizzazione, la ricerca o il rilevamento per quella fonte. I Custom Parser mappano i campi dei log agli schemi standardizzati di eventi XDR supportati. Solo dopo si può verificare se sono presenti i campi necessari per la ricerca desiderata, per un detector o per una Custom Detection Rule.

I Custom Parser richiedono un abbonamento Next-Gen SIEM. Possono gestirli i ruoli Admin e Super Admin; gli altri ruoli possono soltanto visualizzare l’elenco dei parser configurati. I messaggi che non corrispondono ad alcun parser utilizzano lo schema generic. Possono fornire contesto ai case e alle regole personalizzate, ma compaiono nei risultati soltanto con parametri di ricerca avanzati. L’assenza di risultati in una ricerca semplice non dimostra quindi che non siano stati acquisiti dati.

Anche i dati normalizzati correttamente non attivano automaticamente tutti i detector corrispondenti allo schema. Sophos indica determinati percorsi di rilevamento supportati con i campi necessari; gli altri detector non sono garantiti. Il rilevamento desiderato va quindi convalidato separatamente con eventi di prova adeguati. L’assistenza IA pubblicizzata non sostituisce questa verifica.

Un Custom Parser appena creato è disattivato per impostazione predefinita. Viene testato più volte con messaggi di esempio diversi, salvato e solo successivamente attivato separatamente. Le modifiche a un parser già attivo, invece, hanno effetto immediato al salvataggio; occorre quindi testarle attentamente prima di salvare.Confirm Strings sovrapposte possono assegnare i messaggi al parser sbagliato; occorre quindi verificare anche l’extractor path effettivamente utilizzato.

Sophos non cura la manutenzione né l’aggiornamento dei Custom Parser. Un responsabile operativo deve ricontrollare mappatura dei campi, timestamp e risultati di ricerca o rilevamento dopo modifiche al formato della fonte o al parser. Per il progetto pilota, acquisizione, normalizzazione e analisi desiderata vengono documentate come tre risultati distinti; uno stato di trasporto verde non basta.

La configurazione pratica è descritta in Custom HTTP Ingest, nelle varianti S3, in Azure Event Hubs e Storage e nel runbook Custom Parser. Per ogni variante trasporto, schema e analisi desiderata restano risultati di accettazione separati.

Aprire la dashboard NG-SIEM per verificare le evidenze

Con il componente aggiuntivo abilitato, la vista fornita può essere aggiunta all’elenco personale delle dashboard come segue:

1. Aprire Dashboards > Manage dashboards.
2. Selezionare Find dashboards e aggiungere NG-SIEM all’elenco.
3. Aprire la dashboard dall’elenco e confrontare i dati visualizzati con l’inventario delle fonti, il periodo e gli eventi attesi.

La dashboard NG-SIEM contiene widget su controllo degli accessi, sicurezza di rete ed eventi di audit. Sophos descrive inoltre un esempio di dashboard ISO 27001 che riunisce autenticazione, modifiche, eventi di rete/firewall, attività e-mail/file e flussi di rilevamento e gestione dei case. Le informazioni effettivamente disponibili per le proprie evidenze dipendono dalle fonti collegate e dalla qualità dei loro dati; la vista non costituisce una certificazione ISO né una conferma automatica della conformità.

La guida generale alle dashboard spiega elenchi personali, viste disponibili ed esportazione PDF. Se manca NG-SIEM, si verificano prima tenant, componente aggiuntivo e autorizzazioni; una vista vuota viene analizzata in relazione all’origine dei dati e al periodo. Né i widget mancanti né quelli verdi sostituiscono la verifica degli eventi sottostanti.

L’attuale guida NG-SIEM specifica del prodotto del 1° ottobre 2026 descrive questo accesso. La precedente guida comune ai dashboard del 17 settembre menziona ancora solo il dashboard TAC. La disponibilità della vista dipende dall’offerta e dal provisioning del tenant. Se la voce manca nonostante un’offerta corrispondente, chiarire il provisioning effettivo; non creare una seconda integrazione per tentativi.

Distinguere conservazione, finestre di ricerca e dati grezzi

13 mesi nella guida per amministratori, un anno nella pagina del prodotto

La panoramica tecnica del 1° ottobre 2026 indica 13 mesi di conservazione standard. La pagina pubblica del prodotto, verificata al 28 ottobre, indica invece un anno. Entrambe citano estensioni a tre, cinque, sette o dieci anni. La differenza non viene interpretata come modifica confermata del prodotto o come semplice arrotondamento diverso; manca una spiegazione univoca di Sophos.

Per l’inquadramento tecnico di questo articolo, il riferimento sono i 13 mesi della guida per amministratori specifica del prodotto. Prima di un ordine o di un impegno vincolante sulla conservazione, occorre comunque ottenere conferma del periodo applicabile al tenant, ai tipi di dati e all’offerta specifici. La conferma va registrata nell’inventario delle fonti. Se, ad esempio, il funzionamento richiede più di dodici mesi di storico, non si deve presumere il periodo aggiuntivo soltanto sulla base della pubblicità generale del prodotto. L’inventario della conservazione e il collaudo descritti sotto verificano l’ambito concordato; non risolvono la contraddizione tra le fonti assumendo una durata.

Periodo di ricerca e accesso ai dati grezzi

Una lunga conservazione non consente una query arbitrariamente grande in un’unica esecuzione. La guida attuale agli schemi permette al massimo 31 giorni per query sugli Events normalizzati, con qualsiasi data iniziale entro i dati effettivamente conservati. Suddividere indagini più lunghe in finestre adeguate. La ricerca nelle detections è separata.

Per @raw e original_data, la guida SQL-QL più recente del 15 settembre 2026 indica un limite di accesso separato di 20 giorni. Una richiesta esterna a tale ambito viene rifiutata, non ridotta silenziosamente all’intervallo consentito. La precedente guida Query Language menziona anche incrementi di 20 giorni; questo non garantisce dati grezzi più vecchi. Suddividere le richieste non rende automaticamente accessibili i vecchi dati Raw. Il limite di ricerca non prova una cancellazione fisica dopo 20 giorni né una riduzione generale della conservazione normalizzata.

Data Lake Search ed esportazione spiega scelta dello schema, limiti di query, finestre storiche e prova dell’export completo. La gestione delle regole distingue una ricerca riuscita da una regola di detection o suppression valutata continuamente.

Creare un inventario della conservazione per ogni fonte

L’inventario appartiene alla documentazione operativa, non soltanto all’offerta. Per ogni fonte si registrano i dati seguenti; categorie di eventi diverse della stessa applicazione possono richiedere voci separate:

• Sistema sorgente, tenant sorgente, categorie di eventi e persona responsabile.
• Scopo dell’acquisizione e domanda concreta a cui una futura ricerca o evidenza dovrà rispondere.
• Campi necessari, ad esempio data e ora dell’evento con fuso orario, azione, risultato e un’identità adatta all’indagine.
• Classificazione dei dati, contenuti consentiti e autorizzazione per trasmissione e accesso.
• Conservazione desiderata con motivazione e ambito confermato effettivamente applicabile.
• Metodo di integrazione, autorizzazioni necessarie e responsabile delle credenziali, senza copiare segreti nell’inventario.
• Inizio dell’acquisizione, ritardo di elaborazione previsto e un evento di prova riproducibile.
• Metodo di ricerca verificato, record più vecchio trovato, ultima verifica riuscita e prossima data di revisione.
• Procedura in caso di guasto, cambio della fonte, modifica della conservazione e dismissione.

L’indicazione del prodotto 13 mesi, estendibili fino a 10 anni non va registrata automaticamente come durata effettiva per ogni record esistente. Per la propria fonte occorre chiarire ambito, inizio e accesso ai dati storici. Non si deve nemmeno dare per scontata l’importazione retroattiva dei vecchi dati o il recupero di dati già scaduti.

Esempio di una fonte pilota

L’esempio seguente è una scheda di pianificazione, non una configurazione Sophos né un connettore verificato. I valori sono requisiti scelti liberamente per un’organizzazione fittizia:

Fonte: applicazione aziendale interna, ambiente di prova
Eventi: accesso riuscito e modifica amministrativa del ruolo
Scopo: ricostruire chi ha modificato un’autorizzazione
Campi obbligatori: data e ora dell’evento con fuso orario, account di prova, azione, risultato
Conservazione desiderata: 24 mesi
Motivazione: periodo d’indagine approvato internamente
Ambito confermato: ancora da chiarire prima dell’ordine e del progetto pilota
Collegamento e metodo di ricerca: ancora da confermare per questa fonte personalizzata
Prova: modifica autorizzata del ruolo di un account dedicato alle prove
Ripristino: ripristinare il ruolo iniziale e verificare la modifica
Team responsabili: team dell’applicazione insieme al team delle operazioni di sicurezza

I 24 mesi sono qui un requisito interno, non un termine legale generale né uno standard del prodotto. Superano la conservazione standard descritta; prima dell’approvazione va quindi confermata un’estensione adeguata. Account ed eventi vanno sostituiti con i propri dati di prova autorizzati. Per questa prova non si modificano le autorizzazioni di produzione.

Accettare separatamente acquisizione e conservazione

Per il progetto pilota si registrano lo stato iniziale e l’inizio dell’acquisizione. I percorsi di raccolta dei log esistenti restano attivi finché la nuova fonte non è stata accettata. Si genera poi un evento innocuo e autorizzato appartenente alla categoria prevista. Nell’esempio si modifica il ruolo dell’account di prova e successivamente lo si riporta al valore iniziale documentato.

Trascorso il tempo di elaborazione previsto, si verifica quanto segue attraverso il metodo di ricerca o analisi confermato per quella fonte:

1. L’esatto evento di prova è presente nel tenant corretto?
2. Sistema sorgente, data e ora dell’evento, azione e risultato coincidono con l’evidenza della fonte?
3. I campi necessari sono mappati in modo comprensibile, anziché essere disponibili soltanto come testo grezzo inutilizzabile?
4. È possibile ricostruire altri eventi attesi durante il periodo pilota?

Un record appena trovato dimostra l’acquisizione per quella prova, non una conservazione pluriennale. Per accettare la retention si confronta inoltre l’ambito confermato con l’impostazione effettiva o con una conferma specifica del tenant. I dati storici già presenti si verificano in un intervallo temporale mirato, annotando il record più vecchio trovato e le lacune note. Per una nuova fonte senza storico si documenta che la conservazione a lungo termine non è ancora stata dimostrata dal tempo trascorso e si pianificano controlli successivi.

La verifica dell’acquisizione non richiede un allarme di sicurezza. Un normale evento di audit può servire come record senza generare un incidente. Data Collection e Live Discover spiega le query XDR esistenti; non ne deriva però una query universale per una nuova fonte personalizzata.

Individuare i guasti e annullare le modifiche in sicurezza

Se manca il componente aggiuntivo o una funzione, si verificano prima il tenant, lo stato effettivo dell’aggiornamento a Fusion e l’ambito confermato del componente aggiuntivo. Non si crea una seconda integrazione per tentativi e non si modifica una policy di protezione degli endpoint per risolvere una presunta carenza di licenza.

Se mancano eventi recenti, si confronta prima l’evidenza della fonte con l’inizio dell’acquisizione, la categoria di eventi, l’autenticazione, il formato e il ritardo di elaborazione concordato. Se i record sono presenti ma inutilizzabili, si verificano la mappatura dei campi e i riferimenti temporali. Se mancano soltanto eventi più vecchi, si esaminano separatamente inizio dell’acquisizione, lacune nei dati, conservazione effettiva e intervallo temporale di ricerca. Un’estensione successiva della conservazione non è un rimedio garantito per dati già mancanti.

Prima di ridurre la conservazione o dismettere l’integrazione, si chiarisce con i responsabili quali dati siano ancora necessari e come preservarli, ove supportato e richiesto. Non si deve presumere che un successivo ritorno al valore precedente ripristini lo storico perso. Analogamente, rimuovere un’integrazione non dimostra che i dati già acquisiti siano stati cancellati.

Se il progetto pilota non riesce, si annulla soltanto la modifica documentata alla fonte pilota tramite la procedura di ripristino confermata per essa. Credenziali condivise, collector e altre fonti restano intatti. Si verifica poi lo stato ripristinato della fonte e il vecchio percorso di raccolta dei log ancora necessario. Cancellazione dei dati e disdetta del componente aggiuntivo vanno chiarite separatamente con il partner o i responsabili; questo articolo non promette un comando universale per tali operazioni.

Per il passaggio alla gestione operativa devono essere disponibili inventario delle fonti, ambito confermato, evidenze del progetto pilota, lacune storiche ancora aperte, responsabilità in caso di guasto e data di revisione. Se restano da chiarire formato dei dati, metodo di ricerca o conservazione di una fonte necessaria, quella fonte non è ancora accettata. Per l’escalation bastano inizialmente l’identificazione del tenant, l’intervallo temporale, la categoria di eventi e le evidenze di errore depurate; la richiesta non deve contenere segreti né dati personali grezzi non necessari.