Herramientas para análisis estático de seguridad: estado del arte

Presentación del tema: "Herramientas para análisis estático de seguridad: estado del arte"— Transcripción de la presentación:

1 Herramientas para análisis estático de seguridad: estado del arte
III OWASP Spain Charter Meeting

2 Resumen: En esta ponencia se examina la situación actual de la clase de herramientas de análisis estático de seguridad, que sin ejecutar el código del software, tratan de identificar las vulnerabilidades explotables en las aplicaciones y servicios web. Se determina el estado del arte de las herramientas académicas y de código abierto, la oferta de OWASP en este dominio, los límites de esta tecnología, y se proponen algunas ideas para mejorar la difusión y la cobertura desde OWASP. Ponente: Luis Rodríguez Responsable laboratorio SW de ALS. CISSP.

3 Índice ¿Por qué las aplicaciones web son como anchas autopistas para los malos? Análisis estático de seguridad del SW: cómo funciona Ventajas (e inconvenientes) del análisis estático Técnicas aplicables para el análisis estático de seguridad Estado actual de las herramientas de código abierto. Limitaciones. Integración, en el ciclo de vida SW, de las revisiones de seguridad en el código. Conclusiones. ¿Qué más puede hacerse desde OWASP en este ámbito?

4 Herramientas para análisis estático de seguridad: estado del arte
¿Por qué las aplicaciones son como anchas autopistas para los malos?

5 Todo efecto tiene una(s) causa(s)
“I'm glad software developers don't build cars” -- Eoin Keary, líder del proyecto OWASP Code Review Guide Modelo económico del software que no incorpora el riesgo o la “seguridad” del producto Falta de recursos (tiempo, herramientas, personal…) Falta de mercado (de vulnerabilidades, de seguros) Falta de conocimientos elementales de seguridad en los equipos de desarrollo (y pruebas) de software Principios de diseño de seguridad Desconocimiento de cómo abusan los malos del protocolo HTTP ¿Validación de entradas? Ein? Cómo operan las inyecciones, XSS/CSRF, Path traversal… Modelos de ciclo de vida / proceso de desarrollo SW que ignoran la seguridad

6 A2. Control de accesos roto
OWASP top-10 A1. Entrada no validada A2. Control de accesos roto A3. Autenticación/Gestión de sesiones rotos A4. XSS, Cross Site Scripting (y su variante CSRF) A5. BO, desbordamiento de búfer A6. Inyección (SQL, comandos…) A7. Tratamiento de errores incorrecto A8. Almacenamiento inseguro / mal uso del criptografía A9. Denegación de servicio A10. Gestión de configuración insegura Nota: Muchas son las críticas a la forma en la que OWASP definió este mapa de problemas de aplicaciones web: ¿Son vulnerabilidades, ataques o malas prácticas (de codificación)? Cómo diferenciar los diferentes elementos?: A1-A3 son vulnerabilidades, A4-A6 son ataques (contra A1 y otras), A9 es una condición/efecto que se produce ante diferentes ataques, etc. Al ser humano le encantan las listas: Basta poner en google “Top 10 security”… Otras listas/taxonomías muy difundidas sería: SANS Top 20 ( Los “19 pecados capitales” (definidos en el libro del mismo nombre de Howard, LeBlanc y Viega) La enumeración de De todos estos, los tres más comunes hoy día son (SANS Top-20 actual): PHP Remote File Include (allow_url_fopen + permitir a los usuarios control sobre nombre de ficheros + SMB file wrappers) Inyección SQL (muy general, y fácil de evitar completamente) XSS / CSRF (muy difícil de evitar al 100%)

7 Algunas concepciones erróneas
“Programación defensiva es lo que necesito” = Codificar con la idea de que los errores son inevitables y, antes o después, algo irá mal y provocará condiciones inesperadas. Hay que codficar el software “de forma que pueda afrontar pequeños desastres” No es una idea dirigida a producir software seguro, sino código que facilite la detección de defectos no debidos al uso “inesperado” (malicioso) del software. “Funciones de seguridad = funciones seguras” Para que un programa sea seguro, no basta con las funciones de seguridad implantadas. La seguridad de software es más que añadir funciones de seguridad, como la autenticación o el control de accesos. “El proceso de pruebas y QA incluye la seguridad, ¿no?” Debería, pero no… Pruebas / QA != pruebas de seguridad El software fiable hace lo que se supone que debe hacer; el software seguro, hace siempre lo que se supone que debe hacer, y nada más. Esto es programación defensiva: void printMsg(FILE* file, char* msg) { if (file == NULL) logError(“Fichero NULL"); else if (msg == NULL) logError(“Mensaje NULL"); else fprintf(file, msg); } Pero el código presenta una vulnerabilidad (trivial) de cadena de formato, si msg no está debidamente validado (un atacante puede conseguir suministrar, por ejemplo, AAA1_%08x.%08x.%08x.%08x.%08x.%n, lo cual puede dar lugar a una condición de desboradamiento de búfer). Para que un programa sea seguro, todas las prociones del mismo deben serlo, no sólo las partes que se centran en las funciones de seguridad. De hecho, y casi siempre, los fallos de seguridad no están ligados a funciones de seguridad (aunque, por supuesto, una función de seguridad mal diseñada o implantada puede comprometer la seguridad). Un ejemplo: numerosas vulnerabilidades explotables de tipo “desbordamiento de búfer” en librerías de procesamiento de imágenes (zLib, GDI, etc.) han podido comprometer código de aplicación que hacía uso de estas librerías, pudiendo desembocar desde la denegación de servicio hasta la toma total de control del sistema hospedador. En cuanto a si QA debería incluir la seguridad del sofware, lo cierto es que los departamentos QA tienen un enfoque mucho más centrado en la fiabilidad y la corrección funcional (ausencia de defectos funcionales). Las pruebas (unitarias, funcionales, de carga…) intentan verificar si el software cumple con los requisitos establecidos. Algunas pruebas pueden (¡ deberían !) intentar verificar si el software es correcto funcionalmente hablando, identificando defectos que afecten a la mayoría de los usuarios en la mayoría de los usos. Este enfoque no se dirige a identificar usos inesperados que pueden aplicarse al software para conseguir un comportamiento inesperado (“ataque malicioso”). Los problemas de seguridad son “funcionalidad inesperada” que un atacante puede aprovechar, y esa funcionalidad inesperada puede ser compatible con los requisitos funcionales.

8 Método, a lo largo del ciclo de vida
Metodología de seguridad en el ciclo de vida del software Captura de Requisitos y Análisis Arquitectura Diseño Plan de Pruebas Codificación Ensamblaje Paso a producción Soporte Manteni- miento Casos de abuso de seguridad Revisión externa Modelado de amenazas Pruebas de seguridad Análisis estático dinámico Operación Auditoría (Certificación) Prueba de penetración actividades pilar 1: pilar 2: Formación y concienciación (de equipos de desarrollo y usuarios finales) Gestión de Riesgos Es esencial entender que la seguridad en el software sólo podrá alcanzarse si: Los desarrolladores están formados y concienciados en seguridad del software, y conocen “los 7 reinos perniciosos” (u otras taxonomías equivalentes de problemas de seguridad a nivel de software). Hay una gestión de riesgos como elemento para ordenar la toma de contramedidas y priorizar actuaciones. Se aplican un conjunto complementario de técnicas que cubran adecuadamente el espectro de amenazas y permitan reducir de forma efectiva los riesgos hasta los valores asumibles por la organización usuaria. Las técnicas directamente relacionadas con la seguridad del software son diversas pero bien conocidas: Establecer requisitos de seguridad (como parte de los requisitos de sistema). En ocasiones los requisitos de seguridad forman parte de los requisitos funcionales (particularmente en lo que atañe a lo que puede hacer o no un usuario), pero no deben olvidarse los otros “servicios” de seguridad, además del control de accesos. Modelar las amenazas según el tipo de aplicación, los perfiles de atacante, los recursos involucrados, el entorno donde se desplegará la aplicación, etc. Definir casos de abuso (un caso de abuso es una suerte de caso de uso, donde se refleja cómo un atacante ínteractuaría con el sistema y cómo respondería el sistema a ese abuso). Definir una arquitectura de seguridad (como parte de la arquitectura del sistema) donde se reflejen cómo se van a materializar las funciones y propiedades de seguridad identificadas. Pruebas de seguridad (verificaciones a realizar por el equipo de desarrollo, por el equipo de pruebas, etc. a partir de los casos de abuso establecidos, y de los requisitos de seguridad) Análisis estático: Determinar propiedades del sistema software (e.g. vulnerabilidades potenciales introducidas por defectos en la codificación) sin ejecutarlo. Del tipo conocido como “prueba de caja blanca” (las revisiones de seguridad del código pueden usar esta técnica en mayor o menor medida). Análisis dinámico: Idem, pero con el sistema software en ejecución. Del tipo conocido como “prueba de caja negra”, normalmente se diferencia de la prueba de penetración en que en este caso se exploran, con apoyo de herramienta, todo un abanico de vulnerabilidades estándar conocidas que aparecen en los sistemas software, en vez de limitarse a comprobar si resulta factible explotar una vulnerabilidad. Certificación de seguridad: Una organización independiente al equipo de desarrollo analiza desde distintos puntos de vista el sistema software, para determinar si el riesgo actual está dentro de lo asumible. Operación de seguridad: Configuración de la seguridad del sistema software en su entorno, y monitorización de posibles incidentes que afecten al software o a sus usuarios a través del software. (*) Adaptado de Software Security: Building Security In. Gary McGraw. Addison Wesley, 2006

9 Ataques y contramedidas
casos de abuso casos de prueba de seguridad validación (positiva) de entradas filtrado de salidas análisis estático + revisión de código mínimo privilegio criptografía (bien implantada) auditoría de seguridad prueba de penetración inyección SQL inyección de código en cliente web (XSS) ataques a la autenticación secuestro de sesiones captura no autorizada de información / configuración desbordamiento de buffer denegación de servicio división HTTP navegación por el sistema de ficheros SQL parametrizado ‘captcha’ (reto anti-robot) autenticación robusta tickets de autenticación cifrado gestión de config. canonicalización no derivar desde entradas tipos de ataque controles genéricos específicos Controles de infraestructura APIs seguros protectores de pila limitadores de tráfico no mezclar código/datos ‘desactivar’ la salida Algunos controles pueden ser de una trivialidad pasmosa, como redefinir mediante macros de preprocesador las funciones C “prohibidas”: #define strcpy unsafe_strcpy De manera que el compilador genere errores cuando un programador inadvertidamente las use (p.ej. en vez de la alternativa recomendada, strncpy())

10 OWASP Community Platform
OWASP Foundation (finances, legal, infrastructure, communications) OWASP Community Platform (wiki, forums, mailing lists, leaders) Projects (tools and documentation) Chapters AppSec Conferences Core Application Security Knowledge Base Acquiring and Building Secure Applications Verifying Application Security Managing Application Security Application Security Tools AppSec Education and CBT Research to Secure New Technologies Guide to Building Secure Web Applications and Web Services Guide to Application Security Testing and Guide to Application Security Code Review Tools for Scanning, Testing, Simulating, and Reporting Web Application Security Issues Web Based Learning Environment and Education Project Guidance and Tools for Measuring and Managing Application Security Research Projects on Securing New Technologies (Web Services & Ajax) (*) Tomado de “Finding and Fighting the Causes of Insecure Applications”, Jeff Williams 10

11 Herramientas para análisis estático de seguridad: estado del arte
Análisis estático de seguridad del SW Cómo funciona, Ventajas e inconvenientes Técnicas aplicables Herramientas disponibles. Limitaciones.

12 Cuatro clases de técnicas
manual (‘creativo’) Prueba de penetración Aplicación web desplegada. Conocimiento ‘nulo’ Escaneo Batería predefinida de pruebas. Variantes: fuzzers, scanners, protocol proxies, etc. Revisión de código Código y configuración. Uso de docs (specs y diseño) Orientado a defectos de diseño y codificación Análisis estático Reglas predefinidas. Orientado a defectos de codificación automático (‘barato’) dinámico estático En el prefacio de OWASP Code Review, Jeff Williams lo expresa de forma nítida: Every application is different, that's why I believe it's important to to empower the individuals verifying security to use the most cost-effective techniques available. One common pattern is to use security code review to find a problem and penetration testing to prove that it is exploitable. Another pattern is finding a potential issue with penetration testing, and then verifying the issue by finding and examining the code. I strongly believe that the "combined" approach is the best choice for most applications. Recuérdese: Cada una tiene sus aplicaciones, fortalezas, debilidades y puntos ciegos. Es absurdo preguntarse si es mejor un martillo o un serrucho: para construir se necesitan distintas herramientas… Toda aplicación es diferente: úsese la combinación de técnicas más efectiva, caso por caso.

13 Algunas herramientas Analizador estático Cortafuegos de aplicación
Código fuente Librerías (validación…) IDE, compilador Plugins y ext. seguridad Código objeto Código empaquetado Analizador estático Cortafuegos de aplicación Escáner de vulnerabilidades Entorno aplicación PRODUCCIÓN PRUEBAS PRE-PROD DESARROLLO Fuzzer A fin de evitar confusiones, conviene diferenciar claramente un analizador estático de un escáner de vulnerabilidades, y de un cortafuegos de aplicación, aunque algunas herramientas puedan funcionar en modo “híbrido”.

14 Análisis estático de seguridad en código
Estático = se analiza sin ejecutar el software Ventajas: Consistencia. La herramienta ve lo que ve, sin ideas preconcebidas (que normalmente tienen los desarrolladores o revisores). Apuntan a la causa raíz, no a los síntomas. Una prueba de penetración puede establceder que hay un problema, pero no su causa final ni cómo corregirlo. Detección precoz. La aplicación no tiene que estar integrada ni necesita ejecutarse. Su ejecución es barata. Un sistema puede re-analizarse cuando se aplican cambios, o cuando se descubre una nueva vulnerabilidad de aplicación. Inconvenientes: Falsos positivos. Impacto (coste) crece al tener que evaluar cada positivo. Falsos negativos. Suelen ser incapaces de detectar vulnerabilidades de seguridad achacables al diseño, o específicas del contexto propio de la aplicación (se centran en vulnerabilidades genéricas, de codificación). ¿Qué es mejor? En seguridad, sin duda, baja tasa de falsos negativos sin una tasa desproporcionada de falsos positivos.

15 Las interioridades del análisis estático
Símbolos Tipos ControlFlow DataFlow CallFlow Punteros Tainting Código fuente (o bytecode…) Verificador Parser Informe de defectos AST modelo del SW análisis semántico y estructural reglas de seguridad Herramienta Las etapas iniciales son similares a las que sigue un compilador. El análisis semántico permite pasar a una representación interna del software en la que están representadas las nociones básicas para determinar defectos de seguridad: flujo de datos y llamadas, tipos y tamaños de las variables, entradas y recursos alcanzables, y qué entradas están bajo control (taint) del usuario. Este modelo incluye el entorno (librerías, funciones de sistema, etc.) La “inteligencia” está codificada en reglas que un verificador aplica sobre el modelo interno para determinar posibles defectos. El parser analiza un item cada vez (un fichero fuente); análisis semántico construye una representación (normalmente global) del sistema bajo análisis, filtrando lo que no resulta relevante y resolviendo las relaciones que el código expone. El modelo no sólo incluye el software bajo análisis, sino también los elementos que el software puede utilizar (librerías comunes, funciones de sistema, recursos accedidos, controles que permiten verificar las entradas, etc.) El flujo de control representa el flujo en una función o método del código, con todos los caminos posibles de ejecución. El flujo de datos se apoya en el flujo de control para determinar los valores posibles que las variables pueden tomar a lo largo de dichos caminos alternativos. El flujo de llamadas representa las invocaciones entre funciones. El análisis de punteros determina (en los lenguajes con tal capacidad, como C) las áreas de memoria a las que se refieren y si dos punteros referencian regiones solapadas. Finalmente el tainting representa la ‘corrupción’ que un sumidero (un recurso accesible, como un motor de base de datos, una página HTML generada, o una función del sistema que permite ejecutar comandos arbitrarios) está conectada con una entrada controlable por el usuario. El verificador determina si, a lo largo de los múltiples caminos de ejecución (dentro de cada función o en el grafo de llamadas entre funciones) existe un problema de seguridad definido por una regla. Para que el análisis estático funcione con sistemas software ‘del mundo real’ (decenas o centenares de miles de líneas de código, miles de clases y funciones, uso de librerías y recursos típicos en una plataforma TI) se necesitan hacer muchas optimizaciones para que el verificador ofrezca resultados correctos, con una baja tasa de falsos positivos y falsos negativos. La capacidad de una herramienta de análisis estático de seguridad reside aquí, que es donde está la inteligencia.

16 Algunos tipos de análisis
Análisis semántico: Funciones anotadas con precondiciones y postcondiciones que resumen el comportamiento de la función. Análisis estructural: Puede usar lenguajes de consulta de código, la mayoría académicos (como PQL): void FillString(    __out_ecount(cchBuf) TCHAR* buf,       size_t cchBuf,          char ch) { … } TCHAR *b = (TCHAR*)malloc(200*sizeof(TCHAR)); FillString(b,210,'x'); query simpleSQLInjection() uses object HttpServletRequest r; object Connection c; object String p; matches { p = r.getParameter(_); } replaces c.execute(p) with Util.CheckedSQL(c, p); Las anotaciones pueden usar distintas materializaciones: en Java pueden usarse comentarios JavaDoc, JML o las anotaciones a partir de Java 1.5 (con la ventaja de que las anotaciones acaban en el bytecode compilado). En lenguajes como C pueden usarse macros de preprocesador que una extensión del compilador (o herramienta externa) pueda entender. Anotar el código (especialmente en librerías comúnmente usadas) permite que los analizadores “sepan” qué espera y qué produce una función, y usen ese conocimiento para analizar código que invoca a esas funciones de librería y facilitar la detección de código incorrecto (p.ej. para detección de desbordamiento de buffer). Para entender las anotaciones usadas por Visual Studio 2005 (SAL) y la opción /analyze del compilador, ver “a brief introduction to the Standard Annotation Language (SAL) “,

17 Ejemplo: Propagación de entradas
If( fgets(buf, sizeof(buf), stdin) == buf) { strcpy(cmd, buf); system(cmd); } 1) Fuente: fgets 2) DFA conecta fuente fgets con buf 3) Se propaga a cmd 4) DFA propaga cmd a la llamada a system 5) Sumidero alcanzado: system Se lanza problema: “inyección de comando” El objetivo es determinar si una entrada controlada por el usuario alcanza un recurso sin verificar Inyección SQL, de comandos, cross-site scripting Además de fuentes y sumideros, hay que considerar reglas de propagación (3) y reglas de filtrado o limpieza El grado en que una entrada puede estar controlada por el atacante debe manejarse durante el análisis La causa #1 de defectos de seguridad es la falta de validación de entradas. El análisis de propagación determina, usando el flujo de datos del programa, qué a qué recursos sensibles puede acceder el atacante. Se necesita identificar dónde la información entra en el programa (“fuentes”) y cómo se mueve por el programa (dado que las aplicaciones web actuales son multi-capa, típicamente se combina flujo de datos + flujo de invocaciones en un análisis “global”). Este análisis de propagación es clave para identificar numerosos defectos de validación de entradas y representación (inyecciones, control sobre el nombre de ficheros, etc.) Las entradas son típicamente funciones de entrada, o elementos de APIs que actúan como puntos de entrada de una aplicación (por ejemplo un HttpServlet o una clase Action en los marcos web basados en Java). Los sumideros suelen ser elementos cuyo acceso a través de la aplicación por parte del atacante pueden dar lugar a vulnerabilidades explotables: funciones de ejecución de comandos del sistema, API de acceso a ficheros, API para la ejecución de sentencias arbitrarias en base de datos, etc. NOTA: El lenguaje Perl incluye un mecanismo de análisis de propagación (dinámico en este caso), donde el programador puede marcar un programa en modo “taint”, de manera que el intérprete evita (en ciertos casos) que una entrada de usuario, sin filtrar, llegue a una “función sumidero”.

