CAPÍTULO 3. FLUJO DE TRABAJO PARA LA INTEGRACIÓN EN LOS ESTÁNDARES FEDERADOS

En este capítulo se propone un flujo de trabajo, que cualquier RP puede implementar, para integrar las técnicas de análisis de comportamientos en los esquemas de gestión de identidades federados (p. ej. OAuth y OIDC) [110]. Tal y como se ha podido ver en el capítulo del estado del arte (Sección 2.1), en las especificaciones federadas, las credenciales de los usuarios son almacenadas por el IdP. Cuando un usuario trata de acceder a un recurso, servicio o aplicación (es decir, SP o en el entorno federado RP), la RP confía en el IdP para solventar los procesos de IAAA. De este modo, el usuario final se autentica de forma externa a la RP, es decir, en el IdP, obteniendo una acreditación en forma de token. Finalmente, el usuario final utiliza este token para comunicarse con la RP, y poder así interactuar con ella.

La solución propuesta en esta tesis doctoral para mejorar la seguridad de estos esquemas federados se basa en utilizar los modelos de análisis de comportamientos. Cuando una RP utiliza un flujo federado para solventar los procesos de IAAA, está delegando parte de la seguridad en el IdP. Sin embargo, delegar los procesos de IAAA en un agente externo no tiene por qué significar delegar todos los aspectos de la seguridad como, por ejemplo, desde el punto de vista de la prevención o de la detección.

La RP tiene un rol muy significativo a la hora de proteger a sus usuarios de recibir un ciberataque como, por ejemplo, ataques de suplantación de identidad, ya que los usuarios interactúan la mayor parte del tiempo con ella. Cuando se utiliza un esquema de gestión de identidades federado, la mayoría de las partes implicadas asumen que la seguridad pasa a ser responsabilidad del IdP en exclusiva, siendo esta una suposición errónea. Tanto IdP como RP deben estar concienciados en asumir su responsabilidad en cuanto a la seguridad, para poder proteger a los usuarios de las posibles amenazas que existen.

De aquí en adelante, se detalla el flujo de trabajo propuesto, que puede utilizar cualquier RP con el objetivo de mejorar los niveles de seguridad proporcionados al usuario final. Este flujo de trabajo se centra en la prevención y detección de ataques de suplantación de identidades por medio del robo de credenciales o secuestros de sesión. Se basa en utilizar técnicas de análisis de comportamiento, y en los detalles de integración con los principales estándares de gestión de identidades.

3.1. Arquitectura y premisas

A lo largo de este capítulo se asume una arquitectura federada en la que existen tres roles principales: el EU, el IdP y la RP.

Las RPs necesitan conocimiento acerca del comportamiento de sus usuarios. Este conocimiento se suele extraer de diferentes tecnologías, interfaces o APIs que son capaces de recopilar información relativa al software o hardware utilizado por el EU, aspectos de configuración (ya sea del sistema o del cliente web utilizado) y de su comportamiento. Toda esta información se utiliza para generar una huella digital, capaz de identificar única y exclusivamente a cada EU.

Una huella digital puede suponer una invasión para la privacidad de los usuarios de los que se recopila información. Estas huellas se pueden utilizar para fines como el perfilado de usuario o para la personalización de contenido publicitario, lo cual puede suponer un rechazo por parte de los usuarios y, por consiguiente, la negativa a su adopción [111]. Hoy en día, existen multitud de trabajos de investigación y de productos finales de empresas privadas que protegen a los clientes web y a las aplicaciones de los usuarios, bloqueando los códigos encargados de la recopilación de la información o cambiando los valores de los atributos que estos recopilan [112].

Por todo lo expuesto anteriormente, en este trabajo se asumen las siguientes premisas:

▪ Existe suficiente diversidad en el comportamiento de los usuarios como para poder generar una huella digital, única y identificativa para cada usuario.

▪ La RP no colabora con el IdP para generar esta huella, ni para analizarla y detectar posibles anomalías que suponen una brecha de seguridad para la RP. Esto quiere decir que, la RP es capaz de seguir el flujo de trabajo propuesto de forma independiente y utilizando única y exclusivamente sus propios recursos.

▪ La RP informa a los usuarios del flujo de trabajo que va a utilizar con el objetivo de mejorar los niveles de seguridad ofrecidos. Más concretamente, la RP informa a los usuarios que este flujo de trabajo puede prevenir y detectar ataques de robo de credenciales y de secuestro de sesión.

▪ La RP cumple con las garantías de privacidad y protección de datos (Reglamento General de Protección de Datos (RGPD) y Ley Orgánica de Protección de Datos de Carácter Personal (LOPD)). Además, sigue los principios de privacidad desde el diseño minimizando la recogida de información, obteniendo el necesario consentimiento explícito e informado del usuario final, y garantizando los niveles adecuados de transparencia.

3.2. Casos de uso

En general, el flujo de trabajo propuesto a continuación puede ser implementado por cualquier RP para mejorar los niveles de seguridad cuando se utiliza un estándar de gestión de identidades federado para realizar los procesos de IAAA. Más específicamente, este flujo de trabajo permite mejorar los niveles de seguridad añadiendo nuevos mecanismos para el control de accesos utilizando los sistemas basados en riesgos, la autenticación continua y los sistemas de alerta temprana. Se han seleccionado estos tres casos de uso representativos, en los que la implantación del flujo de trabajo es de utilidad:

▪ Caso de uso 1: una RP decide utilizar el nivel de garantía (en inglés, Level of Assurance [LoA]) en la petición de autenticación. De esta manera, utilizando el LoA, una RP puede especificar el grado de confianza que requiere al IdP para poder autenticar a un usuario (uno o dos factores de autenticación, factores biométricos o criptografía). Normalmente, el LoA se define de forma estática, sin embargo, gracias al uso del flujo de trabajo propuesto, este valor se puede fijar de forma dinámica en función de los valores devueltos por los modelos de análisis de comportamientos. Por ejemplo, un comercio electrónico en el que un usuario realiza una compra desde un navegador totalmente distinto al que suele utilizar, y sus dinámicas de comportamiento del uso del teclado y ratón son anómalas. En este caso, la RP puede solicitar al IdP un LoA mayor, de tal manera que el EU debe mostrar más autenticadores para terminar satisfactoriamente el proceso de autenticación. Este comportamiento anómalo es un signo de una posible suplantación de identidad. En caso de que el usuario sea legítimo podrá demostrarlo por medio de más autenticadores, mientras que para un atacante será más difícil o imposible.

▪ Caso de uso 2: una RP decide implantar un mecanismo de autenticación continua durante las sesiones de sus usuarios. En el flujo de trabajo propuesto, estos mecanismos de autenticación continua son implementados mediante modelos de análisis de comportamientos. De esta manera, el EU deberá de presentar los autenticadores necesarios, cuando la RP lo considere a lo largo de una sesión, teniendo en cuenta los comportamientos anómalos detectados por los modelos de análisis de comportamientos. Este proceso le permitirá quedar autenticado recibiendo los tokens pertinentes. Nuevamente, estos comportamientos anómalos pueden estar vinculados a un evento que no sea necesariamente un incidente de ciberseguridad, o por el contrario pueden ser debidos a un secuestro de sesión, el cual quedaría bloqueado gracias a esta propuesta.

▪ Caso de uso 3: una RP decide almacenar el histórico de comportamiento de todos los EU. En este sentido, el análisis de toda esta información se prepara para ser procesado de forma periódica (p. ej. cada noche o cada semana). Los modelos de análisis de comportamientos determinan si se han detectado comportamientos anómalos, de tal manera que se levanten alertas en caso afirmativo. De esta forma, tanto los EU como las RPs pueden tomar las acciones necesarias teniendo en cuenta estas alertas. Este procesamiento no se realiza en tiempo real, como sucede en los casos de uso 1 y 2. La gran ventaja de este caso de uso es que la no tener el requisito de procesar la información en tiempo real, los modelos de análisis de comportamientos tienden a ser más precisos y eficaces. Por otro lado, la desventaja es que la brecha de seguridad ya habrá sucedido y por tanto no se podrá evitar, únicamente se podrá levantar una alerta para tener constancia de su ocurrencia.

Tal y como se ha comentado en el estado del arte, la gestión de identidades no solo es aplicable a usuarios, sino también a entidades (p. ej. sensores en entornos IoT). Cabe destacar, que los casos de uso aquí propuestos también son de utilidad para esta casuística. Por ejemplo, la fase de alta o enrollment en sensores en una ciudad inteligente puede ser muy costosa debido a la gran escala de este tipo de proyectos. El análisis de comportamiento es de gran utilidad para solventar este caso de uso, así como sus fases posteriores de autenticación y autorización [113]. Otro caso de uso en este ámbito es la detección de intrusiones analizando el tráfico de red de las comunicaciones de los sensores [114].

3.3. Flujo de trabajo

El flujo de trabajo propuesto en esta tesis doctoral, proporciona a las RPs las líneas generales para integrar soluciones basadas en el análisis de comportamiento dentro de los esquemas de gestión de identidades federados. Este flujo está pensado para poder ser utilizado en todos los casos de uso detallados en la Sección 3.2. Estos casos de uso pueden ser previos o posteriores a la autenticación, algunos son offline y otros son online. Además, los recursos de computación o los datos recopilados, así como los consentimientos necesarios por parte de los EU son muy diversos.

En la Figura 3.1 se muestra el flujo general que han de seguir todos los agentes que interactúan en un flujo federado de gestión de identidades. Es decir, esta figura extrapola el funcionamiento de cualquier estándar de gestión de identidades federado, y el lugar donde se integran las técnicas de análisis de comportamiento y cada caso de uso. Estos pasos no están enumerados, pues se pueden realizar de forma asíncrona, es decir, los agentes pueden ir avanzando y volviendo a pasos anteriores en función del estado en el que se encuentren.

En la Figura 3.2 se detallan los pasos precisos que ha de seguir cualquier RP para integrar las técnicas de análisis de comportamientos dentro del flujo visto en la Figura 3.1. Consta de cinco pasos fundamentales: la selección de la huella digital, la generación de la huella digital, el modelado de las huellas digitales, la evaluación de los modelos generados y su integración en los flujos de información de los estándares federados. Cabe destacar, que una RP puede avanzar y retroceder en la realización de estos pasos en función de los resultados parciales obtenidos en los mismos con el objetivo de lograr una integración satisfactoria.

El primer paso es definir y seleccionar la huella digital. Para ello tiene que utilizar información de comportamiento y atributos lo suficientemente relevantes y descriptivos para que cada huella sea única. De esta forma, las huellas son distinguibles entre sí y por tanto se pueden detectar anomalías de comportamientos.

El segundo paso se centra en generar esta huella digital considerando la información y atributos previamente seleccionados. Para ello se debe utilizar la información recopilada y limpiar la información no relevante (ruido), realizar un preprocesamineto de los datos y transformarlos en variables descriptivas que puedan ser utilizados por los algoritmos de aprendizaje máquina. Posteriormente, el conocimiento extraído en forma de variables descriptivas ha de almacenarse de forma eficiente en una base de datos robusta y escalable. Además, se han de definir procesos para verificar que las huellas digitales son válidas a lo largo del tiempo, ya que estas dinámicas y pueden ir cambiando y poder así actualizarlas.

El tercer paso es modelar las huellas digitales. Para ello se va a hacer uso de los modelos de análisis de comportamiento (es decir, modelos de aprendizaje máquina) específicos que permiten realizar la detección de anomalías. Estos algoritmos se nutren del conocimiento extraído en el segundo paso, por lo que, si este segundo paso no se realiza de forma óptima, es de esperar que el resultado obtenido para el tercer paso no sea tampoco óptimo. Los modelos de análisis de comportamientos tienen que permitir comparar nuevos comportamientos con las huellas digitales generadas, con el objetivo de poder encontrar anomalías y por consiguiente detectar posibles brechas de seguridad. Para obtener buenos resultados, una RP ha de considerar una métrica de similitud o distancias entre huellas digitales precisa. Posteriormente, ha de ser capaz de fijar un umbral de decisión a partir del cual una muestra analizada se considere legítima o una anomalía. Finalmente, al igual que con la generación de huellas digitales, los modelos de aprendizaje máquina han de estar preparados para reentrenarse con el objetivo de considerar los cambios de comportamiento intrínsecos que surgen en los propios usuarios. Esto último, también se puede realizar considerando un modelo de entrenamiento online, es decir, un modelo que va entrenándose a medida que va realizando nuevas predicciones en el sistema.

El cuarto paso es evaluar los modelos de análisis de comportamientos, elaborados en el paso anterior. Este proceso permite detectar posibles errores de diseño que no se han considerado en un primer momento como, por ejemplo, que las huellas digitales seleccionadas y generadas en los pasos previos, no son lo suficientemente descriptivas como para ser funcionales. Además, permite determinar si los modelos de aprendizaje máquina obtenidos se comportan de la manera esperada, es decir, si permiten detectar anomalías de comportamiento, son robustos y tienen capacidad de generalización. En caso de que no se comporten de la manera esperada, la RP ha de evaluar los motivos y solventarlos volviendo atrás a alguno de los pasos anteriores. Cabe destacar, que las métricas estándares de evaluación de modelos de aprendizaje máquina no son lo suficientemente descriptivas en el ámbito del análisis de comportamiento. Es por esto que se suelen utilizar métricas específicas para este dominio.

Finalmente, la quinta tarea es la integración del flujo de trabajo en los estándares de gestión de identidades federados. Este proceso depende específicamente del estándar donde se quiera integrar el flujo. En este trabajo se establecen la líneas y procedimientos que una RP ha de considerar como, por ejemplo, modificar lo menos posible los flujos de información ya determinados por los estándares y utilizar los propios mecanismos que estos estándares proveen para modificarlos en caso de ser necesario. Además, al realizar esta integración y teniendo en cuenta los aspectos relativos a la privacidad, la RP ha de informar a los usuarios de la recopilación y tratamiento de los datos que se van a realizar.

De aquí en adelante, se va a analizar cada una de estas tareas en detalle.

3.3.1. Selección de huella digital

En esta sección se proponen una serie de atributos que cualquier RP puede utilizar para generar una huella digital con el objetivo de poder completar el flujo de trabajo propuesto. Cabe destacar, que es imposible definir una huella digital general que sirva como solución a todas y cada una de las RPs. Esto se debe a que, existen multitud de RPs de naturaleza totalmente distinta (p. ej. aplicación web, aplicación móvil) y que poseen recursos totalmente diferentes y heterogéneos para contemplar multitud de casos de uso en distintos dominios. Es por esto que cada RP ha de decidir un mínimo de atributos que garantice los niveles de seguridad necesarios en función de sus necesidades.

Debe existir una solución equilibrada entre eficacia y privacidad. Esto se debe a que, cuanto mayor sea el número de atributos seleccionados, más eficaces serán los modelos de análisis de comportamientos a la hora de detectar posibles brechas de seguridad. Sin embargo, a medida que el número de atributos aumenta, el proceso de recolección de la información será más costoso y además será más invasivo para la privacidad del usuario final. Un claro ejemplo de este equilibrio se puede encontrar en la diferencia de aumentar la seguridad de una aplicación financiera y en una red social. En el caso de la aplicación financiera, posiblemente un usuario prefiera sacrificar privacidad a cambio de obtener un nivel de seguridad más alto, no siendo así para proteger su perfil en una red social. Toda RP dispuesta a integrar este flujo de trabajo ha de asegurarse el cumplimiento de la normativa sobre privacidad y protección de datos vigente.

Todos los atributos propuestos se pueden ver categorizados en la Figura 3.3. En primer lugar, estos atributos se dividen en estáticos y dinámicos. Los atributos estáticos están compuestos mayoritariamente por información de contexto. Estos atributos se consideran estáticos, porque suelen cambiar nada o muy poco a lo largo del tiempo. Por otro lado, los atributos dinámicos representan las interacciones del usuario final con la RP. Estos atributos son muy cambiantes a lo largo del tiempo. Muchos de los atributos estáticos están definidos por un conjunto finito de posibles valores, por lo que, pueden existir muchos usuarios con valores similares o idénticos, mientras que los atributos dinámicos pueden tomar valores muy heterogéneos (p. ej. no existe un patrón único de comportamiento en las dinámicas de teclado que agrupe un conjunto amplio de usuarios). El grupo de atributos estáticos que garantiza la suficiente singularidad en las huellas digitales, es decir, sus valores presentan la suficiente diversidad como para que la huella digital sea única, son los siguientes:

▪ Codificación del contenido: normalmente un algoritmo de compresión que el navegador soporta.

▪ Idioma del contenido: preferencias de lenguaje seleccionado por el usuario en el navegador.

▪ Cabeceras HTTP: parámetros contenidos en las cabeceras de las peticiones HTTP.

▪ Lista de plugins: plugins instalados en el navegador. Por ejemplo, Java, Flash, o Silver-light.

▪ Cookies habilitadas: configuración de cookies en el navegador.

▪ Tipo de almacenamiento: mecanismos de almacenamiento soportados por el navegador (local, indexedDB, sesión, Web-SQL, etc.).

▪ Seguimiento: cabecera que se incluye cuando no se desea obtener seguimiento de ciertas páginas o aplicaciones web.

▪ Bloqueador de anuncios: software instalado que bloquea la publicidad agresiva o que afecta a la privacidad del usuario en el navegador.

▪ WebGL: WebGL es una API para renderizar los gráficos en el navegador. Esta API permite obtener diferentes atributos relacionados con el navegador instalado.

▪ Agente de usuario: información relacionada con el navegador y sistema operativo utilizado por el usuario.

▪ Resolución de pantalla, profundidad del color y densidad de píxeles: información relacionada con la tarjeta gráfica utilizada y los drivers instalados.

▪ Canvas: script que se utiliza para renderizar el texto y gráficos de HTML. Proporciona información del software y el hardware del usuario.

▪ Dirección IP: identifica la fuente de comunicación.

▪ TCP/IP: puertos abiertos, DNS utilizado, configuración NAT, etc.

▪ Geolocalización: obtenida por medio de inferencia por la red usada o por APIs específicas.

▪ Zona horaria: zona horaria seleccionada en la configuración del navegador.

La recomendación que se propone en esta tesis doctoral para seleccionar los atributos estátcos es la de seleccionar al menos un atributo de cada una de las categorías siempre y cuando sea posible.

