NIST y el desarrollo seguro de software

La seguridad no es una cuestión meramente puntual, sino continua. Una casa puede ser segura en el momento de su construcción, pero si con el paso de los años no se cuida con diligencia, ni se implementan mejoras para protegerla, es posible que deje de serlo. Este ejemplo cotidiano puede trasladarse al ámbito de la ciberseguridad y a la protección del software. Por ello, el NIST ha desarrollado el Marco de desarrollo seguro de software (SSDF), una guía para ayudar a las compañías a implementar prácticas seguras en todo el ciclo de vida del software.

El National Institute of Standards and Technology de Estados Unidos (NIST) se ha convertido en un auténtico referente en materia de ciberseguridad. Sus guías y frameworks son empleados por compañías y profesionales de la ciberseguridad a nivel global. De tal forma que muchas de sus metodologías son consideradas estándares en todo el planeta. Al igual que pasa con el conocimiento generado por OWASP o CIS.

La digitalización de la economía y la sociedad ha generado una enorme cantidad de ventajas y oportunidades, tanto para las empresas, como para los ciudadanos. Sin embargo, también ha supuesto el aumento de la ciberexposición. Cuanto más digitalizada esté una compañía o una administración pública, más expuesta está a los ciberataques.

A ello cabe sumar el hecho de que las tácticas y técnicas de los agentes maliciosos son cada vez más sofisticadas y, potencialmente, más peligrosas.

Ambas cuestiones han incidido en el incremento de los ataques de cadena de suministro. Es decir, acciones maliciosas que buscan atacar a una compañía o a sus clientes, vulnerando el software de uno de sus proveedores.

A continuación, vamos a analizar el Marco de desarrollo seguro de software del NIST y su utilidad en la securización del software.

1. ¿Por qué y para qué usar el Marco de desarrollo seguro de software?

En febrero de 2022, el NIST publicó la versión 1.1. de su Marco de desarrollo seguro de software, indicando que dicho framework nace de una carencia detectada. El instituto considera que pocos modelos de ciclo de vida de desarrollo de software ahondan con la profundidad debida en la cuestión de la seguridad.

Muchos desarrolladores se centran, como no podía ser de otra forma, en la calidad del software que diseñan y producen, en su usabilidad, o en su complejidad técnica. Sin embargo, la seguridad no ocupa la posición central que debería tener a la hora de desarrollar software.

Este escenario abre la puerta a los ciberataques y permite la propagación de ataques de cadena de suministro que no solo buscan dañar a los productores de software, sino, sobre todo, a las empresas que los usan. Como se ha demostrado en ataques de cadena de suministro célebres contra empras de software como Solarwinds Orion, Kaseya o Ledger.

Frente a este peligroso panorama, el NIST propone, con su Marco de desarrollo seguro de software, implementar una serie de buenas prácticas a lo largo de todas las fases del ciclo de vida del software.

Mediante este Marco de desarrollo seguro de software se busca:

1. Reducir el número de vulnerabilidades en el software presente en el mercado.
2. Mitigar el impacto que podría tener la explotación de vulnerabilidades no subsanadas.
3. Analizar las causas raíz de las vulnerabilidades para prevenir futuras debilidades.
4. Facilitar la comunicación entre proveedores y consumidores de software y ayudar a las empresas a establecer sistemas de control del software de terceros que emplean.

2. Buenas prácticas para alcanzar resultados

Para alcanzar los objetivos que venimos de señalar, el Marco de desarrollo seguro de software propone cuatro recomendaciones que articulan, a su vez, el conjunto de buenas prácticas que conforman este framework:

• Las compañías deben asegurarse de que sus profesionales, procesos y herramientas están preparados para llevar a cabo un desarrollo de software seguro durante todo el ciclo de vida de las soluciones que producen.
• Las organizaciones deben proteger todos los componentes empleados en su software, atendiendo especialmente a la manipulación de los mismos, así como ante accesos no autorizados.
• Las empresas tienen que producir software seguro no solo en las primeras fases del ciclo de vida, sino también en todas las versiones de sus soluciones, reduciendo las vulnerabilidades al mínimo.
• Las compañías han de ser capaces de identificar vulnerabilidades residuales en las versiones del software y contar con mecanismos eficaces para subsanarlas.

La estructura del Marco de desarrollo seguro de software es muy sencilla e intuitiva. Cada recomendación se traduce en una serie de prácticas. La guía define cada práctica y establece las tareas que se deben llevar a cabo para implementarla.

Asimismo, para facilitar su uso por parte de cualquier tipo de empresa, el Marco de desarrollo seguro de software incluye ejemplos prácticos de implementación de las prácticas y las tareas. Finalmente, incorpora las referencias empleadas en su diseño y que pueden ser útiles a la hora de poner en marcha el Marco de desarrollo seguro de software, entre las que se incluyen materiales de referencia como los estándares de OWASP o las guías CIS.

Todo ello convierte al Marco de desarrollo seguro de software en una metodología abierta, que no está centrada en establecer cómo se deben implementar las buenas prácticas, sino que está enfocada en la consecución de resultados.

2.1. Preparar a la organización

Todas las acciones que acometemos en nuestra vida requieren una preparación. Comúnmente se dice que nadie nació aprendido, a ello podríamos sumar el hecho de que nadie nace preparado.

La preparación de una empresa para facilitar que el software que desarrolla es seguro, requiere implementar cinco prácticas:

1. Definir los requisitos de seguridad para el desarrollo de software. Para ello es necesario recopilar tanto fuentes internas, por ejemplo, la estrategia de gestión de riesgos de seguridad, como externas, tal como la normativa en vigor que se debe cumplir. Asimismo, es necesario comunicar estos requisitos a los proveedores de componentes de software que van a ser utilizados en el software propio de la compañía.
2. Establecer funciones y responsabilidades. Es importante que tanto los profesionales internos, como los externos, tengan claro cuál es su papel, reciban la formación adecuada y asuman sus responsabilidades a lo largo de todo el ciclo de vida del software.
3. Implementar cadenas de herramientas de apoyo. La automatización juega un papel esencial en la protección del software en todo su siclo de vida. Ayudando a los profesionales a detectar vulnerabilidades, optimizar las prácticas y documentarlas.
4. Definir y usar criterios para verificar la seguridad del software durante todas sus fases de desarrollo.
5. Poner en marcha y mantener entornos seguros para el desarrollo de software. Es fundamental asegurarse de que todos los componentes de los entornos están protegidos, tanto frente ataques externos como internos.

2.2. Proteger el software

Además de poner en marcha prácticas de trabajo y organización seguras, es crucial proteger el código del software y contar con protocolos y metodologías para verificar la seguridad de cada versión del software:

1. Proteger el código frente al acceso no autorizado y evitar su manipulación. Los cambios no autorizados del código pueden anular las características de seguridad implementadas o introducir nuevas vulnerabilidades y, además, el acceso indebido puede facilitar la búsqueda de vulnerabilidades por parte de los delincuentes e, incluso, conllevar el robo del software o el código fuente y atentar contra la propiedad intelectual.
2. Establecer un mecanismo para verificar la integridad de cada versión del software. No solo es importante que la organización verifique internamente la seguridad de cada versión que lanza, sino que los compradores también deben contar con los mecanismos necesarios para asegurarse de que el software que adquieren es legítimo y no ha sufrido ningún tipo de manipulación.
3. Recopilar y archivar cada versión de software para detectar y subsanar vulnerabilidades. Si se documenta y conserva cada versión lanzada, se facilita la posibilidad de analizar, mitigar y eliminar vulnerabilidades descubiertas después de que la versión haya sido publicada.

2.3. Producir software bien protegido

Este grupo contiene el mayor número de prácticas a implementar:

1. Diseñar el software para cumplir con los requisitos de seguridad y mitigar los riesgos. Tener en cuenta los requisitos y riesgos desde la fase de requisitos y diseño del software es clave para mejorar el desarrollo.
2. Revisar el diseño para verificar que se cumplen con los requisitos y se informa sobre los riesgos de forma debida.
3. Reutilizar software previo y que esté bien protegido, cuando sea factible, en vez de reimplementar funcionalidades. Esto no solo reduce los costes y los tiempos de desarrollo, sino que disminuye la posibilidad de introducir nuevas vulnerabilidades al software.
4. Emplear prácticas de codificación segura a la hora de crear código fuente del software.
5. Configurar los procesos de compilación, interpretación y construcción con el objetivo de mejorar la seguridad de los ejecutables. De nuevo, esta práctica permite reducir costes y vulnerabilidades.
6. Realizar una auditoría del código fuente (SAST), los scripts y demás código legible por humanos para buscar vulnerabilidades y asegurarse del cumplimiento de los requisitos de seguridad antes de que el software sea liberado.
7. Testear el código ejecutable previamente a su puesta en producción para detectar vulnerabilidades y comprobar el cumplimiento de los requisitos de seguridad antes de que el software sea liberado y que las vulnerabilidades puedan ser identificadas y explotadas. En este sentido la ejecución de pruebas DAST (Dynamic application security testing) juegan un papel fundamental.
8. Configurar los parámetros del software de forma segura. El objetivo es que, en el momento de la instalación, el software no sea desplegado con configuraciones de seguridad débiles, susceptibles de ser atacadas de forma exitosa. En este sentido, se pueden ejecutar auditorías de seguridad de infraestructura o servicios de pentesting previamente a la puesta en producción.

