Strategia ITDR per ISO 27001, NIS2, DORA e GDPR

Alle 3:00 di un martedì mattina, Sarah, CISO di FinScale, si è svegliata per un allarme del tipo che i responsabili della sicurezza temono sempre di più. La sessione attiva di uno sviluppatore senior, autenticata con MFA solo poche ore prima, veniva utilizzata da una sorgente insolita per enumerare gli schemi dei database di produzione.

Nessun beacon malware. Nessuna richiesta di riscatto. Nessun exploit del firewall. Solo identità.

Il SOC ha intercettato l’attività, ma la risposta è stata disordinata. Si trattava di bypass della MFA, di un token di sessione rubato o di una compromissione dello stesso provider di identità? Chi aveva l’autorità per chiudere la sessione attiva? Revocare la password era sufficiente oppure il team doveva invalidare i token di refresh, ruotare le credenziali API e riesaminare le concessioni OAuth? Quando l’attività è stata contenuta, l’attaccante era rimasto attivo per 47 minuti.

La mattina successiva, l’incidente di sicurezza è diventato un problema di governance. Il consiglio di amministrazione voleva una spiegazione in linguaggio chiaro per capire se l’igiene informatica di FinScale fosse risultata carente ai sensi di NIS2. Il team di compliance voleva sapere se l’evento potesse essere classificato come grave incidente ICT ai sensi di DORA. La funzione legale aveva bisogno di una risposta sostenibile sulla possibilità che dati personali fossero stati consultati ai sensi di GDPR Article 32 e sulla necessità di una valutazione della violazione dei dati personali. L’auditor esterno ha chiesto se i controlli ISO/IEC 27001:2022 fossero effettivamente operativi, e non solo documentati nelle politiche.

Il problema di Sarah non era la mancanza di strumenti. FinScale disponeva di un provider di identità, MFA, un SIEM, controlli endpoint, log cloud e un processo di risposta agli incidenti. Il problema era che gestione delle identità, registrazione, monitoraggio, risposta agli incidenti, valutazione privacy e gestione delle evidenze operavano in silos.

Questo è il problema dell’Identity Threat Detection and Response nel 2026. L’ITDR non è più solo una capacità delle operazioni di sicurezza. È un motore di evidenze trasversale per la conformità a ISO/IEC 27001:2022, NIS2, DORA e GDPR Article 32.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, la suite di politiche Clarysec e Zenith Controls: The Cross-Compliance Guide Zenith Controls aiutano le organizzazioni a trasformare gli attacchi basati sull’identità da indagini caotiche in processi di controllo ripetibili e verificabili.

Perché l’Identity Threat Detection and Response è ora una questione da consiglio di amministrazione

Gli attacchi basati sull’identità funzionano perché abusano di percorsi di accesso legittimi. Un attaccante che ruba un token di sessione, registra un’applicazione OAuth malevola, compromette un account di servizio o sfrutta la MFA push fatigue può apparire come un utente valido ai sistemi che verificano solo l’esito positivo dell’autenticazione.

Questo rende l’ITDR diverso dalla difesa perimetrale tradizionale. Un programma maturo deve poter rispondere a queste domande:

• Quali identità umane, di servizio, di fornitore e applicative esistono?
• Quali identità sono privilegiate, inattive, condivise o federate esternamente?
• Quali eventi di autenticazione sono normali, rischiosi o impossibili?
• Quali concessioni OAuth, token SaaS e credenziali API possono accedere a dati sensibili?
• Quali allarmi attivano la classificazione dell’incidente, la conservazione delle evidenze e il processo decisionale regolatorio?
• Quali controlli dimostrano che l’accesso ai dati personali è protetto mediante misure tecniche e organizzative adeguate?

NIS2 rende questo tema una questione di governance. Article 20 richiede agli organi di gestione delle entità essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, valutazione dell’efficacia dei controlli, igiene informatica, formazione, controllo degli accessi, gestione degli asset e autenticazione a più fattori o continua, ove appropriato.

DORA esercita una pressione analoga sugli enti finanziari. Richiede un quadro documentato per la gestione del rischio ICT, la responsabilità dell’organo di gestione, meccanismi di rilevamento, gestione degli incidenti, classificazione, segnalazione, test di resilienza e gestione del rischio ICT di terze parti. DORA si applica dal 17 gennaio 2025. Per gli enti finanziari identificati anche ai sensi di NIS2, DORA opera come disciplina settoriale specifica per gli obblighi ICT e di incident reporting sovrapposti.

GDPR aggiunge il livello di accountability privacy. Article 5 richiede integrità, riservatezza e responsabilizzazione. Article 4 definisce in senso ampio la violazione dei dati personali, includendo l’accesso non autorizzato ai dati personali. Article 32 richiede misure tecniche e organizzative adeguate per garantire un livello di sicurezza commisurato al rischio. Negli incidenti basati sull’identità, log, controlli di accesso, registrazioni di autenticazione ed evidenze dell’incidente diventano centrali per dimostrare se i dati personali fossero protetti.

ISO/IEC 27001:2022 è il sistema di gestione che può tenere insieme questi obblighi. La clausola 4 richiede all’organizzazione di comprendere il proprio contesto, le parti interessate e i requisiti legali, normativi e contrattuali. La clausola 6 richiede valutazione del rischio, trattamento del rischio, approvazione da parte del titolare del rischio ed evidenze conservate. L’Annex A include controlli per gestione delle identità, autenticazione sicura, registrazione, monitoraggio, gestione degli incidenti, raccolta delle evidenze, rapporti con i fornitori, servizi cloud e tutela della privacy.

L’ITDR deve stare all’interno del SGSI perché il rischio legato all’identità diventa verificabile solo quando è incluso nell’ambito, assegnato a un titolare, valutato, trattato, monitorato e migliorato.

Lo scenario di attacco basato sull’identità che interessa ai regolatori

Consideriamo un fornitore cloud di workflow finanziari che serve clienti nell’UE. Utilizza Microsoft 365, una piattaforma SaaS di assistenza clienti, infrastruttura cloud, un fornitore di servizi di pagamento e varie integrazioni basate su API. Un tecnico senior dell’assistenza riceve una richiesta convincente per riconnettere un’applicazione di produttività. La schermata di consenso OAuth richiede accesso in lettura alla casella di posta e accesso offline. Il tecnico approva.

Nel giro di pochi minuti, l’attaccante usa il token per cercare identificativi dei clienti e allegati dell’assistenza. Enumera le appartenenze ai gruppi e tenta l’accesso a un portale di amministrazione. La MFA era abilitata, ma l’attaccante non ha più bisogno della password perché il token concede accesso persistente. Il SOC rileva accessi insoliti alla casella di posta, una nuova applicazione OAuth, tentativi falliti verso il portale di amministrazione e attività da una geografia insolita.

Questo singolo scenario attraversa più domini di controllo:

• Ciclo di vita dell’identità, perché il ruolo e le autorizzazioni dell’utente determinano il raggio d’impatto.
• Autenticazione sicura, perché la sola MFA non ha impedito l’abuso del token.
• Registrazione e monitoraggio, perché il rilevamento dipende dai log del provider di identità, del SaaS e delle applicazioni.
• Risposta agli incidenti, perché credenziali, sessioni, token e concessioni OAuth devono essere revocati rapidamente.
• Raccolta delle evidenze, perché possono seguire esposizione dei dati personali e segnalazioni regolatorie.
• Governance dei fornitori e del cloud, perché i log SaaS e le API di audit fanno parte della catena delle evidenze.
• Tutela della privacy, perché l’accesso ai dati personali deve essere valutato ai sensi del GDPR.

La domanda migliore non è “Quale strumento ha fallito?”. La domanda corretta è se l’organizzazione disponesse di una catena di controllo ITDR progettata, testata e verificabile.

La catena di controllo ISO 27001:2022 alla base di un ITDR efficace

I programmi ITDR più efficaci collegano controlli preventivi, di rilevamento, correttivi e probatori.

In Zenith Controls, il controllo ISO/IEC 27001:2022 5.16 Gestione delle identità è trattato come un controllo preventivo a supporto di riservatezza, integrità e disponibilità. Si collega direttamente a 5.15 controllo degli accessi, 5.17 informazioni di autenticazione, 5.18 diritti di accesso, 5.19 sicurezza delle informazioni nei rapporti con i fornitori, 5.36 conformità a politiche, regole e norme per la sicurezza delle informazioni, e 8.2 diritti di accesso privilegiato.

Questo è rilevante perché il rilevamento delle minacce all’identità fallisce quando la governance delle identità è debole. Se un account di servizio non è documentato, un’identità di fornitore non è gestita o un ruolo privilegiato non ha un titolare, il monitoraggio può rilevare un evento ma i team di risposta non riescono a interpretarlo rapidamente.

