Desarrollo Seguro, principios y cómo comenzar

En la actualidad existen metodologías y buenas prácticas, tal como SCRUM, DevOps, etc, para el desarrollo ágil de software, donde el objetivo es liberar el software lo más pronto posible, para cumplir con fechas de entrega y concretar la inversión del presupuesto, enfocándose en la funcionalidad del producto final. Sin embargo estos modelos en el Ciclo de Vida de Desarrollo de Software no ponen suficiente atención en la seguridad de Aplicaciones y dejan de un lado la  consideración vital  que debe tomarse en cuenta para no poner en riesgo los activos de la organización.

Los desarrolladores deben entender los errores más comunes en programación, ya que juegan un rol crucial en la construcción de software y en el buen o mal uso que se le pueda dar a las aplicaciones, los bugs pueden representar vulnerabilidades y éstas pueden ser aprovechadas por diversas entidades maliciosas que ponen en riesgo a la organización y la confianza en nuestro producto. Estos bugs son introducidos principalmente durante la etapa de desarrollo y se encuentran documentados bajo diversas investigaciones de grandes organizaciones, IEEE, OWASP, SANS. 

El no desarrollar de manera segura nos lleva a originar bugs que pueden volverse vulnerabilidades y representar un riesgo dentro de una organización, los errores más comunes de desarrollo se definen como Los Siete Reinos Perniciosos, que son la categorización de los errores más comunes que existen en el Ciclo de Vida de Desarrollo de Software, o SDLC por sus siglas en inglés, y que deben ser contemplados durante toda fase del SDLC, mismos que a continuación describo; sumándole a ellos un octavo reino que no es parte del desarrollo de software pero contempla todo lo que puede afectar el buen funcionamiento de nuestro producto.

1.- Validación de entrada y representación

Es de las vulnerabilidades más persistentes en el software lo causan metacaracteres, codificaciones alternadas, representaciones numéricas donde no son controladas correctamente las entradas y se confía en que el usuario las use correctamente. Todo input debe ser sanitizado y validado. Las vulnerabilidades que esto genera son: “Buffer Overflows”, “Cross-Site Scripting” attacks, “SQL Injection”, etc.

2.- Abuso de API

Este es un contrato entre quien realiza la petición y quién responde, sin embargo, el problema comienza cuando se viola el contrato. Quien realiza la petición la hace incorrectamente violando el contrato de funcionalidad. Los problemas que causa esta violación de contrato son: “Heap   Inspection”, “Directory Restriction”, “Unchecked Return Value”, etc.

3.- Características de seguridad

La seguridad del software, no es un software de seguridad. En este punto lo que debe tenerse claro, es que un número pseudoaleatorio no soportan ataques criptográficos, también el almacenar contraseñas en texto plano o codificarlas es un riesgo de seguridad o el no tener un control de acceso correcto puede llevar a la ejecución de paths. Se pueden tener diversos controles de seguridad, pero esto no asegura que nuestro software no sea vulnerable o esté siendo aprovechado para fines distintos.

4.- Tiempo y estado

Este refiere a la computación distribuida que se basa en estados y tiempos. Los sistemas actuales ofrecen características multi-core, multi-cpu o sistemas distribuidos, en los que dos eventos pueden tener lugar al mismo tiempo. Es importante estar consciente de que lo que se ejecuta y lo que pasa en realidad es muy diferente. Los eventos ocurren ocupando variables, sistemas de archivos y sobre todo cambios en memoria, caché, en todo lugar donde se almacene la  información. El no controlar estos eventos puede llevar a problemas de fallas de autenticación, donde se podría robar una sesión, permitir el acceso a archivos temporales o incluso lograr un escalamiento de privilegios.

5.- Errores

Los errores no controlados son comunes. Existen dos maneras de crear un error de seguridad. Errores no controlados correctamente y crear errores que brinden información. El correcto control de errores desde el desarrollo del software es de vital importancia ya que estos pueden brindar información útil o ser aprovechados como pivotes para un atacante.

6.- Calidad del código

Una calidad baja en el código puede producir comportamientos inesperados, lo que para un atacante es una ventaja que puede aprovecharse para comprometer el sistema.

7.- Encapsulación

Se tienen que crear límites fuertes. Esto quiere decir que se debe diferenciar la información validada y la que no lo es, así como lo que un usuario puede visualizar y lo que no debe de ver. El no encapsular correctamente la información significa un riesgo para la seguridad y privacidad.

8.- Ambiente

Este incluye todo lo que está fuera de nuestro código y es crucial considerarlo ya que son parte de nuestro producto. Dentro de este punto se consideran malas configuraciones del propio servidor, compilador, de la red, etc. Para poder evaluar nuestro ambiente es necesario realizar un modelado de amenazas correcto para así poder proteger nuestros activos.

Los errores más comunes en desarrollo de código que significan un riesgo para la seguridad llevan por nombre Enumeración de Errores Comunes o CWE. A continuación les comparto los 25 más comunes, ordenados de mayor a menor impacto en la seguridad.

Como bien se ha visto, se requiere de un gran esfuerzo para el análisis de código y la detección de  vulnerabilidades, por lo que es de suma importancia mencionar los Retos que se presentan para esta importante tarea.

• Complejidad: La existencia de diferentes lenguajes de programación interactuando y la cantidad de líneas de código. Por cada mil líneas de código existen de 5 a 50 bugs creados, por lo que para un Software con una gran cantidad de líneas de código, exige un enorme esfuerzo detectar estos bugs por un equipo de desarrolladores. Ejemplo de ello es la siguiente tabla, que muestra la cantidad de líneas de código por cada Software:

• Extensibilidad: La variedad de diferentes arquitecturas de hardware, diferentes sistemas operativos y parches. Las actualizaciones o parches de las dependencias de nuestro software puede cambiar su comportamiento, lo que significa para el equipo de desarrollo que debe modificar el código para que la funcionalidad del producto no sea afectada. Estos cambios implican que se hayan introducido nuevos bugs que deben ser detectados y remediados. 

• Conectividad: En la actualidad todo está conectado, comunicándose e interactuando de muchas maneras, esto no lo podemos controlar y es lo que hoy en día se conoce como Ciberespacio. El no realizar un correcto análisis de vulnerabilidades a nuestro código y la infraestructura de nuestro producto final representa un riesgo de seguridad.

La necesidad de realizar un análisis de código ya ha sido tomada en cuenta por diversas autoridades de distintos sectores como el sector bancario, el sector energético,  gobiernos, etc., que exigen que un software debe ser desarrollado de manera segura y éste debe cumplir con estándares de seguridad. Los estándares de seguridad, por mencionar algunos, son: PCI, FISMA, MITRE CWE, SANA 25, OWASP, etc.

La importancia de desarrollar software seguro va más allá de comprometer nuestra información. Los usuarios confían en la funcionalidad del producto por lo que se debe desarrollar un producto de calidad y confiable. Han existido fallas de software en diversas tecnologías a través de la historia, lo que demuestra la necesidad de desarrollar un producto seguro. Se pueden mencionar los siguientes casos:

Fallas de software en diversas tecnologías a través de la historia

• Mayo 1-2015 cuando se detecta un “buffer overflow” en un avión Boeing 787, que provoca que el sistema se apague, incluso si esté en vuelo. La primera solución es reiniciarlo cada 248 días.

• 2018 en México, se lleva a cabo un ataque a SPEI y roban 300 millones de pesos. Se aprovechan de la funcionalidad de la plataforma.

• Febrero 2018 Bangladesh, se realiza el robo de más de 80 millones de dólares a través de la plataforma Swift. El ambiente del banco no fue correctamente protegido o no se realizó un modelado de amenazas adecuado.

• Febrero 2019 se detecta la vulnerabilidad en el protocolo TLS V 1.3 que permite escuchar tráfico. El ataque aprovecha una fuga de canal lateral (side-channel leak) a través de los tiempos de acceso de caché de estas implementaciones, para romper los intercambios de claves RSA de las implementaciones TLS.

Retomando un sin fin de experiencias, queda claro que el no desarrollar un software de manera segura nos puede salir muy caro.

Realizar remediaciones de vulnerabilidades a un producto que ya se encuentra liberado, seguramente no estaba contemplado dentro del presupuesto del proyecto lo que reducirá las utilidades que se tenían previstas. La siguiente gráfica muestra el costo, las cifras económicas son representativas, de realizar estas remediaciones según la fase en la que se encuentre nuestro software. 

Podemos observar que durante la fase de desarrollo es donde más bugs son introducidos al código y que es aquí donde es más conveniente repararlos, en cambio en las etapas finales eleva mucho el costo, por lo que sugiero  integrar en el Ciclo de Vida de Desarrollo de Software una herramienta como Checkmarx, que se especializa en el análisis estático de código fuente para identificación de vulnerabilidades y así reducir los riesgos de seguridad en cualquier organización. La integración de esta herramienta a nuestro SDLC nos ayuda a automatizar la ardua labor de analizar nuestro código y no solo eso si no que tendremos un Ciclo de Vida de Desarrollo de Software Seguro, o S-SDLC,  y si nuestra organización se encuentra madura no solo tendremos un DevOps si no que ahora tendremos un SecDevOps.

Checkmarx

He utilizado esta herramienta especializada para llevar a cabo el retador trabajo de analizar código fuente para la detección de vulnerabilidades de seguridad. Además es importante remarcar que Checkmarx es líder en esta categoría en el cuadrante Gartner. El módulo de Checkmarx para realizar esta tarea lleva por nombre CxSAST, Checkmark Static Application Security Testing. El objetivo es asegurar el código desde el comienzo.

Checkmarx va más allá de analizar la correcta sintaxis de código y seguimiento de buenas prácticas de desarrollo, éste analiza el flujo de la información que nuestro código realiza y sobre estos flujos realiza el análisis de vulnerabilidades.

Checkmarx soporta diversos lenguajes de programación, por mencionar algunos:

Una de las características que hace diferente a Checkmarx, es que nos ofrece el mejor lugar para la reparación de vulnerabilidades. Esto nos ayuda a ahorrar mucho tiempo en la reparación y nos hace la vida más fácil indicándonos donde realizar la reparación del código y así solucionar los fallos desde el origen de la vulnerabilidad.
El esfuerzo de realizar un escaneo es mínimo ya que prácticamente solo tienes que cargar el código y Checkmarx lo analizará, no requiere dependencias externas que configurar, y es fácilmente integrable a diversos IDEs.

Checkmarx analiza 200 mil líneas de código por hora aproximadamente, dependiendo del hardware donde Checkmarx viva, lo que demuestra su gran capacidad de analizar enormes proyectos en busca de puntos débiles que hemos creado no intencionalmente, ¿o sí?...

El código puede vivir en diversos repositorios o File Systems. Checkmarx puede ir por él para automatizar y facilitar el análisis de vulnerabilidades.                                                                            

Al ser tan fácil de usar Checkmarx es capaz de integrarse a modelos de desarrollo ágil y DevOps, y nosotros podemos tener un SecDevOps muy fácilmente si ya contamos con un modelo DevOps, lo que nos ayuda a cumplir con nuestras fechas de entrega no solo de un producto funcional si no de un producto funcional y seguro.

Para poder adaptarse a modelos de desarrollo ágil, Checkmarx ofrece las remediaciones de las vulnerabilidades detectadas, podemos copiar y pegar la remediación, e incluso Checkmarx nos explica por qué es una vulnerabilidad.

Checkmarx ha sido desarrollado para facilitar el aseguramiento de nuestros desarrollos y hacernos la vida más fácil, podemos asignar y dar seguimiento a las vulnerabilidades para que sean reparadas por un desarrollador específico, podemos incluso crear nuestras propias reglas de escaneo personalizadas, así de flexible es Checkmarx.

¿Sabías que el 80% de los ataques son llevados a cabo en la capa de aplicación? asiste a nuestro webinar y conoce las nuevas tendencias de integración de seguridad en el desarrollo de código seguro de una forma eficiente.