Automatización en Ciberseguridad: ¿estamos listos?

Después de casi quince años de evolución de los SOC (Centro de Operaciones de Seguridad) e integrarlos con múltiples herramientas, como veíamos en un post anterior, nos hemos enfrentado con una serie de retos que llevamos tiempo intentamos solucionar, como la automatización. Sin embargo, con los avances en la tecnología de hoy, estamos más cerca de poder generar automatizaciones que minimicen los errores o fallos en detecciones y monitoreo.

En la mayoría de las lecciones aprendidas tras una respuesta a incidentes, surgen preguntas como: ¿Por qué no lo detectaron? ¿Por qué nadie vio la alerta? ¿Con qué se monitoreaba ese dispositivo? ¿Por qué no estaba actualizado? ¿Cuánto tiempo llevaba esa contraseña? ¿Nadie se le ocurrió revisar esa IP?

La cantidad de alertas y falsos positivos es inmanejable, y el exceso de alertas no relevantes puede saturar a los analistas.

Las respuestas, aunque con varios matices, suele coincidir en una lógica común, que se ve reflejada en respuestas como: la cantidad de alertas y falsos positivos es inmanejable, los analistas de primer nivel no validaron de forma diligente el origen de la conexión, ese segmento de red no se monitoreaba, o simplemente, nadie entendió que eso era parte de un ataque.

El desafío de los falsos positivos

Esa problemática es precisamente la que la automatización busca mitigar. La idea es que sean los procesos de analítica y flujos de trabajo establecidos los que tomen las decisiones y acciones necesarias, notificando a los responsables y guardando los registros de las acciones. No obstante, estos desarrollos no siempre eran tan efectivos o confiables, por lo que en muchos SOC se mantiene el análisis tradicional.

Esto está cambiando, debido a las nuevas tecnologías y la integración de sistemas que permiten realizar una analítica de grandes volúmenes de datos casi en tiempo real. Incluso, algunas empresas especializadas ya ofrecen conectar esos equipos a nubes que enriquecen la alerta y mejoran la detección mediante sistemas analíticos avanzados.

El mundo de la ciberseguridad y el open source siempre han estado estrechamente vinculados. Hoy, vemos cómo estas comunidades se unen nuevamente, puntualmente hablando de sistemas de automatización por flujos de trabajo, como lo es n8n.

Esto abre un panorama de posibilidades, donde las preguntas en las reuniones de lecciones aprendidas podrían cambiar. Uno de los principales enfoques actuales es detectar eventos o alertas que se esconden entre falsos positivos, o enriquecer una alerta con inteligencia de amenazas en línea, de modo que el analista no solo reciba la alerta, sino que esta venga acompañada de datos relevantes sobre el comportamiento o la seguridad de esa IP.

La automatización no reemplaza al analista, lo potencia.

Algunos ejemplos

Empecemos con un caso interno, el EDR de un servidor de archivos reporta un acceso al directorio de shadow copy (copia de seguridad de Windows), esta alerta es crítica porque suele indicar que un atacante está eliminando la posibilidad de restablecer el sistema después de que ejecute un ransomware. Pero también puede indicar que el administrador está haciendo una validación de las copias de seguridad.

En un SOC tradicional, el analista tendría que detectar esa alerta entre varias decenas que pueden estar sucediendo simultáneamente. Cuando la tenga, debe tomar los datos de la alerta y buscar más información que le permita definir si el comportamiento es válido, por ejemplo, confirmar si la IP es del área de TI o si estaba programado algún mantenimiento o revisión en ese servidor, con esos datos determinar la acción a tomar frente a la posible amenaza.

—Esto puede tardar varios minutos e incluso horas, dándole la oportunidad a un atacante de tomar el control y ejecutar el ransomware antes de que esa validación termine.

Los sistemas pueden hacer en segundos lo que antes tomaba horas.

En un proceso automatizado, se tienen interconectados los sistemas y la información con la que se puede enriquecer las alertas, por lo tanto, una vez la alerta llegue, sin importar si viene entre millones de otros eventos, se analiza con los niveles configurados y se enriquece tomando cada dato de la alerta y usándolo de insumo de búsqueda en bases de datos o sistemas de planeación. En segundos el sistema detectará si la actividad estaba planeada o no, enviando automáticamente la acción, que puede ser de bloqueo o de notificar en la bitácora el cambio.

Ahora miremos un caso externo, donde se reporta un intento fallido de acceso a la administración de un servicio web. Esta alerta se puede presentar por una equivocación del usuario responsable o ser parte de un intento de fuerza bruta al usuario de administración de la plataforma, para determinar la causa se requiere analizar el contexto.

Para este caso miremos el procedimiento que se debería realizar al presentarse esa alerta. Una vez la alerta se activa en el SIEM,

1. Se debe realizar una revisión en varias fuentes de eventos
   1. Registros de éxito y fallos de autenticación del servicio, para validar la periodicidad del evento.
   2. Registros de autenticación en la red, para validar si el usuario tiene la misma dirección IP que está intentando acceder.
   3. Registros de conexiones en el firewall y servicio, para analizar si la IP ha realizado alguna otra acción en los servicios expuestos.
2. Si la dirección IP es externa se requiere enriquecer la información asociada, por lo que se necesita
   1. Confirmar reputación de la IP en varios motores públicos o privados.
   2. Validar geolocalización reportada de la IP.
   3. Consultar reportes de acciones de esa IP en la red.
3. Del usuario que falló el acceso se debe validar:
   1. Accesos realizados ese día, para validar si es la misma dirección.
   2. Número de intentos fallidos en la plataforma.
   3. Último cambio de credenciales de acceso.

Con estos datos entraría la fase de las acciones para mitigar la amenaza o reportar el caso como un falso positivo y cerrar el caso.

En un SOC tradicional, el analista debe realizar todos los pasos accediendo a las consolas y validando los datos y reportes. Este proceso puede tomar varios minutos y depende en alguna medida de la capacidad y tiempo del analista para realizar las búsquedas en los eventos de registro. Además, esto solo sería la primera parte para determinar el posible riesgo o amenaza de esa alerta.

Este proceso se puede automatizar e incluso llevar dentro del mismo proceso a una respuesta estandarizada ante esta amenaza, lo cual se demoraría unos segundos en realizar los análisis de los eventos y de enriquecimiento de las direcciones, con lo que se puede plantear que la acción sea un bloqueo de IP externa, forzar el cambio de credenciales del usuario, reportar a las áreas responsables y generar el caso. Todo en unos dos o tres minutos.

El verdadero reto no es automatizar, sino hacerlo con eficacia y confianza. Requiere preparación, experiencia y validación integral.

Parece sencillo, pero...

Como muchas cosas en tecnología, la implementación en papel suena simple. Sin embargo, requiere preparación de la red, del personal y de los procesos para que la automatización funcione de forma sincronizada y validada.

Este proceso no puede implementarse de la noche a la mañana ni pretende reemplazar a los analistas. Más bien, los automatismos deben enfocarse en casos conocidos y repetitivos, permitiendo que los analistas se conviertan en investigadores de nuevos escenarios y patrones de anomalías.

Automatizar no es el final del camino, es el comienzo de una nueva forma de defendernos.

Ciberseguridad

Hemos construido el SOC del futuro con IA, talento y NextDefense XDR

30 de octubre de 2025