Análisis de Código Noticias

¿Qué tan segura es su aplicación de banca en línea?

La banca se ha vuelto digital. Casi todos los principales bancos ofrecen tanto un portal en línea como una aplicación móvil, y las personas parecen preferirlo de esa manera. Una encuesta reciente de PwC encontró que el 46% de los consumidores solo usan la banca en línea, un salto masivo respecto de su encuesta anterior en 2012, en la que solo el 27% usaba la banca en línea exclusivamente.

Para los bancos y otras instituciones financieras, ahora es necesario ofrecer una aplicación en línea que permita el acceso a la banca en línea o móvil cuando se observan esos números. Los usuarios anhelan la conveniencia que conlleva la banca sobre la marcha, y aunque las ventajas que conlleva poder realizar operaciones bancarias personales en su dispositivo móvil o computadora es innegable, aún persiste otra pregunta: ¿cuán seguras son estas aplicaciones de banca en línea?

La investigación que se lanzó a fines de 2017 puede ofrecer una respuesta a esa pregunta. La investigación , realizada en la Universidad de Birmingham, encontró problemas de seguridad en las aplicaciones de banca móvil que podrían dejar a millones de usuarios abiertos a ataques. El problema principal que encontraron se relaciona con una falla en la fijación de certificados, lo que significaba que las pruebas no detectaban “una vulnerabilidad grave que podría permitir a los atacantes tomar el control de la banca en línea de una víctima”, dijo The Register .

Son problemas de seguridad como este los que muestran cuán importante es cubrir todas sus bases al desarrollar aplicaciones de banca digital. Si bien la banca digital puede ayudar a fomentar nuevas conexiones y ofrecer servicios nuevos e innovadores, trayendo así más ganancias para las instituciones financieras, la banca digital también conlleva un gran riesgo.

7 pasos críticos para los desarrolladores de aplicaciones bancarias

Si bien los consumidores tienen una carga de seguridad que incluye el uso de WiFi seguro para acceder a su aplicación bancaria, bloquear sus dispositivos cuando no los usan, usar una contraseña única y no usar computadoras públicas para acceder a sus cuentas, la carga principal de garantizar la seguridad de los clientes es En los bancos. O más bien, los desarrolladores y equipos que trabajan en las aplicaciones.

El desarrollo de un ciclo de vida de desarrollo de software o SDLC es vital para el desarrollo continuo de aplicaciones seguras. El SDLC implementará una estrategia para garantizar la seguridad del producto, sin ralentizar el proceso de desarrollo. Aquí hay siete pasos críticos en el SDLC en los que los desarrolladores y los equipos de seguridad deben trabajar juntos para garantizar el lanzamiento de una aplicación segura de banca en línea o móvil.

1. Establecer requisitos de seguridad

El primer paso es comprender los requisitos de seguridad de la aplicación bancaria. Debido a la naturaleza sensible de las aplicaciones bancarias, es importante asignar al menos un miembro del equipo de seguridad para que trabaje con el equipo de compilación, y esta asociación debe comenzar antes que el desarrollo.

Durante esta parte del SDLC, el desarrollo y la seguridad deben identificar los riesgos de seguridad clave dentro del software, incluidos los estándares (tanto organizativos como legales / reglamentarios) que debe seguir el software. Las partes interesadas de los equipos de desarrollo y seguridad deben identificarse para asegurarse de que la comunicación sea clara desde el principio, y cualquier brecha en el proceso debe tenerse en cuenta. Solo una vez que los requisitos de seguridad se hayan establecido y acordado por todas las partes, puede comenzar el desarrollo.

2. Analizar la superficie de ataque.

Cualquier software bancario vendrá con áreas de riesgo, conocidas como su superficie de ataque. La superficie de ataque, escribe OWASP , se compila de:

  • La suma de todas las rutas para datos / comandos dentro y fuera de la aplicación
  • El código que protege estos caminos
  • Todos los datos valiosos utilizados en la aplicación, incluidos secretos y claves, propiedad intelectual, datos comerciales críticos, datos personales y PII
  • El código que protege estos datos.

Varias organizaciones han ideado métodos para cuantificar la superficie de ataque: Michael Howard de Microsoft ha diseñado un cociente de superficie de ataque relativo, y los investigadores de Carnegie Mellon han creado la métrica de superficie de ataque. Puede ser útil comenzar usando uno de estos métodos mientras crea uno que funcione mejor para su organización.

El análisis de la superficie de ataque es una parte compleja pero crucial de la protección de cualquier aplicación, ya que señala las áreas más críticas y potencialmente vulnerables del código para garantizar que estén correctamente protegidas durante el desarrollo y las pruebas.

