¿Puedes confiar en las empresas que desarrollan el software que utilizas?

En los últimos 3 años se han hecho públicos, al menos, 6 casos de incidentes de seguridad relevantes relacionados con manipulación de software, como aquel incidente denominado NotPetya, allá por 2017.

Estos incidentes (que parecen estar ligados a un grupo chino que, según a la firma de investigación a la que se le pregunte, se le conoce como Barium, ShadowHammer, ShadowPad o Wicked Panda) nos han hecho darnos cuenta de que, no sólo debemos evaluar la seguridad de las compañías que se conectan a nuestros sistemas, y de aquellas otras que gestionan nuestra información, sino que también debemos conocer el nivel de seguridad de los sistemas internos de aquellas empresas que desarrollan el software que utilizamos.

Sí, sí. No nos hemos vuelto locos. Estos ataques que mencionamos, y que han venido a denominarse ataques a la cadena de suministro de software, no pueden ser fácilmente detectados por otra vía, pues los atacantes son capaces de vulnerar los sistemas de los desarrolladores hasta el punto de que las versiones manipuladas van firmadas con el certificado del desarrollador. Es decir, son indetectables para cualquier tipo de antivirus, cortafuegos u otras medidas habituales de protección, utilizando el propio proceso de parcheado como vector de ataque. O sea, que castigan a los que aplican buenas prácticas.

Este tipo de ataques llevan al extremo el concepto de seguridad en la cadena de suministro, puesto que al final no dejan de explotar una relación de confianza que tenemos con un tercero. En lugar de un proveedor de servicios externo, es un desarrollador externo. De hecho, supone una maximización de la "rentabilidad" del ataque, pues infectando a un desarrollador se puede llegar a cientos de miles o incluso a millones de usuarios (recordemos los casos del software de actualización de Asus o del conocido CCleaner. Ambos sufrieron ataques que afectaban a software firmado con certificado oficial de las empresa respectiva, lo que impedía que los sistemas de detección no hiciesen saltar las alarmas).

Existen incluso incidentes relacionados con cuartas partes, es decir, los atacantes vulneran un software utilizado por un desarrollador, de forma que pueden infectar a todos los desarrollos que utilicen dicho software (como, por ejemplo, corrompiendo un compilador de Visual Studio o una herramienta como Xcode).

Pues bien, lo mejor que se puede hacer frente a este tipo de ataques a la cadena de suministro de software, como explica Andy Greenberg en WIRED es "tratar de descubrir las prácticas de seguridad interna de las compañías cuyo software estás usando". No estamos hablando de evaluar los procesos de desarrollo para analizar si están bien hechos o su nivel de madurez, como haría CMMI, sino que nos referimos a que las compañías que desarrollan software también deberían calificar el nivel de ciberseguridad interno de su entorno de trabajo, para transmitir confianza a los usuarios de su software.

All you need is LEET!

Recibe nuestras notificaciones desde este enlace