Por otro lado, los atributos dinámicos están fuertemente ligados al dispositivo que se utiliza para acceder a la RP. Por ejemplo, las dinámicas de teclado, ratón o el uso de sensores de entrada como el micrófono o cámara, están muy ligados a dispositivos como un ordenador personal. Sin embargo, sensores más específicos como el giroscopio, acelerómetro o el sensor de una pantalla táctil están ligados a dispositivos como teléfonos móviles inteligente o tabletas. Cabe destacar que, algunos atributos dinámicos pueden ser generales, es decir, pueden ser recopilados independientemente del dispositivo utilizado, como las trazas de interacción con una interfaz gráfica, los nodos visitados y rutas seguidas para realizar una tarea concreta, etc.

A continuación, se definen una serie de perfiles para que las RPs puedan tener unas bases para seleccionar unos atributos u otros. Estos perfiles se basan en estudios del estado del arte que tratan de analizar la entropía o singularidad que proporcionan cada uno de estos atributos a la hora de generar una huella digital, así como la facilidad de recopilación de los mismos, y la posible aceptación que un usuario puede tener a la hora de permitir recopilarlos (debido a la invasión de la privacidad que puede suponer recopilar ciertos atributos). Para los atributos estáticos cabe destacar los trabajos [115], [116], mientras que para los atributos dinámicos el estudio realizado en [117], [118]. Estos perfiles distinguen, en primer lugar, por RPs accesibles desde web o desde un entorno móvil, y en segundo lugar se categorizan en tres niveles de seguridad (básico, medio y alto). Estos niveles de seguridad son incrementales, es decir, los niveles superiores incluyen los atributos seleccionados para los niveles inferiores. A continuación, se detallan los atributos específicos que se incluyen en cada uno de los niveles:

▪ Seguridad básica para una RP web: agente de usuario, lista de plugins, resolución de pantalla, zona horaria y habilitación de cookies.

▪ Seguridad básica para una RP en entorno móvil: Resolución de pantalla, zona horaria, utilización de batería y utilización del sistema.

▪ Seguridad media para una RP web: Canvas, WebGL y entorno.

▪ Seguridad media para una RP en entorno móvil: Canvas, giroscopio, acelerómetro y entorno.

▪ Seguridad alta para una RP web: dinámicas de ratón, dinámicas de teclado, interacciones con el entorno y geolocalización.

▪ Seguridad alta para una RP en entorno móvil: dinámicas de pulsación en pantalla, interacciones con el entorno y geolocalización.

Como se ha mencionado con anterioridad, estos perfiles son una recomendación, es decir, no son obligatorios y por consiguiente cualquier RP tiene la capacidad de partir de cualquiera de estos perfiles e ir añadiendo o eliminando atributos específicos para cumplir con sus requisitos y necesidades. Si una RP decide eliminar o no puede incluir alguno de los atributos específicos, para conseguir el mismo nivel de seguridad se recomienda seleccionar un atributo de un nivel de seguridad inmediatamente superior. Si esta casuística sucediese para el nivel más alto, la recomendación es seleccionar al menos dos atributos del nivel de seguridad inmediatamente inferior.

3.3.2. Generación de la huella digital

La información recopilada durante este paso ha de ser común a todos los usuarios y amplia en cuanto a volumen para cada usuario. Esto se debe a que, las huellas digitales han de poder ser comparadas entre los diferentes usuarios, por lo que, tienen que poseer las mismas características. Además, cuanta más información se recopile para cada usuario, se podrá determinar con mayor facilidad las fronteras de decisión y los patrones que definen a cada usuario de forma única. La tecnología utilizada ha de ser genérica y multiplataforma con el objetivo de que sea adaptativa. Los procesos de recopilación y generación de la información han de ser eficientes, evitando introducir latencias innecesarias y un consumo de recursos excesivos. La recopilación de los datos se puede llevar a cabo por lotes, es decir, recibiendo la información de forma periódica, o en tiempo real y de forma continua en el tiempo, es decir, en streaming.

Una vez se ha recopilado la información, el siguiente paso es el proceso de almacenamiento de la información. Este proceso tiene que hacer uso de un sistema fácilmente escalable, con el objetivo de que pueda aumentar sus capacidades en el caso de que el número de usuarios o de información recopilada sea masivo.

El procesado de los datos también debe estar claramente definido. Para ello, se deben descartar valores atípicos, información con ruido o información obsoleta, la cual puede hacer que los modelos generados se vean lastrados.

Es indispensable determinar como la información recopilada y posteriormente almacenada se va a representar. Por ejemplo, las cadenas de Markov son de utilidad para transformar a estados cada comportamiento, acción o interacción del usuario. En este caso concreto, se analizarán las transiciones entre estados, determinando que, si el usuario se ha desplazado de un estado en el que es altamente probable que se encuentre, a un estado poco probable, el comportamiento realizado es atípico y por consiguiente se considera una anomalía y una posible brecha de seguridad. Otras soluciones tratan cada interacción del usuario como un conjunto de características que lo definen, por ejemplo, velocidades de movimiento o ángulo de desplazamiento en el caso de considerar dinámicas de movimientos de ratón. Estas características se agrupan temporalmente formando un vector que define el comportamiento de un usuario en un intervalo de tiempo.

En este trabajo se recomienda que una RP primero seleccione una solución simple que se adapte correctamente a sus necesidades. Esta solución puede basarse en generar secuencias de vectores, que se pueden agrupar posteriormente utilizando ventanas temporales deslizantes, de tal manera que los vectores consecutivos contengan también información de los vectores adyacentes. De esta forma, los vectores consideran una mayor cantidad de información de seguido. Por ejemplo, dado un vector que contenga cuatro elementos, estos se pueden separar en subvectores de longitud dos tal que, el primer subvector contiene los elementos uno y dos, el siguiente subvector los elementos dos y tres y así sucesivamente.

3.3.3. Modelado

En la parte de modelado, las técnicas de aprendizaje máquina basadas en detección de anomalías se posicionan como una de las mejores soluciones para detectar posibles brechas de seguridad utilizando información de comportamientos. Estas técnicas se denominan, en el ámbito del aprendizaje máquina, detección de atípicos. Además, estas técnicas permiten, entre otras cosas, que las RPs puedan manejar datos no etiquetados (aprendizaje no supervisado) y desequilibrados, los cuales son dos de los grandes problemáticas en este ámbito.

La detección de atípicos se basa fundamentalmente en establecer una medida de distancias o similitud (p. ej. la distancia Euclídea) entre objetos [85]. Para el caso concreto que aplica a esta tesis doctoral, estos objetos son huellas digitales de comportamiento. De esta forma, gracias a la medida de distancia o similitud, se pueden definir núcleos de comportamiento que se consideran normales o esperados para un usuario concreto teniendo en cuenta su huella digital, es decir, teniendo en cuenta su histórico de comportamientos. Posteriormente, las nuevas interacciones que llegan al sistema generan nuevas trazas de comportamientos que se comparan con el comportamiento esperado, es decir, con la huella digital. Definiendo un umbral, se puede determinar si estos nuevos comportamientos son normales, o si por el contrario son atípicos y por lo tanto pueden suponer una brecha de seguridad.

Los algoritmos de aprendizaje máquina que pueden ser útiles para una RP con el objetivo de poder seguir el flujo de trabajo propuesto se pueden clasificar en tres grupos [119]:

▪ Forecasting: se basan en el aprendizaje supervisado. En este grupo, los algoritmos se entrenan utilizando datos etiquetados. Estos algoritmos tratan de realizar predicciones basándose en el análisis de tendencia, de estacionalidad y ciclos de datos temporales. ARIMA [120], SVM, K-NN, NN y las redes bayesianas son algunos ejemplos de algoritmos que encajan en este ámbito.

▪ No supervisado: se basan mayoritariamente en agrupar los datos. De esta forma, se toma como premisa que los datos generados por la misma fuente (es decir, generados por el mismo usuario) pertenecerán a los mismos grupos, mientras que los datos atípicos se encontrarán fuera de estos grupos definidos como normales. OC-SVM, K-means e isolation forest [121] son algunos ejemplos de algoritmos que encajan en este grupo.

▪ Basados en densidades: este grupo es en realidad una subcategoría de los no supervisados. Se basa en determinar la densidad de datos que contienen las distintas regiones del espacio. De esta forma, las regiones de alta densidad se pueden definir como las regiones normales o esperadas. Por otro lado, si una muestra se encuentra en una región de baja densidad, será considerado como atípica y, por consiguiente, se determina que no pertenece al usuario legitimo. Algunos ejemplos de estos algoritmos son Local Outlier Factor [122] oDBSCAN [123].

Una RP específica que desee implementar el flujo de trabajo propuesto, ha de primero analizar los datos recopilados y almacenados para generar la huella digital. Esta huella digital, en función de la naturaleza de la RP específica, poseerá unas cualidades únicas. Por ejemplo, una RP que recopile información de la sesión del usuario, podrá tener datos etiquetados y por lo tanto utilizar modelos de forecasting para realizar las predicciones o para mejorar las predicciones realizadas por modelos no supervisados. Cabe destacar, que la información de las etiquetas también puede estar sesgada, es decir, si durante el proceso de recopilación de datos ya existía una brecha de seguridad, los datos recopilados pueden contener comportamientos atípicos. Esto significa, que estos datos atípicos serán considerados como normales o esperados si no se realiza un proceso de preprocesamiento y limpieza de datos adecuado. La recomendación que se propone en esta tesis doctoral es utilizar las etiquetas siempre y cuando sea posible, pero teniendo en cuenta el propio sesgo que puede existir en dichos datos y, por consiguiente, combinar modelos supervisados con modelos no supervisados o basados en densidades para obtener predicciones más precisas. Por ejemplo, una buena aproximación de combinación de varios tipos de algoritmos se encuentra en [124], donde primero se aplican técnicas de clustering para agrupar los diferentes comportamientos para posteriormente aplicar múltiples algoritmos específicos que modelen cada grupo de forma independiente, obteniendo resultados más precisos para cada uno de ellos.

