Esaminare Directory e Identity Details di Sophos ITDR

La Directory di Sophos ITDR è l’inventario operativo delle identità, dei gruppi, dei dispositivi e delle app che ITDR acquisisce dai provider di identità connessi. Le schede con gli indicatori mostrano il numero di oggetti monitorati; facendo clic si apre la vista corrispondente. Per svolgere un’indagine, da questo inventario complessivo si accede ai dati di dettaglio dell’oggetto tramite il relativo nome visualizzato.

Percorso rapido: in My Products > Identity > Directory, selezionare innanzitutto il tab corretto, applicare ricerca e filtri e verificare l’origine dei dati. Per un utente, aprire Display Name, quindi verificare un’ipotesi concreta in ciascuna delle sezioni Summary, Activity Log, Findings, Insights, Group Membership e Dark Web Intelligence. Un singolo tag, un Risk Score elevato o un accesso insolito costituiscono un segnale per definire le priorità, ma da soli non provano una compromissione.

Chiarire i limiti del prodotto prima dell’indagine

La Directory di ITDR non è il servizio directory di Sophos Fusion (in precedenza Sophos Central). Mostra il contesto di sicurezza acquisito dall’integrazione ITDR o dal sensore ITDR. Global Settings > Platform > Directory service, invece, mette a disposizione utenti e gruppi per le funzioni e i prodotti Central condivisi. Ne derivano tre limiti importanti:

• Un’identità assente dalla Directory di ITDR non ricompare eseguendo nuovamente Central Directory Sync. Occorre innanzitutto verificare l’integrazione ITDR, l’inventario del provider e lo stato della relativa acquisizione.
• Un oggetto nella Directory di ITDR non è automaticamente un utente Central gestito e non implica l’assegnazione di un prodotto né l’installazione di Endpoint.
• I filtri, i tag e la semplice apertura delle pagine di dettaglio in ITDR non modificano gli oggetti di directory di Entra ID, Active Directory, Intune o Central. Le correzioni tecniche vengono eseguite nel sistema autorevole e successivamente convalidate in ITDR; separatamente, le azioni di risposta espressamente autorizzate possono essere disponibili tramite gli appositi punti di accesso Actions.

Anche Sophos XDR ha una finalità diversa. La Directory di ITDR fornisce il contesto relativo all’inventario, alla postura di sicurezza e alle identità. Una query o un’indagine XDR, invece, correla telemetria ed eventi provenienti dalle origini dati supportate. Per questo motivo, Activity Log in Identity Details non è una timeline XDR completa e un Finding ITDR non equivale automaticamente a una Detection XDR. Per un’indagine sulle minacce che coinvolga più casi, i segnali ITDR confermati vengono correlati con i dati XDR, Endpoint, Entra e di rete disponibili, senza interpretare l’assenza di telemetria come un risultato privo di anomalie.

Interpretare correttamente l’inventario della Directory

Il punto di accesso My Products > Identity > Directory presenta quattro tab con funzioni distinte:

I campi di ricerca restringono la rispettiva vista in base al nome. Ricerca e filtri agiscono esclusivamente sui dati visualizzati e acquisiti da ITDR. L’assenza di risultati, quindi, non prova né che l’oggetto non esista presso il provider né che sia stato eliminato. Prima di procedere con un’escalation, verificare ortografia, tab, filtri attivi, tenant del provider e momento dell’acquisizione.

Cercare, ordinare e filtrare le identità

Identities può essere visualizzato sotto forma di schede o di elenco. Per impostazione predefinita, gli utenti sono ordinati alfabeticamente. Nel menu di ordinamento è possibile, ad esempio, selezionare l’ordine decrescente per Risk Score, così da individuare le identità da esaminare per prime. Search Identities filtra in base al nome.

