Analizzare e correggere i rischi in Sophos ITDR Dark Web Intelligence

Dark Web Intelligence mostra i record delle fughe di dati che Sophos ha raccolto per i domini configurati. Lo scopo di questo runbook non è trattare ogni occorrenza come un accesso attuale all’account. Per prima cosa vengono controllati identità, riferimento temporale, tipo di password e stato della fuga. Successivamente, si risponde solo attraverso un processo approvato per l’identità effettivamente collegata.

I Credential Leaks Active aumentano il Risk Score di un’identità. I record storici restano comunque visibili, anche quando sono inattivi. La tabella serve quindi sia come vista operativa dei rischi attuali sia come prova di scoperte passate.

Flusso rapido

1. Apri My Products > Identity > Dark Web Intelligence e documenta i filtri predefiniti.
2. Dai priorità a un record attivo e registra Source, identità collegata, tipo di password e Publish Date, Leaked Date e Breach Date.
3. Verifica perché il record è Active; non considerare ogni riga come un account o una password univoci.
4. Per un Finding associato, confronta la gravità visualizzata con la matrice utilizzando il tipo di account, il tipo di password e la forza dell’MFA.
5. Conferma responsabilità e autorizzazione. Solo allora esegui la risposta appropriata, già autorizzata.
6. Correggi le credenziali nell’Identity Provider responsabile seguendo il processo approvato. Non usare lo stato del Finding o del leak come sostituto di tale correzione.
7. Dopo almeno un ciclo di 15 minuti, riesamina lo stato, il Finding e il Risk Score e documenta le evidenze.

Visualizzazioni e filtri predefiniti

Accesso diretto

My Products > Identity > Dark Web Intelligence

Quando si apre direttamente questa pagina, la tabella è filtrata per lo stato della perdita Active e lo stato dell’identità Active. Prima di esaminare, salva uno screenshot o annota i filtri attivi. Una visualizzazione predefinita vuota non prova che non ci siano dati storici di perdite; per questo controllo, allarga deliberatamente i filtri di stato.

Accesso tramite Identity Overview

Identity Overview > Credential Leaks

Cliccando su una metrica nel widget Credential Leaks si apre Dark Web Intelligence con una sezione corrispondente alla metrica:

Breached Email Accounts e Unique Passwords Breached sono le metriche aggregate dei dati sottostanti. Non esiste alcun filtro aggiuntivo della tabella che mappi completamente il loro metodo di conteggio unico. Pertanto, la metrica non può essere ricostruita esattamente dalle righe della tabella visibili dopo il clic.

Interpretare correttamente le metriche

Le metriche sopra Dark Web Intelligence si riferiscono alle perdite attive:

Questi valori utilizzano unità diverse: fonti, registri di perdite, account e password uniche. Non possono essere sommati o convalidati semplicemente contando le righe della tabella.

Indagare su un record di perdita

1. Definire l’ambito

Per prima cosa, nota i filtri e l’ordinamento. Per il primo triage, almeno queste caratteristiche sono rilevanti:

• Stato della perdita Active o Inactive
• Stato dell’identità e identità collegata
• Plaintext o Hashed
• Admin, contesto non admin o VIP, se indicato
• Source
• Publish Date, Leaked Date e Breach Date
• Finding associato, se presente

Non stabilire le priorità esclusivamente in base alla data più recente nella tabella. Un record con una nuova Publish Date può contenere dati più vecchi, soprattutto nel caso delle combolist.

2. Apri dettagli

Clicca sul campo Source. Il pannello dei dettagli mostra informazioni aggiuntive sulla perdita e, se disponibile, l’identità collegata. Prima di rispondere, la riga della tabella e il pannello dei dettagli devono riferirsi alla stessa fonte e identità.

Se non viene assegnata alcuna identità, il record rimane rilevante per l’indagine storica, ma è considerato inattivo. Actions è disabilitato in questo caso. Non assegnare un’identità basandoti su un’ipotesi e non agire contro un account con un nome simile.

