Automatización del cálculo del nivel de seguridad de un entorno IoT basado en el inventario y las vulnerabilidades intrínsecas del sistema

ActasdelasXVJornadas deIngenieríaTelemática (JITEL2021), ACoruña(España), 27‐29deoctubrede2021. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) Automatización del cálculo del nivel de seguridad de un entorno IoT basado en el inventario y las vulnerabilidades intrínsecas del sistema Marc Salinero, Julia Sánchez, Guiomar Corral. Departamento de In g eniería, Grupo de Investi g ación en Internet Technolo g ies and Stora g e (GRITS), La Salle Campus Barcelona – Universidad Ramon Llull (URL) Quatre Camins 30, 08022, Barcelona. marc.salinero @ students.salle.url.edu, j .sanchez @ salle.url.edu, g uiomar.corral @ salle.url.edu. Este documento presenta la implementación de un bloque encargado de calcular el nivel de seguridad asociado a un entorno IoT basándose en los dispositivos presentes y en las vulnerabilidades intrínsecas del mismo. Este bloque forma parte de un sistema más complejo encargado de calcular el riesgo total del entorno IoT añadiendo el resultado de: (1) la realización de ciertos tests contra los dispositivos encontrados y, (2) la correlación de los logs almacenados fruto de la monitorización continua de dicho entorno. Palabras Clavejitel, telemática, IoT, ciberseguridad, riesgos I. I NTRODUCCIÓN El paradigma IoT (Internet of Things) ha ganado importancia en los últimos años debido a las ventajas que proporciona al mejorar nuestra calidad de vida. Los dispositivos IoT obtienen información del entorno que, tratada adecuadamente, proporciona cierto grado de inteligencia permitiendo tomar decisiones difíciles de manera más fácil y, por tanto, ejecutar tareas diarias con la mínima intervención humana. IoT convierte los hogares, edificios, hospitales, ciudades, industrias, entre otros, en sistemas inteligentes capaces de obtener el conocimiento del entorno y aplicarlo para su adaptación de acuerdo a las necesidades de los habitantes. El IoT no para de crecer, cada vez más todos los dispositivos que tenemos o tendremos estarán conectados entre ellos y al cloud. Se multiplicarán las conexiones, la información transmitida a través de la red y, desafortunadamente, los ataques hacia estos dispositivos. Estos dispositivos pueden transmitir información crítica o confidencial y, por tanto, el nivel de seguridad que deben tener es elevado. El grupo de investigación en Internet Technologies and Storage (GRITS) de La Salle Campus BCN-URL ha dedicado parte de sus esfuerzos, desde hace algún tiempo, a investigar sobre IoT, concretamente sobre ciberseguridad en entornos IoT. La gran dependencia que mantiene la sociedad actual con este tipo de entornos, genera la necesidad de estudiar cómo ofrecer un buen nivel de seguridad al usuario final y de la manera más eficiente posible. En el grupo de investigación GRITS, se han realizado varias investigaciones y se ha participado en varios proyectos que han aportado información suficiente para plantear un sistema que proteja de manera adecuada un entorno IoT. Del proyecto FINESCE [1], se extrajeron las implicaciones de seguridad y contramedidas a aplicar en entornos cloud, lugares donde se pueden encontrar aplicaciones IoT. De investigaciones realizadas sobre ecosistemas IoT y sistemas ICS (Industrial Control Systems), se vieron las tendencias y necesidades de ciberseguridad para este tipo de entornos. En el proyecto SPRINT 4.0 [2] quedaron al descubierto los retos de seguridad, las amenazas y la necesidad de implementar sistemas robustos en el sector de la Industria 4.0, así como la necesidad de aplicar un conjunto de mejores prácticas para un correcto diseño de un sistema seguro. De otras investigaciones y proyectos como SmartCampus [3], u otros centrados en hogares inteligentes, se aprendieron las diferencias entre las comunicaciones de entornos IoT en ámbitos 245 Salinero, Sánchez, Corral, 2021. distintos, y por tanto la necesidad de adaptación del sistema y su seguridad según el ámbito IoT. Toda esta investigación muestra que existen problemas y vulnerabilidades en todos los ámbitos principales de la actualidad, que existe un gran incremento en la conexión de dispositivos de naturaleza heterogénea a Internet (para procesos críticos de la sociedad y la industria), que las tecnologías emergentes suponen un cambio constante y nuevos vectores de ataque, y que los ataques cada vez son más sofisticados y difíciles de detectar. De manera que el proceso de securización de entornos IoT no es nada fácil. El problema no es sólo la inmensa cantidad de dispositivos conectados a la red, sino que también se debe tener en cuenta que existen dispositivos con sistemas o software de seguridad más avanzado y dispositivos simples, como bombillas o sensores, que no tienen detección de ataques y son más vulnerables. También es importante considerar la seguridad de la red y controlar los accesos, así como la seguridad de los proveedores de servicios que dan acceso a los dispositivos IoT de manera remota y proveedores cloud, que albergan las aplicaciones que el entorno IoT pueda utilizar para su gestión y mantenimiento. Además, el hecho de que haya múltiples fabricantes también dificulta el proceso. Cada fabricante diseña sus productos con sus propios protocolos de seguridad y protocolos de comunicación, lo que hace que sea muy complicado crear un estándar a seguir para aplicar seguridad [4][5]. A pesar de esta dificultad, gobiernos e instituciones, entre ellas Estados Unidos y la fundación OWASP, han comenzado a desarrollar proyectos para concienciar sobre estos riesgos. El proyecto llevado a cabo en Estados Unidos busca concienciar a los ciudadanos proponiendo unos pasos a seguir para prevenir posibles brechas de seguridad en los dispositivos. Por otro lado, la fundación OWASP [6] alerta sobre las 10 vulnerabilidades más comunes en entornos IoT de manera anual, y proporciona información y guías para diseñar, desarrollar configurar y testear dispositivos IoT. Se pueden encontrar múltiples soluciones a los diferentes retos de seguridad y problemas que plantea un entorno IoT, pero hasta hace pocos meses, ningún estándar aprobado. Actualmente, existen estándares como el europeo ETSI EN 303 645 [7] con el objetivo de proporcionar unas mejores prácticas a aplicar en entornos IoT. A continuación, se listan ejemplos de mejores prácticas o recomendaciones extraídas de [7] y [8] que, a pesar de parecer obvias, son importantes y buscan concienciar y ayudar a asegurar una red contra posibles ataques: Utilizar credenciales robustas y cambiarlas con frecuencia; no usar contraseñas por defecto. Cifrar los datos transmitidos a través de la red. Tener los dispositivos al día de actualizaciones de software/firmware o antivirus. Almacenar de forma segura los parámetros críticos de seguridad. Asegurar la integridad del software. Revisar los permisos de las aplicaciones (como las de los wearables y smartphones). Segmentar la red para tener mayor control de lo que sucede y aislar las zonas más sensibles. Asegurarse de que los datos personales sean seguros. Hacer que el sistema sea resiliente a los cortes. Utilizar Firewalls que obstaculicen el tráfico sospechoso y hagan seguimiento de eventos. Controlar el acceso a dispositivos. Hacer que los usuarios puedan eliminar sus datos fácilmente. Hacer que la instalación y mantenimiento de los dispositivos sea sencilla. Implementar métodos de análisis de riesgos para estimar la seguridad del entorno IoT. Tener medios para generar reports de las vulnerabilidades. Hacer auditorías de seguridad periódicamente para saber el estado de todos los dispositivos en términos de protección, control y medidas de seguridad. Aparte del estándar mencionado anteriormente, existe el NISTIR 8259 (del departamento de comercio de los estados unidos) [9] el cual se centra más en dar recomendaciones a los fabricantes para securizar sus dispositivos. El estándar ofrece seis consejos para mejorar la seguridad de los dispositivos, cuatro de ellos se deben realizar antes de lanzar el producto al mercado, y los dos restantes se aplican una vez ya se ha puesto el producto en venta. El trabajo presentado en este documento utiliza las recomendaciones de “Implementar métodos de análisis de riesgos” y “Hacer auditorías de seguridad periódicamente” y propone un sistema que calcula el riesgo de seguridad de un entorno IoT de manera automática. En la Sección II, se presenta el sistema y se definen los diferentes bloques funcionales que lo conforman. En la Sección III, se explica la implementación del primero de los bloques funcionales, “Inventario del sistema y nivel de seguridad intrínseco”, detallando su diseño, los cálculos, la implementación de código y los resultados obtenidos sobre el entorno de testeo. En la Sección IV se muestran las conclusiones del trabajo realizado y, finalmente, la Sección V detalla las líneas futuras que se han observado una vez realizada la implementación del primer bloque funcional del sistema. II. C ÁLCULO DE RIESGOS EN ENTORNOS I O T El objetivo del sistema que se propone es proporcionar el cálculo de riesgo de un entorno IoT. El sistema está compuesto por los bloques mostrados en la Fig. 1. Fig. 1. Sistema para el cálculo de riesgo de un entorno IoT 246 ActasdelasXVJornadas deIngenieríaTelemática (JITEL2021), ACoruña(España), 27‐29deoctubrede2021. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) Inventario del Sistema y Nivel de seguridad intrínseco. Inventario de dispositivos (HW), SW, tecnologías de comunicaciones utilizadas, etc. Proporciona un valor que dará una idea del nivel de seguridad intrínseco del sistema según las vulnerabilidades que tengan los dispositivos. Debe actualizarse automáticamente al añadir un dispositivo para permitir actualizar el cálculo del riesgo total. Batería de pruebas. Conjunto de tests realizados al entorno IoT para determinar la existencia de ciertas amenazas y poder afinar el cálculo de riesgo. Las vulnerabilidades encontradas en el bloque anterior alimentan este segundo bloque. Correlación de Logs. De dispositivos IoT, Gateway IoT, PCs, Smartphone/Tablet, dispositivos de red, dispositivos de seguridad de red, etc. Proporciona información del estado del sistema y permite detectar posibles amenazas y comprobarlas. Riesgo del sistema. Mediante la información recogida de los tres bloques anteriores, se genera un cálculo de riesgo del sistema. Finalmente, y como se aprecia en la Fig. 1, del bloque “Riesgo del sistema” salen Alertas y Acciones de Protección. Esta funcionalidad se propone como implementación a largo plazo con el objetivo de conseguir un sistema de predicción temprana, que sea capaz de aprender del entorno de manera automática y autoprotegerse, generando e instalando automáticamente reglas en los firewalls o ejecutando las acciones necesarias determinadas previamente con todo el proceso de análisis y cálculo del riesgo. Para poder hacer frente a este gran reto, es necesario ir resolviendo cada uno de los bloques por separado, convirtiendo el sistema en pequeños subsistemas que posteriormente se enlazarán. Y, además, será necesaria la automatización de las tareas para que todo el conjunto sea viable. Este documento detalla una primera aproximación de la implementación del bloque “Inventario del Sistema y Nivel de seguridad intrínseco”. III. I MPLEMENTACIÓN DEL BLOQUE “I NVENTARIO DEL S ISTEMA Y N IVEL DE S EGURIDAD I NTRÍNSECO ”. El objetivo de automatizar las tareas que se realizan en un análisis de riesgos es el de mejorar y optimizar estos procesos. Es obvio que este proceso automatizado siempre debe estar supervisado por una persona por si se da el caso de que el resultado no es del todo fiable o algún procedimiento no se ha hecho correctamente. Pero el hecho de que esté automatizado permite un ahorro significativo de los recursos de una empresa, y, además, consigue el resultado final con mucho menos tiempo que si se hiciera manualmente. La diferenciación que presenta este proyecto respecto a los análisis de riesgos convencionales, aparte de la automatización, es que se realiza sobre un entorno IoT y no sobre una red convencional. Hay que decir que el procedimiento a seguir es bastante parecido al de un análisis de riesgos convencional, pero se deben tener en cuenta ciertos parámetros y procedimientos que, por el simple hecho de ser un entorno IoT, pueden cambiar considerablemente. Un ejemplo de ello podría ser el número de dispositivos que forman la red, el cual se puede disparar considerablemente en un entorno IoT y, consecuentemente, también se puede disparar el volumen de tráfico que circula por la red. Además, se debe tener en cuenta que muchos de estos dispositivos pueden ser sensores o pequeños microprocesadores, los cuales no tendrán sistemas de seguridad avanzados como los que puede tener un ordenador o los servidores. A. Formato y estilo El trabajo se ha dividido en cuatro grandes bloques. Con el fin de automatizar estos cuatro bloques y que funcionen conjuntamente, se ha escrito un script en Python, el cual sólo hay que ejecutar y él solo se encargará de ejecutar los cuatro bloques y mostrar los resultados obtenidos. El resultado que se quiere conseguir mediante este script es obtener un valor cuantificado de la seguridad de la red. Este valor será mostrado en una escala del 1 al 10, donde 10 es el más crítico, y servirá para hacernos una idea del riesgo existente en nuestra red o entorno IoT. Posteriormente, este valor sería utilizado en el sistema presentado en la Fig. 1 para obtener el valor de riesgo del sistema. En la Fig. 2, se muestra un diagrama de bloques que representa el funcionamiento del script que implementa el bloque “Inventario del Sistema y Nivel de Seguridad Intrínseco”. Fig. 2. Diagrama de bloques del script Inventario de la red. El primer bloque consiste en hacer un escaneo de toda la red, con el fin de saber qué dispositivos están conectados y sus características. Además, a la vez que se descubren los dispositivos, también se escanean las posibles vulnerabilidades que puedan tener. Consultas a la API de vulnerabilidades. Ahora que ya tenemos la información imprescindible para cada dispositivo, toca buscar más información sobre cada vulnerabilidad, haciendo consultas a una API. Buscamos el vector asociado a cada vulnerabilidad con el que vamos a calcular el riesgo que presenta. Aplicar parámetros IoT. Este bloque es de los más importantes ya que es el que se encarga de tener en cuenta el hecho de que es una red IoT y no una convencional. Se modifica el vector obtenido en el bloque anterior, y se añaden ciertos parámetros que en una red convencional no se tendrían en cuenta, pero en un entorno IoT es imprescindible contar con ellos. 247 Salinero, Sánchez, Corral, 2021. Cálculo del rating final. Por último, una vez tenemos los vectores nuevos adaptados al entorno IoT, toca hacer los cálculos pertinentes para pasar de vector a un valor comprendido entre el 1 y el 10. De esta forma, después de realizar todos los cálculos para todas las vulnerabilidades, sólo se tendrá que hacer la media de estos valores y se obtendrá el Score o Rating final del entorno IoT. B. Inventario de la red El script implementado está pensado para ejecutarse en un entorno Linux, que contenga el software Nmap [10], ya que el script lo usa. En este trabajo se ha usado Kali Linux que ya lleva incorporadas todas las herramientas necesarias. Se usa Nmap porqué es una herramienta muy potente cuando se trata de escanear redes, además cuenta con la ventaja de que es Open Source. Gracias a que permite el uso de scripts, se pueden incrementar en gran medida las capacidades de esta herramienta, y podemos conseguir que, aparte de escanear los puertos abiertos de un dispositivo y averiguar su sistema operativo, con el uso de los scripts podemos llegar a escanear las vulnerabilidades. Para ello se ha hecho uso de un script llamado nmap-vulners [11]. Existen otras herramientas más potentes para detectar vulnerabilidades como viene siendo el caso de Nessus [12], pero el inconveniente que presenta es que sólo se puede usar con una interfaz de usuario y no por CLI (Command Line Interface), aparte de que es una herramienta de pago. Entonces, si el objetivo del proyecto es automatizar todo este proceso, una herramienta que se controla por CLI es mucho más fácil de scriptar que una herramienta basada en una GUI (Graphical User Interface). La instrucción utilizada para generar el inventario y encontrar las vulnerabilidades de todos los dispositivos es la siguiente: nmap −−script nmap−vulners −sV −O −oX output.xml 10.14.1.0/24 Como se puede ver anteriormente, la instrucción hace uso de cuatro modificadores diferentes. El primero es el -- script que indica al Nmap que se quiere utilizar el script nmap-vulners, el cual será el encargado de mostrarnos toda la información relacionada con las vulnerabilidades de cada dispositivo. El segundo modificador es el -sV que se utiliza para determinar la versión y el servicio de cada puerto. Por ejemplo, si el puerto se trata de un Apache o cualquier otro servicio, indicando en la mayoría de los casos su versión. El tercer modificador es el -O que sirve para habilitar el escaneo de Sistema Operativo, es decir, nos dirá si el dispositivo en cuestión se trata de un Windows, un Linux, etc. Finalmente, el cuarto modificador, el -oX, simplemente sirve para facilitar el tratamiento de los datos en el siguiente bloque. Lo que hace es parsear la salida del Nmap en formato XML y guarda esta salida en un fichero específico. Y para terminar tenemos que introducir la red dónde queremos lanzar el escaneo del Nmap. Para procesar la información que nos devuelve la instrucción en formato XML, primero se ha cogido el archivo y mediante el uso de una librería que permite convertir el formato XML del fichero a diccionario, se ha convertido el contenido a formato diccionario. Esta librería se llama xmltodict. Trabajar con información en formato diccionario en Python es mucho más sencillo que tratar de leer y acceder a los datos de un archivo XML. La salida del Nmap en formato XML ha dificultado el tratamiento de la información ya que, dependiendo del host no siempre se accede de la misma manera al CVE de una vulnerabilidad. Para almacenar toda la información obtenida mediante el escaneo, se han creado dos estructuras de datos en Python. El primer tipo es el que se ha llamado Host que, como se puede ver a continuación (Código 1), tiene tres campos: el de la dirección IP, el del sistema operativo y el de las vulnerabilidades. Código 1: Clase Host En cuanto a la segunda clase o estructura de datos (Código 2), ésta tiene la función de almacenar toda la información relacionada con las vulnerabilidades y que es necesaria para hacer los cálculos del valor entre 1 y 10 del peligro de la vulnerabilidad. A continuación, se puede ver la clase creada para almacenar las vulnerabilidades. Código 2: Clase Vuln En este bloque del script sólo se llenarán los dos primeros campos de las vulnerabilidades, ya que los demás se llenarán en los próximos bloques. Primero encontramos el campo del CVE, y después tenemos el Score que es el valor entre 1 y 10 de la vulnerabilidad. Una vez tenemos guardada toda la información necesaria, miramos vulnerabilidad por vulnerabilidad si hay alguna donde no haya guardado el CVE porque el escaneo no lo ha podido encontrar, y si se da el caso, borramos esa vulnerabilidad. C. Consultas a la API de vulnerabilidades Para obtener más información acerca de una vulnerabilidad, lo que se ha hecho ha sido utilizar una API que proporcionaba la organización NIST [13]. Con el fin de obtener información a través de la petición, sólo debe hacerse un simple GET. Por lo tanto, por cada petición se forma una URL, se hace un GET sobre ésta, y una vez nos hemos asegurado de que no ha devuelto ningún error mediante el Status Code, se transforma el resultado del GET en formato JSON. Un ejemplo de una petición es el siguiente: 248 ActasdelasXVJornadas deIngenieríaTelemática (JITEL2021), ACoruña(España), 27‐29deoctubrede2021. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) https://services.nvd.nist.gov/rest/json/cve/1.0/CVE-202015778 Para medir el nivel de peligrosidad que tiene una vulnerabilidad, se utiliza un sistema de puntuación que mide diferentes aspectos de ésta llamados métricas. La entidad responsable de llevar a cabo este sistema de puntuación se llama FIRST (Forum of Incident Response and Security Teams) [14]. Y el sistema que tienen para puntuar las vulnerabilidades se llama CVSS (Common Vulnerability Scoring System) [15]. En este proyecto se calculará el rating final y se aplicarán los parámetros IoT sobre la versión CVSS 2.0. Desafortunadamente, la API que se utiliza para obtener el vector de cada vulnerabilidad siempre devuelve el vector de esta versión y, en muy pocos casos, devuelve el vector de la versión CVSS 3.0. De todos modos, el código se ha adaptado para que, cambiando sólo un parámetro, pueda trabajar con la versión CVSS 3.0 (o su actualización 3.1). Porque si en un futuro esta API devuelve también los vectores de ambas versiones, el rating final se pueda obtener a partir de la versión CVSS 3.0 (o 3.1). D. Aplicar parámetros IoT Antes de aplicar los parámetros IoT, es necesario entender en qué consiste un vector CVSS. El CVSS se compone de tres grupos de métricas diferentes; la Base, la Temporal y la Medioambiental (siendo las dos últimas opcionales para el cálculo mientras que la primera siempre es obligatoria). Base Metric Group. Representa las características intrínsecas y fundamentales de una vulnerabilidad, que son constantes a lo largo del tiempo e independientes de los entornos y usuarios. En la Tabla 1 se muestra un resumen con las métricas del vector Base y sus correspondientes valores. Tabla 1: Métricas CVSS 2.0 Temporal Metric Group. Representa las características de una vulnerabilidad que cambia a lo largo del tiempo, pero que no depende de los usuarios. Environmental Metric Group. Representa las características de una vulnerabilidad que cambia dependiendo de los usuarios. Como el grupo temporal y medioambiental no son obligatorios para calcular el resultado final, no se han tenido en cuenta. Pero no sólo por este motivo, sino porque la API que se utiliza para obtener esta información, sólo devuelve los vectores del grupo Base. A continuación, se muestran las fórmulas para calcular el rating de una vulnerabilidad. Estas fórmulas están sacadas directamente de la web de FIRST. BaseScore  roundToOneDecimal󰇛󰇛󰇛0.6 ∗Impact󰇜󰇛0.4 ∗Exploitabilit y 󰇜1.5󰇜 ∗f 󰇛Impact󰇜󰇜 (1) Impact  10.41 ∗ 󰇛1  󰇛1  ConfImpact󰇜 ∗ 󰇛1 IntegImpact󰇜∗󰇛1  AvailImpact󰇜󰇜 (2) Exploitabilit y 20 ∗ AccessVector ∗AccessComplexit y ∗Authentication (3) f 󰇛impact󰇜 0 si Impact  0, sino f 󰇛impact󰇜1.176 (4) Para hacer los cálculos con el CVSS 3.1, nos basamos en la Tabla 2, la cual muestra diferencias con la tabla de la versión CVSS 2.0 (Tabla 1). Tabla 2: Métricas CVSS 3.1 249 Salinero, Sánchez, Corral, 2021. Las fórmulas que se usan para calcular el rating de una vulnerabilidad en la versión CVSS 3.0 son las siguientes: Si Impac t  0 ,B aseScore  0 (5) Si Scope no cambia (Unchanged): BaseScore  RoundToOneDecimal󰇛Minim󰇟󰇛Impact Exploitabilit y 󰇜,10󰇠 (6) Si cambia: BaseScore RoundToOneDecimal󰇛Minim󰇟1.08 ∗󰇛ImpactExploitabilit y 󰇜,10󰇠 (7) Para calcular la Exploitability: Exploitabilit y 8.22 ∗ AttackVector ∗AttackComplexit y ∗ PrivilegesRequired ∗UserInteraction (8) Finalmente, para el Impact, si Scope no cambia (Unchanged): Impact 6.42 ∗ISS (9) Si cambia: Impact 7.52 ∗ 󰇛ISS0.029󰇜3.25 ∗󰇛ISS  0.02󰇜 dónde ISS 1󰇟󰇛1Confidentiality󰇜∗󰇛1 Integrit y 󰇜∗󰇛1 Availabilit y 󰇜󰇠 (10) Para adaptar estos cálculos a un entorno IoT, se utiliza la información de [16] dónde se explica qué cambios son necesarios para que el resultado esté adaptado a un entorno IoT. Se puede integrar muy fácilmente al proyecto ya que sólo se modifican pesos de las métricas y se añade un parámetro llamado Human Safety Index. A continuación, se explican con detalle estos cambios. Cambio en los valores del vector AV. Se propone añadir dos valores nuevos enfocados a un entorno IoT, es decir, se mantendrá el valor L y se añadirá el valor Li con una métrica de 0.6. Y para el valor P, se añadirá el valor Pi con una métrica de 0.44. Estas métricas son ligeramente más altas ya que es más fácil acceder físicamente a los dispositivos IoT. Cambio en los valores del vector AC. En este caso se añade un valor nuevo M con una métrica de 0.44 y de la misma manera que en el caso anterior, aparte del valor H, se añade un valor Hi con una métrica de 0.2. Como se requiere más complejidad para llevar a cabo un ataque a los dispositivos IoT, se les asigna unas métricas ligeramente inferiores en comparación a las métricas definidas para dispositivos convencionales. Human Safety Index. Se añade al grupo Base y Environmental y mide el nivel de seguridad para los humanos, ya que si, por ejemplo, tenemos maquinaria conectada a Internet en una fábrica, un ataque a estas máquinas podría provocar daños humanos que se deben tener en cuenta de cara al resultado final. Las fórmulas siguen siendo las mismas que antes, pero con los nuevos valores de las métricas y añadiendo el Human Safety Index al cálculo del Impact. Es importante remarcar que el valor del Human Safety Index en caso de ser 0 no afecta a los cálculos, ya que como se puede ver en la siguiente fórmula, el valor sólo está para darle más precisión a los cálculos en caso de ser diferente a 0. ISS 1󰇟󰇛1Confidentialit y 󰇜∗󰇛1 Integrit y 󰇜 ∗󰇛1Availabilit y 󰇜∗󰇛1 HSI󰇜󰇠 (11) Para que todo el proceso se entienda mejor, se muestra el cálculo para un entorno convencional y un entorno IoT teniendo en cuenta una misma vulnerabilidad. Se utiliza como ejemplo la vulnerabilidad CVE-202015778. Empezamos listando el vector en un entorno convencional y en un entorno IoT. Vector: AV:N/AC:M/Au:N/C:P/I:P/A:P Vector IoT: AV:N/AC:Mi/Au:N/C:P/I:P/A:P/Hi:Ni El cálculo en un entorno convencional sería: Impact  10.41 ∗1  󰇛10.275󰇜∗󰇛1 0.275󰇜∗󰇛10.275󰇜6.44 (12) Exploitabilit y  20∗1 ∗ 0.61 ∗ 0.7048.58 (13) f 󰇛impact󰇜 0 si Impact  0, sino f 󰇛impact󰇜 1.176 (14) BaseScore  roundToOneDecimal󰇡󰇛0.6 ∗6.44󰇜󰇛0.4∗8.58󰇜1.5 ∗1.176󰇢 𝟔.𝟖 (15) En cambio, para un entorno IoT tendríamos: Impact  10.41 ∗1  󰇛10.275󰇜 ∗󰇛10.275󰇜∗󰇛10.275󰇜 ∗󰇛10󰇜 6.44 (16) Exploitabilit y  20∗0.85 ∗ 0.44 ∗0.704 5.27 (17) f 󰇛impact󰇜 0 si Impact  0, sino f 󰇛impact󰇜 1.176 (18) 250 ActasdelasXVJornadas deIngenieríaTelemática (JITEL2021), ACoruña(España), 27‐29deoctubrede2021. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) BaseScore  roundToOneDecimal󰇡󰇛0.6 ∗6.44󰇜󰇛0.4∗5.27󰇜1.5 ∗1.176󰇢 𝟓.𝟐 (19) E. Cálculo del rating final Para calcular el rating final de la red, se hace la media aritmética de los scores de todas las vulnerabilidades de todos los dispositivos. Además, el script hace la media tanto en un entorno IoT como en uno convencional para poder comparar los resultados. La fórmula utilizada en este caso es la siguiente: ScoreRoundToOneDecimal󰇛  𝑛𝑢𝑚𝑉𝑢𝑙𝑛  𝑖   󰇜 (20) Este método no es del todo preciso ya que no todos los dispositivos de la red tienen la misma importancia. Por ejemplo, no es lo mismo una vulnerabilidad en el router que está entre Internet y la red interna, que una vulnerabilidad en una bombilla inteligente. En este proyecto se ha hecho una aproximación de este riesgo final, ya que no se ha implementado ningún sistema de pesos que pueda dar más importancia a ciertas vulnerabilidades dependiendo de en qué dispositivo se encuentren. F. Resultados El script se ha lanzado en una red de laboratorio disponible en la propia universidad con diferentes dispositivos los cuales tienen varias vulnerabilidades. Los resultados se resumen en la Tabla 3 y Tabla 4. Tabla 3: Resultados obtenidos por host Tabla 4: Resultados totales Para tener una representación más visual, se han generado unas gráficas del resultado obtenido. En la Fig. 3 se muestra la comparativa del valor medio del score tanto en un entorno convencional como en uno IoT para las diferentes vulnerabilidades de cada host. Se puede apreciar que, exceptuando el host 9, 10 y 14, el script ha detectado vulnerabilidades. En color azul el score medio que tendrían las vulnerabilidades si el host estuviera en un entorno convencional, y en color verde si estuviera en un entorno IoT. Fig. 3. Comparativa de las vulnerabilidades en ambos entornos La siguiente gráfica, Fig. 4, muestra la media del score de todas las vulnerabilidades de todos los hosts, es decir, a partir del valor medio de cada host se ha obtenido un score final, el cual en color azul sería de un entorno convencional y en color verde de un entorno IoT. Fig. 4. Score final de la red Además de estas gráficas, el propio script genera un report con información más detallada de cada vulnerabilidad y de cada dispositivo. IV. C ONCLUSIONES Después de haber desarrollado la automatización de un análisis de riesgos en un entorno IoT, se ha visto la utilidad de los métodos que se utilizan para calcular la severidad de 251 Salinero, Sánchez, Corral, 2021. las vulnerabilidades con relación a otras, ya que gracias a estos cálculos uno se puede hacer una idea del riesgo actual de su red o dispositivo. En este proyecto se acabó utilizando la metodología CVSS ya que es la más conocida y estandarizada actualmente. Los resultados han sorprendido un poco, ya que el resultado obtenido de la misma vulnerabilidad en un entorno IoT, generalmente ha sido más bajo que el resultado obtenido en una red convencional. Esto se debe a que después de aplicar los parámetros específicos para entornos IoT, se obtenía un vector mucho más preciso en cuanto a la severidad de la vulnerabilidad, haciendo que, con este aumento de precisión, el resultado variará respecto al valor inicial. Estos parámetros son el Attack Vector (AV), el Attack Complexity (AC) y el Human Safety Index. Se han modificado específicamente para satisfacer requisitos del IoT que en el CVSS original no se tienen en cuenta. Al analizar los resultados obtenidos vemos que tienen su lógica. Esto se debe a cómo se han aplicado los pesos de cada vector, es decir, el hecho de haberlos aplicado de manera estática, hace que se traten todas las vulnerabilidades por igual, por lo tanto, no se diferencia entre si una vulnerabilidad puede afectar más por el simple hecho de ser un entorno IoT o no. Todas las vulnerabilidades se comportan diferente, y sobre todo si el entorno cambia, de modo que aplicar valores estáticos no es del todo preciso. Según la información extraída de [16], al valor de Human Safety como no tiene ninguna referencia previa en el vector original y es un campo que se añade nuevo, se le asigna el valor de 0 para todas las vulnerabilidades (para que no afecte al cálculo final). En cambio, al variar el valor del AV y AC, vemos como el resultado final es distinto, haciendo que sea más bajo. V. LÍNEAS DE FUTURO A continuación, se listarán las líneas de futuro o mejoras que se pueden aplicar a esta primera aproximación del bloque descrito. Usar CVSS 3.0 en vez de CVSS 2.0. Asignar los pesos de forma dinámica. Realizar la asignación de más o menos peso dependiendo de la vulnerabilidad. Asignar el Human Safety Index de manera dinámica, asignando un valor distinto dependiendo del tipo de dispositivo y su criticidad. Para ello se podría generar una tabla de valores dónde se clasificarían los dispositivos IoT por tipo, funcionalidad o criticidad. Calcular la media final teniendo en cuenta la criticidad de un dispositivo en una red, por ejemplo, dar más importancia a las vulnerabilidades de un router que las vulnerabilidades de un sensor cualquiera. Para terminar, se podría generar un informe con más detalles de cada vulnerabilidad y dispositivo. Por otro lado, recordar que los próximos pasos deben contemplar la implementación de los otros bloques que componen el sistema descrito en la Fig. 1. REFERENCIAS [1] Sánchez, J., Corral, G., de Pozuelo, R. M., & Zaballos, A. (2016). Security issues and threats that may affect the hybrid cloud of FINESCE. Netw. Protoc. Algorithms, 8(1), 26-57. [2] SPRINT 4.0 Project, 2020, [Online] “https://www.sprint40.eu/ [3] Zaballos, A., Briones, A., Massa, A., Centelles, P., & Caballero, V. (2020). A smart campus’ digital twin for sustainable comfort monitoring. Sustainability, 12(21), 9196. [4] PublicaTIC, “Controles y auditoría del IoO,” 2019, [Online] https://blogs.deusto.es/master-informatica/controles-y-auditoriadel-iot/ [5] INCIBE, “La importancia de la seguridad en iot. principales amenazas,” 2019, [Online] https://www.incibecert.es/blog/importancia-seguridad-iot-principales-amenazas [6] OWASP, “Top 10 web application security risks,” 2019, [Online] https://owasp.org/www-project-top-ten/ [7] ETSI, “ETSI EN 303 645: Cyber Security for Cunsomer Internet of Things: Baseline Requierements,” 2020, [Online] https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.0 1.01_60/en_303645v020101p.pdf [8] C. Otero, “Cómo configurar con más seguridad tus dispositivos IoT y red casera,” 2019, [Online] https://as.com/meristation/2019/09/06/betech/1567723080_55008 7.html [9] NIST, “NISTIR 8259: Foundational Cybersecurity Activities for IoT Device Manufacturers” 2021, [Online] https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259.pdf [10] G. Lyon, “Nmap.org,” 2020, [Online] https://insecure.org/fyodor/ [11] TOKYONEON, “Easily detect cves with nmap scripts,” 2019, [Online] https://null-byte.wonderhowto.com/how-to/ easilydetect-cves-with-nmap-scripts-0181925/ [12] Tenable, “Nessus es la solución n.° 1 para evaluaciones de vulnerabilidades,” 2020, [Online] https://es-la.tenable.com/ products/Nessus [13] B. Byers and H. Owen, “Automation support for cve retrieval,” 2019, [Online] https://csrc.nist.gov/CSRC/media/Projects/ National-VulnerabilityDatabase/documents/web%20service%20documentation/ Automation%20Support%20for%20CVE%20Retrieval.pdf [14] FIRST, “First is the global forum of incident response and security teams,” 2020, [Online] https://www.first.org/ [15] FIRST., “Common vulnerability scoring system version 3.1: Specification document,” 2019, [Online] https://www.first.org/cvss/specification-document [16] A. Ur-Rehman, I. Gondal, J. Kamruzzaman, and A. Jolfaei, “Vulnerability modelling for hybrid it systems.” in ICIT, 2019, pp. 1186–1191. 252