Codigo

Exposición al código: las vulnerabilidades en su código y dónde se originan

Las aplicaciones de software típicas se componen de dos tipos de código: código personalizado creado por sus equipos internos de desarrollo y código de terceros, a menudo de código abierto, creado fuera de la organización. Hasta hace unos 10 a 15 años, casi todo el software era código personalizado, y cada línea de software fue creada y probada por equipos de software internos. No se confiaba en el código de terceros de los proveedores, y en particular en el software de código abierto. Independientemente de la fuente, hay vulnerabilidades en casi cada pieza de código, que llamamos, exposición de código.

Las soluciones de seguridad de software que incluyen pruebas de seguridad de aplicaciones (AST) administran y miden su exposición general al software , lo que lo ayuda a comprender con precisión y reducir significativamente el riesgo comercial de su organización. Un componente de la exposición de software incluye el concepto de exposición de código como se muestra en el gráfico a continuación. Este concepto plantea la pregunta: “¿Hemos identificado vulnerabilidades críticas en nuestro software, tanto de código personalizado como de código abierto?”

 

¿Qué son las vulnerabilidades?

Las vulnerabilidades son debilidades en el software que a menudo pueden ser explotadas por actores de amenazas. La mayoría de las vulnerabilidades ocurren durante la fase de diseño y codificación del Ciclo de vida del desarrollo de software (SDLC). Estas vulnerabilidades son el resultado de varios factores que incluyen errores de diseño, errores de codificación y el uso de componentes de código abierto con vulnerabilidades conocidas. Otro factor importante que contribuye a que los desarrolladores introduzcan vulnerabilidades se debe a la complejidad del código.

Las organizaciones con aplicaciones de software muy grandes generalmente no tienen una persona en el personal que comprenda toda la base de código, lo que puede contribuir a la propagación de problemas de seguridad en toda la base de código.

Vulnerabilidades debido a errores de codificación

Los desarrolladores de software trabajan a partir de una especificación que describe lo que el software está destinado a hacer (por ejemplo, cuando se presiona el botón A, mostrar información de la cuenta). Los desarrolladores usan requisitos funcionales como el modelo para su trabajo. Si un requisito funcional no funciona como se especifica, se registra un “error” funcional.

Pueden ocurrir errores o defectos de seguridad cuando las características no se implementan correctamente. Por ejemplo, cuando se presiona el botón A, se muestra información sobre todas las cuentas. O la característica funciona, pero puede ser manipulada por actores de amenazas para obtener acceso a información privilegiada. La seguridad debe tener en cuenta los casos de uso indebido imprevisto que provocan que la aplicación se “rompa” o se realice de otra manera de forma no intencionada.

La seguridad del software generalmente no forma parte de la especificación funcional, y el simple hecho de que el software sea “seguro” no cuenta. Los desarrolladores de software se han medido tradicionalmente de manera funcional. Si entregaron características a tiempo, estaban haciendo su trabajo correctamente. La seguridad nunca se consideró hasta hace unos 20 años, y la codificación segura todavía rara vez se enseña en los programas informáticos.

Falta de enfoque en la seguridad, conduce a la exposición del código

Una fuente de exposición al código son los errores o debilidades creadas por los desarrolladores en software personalizado cuando escriben código. Estas debilidades a menudo se derivan de comportamientos, hábitos y políticas de codificación deficientes, o se deben a un panorama de amenazas o características en constante cambio de varios lenguajes de codificación. Los actores de la amenaza centran sus esfuerzos en encontrar estas debilidades y explotarlas, a menudo para su beneficio financiero. Las debilidades más comunes (o errores de software) se enumeran en el OWASP Top 10 y el SANS Top 25 .

Vulnerabilidades de componentes de terceros

La adopción de componentes de código abierto por parte de los equipos de desarrollo de software cambió drásticamente la industria del software. En lugar de construir todo el software “desde cero”, las organizaciones usan componentes de código abierto para proporcionar características y funcionalidades comunes o repetitivas. Esto limita el uso de código personalizado a características y funcionalidades propietarias.

Como resultado, los desarrolladores dedican su tiempo a diferenciadores clave, en lugar de recrear características comunes. La adopción de código abierto por casi todas las industrias ha impulsado aumentos en el desarrollo de código abierto. Muchas organizaciones grandes, como Microsoft , han adoptado el código abierto, y millones de proyectos de código abierto están disponibles para que los desarrolladores los utilicen y contribuyan.

El software de código abierto sigue siendo software y está expuesto a errores de codificación que pueden generar vulnerabilidades de seguridad. Un gran número de vulnerabilidades recientemente descubiertas se revelan en software de código abierto cada año. Estas vulnerabilidades generalmente se informan de manera responsable, acompañadas de un parche o una versión actualizada que corrige la vulnerabilidad, lo que hace que la reparación de componentes vulnerables sea relativamente fácil.

Remediación de componentes vulnerables

Sin embargo, no siempre es sencillo remediar “el uso” de un componente de código abierto vulnerable. Primero, debe tener visibilidad de dónde se utilizan los componentes de código abierto. Desafortunadamente, muchas organizaciones no rastrean su uso de código abierto, o lo hacen en una hoja de cálculo estática y desactualizada. La aplicación promedio incluye cientos de componentes únicos de código abierto, y los desarrolladores descargan y mantienen esos componentes en sus espacios de trabajo durante años.

A medida que estos componentes envejecen, aumenta la posibilidad de que las vulnerabilidades ya se hayan descubierto y revelado en ellos. Con cientos de componentes mal rastreados y muchas vulnerabilidades nuevas cada año, muchas organizaciones están expuestas a una posible explotación. Los atacantes son conscientes de que estos componentes de código abierto a menudo se rastrean y mantienen de manera deficiente.

Identificación de la exposición del código para el código personalizado

Afortunadamente, existen soluciones que ayudan a identificar la exposición del código. Comience analizando el software que su organización crea internamente y elija una solución completa de prueba de seguridad de aplicaciones que se integre con los servidores de Integración Continua (CI), así como con el entorno de desarrollo integrado (IDE) de los desarrolladores. Las pruebas de seguridad de aplicaciones estáticas (SAST) y las soluciones de pruebas de seguridad de aplicaciones integradas (IAST) son imprescindibles. Estas soluciones lo ayudan a identificar errores de codificación en un código personalizado para que pueda encontrar vulnerabilidades al principio del SDLC. También es importante configurar su solución de seguridad para probar tipos específicos de debilidades o errores, como los enumerados en OWASP Top 10 o SANS Top 25. Por supuesto, esas no son las únicas vulnerabilidades de las que preocuparse, por lo que es útil ser capaz de realizar una prueba más amplia en todos los casos.

Identificar la exposición del código en el código de terceros

Hoy, la aplicación promedio es principalmente de código abierto. El análisis de composición de software demuestra que las aplicaciones actuales están compuestas por más del 80% de los componentes de código abierto dentro de la base del código. La adopción de Linux como sistema operativo de clase empresarial, Java como lenguaje de desarrollo primario y Apache Struts como marco MVC han aumentado la confianza en los componentes de código abierto.

Dado que los componentes de código abierto se han convertido en los componentes básicos de las aplicaciones modernas, identificar la exposición del código en componentes de terceros se ha convertido en una parte esencial de cualquier programa de seguridad de software. Necesita una solución que mitigue la exposición al código de componentes de terceros mediante el escaneo de compilaciones para identificar todos los componentes de código abierto utilizados. Busque soluciones que proporcionen una lista de las vulnerabilidades reportadas públicamente en esos componentes, acompañadas de consejos de corrección para usar versiones actualizadas o parches para esas vulnerabilidades. Es esencial que sus soluciones de seguridad de software se integren en los procesos de compilación, luego se revisen y se actúe con cada compilación.

Resolver exposición de código

Incorpore soluciones de prueba de seguridad de aplicaciones (AST) en todo su SDLC para administrar los riesgos inherentes a la exposición del código. Estas son algunas soluciones clave de seguridad de software que pueden ayudar a su equipo a resolver la exposición del código:

Pruebas de seguridad de aplicaciones estáticas

Qué buscar: capacidad de escanear automáticamente código sin compilar / sin compilar e identificar vulnerabilidades de seguridad en los lenguajes de codificación más frecuentes.

Prueba interactiva de seguridad de aplicaciones

Qué buscar: capacidad para monitorear continuamente el comportamiento de la aplicación y encontrar vulnerabilidades que solo pueden detectarse en una aplicación en ejecución.

Análisis de código abierto

Qué buscar: capacidad de aplicar el análisis de código abierto como parte del SDLC y administrar los componentes de código abierto al tiempo que puede garantizar que los componentes vulnerables se eliminen o reemplacen antes de que se conviertan en un problema.

Desarrollador Software Seguridad Educación

Qué buscar: una plataforma interactiva y atractiva de capacitación en seguridad de software integrada en el entorno de desarrollo, agudizando las habilidades que los desarrolladores necesitan para evitar problemas de seguridad, corregir vulnerabilidades y escribir código seguro.

Servicios profesionales y gestionados

Qué buscar:   un equipo confiable de asesores que puedan ayudar a las organizaciones de desarrollo a transformar sus iniciativas DevOps agregando seguridad en todo su SDLC.

Con la información que proporcionan estas soluciones de seguridad de software, su equipo puede priorizar los problemas correctamente y resolverlos de manera oportuna.

aplicacion

¿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.

Abrir chat
1
Hola, soy Mónica, ¿te puedo apoyar con algo?