Todos los tipos de algoritmos, arriba mencionados, se pueden implementar de dos formas diferentes, offline y online. Los algoritmos offline utilizan el histórico de información para generar un modelo estático que posteriormente se utiliza para realizar predicciones durante un periodo de tiempo. Estos modelos han de irse adaptando para poder considerar los cambios de la distribución de los datos de entrada, es decir, los usuarios no mantienen su comportamiento estable a lo largo del tiempo. Para poder considerar estos cambios de comportamiento, estos modelos han de irse reentrenando. Para lograr que el reentrenamiento sea efectivo, se deben establecer unas políticas que contemplen indicadores para determinar cuándo las distribuciones iniciales de los datos han cambiado y por lo tanto el modelo ha quedado obsoleto y está perdiendo eficacia y precisión.

Por otro lado, los algoritmos online van entrenando a medida que van realizando nuevas predicciones. De esta forma, cuando llegan nuevas muestras para evaluar, el propio modelo se va actualizando y cambiando sus fronteras de decisión para considerar estos nuevos comportamientos. Así, a medida que el modelo obtiene nuevas muestras, su eficacia y precisión va aumentando. Sin embargo, también hay que considerar que estos modelos también han de ir descartando la información obsoleta que puede quedar cuando el modelo lleva funcionando durante un largo periodo de tiempo. Este tipo de modelos son de mucha utilidad cuando se combinan con una recopilación de la información en streaming.

Una de las problemáticas más comunes a las que se enfrentan las propuestas de este ámbito, es la de detectar anomalías para los primeros accesos, es decir, cuando apenas se posee información de comportamiento del usuario. Esta problemática se denomina arranque en frío. Para este caso concreto, el resultado suelen ser modelos de aprendizaje máquina muy pobres, que no poseen suficiente información para comparar las muestras a evaluar y, por consiguiente, categorizan multitud de muestras como anomalías, cuando no lo son. Esto se traduce, en modelos con una tasa de falsos positivos muy elevada, haciendo que los sistemas en los que se integran estos modelos no sean muy fiables. Una buena solución para este problema es utilizar un sistema de recomendación, capaz de detectar cuando un usuario está utilizando el sistema por primera vez, y alimentar una máquina de factorización para tratar de asemejar estos comportamientos de los de otros usuarios parecidos, mitigando así el problema [125]. Otras posibles soluciones se basan en utilizar modelos no paramétricos para la fase inicial en la que puede existir arranque en frío y otros modelos más precisos cuando ya se ha superado esta fase [126], o tomar como punto de partida un modelo previamente entrenado para otro usuario. De esta forma, aunque siga existiendo el arranque en frío, este durará un menor tiempo, pues el modelo no parte de cero y solo tendrá que irse adaptando, modificando sus fronteras de decisión, a los nuevos comportamientos que genere el nuevo usuario.

3.3.4. Evaluación

El paso de evaluación permite cuantificar la eficacia de los modelos de aprendizaje máquina desarrollados en el paso anterior. De esta forma, se pueden encontrar errores de diseño, ya sea a la hora de seleccionar o generar la huella digital, como determinar los motivos que hacen que el modelo en sí no esté funcionando correctamente. Esta detección temprana permite que la RP pueda regresar a los pasos anteriores, con el objetivo de mejorar la eficacia del modelo final. Es por esto que este paso es fundamental, pues se posiciona como la capa intermedia entre el desarrollo del flujo de trabajo y su puesta en producción.

En primer lugar, se definen las clases que se quieren evaluar. Para el caso del análisis de comportamiento, típicamente se consideran dos clases, la positiva que representa al usuario genuino, y la clase negativa que representa al usuario impostor. Dadas estas dos clases, un modelo de aprendizaje máquina puede predecir de forma correcta o incorrecta cada una de estas clases, obteniendo así cuatro posibles valores. En primer lugar, el valor Verdaderos Positivos (VP) representa a los usuarios genuinos autenticados correctamente. Verdaderos Negativos (VN) representa a los impostores rechazados por el modelo de forma correcta. Falsos Positivos (FP) son los usuarios impostores que se han logrado autenticar como usuarios genuinos y no han sido detectados por el modelo. Falsos Negativos (FN) son los usuarios genuinos que se han detectado incorrectamente como impostores por el modelo. Estos cuatro valores, se agrupan formando una matriz de confusión tal y como se muestra a continuación (ver Figura 3.4):

Existen multitud de métricas para evaluar diferentes aspectos específicos de los resultados obtenidos para los algoritmos de aprendizaje máquina. Dada esta matriz de confusión, típicamente se suelen calcular tres métricas asociadas: la exactitud, la precisión y la sensibilidad. La exactitud es la tasa de acierto sobre el total de muestras, es decir, el porcentaje de acierto del modelo de manera global. La precisión es el porcentaje de aciertos para la clase positiva. La sensibilidad es el porcentaje de muestras para la clase positiva que se aciertan de forma correcta sobre el total de posibles positivos. Estas métricas vienen definidas como sigue:

▪ Exactitud= (VP+VN)/(VP+FP+FN+VN)

▪ Precisión= VP/(VP+FP)

▪ Sensibilidad= VP/(VP+FN)

Sin embargo, en el ámbito del modelado de comportamiento, estas métricas no suelen ser suficiente, pues los problemas de este tipo poseen unas cualidades peculiares, como los datos desequilibrados. Por ejemplo, en el caso de considerar una clase mayoritaria que posee el 99 % de la información genuina, es decir, de información de clase positiva, un modelo trivial que clasifique cada muestra en esta clase obtendría un 99 % de tasa de acierto o exactitud. Si una RP únicamente tuviese en cuenta esta métrica, seguramente este modelo sería seleccionado, pues tiene un acierto muy alto. Sin embargo, el objetivo del problema es justo detectar la clase minoritaria, es decir, la clase que contiene los comportamientos realizados por usuarios impostores (clase negativa) y que pueden suponer una brecha de seguridad. En este caso, este modelo trivial tendría una tasa de acierto del 0 %, convirtiendo así a este modelo en inútil y por tanto habría que desecharlo.

Una métrica que ha demostrado ser más efectiva que las anteriores para lidiar con datos desequilibrados es el F1-score [127]. Esta métrica se puede definir como la media armónica entre la precisión y la sensibilidad. Nuevamente, esta métrica considera como clase de interés la clase genuina.

Todas las métricas definidas hasta ahora se basan fundamentalmente en evaluar la clase positiva, es decir, la de usuarios genuinos. Para el problema que se desea resolver en esta tesis, debería ser al contrario, es decir, se debe evaluar la clase de usuarios impostores, pues es la clase de interés.

Existen métricas específicas que detallan con más precisión las casuísticas específicas en el ámbito del análisis de comportamiento. Estas métricas son: tasa de aceptación falsa (en inglés, False Acceptance Rate [FAR]), tasa de rechazo falso (en inglés, False Rejection Rate [FRR]) y la tasa de error igual (en inglés, Equal Error Rate [EER]) [128]. El FAR se define como la proporción de usuarios impostores que no son detectados correctamente por el modelo. El FRR es la proporción de usuarios legítimos que el modelo predice como usuarios impostores. Un mismo modelo puede ser más restrictivo o más permisivo en función del umbral definido. Esto es, un mismo modelo puede determinar la probabilidad de una muestra de pertenecer a la clase genuina o a la clase impostora, pero es gracias al umbral cuando finalmente se clasifica cada muestra. De esta forma, un mismo modelo con un umbral alto puede ser más restrictivo y por lo tanto tener más acierto para la clase impostora pero menos para la clase genuina (sistema más seguro), o puede ser más permisivo fijando un umbral bajo y por consiguiente tener más acierto en la clase genuina pero menos en la impostora (nunca se podría fijar un umbral que haga tener más acierto en ambas clases simultáneamente). De este modo, dependiendo del umbral se obtienen una pareja de valores FAR y FRR. El EER se puede definir, por tanto, como el punto óptimo entre estos dos valores, es decir, el umbral donde se obtiene un mejor valor para ambas métricas de forma simultánea (ver Figura 3.5).

Las métricas utilizadas en este documento para evaluar los modelos y que se recomienda que utilice cualquier RP que desee integrar el flujo de trabajo propuesto, se definen a continuación.

▪ Especificidad= VN/(VN+FP)

▪ FAR= FP/(FP + VN)

▪ FRR= FN/(FN + VP)

▪ EER= Valor de la intersección entre FAR y FRR cuando se consideran múltiples umbrales.

▪ Valor Predictivo Negativo (VPN)= VN/(VN+FN)

▪ $F 1^{-} = 2 \cdot \frac{VPN \cdot Especificidad}{VPN + Especificidad}$

Donde la especificidad es la proporción de impostores correctamente identificados, esto es, la sensibilidad para el grupo de impostores (clase negativa). VPN es la eficacia del método a la hora de detectar impostores, esto es, la precisión para el grupo de los impostores. F^1_ es la media harmónica entre el VPN y la especificidad [129], es decir, el F1-Score para el grupo de los impostores.

