Saltar a contenido

4.1.3.-Playbooks y runbooks

4.1.3. Playbooks y runbooks de respuesta a incidentes

Idea principal

Un playbook traduce el plan de respuesta a un escenario concreto, como phishing, ransomware o compromiso de identidad. Un runbook baja un paso más y describe tareas técnicas repetibles, como aislar un endpoint, revocar sesiones o restaurar un servicio.

En el punto anterior hemos visto cómo construir un plan de respuesta a incidentes. Ese plan explica la organización general: roles, canales, escalado, documentación y revisión posterior. Sin embargo, cuando aparece un incidente concreto, el equipo necesita una guía más específica.

No se responde igual a un phishing que a un ransomware, a un defacement web o a un compromiso de proveedor. Por eso se crean playbooks: documentos tácticos que indican cómo investigar, contener, erradicar, recuperar y comunicar ante un tipo de incidente.

Código Descripción
RA4 Implementa medidas de ciberseguridad en redes y sistemas respondiendo a los incidentes detectados y aplicando las técnicas de protección adecuadas.
CE a) Se han desarrollado procedimientos de actuación detallados para dar respuesta, mitigar, eliminar o contener los tipos de incidentes de ciberseguridad más habituales.
CE b) Se han preparado respuestas ciberresilientes ante incidentes que permitan seguir prestando los servicios de la organización y fortaleciendo las capacidades de identificación, detección, prevención, contención, recuperación y cooperación con terceros.
CE c) Se ha establecido un flujo de toma de decisiones y escalado de incidentes interno y/o externo adecuados.
CE d) Se han llevado a cabo las tareas de restablecimiento de los servicios afectados por un incidente hasta confirmar la vuelta a la normalidad.
CE e) Se han documentado las acciones realizadas y las conclusiones que permitan mantener un registro de "lecciones aprendidas".
CE f) Se ha realizado un seguimiento adecuado del incidente para evitar que una situación similar se vuelva a repetir.

Definición

Un playbook de respuesta a incidentes es una guía táctica que recoge las acciones recomendadas para gestionar un tipo concreto de incidente, manteniendo la coordinación con el plan general de respuesta.

Qué deberías saber al terminar

Al acabar este tema deberías poder:

  • diferenciar playbook y runbook;
  • decidir qué incidentes necesitan playbook;
  • diseñar la estructura mínima de un playbook;
  • usar MITRE ATT&CK, la taxonomía de incidentes y el análisis de riesgos como apoyo;
  • relacionar un playbook con el repositorio de práctica incident-response-plan-plantilla.

1. Playbook, runbook y plan: cómo encajan

La relación entre plan, playbook y runbook puede entenderse como tres niveles de concreción.

Nivel Documento Pregunta que responde Ejemplo
Organizativo Plan de respuesta ¿Cómo se organiza la respuesta en la organización? Roles, canales, escalado, evidencias, revisión posterior.
Táctico Playbook ¿Qué hacemos ante este tipo de incidente? Playbook de phishing o ransomware.
Operativo Runbook ¿Cómo ejecuto esta tarea paso a paso? Revocar sesiones en Microsoft 365 o aislar un host desde EDR.

Idea clave

El playbook no sustituye al plan. Lo aplica a un escenario concreto. El runbook no sustituye al playbook. Detalla una tarea técnica concreta dentro de ese playbook.

2. Diferencia entre playbook y runbook

Aunque a veces se usan como sinónimos, conviene distinguirlos.

Aspecto Playbook Runbook
Enfoque Táctico y coordinado. Técnico y operativo.
Alcance Tipo de incidente completo. Tarea concreta dentro del incidente.
Público Equipo de respuesta, responsables técnicos, comunicación, legal. Personal técnico que ejecuta acciones.
Contenido Investigación, contención, erradicación, recuperación y comunicación. Pasos, comandos, pantallas, validaciones y rollback.
Ejemplo Playbook de phishing. Procedimiento para revocar sesiones y forzar cambio de contraseña.

Ejemplo

Ante un phishing, el playbook indica que hay que investigar destinatarios, analizar enlaces, contener cuentas, purgar mensajes y comunicar a usuarios. El runbook explica exactamente cómo buscar el mensaje en el gateway de correo y cómo purgarlo de los buzones.

3. Qué incidentes necesitan playbook

No todos los incidentes necesitan un playbook propio. Conviene priorizar los casos más probables, más repetidos o con mayor impacto.

Criterios para elegir playbooks:

  • probabilidad alta según histórico o inteligencia de amenazas;
  • impacto alto en servicios o datos;
  • necesidad de coordinación entre varios equipos;
  • decisiones urgentes de contención;
  • obligaciones legales o de comunicación;
  • tareas técnicas repetibles;
  • relación con riesgos críticos de la organización.

Ejemplos habituales:

  • phishing;
  • ransomware;
  • compromiso de identidad y acceso;
  • defacement web;
  • fuga o exposición de datos;
  • pérdida o robo de dispositivo;
  • DDoS;
  • compromiso de cadena de suministro;
  • malware en endpoint;
  • actividad anómala en red.

