Esaminare e gestire i finding di Sophos ITDR

In My Products > Identity > Findings, Sophos ITDR mostra i risultati dei controlli eseguiti sull’infrastruttura di identità connessa. Per impostazione predefinita, la tabella è ordinata per rischio. Un finding non costituisce automaticamente la prova di una compromissione attiva, né è una XDR Detection o un XDR Case. È un elemento di lavoro ITDR che deve essere valutato, gestito nel sistema di identità competente e quindi verificato nuovamente.

Il flusso di lavoro sicuro è il seguente:

1. Assegnare la priorità ai finding aperti in base a Risk e usare i filtri per creare una coda di lavoro gestibile.
2. Leggere Finding Details, Description, Definition e Recommendation; se necessario, esaminare i dati non elaborati in Result e le modifiche in History.
3. Valutare l’impatto e le dipendenze nel proprio ambiente prima di modificare una configurazione.
4. Correggere la causa nel sistema o servizio di identità interessato, anziché limitarsi a cambiare lo stato in ITDR.
5. Convalidare lo stato prima presso il provider e poi in ITDR.
6. Impostare un finding su Resolved o Dismissed soltanto a seguito di una decisione consapevole. Impostarlo manualmente su Resolved non equivale a correggere il problema.

Interpretare correttamente stati, livelli di rischio e categorie

Stato

ITDR non considera più i finding Resolved e Dismissed come rischi per l’ambiente. I due stati restano tuttavia distinti sul piano operativo: Resolved indica una causa corretta o un rischio ridotto, mentre Dismissed indica una decisione consapevole di accettazione del rischio.

Rischio

Il livello di rischio deriva dal controllo sottostante e consente di stabilire le priorità. A parità di livello, esaminare prima le identità privilegiate esposte, gli indizi di credenziali compromesse e i finding con un ampio raggio d’azione. La specifica Recommendation rimane più importante di qualsiasi intervento generico.

Categoria

ITDR usa le categorie seguenti. I nomi restano invariati nell’interfaccia Sophos in inglese:

• User Behavior
• Configuration
• Entra Conditional Access Gaps
• Dormant Resources
• Lateral Movement
• Credential Compromise
• Persistence
• Privilege Escalation
• Defense Evasion
• Exfiltration
• VIP Exposure

La categoria descrive il tipo di controllo e, dove opportuno, può essere allineata al modello MITRE ATT&CK. Non sostituisce l’analisi dettagliata né la verifica che una configurazione osservata sia intenzionale nel proprio ambiente.

Filtrare i finding e creare una coda di lavoro

Il menu dei filtri comprimibile a sinistra della tabella Identity Findings combina i filtri seguenti:

• Risk: livello di rischio del finding.
• Status: Open, Resolved o Dismissed.
• Reference Type: tipo di oggetto interessato.
• Category: categoria del finding.
• Is New: finding rilevati per la prima volta negli ultimi sette giorni.
• Finding: titolo del finding.
• First Seen: data e ora della prima osservazione.
• Last Seen: data e ora dell’ultima osservazione.
• Last Modified: data e ora dell’ultima modifica.

Per Reference Type sono disponibili esattamente questi valori:

• User Object
• Application
• Group Object
• Device Object
• Tenant Configuration

I filtri selezionati compaiono sopra la tabella. Usare X per rimuovere un singolo filtro e Clear All per rimuoverli tutti. La tabella e l’URL si aggiornano dinamicamente in base alla selezione. È quindi possibile salvare un URL filtrato come vista di lavoro o condividerlo con i colleghi. Prima di condividerlo, verificare che i destinatari abbiano accesso allo stesso tenant Central e che l’URL possa essere inserito nel ticket previsto.

Una coda di lavoro iniziale efficace usa Status = Open, seguito da Risk = Critical o High. Restringere poi i risultati con Category, Reference Type o Is New. In questo modo i nuovi rischi critici per le identità restano visibili senza perdere gli elementi aperti meno recenti.

