Qué es SOAR y por qué es clave en la ciberseguridad moderna

En ciberseguridad, hay algo casi tan numeroso como las vulnerabilidades, los acrónimos. Y hoy vamos a tratar uno fundamental si queremos que nuestro departamento de ciberseguridad funcione óptimamente: SOAR (Security Orchestration, Automation and Response u Orquestación de Seguridad, Automatización y Respuesta). De implementar estas siglas dependerá que nuestra respuesta a incidentes sea veloz y, sobre todo, eficiente.
Por eso, analizaremos qué es SOAR, para qué sirve, cómo funciona y cómo puede multiplicar nuestra efectividad contra amenazas. O, al menos, hacernos los días más llevaderos.

¿Qué es SOAR?

Las películas dan la imagen de que la seguridad informática consiste en hackers con enorme conocimiento peleando en la terminal, escribiendo hechizos incomprensibles en una pantalla negra. O tecleando a toda velocidad incoherencias, hasta que el más rápido dice «estoy dentro».
Nada más lejos de una realidad de teclados con migas de Doritos, script kiddies pegando instrucciones que no comprenden, toneladas de spam y phishing por minuto y usuarios corriendo a hacer clic justo donde has dicho que ni se les ocurra.
En ese contexto, SOAR es una tecnología que permite dos objetivos principales:

• Orquestar, es decir, coordinar de manera sincronizada respuestas adecuadas a las principales amenazas.
• Automatizar en lo posible respuestas óptimas ante amenazas habituales y repetitivas.

En la situación actual, implementar un SOAR es imprescindible en organizaciones con cierta complejidad, tamaño o importancia estratégica. ¿Por qué? Porque la ciberserguridad hoy se parece más a «desangrarse por mil pequeños cortes» que al enfrentamiento contra adversarios que lanzan ataques zero-day con técnicas en la punta de lanza.
Los escaneos de puertos constantes, los miles de emails de phishing, el uso de credenciales antiguas filtradas a la web oscura… Somos Gulliver sobrepasados por la fuerza del número de diminutos liliputienses.
En ese contexto, o automatizas respuestas, o tienes a tus expertos ocupados (y sobrepasados) por constantes tareas manuales de mitigación de amenazas poco complejas. Un derroche de recursos.
Un SOAR ejecuta de forma automatizada esa labor de respuesta, pesada y repetitiva, pero necesaria.
Su objetivo no es sustituir al SOC, sino quitarle peso de la espalda, liberando a expertos humanos para dedicarlos a tareas complejas de alto valor, como colapsar el ancho de banda con torrents de todas las temporadas de Star Trek, mientras las respuestas automáticas se ocupan de baneos de IPs y gestión de phishing.
Sin un SOAR somos más vulnerables. Porque mientras tenemos a nuestros genios asignando tickets o actualizando listas de bloqueo, un hacker se ha colado por un dispositivo IoT, ha realizado movimiento lateral a una impresora y busca cómo saltar a otro equipo y escalar privilegios, mientras los guardianes del templo están mitigando a mano el enésimo DDoS.

Componentes clave de una solución SOAR

Los pilares que sustentan una solución SOAR vienen dados por las letras de su acrónimo:

• Orquestar.
• Automatizar.
• Responder.

Orquestación significa coordinar herramientas y sistemas de seguridad, como un SIEM, EDRs, firewalls… Dependiendo de la solución elegida, se puede aplicar mediante APIs, conectores, etc.
Esta orquestación permite la automatización de contramedidas, que es el siguiente componente clave de un SOAR.
Un ejemplo muy básico podría ser analizar adjuntos de correo. En la herramienta SOAR se puede crear un flujo de respuesta (llamado playbook y que veremos más a fondo) para estos casos. Este puede consistir en analizar dichos adjuntos, comprobar que sean malware y, en ese caso, bloquear al remitente y poner en cuarentena el mensaje. Quizá mandando un aviso a dicho remitente, en caso de ser del dominio de la empresa, bloqueando preventivamente su cuenta.
Los playbooks de respuesta automática pueden ser muy flexibles y, con ellos, no desperdicias cinco años de ingeniería en analizar adjuntos y bloquear cuentas.
Finalmente, viene la respuesta. La automatización de flujos anterior la contendrá en ellos en muchas ocasiones, y dicha respuesta puede variar según la amenaza.
Por ejemplo, para cosas sencillas como la anterior, podemos automatizar ese bloqueo preventivo de cuenta del dominio. En otros casos, se puede definir un playbook que requiera aprobación humana, incluyendo crear un mensaje para el SOC, a fin de que tome una decisión o cartas en el asunto.

