Valutare in sicurezza l'Identity Risk Score di Sophos ITDR

L’Identity Risk Score valuta il rischio di una singola identità utente su una scala da 0 a 10. Combina la probabilità di un incidente di sicurezza con il potenziale impatto di un’identità compromessa. Un valore elevato è quindi un segnale di priorità, ma non dimostra una compromissione e non costituisce un’istruzione automatica a intervenire.

Per il triage quotidiano, ordinare le identità per Risk Score decrescente, esaminare i Contributing factors di quelle ai primi posti e affrontare innanzitutto i finding critici o alti ancora aperti e i Security Factors direttamente controllabili. Il solo valore numerico non basta per prendere una decisione fondata.

Dove trovare il Risk Score

Sophos ITDR mostra il valore in tre punti:

• In My Products > Identity > Directory > Identities, la tabella contiene la colonna Risk Score. Nella vista a schede, il valore appare in alto a destra su ogni scheda.
• Dopo aver selezionato un’identità, Identity Details > Summary mostra il pannello Risk Score con Current score, Contributing factors e l’ora dell’ultimo calcolo.
• In My Products > Identity > Identity Overview, il widget Top 5 Risky Users combina punteggi elevati e finding aperti. Ogni voce mostra il nome dell’identità, i finding aperti suddivisi per gravità e il punteggio attuale.

Per una verifica completa, usare Directory > Identities > Identity Details > Summary. Il widget della panoramica aiuta a stabilire rapidamente le priorità, ma non sostituisce la vista di dettaglio.

Interpretare correttamente le cinque fasce

I limiti delle fasce sono fissi, ma la ponderazione dei fattori non lo è. Non è quindi possibile calcolare un punteggio esatto da un elenco di attributi. Due utenti con la stessa funzione possono avere valori diversi a causa dello stato MFA, dei ruoli amministrativi, dello stato di guest, dei finding, della posizione di accesso o delle precedenti attività di allerta e indagine.

Anche un punteggio basso non garantisce la sicurezza. Riflette soltanto il modo in cui il modello valuta i segnali attualmente disponibili. Telemetria mancante, una baseline non ancora completa o un finding scoperto in seguito possono modificare la classificazione.

Quali identità ricevono un punteggio

Attualmente i Risk Score vengono calcolati per le identità utente Active provenienti da Microsoft Entra ID e Active Directory locale. Le identità con stato Deleted o Disabled presso l’identity provider non mostrano alcun Risk Score. Il punteggio esclude inoltre le identità di applicazioni e service principal.

Questo ambito è importante nei confronti: un’identità senza valore non è automaticamente a basso rischio. Verificarne prima il tipo e lo stato nell’identity provider collegato. Un valore assente è un’indicazione diagnostica solo se si tratta di un’identità utente attiva.

Distinguere Security Factors e Profile Factors

Il pannello Contributing factors distingue due tipi di effetto:

• Factors raising Risk Score mostra i fattori che aumentano il valore attuale.
• Factors lowering Risk Score mostra i fattori che lo riducono.

In entrambi i gruppi, Sophos distingue tra Security Factors e Profile Factors.

Security Factors: intervenire prima qui

I Security Factors descrivono lo stato di sicurezza, la configurazione e l’attività nota. Tra quelli direttamente modificabili rientrano:

• MFA assente;
• MFA senza un metodo passwordless;
• finding aperti, indicati nel pannello come Identity Exposures;
• ruoli di directory amministrativi o privilegiati;
• stato di guest;
• fughe di credenziali attive;
• un numero elevato di indirizzi e-mail collegati.

Altri segnali comprendono un account ibrido sincronizzato da una directory locale e lo storico di allerte e indagini. Nessuno dei due può essere eliminato con una singola modifica all’identità: lo stato ibrido descrive l’architettura della directory, mentre lo storico riflette allerte e indagini precedenti.

Tra i fattori che riducono il punteggio vi sono MFA applicata, un metodo MFA passwordless, uno storico privo di allerte o indagini rilevanti, finding corretti o contrassegnati come Dismissed, la rimozione di ruoli amministrativi superflui e un minor numero di indirizzi e-mail collegati. Il modello pondera questi segnali; l’elenco non è una tabella di punti cumulativi.

Profile Factors: contesto, non obiettivo di correzione

I Profile Factors riguardano gli attributi dell’identità, ad esempio:

• Department;
• Job Title;
• City;
• Employee Type;
• presenza o assenza di un manager;
• monitoraggio VIP, visibile nel pannello come High-value identity, prioritize monitoring.

Queste caratteristiche possono aumentare o ridurre il punteggio, ma di norma non costituiscono errori di configurazione della sicurezza. Reparto, funzione o posizione non devono essere modificati solo per abbassare un numero. È corretto aggiornare dati anagrafici errati o obsoleti; i dati di profilo corretti devono rimanere e fungono da contesto di rischio.

