Utilizzare Sophos XDR Threat Intelligence Explorer

Threat Intelligence Explorer rende ricercabili le informazioni sulle minacce della Sophos Counter Threat Unit (CTU) in Sophos Fusion (in precedenza Sophos Central). Consente di cercare famiglie di malware, analisi e gruppi di minaccia noti e di confrontare il contesto descritto con le detection del proprio ambiente. Una voce in questa base di conoscenza non equivale a un riscontro nel proprio tenant né a una compromissione confermata.

Il percorso rapido: aprire Security Operations > Threat Intelligence, cercare attraverso Malware, Threat Report o Threat Group, leggere i dettagli disponibili e distinguere Related Detections da Related Detectors. Solo i propri eventi mostrano se il contesto ricercato è pertinente a un case concreto.

Prerequisiti e limiti

L’Explorer richiede una licenza XDR o Enterprise. Questa procedura descrive la vista Security Operations. Threat Analysis Center rimane disponibile come vista Classic; i runbook esistenti per indagini e case possono quindi mostrare ancora questo percorso di menu. Non mescolare le etichette delle due viste.

La CTU aggiorna la propria intelligence sulla base di indagini di incident response, osservazione globale delle minacce, analisi tecniche di malware e campagne e collaborazione con partner e autorità. Queste informazioni descrivono lo scenario delle minacce; detection ed eventi nel tenant descrivono l’attività osservata nel proprio ambiente. Un’indagine richiede entrambi i livelli.

Sono importanti tre termini:

Un Indicator of Compromise (IOC) è, ad esempio, un indizio di possibile compromissione citato in un’analisi. Il suo significato va valutato insieme a momento, origine e comportamento osservato.
Un Detector è la logica di rilevamento che genera una detection da eventi insoliti o sospetti. Un detector correlato non equivale a un riscontro già presente.
Tactics, Techniques and Procedures (TTPs) descrivono il modo di operare di un attaccante. TTP simili o lo stesso malware non dimostrano che un determinato gruppo abbia attaccato il proprio tenant.

Qui l’Explorer è un punto di partenza per ricerche e indagini. Leggere o filtrare una famiglia di malware non viene trattato come configurazione di un threat feed firewall, di una regola di blocco o di una Response Action.

Cercare prima di restringere i risultati

La barra di ricerca in alto a destra cerca in malware, Threat Report e Threat Group. Come punto di partenza si può usare un termine da una detection o da un rapporto, ad esempio Emotet. Il valore è solo un esempio di ricerca: utilizzare il nome effettivamente da esaminare.

In Security Operations > Threat Intelligence, aprire una delle tre viste e inserire il termine di ricerca.
Selezionare un risultato concreto per vederne i dettagli. Per confrontare prima l’elenco dei risultati, scegliere View in table o See all. La tabella corrispondente viene filtrata sui risultati della ricerca.
Solo dopo aggiungere altri filtri. In questo modo rimane riconoscibile se un filtro restrittivo ha escluso risultati utili.
Per iniziare una nuova ricerca, fare clic sulla X a destra nel campo di ricerca. Cancella la ricerca e reimposta anche i filtri della tabella. Annotare prima i termini e i filtri importanti nel registro dell’indagine.

Più filtri sono utili quando rispondono a una domanda concreta. Cercare un nome di malware noto insieme a una CVE è diverso dal cercare rapporti ransomware recenti per un settore. Troppi criteri all’inizio rendono difficile interpretare un elenco vuoto.

Esaminare una famiglia di malware

Malware contiene analisi tecniche, IOC e collegamenti con attori delle minacce. Per impostazione predefinita, la tabella è ordinata prima per Threat Priority assegnata dalla CTU a minacce importanti o attuali, poi per ultimo aggiornamento. Questo ordine rappresenta una priorità dell’intelligence, non la Severity di una propria detection.

I filtri documentati hanno compiti diversi:

Malware cerca il nome della famiglia, ad esempio Emotet o TrickBot.
Type restringe la classificazione, ad esempio Trojan, Ransomware o Backdoor.
Threat Group cerca malware collegati a un determinato gruppo, ad esempio GOLD MYSTIC o BRONZE BUTLER.
CVE cerca malware che sfruttano una determinata vulnerabilità. Ad esempio, utilizzare CVE-2021-44228 quando l’indagine riguarda proprio questa vulnerabilità. Il filtro non sostituisce la verifica dell’effettivo coinvolgimento dei propri sistemi.

Un clic sul nome della famiglia apre il pannello laterale dei dettagli. Leggere prima Malware family overview per descrizione e classificazione, poi Technical details per comportamento, capacità e indicatori. Solution and mitigation contiene le misure di protezione consigliate. Verificare le raccomandazioni rispetto alla propria piattaforma e alle protezioni già presenti, senza attuarle solo perché compare un risultato di ricerca.

L’intelligence correlata è disponibile, quando presente, in schede dedicate:

Threat Group indica i gruppi che utilizzano questo malware.
Threat Report rimanda ai rapporti CTU correlati.
Related Detections mostra dati delle detection del proprio ambiente.
Related Detectors mostra i detector Sophos XDR che rilevano questo malware.

L’icona New Tab permette di aprire la vista dei dettagli in una nuova scheda. Da lì si può copiare l’URL e usarlo come riferimento preciso nel registro dell’indagine. È più utile del solo nome della famiglia quando più analisti devono esaminare la stessa voce.

Scegliere il Threat Report per la domanda concreta

Threat Report contiene pubblicazioni CTU quali briefing giornalieri, analisi approfondite e avvisi sulle minacce. Per una detection concreta, cercare prima malware, gruppo o CVE; per una panoramica periodica della situazione, usare argomento e tipo di pubblicazione.

I filtri distinguono contenuto e forma della pubblicazione:

Threat Report cerca il nome del rapporto, ad esempio Daily Threat Brief o Ransomware Analysis.
Report Type è la categoria generale di pubblicazione, ad esempio Advisory, Analysis o Brief.
Category indica il tipo più specifico, ad esempio Customer Advisory, Threat Analysis o CTU TIPS.
Threat Type restringe le minacce trattate, ad esempio Ransomware, APT o Cybercrime.
Threat Actor Type distingue tipi di attori come Nation-state, Cybercriminal o Hacktivist.
Target Geography cerca l’area geografica di interesse, ad esempio Europe o Global.
Target Sectors restringe i settori discussi, ad esempio Financial, Healthcare o Government.
Threat Group, Malware e CVE cercano rispettivamente i gruppi, le famiglie di malware e le vulnerabilità trattati nel rapporto.

Target Geography e Target Sectors aiutano a stabilire le priorità, ma non sono criteri per escludere il proprio rischio. Gli attacchi opportunistici possono colpire qualsiasi regione e settore anche senza una preferenza specifica. Non limitare quindi una panoramica della situazione esclusivamente al proprio settore.

Fare clic sul nome del rapporto e leggere il pannello dei dettagli. A seconda del rapporto, sono disponibili Full report text, Executive summary, Technical details e Indicators of compromise. Non ogni pubblicazione contiene tutte queste sezioni. Indicators of compromise può includere IOC e firme correlati. Il riepilogo fornisce orientamento; per l’indagine contano i dettagli tecnici concreti e i loro limiti.

Quando disponibili, Related Detections mostra le proprie detection e Related Detectors i detector XDR citati nel rapporto. Anche qui, una logica di rilevamento disponibile e un riscontro osservato nel tenant sono due affermazioni distinte. Aprire il rapporto completo con New Tab ed eventualmente copiarne l’URL per il case.

Considerare il Threat Group come ipotesi di lavoro

