MTTR en ciberseguridad: la métrica que reemplaza al 'estamos protegidos'

Tu CISO dice: “estamos protegidos”. Tu CEO duerme tranquilo. Tu equipo tiene firewall, EDR, MFA, SIEM, antivirus. Todo en verde.

Y aún así, Verizon DBIR 2024 reporta que el tiempo promedio para detectar una intrusión es de 84 días. El tiempo promedio para contenerla: 24 días adicionales. Total: 108 días desde compromise hasta erradicación.

Esos 108 días son MTTR — Mean Time To Remediate. Y es la única métrica que tu próximo cliente, auditor ISO o regulador va a pedirte demostrar.

¿Qué es MTTR exactamente?

Mean Time To Remediate es el tiempo promedio que tarda tu organización desde que se detecta una vulnerabilidad hasta que se resuelve.

No confundir con primos cercanos:

En este post hablamos de MTTR = Mean Time To Remediate — el más exigente.

Por qué importa (datos crudos)

IBM Cost of a Data Breach 2024:

• Costo promedio global de un breach: USD 4.88 millones (récord histórico)
• Empresas con MTTR < 30 días: ahorran USD 2.22 millones por incidente
• Empresas con MTTR < 7 días: detectan automatizadamente y responden con SOAR

Verizon DBIR 2024:

• 68% de breaches involucran factor humano
• Tiempo promedio entre publicación de CVE y exploitation in the wild: 5 días (caído desde 38 días en 2017)
• Si tu MTTR es > 5 días, estás del lado perdedor de la curva

El truco que nadie te dice: MTTR por severidad

Reportar “MTTR promedio = X” es engañar a la junta directiva. La métrica útil es MTTR por severidad:

Si tu MTTR Critical es > 24h, tienes un problema. No de seguridad — de proceso. Las herramientas de detección son baratas; la cadena de aprobación-fix-deploy-validación es lo que rompe el SLA.

Cómo medirlo con rigor: el sidecar finding_states

Aquí entra la parte técnica que hicimos en Pentest C360. El problema: cómo trackear el MTTR de cada hallazgo individual a través de auditorías repetidas en el tiempo.

La solución: un sidecar SQLite con WAL mode que indexa cada finding con (target_slug, finding_key) como PK, y campos first_seen, last_seen, resolved_at.

CREATE TABLE finding_states (
  target_slug   TEXT NOT NULL,
  finding_key   TEXT NOT NULL,
  severity      TEXT NOT NULL,
  module        TEXT NOT NULL,
  first_seen    INTEGER NOT NULL,  -- epoch
  last_seen     INTEGER NOT NULL,
  resolved_at   INTEGER,           -- NULL si abierto
  PRIMARY KEY (target_slug, finding_key)
);

CREATE INDEX idx_severity_resolved ON finding_states(severity, resolved_at);
CREATE INDEX idx_target ON finding_states(target_slug);

Por qué SQLite y no Postgres:

1. WAL mode permite escritor + múltiples lectores concurrentes
2. Un solo archivo, fácil backup
3. Suficiente para 100K-1M de findings (orden de magnitud realista)
4. Bench público: 0.30 ms por consulta MTTR vs 7.04 ms recompute desde JSONs = 23× más rápido (bench documentado)

Endpoint público: /api/pentest/findings/mttr

Pentest C360 expone el MTTR computado en tiempo real:

curl https://pentest.cedula360.tech/api/pentest/findings/mttr

Responde con:

{
  "mttr_by_severity": {
    "critical": {"avg_hours": 3.5, "count": 12},
    "high":     {"avg_hours": 18.2, "count": 47},
    "medium":   {"avg_hours": 96.7, "count": 89},
    "low":      {"avg_hours": 240.0, "count": 13}
  },
  "open_findings": 5,
  "resolved_total": 156,
  "computed_at": "2026-05-06T16:30:00Z"
}

Esos números son públicos y reproducibles. El motor usa los mismos endpoints que vas a auditar tu sitio.

Cómo se relaciona con ISO 27001

ISO/IEC 27001:2022 control A.9.1 (Monitoring) + A.9.2 (Internal audit) requieren métricas medibles. MTTR es la métrica natural.

Auditor pregunta:

• “¿Cuál es su MTTR para vulnerabilidades críticas?”
• “¿Cómo lo miden? Muéstreme la fuente de datos.”
• “¿Cuál es la tendencia de los últimos 12 meses?”

