La perspectiva de Cyber Academy
SOAR es la capa que toma las alertas del SIEM y ejecuta playbooks: enriquecimiento, triaje, contención y ticketing. Objetivo: reducir el MTTR y liberar a los analistas de tareas de copiar y pegar. Precaución con las promesas excesivas de los fabricantes: un SOAR vale lo que valen los playbooks que se escriben y mantienen. La mayoría de los proyectos SOAR fallidos se quedaron sin autores de playbooks.
Lo que el SOAR añade por encima del SIEM
Security Orchestration, Automation and Response es la capa de acción que se sitúa detrás de la detección. Un SIEM es bueno recopilando registros, correlacionándolos y generando alertas, pero se detiene en la alerta. El SOAR toma el relevo desde ahí y hace el trabajo que de otro modo un analista realizaría a mano: enriquece la alerta con búsquedas de reputación y contexto de activos, decide su grado de urgencia, abre o actualiza un ticket y, cuando la política lo permite, toma medidas de contención como aislar un host, deshabilitar una cuenta o bloquear un indicador en el firewall. La unidad de trabajo en un SOAR es el playbook, una secuencia de pasos codificada que convierte un procedimiento repetible de gestión de incidentes en algo que la plataforma puede ejecutar por sí sola.
La orquestación y la automatización son dos ideas distintas que el acrónimo agrupa. La orquestación es el cableado: conectar el SIEM, el EDR, el sistema de ticketing, el proveedor de identidad, las fuentes de inteligencia de amenazas y el firewall para que puedan intercambiar datos y comandos entre sí a través de una sola consola. La automatización es lo que se ejecuta a través de ese cableado sin intervención humana.
La mayoría de los equipos maduros mantienen un punto de aprobación humana en los pasos destructivos, de modo que la plataforma enriquece y clasifica automáticamente, pero espera a que un analista confirme antes de poner en cuarentena un servidor de producción. Esa mezcla, el trabajo tedioso automatizado con el criterio humano en las acciones de consecuencias importantes, es lo que los profesionales realmente despliegan.
SIEM, SOAR y el SOC
Estos tres términos van juntos y es fácil confundirlos. No son productos que compitan entre sí. Describen funciones diferentes dentro de una misma operación de detección y respuesta.
| Término | Qué es | Su función |
|---|---|---|
| SIEM | Una plataforma | Recopila y correlaciona registros y telemetría, y luego genera alertas cuando algo parece anómalo. |
| SOAR | Una plataforma | Toma esas alertas y ejecuta playbooks: enriquecimiento, triaje, contención, ticketing. |
| SOC | Un equipo y una función | Los analistas y el proceso que operan ambos, investigan lo que las herramientas hacen aflorar y deciden qué hacer. |
Léelo como una tubería. El SIEM encuentra la señal, el SOAR hace el trabajo de respuesta repetible en torno a esa señal, y el SOC son las personas que son dueñas de todo el ciclo y gestionan todo lo que los playbooks no pueden. El valor más claro del SOAR está en el volumen: informes de phishing, alertas de malware común, inicios de sesión sospechosos. Cualquier cosa que llegue de forma masiva y siga un patrón de gestión predecible es candidata a un playbook, que es de donde proviene la reducción del tiempo medio de respuesta y por qué los analistas dejan de pasar su turno haciendo enriquecimiento de copiar y pegar.
Por qué los proyectos SOAR triunfan o fracasan
La shortDefinition es contundente sobre la trampa, y coincide con lo que se ve en el campo: un SOAR solo vale lo que valen los playbooks que escribes y mantienes, y la mayoría de los proyectos SOAR fracasados se quedaron sin autores de playbooks. La plataforma viene con conectores y un motor de flujos de trabajo, pero viene sin ningún conocimiento de tu entorno. Cada playbook tiene que diseñarse, construirse, probarse contra alertas reales y luego mantenerse a medida que cambian tus herramientas, tu red y tus atacantes. Un playbook que llama a una API que quedó obsoleta el trimestre pasado es peor que ningún playbook, porque falla en silencio en mitad de un incidente.
Desde el ángulo de la gobernanza, el SOAR es la forma en que varios objetivos de control dejan de ser aspiracionales. Dentro de un sistema de gestión de la seguridad de la información ISO/IEC 27001, respalda la parte técnica de la gestión de incidentes, el registro y la supervisión, y produce un registro coherente y con marca de tiempo de cómo se gestionó cada incidente, que es exactamente la evidencia que quiere un auditor. También sustenta la capacidad de respuesta que el NIST Cybersecurity Framework presupone y que regulaciones como NIS2 y DORA esperan que las organizaciones mantengan, en particular en torno a la gestión y notificación oportunas de incidentes significativos. Trata el SOAR como un multiplicador de fuerza para un proceso que funciona, no como un sustituto de tener uno.
Frequently asked questions
01¿Cuál es la diferencia entre SIEM y SOAR?
Un SIEM recopila y correlaciona registros y genera alertas. Un SOAR toma esas alertas y actúa sobre ellas ejecutando playbooks que enriquecen, clasifican, crean tickets y contienen. El SIEM encuentra la señal, el SOAR hace el trabajo de respuesta repetible que la rodea. Se despliegan habitualmente juntos en lugar de como alternativas.
02¿El SOAR reemplaza a los analistas del SOC?
No. El SOAR elimina el trabajo repetitivo de copiar y pegar para que los analistas puedan dedicar tiempo a la investigación y al criterio. Necesita personas para escribir y mantener los playbooks, para gestionar todo lo que los playbooks no pueden y para aprobar las acciones de contención de consecuencias importantes. Es un multiplicador de fuerza, no un reemplazo.
03¿Qué es un playbook SOAR?
Un playbook es un procedimiento de gestión de incidentes codificado y repetible que la plataforma puede ejecutar. Uno típico enriquece una alerta con contexto e inteligencia de amenazas, puntúa su urgencia, abre un ticket y, cuando la política lo permite, toma una medida de contención como aislar un host o deshabilitar una cuenta.
04¿Por qué fracasan los proyectos SOAR?
La mayoría se estanca porque no queda nadie para escribir y mantener los playbooks. La plataforma viene sin ningún conocimiento de tu entorno, así que cada playbook debe construirse, probarse y mantenerse actualizado a medida que cambian las herramientas y las amenazas. Sin un esfuerzo de redacción sostenido, el valor nunca se materializa.
05¿Es obligatorio el SOAR para el cumplimiento?
Ninguna norma nombra específicamente al SOAR. Sus capacidades se corresponden con los controles de gestión de incidentes, registro y supervisión de ISO/IEC 27001 y con las expectativas de respuesta del NIST CSF y de regulaciones como NIS2 y DORA. Es una forma de operacionalizar esas obligaciones de manera coherente, no una casilla que marcar en sí misma.