Error de AppSec n° 1: usar un solo tipo de prueba

04 de septiembre 2018

 

Esta es la primera de una serie de blogs que analiza algunos de los errores más comunes  que conducen a iniciativas fallidas de AppSec.

El mito de la bala de plata de AppSec

No existe una bala de plata para la seguridad de las aplicaciones. Intentar elegir el «mejor» tipo de prueba sería como tratar de elegir el mejor utensilio para comer: ¿tenedor, cuchillo o cuchara? Bueno, depende de la comida y, en última instancia, cada uno desempeña un papel diferente, y los necesitas a todos. ¿Cereal en la mañana? Cuchara mejor. ¿Carne para la cena? El cuchillo sería bueno, pero no tan útil sin un tenedor. Piensa en los diferentes tipos de pruebas de seguridad de aplicaciones de la misma manera: cada uno tiene diferentes fortalezas y debilidades y son mejores en diferentes escenarios, pero no serían efectivos sin aprovecharlos todos. 

¿Por qué se necesita análisis estático y dinámico? 

Los programas efectivos de seguridad de aplicaciones analizan el código de forma estática en el desarrollo y de forma dinámica en la producción. ¿Por qué se requieren estos dos tipos de prueba? Porque cada uno encuentra diferentes tipos de defectos relacionados con la seguridad. Por ejemplo, las pruebas dinámicas son mejores para detectar fallas de configuración de implementación, mientras que las pruebas estáticas encuentran los errores de inyección de SQL más fácilmente. El informe reciente realizado por Veracode,  State of Software Security  examina las cinco principales categorías de vulnerabilidad que se encontraron durante pruebas dinámicas:

1. Fuga de información

2. Cuestiones criptográficas

3. Configuración de implementación

4. Encapsulación

5. Scripting entre sitios

Además, la seguridad efectiva de las aplicaciones protege el software a lo largo de todo el ciclo de vida, desde el inicio hasta la producción. Con la velocidad de los ciclos de desarrollo actuales y la velocidad con la que el software cambia y el panorama de amenazas evoluciona, sería absurdo suponer que el código siempre estará 100% libre de vulnerabilidades después de la fase de desarrollo, o que el código en producción no se necesita ser probado o, en algunos casos, parchado. 

¿Por qué se necesita un análisis de composición de software?

Las aplicaciones se «ensamblan» cada vez más a partir de componentes de código abierto, en lugar de desarrollarse desde cero. Con la velocidad de los ciclos de desarrollo actuales, los desarrolladores no tienen tiempo para crear cada línea de código desde el principio, y ¿por qué lo harían con tanta funcionalidad de código abierto disponible? Sin embargo, dejar de evaluar y realizar un seguimiento de los componentes de código abierto que se esté utilizando dejaría expuesta una gran parte del código y lo dejaría expuesto a los ataques. La seguridad efectiva de las aplicaciones implica la evaluación del código de primera parte, además de evaluar y crear un  inventario del análisis de composición de software.

¿Por qué se necesitan pruebas de penetración manual?

La automatización por sí sola no es suficiente para garantizar que una aplicación se pruebe exhaustivamente desde una perspectiva de seguridad. Algunos defectos, como CSRF ( Cross-Site Request Forgery ) y  vulnerabilidades de lógica de negocios , requieren que un ser humano esté en el camino para explotar y verificar la vulnerabilidad. Solo las pruebas de penetración manual pueden proporcionar una identificación positiva y la validación manual de estas vulnerabilidades.

Aprende de los errores

No repitas los errores del pasado; aprende de otras organizaciones y evita las trampas de AppSec más comunes. Primer consejo: no confíes en un solo tipo de prueba; eso es como tratar de comer todas tus comidas con solo una cuchara. La seguridad efectiva de las aplicaciones combina una variedad de tipos de pruebas y evalúa la seguridad durante el ciclo de vida de una aplicación, desde el inicio hasta la producción.

Síguienos en nuestras redes sociales