Una versión de este artículo apareció en Security Magazine. Se ha actualizado y sindicado aquí.

‍

Para los profesionales de la seguridad, el 13 de diciembre tiene algo especial. ¿Es el día en que por fin erradicamos la inyección SQL, para siempre? Por supuesto que no. ¿Quizás es el "Día Internacional de Apreciación de los Trabajadores de Seguridad"? Tampoco. Es el día en que FireEye y Mandiant publicaron su impactante informe sobre una campaña de intrusión global hasta entonces desconocida que se conocería como SolarWinds. El informe detallaba un ataque continuo y casi increíble en el que se escondía un código malicioso en las actualizaciones del popular software de gestión Orion de SolarWind.

Más de 18.000 clientes de SolarWinds ya habían descargado la actualización corrupta. Muchos de ellos lo hicieron automáticamente, al igual que hicieron con cientos de otras actualizaciones de software en sus organizaciones y redes. Los atacantes fueron muy selectivos en lo que eligieron para atacar una vez que se les dio acceso a través de la brecha de SolarWinds. Muchas empresas importantes, así como agencias gubernamentales, vieron sus datos robados y sus redes comprometidas. Fue una de las mayores y probablemente más costosas violaciones de todos los tiempos, especialmente porque en el caso de las agencias gubernamentales, el alcance total del daño nunca se ha compartido públicamente.

Y todo ocurrió porque la gente confió en los proveedores de su cadena de suministro de software sin verificar o investigar adecuadamente sus actividades.

El cambio masivo hacia la seguridad de la cadena de suministro

Una vez que se dio la alarma, las empresas, organizaciones y organismos gubernamentales se apresuraron a responder. La brecha de SolarWinds se detuvo, por supuesto, pero el ataque también expuso los peligros de una cadena de suministro de software no regulada y no supervisada. Aunque el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones relativas a cómo se utilizó la cadena de suministro como vector de ataque siguen vigentes. Si nada bueno salió del ataque, al menos puso el foco en un aspecto crítico pero ignorado de la ciberseguridad.

Una de las respuestas más destacadas al ataque de SolarWinds fue la Orden Ejecutiva del Presidente Biden para mejorar la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en Estados Unidos. Exige una mejor ciberseguridad en las agencias y para aquellos que hacen negocios con el gobierno, aboga por protecciones avanzadas como las redes de confianza cero, y subraya la necesidad de la seguridad de la cadena de suministro de software.

Si bien la OE es específica para el gobierno, otros grupos también han comenzado a enfatizar la importancia de la seguridad de la cadena de suministro para evitar otro ataque al estilo de SolarWinds. Por ejemplo, Palo Alto ha publicado recientemente su informe sobre la amenaza de la nube de la Unidad 42, titulado "Asegurar la cadena de suministro de software para asegurar la nube". El informe afirma que ningún despliegue en la nube es totalmente seguro sin la seguridad de la cadena de suministro de software. Y la Cloud Native Computing Foundation está de acuerdo, publicando un libro blanco en el que se detallan las mejores prácticas críticas de la cadena de suministro de software que deben seguirse a raíz de SolarWinds.

Es seguro decir que los dos últimos años han sido transformadores para las normas de ciberseguridad y, aunque no es obligatorio, debería ser un objetivo para todas las organizaciones seguir el ejemplo y examinar las prácticas de seguridad de los proveedores como si fueran parte de su propio programa de seguridad interna. Iniciativas como el nuevo Plan Estratégico de CISA proporcionan una prueba más de que enfocar la seguridad como una responsabilidad compartida está formando parte de un nuevo estándar para todos los creadores de software, especialmente aquellos implicados en infraestructuras críticas o en la cadena de suministro de software.

¿Qué pueden hacer las organizaciones para mejorar sus cadenas de suministro de software?

La situación hace que muchos proveedores se pregunten, con razón, qué pueden hacer para proteger sus propias cadenas de suministro. Qué puede hacer una organización para asegurarse de que sus proveedores se preocupan por la ciberseguridad tanto como ellos? 

La OE destaca específicamente el impacto de los desarrolladores de software, y la necesidad de que cuenten con habilidades y conciencia de seguridad verificadas, que es un área que tiende a ser olvidada en una industria que está obsesionada con las herramientas, en lugar de centrarse en la defensa dirigida por las personas a través de habilidades clave de seguridad.

Se ha hecho evidente que cualquier enfoque integral de la ciberseguridad en estos días debe incluir absolutamente un riesgo detallado de terceros assessment, que cubra los controles técnicos de seguridad en el lugar y un assessment de cómo los socios ven la gobernanza, el riesgo y el cumplimiento dentro de sus propias organizaciones. 

Todas las evaluaciones de terceros deben incluir garantías y planes detallados sobre cómo los integrantes de su cadena de suministro de software planean lanzar actualizaciones seguras de programas con firmas de certificados verificados, y cómo ayudarán a gestionar las identidades de todo su software y dispositivos. También debe demostrar una ruta clara para las actualizaciones criptográficas y las actualizaciones para sus productos.

Y ahora que por fin se considera a los desarrolladores como un componente crítico de la seguridad de la cadena de suministro de software, cualquier assessment debe incluir también un informe que detalle cómo fomentan la codificación segura y la mejora continua dentro de su comunidad de desarrolladores, e idealmente, la evaluación comparativa de sus habilidades y la formación actual. Sabemos que el énfasis en la capacitación de los desarrolladores está mejorando, pero el 48% de los desarrolladores ha admitido haber enviado a sabiendas código vulnerable.

Factores como la falta de tiempo y la realidad de que la seguridad simplemente no es una prioridad (ni una medida del éxito) en su mundo, contribuyen a un entorno en el que las vulnerabilidades a nivel de código no se abordan tan pronto como deberían. Si queremos evitar que infecten la cadena de suministro de software, todas las organizaciones deben comprometerse con un programa de seguridad más favorable para los desarrolladores. 

¿Siguientes pasos?

Las evaluaciones de riesgos son fundamentales porque, si utiliza software de un proveedor que tiene problemas de seguridad, los heredará en su ecosistema y sufrirá las consecuencias. Sin embargo, las organizaciones también deberían darse cuenta de que es posible que sus proveedores sean en realidad más seguros, e incluso que sean mejores en el apoyo a sus comunidades de desarrolladores. 

Puede utilizar el riesgo de un tercero assessment como una forma secundaria de evaluar su propia seguridad. Si un proveedor maneja algún aspecto de la seguridad mejor que usted internamente, puede adoptar sus métodos para mejorar su propia organización.

Por último, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implantar certificaciones de codificación segura para los desarrolladores. Disponer de un buen plan es el primer paso, pero la verificación de que realmente se está siguiendo y ayudando a producir un código seguro es también una necesidad. 

Hasta que lleguemos a un punto en el que la habilitación de los desarrolladores para la codificación segura sea la norma, siempre estaremos rezagados a la hora de cerrar ventanas de oportunidad antes de que los actores de amenazas puedan asomarse. Sin embargo, nunca es demasiado tarde para lograr un impacto positivo con el apoyo adecuado. Vea ahora cómo sus desarrolladores pueden perfeccionar habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil.