Por qué tu MTTR de 4 horas es ficción.

El reporte mensual del SOC dice que el MTTR es de 4 horas. La presentación al board dice 4 horas. El SLA con el MSSP promete 4 horas. Y, sin embargo, cuando reconstruimos un incidente real desde el principio — desde que el atacante entra, no desde que la consola levanta un ticket — el número siempre, sin excepción, es mayor. A veces el doble. A veces diez veces.

Esto no es un problema cosmético. Es la diferencia entre creerse a salvo y estarlo.

De dónde sale el 4

El MTTR que la mayoría de SOCs miden es la diferencia entre el momento en que se abre un ticket en la herramienta de tickets y el momento en que se cierra ese ticket. Esa métrica es honesta para una sola cosa: cuánto tarda el equipo en cerrar tickets una vez abiertos. Es útil para gestión de carga, no para postura de seguridad.

El reloj que importa al negocio es otro. Empieza en T0 = atacante consigue acceso inicial y para en T = riesgo neutralizado. Entre el T0 real y el momento del ticket suelen pasar, en nuestra experiencia, entre 2 y 14 días según madurez del programa. Eso es dwell time, y es la magnitud que el atacante usa para hacer daño.

Por qué el delta es siempre mayor de lo que crees

Tres motivos sistemáticos:

1. La detección llega tarde porque la regla no existía. El atacante usó una técnica para la que tu stack no tiene cobertura. La alerta solo se dispara cuando hace algo más ruidoso, días después.
2. Los logs que demostrarían el T0 real no existen ya. Si tu retención de auditoría es de 30 días y descubres una intrusión a los 45, T0 es "fecha desconocida". El SOC reporta lo único que tiene: la primera alerta. Por definición, baja el MTTR.
3. El ticket se abre tras varios saltos de manos. La alerta se ignora primero, se reabre por correlación, se manda al L2, alguien la triaja, y entonces empieza el cronómetro oficial. Todo ese pre-ticketing es invisible.

Cómo medirlo de verdad

La métrica que usamos internamente para clientes maduros tiene tres puntos:

Punto	Qué mide	Cómo se obtiene
T0	Acceso inicial confirmado	Reconstrucción forense post-incidente
Td	Detección efectiva	Timestamp de la primera alerta legítima
Tr	Riesgo neutralizado	Aislamiento + revocación de credenciales + cierre de vector

De ahí salen tres números útiles, no uno: MTTD = Td − T0 (cuánto vives ciego), MTTR = Tr − Td (cuánto tardas desde que ves), y el más importante, Dwell Time = Tr − T0 (cuánto te tuvo el atacante a su disposición).

Solo el primero requiere reconstrucción forense, lo cual es una tara para reporting mensual. Por eso recomendamos reportar los tres trimestralmente, sobre los incidentes confirmados de severidad alta. Si solo tienes recursos para uno, prioriza Dwell Time. Es el único que el atacante también está midiendo.

Cómo reducirlo

El MTTR oficial baja con automatización de respuesta: aislamiento, revocación de tokens, terminación de procesos. El Dwell Time real solo baja con dos cosas:

• Cobertura de detección sobre TTPs, no sobre IOCs. Si solo tienes reglas que dependen de hashes, IPs y dominios concretos, te van a faltar todas las técnicas. Aquí la nota sobre Scattered Spider tiene varios ejemplos.
• Threat hunting periódico. La detección automática mira lo que has codificado; el hunting busca lo que no has codificado todavía. Si no haces hunting, tu Dwell Time real es indeterminadamente largo.

Lo que no debes hacer

No retoques la métrica para que el número quede mejor. La tentación de mover el T0 hacia el Td "porque no podemos saberlo con seguridad" es enorme y completamente humana. Si lo haces, estás regalándole horas al atacante en tu reporte y mintiéndote a ti mismo. Mejor un Dwell Time grande y honesto que un MTTR pequeño y falso. El primero te dice dónde mejorar; el segundo te tranquiliza hasta el día de la brecha.