3.3.5. Integración en los sistemas de gestión de identidades federados

La integración del flujo de trabajo en los esquemas de gestión de identidades federados acarrea multitud de retos.

En primer lugar, los usuarios finales seguramente no estén dispuestos a tener que instalar software externo, especialmente si este va a afectar a su privacidad. Este flujo de trabajo es claramente un ejemplo en el que los usuarios pueden sacrificar cierta privacidad (dependiendo de la huella digital seleccionada) con el objetivo de ganar seguridad. Por ejemplo, un usuario puede ser reacio a que una red social recopile información de su comportamiento, sin embargo, si su aplicación de banca electrónica se lo solicita puede optar por aceptar las condiciones.

El flujo de trabajo aquí expuesto no requiere que el usuario final tenga que instalar software externo, simplemente necesita que el usuario acepte las condiciones y por consiguiente consienta que la RP recopile información para generar su huella digital de comportamiento. Es por esto que un mismo usuario puede optar por permitir que ciertas RPs recopilen más información que otras, o incluso ninguna, con el objetivo de que el propio usuario final se vea beneficiado o no, de la implantación del flujo de trabajo propuesto. En cuanto a la privacidad, la RP ha de informar de forma transparente de todos y cada uno de los datos que va a recopilar, así como de cuál va a ser el uso que le va a dar. Cabe destacar, que esta información solo ha de ser accessible por la propia RP, es decir, no se tiene que compartir con terceros, y ha de ser debidamente protegida, desde que se genera en el dispositivo del usuario, mientras se envía por algún canal de comunicación debidamente encriptado utilizando Transport Layer Security (TLS), hasta que se almacena en algún sistema de información.

Por otro lado, la aceptación de los usuarios también se va a ver afectada dependiendo de la eficiencia y la usabilidad. La solución finalmente implementada ha de estar basada en una huella digital lo suficientemente única y robusta como para poder detectar las brechas de seguridad, sin afectar altamente al consumo de recursos, evitando introducir latencias innecesarias y disminuyendo el número de falsos positivos que pueden hacer que el sistema se vuelva poco usable.

Los IdPs no se deben ver afectados por la implantación de este flujo de trabajo. Todos los aspectos relacionados con la integración (consumo de recursos, notificación a los EU, etc) han de recaer sobre la propia RP, la cual es la interesada en proporcionar a sus usuarios finales la capacidad de aumentar sus niveles de seguridad. Es por esto que la implantación de este flujo de trabajo solo dependerá de la comunicación entre la RP y el EU, no necesitando de la colaboración de terceros o del IdP.

Otro reto asociado a la integración del flujo de trabajo es la aceptación de las propias RPs. Esto se debe a que, si el flujo de trabajo requiere modificar los propios estándares de gestión de identidades existentes, probablemente se van a volver reacias a implementarlos. Esto se debe a la dificultad añadida de implantación que esto supondría. Es por esto que los flujos de información de los estándares federados no han de ser modificados, o en su defecto lo menos posible y, por lo tanto, las RPs deben de utilizar los propios mecanismos facilitados por dichos estándares para realizar su cometido. De este modo, se deben utilizar las propias peticiones y respuestas, los parámetros, tokens y cualquier otro aspecto ya existente en los flujos de información para realizar la implantación del flujo de trabajo.

3.3.6. Resumen del flujo de trabajo

A modo resumen, en la Tabla 3.1 se muestra de forma gráfica, todas las decisiones y consideraciones que ha de tomar una RP para implantar el flujo de trabajo propuesto. Estas decisiones se corresponden con cada uno de los pasos fundamentales en los que se basa dicho flujo de trabajo.

Tarea	Decisión	Alternativas	Criterio de decisión
1. Selección de huella digital	Huella digital que proporciona la suficiente singularidad y no es invasiva para el usuario	Atributos estáticos y dinámicos (Figure 3.3)	Caso de uso. Niveles de seguridad deseados.
2. Generación de la huella digital	Recopilar, almacenar, preprocesar y representar los datos: tecnologías y procedimientos	Por lotes o streaming; SQL o No-SQL; lenguajes de programación; Técnicas de representación de la información	Eficiencia y eficacia, Consumo de recursos, escalabilidad
3. Modelado	Detectar anomalías en las huellas digitales: técnicas	Forecasting, aprendizaje no supervisado, algoritmos basados en densidades; modelos offline o online	Huella digital seleccionada, caso de uso, recursos computacionales disponibles en la RP
4. Evaluación	Decidir si se necesitan más iteraciones en el flujo de trabajo: métricas de evaluación	Exactitud, especificidad, FAR FRR, EER, VPN y F1^-	Caso de uso
5. Integración	La RP debe integrar los modelos de análisis de comportamiento para realizar los procesos de IAAA: modificaciones	Cambios en el estándar (peticiones, tokens, flujos); Cambios en la implementación (comprobaciones adicionales, estructura de datos)	Caso de uso, coste permitido

Tabla 3.1: Resumen del flujo de trabajo propuesto

Bibliografía

[1]J. Pato y O. C. Center, “Identity management: Setting context,” Hewlett-Packard, Cambridge, MA, 2003.

[2]B. F. Skinner, Science and human behavior, 92904. Simon y Schuster, 1953.

[3]M. Sidman, Tactics of scientific research. Basic Books, Incorporated, Pub., 1960.

[4]A. G. Martín, A. Fernández-Isabel, I. M. de Diego y M. Beltrán, “A survey for user behavior analysis based on machine learning techniques: current models and applications,” Applied Intelligence, pp. 1–27, 2021.

[5]E. Gurarie, C. Bracis, M. Delgado, T. D. Meckley, I. Kojola y C. M. Wagner, “What is the animal doing? Tools for exploring behavioural structure in animal movements,” Journal of Animal Ecology, vol. 85, n.^o 1, pp. 69–84, 2016.

[6]J. Pacheco y S. Hariri, “Anomaly behavior analysis for IoT sensors,” Transactions on Emerging Telecommunications Technologies, vol. 29, n.^o 4, pp. 1–15, 2018.

[7]M. Pantic, A. Pentland, A. Nijholt y T. S. Huang, “Human computing and machine understanding of human behavior: a survey,” en Artifical Intelligence for Human Computing, Springer, 2007, pp. 47–71.

[8]J. Navarro, I. M. de Diego, P. C. Pérez y F. Ortega, “Outlier detection in animal multivariate trajectories,” Computers and Electronics in Agriculture, vol. 190, pp. 1–6, 2021.

[9]M. Xie, S. Han, B. Tian y S. Parvin, “Anomaly detection in wireless sensor networks: A survey,” Journal of Network and Computer Applications, vol. 34, n.^o 4, pp. 1302–1325, 2011.

[10]M. Bohge y W. Trappe, “An authentication framework for hierarchical ad hoc sensor networks,” en Proceedings of the 2nd ACM workshop on Wireless security, ACM, 2003, pp. 79–87.

[11]R. A. LeVine, Culture, behavior, and personality: An introduction to the comparative study of psychosocial adaptation. Routledge, 2018.

[12]I. Carter, Human behavior in the social environment: A social systems approach. Routledge, 2017.

[13]W. Li y C. J. Mitchell, “Analysing the Security of Google’s implementation of OpenID Connect,” en International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, Springer, 2016, pp. 357–376.

[14]M. Miculan y C. Urban, “Formal analysis of Facebook Connect single sign-on authentication protocol,” en SOFSEM, Citeseer, vol. 11, 2011, pp. 22–28.

[15]Financial-grade API (FAPI), https://openid.net/wg/fapi/, Visitado: 2022-0504.

[16]D. Fett, R. Küsters y G. Schmitz, “The web sso standard openid connect: In-depth formal security analysis and security guidelines,” en 2017 IEEE 30th Computer Security Foundations Symposium (CSF), IEEE, 2017, pp. 189–202.

[17]J. Navas y M. Beltrán, “Understanding and mitigating OpenID Connect threats,” Computers & Security, vol. 84, pp. 1–16, 2019.

[18]A. G. Martín y M. Beltrán, “Mejora de la seguridad de esquemas de gestión de identidades federados mediante técnicas de User Behaviour Analytics,” en V Jornadas Nacionales de Investigación en Ciberseguridad (JNIC 2019), UEX, 2019, pp. 159–166.

[19]D. Recordon y D. Reed, “OpenID 2.0: a platform for user-centric identity management,” en Proceedings of the second ACM workshop on Digital identity management, 2006, pp. 11–16.

[20]D. Hardt et al., The OAuth 2.0 authorization framework, 2012.

[21]N. Sakimura, J. Bradley, M. Jones, B. De Medeiros y C. Mortimore, “Openid connect core 1.0,” The OpenID Foundation, pp. 1–85, 2014.

[22]E. Bertino y K. Takahashi, Identity management: Concepts, technologies, and systems. Artech House, 2010.

[23]D. Gollmann, “Computer security,” Wiley Interdisciplinary Reviews: Computational Statistics, vol. 2, n.^o 5, pp. 544–554, 2010.

[24]S. Samonas y D. Coss, “The CIA strikes back: Redefining confidentiality, integrity and availability in security.,” Journal of Information System Security, vol. 10, n.^o 3, 2014.

