Explicabilidad aplicada a ciberseguridad en sistemas autónomos: un enfoque basado en LLMs para la detección forense de amenazas

Explicabilidad aplicada a ciberseguridad en sistemas aut´ onomos: Un enfoque basado en LLMs para la detecci´ on forense de amenazas David Sobr´ ın-Hidalgo Grupo de Rob´ otica, Universidad de Le´ on Campus de Vegazana s/n, 24071 Le´ on, Espa˜ na [email protected] Irene Gonz´ alez-Fern´ andez Grupo de Rob´ otica, Universidad de Le´ on Campus de Vegazana s/n, 24071 Le´ on, Espa˜ na [email protected] Miguel ´ Angel Gonz´ alez-Santamarta Grupo de Rob´ otica, Universidad de Le´ on Campus de Vegazana s/n, 24071 Le´ on, Espa˜ na [email protected] Adri´ an Campazas-Vega Grupo de Rob´ otica, Universidad de Le´ on Campus de Vegazana s/n, 24071 Le´ on, Espa˜ na [email protected] ´ Angel Manuel Guerrero-Higueras Grupo de Rob´ otica, Universidad de Le´ on Campus de Vegazana s/n, 24071 Le´ on, Espa˜ na [email protected] Francisco Javier Rodr´ ıguez-Lera Grupo de Rob´ otica, Universidad de Le´ on Campus de Vegazana s/n, 24071 Le´ on, Espa˜ na [email protected] Vicente Matell´ an-Olivera Grupo de Rob´ otica, Universidad de Le´ on Campus de Vegazana s/n, 24071 Le´ on, Espa˜ na [email protected] Resumen—En un mundo donde la interacci´ on entre humanos y sistemas rob´ oticos es cada vez m´ as frecuente, la ciberseguridad se vuelve imperativa para salvaguardar la integridad de ambos. Es fundamental establecer medidas de seguridad robustas que protejan a los humanos ante posibles accidentes o ciberataques que pueda sufrir un sistema rob´ otico. Sin embargo, tras un suceso inesperado, ya sea provocado por el mal funcionamiento del sistema o por la influencia de un actor malicioso, debe ser posible explicar lo sucedido. En este art´ ıculo se propone combinar el campo de la explicabilidad con el de la ciberseguridad, explorando as´ ı el potencial de un sistema de explicabilidad en rob´ otica basado en LLMs como herramienta forense. Para ello, se ha realizado un ataque de denegaci´ on de servicio sobre el controlador de un robot m´ ovil y, posteriormente, se han analizado los logs generados a trav´ es del sistema de explicabilidad propuesto. Los resultados obtenidos demuestran que este sistema es capaz de detectar la presencia de una potencial amenaza que afecta al comportamiento del robot. Index Terms—Rob´ otica, Explicabilidad, Ciberseguridad, An´ alisis forense, ROS 2, LLM Tipo de contribuci´ on: Investigaci´ on original I. INTRODUCCI´ ON Debido al r´ apido avance de la tecnolog´ ıa en general, tanto a nivel de hardware c´ omo de software, y de la inteligencia artificial en particular, el mundo est´ a atravesando una era caracterizada por una importante tendencia a la informatizaci´ on y a la automatizaci´ on de tareas. La rob´ otica asume un papel protagonista en este aspecto. La incorporaci´ on de robots en el mundo real es algo cada vez m´ as com´ un, que abarca desde el uso de robots camareros hasta la inclusi´ on de robots cirujanos. Todos estos sistemas deben hacer frente a los desaf´ ıos cl´ asicos de la ciberseguridad y todos ellos son v´ ıctimas potenciales de ciberataques. Son muchos los tipos de robots que pueden llamar la atenci´ on de un agente malicioso cuyas acciones pueden tener graves consecuencias. Algunos ejemplos son los robots industriales utilizados en f´ abricas, los coches aut´ onomos o los ya citados robots cirujanos. A diferencia de un ataque sobre un sistema inform´ atico, la alteraci´ on maliciosa del comportamiento de un sistema rob´ otico puede conllevar p´ erdidas materiales y, en el peor de los casos, provocar v´ ıctimas humanas. Es por esta raz´ on que, en particular, todos aquellos robots que interact´ uen de una forma u otra con humanos (rama de la rob´ otica conocida c´ omo interacci´ on humano-robot o HRI por sus siglas en ingl´ es) deben de integrar medidas de seguridad robustas. Dichas medidas deben proteger a los humanos de cualquier accidente que pudiera ocurrir, ya sea debido al malfuncionamiento puntual del robot o a la acci´ on de un ciberatacante. Sin embargo, no siempre es posible evitar estas situaciones de riesgo y, a´ un evit´ andose, resulta necesaria la realizaci´ on de estudios a posteriori que tienen c´ omo objetivo desentra˜ nar la naturaleza del incidente. Conocer lo ocurrido durante un accidente o un ataque es una informaci´ on fundamental, pues permite atribuir responsabilidades, detectar errores y solucionar potenciales agujeros de seguridad. Adem´ as, toda esta informaci´ on contribuye a reforzar los sistemas ante nuevos ataques, evitando de esta manera que se pueda repetir un ciberincidente. JNIC 2024 ISBN:978-84-09-62140-8 644 El presente trabajo se centra en el an´ alisis forense de incidencias en robots, utilizando un sistema de explicabilidad basado en LLMs para detectar intrusiones. La explicabilidad puede entenderse c´ omo la capacidad de un sistema aut´ onomo o inteligente de explicar sus propias decisiones. Este campo de estudio tiene un fuerte impacto en el mundo de la inteligencia artificial (eXplainable Artificial Intelligence o XAI [1]), d´ onde se han realizado una gran variedad de estudios por parte de la comunidad cient´ ıfica. Sin embargo, la explicabilidad no solo afecta a modelos de aprendizaje, sino tambi´ en a todo sistema que trabaje de forma aut´ onoma, c´ omo es el caso de los robots sociales o de servicio. La variante de la explicabilidad que se aplica al mundo rob´ otico se conoce c´ omo eXplainable Autonomous Robots (XAR) [2], y es desde esta variante desde la que se abordar´ a el planteamiento del presente trabajo. El comportamiento de un robot es complejo, lo cual hace crecer en complejidad el problema de ofrecer explicaciones sobre dicho comportamiento. La capacidad de autoexplicaci´ on en sistemas aut´ onomos no solo es de inter´ es para la comunidad investigadora, sino que en la ´ ultima d´ ecada se ha comenzado a reconocer la importancia de la explicabilidad en documentos legales, tal y c´ omo se recoge en el Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protecci´ on de las personas f´ ısicas en lo que respecta al tratamiento de datos personales y a la libre circulaci´ on de estos datos”[3]; documento en el que se abordan los derechos que tienen los ciudadanos respecto a las decisiones tomadas por un sistema inteligente que afectan de forma personal al ciudadano en cuesti´ on. En su Considerando 71 se recoge la siguiente cita: ”[...] derecho a obtener intervenci´ on humana, a expresar su punto de vista, a recibir una explicaci´ on de la decisi´ on tomada despu´ es de tal evaluaci´ on y a impugnar la decisi´ on.” Teniendo en cuenta la presencia de la explicabilidad en reglamentos oficiales queda patente la necesidad latente de que los sistemas aut´ onomos incorporen sistemas de explicabilidad. Sin embargo, ¿puede aprovecharse dicho sistema para mejorar la seguridad del robot? Lo cierto es que un sistema de explicabilidad robusto no solo deber´ ıa centrarse en generar una explicaci´ on de lo sucedido, sino que tambi´ en deber´ ıa prestar atenci´ on a todos los datos relevantes que el robot produce durante su comportamiento y que posteriormente podr´ ıan utilizarse para generar una explicaci´ on y se˜ nalar el origen de un comportamiento o problema. A este aspecto se le conoce c´ omo trazabilidad o accountability en ingl´ es. La trazabilidad est´ a muy relacionada con el proceso de selecci´ on de los datos, es decir, decidir qu´ e datos guardar y c´ omo guardarlos. Por lo tanto un sistema que incorpore tanto capacidades de trazabilidad c´ omo de generaci´ on de explicaciones puede ser una potencial herramienta para analizar comportamientos an´ omalos en robots, facilitando tareas c´ omo el an´ alisis forense realizado tras un incidente. El objetivo principal de este trabajo es, por tanto, comprobar la capacidad de un sistema de explicabilidad, dise˜ nado previamente, para detectar comportamientos an´ omalos en un robot m´ ovil utilizando los logs generados por el sistema. Para ello, el sistema de explicabilidad utilizado en la presente investigaci´ on esta compuesto por un manager de di´ alogo basado en un Large Language Model (LLM), cuyo objetivo es el de interpretar los logs del robot y generar explicaciones sobre lo sucedido. De esta forma un usuario, ejerciendo el rol de un analista forense, puede realizar preguntas al sistema de explicabilidad evitando de esta forma tener que analizar una gran cantidad de registros almacenados en el sistema. Concretamente, este trabajo se ha desplegado sobre sistemas rob´ oticos que incorporan ROS 2 [4] (Robot Operating System 2), es el middleware m´ as popularizado a la hora de construir aplicaciones rob´ oticas. ROS 2 cuenta con su propio sistema de log, el cual se ha utilizado para registrar la informaci´ on relevante para el posterior an´ alisis del comportamiento del robot. El art´ ıculo se estructura de la siguiente manera: en la Secci´ on II se realiza un breve an´ alisis de los trabajos relacionados referentes al uso de LLMs para ciberseguridad, as´ ı c´ omo de los principales problemas de ciberseguridad en ROS 2. En la Secci´ on III se presentan los materiales empleados y se define el experimento realizado. En la Secci´ on IV se recogen y discuten los resultados obtenidos a partir del experimento. Por ´ ultimo, en la Secci´ on V se exponen las conclusiones y los trabajos futuros. II. TRABAJOS RELACIONADOS En esta secci´ on se exploran algunos de los trabajos relacionados con la investigaci´ on realizada. El principal enfoque de la explicabilidad dentro del ´ ambito de la ciberseguridad es la de proporcionar explicaciones sobre las respuestas proporcionadas por diferentes aplicaciones de seguridad que funcionan de forma aut´ onoma (mediante el uso de Machine Learning (ML) y Deep Learning (DL) principalmente), c´ omo por ejemplo los sistemas de detecci´ on de intrusiones [5]. Sin embargo, el planteamiento de esta investigaci´ on radica en el uso de un sistema de explicabilidad integrado en un robot para realizar an´ alisis forense sobre el mismo. Debido a que una parte considerable de la implementaci´ on del sistema de explicabilidad se corresponde con uso de LLMs se ha decidido analizar algunos de los trabajos presentes en la literatura que abordan la relaci´ on entre estos modelos y la ciberseguridad. Tambi´ en se ha buscado analizar el estado actual a nivel de seguridad en el mundo de rob´ otica, en concreto en ROS 2, una cuesti´ on necesaria a la hora de comprender cuales son las amenazas m´ as comunes para este tipo de sistemas. II-A. Ciberseguridad y Large Language Models En primer lugar, con el objetivo de conocer el estado del arte respecto a las implicaciones de los LLMs en el mundo de la ciberseguridad, se han consultado algunas revisiones de literatura que abordan el tema. El a˜ no 2022 fue un momento de gran importancia para el mundo de la inteligencia artificial, debido al creciente inter´ es en los modelos de lenguaje. Desde entonces, los LLMs han mantenido la inercia y actualmente sus capacidades e influencia siguen creciendo. En [6] se explora la historia y el recorrido de algunos de los LLMs m´ as populares, as´ ı c´ omo la relaci´ on de estos con la ciberdefensa desde una perspectiva que explora el uso malicioso de LLMs. Explicabilidad aplicada a ciberseguridad en sistemas aut´onomos: Un enfoque basado en LLMs para la detecci´on forense de amenazas 645 En [7] se abordan dos enfoques. Los autores estudian por un lado las vulnerabilidades que puede presentar un LLM. Estas generalmente consisten en t´ ecnicas de bypassing las cuales tratan de modificar la entrada del modelo (tambi´ en conocida c´ omo prompt) para evitar las limitaciones del modelo, por ejemplo para forzarlo a generar c´ odigo malicioso. Los autores tambi´ en demuestran que pueden realizarse ataques de inyecci´ on de prompt para obtener informaci´ on delicada del modelo. Finalmente, analizando los LLM desde una perspectiva ofensiva, los autores exploran una serie de ataques que podr´ ıan verse beneficiados por el uso de un modelo de lenguaje. Debido a su destacable capacidad para generar texto, algunos de los ataques m´ as influenciados por LLMs son: ataques de ingenier´ ıa social, ataques de phishing, y la generaci´ on de ransomware y otro tipo de malware. De forma similar al art´ ıculo anterior, en [8] los autores analizan las vulnerabilidades potenciales que presentan los LLMs priorizando los ataques tipo backdoor. Para el prop´ osito de este art´ ıculo, el aspecto m´ as importante es el de la ciberdefensa, es decir c´ omo utilizar los modelos de lenguaje para favorecer los mecanismos de defensa de los sistemas rob´ oticos. En [7] y [9] se destaca la capacidad de procesamiento de lenguaje natural de los LLMs, la cual se convierte en una herramienta de gran utilidad a la hora de analizar c´ odigo fuente para buscar vulnerabilidades y solucionarlas. La generaci´ on de informes tambi´ en es una tarea en la que este tipo de modelos destacan de manera notable. La capacidad de gestionar cantidades de datos grandes y razonar sobre dichos datos es una de las facultades de los LLMs que pueden aportar un enorme valor al proceso del an´ alisis forense, lo cual es de un elevado inter´ es para el prop´ osito de este art´ ıculo. Siguiendo esta l´ ınea, los autores de [7] declaran: ”ChatGPT can process large volumes of log data and efficiently detect anomalies or security issues within access logs.” Otra propuesta diferente se puede encontrar en [10] d´ onde los autores comprueban la capacidad de ChatGPT-4.0 [11] para generar test de seguridad. Llegando a obtener resultados que superan a algunas de las herramientas m´ as popularizadas. Los autores tambi´ en destacan la necesidad de proveer al LLM con un prompt adecuado que cubra el respectivo dominio de conocimiento, necesario para proporcionar respuestas coherentes. Por otro lado, tambi´ en han surgido trabajos c´ omo el realizado en [12], en el cual proponen un nuevo modelo de lenguaje (SecureBERT) basado en BERT [13] y orientado a procesamiento de textos del ´ ambito de la ciberseguridad. La mayor parte de la literatura asume los LLMs c´ omo una herramienta destinada a acelerar tareas y mejorar el rendimiento humano. Sin embargo, a´ un teniendo en cuenta el incre´ ıble potencial de los LLMs, la comunidad investigadora parece llegar a un acuerdo a la hora de concebir los LLMs c´ omo un asistente eficaz para los profesionales de la ciberseguridad, pero de ninguna manera c´ omo una herramienta autom´ atica independiente del usuario humano. II-B. Ciberseguridad en ROS 2 Respecto a la seguridad en la rob´ otica y en concreto en ROS 2, uno de los problemas cl´ asicos del popular middleware es la escasa seguridad en sus comunicaciones. Si bien ROS 2 mejor´ o este aspecto al incorporar funcionalidades de criptograf´ ıa, estas est´ an desactivadas por defecto y su activaci´ on puede afectar al rendimiento de los sistemas debido a la carga de procesamiento adicional que a˜ naden al comportamiento del robot, tal y c´ omo exponen los autores de [14]. Otro inconveniente para la securizaci´ on de ROS 2, es que muchos de los equipos rob´ oticos todav´ ıa implementan internamente ROS y en muchas ocasiones la migraci´ on a ROS 2 depende del fabricante de cada robot. Esto provoca que para poder trabajar con ROS 2 se deban utilizar bridges, unos componentes software que permiten traducir los mensajes entre ROS y ROS 2, y viceversa. Esta capa adicional en las comunicaciones puede provocar nuevos agujeros de seguridad. Pese a que la migraci´ on a ROS 2 ha dejado algunos de los ataques cl´ asicos obsoletos al cambiar la capa de transporte (en ROS 2 se pasa a utilizar DDS en lugar de TCPROS), la nueva versi´ on todav´ ıa no est´ a libre de vulnerabilidades, algunas de ellas heredadas de su anterior versi´ on. En [15] los autores proponen dos herramientas para realizar pentesting en aplicaciones construidas en ROS y proponen dos herramientas: ROSPen y Roschaos, que permiten analizar y manipular dichas aplicaciones. En el citado trabajo pueden advertirse algunos de los ataques m´ as populares en ROS, c´ omo ataques de denegaci´ on de servicio (DoS) o ataques basados en violaci´ on de la integridad y privacidad de las comunicaciones, c´ omo los del tipo man-in-the-middle (MITM). Otro ejemplo de los fallos de seguridad de ROS, que permiten interceptar y manipular la comunicaci´ on entre los nodos de ROS, se recoge en [16], d´ onde los autores exponen las vulnerabilidades en el protocolo de comunicaciones a trav´ es de un ataque MITM. El peligro subyacente a la ausencia de m´ etodos criptograficos en ROS o a la incapacidad de aplicarlos en sistemas concretos se puede apreciar en [17] d´ onde los autores demuestran la posibilidad de capturar los mensajes intercambiados por los nodos dentro de una red utilizando herramientas c´ omo Wireshark. Otro de los ataques a los que las aplicaciones construidas sobre ROS son m´ as susceptibles es la denegaci´ on de servicio, tal y c´ omo se ha indicado previamente. En [18] se recoge un an´ alisis sobre este tipo de ataques dirigidos a robots teleoperados. Esta misma situaci´ on es la que se ha elegido para dirigir el experimento planteado en el presente trabajo. III. M´ ETODOS Y MATERIALES El presente trabajo explora la posibilidad de que un sistema de explicabilidad integrado en un sistema rob´ otico pueda ser utilizado tambi´ en para facilitar y acelerar tareas relacionadas con el an´ alisis forense realizado despu´ es de un incidente. Para abordar este problema se ha partido de un sistema de explicabilidad basado en LLMs, previamente implementado en [19]. Dicho sistema aprovecha las altas capacidades de esta tecnolog´ ıa a la hora de realizar tareas relacionadas con el procesamiento del lenguaje natural, para analizar grandes conjuntos de logs que se han generado durante el comportamiento del robot. D. Sobr´ın Hidalgo, I. Gonz´alez Fern´andez, M. A. Gonz´alez Santamarta, A. Campazas Vega, A. M. Guerrero Higueras, F. J. Rodr´ıguez Lera and V. Matell´an Olivera 646 III-A. Materiales A la hora de realizar el experimento que gu´ ıa la presente investigaci´ on se han empleado una serie de recursos y materiales, tanto software c´ omo hardware. Dichos materiales se enumeran a continuaci´ on. ROS 2. Tanto el robot c´ omo los componentes software desarrollados para el experimento est´ an constru´ ıdos sobre ROS, en concreto sobre ROS 2 Humble, la ´ ultima distribuci´ on de ROS 2 estable. Langchain [20]. Una librer´ ıa que facilita el desarrollo de aplicaciones basadas en LLMs. Tambi´ en ofrece la posibilidad de implementar el m´ etodo RAG de una forma sencilla. Liminerity/M7-7b-GGUF. Modelo encargado de procesar la pregunta del usuario y los logs m´ as relevantes, para generar una explicaci´ on Mixedbread-ai/mxbai-embed-large-v1. Modelo encargado de generar los embbedings de cada uno de los logs recibidos a trav´ es del topic /rosout. La investigaci´ on se ha llevado a cabo sobre sistemas rob´ oticos constru´ ıdos en ROS 2. El funcionamiento b´ asico de ROS 2 es el de un modelo Publisher -Subscriber, en el cual la comunicaci´ on se realiza a trav´ es de componentes software denominados Nodos que intercambian mensajes a trav´ es de canales de informaci´ on llamados topics. La ventaja de este tipo de comunicaci´ on es la facilidad con la que pueden monitorizar los mensajes intercambiados. Toda la informaci´ on que llega a los topics, ya sea la publicada por los sensores del robot o la destinada a controlar sus actuadores, puede registrarse. El sistema de explicabilidad utilizado para la presente investigaci´ on aprovecha este registro de mensajes y trata de razonar lo que ha sucedido. Su funcionamiento consiste en utilizar los mensajes que han sido enviados al topic /rosout (log principal de ROS 2) c´ omo contexto para el LLM encargado de generar las explicaciones. Sin embargo, la cantidad de mensajes publicados en /rosout puede suponer un contexto demasiado grande para el sistema, y provocar que los razonamientos no sean coherentes ni precisos. Para ello se construye un contexto m´ as reducido a partir de todos los mensajes registrados. Este contexto se corresponde con los logs m´ as relevantes para construir una explicaci´ on concreta. Este nuevo contexto se consigue a trav´ es del m´ etodo Retrieval Aumented Generator (RAG) [21] y empleando una base de datos de vectores para almacenar los logs. En la Figura 1 se ilustra el funcionamiento del sistema de explicabilidad junto al m´ etodo RAG. Figura 1. Funcionamiento del sistema de explicabilidad d´ onde se muestra el m´ etodo RAG. Imagen extra´ ıda de [19]. En lo referente a los modelos utilizados, estos han sido obtenidos a trav´ es de Hugging Face. Para ambos modelos se ha tenido en consideraci´ on su posici´ on de sus respectivos leaderboards en Hugging Face; [22] para el modelo de explicabilidad y [23] para el modelo encargado e los embbedings. Otras caracter´ ısticas influyentes en la elecci´ on han sido el tama˜ no del modelo y su quantizaci´ on. Por otra parte, el experimento se ha realizado empleando un robot real navegando mediante teleoperaci´ on por un apartamento simulado. El robot utilizado ha sido TIAGo, un robot manipulador m´ ovil fabricado por Pal Robotics. Por otro lado, en la Figura 2, junto al citado robot, se muestra el entorno en el que se ha realizado el experimento, una testbed certificada por la European Robotics League (ERL): Leon@Home1. Figura 2. Imagen de la testbed utilizada junto al robot TIAGo. El entorno consiste en un apartamento simulado. III-B. M´ etodos A continuaci´ on se detalla el experimento realizado junto con el ataque seleccionado para evaluar el sistema de explicabilidad. III-B1. Dise˜ no del experimento: El experimento planteado para la presente investigaci´ on consiste en analizar el comportamiento de un robot teleoperado. Para ello se ha desarrollado un nodo de ROS 2 que monitoriza constantemente la actividad de un topic, calculando los Hz a los que se est´ a publicando en dicho topic e imprimiendo una traza en /rosout en caso de que la tasa de publicaci´ on crezca o disminuya de manera significativa. El contexto del experimento es, por tanto, el siguiente. Un usuario teleopera un robot de servicio a trav´ es de un mando o controlador remoto para hacerlo recorrer un espacio real (un apartamento en el caso del presente experimento). El controlador publica mensajes en el topic /input joy/cmd vel. Los topics /cmd vel est´ an tradicionalmente relacionados con la navegaci´ on, pues se utilizan para intercambiar mensajes sobre el movimiento del robot. Estos mensajes son del tipo /geometry msgs/Twist que tienen el formato presentado en el Listado 1. # This expresses velocity in free space broken into its linear and angular parts. Vector3 linear 1Se puede consultar la informaci´ on referente a la testbed a trav´ es de su p´ agina web: https://robotica.unileon.es/index.php?title=Testbed Explicabilidad aplicada a ciberseguridad en sistemas aut´onomos: Un enfoque basado en LLMs para la detecci´on forense de amenazas 647 float64 x float64 y float64 z Vector3 angular float64 x float64 y float64 z Listing 1. Estructura de un mensaje tipo Twist El sistema de explicabilidad se suscribe a /rosout, d´ onde el nodo encargado de monitorizar la tasa de publicaci´ on de /cmd vel publicar´ a los cambios relevantes. A partir de este punto el sistema tomar´ a c´ omo contexto los logs generados durante la teleoperaci´ on. Una vez finalizada la actividad del robot. El usuario ser´ a capaz de realizar preguntas al sistema para conocer lo que ha ocurrido. El experimento ha consistido en dos ejecuciones. En cada una de ellas el objetivo del teleoperador es llevar al robot de un punto a otro dentro del apartamento, siendo estos puntos siempre los mismos. La ruta seguida por el robot se muestra en la Figura 3. Figura 3. Plano del apartamento simulado en el que se representa la ruta seguida por el robot mediante una flecha roja. El c´ ırculo verde representa el punto de inicio de la navegaci´ on, mientras que el c´ ırculo rojo muestra el punto de destino. Durante la ejecuci´ on 2 se ha simulado un ataque de denegaci´ on de servicio durante la navegaci´ on, a trav´ es de la publicaci´ on adicional de mensajes en el topic que controla el movimiento del robot. Las distintas ejecuciones realizadas se enumeran a continuaci´ on: E1 El robot completa la navegaci´ on sin que se produzca ning´ un ataque. E2 El robot sufre un ataque con una tasa de publicaci´ on muy superior a la normal (500 Hz). Los datos generados durante la realizaci´ on de las pruebas se han grabado mediante Rosbags, un formato de datos de ROS que permite almacenar los mensajes intercambiados durante la ejecuci´ on del comportamiento del robot. Los Rosbags obtenidos se han analizado a posteriori utilizando el sistema de explicabilidad dise˜ nado para ROS. Emulando un posible an´ alisis forense, el Rosbag se ha reproducido y los mensajes generados en el topic /rosout han sido capturados y procesados por el LLM. El sistema de explicabilidad utilizado funciona c´ omo un m´ anager de di´ alogo entre el usuario y el LLM, por lo tanto para obtener una explicaci´ on de lo sucedido, el usuario debe realizar una pregunta al modelo. Las preguntas realizadas constituyen parte del prompt del LLM y su expresi´ on y estructura son fundamentales para poder obtener resultados coherentes. El sistema de explicabilidad deber´ a, de esta forma, responder a la misma pregunta para ambas ejecuciones. La pregunta establecida para comprobar el funcionamiento del sistema ha sido formulada en ingl´ es para un mejor procesamiento por parte del LLM. Dicha pregunta se ha presentado de la siguiente forma: Pregunta 1: Do you observe any problems in the cmd vel? If so, could it be a cyberattack, and what type of cyberattack? Adem´ as de la pregunta es necesario establecer una plantilla para el prompt (prompt template), que permite dar ciertas indicaciones y contexto al modelo. La plantilla utilizada se recoge en el Listado 2. "You are an explainability AI tool for ROS 2 mobile robots. " "Your goal is to detect possible cyberattacks. " "You have to detect anomalous behavior within the robot’s data. " "You have to interpret the robot’s data paying attention to the publication rates of cmd_vel, that is between 8.0Hz and 23.0Hz.\n\n" "Relevant data:\n" "{logs}\n\n" "USER: " "Given the context information and not prior knowledge, answer the query: {question}\n" "ASSISTANT:" Listing 2. Prompt template utilizada para el LLM El prompt final que servir´ a c´ omo entrada del LLM est´ a constru´ ıdo mediante la combinaci´ on de la plantilla, la pregunta del usuario y los 10 registros m´ as relevantes obtenidos mediante el m´ etodo RAG. Los logs recogen la frecuencia de publicaci´ on del topic /cmd vel; la plantilla establece que el sistema debe comportarse c´ omo un Sistema de Detecci´ on de Intrusiones (IDS) e indica el rango de frecuencias de publicaci´ on esperado durante una ejecuci´ on normal del robot. Por ´ ultimo, en la pregunta se insiste en el an´ alisis del topic. Toda esta informaci´ on es necesaria para que el LLM pueda producir una respuesta razonable, debido al impacto que el contexto y la verbosidad de los datos tienen en el comportamiento del modelo. III-B2. Ataque de denegaci´ on de servicio: Se ha decidido evaluar las capacidades del sistema descrito mediante la simulaci´ on de un ataque de denegaci´ on de servicio. La raz´ on tras la selecci´ on de este tipo de ataque es que debido al funcionamiento de las comunicaciones de ROS 2, resulta sencillo inundar un topic con mensajes maliciosos que alteren el funcionamiento del robot. Debido a que el controlar del robot seleccionado para el experimento tiene una tasa de publicaci´ on de 10 Hz, es posible saturar el topic publicando mensajes a una tasa muy superior de, por ejemplo, 500 Hz. La informaci´ on que el supuesto atacante publicar´ a en el topic ser´ an mensajes del tipo Twist, definido previamente, pero con un valor de 0 en cada una de sus componentes (velocidad lineal y angular). Esto provocar´ a que los mensajes del controlador se pierdan y el robot se detenga. En la Figura D. Sobr´ın Hidalgo, I. Gonz´alez Fern´andez, M. A. Gonz´alez Santamarta, A. Campazas Vega, A. M. Guerrero Higueras, F. J. Rodr´ıguez Lera and V. Matell´an Olivera 648 4 se ilustra la comunicaci´ on del robot con el teleoperador a trav´ es de ROS 2, y la intervenci´ on del atacante. Figura 4. Ataque de denegaci´ on de servicio sobre un robot m´ ovil. Los Nodos de ROS 2 se representan con c´ ırculos y los topics con cuadrados. La comunicaci´ on normal est´ a representada por flechas azules, mientras que la comunicaci´ on maliciosa se representa con una flecha roja. El LLM que se emplear´ a para interpretar y explicar los datos requiere una informaci´ on concreta. En este punto la verbosidad de los logs adopta un papel fundamental a la hora de obtener buenas explicaciones. Esta es la raz´ on por la que se ha necesitado desarrollar un nodo que se encargue de monitorizar los Hz, ya que esta informaci´ on puede ser ´ util a la hora de decidir si el comportamiento que se est´ a visualizando en un topic es correcto o an´ omalo. IV. RESULTADOS Y DISCUSI ´ ON En esta secci´ on se presentan y analizan los resultados obtenidos durante el experimento. Para cada una de las dos ejecuciones realizadas se han recogido la salida mostrada por el nodo de monitorizaci´ on, y los pares preguntas-respuestas relativos a la explicaci´ on generada por el sistema. Adem´ as en la Tabla I se muestra informaci´ on relativa a los rosbags generados. Tabla I INFORMACI ´ ON DE LOS rosbags DE LAS DIFERENTES EJECUCIONES. INCLUYE EL N ´ UMERO TOTAL DE MENSAJES REGISTRADOS,LA DURACI ´ ON DE LA EJECUCI´ ON Y EL TAMA ˜ NO DEL rosbag. ID Ejecuci´ on Nº Mensajes Duraci´ on (s) Tama˜ no (MB) E1 7120 75.6 6.6 E2 10355 40.2 3.5 IV-A. Ejecuci´ on 1 En la Ejecuci´ on 1 el robot navega (mediante la teleoperaci´ on de un usuario humano) sin ning´ un incidente. Las trazas generadas por el nodo encargado de monitorizar el topic /cmd vel se recogen en el Listado 3. Average publication rate of cmd_vel: 9.00Hz. Average publication rate of cmd_vel: 9.14Hz. Average publication rate of cmd_vel: 9.50Hz. Average publication rate of cmd_vel: 12.00Hz. Average publication rate of cmd_vel: 12.86Hz. Average publication rate of cmd_vel: 14.22Hz. Average publication rate of cmd_vel: 19.56Hz. Average publication rate of cmd_vel: 19.54Hz. Average publication rate of cmd_vel: 20.67Hz. Average publication rate of cmd_vel: 20.93Hz. Average publication rate of cmd_vel: 21.73Hz. Average publication rate of cmd_vel: 21.73Hz. Average publication rate of cmd_vel: 22.39Hz. Average publication rate of cmd_vel: 21.47Hz. Average publication rate of cmd_vel: 20.62Hz. Average publication rate of cmd_vel: 20.01Hz. Average publication rate of cmd_vel: 20.01Hz. Average publication rate of cmd_vel: 20.01Hz. Listing 3. Frecuencia de publicaci´ on durante la Ejecuci´ on 1 En el Listado 6 se recoge la pregunta del usuario y la respuesta del LLM a trav´ es de un servicio de ROS 2. $ ros2 service call /question explicability_msgs/srv /Question "{question: ’Do you observe any problem in the cmd_vel? If so, could it be a cyberattack, and what type of cyberattack?’}" response: explicability_msgs.srv.Question_Response(answer=" Based on the provided data alone, focusing solely on the publication rates of cmd_vel within the expected range of 8.0Hz to 23.0Hz, there do not appear to be any obvious anomalies or signs of a cyberattack. The rates fluctuate naturally, but they remain within the acceptable range. However, it’s important to note that a comprehensive analysis would require more context and a broader set of metrics to accurately detect potential cybersecurity threats.") Listing 4. Explicaci´ on generada por el LLM El v´ ıdeo que muestra la ejecuci´ on de este experimento se encuentra disponible en https://www.youtube.com/watch?v= fov5Jwoh vQ. IV-B. Ejecuci´ on 2 En la Ejecuci´ on 2 se produce un ataque de denegaci´ on de servicio, inundando de datos el topic /cmd vel, mientras el robot est´ a siendo teleoperado. Este ataque provoca que el robot se detenga, ignorando las instrucciones de su controlador humano. En este caso, las trazas generadas por el nodo monitorizador se muestran en el Listado 5. Average publication rate of cmd_vel: 8.50Hz. Average publication rate of cmd_vel: 8.57Hz. Average publication rate of cmd_vel: 10.25Hz. Average publication rate of cmd_vel: 11.41Hz. Average publication rate of cmd_vel: 12.23Hz. Average publication rate of cmd_vel: 36.32Hz. Average publication rate of cmd_vel: 96.57Hz. Average publication rate of cmd_vel: 146.37Hz. Average publication rate of cmd_vel: 170.00Hz. Average publication rate of cmd_vel: 170.00Hz. Listing 5. Frecuencia de publicaci´ on durante la Ejecuci´ on 1 De nuevo, la pregunta del usuario y la respuesta del LLM se recogen en el Listado 6. $ ros2 service call /question explicability_msgs/srv /Question "{question: ’Do you observe any problem in the cmd_vel? If so, could it be a cyberattack, and what type of cyberattack?’}" response: explicability_msgs.srv.Question_Response(answer=" In the provided data, there are significant spikes in the average publication rates of cmd_vel, which exceed the expected range of 8.0 Hz to 23.0Hz. At 1710853730.8051765, the rate jumps to 36.32Hz, and from 1710853735.805152 to 1710853745.805236, the rates are abnormally high, reaching up to 170.00Hz. While these extreme fluctuations might indicate a problem with the system, it’s crucial to note that solely based on this data, we cannot definitively conclude it as a cyberattack. Anomalous behavior could be due to various reasons, including software glitches or misconfigurations. To determine if it’s a Explicabilidad aplicada a ciberseguridad en sistemas aut´onomos: Un enfoque basado en LLMs para la detecci´on forense de amenazas 649 cyberattack, more context and evidence would be necessary. If confirmed as a malicious act, one might speculate a Denial of Service (DoS) attack or a manipulation attempt to compromise the robot’s control, but further investigation is required for a conclusive assessment.") Listing 6. Explicaci´ on generada por el LLM El v´ ıdeo que muestra la ejecuci´ on de este experimento se encuentra disponible en https://www.youtube.com/watch?v= LSVOb0mBxPE. IV-C. Discusi´ on El principal inter´ es del presente trabajo es analizar las respuestas generadas por el sistema de explicabilidad para valorar si su uso puede ser beneficioso para un an´ alisis forense. Si analizamos el primer caso, recogido en los Listados 3 y 4 se puede observar c´ omo el modelo considera los logs dentro del comportamiento normal. Es de gran importancia tener en cuenta el contexto que se le proporciona al LLM antes de la ejecuci´ on, en este caso indic´ andole los rangos entre los que deber´ ıa oscilar la frecuencia de publicaci´ on para considerarse normal. Por otro lado, destacan los resultados obtenidos para la segunda ejecuci´ on, que se corresponde con una inundaci´ on del topic de movimiento del robot, y que se presenta en los Listados 5 y 6. En esta ejecuci´ on, el sistema identifica correctamente los incrementos en las frecuencias de publicaci´ on del topic considerando incluso las marcas de tiempo asociadas a las diferentes trazas. El sistema indica que la frecuencia de publicaci´ on llega a ser ”anormalmente elevada, alcanzado los 170Hz”. A la hora de asociar los logs generados durante la ejecuci´ on con un posible ataque, el sistema infiere de forma exitosa que se trata de un ataque DoS para comprometer el control del robot. En ambas ejecuciones el sistema expresa la necesidad de que la situaci´ on sea estudiada por un experto humano, dejando claro que su respuesta no es definitiva. Es necesario destacar este comportamiento ya que est´ a alineado con la intenci´ on original del trabajo en la cual se propone el uso de este tipo de tecnolog´ ıa c´ omo un complemento al analista, pero nunca c´ omo una sustituci´ on. El objetivo final, del sistema es, por tanto, el de acelerar el proceso de an´ alisis forense. Si se observan los resultados recogidos en la Tabla I, se puede observar que para ejecuciones con una duraci´ on de aproximadamente un minuto pueden llegar a generarse una cantidad de logs muy elevada, lo cual aumenta la complejidad a la hora de ser analizados por un experto humano. En la ejecuci´ on 1 se generaron 7120 mensajes. En la ejecuci´ on 2, por su parte, se generaron un total de 10355. Como se puede observar, el sistema es capaz de advertir una posible amenaza y orientar al analista a la hora de comenzar a estudiar los datos. V. CONCLUSI´ ON La presencia de sistemas rob´ oticos en la sociedad ha aumentado exponencialmente en los ´ ultimos a˜ nos. Este nuevo paradigma plantea importantes retos a nivel de seguridad. La convivencia entre humanos y robots crea la necesidad de que estos sistemas sean cibern´ eticamente seguros. Por otro lado, es necesario conocer que eventos est´ an ocurriendo en el propio robot, es decir que los sistemas posean capacidades para explicar su comportamiento. Esta capacidad puede ser utilizada para detectar un posible comportamiento an´ omalo del sistema, pero tambi´ en para detectar ciberataques sobre el robot. En este trabajo se ha presentado un mecanismo que demuestra el potencial de un sistema de explicabilidad basado en LLMs para ser utilizado c´ omo herramienta complementaria a la hora de realizar tareas de an´ alisis forense en sistemas rob´ oticos. Los resultados obtenidos muestran la capacidad de este tipo de sistemas de inferir lo ocurrido durante un ciberataque, mejorando as´ ı la comprensi´ on del mismo y minimizando exponencialmente la cantidad de tiempo que necesita emplear un analista forense a la hora de analizar los datos generados por el sistema. Por un lado, a ra´ ız de las conclusiones obtenidas en este art´ ıculo, se plantea ampliar el trabajo aqu´ ı presentado para comprobar su validez a la hora de enfrentarse a otros tipos de ataque com´ unmente realizados sobre robots, c´ omo por ejemplo la interferencia de las comunicaciones a ra´ ız de un ataque del tipo man-in-the-middle [24]. Por otro lado, en este art´ ıculo se ha planteado el uso, c´ omo herramienta forense, de un sistema de explicabilidad previamente incorporado en un robot. Sin embargo, en un futuro se plantea modificar dicho sistema, para ampliar su funcionalidad y poder construir un sistema de alertas sobre posibles incidencias en tiempo real. De esta manera el sistema no se centrar´ a´ unicamente en generar explicaciones sino que tambi´ en tendr´ a funcionalidades propias de un IDS. AGRADECIMIENTOS Este trabajo ha sido parcialmente financiado por el Plan de Recuperaci´ on, Transformaci´ on y Resiliencia, financiado por la Uni´ on Europea (Next Generation) gracias al proyecto TESCAC (Trazabilidad y Explicabilidad en Sistemas Aut´ onomos para la mejora de la Ciberseguridad) concedido por INCIBE a la Universidad de Le´ on. Este trabajo ha sido financiado por EDMAR: Grant PID2021-126592OB-C21 financiado por MCIN/AEI/10.13039/501100011033. David Sobr´ ın Hidalgo agradece una beca para financiar sus estudios de doctorado proporcionada por la Universidad de Le´ on. REFERENCIAS [1] F. K. Doˇ silovi´ c, M. Brˇ ci´ c, and N. Hlupi´ c, “Explainable artificial intelligence: A survey,” in 2018 41st International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2018, pp. 0210–0215. [2] T. Sakai and T. Nagai, “Explainable autonomous robots: a survey and perspective,” Advanced Robotics, vol. 36, no. 5-6, pp. 219–238, 2022. [Online]. Available: https://doi.org/10.1080/01691864.2022.2029720 [3] U. Europea, “Reglamento (ue) 2016/679 del parlamento europeo y del consejo de 27 de abril de 2016 relativo a la protecci´ on de las personas f´ ısicas en lo que respecta al tratamiento de datos personales ya la libre circulaci´ on de estos datos y por el que se deroga la directiva 95/46/ce (reglamento general de protecci´ on de datos)(texto pertinente a efectos del eee),” 2021. [4] S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot operating system 2: Design, architecture, and uses in the wild,” Science Robotics, vol. 7, no. 66, p. eabm6074, 2022. [Online]. Available: https://www.science.org/doi/abs/10.1126/scirobotics.abm6074 [5] N. Capuano, G. Fenza, V. Loia, and C. Stanzione, “Explainable artificial intelligence in cybersecurity: A survey,” IEEE Access, vol. 10, pp. 93 575–93 600, 2022. D. Sobr´ın Hidalgo, I. Gonz´alez Fern´andez, M. A. Gonz´alez Santamarta, A. Campazas Vega, A. M. Guerrero Higueras, F. J. Rodr´ıguez Lera and V. Matell´an Olivera 650 [6] A. Kucharavy, Z. Schillaci, L. Mar´ echal, M. W¨ ursch, L. Dolamic, R. Sabonnadiere, D. P. David, A. Mermoud, and V. Lenders, “Fundamentals of generative large language models and perspectives in cyber-defense,” 2023. [7] M. Gupta, C. Akiri, K. Aryal, E. Parker, and L. Praharaj, “From chatgpt to threatgpt: Impact of generative ai in cybersecurity and privacy,” IEEE Access, vol. 11, pp. 80218–80245, 2023. [8] H. Li, Y. Chen, J. Luo, Y. Kang, X. Zhang, Q. Hu, C. Chan, and Y. Song, “Privacy in large language models: Attacks, defenses and future directions,” 2023. [9] F. N. Motlagh, M. Hajizadeh, M. Majd, P. Najafi, F. Cheng, and C. Meinel, “Large language models in cybersecurity: State-of-the-art,” arXiv preprint arXiv:2402.00891, 2024. [10] Y. Zhang, W. Song, Z. Ji, Danfeng, Yao, and N. Meng, “How well does LLM generate security tests?” arXiv e-prints, p. arXiv:2310.00710, Oct. 2023. [11] OpenAI, “Gpt-4 technical report,” 2024. [12] E. Aghaei, X. Niu, W. Shadid, and E. Al-Shaer, “Securebert: A domainspecific language model for cybersecurity,” in Security and Privacy in Communication Networks, F. Li, K. Liang, Z. Lin, and S. K. Katsikas, Eds. Cham: Springer Nature Switzerland, 2023, pp. 39–56. [13] J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “Bert: Pre-training of deep bidirectional transformers for language understanding,” 2019. [14] J. Kim, J. M. Smereka, C. Cheung, S. Nepal, and M. Grobler, “Security and performance considerations in ros 2: A balancing act,” arXiv preprint arXiv:1809.09566, 2018. [15] B. Dieber, R. White, S. Taurer, B. Breiling, G. Caiazza, H. Christensen, and A. Cortesi, “Penetration testing ros,” Robot Operating System (ROS) The Complete Reference (Volume 4), pp. 183–225, 2020. [16] R. R. Teixeira, I. P. Maurell, and P. L. Drews, “Security on ros: analyzing and exploiting vulnerabilities of ros-based systems,” in 2020 Latin American Robotics Symposium (LARS), 2020 Brazilian Symposium on Robotics (SBR) and 2020 Workshop on Robotics in Education (WRE), 2020, pp. 1–6. [17] J. McClean, C. Stull, C. Farrar, and D. Mascarenas, “A preliminary cyber-physical security assessment of the robot operating system (ros),” in Unmanned systems technology xv, vol. 8741. SPIE, 2013, pp. 341– 348. [18] T. Bonaci, J. Yan, J. Herron, T. Kohno, and H. J. Chizeck, “Experimental analysis of denial-of-service attacks on teleoperated robotic systems,” in Proceedings of the ACM/IEEE sixth international conference on cyberphysical systems, 2015, pp. 11–20. [19] D. Sobr´ ın-Hidalgo, M. A. Gonz´ alez-Santamarta, ´ Angel M. Guerrero- Higueras, F. J. Rodr´ ıguez-Lera, and V. Matell´ an-Olivera, “Explaining autonomy: Enhancing human-robot interaction through explanation generation with large language models,” 2024. [20] H. Chase, “LangChain,” Oct. 2022. [Online]. Available: https: //github.com/langchain-ai/langchain [21] Y. Gao, Y. Xiong, X. Gao, K. Jia, J. Pan, Y. Bi, Y. Dai, J. Sun, Q. Guo, M. Wang, and H. Wang, “Retrieval-augmented generation for large language models: A survey,” 2024. [22] E. Beeching, C. Fourrier, N. Habib, S. Han, N. Lambert, N. Rajani, O. Sanseviero, L. Tunstall, and T. Wolf, “Open llm leaderboard,” 2023. [Online]. Available: {https://huggingface.co/spaces/HuggingFaceH4/ open\llm\leaderboard} [23] N. Muennighoff, N. Tazi, L. Magne, and N. Reimers, “Mteb: Massive text embedding benchmark,” arXiv preprint arXiv:2210.07316, 2022. [Online]. Available: https://arxiv.org/abs/2210.07316 [24] A. M. D´ ıez, A. C. Vega, B. J. de Castro, C. ´ A. Aparicio, I. S. C. Mart´ ınez, and ´ A. M. G. Higueras, “Evaluaci´ on de la seguridad en el robot cuadr´ upedo a1 de unitree robotics,” in Actas de las VIII Jornadas Nacionales de Investigaci´ on en Ciberseguridad: Vigo, 21 a 23 de junio de 2023. Universidade de Vigo, 2023, pp. 133–138. Explicabilidad aplicada a ciberseguridad en sistemas aut´onomos: Un enfoque basado en LLMs para la detecci´on forense de amenazas 651