MTTD / MTTR Mean Time to Detect / Recover.

Due metriche, un'unica linea temporale

L'MTTD e l'MTTR descrivono due segmenti consecutivi della stessa linea temporale di un incidente. L'MTTD copre il periodo silenzioso tra il momento in cui un attaccante agisce per la prima volta e il momento in cui il vostro team si accorge che qualcosa non va. L'MTTR copre tutto ciò che segue quel punto, dal triage al contenimento e al ripristino, fino a un ritorno confermato alla normalità. Leggerli insieme è proprio il punto: un MTTD basso con un MTTR alto significa che individuate le minacce rapidamente ma faticate ad agirvi, mentre un MTTD alto con un MTTR basso significa che rispondete in fretta, ma solo quando il danno è già fatto. Nessuno dei due numeri è utile isolatamente, e migliorare l'uno a scapito dell'altro raramente aiuta.

In pratica questi sono i numeri di punta che un SOC riferisce alla direzione, perché traducono l'attività tecnica in un linguaggio che il business comprende: per quanto tempo siamo stati esposti e quanto ci è voluto per chiudere la porta. Sono anche le metriche attorno a cui ruotano i regolatori e i framework, anche quando usano parole diverse. Una scadenza per la notifica di una violazione è essenzialmente un tetto legale su una parte del vostro MTTR, e l'obbligo di rilevare gli incidenti in tempo utile è l'obbligo di mantenere basso l'MTTD.

Cosa muove davvero questi numeri

L'MTTD è guidato dalla visibilità e dalla messa a punto. Non potete rilevare ciò che non raccogliete, quindi la copertura dei log su endpoint, rete, identità e cloud è la base. Oltre a questo, il contenuto di rilevamento va messo a punto: troppo permissivo e gli analisti annegano nei falsi positivi e perdono il segnale reale, troppo stretto e le intrusioni autentiche sfuggono. Per questo un SIEM, una buona ingegneria di rilevamento e la threat intelligence alimentano direttamente l'MTTD.

L'MTTR è guidato dal processo e dall'autorità: playbook documentati, il potere di isolare un host o disabilitare un account senza attendere un comitato, backup testati e una comunicazione provata. Il miglioramento classico qui è l'automazione tramite un SOAR, che elimina i minuti persi nei passaggi manuali.

Come le metriche compaiono negli standard e nei benchmark

I framework di solito non impongono un obiettivo specifico di MTTD o MTTR, perché il numero giusto dipende dall'organizzazione e dalla minaccia. Ciò che richiedono è la capacità e la misurazione. La ISO/IEC 27035 definisce il ciclo di vita della gestione degli incidenti che queste metriche quantificano. Le linee guida del NIST sulla gestione degli incidenti inquadrano rilevamento, analisi, contenimento, eradicazione e ripristino come fasi distinte, che è esattamente la struttura su cui poggiano l'MTTD e l'MTTR.

L'ENISA e le agenzie nazionali come l'ANSSI trasmettono lo stesso messaggio operativo: rilevare presto, rispondere in fretta ed essere in grado di dimostrarlo. I regimi normativi aggiungono scadenze esterne rigide, ad esempio le finestre di notifica delle violazioni previste dal GDPR e gli obblighi di segnalazione degli incidenti previsti da NIS2 e DORA, che trasformano una parte del vostro tempo di risposta in un requisito di conformità anziché in un obiettivo di prestazione.

I benchmark per entrambe le metriche tendono a collocarsi scomodamente in alto in tutto il settore, spesso dell'ordine di giorni o settimane per il rilevamento, mentre i programmi maturi puntano a ore. Inseguire un benchmark pubblicato è però l'istinto sbagliato. Il valore dell'MTTD e dell'MTTR risiede nelle linee di tendenza che possedete: misuratele in modo coerente, osservate la direzione nei trimestri e collegate il movimento a investimenti specifici in visibilità, messa a punto e automazione. Un numero definito onestamente e in calo costante vale molto di più di una cifra lusinghiera e isolata.