3. Distinguere i campi della data

Publish Date

Il momento in cui Sophos ha rilevato per la prima volta il record di perdita nei dati che ha analizzato. Non si riferisce né al momento della disponibilità pubblica né necessariamente al momento dell’incidente.

Leaked Date

La data in cui il set di dati è diventato pubblicamente disponibile. Questa data viene confrontata con l’ultima modifica della password per valutare se il rischio delle credenziali è attuale.

Breach Date

Il momento in cui si è verificata la violazione sottostante. Fornisce il contesto dell’incidente, ma potrebbe non essere disponibile.

Un Breach Date mancante non fa sì che Leaked Date sia il tempo di violazione confermato. Allo stesso modo, un nuovo Publish Date non dimostra che la password sia stata compromessa di recente. Per la logica dello stato, è cruciale sapere se l’ultimo cambio di password è avvenuto prima o dopo il tempo della prima perdita rilevante.

4. Interpretare duplicati e combolist

La stessa persona può apparire in diverse righe all’interno di una fonte. Le ragioni comuni includono:

• la persona appare più volte nel set di dati originale;
• lo stesso contenuto è stato riconosciuto in una fonte generica come un combolist;
• dati di perdite più vecchi diventano di nuovo visibili in una raccolta trovata successivamente.

Più righe, quindi, non indicano automaticamente né più account compromessi né più compromissioni attuali di password. Confronta fonte, data, tipo di password e identità collegata per ogni riga. Le metriche Emails e Unique Passwords applicano una logica di deduplicazione; le righe della tabella non sono deduplicate allo stesso modo.

Quando una perdita è Active o Inactive

Una perdita è Active se entrambe le condizioni sono soddisfatte:

1. Il record può essere collegato a un’identità attiva in un Identity Provider configurato.
2. L’ultima modifica della password dell’account associato è avvenuta prima del primo momento della fuga.

Active indica quindi un rischio legato alle credenziali che è ancora rilevante. Lo stato da solo non prova un accesso riuscito da parte di terzi o un attacco in corso.

Una perdita è Inactive se almeno uno degli scenari documentati si applica:

• Non esiste alcuna identità corrispondente negli Identity Provider configurati.
• L’ultima modifica della password è avvenuta dopo il momento della fuga di dati.
• La password dell’account è stata cambiata di recente.
• L’account è stato disattivato o eliminato.
• Un Finding correlato è stato impostato su Resolved o Dismissed.

I dati storici sui domini monitorati continuano a essere raccolti e conservati. Un record inattivo, quindi, non è errato né irrilevante soltanto a causa della sua età. Può spiegare perché la stessa persona o fonte appare più volte.

Quando viene creato un Finding

Sophos descrive la seguente elaborazione per i Findings relativi alla compromissione degli account:

1. Sophos verifica se esiste un’identità attiva negli Identity Provider configurati.
2. Sophos determina dai dati storici disponibili quando il valore in chiaro o l’hash è stato divulgato per la prima volta. Questo è inteso a riconoscere contenuti vecchi in nuove combolists.
3. Per un valore in chiaro, Sophos lo confronta con i requisiti globali di complessità delle password di Microsoft Entra ID per escludere i valori non validi.
4. Sophos confronta il momento della prima fuga della password con l’ultima modifica della password. Se la prima fuga è successiva a tale modifica, Sophos crea un Finding.

I Findings vengono creati solo per le identità attive. I dati grezzi rimangono visibili in Dark Web Intelligence anche se non è collegata alcuna identità attiva.

Matrice di gravità per la compromissione dell’account

Secondo Sophos, la gravità del Finding dipende dal tipo di account, dal tipo di password e dalla robustezza dell’MFA:

La matrice dà priorità al lavoro, ma non sostituisce una valutazione del singolo caso. Soprattutto per gli account amministrativi, è necessario confermare l’effettiva associazione dell’account prima di intervenire. Un livello di gravità inferiore non significa che non sia necessaria alcuna correzione.

