¿A los proveedores de software les importa la seguridad tanto como a usted?

Una versión de este artículo apareció en Security Magazine. Ha sido actualizado y distribuido aquí.

‍

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

Más de 18,000 clientes de SolarWinds ya habían descargado la actualización corrupta. Muchos de ellos lo hicieron automáticamente, tal como lo hacían con cientos de otras actualizaciones de software dentro de sus organizaciones y redes. Los atacantes fueron altamente selectivos en lo que eligieron atacar una vez que obtuvieron acceso a través de la brecha de SolarWinds. Muchas grandes corporaciones, así como agencias gubernamentales, sufrieron el robo de sus datos y la vulneración de sus redes. Fue una de las brechas más grandes y probablemente la más costosa 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 sucedió porque las personas confiaron en los proveedores dentro de su cadena de suministro de software sin verificar o evaluar adecuadamente sus actividades.

El cambio masivo hacia la seguridad de la cadena de suministro

Una vez que se dio la voz de alarma, las empresas, organizaciones y agencias gubernamentales respondieron rápidamente. 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 sin supervisión. Aunque el incidente de SolarWinds se resolvió rápidamente una vez descubierto, las implicaciones sobre cómo se utilizó la cadena de suministro como vector de ataque aún persisten. Si algo bueno salió del ataque, al menos fue poner el foco en un aspecto crítico pero pasado por alto de la ciberseguridad.

Una de las respuestas de mayor perfil al ataque de SolarWinds fue la Orden Ejecutiva del presidente Biden sobre la mejora de la ciberseguridad de la nación. La orden es una de las directivas de ciberseguridad más completas jamás emitidas en los Estados Unidos. Exige una mejor ciberseguridad en las agencias y para aquellos que hacen negocios con el gobierno, aboga por protecciones avanzadas como la red de confianza cero (zero-trust) y subraya la necesidad de seguridad en la cadena de suministro de software.

Si bien la orden ejecutiva 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 prevenir otro ataque al estilo SolarWinds. Por ejemplo, Palo Alto publicó recientemente su Informe de Amenazas en la Nube de la Unidad 42 titulado “Asegurar la cadena de suministro de software para asegurar la nube”. El informe establece que ninguna implementación en la nube es totalmente segura sin seguridad en la cadena de suministro de software. Y la Cloud Native Computing Foundation está de acuerdo, publicando un documento técnico que detalla las mejores prácticas críticas de la cadena de suministro de software que deben seguirse tras SolarWinds.

Podemos afirmar que los últimos años han transformado los estándares de ciberseguridad y, aunque no sea obligatorio, todas las organizaciones deberían marcarse como objetivo seguir este camino y examinar las prácticas de seguridad de sus proveedores como si fueran parte de su propio programa de seguridad interno. Iniciativas como el nuevo Plan Estratégico de CISA proporcionan más pruebas de que abordar la seguridad como una responsabilidad compartida está formando parte de un nuevo estándar para todos los creadores de software, especialmente aquellos involucrados en infraestructura crítica 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 garantizar que a sus proveedores les importe tanto la ciberseguridad como a ellos?

La orden ejecutiva describe específicamente el impacto de los desarrolladores de software y la necesidad de que tengan habilidades de seguridad verificadas y conciencia, un área que tiende a olvidarse en una industria obsesionada con las herramientas, en lugar de centrarse en la defensa liderada por personas a través de habilidades de seguridad clave.

Se ha vuelto evidente que cualquier enfoque integral de la ciberseguridad hoy en día debe incluir absolutamente una evaluación detallada de riesgos de terceros, que cubra los controles de seguridad técnicos implementados y una evaluación 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 de programas seguras con firmas de certificados verificadas, y cómo ayudarán a gestionar las identidades de todo su software y dispositivos. También debe demostrar un camino claro para las actualizaciones y mejoras criptográficas de sus productos.

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

Factores como las limitaciones de tiempo y la realidad de que la seguridad simplemente no es una prioridad máxima (ni una medida de éxito) en su mundo, contribuyen a un entorno donde 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, cada organización debe comprometerse con un programa de seguridad más amigable para los desarrolladores.

¿Próximos 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 deben darse cuenta de que es posible que sus proveedores sean, de hecho, más seguros y que incluso puedan ser mejores apoyando a sus comunidades de desarrolladores.

Puede utilizar una evaluación de riesgos de terceros 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.

Finalmente, el siguiente gran paso para mejorar realmente la cadena de suministro de software es implementar certificaciones de codificación segura para los desarrolladores. Tener un buen plan es el primer paso, pero verificar que realmente se esté siguiendo y que ayude a producir código seguro también es una necesidad.

Hasta que la capacitación de los desarrolladores en codificación segura sea la norma, siempre estaremos un paso atrás para cerrar las brechas antes de que los atacantes puedan aprovecharlas. Sin embargo, nunca es tarde para generar un impacto positivo con el apoyo adecuado. Descubra cómo sus desarrolladores pueden perfeccionar habilidades de seguridad relevantes y de alto impacto con el poder del aprendizaje ágil ahora.