Esaminare a fondo un finding

Selezionando il link nella colonna Findings si apre il pannello dei dettagli. Il pannello mostra l’oggetto associato, il rischio, First Seen, Last Seen, Last Modified e la raccomandazione. Usare l’icona New Tab per aprire la pagina completa in una nuova scheda.

Il pannello e la vista completa includono:

• Finding Details: riepilogo con livello di rischio, stato, commenti, timestamp e tag.
• Description: descrizione del finding.
• Definition: informazioni sul controllo di identità associato e sui relativi riferimenti.
• Recommendation: raccomandazione di Sophos per ridurre il rischio specifico.

Per un triage affidabile è necessario rispondere almeno alle domande seguenti:

1. Quale oggetto è interessato e Reference Type corrisponde all’oggetto previsto?
2. La condizione descritta in Description e Definition è ancora presente presso il provider di identità?
3. Qual è l’ambito delle autorizzazioni e quali sono le dipendenze e i possibili effetti di una modifica?
4. La Recommendation è adatta al proprio ambiente e la modifica è autorizzata internamente?
5. First Seen, Last Seen e Last Modified indicano un problema nuovo, ricorrente o già gestito?

Finding Details mostra commenti e tag. Tuttavia, la documentazione Sophos relativa alla pagina Findings non descrive né una funzione di assegnazione né controlli per creare o modificare commenti e tag. La responsabilità e le prove delle modifiche devono pertanto essere registrate nel sistema approvato di change management o ticketing; i commenti non sostituiscono né un change ticket né la prova della modifica nel sistema di origine.

Esaminare Result come dati non elaborati

La scheda Result mostra l’output non elaborato del controllo eseguito in formato JSON. È particolarmente utile quando il riepilogo non consente di capire quale attributo, oggetto o risultato abbia determinato la valutazione.

Considerare le chiavi e i valori JSON come l’esito dello specifico controllo, senza dedurne uno schema generale. Confrontare gli identificatori degli oggetti, gli stati e i timestamp pertinenti con le informazioni correnti presso il provider di identità. I dati non elaborati sensibili devono essere inseriti soltanto in ticket o note d’indagine approvati.

Tenere traccia delle modifiche con History

La scheda History mostra le azioni precedenti sul finding. View Diff apre le modifiche esatte e consente di ricostruire le variazioni di stato e le altre fasi di gestione. In questo modo è possibile distinguere una riapertura imprevista da un nuovo finding.

Correggere la causa e convalidare il risultato

⚠️ Verificare prima di apportare modifiche: una raccomandazione Sophos deve essere adatta all’ambiente, alla tolleranza al rischio e al processo di approvazione delle modifiche dell’organizzazione. Le modifiche a ruoli, autenticazione, accesso condizionale, applicazioni o altri oggetti di identità possono influire su utenti, applicazioni e accessi. Chiarire quindi le dipendenze e il piano di ripristino prima dell’implementazione.

La correzione deve essere eseguita nel sistema in cui ITDR ha rilevato il problema, ad esempio il provider di identità connesso o il servizio applicativo competente. Lo stato in ITDR gestisce soltanto il flusso di lavoro dei finding e non modifica la configurazione del provider.

Una chiusura controllata prevede quattro passaggi:

1. Verificare lo stato del provider: confermare che la modifica autorizzata sia stata salvata e sia effettiva per l’oggetto interessato.
2. Verificare nuovamente il finding: controllare l’oggetto associato, Last Seen, Result e History. Un risultato obsoleto o invariato non dimostra il successo dell’intervento.
3. Attendere il comportamento automatico: se a un nuovo controllo il finding non compare più, ITDR lo risolve automaticamente e aggiunge un commento. I controlli della postura di Entra ID e delle risorse inattive vengono normalmente eseguiti ogni due ore; il Risk Posture Score dell’intera organizzazione viene aggiornato ogni giorno.
4. Documentare il risultato: registrare nel documento di lavoro approvato le prove del provider, lo stato del finding, il timestamp e, se applicabile, View Diff. Se il finding resta aperto dopo l’intervallo di controllo previsto, confrontare nuovamente lo stato del provider, l’oggetto interessato e il risultato JSON, anziché cambiare ripetutamente lo stato a mano.