Threat Group descrive gruppi di minaccia noti e le loro TTP. Questa vista è utile quando un rapporto cita un gruppo, quando occorre risolvere un alias noto o quando si vuole valutare la propria difesa rispetto a determinate modalità operative.

I filtri coprono identità, intenzioni e modalità operative:

Threat Group cerca la denominazione del gruppo, ad esempio GOLD MYSTIC o BRONZE ATLAS.
Thematic Area restringe il contesto tematico o regionale, ad esempio Cybercrime, China o Russia.
Aliases cerca nomi alternativi come APT1, Lazarus Group o FIN7.
Status distingue lo stato di attività attuale, ad esempio Active e Inactive.
Motivation descrive motivazioni come Financial, Political o Military.
Objectives descrive obiettivi come Financial Gain, Espionage o Disruption.
Target Geography e Target Sectors cercano schemi di targeting geografici o settoriali.
Malware cerca famiglie collegate; Tools cerca strumenti e tecniche utilizzati, ad esempio PowerShell, Mimikatz o PsExec.

Anche gruppi senza preferenze specifiche possono colpire la propria regione o il proprio settore. Un elenco vuoto dopo un filtro settoriale non è quindi un segnale di assenza di rischio.

Dopo il clic sul nome del gruppo, il pannello dei dettagli contiene Group description, con contesto e capacità stimate, Attribution assessment, con attribuzione geografica o organizzativa, Activity timeline, con campagne e operazioni, e l’analisi delle Tactics, Techniques, and Procedures. New Tab apre i dettagli per ottenere un riferimento diretto copiabile.

Attribution assessment rimane una valutazione della CTU. Non dimostra né la responsabilità di un proprio incidente né che ogni utilizzo dello stesso malware appartenga a questo gruppo. Nel case annotare quindi, ad esempio, «Il comportamento è compatibile con le tecniche descritte» e documentare separatamente quali propri eventi sostengono l’affermazione. Un’attribuzione definitiva a un attore richiede più evidenze di una corrispondenza di nome, strumento o malware.

Dalla voce di intelligence alla detection e al case

La Threat Intelligence arricchisce automaticamente le detection con contesto pertinente; diversi detector XDR utilizzano questi dati per il rilevamento. Questo non garantisce che ogni tecnica descritta venga rilevata in ogni tenant. L’indagine torna quindi dal contesto agli eventi effettivi.

Verificare le proprie detection

Se Related Detections contiene risultati, aprire un risultato pertinente e visualizzare i dettagli completi della detection tramite New Tab. In alternativa, cercare in Security Operations > Detections. L’intervallo predefinito è di 72 ore; per un incidente più vecchio occorre modificarlo. Controllare filtri e Include Options per non escludere involontariamente detection personalizzate o già sottoposte a triage.

Nella detection verificare:

In Summary, leggere Affected Entities, il Detector che l’ha generata, le informazioni temporali disponibili, Severity e Confidence. First and Last Activity descrivono gli orari degli eventi; Inserted At indica il momento della registrazione.
In Events, aprire gli eventi che hanno portato alla detection. In JSON, consultare se necessario i dati sottostanti della detection. Il riepilogo non sostituisce queste evidenze.
In Insights, verificare detection aperte e chiuse correlate e case. I case già esistenti possono evitare lavoro duplicato; quelli chiusi forniscono contesto storico dell’indagine.
Per altra intelligence, fare clic sull’icona a forma di scudo in Affected Entities oppure selezionare in Entities un’entità con questa icona. Il passaggio dalla detection all’intelligence funziona quindi anche nella direzione opposta.

Per approfondire processi endpoint e grafi, consultare il runbook su detection e Threat Graph. Tratta anche la vista Classic. L’assenza di proprie detection in una voce di intelligence non dimostra né che il tenant sia privo di compromissioni né che la telemetria sia completa. Se occorrono ulteriori query, il runbook su Data Collection e Live Discover spiega la base dati e la procedura di query classica.