Campi vuoti come Department, Employee Type o Job Title non sono necessariamente neutri. Il modello può considerare le informazioni mancanti confrontandole con identità simili e ricavarne un contesto di rischio. Dati di directory completi e corretti forniscono quindi un contesto più preciso, ma non garantiscono un punteggio specifico né la direzione della variazione.

Secondo Sophos, fughe di credenziali attive, stato ibrido e monitoraggio VIP possono aumentare il punteggio, ma non contribuiscono a ridurlo. Ciò non significa che il monitoraggio VIP debba essere rimosso: l’etichetta rende deliberatamente più visibile un’identità importante e non va eliminata per migliorare il punteggio solo in apparenza.

Che cosa significa No data

Se una sezione del pannello Risk Score mostra No data, in quella specifica categoria non è elencato alcun fattore. Non significa automaticamente che manchino tutti i dati dell’identità o che l’integrazione non funzioni.

Verificare nell’ordine:

1. No data compare solo in una sottosezione, ad esempio nei Profile Factors che riducono il punteggio?
2. Negli altri gruppi sono presenti fattori?
3. L’ora dell’ultimo calcolo in fondo al pannello è plausibile?
4. Si tratta di un’identità utente attiva?
5. Gli attributi di directory e i finding attesi sono presenti nelle rispettive posizioni?

Controllare la fornitura dei dati dell’integrazione solo se mancano più aree previste, l’ora del calcolo non è plausibile o un’identità utente attiva non riceve alcun punteggio.

Considerare baseline e cicli di calcolo

Per un nuovo tenant o una nuova identità utente, ITDR crea innanzitutto un profilo comportamentale. Molte nuove identità possono quindi rimanere nella fascia Informational fino a 30 giorni. Si tratta di una possibile fase di creazione della baseline, non di un periodo nel quale ignorare i finding: un finding aperto può produrre un punteggio più alto anche per una nuova identità.

I punteggi vengono sottoposti a un ciclo di valutazione giornaliero. Può avvenire un nuovo calcolo anche quando ITDR rileva una modifica dell’account o di un finding. Il punteggio può cambiare da un giorno all’altro senza modifiche visibili alla directory, perché il modello include lo storico di allerte e indagini e ne adegua la ponderazione nel tempo.

Dopo la correzione di un finding, può comparire rapidamente un valore aggiornato. I finding corretti continuano a influire con peso ridotto fino al ciclo giornaliero successivo; l’effetto completo è quindi visibile solo nel punteggio del giorno seguente. Da questi meccanismi non si può dedurre né un’ora di aggiornamento garantita né una variazione esatta e prevedibile dei punti.

Limiti del modello ML

Il Risk Score deriva da un modello di machine learning, non da una lista di controllo fissa. I fattori non hanno tutti lo stesso peso; pertanto, gli stessi fattori visibili non producono necessariamente lo stesso punteggio o la stessa variazione per due identità.

Secondo Sophos, il modello viene addestrato su segnali aggregati relativi al comportamento e agli account della clientela ITDR; il punteggio di un’identità viene calcolato con i dati attuali del proprio tenant. Restano tuttavia limiti operativi chiari:

• Il punteggio indica la priorità, non la causa di un incidente. Per stabilirla servono finding e ulteriori risultati delle indagini.
• Un valore elevato non dimostra una compromissione. Un’identità privilegiata con una postura debole può risultare ad alto rischio anche senza attività sospette osservate.
• Un valore basso non dimostra l’assenza di rischi.
• I fattori visualizzati sono la spiegazione operativa per l’identità, non una formula con cui riprodurre il valore numerico.
• Una variazione del punteggio non dimostra da sola che un intervento sia riuscito tecnicamente.

L’approccio sicuro consiste quindi nel leggere la causa nel pannello, verificare separatamente la configurazione o il finding sottostante e solo dopo usare il punteggio come ulteriore indicatore dell’effetto.

Stabilire le priorità in sicurezza

Ordinare esclusivamente in base al valore più alto può far perdere informazioni di contesto importanti. Procedere come segue:

1. In Directory > Identities, ordinare per Risk Score decrescente.
2. Aprire Identity Details > Summary per le identità ai primi posti.
3. In Contributing factors, verificare la presenza di Identity Exposures critiche o alte ancora aperte.
4. Dare priorità ai finding critici e alti e alle fughe di credenziali attive rispetto al solo contesto del profilo.
5. A parità di urgenza, esaminare prima le identità privilegiate, amministrative e monitorate come VIP per il loro possibile impatto.
6. Per ogni intervento, registrare valore iniziale, fascia, timestamp e specifico fattore di aumento.
7. Correggere soltanto la causa sottostante, senza ottimizzare il punteggio in modo cosmetico.

