SOC 24/7 ≠ Respuesta a Incidentes 24/7

Muchas empresas creen que, si tienen un SOC 24/7, tienen cubierto el “peor día del año”.

Es una suposición razonable… y peligrosa.

Porque en la práctica, la mayoría de incidentes graves no escalan por falta de detección.

Escalan por falta de transferencia: el paso desde “vemos algo” hasta “tomamos acciones que reducen daño”.

El SOC puede estar despierto a las 03:00.

La organización, no.

Y cuando el atacante optimiza por velocidad, persistencia y ventanas de oportunidad, esa diferencia es el incidente.

Qué significa “SOC 24/7” y qué NO significa

SOC 24/7 suele significar:

• Monitorización continua de alertas y telemetría.
• Triage y clasificación inicial.
• Apertura de ticket, evidencias básicas y comunicación.
• Escalado a equipos internos o proveedores según procedimiento.

Pero Respuesta a Incidentes 24/7 (IR 24/7) implica algo distinto:

• Capacidad de contener (aislar, bloquear, cortar movimientos laterales).
• Capacidad de erradicar (eliminar persistencia, credenciales comprometidas, rutas de acceso).
• Capacidad de recuperar (restaurar servicios con seguridad).
• Capacidad de decidir bajo presión, con autoridad y permisos.

La diferencia entre ambas no es semántica: es el tiempo de exposición.

El cuello de botella real: la transferencia

La transferencia es lo que ocurre entre:

1. “Tenemos indicios” y
2. “Ejecutamos acciones con impacto”

Si esa transferencia depende de “mañana lo vemos”, el SOC 24/7 se convierte en un buzón nocturno.

Por qué falla la transferencia (causas típicas)

1) Autoridad difusa

Nadie tiene claro quién puede autorizar aislamiento de un servidor, bloqueo de una cuenta privilegiada o corte de una VPN.

2) Permisos incompletos

El SOC detecta, pero no tiene capacidad (técnica o contractual) para ejecutar acciones. Todo depende de un tercero o de un equipo interno no on-call.

3) Escalado por ticketing, no por severidad

Si el flujo es “abrir ticket” en vez de “activar respuesta”, los tiempos se vuelven administrativos.

4) Runbooks que describen, pero no deciden

Playbooks llenos de texto y sin umbrales: “revisar”, “analizar”, “validar”. En un incidente real, eso es indecisión estructurada.

5) Comunicación no preparada

No hay canales claros, ni criterios de activación, ni responsables por turnos. A las 03:00, todo cuesta el doble.

El patrón más común: se detecta de madrugada, se contiene por la mañana

Este patrón se repite en empresas de todos los tamaños:

• 02:10: el SOC detecta actividad anómala, posible compromiso.
• 02:25: se abre ticket y se notifica a un buzón o a un grupo general.
• 03:00–08:30: no hay respuesta ejecutiva/técnica.
• 09:15: alguien lee el aviso, pide contexto, reabre preguntas.
• 10:30: se ejecutan acciones de contención.

Durante ese tiempo, el atacante:

• eleva privilegios,
• se mueve lateralmente,
• establece persistencia,
• exfiltra o prepara ransomware.

Luego, en retrospectiva, la narrativa es: “lo vimos a tiempo”.

Pero el negocio vive otra realidad: lo vimos, pero no actuamos.

Por qué esto es un problema de negocio, no solo técnico

La transferencia fallida se convierte en coste por tres vías:

1) Tiempo de exposición = incremento no lineal del impacto

Cada hora extra no suma, multiplica: más sistemas, más cuentas, más datos, más incertidumbre.

2) La organización aprende a ignorar

Si las alertas nocturnas no llevan a acciones, se normaliza la pasividad. Eso mata la eficacia futura.

3) Se destruye la trazabilidad

Sin contención temprana, el entorno cambia (logs rotan, endpoints se reinician, acciones improvisadas). Luego el forense se convierte en conjetura.

Cómo se cierra de verdad: diseñar la respuesta, no prometerla

No va de “poner más gente”. Va de reducir fricción entre detección y acción.

1) Definir un modelo de severidad que active respuesta, no conversación