Un finding impostato manualmente su Resolved può essere riportato dal sistema a Open non appena ITDR osserva di nuovo la stessa condizione. Non si tratta di un errore del modello degli stati, ma dell’indicazione che la causa è ancora presente, si è ripresentata o è ancora visibile nei dati valutati da ITDR.

Usare Dismissed solo per una decisione consapevole sul rischio

⚠️ Dismissed impedisce la creazione di ulteriori finding: quando un finding viene escluso, ITDR non crea nuovi finding per lo stesso problema sull’oggetto interessato. Il finding resta nella tabella, ma viene escluso dal dashboard e dal Risk Posture Score dell’intera organizzazione. Un’esclusione prematura può quindi sottrarre alla normale visualizzazione un rischio ancora presente o che potrebbe tornare rilevante.

Dismissed è appropriato soltanto quando la condizione è prevista, la correzione è comprovabilmente impossibile o non giustificabile sul piano operativo e il responsabile accetta il rischio residuo. Documentare fuori da ITDR almeno l’oggetto, la motivazione, i controlli compensativi, l’approvazione e la data di riesame. In alternativa, un finding tecnicamente non risolvibile può restare Open, mantenendo il rischio visibile nel punteggio e nel monitoraggio continuo.

Assegnare la priorità a Credential Compromise

I finding relativi ad account compromessi vengono generati soltanto per le identità attive. Tra gli altri fattori, ITDR verifica se esiste un’identità attiva, quando una password in chiaro o un hash sono stati divulgati per la prima volta e se tale data è successiva all’ultima modifica della password. Un valore in chiaro viene inoltre confrontato con i requisiti globali di complessità delle password di Microsoft Entra ID. I dati non elaborati possono comunque essere visibili in Dark Web Intelligence, indipendentemente dalla generazione di un finding.

Quando viene generato un finding, ITDR determina il livello di rischio in base al tipo di account, al tipo di divulgazione e al livello di protezione MFA:

Ai fini della priorità, gestire prima i finding Critical e poi quelli High; a parità di livello, esaminare prima gli account privilegiati e le divulgazioni in chiaro. Una classificazione più bassa in presenza di MFA o di MFA resistente al phishing non significa che il finding possa essere ignorato. Eseguire le misure di protezione e correzione approvate nel sistema di identità competente e secondo il proprio processo di risposta agli incidenti. Convalidare quindi lo stato del provider, il finding e la cronologia come descritto sopra. Lo stato, da solo, non conferma la sicurezza di un’identità.

Distinguere le responsabilità del cliente, di MDR e di XDR

Sophos ITDR è una soluzione monitorata dal cliente. Anche con Sophos MDR acquistato separatamente, il triage e la gestione ordinaria dei finding restano responsabilità del cliente. L’MDR Operations Team si concentra sulle minacce attive alle identità e può includere nella propria indagine singoli finding critici o ad alto rischio se indicano una minaccia attiva. Ciò non implica né la presa in carico automatica di tutti i finding né l’esecuzione di modifiche presso il provider di identità.

Per ogni finding inoltrato a un livello superiore è quindi necessario documentare chiaramente:

• chi è responsabile del triage e delle decisioni sul rischio;
• chi autorizza ed esegue le modifiche nel sistema di identità;
• se un indizio di minaccia attiva è stato trasferito al processo MDR concordato;
• chi esegue la convalida finale dell’effetto tecnico e dello stato ITDR.

I finding ITDR restano separati da XDR Detections e XDR Cases. Il contesto relativo alle identità può contribuire a un’indagine più approfondita. Tuttavia, stato, commenti e chiusura del finding ITDR appartengono al flusso di lavoro ITDR e non equivalgono al flusso di lavoro XDR o MDR.