Para obtener más información sobre el análisis de la superficie de ataque, consulte la hoja de trucos de OWASP

3. Implementar modelos de amenazas

El siguiente paso en el SDLC seguro es realizar el modelado de amenazas. El modelado de amenazas ayuda a los desarrolladores a comprender qué controles de seguridad se requieren para que la aplicación garantice aún más la seguridad desde el principio. El proceso de modelado de amenazas implica definir qué activos y recursos deben protegerse, los puntos de entrada y acceso en los que se pueden obtener estos activos y recursos, junto con el desarrollo de estrategias de mitigación para cada amenaza una vez que se han priorizado.

La relación entre el modelado de amenazas y el análisis de la superficie de ataque es cercana, y esto significa que cualquier cambio en la superficie de ataque requerirá un modelado de amenazas, y ese modelado de amenazas ayuda a las partes interesadas a comprender mejor la superficie de ataque.

Profundice en el modelado de amenazas con la hoja de trucos dedicada de OWASP

4. Realizar pruebas de seguridad de análisis estático

En su forma más básica, las pruebas de seguridad de análisis estático, o SAST , prueba el código fuente de una aplicación para detectar vulnerabilidades críticas. Las herramientas avanzadas de SAST hacen esto automáticamente, asegurando el código desde la raíz, y pueden implementarse en las etapas iniciales del proceso de desarrollo. Las pruebas SAST son una parte importante del SDLC porque detecta fallas mucho antes de que la aplicación entre en producción, lo que significa que se pueden encontrar y corregir errores donde es más fácil y más barato hacerlo. SAST funciona señalando a los desarrolladores áreas específicas del código donde hay problemas.

Además de detectar las vulnerabilidades incluidas en el OWASP Top 10 y mucho más allá, SAST también comprueba el código en busca de problemas de compatibilidad relacionados con los estándares legales y reglamentarios, incluido PCI-DSS, que muchos bancos deben cumplir.

Continúe leyendo con nuestra Guía para principiantes sobre pruebas de seguridad en el SDLC

5. Realice pruebas de seguridad de aplicaciones interactivas
Mientras que SAST interactúa con el código, IAST , el siguiente paso en el SDLC seguro, prueba una versión en vivo del software. En esencia, mientras que SAST es una persona de seguridad que garantiza un código seguro, IAST es un hacker que trabaja para obtener acceso a áreas de la aplicación que no debería poder. IAST no requiere una comprensión profunda de la aplicación, solo mira si es vulnerable y cómo se puede aprovechar esa vulnerabilidad.

El uso de una combinación de pruebas de seguridad estáticas y dinámicas es la mejor manera de garantizar que las vulnerabilidades se eliminen del código y la aplicación antes de que se active. Especialmente para aplicaciones más sensibles como el software bancario, esta combinación es crucial para reducir las vulnerabilidades y el riesgo de ataque lo más bajo posible.

¿Interesado en aprender más sobre IAST? Consulte nuestro seminario web ” ¿Qué pasa con IAST? 

6. Crear puertas de seguridad

Quizás la parte más importante del SDLC es asegurarse de que el software con fallas de vulnerabilidad media o alta no llegue a producción. El proceso SDL de Microsoft se refiere a las puertas de seguridad como ‘barras de error’, pero la idea es la misma. Las puertas de seguridad establecen un nivel mínimo de seguridad y se verifica el código para detectar vulnerabilidades de alto riesgo. Cualquier código marcado como de alto riesgo debe enviarse de vuelta a los desarrolladores para implementar una solución. Estas comprobaciones se realizan mejor mientras aún están en desarrollo utilizando pruebas de análisis estático, ya que una plataforma como CxSAST puede detectar automáticamente estas vulnerabilidades mientras los desarrolladores aún escriben el código para ayudarlos a solucionarlo en la fuente.

Es esencial que una vez que se establezcan las puertas de seguridad, no se rompan, no importa cuán cerca esté de lanzar la aplicación: nunca se debe permitir que una vulnerabilidad de riesgo medio o alto entre en producción, y la puerta de seguridad ayuda a definir qué son y qué hacer cuando son descubiertos.

7. Introducir educación continua sobre desarrollo seguro

Si bien no forma parte del SDLC tradicional, la educación para desarrolladores es parte del SDLC seguro. La capacitación de desarrolladores está ganando terreno rápidamente en las organizaciones de desarrollo seguro debido a su efectividad para convertir a los desarrolladores que saben poco o nada sobre seguridad en desarrolladores seguros que consideran la seguridad en todo momento.

Especialmente en un entorno altamente sensible como una aplicación bancaria, hacer que los desarrolladores que entienden el proceso de seguridad lleguen lejos en la liberación más rápida de software seguro.