I filtri utili dipendono dall’indagine. Per una prima definizione delle priorità, Status restringe la selezione in base allo stato dell’account segnalato dal provider di identità, mentre Risk Severity la restringe in base all’intervallo del Risk Score calcolato. Is Admin rappresenta il contesto amministrativo impostato dal provider o in base ai ruoli privilegiati rilevati, Is VIP indica la selezione per il VIP Monitoring e Is Compromised segnala la presenza di fughe attive di credenziali. Is Dormant individua gli account per i quali non sono stati acquisiti accessi da oltre 90 giorni.

Per contestualizzare l’account sono disponibili Department ed Employee Type come attributi organizzativi, se forniti dal provider. Is Guest identifica un account guest presso il provider di identità; Is Cloud Only identifica un account presente esclusivamente presso il provider di identità cloud e privo di identificatori locali. Il contesto MFA è fornito da Has MFA, Has Passwordless MFA, Primary MFA Method e MFA Method. Country e Region filtrano in base agli attributi geografici configurati presso il provider.

Un valore di filtro vuoto non rappresenta un risultato negativo. Se il provider non fornisce un attributo, la licenza limita l’accesso API oppure Microsoft non ha ancora reso disponibili dati aggiornati, ITDR non può popolare il campo in modo affidabile. Ciò vale in particolare per i dati relativi a MFA, amministratori, dispositivi e attività.

Nella vista a schede, la freccia in fondo a una scheda mostra ulteriori informazioni; è possibile espandere una sola scheda alla volta. Nella vista a elenco, la freccia a sinistra espande una riga. Il menu delle colonne consente di bloccare le colonne, ridimensionarle automaticamente, ripristinarle, aggiungerle o rimuoverle. Queste impostazioni di visualizzazione non modificano né l’oggetto né la relativa valutazione.

Se le azioni di risposta sono state autorizzate in precedenza, per un utente sono disponibili tramite Actions nella scheda espansa o nella colonna Actions della vista a elenco. La disponibilità di un punto di accesso o di un’azione dipende dallo stato dell’identità e dalla configurazione; l’esecuzione richiede inoltre le necessarie autorizzazioni dell’operatore e il processo di approvazione interno. Filtri, tag e apertura dei dettagli restano funzioni distinte che non apportano modifiche. Dopo l’esecuzione di un’azione, verificarne l’esito nel provider autorevole e successivamente controllare lo stato aggiornato in ITDR.

Usare icone e tag come contesto, non come giudizio

Le icone identificano User, MFA User, Deleted User, Locked User, Admin, Guest o Service. I tag aggiuntivi descrivono proprietà diverse e non devono essere interpretati come un giudizio complessivo sul rischio: Admin indica che l’account è stato riconosciuto come amministratore, Guest identifica un guest nel tenant, Deleted User un account eliminato presso il provider e Locked User un account disabilitato.

MFA User indica che l’MFA è abilitata, Compromised una fuga attiva di credenziali e Dormant Account un’identità senza accessi acquisiti negli ultimi 90 giorni. Cloud Only significa che non sono presenti identificatori locali; con Hybrid, gli identificatori locali sono presenti e sincronizzati tra il cloud e l’ambiente locale. Human classifica l’identità come utente umano, mentre VIP identifica la configurazione per il VIP Monitoring.

Human e Non-Human Identity (NHI) non devono essere confusi. Un account umano rappresenta una persona. Le NHI comprendono in particolare Service Principals, applicazioni e altre identità macchina. Un’icona Service fornisce il contesto corrispondente nella vista delle identità; le Enterprise Applications locali del tenant vengono esaminate nel tab Apps. Il fatto che un nome visualizzato sembri riferirsi a una persona o a un servizio non costituisce una classificazione attendibile.

Distinguere Application Object e Service Principal

Un Application Object di Microsoft Entra è la definizione globale di un’applicazione registrata nel relativo Home Tenant. Descrive, tra l’altro, la configurazione dell’identità dell’applicazione e possiede un App ID, detto anche Client ID. Nel caso di un Service Principal di tipo Application, il Service Principal è l’istanza locale concreta di tale applicazione in un determinato tenant. Questo tipo fa riferimento all’Application Object e stabilisce, nel tenant interessato, che cosa può fare l’app, chi può accedervi e a quali risorse può accedere. Tale associazione non vale per tutti i tipi di Service Principal: un Service Principal di tipo Managed identity non dispone di un Application Object associato; un Service Principal Legacy non dispone di una registrazione app associata.

Il tab Apps mostra le Enterprise Applications acquisite da ITDR nel tenant Entra monitorato, vale a dire istanze locali del tenant correlate alle applicazioni, e non semplicemente un secondo elenco di registrazioni app globali. Non se ne può quindi dedurre né che vi compaia ogni tipo di Service Principal presente in Entra, né che ogni contesto NHI visualizzato disponga di una registrazione app. Un’applicazione multi-tenant può disporre di un Application Object nel proprio Home Tenant, ma di un Service Principal distinto di tipo Application in ciascuno dei tenant che la utilizzano. Per questo motivo, Display Name, tenant, App/Client ID, Object ID, Owner e autorizzazioni devono essere confrontati congiuntamente. Nomi identici non indicano necessariamente lo stesso oggetto; Service Principals locali diversi di questo tipo possono fare riferimento alla stessa applicazione globale.

Tramite Display Name si apre App Details. Qui si verificano i metadati acquisiti da ITDR e le tabelle relative agli Owner dell’app, ai Findings collegati e alle autorizzazioni. Un’autorizzazione anomala va convalidata nel provider rispetto allo scopo aziendale previsto, al Publisher, al Consent e all’Owner responsabile. La visualizzazione nella Directory non revoca di per sé alcun Consent e non rimuove alcuna autorizzazione.

Esaminare gruppi e dispositivi

In Groups, la ricerca può essere circoscritta con quattro filtri: Deleted identifica i gruppi eliminati presso il provider, Mail Enabled quelli in grado di ricevere e-mail e Security Enabled quelli che possono controllare l’accesso alle risorse. Assignable to Roles identifica i gruppi ai quali è possibile assegnare ruoli.

Facendo clic su Group Name si apre Group Details, con i metadati del gruppo acquisiti e le tabelle degli utenti, dei gruppi e delle applicazioni assegnati. Durante una verifica degli accessi, occorre confermare nel provider autorevole il tipo di gruppo, l’Owner, le relazioni dirette e annidate e la necessità aziendale. Mail Enabled non indica se un gruppo viene utilizzato per le autorizzazioni; a questo scopo è rilevante Security Enabled.

In Devices è possibile cercare dispositivi e applicare filtri per State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed e Compliant. La vista include i dispositivi personali e aziendali registrati in Microsoft Entra ID. Un oggetto dispositivo è un’identità nel provider; Microsoft Entra registered, Microsoft Entra joined e Microsoft Entra hybrid joined sono contesti distinti di registrazione o join e non equivalgono all’installazione di un Sophos Endpoint Agent.

Tramite Display Name si apre Device Details. A seconda del tipo di dispositivo, la pagina mostra i metadati acquisiti, le identità assegnate, i Findings pertinenti e altre informazioni disponibili. Managed, Compliant, Rooted e Ownership sono dati forniti dal provider. Se mancano, il valore va documentato come non disponibile o sconosciuto ai fini dell’indagine. Da tale assenza non si possono dedurre gli stati «unmanaged», «non-compliant» o «not rooted», né la proprietà personale o aziendale. Un valore assente, inoltre, non equivale a un valore Unknown esplicitamente segnalato dal provider.

Esaminare Identity Details in modo sistematico

In Identities, facendo clic su Display Name si apre la pagina Identity Details. Invece di leggere ogni tab senza formulare un’ipotesi, si consiglia di procedere come segue:

1. Confermare l’oggetto: confrontare nome visualizzato, stato, tipo, indirizzi e-mail e contesto del provider con l’utente atteso.
2. Comprendere la priorità: verificare Risk Score, fattori che vi contribuiscono, Findings aperti, Compromised, Admin e contesto MFA e Dormant. Uno score stabilisce la priorità dell’indagine, ma non la sostituisce.
3. Verificare la plausibilità del profilo e degli asset: confrontare ruolo, reparto, regione, struttura organizzativa e dispositivi Intune assegnati con il profilo previsto.
4. Esaminare l’attività: impostare l’intervallo temporale e verificare accessi riusciti e non riusciti, orari, paesi, indirizzi IP e ASN alla ricerca di anomalie.
5. Aprire le evidenze collegate: esaminare singolarmente Findings, Detections, gruppi e dati del dark web, invece di dedurre la causa da un riepilogo.
6. Convalidare nel sistema autorevole: eseguire una verifica incrociata con Entra ID, AD locale, Intune e, se necessario, la telemetria XDR. Apportare quindi le modifiche tecniche nel rispettivo sistema autorevole. Se è invece prevista una risposta ITDR espressamente approvata, utilizzare a tale scopo un punto di accesso Actions disponibile.
7. Aggiornare il risultato: dopo la correzione o la risposta, verificare nuovamente l’esito presso il provider e in ITDR e documentare quali visualizzazioni risultano già aggiornate e quali attendono ancora il successivo ciclo di acquisizione.

Summary

Summary riunisce profilo, priorità e attività recente. In Details sono disponibili i dati Entra ID quali ruolo, reparto, stato, paese e regione, data e ora di creazione e modifica, ultima modifica della password e ulteriori indirizzi e-mail associati. Assets mostra i dispositivi Intune assegnati all’utente in Entra ID. Multi-Factor Authentication indica il provider MFA, il metodo MFA primario e gli altri tipi di MFA configurati. Organization fornisce il contesto organizzativo con responsabili, collaboratori diretti e struttura dell’organizzazione; facendo clic su una persona, questa si apre in un nuovo tab.

Ai fini della valutazione della sicurezza, Recent Detections mostra le Open Detections degli ultimi sette giorni e le Closed Detections degli ultimi 30 giorni; View All conduce a Insights. Risk Score contiene lo score corrente e i principali fattori che contribuiscono al punteggio. Top Sign-in Locations riepiloga le località di accesso più frequenti con attività da IP pubblici e privati. Se sono disponibili dati, Commonly Used Entities suddivide le autenticazioni riuscite degli ultimi 30 giorni in base a IP Addresses, Browser, Asset Name e OS Version.

In Top Sign-in Locations > View Details vengono mostrati, in particolare, località geografica, ASN e frequenza degli indirizzi IP principali negli ultimi 30 giorni. IP type e Login outcome fungono da filtri e non si presume che siano necessariamente visualizzati come colonne dei risultati. Gli indirizzi IP privati non devono essere interpretati geograficamente come quelli pubblici. Una città ricorrente può dipendere dall’egress di una VPN o di un servizio cloud; un paese sconosciuto può giustificare una verifica, ma senza il contesto relativo a orario, dispositivo e provider non costituisce ancora un incidente.

Activity Log

Activity Log mostra l’attività di autenticazione per l’intervallo selezionato in alto a destra. Total Activities, Successful Logins e Failed Logins forniscono innanzitutto il volume. Per la valutazione geografica, Top sign-in locations mostra paesi, indirizzi IP, conteggio e distribuzione tra IP pubblici e privati. Authentication locations integra le autenticazioni più frequenti degli ultimi 30 giorni in base a indirizzo IP e ASN, oltre a una ricerca per località, IP o ASN. L’andamento temporale è rappresentato da Logins per day, con accessi riusciti e non riusciti separati, e da Activity map, sotto forma di heatmap per giorno della settimana e ora del giorno.

