Levantando el velo sobre las cibervulnerabilidades en los conductos de la cadena de suministro del Gobierno

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

‍

Como si no hubiéramos tenido suficientes interrupciones en el Año que no puede ser nombrado, 2021 comenzó con una explosión ensordecedora para el gobierno de Estados Unidos, en forma de una de las peores violaciones de datos registradas. El incidente de SolarWinds fue un devastador y sofisticado ataque de estado-nación que hizo que varios departamentos gubernamentales y grandes organizaciones entraran en pánico, luchando por asegurar sus puntos finales. Prácticamente todos los usuarios finales del software de 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 el equipo de desarrollo medio

Cada día se produce una enorme cantidad de software, que representa miles de millones de líneas de código cada año, y que no hace más que aumentar con la demanda creada por nuestro estilo de vida progresivamente digital. La población mundial de desarrolladores está en camino de aumentar a 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 sin duda existe un riesgo sostenido de que se introduzcan debilidades básicas de seguridad en el software al que confiamos nuestros datos.

A los desarrolladores se les evalúa por su capacidad 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 ese sentimiento 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 la etapa más temprana de la creación de software. Sin embargo, la realización y la puesta en práctica son dos cosas diferentes, y dado que la mayoría de los desarrollos terciarios courses omiten cualquier contexto en torno a las prácticas de codificación segura, a menudo es el lugar de trabajo del desarrollador el que debe suplir esa carencia. Si el desarrollo de habilidades y el intercambio de conocimientos son infrecuentes o irrelevantes, entonces es probable que sean ineficaces. Y así, el ciclo de vulnerabilidades recurrentes por la falta de desarrollo de habilidades sigue sin romperse. 

Naturalmente, no es responsabilidad del desarrollador de software medio resolver los problemas de ciberseguridad del mundo; después de todo, las organizaciones contratan a esos carísimos profesionales de la seguridad por una razón. Sin embargo, los gurús de la seguridad escasean y los desarrolladores pueden contribuir a reducir la presión. 

Pero, ¿dónde nos deja esto -y a los proveedores que crean software para infraestructuras críticas y organizaciones sensibles- en términos de prevención de un ciberataque devastador? Va a 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, por desgracia, igual de cierto cuando se trata del suministro de software. Realmente no importa si su empresa ha llegado a la fiesta con las mejores prácticas de seguridad reforzadas, la inversión en la capacitación de los desarrolladores, y un movimiento hacia un entorno DevSecOps funcional (es decir, todo el mundo comparte la responsabilidad de que el software se haga de la manera más segura posible); si usted utiliza el software de un proveedor que tiene problemas de seguridad, los heredará en su ecosistema y soportará las consecuencias.

Por supuesto, el equipo de seguridad debe ayudar a evaluar la seguridad de las adiciones de terceros a la pila tecnológica, pero las decisiones se pueden tomar sobre la base de una necesidad de negocio con poca elección entre las soluciones. En este punto, puede ser un ejercicio de confianza. ¿Se preocupa el proveedor por la seguridad tanto como su empresa? ¿Y puede el proveedor evaluar realmente los riesgos como sólo usted podría entenderlos, así como los activos que usted necesita proteger?

La transparencia es un factor muy importante a la hora de evaluar la viabilidad de la seguridad de las adiciones de software del proveedor. ¿Son honestos 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 ningún sitio, o no hay información disponible, es muy probable que la seguridad no sea lo más importante. El proveedor debe ser capaz de responder a las preguntas técnicas, y las certificaciones independientes como ISO27001 y SOC2 tampoco estarían de más. Además, si no puedes "mirar bajo el capó" y escanear en busca de vulnerabilidades como parte de tus propias prácticas internas de diligencia debida y seguridad, olvídalo.

Con una demanda que impulsa una implementación tan rápida de las necesidades de software, especialmente si el código del proveedor se está integrando en 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 deben tener a sus desarrolladores como las botas en el terreno para recoger los errores y defectos de seguridad comunes antes de que se envíen. Podría haber cientos -o miles- de dependencias comprometidas si se agrega una nueva adición a la telaraña existente de soluciones tecnológicas, y un pequeño fallo podría llevar a un descalabro catastrófico.

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

Todavía no hay una bala de plata, pero hay soluciones

Para los compradores, la seguridad assessment del software del proveedor y las prácticas de desarrollo deben ser una prioridad del programa general de seguridad y del plan de mitigación de riesgos. Haga preguntas sobre sus certificaciones, prácticas y 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 lo más importante, y deben centrarse en la mejora de las competencias. Los desarrolladores con conocimientos de seguridad están muy solicitados y, con las herramientas y el apoyo adecuados, pueden formarse a partir de su equipo actual y capacitarse para defenderse de los ataques derivados de las vulnerabilidades más comunes. Pero no les dé una formación cualquiera. Déles tiempo para que prosperen con herramientas de seguridad que complementen sus flujos de trabajo actuales. Hágalo lo más fácil posible y vea cómo esos molestos errores empiezan a desaparecer entre el código que alimenta la empresa.

La conclusión es que cualquier riesgo de software se agrava inmediatamente si forma parte de la cadena de suministro, afectando 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 tanto el proveedor como la organización tienen carencias en su programa de seguridad-, los ataques a la cadena de suministro más devastadores y de mayor alcance, como el de SolarWinds, se convertirán inevitablemente en la norma, y este es un problema crítico para todos.