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 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 Central, 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

1. Verificare che sul firewall sia attivo Xstream Protection Bundle e che Sophos Central disponga di Sophos MDR Essentials o Sophos MDR Complete.
2. In System > Sophos Central, confermare che il firewall corretto sia registrato nell’account Central corretto.
3. Documentare in Sophos Central 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 test controllato oppure Log and drop per la protezione in produzione dopo una verifica riuscita, quindi fare clic su Apply.
7. Eseguire test positivi e negativi tramite Log Viewer, contesto endpoint e Sophos Central.
8. 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 Central, 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 only registra la corrispondenza ma consente il traffico.
• Log and drop registra 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 Central e l’azione locale del feed sono due livelli distinti. La modalità Central 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.

Verificare correttamente i prerequisiti

Licenza e Sophos Central

Gli MDR Threat Feeds richiedono Xstream Protection Bundle sul firewall. In Sophos Central è inoltre necessario Sophos MDR Essentials o Sophos MDR Complete. Il solo bundle Xstream non include un servizio MDR completo.

Il firewall deve essere registrato nell’account Sophos Central corretto. In System > Sophos Central si verificano la registrazione e l’inoltro di report e log. Collegare Sophos Firewall a Sophos Central descrive il processo completo.

Prima dell’attivazione devono essere chiare anche le responsabilità:

• Chi può modificare il Threat response mode in Central?
• 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 Central

La colonna Central reporting appare solo dopo aver attivato Send reports and logs to Sophos Central nella pagina Sophos Central. XGS 87/87w e 107/107w non supportano il reporting locale; su questi modelli sono quindi necessari Central Reporting o Syslog.

Per le notifiche si controlla anche System services > Notification list. L’attivazione di una destinazione di log dimostra solo il percorso di trasporto, non 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.

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

1. Accedere a WebAdmin con un account amministratore personale.
2. Aprire Protect > Active threat response > MDR threat feeds.
3. Attivare MDR threat feeds.
4. In Action, scegliere Log only per un test con scadenza definita o Log and drop dopo una verifica riuscita.
5. Salvare con Apply.
6. Ricaricare la pagina e verificare che interruttore e azione siano stati salvati.
7. Controllare nell’Audit Trail l’ora, l’amministratore e la modifica.
8. In Sophos Central, 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

1. Controllare l’interruttore MDR e l’azione desiderata sul firewall.
2. Verificare la registrazione Central e la licenza MDR.
3. Confermare il logging Active Threat Response verso la destinazione prevista.
4. In Central, verificare se i task MDR o firewall sono stati elaborati correttamente.
5. Durante un incidente MDR reale, confrontare lo IoC previsto e l’Audit ID associato con il team MDR.

La Sophos Central Firewall Task Queue mostra task MDR e API. Success conferma l’elaborazione del task in Central, 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_ID per 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 Central.

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 Central dello stesso intervallo temporale.

Test positivo e negativo

Un test in produzione deve includere almeno questi due casi:

1. Positivo: Un IoC o incidente reale confermato dal team MDR genera sul firewall previsto una voce tracciabile con azione e Audit ID corretti.
2. 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 è:

1. Conservare ora, azione, IoC, nome del feed, Event ID e audit_ID.
2. Identificare host e utente interessati tramite IP sorgente, DHCP, Synchronized Security e dati endpoint.
3. Aprire in Sophos Central il caso MDR associato, la detection e gli altri eventi del dispositivo.
4. Correlare i log firewall, DNS, web, IPS ed endpoint dello stesso intervallo temporale.
5. Chiarire con il team MDR perché lo IoC è stato aggiunto e quale risposta è prevista.
6. Avviare il processo interno di risposta agli incidenti dopo la conferma di una compromissione.
7. 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 Central. 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 Central. Dopo una migrazione, un ripristino o una sostituzione, ricontrollare esplicitamente funzione, azione, logging e assegnazione Central.

Se non appare alcuna corrispondenza MDR

Il controllo non inizia con il riavvio di un servizio. Prima separare i livelli:

1. Licenza MDR, account Central, registrazione del firewall e Threat response mode sono corretti?
2. MDR Threat Feeds è attivo localmente e l’azione è stata salvata?
3. Il team MDR ha realmente inviato lo IoC interessato a questo ambiente?
4. Central Task Queue mostra Success, Partial Success, Failed o ancora Pending?
5. I log Active Threat Response sono attivi localmente, per Syslog o in Central?
6. Il traffico attraversa il firewall, la regola e l’ispezione previsti?
7. Lo IoC è incluso in un’eccezione Active Threat Response, web o SSL/TLS?
8. 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 Central 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.

1. Conservare la corrispondenza interessata e l’impatto aziendale.
2. Informare il team MDR tramite Audit ID e incidente.
3. Se approvato, riportare temporaneamente l’azione locale da Log and drop a Log only.
4. Solo se ciò non basta e MDR approva, riportare il feed in modo controllato allo stato precedente documentato.
5. Verificare nuovamente lo stesso processo aziendale e l’effetto sui log dopo ogni modifica.
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 risiedono sul nodo che ha elaborato il traffico. Dopo un failover controllato, verificare nuovamente connessione Central, 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
• Sophos MDR Essentials o MDR Complete attivo
• firewall registrato nell’account Central 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