Mean Time to Remediation (MTTR)

TL;DR

MTTR rappresenta il tempo medio necessario per risolvere una vulnerabilità di sicurezza dopo l’identificazione, fornendo una misura diretta dell’efficienza operativa.
Per calcolare MTTR, dividere il tempo totale impiegato per risolvere i problemi per il numero di incidenti.
L’obiettivo è minimizzare il tempo di esposizione in modo che gli attaccanti abbiano meno probabilità di sfruttare le lacune conosciute.
La soluzione è accelerare il processo automatizzando tutto, dalla rilevazione delle vulnerabilità alla generazione delle correzioni del codice, eliminando i ritardi nelle code di ticket manuali e garantendo una più rapida risoluzione.

Che cos’è MTTR?

Il Mean Time to Remediation (MTTR) è una metrica chiave della cybersecurity che mostra quanto rapidamente si risponde a una minaccia conosciuta. Misura il tempo che intercorre da quando viene trovata una vulnerabilità a quando viene implementata una correzione.

Mentre metriche come MTTD riflettono la velocità di rilevamento, MTTR rivela la vera efficienza di risoluzione della tua organizzazione. Un rilevamento rapido deve essere accompagnato da una risoluzione tempestiva per contenere l’esposizione al rischio e supportare la continuità aziendale.

Perché MTTR è importante

I cybercriminali operano più velocemente delle tempistiche di sviluppo tradizionali, accelerando la domanda di operazioni di sicurezza reattive. Le tendenze del settore indicano che le finestre di difesa si stanno riducendo.

La finestra di sfruttamento di 5 giorni: Nel 2025, il Tempo Medio di Sfruttamento (TTE), l’intervallo tra quando una vulnerabilità viene resa pubblica e quando viene attivamente sfruttata, è sceso da 32 giorni a soli 5 giorni (CyberMindr, 2025).
Aumento dello sfruttamento: L’uso delle vulnerabilità come via d’accesso è aumentato del 34% quest’anno e ora causa il 20% di tutte le violazioni confermate.
Il ritardo nella rimedio: Gli attaccanti agiscono in giorni, ma le organizzazioni spesso impiegano settimane. Il tempo mediano per correggere vulnerabilità critiche nei dispositivi edge e VPN rimane 32 giorni, lasciando una significativa finestra di rischio. Solo il 54% delle falle viene mai completamente corretto (Verizon DBIR, 2025). Accelerazione del giorno: La scoperta di vulnerabilità zero-day sfruttate è aumentata del 46% rispetto all’anno scorso. Gli attaccanti ora armano queste falle entro poche ore dall’identificazione (WithSecure Labs, 2025).
Alto MTTR aumenta i costi aziendali ben oltre il debito tecnico. Nel 2025, il costo medio di una violazione dei dati negli Stati Uniti è di 4,4 milioni di dollari, principalmente a causa della risposta ritardata e delle sanzioni normative (IBM, 2025).
Sanzioni per non conformità: Sotto regole come DORA, lunghi tempi di esposizione sono considerati fallimenti sotto la resilienza operativa. Le organizzazioni con alto MTTR ora affrontano obblighi di segnalazione obbligatoria e grandi multe per non conformità. Non puoi muoverti più velocemente degli script di sfruttamento; la tua difesa è puramente teorica.

Come Calcolare MTTR

MTTR è calcolato dividendo il tempo totale trascorso a riparare un sistema per il numero di riparazioni effettuate in un periodo specifico.

La Formula

MTTR-formula

Esempio di Calcolo

Immagina che il tuo team di ingegneri abbia gestito 4 incidenti lo scorso mese:

Incidente A: Interruzione del database (Risolto in 30 minuti)
Incidente B: Fallimento dell’API (Risolto in 2 ore / 120 minuti)
Incidente C: Errore di cache (Risolto in 15 minuti)
Incidente D: Patch di sicurezza (Risolto in 45 minuti)

Tempo Totale di Riparazione: 30 + 120 + 15 + 45 = 210 minuti
Numero di Riparazioni: 4

MTTR-formula-calculation

Questo significa che, in media, il tuo team impiega circa 52 minuti per risolvere un problema una volta iniziato a lavorarci.

Esempio Pratico

Considera due aziende che affrontano una vulnerabilità di sicurezza critica (ad esempio, Log4Shell).

Azienda A (Alto MTTR):