Questa vista ITDR riassume dati aggregati e schemi ricorrenti. Non mostra una tabella degli eventi in cui tutte queste informazioni compaiano affiancate per ogni accesso. Browser, Asset Name e OS Version devono invece essere valutati come dati aggregati del profilo delle autenticazioni riuscite negli ultimi 30 giorni in Summary > Commonly Used Entities e non devono essere attribuiti a una singola voce di Activity Log. Per correlare un evento con data, ora e fuso orario esatti, esito, IP di origine, ASN, paese, dispositivo, browser, sistema operativo o Detections adiacenti, occorre consultare i log eventi Entra o XDR disponibili. I frequenti tentativi non riusciti presenti nei dati aggregati ITDR possono dipendere da errori dell’utente, credenziali obsolete o un attacco; soltanto la correlazione con le evidenze degli eventi consente di stabilirlo.

Findings, Insights, Group Membership e Dark Web Intelligence

Findings elenca i Findings dell’identità in base al rischio. Il testo completo in Recommendation appare al passaggio del mouse; facendo clic sul nome del Finding si aprono i relativi dettagli. Occorre verificare stato, rischio, categoria, evidenze interessate e rimedio consigliato. La modifica manuale di uno stato non equivale alla correzione tecnica presso il provider.

Insights mostra per impostazione predefinita le Open Detections degli ultimi sette giorni; l’intervallo può essere modificato tramite il Date Picker. Closed Detections copre gli ultimi 30 giorni. L’assenza di risultati nell’intervallo predefinito, pertanto, non esclude attività meno recenti.

Group Membership elenca i gruppi dell’utente. Il campo di ricerca restringe l’elenco; facendo clic su Group Name si apre il gruppo con gli altri membri. Sono particolarmente rilevanti le appartenenze privilegiate, assegnabili a ruoli, annidate, inattese o non più necessarie per l’attività aziendale. Le modifiche vengono eseguite nel provider autorevole.

Dark Web Intelligence mostra i record relativi a fughe di dati associati all’identità. Tramite Breach Source si apre il relativo record. Un record documenta l’esposizione di credenziali. Per valutarlo, occorre considerare congiuntamente la data della fuga, il contesto della pubblicazione o della violazione, lo stato dell’account e l’ultima modifica della password. Il record non prova automaticamente che le credenziali attualmente utilizzate siano valide né che si sia verificato un accesso.

Considerare i limiti dei provider e i tempi di aggiornamento

Sophos ITDR supporta Microsoft Entra ID e Active Directory locale, ma non tutti i provider forniscono gli stessi oggetti e campi. I dati specifici del cloud, quali asset Intune, Service Principals Entra, metodi MFA o attività di accesso Entra, possono mancare in un’integrazione esclusivamente con AD locale. Viceversa, il sensore ITDR locale acquisisce ulteriori tipi di oggetti AD per le verifiche della postura di sicurezza; ciò non rende automaticamente completi i tab cloud.

Dopo l’acquisizione completa iniziale di Entra, ITDR verifica gli aggiornamenti a intervalli diversi a seconda del tipo di dati: dettagli relativi a utenti, Service Principals, app, gruppi e dispositivi all’incirca ogni dieci minuti, configurazione MFA all’incirca ogni 15 minuti, ultimo accesso dell’utente all’incirca ogni sei ore e dati di dominio all’incirca ogni 24 ore. Si tratta di intervalli di acquisizione e non della garanzia che Microsoft abbia già reso disponibili tramite API le informazioni modificate alla fonte.

Per l’ambito dati ITDR previsto è necessaria una licenza Entra ID P1 o P2. Con Entra ID Free, le API e le verifiche della postura di sicurezza sono limitate; un’integrazione può quindi mostrare Provisioning Failed. Dopo un upgrade della licenza, le informazioni relative ad amministratori o MFA possono rimanere obsolete presso Microsoft per un massimo di una settimana. In tal caso, verificare innanzitutto il relativo report attività di Microsoft Entra. Se già la visualizzazione del provider non risulta aggiornata, ITDR non può ancora mostrare uno stato più recente.

Anche l’MFA di terze parti in una configurazione Okta o Duo meno recente può apparire come non protetta, perché Entra non memorizza le informazioni MFA a livello di utente. In questo caso, una visualizzazione Has MFA = false non deve essere considerata isolatamente come prova dell’assenza di un controllo MFA. La configurazione del provider, Conditional Access, gli attuali External Authentication Methods e un test di accesso controllato devono fornire risultati coerenti.

