Articolo Pubblicazioni

Metriche di sicurezza: MTTD, MTTR e indicatori per il consiglio di amministrazione

di · Pubblicato il 14 novembre 2026

Abstract

Le metriche di sicurezza servono a sapere se le cose migliorano e a far prendere decisioni a chi governa l’organizzazione. L’articolo distingue indicatori di prestazione e di rischio, spiega come misurare i tempi di rilevamento e di risposta, propone un insieme ridotto di indicatori per il consiglio di amministrazione e indica gli errori che rendono i cruscotti inutili.

Vincenzo Calabrò | Metriche di sicurezza: MTTD, MTTR e indicatori per il consiglio di amministrazione
 

Misurare per decidere

Molti rapporti sulla sicurezza contano quello che è facile contare, come email bloccate, attacchi respinti dal firewall e numero di patch installate. Sono numeri grandi che non dicono se l’organizzazione è più sicura del mese precedente né dove investire. Una metrica utile risponde a una domanda che qualcuno deve porsi per decidere, ha un obiettivo, una tendenza nel tempo e un responsabile.

KPI e KRI

Conviene distinguere due famiglie. Gli indicatori di prestazione, o KPI, misurano quanto bene funzionano i processi di sicurezza, come i tempi di correzione o di risposta. Gli indicatori di rischio, o KRI, segnalano che l’esposizione sta crescendo, come l’aumento dei sistemi non supportati o degli account privilegiati senza autenticazione a più fattori. Un cruscotto per i vertici ha bisogno di entrambi.

I tempi

  • MTTD (mean time to detect), il tempo medio fra l’inizio di un incidente e il suo rilevamento, che misura la capacità di accorgersi degli attacchi;
  • MTTR, che a seconda delle organizzazioni indica il tempo medio di risposta, cioè dal rilevamento al contenimento, o di ripristino, cioè fino al ritorno alla normalità, e va quindi definito con precisione;
  • Tempo di correzione delle vulnerabilità per classe di priorità, confrontato con i termini stabiliti.
I tempi medi sono sensibili ai pochi casi estremi, quindi conviene affiancarli alla mediana e al valore che copre il 90% dei casi. Il momento di inizio di un incidente si conosce spesso solo dopo l’analisi, e va aggiornato quando emerge.

Un cruscotto per il consiglio

  1. stato di attuazione delle misure di sicurezza rispetto al piano, per esempio secondo le funzioni del NIST Cybersecurity Framework 2.0 o le misure di base dell’ACN;
  2. vulnerabilità critiche e già sfruttate aperte oltre il termine, sui sistemi esposti e su quelli critici;
  3. percentuale di account privilegiati e di accessi remoti protetti da autenticazione a più fattori;
  4. esito dell’ultima prova di ripristino dei sistemi critici, confrontato con gli obiettivi della business impact analysis;
  5. incidenti del periodo per gravità, con tempi di rilevamento e di risposta;
  6. stato dei fornitori critici valutati e delle azioni aperte;
  7. tasso di segnalazione delle email sospette da parte del personale, più utile del tasso di clic nelle simulazioni.
Sette indicatori, presentati con la tendenza e un commento di due righe su che cosa significano e quale decisione richiedono, dicono al consiglio più di un rapporto di trenta pagine. Per le decisioni di investimento le metriche si possono affiancare a stime economiche del rischio sui pochi scenari principali.

Errori da evitare

  • metriche che misurano l’attività svolta senza dire nulla sul risultato;
  • obiettivi fissati senza dati di partenza;
  • indicatori che cambiano a ogni trimestre e non permettono di vedere una tendenza;
  • numeri senza contesto, che il consiglio non sa interpretare né trasformare in una decisione.

Come si raccolgono i dati

Le metriche valgono quanto i dati da cui nascono. I tempi di rilevamento e risposta si ricavano dal sistema di gestione dei ticket o degli incidenti, a patto che ogni incidente registri in campi strutturati l’ora del primo evento, quella del rilevamento, quella del contenimento e quella della chiusura. Lo stato delle vulnerabilità viene dagli strumenti di scansione, la copertura dell’autenticazione a più fattori dal sistema di gestione delle identità, l’esito dei ripristini dai verbali delle prove. Conviene automatizzare la raccolta il più possibile, perché un indicatore calcolato a mano ogni trimestre finisce per essere aggiornato in ritardo o non aggiornato affatto.

Obiettivi e soglie

Ogni indicatore ha bisogno di un obiettivo e di una soglia oltre la quale si interviene. Per esempio, nessuna vulnerabilità del catalogo KEV aperta oltre sette giorni sui sistemi esposti, copertura dell’autenticazione a più fattori per gli account privilegiati pari al 100%, ripristino dei sistemi critici entro il tempo fissato dalla business impact analysis in almeno una prova all’anno. Gli obiettivi si fissano partendo dalla situazione reale e si alzano quando vengono raggiunti stabilmente. Un semaforo verde, giallo e rosso accanto a ogni indicatore aiuta il consiglio a capire subito dove guardare.

Un esempio di presentazione

Una pagina per trimestre è sufficiente. In alto lo stato complessivo rispetto al piano di sicurezza, con la percentuale di misure completate. Al centro i sette indicatori, ognuno con il valore attuale, l’obiettivo, la tendenza degli ultimi quattro trimestri e una riga di commento. In basso le decisioni richieste al consiglio, per esempio l’approvazione di un investimento, l’accettazione formale di un rischio residuo o la scelta fra due alternative, con i costi e gli effetti attesi. Il commento è la parte più importante, perché spiega perché un numero è cambiato e che cosa si sta facendo.
Le metriche si rivedono ogni anno. Alcune perdono significato quando l’obiettivo è raggiunto in modo stabile e possono uscire dal cruscotto principale, altre diventano necessarie con nuovi rischi, nuove norme o nuovi servizi.
Le metriche servono anche a dialogare con le autorità e con i clienti. Nelle verifiche previste dalla NIS2 o da DORA, e nei questionari dei clienti più strutturati, poter mostrare indicatori raccolti con regolarità e una tendenza di miglioramento è una prova concreta che la sicurezza viene gestita.
 
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn