Microsoft Sentinel está incorporando las anomalías de UEBA directamente en su capa Behaviors. UEBA es el análisis del comportamiento de usuarios y entidades: compara una actividad con patrones anteriores para señalar lo que se desvía. La novedad une esa señal con el comportamiento investigado y añade contexto para explicar por qué merece atención.
Para un analista, la mejora reduce el salto entre tres preguntas: qué ocurrió, quién o qué participó y por qué esa secuencia destaca. Behaviors ya agrupaba eventos individuales en patrones con sentido; ahora cada comportamiento puede incluir la anomalía asociada y sus enriquecimientos, sin obligar a empezar por telemetría repartida entre varias tablas.
Más cobertura que la identidad
La ampliación no se limita a usuarios. La UEBA clásica añade soporte para fuentes de red y nube: AWS GuardDuty, Check Point, Zscaler y Fortinet a través de CommonSecurityLog. La propia capa Behaviors incorpora además registros de Fortinet mediante esa tabla común.
Esto no significa que cualquier registro se convierta automáticamente en una buena señal. Sentinel necesita datos normalizados y entidades que se puedan resolver de forma consistente. La documentación de UEBA explica cómo se construye el contexto alrededor de usuarios, hosts, direcciones IP y otras entidades.
Una explicación ayuda, pero no sentencia
Una anomalía indica que algo se aparta del patrón esperado; no demuestra por sí sola que exista un incidente. El contexto sirve para priorizar y formular una hipótesis más deprisa, pero el analista sigue necesitando contrastar la secuencia con cambios autorizados, ventanas de mantenimiento, actividad administrativa y otras evidencias.
También cambia el punto de entrada al triaje. En lugar de revisar primero una alerta aislada y reconstruir después su historia, el SOC puede comenzar por el comportamiento, ver la desviación y decidir si la secuencia justifica una investigación más profunda. Ese orden puede ahorrar tiempo cuando la resolución de entidades y la cobertura de datos son buenas.
Qué comprobar en un piloto
Empezaría con una fuente ya estable y un conjunto acotado de entidades. Durante dos semanas compararía los comportamientos enriquecidos con los casos que el equipo ya revisa. Mediría cuántas anomalías aportan una pista nueva, cuántas repiten información conocida y cuántas se explican por actividad legítima.
Después revisaría cuatro aspectos: continuidad de la ingesta, calidad de la normalización, porcentaje de eventos enlazados con una entidad y volumen adicional de investigación. Ampliar a GuardDuty o a dispositivos de red sin controlar esas bases puede producir más cobertura, pero no necesariamente mejor priorización.
Behaviors continúa en public preview, por lo que la interfaz, la cobertura y los límites pueden cambiar antes de la disponibilidad general. Conviene documentar el resultado del piloto y evitar que una función en preview se convierta en la única ruta para detectar o investigar una amenaza.
La aportación más interesante no es una anomalía adicional. Es colocar la desviación dentro de una historia comprensible. Si esa explicación se apoya en datos completos y entidades bien resueltas, el SOC puede dedicar menos tiempo a reconstruir el contexto y más a decidir qué hacer con él.