
Seguridad de apps satisfactoria
SAST (Pruebas de seguridad de aplicaciones estáticas)
es un tipo de prueba caja blanca
en la que se utiliza un conjunto de tecnologías
para analizar el código fuente,
el código de bytes o los binarios de la aplicación
con el fin de revelar vulnerabilidades de seguridad conocidas
que puedan ser explotadas por usuarios malintencionados.
Un poco de historia
En su artículo de 1976,
Design and Code Inspections to Reduce Errors in Program Development,
Michael E. Fagan explica cómo realizar una revisión de código y,
de este modo, crea el primer proceso de revisión
de código del mundo. La inspección de Fagan
es un proceso de ejecución formal
que implica varias fases y participantes,
y también define criterios de entrada
y salida para iniciar y finalizar el proceso.
En 1992, en su artículo Experience with Fagan’s Inspection Method
(Experiencia con el método de inspección de Fagan),
E.P. Doolan propone utilizar un software que mantenga
una base de datos de errores detectados
y escanee automáticamente el código en busca de ellos.
Se inicia así el uso de herramientas automatizadas.
Ciclo de vida del desarrollo de software (SDLC)
El SDLC es una serie de etapas que deben seguirse
para el desarrollo de un producto de software específico.
Estas etapas garantizan que la calidad,
la funcionalidad y los objetivos de la aplicación cumplan
las expectativas del cliente y los estándares de desarrollo.
Imagen 2. Etapas del ciclo de vida de desarrollo de software vía
Synotive.com
Durante el SDLC es importante utilizar metodologías de prueba
en las primeras fases de desarrollo que identifiquen
y resuelvan rápidamente las vulnerabilidades de seguridad,
antes de la publicación de la aplicación.
Estas vulnerabilidades se pueden encontrar en los siguientes sitios web:
Imagen 3. Proyecto OWASP Top Ten vía owasp.org
Aplicando SAST podemos detectar y evitar
la mayoría de las vulnerabilidades de seguridad enumeradas
en las páginas de los enlaces anteriores.
¿Cómo funciona SAST?
SAST puede aplicarse manualmente
o mediante el uso de herramientas automatizadas.
Las pruebas manuales son realizadas por un equipo de evaluadores
encargados de revisar el código en busqueda
de vulnerabilidades de seguridad conocidas.
Una vez encontradas las vulnerabilidades,
se reportan al equipo de desarrollo para su solución.
Las pruebas manuales incluyen varias etapas
Sincronización: Esta etapa incluye recibir
de los desarrolladores la aplicación,
una explicación completa de lo que hace la aplicación y cómo lo hace.Revisión: En esta etapa, el equipo de pruebas toma
el código fuente y analiza cada línea, método,
clase y archivo en búsqueda de vulnerabilidades de seguridad.Reporte: En esta etapa, se eliminan los falsos positivos
y la información irrelevante, se crean reportes de hallazgos
y se entregan a los líderes de proyecto responsables
de comunicarse con los desarrolladores,
quienes entonces mitigan o remedian las vulnerabilidades.
Imagen 4. Reporte de hallazgos en pruebas manuales vía
Mitre.org
Herramientas automatizadas: Existen muchas
herramientas
que nos permiten realizar análisis de código de forma automática
y proporcionar reportes de las vulnerabilidades descubiertas
durante el proceso de escaneo.
Dado que estas herramientas son más flexibles,
pueden integrarse con entornos de desarrollo
que incluyen escenarios Waterfall,
entornos de Integración Continua (CI/CD),
Agile/DevOps, repositorios de fuentes,
e incluso con otras herramientas de pruebas.
Este tipo de herramientas utilizan funciones sofisticadas
como el análisis de flujo de datos,
el análisis de flujo de control y el reconocimiento de patrones
para identificar posibles vulnerabilidades de seguridad.
El resultado será que las vulnerabilidades se reporten antes,
sobre todo en proyectos complejos o con demasiadas líneas de código.
Imagen 5. Reporte de hallazgos en pruebas automatizadas vía
Oreilly.com
Los reportes siempre son revisados por los empleados
porque las herramientas automatizadas tienden a generar
un gran número de falsos positivos y necesitan ser filtrados
para extraer los riesgos potenciales de una aplicación.
Según
Synopsys.com:
Hay seis sencillos pasos necesarios para realizar SAST de forma eficiente
en empresas que tienen un gran número
de aplicaciones construidas en diferentes
lenguajes, marcos y plataformas.
Finalizar la herramienta: Selecciona una herramienta
de análisis estático que pueda realizar revisiones
de código de aplicaciones escritas en los lenguajes
de programación que utilices.Crear la infraestructura de análisis y desplegar la herramienta:
Este paso implica gestionar los requisitos de licencia,
configurar el control de acceso y la autorización,
y conseguir los recursos necesarios
(p. ej., servidores y bases de datos) para desplegar la herramienta.Personalizar la herramienta: Ajusta la herramienta
para que se adapte a las necesidades de la organización.
Por ejemplo, puedes configurarla para reducir los falsos positivos
o encontrar vulnerabilidades de seguridad adicionales
escribiendo nuevas reglas o actualizando las existentes.
Integra la herramienta en el ambiente de construcción,
crea tableros para rastrear los resultados del escaneo
y crea reportes personalizados.Priorizar e incorporar las aplicaciones:
Una vez que la herramienta esté lista, incorpora tus aplicaciones.
Si tienes una gran cantidad de aplicaciones,
prioriza las de alto riesgo para escanearlas primero.
Con el tiempo, todas las aplicaciones deberían incorporarse
y analizarse con regularidad,
y los análisis de las aplicaciones deberían sincronizarse
con los ciclos de publicación,
las compilaciones diarias o mensuales,
o las comprobaciones de código.Analizar los resultados del escaneo: Este paso consiste en
clasificar los resultados
del escaneo para eliminar los falsos positivos.
Una vez finalizado el conjunto de problemas,
deben ser rastreados y proporcionados a los equipos de despliegue
para su remediación adecuada y oportuna.Proporcionar gobernanza y formación:
Una gobernanza adecuada garantiza que los equipos de desarrollo
empleen correctamente las herramientas de escaneo.
Los puntos de contacto de la seguridad del software
deben estar presentes en el SDLC.
SAST debe incorporarse como parte de tu proceso de desarrollo
y despliegue de aplicaciones.
Beneficios
SAST puede aplicarse en las primeras fases del SDLC,
ya que busca vulnerabilidades en el código antes de que se compile.
De este modo, se garantiza que la aplicación contenga
el menor número posible de vulnerabilidades de seguridad
antes de su publicación.
SAST puede reducir los costos de dinero y tiempo al encontrar
y resolver vulnerabilidades en las primeras etapas del SDLC
que podrían costarte mucho más arreglar,
si se descubren, en las etapas posteriores.
SAST es flexible y puede adaptarse a cualquier tipo de proyecto.
SAST puede integrarse completamente con los ambientes CI/CD,
Agile y DevOps (DevSecOps).
Conclusiones
Es importante conocer las vulnerabilidades de seguridad
a las que están expuestas las aplicaciones.
Para ello,
debemos leer e informarnos continuamente a través de recursos
como OWASP
o CWE.
Siempre se deben realizar
pruebas de seguridad
a las aplicaciones para garantizar
que son capaces de mantener la confidencialidad,
integridad y disponibilidad de la información.
Realiza siempre revisiones continuas de una aplicación.
Las pruebas de seguridad nunca deben realizarse solo una vez.
El uso de SAST ayuda a los programadores a reforzar los estándares
de codificación.
Referencias
*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Kevin Cardona. Read the original post at: https://fluidattacks.com/es/blog/seguridad-app-sastisfactoria/