Attivare e verificare gli MDR Threat Feeds su Sophos Firewall

Gli MDR Threat Feeds collegano il servizio Sophos MDR a Sophos Firewall. Gli analisti MDR possono inviare al firewall, tramite Sophos Fusion (in precedenza Sophos Central), indirizzi IPv4, domini e URL correlati a un incidente attivo nel proprio ambiente. Il firewall registra o blocca quindi il traffico corrispondente senza richiedere la manutenzione manuale di un file di feed dedicato.

Per un rollout sicuro non basta attivare un interruttore in WebAdmin. La licenza MDR, la registrazione in Sophos Fusion, l’azione locale, la visibilità necessaria sul traffico, le destinazioni dei log e il percorso di contatto con il team MDR devono essere coerenti. Uno stato locale Log and drop non dimostra ancora che sia arrivato uno specifico IoC né che il flusso interessato attraversi le ispezioni necessarie.

Denominazioni nell’interfaccia: i percorsi di Sophos Fusion utilizzati qui seguono la guida di SFOS 22. La guida di SFOS 23 utilizza ancora Sophos Central per lo stesso collegamento al cloud. Se il proprio build mostra questa denominazione, aprire la pagina corrispondente di Sophos Central; il solo nome non fornisce indicazioni sulla registrazione, sull’abilitazione MDR o sulla consegna dei feed. Send reports and logs to Sophos Central rimane il nome documentato dell’opzione di logging.

MDR Threat Feeds in otto passaggi

1. Verificare che sul firewall sia presente Xstream Protection Bundle e che in Sophos Fusion sia disponibile un’abilitazione MDR attiva.
2. In System > Sophos Fusion, controllare che il firewall corretto sia registrato nell’account Sophos Fusion corretto.
3. Documentare in Sophos Fusion il Threat response mode previsto e il percorso operativo di contatto MDR.
4. In System services > Log settings, attivare almeno una destinazione di log utilizzabile per Active threat response.
5. Aprire Protect > Active threat response > MDR threat feeds e attivare la funzione.
6. Scegliere Log only per un breve progetto pilota controllato oppure Log and drop per la protezione in produzione dopo un esito positivo della verifica di accettazione, quindi fare clic su Apply.
7. Eseguire le verifiche positive e negative tramite Log Viewer, contesto endpoint e Sophos Fusion.
8. Documentare Audit ID, responsabili, processo di gestione delle eccezioni, data di revisione e rollback.

Importante: gli MDR Threat Feeds sono solo una parte delle attività operative MDR. Non sostituiscono il contratto MDR, i sensori endpoint, le comunicazioni relative agli incidenti, regole firewall restrittive o una procedura di ripristino testata. Un’eccezione ampia o una disattivazione non controllata può indebolire una risposta in corso del team MDR.

Cosa offrono gli MDR Threat Feeds

Gli analisti Sophos MDR possono inviare al firewall informazioni di intelligence relative a un incidente attivo direttamente tramite Sophos Fusion. Il feed è quindi più specifico per il cliente rispetto a una generica lista globale di reputazione. Un IoC trasmesso può essere un indirizzo IPv4, un dominio o un URL.

L’azione locale del firewall determina cosa accade in caso di corrispondenza:

• Log only registra la corrispondenza, ma consente il traffico.
• Log and drop registra e scarta il traffico corrispondente.

Sophos consiglia il blocco per gli IoC noti. Un breve progetto pilota con Log only può comunque essere utile quando occorre prima verificare visibilità, logging e possibili effetti collaterali in un ambiente esistente. Questo progetto pilota deve avere una data di fine definita. Senza una transizione pianificata, un’integrazione MDR attiva rischia altrimenti di rimanere permanentemente priva di un’azione di blocco locale.

Il Threat response mode in Sophos Fusion e l’azione locale del feed sono due livelli distinti. La modalità di Sophos Fusion definisce le autorizzazioni di risposta del team MDR. Log only o Log and drop determina invece come il firewall gestisce un IoC già trasmesso. Prima del rollout, entrambe le impostazioni devono essere verificate rispetto al contratto MDR e al processo interno di gestione degli incidenti. La documentazione Sophos attuale sul Threat response mode distingue tra Collaborate, Authorize e Notify Only.