¿Cómo funciona un SOAR?

En el núcleo de funcionamiento del SOAR están los playbooks de los que hablábamos.
Un playbook (o «libro de jugadas», término tomado de deportes como el fútbol americano, donde representan estrategias de juego predefinidas, que los jugadores conocen y los líderes en el campo señalan para que se ejecuten) son flujos de trabajo automatizados que indican al SOAR qué debe hacer en cada situación.
Dependiendo de la herramienta SOAR elegida, la creación de dicho flujo puede ser programada en código (Python, por ejemplo) o mediante no code o low code.
Por ejemplo, Splunk SOAR permite definir los playbooks de manera visual, creando un diagrama de flujo que indique qué se debe hacer en cada situación, sin tener que estar tecleando condicionales if.
Así, un ejemplo de flujo de trabajo típico sería:

• El SIEM manda una alerta de posible correo con malware, información que le ha venido desde el EDR instalado en un endpoint, como el portátil del CEO.
• El SOAR recibe dicha alerta y dispara el playbook correspondiente.
• Se ejecutan las primeras acciones de respuesta automática, como aislar el email potencialmente malicioso.
• Ahora puede haber decisiones condicionales en el playbook, lo que otorga flexibilidad. Si el email es externo y nunca nos había escrito, se borra el mensaje, se bloquea al remitente y no se molesta a nadie, porque eso pasará cien veces al día. El SOAR guarda lo hecho en un log por si acaso y ya está.
• Si el email viene del dominio propio, el playbook puede determinar que quizá el peligro es mayor, y algo puede pasar con la configuración DMARC por ejemplo, de modo que, en ese caso, dispara una acción híbrida diferente. Por un lado, automatiza poniendo en cuarentena el mensaje, crea una alerta con la información pertinente del mismo y la envía al SOC, para que investigue.

Es importante no confundir playbook con runbook. Este último es un proceso a seguir, al estilo de las recetas de la abuela por pasos lineales, para realizar una acción, como levantar un servicio caído.
Los playbooks suelen ser más complejos y no lineales, tomando decisiones según condiciones, en lugar de seguir siempre los mismos pasos como un runbook.

Beneficios de implementar un SOAR en tu organización

Las ventajas de un SOAR son claras. A nuestro pequeño ejército de ciberseguridad le sumamos drones automatizados que se despliegan en el campo de batalla cuando la monitorización de seguridad ha encontrado algo. Así eliminamos esos constantes «pequeños cortes que nos desangran recursos».
Eso produce:

• Una reducción de los tiempos medios de detección y respuesta (MMTD y MMTR respectivamente por sus siglas en inglés).
• Una mayor capacidad de respuesta sin aumentar los efectivos humanos del SOC.
• Un mejor cumplimiento normativo, al poder definir playbooks que guarden automáticamente la información necesaria para auditorías forenses, o constaten que vigilamos activamente nuestra infraestructura IT.
• Una reducción de errores humanos en respuestas, especialmente las repetitivas, proclives a fallos por cansancio o falta de atención.
• Una respuesta estandarizada y más efectiva, basada en playbooks que implementan las mejores prácticas.

Casos de uso comunes de SOAR

Hemos visto ejemplos de amenazas ante las cuales un SOAR es ideal para no volver (aún más) locos a nuestros ingenieros, pero otros casos de uso habituales son:

• Mitigación de phishing o malware, ya vista en los ejemplos.
• Una mejor gestión de alertas y falsos positivos. Siempre que las reglas de los playbooks sean buenas, como por ejemplo, ignorar intentos de login desde IPs internas.
• Una investigación más rápida de incidentes. Por ejemplo, consolidando en la respuesta un solo informe el log del Active Directory, los del firewall y el EDR, en lugar de que el SOC tenga que bucear en cada uno.
• Mitigación automática de ataques DDoS.
• Automatizar cumplimiento normativo (informes de auditoría, registros de cada acción en un incidente…).
• Automatizar parcheados de vulnerabilidades en sistemas no críticos.
• Bloquear cuentas de agentes maliciosos internos (cuando se detectan descargas masivas de datos, por ejemplo).
• Etc, etc.

Diferencias entre SOAR y SIEM: ¿rivalidad o complemento?

En ciberseguridad, como en la vida, no existen blancos y negros, ni fronteras siempre bien delimitadas. Además, hay una inclinación a que las herramientas traten de ampliar sus funcionalidades.
Así, hay un fuerte incentivo a que, por ejemplo, un software IDS, como Snort, no solo escanee la red, sino que también tenga funcionalidades de prevención, pasando a ser un IPS.
Un SIEM y un SOAR suelen situarse en una «posición contigua» dentro de la estructura de ciberseguridad. Por eso, tienen cierta tendencia a diluir la frontera que comparten y que uno adopte ciertas prestaciones del otro, para hacer su funcionalidad más atractiva.
Sin embargo, SIEM y SOAR son dos especialistas de élite, cada uno en lo suyo:

• SIEM es el experto en analizar información, correlacionarla para convertirla en conocimiento clave e incluso usar Machine Learning para predecir posibles amenazas que no aparecen a simple vista.
• SOAR es el experto en actuar basado en esa información, en dar la respuesta, con capacidades mayores y más flexibles.

Así, un SIEM puede tener ciertas prestaciones de respuesta automatizada y SOAR cierta capacidad de análisis, pero la clave de la seguridad óptima es poner a trabajar juntos a ambos especialistas.
Sin embargo, es verdad que la respuesta será tan buena como la información suministrada.
De lo contrario, el SOAR empezará a bloquear masivamente IPs innecesarias si la información que recibe es mediocre, o borrar emails que deberían llegar al buzón. De ahí la importancia de un SIEM que aglutine y analice la información antes de alertar al SOAR.
Resumiendo:

Integración de SOAR con otras herramientas de seguridad

SOAR no puede funcionar solo. Depende, como hemos visto, de su conexión al SIEM (en caso de haberlo) o a otros programas (como un IDS) para que le digan sobre qué tiene que actuar. Sin embargo, también depende de conectarse a otros dispositivos para poder ejecutar sus playbooks. Esa es la orquestación de su nombre, dirigiendo con su batuta a los demás elementos para responder a la amenaza.
Ahí es donde entra la importancia de las APIs y los conectores, de que sean fáciles de configurar y que la solución trabaje bien en equipo.
Pongamos un ejemplo de arquitectura SOAR moderna y cómo funcionarían sus conexiones en un caso sencillo de malware.

• Un empleado descontento llega a la oficina con un USB cargado de malas intenciones.
• Ejecuta el malware que hay en él, pero el EDR vigila esa acción y, como está conectado a un SIEM, se lo comunica, el SIEM decide que es una amenaza y alerta al SOAR.
• El SOAR implementa el Playbook definido para esos casos, de modo que conecta con el EDR para paralizar la ejecución del archivo.
• Del mismo modo, el SOAR conecta con Virustotal vía API, por ejemplo, para enviarle el archivo.
• Si recibe respuesta positiva de Virustotal, SOAR conecta con el EDR bloqueando el equipo y con el sistema de tickets para crear uno para el SOC sobre lo ocurrido, y quién está implicado.

Como podemos ver, el SOAR depende de las conexiones con otras tecnologías, en uno y otro sentido, para orquestar y responder de forma automática.

Consideraciones para implementar una solución SOAR

