¿Qué miden MTTD, MTTA, MTTC y MTTR?
Las cuatro métricas dividen el ciclo de vida de un incidente en tramos. Juntas responden a una pregunta: cuánto tiempo tuvo el atacante para actuar antes de que lo frenaras.
| Métrica | Nombre | Empieza | Termina |
|---|---|---|---|
| MTTD | Mean Time to Detect (tiempo medio de detección) | Inicio de la actividad maliciosa | Primera alerta o detección |
| MTTA | Mean Time to Acknowledge (tiempo medio de reconocimiento) | Alerta generada | Una persona o un sistema empieza a trabajarla |
| MTTC | Mean Time to Contain (tiempo medio de contención) | Detección | Amenaza contenida: equipo aislado, cuenta bloqueada o comunicación cortada |
| MTTR | Mean Time to Respond, Remediate, Resolve o Recover | Detección | Respuesta completada o servicio restablecido, según la definición |
La R de MTTR es ambigua. Para unos es respuesta (investigar y actuar), para otros remediación (eliminar la causa) y para otros recuperación (volver a operar con normalidad). Todas son válidas, pero dos cifras de MTTR con definiciones distintas no se pueden comparar. Escribe la tuya y úsala siempre igual.
¿Cómo se calculan? Fórmulas y ejemplo
Todas son medias de diferencias de tiempo sobre los incidentes de un periodo, donde n es el número de incidentes (o de alertas, en el caso del MTTA):
- MTTD = Σ (momento de detección - momento de inicio) / n
- MTTA = Σ (momento de reconocimiento - momento de la alerta) / n
- MTTC = Σ (momento de contención - momento de detección) / n
- MTTR = Σ (momento de resolución - momento de detección) / n
| Incidente | Inicio | Detección | Contención | Resolución |
|---|---|---|---|---|
| A: phishing con robo de credenciales | Lunes 09:00 | Lunes 13:00 (4 h) | Lunes 14:00 (1 h) | Martes 13:00 (24 h) |
| B: malware en un portátil | Miércoles 10:00 | Miércoles 10:30 (0,5 h) | Miércoles 10:45 (0,25 h) | Miércoles 16:30 (6 h) |
| C: acceso remoto con una cuenta válida | Viernes 22:00 | Lunes 08:00 (58 h) | Lunes 09:00 (1 h) | Martes 08:00 (24 h) |
Resultado: MTTD = (4 + 0,5 + 58) / 3 ≈ 20,8 horas; MTTC = (1 + 0,25 + 1) / 3 = 0,75 horas (45 minutos); MTTR = (24 + 6 + 24) / 3 = 18 horas. La mediana del tiempo de detección es de 4 horas: el incidente C, que empezó un viernes por la noche y nadie vio hasta el lunes, dispara la media. Por eso conviene publicar media y mediana, y analizar aparte los incidentes fuera de horario.
¿Qué es el dwell time y cómo se relaciona con el MTTD?
El dwell time, o tiempo de permanencia, es el tiempo que un atacante pasa dentro del entorno antes de ser detectado. Mide lo mismo que el MTTD, pero lo suelen publicar empresas de respuesta a incidentes sobre los casos que investigan, y normalmente como mediana en lugar de media. Según el informe M-Trends 2026 de Mandiant, la mediana global fue de 14 días en las investigaciones de 2025, frente a 11 días el año anterior. El Active Adversary Report 2026 de Sophos sitúa la mediana en 3 días en sus casos de respuesta a incidentes y MDR. La diferencia muestra cuánto depende la cifra de la muestra: tipo de cliente, de ataque y de servicio.
¿Por qué importa tanto la velocidad?
Los datos de Sophos dan una idea del margen. En sus casos, una vez dentro, los atacantes tardaron una mediana de 3,4 horas en ir a por el servidor de Active Directory. La exfiltración de datos se produjo a algo más de tres días (78,8 horas) del inicio del ataque y apenas 1,87 horas antes de su detección. Un MTTC medido en horas puede llegar tarde si el atacante ya controla el dominio.
¿Qué alarga el MTTD y el MTTR?
- Fuentes sin conectar: si no recoges logs de identidad, correo o cloud, los ataques que pasan por ahí no generan alertas.
- Detecciones genéricas o desactualizadas: reglas que no cubren las técnicas que se usan contra tu sector.
- Ruido: miles de falsos positivos hacen que las alertas reales esperen en la cola, y el MTTA se dispara.
- Triaje manual: cada alerta exige consultar varias consolas para reunir el contexto.
- Horario de oficina: lo que ocurre de noche o en fin de semana espera al siguiente turno.
- Aprobaciones lentas: nadie autorizado para aislar un servidor a las 3 de la mañana.
- Herramientas que detectan pero no permiten contener en remoto.
¿Cómo reducir el MTTD, el MTTC y el MTTR?
- Amplía la visibilidad a endpoint, identidad, correo, red y cloud. Prioriza la identidad: muchos ataques entran con credenciales válidas.
- Alinea las detecciones con MITRE ATT&CK y revisa qué técnicas cubres de verdad.
- Automatiza el triaje y el enriquecimiento para que el analista reciba casos con contexto en lugar de alertas en bruto.
- Define playbooks de contención con acciones preaprobadas por tipo de incidente y criticidad del activo.
- Garantiza cobertura 24/7 con personas autorizadas para contener, también de noche.
- Haz threat hunting para encontrar lo que ninguna regla detectó y convierte cada hallazgo en una detección nueva.
- Revisa cada incidente: dónde se perdió el tiempo y qué cambio lo evita la próxima vez.
¿Qué errores se cometen al medir?
- Excluir los incidentes que detectó un tercero: el MTTD sale artificialmente bajo.
- Confundir el MTTR con el tiempo de cierre del ticket.
- Usar solo la media: un par de casos extremos la distorsionan.
- Mezclar alertas e incidentes: el MTTA se mide sobre alertas; el MTTD, el MTTC y el MTTR, sobre incidentes confirmados.
- Optimizar la métrica en lugar del resultado: cerrar alertas rápido sin investigarlas baja el MTTR y sube el riesgo.
Cómo te ayuda Ciberia
Ciberia MDR actúa sobre los tramos donde más tiempo se pierde. Se integra con más de 600 fuentes (EDR/XDR, SIEM, firewall, correo, identidad y cloud), así que trabaja sobre la telemetría que ya tienes. Sus agentes de IA propios investigan cada alerta en segundos y automatizan alrededor del 90 % del triaje. Cada caso llega con contexto y un analista valida las decisiones con impacto. Para alertas críticas, el SLA contractual es de 15 minutos hasta la contención inicial, a cualquier hora. Con Threat Hunting, los hallazgos se convierten en nuevas reglas de detección.
