Automatización de respuesta a incidentes con SOAR y playbooks

[INFO] Este artículo está diseñado para administradores de sistemas, analistas de seguridad y responsables de SOC que buscan madurar sus procesos de respuesta a incidentes mediante la automatización. Se asume un conocimiento básico de SIEM y orquestación.

La ciberseguridad moderna se enfrenta a un diluvio de alertas. Un SOC medio puede recibir miles de eventos al día, muchos de ellos falsos positivos o incidentes de baja criticidad. Responder manualmente a cada uno es insostenible. Aquí es donde entra en juego la automatización de la respuesta a incidentes, y su máximo exponente son las plataformas SOAR (Security Orchestration, Automation and Response) y los playbooks.

Este artículo es una guía técnica para entender, diseñar e implementar un pipeline de respuesta automatizada, utilizando MITRE ATT&CK como lenguaje común y los playbooks como motor de ejecución.

---

¿Qué es SOAR y por qué necesitas uno?

SOAR no es solo una herramienta; es una metodología. Combina tres capacidades clave:

• Orquestación: Conecta herramientas dispares (SIEM, EDR, Firewall, Ticketing, Threat Intelligence). Un SOAR actúa como el sistema nervioso central, enviando comandos y recogiendo datos de múltiples fuentes.
• Automatización: Ejecuta tareas repetitivas sin intervención humana. Por ejemplo, aislar un host, bloquear una IP en el firewall o buscar un hash en VirusTotal.
• Respuesta: Gestiona el ciclo de vida completo de un incidente, desde la detección hasta la post-mortem, incluyendo la creación de tickets y la notificación a las partes interesadas.

El problema de la respuesta manual

Sin SOAR, la respuesta a incidentes suele ser:

1. Un analista ve una alerta en el SIEM.
2. Abre un ticket.
3. Accede manualmente a la consola del EDR para aislar el endpoint.
4. Consulta la IP en una base de datos de Threat Intelligence.
5. Escribe un informe.
6. Cierra el ticket.

Este proceso puede llevar de 15 a 60 minutos. En ese tiempo, un ransomware puede haberse propagado a todo el dominio. SOAR reduce ese tiempo a segundos.

---

Playbooks: El corazón de la automatización

Un playbook es un conjunto de pasos predefinidos y automatizados que se ejecutan en respuesta a un evento específico. Piensa en ellos como una receta de cocina: ingredientes (herramientas), pasos (acciones) y un resultado esperado (contención del incidente).

Estructura de un playbook

Un playbook bien diseñado debe incluir:

• Trigger: ¿Qué evento lo inicia? (Ej: una alerta de alta criticidad de un EDR).
• Condiciones: ¿Se cumplen los requisitos para ejecutarlo? (Ej: el host está en producción, no es un servidor crítico).
• Acciones: Secuencia de pasos a ejecutar.
• Decisiones: Puntos donde el flujo se bifurca según el resultado de una acción.
• Salidas: ¿Qué se genera? (Ticket, informe, notificación).

Tipos de playbooks

Tipo	Descripción	Ejemplo
Reactivo	Se ejecuta ante una alerta.	Aislar un endpoint infectado.
Proactivo	Se ejecuta de forma programada.	Escanear en busca de vulnerabilidades.
Investigativo	Ayuda al analista a recopilar datos.	Enriquecer un IOC con fuentes externas.
Contención	Detiene la progresión del ataque.	Bloquear una IP maliciosa en el firewall.

---

Integración con MITRE ATT&CK: El lenguaje común

No basta con automatizar; hay que hacerlo de forma inteligente. MITRE ATT&CK proporciona un marco de tácticas y técnicas que permite categorizar los ataques. Al integrar ATT&CK en tus playbooks, consigues:

• Contexto: Sabes qué técnica se está utilizando (ej: T1059.001 - PowerShell).
• Priorización: Las técnicas asociadas a grupos APT de alto riesgo pueden tener un playbook más agresivo.
• Métrica: Puedes medir qué técnicas estás automatizando y cuáles no.

Ejemplo práctico: Playbook para T1566.001 (Phishing con Spearphishing Attachment)

Supongamos que un usuario reporta un correo sospechoso. El playbook se activa.

1. Trigger: Alerta de phishing desde el SIEM o un botón de "Reportar phishing".
2. Enriquecimiento (Automático):
   • Extrae el hash del adjunto.
   • Consulta VirusTotal, Hybrid Analysis y AbuseIPDB.
   • Identifica la técnica MITRE ATT&CK: T1566.001.
3. Decisión:
   • Si el hash es malicioso (score > 5 en VT) -> Contención automática.
   • Si el score es dudoso -> Escalado a analista.
4. Contención:
   • Elimina el correo de todos los buzones de la organización (vía API de Exchange/Graph).
   • Bloquea el hash en el EDR (si se ejecutó).
   • Aísla el host del usuario que lo reportó (medida preventiva).
5. Salida:
   • Crea un ticket en Jira/Servicenow.
   • Envía un informe al CISO.

[TIP] Mapea cada paso de tu playbook a una técnica de MITRE ATT&CK. Esto te permitirá generar informes de "cobertura de automatización" y justificar inversiones.

---

Implementación práctica: De la teoría al código

Paso 1: Identificar casos de uso de alto volumen

No automatices todo. Empieza por los incidentes que más tiempo consumen y que tienen una respuesta binaria (sí/no). Ejemplos ideales:

• Detección de malware conocido: Hash malicioso en VirusTotal -> Aislar host.
• Escaneo de puertos externos: IP que escanea > 100 puertos en 5 minutos -> Bloquear en firewall.
• Inicios de sesión desde ubicaciones imposibles: Usuario loguea desde EEUU y 5 minutos después desde Rusia -> Forzar MFA y deshabilitar cuenta temporalmente.

Paso 2: Diseñar el playbook en pseudocódigo

Antes de tocar la UI de tu SOAR, escribe el flujo. Por ejemplo, para un playbook de "Aislamiento por detección de ransomware":

# Playbook: ransomware_isolation_v1
# Trigger: Alerta "RansomwareBehavior" desde EDR (CrowdStrike/SentinelOne)

1. Obtener detalles del host (nombre, IP, usuario) desde el payload de la alerta.
2. Consultar CMDB (ServiceNow) para saber si el host es crítico.
   -> Si es crítico: Crear ticket P1 y notificar al equipo de turno. FIN.
   -> Si no es crítico: Continuar.
3. Ejecutar acción en EDR: "Isolate Host" (API POST).
4. Esperar confirmación de aislamiento (máx. 30 segundos).
   -> Si falla: Escalar a analista.
5. Bloquear IP del host en el firewall de perímetro (Palo Alto/Fortinet) para evitar propagación por red.
6. Capturar un snapshot de memoria (Forensics) del host.
7. Crear ticket en Jira con todos los datos recopilados.
8. Enviar notificación a Slack al canal #sec-incidents.
9. Registrar el incidente en SIEM como "Contenido automáticamente".

Paso 3: Configurar las integraciones en la plataforma SOAR

Las principales plataformas (Splunk SOAR, Palo Alto XSOAR, IBM Resilient, TheHive/Cortex) funcionan con conectores o apps. Cada acción del playbook se traduce en una llamada API.

Ejemplo de configuración de un conector para un firewall:

# Ejemplo de entrada de configuración para un playbook en XSOAR
name: "Block IP on Firewall"
instance_name: "PaloAlto_Panorama_Prod"
parameters:
  ip_address: ${incident.sourceip}
  rule_name: "SOAR_Blocked_IPs"
  vsys: "vsys1"
  action: "drop"
  timeout: 30

Paso 4: Probar en un entorno sandbox

NUNCA despliegues un playbook en producción sin probarlo. Usa un entorno aislado donde puedas simular ataques (por ejemplo, con Atomic Red Team).

# Simular la técnica T1059.001 (PowerShell) para probar el playbook
Invoke-AtomicTest T1059.001

[WARNING] Un playbook mal diseñado puede causar una denegación de servicio. Por ejemplo, aislar a un CEO o bloquear la IP de un servicio cloud crítico. Implementa aprobación humana para acciones destructivas.

---

Métricas y mejora continua

La automatización no es un proyecto de "configurar y olvidar". Debes medir su eficacia.

KPI clave para SOAR

1. Tiempo medio de respuesta (MTTR): Antes y después de SOAR.
2. Tasa de automatización: % de incidentes resueltos sin intervención humana. Un objetivo realista es 70-80% para incidentes de baja criticidad.
3. Tasa de falsos positivos automatizados: ¿Cuántas veces el playbook actuó sobre un falso positivo? Esto ayuda a ajustar los triggers.
4. Tasa de escalado: % de incidentes que requirieron un analista. Si es > 30%, el playbook es demasiado conservador.

Ciclo de vida de un playbook

1. Diseño: Basado en un caso de uso real.
2. Implementación: Código y conectores.
3. Prueba: Simulación con Atomic Red Team o similar.
4. Despliegue: En producción, inicialmente en modo "solo monitorización" (sin acciones automáticas).
5. Revisión: Analiza los logs de ejecución. ¿Se saltó algún paso? ¿Hubo errores de API?
6. Iteración: Ajusta condiciones, tiempos de espera o acciones.

Conclusión

La automatización de respuesta a incidentes con SOAR y playbooks es el siguiente paso lógico para cualquier organización que maneje un volumen significativo de alertas de seguridad. No se trata de sustituir al analista, sino de liberarlo de tareas repetitivas para que se centre en la caza de amenazas y la investigación profunda.

Al integrar MITRE ATT&CK en tus playbooks, no solo automatizas, sino que lo haces con inteligencia táctica, alineando tu respuesta con el marco de referencia más utilizado en la industria.

El camino es claro: empieza pequeño, mide cada paso y escala. Tu SOC (y tu sueño) te lo agradecerán.