Los sistemas de detección de intrusiones están pasando de depender casi por completo de firmas conocidas a una arquitectura híbrida que combina la coincidencia tradicional, el aprendizaje automático y la investigación agencial. Un análisis publicado en el blog de Stack Overflow sostiene que SnortML representa una capa de detección de bajo nivel dentro de Snort 3, mientras que la inteligencia artificial agencial se encarga de correlacionar eventos a lo largo del tiempo y entre distintas fuentes, así como de decidir el siguiente paso de la investigación.
El problema de las firmas tradicionales no es que sean imprecisas, sino que son precisas respecto a aquello para lo que fueron diseñadas. Una regla personalizada para una vulnerabilidad concreta, como CVE-2024-12345, puede detectar la explotación conocida con una tasa muy baja de falsos positivos, pero quizá no responda a una carga útil modificada que atraviese la misma ruta de código vulnerable. Entre la aparición de una nueva explotación en la naturaleza, su análisis, la escritura de una regla, su prueba y su distribución, pueden pasar días o semanas, una brecha peligrosa cuando la vulnerabilidad está siendo explotada activamente.
¿Cómo funciona SnortML dentro de Snort 3?
Cisco Talos presentó el motor SnortML en marzo de 2024 como un motor de detección mediante aprendizaje automático que funciona de forma nativa dentro de Snort 3. El motor no depende de un servicio externo en la nube, ya que la inferencia se realiza localmente dentro del mismo flujo de procesamiento utilizado para evaluar las reglas, y produce un resultado en menos de un milisegundo.
La implementación consta de la unidad snort_ml_engine, que carga modelos de TensorFlow previamente entrenados al iniciarse, y del inspector snort_ml, que recibe datos de los inspectores de servicios existentes en Snort 3 mediante una interfaz de publicación y suscripción. Cuando el inspector HTTP termina de analizar la solicitud, envía la cadena de consulta y el contenido POST al bus de eventos; después, SnortML los clasifica y devuelve un valor probabilístico que indica la probabilidad de que contengan un intento de explotación.
El modelo utiliza una red LSTM precedida por una capa de incrustación que transforma los valores de bytes sin procesar en representaciones vectoriales, lo que permite captar las relaciones y el contexto entre los bytes, antes de que la LSTM procese su orden y secuencia. Una capa densa final reduce el resultado a un único valor probabilístico. LibML, incluido con SnortML, utiliza la biblioteca XNNPACK para acelerar las operaciones matriciales. Según el artículo, una clasificación tarda aproximadamente 350 microsegundos en un procesador AMD a 4,7 GHz.
A partir de Secure Firewall 10.0.0, SnortML selecciona automáticamente un modelo adecuado para longitudes de 256, 512 o 1024 bytes. Las solicitudes que superan los 1024 bytes se truncan en ese límite antes de la clasificación. La primera versión comenzó detectando inyecciones SQL; posteriormente, hasta finales de 2025, la cobertura se amplió para incluir XSS e inyección de comandos, y las actualizaciones de los modelos llegan mediante el mismo sistema Lightweight Security Package utilizado para distribuir el contenido de las reglas.
Fortalezas y limitaciones del enfoque híbrido
SnortML funciona en paralelo con la coincidencia de firmas, no como sustituto de esta. El modelo puede detectar nuevas variantes de ataques que pertenecen a categorías conocidas, mientras que las firmas tradicionales proporcionan una línea de detección con poco ruido para los patrones confirmados. Cuando ambos mecanismos generan una alerta sobre la misma carga útil, esto puede considerarse una señal más fuerte que una alerta emitida únicamente por el aprendizaje automático, aunque cada mecanismo mantiene características de error diferentes.
Sin embargo, SnortML analiza un único parámetro HTTP, como una cadena de consulta URI o el contenido POST, y no sabe qué ocurrió antes o después de la solicitud ni qué hizo la dirección de origen durante los minutos anteriores. Por ello, una secuencia de reconocimiento, seguida de enumeración y después de una explotación personalizada, puede pasar sin que ningún paso individual supere el umbral de detección. Además, el modelo actual no observa túneles DNS, ataques de la capa TLS, explotación de SMB ni comportamientos anómalos en protocolos distintos de HTTP, porque los modelos disponibles están vinculados al flujo de datos del inspector HTTP.
El tiempo de procesamiento de aproximadamente 350 microsegundos añade un coste real, aunque limitado y predecible gracias a XNNPACK. Por ello, el rendimiento del modelo no debería evaluarse de forma aislada respecto al tamaño del conjunto de reglas, la complejidad de los protocolos y el presupuesto de procesamiento del dispositivo de seguridad.
¿Qué aporta la inteligencia artificial agencial?
El análisis distingue entre un modelo de aprendizaje automático que evalúa únicamente lo que tiene delante, un manual de operaciones SOAR que sigue pasos fijos y un agente que mantiene el estado de una investigación de varias etapas y decide qué debe examinarse a continuación basándose en los resultados anteriores. Según el planteamiento expuesto, el agente puede consultar en el SIEM eventos relacionados, comprobar la huella de un archivo mediante una plataforma de inteligencia de amenazas, recuperar la actividad de un usuario desde el proveedor de identidad y después reunir el contexto antes de recomendar una respuesta o derivarla a un analista humano.
El artículo señala el lanzamiento de ATOM, o Autonomous Threat Operations Machine, de IBM en abril de 2025, y el lanzamiento de Agentic SIEM de Trend Micro en agosto de 2025. Estos sistemas se presentan como plataformas de coordinación e investigación multiagente, no simplemente como interfaces conversacionales dotadas de información de seguridad. El análisis relaciona su expansión con la presión derivada de la escasez de personal; menciona una brecha mundial de aproximadamente cuatro millones de puestos vacantes en ciberseguridad, además de una encuesta de 2025 según la cual el 82% de los analistas de centros de operaciones de seguridad teme pasar por alto amenazas reales debido al volumen de alertas.
En esta arquitectura, Snort 3 y SnortML se convierten en sensores próximos a la red que proporcionan a la capa superior de inferencia lo que se ha observado realmente. Sin embargo, el mayor nivel de automatización hace que la precisión del sensor sea más importante: una falsa alerta no solo consume el tiempo del analista, sino también los recursos de los agentes y puede activar medidas de contención en entornos mal configurados. Además, el resultado probabilístico de SnortML permite construir una puntuación de confianza compuesta; una alerta que combine una firma tradicional y una puntuación de ML de 0,97 debería tratarse de forma distinta de una alerta emitida únicamente por ML con una puntuación de 0,61.
Arquitectura de integración y el problema del bucle de retroalimentación
El artículo propone una arquitectura que comienza con una capa de captura de paquetes mediante DAQ, utilizando AFPacket RSS o DPDK según los requisitos de rendimiento, seguida de una capa de detección que ejecuta en paralelo el motor MPSE Hyperscan y SnortML. Ambas capas envían eventos en formato JSON, incluidos datos de alertas, puntuaciones de probabilidad y flujos, a un bus de telemetría unificado.
Después, las tareas se distribuyen entre agentes especializados: un agente de clasificación, eliminación de duplicados y estimación de gravedad; agentes de enriquecimiento e inteligencia de amenazas; un agente de investigación que correlaciona registros del SIEM, del proveedor de identidad y de los puntos finales; y un agente de contexto que compara la actividad con patrones históricos y campañas conocidas. El planteamiento insiste en la necesidad de devolver los resultados confirmados de las investigaciones a los motores de modelos y reglas, en lugar de detener el flujo en la etapa de respuesta.
Las cargas útiles que se haya confirmado que son ataques, pero que hayan obtenido una puntuación baja o no hayan coincidido con ninguna firma, pueden convertirse en datos de entrenamiento o en entradas para formular nuevas reglas. Sin embargo, este proceso necesita validación humana y mecanismos para detectar el envenenamiento de los datos de entrenamiento, ya que un atacante podría intentar manipular los resultados de la investigación automatizada para introducir muestras corruptas en el proceso de nuevo entrenamiento.
Limitaciones de la implementación y recomendaciones prácticas
El análisis identifica otras brechas, entre ellas que la cobertura actual de SnortML se limita a parámetros HTTP, la falta de madurez de los protocolos de coordinación de agentes y la escasa interpretabilidad de las alertas del modelo. Los resultados actuales muestran la puntuación de probabilidad y la carga útil que provocó la alerta, pero no explican qué bytes o regiones de la entrada influyeron en el resultado. Asimismo, según el artículo, la resistencia del modelo frente a la ofuscación, la codificación, la manipulación de espacios y la inyección de comentarios SQL no se ha descrito públicamente en evaluaciones publicadas.
En la práctica, el artículo recomienda comenzar a ejecutar SnortML en un puerto de monitorización y en modo de solo alerta, no en la ruta directa con bloqueo. Deben medirse los falsos positivos sobre el tráfico de aplicaciones conocidas durante al menos dos semanas que cubran los ciclos de trabajo habituales, y después ajustar los umbrales antes de activar el despliegue selectivo inline. Asimismo, la puntuación de ML debe tratarse como un factor dentro de un cálculo de confianza compuesto, no como un sustituto de la firma tradicional ni como un desencadenante aislado del bloqueo.
En cuanto a las medidas de contención de alto impacto, como bloquear direcciones IP, aislar dispositivos o restablecer credenciales, deben permanecer dentro de un circuito de revisión humana. La conclusión principal del análisis es que la automatización puede encargarse intensivamente de la clasificación, el enriquecimiento, la correlación y la recopilación de contexto, mientras que la decisión final de respuesta sigue siendo más segura cuando la revisa una persona basándose en el contexto recopilado por el agente.