De acuerdo a una Informe de Gartner, hasta el 45% de las organizaciones en todo el mundo habrían experimentado un ataque a su cadena de suministro de software para 2025. Este tipo de ataque se está volviendo frecuente y difícil de abordar debido a los cambios en la forma en que se construyen los productos de software hoy en día.
Hoy en día, los ingenieros de software no tienen que crear aplicaciones desde cero. Tanto como 90% de una aplicación se puede construir con códigos de terceros, bibliotecas discretas y software de código abierto. Si bien este enfoque para el desarrollo de software ayuda a simplificar el proceso de creación de aplicaciones y ahorra una cantidad significativa de tiempo, también aumenta las amenazas y las vulnerabilidades de seguridad, ya que los paquetes maliciosos pueden entregarse a través de códigos y software de terceros.
En última instancia, es volviéndose cada vez más difícil para mantener la integridad de las cadenas de suministro de software. El reciente aumento de los riesgos en la cadena de suministro de software y las violaciones de alto perfil causadas por ellos demuestran cuán grave es el problema de las vulnerabilidades en la cadena de suministro.
En línea con esta tendencia, se ha vuelto imperativo que las organizaciones tomen medidas para garantizar la integridad y seguridad de su software. En esta publicación, exploraremos los riesgos comunes de la cadena de suministro de software y las diversas formas en que las organizaciones pueden mitigar estas vulnerabilidades y proteger su software de los ataques.
Las vulnerabilidades conocidas en las cadenas de suministro de software
El software de terceros puede plantear varias amenazas a la cadena de suministro de software. Los atacantes pueden utilizar varias formas de explotar las vulnerabilidades en los sistemas que dependen de este software de terceros. Algunos de estos métodos de ataque incluyen la introducción de código malicioso en el software, confusión de dependencias, typosquatting, etc.
Sin embargo, debido a la complejidad del desarrollo de software y la velocidad a la que se deben entregar nuevas aplicaciones en el mercado digital altamente competitivo de hoy, los ingenieros de software no tienen más remedio que confiar en herramientas de terceros y bibliotecas externas para crear aplicaciones lo más rápido posible. .
Se pueden introducir vulnerabilidades en las aplicaciones como resultado de:
- El código que escribes: malas prácticas de seguridad en el código personalizado que tú mismo escribiste
- Con qué construyes: las herramientas de desarrollo de software utilizadas para crear aplicaciones pueden verse comprometidas, exponiendo tu software a vulnerabilidades de seguridad.
- Lo que compra: algunas aplicaciones de software como servicio (SaaS) disponibles en el mercado que se utilizan para el desarrollo de aplicaciones pueden contener vulnerabilidades
- Qué utiliza: muchas aplicaciones dependen de bibliotecas de código abierto de terceros que pueden actuar como el eslabón débil de su cadena de suministro.
Teniendo en cuenta los numerosos eslabones débiles potenciales en cada cadena de suministro de software, las organizaciones deben ser proactivas para prevenir y remediar vulnerabilidades de la cadena de suministro de software. Para hacer esto, los ingenieros de software deben comprender estos riesgos o amenazas potenciales que sus proyectos de software pueden enfrentar. Algunas de estas amenazas incluyen:
Paquete de código malicioso integrado
Una de las cosas que hacen los atacantes en un ataque a la cadena de suministro de software es infectar los puntos finales afectados con software malicioso. Este malware podría ser un virus, ransomware, troyano o software espía que puede causar estragos en el software y los sistemas informáticos afectados.
Los atacantes suelen elegir objetivos cuyos sistemas tienen autorización de alto nivel en los dispositivos de los usuarios. Un ejemplo notable de un ataque como este es el ciberataque de 2021 sufrido por Kaseya, un desarrollador de soluciones de TI cuyos clientes incluían proveedores de servicios gestionados y clientes empresariales.
Una de las soluciones de TI clave que ofrece Kaseya es VSA, una herramienta unificada de administración y monitoreo remoto. El servidor VSA era altamente confiable en los dispositivos de los clientes y, al infiltrarse en él, los atacantes pudieron eludir los controles de autenticación en los clientes conectados. De esta manera, podrían cargar cargas útiles maliciosas sin obstáculos. El ataque a Kaseya es similar al El fiasco de seguridad de SolarWinds, donde los atacantes pudieron enviar actualizaciones maliciosas a miles de clientes, lo que los dejó expuestos a vulnerabilidades de seguridad adicionales.
Exfiltración de datos sensibles
Todo ataque con objetivo de robo de datos puede clasificarse como un ataque de exfiltración de datos. Se dice que la exfiltración de datos ocurre cuando un actor malicioso lleva a cabo una transferencia no autorizada de datos confidenciales desde un sistema de destino a una ubicación diferente. Un ejemplo notable de un ataque de exfiltración de datos que ocurrió como resultado de un ataque a la cadena de suministro fue el Ataque de noviembre de 2013 a Target, una de las empresas minoristas más grandes de Estados Unidos.
Los atacantes ingresaron a los sistemas de Target utilizando credenciales que habían robado de un proveedor externo. Este ataque les dio acceso no autorizado a la base de datos de servicio al cliente de Target, lo que les permitió capturar los nombres, números de teléfono, direcciones de correo electrónico, información de tarjetas de pago y otros datos confidenciales de los clientes. La información de las tarjetas de pago de 41 millones de clientes objetivo fue exfiltrada a los servidores del atacante, mientras que más de 60 millones de clientes vieron expuesta su información de contacto.
Ejecución remota de código
La ejecución remota de código (también llamada ejecución de código arbitrario) es un tipo de ciberataque en el que un atacante obtiene acceso para controlar el funcionamiento de un dispositivo o computadora de forma remota. Normalmente, el atacante inyecta código malicioso en un archivo, cadena o paquete completo que la víctima pretende ejecutar en sus sistemas. Esto permite al atacante lanzar un ataque a gran escala que puede comprometer una aplicación web o un servidor web completo. Dos formas comunes en que pueden ocurrir ataques de ejecución remota de código en ataques a la cadena de suministro de software son a través de Typosquatting y Dependency Confusion:
Typosquatting
Para ejecutar este tipo de ataque, los actores maliciosos suelen crear un paquete comprometido que es idéntico a las dependencias que desea instalar. Normalmente, el paquete malicioso tiene una ortografía ligeramente diferente. La intención es aprovechar una posible escritura incorrecta de un comando de instalación. El paquete malicioso funciona normalmente igual que la dependencia que el ingeniero pretendía instalar, pero también ejecuta un código malicioso que se ha incrustado en él al mismo tiempo.
Confusión de dependencia
La confusión de dependencias es otro enfoque que utilizan los atacantes para iniciar una ejecución remota de código en un ataque a la cadena de suministro de software. Con este tipo de ataque, los actores maliciosos crean un paquete en una biblioteca externa con el mismo nombre que un paquete de dependencia interna. Dado que ambas dependencias tienen el mismo nombre, el administrador de paquetes puede instalar el código malicioso en su lugar. Esto permite al atacante penetrar el entorno de integración continua/implementación continua (CI/CD) de la aplicación de software que se está desarrollando.
¿Cómo mitigar los riesgos en la cadena de suministro de software?
En los últimos años, los ataques a la cadena de suministro de software se han convertido en una de las mayores amenazas cibernéticas a las que se enfrentan las organizaciones de todo el mundo. Mitigar los riesgos de ataques como este se ha convertido en una parte importante de la seguridad cibernética y la gestión de riesgos en todas las organizaciones, especialmente aquellas que dependen de un software de terceros u otro. En lugar de confiar ciegamente en plataformas de terceros y repositorios públicos, es mejor tomar precauciones y llevar a cabo las comprobaciones necesarias sobre lo que se importa a su sistema. Al crear su plan de gestión de riesgos de la cadena de suministro de software, puede utilizar las siguientes formas de mitigar los riesgos de ataques a la cadena de suministro de software:
Audita tu software
Lo que hace que los ataques a la cadena de suministro sean tan difíciles de combatir es que el riesgo va más allá de sus propios sistemas. Para mitigar el riesgo de estos ataques, hay que hacer algo más que proteger su propio perímetro. En cambio, su estrategia debe centrarse más en garantizar que los sistemas de software externos conectados al suyo sean igual de seguros.
Sin embargo, esto suele ser difícil de lograr, especialmente cuando ni siquiera tienes suficiente información sobre los sistemas externos a los que estás conectado o las dependencias de código utilizadas dentro de tu aplicación. El primer paso para mitigar el riesgo de un ataque a la cadena de suministro es realizar una auditoría exhaustiva de su cadena de suministro de software.
Recientemente, tras el ataque a SolarWinds de 2020 que afectó a varias agencias gubernamentales de EE. UU., El gobierno federal de los Estados Unidos convirtió las auditorías de software en un requisito legal. por cada empresa que vende software a una agencia del gobierno de EE. UU. También deberías hacer lo mismo con todos tus sistemas. Mantener un registro claro de todas sus dependencias de software es la única forma de saber si su sistema está expuesto al riesgo de ataques a la cadena de suministro.
Además de auditar las dependencias de su software de inmediato, también necesita auditar su sistema nuevamente con cada nueva versión de su software. Es posible que también deba ir más allá de la auditoría manual y realizar una auditoría más exhaustiva que pueda identificar todo tipo de dependencias, incluidas las transitorias.
Auditoría automatizada
Además de auditar manualmente sus sistemas, es posible que también necesite configurar su auditoría en piloto automático. La automatización juega un papel clave a la hora de detectar vulnerabilidades en cualquier parte de su software. Los escaneos automatizados ayudan a descubrir rápidamente vulnerabilidades en el código de su software para que puedan abordarse antes de que el código entre en producción. El uso de código de terceros en el desarrollo de software seguirá creciendo y los actores maliciosos atacarán continuamente estos sistemas como un eslabón débil para lanzar ataques al software en la cadena de valor. La única manera de detenerlos es estar continuamente al tanto de la seguridad de su sistema auditándolo continuamente.
Prepare una lista de materiales de software
La lista de materiales del software (SBOM) se ha convertido en una de las formas clave de garantizar la seguridad de su software y mitigar los riesgos de la cadena de suministro. Este documento es un metadato formal legible por máquina que está diseñado para identificar todo el contenido de un paquete de software. También detalla otra información vital, como los datos de licencia y los derechos de autor de todos los componentes utilizados en la creación de un producto de software.
El concepto de preparar una lista de materiales no es completamente nuevo. Históricamente, tiene su origen en el mundo de la fabricación. Aquí, cada producto fabricado recibe una lista de materiales que sirve como inventario de todos los elementos incluidos en el proceso de fabricación de ese producto.
El mismo principio se puede aplicar a la gestión de riesgos de la cadena de suministro de software. El SBOM detalla la parte de su aplicación que creó desde cero, al mismo tiempo que enumera todas las partes que obtuvo de proveedores externos. De esta manera, cuando se descubre una vulnerabilidad, se puede rastrear fácilmente su origen.
Los SBOM están destinados a compartirse entre varias organizaciones que utilizan un componente de software. Esto proporciona transparencia sobre todos los componentes que utilizan todos los integrantes de una cadena de suministro de software. Como organización preocupada por la seguridad de su software, debe hacer de los SBOM una prioridad. Antes de agregar un componente a su producto de software, sería útil obtener una lista de materiales del proveedor. Esto facilitará la respuesta a los desafíos y vulnerabilidades de seguridad.
Desarrollar un marco de gestión de riesgos
Para mitigar los riesgos de ataques a la cadena de suministro de software, siempre es mejor adoptar un enfoque proactivo que esperar hasta que ocurra un ataque. Al describir de antemano los posibles escenarios de ataque, podrá acceder a su preparación para combatirlos en el futuro.
Como parte de sus esfuerzos de gestión de riesgos en la cadena de suministro de software, necesita desarrollar una forma de evaluar la probabilidad de que un atacante comprometa su sistema. De esta manera, podrá determinar las estrategias preventivas que debe adoptar para limitar estos riesgos, así como el plan de contingencia que debe implementar para abordar el riesgo.
Capacitar a todos los miembros de su organización sobre cómo responder a los ataques a la cadena de suministro es otra parte esencial de su marco de gestión de riesgos. Esto permitirá a todos estar alerta para anticipar tales ataques y responder adecuadamente si ocurren.
Conclusión
Los ataques a la cadena de suministro de software seguirán exponiendo a las organizaciones a diversas formas de riesgos. Por lo tanto, los ingenieros ya no pueden asumir que los paquetes de terceros que utilizan para crear, implementar y mantener sus aplicaciones de software son seguros y se mantienen adecuadamente. De hecho, la razón principal por la que los ataques a la cadena de suministro de software se han vuelto más comunes que antes se debe en parte a la mayor dependencia de códigos de terceros en la creación de aplicaciones de software. Para mitigar estos riesgos, debe hacer un inventario de su cadena de suministro de software e implementar medidas para minimizar el impacto de estas amenazas en su sistema a fin de evitar infracciones importantes y las consecuencias que las acompañan.