Estimados amigos de Inseguros !!!
Seguimos con la serie sobre Wazuh, y hoy vamos a meternos en uno de esos temas que, cuando se cuentan mal, parecen magia. Y cuando se cuentan bien, simplemente son una mejora operativa bastante interesante.
Me refiero a integrar Wazuh con un LLM, la famosa IA vamos… xD
Aquí hay que empezar poniendo un poco de orden, porque si no enseguida entramos en la película de siempre. No, esto no significa que ahora el SIEM “piense”. No significa que vaya a sustituir a un analista. Y tampoco significa que de repente puedas dejar de entender alertas, logs y contexto técnico porque ya “te lo explica la IA”.
Pero si quieres aprender de verdad esta lección, ya sabes,curso de Wazuh y seguimos !!!
Lo que sí significa es algo mucho más útil: poder consultar información de seguridad en lenguaje natural, resumir grandes volúmenes de logs y obtener una ayuda adicional para interpretar alertas y contexto sin tener que estar peleándote todo el rato con queries más complejas. Esa es la idea que se plantea en la lección: usar un modelo LLM para preguntarle cosas como intentos de login, creación de usuarios, actividad reciente en agentes o resúmenes de logs concretos.
Y esto, bien planteado, tiene sentido.
Porque uno de los problemas habituales cuando alguien empieza con un SIEM no es solo la cantidad de información. Es la fricción. Tienes datos, tienes alertas, tienes logs… pero sacar valor de ahí exige conocer la sintaxis, saber filtrar bien, entender qué buscar y, sobre todo, hacer las preguntas correctas.
Con un LLM por encima, parte de esa fricción baja.
No porque desaparezca la complejidad real, sino porque puedes pedir determinadas cosas en lenguaje humano. En lugar de construir una consulta desde cero, puedes preguntar directamente por fallos de acceso SSH en las últimas horas, por un resumen de eventos recientes o por actividad sospechosa en un agente concreto. El objetivo no es eliminar el análisis, sino facilitar el acceso a la información.
En el material del curso se usa Llama 3, ejecutado de forma local, lo cual además tiene bastante sentido en este contexto. Primero, porque hablamos de un modelo abierto. Segundo, porque para muchos entornos de seguridad no siempre resulta buena idea andar enviando determinada información fuera alegremente. Y tercero, porque permite montar un laboratorio bastante interesante sin depender de terceros.
Ahora bien, donde esto empieza a ser de verdad útil no es en el “pregúntame cualquier cosa”, sino en tres casos concretos.
El primero es el resumen operativo. Cuando tienes mucho volumen de logs o muchas alertas, un chatbot puede ayudarte a condensar la información y devolverla de forma más legible. No sustituye la revisión técnica, pero sí puede ahorrarte tiempo en una primera pasada.
El segundo es la explicación de alertas y contexto. Esto me parece especialmente interesante para gente que está aprendiendo. Muchas veces ves una alerta, la descripción está en inglés, la regla no te queda clara o no entiendes si estás ante algo serio o ante un falso positivo bastante normal. Tener una capa que te explique qué significa una alerta, por qué puede ocurrir y qué contexto operativo tiene, ayuda bastante.
Y el tercero son las recomendaciones. No ya solo qué ha pasado, sino qué podrías hacer para reducir la probabilidad de que vuelva a pasar. Esto, evidentemente, hay que cogerlo con criterio, porque un LLM no conoce tu entorno como lo conoce tu equipo. Pero como apoyo para orientar medidas o para acelerar una primera interpretación, puede resultar útil.
Luego está la parte delicada, que es donde conviene no fliparse.
En la explicación también se comenta que el modelo puede encontrar algunos patrones o correlaciones no contemplados en reglas predefinidas. Esto hay que leerlo bien. Puede ayudar a relacionar señales y a proponer lecturas que quizá no habías tenido en cuenta, sí. Pero no convierte un chatbot en un sistema de detección milagroso. Si las fuentes son malas, si faltan logs, si el entorno está mal configurado o si el modelo interpreta regular, lo que tendrás será una respuesta aparentemente convincente… y eso, en seguridad, puede ser peligroso.
Por eso este tipo de integración me gusta más como copiloto que como piloto.
Como ayuda para consultar, resumir, interpretar y acelerar. No como sustituto del criterio del analista.
Es decir, no estamos hablando solo de “usar IA”. Estamos hablando de montar una pequeña arquitectura práctica: Wazuh genera y almacena eventos, el modelo local procesa o ayuda a consultar esa información y el operador interactúa a través de una interfaz tipo chatbot. Eso ya empieza a parecer una pieza útil de laboratorio o incluso una ayuda interesante en determinados contextos controlados.
Y encima tiene otro valor formativo.
Sirve para entender que el futuro del analista SOC no va solo de aprender herramientas aisladas. Va de saber combinar fuentes, automatización, contexto, modelos de apoyo y criterio técnico. Hoy puede ser Wazuh con Llama 3 en local. Mañana puede ser otra arquitectura. Pero la idea de fondo será la misma: reducir fricción y sacar valor real del dato de seguridad.
Porque una cosa es ver una demo bonita, y otra entender qué estás montando, por qué tiene sentido, qué límites tiene y dónde te puede ayudar de verdad en un entorno de monitorización.
Seguiremos con más partes de Wazuh, porque aquí todavía queda bastante jugo: reglas, alertas, correlación, casos prácticos y también estas integraciones modernas que, si se usan con cabeza, pueden aportar bastante.
Gracias por leerme !!!