Distinguere la telemetria del firewall dalla risposta degli analisti

I dati fluiscono anche nella direzione opposta: il firewall fornisce eventi di sicurezza per le indagini MDR. A questo scopo deve essere registrato in Sophos Central firewall management; sul firewall devono essere attivi Sophos Central services e selezionata l’opzione Send reports and logs to Sophos Central. MDR analizza continuamente i log di sicurezza di Advanced Threat Protection (ATP), Intrusion Detection and Prevention (IDP/IPS), Antivirus, Antispam, Sandstorm Sandbox, Web Protection e Application Control. Insieme ai dati di endpoint, server e altre fonti integrate, questi eventi aiutano a identificare attività dannose, IoC e tentativi di movimento laterale. La telemetria in ingresso dal firewall non è però il feed di IoC specifico del cliente che gli analisti MDR inviano al firewall nella direzione opposta.

In caso di incidente critico, il team MDR può, ad esempio, terminare le sessioni VPN degli utenti compromessi. Si tratta di una misura di risposta agli incidenti eseguita dagli analisti nell’ambito delle autorizzazioni concesse, non di una conseguenza automatica di una corrispondenza nel feed né di una procedura locale tramite clic o comandi CLI. Con Authorize, il team può rispondere alle minacce attive senza consultare prima i contatti designati; con Collaborate, la risposta viene coordinata con tali contatti. Questo non implica autorizzazioni di risposta illimitate per tutti i dispositivi o le integrazioni. Le sessioni VPN di produzione non vengono terminate come test funzionale.

Per intervenire tramite Live Response, Live Response deve essere consentito sul dispositivo interessato. Isolare Sophos Endpoint e indagare con Live Response illustra i prerequisiti e la procedura sicura. Le azioni di Microsoft 365, come bloccare o consentire gli accessi, revocare le sessioni attive e disattivare le Inbox Rules, richiedono che l’integrazione di risposta sia configurata; si applica la procedura separata descritta in Integrazioni MDR e XDR. Il logging del firewall o la ricezione di un IoC MDR non abilitano automaticamente questi interventi.

I cybora.io Threat Feeds utilizzati da Avanet per Sophos Firewall sono invece Third-Party Threat Feeds, non Sophos MDR Threat Feeds né feed MDR creati da Avanet. La loro configurazione segue la procedura per i feed di terze parti; non concede al team Sophos MDR ulteriori autorizzazioni di risposta.

Comprendere l’ordine di elaborazione e il ciclo di vita

SFOS 22 elabora Active Threat Response nell’ordine MDR, NDR Essentials, Sophos X-Ops e Third-Party Threat Feeds. Se un IoC trova corrispondenza in MDR con Log and drop, il firewall scarta il traffico, lo registra sotto MDR e non verifica più i feed successivi. Con Log only o Monitor possono essere generati eventi separati per MDR, X-Ops e Third-Party Feeds. Con Log only o azioni diverse tra i moduli, non si deve dedurre un’autorizzazione generale; occorre considerare le altre azioni configurate e verificare le evidenze del traffico e dei log.

I singoli IoC MDR non vengono creati o modificati in WebAdmin. Gli analisti MDR li aggiungono e li rimuovono tramite Sophos Fusion. Entrambe le operazioni vengono registrate con l’azione e l’identità dell’analista come audit_ID. Questi eventi amministrativi vanno cercati nella vista dettagliata Admin del Log Viewer o nella Sophos Fusion Firewall Task Queue e non devono essere confusi con le corrispondenze di traffico in Active threat response. Localmente si controlla solo se il feed MDR è attivo e se le corrispondenze vengono registrate oppure anche scartate. Le Threat Exclusions sono invece globali e si applicano a tutti i moduli Active Threat Response.

La documentazione di SFOS 22 non indica un periodo di validità degli IoC MDR configurabile dall’amministratore del firewall. Non si deve quindi dedurre una data di scadenza dall’interfaccia locale. Se una voce è dubbia o potrebbe essere obsoleta, conservare audit_ID, IoC e data e ora, quindi chiarirne lo stato con il team MDR. Questo aspetto è importante anche per il ripristino dello stato precedente: una modifica da Log and drop a Log only riguarda tutti gli IoC MDR attualmente ricevuti; una Threat Exclusion può inoltre indebolire NDR, X-Ops e Third-Party Feeds.

Verificare accuratamente i prerequisiti

Licenza e Sophos Fusion

Gli MDR Threat Feeds richiedono Xstream Protection Bundle sul firewall. La tabella delle licenze di SFOS 22 indica inoltre Sophos MDR Essentials o Sophos MDR Complete in Sophos Fusion; la documentazione attuale di Sophos Fusion denomina le varianti del servizio MDR e MDR Plus. Occorre quindi verificare l’abilitazione MDR attiva nel proprio account Sophos Fusion, anziché dedurre il diritto all’utilizzo soltanto da una vecchia denominazione del prodotto. Il solo bundle Xstream non include un servizio MDR.

Il firewall deve essere registrato nell’account Sophos Fusion corretto. In System > Sophos Fusion si verificano la registrazione e l’invio di report e log. La procedura completa di collegamento è descritta in Collegare Sophos Firewall a Sophos Fusion.

Inoltre, il servizio Sophos MDR deve essere configurato. La registrazione del firewall e la verifica della licenza, da sole, non sostituiscono questa configurazione. Prima dell’attivazione locale, confermare con il responsabile MDR che il servizio sia configurato per il cliente corretto e che il Threat response mode sia stato scelto consapevolmente. Sophos richiede almeno un contatto autorizzato prima che sia possibile configurare ulteriori impostazioni MDR o utilizzare il servizio. Per il contesto endpoint aggiuntivo tramite Synchronized Security, la tabella delle licenze di SFOS 22 indica anche una licenza Intercept X in Sophos Fusion; questo contesto non è garantito dal solo bundle Xstream.

Sophos MDR: configurare contatti e Threat Response descrive il flusso centrale completo con ruoli dei contatti, fallback Collaborate, accesso ai dispositivi e verifica sicura dei valori salvati. Non sostituisce la successiva configurazione locale del feed.

Prima dell’attivazione occorre anche chiarire le responsabilità:

• Chi può modificare il Threat response mode in Sophos Fusion?
• Chi risponde a una chiamata MDR o a una richiesta di chiarimenti fuori dall’orario di lavoro?
• Chi può approvare un’eccezione?
• Dove vengono documentati Audit ID, Incident ID ed evidenze tecniche?
• Quali sistemi possono essere isolati in caso di compromissione confermata?

Attivare le destinazioni dei log

In System services > Log settings, attivare nella riga Active threat response almeno una delle seguenti destinazioni:

• Local reporting per Log Viewer e report locali
• un Syslog server configurato per SIEM o SOC
• Central reporting per Sophos Fusion

La colonna Central reporting compare solo quando nella pagina di Sophos Fusion è attivata l’opzione Send reports and logs to Sophos Central. XGS 87/87w e 107/107w non supportano il reporting locale; su questi modelli è necessario utilizzare Central Reporting o Syslog.

Dopo aver selezionato le destinazioni dei log in System services > Log settings, fare clic su Apply. Ricaricare quindi la pagina e verificare che le destinazioni previste siano ancora selezionate nella riga Active threat response. Questo conferma il salvataggio della configurazione; il trasporto effettivo dei log e la consegna delle notifiche degli incidenti vengono verificati separatamente.

Per le notifiche, verificare anche System services > Notification list. L’attivazione di una destinazione di log definisce il percorso di trasporto, ma non dimostra né l’effettiva consegna né la corretta gestione degli allarmi.

Visibilità per IP, dominio e URL

Un IoC ha effetto solo sul traffico che il firewall può elaborare in modo appropriato. Per il traffico inoltrato verso un IP di destinazione è necessaria una regola firewall adeguata. Le corrispondenze di dominio richiedono Application Classification o una policy IPS nella regola interessata. Per un percorso URL HTTPS completo occorre un Web Proxy con decrittazione oppure DPI con una regola SSL/TLS Inspection adeguata.

Il traffico diretto al sistema verso i servizi in Administration > Device access, ad esempio WebAdmin, VPN Portal e VPN, può essere verificato in base a un indirizzo IPv4 di origine malevolo. Per il traffico in ingresso inoltrato tramite DNAT o WAF, è necessario attivare anche Remote source match (inbound traffic) in System services > Log settings > Active threat response per ottenere la visibilità prevista nei log.

Limite non chiarito per ATR/X-Ops: la descrizione ufficiale e la matrice del traffico si contraddicono sulle corrispondenze degli indirizzi di destinazione e degli indirizzi di origine locali per Sophos X-Ops. Per questi casi non è stata chiarita in modo affidabile né la presenza né l’assenza del supporto; le indicazioni su traffico e moduli nei collegamenti non costituiscono quindi una base approvata per la configurazione. Da questa incongruenza non si deduce alcuna direzione del traffico MDR e non si presume alcuna protezione per i casi X-Ops interessati. Prima di effettuare una modifica basata su tali indicazioni, è necessario ottenere un chiarimento vincolante da Sophos o eseguire un test del prodotto esplicitamente approvato; i collegamenti seguenti non risolvono questa contraddizione.

La logica generale di traffico, moduli e ispezione è descritta in Configurare e gestire in sicurezza i Threat Feeds su Sophos Firewall. La guida spiega anche perché il rilevamento di un dominio o di un URL può non avvenire senza la classificazione o la decrittazione adeguata.

Configurare gli MDR Threat Feeds

1. Accedere a WebAdmin con un account amministratore personale.
2. Aprire Protect > Active threat response > MDR threat feeds.
3. Attivare MDR threat feeds.
4. Come Action, scegliere Log only per un progetto pilota con una scadenza definita oppure Log and drop dopo un esito positivo della verifica di accettazione.
5. Salvare con Apply.
6. Ricaricare la pagina e controllare che l’interruttore e l’Action siano stati salvati.
7. Verificare nel registro di audit data e ora, amministratore e modifica.
8. Controllare in Sophos Fusion che il firewall sia online e che MDR sia associato al cliente o tenant corretto.

Non apportare contemporaneamente modifiche estese a logging, ispezione, eccezioni e Action. Un rollout graduale permette di individuare quale modifica abbia causato una corrispondenza o un effetto collaterale.

Verificare l’efficacia con evidenze affidabili

Accedere a un vero dominio malware o a un IP noto come dannoso non costituisce quindi una valida verifica di accettazione. Il controllo tecnico viene suddiviso in più livelli verificabili. Un test autonomo con un feed di terze parti dimostra soltanto il percorso di traffico e ispezione verificato per quel feed, non la consegna di un IoC MDR da parte del team di analisti.

Configurazione e trasporto

1. Verificare l’interruttore MDR e l’Action desiderata sul firewall.
2. Controllare la registrazione in Sophos Fusion e la licenza MDR.
3. Confermare il logging Active Threat Response per la destinazione prevista.
4. Verificare in Sophos Fusion che i task MDR o firewall siano stati elaborati correttamente.
5. In caso di un vero incidente MDR, verificare con il team MDR l’IoC previsto e il relativo Audit ID.

La Sophos Fusion Firewall Task Queue mostra le operazioni MDR e API. Success conferma l’elaborazione del task di Sophos Fusion, ma non ancora l’effetto su uno specifico flusso di dati. In caso di Partial Success o Failed, conservare i dati relativi al firewall interessato, Entity, Action e Credential ID e confrontarli con la configurazione locale.

Esaminare le corrispondenze nel Log Viewer

In Log viewer > Active threat response, conservare almeno le seguenti informazioni:

• Data e ora, firewall e, in caso di HA, nodo che ha elaborato il traffico
• Action e nome del feed
• IP di origine e destinazione, dominio o URL
• Porte e protocollo
• Event ID e ulteriori campi di dettaglio
• Per MDR, anche il relativo audit_ID dell’evento amministrativo o della Task Queue

L’evidenza del traffico e l’azione dell’analista sono prove distinte. L’assenza del campo audit_ID nella voce di traffico non indica, da sola, un errore di consegna. L’associazione viene effettuata in base a IoC, firewall e intervallo temporale e, in caso di dubbi, viene confermata con MDR.

