SOAR vs SIEM: diferencias, integración y cuándo necesitas ambos

Comparativa detallada entre SOAR y SIEM: diferencias funcionales, cuándo necesitas cada uno, cómo integrarlos y mejores prácticas para un SOC eficiente.

¿Qué es un SIEM y qué problema resuelve?

Un SIEM (Security Information and Event Management) es la herramienta central de visibilidad de un SOC. Según la definición de Gartner, un SIEM combina dos capacidades que originalmente eran productos separados: la gestión de información de seguridad (SIM) y la gestión de eventos de seguridad (SEM).

En términos prácticos, un SIEM hace tres cosas fundamentales:

Recopilación centralizada de logs. Ingesta datos de decenas o cientos de fuentes: firewalls, endpoints, servidores, aplicaciones, servicios cloud, proxies, sistemas de autenticación, bases de datos. Todo se normaliza en un formato común para poder correlacionar eventos entre fuentes diferentes.

Correlación y detección. Aplica reglas de correlación, modelos estadísticos y (cada vez más) modelos de machine learning para identificar patrones sospechosos. Por ejemplo: un inicio de sesión desde una IP en un país inusual, seguido de un acceso a un recurso sensible, seguido de una transferencia de datos superior al umbral normal. Ninguno de estos eventos por separado sería una alerta, pero la secuencia sí.

Almacenamiento y búsqueda. Retiene logs durante semanas, meses o años (según la política de retención), permitiendo investigaciones forenses retrospectivas. Cuando un analista necesita reconstruir la secuencia de un ataque que empezó hace tres meses, el SIEM es donde busca.

Los SIEM más extendidos en el mercado incluyen Splunk Enterprise Security, Microsoft Sentinel, IBM QRadar, Elastic Security, Google Chronicle (SecOps) y LogRhythm. Cada uno tiene fortalezas distintas en escala, coste, facilidad de uso o integraciones nativas.

Las limitaciones reales de un SIEM

A pesar de su importancia, un SIEM tiene limitaciones que cualquier equipo SOC conoce de primera mano:

• Fatiga de alertas: un SIEM mal tunado puede generar miles de alertas diarias, de las cuales un porcentaje significativo son falsos positivos. Los analistas acaban ignorando alertas o priorizando mal.
• Acción manual: el SIEM detecta, pero no actúa. Cuando genera una alerta, un analista humano debe investigar, decidir y ejecutar la respuesta. Esto introduce latencia.
• Complejidad de reglas: mantener las reglas de correlación actualizadas requiere conocimiento del panorama de amenazas y de la infraestructura. Las reglas obsoletas generan ruido, y las que faltan dejan puntos ciegos.
• Coste de ingesta: el modelo de precios de muchos SIEM se basa en volumen de datos ingeridos (GB/día). A medida que la infraestructura crece, los costes pueden dispararse, forzando decisiones incómodas sobre qué logs incluir.

Estas limitaciones son exactamente las que un SOAR viene a resolver.

¿Qué es un SOAR y qué problema resuelve?

SOAR (Security Orchestration, Automation and Response) es una categoría de herramientas que automatiza y orquesta los flujos de trabajo de respuesta a incidentes de seguridad. El término fue acuñado por Gartner en 2017, aunque las capacidades subyacentes existían antes bajo otros nombres.

Un SOAR tiene tres componentes principales:

Orquestación (Orchestration). Conecta herramientas de seguridad dispares y coordina acciones entre ellas. Un SOAR puede, en una sola ejecución de playbook, consultar el SIEM, enriquecer una IP en un servicio de reputación, bloquear la IP en el firewall, crear un ticket en el sistema de gestión y enviar una notificación al canal de Slack del equipo. Sin el SOAR, un analista haría esto manualmente, alternando entre 5 o 6 consolas diferentes.

Automatización (Automation). Ejecuta tareas repetitivas sin intervención humana. El ejemplo clásico: una alerta de phishing llega al SIEM, el SOAR automáticamente extrae los indicadores (URLs, hashes de adjuntos, remitente), los consulta contra bases de reputación (MITRE ATT&CK, VirusTotal, AbuseIPDB), y si el veredicto es malicioso, bloquea el remitente, elimina el correo de todos los buzones afectados y documenta el caso. Todo en menos de un minuto.