Tra le misure sicure tipiche rientrano la correzione alla radice dei finding critici e alti, l’applicazione di MFA e, ove possibile, la disponibilità di un metodo MFA passwordless. Gestire le fughe di credenziali attive tramite il processo approvato per gli incidenti. Revocare i ruoli amministrativi superflui ed eliminare gli indirizzi e-mail collegati non più necessari; se opportuno, convertire gli account guest in account gestiti. Ogni modifica richiede le consuete approvazioni dell’organizzazione e una verifica funzionale separata.

Convalidare l’effetto dopo un intervento

Una verifica affidabile separa l’efficacia tecnica dalla risposta del modello:

1. Registrare lo stato iniziale: Annotare identità, Current score, fascia, Factors raising Risk Score, finding aperti e timestamp dell’ultimo calcolo.
2. Correggere la causa: Ad esempio, applicare realmente MFA nell’identity provider o rimuovere un ruolo superfluo dopo l’approvazione. Per mantenere tracciabile l’effetto, non modificare contemporaneamente più fattori indipendenti.
3. Verificare lo stato tecnico: Controllare nel sistema competente che la modifica sia effettiva. Il Risk Score non è la prova principale.
4. Verificare i dati ITDR: In Identity Details > Summary, confermare che il fattore o il finding sia visualizzato correttamente dopo l’elaborazione.
5. Attendere il nuovo calcolo: Controllare il timestamp in fondo al pannello. Dopo aver corretto un finding, verificare l’aggiornamento a breve termine e attendere il ciclo giornaliero successivo per valutarne l’effetto completo.
6. Confrontare il risultato: Confrontare punteggio, fascia e fattori con lo stato iniziale. Attendersi una rappresentazione coerente della causa corretta, non un punteggio prestabilito.
7. Affrontare le cause restanti: Se il valore rimane alto, esaminare gli altri Security Factors, i finding aperti e infine il contesto del profilo.

La convalida è completa quando sono confermati tre punti: la misura tecnica è efficace, ITDR mostra correttamente il fattore sottostante e il calcolo successivo è plausibile rispetto ai segnali rimanenti.

Risolvere i problemi relativi a punteggi inattesi

Il punteggio aumenta improvvisamente

Aprire prima la vista dettagliata e cercare in Factors raising Risk Score nuove Identity Exposures, soprattutto finding critici o alti. Confrontare poi MFA, ruoli, stato di guest, fughe di credenziali e ora del calcolo. Un aumento non dimostra un incidente, ma una fascia critica o alta richiede un’indagine tempestiva.

Il punteggio non diminuisce come previsto dopo l’intervento

Verificare che la modifica sia effettiva nell’identity provider competente e che ITDR mostri già il fattore aggiornato. Un finding corretto può mantenere un peso residuo ridotto fino al ciclo giornaliero successivo. Se il punteggio resta elevato, esaminare gli altri fattori; non attendersi una riduzione fissa dei punti per un singolo intervento.

Il punteggio cambia senza modifiche alla directory

Non è necessariamente un errore. Il ricalcolo giornaliero e l’aggiunta o l’invecchiamento delle attività di allerta e indagine possono modificare il valore. Documentare punteggio precedente e nuovo, entrambi gli orari di calcolo e i fattori visualizzati. Esaminare ulteriormente l’integrazione solo in presenza di dati contraddittori o di un timestamp non plausibile.

Un’identità utente attiva non ha un punteggio

Confermare prima nell’identity provider lo stato Active, il tipo User e l’assegnazione all’origine Entra ID o Active Directory collegata. Verificare poi se in ITDR compaiono altri attributi aggiornati della stessa identità. Deleted, Disabled, applicazioni e service principal non rientrano nell’ambito attuale del punteggio.

Molte nuove identità rimangono Informational

Controllare la data di onboarding e i finding aperti. Durante la possibile fase di baseline, che può durare fino a 30 giorni, questo comportamento può essere normale; i finding aperti devono comunque essere affrontati subito. Se molte identità rimangono nella fascia Informational dopo 30 giorni, controllare ora del calcolo, fattori visualizzati e aggiornamento dei dati per determinare se ITDR elabora i segnali previsti.

Se non è possibile spiegare uno stato inatteso, registrare l’identificativo dell’identità senza dati personali aggiuntivi non necessari, origine, stato, punteggio, fascia, fattori visibili, ora del calcolo, ID dei finding pertinenti e ora dell’ultima modifica approvata. Queste informazioni consentono un’escalation mirata senza dedurre dal punteggio stesso una causa non dimostrata.