Domande frequenti sui sistemi ITDR

È supportato Microsoft Entra ID.

Sì, è possibile aggiungere più tenant di Entra ID dalla pagina Impostazioni di identità. Per maggiori informazioni, vedere Impostazioni di identità.

ITDR richiede Entra ID P1 o P2, che sono disponibili in prodotti autonomi e add-on, o che sono inclusi con altre licenze Microsoft come Microsoft 365 E3 ed E5, Microsoft Business Premium e Microsoft 365 Frontline Worker F1, F3 e F5. Microsoft Entra ID Free fornisce accesso alle API di Microsoft, ma limita alcuni dei dati che possono essere acquisiti e alcuni controlli del profilo di rischio che possono essere eseguiti.

ITDR utilizza le API di Microsoft per raccogliere informazioni sugli account. Microsoft limita anche l’accesso ad alcune API in base alle licenze, quindi informazioni come il ruolo di un utente (amministratore o meno) o lo stato di registrazione per la MFA potrebbero non essere visualizzate immediatamente dopo un upgrade della licenza. Potrebbe volerci fino a una settimana prima che Microsoft fornisca le informazioni aggiornate sugli utenti, dopo che un cliente ha effettuato l’upgrade della licenza. È possibile verificare le informazioni visualizzando il report sulle attività nell’Interfaccia di amministrazione di Microsoft Entra. Per maggiori informazioni, vedere Attività dei metodi di autenticazione. Se le informazioni contenute nel report dell’utente non sono aggiornate, anche ITDR risulterà non aggiornato finché Microsoft non aggiornerà le informazioni.

Alcune possibili cause potrebbero essere le seguenti:

• Non è presente la licenza Microsoft Entra ID richiesta, ad es. P1 o P2.
• Recentemente è stato eseguito l’upgrade della propria licenza, e Microsoft non ha ancora reso disponibili i dati. Per informazioni dettagliate, vedere “Quanto tempo ci vuole per l’aggiornamento di ITDR dopo l’upgrade da Entra ID Free a una licenza P1 o P2?”

• Si sta utilizzando un provider di MFA di terze parti come Okta o Duo con una configurazione obsoleta. In questo scenario, lo stato di MFA non verrà segnalato correttamente, perché Microsoft Entra ID non memorizza le informazioni sulla MFA a livello utente per i provider di MFA esterni. Tuttavia, possiamo dedurre che viene utilizzato un provider esterno se si utilizzano i nuovi metodi di autenticazione esterna di Microsoft all’interno della propria configurazione del tenant di Entra ID.

  Per maggiori informazioni, vedere il Blog di Microsoft Entra. Sono disponibili ulteriori dettagli di configurazione per Duo e Okta. Per maggiori informazioni, consultare la documentazione di Duo e la documentazione di Okta.

ITDR include una serie di valutazioni, ciascuna delle quali esegue controlli diversi, che vengono svolti ai seguenti intervalli:

• Controlli del profilo di rischio di Entra ID: ogni 2 ore.
• Controlli delle risorse inattive: ogni 2 ore.

Subito dopo la configurazione iniziale, raccogliamo l’intero catalogo di dati da Microsoft Entra ID. Successivamente, controlliamo la presenza di aggiornamenti in base al tipo di dati, come indicato di seguito:

• Dettagli utente: ogni 10 minuti.
• Dettagli di entità servizio e applicazioni: ogni 10 minuti.
• Gruppi: ogni 10 minuti.
• Dispositivi: ogni 10 minuti.
• Configurazione della MFA per gli utenti: ogni 15 minuti.
• Attività utente (ultimo accesso): ogni 6 ore.
• Dati del dominio: ogni 24 ore.

Il punteggio del Profilo di rischio di identità viene aggiornato quotidianamente in base ai cambiamenti rispetto al giorno precedente. Il punteggio aumenta o diminuisce a seconda che siano stati rilevati nuovi risultati delle analisi, o che i risultati esistenti siano stati risolti o ignorati.

È possibile visualizzare l’elenco dei controlli nella scheda Preferenze per i controlli del profilo di rischio della pagina Impostazioni di identità. Per maggiori informazioni, vedere Impostazioni di identità.

Sì, è possibile attivare e disattivare i controlli del profilo di rischio nella scheda Preferenze per i controlli del profilo di rischio della pagina Impostazioni di identità. Per maggiori informazioni, vedere Impostazioni di identità.

No, ITDR è un software da monitorare. Tuttavia, se si utilizza il servizio MDR, il team MDR Operations svolgerà indagini sulle minacce basate sull’identità, oltre a monitorare gli altri elementi inclusi nel servizio.

Il team MDR Operations si concentra principalmente sulle minacce di identità attive ed esamina un sottoinsieme di risultati critici o ad alta priorità che potrebbero indicare la presenza di una minaccia attiva. Tuttavia, la responsabilità di monitorare e gestire i risultati spetta all’utente.

Il team Operazioni MDR Operations utilizza il contesto aggiuntivo sulle identità raccolto da Microsoft Entra ID per comprendere meglio gli utenti e i rischi associati. Questo accelera i processi di indagine e risposta sia per i rilevamenti che riguardano le identità, sia per gli altri rilevamenti correlati all’utente.

