Construcción de Playbooks de Respuesta a Incidentes

¿Qué hace Construcción de Playbooks de Respuesta a Incidentes?

Cuándo Usarlo

• Establecer o madurar un programa de respuesta a incidentes desde cero
• Documentar procedimientos para un nuevo tipo de incidente después de un ataque novedoso
• Automatizar flujos de trabajo de respuesta en una plataforma SOAR (Cortex XSOAR, Splunk SOAR)
• Prepararse para auditorías de cumplimiento que requieren procedimientos de IR documentados (SOC 2, PCI-DSS, HIPAA)
• Realizar un análisis de brechas de las capacidades de IR existentes frente a escenarios de amenazas específicos

No usar para investigaciones puntuales ad hoc; los playbooks son documentos de procedimiento reutilizables, no informes específicos de casos.

Prerrequisitos

• Evaluación de riesgos organizacional que identifique los principales escenarios de incidentes por probabilidad e impacto
• Marco NIST SP 800-61r3 o SANS PICERL adoptado como estándar de IR organizacional
• Inventario de activos con clasificaciones de criticidad empresarial y clasificación de datos
• Diagrama RACI que defina roles: Comandante de Incidentes, analistas SOC, administradores de sistemas, legal, comunicaciones
• Inventario de capacidades de detección existentes (reglas SIEM, detecciones EDR, firmas IDS)
• Acceso a la plataforma SOAR si se construyen playbooks automatizados

Flujo de Trabajo

Paso 1: Seleccionar y Definir el Alcance del Tipo de Incidente

Definir el escenario específico que abordará el playbook:

• Identificar los principales tipos de incidentes según la evaluación de riesgos organizacional y datos históricos
• Limitar cada playbook a un solo tipo de incidente para mayor claridad (no combinar escenarios no relacionados)
• Definir las condiciones de activación que inician el playbook

Tipos de playbook comunes:

Playbooks Prioritarios (construir primero):
1. Respuesta a incidentes de ransomware
2. Phishing/compromiso de credenciales
3. Compromiso de correo electrónico corporativo
4. Infección de malware
5. Filtración/exfiltración de datos
6. Ataque DDoS
7. Amenaza interna
8. Toma de control de cuentas
9. Compromiso de aplicación web
10. Compromiso de infraestructura en la nube

Paso 2: Definir la Estructura del Playbook

Cada playbook debe seguir una estructura consistente:

PLANTILLA DE PLAYBOOK
━━━━━━━━━━━━━━━━━━━━
1. Metadatos del Playbook
   - Nombre, versión, propietario, fecha de última revisión
   - Condiciones de activación
   - Criterios de severidad

2. Matriz RACI
   - Quién es Responsable, Responsable Último, Consultado, Informado para cada paso

3. Detección y Triaje
   - Cómo se detecta el incidente
   - Lista de verificación de triaje inicial
   - Criterios de clasificación de severidad

4. Contención
   - Acciones de contención a corto plazo
   - Acciones de contención a largo plazo
   - Requisitos de preservación de evidencia

5. Erradicación
   - Identificación de la causa raíz
   - Pasos para eliminar malware/amenaza
   - Procedimientos de verificación

6. Recuperación
   - Pasos de restauración del sistema
   - Criterios de validación
   - Requisitos de monitoreo post-recuperación

7. Post-Incidente
   - Disparador de reunión de lecciones aprendidas
   - Plantilla de informe
   - Acciones de mejora de detección

8. Comunicación
   - Matriz de notificación interna
   - Requisitos de notificación externa (reguladores, clientes, fuerzas del orden)
   - Cadencia de actualización de estado

9. Apéndices
   - Procedimientos específicos de herramientas
   - Listas de contactos
   - Listas de verificación de recolección de evidencia

Paso 3: Escribir Árboles de Decisión y Criterios de Escalación

Definir puntos de decisión claros con resultados binarios:

Alerta de Detección Recibida
├── ¿Es la alerta un verdadero positivo?
│   ├── SÍ → Clasificar severidad
│   │   ├── P1 (Crítico) → Llamar al comandante de incidentes, iniciar contención inmediatamente
│   │   ├── P2 (Alto) → Notificar al líder de IR, iniciar investigación en 30 min
│   │   ├── P3 (Medio) → Encolar para investigación en 4 horas
│   │   └── P4 (Bajo) → Documentar e investigar en 24 horas
│   └── NO → Documentar como falso positivo, ajustar regla de detección
└── No se puede determinar → Escalar a Nivel 2 para análisis más profundo

Disparadores de escalación:

• Cualquier incidente P1: Escalación inmediata al líder de IR y al CISO
• Exfiltración de datos confirmada: Notificar al asesor legal y al responsable de privacidad
• Datos de clientes involucrados: Activar proceso de notificación al cliente
• Participación de terceros: Contactar al contacto de seguridad del proveedor
• Fuerzas del orden necesarias: El asesor legal general autoriza antes del contacto

Paso 4: Definir Procedimientos Técnicos Específicos

Escribir instrucciones específicas de la herramienta para cada paso (no orientación genérica):

CONTENCIÓN - Aislamiento de Endpoint mediante CrowdStrike:
1. Abrir Falcon Console > Hosts > Buscar el nombre del host afectado
2. Hacer clic en el host > Detalles del host
3. Hacer clic en el botón "Contener Host" en la esquina superior derecha
4. Confirmar el aislamiento (el host solo se comunicará con la nube de CrowdStrike)
5. Documentar la acción de contención en el ticket del incidente con marca de tiempo
6. Verificar la contención: El host debe mostrar la insignia de estado "Contenido"

CONTENCIÓN - Bloquear dominio C2 en DNS:
1. SSH al servidor DNS: ssh [email protected]
2. Agregar a la zona de bloqueo: echo "zone evil.com { type master; file /etc/bind/db.sinkhole; };" >> /etc/bind/named.conf.local
3. Recargar DNS: rndc reload
4. Verificar: dig @dns-primary evil.com (debe resolver a IP del sumidero 10.0.0.99)
5. Documentar el dominio bloqueado en el ticket del incidente

Paso 5: Integrar con la Plataforma SOAR

Convertir los pasos manuales del playbook en flujos de trabajo automatizados:

• Mapear cada paso del playbook a una acción SOAR (llamada API, script, punto de decisión humana)
• Definir los límites de automatización (qué se ejecuta automáticamente vs. qué requiere aprobación del analista)
• Crear automatizaciones de enriquecimiento para la fase de triaje
• Crear automatizaciones de contención con puertas de aprobación para acciones de alto impacto
• Configurar automatizaciones de notificación para la comunicación con las partes interesadas

Paso 6: Probar y Mantener el Playbook

Validar el playbook mediante ejercicios y mantenerlo actualizado:

• Realizar ejercicios de mesa con el equipo de IR recorriendo el playbook
• Realizar ejercicios con fuego real simulando el tipo de incidente en un entorno de prueba
• Revisar y actualizar después de cada incidente real que utilice el playbook
• Programar revisiones trimestrales para verificar la precisión de las listas de contactos, procedimientos de herramientas y rutas de escalación
• Realizar seguimiento de métricas del playbook: tiempo medio para contener, tiempo medio para resolver, tasa de falsos positivos

Conceptos Clave

Término	Definición
Playbook	Conjunto documentado y repetible de procedimientos para responder a un tipo específico de incidente
Runbook	Más granular que un playbook; instrucciones técnicas paso a paso para una tarea específica dentro de un playbook
Matriz RACI	Diagrama de asignación de responsabilidades que define quién es Responsable, Responsable Último, Consultado e Informado para cada actividad
Árbol de Decisión	Lógica basada en diagramas de flujo que define la ruta de respuesta según condiciones binarias en cada punto de decisión
Criterios de Escalación	Condiciones predefinidas que activan la notificación de personal de nivel superior o partes externas
Playbook SOAR	Flujo de trabajo automatizado en una plataforma de Orquestación, Automatización y Respuesta de Seguridad que ejecuta los pasos del playbook