Respuesta (Response). Gestiona el ciclo de vida completo de los incidentes: creación del caso, asignación al analista adecuado, seguimiento de las tareas de remediación, generación de métricas (MTTD, MTTR, tasa de falsos positivos) y creación de informes para la dirección.

Tabla comparativa: SIEM vs SOAR

La conclusión de esta tabla es simple: SIEM y SOAR no son competidores. Son complementarios. El SIEM es los ojos del SOC. El SOAR es las manos.

Orquestación, playbooks y respuesta automática: lo que aporta un SOAR

Para entender cuándo necesitas un SOAR, es útil desglosar las capacidades exclusivas que aporta:

Playbooks automatizados

Un playbook es una secuencia de acciones predefinidas que se ejecuta automáticamente (o con aprobación humana en pasos críticos) cuando se cumple un disparador. Ejemplos reales:

Playbook de phishing:

1. Alerta de phishing llega del SIEM o de la bandeja de abuso.
2. Extraer URLs, IPs, hashes de adjuntos, remitente.
3. Consultar reputación en VirusTotal, URLhaus, AbuseIPDB.
4. Si es malicioso: bloquear remitente en el gateway de correo, eliminar correo de buzones afectados, aislar endpoints que hayan hecho clic.
5. Crear caso con toda la evidencia adjunta.
6. Notificar al equipo y al usuario afectado.
7. Generar informe de cierre.

Playbook de endpoint comprometido:

1. Alerta de EDR indica comportamiento sospechoso en un endpoint.
2. Aislar el endpoint de la red (vía API del EDR).
3. Capturar snapshot de memoria y procesos activos.
4. Consultar hashes de procesos sospechosos contra threat intelligence.
5. Si se confirma compromiso: escalar a N2, iniciar procedimiento forense.
6. Si es falso positivo: restaurar conectividad, documentar y cerrar.

Playbook de fuerza bruta:

1. El SIEM detecta múltiples intentos fallidos de autenticación desde una IP.
2. Consultar la IP en listas de reputación.
3. Si la IP es conocida como maliciosa: bloquear en firewall, notificar.
4. Si la IP es interna: verificar si la cuenta está comprometida, forzar cambio de contraseña.
5. Documentar y cerrar.

Estos playbooks no son teoría. Son flujos que los SOC maduros ejecutan decenas de veces al día, y sin automatización cada uno consume entre 20 y 45 minutos de trabajo de analista.

Orquestación multi-herramienta

Un SOC típico utiliza entre 10 y 50 herramientas de seguridad. El SOAR actúa como el conector central que permite a estas herramientas trabajar juntas sin que el analista tenga que saltar entre consolas. Las integraciones típicas incluyen:

• SIEM (Splunk, Sentinel, QRadar)
• EDR (CrowdStrike, SentinelOne, Microsoft Defender)
• Firewall/NGFW (Palo Alto, Fortinet, Check Point)
• Ticketing (ServiceNow, Jira)
• Threat Intelligence (MITRE, VirusTotal, OTX, MISP)
• Email security (Proofpoint, Mimecast)
• Cloud (AWS Security Hub, Azure Defender, GCP SCC)
• Comunicaciones (Slack, Teams, PagerDuty)

Gestión de casos e investigación

El SOAR proporciona un espacio centralizado donde cada incidente tiene su timeline de eventos, evidencias adjuntas, acciones realizadas (automáticas y manuales), analistas asignados y estado actual. Esto es crítico para:

• Auditorías de cumplimiento (DORA, NIS2, ISO 27001).
• Traspaso entre turnos de analistas.
• Post-mortem de incidentes.
• Métricas de rendimiento del SOC.

Métricas y reporting automatizado

Un SOAR bien configurado genera automáticamente métricas que un SIEM por sí solo no puede calcular:

• MTTD (Mean Time to Detect): tiempo desde que ocurre el evento hasta que se genera la alerta.
• MTTR (Mean Time to Respond): tiempo desde la alerta hasta la remediación completa.
• Tasa de automatización: porcentaje de alertas gestionadas sin intervención humana.
• Alertas por analista: carga de trabajo por persona.
• Falsos positivos: porcentaje de alertas que resultan benignas después de investigación.