Gestione dei valori della password

Sophos afferma che non memorizza né le password in chiaro né i valori hash. Sophos afferma inoltre di non poter acquisire questi valori dagli Identity Provider. Sophos applica il proprio hash ai valori osservati durante la raccolta e poi classifica il set di dati come Plaintext o Hashed. Secondo Sophos, questo metodo rende possibile determinare valori unici e indicatori derivati senza memorizzare il valore della password sottostante.

Operativamente, questo significa:

• Plaintext descrive il tipo di contenuto della perdita osservata, non una password disponibile in Sophos Fusion (in precedenza Sophos Central).
• Non provare a recuperare il valore originale da Sophos Fusion, screenshot o esportazioni.
• Non copiare password sospette, valori hash o nuove credenziali in ticket, note o messaggi di chat.
• Imposta una nuova password esclusivamente tramite il processo approvato dell’Identity Provider e trattala nel sistema di password previsto.

Risposta autorizzata e rimedio

Decidi prima di intraprendere qualsiasi azione

Prima di Actions devono essere soddisfatti tutti i seguenti punti:

• L’identità collegata è chiaramente confermata dal pannello dei dettagli.
• Il titolare del conto, il tipo di conto e la funzione aziendale sono noti.
• Lo stato attuale della fuga, il tipo di password e tre campi data sono stati controllati.
• Le Response Actions sono autorizzate per il tenant.
• La persona che esegue l’azione è autorizzata per l’identità specifica e l’impatto previsto.
• Il responsabile del servizio o del sistema è coinvolto in account privilegiati o condivisi.

Se una di queste condizioni manca, non viene attivata alcuna azione. Il record viene passato alla persona responsabile del team Identità o Sicurezza con data e ora, stato del filtro e dettagli dell’approvazione mancante.

Rispondi in Dark Web Intelligence

Se le Response Actions sono autorizzate, sono disponibili per le identità collegate nella tabella o nel dettaglio della perdita:

1. Apri la riga corretta o il pannello dei dettagli dell’identità confermata.
2. Seleziona Actions.
3. Seleziona solo la Response Action già approvata.
4. Rivedi e segui tutte le istruzioni e conferme sullo schermo.
5. Documenta azione, operatore, orario, identità di destinazione e risultato visibile, ma non acquisire le credenziali.

È possibile utilizzare esclusivamente le Response Actions disponibili nel tenant e autorizzate dall’organizzazione. Se non esiste un’identità adatta, Actions rimarrà disabilitato; questo non deve essere bypassato.

Rimedia il rischio delle credenziali

La risoluzione tecnica avviene tramite l’Identity Provider responsabile dell’account e il processo di credenziali approvato:

1. Controlla l’ultima modifica della password e lo stato dell’account dell’identità confermata rispetto al momento della perdita.
2. Se non è possibile escludere che i dati di accesso osservati nella perdita siano ancora validi, avvia o esegui una modifica autorizzata della password per questo specifico account.
3. Se un account è disabilitato o eliminato, conferma lo stato nell’Identity Provider anziché riattivare l’account per la correzione.
4. Se il record non è collegato a un’identità, trattalo come una perdita storica e inattiva e non tentare di indovinare l’identità dell’account.
5. Gestisci un Finding associato secondo il processo previsto solo dopo aver documentato l’effettiva correzione delle credenziali. Usa Dismissed solo dopo una decisione tecnicamente motivata e documentata, non per abbreviare la coda.

Non dedurre alcun cambiamento aggiuntivo di account, sessione, MFA o directory dal record di perdita. Tali misure richiedono un motivo confermato separatamente e l’approvazione necessaria per esse.

Cadenza e convalida di 15 minuti

Sophos controlla Dark Web Intelligence ogni 15 minuti. Sophos monitora e raccoglie continuamente i risultati delle perdite; se viene rilevata una perdita attiva, di solito viene generato un Finding entro 15 minuti. “Di solito” non è un tempo massimo garantito.