Herramientas y Sistemas

• Cortex XSOAR: Plataforma SOAR con editor visual de playbooks, más de 700 integraciones y Sala de Guerra colaborativa
• Splunk SOAR: Plataforma SOAR integrada con Splunk ES, creador de playbooks de arrastrar y soltar con más de 2,800 acciones automatizadas
• TheHive: Plataforma de respuesta a incidentes de código abierto con plantillas de casos que funcionan como marcos de playbook
• Confluence / GitLab Wiki: Plataformas de documentación para mantener documentos de playbook legibles por humanos con control de versiones
• Tines: Plataforma de automatización de seguridad sin código para construir flujos de trabajo de playbook sin programación

Escenarios Comunes

Escenario: Construcción de un Playbook de Respuesta a Phishing desde Cero

Contexto: Una organización con un SOC de 5 personas no tiene un procedimiento documentado de respuesta a phishing. Los analistas manejan los informes de phishing de manera inconsistente.

Enfoque:

1. Entrevistar a los analistas del SOC para documentar su proceso ad hoc actual
2. Definir el disparador: el usuario reporta un correo de phishing a través del buzón abuse@ o del botón de phishing
3. Escribir pasos de triaje: extraer encabezados del correo, verificar reputación del remitente, analizar URL/archivos adjuntos en un entorno sandbox
4. Definir contención: poner en cuarentena el correo de todos los buzones, bloquear el dominio del remitente, restablecer contraseñas si se ingresaron credenciales
5. Construir automatización SOAR: extraer automáticamente los IOCs del correo reportado, enriquecer mediante VirusTotal, crear un caso en TheHive
6. Probar con un correo de phishing simulado y medir la mejora en el tiempo de respuesta

Errores comunes:

• Escribir procedimientos demasiado genéricos que no hagan referencia a interfaces o comandos específicos de herramientas
• No incluir el plan de comunicación para notificar a los usuarios que recibieron el correo de phishing
• Olvidar definir los criterios para determinar cuándo un informe de phishing se convierte en una investigación de incidente completa
• No versionar el playbook ni programar ciclos de revisión regulares

Formato de Salida

PLAYBOOK DE RESPUESTA A INCIDENTES
====================================
Nombre del Playbook:    Respuesta a Incidentes de Phishing
Versión:               2.1
Propietario:           Administrador del SOC
Última Revisión:       2025-11-01
Próxima Revisión:      2026-02-01
Disparador:            Correo de phishing reportado a través de [email protected] o botón de phishing

MATRIZ RACI
Actividad                | SOC L1 | SOC L2 | Líder IR | Legal | Comunicaciones
Triaje Inicial          |   R    |   C    |   I      |       |
Análisis de Correo      |   R    |   A    |   I      |       |
Contención              |        |   R    |   A      |   I   |
Restablecimiento de Credenciales |        |   R    |   A      |       |
Notificación al Usuario |        |   C    |   A      |       |   R
Notificación Regulatoria|        |        |   C      |   R   |   A
Lecciones Aprendidas    |   C    |   C    |   R      |   I   |   I

PASOS DEL PROCEDIMIENTO
[Pasos detallados con instrucciones específicas de la herramienta]

ÁRBOL DE DECISIÓN
[Lógica del diagrama de flujo]

MATRIZ DE ESCALACIÓN
[Condiciones y contactos]

MÉTRICAS
Tiempo Medio para Actuar (MTTA) Objetivo: 15 minutos
Tiempo Medio para Contener (MTTC) Objetivo: 1 hora
Tiempo Medio para Resolver (MTTR) Objetivo: 4 horas