MTTD / MTTR Mean Time to Detect / Recover.

Duas métricas, uma só linha temporal

O MTTD e o MTTR descrevem dois segmentos consecutivos da mesma linha temporal de um incidente. O MTTD cobre o período silencioso entre o momento em que um atacante age pela primeira vez e o momento em que a sua equipa percebe que algo está errado. O MTTR cobre tudo o que vem depois desse ponto, da triagem à contenção e à recuperação, até um regresso confirmado à normalidade. Lê-los em conjunto é precisamente o objetivo: um MTTD baixo com um MTTR alto significa que deteta as ameaças com rapidez mas tem dificuldade em agir sobre elas, ao passo que um MTTD alto com um MTTR baixo significa que responde depressa, mas só depois de o dano já estar feito. Nenhum dos números é útil isoladamente, e melhorar um à custa do outro raramente ajuda.

Na prática, estes são os números de destaque que um SOC reporta à direção, porque traduzem a atividade técnica numa linguagem que o negócio compreende: durante quanto tempo estivemos expostos e quanto tempo demorámos a fechar a porta. São também as métricas em torno das quais giram os reguladores e os referenciais, mesmo quando usam palavras diferentes. Um prazo de notificação de uma violação é, no essencial, um limite legal sobre uma parte do seu MTTR, e a obrigação de detetar incidentes em tempo útil é a obrigação de manter o MTTD baixo.

O que realmente move estes números

O MTTD é impulsionado pela visibilidade e pela afinação. Não consegue detetar aquilo que não recolhe, por isso a cobertura de registos nos endpoints, na rede, na identidade e na cloud é a base. Além disso, o conteúdo de deteção tem de ser afinado: demasiado solto e os analistas afogam-se em falsos positivos e perdem o sinal real, demasiado apertado e intrusões genuínas passam despercebidas. É por isso que um SIEM, uma boa engenharia de deteção e a threat intelligence alimentam diretamente o MTTD.

O MTTR é impulsionado pelo processo e pela autoridade: playbooks documentados, o poder de isolar um host ou desativar uma conta sem esperar por um comité, backups testados e comunicação ensaiada. A melhoria clássica aqui é a automatização através de um SOAR, que elimina os minutos perdidos nas transferências manuais.

Como as métricas aparecem nas normas e nos benchmarks

Os referenciais normalmente não impõem um alvo específico de MTTD ou de MTTR, porque o número certo depende da organização e da ameaça. O que exigem é a capacidade e a medição. A ISO/IEC 27035 estabelece o ciclo de vida da gestão de incidentes que estas métricas quantificam. As orientações do NIST sobre tratamento de incidentes enquadram deteção, análise, contenção, erradicação e recuperação como fases distintas, que é exatamente a estrutura sobre a qual o MTTD e o MTTR assentam.

A ENISA e agências nacionais como a ANSSI transmitem a mesma mensagem operacional: detetar cedo, responder depressa e ser capaz de o provar. Os regimes regulatórios acrescentam prazos externos rígidos, por exemplo as janelas de notificação de violações ao abrigo do RGPD e as obrigações de comunicação de incidentes ao abrigo da NIS2 e do DORA, que transformam parte do seu tempo de resposta num requisito de conformidade em vez de num objetivo de desempenho.

Os benchmarks para ambas as métricas tendem a situar-se desconfortavelmente altos em todo o setor, muitas vezes na ordem de dias ou semanas para a deteção, ao passo que os programas maduros visam horas. Perseguir um benchmark publicado é, porém, o instinto errado. O valor do MTTD e do MTTR está nas linhas de tendência que são suas: meça-as de forma consistente, observe a direção ao longo dos trimestres e ligue o movimento a investimentos concretos em visibilidade, afinação e automatização. Um número definido com honestidade e a descer de forma constante vale muito mais do que uma cifra lisonjeira e pontual.