Identity Analytics

El SIEM correlaciona logs y eventos de red, servidores y aplicaciones para detectar patrones conocidos de ataque, y el antivirus/EDR vigila el endpoint. El análisis de identidades (UEBA) trabaja con una unidad de análisis distinta: construye un perfil de comportamiento normal para cada usuario (qué aplicaciones usa, desde dónde, a qué hora, con qué privilegios) y detecta desviaciones sobre ese perfil, aunque la actividad venga de una sesión legítima con credenciales válidas que ningún SIEM marcaría como maliciosa. No sustituye al SIEM: le aporta contexto de identidad que el SIEM no tiene, y en muchas arquitecturas sus alertas se envían al propio SIEM para enriquecer la correlación.

Es un riesgo real si la herramienta se limita a reglas rígidas tipo "viaje imposible" sin contexto adicional. Un motor de UEBA bien calibrado pondera varios factores a la vez (dispositivo habitual, franja horaria, aplicación, nivel de privilegio usado) antes de generar una alerta, y prioriza por score de riesgo en lugar de lanzar un aviso por cada anomalía aislada, lo que reduce sensiblemente el ruido frente a reglas de correlación simples. Aun así, ningún sistema de este tipo llega a cero falsos positivos: la calibración inicial y el ajuste de umbrales durante las primeras semanas son los que determinan si el volumen de alertas es manejable para el equipo que las revisa.

Detecta ambos casos porque los dos se manifiestan igual desde el punto de vista de la identidad: una cuenta accediendo a recursos o con una frecuencia distinta a su patrón habitual. Un atacante externo con credenciales robadas y un empleado (o excolaborador con acceso que no se ha revocado) que accede a datos fuera de su función aparecen igual ante el motor de comportamiento: como una desviación del perfil normal de esa identidad. De hecho, el abuso de permisos legítimos por personal interno es uno de los escenarios donde este tipo de análisis aporta más valor, precisamente porque no depende de firmas de malware ni de tráfico externo sospechoso.

El periodo de calibración (baseline) habitual se sitúa entre dos y cuatro semanas de actividad normal para perfiles con un patrón de uso estable, y puede extenderse a varios meses en roles con actividad muy irregular (comerciales con viajes frecuentes, personal por turnos). Durante ese periodo la herramienta ya empieza a generar valor con detecciones basadas en reglas y en la analítica de otros usuarios del mismo perfil, no solo en el histórico individual, por lo que no es un tiempo muerto sin ninguna protección. El plazo exacto depende del volumen de datos históricos disponibles antes del despliegue.

No es imprescindible un SOC propio: el sistema prioriza las alertas por nivel de riesgo, de forma que el equipo de TI habitual solo necesita revisar las de mayor severidad en el día a día, en lugar de examinar todo el tráfico de anomalías. Sí conviene que alguien tenga asignada la responsabilidad de revisar esas alertas con cierta regularidad, aunque sea a tiempo parcial, porque una herramienta de este tipo sin nadie que actúe sobre sus avisos pierde buena parte de su valor. Para organizaciones sin equipo de seguridad interno, este seguimiento puede externalizarse como parte de un servicio gestionado.

Son complementarios, no intercambiables. La certificación de accesos (propia de IGA) es una revisión periódica y formal en la que un responsable confirma que cada permiso sigue siendo necesario; el análisis de comportamiento es continuo y detecta un uso anómalo de un permiso que, en la foto fija de la certificación, sigue pareciendo legítimo. Un permiso puede superar una certificación trimestral y aun así estar siendo usado de forma anómala la semana siguiente: por eso las organizaciones maduras en IAM combinan ambos procesos en lugar de sustituir uno por otro.

La herramienta analiza metadatos de acceso: qué cuenta ha entrado a qué sistema, desde qué dispositivo o ubicación, a qué hora y con qué nivel de privilegio, no el contenido de los correos, documentos o comunicaciones del empleado. Aun así, al tratarse de datos vinculados a una persona identificable, su uso debe ampararse en una base legal (normalmente interés legítimo de seguridad) e informarse a la plantilla conforme al RGPD y a la normativa laboral española sobre control de la actividad del trabajador, típicamente a través de la política de uso de sistemas de información y, cuando aplique, consulta a la representación de los trabajadores. El diseño de la herramienta sobre metadatos de identidad, en vez de contenido, facilita ese encaje legal frente a otras formas de monitorización más invasivas.