En muchos sentidos, la cadena de suministro de software es similar a la de los productos manufacturados, que todos sabemos que se ha visto muy afectada por una pandemia mundial y la escasez de materias primas.
Sin embargo, en el mundo de las tecnologías de la información, no son la escasez o las pandemias los principales obstáculos a superar en los últimos años, sino los ataques destinados a dañar a cientos o incluso miles de víctimas simultáneamente. Si ha oído hablar de un ataque cibernético entre 2020 y hoy, es probable que la cadena de suministro de software haya jugado un papel.
Cuando hablamos de un ataque a la cadena de suministro de software, en realidad nos referimos a dos ataques sucesivos: uno dirigido a un proveedor y otro dirigido a uno o más usuarios intermedios de la cadena, utilizando el primero como vehículo.
En este artículo, profundizaremos en los mecanismos y riesgos de la cadena de suministro de software al observar una vulnerabilidad típica del ciclo de desarrollo moderno: la presencia de información de identificación personal, o «secretos», en los activos digitales de las empresas. También veremos cómo las empresas se están adaptando a esta nueva situación aprovechando los ciclos de mejora continua.
La cadena de suministro, en el corazón del ciclo de desarrollo TI
¿Qué es la cadena de suministro?
Hoy en día, es extremadamente raro ver empresas que produzcan software 100% internamente. Ya se trate de bibliotecas de código abierto, herramientas para desarrolladores, sistemas de implementación y entrega en las instalaciones o basados en la nube, o servicios de software como servicio (SaaS), estos componentes básicos se han vuelto esenciales en la fábrica de software moderna.
Cada uno de estos «ladrillos» es en sí mismo el producto de una larga cadena de suministro, lo que convierte a la cadena de suministro de software en un concepto que abarca todas las facetas de TI: desde el hardware hasta el código fuente escrito por desarrolladores, herramientas y plataformas de terceros, pero también almacenamiento de datos y todas las infraestructuras establecidas para desarrollar, probar y distribuir el software.
La cadena de suministro es una estructura en capas que permite a las empresas implementar fábricas de software altamente flexibles, que son el motor de su transformación digital.
La reutilización masiva de componentes y bibliotecas de código abierto ha acelerado drásticamente el ciclo de desarrollo y la capacidad de ofrecer funcionalidad de acuerdo con las expectativas del cliente. Pero la contrapartida de esta impresionante ganancia ha sido la pérdida de control sobre el origen del código que se incluye en los productos de las empresas. Esta cadena de dependencias expone a las organizaciones y sus clientes a vulnerabilidades introducidas por cambios fuera de su control directo.
Obviamente, este es un problema importante de ciberseguridad, y uno que solo aumenta a medida que la cadena de suministro se vuelve más y más compleja año tras año. Por lo tanto, no sorprende que los ataques cibernéticos a gran escala hayan podido explotarlo en su beneficio recientemente.
El riesgo del eslabón débil
Para los piratas informáticos, la cadena de suministro de software de las empresas representa un objetivo interesante por varias razones. En primer lugar, debido a su complejidad y al número de «ladrillos» que interactúan en el corazón de la fábrica de software, su superficie de ataque es muy grande. En segundo lugar, la seguridad de la aplicación, que históricamente se centró en proteger la aplicación en producción (es decir, expuesta al público), a menudo carece de la visibilidad y las herramientas para proteger eficazmente los servidores de compilación internos y otras partes de la tubería de CI/CD.
Además, es importante entender que la cadena de desarrollo actual está en continua evolución, agregando nuevas herramientas constantemente. Esta es una de las características definitorias del movimiento DevOps, que ha desdibujado enormemente la línea entre el desarrollo y las operaciones, dejando a los desarrolladores libertad para ofrecer funciones a sus clientes lo más rápido posible.
Sin embargo, estas opciones a menudo se implementan sin supervisión y pueden ser muy diferentes de un equipo a otro, incluso dentro del mismo departamento. La acumulación de herramientas, bibliotecas y plataformas ligeramente diferentes hace que sea muy difícil crear inventarios precisos que son la piedra angular de una gestión eficaz de la seguridad.
Finalmente, al explotar la cadena de suministro, los piratas informáticos encuentran formas de maximizar el impacto y, por lo tanto, el rendimiento de un ataque. Para entender esto, debemos considerar que los productos y servicios de la cadena de suministro de una empresa de servicios de software son los componentes básicos de otras cadenas de suministro. Un atacante que se ha infiltrado con éxito en un eslabón de una cadena puede comprometer a toda la base de usuarios, lo que puede tener consecuencias desastrosas.
El auge de los ataques a la cadena de suministro
En el ataque de SolarWinds, entre marzo y junio de 2020, aproximadamente 18 000 clientes de la plataforma Orion, incluidas varias agencias gubernamentales de EE. UU., descargaron actualizaciones con código malicioso inyectado en ellas. Este código otorgó acceso de puerta trasera no autorizado a sistemas y redes privadas. SolarWinds no descubrió la brecha hasta diciembre de 2020. Se produjo un escándalo internacional.
Unas semanas más tarde, en enero de 2021, un atacante obtuvo las credenciales utilizadas en la creación de imágenes de Docker con el software Codecov, debido a un error en el proceso de compilación. Estas credenciales permitieron al atacante secuestrar Codecov, un software para probar la cobertura del código de los desarrolladores, y convertirlo en un verdadero caballo de Troya: dado que el software se usa en entornos de integración continua (CI), tiene acceso a las credenciales secretas de la compilación. procesos (volveremos a esto).
Por lo tanto, el atacante pudo desviar cientos de credenciales de los usuarios de Codecov, lo que le permitió acceder a la mayor cantidad de sistemas seguros. La empresa solo detectó la brecha unos meses después, en abril.
El 2 de julio de 2021, unos noventa días después, un sofisticado grupo de ransomware aprovechó una vulnerabilidad en los servidores de Kaseya Virtual System Administrator (VSA), que afectó a aproximadamente 1500 pequeñas empresas. Kaseya es un desarrollador de software de administración de red, sistema e infraestructura utilizado por proveedores de servicios administrados (MSP) y otros contratistas de TI. Aunque un ataque de ransomware tomó el control de los sistemas de los clientes, el ataque fue contenido y derrotado después de unos días.
Pero esta no es la mayor vulnerabilidad de la cadena de suministro de 2021. En diciembre de 2021, unos meses después del incidente de Kaseya, ocurrió lo que posiblemente sea el ataque más simple pero más extendido en la cadena de suministro de software. Después de que se revelara una prueba de concepto (POC) inicial, los atacantes comenzaron una explotación masiva de una vulnerabilidad que afectaba a Apache Log4j, una biblioteca de registro de código abierto extremadamente popular en el ecosistema de Java.
Aunque se propuso una actualización que solucionó el problema con relativa rapidez, el hecho de que esta biblioteca, mantenida por solo un puñado de personas, se use a gran escala en todo el mundo, y rara vez de manera transparente, ha creado una enorme superficie de ataque que tardará años en resolverse: la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) acaba de describirlo como » endémico «, lo que significa que probablemente resurgirá en la próxima década.
A pesar de su magnitud, esta vulnerabilidad está lejos de ser un caso aislado: el número de ataques que utilizan el ecosistema de código abierto como vector de propagación para llegar a las cadenas de suministro se ha incrementado en un 650% entre 2020 y 2021 . La Agencia Europea de Ciberseguridad (ENISA) predice que los ataques a la cadena de suministro se cuadruplicarán para 2022 .
Todos estos ataques y vulnerabilidades han puesto de manifiesto la falta de visibilidad y herramientas para proteger eficazmente la cadena de suministro, ya sean sistemas para inventariar el uso de componentes de código abierto, para verificar su integridad o para evitar la fuga de información confidencial. En este último punto, es importante dar un paso atrás y observar más de cerca este elemento clave de la seguridad.
La clave de la cadena de suministro: secretos
Conseguir credenciales no cifradas es la manera perfecta para que un pirata informático gire y avance en la cadena de suministro desde un proveedor hasta sus clientes: con credenciales válidas, los atacantes operan como usuarios autorizados y la detección posterior a la intrusión se vuelve mucho más difícil.
Desde un punto de vista defensivo, los secretos codificados son un tipo único de vulnerabilidad. El código fuente es un activo con muchas fugas porque, por naturaleza, está destinado a ser clonado y distribuido con frecuencia en varias máquinas. De hecho, los secretos del código fuente viajan con él. Pero aún más problemático es que el código también tiene una ‘memoria’.
Hoy en día, cualquier repositorio de código se gestiona a través de un sistema de control de versiones (VCS), normalmente Git , que mantiene una línea de tiempo perfecta de todos los cambios que se han realizado en los archivos de la base de código, a veces durante décadas. El problema es que los secretos aún válidos pueden ocultarse en cualquier parte de esa línea de tiempo, lo que abre una nueva dimensión, esta vez histórica, a la superficie de ataque del software.
Lamentablemente, la mayoría de los análisis de seguridad se limitan a comprobar el estado actual, implementado o próximo a implementarse del código fuente de una aplicación. En otras palabras, cuando se trata de secretos enterrados en una confirmación anterior o incluso en una rama nunca implementada, las herramientas tradicionales son completamente ciegas.
Solo el año pasado, se publicaron más de 6 millones de secretos en repositorios públicos solo en GitHUb: en promedio, 3 confirmaciones de cada 1000 contenían un secreto. Esto es un aumento del cincuenta por ciento con respecto al año anterior.
Una gran cantidad de estos secretos dieron acceso a los recursos corporativos. Es importante comprender que, incluso si la mayoría de los proyectos de código abierto alojados en GitHub son repositorios personales, es muy fácil para un desarrollador profesional publicar sin darse cuenta código que da acceso a recursos corporativos. Sucede regularmente!
Por lo tanto, no es sorprendente que un actor malicioso que busca llevar a cabo un ataque en la cadena de suministro de software observe de cerca los repositorios públicos en GitHub: tendría una buena oportunidad de descubrir fallas a mano, principalmente secretos presentes en la fuente. código que le permitiría autenticarse en un sistema sin despertar sospechas.
Una vez que se publica un secreto, debe considerarse inmediatamente como comprometido: un simple experimento consiste en publicar voluntariamente un » canary token «, es decir, un código que tiene la apariencia de un secreto válido, con un mecanismo de alerta que se activa cuando se usa. ¡El tiempo entre la publicación y la alerta es de 4 segundos en promedio! Este espacio es monitoreado de cerca y explotado activamente.
Para neutralizar el riesgo de intrusión lo antes posible, solo existe una solución: la revocación inmediata del secreto. Pero, por pánico o falta de conocimientos técnicos, algunas personas intentan encubrir el error agregando un commit que borra el secreto, lo que no mitiga en absoluto la falla de seguridad: de hecho, Git realiza un seguimiento de todo el historial de código agregado, modificado o eliminado con el tiempo. En la práctica, esto significa que es difícil borrar todos los rastros de un error pasado. También significa que, en muchos casos, el secreto seguirá estando disponible en línea incluso después de que haya sido eliminado del estado «final» del código.
Pero los problemas no acaban ahí. En nuestro escenario, a medida que el archivo que contiene el secreto se reemplaza por un archivo «limpio», el secreto ya no será detectable ni durante la revisión manual del código por parte de un compañero (una práctica común), ni por las herramientas de seguridad de aplicaciones tradicionales, como escáneres, que también solo consideran la versión más reciente del código fuente. Peor aún, la falla se duplicará cada vez que se clone el código y, por lo tanto, corre el riesgo de propagarse en silencio durante mucho tiempo. En otras palabras, un regalo del cielo para los piratas informáticos.
El 3 de julio, el CEO del gigante de las criptomonedas Binance advirtió sobre una violación masiva que supuestamente filtró «mil millones de registros de residentes [chinos]» pertenecientes a la policía de Shanghái, incluidos «nombre, dirección, identidad nacional, teléfono celular, policía y registros médicos.» ¿La causa? Un fragmento del código fuente que contiene el secreto para conectarse a una base de datos titánica de información personal fue presuntamente copiado y pegado en un blog por los desarrolladores del CSDN chino.
La respuesta de las organizaciones: llevar la seguridad al ciclo de desarrollo
El surgimiento de DevSecOps
Las cadenas de suministro de software tienen muchas áreas grises que los métodos de seguridad tradicionales no abordan. Las organizaciones se han dado cuenta de la necesidad de introducir seguridad en el ciclo de vida del desarrollo que logre el equilibrio adecuado entre productividad y resiliencia.
Así nació el movimiento DevSecOps. DevSecOps consiste en insertar seguridad en las prácticas de DevOps. Como recordatorio, DevOps es una filosofía de desarrollo que reúne procesos y tecnologías que permiten a los desarrolladores cooperar de manera más efectiva con los equipos operativos. A menudo hablamos del pipeline DevOps (la columna vertebral de la cadena de suministro de software) que se caracteriza por su continuidad: se trata de poder integrar, probar, validar y entregar código en preproducción, de manera continua.
Los enfoques de seguridad tradicionales estaban en desacuerdo con la filosofía DevOps: entregar cada vez más rápido y adaptarse sobre la marcha. Hubo una fricción significativa entre los equipos de seguridad de aplicaciones y los equipos de desarrolladores, con culturas, experiencia y métodos muy diferentes. Esta división, fuente de muchos malentendidos, contribuyó en última instancia a la fragilidad del ciclo de desarrollo.
Para los administradores de seguridad, el desafío era mantener la velocidad de DevOps y al mismo tiempo reforzar la postura de seguridad mejorada: incluir reglas de seguridad desde las primeras etapas del ciclo de desarrollo (planificación, diseño), difundir las mejores prácticas y reducir el tiempo medio de remediación (MTTR) al capturar más fallas «benignas» antes.
Más que un método, es ante todo un ideal hacia el que las empresas quieren aspirar. El camino no es largo: las diferencias culturales son tenaces y, a menudo, tardan años en desaparecer. Se han propuesto varias vías para promover esta transición.
La primera vía es confiar en las herramientas modernas. Los desarrolladores adoptan herramientas intuitivas que se integran perfectamente con sus entornos de trabajo: la línea de comandos, la API, el IDE (Entorno de desarrollo integrado) o incluso su sistema de control de versiones (VCS). Hasta hace poco, las herramientas típicas del analista de seguridad estaban muy alejadas de este mundo, con una jerga muy específica y, a menudo, impenetrable. Los proveedores de software de seguridad han hecho grandes avances en esta área, ofreciendo a los desarrolladores la oportunidad de familiarizarse con los conceptos de seguridad y volverse autosuficientes en un área amplia.
La automatización también es clave para permitir la creación de sistemas de seguridad efectivos. Los ingenieros de software son especialistas en automatización, por lo que realmente no tenía sentido que no pudieran implementar, o incluso comprender, las reglas de seguridad que se les imponen para proteger la cadena de suministro. También son los que más conocen los sistemas que deben defenderse. La combinación de sus conocimientos con la experiencia de los ingenieros de seguridad permite el mejor uso de los recursos disponibles y, en general, equipos más felices.
Quizás el elemento más importante de DevDecOps es la idea de que la seguridad debe ser parte de todas las etapas del ciclo de desarrollo. Su seguridad no puede existir simplemente como una simple lista de verificación para marcar justo antes del lanzamiento de una nueva versión.
Para lograr este resultado, es fundamental abordar un concepto importante: la responsabilidad compartida.
La respuesta de las empresas para hacer frente a los nuevos riesgos de la cadena de suministro de software será, por tanto, tanto técnica como organizativa . La colaboración entre las diferentes profesiones que trabajan a lo largo de la cadena de suministro es ahora una prioridad para la seguridad de los sistemas de información.
Nota: este artículo está escrito y contribuido por Thomas Segura, escritor de contenido técnico en GitGuardian.