18 Criterios para selección de herramientas
Tipos de análisis (AFD, semántico, estructural) Categorías de vulnerabilidades que pueden detectarse, y esquema de nombres que siguen (e.g. CWE) Precisión (falsos positivos y negativos) Capacidad de configuración (esp. del entorno: librerías de terceros), por ejemplo mediante reglas, filtros, marcas sobre items del código… Calidad de las recomendaciones correctivas Posibilidad de trabajar en modo ‘híbrido’ (análisis estático + confirmación en modo ‘caja negra’) Capacidades de integración (IDE, detectores dinámicos...) Posibilidades de detección de defectos de diseño Explicación razonable (“causa raiz”), y nivel de confianza NIST SAMATE (Software Assurance Metrics And Tool Evaluation) El proyecto SAMATE ( identifica un conjunto común de debilidades que suelen aparecer en la mayoría de los desarrollos, y establece unos mínimos a cumplir por cualquier herramienta de análisis de código. Las capacidades de explicación deben aclarar por qué el analizador ha llegado a una conclusión, y pueden incluir diagramas de flujo de datos y de invocaciones, diagramas de estados, una traza de la ejecución simulada, etc. Las capacidades de filtrado también son importantes: por ejemplo, una regla puede señalar un fichero como afectado por una posible vulnerabilidad en el código. Si el analista tiene claro que el acceso a dicho fichero es seguro, la herramienta debería permitir señalar esta circunstancia para eliminar los resultados indeseados.

19 Lista (en modo alguno completa) de herramientas de análisis estático que tocan (en mayor o menor medida) la detección de defectos de seguridad en el código fuente. Estas heramientas combinan una o más de las distintas estrategias de análisis (de flujo de datos, semántico, estructural). Las herramientas más elaboradas en el presente son las comerciales, estando la oferta de código abierto en esta parcela bastante atrás (aunque diversas iniciativas OWASP pudieran cambiar esta situación en el futuro). Herramientas

20 Proyectos OWASP relacionados
Herramientas OWASP LAPSE (tool) OWASP Orizon (tool) Documentación OWASP (Building) Guide Top Ten Project Testing Guide CLASP Code Review Project App Security Metrics Project Conclusiones: Herramientas muy por debajo de sus equivalentes comerciales Mayor abanico de posibilidades en análisis “dinámico” (fuzzers, escáners dinámicos) que en estático Madurez El proyecto CodeReview incluye algunos contenidos básicos, como “First sweep of the code base” (soportado por una herramienta de búsqueda bastante simple, CodeCrawler).

21 Ejemplo open-source: OWASP LAPSE
Plugin Eclipse (Java) Muy básico Basado en tainting Detecta vulnerabilidades de tipo inyección

22 Ejemplo: Análisis de Tomcat 5.5 (Fortify opensource)

23 Ej.: Fortify Audit Workbench
código orden Una presentación adecuada de los resultados facilita su análisis: Agrupación y ordenación de resultados, por distintos criterios (severidad, nivel de confianza, categoría, etc.) Filtrado de resultados indeseados Explicación de por qué se ha llegado a dicha conclusión Posibilidad de navegar por el código Posibilidad de seguimiento de los defectos a lo largo del tiempo explicación Traza (de flujo de datos)

24 Ejemplo: Microsoft FxCop
Herramienta freeware de Microsoft. Orientada a análisis estático general sobre .NET, incluye algunas reglas de seguridad. Aunque no sea trivial, es posible crear reglas personalizadas (exige algo de búsqueda web y un poco de programación en C#).

25 Herramientas para análisis estático de seguridad: estado del arte
Integración de las revisiones de seguridad de código en el ciclo de vida

26 Procesos: Revisión de código / análisis estático
Esta sección expone cómo las herramientas de análisis estático de seguridad pueden formar parte de una estrategia general de seguridad en el software. La herramienta automatiza la detección de un buen número de vulnerabilidades, una fracción de las mismas explotables, que se introducen en el código como consecuenta de defectos que los programadores introducen por error. Ni que decir tiene que el análisis estático no es la única técnica que deba aplicarse en esta estrategia. El análisis estático no es capaz de hacer lo que una revisión manual de diseño o código puede hacer: identificar ciertos tipos de fallos funcionales en las funciones de seguridad implantadas (como la autenticación, el control de accesos, el control de la privacidad, etc.), o detectar defectos de diseño que llevan a vulnerabilidades de seguridad, no debidos a defectos de codificación. Por lo tanto claro debe quedar que la seguridad del software requiere una combinación de técnicas, herramientas y procesos. Lo que sigue define un esquema de proceso en el que las herramientas de análisis estático de la seguridad del software pueden enmarcarse. Fuente:

27 Revisión de código (apoyado mediante análisis estático)
Establecer objetivos Priorizar qué partes a analizar Entender el software (a alto nivel) Comprender riesgos Lanzar herramientas Introducir reglas específicas Compilar el código; lanzar herramienta Revisar resultados Revisión manual a partir de problemas potenciales Si falso positivo: Reconfigurar; Si falso negativo: Añadir regla Registro de problemas (informe formal, gestor de defectos…) Introducir correcciones Revisar (manual/automáticamente) cambios Actualizar “Buenas prácticas”, objetivos alcanzados, y reglas 1. Establecer objetivos 4. Introducir correcciones 2. Lanzar herramientas 3. Revisar resultados

28 ¿Quién ejecuta la herramienta? ¿Cuándo?
Quién, cúando, cómo… ¿Quién ejecuta la herramienta? Seguridad del software, desarrolladores, o mejor ambos. ¿Cuándo? Desde el IDE del programador; en subida de código al control de versiones; en script de build; al librerar una versión; en procesos formales de auditoría de código. No olvidar que la MAYOR CARGA (90%) de trabajo se consume al analizar resultados e introducir correcciones. ¿Cómo tratar los resultados? “Si hay riesgo, se bloquea la liberación de la versión” “Una autoridad central filtra y decide” Usar aproximación incremental al adoptar técnicas: Recordar las tácticas empleadas con los IDS/IPS Corregir defectos es más barato cuanto antes se identifiquen y corrijan en el ciclo de vida. El análisis estático es una técnica “barata” y repetible para poder identificar problemas de seguridad en el software en fases tempranas, introduciendo cierta proactividad.

29 Cómo interpretar las métricas
Densidad de defectos = # vuln. potenciales / KLOC Cuidado! La densidad de defectos depende mucho de factores no cuantificados, como el estilo de programación Útil para establecer prioridades, por comparación a nivel de sistemas / módulos / en el tiempo Es importante la evolución en el tiempo, y el tiempo medio de corrección Las métricas deberían desglosarse por severidad del defecto Como siempre que se habla de métricas, es mejor una métrica buena, fácil de comprender y que nos diga algo del proceso, que ciento mal entendidas. La densidad de defectos suele ser una de las métricas habitualmente empleadas en QA y, por extensión, en seguridad de software.

30 Sociología de la revisión de seguridad
Las 6 excusas “No creo que sea explotable: demuéstramelo…” “Confío en los administradores de redes / sistemas” “Tienes que estar autenticado para acceder a esa página” “A nadie se le ocurriría hacer eso” “Esa función nunca ha dado problemas (en los tests, nodo X…)” “Ese código no estaba previsto que acabase en producción; tenlo en cuenta…” Los gestores deben transmitir este modo de proceder: Si hay un defecto de seguridad, incluso potencial, debe resolverse. Punto. El equipo de revisión no tiene que demostrar nada a desarrollo. El equipo de desarrollo, si lo desea, puede argumentar las razones por las que creen que el código es seguro, sin usar ninguna de las “6 excusas” arriba enumeradas. Siempre es mejor cubrir con código defensivo una vulnerabilidad potencial no explotable, que dejar sin tratar una vulnerabilidad explotable. La “trampa de la explotabilidad” es el arma nuclear táctica que los equipos de desarrollo usan contra los equipos de revisión de seguridad para quitarse de encima trabajo adicional. Los equipos de revisión cuentan con muy poco tiempo como para tener que desarrollar un exploit (cosa bastante compleja) para cada defecto identificado por la herramienta. Luchemos con uñas y dientes contra ella. “La seguridad es demasiado importante como para dejarla en manos de los equipos de desarrollo”. Una buena estrategia consiste en incluir las seis excusas en el informe, dejándolas en evidencia con argumentos que prueban su inconsistencia. Los desarrolladores se verán entonces abocados a 1) cerrar los agujeros sin chistar 2) argumentar, cuando crean que un problema potencial es un falso positivo, con razones técnicas sobre las que puede discutirse.