Con Synchronized Security, il firewall può mostrare anche utente, host e processo per gli endpoint Windows gestiti. Nel Log Viewer sono rilevanti Process user ed Executable, oltre a host_process_user, endpoint_id ed execution_path nella vista dettagliata. Su macOS questi dettagli di processo non vengono visualizzati; l’endpoint viene identificato tramite l’IP di origine e i dati di Sophos Fusion.

Quando si verifica un rilevamento, il firewall richiede questi dettagli agli endpoint gestiti tramite Sophos Fusion. La guida descrive la visualizzazione per Windows 7 e versioni successive; questo non costituisce una raccomandazione a utilizzare Windows 7 né una garanzia del supporto endpoint attuale per ogni sistema Windows meno recente. Su macOS può invece comparire un messaggio generico come Active threat C2/Generic-C deleted. Questo messaggio non sostituisce né l’identificazione dell’host tramite l’IP di origine né la prova dell’azione applicata dal firewall al traffico.

Il riepilogo locale si trova in Reports > Network & threats > Active threat response, nell’elenco Synchronized IoC. La Panoramica dei servizi e dei file di log di Sophos Firewall fornisce inoltre informazioni su atr.log. Una singola voce di log non viene mai valutata isolatamente: gli eventi di firewall, DNS, Web, IPS, endpoint e Sophos Fusion relativi allo stesso intervallo temporale devono essere considerati insieme.

Verifiche positive e negative

Un progetto pilota in produzione dovrebbe includere almeno questi due casi:

1. Positivo: in presenza di un IoC o di un incidente reale confermato dal team MDR, conservare separatamente una voce di traffico verificabile con l’Action corretta e la relativa azione dell’analista con Audit ID, quindi confrontarle. Non generare ulteriore traffico verso infrastrutture dannose a questo scopo.
2. Negativo: un processo aziendale legittimo comparabile rimane accessibile e non genera un blocco MDR involontario.

In assenza di un incidente reale, non si crea artificialmente un IoC MDR. Si verificano invece configurazione, elaborazione dei task, trasporto dei log e percorso di comunicazione. Per un test del traffico completamente controllabile, un proprio feed pilota di terze parti è più adatto di una destinazione dannosa esterna.

Gestire le corrispondenze MDR come incidenti

Una corrispondenza MDR è un segnale forte, ma la sola voce di log non spiega ancora l’intero percorso dell’attacco. Una procedura ordinata è la seguente:

1. Conservare data e ora, Action, IoC, nome del feed, Event ID e audit_ID.
2. Identificare l’host e l’utente interessati tramite IP di origine, DHCP, Synchronized Security e dati endpoint.
3. Aprire in Sophos Fusion il caso MDR associato, il rilevamento e gli ulteriori eventi del dispositivo.
4. Correlare i log di firewall, DNS, Web, IPS ed endpoint nello stesso intervallo temporale.
5. Chiarire con il team MDR perché sia stato aggiunto l’IoC e quale risposta sia prevista.
6. In caso di compromissione confermata, avviare la procedura interna di risposta agli incidenti.
7. Solo successivamente decidere in merito a bonifica, regole aggiuntive o un’eccezione circoscritta.

L’Audit ID identifica l’azione dell’analista MDR. Nel Log Viewer, fare prima clic sul pulsante della vista dettagliata, quindi selezionare Admin nel menu a discesa. Conservare qui l’azione e l’audit_ID dell’aggiunta o della rimozione. In alternativa, l’azione dell’analista è disponibile in My Products > Firewall management > Tasks Queue in Sophos Fusion. In caso di richiesta di chiarimenti a MDR, includere nel caso l’Audit ID insieme a numero di serie del firewall, data e ora, IoC, Event ID e Incident ID. Una rimozione registrata dimostra un’azione amministrativa, non la bonifica dell’endpoint interessato.

Gestire le eccezioni in modo controllato

In Protect > Active threat response > Add threat exclusions è possibile creare eccezioni per host/reti e per minacce. Queste eccezioni si applicano a tutti i moduli. Un’eccezione per una corrispondenza MDR può quindi indebolire anche X-Ops, NDR o Third-Party Threat Feeds.