Convalida e risoluzione dei problemi

L’oggetto manca o compare nel tab errato

1. Reimpostare la ricerca e i filtri attivi e verificare l’ortografia e i nomi visualizzati alternativi.
2. Controllare se Identities, Groups, Devices o Apps corrisponde al tipo di oggetto corretto.
3. Confermare il tenant e il provider di identità autorevole; per le app, distinguere Application Object, Service Principal, App/Client ID e Object ID.
4. Cercare l’oggetto direttamente presso il provider e verificarne stato, eliminazione e contesto Guest, Cloud, Hybrid o Service.
5. Controllare lo stato e l’ultima acquisizione riuscita nelle impostazioni dell’integrazione ITDR. Non riavviare Central Directory Sync come soluzione alternativa.
6. Ripetere la verifica soltanto dopo l’intervallo di acquisizione specifico per il tipo di dati e documentare le date e gli orari.

Un filtro o un campo MFA, amministratore o dispositivo è vuoto o inatteso

• Rimuovere i filtri e verificare l’attributo non elaborato presso il provider.
• Controllare la licenza Entra, la disponibilità delle API e lo stato dell’integrazione.
• Per l’MFA, verificare inoltre il provider, il metodo primario, gli altri metodi e la configurazione di terze parti.
• Per i dispositivi, distinguere registrazione o join, gestione Intune, conformità e protezione Sophos Endpoint.
• Dopo modifiche alla licenza o agli attributi, convalidare innanzitutto la visualizzazione aggiornata del provider e non soltanto ITDR.
• Documentare «vuoto», No data o un tag assente come sconosciuto, non come «no».

La località di accesso o lo schema di attività sembra sospetto

In Activity Log, confrontare innanzitutto l’intervallo temporale, il volume degli accessi, i dati aggregati di successi e insuccessi, i paesi, gli indirizzi IP, gli ASN e gli schemi relativi a giorno e ora. In Top Sign-in Locations è possibile utilizzare IP type e Login outcome come filtri.

Valutare separatamente Browser, Asset Name e OS Version in Commonly Used Entities come dati aggregati su 30 giorni. Correlare quindi nei log eventi Entra o XDR disponibili l’ora esatta dell’evento con il relativo fuso orario, nonché esito, dispositivo, browser e sistema operativo di un singolo accesso. Verificare anche i Findings e gli Insights associati.

NAT, VPN, reti mobili, egress cloud e viaggi possono modificare la località visualizzata. In presenza di un rischio confermato, eseguire le misure di risposta esclusivamente in conformità alla procedura interna di gestione degli incidenti e con le autorizzazioni necessarie.

Verificare la visualizzazione dopo una correzione

Confermare innanzitutto la modifica tecnica nel sistema autorevole. Attendere quindi il momento di acquisizione ITDR previsto, reimpostare i filtri e riaprire la stessa identità o lo stesso oggetto. Verificare il campo corretto, i tag dipendenti, i Findings associati e l’intervallo di indagine pertinente. Risk Score, Findings e attributi del provider possono avere cicli di aggiornamento diversi; uno score ancora invariato non smentisce la riuscita modifica alla fonte. Se la visualizzazione rimane errata oltre l’intervallo previsto, acquisire come materiale per l’escalation la prova fornita dal provider, il tenant, l’Object ID, l’ora della modifica, lo stato dell’integrazione e gli screenshot.

Concludere l’indagine in modo tracciabile

Al termine, documentare oggetto, tenant, provider e tipo di identità. Registrare inoltre la ricerca e i filtri utilizzati, l’intervallo dell’indagine, le aree di dettaglio verificate, i dati mancanti del provider e i risultati della convalida nel sistema autorevole e in ITDR. Mantenere distinti il contesto Human e NHI, così come Application Object e Service Principal.