Il controllo 8.5 autenticazione sicura è un altro cardine dell’ITDR. In Zenith Controls, si collega a gestione delle identità, informazioni di autenticazione, diritti di accesso privilegiato, restrizione dell’accesso alle informazioni, attività di monitoraggio, gestione degli incidenti e protezione privacy dei PII. L’autenticazione non termina al login. Gestione delle sessioni, trattamento dei token, protezione delle credenziali e tracciabilità fanno parte della stessa storia probatoria.

Il controllo 8.16 attività di monitoraggio è il punto di snodo tra la raccolta dei log e il processo decisionale. Dipende da 8.15 registrazione e supporta 5.25 valutazione e decisione sugli eventi di sicurezza delle informazioni, 5.26 risposta agli incidenti di sicurezza delle informazioni e la più ampia gestione degli incidenti. Per l’ITDR, 8.16 è il punto in cui un comportamento sospetto dell’identità diventa un evento sottoposto a triage, un incidente dichiarato o un falso positivo documentato.

La tabella non è una mappatura teorica. È la catena pratica delle evidenze che un auditor, un membro del consiglio di amministrazione o un regolatore si aspetterà dopo un incidente basato sull’identità.

Cosa aggiungono le politiche Clarysec: titolarità, criteri di attivazione e regole sulle evidenze

Gli strumenti di identità non creano automaticamente responsabilità. Durante una crisi, i team di risposta hanno bisogno dell’autorità per revocare sessioni, disabilitare account, esportare log, conservare evidenze e prendere decisioni di escalation. Gli auditor devono vedere che queste azioni non sono state improvvisate.

La suite di politiche Clarysec fornisce questo modello operativo.

Dalla Politica di gestione degli account utente e dei privilegi Politica di gestione degli account utente e dei privilegi enterprise, la clausola 5.9 dei requisiti di governance stabilisce:

L’organizzazione deve mantenere un inventario dettagliato di tutte le credenziali attive e inattive, degli account privilegiati e degli account di servizio a livello di sistema. Questo inventario deve essere aggiornato continuamente e riesaminato trimestralmente.

Questo trasforma l’inventario delle identità in un obbligo di controllo esplicito. È particolarmente importante perché account di servizio, chiavi API e credenziali inattive sono punti ciechi comuni dell’ITDR.

La stessa politica stabilisce, nella clausola 5.8 dei requisiti di governance:

Tutte le attività amministrative e le azioni degli account privilegiati devono essere registrate in modo antimanomissione e monitorate per rilevare anomalie o violazioni della politica.

Questa clausola collega la gestione degli accessi privilegiati al rilevamento. Un’azione privilegiata non è semplicemente consentita o negata. Deve essere monitorata per individuare comportamenti non coerenti con utente, ruolo, sorgente, orario o processo aziendale.

Per le organizzazioni più piccole, la Politica di gestione degli account utente e dei privilegi - SME Politica di gestione degli account utente e dei privilegi - SME fornisce un’aspettativa sintetica nella clausola 8.1.1 di Applicazione e conformità:

Il referente IT deve riesaminare regolarmente i log di sistema per individuare tentativi di accesso non autorizzato, anomalie di accesso o modifiche dei privilegi non approvate.

È qui che iniziano molti programmi ITDR per le PMI. Non richiede un grande SOC. Richiede una titolarità nominativa e un riesame periodico dei segnali di identità corretti.

La politica di registrazione fornisce il fondamento probatorio. La Politica di registrazione e monitoraggio - SME Politica di registrazione e monitoraggio - SME specifica nella clausola 5.4.2 dei requisiti di governance:

Log di autenticazione: tentativi di accesso riusciti e non riusciti, durata della sessione, utilizzo della MFA

Questi campi non sono opzionali. Aiutano a dimostrare se l’evento sospetto ha comportato autenticazione riuscita, fallimenti ripetuti, uso della MFA, persistenza della sessione o durata anomala.

La Politica di registrazione e monitoraggio Politica di registrazione e monitoraggio enterprise amplia l’ambito dei log richiesti nella clausola 6.1.1 dei Requisiti di applicazione della politica:

Tutti i sistemi coperti devono generare log che acquisiscano: 6.1.1.1 Autenticazione degli utenti e tentativi di accesso 6.1.1.2 Attività degli utenti privilegiati 6.1.1.3 Modifiche di configurazione 6.1.1.4 Tentativi di accesso non riusciti o eventi di sistema 6.1.1.5 Rilevamenti di malware e allarmi di sicurezza 6.1.1.6 Comunicazioni esterne e attivazioni delle regole del firewall

Le modifiche di configurazione sono particolarmente importanti negli attacchi basati sull’identità. Gli attaccanti spesso aggiungono concessioni OAuth, creano regole di inoltro, registrano dispositivi, modificano metodi MFA o creano percorsi di accesso di emergenza.

La politica di risposta agli incidenti attribuisce poi autorità ai team di risposta. La Politica di risposta agli incidenti Politica di risposta agli incidenti enterprise stabilisce nella clausola 6.2.1 dei Requisiti di applicazione della politica:

Il SOC deve isolare immediatamente i sistemi interessati, revocare le credenziali compromesse o bloccare il traffico malevolo utilizzando firewall o strumenti di sicurezza degli endpoint.

La Politica di risposta agli incidenti - SME Politica di risposta agli incidenti - SME stabilisce nella clausola 4.2.2 di Ruoli e responsabilità:

Attua azioni di contenimento e ripristino, ad esempio disabilitando l’accesso o ripristinando i backup.

Per l’ITDR, revocare una password non è sufficiente. I runbook devono includere disabilitazione degli account, revoca delle sessioni, invalidazione delle concessioni OAuth, rotazione dei segreti, reset dei metodi MFA e riesame delle autorizzazioni delegate.

La gestione delle evidenze è ciò che distingue rispondere da dimostrare. La Politica per la raccolta delle evidenze e l’analisi forense Politica per la raccolta delle evidenze e l’analisi forense enterprise stabilisce nella clausola 5.5 dei requisiti di governance:

Tutte le evidenze raccolte devono essere identificate in modo univoco, etichettate e archiviate in un repository sicuro con: 5.5.1 Verifica dell’integrità, ad esempio valori hash SHA-256 5.5.2 Log degli accessi con marcatura temporale 5.5.3 Voci della catena di custodia firmate da ciascun custode

La Politica per la raccolta delle evidenze e l’analisi forense - SME Politica per la raccolta delle evidenze e l’analisi forense - SME stabilisce nella clausola 6.1.1 dei Requisiti di applicazione della politica:

Deve sempre essere creata una copia forense o un’esportazione; l’evidenza originale non deve mai essere modificata direttamente.

Nello scenario FinScale, ciò significa che il SOC esporta log del provider di identità, log di audit SaaS, registrazioni di accesso alla casella di posta, registrazioni dei consensi OAuth, registrazioni di revoca delle sessioni e allarmi SIEM in un repository delle evidenze con protezione dell’integrità e catena di custodia.

Costruire la roadmap ITDR con Zenith Blueprint

Zenith Blueprint traduce la catena di controllo in passaggi di implementazione.

Nella fase Controlli in azione, Passaggio 19, Controlli tecnologici I, il Blueprint è diretto sull’autenticazione:

Ove possibile, l’autenticazione basata solo su password deve essere evitata, in particolare per account amministrativi, console cloud, strumenti di accesso remoto e qualsiasi sistema esposto a Internet. La MFA, mediante un secondo fattore come una chiave hardware, un’app mobile o dati biometrici, è ormai un requisito minimo, non un lusso. Mitiga i rischi di furto di credenziali, phishing e attacchi di forza bruta.

Lo stesso passaggio va oltre le password. Richiede archiviazione e trasmissione sicure dei dati di autenticazione, gestione sicura dei token API, degli ID di sessione e delle credenziali OAuth, strumenti di gestione dei segreti per l’autenticazione machine-to-machine, rotazione dei token, controlli sulla durata delle sessioni, flag sicuri dei cookie e riesame dei log di autenticazione.

Il Passaggio 22, Controlli organizzativi, formalizza il ciclo di vita degli accessi. Guida i team a integrare provisioning e deprovisioning con le Risorse Umane, eseguire riesami trimestrali documentati degli accessi, definire tipi di identità come account individuali, condivisi e di servizio, imporre la MFA per gli account privilegiati, eliminare gli account inattivi e ruotare le credenziali di servizio.

Il Passaggio 19 fornisce anche il percorso di miglioramento della registrazione: inoltrare i log critici a un SIEM o a un aggregatore di log, validare la conservazione, ricostruire un evento recente usando i log, documentare le funzionalità di integrità dei log e confermare gli allarmi per accessi non riusciti o elevazioni dei privilegi. La sincronizzazione temporale è essenziale perché la ricostruzione dell’incidente fallisce quando provider di identità, SaaS, endpoint e log cloud non concordano sulle marcature temporali.

Il Passaggio 23, Controlli organizzativi per 5.19-5.37, valida le capacità di gestione degli incidenti. Richiede un piano di risposta agli incidenti aggiornato, eventi soggetti a segnalazione definiti, esercitazioni a tavolino, decisioni documentate, registrazioni delle comunicazioni, lezioni apprese e conservazione delle evidenze forensi come snapshot dei log, backup e isolamento sicuro.

Una sequenza ITDR pragmatica di Clarysec si presenta così:

1. Definire tipi di identità e titolari.
2. Proteggere autenticazione, token e sessioni.
3. Raccogliere log di autenticazione, privilegi e SaaS.
4. Monitorare i comportamenti rischiosi.
5. Definire regole decisionali da evento a incidente.
6. Conservare le evidenze.
7. Segnalare, ripristinare e migliorare.

Un pacchetto di evidenze ITDR in una settimana

Un “pacchetto di evidenze per incidente basato sull’identità” mirato è uno dei modi più rapidi per far emergere le lacune. Scegliere uno scenario ad alto rischio, ad esempio: “Un utente SaaS privilegiato concede il consenso a un’applicazione OAuth non autorizzata e il token viene usato per accedere a dati dei clienti”.

Costruire quindi il pacchetto di evidenze in una settimana.

Includere almeno una traccia reale. Prendere una recente anomalia di accesso benigna e dimostrare come il team passa dall’allarme all’identità utente, dispositivo, IP sorgente, metodo MFA, durata della sessione, risorse SaaS accedute, dati interessati e decisione di contenimento. Se l’organizzazione non riesce a ricostruire questa catena in un’esercitazione a tavolino, farà fatica durante un incidente reale.

Il risultato diventa evidenza riutilizzabile per gli audit interni ISO/IEC 27001:2022, i test del processo degli incidenti ICT DORA, la supervisione dell’igiene informatica NIS2 e l’accountability GDPR.

Mappare l’ITDR su NIS2, DORA e GDPR Article 32

La forza di un modello ITDR unificato è che le stesse evidenze soddisfano più obblighi, pur rispettando il linguaggio di ciascun quadro di riferimento.

NIS2 Article 21 si attende misure tecniche, operative e organizzative basate sul rischio e proporzionate. Per l’ITDR, ciò significa controllo degli accessi, gestione degli asset, igiene informatica, formazione, gestione degli incidenti, valutazione dell’efficacia dei controlli e MFA o autenticazione continua ove appropriato. Article 23 crea una segnalazione a fasi per gli incidenti significativi, compreso un allarme precoce entro 24 ore, una notifica dell’incidente entro 72 ore e un rapporto finale entro un mese.

DORA Articles 8 to 14 richiedono l’identificazione di asset e dipendenze ICT, protezione e prevenzione, meccanismi di rilevamento, continuità e ripristino, apprendimento e comunicazione. Articles 17 to 19 richiedono gestione degli incidenti, identificazione della causa radice, indicatori di allarme precoce, classificazione per gravità e criticità del servizio, escalation, notifica all’organo di gestione, segnalazione all’autorità competente e notifica ai clienti quando sono interessati interessi finanziari.

GDPR richiede misure tecniche e organizzative adeguate e accountability dimostrabile. Negli attacchi basati sull’identità, le domande GDPR includono se si sia verificato accesso non autorizzato, quali dati personali siano stati coinvolti, se le misure di sicurezza fossero operative e se siano state superate le soglie di notifica della violazione.

Per le fintech, la relazione tra NIS2 e DORA è rilevante. DORA è trattato come quadro di riferimento settoriale specifico per gli enti finanziari in perimetro quando esistono obblighi sovrapposti di rischio ICT e segnalazione degli incidenti. In pratica, le organizzazioni dovrebbero costruire un unico modello di evidenze ITDR e mappare le decisioni di segnalazione sul percorso giuridico applicabile.