2.4. Identificar y responder a las vulnerabilidades

El último de los grupos de prácticas que componen el Marco de desarrollo seguro de software se centra en las vulnerabilidades que las soluciones pueden tener y cómo subsanarlas:

1. Buscar y detectar las vulnerabilidades de forma continua, de cara a identificarlas lo antes posible y poder remediarlas con mayor rapidez, en función del riesgo que supongan para la organización.
2. Evaluar, priorizar y subsanar vulnerabilidades.
3. Analizar las vulnerabilidades e identificar sus causas para reducir la aparición de más vulnerabilidades en el futuro.

3. ¿A quién va dirigido el Marco de desarrollo seguro de software?

A priori, podría parecer que la audiencia objetiva del Marco de desarrollo seguro de software son los productores de soluciones. Sin embargo, el alcance de esta metodología trasciende a esta tipología de actores.

De hecho, la guía del NIST que desgrana su Marco de desarrollo seguro de software define tres targets para los que este framework puede ser de suma utilidad: los productores y los compradores de software.

3.1. Los responsables dentro de las empresas que producen software

El primer target del Marco de desarrollo seguro de software son los propietarios y cargos directivos de las compañías que desarrollan software, los gestores de proyectos y los profesionales a cargo de la ciberseguridad de las empresas.

El Marco de desarrollo seguro de software opera, para estos perfiles de primer nivel, casi como un diccionario o una enciclopedia. Les facilita un lenguaje común para que puedan intercambiar información y comunicarse, con el objetivo de securizar el software a lo largo de su ciclo de vida.

Esto se debe, en gran medida, a que el Marco de desarrollo seguro de software del NIST no es un documento con una gran complejidad técnica, sino que ha sido diseñado para que pueda ser comprendido y empleado no solo por los desarrolladores de software, sino también por otros perfiles profesionales como los que señalamos anteriormente.

La implementación de las buenas prácticas que articulan esta herramienta no compete, solo, a los desarrolladores, sino que entran en juego otros actores, en especial, aquellos que cuentan con capacidad de decisión dentro de la compañía.

3.2. Los desarrolladores de software

Los profesionales que desarrollan software deben tener en cuenta las buenas prácticas recopiladas por el NIST y ejecutar las tareas propuestas para proteger el software a lo largo de su ciclo de vida. El instituto incluye en esta categoría a los desarrolladores de software comercial-off-the-shelf, vendedores de productos, desarrolladores de software gubernamental, de software a medida, equipos de desarrollo interno de las compañías…

El Marco de desarrollo seguro de software es lo suficientemente amplio como para ser útil a cualquier tipo de empresa, sin importar su tamaño, su sector económico o su nivel de madurez con respecto a la ciberseguridad. Y para ser empleado en todo tipo de desarrollo de software: aplicaciones web, móviles, SaaS, ICS, IoT… Sin importar las tecnologías, plataformas, lenguajes o entornos de programación empleados por los desarrolladores.

Todo esto es posible porque el framework no establece las metodologías y técnicas que se deben emplear para llevar a cabo cada práctica, sino que se centra, como ya señalamos antes, en los resultados. Dejando, así, que sean las empresas las que seleccionen los procedimientos que mejor se ajusten a sus recursos y necesidades para conseguir las metas propuestas por el Marco de desarrollo seguro de software.

Cabe señalar, también, que el Marco de desarrollo de software seguro no solo está pensado para que los productores lo implementen cuando ponen en marcha un nuevo proyecto de desarrollo. Sino que sus prácticas pueden servir para que una compañía pase de un modelo de desarrollo de software clásico a otro más moderno, ágil y, sobre todo, seguro.

3.3. Los compradores de software

Tanto las empresas como las administraciones públicas que adquieren software deben sentirse interpeladas por el Marco de desarrollo seguro de software del NIST aunque no sean ellas las encargadas de realizar dicho desarrollo. ¿Por qué?

1. Aunque no produzcan el software, lo emplean. Lo que implica que, mediante un ataque de cadena de suministro (supply chain attacks), una compañía puede ser víctima de un ciberataque sustentado sobre una vulnerabilidad del software que la empresa ha contratado. Toda estrategia de seguridad plenamente optimizada debe tener en cuenta los ataques de cadena de suministro y establecer medidas para analizar de forma continua la seguridad del software que usa la empresa.

2. Las buenas prácticas que conforman el Marco de desarrollo seguro de software pueden ser empleadas por las empresas y administraciones para evaluar a los proveedores de software antes de adquirirlos. Así como en lo que respecta a la gestión del software durante las diversas fases de su ciclo de vida.

Esta metodología ayuda a todas las organizaciones a comprender e interiorizar las prácticas que contribuyen a securizar el software con el que trabajan diariamente. Así como los riesgos asociados a no prestar atención a la seguridad de las soluciones de proveedores.