Señales claras de que tu SOC necesita un SOAR

No todos los SOC necesitan un SOAR. Hay señales claras de que ha llegado el momento:

Señales de que necesitas un SOAR

1. Tu equipo no puede gestionar el volumen de alertas. Si los analistas procesan menos del 50% de las alertas generadas por el SIEM, las alertas pendientes se acumulan y los tiempos de respuesta crecen semana a semana, necesitas automatizar.

2. Las tareas repetitivas consumen más del 60% del tiempo de los analistas. Enriquecer IoCs, crear tickets, notificar a stakeholders, documentar acciones. Si tus analistas N1 pasan la mayor parte del día en tareas que no requieren juicio experto, un SOAR libera su tiempo para investigaciones reales.

3. El MTTR supera los 30 minutos para alertas de riesgo medio. Un SOAR bien configurado puede reducir el MTTR de alertas rutinarias de 30 minutos a menos de 2 minutos.

4. Tienes requisitos regulatorios de documentación y trazabilidad. Marcos como DORA, NIS2 o ISO 27001 exigen evidencias de que los incidentes se gestionan de forma estructurada, con tiempos de respuesta medibles y acciones documentadas.

5. Operas un SOC 24/7 con rotación de turnos. La consistencia en la respuesta es crítica. Un playbook automatizado aplica la misma lógica a las 3 de la mañana que a las 10 de la mañana, independientemente de quién esté de turno.

¿Cuándo NO necesitas un SOAR (todavía)?

• Tu equipo SOC tiene menos de 3 personas y el volumen de alertas es manejable.
• No tienes playbooks de respuesta documentados (primero documenta, luego automatiza).
• Tu SIEM no está bien tunado y genera más ruido que señales (arregla el SIEM primero).
• No tienes integraciones API con tus herramientas de seguridad (el SOAR necesita APIs para actuar).

¿Cómo se integran SOAR y SIEM?

La integración entre SIEM y SOAR sigue patrones bien establecidos. Estos son los más comunes:

Patrón 1: SIEM como fuente primaria de alertas

El flujo más básico y más común:

[Fuentes de logs] → [SIEM] → [Alertas correlacionadas] → [SOAR] → [Acciones automatizadas]

El SIEM ingesta logs, aplica reglas de correlación y genera alertas. El SOAR recibe estas alertas vía API, webhook o syslog, y ejecuta el playbook correspondiente. Este patrón funciona bien cuando el SIEM es la fuente principal de detección.

Patrón 2: SOAR como agregador multi-fuente

En SOCs maduros, el SOAR recibe alertas de múltiples fuentes, no solo del SIEM:

[SIEM]           ─┐
[EDR]            ─┤
[Email gateway]  ─┼→ [SOAR] → [Deduplicación + Correlación + Playbook]
[Cloud alerts]   ─┤
[Threat intel]   ─┘

En este patrón, el SOAR deduplica alertas (la misma IP puede generar alertas en el SIEM, el EDR y el firewall simultáneamente), las correlaciona como parte del mismo incidente y ejecuta un playbook unificado. Esto evita que tres analistas investiguen el mismo evento por separado.

Patrón 3: Retroalimentación bidireccional

El patrón más avanzado incluye un bucle de feedback:

[SIEM] ←→ [SOAR]
  ↑           ↓
  └── [Threat Intel actualizada, reglas refinadas] ──┘

El SOAR, tras resolver un incidente, puede actualizar las reglas del SIEM (añadir una IP a una watchlist, ajustar un umbral de correlación), enriquecer las fuentes de threat intelligence (agregar nuevos IoCs validados) o modificar la prioridad de futuras alertas similares. Este bucle de mejora continua es lo que diferencia un SOC reactivo de uno proactivo.

Ejemplo de integración práctica

Un banco mediano con Splunk Enterprise Security como SIEM y Splunk SOAR decide automatizar el proceso de phishing:

1. Configuración en Splunk ES: regla de correlación que detecta correos con adjuntos ejecutables o URLs sospechosas reportados por usuarios.
2. Conector SOAR: webhook que envía la alerta a Splunk SOAR cuando la regla se dispara.
3. Playbook en SOAR: extrae IoCs, consulta VirusTotal y URLhaus, verifica si otros usuarios recibieron el mismo correo, y decide:
   • Si malicioso: elimina correo de todos los buzones (vía API de Exchange/M365), bloquea URLs en el proxy (vía API de Zscaler), crea caso y notifica.
   • Si sospechoso: escala a analista N2 con toda la información pre-enriquecida.
   • Si benigno: cierra automáticamente y documenta.
4. Feedback: los IoCs confirmados se añaden a la watchlist de Splunk ES para detección futura.

Resultado: lo que antes consumía 35 minutos por alerta ahora se resuelve en 90 segundos para los casos automáticos, y en 10 minutos para los escalados (porque el analista recibe toda la información ya enriquecida).

Principales plataformas SOAR del mercado

Soluciones enterprise

Splunk SOAR (antes Phantom) Probablemente el SOAR más maduro del mercado. Más de 300 integraciones nativas, editor visual de playbooks, fuerte en automatización y con la ventaja de integración nativa con Splunk ES. Adquisición por Cisco en 2024 amplía el ecosistema. Punto débil: precio elevado y curva de aprendizaje para playbooks complejos.

Cortex XSOAR (Palo Alto Networks) Originalmente Demisto, adquirido por Palo Alto en 2019. Destaca por su marketplace de integraciones y content packs, su motor de machine learning para clasificación de alertas y la integración con el ecosistema Palo Alto (NGFW, Prisma, Cortex XDR). Incluye un módulo de threat intelligence integrado (TIM). Punto débil: funcionalidad completa requiere el ecosistema Palo Alto.

Microsoft Sentinel + Logic Apps Microsoft ha integrado capacidades SOAR directamente en Sentinel mediante Logic Apps y reglas de automatización. No es un SOAR independiente, sino capacidades de automatización integradas en el SIEM. Ventaja: coste nulo adicional si ya usas Sentinel. Punto débil: menos flexible que un SOAR dedicado para orquestación multi-vendor.

IBM QRadar SOAR (antes Resilient) Fuerte en gestión de casos y cumplimiento regulatorio (incluye plantillas para GDPR, DORA, NIS2). Buena integración con QRadar SIEM. Punto débil: interfaz menos moderna que competidores y menor comunidad de integraciones.

Alternativas open source y low-cost

Shuffle SOAR open source con editor visual de workflows, más de 1000 integraciones vía OpenAPI y despliegue on-premise o cloud. Ideal para equipos que quieren control total y tienen capacidad de gestión. Licencia gratuita para uso básico, con planes de pago para funcionalidades avanzadas.

Tines Plataforma de automatización no-code con enfoque en seguridad. Ofrece un tier Community Edition gratuito con funcionalidad completa (limitado en volumen). Destaca por su simplicidad: los playbooks se construyen arrastrando “stories” (acciones) y conectándolas visualmente. Ideal para equipos pequeños que necesitan resultados rápidos.

TheHive + Cortex Combinación open source donde TheHive gestiona los casos y Cortex ejecuta los analyzers y responders (automatizaciones). Muy popular en CERTs y SOCs europeos. Punto débil: requiere más esfuerzo de mantenimiento que las soluciones comerciales.

n8n (con enfoque seguridad) Aunque n8n es una plataforma de automatización genérica, su modelo self-hosted, su motor de workflows visuales y sus integraciones con APIs de seguridad lo convierten en una opción viable para equipos que necesitan automatización SOC sin el coste de un SOAR enterprise. Especialmente útil cuando ya se utiliza n8n para otras automatizaciones operativas.

Build vs buy: cuando construir tus propios playbooks

La decisión entre comprar un SOAR comercial o construir automatizaciones con herramientas genéricas depende de varios factores:

¿Cuándo comprar un SOAR comercial?

• Tu SOC tiene más de 10 analistas y gestiona más de 500 alertas diarias.
• Necesitas integraciones out-of-the-box con docenas de herramientas de seguridad.
• Tienes requisitos de cumplimiento que exigen un audit trail robusto (DORA, NIS2).
• El presupuesto lo permite (entre 50.000 y 300.000 EUR anuales según la solución y el tamaño).

