GDPR
La amenaza interna ya no tiene por qué ser humana: cómo construir un programa basado en comportamiento
21 min lectura
Imagen generada por IALa cuenta que exfiltra datos no siempre pertenece a un empleado descontento. Puede ser un usuario legítimo cuya conducta ha cambiado, una cuenta de servicio con permisos excesivos, un proveedor conectado a la red o un agente de IA que ejecuta una instrucción equivocada con credenciales válidas. El problema no es solo quién tiene acceso. Es qué hace esa identidad, con qué frecuencia, desde dónde y contra qué sistemas.
Ese es el punto de partida del Building a BehaviorDriven Insider Threat Program: A 10-Step Playbook, publicado por Exabeam en Bank Info Security el 11 de agosto de 2026. El documento propone pasar de una vigilancia centrada en eventos aislados a un programa que combine analítica de comportamiento, puntuación de riesgo, gestión de identidades, visibilidad sobre datos y coordinación entre seguridad, recursos humanos, legal y gobierno.
La idea no es revolucionaria. La ejecución sí suele serlo. Muchas organizaciones siguen tratando la amenaza interna como una lista de empleados sospechosos y unas cuantas reglas en el SIEM. Eso deja fuera precisamente a las identidades más difíciles de gobernar: las cuentas técnicas, los flujos automatizados y los agentes que toman decisiones o actúan sobre sistemas sin intervención humana constante.
El playbook llega en un momento incómodo. La automatización está multiplicando las identidades con capacidad operativa, mientras que DORA, NIS2, el RGPD y el AI Act exigen demostrar que los accesos, los incidentes y los sistemas de alto impacto están gobernados. Detectar una anomalía ya no basta. Hay que poder explicar qué se observó, por qué se elevó el riesgo, quién decidió intervenir y cómo se evitó causar un daño adicional a la persona investigada.
La amenaza interna no es sinónimo de empleado malicioso
La definición operativa importa porque determina qué datos se recogen y qué controles se despliegan. Un programa limitado al empleado que roba información por voluntad propia se queda corto desde el primer día. La amenaza interna puede incluir, al menos, cuatro escenarios distintos:
- Malicia deliberada: una persona con acceso legítimo copia información, manipula registros o facilita credenciales para obtener un beneficio.
- Compromiso de una identidad: un atacante externo utiliza una cuenta válida después de robar credenciales, secuestrar una sesión o abusar de un token.
- Error o negligencia: un usuario comparte un fichero sensible con el destinatario equivocado, descarga malware o configura de forma insegura una herramienta.
- Abuso de identidades no humanas: una cuenta de servicio, una API, un robot o un agente de IA emplea permisos legítimos fuera de su patrón normal.
Los cuatro casos pueden producir señales parecidas: una descarga masiva, una conexión desde una ubicación no habitual, un acceso fuera de horario o una consulta a un repositorio que la identidad no había utilizado antes. Pero no requieren la misma respuesta. Suspender automáticamente la cuenta de un trabajador puede ser desproporcionado si el comportamiento se explica por una migración autorizada. Mantener activa una cuenta de servicio comprometida durante horas puede ser mucho más peligroso que bloquear a un usuario humano.
Aquí aparece la primera aportación práctica del enfoque conductual: sustituir el indicador aislado por una secuencia. Una descarga de gran tamaño no demuestra una amenaza. Cinco descargas consecutivas, desde un dispositivo nuevo, hacia un dominio externo, después de un cambio de privilegios y justo antes de una baja laboral, dibujan una historia distinta. La detección mejora cuando el sistema conserva contexto temporal y relaciona eventos de identidad, dispositivo, aplicación y datos.
El dato más importante no es el nombre de la persona, sino la desviación
Los programas tradicionales suelen preguntar: «¿Qué usuarios tienen acceso a este sistema?». Un programa basado en comportamiento añade preguntas más útiles: «¿Qué comportamiento es normal para esta identidad?», «¿qué ha cambiado?» y «¿qué combinación de señales eleva el riesgo?».
Construir esa línea base exige identificar patrones legítimos. Un administrador de bases de datos puede acceder a cientos de servidores; para él, una conexión lateral no es automáticamente anómala. Un analista financiero puede descargar grandes volúmenes al cierre mensual; el mismo volumen el día de su salida puede merecer revisión. Un agente de IA diseñado para clasificar expedientes puede generar miles de llamadas a una API, pero no debería empezar a consultar un repositorio de recursos humanos.
La línea base debe ser suficientemente específica para no confundir actividad intensa con actividad peligrosa. Como mínimo, conviene relacionar:
- la identidad y su tipo: persona, cuenta de servicio, API, robot o agente de IA;
- los privilegios efectivos, no solo el grupo asignado en el directorio;
- el dispositivo, la ubicación, la red y el método de autenticación;
- las aplicaciones utilizadas y los repositorios consultados;
- la sensibilidad de los datos y el volumen de operaciones;
- el momento de la actividad y su relación con cambios organizativos o técnicos;
- las aprobaciones, tickets y excepciones que puedan justificar el comportamiento.
La puntuación de riesgo puede ayudar a priorizar, pero no debe convertirse en una sentencia automática. Un modelo que asigna una cifra a cada usuario no elimina el juicio humano; lo desplaza. La organización debe conocer qué señales alimentan la puntuación, cuánto tiempo se conservan, cómo se corrigen los falsos positivos y quién puede consultar la información. Si nadie puede explicar por qué una identidad recibió una puntuación alta, el número es decoración con apariencia científica.
La expansión de las identidades no humanas cambia el perímetro
El playbook de Exabeam coloca en el mismo mapa a usuarios, cuentas de servicio, agentes de IA y flujos automatizados. Esa integración es probablemente más relevante que cualquier regla concreta de detección. Durante años, la seguridad de identidades se diseñó alrededor de empleados y contratistas. Las organizaciones podían saber quién era el propietario de una cuenta, aunque no siempre controlasen bien sus permisos. Ahora deben gobernar identidades que no tienen nómina, jefe ni conciencia que apelar.
Una cuenta de servicio suele sobrevivir a su creador, acumular permisos y funcionar sin una autenticación interactiva. Un secreto almacenado en un repositorio de código puede terminar dando acceso a producción. Un agente de IA puede encadenar llamadas a varias herramientas, leer información de una aplicación y escribir resultados en otra. En cada salto, la acción puede parecer legítima si se observa por separado. El riesgo aparece en la combinación.
La respuesta no pasa por aplicar exactamente las mismas políticas a humanos y máquinas. Pasa por exigir a cada identidad un propietario, una finalidad, un ámbito de permisos, una caducidad o revisión periódica y registros suficientes para reconstruir sus acciones. En el caso de los agentes de IA, hay que añadir el modelo utilizado, la versión de las instrucciones, las herramientas habilitadas y las decisiones que requieren aprobación humana.
El principio de mínimo privilegio también cambia de forma. Para un usuario, puede significar acceso a una aplicación durante su jornada. Para una cuenta de servicio, puede significar permitir una sola operación sobre una sola tabla. Para un agente, puede significar que puede leer expedientes, pero no exportarlos ni modificar el sistema de origen. El permiso «puede usar esta herramienta» es demasiado tosco cuando la herramienta puede consultar, borrar, enviar y crear.
Lo que DORA exige a una entidad financiera
En una entidad financiera europea, el programa no puede vivir únicamente en el equipo de threat detection. DORA asigna la responsabilidad última del marco de gestión del riesgo ICT al órgano de dirección en su artículo 5 y exige un marco documentado en el artículo 6. La detección de actividad anómala conecta directamente con el artículo 10, sobre detección de anomalías y mecanismos para identificar rápidamente actividad anómala.
El artículo 11 añade la obligación de contar con una política de respuesta y recuperación ante incidentes relacionados con ICT. Eso tiene una consecuencia concreta para la amenaza interna: la organización debe haber decidido de antemano qué ocurre cuando la identidad sospechosa pertenece a un empleado crítico, a un proveedor, a una cuenta privilegiada o a un proceso automatizado que no puede detenerse sin afectar a pagos o liquidaciones.
La dependencia de terceros complica el análisis. DORA dedica el artículo 28 a la gestión del riesgo de terceros proveedores de servicios ICT y exige que las entidades mantengan la responsabilidad sobre sus obligaciones regulatorias aunque externalicen la actividad. Los contratos deben cubrir, entre otros elementos, derechos de acceso, inspección y auditoría, según el artículo 30. Si el proveedor aloja el sistema de monitorización, opera el SOC o administra identidades privilegiadas, la entidad necesita evidencias de que sus registros son completos, accesibles y protegidos frente a alteraciones.
La amenaza interna tampoco encaja solo en el apartado de ciberseguridad. Puede convertirse en un incidente operativo si interrumpe un servicio crítico, altera datos o afecta a la continuidad. Por eso el inventario de identidades debe relacionarse con el registro de funciones y servicios ICT, los procesos críticos y los escenarios de pruebas. Un administrador con acceso a un sistema de pagos no debería recibir el mismo nivel de priorización que una cuenta con acceso de lectura a un entorno de pruebas.
La pregunta que una auditoría o una inspección puede formular no es únicamente si existe una herramienta UEBA. Es si la entidad puede demostrar que:
- conoce qué identidades tienen acceso a activos críticos;
- revisa los privilegios y las cuentas no humanas;
- correlaciona anomalías con cambios de identidad, proveedor y configuración;
- dispone de procedimientos de contención que no dependen de una persona concreta;
- prueba la respuesta mediante escenarios realistas, incluidos los de compromiso de una cuenta privilegiada.
Comprar una plataforma y conectarla al SIEM no satisface ninguna de esas preguntas por sí solo. El software puede detectar una desviación. La gobernanza tiene que decidir si esa desviación es riesgo, incidente o simplemente una explicación pendiente.
NIS2: el comportamiento anómalo también es una cuestión de gestión
Para las entidades incluidas en el ámbito de NIS2, el artículo 21 exige medidas técnicas, operativas y organizativas proporcionadas para gestionar los riesgos que afectan a la seguridad de las redes y sistemas de información. Entre ellas figuran el análisis de riesgos, la gestión de incidentes, la continuidad, la seguridad de la cadena de suministro, la evaluación de la eficacia de las medidas y las prácticas de higiene cibernética.
Un programa de amenaza interna basado en comportamiento puede contribuir a varias de esas obligaciones, pero no las sustituye. La analítica necesita datos de calidad; la gestión de riesgos necesita un inventario; la respuesta necesita responsables; y la cadena de suministro necesita visibilidad sobre accesos de terceros. Si cada proveedor registra de una forma distinta y los logs se conservan durante periodos incompatibles, la supuesta detección temprana será una colección de piezas inconexas.
El artículo 23 de NIS2 fija obligaciones de notificación de incidentes significativos con una alerta temprana en un plazo de 24 horas desde que la entidad tiene conocimiento del incidente, una notificación del incidente en 72 horas y un informe final, salvo que la autoridad competente establezca otra cosa. Un acceso interno malicioso que afecte a la disponibilidad, autenticidad, integridad o confidencialidad de los sistemas puede activar ese circuito. Por eso el proceso de investigación debe registrar cuándo se detectó la anomalía, cuándo se calificó como incidente y qué hechos sustentaron la decisión.
La conexión entre UEBA, respuesta y reporting suele romperse en el momento crítico. El equipo técnico habla de una puntuación de riesgo; el responsable de cumplimiento necesita describir un incidente; legal quiere conocer el alcance; recursos humanos pide garantías sobre el tratamiento de la información. Un programa maduro define un lenguaje común antes de que aparezca el caso difícil.
RGPD y derecho laboral: vigilar no equivale a poder hacerlo todo
La observación de conductas laborales implica tratamiento de datos personales, incluso cuando el objetivo sea proteger sistemas. El artículo 5 del RGPD obliga a respetar licitud, lealtad, transparencia, limitación de la finalidad, minimización, exactitud, limitación del plazo de conservación, integridad y confidencialidad. El artículo 6 exige una base jurídica. En una investigación de seguridad, el interés legítimo o una obligación legal pueden ser relevantes, pero no convierten cualquier monitorización en lícita por defecto.
La organización debe separar la finalidad de seguridad de la vigilancia general de productividad. Registrar que una cuenta accedió a un repositorio protegido puede ser necesario para la seguridad. Analizar continuamente cada pulsación del teclado para inferir la actitud de un trabajador plantea una cuestión distinta y mucho más difícil de justificar. El programa conductual debe medir señales relacionadas con riesgo, no construir un retrato total de la vida laboral de cada persona.
El artículo 13 del RGPD exige informar a los afectados sobre el tratamiento de sus datos. Las políticas deben explicar, con el nivel de detalle adecuado, qué categorías de actividad se registran, con qué fines, quién puede acceder, cuánto tiempo se conservan y qué derechos existen. Una frase genérica sobre «monitorización por motivos de seguridad» puede quedarse corta si el sistema genera perfiles de riesgo o cruza actividad de identidad con información de recursos humanos.
El artículo 22 limita las decisiones basadas únicamente en tratamientos automatizados que produzcan efectos jurídicos o afecten significativamente a una persona. Por tanto, una puntuación de riesgo no debería activar por sí sola un despido, una sanción disciplinaria o una acusación de fraude. El sistema puede priorizar una revisión o exigir una autenticación reforzada. La decisión que impacta en la persona necesita análisis humano, trazabilidad y posibilidad real de impugnación.
El artículo 32 exige medidas de seguridad apropiadas al riesgo. En un programa de amenaza interna eso incluye proteger los propios datos de monitorización: registros de accesos, investigaciones, información laboral y posibles indicadores de salud o conducta. El repositorio de investigaciones no puede convertirse en un segundo objetivo privilegiado. Debe existir segregación de funciones, controles de acceso, registro de consultas y una política de conservación defendible.
Cuando el tratamiento pueda implicar un alto riesgo, el artículo 35 obliga a realizar una evaluación de impacto relativa a la protección de datos. La supervisión sistemática de empleados a gran escala y la elaboración de perfiles son señales claras para evaluar esa obligación. En España, además, la LOPDGDD aborda los derechos digitales en el ámbito laboral en sus artículos 87 a 91, incluidos el derecho a la intimidad en el uso de dispositivos, la desconexión digital y la intimidad frente a dispositivos de videovigilancia y geolocalización.
La conclusión práctica es incómoda pero sencilla: un programa que detecta más puede incumplir más si no limita lo que recoge. La eficacia técnica no corrige una base jurídica débil, una información insuficiente o una retención indefinida.
El AI Act añade una capa: gobernar al agente que gobierna a otros
Los agentes de IA introducen un problema diferente al de un usuario humano comprometido. Su actividad puede ser perfectamente coherente con una instrucción defectuosa, un permiso demasiado amplio o una salida manipulada. No hace falta que el agente «quiera» causar daño. Basta con que pueda ejecutar la instrucción equivocada a escala.
El artículo 4 del AI Act exige medidas de alfabetización en materia de IA para proveedores y responsables del despliegue, aplicables desde el 2 de febrero de 2025. Esa alfabetización no debería reducirse a un curso genérico para empleados. En un entorno con agentes conectados a sistemas internos, debe cubrir límites de autonomía, tratamiento de datos, escalado a una persona, registro de decisiones y reconocimiento de instrucciones maliciosas o ambiguas.
Las aplicaciones de IA utilizadas en empleo y gestión de trabajadores pueden entrar en la categoría de alto riesgo del anexo III, punto 4, cuando se emplean para contratación, selección, evaluación, promoción, terminación de relaciones laborales o asignación de tareas a partir de comportamiento o características personales. Un sistema que puntúa el riesgo de una identidad y alimenta decisiones laborales exige separar con cuidado la finalidad de ciberseguridad de la evaluación del trabajador.
El artículo 14 del AI Act trata de la supervisión humana de sistemas de alto riesgo. Aunque no toda herramienta UEBA sea un sistema de alto riesgo, el principio operativo resulta útil: debe haber personas capaces de interpretar la salida, detectar anomalías en el propio sistema y anular o detener el proceso cuando sea necesario. Si una plataforma bloquea a una identidad basándose en un modelo que nadie comprende, la supervisión es nominal.
El artículo logging y documentación de los sistemas de alto riesgo también ofrece una referencia relevante, junto con las obligaciones de exactitud, robustez y ciberseguridad del artículo 15. Para un agente que ejecuta operaciones, la organización debería conservar, en la medida necesaria, la instrucción recibida, la identidad que la emitió, las herramientas utilizadas, la respuesta generada, la acción ejecutada y la intervención humana posterior. Sin esa cadena, investigar un incidente se convierte en arqueología digital.
Cómo convertir el enfoque conductual en un programa que funcione
El playbook propone diez pasos, pero el material público disponible describe sobre todo el marco: integrar analítica de comportamiento y riesgo con gobierno, identidad, visibilidad de datos y respuesta. La traducción operativa requiere tomar decisiones que suelen quedar ocultas detrás de la palabra «programa».
Primero: definir qué se intenta proteger
No tiene sentido empezar por todos los logs disponibles. Hay que comenzar por los procesos y datos cuya alteración produciría un daño concreto: pagos, expedientes clínicos, modelos financieros, propiedad intelectual, información personal, sistemas de autenticación o repositorios de código. La criticidad determina qué señales merecen una respuesta inmediata y cuáles pueden esperar una revisión.
Segundo: inventariar identidades y permisos efectivos
El directorio corporativo no es un inventario suficiente. Hay que cruzar identidades humanas con cuentas de servicio, secretos, certificados, tokens, aplicaciones OAuth, robots y agentes. El propietario debe ser identificable. También la finalidad, el entorno, el alcance y la fecha de revisión. Una cuenta sin propietario no es una excepción administrativa: es un riesgo sin responsable.
Tercero: diseñar casos de uso antes de elegir la puntuación
Los casos de uso deben expresar una hipótesis comprobable. Por ejemplo: «una cuenta privilegiada que inicia sesión desde un dispositivo no registrado, modifica permisos y exporta datos en menos de una hora requiere contención». La hipótesis indica qué fuentes se necesitan y qué respuesta procede. Sin ella, la organización acumula alertas que nadie puede priorizar.
Cuarto: combinar señales, no perseguir anomalías sueltas
La desviación estadística es un indicio, no una conclusión. Conviene combinar contexto de identidad, criticidad del activo, sensibilidad del dato, historial de permisos, autenticación y cambios recientes. El cambio de departamento, una migración autorizada o una ventana de mantenimiento deben poder explicar parte de la actividad. Esa información reduce falsos positivos y evita que los analistas conviertan cada diferencia respecto a la media en una crisis.
Quinto: definir respuestas graduadas
La respuesta puede ir desde pedir una autenticación adicional hasta revocar un token, aislar un dispositivo, congelar una exportación o activar una investigación formal. No todos los casos justifican el mismo nivel de intervención. Las acciones automáticas deben tener límites, reversibilidad y registro. Un bloqueo irreversible ejecutado por un modelo opaco es una mala práctica incluso aunque acierte de vez en cuando.
Sexto: unir seguridad, recursos humanos y legal sin compartirlo todo
La coordinación no significa que todos accedan a todos los datos. Seguridad puede necesitar indicadores técnicos; recursos humanos, información laboral estrictamente necesaria; legal, trazabilidad de decisiones y base jurídica. El acceso debe regirse por necesidad de conocer y segregación de funciones. El objetivo es investigar el riesgo, no crear un expediente paralelo sobre cada empleado.
Séptimo: probar el programa con identidades no humanas
Una prueba basada únicamente en el robo de credenciales de un empleado no cubre el riesgo actual. Hay que simular el compromiso de una cuenta de servicio, la filtración de un secreto, el uso indebido de una API y una instrucción que empuja a un agente a consultar o exportar datos fuera de su propósito. La prueba debe medir el tiempo de detección, la capacidad de atribución y el tiempo necesario para contener sin interrumpir innecesariamente un proceso crítico.
El registro que falta suele ser más importante que el algoritmo
La calidad de un programa conductual depende de la telemetría. No basta con registrar el inicio de sesión. Hace falta saber qué operación se ejecutó, con qué privilegio, sobre qué objeto y mediante qué aplicación. Para agentes y automatizaciones, además, se necesita conservar la relación entre la identidad humana que autorizó el flujo, la identidad técnica que lo ejecutó y el resultado producido.
Los registros deben protegerse frente a manipulación y contar con sincronización temporal razonable. Deben existir reglas de retención vinculadas a la finalidad y a las obligaciones aplicables. Conservarlo todo para siempre no es una estrategia de seguridad; es una futura brecha de privacidad con una factura de almacenamiento.
También hay que controlar el acceso a la propia telemetría. Un investigador con permisos ilimitados sobre los registros puede consultar patrones laborales que no necesita, modificar evidencias o descubrir información sensible de otros empleados. Las consultas sobre logs de alto riesgo deben quedar registradas y someterse a revisiones independientes cuando sea necesario.
Para una entidad financiera, la evidencia útil no es la captura de una pantalla con una alerta roja. Es la cadena completa: identidad, activo, evento, contexto, regla o modelo que elevó el riesgo, análisis del operador, acción adoptada, aprobación, resultado y cierre. Esa cadena sirve para mejorar el control, responder a una auditoría y reconstruir un incidente bajo presión.
Qué puede salir mal
El primer riesgo es el exceso de confianza en la puntuación. Un marcador de 87 sobre 100 no es una probabilidad universal de ataque. Es el resultado de unas señales, unos pesos y unos datos históricos. Si el entorno cambia, el modelo puede degradarse. Deben medirse falsos positivos, falsos negativos, tiempos de investigación y diferencias por tipo de identidad. Un sistema que siempre alerta a los mismos perfiles puede estar reproduciendo sesgos de los datos de entrenamiento o del diseño de permisos.
El segundo es la automatización sin frenos. Revocar una cuenta privilegiada puede proteger un sistema, pero también detener nóminas, pagos o atención sanitaria. Las acciones de alto impacto necesitan circuitos de aprobación, excepciones documentadas y mecanismos de recuperación. La velocidad importa, pero la velocidad sin contexto es solo una forma eficiente de equivocarse.
El tercero es confundir privacidad con obstáculo. El RGPD no prohíbe registrar actividad relevante para la seguridad. Exige hacerlo con finalidad, proporcionalidad, transparencia y controles. Un programa bien diseñado puede recoger menos datos y producir mejores decisiones si se centra en acciones sobre activos críticos, en lugar de vigilar indiscriminadamente cada movimiento.
El cuarto es olvidar el factor organizativo. Una cuenta se vuelve peligrosa cuando sus permisos, su finalidad y su contexto dejan de coincidir. Eso puede ocurrir por una baja laboral mal comunicada, una reorganización, una adquisición, una urgencia operativa o un proveedor que conserva acceso más allá del contrato. La analítica detectará parte del problema, pero la solución exige que recursos humanos, compras, tecnología y seguridad compartan procesos de alta, cambio y baja.
La conclusión: detectar comportamiento no sustituye a gobernar identidades
El mensaje central del documento de Exabeam es correcto, con una salvedad: la analítica conductual no arregla un programa de identidades desordenado. Puede señalar que una cuenta actúa de forma extraña, pero no puede inventar un propietario, justificar un permiso ni decidir qué proceso es crítico. Si la organización no sabe qué identidades existen, qué pueden hacer y quién responde por ellas, la inteligencia de comportamiento llega tarde y trabaja a ciegas.
La prioridad para 2026 debería ser integrar tres capas. La primera es la identidad: autenticación resistente, mínimo privilegio, revisión de accesos y control específico de cuentas no humanas. La segunda es la conducta: telemetría correlacionada, líneas base, puntuación explicable y detección de secuencias. La tercera es la decisión: respuesta graduada, supervisión humana, protección de datos y evidencias suficientes para explicar cada intervención.
Para una empresa regulada, la prueba definitiva no será demostrar que compró una solución UEBA o que publicó una política contra la amenaza interna. Será demostrar que puede detectar una desviación relevante, distinguir un error de un abuso, contener una identidad humana o automática, respetar los derechos de las personas afectadas y reconstruir lo ocurrido después.
La amenaza interna moderna no siempre tiene intención, nómina ni horario. A veces tiene un token, una API y permisos que nadie revisó desde 2023. Ese detalle —mucho menos cinematográfico que el empleado que copia archivos a un USB— es probablemente el que más trabajo dará a los CISO y responsables de compliance este año.