El ethical hacking en el desarrollo de software seguro

Introducción

Para encontrar vulnerabilidades es necesario hacer pruebas de seguridad, y éstas no deben limitarse solo al pentesting (o ethical hacking), que quizá sea la prueba más popular. El motivo es que el pentesting se hace tras implementar y poner en marcha una aplicación (pruebas de caja negra). Si las únicas pruebas de seguridad que se hacen durante el desarrollo de un software son esas, estaremos aumentando su coste.
Este aumento de coste es debido a que cuanto 1º se detecte una vulnerabilidad en la cadena de producción de un software, menor será el coste de arreglarla. No debemos por tanto centrar nuestra estrategia de pruebas de desarrollo en el final de esta cadena, especialmente cuando los recursos son limitados, como en el caso de una start-up.
Eso no quiere decir que el pentesting no sea necesario (todo lo contrario), pero sí que no debe ser la única técnica de prueba y que debe combinarse con otras. En este artículo desarrollaremos más esta idea.

Estructura de las pruebas de seguridad

Las pruebas de seguridad deben mejorar todo el ciclo de vida de desarrollo de software (Software Development Life Cycle, en adelante SDLC) incluyendo pruebas de seguridad adecuadas en cada una de las fases del proceso de desarrollo (convirtiéndolo en el Secure SDLC).

Toda prueba debe tener en cuenta lo que hemos dicho: El coste de arreglar un problema de seguridad aumenta cuanto más a la derecha del SSDLC esté la prueba que lo descubre [1]. Por tanto, hay que cargar un gran peso de las pruebas lo más a la izquierda del pipeline de la Figura 1 (“shift left”), asumiendo que empieza en la fase de requisitos. Las pruebas de seguridad son pues una parte integral del desarrollo de toda aplicación.
Por tanto, se debe probar pronto, a menudo y, al ser parte del ciclo de desarrollo de la aplicación, siempre se hará de forma ética: planificada, conocida y acordada por todos los involucrados
Se deben probar en general los siguientes componentes cuando sea aplicable:

• Personas: Garantizar que haya una educación y sensibilización adecuadas sobre el negocio y los datos que van a manejar.

• Procesos: Garantizar que existan políticas y estándares adecuados y que las personas sepan cómo seguir estas políticas.

• Tecnologías: Para asegurar que el proceso ha sido eficaz en su implementación.

También se deben usar procedimientos estandarizados adaptados al tipo de software que se vaya a probar. Por ejemplo, para aplicaciones web es muy aconsejable usar el OWASP Web Security Testing Guide (WSTG) [2] 
Es también muy importante recordar que no hay “varitas mágicas” a la hora de hacer pruebas de seguridad, y ninguna herramienta va a encontrar por si sola todas las posibles vulnerabilidades. Todas las pruebas son piezas de un “rompecabezas”, y la seguridad es un proceso y no un producto. Además, las estrategias de defensa en profundidad (aplicación, infraestructura, usuarios) son obligatorias para obtener una seguridad adecuada. 

Como esto es complejo, existen varios frameworks para ayudarnos a planificar y estructurar las pruebas, divididos en dos tipos:

• Descriptivos: Muestran cómo debe usarse el SSDLC en el mundo real, detallando aspectos que les han funcionado bien a otras organizaciones como ayuda para tomar decisiones. Ej.: BSIMM-V [3]

• Obligatorios: Muestra cómo debe funcionar el SSDLC, siendo el tipo más sencillo para empezar a trabajar estos aspectos. Ejs.: Open Software Assurance Maturity Model (OpenSAMM) [4], ISO/IEC 27034 (Partes 1-8) [5]

