Detección sin firmas: cuatro motores, cuatro supuestos

8 Min. Tiempo de lectura

La detección basada en firmas solo reconocerá en 2026 los ataques que el atacante ya quería dejar atrás. Los modelos de análisis de comportamiento, los modelos de anomalías por ML y el razonamiento mediante LLM llenan la brecha; sin embargo, no son tres variantes del mismo instrumento. Quien los adquiere como una misma categoría crea un SOC que se queda sin saber qué hacer en un incidente real.

Lo más importante en resumen

Las firmas siguen siendo obligatorias, no la solución. Capturan el ruido que todo SOC necesita para funcionar. Para ataques dirigidos, estas firmas son el nivel equivocado.
El análisis de comportamiento necesita un inventario. Quien no tiene una comprensión básica de sus usuarios y máquinas, principalmente obtendrá ruido de las motores de análisis de comportamiento.
El razonamiento mediante LLM es la clase más costosa. Ofrece las mejores explicaciones, pero aún no es económico para operaciones 24/7. Es adecuado para investigaciones específicas, pero no para detecciones generales.

Relacionado:Análisis de amenazas impulsado por IA para SOCs alemanes / NIS2 cumple con el CLOUD Act

Qué realmente puede hacer una engine de detección en 2026

¿Qué es una engine de detección? Una engine de detección es el componente en un stack de SOC o EDR que extrae conclusiones a partir de datos brutos: aquí está ocurriendo algo que alguien debe analizar. Evalúa registros, telemetría y flujos de red, los compara con patrones o modelos y genera alertas. La engine decide qué se muestra como incidente y qué permanece en segundo plano.

La escena de la detección se ha diversificado en los últimos tres años. Mientras que hasta 2022 IDS y EDR dominaban el panorama, en 2026 cuatro engines metodológicamente diferentes se encuentran uno al lado del otro: firmas, análisis de comportamiento, anomalías por ML y razonamiento mediante LLM. Estos sistemas provienen de mundos distintos, tienen costos distintos y ofrecen resultados diferentes en casos reales de incidentes.

La discusión en los SOCs alemanes lleva dos años centrada en la pregunta de cuál de estos engines es el «correcto». La respuesta no es un único engine, sino una estratificación consciente. Quien lo ignora compra herramientas que se sobrepasan entre sí o que dejan brechas abiertas que nadie logra identificar.

Cuatro motores, cuatro suposiciones, cuatro debilidades

Motor	Punto fuerte	Punto ciego	Requisito previo
Signatura	Rápido, económico, determinista. Detecta malware masivo sin esfuerzo.	Uso de técnicas “living-off-the-land”, vulnerabilidades zero-day y atacantes dirigidos con herramientas personalizadas.	Flujos actuales de inteligencia sobre amenazas y reglas YARA bien mantenidas.
Análisis del comportamiento	Detecta secuencias anómalas como movimientos laterales inusuales o abusos de cuentas de servicio.	Posibles falsos positivos en entornos vivos sin un inventario limpio.	Inventario de usuarios y activos, junto con una fase de aprendizaje de referencia de seis a ocho semanas.
Anomalía basada en ML	Identifica patrones estadísticamente inusuales en grandes volúmenes de datos, incluso sin inteligencia sobre amenazas.	Difícil de interpretar, complicado de calibrar y sufre desviaciones cada vez que se modifica la infraestructura.	Pipeline de datos estable y presencia de ingenieros de ML en el equipo o en servicios gestionados.
Razonamiento basado en LLM	Proporciona explicaciones contextualmente ricas ante las alertas y sugiere el siguiente paso a seguir en la investigación.	El coste por alerta no es insignificante, con riesgo de alucinaciones en casos límite.	Agregación limpia de logs y uso de regiones de inferencia alemanas o europeas.

Fuente: Análisis propio de configuraciones SOC en la región DACH, actualizado a mayo de 2026.

La tabla no constituye un ranking. Muestra que cada uno de los cuatro motores resuelve un problema distinto, pero al mismo tiempo genera otro. Quien solo trabaja con tecnología basada en firmas termina con un SOC que no detecta ataques dirigidos. Quien adquiere únicamente razonamiento basado en LLM se encuentra con una solución costosa que carece de disciplina en el manejo de datos brutos.

Qué escenarios de ataque necesita realmente cada motor

Tres ejemplos de la rutina diaria de incidentes de los últimos trimestres hacen tangible esta estratificación.

En primer lugar, una oleada masiva de phishing con una familia de malware conocida. El motor de firmas detecta los archivos adjuntos en cuestión de minutos, porque están en la base de datos de inteligencia de amenazas. Un motor de comportamiento podría detectar el intento, pero aquí es la herramienta más lenta. Un motor LLM explicaría la detección sin acelerarla. Conclusión: las firmas son lo correcto aquí, cualquier otra cosa sería excesivo.

En segundo lugar, un atacante dirigido que accede al Active Directory mediante credenciales comprometidas y se desplaza lateralmente utilizando herramientas nativas del sistema. Ninguna firma de malware resulta efectiva. El análisis de comportamiento es aquí la primera oportunidad real, porque el patrón de inicios de sesión, el uso de cuentas de servicio y los accesos a archivos se desvían de la línea base. La detección de anomalías mediante ML puede complementar. El razonamiento LLM ayuda a priorizar las alertas y a sugerir los siguientes pasos de rastreo.