Per organizzazioni SaaS, cloud, di servizi gestiti, di servizi di sicurezza gestiti e piattaforme digitali, l’ambito NIS2 deve essere verificato con attenzione. NIS2 copre molti settori dell’Annex I e dell’Annex II, tra cui infrastrutture digitali, fornitori di servizi di cloud computing, data center, servizi fiduciari, DNS, registri TLD, prestatori di servizi gestiti, fornitori di servizi di sicurezza gestiti, marketplace online, motori di ricerca e piattaforme di social networking. La definizione dell’ambito e l’analisi delle parti interessate ai sensi della clausola 4 di ISO/IEC 27001:2022 non sono quindi semplice documentazione formale. Definiscono quali obblighi il SGSI deve affrontare.

Rischio di identità relativo a fornitori e SaaS

Gli incidenti basati sull’identità dipendono spesso dalle evidenze dei fornitori. Il provider SaaS può esportare log di audit? Mostra eventi di consenso OAuth? Supporta controlli di accesso sicuri, registrazione e capacità di protezione dei dati? Assistenza per gli incidenti, localizzazione dei dati, subappalto, diritti di accesso e disposizioni di uscita sono coperti contrattualmente?

La Politica di utilizzo del cloud - SME Politica di utilizzo del cloud - SME di Clarysec include un requisito diretto nella clausola 5.2.4 dei requisiti di governance:

Il servizio fornisce controlli di accesso sicuri, registrazione e capacità di protezione dei dati

Questa frase semplice è un controllo di approvvigionamento. Se una piattaforma SaaS non può produrre i log di identità necessari per la risposta agli incidenti, crea rischio di conformità.

DORA lo rende esplicito attraverso gli obblighi di rischio ICT di terze parti. Gli enti finanziari restano responsabili della conformità, devono mantenere registri dei contratti di servizi ICT, distinguere funzioni critiche o importanti, svolgere due diligence, valutare il rischio di concentrazione, includere diritto di audit e diritti di accesso, definire l’assistenza in caso di incidente e garantire strategie di uscita.

In Zenith Controls, il controllo ISO/IEC 27001:2022 8.16 attività di monitoraggio si collega a 5.22 monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori. Questo riflette la realtà operativa. Allarmi del provider di identità, log di audit SaaS, attività degli amministratori cloud e account dei fornitori di servizi gestiti fanno tutti parte della superficie ITDR.

Come gli auditor valuteranno l’ITDR

Un programma ITDR solido deve resistere a più prospettive di audit. Ogni interlocutore pone domande diverse, ma le evidenze dovrebbero provenire dallo stesso sistema di controllo.

Un auditor ISO/IEC 27001:2022 chiederà se le minacce all’identità sono incluse nella valutazione del rischio, se i titolari del rischio hanno approvato il trattamento, se la Dichiarazione di Applicabilità include i controlli pertinenti dell’Annex A, se le politiche sono applicate e se le evidenze mostrano che i controlli sono operativi. Può campionare un account privilegiato e tracciare approvazione, impostazione MFA, attività di log, riesame degli accessi e deprovisioning.

Un valutatore NIST CSF 2.0 esaminerà gli esiti GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER. L’ITDR si inserisce naturalmente in un profilo limitato a compromissione dell’identità, abuso di token SaaS o uso improprio dell’accesso privilegiato.

Un esaminatore DORA cercherà accountability dell’organo di gestione, funzioni aziendali supportate da ICT, meccanismi di rilevamento, criteri di classificazione degli incidenti, escalation, regole di comunicazione ai clienti, analisi della causa radice e dipendenze ICT da terze parti.

Un referente GDPR chiederà se l’organizzazione può dimostrare la sicurezza adeguata dei dati personali. Esaminerà restrizione degli accessi, rilevamento dell’accesso non autorizzato, log che mostrano quali dati potrebbero essere stati acceduti, valutazione della violazione ed evidenze di accountability.

Un auditor in ambito COBIT 2019 o ISACA esaminerà governance, obiettivi di controllo, titolarità, monitoraggio delle prestazioni e assurance.

Zenith Controls è utile in questo contesto perché funge da guida trasversale alla conformità. Non crea “controlli Zenith” separati. Mappa le aree di controllo ISO/IEC 27001:2022 ai controlli ISO correlati, ad altri standard, alle aspettative di audit e alle relazioni di implementazione.

Metriche che dimostrano che l’ITDR è operativo

