Cuando surge el tema de las brechas de ciberseguridad, la mayor parte de la atención pública se centra en los hackers, no en los ingenieros de software. Sin embargo, la historia ha demostrado que las brechas más devastadoras a menudo se originan dentro del mismo código en el que confiamos para proteger nuestros sistemas más sensibles. La incómoda verdad es la siguiente: si no se puede ver el código fuente y no se puede verificar la integridad y procedencia de las personas que lo construyeron, no se puede estar seguro de que esté libre de puertas traseras.
El software de código cerrado, por su propia naturaleza, exige confianza, no sólo en el proveedor, sino en todas las personas que han contribuido a su código base. En sectores como defensa, inteligencia, finanzas y otras industrias reguladas, la confianza ciega ya no es aceptable. Necesitamos una política firme: cualquier proveedor de software de código cerrado que venda en infraestructuras críticas debe ser obligatorio certificar que ninguno de sus desarrolladores ha trabajado nunca para un servicio de inteligencia o de defensa extranjero, especialmente en funciones de ciberseguridad, lo que podría permitirles implantar vulnerabilidades ocultas.
No se trata de paranoia, sino de reconocimiento de patrones. La historia del ciberespionaje de alto impacto está plagada de ejemplos en los que actores sofisticados introdujeron puertas traseras de forma prácticamente indetectable hasta que el daño estaba hecho.
Caso práctico 1: La puerta trasera NetScreen / ScreenOS (Juniper Networks)
A finales de 2015, Juniper Networks reveló que se había insertado código no autorizado en su sistema operativo de cortafuegos ScreenOS, el software responsable de proteger las redes del gobierno de Estados Unidos, los contratistas de defensa y las empresas de Fortune 500. No se trataba de un fallo chapucero. Se trataba de una modificación implantada quirúrgicamente en el generador de números aleatorios Dual_EC_DRBG, que otorgaba al atacante la capacidad de descifrar el tráfico VPN a voluntad.
Los investigadores de seguridad llegaron más tarde a la conclusión de que la explicación más plausible era que la puerta trasera había sido añadida intencionadamente por un servicio de inteligencia altamente capacitado. El código era de código cerrado y no se detectó durante años.
Lo más importante: El código de fuente cerrada permitía a un infiltrado (o ex infiltrado) bien situado alterar funciones criptográficas básicas que eran prácticamente imposibles de detectar por los clientes.
Caso práctico 2: Compromiso de Solarigate / SolarWinds Orion
El ataque a la cadena de suministro de SolarWinds en 2020 -denominado "Solarigate"- fue una obra maestra del sigilo. Los atacantes comprometieron el sistema de construcción de la plataforma de monitorización de red Orion, inyectando una puerta trasera firmada digitalmente y distribuida como parte de actualizaciones de software legítimas. Miles de clientes la instalaron, entre ellos el Departamento de Seguridad Nacional de Estados Unidos, varias agencias federales y contratistas de defensa.
No se trataba de una operación de script-kiddie, sino de un ataque con grandes recursos, patrocinado por el Estado y diseñado para mezclarse con el comportamiento normal del software. El código base de Orion estaba cerrado, el proceso de creación era opaco y el punto de inserción estaba controlado por personas de confianza.
Lo más importante: A falta de una auditoría abierta, la integridad del software de código cerrado depende totalmente de la fiabilidad y los antecedentes de las personas que participan en la cadena de desarrollo y construcción.
Caso práctico 3: Incidente con el rootkit de JPMorgan Chase
En 2014, JPMorgan Chase sufrió una de las mayores brechas en la historia de la banca estadounidense, con el robo de los datos personales de más de 83 millones de clientes. Las investigaciones revelaron que los atacantes habían alcanzado un alto nivel de persistencia, aprovechando el acceso a nivel de rootkit para mantener el control y eludir la detección. Aunque el ataque tuvo múltiples fases y actores, puso de relieve que una vez que los atacantes pueden implantar ganchos de bajo nivel, pueden manipular datos, interceptar transacciones y eludir los controles de seguridad estándar.
Aunque JPMorgan no confirmó públicamente si el rootkit procedía de una infiltración en la cadena de suministro o de un ataque interno, el incidente subraya que los componentes de código cerrado de la infraestructura bancaria son objetivos prioritarios para modificaciones sigilosas y persistentes.
Lo más importante: En los sectores financieros y regulados, una sola puerta trasera oculta en un módulo de código cerrado puede socavar miles de millones de dólares invertidos en defensas de seguridad y años de trabajo de cumplimiento normativo.
Patrones revelados:
Retrasos de detección de varios años son habituales, incluso en organizaciones con SOC avanzados.
Creación de entornos y actualización de servidores son puntos de inserción privilegiados para los actores del Estado-nación.
El código cerrado oculta cambios malintencionados mucho más eficazmente que los equivalentes de código abierto.
Sistemas financieros y de seguridad nacional de alto valor son objetivo constante.
La brecha política: el origen de los desarrolladores es una cuestión de seguridad nacional
Tenemos estrictos controles de exportación de criptografía, restricciones a la importación de equipos de telecomunicaciones procedentes de países adversarios y regímenes de certificación para las cadenas de suministro de hardware. Sin embargo ninguna salvaguardia equivalente para garantizar que las personas que escriben y compilan código fuente cerrado para infraestructuras críticas no han sido entrenadas por -o trabajado para- servicios de inteligencia extranjeros conocidos por sus operaciones cibernéticas ofensivas.
La Unidad 8200 de Israel, las unidades cibernéticas GRU y SVR de Rusia, la Unidad 61398 del Ejército Popular de Liberación de China y otras divisiones cibernéticas ofensivas de todo el mundo tienen historiales bien documentados de desarrollo e implantación de puertas traseras en sistemas abiertos y cerrados. Si un proveedor contrata a un desarrollador con estos antecedentes -sin revelar o mitigar el riesgo- los clientes no tienen forma de saber que están confiando potencialmente en código escrito por alguien que ha sido entrenado explícitamente para insertar vulnerabilidades indetectables.
La audaz afirmación: sin certificación no hay despliegue
Las infraestructuras críticas de defensa, inteligencia y sectores regulados deben negarse a implantar software de código cerrado a menos que el proveedor proporcione una certificación vinculante eso:
Ningún código del producto ha sido desarrollado, compilado o revisado por nadie que haya trabajado para una organización extranjera de inteligencia o defensa en un papel de ciberseguridad, inteligencia de señales o explotación de redes.
El proveedor mantiene una investigación continua de los antecedentes de todos los colaboradores de la base de código cerrado.
El software se somete a comprobaciones periódicas de integridad de nivel binario por parte de un laboratorio de seguridad independiente con sede en Estados Unidos y autorización gubernamental.
No se trata de xenofobia ni de proteccionismo, sino de la realidad operativa. Los incidentes de puertas traseras en Juniper, SolarWinds y muchos otros han demostrado que la cadena de desarrollo es una superficie de ataque para la seguridad nacional. Ya bloqueamos el acceso físico a los sitios críticos y a las cadenas de suministro de hardware; es hora de aplicar el mismo rigor a las personas que escriben y compilan el código que ejecuta esos sistemas.
Conclusión: Confiar, pero exigir procedencia
En el moderno campo de batalla cibernético, la línea entre defensa y ataque es delgada, y muchos de los mejores ingenieros del mundo han usado ambos sombreros. Para las aplicaciones de consumo no reguladas, tal vez sea un riesgo aceptable. ¿Para el software que controla los sistemas de mando nuclear, los satélites de defensa, las cámaras de compensación financiera y el control del tráfico aéreo? No lo es.
El software de código cerrado es una caja negra, y la historia ha demostrado que las cajas negras pueden esconder cuchillos muy afilados. Hasta que no exijamos garantías verificables sobre quién construyó el código, cada despliegue es un acto de fe ciega. Para las infraestructuras críticas, la fe ciega no es una estrategia de seguridad.