En tercer lugar, una filtración sutil de datos a través de APIs en la nube que se disfraza como un trabajo de copia de seguridad legítimo. Las firmas no ven nada, porque no hay malware involucrado. El análisis de comportamiento detecta algo si el volumen de la copia de seguridad es anómalo, pero las fluctuaciones legítimas pueden ocultar la señal. La detección de anomalías mediante ML sobre llamadas a APIs en la nube es aquí el motor que encuentra el patrón. El razonamiento LLM puede hacer comprensible el patrón para el SOC.

Una estrategia de detección sin una clara estratificación de motores es una lista de proveedores, no un concepto. En una auditoría, una lista no basta.

Cuánto cuesta concretamente el razonamiento LLM en la realidad de la región DACH

0,80 €

cuesta un análisis asistido por LLM por alerta de tamaño medio (aproximadamente 5.000 tokens de entrada, 1.500 tokens de salida) según los precios de lista actuales de los grandes proveedores. Con 2.000 alertas al día, esto supone una cifra anual de seis dígitos, antes de añadir las herramientas complementarias.

Fuente: Evaluación propia de precios de proveedores, situación a mayo de 2026.

Esto no significa el fin del motor LLM en el SOC, sino un límite para su uso. La capa LLM tiene sentido en 2026 principalmente en dos situaciones: en la triaje de alertas de alta prioridad y en la investigación de incidentes concretos. Para el procesamiento continuo de cada alerta, actualmente resulta demasiado cara; esto probablemente cambiará con los modelos de endpoint más económicos en la segunda mitad de 2026.

Quien ofrezca un motor LLM como detección generalizada debería comunicar abiertamente el precio por alerta. Quien no lo conozca, no ha calculado el producto con honestidad.

Tres pasos concretos para la estrategia de detección 2026

Estratificación en ventana de 90 días

Día 1 a 30

Verificar capa de firmas. Analizar feeds de Threat Intel, reglas estándar EDR y YARA personalizados para las cargas de trabajo propias. Qué está actualizado y qué está obsoleto. Actualizar o reemplazar los feeds desactualizados.

Día 31 a 60

Construir capa de comportamiento. Consolidar inventarios de usuarios y activos, activar módulo UEBA e iniciar fase de línea base. Seis u ocho semanas son realistas, no dos.

Día 61 a 90

Definir capa LLM para triaje. Establecer por nivel de severidad cuándo se ejecuta un análisis LLM. Fijar un límite de costes diario y garantizar el anclaje regional en la UE.

La capa de anomalías ML aún no encaja en ninguna plantilla de 90 días en 2026. Exige su propia canalización de datos, requiere un ingeniero de ML y necesita aceptar el ruido de falsos positivos durante la fase de aprendizaje. Quien lo tome en serio planifica un semestre, no un trimestre.

Qué ha cambiado respecto al SOC de 2022

Tres desplazamientos que cualquier actualización de arquitectura SOC debería tener en cuenta. Primero: las firmas ya no son la capa principal, sino la capa de higiene. Siguen siendo obligatorias, pero no constituyen la herramienta de diferenciación. Segundo: el análisis de comportamiento es estándar en 2026 para cualquier SOC serio, no una opción premium. Quien opere sin él acepta una zona ciega que será visible en auditorías NIS2. Tercero: el razonamiento LLM es la nueva clase premium con impacto real, pero con límites realistas.

Quien no refleje esto en la estrategia, compra demasiado en una capa o demasiado poco en otra. La mala inversión más frecuente en 2026 es una plataforma XDR costosa que promete cuatro motores bajo un mismo techo y que en la práctica solo implementa seriamente dos de ellos. Quien verifique esto, examina la hoja de ruta del producto del proveedor, no el folleto de marketing.

Preguntas frecuentes

¿Es realmente necesaria la detección basada en firmas cuando funcionan el comportamiento y el ML?

Sí, por dos razones. Primero, las firmas capturan el alto volumen de ataques estándar que sobrecargaría de ruido a los motores de comportamiento y ML. Segundo, son deterministas y explicables, lo cual es oro en valor para auditorías y documentación de cumplimiento. Un SOC sin capa de firmas tiene tasas más altas de falsos positivos en otras capas y una trazabilidad de auditoría dificultada.

¿Cuánto dura realmente la fase de línea base de un motor UEBA?

Seis u ocho semanas en un entorno estable, tres o cuatro meses en uno dinámico. Quien durante este periodo lleve a cabo una migración a la nube, una fusión de inquilinos de Office 365 o una reestructuración importante de AD, debería prolongar la fase de línea base; de lo contrario, el modelo aprenderá la reestructuración y no la normalidad. Las promesas de los fabricantes de «productivo tras 14 días» valen para casos de uso predefinidos, no para una línea base honesta.

¿Pueden los modelos de anomalías ML explicar por qué han generado una alerta?

Limitadamente. Los modelos estadísticos clásicos como Isolation Forest o Autoencoder emiten puntuaciones de anomalía, pero no explican su decisión en lenguaje natural. Las técnicas de explicabilidad como SHAP o LIME ayudan, pero son difíciles de consumir en el contexto de alertas en vivo. En la práctica, los LLMs asumen aquí la parte de explicación; esa es la tarea de la capa de razonamiento LLM.

¿Merece la pena un SIEM propio si un proveedor de XDR gestionado aporta todos los motores?

Depende del grado de madurez. Un SIEM propio o una plataforma de detección como Wazuh, Elastic Security o Sentinel otorga control sobre las propias reglas y los propios datos, pero exige contar con empleados que posean habilidades de ingeniería de detección. Un proveedor de XDR gestionado aporta los motores, pero también asume la lógica de las reglas. Quien necesite auditabilidad NIS2 y siga una propia estrategia cibernética, a medio plazo no podrá prescindir de competencias en ingeniería de detección internas.