31 Herramientas para análisis estático de seguridad: estado del arte
Conclusiones. Áreas de futuro trabajo

32 Papel actual del análisis
Conclusiones Los resultados emitidos por herramientas de análisis estático necesitan de evaluación humana Es más efectivo (aunque difícil) el cambio activo de los hábitos de desarrollo SW, que seguir una aproximación puramente reactiva (ciclos auditoría – corrección ) Tecnologías reactivas (cortafuegos de red o de aplicación) pueden aliviar el problema, no lo corrigen. El problema es el software malo. Y surge desde la mesa de diseño. Las herramientas de análisis estático de la seguridad en código pueden (deben?) formar parte del proceso de desarrollo. ¿Qué puede hacerse dentro de OWASP? Help! Aportar allí donde más necesidad hay: Herramientas de análisis estático OWASP CodeReview Guide OWASP AppSecurity Metrics Project Papel actual del análisis estático en OWASP

33 Bibliografía “Economics and Security Resource Page” (esp. Economics of vulnerabilities), R. Anderson. Secure Programming with Static Analysis, B. Chess and J. West. Addison-Wesley. ISBN: Exploiting Software: How to Break Code. G. Hoglund, G. McGraw. Addison-Wesley. ISBN: Software Security: Building Security In. G. McGraw. Addison- Wesley. ISBN: 19 Deadly Sins of Software Security. M. Howard, D. Leblanc, J. Vieiga. McGraw-Hill. ISBN Static Analysis for Security - “El análisis de código, fuente de seguridad”. J. Crespo. Revista SIC, nº 74, Abril 2007.