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 nell’ambiente del cliente. Il firewall registra o blocca quindi il traffico corrispondente senza richiedere la manutenzione manuale di un file di feed.
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.
MDR Threat Feeds in otto passaggi
- Verificare che sul firewall sia attivo Xstream Protection Bundle e che in Sophos Fusion sia presente un’abilitazione MDR attiva.
- In
System > Sophos Fusion, confermare che il firewall corretto sia registrato nell’account Sophos Fusion corretto. - Documentare in Sophos Fusion il Threat response mode previsto e il percorso operativo di contatto MDR.
- In
System services > Log settings, attivare almeno una destinazione di log utilizzabile per Active threat response. - Aprire
Protect > Active threat response > MDR threat feedse attivare la funzione. - Scegliere
Log onlyper un breve test controllato oppureLog and dropper la protezione in produzione dopo una verifica riuscita, quindi fare clic su Apply. - Eseguire test positivi e negativi tramite Log Viewer, contesto endpoint e Sophos Fusion.
- Documentare Audit ID, responsabili, processo di eccezione, data di revisione e rollback.
Importante: Gli MDR Threat Feeds sono solo una parte delle operazioni MDR. Non sostituiscono il contratto MDR, i sensori endpoint, la comunicazione degli incidenti, regole firewall restrittive o un percorso di ripristino testato. Un’eccezione ampia o una disattivazione non controllata può indebolire una risposta in corso del team MDR.
Funzione degli MDR Threat Feeds
Gli analisti Sophos MDR possono inviare direttamente al firewall, tramite Sophos Fusion, intelligence relativa a un incidente attivo. Il feed è quindi più specifico per il cliente rispetto a un elenco di reputazione globale. Un IoC trasmesso può essere un indirizzo IPv4, un dominio o una URL.
L’azione locale del firewall determina cosa accade in caso di corrispondenza:
Log onlyregistra la corrispondenza ma consente il traffico.Log and dropregistra e scarta il traffico corrispondente.
Sophos consiglia di bloccare gli IoC noti. Un breve test Log only può comunque essere utile se un ambiente esistente deve prima verificare visibilità, logging e possibili effetti collaterali. Il test deve avere una data di fine definita. Senza una transizione pianificata, un’integrazione MDR attiva potrebbe altrimenti rimanere permanentemente priva di effetto di blocco locale.
Il Threat response mode in Sophos Fusion e l’azione locale del feed sono due livelli distinti. La modalità Sophos Fusion definisce le autorizzazioni di risposta del team MDR. Log only o Log and drop stabilisce come il firewall tratta uno IoC già trasmesso. Prima del rollout, entrambe le impostazioni vengono allineate al contratto MDR e al processo interno di gestione degli incidenti. L’attuale documentazione Sophos sul Threat response mode distingue Collaborate, Authorize e Notify Only.
Comprendere priorità e ciclo di vita
SFOS 22 elabora Active Threat Response nel seguente ordine: MDR, NDR Essentials, Sophos X-Ops e infine Third-Party Threat Feeds. Se un IoC trova corrispondenza in MDR con Log and drop, il firewall scarta il traffico, registra l’evento sotto MDR e non controlla i feed successivi. Con Log only o Monitor possono essere registrati eventi distinti per MDR, X-Ops e feed di terze parti. Un feed esterno successivo non può quindi prevalere sulla decisione MDR; l’assenza di una corrispondenza nel feed di terze parti può anche indicare che un modulo precedente ha già elaborato lo IoC.
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 compaiono con l’identità dell’analista come audit_ID nei log di Active Threat Response. In locale si controlla soltanto se il feed MDR è attivo e se le corrispondenze vengono registrate o 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 una durata 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 sembra obsoleta, occorre conservare audit_ID, IoC e data e ora, quindi confermarne lo stato con il team MDR. Questo è importante anche per il rollback: passare da Log and drop a Log only interessa tutti gli IoC MDR attualmente forniti, mentre una Threat Exclusion può indebolire anche NDR, X-Ops e i feed di terze parti.
Verificare correttamente 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, mentre la documentazione Sophos Fusion attuale chiama i livelli del servizio MDR e MDR Plus. È quindi necessario verificare il diritto MDR attivo nel proprio account Sophos Fusion, anziché dedurre l’idoneità da una precedente denominazione del prodotto. Il solo bundle Xstream non include il servizio MDR.
Il firewall deve essere registrato nell’account Sophos Fusion corretto. In System > Sophos Fusion si verificano la registrazione e l’inoltro di report e log. Collegare Sophos Firewall a Sophos Fusion descrive il processo completo.
Prima dell’attivazione devono essere chiare anche le responsabilità:
- Chi può modificare il Threat response mode in Sophos Fusion?
- Chi risponde a una chiamata o richiesta MDR fuori dall’orario di lavoro?
- Chi può approvare un’eccezione?
- Dove vengono documentati Audit ID, Incident ID e prove tecniche?
- Quali sistemi possono essere isolati dopo la conferma di una compromissione?
Attivare le destinazioni dei log
In System services > Log settings, attivare almeno una delle seguenti destinazioni nella riga Active threat response:
- Local reporting per Log Viewer e report locali
- un Syslog server configurato per il SIEM o il SOC
- Central reporting per Sophos Fusion
La colonna Central reporting appare solo dopo aver attivato Send reports and logs to Sophos Central nella pagina Sophos Fusion. XGS 87/87w e 107/107w non supportano il reporting locale; su questi modelli sono quindi necessari Central Reporting o Syslog.
Dopo aver selezionato le destinazioni dei log, fare clic su Apply in System services > Log settings. Ricaricare quindi la pagina e verificare che le destinazioni previste siano ancora selezionate nella riga Active threat response. Questo conferma la configurazione salvata; il trasporto effettivo dei log e la consegna delle notifiche di incidente devono essere verificati separatamente.
Per le notifiche si controlla anche System services > Notification list. L’attivazione di una destinazione di log definisce il percorso di trasporto, ma non dimostra né la consegna effettiva né la corretta gestione degli avvisi.
Visibilità per indirizzi IP, domini e URL
Un IoC agisce solo sul traffico che il firewall può elaborare in modo appropriato. Il traffico inoltrato verso un IP di destinazione richiede una regola firewall corrispondente. Le corrispondenze di dominio richiedono Application Classification o una policy IPS nella regola interessata. Per vedere il percorso completo di una URL HTTPS serve Web Proxy con decrittografia oppure DPI con una regola SSL/TLS Inspection adeguata.
Il traffico destinato al sistema verso servizi in Administration > Device access, come WebAdmin, VPN Portal e VPN, può essere confrontato con un indirizzo IPv4 sorgente dannoso. Per il traffico DNAT o WAF in ingresso e inoltrato, è necessario attivare anche Remote source match (inbound traffic) in System services > Log settings > Active threat response per ottenere la visibilità attesa nei log.
Limite irrisolto di ATR/X-Ops: La descrizione ufficiale e la matrice del traffico si contraddicono sulle corrispondenze dell’indirizzo di destinazione e dell’indirizzo sorgente locale per Sophos X-Ops. Per questi casi non è stato accertato in modo affidabile né il supporto né l’esclusione; le indicazioni sul traffico e sui moduli raggiungibili dai link non costituiscono una base di configurazione validata. Non se ne deve dedurre alcuna direzione di traffico MDR né presumere protezione per i casi X-Ops interessati. Prima di una modifica basata su tali affermazioni occorre un chiarimento autorevole di Sophos o un test del prodotto espressamente autorizzato; i link seguenti non risolvono questa contraddizione.
Configurare e gestire in sicurezza i Threat Feeds su Sophos Firewall spiega la logica generale di traffico, moduli e ispezione. Illustra inoltre perché il rilevamento di domini o URL può non avvenire senza la classificazione o la decrittografia appropriate.
Configurare gli MDR Threat Feeds
- Accedere a WebAdmin con un account amministratore personale.
- Aprire
Protect > Active threat response > MDR threat feeds. - Attivare MDR threat feeds.
- In Action, scegliere
Log onlyper un test con scadenza definita oLog and dropdopo una verifica riuscita. - Salvare con Apply.
- Ricaricare la pagina e verificare che interruttore e azione siano stati salvati.
- Controllare nell’Audit Trail l’ora, l’amministratore e la modifica.
- In Sophos Fusion, verificare che il firewall sia online e che MDR sia assegnato al cliente o tenant corretto.
Non modificare contemporaneamente e su larga scala logging, ispezione, eccezioni e azione. Un rollout graduale rende visibile quale modifica ha causato una corrispondenza o un effetto collaterale.
Verificare l’effetto in modo affidabile
Sophos non pubblica un indicatore di test MDR generale e innocuo. Contattare un vero dominio malware o un indirizzo IP dannoso noto non è quindi una verifica adeguata. Il controllo tecnico viene suddiviso in più livelli dimostrabili.
Configurazione e trasporto
- Controllare l’interruttore MDR e l’azione desiderata sul firewall.
- Verificare la registrazione Sophos Fusion e la licenza MDR.
- Confermare il logging Active Threat Response verso la destinazione prevista.
- In Sophos Fusion, verificare se i task MDR o firewall sono stati elaborati correttamente.
- Durante un incidente MDR reale, confrontare lo IoC previsto e l’Audit ID associato con il team MDR.
La Sophos Fusion Firewall Task Queue mostra task MDR e API. Success conferma l’elaborazione del task in Sophos Fusion, ma non il suo effetto su uno specifico flusso di traffico. In caso di Partial Success o Failed, conservare firewall interessato, Entity, Action e Credential ID e confrontarli con la configurazione locale.
Analizzare una corrispondenza in Log Viewer
In Log viewer > Active threat response si conservano almeno queste informazioni:
- data e ora, firewall e, in HA, nodo che ha elaborato il traffico
- azione e nome del feed
- indirizzo IP sorgente e destinazione, dominio o URL
- porte e protocollo
- Event ID e altri campi dettagliati
audit_IDper MDR
Con Synchronized Security, il firewall può mostrare anche utente, host e processo per gli endpoint Windows gestiti. In Log Viewer sono rilevanti Process user e Executable, oltre a host_process_user, endpoint_id e execution_path nella vista dettagliata. Questi dettagli di processo non vengono visualizzati su macOS; in quel caso l’endpoint viene identificato tramite IP sorgente e dati Sophos Fusion.
Il riepilogo locale è disponibile in Reports > Network & threats > Active threat response, nell’elenco Synchronized IoC. La panoramica dei servizi e dei file di log di Sophos Firewall descrive anche atr.log. Non valutare mai una singola voce isolatamente: correlare gli eventi firewall, DNS, web, IPS, endpoint e Sophos Fusion dello stesso intervallo temporale.
Test positivo e negativo
Un test in produzione deve includere almeno questi due casi:
- Positivo: Un IoC o incidente reale confermato dal team MDR genera sul firewall previsto una voce tracciabile con azione e Audit ID corretti.
- Negativo: Un processo aziendale legittimo e comparabile resta raggiungibile e non genera un blocco MDR indesiderato.
Senza un incidente reale non viene creato artificialmente uno IoC MDR. Si verificano invece configurazione, elaborazione dei task, trasporto dei log e percorso di comunicazione. Per un test di traffico completamente controllato, un feed pilota di terze parti gestito internamente è più sicuro di una destinazione dannosa esterna.
Trattare una corrispondenza MDR come incidente
Una corrispondenza MDR è un segnale forte, ma la singola voce di log non spiega l’intero percorso dell’attacco. Un processo ordinato è:
- Conservare ora, azione, IoC, nome del feed, Event ID e
audit_ID. - Identificare host e utente interessati tramite IP sorgente, DHCP, Synchronized Security e dati endpoint.
- Aprire in Sophos Fusion il caso MDR associato, la detection e gli altri eventi del dispositivo.
- Correlare i log firewall, DNS, web, IPS ed endpoint dello stesso intervallo temporale.
- Chiarire con il team MDR perché lo IoC è stato aggiunto e quale risposta è prevista.
- Avviare il processo interno di risposta agli incidenti dopo la conferma di una compromissione.
- Solo successivamente decidere su remediation, regole aggiuntive o un’eccezione restrittiva.
L’Audit ID identifica l’azione dell’analista MDR. È visibile nella vista dettagliata Admin di Log Viewer e in My Products > Firewall management > Tasks Queue in Sophos Fusion. Includerlo insieme a numero di serie del firewall, ora, IoC, Event ID e Incident ID in ogni richiesta al team MDR.
Gestire le eccezioni in modo controllato
In Protect > Active threat response > Add threat exclusions si possono aggiungere eccezioni host/rete e threat. Queste eccezioni si applicano a tutti i moduli. Un’eccezione per una corrispondenza MDR può quindi indebolire anche X-Ops, NDR o i Threat Feeds di terze parti.
Prima di aggiungere un’eccezione, documentare IoC, processo aziendale interessato, caso MDR e conferma del falso positivo. Mantenere l’eccezione il più restrittiva possibile e assegnarle motivo, responsabile, ticket e data di revisione o scadenza. Intere reti client o ampi intervalli di domini non sono una riparazione rapida appropriata.
Le configurazioni dei Threat Feeds non possono essere importate o esportate separatamente, mentre le Threat Exclusions sì. Le impostazioni MDR non possono inoltre essere trasferite tramite Import existing configuration nella configurazione iniziale di un nuovo gruppo firewall Sophos Fusion. Dopo una migrazione, un ripristino o una sostituzione, ricontrollare esplicitamente funzione, azione, logging e assegnazione Sophos Fusion.
Se non appare alcuna corrispondenza MDR
Il controllo non inizia con il riavvio di un servizio. Prima separare i livelli:
- Licenza MDR, account Sophos Fusion, registrazione del firewall e Threat response mode sono corretti?
- MDR Threat Feeds è attivo localmente e l’azione è stata salvata?
- Il team MDR ha realmente inviato lo IoC interessato a questo ambiente?
- Sophos Fusion Firewall Task Queue mostra
Success,Partial Success,Failedo ancoraPending? - I log Active Threat Response sono attivi localmente, per Syslog o in Sophos Fusion?
- Il traffico attraversa il firewall, la regola e l’ispezione previsti?
- Lo IoC è incluso in un’eccezione Active Threat Response, web o SSL/TLS?
- L’intervallo temporale e, in HA, il nodo esaminato corrispondono?
Per lo stato del motore e del feed, correlare temporalmente atr.log con Log Viewer e Sophos Fusion Firewall Task Queue. I log vengono solo letti; modifiche non documentate a dati dei feed, database o servizi non sono un passaggio standard. Se la causa rimane incerta, raccogliere CTR, log rilevanti, Task ID, Audit ID, build e ora per Sophos MDR o Sophos Support.
Rollback e controllo delle modifiche
Prima dell’attivazione, documentare lo stato precedente dell’interruttore, l’azione, le destinazioni dei log e le eccezioni esistenti. In caso di impatto aziendale inatteso non creare subito un’eccezione ampia.
- Conservare la corrispondenza interessata e l’impatto aziendale.
- Informare il team MDR tramite Audit ID e incidente.
- Se approvato, riportare temporaneamente l’azione locale da
Log and dropaLog only. - Solo se ciò non basta e MDR approva, riportare il feed in modo controllato allo stato precedente documentato.
- Verificare nuovamente lo stesso processo aziendale e l’effetto sui log dopo ogni modifica.
- 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 risiedono sul nodo che ha elaborato il traffico. Dopo un failover controllato, verificare nuovamente connessione Sophos Fusion, stato del feed, nuove voci di log e traffico reale; non presumere una continuità MDR o dei log senza interruzioni.
Lista di controllo
- Xstream Protection Bundle attivo
- abilitazione MDR attiva in Sophos Fusion
- firewall registrato nell’account Sophos Fusion corretto
- Threat response mode e percorso di contatto MDR documentati
- destinazione log Active Threat Response attiva
- MDR Threat Feeds attivo
- azione scelta consapevolmente e test con scadenza definita
- visibilità del traffico per IPv4, dominio e URL verificata
- Remote source match attivo per DNAT/WAF se necessario
- Task Queue e stato locale confrontati
- Audit ID e processo di gestione degli incidenti conosciuti
- contesto endpoint e limiti della piattaforma verificati
- eccezioni con responsabile e data di revisione
- rollback e verifica HA documentati
Domande frequenti
Gli MDR Threat Feeds sono inclusi nel bundle Xstream?
Qual è la differenza tra Threat response mode e Log and drop?
Log and drop è l’azione locale del firewall per uno IoC già trasmesso. Entrambi i livelli devono corrispondere al contratto e al processo interno di gestione degli incidenti.Come identifica MDR una specifica voce del feed?
audit_ID dell’azione dell’analista. Inviare questo ID al team MDR insieme a ora, IoC, Event ID e Incident ID.