Dopo la correzione, non registrare immediatamente un successo finale. Invece:

1. Registra l’orario di completamento del cambio della password o del cambio account confermato con il fuso orario.
2. Attendi almeno un ciclo completo di 15 minuti. Considera che l’acquisizione da parte di Sophos dei dati aggiornati dell’Identity Provider può richiedere tempo aggiuntivo.
3. Riapri My Products > Identity > Dark Web Intelligence.
4. Cerca la stessa identità e fonte con gli stessi filtri.
5. Verifica se la perdita è passata da Active a Inactive e se lo stato dell’identità visualizzato è corretto.
6. Controlla separatamente il Finding associato. L’assenza di un nuovo Finding non è una prova sufficiente se il leak è ancora Active.
7. Monitora il Risk Score dell’identità come segnale di follow-up. Non è la prova primaria del cambiamento della password.
8. Documenta il valore iniziale, l’azione, l’ora di completamento, l’ora di convalida e lo stato finale.

Criteri di accettazione

L’elaborazione è completata solo quando:

• identità e fonte della perdita sono chiaramente documentate;
• i campi di tipo password e data sono stati valutati;
• la correzione delle credenziali è confermata nell’Identity Provider responsabile oppure l’account risulta disabilitato o eliminato;
• Il registro della perdita corretta non è più Active dopo l’elaborazione;
• Il Finding associato è stato gestito attraverso un processo controllato;
• nessun valore segreto è nella documentazione.

Se il record rimane Active dopo diversi cicli di 15 minuti, ricontrolla innanzitutto l’ultima modifica effettiva della password, lo stato dell’account e l’identità collegata. Se queste informazioni sono corrette e lo stato resta inspiegabile, acquisisci lo stato dei filtri, la fonte, tutti e tre i campi data, il riferimento all’identità, il riferimento al Finding e il timestamp. Quindi inoltra il caso al supporto Sophos. Non apportare ulteriori modifiche all’account basandoti su un’ipotesi.

Registro di triage

Tenant / ambiente:
Ora di convalida con fuso orario:
Percorso e filtri attivi:
Source:
Identità collegata:
Stato dell'identità:
Tipo di account: Admin / Non-Admin / non chiaro
Monitoraggio VIP: sì / no / non chiaro
Tipo di password: Plaintext / Hashed
Stato della perdita prima dell'azione:
Publish Date:
Leaked Date:
Breach Date: Valore / non disponibile
Più righe o contesto della lista combinata:
Riferimento e gravità Finding:
Ultima modifica della password secondo Identity Provider:
Approvazione della risposta:
Azione autorizzata eseguita:
Tempo di completamento con fuso orario:
Validazione dopo il ciclo di 15 minuti:
Stato della perdita dopo la misura:
Stato di Finding dopo l'azione:
Risk Score come segnale di follow-up:
Deviazione / escalation aperta:

Evita errori comuni

• Contare ogni riga della tabella come un account separato: Duplicati e combolist possono creare più righe per la stessa persona.
• Publish Date letto come Breach Date: I tre campi di data descrivono eventi diversi; Breach Date potrebbe mancare.
• Interpretare Inactive come eliminato: I dati storici rimangono intatti e possono essere ulteriormente visibili.
• Considerare rassicurante l’assenza di righe con i filtri predefiniti: L’accesso diretto mostra per impostazione predefinita solo i leak attivi di identità attive.
• Chiudere manualmente un Finding invece di correggere: Un cambiamento di stato non modifica alcun dato di accesso nell’Identity Provider.
• Forzare Actions senza un’identità collegata: Senza un’identità corrispondente, il pulsante è intenzionalmente disabilitato.
• Confondere Plaintext con una password recuperabile: Sophos afferma che né i valori in chiaro né i valori hash sono memorizzati.
• Aspettarsi un aggiornamento immediato: Il controllo viene eseguito ogni 15 minuti; i dati di identità a monte potrebbero richiedere ulteriore tempo di elaborazione.