Associare le evidenze pertinenti a un case

Prima di aggiungerle, verificare se esiste già un case per la stessa indagine e se è modificabile. I case con stato Closed sono di sola lettura, tranne Status e Archive; quelli archiviati consentono solo Unarchive. Utilizzarli inizialmente come contesto storico, senza presumere che siano destinazioni modificabili per nuove evidenze, commenti o riassegnazioni. Nei case MDR, le azioni disponibili e le opzioni di Assignee dipendono anche da chi gestisce il case. Prima di una modifica, verificare le azioni effettivamente disponibili e chiarire le possibilità mancanti con il responsabile.

Per il passaggio, distinguere l’azione della tabella dai dettagli completi della detection. Le guide ufficiali non indicano sempre le stesse etichette per la vista dei dettagli; non esiste quindi un percorso di menu universale per ogni vista verificabile con affidabilità in questo runbook:

Righe selezionate nella tabella Detections: selezionare le detection desiderate e aprire Actions > Add to Case.
Dettagli completi della detection: la guida dei dettagli indica in Actions le azioni dirette Add to Existing Case e Create New Case. La guida dei case descrive invece per le singole detection Actions > Add to Case, seguito dalla scelta di Existing Case o New Case. Usare l’azione effettivamente visualizzata per un case esistente o nuovo, senza cercare un’etichetta assente in quella vista.

Se viene visualizzato il dialogo Add to Case, seguire questi passaggi:

Per un case esistente, scegliere Existing Case, cercare e selezionare il case, quindi salvare con Save to Existing Case.
Per un nuovo case, scegliere New Case, impostare Case Type, eventualmente un modello, titolo, Case Severity e Case Status. Tramite l’icona a matita in Key Findings, aggiungere i primi riscontri e il contesto, quindi scegliere Create New Case.

Con una selezione multipla, verificare se vengono aggiunte solo le detection selezionate o tutte quelle della tabella. Non importare un intero elenco di risultati senza verificarlo. Possono trascorrere alcuni minuti prima che le evidenze compaiano nel case; aprire poi il case di destinazione e controllare l’associazione effettiva.

Per i clienti MDR, i tipi di case Investigation e Other richiedono anche Managed By. La scelta determina chi gestisce il case e non può essere cambiata dopo l’impostazione. Prima di salvare, confrontarla con la responsabilità prevista. Una successiva modifica di Assignee non cambia Managed By.

In un case modificabile, registrare l’URL di intelligence copiato e le affermazioni concretamente utilizzate come contesto dell’indagine, ad esempio in Key Findings oppure, se disponibile, come commento nella pagina completa dei dettagli del case tramite Comments > Comment > Save. Distinguere esplicitamente ricerca ed evidenze del tenant: cosa afferma il rapporto, cosa mostrano i propri eventi e cosa rimane un’ipotesi? L’URL da solo non conserva il contenuto di un’analisi che potrà essere aggiornata; inserire quindi nella nota l’affermazione rilevante e il momento della consultazione.

La guida esistente su case e Detection Rule descrive il percorso classico. Per Security Operations, tenere conto delle varianti di etichetta spiegate sopra e delle azioni mostrate nel tenant. L’Explorer non sostituisce né un analista responsabile né la decisione sul contenimento o sulla bonifica.

Esempio: esaminare in modo verificabile un’indicazione di malware

Supponiamo che una propria detection citi una famiglia di malware non ancora sufficientemente conosciuta. L’esempio seguente non afferma l’esistenza di un riscontro:

Cercare il nome effettivo della famiglia; Emotet è solo un valore di esempio. Non aggiungere subito anche un settore o un gruppo.
Leggere descrizione, dettagli tecnici e raccomandazioni di protezione. In Threat Report, esaminare un rapporto disponibile sul comportamento osservato.
Cercare i propri riscontri in Related Detections. Confrontare ogni risultato pertinente con dispositivo o entità, orario dell’evento ed eventi concreti. In Related Detectors, comprendere quale logica di rilevamento appartiene al contesto.
Se viene citato un gruppo, confrontarne TTP e cronologia delle attività. Mantenere l’attribuzione come valutazione, anche quando singole caratteristiche coincidono.
Associare le detection pertinenti a un case esistente o nuovo. Annotare nel case: voce di intelligence esaminata, momento della ricerca, termini e filtri, riferimenti alle proprie detection, corrispondenze comprovate, domande aperte e prossimo responsabile.

Un risultato utile può anche essere che il rapporto fornisce solo una somiglianza generale. Documentare allora questo limite, anziché dedurne una compromissione o un determinato attaccante.

Verificare il risultato e risolvere le difficoltà più comuni

La ricerca è verificabile quando un altro analista può aprire la stessa voce di intelligence, comprendere i filtri utilizzati e ricondurre ogni conclusione ai dati delle proprie detection e dei propri eventi. In caso di passaggio a un case, verificare anche che le detection corrette siano nel case corretto e che la prossima azione sia assegnata a un responsabile. Se il case è modificabile e l’azione è disponibile, selezionarlo nei dettagli completi del case in Manage Case > Assignee.

Se i risultati non corrispondono alle attese, effettuare queste verifiche:

Nessun risultato di ricerca: controllare l’ortografia e, per i gruppi, Aliases. Rimuovere i filtri aggiuntivi; con la X nel campo di ricerca reimpostare ricerca e filtri della tabella e ricominciare in modo più ampio. Una ricerca vuota da sola non dice nulla sul rischio dell’ambiente.
Troppi risultati: aggiungere una caratteristica pertinente, ad esempio Type per il malware oppure Report Type e Threat Type per i rapporti. In Detections, restringere anche l’intervallo temporale. La tabella Detections è limitata a 10'000 risultati; i risultati aggregati dei filtri arrivano al massimo a 1'000. Una vista ampia non è quindi un inventario completo.
Rapporto senza gli IOC o le schede attesi: i contenuti disponibili dipendono dal rapporto. Leggere il testo completo e l’intelligence correlata presente, senza presumere contenuti mancanti o una determinata copertura.
Detector presenti, ma nessun proprio riscontro: distinguere il contesto del detector dalla detection osservata. Verificare intervallo, filtri e telemetria disponibile per l’indagine. Non eseguire malware o disattivare la protezione per fare un test.
Explorer non disponibile: verificare prima la licenza XDR/Enterprise e il tenant utilizzato. Se manca la nuova navigazione, controllare gli avvisi sulla transizione nella console; non dedurre un errore tecnico del prodotto da un menu mancante.
Evidenze del case non ancora visibili: attendere alcuni minuti per l’elaborazione, poi ricontrollare selezione e case di destinazione. Non creare subito un secondo case.

Ricerca e filtri servono qui solo alla consultazione; per ricominciare basta il ripristino dei filtri descritto. L’aggiunta di evidenze o commenti, e soprattutto la scelta immutabile di Managed By, sono invece modifiche al case. Questo runbook non prevede un passaggio universale per annullarle. Le associazioni errate devono essere chiarite e documentate con il responsabile del case. Non chiudere i case come operazione di pulizia: la chiusura modifica anche le valutazioni delle detection associate.

Durante l’esercizio, esaminare regolarmente nuove voci di malware, attività dei gruppi e rapporti. I filtri settoriali possono focalizzare la panoramica, ma devono integrarla, non sostituire la visione generale. Inserire le conoscenze acquisite nel processo di incident response; le TTP dei gruppi sono utili per il threat modeling, le analisi malware per pianificare e verificare le proprie misure di protezione. Nuova intelligence giustifica una nuova valutazione, non dimostra automaticamente la necessità di modificare la configurazione.