Levantando el velo sobre las vulnerabilidades cibernéticas en los oleoductos de la cadena de suministro gubernamental

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

‍

Como si no hubiéramos tenido suficientes interrupciones en un año que no se puede nombrar, 2021 comenzó con un golpe ensordecedor para el gobierno de los EE. UU., en forma de una de las peores filtraciones de datos de la historia. El incidente de SolarWinds fue un ataque devastador y sofisticado contra un estado nacional que hizo que varios departamentos gubernamentales y grandes organizaciones entraran en pánico y se esforzaran por proteger sus terminales. Prácticamente todos los usuarios finales del software SolarWinds se vieron comprometidos, y el incidente dejó muy claro que la ciberseguridad y la defensa en las cadenas de suministro de software son fundamentales.

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

El estado de la ciberseguridad en un equipo de desarrollo promedio

Todos los días se produce una enorme cantidad de software, lo que representa miles de millones de líneas de código cada año, y eso no hace más que aumentar con la demanda creada por nuestro estilo de vida cada vez más digital. La población mundial de desarrolladores va camino de crecer para casi 29 millones para 2024, y actualmente no existe ninguna certificación formal para evaluar y certificar su capacidad para codificar de forma segura. Esto no quiere decir que todos los desarrolladores produzcan o reutilicen código inseguro, pero no cabe duda de que existe un riesgo sostenido de que se introduzcan puntos débiles de seguridad básicos en el software en el que confiamos nuestros datos.

Se evalúa la capacidad de los desarrolladores para crear funciones y enviar 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 esa opinión está empezando a cambiar a medida que más empresas se dan cuenta del potencial que tienen para prevenir los errores de seguridad más comunes en las primeras etapas de la creación del software. Sin embargo, la realización y la implementación son dos cosas diferentes y, dado que la mayoría de los cursos de desarrollo terciario omiten cualquier contexto relacionado con las prácticas de codificación seguras, a menudo es el lugar de trabajo del desarrollador el que debe compensar el déficit. Si el desarrollo de habilidades y el intercambio de conocimientos son poco frecuentes o irrelevantes, es probable que no sean efectivos. Por lo tanto, el ciclo de vulnerabilidades recurrentes debido a la falta de desarrollo de habilidades permanece ininterrumpido.

Naturalmente, no es responsabilidad de un desarrollador de software promedio resolver los problemas de ciberseguridad del mundo; después de todo, las organizaciones contratan a esos costosos profesionales de seguridad por una razón. Sin embargo, los gurús de la seguridad escasean y, sin duda, los desarrolladores pueden contribuir a reducir 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? Va a requerir, como mínimo, un cambio en el status quo de la adquisición de software.

Los obstáculos que se interponen en el camino de una cadena de suministro de software segura

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

Por supuesto, el equipo de seguridad debería ayudar a evaluar la seguridad de las incorporaciones de terceros a la gama tecnológica, pero las decisiones se pueden tomar en función de una necesidad empresarial con pocas opciones de soluciones. En este punto, puede ser un ejercicio de confianza. ¿El proveedor se preocupa por la seguridad tanto como su empresa? ¿Y puede el proveedor evaluar realmente los riesgos de una manera tal como solo usted puede comprenderlos, así como los activos que necesita proteger?

La transparencia es un factor de suma importancia a la hora de evaluar la viabilidad de seguridad de las incorporaciones de software de los proveedores. ¿Lo son desde el principio con sus propias prácticas de seguridad? Deberían enorgullecerse de su enfoque para mantener los datos seguros y debería ser una de las principales prioridades. Si las prácticas de seguridad no se publican en ninguna parte o no hay información disponible, existe una gran probabilidad de que la seguridad no sea una prioridad. El proveedor debería poder responder a las preguntas técnicas y a las certificaciones independientes, como ISO27001 y el SOC2 tampoco haría daño. Además, si no puede «mirar a escondidas» y analizar vulnerabilidades como parte de sus propias prácticas internas de diligencia debida y seguridad, olvídelo.

Dado que la demanda impulsa una implementación tan rápida de las necesidades de software, especialmente si el código del proveedor se está incorporando a los sistemas existentes para realizar acciones en un nuevo contexto, tanto el proveedor como el comprador deben estar en la cima de su juego, y ambos deberían contar con sus desarrolladores sobre el terreno para detectar los errores y defectos de seguridad más comunes antes de su lanzamiento. Podría haber cientos (o miles) de dependencias comprometidas si se añade una nueva incorporación a la telaraña de soluciones tecnológicas existente, y un pequeño fallo podría llevar a una ruina catastrófica.

Entonces, ¿cuál es la solución? ¿Codificar todo internamente, desde cero? Si fue en 1998, eso podría tener sentido. Sin embargo, del mismo modo que ya no le preguntamos a Jeeves dónde está el lavadero de autos más cercano, necesitamos implementar medidas de seguridad realistas que funcionen en el contexto actual.

Todavía no existe una fórmula mágica, pero hay soluciones

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

Los vendedores (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. Desarrolladores expertos en seguridad tienen una gran demanda y con las herramientas y el soporte adecuados, pueden crearse a partir de su equipo actual y capacitarse para defenderse de los ataques derivados de vulnerabilidades comunes. Pero no les eches en cara ningún entrenamiento antiguo. Déles tiempo para prosperar con herramientas de seguridad que complementen sus flujos de trabajo actuales. Hágalo lo más fácil posible y observe cómo esos molestos errores comienzan a acumularse en el código que impulsa la empresa.

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