Pruebas de seguridad de aplicaciones

La seguridad de aplicación es la disciplina de los procesos, herramientas y prácticas que tienen como objetivo proteger las aplicaciones de las amenazas a lo largo de todo el ciclo de vida de las aplicaciones. Los cibercriminales están organizados, especializados y motivados para detectar y aprovechar las vulnerabilidades en aplicaciones empresariales, con el fin de robar datos, propiedad intelectual e información confidencial. La seguridad de aplicación puede ayudar a las organizaciones a proteger toda clase de aplicaciones (tales como los sistemas heredados, de escritorio, microservicios) utilizados tanto por las partes interesadas internas y externas, entre los que se incluyen clientes, socios de negocio y empleados.

Pruebas estáticas de seguridad de las aplicaciones (SAST)

Se realizarán escaneos estáticos automatizados al código fuente de los aplicativos, dentro del alcance establecido, con la herramienta Micro Focus Fortify. Posteriormente, se generará un reporte/informe técnico, y otro ejecutivo, de los resultados obtenidos durante los escaneos.

La prueba de seguridad de aplicaciones estáticas (SAST) analiza los archivos fuente de la aplicación, identifica con precisión la causa del problema y le ayuda a solucionar los defectos de seguridad subyacentes. Este tipo de evaluación tiene un enfoque de caja blanca (white-box).

El análisis de código estático debe proporcionar información inmediata a los desarrolladores sobre los problemas introducidos en el código durante el desarrollo. Otros aspectos que se buscan evaluar con esta auditoria son:

• Calidad del software

• Complejidad de la aplicación

• Deuda técnica (costo del desarrollo vs mitigación de riesgos)

• Riesgos de seguridad del software

Se deberán realizar al menos pero no limitativas las siguientes validaciones técnicas de los mecanismos de control de los servicios web:

• Injection

• Broken Authentication and Session Management

• Cross-Site Scripting (XSS)

• Insecure Direct Object Reference

• Security Misconfguration

• Sensitive Data Exposure

• Missing Function Level Access Control

• Cross-Site Request Forgery (CSRF)

• Using Components With Know Vulnerabilities

• Unvalidated Redirects And Forwards

Características incluidas:

• El servicio será ejecutado bajo la tecnología Micro Focus Fortify.

• Identificar y eliminar vulnerabilidades en el código fuente, binario o byte.

• Lenguajes soportados: ABAP/BSP, ActionScript, Apex, ASP.NET, C# (.NET), C/C++, Classic, ASP (with VBScript), COBOL, ColdFusion CFML, Go, HTML, Java (incluido Android), JavaScript/ AJAX, JSP, Kotlin, MXML (Flex), Objective C/C++, PHP, PL/SQL, Python, Ruby, Swift, T-SQL, VB.NET, VBScript, Visual Basic y XML

Pruebas dinámicas de seguridad de las aplicaciones (DAST)

La prueba dinámica de seguridad de aplicaciones (DAST) simula ataques controlados a una aplicación o a un servicio web en ejecución para identificar vulnerabilidades explotables en un entorno en ejecución. Se realizarán escaneos dinámicos automatizados a los aplicativos (direcciones IP/hostnames), dentro del alcance establecido, con la herramienta Netsparker. Posteriormente, se generará un reporte/informe técnico y otro ejecutivo, de los resultados obtenidos durante los escaneos. Los escaneos pueden ser realizados en enfoques de caja negra, caja gris y caja blanca.

El análisis de código dinámico:

• Proporciona una visión completa de la seguridad de las aplicaciones centrándose en lo que es explotable y cubriendo todos los componentes (servidor, código personalizado, fuente abierta, servicios).

• Puede ser integrado en Dev, QA y Production para ofrecer una visión holística continua.

• Permite un enfoque más amplio para gestionar el riesgo de la cartera (miles de aplicaciones) y puede analizar aplicaciones heredadas como parte de la gestión de riesgos.

• Probar la aplicación funcional, a diferencia de SAST, se pueden descubrir problemas relacionados con el tiempo de ejecución y el entorno.

Características incluidas:

• El servicio será ejecutado bajo la tecnología Netsparker.

• Identificar y eliminar vulnerabilidades en el código fuente, binario o byte.