Processo: Manuale. Gli avvisi vengono inviati via email. Un ingegnere deve accedere manualmente ai server tramite SSH per trovare i file jar vulnerabili e patcharli uno per uno.
MTTR: 48 Ore.
Risultato: Gli attaccanti hanno due giorni interi per sfruttare la vulnerabilità. I dati sono probabilmente compromessi.

Azienda B (Basso MTTR - utilizzando Plexicus per automatizzare la risoluzione):

Processo: Automatizzato. La vulnerabilità viene rilevata immediatamente. Un playbook automatizzato si attiva per isolare i container interessati e applicare una patch o una regola di firewall virtuale.
MTTR: 15 Minuti.
Risultato: La vulnerabilità viene chiusa prima che gli attaccanti possano lanciare un exploit con successo.

Chi Usa MTTR

Ingegneri DevOps - Per tracciare l’efficienza dei loro pipeline di distribuzione e rollback.
SRE (Site Reliability Engineers) - Per garantire che rispettino gli SLA (Service Level Agreements) per il tempo di attività.
Analisti SOC - Per misurare quanto rapidamente possono neutralizzare le minacce di sicurezza attive.
CTO e CISO - Per giustificare gli investimenti in strumenti di automazione dimostrando una riduzione del tempo di recupero.

Quando Applicare MTTR

MTTR dovrebbe essere monitorato continuamente, ma è più critico durante la fase di Risposta agli Incidenti del SDLC (Software Development Life Cycle)

Durante gli Incidenti: Funziona come un controllo del polso in tempo reale. “Stiamo risolvendo questo problema abbastanza velocemente?”
Post-Mortem: Dopo un incidente, rivedere MTTR aiuta a identificare se il ritardo è stato causato dal rilevamento del problema (MTTD) o dalla sua risoluzione (MTTR).
Negoziazione SLA: Non puoi promettere a un cliente “99,99% di uptime” se il tuo MTTR medio è di 4 ore.

Migliori Pratiche per Ridurre MTTR

Automatizza tutto: Le correzioni manuali sono lente e soggette a errori. Usa Infrastructure as Code (IaC) per ridistribuire l’infrastruttura danneggiata piuttosto che ripararla manualmente.
Miglior monitoraggio: Non puoi correggere ciò che non puoi vedere. Gli strumenti di osservabilità granulare aiutano a individuare la causa principale più rapidamente, riducendo la parte di “diagnosi” del tempo di riparazione.
Runbook e Playbook: Avere guide pre-scritte per guasti comuni. Se un database si blocca, l’ingegnere non dovrebbe dover cercare su Google “come sbloccare un database”.
Post-mortem senza colpe: Concentrati sul miglioramento del processo, non delle persone. Se gli ingegneri temono punizioni, potrebbero nascondere i fallimenti, rendendo imprecisi i metriche MTTR.

Termini correlati

MTTD (Mean Time To Detect)
MTBF (Mean Time Between Failures)
SLA (Service Level Agreement)
Gestione degli incidenti

Miti comuni

Mito: Puoi raggiungere “zero vulnerabilità.”

Realtà: L’obiettivo è risolvere i problemi critici abbastanza velocemente da battere lo sfruttamento.
Mito: Più scanner equivalgono a una sicurezza migliore.

In realtà, aggiungere strumenti crea solo più rumore e lavoro manuale se non integrati.
Mito: Gli strumenti di sicurezza rallentano gli sviluppatori.

Realtà: La sicurezza rallenta gli sviluppatori solo quando genera avvisi “errati”. Quando fornisci una pull request pre-scritta, stai risparmiando loro ore di ricerca.

FAQ

Cos’è un “buon” MTTR?

I migliori team DevOps mirano a un MTTR inferiore a 24 ore per le vulnerabilità critiche.

In cosa differisce l’MTTR dall’MTTD?

MTTD (Mean Time to Detect) mostra quanto tempo una minaccia è presente prima che tu te ne accorga. MTTR mostra quanto tempo rimane dopo che l’hai trovata.

L’IA può effettivamente aiutare con MTTR?

Sì. Strumenti di IA come Plexicus gestiscono il triage e suggeriscono correzioni, che tipicamente rappresentano l’80% del processo di rimedio.

Pensiero Finale

MTTR è il battito cardiaco del tuo programma di sicurezza. Se è alto, il tuo rischio è alto. Automatizzando la transizione dal trovare problemi alla creazione di pull request, smetti di trattare la sicurezza come un collo di bottiglia e inizi a trattarla come una parte normale del tuo pipeline CI/CD.