¿Cuándo construir con herramientas genéricas?

• Tu SOC tiene menos de 10 analistas y el volumen de alertas es moderado.
• Tienes ingenieros de seguridad capaces de desarrollar y mantener playbooks.
• Tus necesidades de automatización son específicas y no justifican el coste de una plataforma completa.
• Prefieres un enfoque incremental: automatizar un playbook, medir resultados, iterar.

Ejemplo de playbook “build” con Python

Para equipos que deciden construir, un playbook de enriquecimiento de IoCs puede ser sorprendentemente simple:

import requests
from datetime import datetime

def enrich_ioc(ioc_value: str, ioc_type: str) -> dict:
    """Enriquece un IoC consultando múltiples fuentes."""
    results = {"ioc": ioc_value, "type": ioc_type, "timestamp": datetime.utcnow().isoformat()}

    if ioc_type == "ip":
        # AbuseIPDB
        resp = requests.get(
            "https://api.abuseipdb.com/api/v2/check",
            headers={"Key": ABUSEIPDB_KEY, "Accept": "application/json"},
            params={"ipAddress": ioc_value, "maxAgeInDays": 90}
        )
        results["abuseipdb_score"] = resp.json()["data"]["abuseConfidenceScore"]

        # VirusTotal
        resp = requests.get(
            f"https://www.virustotal.com/api/v3/ip_addresses/{ioc_value}",
            headers={"x-apikey": VT_KEY}
        )
        stats = resp.json()["data"]["attributes"]["last_analysis_stats"]
        results["vt_malicious"] = stats.get("malicious", 0)

    elif ioc_type == "hash":
        resp = requests.get(
            f"https://www.virustotal.com/api/v3/files/{ioc_value}",
            headers={"x-apikey": VT_KEY}
        )
        stats = resp.json()["data"]["attributes"]["last_analysis_stats"]
        results["vt_malicious"] = stats.get("malicious", 0)

    return results

Este script, conectado a un webhook del SIEM y combinado con un par de acciones de remediación (bloqueo en firewall vía API, creación de ticket en Jira), cubre el 80% de lo que un SOAR básico ofrece para ese caso de uso específico.

¿Qué errores evitar al implementar SOAR?

La implementación de un SOAR es un proyecto que puede salir muy bien o muy mal. Estos son los errores más comunes:

Error 1: Automatizar sin documentar

Si no tienes playbooks de respuesta documentados antes de implementar el SOAR, vas a automatizar el caos. Primero documenta cómo gestionas cada tipo de alerta manualmente (phishing, malware, fuerza bruta, acceso no autorizado). Luego identifica qué pasos son automatizables. Solo entonces configura el SOAR.

Error 2: Intentar automatizar todo desde el día uno

Empieza con 3 a 5 playbooks de alto volumen y bajo riesgo (enriquecimiento de IoCs, cierre automático de falsos positivos conocidos, notificaciones). Mide los resultados durante un mes. Luego expande gradualmente. La tentación de automatizar 50 playbooks en paralelo lleva al agotamiento del equipo y a playbooks mal probados que generan más problemas que los que resuelven.

Error 3: No incluir puntos de decisión humana

No todo debe ser full-auto. Las acciones de alto impacto (aislar un servidor de producción, bloquear una cuenta de un directivo, reportar un incidente al regulador) deben incluir un checkpoint donde un analista humano aprueba o rechaza antes de ejecutar. La automatización sin supervisión en acciones críticas es una receta para el desastre.

Error 4: No medir el antes y el después

Sin métricas de referencia (MTTR antes del SOAR, tiempo por alerta, porcentaje de alertas procesadas), no puedes demostrar el ROI de la implementación. Mide durante al menos un mes antes de desplegar el SOAR, y compara con los mismos KPIs después.

Error 5: Ignorar el mantenimiento continuo

Los playbooks no son “configurar y olvidar”. Las APIs cambian, las herramientas se actualizan, las amenazas evolucionan. Asigna al menos un 20% del tiempo de un ingeniero de seguridad al mantenimiento y evolución de los playbooks. Un playbook roto es peor que no tener playbook, porque da una falsa sensación de seguridad.

Error 6: No alinear con el framework MITRE ATT&CK