Consigli di amministrazione e auditor non hanno bisogno del rumore grezzo del SIEM. Hanno bisogno di evidenze che i controlli di identità funzionino e migliorino. Metriche ITDR utili includono:

• Percentuale di account privilegiati con MFA resistente al phishing.
• Numero di account inattivi oltre la soglia prevista dalla politica.
• Numero di account di servizio senza titolare o data di rotazione.
• Percentuale di piattaforme SaaS critiche che inviano log di autenticazione al SIEM.
• Tempo medio di rilevamento di attività sospette dell’identità.
• Tempo medio di revoca di sessioni e token compromessi.
• Numero di applicazioni OAuth approvate, respinte o rimosse.
• Percentuale di incidenti basati sull’identità con pacchetti di evidenze completi.
• Numero di risultanze del riesame degli accessi scadute.
• Numero di piattaforme di fornitori prive dei log di identità richiesti.

Queste metriche dovrebbero alimentare il riesame della direzione ISO/IEC 27001:2022, la supervisione di governance NIS2, la reportistica del rischio ICT DORA e le discussioni di accountability GDPR.

Risultanze comuni degli audit ITDR e correzioni

Clarysec osserva comunemente cinque risultanze ricorrenti.

Primo, le organizzazioni abilitano la MFA ma non monitorano il comportamento MFA. Correggere registrando modifiche dei metodi MFA, challenge fallite, impossibilità di spostamento, registrazione di nuovi dispositivi e tentativi push ripetuti.

Secondo, gli account di servizio sono esclusi dalla governance delle identità. Correggere inventariando gli account a livello di sistema, assegnando titolari, ruotando i segreti, rimuovendo credenziali incorporate e monitorando comportamenti API anomali.

Terzo, il consenso SaaS non è gestito. Correggere limitando il consenso degli utenti, riesaminando le applicazioni OAuth, monitorando le nuove concessioni, documentando le integrazioni approvate e rimuovendo le app inutilizzate.

Quarto, le evidenze vengono alterate durante l’indagine. Correggere seguendo la regola della Politica per la raccolta delle evidenze e l’analisi forense: creare copie forensi o esportazioni, non modificare mai direttamente gli originali e archiviare le evidenze con hash e registrazioni della catena di custodia.

Quinto, la classificazione degli incidenti è troppo lenta. Correggere predefinendo soglie per gli eventi di identità, incluse compromissione di account privilegiati, accesso a dati personali, abuso di token SaaS con impatto sui clienti, interruzione di servizi critici e compromissione di identità di fornitori.

Ogni risultanza ha una risposta in termini di controllo, politica ed evidenza. Questo è il valore pratico di un programma ITDR unificato: definisce ciò che deve avere un titolare, essere monitorato, testato, evidenziato e migliorato.

Trasformare il rischio legato all’identità in evidenze pronte per l’audit

Se il prossimo incidente basato sull’identità accadesse domani, potreste dimostrare chi ha avuto accesso a cosa, come si è autenticato, quale token o sessione è stato utilizzato, quali dati sono stati interessati, chi ha deciso la classificazione regolatoria e quali azioni correttive sono state completate?

Se la risposta è incerta, iniziate con uno sprint mirato di preparazione ITDR.

Utilizzate Zenith Blueprint per strutturare il percorso di implementazione tra autenticazione, ciclo di vita degli accessi, registrazione, monitoraggio, risposta agli incidenti e gestione delle evidenze. Utilizzate le politiche Clarysec su controllo degli accessi, registrazione, cloud, risposta agli incidenti e analisi forense per assegnare titolarità e autorità di risposta. Utilizzate Zenith Controls per mappare gestione delle identità, autenticazione sicura e attività di monitoraggio su ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 e aspettative di audit.

L’obiettivo è semplice: rendere gli attacchi basati sull’identità rilevabili, contenibili, segnalabili e sostenibili.

Clarysec può aiutarvi a costruire un pacchetto di evidenze ITDR, testarlo mediante uno scenario a tavolino e convertire le risultanze in un piano di trattamento del rischio comprensibile per consiglio di amministrazione, regolatore e auditor. Iniziate riesaminando la Politica di registrazione e monitoraggio, la Politica di gestione degli account utente e dei privilegi - SME, Zenith Blueprint e Zenith Controls, quindi pianificate una valutazione della preparazione ITDR per trasformare il rischio legato all’identità in evidenze pronte per l’audit.