Se prevé que la vulnerabilidad de software Log4j provoque graves problemas en Internet durante los próximos meses y años. La aplicación de parches se ha convertido en una carrera armamentística para las empresas y los organismos públicos. El éxito dependerá de la visibilidad de la red, la rapidez en la aplicación de parches y los flujos de trabajo.
Log4j es una herramienta de registro. Casi todos los servicios en la nube y redes empresariales del mundo lo utilizan para acceder a los servidores. Se trata simplemente de la última vulnerabilidad en la cadena de suministro de software (como la que se descubrió en el ataque a gran escala contra SolarWinds) que ahora afecta a nuestras vidas digitales.
Pero la verdad sobre estas vulnerabilidades de la cadena de suministro es la siguiente: pueden —y deben— controlarse antes de que puedan causar daños.
[Lea también: ¿Qué es Log4j y cómo puedo proteger a mi organización?]
A Nick Selby, antiguo director de seguridad de la empresa de servicios de blockchain Paxos, no le interesan los riesgos innecesarios en lo que respecta a la seguridad de la cadena de suministro de software y de la cadena de suministro. Por eso le preocupa la forma en que muchas organizaciones se protegen actualmente.
«Estamos intentando proteger los entornos modernos prácticamente de la misma forma que lo hacíamos hace 20 años, y esto está dando lugar a una interpretación totalmente errónea de la superficie de ataque», advierte Selby. «Es algo que el sector debe cambiar, y con urgencia», añade.
Gran parte de esa falta de comprensión se debe a la falta de visibilidad sobre los riesgos de seguridad que entrañan el software de terceros, los servicios de software en la nube y el software de código abierto. «El riesgo derivado de terceros, ya sea por vulnerabilidades en la cadena de suministro o en los componentes de software de terceros, sigue siendo un factor determinante en las infracciones provocadas desde el exterior», advirtió Sandy Carielli, analista principal de Forrester Research, durante el reciente « Security & Risk Forum 2021» de la empresa,. «Probablemente, las organizaciones cuenten con más terceros en su ecosistema que nunca», añadió.
Los ataques contra las cadenas de suministro de software de se han disparado durante la pandemia. Precisamente el verano pasado, la herramienta de gestión ágil de proyectos y seguimiento de errores de software de Atlassian presentaba un ataque de «un solo clic» que permitía a un pirata informático acceder al sistema de planificación ágil o a su repositorio de código, lo que hacía posible inyectar exploits en el código fuente de un usuario desprevenido.
Tal y como señaló Chris Condo, analista de seguridad de Forrester, en el foro sobre seguridad y riesgos organizado por dicha empresa: «Usted no sabría que alguien ha iniciado sesión y ha modificado su software». «Este es el tipo de problemas que se producen a diario».
Según la Agencia de Ciberseguridad de la Unión Europea (ENISA), es probable que los ataques a la cadena de suministro (no todos ellos hechos públicos) se hayan cuadruplicado en 2021 con respecto a 2020. Según señala la ENISA, en el 66 % de estos ataques, los atacantes se centraron primero en el código fuente del proveedor para poder dirigir sus ataques hacia el objetivo final.
Dado que los atacantes se centran cada vez más en los ataques de tipo «cadena de suministro», las organizaciones deben comprender cómo protegerse mejor. Considere esto como el primer paso en cualquier gestión de vulnerabilidades basada en el riesgo.
Adapte sus tácticas para hacer frente a los ataques cambiantes
Los ataques a la cadena de suministro están aumentando porque pueden afectar a grandes organizaciones que llevan décadas sin modificar su forma de mitigar los riesgos relacionados con la tecnología empresarial y los terceros. «Las empresas no se han adaptado a la forma en que las empresas modernas adquieren, desarrollan y gestionan la tecnología», afirma Selby, copresentador del podcast « : Tech Debt Burndown» ( ), quien recientemente dejó Paxos para incorporarse a Trail of Bits, una empresa de investigación y consultoría en ciberseguridad. «Seguimos llevando a cabo procesos de diligencia debida de terceros basándonos en hojas de cálculo elaboradas en el curso ’90s por contables».
«. Es probable que las organizaciones cuenten con más terceros en su ecosistema que nunca.»
Esas tácticas funcionaban en una época en la que el principal riesgo para la seguridad derivado de las infracciones cometidas por terceros era la divulgación de datos confidenciales o la interrupción de los servicios. Sin embargo, no dan la talla cuando se trata de riesgos procedentes de terceros que tienen como objetivo una incursión directa destinada a paralizar o bloquear su organización mediante ransomware. Una estrategia de gestión de vulnerabilidades basada en el riesgo debe tener esto en cuenta.
Así es como funcionan los ataques a la cadena de suministro. En lugar de atacar directamente a las organizaciones, los ciberdelincuentes y los hackers patrocinados por Estados se centran en los fabricantes de software y los proveedores de servicios de software. Inyectan código malicioso en programas informáticos que posteriormente utilizan otras organizaciones. Estos atacantes se centran específicamente en los procesos de desarrollo de software vulnerables y en las configuraciones en la nube inseguras, o bien se aprovechan de los procesos de actualización de software.
Tras el devastador ataque a SolarWinds, las autoridades federales han tratado de ayudar a los organismos públicos y a las organizaciones del sector privado a gestionar mejor los riesgos de la cadena de suministro de software . En el marco de la iniciativa « May 2021», el presidente Biden promulgó el decreto ejecutivo « » sobre la mejora de la ciberseguridad nacional, que exige a los proveedores que suministran software al Gobierno federal que incluyan una lista de componentes de software (SBOM) para todos los elementos de sus productos.
[Lea también: Qué supone el decreto ejecutivo de Biden para los directivos del sector tecnológico]
Una SBOM es como una receta de los componentes y las dependencias que componen una aplicación o un paquete de software, incluyendo tanto el código propietario como el de código abierto.
«El decreto ejecutivo establece una serie de medidas sin precedentes», declaró Alla Valente, analista de investigación sénior de Forrester, ante los asistentes al foro sobre seguridad y riesgos de la empresa. Aunque no es una solución milagrosa ni sustituye a unas buenas prácticas de ciberseguridad , la orden ha impulsado las iniciativas de seguridad en la cadena de suministro.
Allan Friedman está de acuerdo. Friedman, defensor de las listas de materiales de seguridad (SBOM) en la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), declaró en una mesa redonda de CISO organizada recientemente por SecurityWeek sobre la transparencia en la seguridad de la cadena de suministro de « » (): «Una de las cosas que más me interesan es mejorar el análisis y la vigilancia de la cadena de suministro».
Instalar un badén
La evaluación de los proveedores externos de servicios en la nube y de software comienza por comprender su nivel de madurez en materia de seguridad. Antes de que Selby entable contacto con un proveedor de software, comienza con una prueba sencilla y directa destinada a descartar a aquellos cuyos programas de seguridad no estén lo suficientemente desarrollados.
«En Paxos, contábamos con un cuestionario de 10 preguntas como evaluación preliminar, y resulta sumamente importante. «Hemos puesto esto en marcha como un obstáculo provisional, no como nuestra evaluación definitiva de seguridad o cumplimiento normativo», afirma.
«Si [su responsable de seguridad es] el vicepresidente de ingeniería, entonces no dispone de un programa de seguridad.»Nick Selby, antiguo director de seguridad de la información (CSO) de Paxos
Entre las preguntas preliminares se incluyen las siguientes: «¿Dispone de políticas y procedimientos de seguridad impresos y por escrito?». ¿Puedo verlos? Háblenme de su programa de entrenamiento. ¿Cuenta con un directivo designado cuya única responsabilidad sea la seguridad de la información?
«Si es así, y se trata del vicepresidente de ingeniería», afirma Selby, «entonces no dispone de un programa de seguridad». «Quiero oír: “Sí, cuento con un director de seguridad, un director de seguridad de la información y un responsable de seguridad de la información”; alguien que asuma la responsabilidad y rinda cuentas de garantizar la seguridad».
Una parte esencial de cualquier evaluación de seguridad de software de debería incluir también revisiones de código realizadas por terceros. Selby aconseja a las organizaciones que estén valorando la adquisición de software para la cadena de suministro que se centren en conocer el proceso de desarrollo de software del proveedor y las prácticas de programación segura de su equipo de ingeniería. «¿Imparte formación sobre programación segura? ¿Y en qué consiste exactamente?» pregunta Selby. «Cuéntenos cuál es su rutina de entrenamiento».
El hecho de superar un control de seguridad no implica que el proveedor vaya a obtener el contrato. Pero sí significa que han superado el umbral más básico y decisivo de las pruebas. «Al menos sabemos que confiamos en que van a superar nuestras pruebas de cumplimiento normativo, seguridad y aspectos legales», afirma Selby.
«Y eso es precisamente lo que, en mi opinión, deberían hacer las organizaciones: involucrar al departamento de seguridad desde el principio en los procesos de incorporación de nuevos proveedores». «Lamentablemente, las empresas siguen sin tener en cuenta la seguridad hasta el último momento».
El software de código abierto es gratuito, pero no está exento de riesgos
Para garantizar una seguridad adecuada de la cadena de suministro, también es necesario identificar y comprender qué servicios y programas de software, tanto locales como en la nube, se están ejecutando en el entorno de red. «Se trata de un reto más complejo de lo que podría parecer a primera vista», afirma Selby.
El uso de componentes de código abierto complica aún más la tarea. «A medida que las organizaciones utilizan el código abierto para crear aplicaciones, o lo incorporan en software disponible en el mercado —que a su vez puede contener hasta un 90 % de código abierto—, están introduciendo en su entorno un nivel alarmante de riesgo derivado de terceros», declaró Valente ante el foro sobre seguridad y riesgos.
«El software disponible en el mercado contiene hasta un 90 % de código abierto, lo que supone un riesgo de terceros alarmante.»
La gestión de los riesgos relacionados con el software de código abierto exige que los equipos de seguridad examinen minuciosamente el código del software. Esto no significa limitarse a comprobar si existen vulnerabilidades conocidas y dar por hecho que todo está en orden si todos los parches de están actualizados.
«La mayoría de las veces, eso es lo que ocurre» en una revisión del equipo de seguridad, afirma Selby. «Comprueban si existen CVE [vulnerabilidades y exposiciones comunes] en el proyecto de código abierto y, si no hay ninguna vulnerabilidad crítica, lo consideran aceptable». «Eso es una locura».
En cambio, los equipos de seguridad deben analizar todos los componentes y las dependencias de software de un proyecto de código abierto, y comprender cómo se han evaluado y probado los distintos componentes en busca de vulnerabilidades de seguridad.
«El código abierto significa que el código fuente está a su disposición para que lo utilice, lo evalúe y lo mejore», afirma Selby. «El código abierto no significa que haya que aceptarlo tal cual o dejarlo».
La seguridad de la cadena de suministro de software en la práctica
Si bien el decreto presidencial del presidente Biden establece nuevos requisitos para que los organismos federales mejoren sus programas de seguridad —como la implantación de un modelo de «confianza cero» ( ), la mejora de las estrategias de seguridad en la nube y la implantación de listas de materiales de seguridad (SBOM)—, el Instituto Nacional de Estándares y Tecnología (NIST) está trabajando para que esas herramientas se hagan realidad.
“Stop using the same spreadsheets that procurement weasels have used since the ’90s.”Nick Selby
Durante un taller celebrado recientemente, el NIST revisó las actualizaciones de su publicación especial « » (SP 800-218). Publicado en September 2021, en él se detallan una serie de prácticas fundamentales de alto nivel para el desarrollo de software seguro que las organizaciones pueden integrar en sus ciclos de vida de desarrollo de software. Las directrices definitivas sobre el uso de las SBOM se publicarán en February 2022.
Por otra parte, la Administración Nacional de Telecomunicaciones e Información (NTIA) ha definido recientemente los elementos mínimos que deben incluir las SBOM. Estos deben incluir el nombre del fabricante del software, los datos de versionado del software, formas únicas de identificar los componentes del software, un catálogo de las dependencias entre los componentes y un registro de quién elaboró la SBOM y cuándo lo hizo. La NTIA ha reconocido tres estándares abiertos para compartir información sobre la lista de componentes de software (SBOM): SPDX, CycloneDX y SWID.
Los analistas afirman que cada uno de estos tres estándares presenta diferencias. Mientras que SWID está diseñado para realizar un seguimiento de las licencias de software y los derechos comerciales, SPDX abarca las licencias, los componentes de software, la información de seguridad y otros metadatos. Al mismo tiempo, el estándar CycloneDX está orientado a la seguridad del software.
««CycloneDX está diseñado específicamente para abordar una amplia gama de casos de uso en materia de ciberseguridad que van mucho más allá de los requisitos mínimos publicados por la NTIA», afirmó Steve Springett en la reciente mesa redonda de CISO organizada por SecurityWeek. Springett es presidente de CycloneDX SBOM Standard, un grupo de trabajo del Open Web Application Security Project (OWASP), la comunidad en línea que elabora artículos, metodologías, documentación, herramientas y tecnologías de libre acceso para la seguridad de las aplicaciones web.
[Lea también: ¿Está su agencia preparada para el fin de la vida útil del software?]
A medida que las normas sigan evolucionando, las organizaciones que deseen mejorar su eficacia en el desarrollo seguro de software tendrán que conformarse con lo que haya disponible. Estos procesos no son fáciles de poner en marcha, y las herramientas que sirven de ayuda están en constante evolución.
No obstante, es fundamental que las organizaciones empiecen a reforzar la seguridad de su cadena de suministro de software. «Las empresas deberían plantearse cómo sacar partido a su software actual, ya sea una [plataforma] de GRC o una plataforma de gestión de riesgos de terceros», declaró Valente ante los asistentes al foro.
Si bien la seguridad de la cadena de suministro de software comienza con un minucioso examen de los procesos de seguridad y del ciclo de vida del desarrollo de software seguro, los ciberdelincuentes y los Estados-nación seguirán lanzando ataques contra los proveedores de servicios y, a continuación, utilizarán estos como plataforma de lanzamiento para atacar a los clientes. Aquellos clientes que cuenten con las mejores prácticas generales de seguridad tendrán más éxito a la hora de garantizar la seguridad en sus organizaciones.
Esto implica conocer el software que se utiliza en su organización y mantenerlo actualizado con los parches correspondientes, llevar a cabo una buena gestión de la configuración , y disponer de capacidades eficaces de supervisión y de respuesta ante incidentes .
En cuanto a Selby, afirma que una de las medidas más importantes que pueden adoptar las organizaciones en estos momentos es abandonar lo antes posible las viejas formas de gestionar los riesgos relacionados con el software de terceros y la cadena de suministro.
“Stop using the same spreadsheets that procurement weasels have used since the ’90s,” he says. «Es hora de modificar estas preguntas para centrarnos en cómo gestionan estas organizaciones los riesgos para su entorno».
