Línea base individual y por grupo de pares: el modelo aprende qué es normal para cada entidad y también para su peer group (departamento, rol, tipo de servidor). Que un administrador de bases de datos ejecute consultas masivas es normal; que lo haga alguien de marketing, no.
¿Qué es UEBA?
UEBA (User and Entity Behavior Analytics) es una tecnología de detección que construye una línea base estadística del comportamiento normal de cada usuario y entidad —cuentas, equipos, aplicaciones, identidades de servicio— y genera alertas cuando la actividad se desvía de forma significativa de ese patrón. En lugar de reglas fijas del tipo "tres logins fallidos = alerta", aplica modelos de machine learning sobre semanas de telemetría: horas de conexión, volúmenes de descarga, recursos accedidos, geografías, secuencias de acciones. Es la pieza que permite ver lo que ninguna firma dispara: unas credenciales comprometidas usadas con calma o un empleado que exfiltra datos poco a poco.
¿Por qué importa?
Las dos categorías de incidente más difíciles de detectar comparten un rasgo: toda la actividad es técnicamente legítima. Una amenaza interna usa sus propios permisos; un atacante con credenciales robadas inicia sesión igual que el titular. Las reglas de correlación clásicas de un SIEM no tienen nada que correlar, porque no hay malware, no hay exploit y no hay indicador de compromiso conocido. UEBA cambia la pregunta: en lugar de "¿coincide esto con un patrón de ataque conocido?", pregunta "¿es esto normal para esta persona, este servidor o esta cuenta de servicio a esta hora?". Un comercial que un martes a las 03:14 descarga 4 GB de un repositorio que nunca había tocado no viola ninguna regla, pero sí su línea base. Por eso los fabricantes lo han integrado como módulo nativo: Microsoft Sentinel UEBA, Splunk UBA, Exabeam o Securonix lo usan para priorizar con puntuación de riesgo lo que el SOC debe investigar primero, y cada vez más motores XDR incorporan analítica de comportamiento equivalente.
Puntos clave
Puntuación de riesgo acumulativa en lugar de alertas binarias: cada anomalía suma puntos al score de la entidad (login inusual +10, primera vez en ese recurso +15, volumen anómalo +25). El SOC investiga entidades con score alto, no cada evento suelto, lo que reduce drásticamente la fatiga de alertas.
Casos de uso principales: detección de insider threat (exfiltración previa a una baja, abuso de privilegios), cuentas comprometidas tras phishing, movimiento lateral con credenciales válidas y escalada de privilegios anómala.
Cubre también identidades no humanas: cuentas de servicio, service principals y tokens de API tienen comportamientos muy estables, así que una desviación (una cuenta de backup que de pronto lee buzones) es señal fuerte. Ver NHI.
No sustituye al SIEM, lo potencia: UEBA consume la telemetría que el SIEM ya centraliza (autenticación, EDR, proxy, cloud, DLP) y devuelve contexto de riesgo que alimenta la respuesta, incluida la automatización vía SOAR.
Necesita datos y paciencia: un periodo de aprendizaje de 2 a 4 semanas mínimo, fuentes de identidad bien conectadas (Active Directory, Entra ID) y tuning continuo. Sin telemetría de calidad, el modelo aprende ruido.
Ejemplo: la cuenta comprometida que ninguna regla detecta
Un empleado de finanzas cae en un phishing de proxy inverso que roba su sesión con MFA incluida. El atacante no despliega malware: inicia sesión con la cookie robada y se dedica a leer. Ninguna regla clásica salta, porque cada acción individual es válida.
El módulo UEBA, en cambio, empieza a sumar: sesión desde un ASN residencial de otro país nunca visto para ese usuario (+15), a las 02:40 fuera de su franja habitual (+10), acceso por primera vez a un site de SharePoint del departamento legal (+20), descarga de 600 ficheros en 20 minutos cuando su media diaria es de 12 (+30) y creación de una regla de reenvío en el buzón (+25). El score de la entidad cruza el umbral y el SOC recibe una única investigación priorizada con toda la cadena de anomalías ya reconstruida. El analista revoca sesiones, restablece credenciales y activa la respuesta a incidentes antes de que el atacante monetice el acceso. Sin línea base de comportamiento, este incidente se habría descubierto semanas después, probablemente por la factura del fraude.
Errores habituales
- Comprar UEBA como bala de plata sin arreglar antes la telemetría: si los logs de autenticación, EDR y cloud no llegan completos y con identidades bien resueltas, el modelo puntúa sobre datos parciales y el resultado es ruido con apariencia científica.
- No respetar el periodo de aprendizaje o entrenarlo en un entorno ya comprometido: si el atacante lleva meses dentro, su actividad forma parte de la línea base y pasa a ser 'normal'.
- Tratar cada anomalía como incidente: UEBA está diseñado para acumular señales débiles en un score, no para generar tickets por cada login raro. Usarlo como generador de alertas binarias reproduce la fatiga que venía a resolver.
- Limitar el análisis a usuarios humanos e ignorar cuentas de servicio, tokens y máquinas, que es justamente donde el comportamiento es más predecible y la desviación más significativa.
- Desplegar analítica de comportamiento de empleados sin marco legal: en España exige información previa a la plantilla, proporcionalidad y base jurídica RGPD. Hacerlo a escondidas invalida pruebas en un despido y expone a sanciones.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
Ya tenemos un SIEM con reglas de correlación, ¿qué me aporta añadir UEBA?
Cobertura sobre la categoría de ataques que las reglas no pueden ver: los que usan credenciales válidas y permisos legítimos. Una regla necesita un patrón conocido de antemano; la analítica de comportamiento detecta desviaciones respecto a lo normal aunque el ataque sea nuevo. En la práctica no es una compra separada: Microsoft Sentinel, Splunk o Exabeam lo ofrecen como módulo sobre el SIEM que ya opera tu equipo, y su salida (scores de riesgo por entidad) sirve para priorizar la cola de investigación del SOC, no para sustituir las reglas existentes.
¿Cómo detecto a un empleado que está copiando datos antes de irse a la competencia?
Es el caso de uso clásico de UEBA combinado con DLP. El patrón típico —acceso creciente a repositorios fuera de su área, descargas masivas, uso de USB o de correo personal, actividad fuera de horario— rara vez viola una regla concreta, pero se separa claramente de la línea base del usuario y de su grupo de pares. Muchas organizaciones elevan además la sensibilidad del scoring para empleados en preaviso o en procesos disciplinarios. Importante: hazlo con política informada a la plantilla y proporcionalidad, o las evidencias no valdrán en sede judicial.
¿UEBA sirve para cuentas de servicio y otras identidades no humanas?
Sí, y es donde mejor funciona. Una cuenta de servicio hace siempre lo mismo: mismos servidores, mismos horarios, mismos volúmenes. Cuando una identidad así se desvía —un service principal de backup que empieza a leer buzones, un token de CI/CD usado desde una IP nueva— la probabilidad de compromiso es altísima y los falsos positivos, mínimos. Dado que las identidades no humanas ya superan en número a las humanas en la mayoría de entornos cloud y rara vez tienen MFA, la línea base de comportamiento es a menudo el único control de detección real sobre ellas.
Somos una empresa mediana sin SOC propio, ¿tiene sentido UEBA para nosotros?
Tiene sentido la capacidad, no necesariamente operarla vosotros. UEBA sin analistas que investiguen los scores es un cuadro de mando que nadie mira: el valor aparece cuando alguien revisa las entidades de riesgo alto cada día y actúa. Para una empresa mediana lo razonable es consumirlo a través de un SOC gestionado o un MSSP que ya incluya analítica de comportamiento en su plataforma, con umbrales ajustados a tu negocio. Pagas por detección madura desde el primer mes en lugar de construir durante años un equipo 24x7 propio.