Para hacer esto, se deben formar a los equipos de desarrollo y pruebas que identifiquen y solucionen problemas de seguridad comunes. Aunque se usen lenguajes, librerías o herramientas que disminuyan el nº de vulnerabilidades potenciales en el desarrollo, el equipo debe adquirir la actitud adecuada (pensar de manera creativa, poner a la aplicación en situaciones anómalas o inesperadas, saltarse pasos o procesos...) para probar la aplicación en cada fase de desarrollo desde el punto de vista de un atacante, asumiendo esto como una responsabilidad más [1]. 
Se debe también tener claro el nivel de protección que cada dato va a necesitar y la legislación asociada. Ej.: La Directiva 96/46/EC4 de la EU obliga a tratar los datos personales de una aplicación con extremo cuidado, sin importar su funcionalidad
Para hacer pruebas es necesario tener una buena documentación del proceso de desarrollo y ayudarse en herramientas automatizadas. Un buen conjunto de ellas ahorra tiempo y automatiza muchas tareas rutinarias, pero no reemplazan al equipo que hace auditoría de seguridad. No se debe crear una falsa sensación de seguridad.
También es importante crear métricas para determinar si la seguridad va mejorando a partir de los resultados de las pruebas realizadas. Estas métricas se pueden generar automáticamente a partir del código fuente, con estándares como OWASP Metrics  [6]. Finalmente, se deben documentar los resultados en un formato aceptado por todas las partes.
 

 ^{Figura 1. Fases típicas de un SSDLC, con algunas de las actividades de prueba más comunes en cada una de ellas. Fuente: https://www.jit.io/resources/devsecops/ssdlc-secure-software-development-lifecycle}

Técnicas de pruebas de seguridad

Dado que el pentesting es una prueba de seguridad que entra en juego al final del SSDLC, debemos hablar de otras técnicas de prueba que puedan implementarse antes [2].

 Inspección y revisión manual

Consiste en que un equipo humano revise la seguridad de las personas, políticas, procesos, decisiones tecnológicas y el diseño arquitectónico del software. Normalmente se analiza la documentación y/o se hacen entrevistas a los implicados en la creación del producto. 
La principal ventaja es que no necesita tecnología de soporte y puede aplicarse en muchas situaciones, al ser flexible. Esto implica que se puede hacer pronto en el SDLC, adaptándose al paradigma “shift left” mencionado. Como desventajas, podemos destacar que puede llevar mucho tiempo y que el material necesario no siempre está disponible.
 

Threat Modeling

Técnica para ayudar a los diseñadores a pensar en las amenazas de seguridad de sus sistemas y aplicaciones. Puede verse cómo una evaluación de riesgos para las aplicaciones, que permite desarrollar estrategias de mitigación para vulnerabilidades potenciales que se hayan identificado. Es recomendable desarrollarlas siguiendo un estándar de evaluación de riesgos, como el NIST 800-30 [7]. 
La principal ventaja es que modela una visión del adversario (y práctica) del sistema, es flexible y se puede hacer pronto en el SDLC, de nuevo adaptándose al paradigma “shift left” mencionado. Su principal desventaja es que se necesita experiencia para hacerlo bien.

Revisión de código fuente

Proceso de comprobar manualmente (o con ayuda de herramientas específicas [1]) el código fuente de una aplicación en busca de problemas de seguridad. Es además la única forma de detectar ciertos problemas de seguridad (problemas de concurrencia, de lógica de negocio...). 
Su principal ventaja es que son completas, precisas, efectivas y rápidas. No obstante, su principal desventaja es que necesitan personal altamente especializado, y que a veces no son viables por no estar disponible todo el código fuente.
 

Penetration Testing

Son pruebas de caja negra de una aplicación en ejecución. Su idea básica es encontrar vulnerabilidades sin necesidad de conocer el funcionamiento de ésta en detalle, por lo que el probador necesita adquirir una “mentalidad de adversario”. Al finalizarla, se elabora un informe con todo lo encontrado y sus posibles soluciones, tanto para personal técnico como no técnico.

Requieren por tanto una labor de investigación más minuciosa, y tienen la ventaja de ser rápidas (y más baratas) que las otras, necesitar menos conocimientos técnicos y que prueban el código que realmente está en funcionamiento. Esto último, no obstante, es su principal desventaja como comentamos al principio de este artículo: se hacen demasiado tarde en el SDLC, por lo que los errores que se encuentren costará más solucionarlos por lo dicho en el paradigma shift left.
A pesar de esto, es un tipo de prueba muy popular, usada para localizar vulnerabilidades en aplicaciones en producción, de las que no se tenga acceso al código fuente ni influencia en el proceso de creación de esta, ambos requisitos necesarios para aplicar los otros tipos de pruebas. Por tanto, son pruebas ideales para aplicaciones hechas por 3ºs
Para ayudar a hacer pruebas de pentesting existen varias metodologías:

• Penetration Testing Execution Standard (PTES) [8]. Además de la metodología o proceso, con 7 fases, también proporciona guías técnicas de qué y cómo probar.
• PCI Penetration Testing Guide [9]. El Requirement 11.3 del estándar de seguridad Payment Card Industry Data Security Standard (PCI DSS [10]) define cómo hacerlo, y es el estándar para empresas que procesas, almacenan o transmiten tarjetas de crédito. 
• Penetration Testing Framework [11]. Da una guía detallada, incluyendo las herramientas adecuadas para cada una de sus categorías y un informe final.
• Technical Guide to Information Security Testing and Assessment (NIST800-115) [12]. Esta guía la publica el NIST e incluye varias técnicas de evaluación de seguridad.
• Open-Source Security Testing Methodology Manual (OSSTMM) [13]. Metodología para probar la seguridad de localizaciones físicas, flujos de trabajo, seguridad humana, de comunicaciones, etc. y su nivel de cumplimiento. Puede usarse como referencia para la implementación del framework ISO 27001 [14].
•  OWASP Web Security Testing Guide (WSTG) [2]. Un procedimiento completo para identificar y analizar vulnerabilidades web, con una versión abreviada con las vulnerabilidades más comunes llamada OWASP Top 10 [15]. 
   

Finalmente, es necesario mencionar el MITRE ATT&CK [16], una base de conocimientos libre y accesible a nivel mundial de tácticas y técnicas y procedimientos de adversarios basadas en observaciones del mundo real. Es imprescindible para desarrollar una buena mentalidad del adversario, lo que la hace muy valiosa para desarrollar Threat models y guiar procesos de pentesting.  

Conclusiones

En este artículo hemos tratado de transmitir la idea de que las pruebas de seguridad que se hagan a una aplicación deben integrarse con su proceso de desarrollo. Además, hemos señalado que, aunque el pentesting es importante para las pruebas de seguridad de una aplicación, no es el único tipo de prueba existente y, de hecho, hacer solo pentesting no es aconsejable por el coste de solucionar vulnerabilidades localizadas tan tarde en la cadena de producción del software.
Debido a ello, se han enumerado otro tipo de pruebas que complementan al pentesting, adecuadas para fases más tempranas de dicha cadena de producción, y que deberían hacerse en conjunción con el mismo, para así poder tener un sistema de pruebas de seguridad de una aplicación completo y adecuado.