El software gobierna el mundo. Mantiene los aviones en el cielo, los hospitales en funcionamiento y garantiza que el sistema financiero mundial nunca pierda el ritmo. Pero cada vez más, estas aplicaciones se crean utilizando componentes de código abierto de diversas fuentes dispares. La complejidad es la nueva normalidad, ya sea software propietario o aplicaciones locales hechas a medida. Y la complejidad es enemiga de la seguridad.
Las complejas relaciones entre los componentes y la facilidad con la que los actores de amenazas pueden insertar malware en el código ascendente deberían ser motivo de preocupación para los administradores de seguridad. Las llamadas de atención han llegado con fuerza y rapidez en los últimos años. Es hora de encontrar una manera efectiva de gestionar la cadena de suministro de software riesgo.
Cómo funciona la cadena de suministro de software
Las cadenas de suministro son vías críticas a través de las cuales se dirigen las materias primas y los componentes antes de ser ensamblados, vendidos y utilizados. En el mundo digital, es mejor considerar estos componentes como servicios prestados del proveedor al cliente. Como nosotros discutido en un artículo anterior, estos proveedores de servicios son un objetivo de ataque cada vez más popular porque los actores de amenazas pueden generar un buen retorno de la inversión. Si ataca a un subcontratista de procesos de negocio o a un gigante de servicios de TI, tendrá la oportunidad de robar datos y/o extorsionar a un grupo potencialmente grande de clientes intermedios.
Una cadena de suministro de software es similar, pero en este caso, el sistema comprende los componentes, bibliotecas de códigos, herramientas y procesos necesarios para crear software. Al comprometer un solo componente, o incluso una aplicación completa, los atacantes pueden potencialmente afectar a cualquier desarrollador u organización que utilice ese software/componente.
¿Dónde está el riesgo?
Puede que el software esté dirigiendo el mundo, pero ¿qué implica exactamente crear las aplicaciones que impulsan todo, desde plataformas de comercio electrónico hasta sistemas ERP empresariales críticos? Cada vez más se trata de componentes de código abierto. A Informe sonatipo estima que solo en 2022, los desarrolladores realizaron 3.1 billones de solicitudes de dichos componentes de los cuatro principales ecosistemas de código abierto: Java, JavaScript, Python y .NET. El atractivo es que al descargar estos paquetes prediseñados, los desarrolladores pueden acelerar el tiempo de comercialización y ayudar a la empresa a responder más rápidamente a la demanda del mercado que cambia rápidamente. Es reclamado que el 80% del código de las aplicaciones modernas proviene de software de código abierto preexistente.
El desafío es que estos componentes, o “dependencias” de código abierto, a menudo contienen vulnerabilidades. Según Sonatype, el año pasado se descargaron 1.2 millones de dependencias vulnerables cada mes. Si se descargan sin querer, podrían presentar el riesgo de ser explotados por actores de amenazas en una fecha posterior. De acuerdo con la Fundación Linux, el proyecto de desarrollo de aplicaciones promedio contiene 49 vulnerabilidades en 80 dependencias directas.
Aún peores son las dependencias indirectas o transitivas, que según Sonatype representan seis de cada siete vulnerabilidades del proyecto. Estas dependencias son más difíciles de rastrear, ya que son efectivamente las bibliotecas y paquetes a los que llaman las dependencias directas; en otras palabras, dependencias de dependencias. Como resultado, no es inmediatamente obvio que una aplicación en particular los esté utilizando. Eso puede ocultar vulnerabilidades bajo una capa adicional de ofuscación.
Un ejemplo de ello es el infame Vulnerabilidades de Log4j. Log4j es una herramienta de registro poco conocida pero popular utilizada por más de 35,000 paquetes de software Java. A finales de diciembre de 10.0 se lanzó un parche para una vulnerabilidad crítica (CVSSS 2021) en la herramienta. Pero debido a su uso generalizado en todo el ecosistema de código abierto de Java, fue extremadamente difícil para muchas organizaciones encontrar y parchear definitivamente todas las instancias de Log4j. en su entorno. De acuerdo a Google, la mayoría de los paquetes Java afectados eran vulnerables porque Log4j era una dependencia transitiva difícil de encontrar.
"Cuanto más profunda esté la vulnerabilidad en una cadena de dependencia, más pasos se necesitarán para solucionarla", añadió.
Desafortunadamente, los actores de amenazas no perdieron el tiempo en explotar el error. De acuerdo a Verizon, un tercio (32%) de los análisis en busca de vulnerabilidades en sistemas expuestos el año pasado se realizaron durante los primeros 30 días después de su publicación.
Además del desafío de encontrar y reparar vulnerabilidades en componentes de código abierto, las organizaciones tienen el dolor de cabeza adicional de los paquetes maliciosos publicados en repositorios de código abierto por parte de actores de amenazas. Sonatype afirma haber registrado un aumento anual del 633% en dichos paquetes en 2022, hasta más de 88,000 instancias conocidas.
Otra amenaza: software propietario
Sin embargo, el riesgo de la cadena de suministro de software no se limita al código abierto. Los productos comerciales propietarios pueden contener vulnerabilidades que los ataques podrían explotar y lo hacen regularmente. También pueden incluir buggy componentes y herramientas de código abierto, como Log4j. De hecho, muy poco código que existe hoy en día puede describirse genuinamente como "propietario", según el director de defensa de desarrolladores de Sonatype, Steve Poole.
"Como resultado, los consumidores de aplicaciones aparentemente propietarias tienen una falsa sensación de seguridad y, por lo tanto, pueden ser vulnerables sin saberlo", le dice a ISMS.online.
En ataques más sofisticados, como la campaña SolarWinds, los actores de amenazas pueden incluso comprometer el propio entorno de TI del proveedor e insertar malware en actualizaciones de software legítimas. Esto permitió a los agentes estatales rusos comprometer varios departamentos del gobierno estadounidense.
“Cualquier tipo de software puede verse comprometido. El principal problema es una confianza implícita e injustificada en ese software”, argumenta Udo Schneider, evangelista de seguridad para Europa en Trend Micro.
Samuel Barfoot, líder del equipo de seguridad de Checkmarx, afirma que la madurez del proveedor de software y la acreditación ISO son vitales.
"Si bien el software en sí puede no estar diseñado para causar daño, si se infiltra, puede usarse para filtrar información", le dice a ISMS.online. “Al pasar a la nube, las organizaciones también enfrentan riesgos relacionados con los controles de los proveedores, el soporte, las copias de seguridad y la disponibilidad del sistema en caso de un ataque o una interrupción. La madurez del proveedor es crucial para mitigar estos riesgos mediante la preparación y las provisiones”.
La visibilidad es el primer paso hacia la gestión del riesgo
Ya sea que se trate de código propietario o de código abierto, las organizaciones que quieran mitigar el riesgo en la cadena de suministro de software deben primero obtener información sobre los componentes y subcomponentes "malos", según Schneider de Trend Micro. Esto se puede lograr solicitando una lista de materiales de software (SBOM).
“Un SBOM para un artefacto de software (biblioteca, ejecutable o incluso contenedor) contiene un gráfico de dependencia donde se enumeran todos los (sub)componentes de software utilizados, incluido un número de versión exacto. Los SBOM se pueden generar directamente desde la fuente dentro de un Canalización de CI / CD o más tarde, artefactos 'muertos' como ejecutables o incluso contenedores”, explica.
“Esto es particularmente útil para el software propietario donde el proveedor generalmente no proporciona SBOM. En jurisdicciones/verticales donde los proveedores deben proporcionar un SBOM, se pueden verificar continuamente contra vulnerabilidades conocidas, proporcionando una base actualizada para posibles acciones”.
Poole de Sonatype añade que las organizaciones también deberían evaluar la postura de seguridad de los proveedores, prestando especial atención a la calidad de sus procesos de informes de vulnerabilidades.
Para los componentes de código abierto, las organizaciones deberían ejecutar un programa de evaluación continua de los componentes de código abierto, parcheando/actualizando rápidamente cuando sea necesario para evitar una rápida explotación, argumenta. Las herramientas de análisis de composición de software (SCA) también pueden ayudar a descubrir qué hay dentro de los productos o componentes.
“Sin embargo, la sofisticación de la herramienta SCA debe igualar y superar a la de los malos actores, o la organización enfrentará el riesgo real de un ataque a través de un vector no detectado”, advierte.
"Finalmente, involucrar a los desarrolladores educándolos sobre cómo ocurren los ciberataques modernos y cuáles son los principios de codificación segura, y enséñeles sobre sus responsabilidades al comienzo de la cadena de suministro de software: sus elecciones y acciones inmediatas tienen consecuencias".
Comience con un SGSI
Schneider de Trend Micro sostiene que una sistema de gestión de seguridad de la información (SGSI) puede ser una excelente manera de mitigar el riesgo de la cadena de suministro de software de forma continua.
"Al introducir datos de las herramientas SBOM, enriquecidos con datos de distribución, en un SGSI, es posible evaluar mejor y documentar la situación de seguridad y, por tanto, el riesgo general de todo el sistema, del cual el software es sólo una parte", explica. "Cuando se utiliza como base para mitigar el riesgo y documentar las acciones tomadas, esto, en principio, proporciona una seguridad mucho mejor que el seguimiento manual de los activos de software".
Una lista de verificación para gestionar el riesgo de la cadena de suministro de software:
- Solicitar un SBOM
- Evaluar proveedores de software propietario (especialmente sus informes de vulnerabilidad)
- Utilice herramientas SCA para obtener información sobre los componentes de software
- Escanee continuamente en busca de vulnerabilidades y parchee rápidamente
- Educar a los desarrolladores sobre la importancia de la seguridad por diseño
- Considere introducir datos de SBOM en un SGSI para una gestión integral de riesgos
Descubra cómo la solución ISMS.online permite un enfoque simple, seguro y sostenible para la gestión de riesgos de la cadena de suministro y la gestión de la información con ISO 27001 y más de 100 marcos globales más.