Il flag amministratore in Entra ID è impostato su "vero” per gli utenti assegnati a ruoli che vengono riconosciuti come ruoli di amministrazione o con privilegi all’interno di Entra ID. Questi ruoli hanno generalmente un controllo significativo sulle risorse della directory, sugli utenti o sulle impostazioni di sicurezza. Quello che segue è un elenco dei ruoli di Entra ID che impostano il flag amministratore su “vero”:

• Amministratore globale: accesso completo a tutte le funzionalità di amministrazione in Entra ID.
• Amministratore ruolo con privilegi: gestisce l’assegnazione dei ruoli in Entra ID, inclusa l’assegnazione di altri amministratori.
• Amministratore utenti: gestisce account utente, gruppi e alcuni attributi utente.
• Amministratore della sicurezza: ha pieno accesso a tutte le funzionalità e le impostazioni di sicurezza.
• Amministratore conformità: gestisce funzionalità relative alla conformità come eDiscovery e i controlli.
• Amministratore dell’applicazione: gestisce le registrazioni e le impostazioni delle applicazioni in Entra ID.
• Amministratore autenticazione: è in grado di visualizzare, impostare e ripristinare metodi di autenticazione e controlli, incluse le reimpostazioni delle password.
• Amministratore di Exchange: gestisce le impostazioni per Microsoft Exchange Online.
• Amministratore di SharePoint: gestisce le impostazioni per SharePoint Online.
• Amministratore di Teams: gestisce le impostazioni per Microsoft Teams.
• Amministratore di Intune: gestisce le impostazioni e le configurazioni della gestione dei dispositivi in Microsoft Intune.
• Amministratore fatturazione: gestisce sottoscrizioni, fatturazione e ticket di supporto.
• Amministratore supporto tecnico: ruolo limitato alla reimpostazione delle password e alla risoluzione di problemi di base.
• Amministratore servizio di supporto: gestisce le impostazioni relative al supporto dei servizi.
• Lettori di directory (se abbinato ad altri ruoli con privilegi): sono in grado di leggere informazioni sulla directory; di solito vengono abbinati a un altro ruolo per elevare i privilegi.
• Lettore globale (se abbinato a un altro ruolo di amministrazione): accesso in sola lettura a tutti i servizi Entra ID e Microsoft; è in grado di impostare il flag amministratore su "vero” quando viene abbinato a un altro ruolo di amministrazione.
• Lettore report (se abbinato a un altro ruolo di amministrazione): accesso a report e log, spesso abbinato ad altre responsabilità amministrative.
• Amministratore dell’accesso condizionale: gestisce i criteri di accesso condizionale.
• Amministratore di Identity Governance: gestisce le impostazioni relative alla governance dell’identità, alle revisioni degli accessi e alla gestione dei diritti.
• Ruoli personalizzati con privilegi di amministrazione: ruoli personalizzati con autorizzazioni amministrative paragonabili a quelle dei ruoli di cui sopra, sono anche in grado di impostare il flag amministratore su “vero”.

Questo elenco include i ruoli standard in Entra ID che hanno un impatto sul flag amministratore. Tuttavia, se Microsoft aggiorna questi ruoli o ne aggiunge di nuovi, il comportamento del flag amministratore potrebbe cambiare per rifletterli.

Se l’ultimo accesso è avvenuto più di 90 giorni fa, contrassegniamo un utente come inattivo.

Svolgiamo controlli continui per individuare un’eventuale fuga di credenziali e non appena viene riscontrata una corrispondenza all’interno del set di dati, la elaboriamo e determiniamo se è valida.

Per garantire la generazione di risultati pratici, seguiamo questi passaggi di elaborazione per mettere in correlazione e convalidare i dati che raccogliamo e analizziamo:

1. Verifica dell’esistenza un’identità attiva all’interno dei provider di identità configurati.
2. Individuazione del momento in cui è avvenuta la fuga della password non crittografata o dell’hash per la prima volta, in base allo storico dei dati disponibili. Questo è importante perché spesso gli elenchi combinati appena pubblicati contengono dati obsoleti, relativi a violazioni passate.
3. Se si tratta di un valore della password non crittografato, confrontiamo questo valore con i requisiti globali di complessità della password di Microsoft Entra ID, per eliminare i valori non validi.
4. Infine, confrontiamo la data in cui è avvenuta la fuga della password per la prima volta con il momento dell’ultima modifica della password per l’identità. Se la prima fuga di dati è avvenuta dopo l’ultima modifica della password, generiamo un risultato.

Se abbiamo determinato che deve essere generato un risultato, controlliamo l’account associato per verificare se la MFA è abilitata e, se sì, con quale livello di sicurezza. Ecco i livelli di rischio associati, in base al tipo di utente, al tipo di fuga di dati e alla configurazione della MFA:

No, non memorizziamo alcun valore hash o password non crittografata. Inoltre, non abbiamo la capacità di acquisire queste informazioni dai provider di identità. Quando effettuiamo la scansione e la raccolta dei dati, applichiamo un hash personalizzato ai valori osservati e successivamente categorizziamo il record come password non crittografata o con hash. Questo ci consente di determinare l’unicità delle password e calcolare metriche senza dover conservare i valori sottostanti delle password.

Utilizziamo dati provenienti da vari mercati del dark web, come il marketplace russo e Genesis, i siti di TOR, i canali Telegram pubblici e nascosti, e file di log degli stealer.