[25]A. Ometov, S. Bezzateev, N. Makitalo, S. Andreev, T. Mikkonen e Y. Koucheryavy, “Multi-factor authentication: A survey,” Cryptography, vol. 2, n.° 1, pp. 1–31, 2018.

[26]S. Ayeswarya y J. Norman, “A survey on different continuous authentication systems,” International Journal of Biometrics, vol. 11, n.^o 1, pp. 67–99, 2019.

[27]G. Saunders, M. Hitchens y V. Varadharajan, “An analysis of access control models,” en Australasian Conference on Information Security and Privacy, Springer, 1999, pp. 281–293.

[28]S. Smalley, C. Vance y W. Salamon, “Implementing SELinux as a Linux security module,” NAI Labs Report, vol. 1, n.^o 43, pp. 1–58, 2001.

[29]M. Laurent y S. Bouzefrane, Digital identity management. Elsevier, 2015.

[30]K. Zeilenga et al., “Lightweight directory access protocol (ldap): Technical specification road map,” RFC 4510, June, inf. téc., 2006.

[31]S. P. Miller, B. C. Neuman, J. I. Schiller y J. H. Saltzer, “Kerberos authentication and authorization system,” en In Project Athena Technical Plan, Citeseer, 1988.

[32]C. Rigney, S. Willens, A. Rubens y W. Simpson, Remote authentication dial in user service (RADIUS), 2000.

[33]E. Maler y D. Reed, “The venn of identity: Options and issues in federated identity management,” IEEE security & privacy, vol. 6, n.^o 2, pp. 16–23, 2008.

[34]A. Anderson y H. Lockhart, “SAML 2.0 profile of XACML,” OASIS, September, vol. 51, n.^o 1.4, 2004.

[35]E. Hammer-Lahav, D. Recordon y D. Hardt, “The oauth 1.0 protocol,” RFC 5849, April, inf. téc., 2010.

[36]C. Mainka, V. Mladenov, J. Schwenk y T. Wich, “SoK: single sign-on security—an evaluation of openID connect,” en 2017 IEEE European Symposium on Security and Privacy (EuroS&P), IEEE, 2017, pp. 251–266.

[37]F. Yang y S. Manoharan, “A security analysis of the OAuth protocol,” en 2013 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PA-CRIM), IEEE, 2013, pp. 271–276.

[38]E. Y. Chen, Y. Pei, S. Chen, Y. Tian, R. Kotcher y P. Tague, “Oauth demystified for mobile application developers,” en Proceedings of the 2014 ACM SIGSAC conference on computer and communications security, 2014, pp. 892–903.

[39]P. Hu, R. Yang, Y. Li y W. C. Lau, “Application impersonation: problems of OAuth and API design in online social networks,” en Proceedings of the second ACM conference on Online social networks, 2014, pp. 271–278.

[40]R. Yang, G. Li, W. C. Lau, K. Zhang y P. Hu, “Model-based security testing: An empirical study on oauth 2.0 implementations,” en Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security, 2016, pp. 651–662.

[41]J. Singh y N. K. Chaudhary, “OAuth 2.0: Architectural design augmentation for mitigation of common security vulnerabilities,” Journal of Information Security and Applications, vol. 65, pp. 1–11, 2022.

[42]S. G. Morkonda, S. Chiasson y P. C. van Oorschot, “Empirical Analysis and Privacy Implications in OAuth-based Single Sign-On Systems,” en Proceedings of the 20th Workshop on Workshop on Privacy in the Electronic Society, 2021, pp. 195–208.

[43]H. Halpin, “NEXTLEAP: Decentralizing identity with privacy for secure messaging,” en Proceedings of the 12th International Conference on Availability, Reliability and Security, 2017, pp. 1–10.

[44]R. Weingärtner y C. M. Westphall, “A design towards personally identifiable information control and awareness in OpenID Connect identity providers,” en 2017 IEEE International Conference on Computer and Information Technology (CIT), IEEE, 2017, pp. 37–46.

[45]J. Werner y C. M. Westphall, “A model for identity management with privacy in the cloud,” en 2016 IEEE Symposium on Computers and Communication (ISCC), IEEE, 2016, pp. 463–468.

[46]C. Villarán y M. Beltrán, “Protecting End User’s Privacy When using Social Login through GDPR Compliance,” 2021.

[47]G. Zachmann, “Mytoken-OpenID Connect Tokens for Long-term Authorization,” Tesis doct., Karlsruher Institut für Technologie (KIT), 2021.

[48]A. Sharif, R. Carbone, G. Sciarretta y S. Ranise, “Best current practices for OAuth/OIDC Native Apps: A study of their adoption in popular providers and top-ranked Android clients,” Journal of Information Security and Applications, vol. 65, pp. 1–18, 2022.

[49]Z. Cao, C. Chi, R. Hao e Y. Xiao, “User behavior modeling and traffic analysis of IMS presence servers,” en IEEE GLOBECOM 2008-2008 IEEE Global Telecommunications Conference, IEEE, 2008, pp. 1–5.

[50]X. Kong, M. Li, T. Tang, K. Tian, L. Moreira-Matias y F. Xia, “Shared subway shuttle bus route planning based on transport data analytics,” IEEE Transactions on Automation Science and Engineering, vol. 15, n.^o 4, pp. 1507–1520, 2018.

[51]N. Ding, Q. He, C. Wu y J. Fetzer, “Modeling traffic control agency decision behavior for multimodal manual signal control under event occurrences,” IEEE Transactions on Intelligent Transportation Systems, vol. 16, n.^o 5, pp. 2467–2478, 2015.

[52]R. Faria, J. Sousa, A. Martins y J. Lagarto, “Modeling the strategic behavior of the iberian electricity market producers using time series analysis,” en 2013 10th International Conference on the European Energy Market (EEM), IEEE, 2013, pp. 1–5.

[53]Y. Wang, Q. Chen, C. Kang y Q. Xia, “Clustering of electricity consumption behavior dynamics toward big data applications,” IEEE transactions on smart grid, vol. 7, n.^o 5, pp. 2437–2447, 2016.

[54]H. Alemdar, C. Tunca y C. Ersoy, “Daily life behaviour monitoring for health assessment using machine learning: bridging the gap between domains,” Personal and Ubiquitous Computing, vol. 19, n.^o 2, pp. 303–315, 2015.

[55]M. Manca, P. Parvin, F. Paterno y C. Santoro, “Detecting anomalous elderly behaviour in ambient assisted living,” en Proceedings of the ACM SIGCHI Symposium on Engineering Interactive Computing Systems, 2017, pp. 63–68.

[56]A. Lotfi, C. Langensiepen, S. M. Mahmoud y M. J. Akhlaghinia, “Smart homes for the elderly dementia sufferers: identification and prediction of abnormal behaviour,” Journal of ambient intelligence and humanized computing, vol. 3, n.^o 3, pp. 205–218, 2012.

[57]N. Arbabzadeh y M. Jafari, “A data-driven approach for driving safety risk prediction using driver behavior and roadway information data,” IEEE transactions on intelligent transportation systems, vol. 19, n.^o 2, pp. 446–460, 2017.

[58]W. Zhang y Q. Fan, “Identification of abnormal driving state based on driver’s model,” en ICCAS 2010, IEEE, 2010, pp. 14–18.

[59]A. K. Sahu y P. Dwivedi, “User profile as a bridge in cross-domain recommender systems for sparsity reduction,” Applied Intelligence, vol. 49, n.^o 7, pp. 2461–2481, 2019.

[60]T. Bai, W. X. Zhao, Y. He, J.-Y. Nie y J.-R. Wen, “Characterizing and predicting early reviewers for effective product marketing on e-commerce websites,” IEEE Transactions on Knowledge and Data Engineering, vol. 30, n.^o 12, pp. 2271–2284, 2018.

[61]M. Frank, R. Biedert, E. Ma, I. Martinovic y D. Song, “Touchalytics: On the applicability of touchscreen input as a behavioral biometric for continuous authentication,” IEEE transactions on information forensics and security, vol. 8, n.^o 1, pp. 136–148, 2013.

[62]C. Shen, Y. Li, Y. Chen, X. Guan y R. A. Maxion, “Performance analysis of multimotion sensor behavior for active smartphone authentication,” IEEE Transactions on Information Forensics and Security, vol. 13, n.^o 1, pp. 48–62, 2017.

[63]I. Firdausi, A. Erwin, A. S. Nugroho et al., “Analysis of machine learning techniques used in behavior-based malware detection,” en 2010 second international conference on advances in computing, control, and telecommunication technologies, IEEE, 2010, pp. 201–203.

[64]F. Pérez-Bueno, L. García, G. Maciá-Fernández y R. Molina, “Leveraging a Probabilistic PCA Model to Understand the Multivariate Statistical Network Monitoring Framework for Network Security Anomaly Detection,” IEEE/ACM Transactions on Networking, 2022.

[65]P. Ravisankar, V. Ravi, G. R. Rao e I. Bose, “Detection of financial statement fraud and feature selection using data mining techniques,” Decision support systems, vol. 50, n.^o 2, pp. 491–500, 2011.

[66]U. Mahbub y R. Chellappa, “PATH: person authentication using trace histories,” en Ubiquitous Computing, Electronics & Mobile Communication Conference (UEMCON), IEEE Annual, IEEE, 2016, pp. 1–8.

