SOAR (Security Orchestration, Automation and Response) es una categoría de plataformas que conectan las distintas herramientas de seguridad de una organización, automatizan tareas repetitivas de respuesta y coordinan el trabajo del equipo a través de procedimientos codificados llamados playbooks. El término lo acuñó la consultora Gartner en 2017 para describir la convergencia de tres tecnologías que antes vivían separadas: la orquestación de seguridad, la automatización y la gestión de respuesta a incidentes. El problema que resuelve es concreto y medible: el centro de operaciones de seguridad (SOC) recibe más alertas de las que puede investigar a mano, y cada alerta investigada manualmente consume minutos preciosos que el atacante aprovecha.
El problema: fatiga de alertas y el cuello de botella humano
Un SOC moderno integra decenas de fuentes: firewalls, EDR en endpoints, proxies, IDS/IPS, registros de la nube y un SIEM que correla todo. El resultado son miles de alertas diarias, muchas de ellas falsos positivos. La fatiga de alertas es real y peligrosa: cuando el analista revisa la alerta número trescienta del turno, su capacidad de discriminar la amenaza genuina cae. Los dos indicadores que SOAR busca reducir son el MTTD (Mean Time To Detect, tiempo medio hasta detectar) y el MTTR (Mean Time To Respond, tiempo medio hasta responder). Cada minuto cuenta: un ransomware puede cifrar una red en minutos, y el coste de un incidente crece con su tiempo de contención.
SOAR no sustituye al analista; lo libera del trabajo de bajo valor. Las tareas mecánicas y deterministas —enriquecer una IP con inteligencia de amenazas, comprobar el hash de un fichero en VirusTotal, aislar un endpoint, bloquear un dominio en el proxy, abrir un ticket— se automatizan. El criterio humano se reserva para las decisiones que lo requieren: confirmar un compromiso, autorizar una acción de contención agresiva o declarar un incidente mayor. A esta combinación de pasos automáticos con puntos de decisión humana se la conoce como human-in-the-loop.
Anatomía de un playbook: el flujo de respuesta codificado
El playbook es el corazón de SOAR. Es un flujo de trabajo que describe, paso a paso y de forma ejecutable, cómo responder a un tipo concreto de incidente. Un playbook bien diseñado para un caso de phishing reportado por un usuario podría seguir esta secuencia: extraer la URL y los adjuntos del correo, detonarlos en un entorno aislado (sandbox), consultar reputación de dominios e IP en fuentes de inteligencia, buscar en el correo corporativo otros destinatarios del mismo mensaje, poner en cuarentena las copias encontradas, bloquear el dominio en el proxy y, finalmente, notificar al usuario. El analista interviene solo si el veredicto es ambiguo.
| Tecnología | Función principal | Pregunta que responde |
|---|---|---|
| SIEM | Recolectar y correlar registros, generar alertas | ¿Qué está pasando en mi red? |
| SOAR | Orquestar herramientas y automatizar respuesta | ¿Cómo respondo de forma rápida y consistente? |
| EDR/XDR | Detección y respuesta en endpoints y telemetría amplia | ¿Qué hace este equipo o esta identidad? |
| TIP | Gestionar inteligencia de amenazas (IoC, TTP) | ¿Esto que veo es conocido como malicioso? |
La diferencia con un SIEM es importante y a menudo se confunde. El SIEM detecta: agrega registros, los correla y dispara la alerta. SOAR actúa sobre esa alerta orquestando las herramientas. Por eso la arquitectura habitual es SIEM y SOAR trabajando juntos: el SIEM como sensor y motor de correlación, SOAR como brazo ejecutor y coordinador del caso. Las plataformas XDR incorporan parte de la automatización de respuesta, pero SOAR mantiene su valor cuando la organización tiene un ecosistema heterogéneo de fabricantes que hay que orquestar mediante conectores y APIs.
Marcos de referencia: del incidente al diccionario de técnicas
SOAR no opera en el vacío metodológico. Los playbooks se diseñan sobre marcos reconocidos. La guía NIST SP 800-61 define el ciclo de vida de la gestión de incidentes en cuatro fases: preparación; detección y análisis; contención, erradicación y recuperación; y actividad posterior al incidente (lecciones aprendidas). La norma ISO/IEC 27035 aporta una visión equivalente orientada al sistema de gestión de seguridad de la información, y la familia ISO/IEC 27001 exige procedimientos de respuesta como parte de sus controles.
Para clasificar las acciones del atacante y mapear las defensas, el estándar de facto es MITRE ATT&CK, una base de conocimiento de tácticas y técnicas adversarias observadas en el mundo real. Etiquetar cada playbook con las técnicas ATT&CK que cubre permite medir la cobertura defensiva e identificar huecos. En el plano regulatorio europeo, la Directiva NIS2, traspuesta a los ordenamientos nacionales, impone a las entidades esenciales e importantes obligaciones de gestión de incidentes y de notificación a la autoridad en plazos estrictos —una alerta temprana en 24 horas y una notificación en 72—, lo que convierte la automatización de la notificación en un caso de uso directo de SOAR.
Implementación: por dónde empezar sin tropezar
Una adopción de SOAR realista sigue una progresión por madurez. Primero conviene medir: ¿qué tipos de alerta consumen más tiempo del analista y son más repetitivos? Esos son los candidatos a automatizar primero, porque ofrecen el mayor retorno con el menor riesgo. Segundo, se automatiza el enriquecimiento (recopilar contexto sobre una alerta) antes que la contención (actuar sobre los sistemas), porque enriquecer es de bajo riesgo y acelera la triada del analista. Tercero, se introducen acciones de contención con aprobación humana, y solo cuando el playbook ha demostrado fiabilidad se valora automatizar por completo los casos más claros.
Un caso de uso concreto: triaje de alertas de EDR
Para aterrizar la teoría, conviene seguir un caso habitual: una alerta de EDR que avisa de la ejecución de un proceso sospechoso en un endpoint. Sin SOAR, el analista debe abrir la consola del EDR, identificar el equipo y el usuario, buscar el hash del binario en fuentes de reputación, revisar si ese proceso ha aparecido en otros equipos, consultar los registros del SIEM para reconstruir la cadena de eventos y, solo entonces, decidir. Cada uno de esos pasos implica cambiar de herramienta, copiar identificadores y esperar respuestas; en conjunto, fácilmente quince o veinte minutos por alerta. Multiplicado por las decenas de alertas similares de un turno, el SOC se ahoga.
Con un playbook, ese mismo triaje se ejecuta en segundos: la plataforma recibe la alerta vía API, extrae el hash y el equipo, consulta automáticamente la reputación del binario y la inteligencia de amenazas, comprueba la prevalencia del proceso en el parque, recopila los eventos correlados del SIEM y compone un caso enriquecido con un veredicto preliminar y un nivel de confianza. El analista abre un único caso con todo el contexto ya reunido y decide en lo que importa. Si el veredicto es claramente malicioso y la confianza es alta, el playbook puede proponer —o ejecutar con aprobación— el aislamiento del endpoint y la apertura del ticket de incidente. Este patrón, replicado para los tipos de alerta más frecuentes, es donde SOAR demuestra su retorno.
La clave es que cada acción quede registrada: qué se hizo, cuándo, con qué datos y quién lo aprobó. Esa traza no solo facilita la investigación posterior, sino que constituye la evidencia documental que las obligaciones de NIS2 y las auditorías de seguridad exigen. Un SOAR bien gobernado es, además de un acelerador operativo, un sistema de registro que sostiene el cumplimiento normativo.
Errores comunes al desplegar SOAR
- Automatizar el caos. Si el proceso de respuesta no está definido a mano, codificarlo en un playbook solo automatiza el desorden. Primero el procedimiento, después la automatización.
- Acciones destructivas sin control. Un playbook que aísla endpoints automáticamente puede convertirse en una autodenegación de servicio si un falso positivo dispara el aislamiento masivo. Las acciones de alto impacto piden aprobación humana.
- Conectores frágiles. SOAR depende de las APIs de terceros; un cambio en una API rompe el playbook silenciosamente. Hay que monitorizar la salud de las integraciones.
- Métricas de vanidad. Presumir de "número de alertas automatizadas" sin medir MTTR real ni tasa de falsos positivos contenidos no demuestra valor.
- Olvidar las lecciones aprendidas. La fase posterior al incidente del NIST alimenta la mejora de los playbooks; saltarla congela la capacidad de respuesta.
Preguntas frecuentes
¿SOAR reemplaza a los analistas del SOC? No. Elimina el trabajo mecánico y deja a los analistas las decisiones que exigen criterio, contexto e investigación. El objetivo es que un equipo pequeño gestione un volumen de alertas que de otro modo sería inabordable.
¿Cuál es la diferencia entre SIEM y SOAR? El SIEM detecta correlacionando registros y genera alertas; SOAR orquesta herramientas y automatiza la respuesta a esas alertas. Suelen desplegarse juntos: el SIEM dispara, SOAR ejecuta.
¿Qué es un playbook y quién lo escribe? Es un flujo de respuesta ejecutable para un tipo de incidente. Lo diseñan los analistas y los responsables del SOC partiendo del procedimiento manual existente y de marcos como NIST SP 800-61 y MITRE ATT&CK.
¿SOAR ayuda a cumplir NIS2 o RGPD? Sí, indirectamente: automatiza la documentación del incidente y la notificación a las autoridades en los plazos exigidos, reduciendo el riesgo de incumplir los tiempos legales de comunicación de brechas.
Conclusión: SOAR es disciplina de respuesta antes que tecnología
La trampa al evaluar SOAR es comprar una plataforma esperando que automatice un SOC inmaduro. La realidad es la contraria: SOAR amplifica lo que ya existe. Si los procedimientos de respuesta están escritos, ensayados y medidos, la plataforma los ejecuta a la velocidad de la máquina y libera al analista para lo que ninguna automatización resuelve: entender la intención del adversario y decidir bajo incertidumbre. Si no lo están, SOAR solo acelera los errores. Por eso el orden correcto es definir el procedimiento, etiquetarlo contra MITRE ATT&CK, automatizar primero el enriquecimiento de bajo riesgo y reservar las acciones de contención agresivas para un human-in-the-loop. Medido contra MTTD y MTTR reales —no contra métricas de vanidad—, un programa SOAR bien gobernado convierte un SOC saturado de alertas en un equipo que responde en minutos y aprende de cada incidente. En Summum Sistemas diseñamos esa arquitectura: integración con el SIEM existente, playbooks alineados con NIST SP 800-61 y un modelo de gobierno que mantiene a la persona en el centro de las decisiones críticas.