• Lenguajes soportados: ABAP/BSP, ActionScript, Apex, ASP.NET, C# (.NET), C/C++, Classic, ASP (with VBScript), COBOL, ColdFusion CFML, Go, HTML, Java (incluido Android), JavaScript/ AJAX, JSP, Kotlin, MXML (Flex), Objective C/C++, PHP, PL/SQL, Python, Ruby, Swift, T-SQL, VB.NET, VBScript, Visual Basic y XML.

Lógica de aplicación/negocio

Este tipo de pruebas juegan un papel importante en las pruebas de seguridad, mientras que otros casos de prueba tipificados pueden ser automatizados con cualquier herramienta, pero los casos de prueba de lógica de aplicación/negocio son demasiado difíciles de automatizar con una herramienta porque la lógica de cada aplicación es diferente a las demás. Mediante la definición de escenarios de prueba basados en riesgo, nuestro equipo técnico evalúa los fallos de seguridad puntuales basados en:

• Identificar la superficie de ataque de la lógica. ¿Qué hace la aplicación, ¿qué es lo más valioso, a qué querría acceder un atacante?

• Pruebas de la transmisión de datos a través del cliente. ¿Hay una aplicación de escritorio o una aplicación móvil, varía la transferencia de información entre ésta y la aplicación web?

• Pruebas de la dependencia de la validación de entradas del lado del cliente: ¿intenta la aplicación basar su lógica en el lado del cliente, por ejemplo, tienen los formularios una longitud máxima en el lado del cliente que puede editarse con el navegador y que simplemente se acepta como verdadera?

• Pruebas de cualquier componente thick-client (Java, ActiveX, Flash). ¿La aplicación utiliza algo como Java, Flash, ActiveX o Silverlight? ¿puede descargar el applet y realizar ingeniería inversa?

• Pruebas de los procesos de varias etapas para detectar fallos lógicos: ¿puede pasar de hacer un pedido directamente a la entrega, evitando así el pago? o un proceso similar?

• Pruebas en el manejo de entradas incompletas: ¿puede pasarle a la aplicación entradas dudosas y las procesa como si fueran normales?

• Pruebas de los límites de la confianza: ¿qué puede hacer un usuario de confianza, puede acceder a los aspectos administrativos de la aplicación?

Metodología

La revisión de seguridad de código fuente consiste en un examen sistemático del código fuente de una aplicación, el cual tiene como finalidad descubrir los errores que puedan conducir a vulnerabilidades que debilitan la integridad del sistema.

Esta es la manera más efectiva de descubrir vulnerabilidades y se utilizan análisis automáticos con revisión manual línea por línea para obtener los hallazgos confirmados.

Se utiliza la metodología de revisión de código fuente de la organización OWASP. Esta cuenta con diferentes fases desde el levantamiento de requerimientos hasta la elaboración del reporte técnico final.

Las fases de esta prueba son:

• Levantamiento de requerimientos y análisis funcional.

• Identificación de flujo de datos.

• Análisis transaccional.

• Identificación de problemas y análisis de riesgo.

• Identificación de soluciones.

• Generación de reporte técnico de hallazgos y remediación.

Algunas otras metodologías en las que nos basamos son las siguientes:

• S-SDLC (Secure Software Development Life Cycle). Se basa en verificar los requisitos de seguridad a lo largo de las distintas fases de construcción del software: análisis, diseño, desarrollo, pruebas y mantenimiento. Sobre todo, durante las dos primeras, ya que gran parte de las debilidades de los sistemas se generan incluso antes de comenzar las tareas de programación. Las claves del S-SDLC son la atención al detalle, para favorecer la identificación inmediata de las vulnerabilidades; y la mejora continua.

• CLASP (Comprehensive Lightweight Application Security Process). Proyecto del OWASP que establece una serie de actividades, roles y buenas prácticas dirigidas a coordinar los procesos de desarrollo seguro de software. La organización OWASP CLASP se asienta en cinco perspectivas o vistas que abordan los conceptos generales de esta metodología, la distribución de funciones, la valoración de las actividades aplicables, la implementación de estas actividades, y el listado de problemas que pueden dar lugar a la aparición de vulnerabilidades.

• SSDF (Secure Software Development Framework). Iniciativa del NIST (National Institute of Standards and Technology de Estados Unidos), provee indicaciones para evangelizar a la organización acerca de la importancia de la seguridad informática; proteger el software de uso habitual ante hipotéticos ataques; orquestar un desarrollo seguro de software; y detectar y solucionar con rapidez cualquier vulnerabilidad.