S-SDLC: Desarrollo Seguro

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 (+1) 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 parámetros de entrada

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

Se 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 fallos de autenticación, donde se podría interceptar una sesión, permitir el acceso a ficheros temporales o incluso lograr una escalada 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 para realizar técnicas de pivoting por 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 los 25 más comunes, ordenados de mayor a menor impacto en la seguridad.

• 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 fallos 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:

Fortify Taxonomía: errores de seguridad de software

Fallos históricos de software

• 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 estaba correctamente protegido o no se realizó un modelado de amenazas adecuado.
• Febrero 2019 se identifica una vulnerabilidad en el protocolo TLS V 1.3 que permite interceptar 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 coste, por lo que se recomienda integrar en el Ciclo de Vida de Desarrollo de Software una herramienta como Checkmarx o Kiuwan, que se especializan 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 estas herramientas 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.

Checkmarx

Herramienta especializada en análisis de código fuente para la detección de vulnerabilidades de seguridad. 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, este 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, algunos ejemplos:

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.

¿Sabías que el 80% de los ataques son llevados a cabo en la capa de aplicación? 

Kiwuan

Kiuwan es una herramienta de análisis estático de código basada en la nube (SaaS, Software as a Service), y con especial enfoque en la seguridad.

Los análisis del código hechos por Kiuwan están orientados a medir, analizar y verificar la calidad y seguridad de nuestro código fuente.

Kiuwan está pensado para cubrir las necesidades de varios perfiles implicados en los procesos de desarrollo de software, desde desarrolladores a ingenieros de calidad, pero también IT Managers, responsables de tomar decisiones a partir de la información que la herramienta les proporciona.

Kiuwan tiene algo muy interesante, y es que nos permite realizar análisis estático del código fuente de manera local, mediante una pequeña aplicación descargable, o en la nube, subiendo el código a la propia plataforma.

Más cosas interesantes de la herramienta son:

• No requiere la instalación de software alguno en el puesto cliente, ni tampoco instalación en ningún servidor interno. Al ser una solución en la nube, simplemente necesitamos ir al sitio web de Kiuwan, registrarnos, y empezar a analizar nuestro código. La prueba es 100% funcional durante 15 días, y nos permite analizar hasta 15.000 líneas de código. Ya la tenemos…
• Soporta las tecnologías más significativas: Objetive-C, Android, Java, JSP, Javascript, PHP, C, C++, ABAP, COBOL, JCL, PL/SQL, Transact-SQL, SQL, Visual Basic, C#,  o VB.NET.
• Cuadros de mando diseñados para distintos tipos de perfiles (desarrollador, QA Manager, IT Manager).
• Exporta los resultados a diversos formatos (PDF, Excel, XML).
• Integración con Atlassian JIRA.

El primero es uno de los puntos más importantes. Al tratarse de una solución en la nube, podemos empezar a trabajar, con el 100% de funcionalidad, inmediatamente. Otras soluciones requieren de una máquina dedicada dentro de nuestra infraestructura, en la que tendremos que instalar el producto que queramos usar, ponerlo a nuestro gusto, instalar los plugins que queramos, si queremos alguno, y posteriormente tendremos que preocuparnos de administrar y actualizar la herramienta.

Indicadores de primer nivel en Kiuwan

Kiuwan visión de Defectos

Otro de los puntos que más conviene destacar de Kiuwan es la funcionalidad del análisis What-if. Esta funcionalidad nos permite que, una vez que hemos decidido dedicar cierto tiempo de desarrollo a mejorar la mantenibilidad de nuestra aplicación, por ejemplo, 2 desarrolladores durante 2 semanas, Kiuwan nos dará la lista de defectos sobre los que trabajar para que ese tiempo sea aprovechado al máximo.

Kiuwan nos permite crear un plan de acción, simplemente indicando cuánto tiempo podemos dedicar, y además podemos exportar esos defectos como tickets abiertos en JIRA, para que los desarrolladores puedan hacer un seguimiento de ellos.

Kiuwan. Funcionalidad What If

Introducimos en Total 40, y pulsamos en Simulate

En el Plan de Acción tenemos las tareas sobre las que los desarrolladores tendrán que trabajar.

En resumen, una herramienta muy interesante, y a tener muy en cuenta a la hora de realizar análisis estático de código. Además, una herramienta en constante mejora, y que nos promete entre otras cosas:

• Reducción de la Deuda Técnica.
• Reducción del número de Reentregas.
• Reducción del % de Esfuerzo del Mantenimiento.
• Reducción del Coste del Proceso de Desarrollo.
• Reducción del % de Código Duplicado.
• Reducción del % de Complejidad del código.
• Reducción del % Incidencias en Producción/Explotación.
• Mejora de los indicadores globales de las características software: Mantenibilidad, Fiabilidad, Eficiencia, Seguridad, Portabilidad.

Cuando se habla de seguridad, tal como se expone en el libro Writing Secure Code (anexo en Drive si quereis ampliar conociemiento) los atacantes tienen una ventaja sobre los desarrolladores, y lo exponen en cuatro principios que lo ilustran muy bien:

• Quien defiende debe preocuparse por proteger todos los puntos; el atacante va a seleccionar solo uno, el más débil.
• Los encargados de la defensa van a procurar defenderse de ataques conocidos; el atacante va a probar nuevas formas de llevar adelante sus ataques.
• Quien se encarga de defender debe de estar en constante estado de vigilancia; el atacante hará su movida cuando lo crea conveniente.
• El defensor debe respetar reglas; el atacante puede jugar sucio.

Teniendo en cuenta estos cuatro principios, podemos dimensionar lo importante que es tener un proceso de desarrollo seguro y formal en el que se tengan presentes los controles que garanticen la seguridad de la información.

Cuando escribimos sobre lo que muchos saben pero pocos aplican sobre desarrollo seguro, resaltamos lo necesario que es hacer un juicioso análisis de riesgos para poder enfocarse en los posibles puntos de fallo. 

Es así como al menos deberían tenerse en cuenta los siguientes 10 aspectos:

1. Partir siempre de un modelo de permisos mínimos, es mejor ir escalando privilegios por demanda de acuerdo a los perfiles establecidos en las etapas de diseño.
2. Si se utiliza un lenguaje que no sea compilado, asegurarse de limpiar el código que se pone en producción, para que no contenga rutinas de pruebas, comentarios o cualquier tipo de mecanismo que pueda dar lugar a un acceso indebido.
3. Nunca confiar en los datos que ingresan a la aplicación, todo debe ser verificado para garantizar que lo que está ingresando a los sistemas es lo esperado y además evitar inyecciones de código.
4. Hacer un seguimiento de las tecnologías utilizadas para el desarrollo. Estas van evolucionando y cualquier mejora que se haga puede dejar obsoleta o inseguras versiones anteriores.
5. Todos los accesos que se hagan a los sistemas deben ser validados.
6. Para intercambiar información sensible utilizar protocolos para cifrar las comunicaciones, y en el caso de almacenamiento la información confidencial debería estar cifrada utilizando algoritmos fuertes y claves robustas.
7. Cualquier funcionalidad, campo, botón o menú nuevo debe agregarse de acuerdo a los requerimientos de diseño. De esta forma se evita tener porciones de código que resultan innecesarias.
8. La información almacenada en dispositivos móviles debería ser la mínima, y más si se trata de contraseñas o datos de sesión. Este tipo de dispositivos son los más propensos a extraviarse y por lo tanto su información puede ser expuesta más fácilmente.
9. Cualquier cambio que se haga debería quedar documentado, esto facilitará modificaciones futuras.
10. Poner más cuidado en los puntos más vulnerables, no hay que olvidar que el nivel máximo de seguridad viene dado por el punto más débil.

Consideraciones:

Finalmente, es muy importante resaltar que un atacante necesita solamente un pequeño error, una vulnerabilidad para lograr su cometido. Si dentro de la empresa se descuidan los temas de seguridad por acelerar la operatividad del negocio, podemos estar dejando la puerta abierta a que se comprometa la seguridad de la información. Ser responsables con los procesos es la mejor defensa, y no está de más preguntarse si es mejor invertir unas semanas más en desarrollo, que perder reputación y dinero en un instante por un incidente de seguridad.

Recursos adicionales:

*Toda la información que contiene este post ha sido encontrada en Internet