Al operar como un estándar, el Marco de desarrollo seguro de software del NIST se convierte en un manual que pueden consultar las empresas para constatar que sus proveedores implementan buenas prácticas en el desarrollo de software.

4. Combatir los ataques de cadena de suministro nos compete a todos

El Marco de desarrollo seguro de software del NIST evidencia, tanto en sus prácticas y tareas, como en la definición de su audiencia objetiva, que la securización del software es una tarea ingente que implica a múltiples actores.

Aunque las compañías que desarrollan software juegan un papel central en su protección frente a los ciberataques, el incremento de los ataques de cadena de suministro evidencian que las empresas que adquieren software también deben participar en la implementación de buenas prácticas para apostar por un desarrollo de software seguro.

La European Union Agency for Cybersecurity (ENISA) ha analizado los principales ataques de cadena de suministro de los últimos años, como los que han afectado a empresas como Mimecast, SITA o Accellion. Como fruto de este trabajo, la ENISA ha concluido que:

• El 62% de los ataques se aprovecharon de la confianza en el proveedor por parte de la empresa cliente.
• El 66% de los ataques se centraron en el código de los proveedores de software como vía para atacar a las empresas clientes.
• El 58% de los ataques de cadena de suministro tenían como objetivo acceder a datos confidenciales: información personal de los clientes de las empresas, propiedad intelectual…

¿Qué aprendizajes podemos extraer de estas conclusiones?

• Las compañías no pueden confiar ciegamente en sus proveedores, sino que deben asegurarse de que estos emplean buenas prácticas en materia de seguridad, para lo que es de gran utilidad el Marco de desarrollo seguro de software del NIST, como ya hemos señalado.
• Verificar de forma continua el código del software es crucial para detectar vulnerabilidades antes de que sean explotadas por los delincuentes.
• La protección de datos es una cuestión central en el sector de la ciberseguridad en general, y en lo relativo al desarrollo seguro de software en particular.

4.1. Reducir la exposición ante ataques de cadena de suministro

A la luz de los datos que venimos de exponer, muchas compañías deben considerar contratar servicios par reducir la exposición ante los ataques de cadena de suministro. Dichos servicios deben ejecutarse en múltiples niveles, actuando tanto en las fases de desarrollo de software, como durante el despliegue o cuando ya se ha implantado en producción. Algunos de esos servicios son:

• Servicios SAST (Static Application Security Testing) /SCA (Software composition análisis).
• Identificación de vulnerabilidades en el software o posibles dependencias que hayan sido integradas como parte de la solución final.
• Análisis DAST (Dynamic Application Security Testing). Pruebas dinámicas automatizadas o manuales para garantizar que no se publican vulnerabilidades en entornos productivos o soluciones finales de software.
• Ejecución de auditorías de seguridad para la identificación de posibles vulnerabilidades, facilitando la ejecución del framework de desarrollo seguro de software.

4.2. Un trabajo continuo y que se expande en el tiempo

Como se ha demostrado en diversos ataques de cadena de suministro como Solorigate, las vulnerabilidades pueden surgir en una de las actualizaciones periódicas del software. ¿Qué evidencia esto? La necesidad de que los productores de software y las compañías que los consumen tengan en cuenta las buenas prácticas en materia de ciberseguridad de forma continuada, no solo en las primeras fases del ciclo de vida del software.

Las prácticas incluidas en el Marco de desarrollo seguro de software no están pensadas para ser ejecutadas una única vez, sino que algunas se deben realizar de forma continua (por ejemplo, analizar el código fuente). Mientras que otras han de ser reevaluadas de manera periódica (por ejemplo, la definición de los requisitos de seguridad). ¿Por qué?

Porque las tecnologías cambian a gran velocidad y los atacantes idean nuevas metodologías y tácticas para llevar a cabo sus acciones fraudulentas. Además, la normativa sobre ciberseguridad también se encuentra en plena expansión, como demuestran el reglamento DORA o la directiva NIS2.

Es más, este nuevo marco normativo de la UE presta especial atención a los proveedores IT de las compañías, puesto que los ataques de cadena de suministro han mostrado de manera práctica las consecuencias que pueden tener esta clase de incidentes de seguridad tanto en las empresas que adquieren software, como en sus propios clientes.

En definitiva, el Marco de desarrollo seguro de software del NIST es una metodología abierta, pensada para ser empleada no solo por los desarrolladores de software, sino también para los cargos directivos de las empresas y las compañías que adquieren software.

Este framework facilita la comunicación entre todos los actores de la cadena de suministro, así como la implementación de las mejores prácticas en materia de ciberseguridad a lo largo del ciclo de vida del software.