Si tu respuesta es:

• ❌ “Hacemos auditorías cada 6 meses” → suspendido
• ❌ “Tenemos un Excel” → suspendido
• ✅ “Sidecar SQLite, endpoint público, dashboard tiempo real, tendencia documentada” → aprobado y celebrado

El caso real: 161 findings resueltos en 3 jornadas

Documentado en este blog y en docs/HARDENING-INDEX.md:

¿Cómo se logra MTTR de 3.5 minutos? Combinación de:

1. Detección automatizada que mapea finding → CWE → control → remediación específica
2. Plantillas de remediación pre-validadas: snippet Caddy (c360-security-headers), dns_apply.py con APIs DNS
3. Re-audit automático post-fix que mide resolved_at exacto
4. Sidecar finding_states que cuantifica sin re-procesar histórico

La tabla que tu junta directiva necesita ver

Trae a la próxima reunión esta tabla. Llénala con números reales:

Si no puedes llenarla con datos, estás en mode auditoría reactiva. Cada día que pasa sin esta visibilidad, el costo de un incidente sube exponencialmente.

Mitos sobre MTTR que tu vendor te dijo

Mito 1: “MTTR bajo = ser inseguro porque parchas sin probar”. Realidad: MTTR mide tiempo a remediación validada. No incluye tiempo de testing si el testing es parte del flujo.

Mito 2: “No podemos medir MTTR si no usamos su SIEM”. Realidad: cualquier herramienta con timestamp de detección y resolución sirve. SQLite + script gana al 90% de SIEMs comerciales en agilidad.

Mito 3: “Nuestro MTTR es 0 porque no tenemos vulnerabilidades”. Realidad: si no detectas, no significa que no exista. Verizon DBIR 2024 confirma: el 89% de breaches involucran vulnerabilidades que llevaban meses publicadas y conocidas internamente.

¿Qué hacer esta semana?

3 acciones concretas:

1. Audit baseline + cuenta findings

curl -X POST https://pentest.cedula360.tech/api/pentest/scan \
  -H "Content-Type: application/json" \
  -d '{"target":"https://tu-sitio.com","layers":["passive"]}'

Anota: total findings, distribución por severidad, top 5 por riesgo.

2. Implementa sidecar mínimo

Si no quieres usar Pentest C360, monta tu propio sidecar:

import sqlite3
import time

DB = "findings.db"
conn = sqlite3.connect(DB)
conn.execute("PRAGMA journal_mode=WAL")
conn.execute("""CREATE TABLE IF NOT EXISTS finding_states (
  target_slug TEXT, finding_key TEXT, severity TEXT,
  first_seen INTEGER, last_seen INTEGER, resolved_at INTEGER,
  PRIMARY KEY (target_slug, finding_key))""")

def upsert(target, key, severity):
    now = int(time.time())
    conn.execute("""
      INSERT INTO finding_states (target_slug, finding_key, severity, first_seen, last_seen)
      VALUES (?, ?, ?, ?, ?)
      ON CONFLICT (target_slug, finding_key) DO UPDATE SET last_seen = ?, resolved_at = NULL
    """, (target, key, severity, now, now, now))
    conn.commit()

def resolve(target, key):
    now = int(time.time())
    conn.execute("UPDATE finding_states SET resolved_at = ? WHERE target_slug = ? AND finding_key = ? AND resolved_at IS NULL",
                 (now, target, key))
    conn.commit()

Listo. Ya tienes MTTR cuantificable.

3. Reporta semanalmente

A tu junta, a tu CISO, a tu cliente. La consistencia gana.

El takeaway

MTTR no es la métrica de los geeks de seguridad. Es la métrica que va a aparecer en cada RFP corporativo de 2026 en adelante. Tus competidores que la midan ganarán contratos. Los que sigan diciendo “estamos protegidos” perderán cuentas.

La buena noticia: medirla cuesta poco. Pentest C360 ya lo hace público y reproducible. El motor que llevó 161 findings a resolución cuantificada en 3 jornadas está disponible. Con números reales.

¿Tu sitio cuántos findings tiene abiertos hoy? El primer audit es gratis. Después, decides si quieres trackear el MTTR como los grandes — o seguir confiando en el “estamos protegidos”.