4. Fuentes para diseñar playbooks

Un playbook no debe inventarse desde cero sin contexto. Debe apoyarse en varias fuentes.

Fuente Cómo ayuda
Taxonomía de incidentes Permite nombrar y clasificar tipos de incidente de forma coherente.
Análisis de riesgos Ayuda a priorizar playbooks según impacto y probabilidad.
MITRE ATT&CK Aporta tácticas, técnicas y procedimientos usados por adversarios.
RE&CT Ayuda a mapear acciones defensivas y de respuesta.
NIST SP 800-61 Ordena las fases de respuesta y los criterios de análisis.
Lecciones aprendidas Convierte incidentes reales en mejoras del playbook.
Repositorio de práctica Proporciona estructura reutilizable para roles, respuesta y playbooks.

MITRE no es un playbook

MITRE ATT&CK ayuda a entender técnicas del atacante y posibles detecciones, pero no sustituye a un playbook. El playbook traduce esa información a acciones concretas dentro de una organización.

5. Estructura recomendada de un playbook

Un playbook debe ser breve, accionable y fácil de seguir bajo presión. La estructura usada en incident-response-plan-plantilla/playbooks/ es una buena base:

Playbook: [tipo de incidente]

1. Objetivo
2. Criterios de activación
3. Investigación
4. Remediación
   4.1. Contención
   4.2. Erradicación
5. Recuperación
6. Comunicación
7. Prevención y mejora
8. Recursos y referencias

5.1. Objetivo

Debe explicar qué se pretende conseguir.

Ejemplo

En ransomware, el objetivo es frenar el cifrado, proteger copias de seguridad, preservar evidencias, recuperar servicios críticos y reducir la probabilidad de reinfección.

5.2. Criterios de activación

Indican cuándo se usa el playbook.

Ejemplos:

  • nota de rescate;
  • cifrado masivo de archivos;
  • alerta EDR de comportamiento de ransomware;
  • cuenta enviando correos sospechosos;
  • defacement visible en una web pública;
  • inicio de sesión imposible o desde ubicación anómala;
  • proveedor notificando compromiso.

5.3. Investigación

La investigación busca entender alcance, impacto, vector y evidencias. Debe plantear preguntas concretas.

Preguntas de investigación

- ¿Qué sistemas están afectados?
- ¿Qué cuentas aparecen implicadas?
- ¿Cuándo empezó?
- ¿Cuál es el vector probable?
- ¿Hay datos accedidos, modificados, cifrados o exfiltrados?
- ¿Qué IoC se han observado?
- ¿Qué hipótesis tienen mayor confianza?

5.4. Remediación: contención y erradicación

La remediación debe separar contención y erradicación:

  • contención: frenar el daño y evitar propagación;
  • erradicación: eliminar causa, persistencia y vulnerabilidades explotadas.

No mezclar fases

Si un playbook mezcla contención, erradicación y recuperación sin orden, puede llevar a restaurar sistemas antes de haber eliminado el acceso del atacante.

5.5. Recuperación

La recuperación devuelve servicios a operación normal, pero con validaciones:

  • restaurar desde fuentes confiables;
  • comprobar integridad;
  • validar funcionalidad;
  • reforzar monitorización;
  • confirmar con la persona propietaria del servicio;
  • documentar la vuelta a la normalidad.

5.6. Comunicación

Cada playbook debe indicar qué comunicación específica requiere ese incidente. No comunica igual un phishing interno que una fuga de datos o un defacement público.

6. Plantilla breve de playbook

Playbook: [NOMBRE]

Objetivo
    [Qué queremos conseguir y qué daño queremos limitar]

Criterios de activación
    [Alertas, síntomas o condiciones que activan el playbook]

Investigación
    1. [Pregunta o acción de análisis]
    2. [Fuente de datos]
    3. [Evidencia que debe preservarse]

Contención
    1. [Acción inmediata]
    2. [Responsable]
    3. [Riesgo o validación]

Erradicación
    1. [Eliminar causa]
    2. [Corregir vulnerabilidad]
    3. [Rotar credenciales o secretos si aplica]

Recuperación
    1. [Restaurar servicio]
    2. [Validar integridad]
    3. [Monitorizar]

Comunicación
    1. [A quién se informa]
    2. [Qué se comunica]
    3. [Quién aprueba]

Mejora
    1. [Acciones preventivas]
    2. [Actualización de detecciones]
    3. [Cambios en formación o controles]

7. Ejemplo didáctico: playbook de phishing

Bloque Contenido
Activación Usuario reporta correo sospechoso, alerta del gateway o campaña detectada por terceros.
Investigación Analizar cabeceras, remitente, dominios, URLs, adjuntos, destinatarios y usuarios que interactuaron.
Contención Bloquear URLs, dominios, remitentes y hashes; purgar mensajes; revocar sesiones si hubo credenciales.
Erradicación Eliminar reglas maliciosas, aplicaciones OAuth sospechosas y persistencia en buzones.
Recuperación Restablecer accesos, revisar actividad posterior y reforzar controles de correo e identidad.
Comunicación Avisar a usuarios afectados, soporte, dirección si procede y terceros si hubo suplantación.
Mejora Actualizar reglas SIEM, simulaciones de phishing y formación con ejemplos reales.