Prima di creare un’eccezione, documentare l’IoC, il processo aziendale interessato, il caso MDR e la conferma del falso positivo. L’eccezione deve essere il più circoscritta possibile e deve includere motivazione, responsabile, ticket e data di revisione o scadenza. Intere reti client o ampi insiemi di domini non sono una soluzione rapida adeguata.

Le configurazioni dei Threat Feeds non possono essere importate o esportate separatamente; le Threat Exclusions invece sì. Le impostazioni del feed MDR non possono neppure essere incluse tramite Import existing configuration nella configurazione iniziale di un nuovo gruppo di firewall Sophos Fusion. Dopo una migrazione, un ripristino o una sostituzione, occorre quindi verificare di nuovo esplicitamente funzione, Action, logging e associazione a Sophos Fusion.

Se non compare alcuna corrispondenza MDR

La verifica non inizia con il riavvio di un servizio. Si distinguono prima i vari livelli:

1. La licenza MDR, l’account Sophos Fusion, la registrazione del firewall e il Threat response mode sono corretti?
2. Gli MDR Threat Feeds sono attivi localmente e l’Action è stata salvata?
3. L’IoC in questione è stato effettivamente trasmesso dal team MDR per questo ambiente?
4. La Sophos Fusion Firewall Task Queue mostra Success, Partial Success, Failed oppure ancora Pending?
5. I log Active Threat Response sono attivati localmente, verso Syslog o in Sophos Fusion?
6. Il traffico attraversa il firewall, la regola e l’ispezione previsti?
7. L’IoC è incluso nelle eccezioni Active Threat Response, Web o SSL/TLS?
8. L’intervallo temporale e, in caso di HA, il nodo esaminato sono corretti?

Per lo stato del motore e dei feed, è possibile correlare temporalmente atr.log con Log Viewer e Sophos Fusion Firewall Task Queue. I log vengono soltanto letti; modifiche non documentate ai dati dei feed, ai database o ai servizi non sono un passaggio standard. Se la causa rimane sconosciuta, conservare CTR, log rilevanti, Task ID, Audit ID, build e data e ora per Sophos MDR o Sophos Support.

Rollback e controllo delle modifiche

Prima dell’attivazione, documentare lo stato precedente dell’interruttore, l’Action, le destinazioni dei log e le eccezioni esistenti. In caso di un impatto imprevisto sulle attività aziendali, non impostare subito un’eccezione ampia.

1. Conservare le evidenze della corrispondenza interessata e dell’impatto aziendale.
2. Informare il team MDR indicando Audit ID e incidente.
3. Se approvato dai responsabili competenti, riportare temporaneamente l’Action locale da Log and drop a Log only.
4. Solo se anche questo non è sufficiente e MDR è d’accordo, riportare il feed in modo controllato allo stato precedente documentato.
5. Dopo ogni modifica, verificare nuovamente lo stesso processo aziendale e l’effetto sui log.
6. Risolvere la causa e ripristinare la protezione in produzione con una nuova data di revisione.

Negli ambienti HA, verificare configurazione e stato sul Primary corrente. I log si trovano sul nodo che ha elaborato il traffico. Dopo un failover controllato, verificare nuovamente il collegamento a Sophos Fusion, lo stato del feed, le nuove voci di log e il traffico reale; non si presume una continuità senza interruzioni di MDR o dei log.

Checklist

• Xstream Protection Bundle attivo
• Abilitazione MDR attiva presente in Sophos Fusion
• Firewall registrato nell’account Sophos Fusion corretto
• Threat response mode e percorso di contatto MDR documentati
• Destinazione dei log Active Threat Response attivata
• MDR Threat Feeds attivati
• Action scelta consapevolmente e progetto pilota con scadenza definita
• Visibilità del traffico per IPv4, dominio e URL verificata
• Remote source match attivato per DNAT/WAF, se necessario
• Task Queue e stato locale confrontati
• Audit ID e processo di gestione degli incidenti noti
• Contesto endpoint e limiti delle piattaforme verificati
• Eccezioni corredate di responsabile e data di revisione
• Rollback e verifica HA documentati

Domande frequenti