SOAR: Qué Es, Arquitectura y Diseño de Playbooks de Automatización

Qué es SOAR y por qué importa

Un SOC sin automatización es un SOC abrumado. Un analista N1 recibe entre 50 y 200 alertas diarias. El 80% son falsos positivos o alertas de baja prioridad que requieren los mismos pasos repetitivos: consultar el IOC en VirusTotal, verificar si la IP es de un proveedor conocido, comprobar si el usuario es VIP, documentar en el ticket. Sin automatización, el analista dedica el 70% de su tiempo a tareas que no requieren criterio humano.

SOAR (Security Orchestration, Automation and Response) aborda este problema con tres capacidades integradas:

Orquestación. Conecta las herramientas del SOC (SIEM, EDR, firewall, CTI, ticketing) mediante APIs. En lugar de saltar entre 10 consolas, el SOAR centraliza las acciones en una interfaz unificada.

Automatización. Ejecuta playbooks que replican los procedimientos manuales del analista. Un playbook de triaje de phishing puede extraer URLs del correo, consultar VirusTotal, verificar el dominio en listas negras, y clasificar la severidad, todo en segundos.

Respuesta. Gestiona el ciclo de vida del incidente: desde la detección hasta el cierre. Incluye case management, evidencia, timeline de acciones, métricas de rendimiento y post-mortem.

El resultado medible: los SOCs que implementan SOAR reducen el tiempo medio de respuesta (MTTR) entre un 50% y un 90%, y liberan al analista para tareas que realmente necesitan juicio humano.

---

SOAR vs SIEM vs XDR

Estas tres tecnologías se solapan parcialmente, lo que genera confusión. La distinción fundamental:

Capacidad	SIEM	SOAR	XDR
Ingesta de logs	Masiva (todas las fuentes)	Limitada (alertas del SIEM)	Selectiva (endpoints, red, cloud)
Correlación de eventos	Avanzada (reglas, ML)	Básica (playbook logic)	Nativa (datos propios)
Detección	Core (alertas, anomalías)	No (consume alertas)	Core (ML integrado)
Automatización de respuesta	Básica	Core (playbooks)	Parcial (acciones predefinidas)
Case management	Limitado	Core	Limitado
Integraciones	Ingesta (syslog, API)	Bidireccional (orquesta)	Ecosistema del vendor
Complejidad de playbooks	Baja	Alta (branching, HITL)	Media

SIEM detecta. SOAR responde. XDR hace ambas cosas dentro del ecosistema de un vendor.

En la práctica, la combinación más común en SOCs maduros es SIEM + SOAR: el SIEM genera alertas, el SOAR las procesa y automatiza la respuesta. XDR es una alternativa integrada para organizaciones que prefieren un solo vendor (CrowdStrike, Palo Alto, Microsoft Sentinel + Defender).

---

Arquitectura de un SOAR

Un SOAR tiene cuatro componentes principales que trabajan juntos:

1. Motor de orquestación (Orchestration Engine)

El cerebro del sistema. Ejecuta los playbooks, gestiona el estado de cada ejecución, maneja reintentos y timeouts, y coordina las llamadas a servicios externos.

Características clave:

• Ejecución paralela. Acciones independientes se ejecutan simultáneamente (consultar VT y AbuseIPDB al mismo tiempo).
• Gestión de estado. Cada ejecución tiene un estado (running, completed, failed, waiting_for_approval) y un historial completo de acciones.
• Circuit breakers. Si una API externa falla repetidamente, el motor desactiva las llamadas temporalmente en lugar de bloquear todo el playbook.

2. Playbooks

Flujos de trabajo que definen la lógica de respuesta. Un playbook típico tiene:

• Trigger: qué evento lo activa (alerta SIEM, email, webhook, schedule).
• Inputs: datos de entrada (IP, hash, ID de alerta, correo completo).
• Steps: secuencia de acciones y decisiones.
• Decision nodes: bifurcaciones basadas en condiciones (si abuse_score > 75, escalar).
• Actions: llamadas a APIs, consultas a SIEM, bloqueo en firewall, envío de email.
• HITL (Human-in-the-Loop): puntos donde se requiere aprobación humana antes de continuar.
• Outputs: resultados finales (ticket creado, IP bloqueada, informe generado).

3. Integraciones (Apps)

Cada herramienta del SOC se conecta al SOAR mediante una integración (app). Ejemplos:

Categoría	Herramientas
SIEM	Splunk, QRadar, Elastic, Sentinel
EDR	CrowdStrike, SentinelOne, Carbon Black
Firewall	Palo Alto, Fortinet, Check Point
CTI	VirusTotal, MISP, OTX, Shodan
Email	Exchange, Gmail, Proofpoint
Ticketing	Jira, ServiceNow, TheHive
Comunicación	Slack, Teams, PagerDuty
IAM	Active Directory, Okta, Azure AD

Cada integración expone acciones que los playbooks pueden invocar: "bloquear IP en firewall", "aislar endpoint en EDR", "crear ticket en Jira", "enviar mensaje a Slack".

4. Case Management

Gestión del ciclo de vida del incidente dentro del SOAR:

• Creación automática de caso cuando un playbook detecta un incidente real.
• Timeline de acciones (qué se hizo, cuándo, quién lo aprobó).
• Evidencia adjunta (logs, capturas, resultados de enrichment).
• Métricas (tiempo de respuesta, playbooks ejecutados, tasa de falsos positivos).
• Post-mortem y lecciones aprendidas.

---

Diseño de playbooks: principios y patrones

Diseñar un buen playbook requiere pensar como un analista experimentado y codificar su proceso de decisión. Estos son los principios fundamentales:

Principio 1: Empezar por el SOP manual

Antes de automatizar, documenta el procedimiento que sigue el analista manualmente. Si no existe un procedimiento claro, no tiene sentido automatizarlo. El playbook debe replicar la lógica del analista, no inventar una nueva.

Principio 2: Decision trees explícitos

Cada bifurcación del playbook debe tener condiciones claras y documentadas:

SI detecciones_VT > 10 Y abuse_score > 50:
    → Clasificar como MALICIOSO
    → Ejecutar contención automática
    → Notificar al equipo
SI detecciones_VT entre 1 y 10:
    → Clasificar como SOSPECHOSO
    → Escalar a analista N2
    → Adjuntar enrichment al ticket
SI detecciones_VT == 0 Y abuse_score == 0:
    → Clasificar como FALSO POSITIVO
    → Cerrar alerta con razón documentada
    → Actualizar whitelist si recurrente

Principio 3: HITL en acciones destructivas

La automatización completa tiene límites. Acciones que afectan la disponibilidad (bloquear una IP, aislar un endpoint, desactivar una cuenta) deben requerir aprobación humana:

ACCIONES AUTOMÁTICAS (sin aprobación):
  - Enriquecer IOC (consultar APIs CTI)
  - Crear ticket
  - Enviar notificación informativa
  - Clasificar severidad
  - Recopilar evidencia

ACCIONES CON APROBACIÓN (HITL):
  - Bloquear IP en firewall
  - Aislar endpoint de la red
  - Desactivar cuenta de usuario
  - Borrar correo de buzones
  - Ejecutar respuesta activa en EDR

La excepción: ataques de alta confianza con impacto inmediato (ransomware confirmado, C2 activo) pueden justificar contención automática. Esto requiere calibración cuidadosa y reglas estrictas.

Principio 4: Idempotencia

Un playbook debe poder ejecutarse varias veces sobre la misma alerta sin efectos secundarios. Si la IP ya está bloqueada, no intentar bloquearla de nuevo. Si el ticket ya existe, actualizarlo en lugar de crear uno duplicado.

Principio 5: Fallar con gracia

Si una API externa no responde, el playbook no debe detenerse completamente. Debe registrar el fallo, continuar con las fuentes disponibles, y marcar el resultado como incompleto:

TRY: consultar VirusTotal
  SI timeout: marcar "VT: no disponible"
  SI error: registrar y continuar
TRY: consultar AbuseIPDB
  SI timeout: marcar "AbuseIPDB: no disponible"
  SI error: registrar y continuar
EVALUAR: con los datos disponibles
  SI ninguna fuente respondió: escalar a analista

---

Casos de uso principales

1. Triaje de phishing

El caso de uso más común y con mayor ROI. Un correo sospechoso reportado por un usuario activa el playbook:

1. Extraer metadatos del correo (remitente, asunto, headers).
2. Extraer URLs y adjuntos del cuerpo.
3. Consultar URLs en VirusTotal y URLhaus.
4. Verificar dominio del remitente (SPF, DKIM, DMARC, edad del dominio).
5. Analizar adjuntos (hash lookup, sandbox si disponible).
6. Clasificar: phishing confirmado, sospechoso, o legítimo.
7. Si phishing confirmado: buscar en todos los buzones, borrar copias (con HITL), bloquear remitente, notificar al usuario.
8. Crear ticket con evidencia completa.

Tiempo manual: 15-30 minutos por correo. Tiempo con SOAR: 2-3 minutos (incluyendo aprobación HITL si es necesario).

2. IOC Enrichment automático

Cada alerta del SIEM que contiene un IOC (IP, hash, dominio) activa un enrichment automático:

1. Detectar tipo de IOC.
2. Consultar fuentes de CTI (VirusTotal, Shodan, AbuseIPDB, OTX, MISP).
3. Consolidar resultados y calcular score de riesgo.
4. Adjuntar enrichment al ticket original.
5. Si score alto: escalar y sugerir acciones de contención.

3. Triaje de alertas SIEM

El SIEM genera cientos de alertas. El SOAR filtra el ruido:

1. Recibir alerta del SIEM.
2. Verificar si el activo afectado es crítico (base de datos de activos).
3. Verificar si el usuario es VIP o cuenta de servicio.
4. Enriquecer los IOCs de la alerta.
5. Consultar alertas similares en los últimos 7 días (deduplicación).
6. Clasificar la prioridad (P1 a P4) basándose en los datos enriquecidos.
7. Si P1/P2: notificar inmediatamente al equipo por Slack/PagerDuty.
8. Si P3/P4: añadir a la cola del analista N1.

4. Desprovisión de usuario comprometido

Cuando se confirma que una cuenta ha sido comprometida:

1. Recibir confirmación del analista (HITL).
2. Desactivar cuenta en Active Directory/Azure AD.
3. Revocar tokens de sesión activos.
4. Bloquear acceso a VPN y aplicaciones cloud.
5. Forzar reset de contraseña.
6. Notificar al usuario por canal alternativo.
7. Recopilar logs de actividad de la cuenta (últimas 72h).
8. Crear ticket de incidente con timeline completa.

---

Plataformas SOAR: panorama actual

Palo Alto Cortex XSOAR

La plataforma enterprise más completa. Fortalezas: marketplace con mas de 800 integraciones, editor visual de playbooks, war room colaborativo, machine learning para clasificación de incidentes. Debilidad: precio elevado, curva de aprendizaje pronunciada.

Splunk SOAR (antes Phantom)

Integración nativa con Splunk SIEM. Fortalezas: ejecución paralela de acciones, comunidad activa, playbooks en Python. Debilidad: requiere Splunk como SIEM para máximo valor, licenciamiento complejo.

Tines

Plataforma low-code con enfoque en simplicidad. Fortalezas: tier gratuito generoso (Community Edition), interfaz intuitiva, no requiere programación para playbooks básicos, buen soporte de webhooks. Debilidad: menos integraciones prebuiltas que XSOAR, capacidades de case management limitadas.

Shuffle (Open Source)

SOAR open source basado en Docker. Fortalezas: gratuito, extensible, integración con TheHive/MISP/OpenCTI, API-first. Debilidades: menos pulido que las alternativas comerciales, documentación mejorable, requiere mantenimiento propio. El siguiente artículo de la serie profundiza en Shuffle.

TheHive + Cortex

Plataforma open source de case management (TheHive) con motor de análisis (Cortex). No es un SOAR completo, pero cubre case management y enrichment automático. Se integra bien con MISP para CTI.

Comparativa rápida

Criterio	XSOAR	Splunk SOAR	Tines	Shuffle	TheHive
Tipo	Comercial	Comercial	Freemium	Open Source	Open Source
Integraciones	800+	350+	100+	200+	Cortex analyzers
Editor visual	Avanzado	Avanzado	Intuitivo	Funcional	No (Cortex CLI)
Case management	Integrado	Integrado	Básico	Básico	Core
Python support	Nativo	Nativo	No	Apps Docker	Cortex
Precio entry	50K+ USD/año	50K+ USD/año	Gratuito	Gratuito	Gratuito

---

Métricas de ROI de un SOAR

Implementar un SOAR tiene coste (licencia, integración, desarrollo de playbooks, formación). Para justificar la inversión, estas son las métricas clave:

Métricas de eficiencia

• MTTR (Mean Time to Respond). Tiempo medio desde la detección hasta la contención. Antes del SOAR: 30-60 minutos. Después: 5-10 minutos. Reducción típica: 70-85%.
• Alertas procesadas por analista. Antes: 50-100/día. Después: 200-500/día (el SOAR cierra las triviales automáticamente).
• Tasa de falsos positivos auto-cerrados. Un SOAR maduro cierra automáticamente el 40-60% de las alertas que son falsos positivos confirmados.

Métricas de calidad

• Consistencia de triaje. El playbook aplica los mismos criterios siempre. Sin SOAR, dos analistas pueden clasificar la misma alerta de forma diferente.
• Cobertura de enrichment. Con SOAR: 100% de los IOCs se enriquecen automáticamente. Sin SOAR: depende de que el analista tenga tiempo.
• Documentación de incidentes. El SOAR registra cada acción con timestamp, autor y resultado. Sin SOAR: la documentación depende de la disciplina del analista.

Cálculo de ROI simplificado

Coste sin SOAR:
  4 analistas N1 × 45.000 EUR/año = 180.000 EUR
  Procesando 200 alertas/día (50 por analista)
  80% del tiempo en tareas repetitivas

Coste con SOAR:
  Licencia SOAR: 50.000 EUR/año (o 0 con open source)
  2 analistas N1 × 45.000 EUR = 90.000 EUR
  1 ingeniero SOAR × 55.000 EUR = 55.000 EUR
  Total: 195.000 EUR (o 145.000 EUR con open source)
  Procesando 500 alertas/día con mejor calidad

Ahorro: 35.000-85.000 EUR/año + mejor cobertura y menor riesgo

El ROI real suele ser mayor porque incluye la reducción de riesgo por respuesta más rápida, que es difícil de cuantificar pero significativa.

---

Errores comunes al implementar SOAR

Automatizar todo desde el principio. Empieza con 3-5 playbooks para los casos de uso de mayor volumen (phishing, enrichment, triaje). Añade complejidad gradualmente.

Ignorar los SOPs. Si no tienes procedimientos documentados, el SOAR amplificará el caos. Documenta los procesos manuales antes de automatizarlos.

No medir antes y después. Sin baseline de métricas (MTTR, alertas/día, tasa de FP), no puedes demostrar el ROI.

Playbooks sin HITL. Automatizar acciones destructivas sin aprobación humana es un riesgo operacional. Un falso positivo en un playbook de contención automática puede tumbar un servicio legítimo.

Dependencia de un solo vendor. Si tu SOAR solo funciona con un SIEM o EDR específico, pierdes flexibilidad. Prioriza plataformas con APIs abiertas e integraciones amplias.

---

Próximos pasos

El siguiente artículo pone en práctica estos conceptos con Shuffle, el SOAR open source más accesible. Instalarás Shuffle con Docker, construirás tu primer workflow de triaje de phishing, y lo integrarás con VirusTotal, TheHive y Slack.

---

Recursos

• Gartner Market Guide for SOAR. Análisis de mercado con evaluaciones de vendors.
• NIST SP 800-61: Computer Security Incident Handling Guide. Marco de referencia para respuesta a incidentes.
• Shuffle Documentation. Documentación del SOAR open source.
• TheHive Project. Plataforma open source de incident response.
• Tines Automation Stories. Biblioteca de playbooks listos para adaptar.
• MalwareIntel IOC Enrichment. Enriquecimiento de IOCs con datos de múltiples fuentes CTI.