Hay algunas violaciones de seguridad que cambian la forma en que el sector concibe la seguridad. El ataque a SolarWinds fue una de ellas.
No fue solo la magnitud ni la sofisticación lo que lo hizo destacar. Fue darse cuenta de que las actualizaciones de software que las organizaciones consideraban seguras podían convertirse en el propio vector de ataque. Para muchas organizaciones, ese momento supuso una llamada de atención. Puso de manifiesto la enorme confianza implícita que existía en las cadenas de suministro de software y la escasa visibilidad que había una vez que el código quedaba fuera del control interno.
Años después, la incómoda pregunta sigue sin respuesta. ¿Cuánto ha cambiado realmente?
Cuando la confianza se convierte en vulnerabilidad
A finales de 2020, SolarWinds —un proveedor de software de gestión de TI muy utilizado— se convirtió en el epicentro de uno de los incidentes de ciberespionaje más importantes de la historia moderna. Los atacantes lograron comprometer el proceso de desarrollo de software de la empresa e insertaron código malicioso en sus actualizaciones. A continuación, miles de organizaciones descargaron dicha actualización como parte de su mantenimiento rutinario, lo que, sin saberlo, permitió a los atacantes acceder a los sistemas internos.
No fue solo la magnitud o la sofisticación lo que hizo que la brecha de seguridad llamara la atención. Fue darse cuenta de que las actualizaciones de software que las organizaciones consideraban seguras podían convertirse en el propio vector de ataque.
Lo más llamativo de la filtración no fue que los atacantes lograran acceder a un proveedor de software, sino que consiguieran llegar a miles de organizaciones sin tener que atacar a cada una de ellas por separado.
Tras introducir código malicioso en el proceso de compilación de SolarWinds, los atacantes lograron distribuirlo a través de una actualización de software de confianza que los clientes instalaron como parte de su mantenimiento rutinario. Desde el punto de vista de las organizaciones que la recibieron, todo parecía normal. La actualización procedía de un proveedor conocido, llegó a través de los canales oficiales y se implementó sin levantar sospechas.
Eso es lo que hizo que el ataque fuera tan eficaz. En lugar de aprovechar una deficiencia del cortafuegos o una vulnerabilidad sin parchear en cada entorno objetivo, los atacantes se valieron de la confianza que las organizaciones depositaban en su cadena de suministro de software.
Esto es lo que hace que sea tan difícil defenderse de los ataques a la cadena de suministro. Los mismos sistemas diseñados para agilizar las actualizaciones y mantener la integridad pueden convertirse también en el mecanismo a través del cual se introduce el riesgo.
El riesgo en el proceso de compilación
Los procesos de desarrollo modernos están diseñados para ofrecer rapidez y eficiencia. El código se escribe, se prueba, se integra y se implementa a un ritmo que habría sido impensable hace una década. Esa rapidez conlleva complejidad.
En el proceso intervienen múltiples herramientas, entornos y dependencias, cada uno de los cuales representa un posible punto de vulnerabilidad si no se protege adecuadamente. Cuando los atacantes consiguen acceder a un canal de compilación, no solo están comprometiendo un único sistema, sino que se sitúan en una posición previa en la que pueden influir en todo lo que pasa por él. Es aquí donde la firma de código cobra importancia, pero también puede resultar engañosa. Una actualización firmada transmite una sensación de seguridad, pero solo confirma que el código procede de una fuente de confianza. No garantiza que la fuente no haya sido comprometida.
Sin controles rigurosos sobre cómo se crea, se prueba y se firma el código, esa confianza puede resultar infundada.
El punto ciego en torno a las actualizaciones de software
Las actualizaciones de software están diseñadas para mejorar la seguridad. Por eso suelen implementarse con rapidez, a veces de forma automática, sin un control exhaustivo. El problema es que este proceso da por sentado que la propia actualización es segura.
En el caso de SolarWinds, y de otros ataques a la cadena de suministro que se produjeron posteriormente, el mecanismo de actualización se convirtió en el medio de distribución del código malicioso. Las organizaciones aplicaron la actualización como parte del mantenimiento rutinario, sin ser conscientes de que estaban introduciendo un riesgo en sus propios entornos. Esto pone de manifiesto una laguna. Si bien a menudo se presta mucha atención a la detección de amenazas externas, se dedica menos atención a supervisar lo que ocurre tras la instalación del software.
Sin una mayor visibilidad sobre el comportamiento de los sistemas tras una actualización, resulta difícil detectar cuándo algo no funciona correctamente.
Código externo, riesgo interno
Todas las organizaciones dependen de código externo de alguna forma, ya sea a través de software de terceros, bibliotecas de código abierto o servicios integrados. Esta dependencia es inevitable, pero genera una dependencia que no siempre se comprende del todo.
Una vez que el código externo entra en un entorno, a menudo se considera de confianza por naturaleza, sobre todo si procede de un proveedor reconocido. Esa suposición puede generar puntos ciegos, especialmente cuando los procesos de validación internos son limitados o inconsistentes.
La validación del código externo no implica desconfiar de todos los proveedores. Se trata de reconocer que el riesgo no desaparece por el mero hecho de que la fuente nos resulte conocida. La filtración de SolarWinds demostró que incluso los proveedores de buena reputación pueden formar parte de la cadena de ataque.
Por qué el modelo «Zero Trust» sigue pareciendo inalcanzable
El modelo «zero trust» se ha convertido en un concepto muy debatido en los años transcurridos desde el ataque a SolarWinds. La idea de verificar continuamente a los usuarios, los sistemas y los accesos, en lugar de basarse en la confianza implícita, tiene sentido en principio. En la práctica, su implantación ha sido más lenta de lo que muchos esperaban.
Parte del reto radica en la magnitud del cambio necesario. La transición a un modelo de confianza cero implica replantearse cómo se concede el acceso, cómo interactúan los sistemas y cómo se establece la confianza en toda la organización.
Para muchos equipos, esto supone un cambio significativo con respecto a las formas de trabajo habituales y requiere una coordinación entre departamentos, así como la voluntad de cuestionar supuestos arraigados desde hace tiempo. En consecuencia, el progreso suele ser gradual. Es posible que se introduzcan algunos elementos del modelo «zero trust», pero rara vez de una manera que aborde plenamente los riesgos que plantean los ataques a la cadena de suministro.
Las decisiones humanas que hay detrás de la tecnología
Aunque los ataques a la cadena de suministro suelen analizarse en términos muy técnicos, son las decisiones humanas las que determinan su evolución en cada etapa. Las decisiones relativas a la rapidez con la que se implementan las actualizaciones, el rigor con el que se revisa el código y el grado de visibilidad que se mantiene en todos los sistemas influyen en el nivel de riesgo.
Estas decisiones rara vez se toman de forma aislada. Están condicionadas por los plazos y las presiones operativas y, en ese contexto, la confianza se convierte en una necesidad práctica más que en un riesgo deliberado. El problema es que los atacantes comprenden esta dinámica. No necesitan burlar todos los controles si logran encontrar una forma de actuar dentro del flujo de la actividad normal.
¿Por qué no se han asimilado del todo las lecciones?
La filtración de SolarWinds puso de manifiesto una serie de problemas sistémicos, pero para abordarlos no basta con la concienciación. Se requiere una actuación coherente en múltiples ámbitos, desde la protección de los procesos de compilación hasta la mejora de la visibilidad del comportamiento del software, pasando por el refuerzo de los procesos de validación y la revisión de los modelos de confianza.
No se trata de soluciones rápidas. Implican cambios en la forma en que las organizaciones desarrollan, implementan y gestionan la tecnología a un nivel fundamental. Por eso puede parecer que el progreso es lento. Se comprenden las lecciones, pero llevarlas a la práctica diaria es mucho más complejo.
Avanzar sin confianza ciega
Reducir el riesgo en la cadena de suministro no significa eliminar por completo la confianza. Significa ser más selectivo a la hora de decidir en quién se deposita la confianza y cómo se verifica. Esto implica reforzar los controles en los procesos de desarrollo, mejorar la supervisión del comportamiento del software y garantizar que el código externo sea sometido a los niveles adecuados de escrutinio. También significa reconocer que la confianza no debe ser estática. Lo que en un momento dado se consideraba seguro puede dejar de serlo a medida que los entornos evolucionan.
Un enfoque más resiliente se centra en la validación continua, en la que las hipótesis se comprueban periódicamente en lugar de darse por sentadas.
Cómo puede ayudar MetaCompliance
En MetaCompliance, nos centramos en los comportamientos que subyacen a los riesgos de seguridad complejos, incluidos los que ponen de manifiesto los ataques a la cadena de suministro.
Las lecciones que se desprenden de incidentes como el de SolarWinds no son meramente técnicas. Ponen de manifiesto cómo las decisiones cotidianas, desde la implementación de actualizaciones hasta la gestión de las relaciones con terceros, pueden suponer un riesgo si no se comprenden en su totalidad.
Nuestro enfoque combina la formación específica en concienciación sobre seguridad con el análisis del comportamiento, lo que ayuda a las organizaciones a comprender cómo se manifiestan en situaciones reales los riesgos relacionados con el OWASP Top 10 y las vulnerabilidades de la cadena de suministro. Esto incluye comprender cómo se establece la confianza, en qué momentos puede romperse y cómo responder de forma más eficaz.
Al proporcionar a los equipos orientación práctica y contexto, ayudamos a las organizaciones a ir más allá de las respuestas reactivas y a desarrollar un enfoque más coherente y fundamentado para la gestión de riesgos.
A medida que las cadenas de suministro se vuelven cada vez más complejas, la capacidad de cuestionar las suposiciones y tomar mejores decisiones cobra cada vez más importancia.
Póngase en contacto con nuestro equipo hoy mismo para obtener más información.
Preguntas frecuentes sobre los ataques a la cadena de suministro
¿En qué consistió el ataque informático a SolarWinds y por qué fue tan importante?
El ataque a SolarWinds fue un grave incidente de seguridad en la cadena de suministro en el que los atacantes introdujeron código malicioso en una actualización de software legítima. Esto les permitió acceder a miles de organizaciones, entre ellas organismos gubernamentales y grandes empresas, sin despertar sospechas inmediatas. Su importancia radica en cómo puso de manifiesto los riesgos que conlleva confiar en las actualizaciones de software y en los proveedores externos sin una validación suficiente.
¿Qué es un ataque a la cadena de suministro en el ámbito de la ciberseguridad?
Un ataque a la cadena de suministro se produce cuando los atacantes comprometen a un tercero de confianza, como un proveedor de software, para obtener acceso a los sistemas de sus clientes. En lugar de atacar directamente a las organizaciones, los atacantes se aprovechan de las relaciones y dependencias entre empresas, utilizando a menudo actualizaciones o integraciones de software legítimas como punto de entrada.
¿Por qué las actualizaciones de software suponen un riesgo para la seguridad?
Las actualizaciones de software están diseñadas para mejorar los sistemas, pero pueden suponer un riesgo si el proceso de actualización se ve comprometido. Si se introduce código malicioso en una actualización, este puede difundirse ampliamente e instalarse automáticamente en las organizaciones que confían en la fuente. Sin una supervisión y validación adecuadas, estas actualizaciones pueden introducir amenazas sin ser detectadas.
¿Qué es el modelo «zero trust» y por qué es importante?
El modelo «zero trust» es un enfoque de seguridad que parte de la base de que no se debe confiar por defecto en ningún usuario, sistema o aplicación, incluso si se encuentran dentro de la red. Requiere una verificación continua del acceso y la actividad. Esto es importante porque reduce la dependencia de la confianza implícita, que a menudo se aprovecha en ataques como las brechas en la cadena de suministro.
¿Cómo pueden las organizaciones reducir los riesgos de seguridad en la cadena de suministro?
Las organizaciones pueden reducir los riesgos de seguridad en la cadena de suministro mejorando la visibilidad de su software y sus proveedores, reforzando los controles en torno a los procesos de compilación, validando el código externo de forma más exhaustiva y supervisando el comportamiento del sistema tras la implementación de las actualizaciones.
La adopción de principios como el «cero confianza» y la impartición de formación en materia de concienciación sobre seguridad también pueden ayudar a los equipos a tomar decisiones más fundamentadas en lo que respecta a la confianza y el riesgo.