Runbooks, respuesta y hardening posincidente
El runbook hace que la contención ocurra en minutos, y el posincidente convierte lo que dolió en una defensa permanente, en la aplicación y no solo en el borde.
Qué es
Los runbooks son guiones cortos y accionables para los incidentes más probables: quién decide, qué revisar, qué acción tomar y cómo deshacerla. Un buen runbook cabe en una pantalla y funciona a las tres de la mañana, para quien acaba de despertar.
El hardening posincidente es el otro lado: el borde contiene, pero solo la corrección en la aplicación y en la configuración evita la repetición.
Escalera de contención con plazo
En ataques volumétricos o de abuso, la respuesta escala en escalones, cada uno con TTL, para que un error de clasificación no bloquee a nadie para siempre. Empiece por un desafío (barato para el legítimo, caro para el robot) y solo después bloquee.
trigger: alerta login_failures_zscore > 4 durante 3 minutos
owner: soc-l7 (guardia)
steps:
- verificar: ASNs y fingerprints dominantes, cuentas intentadas (distintas vs repetidas)
- contener:
1: Managed Challenge en los ASNs ofensores # TTL 30 min
2: Block en los fingerprints confirmados # TTL 4 h
3: exigir MFA / reset forzado en cuentas con éxito sospechoso
- comunicar: canal #incidentes, actualización cada 30 min
- deshacer: quitar reglas si la tasa de fallos vuelve al baseline por 30 min
after: postmortem en hasta 5 días hábilesPostmortem sin culpa
El objetivo es aprender, no buscar culpables. Un buen postmortem registra la línea de tiempo (cuándo empezó, cuándo detectamos, cuándo contuvimos), la causa, lo que funcionó, lo que estorbó y acciones con responsable y plazo. Las métricas de detección y contención salen de él y alimentan el tuning.
Hardening en la aplicación
Cada incidente señala controles que no deberían depender del borde. Tres ejemplos frecuentes:
- CSP con nonce: política de seguridad de contenido que solo ejecuta scripts con un nonce generado por solicitud, reduciendo el impacto de .
- estricto: orígenes permitidos explícitos, sin comodín en endpoints con credenciales.
- Validación de esquema en el gateway: rechazar cuerpos y parámetros que no coinciden con la especificación de la API, el aplicado cerca de la aplicación.
Ejemplo: CSP con nonce
Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-{random-por-solicitud}' 'strict-dynamic';
object-src 'none';
base-uri 'none';
frame-ancestors 'none'Ejercicios
Un runbook sin probar es una suposición. Los ejercicios de mesa (tabletop) y las simulaciones con tráfico sintético revelan brechas de permisos, de contactos y de herramientas antes del incidente real, y mantienen entrenado al equipo.
conexiones en el mapa
- Bot managementactivaRunbooks, respuesta y hardening posincidente
- WAF - observación, shadow y enforcementejecutaRunbooks, respuesta y hardening posincidente
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- El ciclo de vida de la respuesta a incidentesresponselos runbooks son el ciclo ensayado y escrito
- SASTappsecel hardening posincidente se vuelve regla y corrección en el código
- Respuesta a incidentes en la nubecloudsecel runbook de L7 es un caso específico de la respuesta general
- Automatización de seguridad y playbooks como códigosecengel runbook que se vuelve playbook automatizado, con frenos
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…