SOAR: automatización de respuesta a incidentes con Shuffle, Tines y XSOAR

SOAR (Security Orchestration, Automation and Response) es la capa tecnológica que conecta todas las herramientas de un SOC — SIEM, EDR, firewall, email, identidad, ticketing — y ejecuta playbooks automatizados para responder a incidentes en minutos en lugar de horas. No reemplaza al analista: lo libera de las tareas repetitivas para que dedique su tiempo a decisiones que requieren criterio humano.

Un SOC sin SOAR repite los mismos pasos manuales decenas de veces al día: copiar un hash, buscarlo en VirusTotal, abrir un ticket, aislar un host, notificar al equipo. SOAR convierte esa secuencia en un workflow reproducible, auditable y medible. Esta lección explica los tres pilares del concepto, las plataformas principales (Shuffle, Tines, Cortex XSOAR), cómo diseñar playbooks efectivos, y qué métricas medir para demostrar el valor de la automatización. Es la séptima lección de la Tanda 8.

SOAR es tecnología defensiva pura: su objetivo es proteger infraestructura y reducir el tiempo de respuesta ante incidentes. Practica siempre en entornos autorizados y con datos de prueba.

Qué es SOAR#

SOAR integra tres capacidades que, por separado, ya existían en los SOC pero funcionaban de forma manual o con scripts frágiles:

• Orquestación (Orchestration): conectar herramientas dispares mediante APIs bidireccionales. Un SOAR habla con el SIEM para obtener la alerta, con el EDR para aislar un host, con el firewall para bloquear una IP, y con el sistema de tickets para documentar todo. Sin orquestación, el analista hace copy-paste entre diez consolas distintas.

• Automatización (Automation): ejecutar secuencias de acciones sin intervención humana cuando el contexto lo permite. Enriquecer un indicador con VirusTotal, buscar destinatarios de un email malicioso en Exchange, o bloquear un dominio en el proxy son tareas que no requieren juicio humano y se ejecutan en segundos.

• Respuesta (Response): tomar acciones de contención, erradicación y recuperación de forma coordinada. La respuesta puede ser completamente automática (phishing de bajo riesgo) o semi-automática (el playbook prepara todo y el analista aprueba con un clic).

Por qué existe: el problema de escala#

Un SOC de tamaño medio recibe entre 500 y 5000 alertas diarias. Sin automatización, cada alerta requiere entre 15 y 45 minutos de trabajo manual: abrir la alerta, copiar IOCs, consultar threat intel, verificar contexto del usuario, decidir acción, ejecutarla, documentar. Las matemáticas no cuadran: un equipo de 8 analistas no puede procesar 3000 alertas al día dedicando 20 minutos a cada una.

SOAR no reduce el número de alertas — eso lo hace el tuning de reglas en el SIEM. SOAR reduce el tiempo que cada alerta consume, automatizando los pasos repetitivos y dejando al analista solo las decisiones que requieren criterio.

Plataformas principales#

Shuffle#

Shuffle es SOAR open-source (licencia AGPL) que se despliega on-premise o en cloud propio. Su editor visual de workflows permite crear playbooks arrastrando nodos sin escribir código. Incluye más de 300 apps preconfiguradas (integraciones con SIEM, EDR, email, cloud). Es la opción preferida por equipos pequeños o con presupuesto limitado que quieren control total del despliegue.

# Despliegue básico con Docker
git clone https://github.com/Shuffle/Shuffle
cd Shuffle
docker compose up -d

Shuffle expone una API REST completa, soporta webhooks como trigger, y permite código Python personalizado dentro de cada nodo cuando las apps preconfiguradas no cubren un caso.

Tines#

Tines es una plataforma no-code comercial que destaca por su simplicidad: cada playbook es un grafo de acciones (HTTP Request, Transform, Trigger, Send Email, Event Transform, AI Action). No requiere programación y su curva de aprendizaje es la más baja del mercado. Ofrece una Community Edition gratuita con límites de ejecuciones.

Tines introduce el concepto de Stories (playbooks) compuestos por Actions (nodos). Cada acción recibe datos del nodo anterior, los transforma, y los pasa al siguiente. Las stories se comparten en la comunidad pública de Tines, lo que acelera la adopción.

Cortex XSOAR#

Cortex XSOAR (antes Demisto, adquirida por Palo Alto Networks) es la plataforma enterprise con el marketplace de integraciones más amplio del mercado (más de 900 packs). Incluye case management nativo, War Room para colaboración en tiempo real durante incidentes, y un motor de playbooks con soporte para sub-playbooks reutilizables.

XSOAR usa Python para la lógica de sus integraciones (Integration Scripts) y JavaScript para transformaciones ligeras. El Marketplace de contenido permite instalar playbooks, integraciones y dashboards verificados por la comunidad y por Palo Alto.

Diseño de playbooks#

Un playbook efectivo tiene cinco componentes:

• Trigger: qué dispara el workflow. Puede ser una alerta del SIEM (webhook), un email a un buzón de abuso, un ticket nuevo, o una ejecución programada.
• Enrichment: recopilar contexto. Consultar VirusTotal, AbuseIPDB, WHOIS, historial del usuario, criticidad del asset.
• Decision: lógica condicional. Si el hash es malicioso Y el host es producción → contención automática. Si es ambiguo → escalar a analista.
• Action: ejecutar la respuesta. Aislar host, bloquear IP, purgar email, deshabilitar cuenta.
• Documentation: registrar todo automáticamente en el caso: timeline, evidencia, acciones tomadas, analista responsable.

Human-in-the-loop#

No todo debe ser automático. La regla general: automatiza lo que siempre tiene la misma respuesta correcta; escala a humano lo que requiere contexto o juicio.

Ejemplos de automatización segura:

• Enriquecer IOCs con threat intel.
• Buscar otros destinatarios de un email malicioso.
• Bloquear hashes con 50+ detecciones en VirusTotal.
• Documentar y cerrar alertas informativas.

Ejemplos que requieren humano:

• Aislar un servidor de producción crítico.
• Decidir si un comportamiento es legítimo en un ejecutivo.
• Escalar a legal si hay exfiltración de datos personales.
• Notificar a reguladores (GDPR, HIPAA).

El playbook prepara toda la información y la presenta al analista con un botón de "aprobar" o "rechazar". El analista toma la decisión en segundos porque el contexto ya está enriquecido.

Ejemplo práctico: playbook de phishing#

Este es el playbook más común en cualquier SOC y el mejor punto de partida para implementar SOAR:

Paso 1: Trigger#

El SIEM detecta un email sospechoso (adjunto con hash desconocido, URL en dominio recién registrado, o fallo de DMARC) y envía un webhook al SOAR con los datos del email.

{
  "alert_id": "SIEM-20261106-4821",
  "type": "suspicious_email",
  "sender": "[email protected]",
  "recipient": "[email protected]",
  "subject": "Factura pendiente - urgente",
  "attachment_hash": "a1b2c3d4e5f6...",
  "urls": ["https://dominio-sospechoso.com/doc.html"],
  "timestamp": "2026-11-06T09:15:00Z"
}

Paso 2: Enriquecimiento automático#

El playbook lanza en paralelo:

• Hash del adjunto → VirusTotal API (detecciones, familia de malware).
• URL → URLScan.io (screenshot, redirects, contenido).
• Dominio del remitente → WHOIS (fecha de registro, registrador).
• IP del servidor de correo → AbuseIPDB (reportes previos).
• Headers → verificación SPF, DKIM, DMARC.

Paso 3: Buscar otros destinatarios#

Query a Exchange Online / Google Workspace: ¿quién más recibió un email del mismo remitente o con el mismo hash en las últimas 24 horas? El resultado es una lista de buzones afectados.

Paso 4: Veredicto automático#

Lógica condicional en el playbook:

IF hash_detections > 5 OR domain_age < 7_days OR dmarc_fail:
    verdict = "malicious"
    confidence = "high"
ELIF hash_detections > 0 OR url_suspicious:
    verdict = "suspicious"
    confidence = "medium"
ELSE:
    verdict = "benign"
    confidence = "low"

Paso 5: Decisión humana (si es necesario)#

Si c "medium", el playbook envía un mensaje a Slack con todo el contexto enriquecido y espera la aprobación del analista. Si es "high", procede automáticamente a contención. Si es "low", documenta y cierra.

Paso 6: Contención#

• Purge del email en todos los buzones afectados (Exchange: Search-Mailbox -DeleteContent o Graph API).
• Bloqueo del dominio del remitente en el proxy y en el filtro de email.
• Bloqueo del hash del adjunto en el EDR.
• Si algún usuario hizo clic en la URL: aislar su equipo en el EDR para investigación.

Paso 7: Documentación#

El playbook crea o actualiza el caso con: timeline completa, IOCs extraídos, resultados de enrichment, acciones tomadas, analista que aprobó (si aplica), y buzones afectados. Todo automático, sin que el analista escriba una línea.

Integraciones críticas#

Un SOAR sin integraciones es un motor sin ruedas. Las conexiones mínimas para un SOC funcional:

Cada integración se conecta vía API REST con autenticación (API key, OAuth, certificado). Los SOAR modernos incluyen conectores preconfigurados; para servicios internos, se escribe un conector personalizado.

Métricas y ROI#

SOAR debe demostrar su valor con datos. Las métricas fundamentales:

• MTTR (Mean Time To Respond): tiempo desde la alerta hasta la contención. Objetivo: reducir de 30-60 min a menos de 10 min.
• MTTD (Mean Time To Detect): SOAR no mejora MTTD directamente (eso es responsabilidad del SIEM), pero reduce el backlog de alertas pendientes, lo que indirectamente mejora la detección.
• Tasa de automatización: porcentaje de pasos del playbook que se ejecutan sin intervención humana. Un playbook maduro automatiza el 70-90% de los pasos.
• Alertas procesadas por analista: sin SOAR, 20-40 al día. Con SOAR, 80-150.
• Consistencia: porcentaje de incidentes que siguen el playbook completo. Sin SOAR, depende del analista. Con SOAR, 100%.

Para calcular ROI: estima el coste hora del analista, multiplica por los minutos ahorrados por alerta, multiplica por el número de alertas mensuales. Un SOAR que ahorra 20 minutos por alerta en un SOC con 2000 alertas mensuales equivale a 667 horas de analista al mes.

Errores comunes al implementar SOAR#

• Automatizar sin entender el proceso: si el proceso manual no está documentado y no funciona bien, automatizarlo solo hace que falle más rápido. Primero documenta, optimiza, y luego automatiza.
• Automatizar decisiones de alto impacto desde el día uno: aislar un servidor de producción automáticamente puede causar más daño que el incidente. Empieza con acciones de bajo riesgo (enriquecimiento, notificación) y escala gradualmente.
• Ignorar el mantenimiento de playbooks: las APIs cambian, las herramientas se actualizan, los procesos evolucionan. Un playbook sin mantenimiento se rompe silenciosamente.
• No medir: sin métricas de MTTR, tasa de automatización y fallos de playbook, es imposible justificar la inversión ni mejorar los workflows.
• Playbooks monolíticos: un playbook de 200 nodos es imposible de mantener. Divide en sub-playbooks reutilizables: uno para enriquecimiento de hash, otro para contención de email, otro para notificación.
• Falta de testing: los playbooks necesitan tests con datos simulados antes de ir a producción. Un error en el nodo de contención puede aislar un host equivocado.

Dónde practicar#

El laboratorio integrity-breach de whoami-labs te pone en el rol de investigador forense analizando tráfico capturado. No es un SOAR, pero practica la parte más importante: entender qué datos necesitas, cómo correlacionarlos, y qué acciones tomar. Es el proceso mental que luego automatizas con SOAR.

El laboratorio shadow-automation entrena el análisis de tareas automatizadas: descubrir qué scripts se ejecutan, con qué privilegios, y cómo se encadenan. La mentalidad es la misma que necesitas para diseñar playbooks SOAR: entender flujos automáticos, sus dependencias, y sus puntos de fallo.

Para práctica directa con SOAR:

• Shuffle: instala con Docker en tu equipo, conecta a un Wazuh o Elastic local, crea tu primer playbook de enrichment.
• Tines Community Edition: registra cuenta gratuita, importa stories de la comunidad, modifícalas.
• XSOAR: Palo Alto ofrece un Developer Hub con sandbox gratuita para probar integraciones.

Preguntas frecuentes#

¿SOAR reemplaza al SIEM?#

No. Son complementarios. El SIEM detecta (alertas, correlación, búsqueda). El SOAR responde (automatización, orquestación, case management). Sin SIEM no hay alertas que procesar. Sin SOAR, las alertas se procesan a mano.

¿Puedo empezar con SOAR sin presupuesto?#

Sí. Shuffle es open-source y se despliega con Docker. Tines tiene free tier. Incluso sin plataforma SOAR, puedes automatizar con scripts de Python que conecten APIs — el concepto es el mismo, la plataforma solo añade interfaz visual, gestión de errores y auditoría.

¿Cuántos playbooks necesito para empezar?#

Tres: phishing response, malware en endpoint, y cuenta comprometida. Cubren la mayoría de alertas de un SOC típico. Empieza con phishing porque es el más frecuente, el más repetitivo, y el de menor riesgo de error en la automatización.

¿Qué pasa si el playbook falla?#

Un SOAR bien configurado tiene manejo de errores en cada nodo: retry con backoff, fallback a acción alternativa, y escalación a humano si todo falla. El peor escenario es que la alerta quede sin procesar automáticamente y pase a la cola manual — exactamente lo que pasaría sin SOAR.

¿SOAR funciona para equipos pequeños?#

Especialmente para equipos pequeños. Un equipo de 3 analistas que automatiza el 80% de los pasos repetitivos equivale a un equipo de 8 trabajando manualmente. SOAR es un multiplicador de fuerza.

Resumen#

• SOAR integra orquestación, automatización y respuesta para reducir el MTTR de incidentes de horas a minutos.
• Shuffle (open-source), Tines (no-code) y Cortex XSOAR (enterprise) son las tres plataformas principales.
• Playbooks efectivos combinan automatización para tareas repetitivas con decisión humana para acciones de alto impacto.
• Human-in-the-loop es crítico: automatiza el enriquecimiento, escala la contención de producción a un analista.
• Métricas (MTTR, tasa de automatización, alertas por analista) son obligatorias para demostrar valor y mejorar.
• Empieza con tres playbooks (phishing, malware, cuenta comprometida) y escala gradualmente.

Fuentes y lecturas recomendadas#

• Shuffle SOAR
• Tines
• Cortex XSOAR
• MITRE ATT&CK
• TheHive Project
• Gartner - Market Guide for SOAR
• NIST SP 800-61 Rev. 2 - Computer Security Incident Handling Guide