Necesitas criterios simples que, cuando se cumplen, activan automáticamente:

• canal de crisis,
• responsables,
• acciones permitidas,
• límites de impacto.

Ejemplo de enfoque: “si hay señal X + confirmación mínima Y → acción Z”.

No “abrir ticket y esperar validación completa”.

2) Preautorizar acciones de contención (con límites claros)

La contención no puede depender de permisos ad hoc.

Acciones típicas que deberían estar preaprobadas para severidades altas:

• reset/lock de credenciales comprometidas,
• bloqueo de tokens/sesiones,
• aislamiento de endpoint,
• bloqueo de egress sospechoso,
• deshabilitar cuentas de servicio anómalas,
• cuarentena de artefactos.

Con límites: impacto máximo, ventanas, excepciones, y quién puede revertir.

3) Tener un “Incident Commander” por turno (aunque sea rotativo)

No hace falta un equipo enorme. Hace falta una cadena de mando:

• una persona con autoridad para decidir,
• un técnico con capacidad para ejecutar,
• un canal de comunicación con negocio.

Sin mando, cada minuto se pierde en coordinación.

4) Runbooks que deciden: umbrales, no literatura

Un runbook útil responde:

• ¿Qué señales disparan la severidad?
• ¿Qué se hace primero?
• ¿Qué NO se hace para no destruir evidencia?
• ¿Quién aprueba qué?
• ¿Qué métricas se recogen?

Si el runbook no reduce decisiones en caliente, no es operativo.

5) Integrar IR con operaciones y continuidad

El SOC vive en seguridad. El incidente vive en operaciones.

Tu plan debe estar conectado con:

• IT/Infra (cambios, redes, identidades),
• continuidad de negocio,
• legal/compliance,
• comunicación interna.

La respuesta falla cuando seguridad intenta operar sola o cuando operaciones bloquea por miedo a impacto.

Métricas que sí reflejan capacidad real (y las que engañan)

Métricas útiles:

• TTD (Time to Detect): detección.
• TTA (Time to Acknowledge): reconocimiento con responsabilidad.
• TTC (Time to Contain): contención efectiva (la métrica que más correlaciona con reducción de daño).
• Tiempo hasta “decisión ejecutable”: desde primera alerta hasta autorización y acción.

Métricas que se maquillan fácil:

• MTTR entendido como “cerrar ticket”.
• Número de alertas tratadas.
• SLAs de respuesta administrativa.

Si una métrica no se conecta con “reducción de impacto”, se convierte en reporting.

Checklist operativo: ¿tienes IR 24/7 o solo monitorización 24/7?

Si hoy ocurre un incidente crítico a las 03:00, ¿puedes responder “sí” a esto?

1. ¿Hay una persona de mando localizable que pueda autorizar contención en minutos?
2. ¿Existen acciones preaprobadas para severidad alta?
3. ¿El SOC tiene acceso y permisos para ejecutar contención o activar a quien sí los tiene?
4. ¿Hay canales de crisis definidos (no email), con responsables por turno?
5. ¿Los runbooks incluyen umbrales y decisiones, no solo pasos genéricos?
6. ¿La contención temprana está priorizada incluso si hay impacto operativo controlado?
7. ¿Se mide TTC (contención) y se revisa post-mortem para reducir fricción?

Si fallan 2–3 puntos, el “24/7” es un claim operativo, no una capacidad real.

Referencias de marco (sin postureo)

No necesitas citar normativa para trabajar bien, pero sí conviene alinear el enfoque:

• NIST (ciclo Detect–Respond–Recover y enfoque de contención)
• ISO 27035 (gestión de incidentes)
• ENISA (guías de respuesta y coordinación)

La idea común en todos: la respuesta es un proceso de decisión y ejecución, no un panel de alertas.

Cierre: el SOC no es el final del camino, es el inicio de la acción

Un SOC 24/7 es valioso.

Pero por sí solo no compra resiliencia.

La resiliencia aparece cuando la organización puede, a cualquier hora:

• reconocer,
• decidir,
• contener,
• recuperar, sin improvisación.

El atacante no necesita que falles en detección.

Le basta con que tardes en actuar.