MTTC e MTTD só dizem algo sobre a operação quando todos os incidentes são cronometrados com o mesmo relógio — e é exatamente nesse ponto que a maioria dos relatórios de SOC se quebra. O M-Trends da Mandiant mostra que a mediana global de tempo de permanência dos invasores subiu de 10 para 11 dias, o primeiro aumento da série histórica, e isso torna as métricas de SOC ainda mais decisivas: cada hora mal contada no dashboard é uma hora em que o adversário opera de graça no ambiente. Este artigo fixa onde cada relógio começa e termina, compara os números internos com benchmarks públicos e lista os erros de coleta que mais distorcem MTTD e MTTC no dia a dia da operação.
O que cada relógio mede
Antes de discutir precisão, convém cravar as definições em linguagem de runbook. Segundo o glossário de SecOps da Fortinet, MTTD é o tempo médio que a equipe de segurança leva para detectar um possível incidente a partir do momento em que ocorre, contado desde a infiltração até o registro formal do incidente no SOC. O MTTC cobre o intervalo da detecção até a contenção efetiva — a ação que impede o invasor de seguir avançando, como isolar um host, resetar uma credencial comprometida ou bloquear um domínio de comando e controle. O MTTR fecha o ciclo com o tempo até a resolução completa e a recuperação do ativo afetado. A detecção vem primeiro, então o MTTD limita todos os relógios seguintes: contenção e resposta não começam antes da detecção.
| Métrica | O que mede | Fórmula prática |
|---|---|---|
| MTTD | Da primeira ação do invasor no ambiente até a detecção pelo SOC | Soma dos tempos de detecção dividida pelo número de incidentes |
| MTTA | Do disparo do alerta até o primeiro atendimento humano | Soma dos tempos de atendimento dividida pelo número de alertas |
| MTTC | Da detecção até a contenção que trava o avanço do invasor | Soma dos tempos de contenção dividida pelo número de incidentes contidos |
| MTTR | Da detecção até a resolução e recuperação do ativo | Soma dos tempos de resolução dividida pelo número de incidentes |
Uma regra que evita discussão em reunião de post-mortem: cada métrica precisa de um marco de início e um marco de parada escritos no runbook antes do incidente acontecer, não decididos depois, quando o número já está na tela do gestor.
Onde o relógio começa
O erro mais comum é trocar o t0 sem perceber. Se num incidente o relógio começa no primeiro evento observável no log e noutro começa no primeiro alerta disparado pelo SIEM, o MTTD agregado mistura duas populações diferentes e perde significado. O mesmo vale para o t1 da contenção: isolar a máquina não equivale a confirmar que a conta comprometida foi totalmente revogada. Em investigações de movimento lateral com pass-the-hash, por exemplo, o t0 honesto costuma estar numa autenticação anômala horas antes do primeiro alerta de escalada — e é essa janela que separa um MTTD real de um MTTD cosmético.
Três requisitos operacionais sustentam um relógio confiável: sincronização de tempo (NTP) em todas as fontes, retenção de logs maior que o tempo de permanência esperado do adversário e gravação automática de carimbos de data/hora em cada transição do ticket (detecção, atendimento, contenção, resolução). Sem esses três, qualquer número de MTTD ou MTTC é uma estimativa, não uma medida.
Benchmarks de dwell time
Comparar o relógio interno com dados públicos ajuda a calibrar expectativa. Segundo o M-Trends 2025 da Mandiant, a mediana de dwell time foi de 26 dias quando a notificação veio de entidades externas, 5 dias quando o próprio adversário avisou e 10 dias quando a descoberta foi interna. A leitura operacional é direta: quando o SOC descobre a intrusão sozinho, o relógio é duas a cinco vezes menor do que quando a notícia chega de fora — e a diferença aparece diretamente no MTTD reportado.
| Origem da descoberta | Mediana de dwell time |
|---|---|
| Notificação de entidades externas | 26 dias |
| Notificação do próprio adversário | 5 dias |
| Descoberta interna pela organização | 10 dias |
| Mediana global | 11 dias |
O relatório também mostra por que a superfície de exploração importa para o relógio: a exploração de vulnerabilidades foi o vetor de infecção inicial mais comum do levantamento, presente em 33% das investigações. Vetores que entram por exposição técnica tendem a gerar telemetria explorável — desde que os logs do perímetro e de identidade estejam na esteira de detecção.
Erros que distorcem os números
A auditoria de qualquer painel de MTTD e MTTC costuma achar ao menos um destes defeitos:
- Relógio de início inconsistente: t0 ora é o evento no log, ora é o alerta, ora é a abertura do ticket, sem regra única.
- Denominador recortado: o MTTD é calculado só sobre os alertas efetivamente investigados; se a fila tem cobertura baixa, o número melhora sem a operação melhorar nada.
- Média sem mediana: um incidente de weeks de dwell time arrasta a média e esconde o caso típico; reportar as duas evita a distorção.
- Mistura de origens: juntar detecções próprias com notificações externas e de extorsão numa única média, quando as populações têm relógios radicalmente diferentes.
- Contenção declarada sem erradicação: fechar o MTTC no isolamento do host sem confirmar revogação de sessões e credenciais, como exige um caso de bypass de MFA por ransomware.
- Falso positivo reclassificado fora da amostra: quando o alerta fechado como benigno era um ataque real, o incidente some do denominador e o relógio oficial fica artificialmente curto.
Como reportar sem enganar
Um protocolo curto resolve a maior parte das distorções:
- Escrever no runbook os marcos de início e parada de MTTD, MTTC e MTTR por tipo de incidente, antes da medição começar.
- Garantir NTP em todas as fontes e retenção de logs maior que o dwell time esperado do adversário no setor da organização.
- Registrar automaticamente os carimbos de cada transição do ticket, sem digitação manual.
- Reportar mediana e distribuição, nunca só a média, e separar por origem da descoberta.
- Publicar a taxa de cobertura da fila de alertas junto com o MTTD, para que um denominador menor não se disfarce de progresso.
Com esses cinco passos, MTTD e MTTC deixam de ser números de vaidade e passam a funcionar como o que deveriam ser sempre: um termômetro honesto da velocidade do SOC contra o relógio do invasor.
