Advisory. Una herramienta para identificar los riesgos de seguridad

Advisory. Una herramienta para identificar los riesgos de seguridad Antonio Germán Márquez Trujillo1[0000−0002−7282−3386], Ángel Jesús Varela-Vaca1[0000−0001−9953−6005], and José A. Galindo1[0000−0001−9293−9784] Universidad de Sevilla, Spain, {amtrujillo,ajvarela,jagalindo}@us.es Resumen En el desarrollo de un proyecto software actual es frecuente delegar parte de la funcionalidad en librerías o dependencias de terceros. Este uso extensivo de dependencias puede introducir problemas de seguridad en el software que estamos desarrollando y que cada vez afecta a más proyectos software dada la necesidad de conocer cada una de las vulnerabilidades de estas dependencias. Para aliviar este problema, presentamos Advisory , una herramienta que aplica técnicas de análisis automático de la variabilidad al análisis de seguridad de proyectos software. Keywords: Ciberseguridad ·Variabilidad ·Análisis automático ·Dependencia ·Impacto ·Proyecto Software ·Vulnerabilidad ·CVE. 1. Introducción y motivación Los sistemas de alta variabilidad (VIS) son aquellos sistemas que deben gestionar y lidiar con un gran número de dependencias [1][4] para funcionar de manera correcta. En la literatura encontramos proyectos con centenares de dependencias y opciones de configuración, como por ejemplo el Kernel de Linux con más de 1060 configuraciones distintas. Dada la dificultad del análisis de dependencias de manera manual, la comunidad de líneas de productos propuso el análisis automático de la variabilidad en los VIS, por ejemplo con técnicas como los AAFM (Automated Analysis of Feature Models) [3]. Los AAFM habilitan el razonamiento sobre los VIS mediante el uso de sistemas de inteligencia artificial o algoritmos ad-hoc, para extraer información relevante del conjunto de dependencias descritas en un VIS. Unido al análisis de variabilidad, han surgido aproximaciones que intentan analizar las vulnerabilidades de una línea de productos software para optimizar el conjunto de pruebas a realizar [8]. En la actualidad, cada día se reportan múltiples vulnerabilidades en cada una de esas dependencias [6] que deben ser conocidas por los desarrolladores. Por ejemplo como en el caso de la reciente vulnerabilidad CVE-2021-442281 detectada en Log4j (https://logging.apache.org/log4j/2.x/), que ha afectado al menos a 186,352 proyectos en el ecosistema Java [5] debido a la complejidad del 1https://nvd.nist.gov/vuln/detail/CVE-2021-44228 2 G. Márquez et al. análisis de sus dependencias. Esta cantidad de dependencias y librerías dificulta que los desarrolladores sean conscientes de qué vulnerabilidades afectan al software que están desarrollando y cómo tomar medidas para paliar los riesgos de seguridad. En este artículo presentamos Advisory , una solución que permite: Modelar las dependencias, es decir, el espacio de configuraciones de un proyecto software, y atribuir ese espacio de configuración con información de seguridad relacionada a sus vulnerabilidades. Habilitar técnicas y operaciones que permitan razonar sobre el espacio de dependencias de un proyecto software teniendo en cuenta la información de seguridad relacionada con las vulnerabilidades. Actualmente Advisory se centra en análisis de dependencias de proyectos existentes dentro del ecosistema Python. Algunas pruebas preliminares han detectado más vulnerabilidades que las alternativas existentes en el mercado como Snyk, OWASP Dependancy Check o DependantBot de Github. 2. Advisory : Una herramienta basada en análisis automático para la detección de vulnerabilidades Advisory sigue el proceso de la Figura 1 para llevar a cabo lo descrito. Primero, la aplicación se conecta a un repositorio de software donde están disponibles los ficheros de descripción de dependencias. Después analiza dichos ficheros para generar un modelo de variabilidad con forma de grafo. Posteriormente este modelo es atribuido con información de seguridad desde distintas bases de datos de vulnerabilidades. Con esta información se aplica una transformación a un solver SMT mediante el cual se realizan distintas operaciones de análisis que nos dan información relevante sobre la seguridad del repositorio que está siendo analizado. SMT Solver 1. Extraer Repositorio del código fuente Analizar el repositorio Generar grafo de dependencias Extraer vulnerabilidades 2. Atribuir Repositorio de vulnerabilidades 3. Transformar Modelo SMT Transformar a modelo formal Modelo Válido Número de configuraciones Filtrar las configuraciones Analizar resultados 4. Operaciones Grafo de dependencias Automatic task Manual task And-gateway Or-gateway Minimizar impacto Maximizar impacto Figura 1. El proceso de identificación de vulnerabilidades de Advisory Actualmente, las operaciones que soporta Advisory , son las siguientes: Advisory. Una herramienta para identificar los riesgos de seguridad 3 Modelo válido: Esta operación verifica que las dependencias dentro de un repositorio son satisfacibles, es decir, si hay alguna configuración que satisfaga tanto los requisitos de dependencias junto con los requisitos de seguridad (p.ej., no usar Log4j). Número de configuraciones: Esta operación devuelve el número de configuraciones posibles descritas en el grafo de dependencias. Esta operación está enfocada a controlar la explosión de la variabilidad que pueda sufrir el desarrollo del software. Filtro de configuraciones: Esta operación, nos permite establecer unos umbrales máximos y mínimos de seguridad que estamos dispuestos a asumir en el proyecto en desarrollo para filtrar en dicho rango. Priorizar por impacto: Para priorizar, debemos definir la función de agregación deseada para calcular el impacto total en la seguridad de la herramienta. Actualmente soportamos todas las que están implementadas en el solver Z3 [7]. Esta operación se puede subdividir en 1) Maximizar: Esta operación nos permite identificar aquellas configuraciones más vulnerables para que, como desarrolladores, podamos tomar medidas e intentar corregirlas o mitigarlas; y 2)Minimizar: Esta operación nos permite identificar aquellas configuraciones que presentan menos vulnerabilidades. Puede ser una operación interesante cuando deseamos desplegar una versión lo más segura posible de un proyecto. 3. Implementación Actualmente la herramienta está implementada en Python como una extensión del framework de análisis automático Flama, basado en la propuesta de Galindo et al. [2]. Dicho marco de desarrollo establece adoptar un paradigma inspirado en el desarrollo guiado por modelos. Dentro de dicho marco, para adaptar nuestro prototipo hemos desarrollado los siguientes plugins. Security-Dependency-Graph metamodel: Este metamodelo implementa un grafo, el cual cuenta con dependencias como vértices, relaciones como aristas y restricciones que se aplican a las mismas, del tipo las versiones que puede tener una dependencia. Implementa además un método que atribuye las dependencias con información relativa a la seguridad como pueden ser su fecha de última release o sus CVEs. Este método extrae las vulnerabilidades para cada dependencia usando como clave la dependencia con cada versión disponible de la misma. El Common Vulnerabilities and Exposures (CVE) de Mitre (http://cve.mitre.org/) es el estándar de facto usado para representar la información de las vulnerabilidades, y es usada en casi todas las bases de datos como la de National Vulnerability Database (NVD) de NIST (http://nvd.nist.gov). Este metamodelo contiene las transformaciones de texto a modelo, entre los ficheros de dependencias y el grafo. SMT metamodel: Este metamodelo implementa las funcionalidad necesaria para razonar sobre el grafo de dependencias usando un solver SMT. Asimismo, este metamodelo implementa las operaciones presentadas en la sección 2, además de la transformación entre el metamodelo Security-Dependency- Graph y este mismo. 4 G. Márquez et al. 4. Conclusiones En este trabajo presentamos una herramienta fruto de la relación entre variabilidad y seguridad que nos permite identificar vulnerabilidades que escapan normalmente del conocimiento de los desarrolladores de un proyecto software. Durante el desarrollo de la misma, hemos aprendido las siguientes lecciones: Vínculos entre variabilidad y seguridad. Podemos analizar la variabilidad que se encuentra en las dependencias de los proyectos software y extraer información relativa a su seguridad; Imposibilidad de analizar el espacio completo de configuraciones. El análisis de espacio de configuraciones muy elevado hace imposible para un resolutor analizar todas las posibles combinaciones válidas de dependencias, una forma de paliar esto es añadir un limite al número de configuraciones a devolver por las operaciones o configurar el uso un rango de versiones de las permitidas por las restricciones por cada dependencia, reduciendo así la variabilidad. Material y agradecimientos Este trabajo ha sido financiado por los proyectos METAMORFOSIS (US-1381375), COPERNICA (P20_01224) y AETHER-US (PID2020-112540RB-C44/AEI/10.13039/501100011033) Video demostrativo de la herramienta, se puede consultar en https://www.youtube.com/watch?v=bFzUYni7_qA Referencias 1. José Angel Galindo Duarte. Evolution, testing and configuration of variability systems intensive. PhD thesis, University of Rennes 1, France, 2015. 2. José A. Galindo and David Benavides. A python framework for the automated analysis of feature models: A first step to integrate community efforts. In SPLC ’20: 24th ACM International Systems and Software Product Line Conference, Montreal, Quebec, Canada, October 19-23, 2020, Volume B, pages 52–55. ACM, 2020. 3. José A Galindo, David Benavides, Pablo Trinidad, Antonio-Manuel Gutiérrez- Fernández, and Antonio Ruiz-Cortés. Automated analysis of feature models: Quo vadis? Computing, 101(5):387–433, 2019. 4. José Angel Galindo, David Benavides, and Sergio Segura. Debian packages repositories as software product line models. towards automated analysis. In ACOTA, Belgium, September, 2010, volume 688, pages 29–34. CEUR-WS.org, 2010. 5. Wenhui Hu, Yu Wang, Xueyang Liu, Jinan Sun, Qing Gao, and Yu Huang. Open source software vulnerability propagation analysis algorithm based on knowledge graph. In 2019 IEEE SmartCloud, pages 121–127, 2019. 6. Jeffrey R. Jones. Estimating software vulnerabilities. IEEE Security Privacy, 5(4):28–32, 2007. 7. Leonardo de Moura and Nikolaj Bjørner. Z3: An efficient smt solver. In International conference on Tools and Algorithms for the Construction and Analysis of Systems, pages 337–340. Springer, 2008. 8. Ángel Jesús Varela-Vaca, Rafael M. Gasca, Jose Antonio Carmona-Fombella, and María Teresa Gómez López. AMADEUS: towards the automated security testing. In 24th ACM SPLC ’20, Montreal, Quebec, Canada, October 19-23, 2020, Volume A, pages 11:1–11:12. ACM, 2020. Advisory. Una herramienta para identificar los riesgos de seguridad 5 Apéndice A: Tiempo planeado para la presentación de la herramienta 5min Presentación del problema y alcance de la herramienta. 10min Demostración de la aplicación. 5min Conclusiones del trabajo.