Parte: 9 — Forense digital y respuesta a incidentes · Fuente: Roberts & Brown — Intelligence-Driven Incident Response y NIST SP 800-61 ⏱️ Duración estimada: 110 min · Nivel: Intermedio
Aprender a diseñar playbooks de respuesta: procedimientos estructurados y repetibles que guían al equipo paso a paso ante tipos concretos de incidente (phishing, ransomware, cuenta comprometida, malware). Al terminar podrás escribir playbooks accionables e integrarlos con automatización (SOAR).
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Qué es un playbook | Respuesta consistente |
| 2 | Anatomía: fases, roles, decisiones | Estructura reutilizable |
| 3 | Playbook de phishing | Coordinar correo, identidad, endpoint y comunicación |
| 4 | Playbook de ransomware | Decidir ante propagación, cifrado y continuidad |
| 5 | Playbook de cuenta comprometida | Revocar sesiones sin perder alcance ni evidencia |
| 6 | Integración con ATT&CK | Mapear al adversario |
| 7 | SOAR y automatización | Escalar la respuesta |
| 8 | Mantenimiento del playbook | No dejar que caduque |
Un playbook convierte política y conocimiento técnico en decisiones repetibles. No es una lista rígida: define disparadores, información mínima, ramas, responsables, aprobaciones, comunicaciones, evidencia y salida. Debe funcionar bajo presión y también explicar cuándo detenerse.
Runbook detalla una tarea; playbook coordina varias. Los contactos, credenciales de emergencia y dependencias se prueban, no se suponen. Cada acción de contención incluye efecto empresarial y reversión. Una versión debe señalar marco aplicable, propietario, fecha y pruebas tabletop. La automatización ejecuta pasos autorizados; no amplía autoridad.
El documento une señal de entrada, severidad, responsables, fuentes mínimas, decisiones y criterios de salida. «Investigar el correo» no es un paso ejecutable; «preservar el .eml, calcular SHA-256 y consultar URL, adjunto, remitente y destinatarios» sí define productos verificables. Cada paso señala quién ejecuta, quién aprueba, dónde registra el resultado y qué dependencia puede detenerlo.
Las ramas se construyen con criterios observables, aunque no siempre binarios: cifrado activo, privilegio administrativo, datos regulados, propagación o impacto de continuidad. El playbook también define cómo proceder con información insuficiente. Una decisión de aislar puede requerir aprobación distinta si afecta una estación de usuario o un sistema clínico.
En phishing se preserva mensaje, se busca alcance entre destinatarios, se correlaciona navegación y se evalúa identidad. En ransomware se priorizan propagación, backups, claves, sistemas críticos y comunicación. En una cuenta cloud se revocan sesiones y secretos coordinadamente, se investigan roles asumidos y se evita destruir la sesión investigativa. Estos ejemplos no se ordenan por una supuesta frecuencia universal: la organización prioriza según su riesgo y datos propios.
ATT&CK ayuda a describir comportamientos y diseñar búsquedas, pero no reemplaza la lógica de respuesta. Un IOC puede caducar o compartirse con infraestructura legítima; un playbook incluye validación, expiración y reversión de bloqueos.
Cada playbook tiene propietario, versión, cambios, dependencias y fecha de la última prueba. Un tabletop prueba autoridad y coordinación; una prueba técnica valida comandos y permisos. Los hallazgos generan cambios trazables y una reprueba. Revisarlo solo por calendario es insuficiente si cambió una API, proveedor, arquitectura o obligación.
SOAR puede enriquecer, abrir casos, consultar y bloquear, pero el grado de automatización depende del daño potencial y confianza. Acciones destructivas o de amplio impacto conservan aprobación y mecanismo de reversión. Las credenciales del SOAR se tratan como acceso privilegiado.
La alerta combina renombrados masivos y una nota de rescate. El playbook exige validar host, proceso y alcance, preservar telemetría disponible y decidir aislamiento según propagación e impacto. La rama «cifrado activo confirmado» autoriza aislamiento de red por el líder de incidente; desconectar almacenamiento compartido requiere al responsable de continuidad. Paralelamente se protege la infraestructura de backups con credenciales separadas.
El documento no ordena «borrar malware». Antes de erradicar, registra imagen, memoria si es viable, identidad, conexiones y mecanismo de persistencia. La recuperación solo avanza desde un punto anterior al compromiso verificado y con monitoreo reforzado. Cada decisión deja hora, responsable, evidencia conocida y resultado esperado.
Dominas la clase cuando otra persona puede ejecutar tu playbook sin interpretación privada: cada paso produce evidencia, cada rama tiene criterios, autoridad y reversión, las dependencias han sido probadas y la automatización conserva límites. Además, puedes adaptar el mismo modelo a phishing, ransomware e identidad sin copiar listas genéricas.
Ejercicio aplicado de diseño de proceso.
Diseña un playbook completo para "cuenta de correo corporativa comprometida" con las seis fases PICERL, al menos cuatro puntos de decisión, mapeo a ATT&CK, criterios de escalado y tres pasos marcados como automatizables.
Criterio de aceptación: el playbook es ejecutable por otra persona sin ayuda, cada fase tiene pasos numerados con responsable, los puntos de decisión tienen criterio explícito, y hay al menos tres técnicas ATT&CK referenciadas.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El playbook es teoría, no acción | Faltan pasos concretos. Escribe comandos/acciones verificables. |
| Nadie sabe cuándo escalar | Sin criterios de escalado. Defínelos por adelantado. |
| Puntos de decisión ambiguos | Criterio subjetivo. Hazlos binarios y objetivos. |
| Playbook desactualizado | Sin mantenimiento. Revísalo tras cada incidente. |
| Todo manual, sin escala | No identificaste tareas automatizables. Marca las repetibles para SOAR. |
❓ ¿Playbook o runbook? El playbook orquesta la respuesta a un tipo de incidente; el runbook detalla una tarea técnica dentro de él.
❓ ¿Cuántos playbooks necesito? Prioriza con datos de riesgo, incidentes, amenazas y dependencias de tu organización. Phishing, ransomware, cuenta comprometida y malware son plantillas iniciales posibles, no un ranking universal.
❓ ¿SOAR reemplaza al analista? No. Automatiza lo repetible (enriquecer IOCs, bloquear, notificar) para que el analista se enfoque en decisiones.
❓ ¿Cómo evito que caduquen? Revísalos tras cada incidente y en las lecciones aprendidas; un playbook es un documento vivo.
Extiende la anatomía de esta clase con los ocho playbooks de custodia: pérdida de fondos, wallet, insider, exchange, API key, discrepancia, retiro no autorizado y ledger. Compara sus decisiones de preservación y contención.
Clase 214 — Recuperación de datos y file carving