Cada playbook debería mapear a una o más tácticas y técnicas de MITRE ATT&CK. Esto permite identificar gaps en la cobertura de detección y respuesta, priorizar playbooks por riesgo real y comunicar el valor al negocio en un lenguaje común.

Coste real de un SOAR: licencias, integración y mantenimiento

El coste total de propiedad (TCO) de un SOAR incluye mucho más que la licencia del software:

Para un SOC mediano (5 a 15 analistas, 200 a 1000 alertas diarias), el coste total del primer año oscila entre 80.000 y 200.000 EUR con una solución enterprise, y entre 30.000 y 80.000 EUR con una solución open source.

El ROI típico se calcula en tiempo de analista recuperado. Si un SOAR automatiza 200 alertas diarias que antes consumían 20 minutos cada una, son 66 horas de analista al día. A un coste medio de 35 EUR/hora, son 2.310 EUR diarios, o más de 840.000 EUR anuales. Incluso con números más conservadores, el ROI es habitualmente positivo en el primer año.

Artículos relacionados:

• Qué Es Un Siem Para Que Sirve
• Cómo Montar Soc Desde Cero

Preguntas frecuentes

¿Puede un SOAR reemplazar completamente a un SIEM?

No. Un SOAR no recopila ni almacena logs, no ejecuta correlación de eventos a gran escala ni proporciona capacidad forense retrospectiva. El SOAR necesita una fuente de detección (normalmente un SIEM) que le alimente con alertas. Son herramientas complementarias: el SIEM detecta, el SOAR responde. Intentar usar un SOAR sin SIEM es como tener un equipo de bomberos sin sistema de alarma contra incendios.

¿Necesito un SOAR si mi SIEM ya tiene automatización básica?

Depende del nivel de automatización que necesites. Muchos SIEM modernos (como Microsoft Sentinel con Logic Apps o Splunk con Adaptive Response) incluyen capacidades básicas de automatización. Para SOCs pequeños con necesidades simples (notificaciones, enriquecimiento básico), esto puede ser suficiente. Cuando necesitas orquestación multi-herramienta compleja, playbooks con lógica condicional avanzada, gestión de casos completa o integraciones con decenas de herramientas externas, un SOAR dedicado aporta un valor significativamente mayor.

¿Cuánto tiempo tarda en ser productivo un SOAR después de la implementación?

El tiempo hasta el primer valor depende del enfoque. Un playbook simple (enriquecimiento automático de IoCs) puede estar operativo en 1 a 2 semanas. Tres a cinco playbooks de producción con integraciones reales suelen estar listos en 4 a 8 semanas. Un programa de automatización maduro con 15 o más playbooks, métricas completas y bucles de feedback lleva entre 3 y 6 meses. La clave es empezar con victorias rápidas que demuestren valor al equipo y a la dirección, y expandir gradualmente.

¿Es viable un SOAR open source para un SOC en producción?

Sí, con matices. Herramientas como Shuffle, TheHive + Cortex o incluso n8n con integraciones de seguridad pueden cubrir las necesidades de un SOC de tamaño pequeño a mediano. Las ventajas son el control total, la ausencia de costes de licencia y la flexibilidad de personalización. Los inconvenientes son la mayor carga de mantenimiento, la necesidad de ingenieros con habilidades de desarrollo, y la ausencia de soporte comercial (aunque Shuffle y Tines ofrecen planes de pago con soporte). Para SOCs con requisitos regulatorios estrictos (banca, seguros), el audit trail y las certificaciones de un SOAR enterprise pueden ser un factor decisivo.

¿Cómo se relaciona la implementación de un SOAR con el cumplimiento de DORA?

DORA (Reglamento UE 2022/2554) exige que las entidades financieras tengan procesos de gestión de incidentes TIC con plazos estrictos de notificación (4 horas para la notificación inicial, 72 horas para la intermedia). Un SOAR facilita el cumplimiento al automatizar la clasificación de incidentes, generar las notificaciones en el formato requerido por las autoridades, documentar automáticamente la timeline de acciones y calcular los tiempos de respuesta. No es un requisito explícito de DORA tener un SOAR, pero en la práctica es muy difícil cumplir los plazos de notificación de forma consistente sin algún nivel de automatización.