Leyendo esto, cualquier responsable de ciberseguridad querrá tener de su lado ese ejército de pequeños «robots programables», que ayudan en lo tedioso y no necesitan comer o ser fustigados, al contrario que sus ingenieros.
Sin embargo, el SOAR no es la respuesta a todas las oraciones ni para todas las organizaciones. Antes de lanzarse, es necesario tener en cuenta algunas consideraciones.
La primera, un análisis de necesidades.
Dependiendo de nuestros recursos e infraestructura a proteger, quizá no sea necesario un SOAR y otras soluciones con algo de respuesta automatizada resulten suficientes. Hemos de tener en cuenta que un SOAR añade complejidad en muchos sentidos y cabe hacerse preguntas importantes como por ejemplo:

• ¿Dedicamos mucho tiempo a tareas repetitivas? Si no, un SOAR no será de gran ayuda.
• ¿Tenemos soluciones SIEM, IDS, etc., que puedan coordinarse bien? Porque un SOAR no hace nada solo.
• ¿Tenemos procesos predefinidos, pero poco automatizados, susceptibles de delegar en el SOAR?

Si el análisis concluye que lo precisamos, entonces hay que elegir entre las opciones disponibles Como esto es la vida real, la primera restricción es presupuestaria, y la segunda, de complejidad.
Hay soluciones de código abierto como Shuffle, que tienen capacidades de respuesta automática, pero lo cierto es que son complejas de configurar.
Y yo amo el código abierto sobre todas las cosas, pero seguramente, si somos una organización estratégica o con riesgos, una solución comercial suele ser más adecuada. Splunk, adquirida no hace mucho por Cisco, es una de las opciones más consideradas, pero no la única: Fortisoar de Fortinet o Microsoft Sentinel son otras de las soluciones más habituales.
Luego viene el despliegue y la integración, que va a depender de la herramienta, claro.
Tras ese despliegue, deberemos hacer pruebas limitadas, probar un par de playbooks, comprobar que van bien, implementarlos «en producción», ir probando más…
A la vez, un SOAR cambia los procesos de seguridad del SOC.
Así, no solo habremos de formar al personal en la nueva herramienta, sino también gestionar el cambio de funciones, dado que muchas tareas monótonas (con suerte) se liberarán y nuestros efectivos humanos adquirirán otras responsabilidades diarias.

SOAR en el ecosistema de Pandora FMS

Pandora SIEM es el mejor aliado en una estructura de seguridad con un SOAR. Colocándose justo «antes» de sus capacidades de actuación, proporciona prestaciones avanzadas de información y alerta, multiplicando la efectividad y reduciendo la carga.
El hecho de que Pandora SIEM ejerza de central de inteligencia reduce la ejecución de playbooks innecesarios o contraproducentes, porque otra vez se bloquearon equipos por alertas falsas y todos nos gritan mientras tratamos de reducir el downtime y soñamos entre lágrimas con ser jardineros.
La integración con el ecosistema Pandora no es solamente con SIEM, sino con ITSM en general, haciéndonos la vida más fácil.
Por ejemplo, Pandora SIEM detecta actividad maliciosa y envía la alerta al SOAR. Este dispara el playbook adecuado, pero imaginemos que es algo serio, de modo que las acciones automáticas mitigan, pero no resuelven.
En ese caso, el SOAR puede crear un ticket en Pandora ITSM para el SOC, con toda la información necesaria, reduciendo el tiempo de respuesta y resolución.
O bien puede ser una falsa alarma, porque el escaneo de puertos se ha realizado desde nuestro Equipo Azul para comprobar posibles puertas mal cerradas. SOAR detecta eso y, en su playbook, puede tener definido cerrar el ticket en Pandora ITSM, especificando suceso y motivos.
De esta manera, el SOC queda libre para tareas de prioridad alta, como jugar online en horas de trabajo sin que nadie se entere.
Como vemos, un SOAR alivia un mal muy extendido en la ciberseguridad actual, pero requiere un análisis previo sobre su conveniencia, así como un presupuesto y un tiempo de configuración y puesta en marcha.
Eso sí, si funciona, habremos ampliado nuestra capacidad de respuesta, desplegando «drones robotizados» en el campo de batalla, que nos liberarán de lo repetitivo.