MTTD e MTTR: as métricas que o board exige

Todo conselho de administração já ouviu que "a questão não é se, mas quando" a empresa vai sofrer um incidente. A frase é verdadeira e inútil: não diz se a empresa está melhorando. O que diz é quanto tempo o atacante fica dentro do ambiente antes de ser visto e quanto tempo leva para ser expulso. Esses dois intervalos têm nome, MTTD e MTTR, e são as métricas de segurança que um board consegue acompanhar sem traduzir jargão.

O problema é que quase ninguém mede do mesmo jeito. Duas empresas podem reportar "MTTR de 4 horas" querendo dizer coisas completamente diferentes. Este artigo define as métricas, mostra onde a medição costuma mentir e propõe um formato de reporte que sobrevive a perguntas de conselheiro.

O que são MTTD e MTTR, sem ambiguidade

MTTD (Mean Time To Detect) é o tempo entre o início da atividade maliciosa e o momento em que alguém, pessoa ou sistema, reconhece que aquilo é um incidente. Não é o tempo até o primeiro alerta: alerta que ninguém olhou não é detecção.

MTTR é onde mora a confusão. O "R" aparece no mercado com pelo menos três significados:

• Respond: tempo entre a detecção e a primeira ação de resposta (isolar host, bloquear conta)
• Recover: tempo entre a detecção e a volta do serviço à operação normal
• Remediate: tempo entre a detecção e a correção da causa raiz (patch aplicado, configuração corrigida)

As três são úteis e medem coisas diferentes. A regra prática: escolha as definições, escreva-as numa página e não mude sem avisar o board. Para a maioria das empresas, vale separar em quatro marcos, porque cada um tem um dono diferente:

O MTTC (tempo até contenção) é o número que mais importa em ransomware: é a janela em que o atacante ainda pode se mover lateralmente e cifrar mais sistemas. Se o board só puder acompanhar dois números, acompanhe MTTD e MTTC.

Por que a média engana

O "M" de MTTD significa média, e média é a pior estatística para tempo de incidente. A distribuição é assimétrica: a maior parte dos incidentes é contida em minutos e alguns poucos ficam semanas no ambiente. São justamente esses poucos que viram notícia.

Um exemplo com dez incidentes no trimestre: nove detectados em 20 minutos e um que ficou 30 dias sem ser visto. A média é de pouco mais de três dias, número que não descreve nenhum incidente real. A mediana é 20 minutos e esconde o caso grave. Nenhuma das duas sozinha conta a história.

Reporte sempre três números por métrica:

1. Mediana: o comportamento típico da operação
2. Percentil 90: quanto demora o caso difícil
3. Máximo do período, com nome: o pior incidente, com uma linha explicando o que foi

Quando o P90 cai trimestre a trimestre, a defesa está de fato melhorando. Quando só a média cai, pode ser apenas volume maior de incidentes fáceis.

Onde a medição mente

As métricas de tempo são fáceis de melhorar no papel sem melhorar a segurança. Os quatro vícios mais comuns:

1. Viés de sobrevivência

MTTD só mede o que foi detectado. O incidente que o SOC nunca viu não entra na conta, e é exatamente o que mais importa. Um SOC que detecta pouco pode ter um MTTD excelente. A única forma de medir o que não se vê é simular: exercícios de Purple Team e Red Team dão o início exato de cada ação ofensiva, e o tempo até a detecção vira um dado controlado, não uma estimativa.

2. Relógio que começa tarde

Muita operação registra como "início" o horário do primeiro alerta, não o da primeira atividade maliciosa. Isso zera o tempo em que o atacante agiu sem disparar nada. A investigação forense quase sempre encontra atividade anterior ao alerta. Atualize o início do incidente quando a investigação descobrir isso, mesmo que o número piore.

3. Fechar o ticket não é conter

Se a métrica é o fechamento do chamado, o time aprende a fechar chamados. Contenção precisa de critério verificável: conta desabilitada, host isolado, IOC bloqueado no perímetro, sessão revogada. Sem critério escrito, o MTTC mede velocidade administrativa.

4. Misturar severidades

Um phishing reportado e contido em 10 minutos e um comprometimento de domínio contido em 3 dias não cabem na mesma média. Segmente sempre por severidade. O board quer saber principalmente dos incidentes altos e críticos.

De onde vêm os dados

Métrica de board precisa ser auditável: qualquer número apresentado deve poder ser reconstruído a partir de registros. As fontes mínimas:

• Plataforma de casos (SOAR, ITSM ou a ferramenta do MSSP) com timestamps de abertura, triagem, contenção e encerramento
• SIEM e EDR para o horário do primeiro evento relacionado, recuperado na investigação
• Relatório pós-incidente com a linha do tempo consolidada, que é a fonte oficial para incidentes altos e críticos
• Resultados de exercícios (Purple Team, Red Team, BAS) com o horário de cada técnica executada

Se o SOC é terceirizado, os marcos de tempo precisam estar no contrato. "Atendimento 24×7" sem SLA de triagem e de contenção por severidade não é mensurável. Veja o que esperar de um SOC 24×7 antes de negociar esses termos.

Como apresentar ao board

Conselho não precisa de painel com quarenta indicadores. Precisa de uma página que responda três perguntas: estamos vendo os ataques mais rápido? Estamos contendo mais rápido? O que ainda não vemos?

Um formato que funciona:

1. Tendência de quatro trimestres de MTTD e MTTC, mediana e P90, apenas para severidade alta e crítica
2. Pior incidente do período, em três linhas: o que aconteceu, quanto tempo durou, o que mudou depois
3. Cobertura de detecção medida no último exercício: percentual das técnicas simuladas que foram detectadas, idealmente mapeado ao MITRE ATT&CK
4. Uma decisão pedida ao conselho, quando houver: orçamento, prioridade, aceite formal de risco

O item 3 é o que dá credibilidade ao resto. Sem ele, MTTD baixo pode significar apenas que pouca coisa é detectada. Com ele, o board vê o tempo e a cobertura juntos.

Metas que fazem sentido

Evite copiar metas de benchmark de mercado. Os estudos usam definições diferentes da sua e populações diferentes da sua empresa. As metas úteis são relativas ao próprio histórico e ao risco:

• Reduzir o P90 de contenção de incidentes críticos em um percentual definido ao longo de quatro trimestres
• Aumentar a cobertura de detecção nas técnicas mais usadas contra o seu setor, medida em exercício
• Zerar incidentes críticos sem linha do tempo consolidada em até 10 dias úteis após o encerramento
• Manter SLA de triagem por severidade acima de um patamar contratado, com a exceção explicada

Meta sem dono não anda. Cada uma delas tem um responsável nomeado e é revisada no comitê de riscos antes de subir ao conselho.

Checklist para o próximo reporte

• Definições de MTTD, MTTA, MTTC e MTTR escritas e aprovadas
• Início do incidente corrigido pela investigação, não pelo primeiro alerta
• Mediana, P90 e máximo, nunca só a média
• Segmentação por severidade
• Critério verificável de contenção
• Cobertura de detecção do último exercício ao lado dos tempos
• Números reconstruíveis a partir de registros

Conclusão

MTTD e MTTR são as métricas de segurança que o board entende porque falam de tempo e tempo vira custo. Mas só servem se forem definidas com precisão, reportadas com distribuição e acompanhadas de uma medida do que ainda não é detectado. Sem isso, viram mais um número verde num painel.

Se a sua operação ainda não tem linha de base, comece pelo exercício: um Purple Team curto produz, em poucos dias, os primeiros tempos de detecção medidos com relógio de verdade.