Revelando las vulnerabilidades cibernéticas en las cadenas de suministro gubernamentales

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

‍

Como si no hubiéramos tenido suficientes interrupciones en el año que no debe ser nombrado, 2021 comenzó con un estruendo ensordecedor para el gobierno de EE. UU., en forma de una de las peores brechas de datos registradas. El incidente de SolarWinds fue un ataque devastador y sofisticado de un estado-nación que provocó el pánico en varios departamentos gubernamentales y grandes organizaciones, que se apresuraron a asegurar sus puntos finales. Prácticamente todos los usuarios finales del software de SolarWinds se vieron comprometidos, y el incidente dejó meridianamente claro que la ciberseguridad y la defensa en las cadenas de suministro de software son fundamentales.

Es evidente que la ciberseguridad es importante, pero ¿qué significa realmente en el contexto de las cadenas de suministro?

El estado de la ciberseguridad en el equipo de desarrollo promedio

Cada día se produce una cantidad enorme de software, lo que representa miles de millones de líneas de código al año, y esto solo aumenta con la demanda creada por nuestros estilos de vida cada vez más digitales. La población mundial de desarrolladores va camino de aumentar a casi 29 millones para 2024, y actualmente no existe una certificación formal para evaluar y certificar su capacidad para programar de forma segura. Esto no quiere decir que todos los desarrolladores produzcan o reutilicen código inseguro, pero sin duda existe un riesgo constante de que se introduzcan debilidades de seguridad básicas en el software en el que confiamos nuestros datos.

A los desarrolladores se les evalúa por su capacidad para crear funciones y entregar código lo más rápido posible. La seguridad no ha sido un punto de referencia para su éxito en la mayoría de las organizaciones, pero ese sentimiento está empezando a cambiar a medida que más empresas se dan cuenta del potencial que tienen para prevenir errores de seguridad comunes en la etapa más temprana de la creación de software. Sin embargo, la comprensión y la implementación son dos cosas diferentes y, dado que la mayoría de los cursos de desarrollo terciario omiten cualquier contexto sobre prácticas de codificación segura, a menudo depende del lugar de trabajo del desarrollador compensar esa carencia. Si el desarrollo de habilidades y el intercambio de conocimientos son poco frecuentes o irrelevantes, probablemente serán ineficaces. Y así, el ciclo de vulnerabilidades recurrentes por falta de desarrollo de habilidades permanece intacto.

Naturalmente, no es responsabilidad del desarrollador de software promedio resolver los problemas de ciberseguridad del mundo; después de todo, las organizaciones contratan a esos profesionales de seguridad tan costosos por una razón. Sin embargo, los gurús de la seguridad son escasos y los desarrolladores sin duda pueden desempeñar un papel en la reducción de la presión.

Pero, ¿dónde nos deja esto a nosotros —y a los proveedores que crean software para infraestructuras críticas y organizaciones sensibles— en términos de prevenir un ciberataque devastador? Se requerirá un cambio en el statu quo de la adquisición de software, como mínimo.

Los escollos que se interponen en el camino de una cadena de suministro de software segura

El viejo adagio de que una cadena es tan fuerte como su eslabón más débil es, lamentablemente, igual de cierto cuando se trata de suministro de software. Realmente no importa si su empresa ha llegado a la mesa con mejores prácticas de seguridad, inversión en la mejora de las habilidades de los desarrolladores y un movimiento hacia un entorno DevSecOps funcional (es decir, todos comparten la responsabilidad de que el software se haga de la manera más segura posible); si utiliza software de un proveedor que tiene problemas de seguridad, los heredará en su ecosistema y asumirá las consecuencias.

Claro, el equipo de seguridad debería ayudar a evaluar la seguridad de las adiciones de terceros a la pila tecnológica, pero las decisiones pueden tomarse en función de una necesidad comercial con pocas opciones entre las soluciones. En este punto, puede ser un ejercicio de confianza. ¿Al proveedor le importa la seguridad tanto como a su empresa? ¿Y puede el proveedor evaluar realmente los riesgos como solo usted podría entenderlos, así como los activos que necesita proteger?

La transparencia es un factor fundamental para evaluar la viabilidad de seguridad de las adiciones de software de los proveedores. ¿Son transparentes con sus propias prácticas de seguridad? Deberían estar orgullosos de su enfoque para mantener los datos seguros, y debería ser una prioridad absoluta. Si las prácticas de seguridad no se publican en ninguna parte, o no hay información disponible, existe una gran posibilidad de que la seguridad no sea una prioridad. El proveedor debería poder responder preguntas técnicas, y certificaciones independientes como ISO27001 y SOC2 tampoco vendrían mal. Además, si no puede "mirar bajo el capó" y buscar vulnerabilidades como parte de su propia diligencia debida y prácticas de seguridad internas, olvídelo.

Con la demanda impulsando una implementación tan rápida de las necesidades de software, especialmente si el código del proveedor se incorpora a los sistemas existentes para realizar acciones en un nuevo contexto, tanto el proveedor como el comprador deben estar en su mejor momento, y ambos deberían tener a sus desarrolladores como personal de campo para detectar errores y fallas de seguridad comunes antes de su lanzamiento. Podría haber cientos, o miles, de dependencias comprometidas si se añade una nueva adición a la red de soluciones tecnológicas existente, y un pequeño fallo podría conducir a una catástrofe.

Entonces, ¿cuál es la solución? ¿Programar todo internamente, desde cero? Si estuviéramos en 1998, eso podría tener sentido. Sin embargo, al igual que ya no preguntamos a "Ask Jeeves" dónde está el lavadero de coches más cercano, debemos implementar salvaguardas realistas que funcionen en el contexto actual.

Todavía no hay una solución mágica, pero existen soluciones

Para los compradores, la evaluación de seguridad del software del proveedor y las prácticas de desarrollo debe ser una prioridad del programa general de seguridad y del plan de mitigación de riesgos. Haga preguntas sobre sus certificaciones, prácticas y la reputación de seguridad de sus desarrolladores.

Los proveedores (y, de hecho, cualquier empresa que cree software) deben estar preparados para demostrar que la seguridad es una prioridad y deben centrarse en la mejora de las habilidades. Los desarrolladores con conocimientos de seguridad tienen una gran demanda y, con las herramientas y el apoyo adecuados, pueden formarse a partir de su equipo actual y recibir el poder para defenderse contra ataques resultantes de vulnerabilidades comunes. Pero no les dé cualquier formación. Déles tiempo para prosperar con herramientas de seguridad que complementen sus flujos de trabajo existentes. Hágalo lo más fácil posible y observe cómo esos molestos errores comienzan a disminuir en el código que impulsa el negocio.

La conclusión es que cualquier riesgo de software se ve exacerbado inmediatamente si forma parte de la cadena de suministro, afectando a todos los usuarios y a cualquier sistema donde se hayan utilizado componentes vulnerables. Si los proveedores no se toman la seguridad tan en serio como las empresas que implementan su software, o si tanto el proveedor como la organización carecen de un programa de seguridad, entonces más ataques devastadores y de gran alcance a la cadena de suministro como SolarWinds se convertirán inevitablemente en la norma, y este es un problema crítico para todos.