[67]C. Giuffrida, K. Majdanik, M. Conti y H. Bos, “I sensed it was you: authenticating mobile users with sensor-enhanced keystroke dynamics,” en International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, Springer, 2014, pp. 92–111.

[68]Y. Li, H. Hu y G. Zhou, “Using data augmentation in continuous authentication on smartphones,” IEEE Internet of Things Journal, vol. 6, n.^o 1, pp. 628–640, 2018.

[69]H. T. Nguyen, C. L. Walker y E. A. Walker, A first course in fuzzy logic. CRC press, 2018.

[70]I. Brosso, A. La Neve, G. Bressan y W. V. Ruggiero, “A continuous authentication system based on user behavior analysis,” en Availability, Reliability, and Security, 2010. ARES’10 International Conference on, IEEE, 2010, pp. 380–385.

[71]Y. Cai, H. Jiang, D. Chen y M.-C. Huang, “Online learning classifier based behavioral biometrie authentication,” en 2018 IEEE 15th International Conference on Wearable and Implantable Body Sensor Networks (BSN), IEEE, 2018, pp. 62–65.

[72]L. Hernández-Álvarez, J. M. De Fuentes, L. González-Manzano y L. H. Encinas, “SmartCAMPP-Smartphone-based continuous authentication leveraging motion sensors with privacy preservation,” Pattern Recognition Letters, vol. 147, pp. 189–196, 2021.

[73]J. M. de Fuentes, L. Gonzalez-Manzano y A. Ribagorda, “Secure and Usable User-in-a-Context Continuous Authentication in Smartphones Leveraging Non-Assisted Sensors,” Sensors, vol. 18, n.^o 4, p. 1219, 2018.

[74]C. Liu y J. He, “Access control to web pages based on user browsing behavior,” en Communication Software and Networks (ICCSN), 2017 IEEE 9th International Conference on, IEEE, 2017, pp. 1016–1020.

[75]H. Gomi, S. Yamaguchi, K. Tsubouchi y N. Sasaya, “Continuous Authentication System Using Online Activities,” en 2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE), IEEE, 2018, pp. 522–532.

[76]P. Zhao, C. Yan y C. Jiang, “Authenticating Web User’s Identity through Browsing Sequences Modeling,” en Data Mining Workshops (ICDMW), 2016 IEEE 16th International Conference on, IEEE, 2016, pp. 335–342.

[77]I. Molloy, L. Dickens, C. Morisset, P.-C. Cheng, J. Lobo y A. Russo, “Risk-based security decisions under uncertainty,” en Proceedings of the second ACM conference on Data and Application Security and Privacy, ACM, 2012, pp. 157–168.

[78]Z. Lu e Y. Sagduyu, “Risk assessment based access control with text and behavior analysis for document management,” en Military Communications Conference, MILCOM 2016-2016 IEEE, IEEE, 2016, pp. 37–42.

[79]B. Rožac, R. Sernec, A. Košir y A. Kos, “User behavior analysis based on Identity management systems’ log data,” Machine learning, vol. 143, pp. 1–5, 2012.

[80]M. Misbahuddin, B. Bindhumadhava y B. Dheeptha, “Design of a risk based authentication system using machine learning techniques,” en 2017 IEEE SmartWorld, Ubiquitous Intelligence & Computing, Advanced & Trusted Computed, Scalable Computing & Communications, Cloud & Big Data Computing, Internet of People and Smart City Innovation, IEEE, 2017, pp. 1–6.

[81]R. S. Gaines, W. Lisowski, S. J. Press y N. Shapiro, “Authentication by keystroke timing: Some preliminary results,” Rand Corp Santa Monica CA, inf. téc., 1980.

[82]S. Bleha, C. Slivinsky y B. Hussien, “Computer-access security systems using keystroke dynamics,” IEEE Transactions on pattern analysis and machine intelligence, vol. 12, n.^o 12, pp. 1217–1222, 1990.

[83]S. Cho, C. Han, D. H. Han y H.-I. Kim, “Web-based keystroke dynamics identity verification using neural network,” Journal of organizational computing and electronic commerce, vol. 10, n.^o 4, pp. 295–307, 2000.

[84]F. Monrose y A. Rubin, “Authentication via keystroke dynamics,” en Proceedings of the 4th ACM Conference on Computer and Communications Security, 1997, pp. 48–56.

[85]K. S. Killourhy y R. A. Maxion, “Comparing anomaly-detection algorithms for keystroke dynamics,” en 2009 IEEEIIFIP International Conference on Dependable Systems & Networks, IEEE, 2009, pp. 125–134.

[86]A. Alsultan, K. Warwick y H. Wei, “Non-conventional keystroke dynamics for user authentication,” Pattern Recognition Letters, vol. 89, pp. 53–59, 2017.

[87]J. Kim, H. Kim y P. Kang, “Keystroke dynamics-based user authentication using freely typed text based on user-adaptive feature extraction and novelty detection,” Applied Soft Computing, vol. 62, pp. 1077–1087, 2018.

[88]K. S. Balagani, V. V. Phoha, A. Ray y S. Phoha, “On the discriminability of keystroke feature vectors used in fixed text keystroke authentication,” Pattern Recognition Letters, vol. 32, n.^o 7, pp. 1070–1080, 2011.

[89]O. Alpar, “Frequency spectrograms for biometric keystroke authentication using neural network based classifier,” Knowledge-Based Systems, vol. 116, pp. 163–171, 2017.

[90]L. Xiaofeng, Z. Shengfei e Y. Shengwei, “Continuous authentication by free-text keystroke based on CNN plus RNN,” Procedia computer science, vol. 147, pp. 314–318, 2019.

[91]Y. Sun, H. Ceker y S. Upadhyaya, “Shared keystroke dataset for continuous authentication,” en 2016 IEEE International Workshop on Information Forensics and Security (WIFS), IEEE, 2016, pp. 1–6.

[92]J. Huang, D. Hou, S. Schuckers, T. Law y A. Sherwin, “Benchmarking keystroke authentication algorithms,” en 2017 IEEE Workshop on Information Forensics and Security (WIFS), IEEE, 2017, pp. 1–6.

[93]B. Ayotte, M. Banavar, D. Hou y S. Schuckers, “Fast Free-text Authentication via Instance-based Keystroke Dynamics,” IEEE Transactions on Biometrics, Behavior, and Identity Science, vol. 2, n.^o 4, pp. 377–387, 2020.

[94]R. A. Everitt y P. W. McOwan, “Java-based internet biometric authentication system,” IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 25, n.^o 9, pp. 1166–1172, 2003.

[95]A. A. E. Ahmed e I. Traore, “A new biometric technology based on mouse dynamics,” IEEE Transactions on dependable and secure computing, vol. 4, n.^o 3, pp. 165–179, 2007.

[96]P. Chong, Y. Elovici y A. Binder, “User authentication based on mouse dynamics using deep neural networks: A comprehensive study,” IEEE Transactions on Information Forensics and Security, vol. 15, pp. 1086–1101, 2019.

[97]C. Shen, Z. Cai, X. Guan, Y. Du y R. A. Maxion, “User authentication through mouse dynamics,” IEEE Transactions on Information Forensics and Security, vol. 8, n.^o 1, pp. 16–30, 2012.

[98]D. Qin, S. Fu, G. Amariucai, D. Qiao e Y. Guan, “MAUSPAD: Mouse-based Authentication Using Segmentation-based, Progress-Adjusted DTW,” en 2020 IEEE 19th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), IEEE, 2020, pp. 425–433.

[99]T. Hu, W. Niu, X. Zhang, X. Liu, J. Lu e Y. Liu, “An insider threat detection approach based on mouse dynamics and deep learning,” Security and Communication Networks, vol. 2019, 2019.

[100]A. Ross y A. Jain, “Information fusion in biometrics,” Pattern recognition letters, vol. 24, n.^o 13, pp. 2115–2125, 2003.

[101]S. Mondal y P. Bours, “A study on continuous authentication using a combination of keystroke and mouse biometrics,” Neurocomputing, vol. 230, pp. 1–22, 2017.

[102]L. Fridman et al., “Multi-modal decision fusion for continuous authentication,” Computers & Electrical Engineering, vol. 41, pp. 142–156, 2015.

[103]S. Salmeron-Majadas, R. S. Baker, O. C. Santos y J. G. Boticario, “A machine learning approach to leverage individual keyboard and mouse interaction behavior from multiple users in real-world learning scenarios,” IEEE Access, vol. 6, pp. 39 154–39 179, 2018.

[104]J. Solano, L. Camacho, A. Correa, C. Deiro, J. Vargas y M. Ochoa, “Combining behavioral biometrics and session context analytics to enhance risk-based static authentication in web applications,” International Journal of Information Security, vol. 20, n.^o 2, pp. 181–197, 2021.

[105]A. Harilal et al., “The Wolf Of SUTD (TWOS): A Dataset of Malicious Insider Threat Behavior Based on a Gamified Competition.,” J. Wirel. Mob. Networks Ubiquitous Comput. Dependable Appl., vol. 9, n.^o 1, pp. 54–85, 2018.

[106]X. Wang, Q. Zheng, K. Zheng y T. Wu, “User Authentication Method Based on MKL for Keystroke and Mouse Behavioral Feature Fusion,” Security and Communication Networks, vol. 2020, 2020.

[107]K. O. Bailey, J. S. Okolica y G. L. Peterson, “User identification and authentication using multi-modal behavioral biometrics,” Computers & Security, vol. 43, pp. 77–89, 2014.

[108]Y. Li, B. Zou, S. Deng y G. Zhou, “Using feature fusion strategies in continuous authentication on smartphones,” IEEE Internet Computing, vol. 24, n.^o 2, pp. 49–56, 2020.

[109]I. Traore, I. Woungang, M. S. Obaidat, Y. Nakkabi e I. Lai, “Combining mouse and keystroke dynamics biometrics for risk-based authentication in web environments,” en 2012 fourth international conference on digital home, IEEE, 2012, pp. 138–145.

[110]A. G. Martín, M. Beltrán, A. Fernández-Isabel e I. M. de Diego, “An approach to detect user behaviour anomalies within identity federations,” Computers & Security, vol. 1-18, p. 102356, 2021.

[111]L. Hernández-Álvarez, J. M. de Fuentes, L. González-Manzano y L. Hernández Encinas, “Privacy-preserving sensor-based continuous authentication and user profiling: a review,” Sensors, vol. 21, n.^o 1, pp. 92–115, 2020.

[112]A. Vastel, P. Laperdrix, W. Rudametkin y R. Rouvoy, “Fp-scanner: The privacy implications of browser fingerprint inconsistencies,” en 27th {USENIX} Security Symposium ({USENIX} Security 18), 2018, pp. 135–150.

[113]M. Beltrán, “Identifying, authenticating and authorizing smart objects and end users to cloud services in Internet of Things,” Computers & Security, vol. 77, pp. 595–611, 2018.

[114]R. Magán-Carrión, J. Camacho, G. Maciá-Fernández y Á. Ruíz-Zafra, “Multivariate Statistical Network Monitoring-Sensor: An effective tool for real-time monitoring and anomaly detection in complex networks and systems,” International Journal of Distributed Sensor Networks, vol. 16, n.^o 5, pp. 1–14, 2020.

[115]A. Gómez-Boix, P. Laperdrix y B. Baudry, “Hiding in the crowd: an analysis of the effectiveness of browser fingerprinting at large scale,” en Proceedings of the 2018 world wide web conference, 2018, pp. 309–318.

[116]P. Laperdrix, N. Bielova, B. Baudry y G. Avoine, “Browser fingerprinting: A survey,” ACM Transactions on the Web (TWEB), vol. 14, n.^o 2, pp. 1–33, 2020.

[117]M. Abuhamad, A. Abusnaina, D. Nyang y D. Mohaisen, “Sensor-based Continuous Authentication of Smartphones’ Users Using Behavioral Biometrics: A Contemporary Survey,” IEEE Internet of Things Journal, vol. 8, n.^o 1, pp. 65–84, 2020.

[118]M. Bhatnagar, R. K. Jain y , “A Survey on Behavioral Biometric Techniques: Mouse vs Keyboard Dynamics,” Int. J. Comput. Appl, vol. 975, pp. 1–5, 2013.

[119]C. Chio y D. Freeman, Machine learning and security: Protecting systems with data and algorithms. O’Reilly Media, Inc.", 2018.

[120]V. Kozitsin, I. Katser y D. Lakontsev, “Online Forecasting and Anomaly Detection Based on the ARIMA Model,” Applied Sciences, vol. 11, n.^o 7, pp. 1–13, 2021.

[121]S. Hariri, M. C. Kind y R. J. Brunner, “Extended isolation forest,” IEEE Transactions on Knowledge and Data Engineering, vol. 33, n.^o 4, pp. 1479–1489, 2019.

[122]Z. Cheng, C. Zou y J. Dong, “Outlier detection using isolation forest and local outlier factor,” en Proceedings of the conference on research in adaptive and convergent systems, 2019, pp. 161–168.

[123]E. Schubert, J. Sander, M. Ester, H. P. Kriegel y X. Xu, “DBSCAN revisited, revisited: why and how you should (still) use DBSCAN,” ACM Transactions on Database Systems (TODS), vol. 42, n.^o 3, pp. 1–21, 2017.

[124]T. Shimshon, R. Moskovitch, L. Rokach e Y. Elovici, “Clustering di-graphs for continuously verifying users according to their typing patterns,” en 2010 IEEE 26-th Convention of Electrical and Electronics Engineers in Israel, IEEE, 2010, pp. 445–449.

[125]B. Tang, Q. Hu y D. Lin, “Reducing false positives of user-to-entity first-access alerts for user behavior analytics,” en 2017 IEEE International Conference on Data Mining Workshops (ICDMW), IEEE, 2017, pp. 804–811.

[126]J. Yan, Y. Qi, Q. Rao y S. Qi, “Towards a user-friendly and secure hand shaking authentication for smartphones,” en 2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE), IEEE, 2018, pp. 1170–1179.

[127]Z. C. Lipton, C. Elkan y B. Narayanaswamy, “Thresholding classifiers to maximize F1 score,” Machine Learning and Knowledge Discovery in Databases, vol. 8725, pp. 225–239, 2014.

[128]S. Eberz, K. B. Rasmussen, V. Lenders e I. Martinovic, “Evaluating behavioral biometrics for continuous authentication: Challenges and metrics,” en Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security, 2017, pp. 386–399.

[129]I. M. De Diego, A. R. Redondo, R. R. Fernández, J. Navarro y J. M. Moguerza, “General Performance Score for classification problems,” Applied Intelligence, 2022.

[130]A. G. Martín, I. M. de Diego, A. Fernández-Isabel, M. Beltrán y R. R. Fernández, “Combining user behavioural information at the feature level to enhance continuous authentication systems,” Knowledge-Based Systems, pp. 1–13, 2022.

[131]Y. Sun, J. Li, J. Liu, B. Sun y C. Chow, “An improvement of symbolic aggregate approximation distance measure for time series,” Neurocomputing, vol. 138, pp. 189–198, 2014.

[132]P. Geurts, D. Ernst y L. Wehenkel, “Extremely randomized trees,” Machine learning, vol. 63, n.^o 1, pp. 3–42, 2006.

[133]F. Moosmann, B. Triggs y F. Jurie, “Fast discriminative visual codebooks using randomized clustering forests,” en Twentieth Annual Conference on Neural Information Processing Systems (NIPS’06), MIT Press, 2006, pp. 985–992.

[134]M. G. Baydogan y G. Runger, “Learning a symbolic representation for multivariate time series classification,” Data Mining and Knowledge Discovery, vol. 29, n.^o 2, pp. 400–422, 2015.

[135]M. P. Van der Loo et al., “The stringdist package for approximate string matching.,” R J., vol. 6, n.^o 1, pp. 1–13, 2014.

[136]H. Li y N. Homer, “A survey of sequence alignment algorithms for next-generation sequencing,” Briefings in bioinformatics, vol. 11, n.^o 5, pp. 473–483, 2010.

[137]C. Trapnell y M. C. Schatz, “Optimizing data intensive GPGPU computations for DNA sequence alignment,” Parallel computing, vol. 35, n.^o 8-9, pp. 429–440, 2009.

[138]J. Cheetham, F. Dehne, S. Pitre, A. Rau-Chaplin y P. J. Taillon, “Parallel clustal w for pc clusters,” en International Conference on Computational Science and Its Applications, Springer, 2003, pp. 300–309.

[139]X. Huang y K.-M. Chao, “A generalized global alignment algorithm,” Bioinformatics, vol. 19, n.^o 2, pp. 228–233, 2003.

[140]H. Abdi, “Metric multidimensional scaling (MDS): analyzing distance matrices,” Encyclopedia of measurement and statistics, pp. 1–13, 2007.

[141]F. Klinker, “Exponential moving average versus moving exponential average,” Mathematische Semesterberichte, vol. 58, n.^o 1, pp. 97–107, 2011.

[142]let’s chat, https://sdelements.github.io/lets-chat, Visitado: 2022-05-04.

[143]M. Cantelon, M. Harter, T. Holowaychuk y N. Rajlich, Node. js in Action. Manning Greenwich, 2014.

[144]Mongodb, https://www.mongodb.com/, Visitado: 2022-05-04.

[145]L. A. Leiva y R. Vivó, “Web browsing behavior analysis and interactive hypervideo,” ACM Transactions on the Web (TWEB), vol. 7, n.^o 4, pp. 1–28, 2013.

[146]OpenAM, https://backstage.forgerock.com/docs/openam/13.5/, Visitado: 2022-05-04.

[147]Martín, Alejandro G and Beltrán, Marta and Fernández-Isabel, Alberto and de Diego, Isaac Martín, “Keystroke and Mouse Dynamics for UEBA Dataset, Mendeley Data, v2,” 2020.

[148]J. Ho y D.-K. Kang, “One-class Naïve Bayes with duration feature ranking for accurate user authentication using keystroke dynamics,” Applied Intelligence, vol. 48, n.^o 6, pp. 1547–1564, 2018.

[149]Y. Zhao, “Learning user keystroke patterns for authentication,” Proceedings of the world academy of science, engineering and technology, vol. 14, pp. 65–70, 2006.

[150]M. Malkauthekar, “Analysis of Euclidean distance and Manhattan distance measure in Face recognition,” en Third International Conference on Computational Intelligence and Information Technology (CIIT 2013), IET, 2013, pp. 503–507.

[151]T. Lodderstedt, S. Dronia y M. Scurtescu, OAuth 2.0 token revocation, 2013.