8. Ejemplo didáctico: playbook de ransomware

Bloque Contenido
Activación Archivos cifrados, nota de rescate, alerta EDR, caída anómala de servicios o indicios de doble extorsión.
Investigación Identificar variante, paciente cero, sistemas afectados, cuentas usadas, backups en riesgo y posible exfiltración.
Contención Aislar equipos, cortar propagación, proteger backups, deshabilitar cuentas comprometidas y bloquear IoC.
Erradicación Eliminar malware, persistencia, herramientas del atacante y vulnerabilidades explotadas.
Recuperación Restaurar desde copias limpias, validar servicios críticos y monitorizar actividad posterior.
Comunicación Coordinar dirección, legal, comunicación, responsables de servicio, proveedores y organismos competentes si procede.
Mejora Reforzar MFA, segmentación, EDR, copias offline, parches y ejercicios de recuperación.

9. Relación con la práctica del repositorio plantilla

La práctica se apoya en:

Dentro de ese repositorio, la carpeta playbooks/ contiene ejemplos adaptables:

Archivo Tipo de incidente trabajado
playbook-phishing.md Phishing, robo de credenciales y fraude por correo.
playbook-ransomware.md Cifrado, extorsión y destrucción de información.
playbook-identity-and-access.md Compromiso de cuentas, sesiones, tokens e IAM.
playbook-defacement.md Alteración de sitios web públicos.
playbook-supply-chain.md Compromiso de proveedor o cadena de suministro.
index.md Introducción y criterio para añadir nuevos playbooks.

Actividad sugerida

Elegid dos playbooks del repositorio, identificad sus criterios de activación, separad acciones de investigación, contención, erradicación, recuperación y comunicación, y proponed qué runbooks técnicos harían falta para ejecutarlos.

10. Cómo convertir un playbook en runbooks

Un playbook suele necesitar varios runbooks. Por ejemplo, el playbook de phishing puede requerir:

Runbook Tarea concreta
Búsqueda de correo Localizar mensajes por asunto, remitente, hash o URL.
Purga de buzones Retirar mensajes de buzones afectados.
Revocación de sesiones Cerrar sesiones activas en el proveedor de identidad.
Rotación de credenciales Forzar cambio de contraseña y revisar MFA.
Bloqueo de IoC Añadir dominios, URLs, IPs o hashes a controles defensivos.

Un runbook debe incluir:

  • herramienta utilizada;
  • permisos necesarios;
  • pasos exactos;
  • validación de éxito;
  • riesgos;
  • rollback o forma de deshacer si procede;
  • evidencias que deben conservarse.

11. Checklist de calidad de un playbook

Antes de dar por bueno un playbook, comprueba que:

  • tiene criterios claros de activación;
  • está alineado con el plan general;
  • separa investigación, contención, erradicación, recuperación y comunicación;
  • indica responsables o equipos implicados;
  • contempla evidencias e IoC;
  • evita acciones destructivas sin validación;
  • incluye comunicación interna y externa si procede;
  • propone medidas de mejora;
  • enlaza runbooks técnicos cuando hacen falta;
  • se prueba mediante ejercicios de mesa o simulacros;
  • se actualiza tras lecciones aprendidas.

12. Errores frecuentes

Error Por qué es un problema Cómo evitarlo
Copiar un playbook genérico sin adaptarlo. No encaja con herramientas, roles ni riesgos reales. Personalizarlo con activos, contactos y procedimientos propios.
Mezclar playbook y runbook. El documento queda demasiado largo o demasiado técnico. Separar guía táctica y pasos operativos.
No definir activación. El equipo no sabe cuándo usarlo. Añadir síntomas, alertas y umbrales claros.
No contemplar comunicación. Puede haber mensajes tardíos o contradictorios. Incluir responsables y aprobaciones.
No probarlo. Los fallos aparecen durante la crisis. Hacer ejercicios de mesa y simulacros.

13. Resumen

En este tema has aprendido que:

  • el playbook aplica el plan a un tipo concreto de incidente;
  • el runbook describe tareas técnicas repetibles;
  • los playbooks deben priorizarse por riesgo, probabilidad e impacto;
  • un buen playbook separa investigación, contención, erradicación, recuperación y comunicación;
  • el repositorio de práctica ofrece ejemplos reales para construir y adaptar playbooks.

Idea clave

Un playbook útil no intenta cubrir todos los detalles técnicos. Ordena la respuesta para un tipo de incidente y enlaza los runbooks necesarios para ejecutar tareas concretas con seguridad.

Fuentes y referencias

Presentación

Slides

Este documento no tiene todavía una presentación Reveal.js asociada.