My viaje en familia a Roma fue estupendo; alejarme de la oficina durante una semana, explorar la ciudad, pasear por lugares históricos, disfrutar de la comida y, simplemente, pasar tiempo con mi familia fue justo lo que necesitaba.
Un día, mientras paseábamos por un callejón pequeño y fresco, nos topamos con una clase para aprender a hacer pasta y tiramisú. Parecía divertido y, como dice el refrán, «cuando estés en Roma, haz como los romanos». Durante unas horas, cambié el malware, la ciberseguridad y las infraestructuras críticas por harina, huevos, agua, sincronización, presión y paciencia.
Cuanto más me iba acostumbrando a la clase, más me daba cuenta de que incluso hacer pasta es todo un sistema. Desde fuera parece sencillo, pero si te importa el resultado, los pequeños detalles cuentan. Demasiada agua altera la masa. Demasiada presión cambia la textura. Si te precipitas en el proceso, el resultado no saldrá del todo bien.
Esto es así tanto en el ámbito de la alimentación como en el empresarial y en el de la ciberseguridad.
Al terminar la clase, ocurrió algo totalmente inesperado: conocí a Jeff Goldblum.

Era cálido, divertido, elegante y muy humano. Como la mayoría de las personas que lo conocen, pensé en sus emblemáticos papeles cinematográficos, el piano de jazz y su capacidad única para ser famoso y, aun así, accesible. Eso fue antes de que mi mente de experto en ciberseguridad tomara el control.
No dejaba de pensar en una escena de la película «Independence Day», de 1996, en la que su personaje, David Levinson, infecta la nave nodriza alienígena con un virus informático.

Esto me hizo pensar: «¿Es siquiera posible que el malware se propague por el espacio?».
Claro que sí.
No es exactamente la versión de Hollywood, pero la idea central es plausible. Cualquier sistema que ejecute software, reciba datos, acepte órdenes o confíe en información procedente del exterior puede ser objeto de un ataque. La nave nodriza no contaba con un modelo de amenazas para confiar en los sistemas humanos, lo que se aplica directamente a la infraestructura espacial actual.
El auge espacial
En este caso, el momento es clave. Da la sensación de que el sector espacial está entrando en un nuevo ciclo de auge, que va más allá de los cohetes, la NASA y la salida a bolsa de SpaceX.
El panorama general es global. Amazon Kuiper se suma a la carrera por la banda ancha por satélite. Europa está desarrollando IRIS² como una constelación de conectividad segura y soberana para las comunicaciones gubernamentales, la respuesta ante crisis, las infraestructuras críticas y los servicios cifrados. China avanza con determinación con grandes programas de constelaciones como «Thousand Sails » y «Guowang». La India está ampliando sus ambiciones en materia de satélites espaciales y de defensa. Japón está invirtiendo más en seguridad espacial. Operadores como Viasat, OneWeb, Planet, Maxar, Intelsat, Iridium, Eutelsat, SKY Perfect JSAT y otros están desarrollando servicios de comunicaciones, imágenes, navegación, defensa y datos en órbita.
El debate va más allá de los satélites como infraestructura de comunicaciones. Elon Musk ha planteado la posibilidad de poner en órbita centros de datos de IA, argumentando que la Tierra tiene limitaciones energéticas, mientras que el espacio cuenta con luz solar constante. El año pasado, Starcloud lanzó una nave espacial equipada con un chip Nvidia H100 y demostró que era posible ejecutar una versión del modelo de IA Gemini de Google desde el espacio. Además, Google dio a conocer el Proyecto Suncatcher para explorar grupos de satélites equipados con TPU y enlaces ópticos, así como sus planes de lanzar satélites prototipo en 2027.
Se trata de un tipo de economía espacial muy diferente.
El sector espacial está pasando del transporte a las comunicaciones, de las comunicaciones a los datos, de los datos a la computación y de la computación a la inteligencia artificial. El sector espacial se está convirtiendo en una capa de infraestructura digital global en la que participan Estados, operadores comerciales, organismos de defensa y cadenas de suministro multinacionales.
...y todas las capas de la infraestructura digital acaban convirtiéndose en un objetivo cibernético.

La ciberseguridad... en el espacio
¿Es la ciberseguridad en el espacio un problema real? ¿Se han producido incidentes reales? ¿Son diferentes de otros incidentes?
Sí, sí y sí.
El espacio comenzó siendo un ámbito propio del gobierno y la defensa. Durante décadas, la mayoría de los programas espaciales eran propiedad de gobiernos, ejércitos, agencias de inteligencia y organismos nacionales de investigación, o estaban sometidos a un estricto control por parte de estos. Esto es importante porque en estos entornos no siempre se hacen públicos los incidentes. Algunos fallos se describen como «anomalías». Algunos incidentes son clasificados. Otros son gestionados de forma discreta por agencias, contratistas o socios del sector de la defensa.
El expediente público no es más que una pequeña parte del historial del incidente.
A pesar de esa limitación, ya existen varias organizaciones que supervisan los riesgos e incidentes de ciberseguridad relacionados con el espacio, entre ellas Space ISAC, la OIG de la NASA y la ENISA.
El Space ISAC se centra en las ciberamenazas espaciales y el seguimiento de incidentes; la OIG de la NASA lleva a cabo investigaciones detalladas y análisis de las causas fundamentales de los incidentes de la NASA y del JPL; y el «Space Threat Landscape» de la ENISA es un agregador público de riesgos cibernéticos espaciales y ejemplos históricos.
Tras cotejar sus resultados con fuentes públicas, he elaborado la siguiente lista de incidentes para arrojar algo de luz sobre las causas de estas infracciones y sus repercusiones:
Año | Organización | Incidente | Cómo se produjo la filtración | Causa principal | URL de la fuente pública |
De 1998 a 2000 | Gobierno de EE. UU. / NASA | Laberinto a la luz de la luna | Una campaña de ciberespionaje de larga duración sustrajo datos relacionados con el Gobierno de EE. UU., el sector de la defensa y la NASA. | Supervisión deficiente, segmentación insuficiente y escasa visibilidad entre organismos | https://nsarchive.gwu.edu/document/19207-national-security-archive-united-states-navy |
1999 | NASA / DTRA | Jonathan James | Robaron credenciales, instalaron puertas traseras, interceptaron correos electrónicos y accedieron a los sistemas de la NASA. El impacto se agravó porque las redes y las zonas de confianza no estaban bien separadas. | Red plana, segmentación deficiente, credenciales débiles | https://www.nytimes.com/2000/09/22/technology/teen-hacker-sentenced.html |
De 2001 a 2002 | NASA / Departamento de Defensa | Gary McKinnon | Analizó los sistemas expuestos, utilizó contraseñas débiles, obtuvo acceso de administrador e instaló herramientas de control remoto. | Sistemas vulnerables, contraseñas débiles, ausencia de autenticación multifactorial (MFA) | https://www.justice.gov/archive/criminal/cybercrime/press-releases/2002/mckinnonIndict.htm |
De 2007 a 2008 | Landsat 7 / Terra AM 1 | Interferencias de la estación terrestre | Se ha informado de interferencias a través de la ruta de la estación terrestre, no de un ataque directo al satélite. | Exposición de la estación terrestre, separación insuficiente de la ruta de comando | |
2007 y siguientes | Turla | Secuestro de un enlace por satélite | Se utilizan de forma indebida conexiones a Internet por satélite sin cifrar para ocultar el tráfico de comando y control. | Enlaces por satélite sin cifrar, autenticación débil | |
2009 | NASA | Malware de la red Mission | Los sistemas de las misiones de la NASA sufrieron infecciones por malware y miles de conexiones no autorizadas. | Malware, controles deficientes de los puntos finales, segmentación deficiente | |
De 2009 a 2012 | NASA | Portátiles extraviados que contienen datos del ISS | La NASA perdió ordenadores portátiles y dispositivos móviles, algunos de ellos sin cifrar, entre los que se encontraba material relacionado con la Estación Espacial Internacional (ISS). | Pérdida de dispositivos, falta de cifrado, datos confidenciales almacenados localmente | |
2011 | NASA | 47 ataques APT | La NASA informó de 47 ataques APT, 13 de los cuales tuvieron éxito, incluido el robo de credenciales. | Phishing, robo de credenciales, autenticación multifactorial (MFA) débil | |
2011 | NASA JPL | 87 GB robados | Los atacantes obtuvieron acceso completo a 18 servidores, modificaron cuentas, instalaron herramientas, alteraron los registros y robaron datos. | Segmentación deficiente, privilegios excesivos, supervisión insuficiente | |
2011 | HTV de la JAXA | Infección por malware | Un empleado abrió un correo electrónico malicioso en un ordenador sin parches. El malware infectó el equipo y provocó la filtración de datos de acceso. | Ataque basado en archivos, correo electrónico malicioso, software de Office sin parches | https://global.jaxa.jp/press/2012/03/20120327_security_e.html |
2012 | JAXA Epsilon | Malware «Rocket Data» | Un programa malicioso infectó un ordenador del Centro Espacial de Tsukuba y podría haber filtrado datos de los cohetes Epsilon, M-V, H-IIA y H-IIB. | Malware basado en archivos, compromiso de una estación de trabajo de ingeniería | https://global.jaxa.jp/press/2012/11/20121130_security_e.html |
2012 | NASA / ESA | Intrusiones en servidores web por parte de «The Unknowns» | Los hackers aprovecharon las deficiencias de los servidores web y revelaron las vulnerabilidades. | Fallos en las aplicaciones web, aplicación deficiente de los parches | |
2014 | NOAA | Violación de la seguridad de los sistemas de datos por satélite | Los atacantes aprovecharon vulnerabilidades conocidas en las aplicaciones web de la NOAA accesibles desde Internet, robaron las credenciales de administrador y se movieron de un sistema a otro. | Vulnerabilidades en aplicaciones web, sistemas sin parches, robo de credenciales | |
2014 | NASA JPL | Malware publicado en la red | Los usuarios del público en general podían subir y ejecutar archivos en un servidor que prestaba apoyo a las misiones astronómicas y a la investigación del JPL. | Ataque basado en archivos, subida de archivos insegura, falta de sanitización | |
2014 | Centro Aeroespacial Alemán, DLR | Infiltración de un APT | En los informes públicos se describían casos de ciberespionaje y spear phishing dirigidos contra sistemas aeroespaciales. | Ataques por correo electrónico, robo de credenciales, supervisión deficiente | https://securityaffairs.com/24031/cyber-crime/german-aerospace-center-espionage.html |
2016 | NASA JPL | Configuración incorrecta del sitio web | Un usuario anónimo obtuvo privilegios elevados y ejecutó código en un servidor de desarrollo. | Configuración incorrecta, privilegios excesivos | |
2017 | NASA JPL | Servidor de código fuente de operaciones terrestres | Una vulnerabilidad desconocida permitía la ejecución remota de código en los sistemas de código fuente. Los registros no se revisaron con la suficiente rapidez. | Vulnerabilidad sin parchear, revisión deficiente de los registros | |
2018 | NASA JPL | Incidente relacionado con la Red Espacial Profunda | Se ha producido una filtración en una cuenta de usuario externa. Los atacantes se han desplazado lateralmente hacia los sistemas operativos debido a una segmentación deficiente y a un inventario de activos insuficiente. | Segmentación deficiente, acceso de terceros, inventario insuficiente | |
2018 | NASA | Fuga de datos personales de los empleados | La violación de la seguridad del servidor de RR. HH. ha supuesto la filtración de datos personales de los empleados. | Control de acceso deficiente, exposición de datos confidenciales | https://federalnewsnetwork.com/cybersecurity/2018/12/nasa-suffers-breach-of-employee-data/ |
2019 | ISRO | Informes sobre el malware DTrack | Según informes públicos, se detectó el malware DTrack y se produjo una posible intrusión en el controlador de dominio. La confirmación por parte de la ISRO fue escasa. | Probablemente se trate de malware basado en archivos y de una filtración de credenciales | https://www.cfr.org/cyber-operations/compromise-of-indian-nuclear-power-plant |
2020 | Visser Precision, proveedor de SpaceX | Ransomware | El proveedor sufrió un ataque de ransomware y se filtraron archivos propios de los clientes. | Vulnerabilidad de un proveedor, ransomware, red inactiva | |
2020 | SolarWinds | Ataque a la cadena de suministro que afecta al sector aeroespacial y al sector público | Una actualización de software malicioso permitió a los atacantes obtener acceso privilegiado a numerosas redes, entre ellas las de la NASA y la FAA | Vulnerabilidad en la cadena de suministro de software de confianza | https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a |
2022 | Viasat KA SAT | Interrupción del servicio de Internet por satélite | Los atacantes aprovecharon una configuración incorrecta de la VPN, accedieron a la red de gestión de confianza y ejecutaron comandos que borraron los datos de la memoria flash del módem. | Vulnerabilidad de la VPN, segmentación deficiente de la red de gestión | https://www.viasat.com/perspectives/corporate/2022/ka-sat-network-cyber-attack-overview/ |
2022 | Roscosmos | Reclamación por incumplimiento de la norma NB65 | Unos hackers afirmaron haber protagonizado un ataque contra activos espaciales rusos. El impacto operativo fue objeto de controversia. | Sin verificar | https://ui.adsabs.harvard.edu/abs/2024arXiv240210324T/abstract |
2023 | Boeing Global Services | Ransomware LockBit | LockBit atacó la división de piezas y distribución de Boeing. Boeing afirmó que la seguridad de los vuelos no se vio afectada. | Ransomware, movimiento lateral, segmentación deficiente | |
2023 | Maximum Industries, proveedor de SpaceX | Reclamación de LockBit | LockBit ha afirmado que se han sustraído planos de ingeniería relacionados con SpaceX a un proveedor. Esta información no se ha verificado plenamente de forma pública. | Vulnerabilidad de un proveedor, robo de datos | https://cyberir.mit.edu/site/lockbit-ransomware-claims-data-breach-spacex-contractor/ |
De 2023 a 2024 | JAXA | Violación de seguridad en la VPN y Microsoft 365 | Es probable que los atacantes se aprovecharan de una vulnerabilidad de la VPN, ampliaran su acceso, comprometieran cuentas y accedieran a Microsoft 365. | Vulnerabilidad de la VPN, filtración de identidades en la nube | |
2024 | Maxar Space Systems | Fuga de datos de los empleados | El atacante accedió a un servidor externo de la zona desmilitarizada (DMZ). Se produjeron fugas de datos de los empleados; según se ha informado, las operaciones no se vieron afectadas. | Exposición de la DMZ a Internet, aislamiento deficiente | |
2025 | Agencia Espacial Polaca, POLSA | Incidente cibernético | Se ha detectado un acceso no autorizado. POLSA ha desconectado su red mientras se lleva a cabo la investigación. | Desconocido, probablemente una intrusión en la red | |
2025 | Controles de VSAT y satélites israelíes | Reclamaciones por interrupciones y problemas de control de los sistemas VSAT y de satélite | El Space ISAC informó de ataques contra segmentos de control de satélites israelíes y sistemas VSAT israelíes durante un conflicto geopolítico. | Hacktivismo, ataques DDoS, interrupciones, ataques dirigidos al segmento terrestre | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | Proveedor estadounidense de comunicaciones por satélite | Salt Typhoon pone en el punto de mira a un proveedor de comunicaciones por satélite | Space ISAC informó de que Salt Typhoon había atacado a un proveedor estadounidense de comunicaciones por satélite como parte de unas operaciones más amplias en el ámbito de las telecomunicaciones. | Compromiso de dispositivos periféricos; ataques dirigidos a las telecomunicaciones y las comunicaciones por satélite | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | Sectores aeroespacial y de defensa de Rusia | Cebos de spear phishing muy específicos como parte de la Operación Cargo Talon | Campaña de ciberespionaje destinada a comprometer entidades y sustraer datos confidenciales. | Spear phishing, ataque basado en archivos | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | Software infraestructura satelital de Irán | Laboratorio Dookhtegan: selección de objetivos para el sistema VSAT marítimo | Según se ha informado, un actor malintencionado atacó el software de satélite que da soporte a la infraestructura VSAT marítima, lo que provocó interrupciones en las comunicaciones y la eliminación de archivos. | Asistencia técnica para software de comunicaciones por satélite, presentación de proveedores y servicios | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | Sectores europeos de las telecomunicaciones, la defensa, la industria aeroespacial y los satélites | El malware iraní «MINIBIKE» tiene como objetivo | Según se ha informado, el grupo APT iraní UNC159 utilizó malware diseñado a medida contra organizaciones europeas de las sectores de las telecomunicaciones, el sector aeroespacial y la defensa. | Es probable que se trate de malware distribuido a través de archivos | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
2025 | Organizaciones aeroespaciales, de defensa y espaciales | Campaña de ciberespionaje a través del grupo APT vinculado a China, RedNovember | Según se informa, RedNovember tiene como objetivo organizaciones espaciales y aeroespaciales de alto perfil, tanto del sector público como del privado, de todo el mundo, utilizando la puerta trasera de código abierto y multiplataforma «Pantegana», basada en el lenguaje Go. | Espionaje, intrusión en redes | https://spaceisac.org/wp-content/uploads/2025/10/Space-ISAC_Q3-2025-Public-Report_TLP-CLEAR-1-1.pdf |
De 2025 a 2026 | ESA | Servidores de colaboración en ingeniería | Se produjeron brechas de seguridad en los servidores externos de colaboración en materia de ingeniería. Según informaciones públicas, quedaron expuestos código, tokens, credenciales, archivos de configuración y documentos de misión. | Robo de credenciales, robo de tokens, sistemas de colaboración expuestos | |
2026 | ESA | Informes sobre fugas de datos a gran escala | Según informes públicos, se filtraron cientos de GB de datos relacionados con la ESA, entre los que se incluían credenciales y documentos de proyectos. Al parecer, la ESA ha abierto una investigación. | Desconocido / En investigación |
Análisis en profundidad de los patrones de ciberseguridad
Al analizar todos los incidentes, observé que se repetían los mismos fallos de ciberseguridad en otros sectores de infraestructuras críticas: archivos inseguros, vulnerabilidades en los proveedores, procesos deficientes de actualización de software, riesgos relacionados con los soportes extraíbles, credenciales robadas y una segmentación deficiente de la red.
Lo que me sorprendió fue la frecuencia con la que las naves espaciales o los satélites no eran los objetivos. La vía de ataque solía comenzar en tierra. Las estaciones terrestres, los sistemas de ingeniería, los proveedores y las redes de apoyo solían recibir un trato diferente al de la propia misión, a pesar de que comprometerlos podía tener las mismas consecuencias.
Dicho esto, aunque la mayoría de los incidentes públicos actuales tienen su origen en sistemas terrestres, a medida que los programas espaciales evolucionen y el acceso a la órbita resulte más barato y habitual, no debemos dar por sentado que los ciberataques siempre se originarán desde la Tierra. En el futuro, es concebible que el panorama de amenazas se amplíe a medida que los Estados-nación o incluso los operadores comerciales sitúen naves espaciales, satélites u otros activos orbitales más cerca de un objetivo para apoyar ciberataques, guerra electrónica, interceptación, interferencias, suplantación de identidad u operaciones de recopilación de inteligencia.
Detección frente a prevención
Muchos de estos incidentes también pusieron de manifiesto las limitaciones de basarse principalmente en cortafuegos tradicionales y en sistemas de seguridad basados en la detección.
En la brecha de seguridad sufrida por el JPL de la NASA en 2018, los atacantes comprometieron una cuenta externa y se desplazaron lateralmente a través de redes mal segmentadas. Las defensas perimetrales resultaron insuficientes una vez que se había establecido la confianza. En el ataque a Viasat KA-SAT de 2022, los atacantes accedieron a una red de gestión de confianza a través de una ruta de VPN o cortafuegos comprometida y ejecutaron comandos de gestión legítimos.
Una vez más, el problema no radicaba simplemente en la detección del tráfico malicioso, sino en no haber utilizado una pasarela unidireccional, que habría garantizado el flujo de datos en una sola dirección por diseño, en lugar de mediante políticas, impidiendo así desde el principio que los atacantes llegaran a los sistemas críticos.

Varios incidentes relacionados con archivos cuentan una historia similar. El incidente de malware del HTV de la JAXA en 2011 comenzó cuando alguien abrió un archivo adjunto malicioso en un correo electrónico en una estación de trabajo sin parches. El incidente de malware por subida de archivos del JPL en 2014 permitió que archivos no fiables llegaran a los sistemas de apoyo a la misión. Las herramientas de detección pueden identificar el contenido malicioso a posteriori, pero una vez que se abre o se ejecuta un archivo, es posible que el daño ya esté hecho.
La lección: debemos considerar los sistemas espaciales como infraestructuras críticas y la infraestructura cibernética que los sustenta como infraestructura crítica para la misión. Muchos de estos incidentes no se debieron a fallos en la detección, sino a fallos en la prevención. Una vez que los atacantes lograban acceder a redes de confianza, entornos de ingeniería, sistemas de gestión o sistemas de misión, los cortafuegos y las alertas solían llegar demasiado tarde.
Estrategias de ciberseguridad para el espacio
Una vez que identificamos el riesgo y las causas fundamentales que subyacen a los incidentes notificados, ¿qué hacemos al respecto?
La ciberseguridad espacial comparte muchas de las causas fundamentales de la ciberseguridad tradicional, pero añade dos dimensiones que lo cambian todo: el tiempo y el entorno.
En la Tierra, si algo sale mal, damos por hecho que podemos conectarnos, inspeccionar, aplicar un parche, restaurar o enviar a alguien al lugar. En el espacio, muchas de esas suposiciones dejan de ser válidas. La comunicación es más lenta, más cara, más limitada y se vuelve más difícil cuanto más te alejas de la Tierra.
La Luna está lo suficientemente cerca como para que las señales tarden poco más de un segundo en cada sentido, pero incluso eso supone un retraso de ida y vuelta de más de dos segundos. En el caso de Marte, el tiempo de ida puede oscilar entre unos 4 y 24 minutos, dependiendo de la posición de la Tierra y Marte en sus órbitas. En las misiones al espacio profundo, el problema se agrava aún más. La Voyager está tan lejos que la comunicación puede tardar casi un día entero en cada sentido.
Esto cambia el modelo de ciberseguridad.
Las herramientas de seguridad modernas dependen cada vez más de una interacción constante con la nube: consultas de reputación, comprobaciones de hash, actualizaciones de firmas, actualizaciones de modelos de IA (una dependencia cada vez mayor a medida que los sistemas basados en IA se lanzan al espacio), envíos a entornos de prueba, cargas de telemetría y veredictos centralizados. En la Tierra, esto funciona porque la conectividad es rápida y fiable. En el espacio, resulta peligroso dar por sentado que el mismo modelo funcionará.
En la Luna, algunas de estas cosas siguen siendo técnicamente posibles, pero no es algo en lo que debas confiar. Cada consulta a la nube añade retraso. Cada envío al entorno de pruebas debe viajar hasta la Tierra y volver. Cada sesión de escritorio remoto se vuelve más lenta. Cada carga forense de gran tamaño compite por el ancho de banda de la misión. Si el enlace con la Tierra está congestionado, degradado, saturado o no está disponible, la seguridad basada en la nube deja de ser fiable.
Si esto ya resulta difícil en la Luna, se vuelve mucho más complicado en Marte, y es imposible hacerlo en tiempo real en el espacio profundo.
Lo mismo ocurre con las actualizaciones. Si se lleva a cabo una misión espacial durante muchos años, no se puede dar por sentado que se pueda actualizar la infraestructura del mismo modo que se hace con un ordenador portátil, un servidor o una carga de trabajo en la nube. Una nave espacial puede estar funcionando con hardware antiguo, memoria limitada, procesadores resistentes a la radiación, ancho de banda restringido, potencia limitada y una ventana de comunicación muy reducida.
Si la actualización es incorrecta, si el comando está mal formado o si el software se comporta de forma diferente en vuelo de lo que lo hacía en la simulación, la recuperación puede resultar difícil o, lo que es peor, imposible.
La Voyager es un ejemplo perfecto. La NASA lanzó la Voyager 1 y la Voyager 2 en 1977, y el equipo sigue manteniéndolas casi cinco décadas después. Actualizar o corregir el software de una nave espacial tan antigua y tan lejana requiere una ingeniería increíble. Pero también demuestra que aplicar parches a una nave espacial es un proceso lento, arriesgado y nada que ver con la aplicación de parches a los sistemas en la Tierra.
Galileo es otro ejemplo ilustrativo. Tras su lanzamiento, la antena de alta ganancia de Galileo no se desplegó por completo, lo que impidió que la nave espacial pudiera utilizar el enlace de comunicación de alta velocidad previsto. Aun así, la NASA y el JPL lograron obtener importantes hallazgos científicos gracias a la compresión de datos, a modificaciones en el software y a una minuciosa planificación de la misión. Esto puso de manifiesto un aspecto clave: en el espacio, las limitaciones de comunicación definen las misiones.
La cuestión de la ciberseguridad es sencilla: ¿qué se hace cuando no se puede contar con una comunicación rápida, una visibilidad constante, una respuesta basada en la nube o el envío de personal in situ? Propongo tres estrategias.
1. Pasar de un enfoque de ciberseguridad espacial centrado en la detección a uno centrado en la prevención
La detección sigue siendo útil, sobre todo en sistemas terrestres, terminales y entornos empresariales relacionados con la misión, pero parte de la base de que se puede detectar el ataque y, a continuación, analizarlo, responder y recuperarse rápidamente. En el espacio, esa suposición es poco sólida, ya que la visibilidad puede ser limitada, las comunicaciones pueden sufrir retrasos, la capacidad de cálculo puede verse restringida y la recuperación puede ser lenta o imposible. Para cuando se detecte el problema, la misión podría estar ya en peligro.
Por eso la estrategia debe centrarse en la prevenciónantes que la confianza.
Cada archivo, actualización de software, modelo de IA, paquete de carga útil, paquete de comandos y dispositivo de almacenamiento extraíble debe considerarse no fiable hasta que haya sido inspeccionado, validado, desinfectado y aprobado. Utiliza el escaneo múltiple, el entorno aislado (sandbox), la desactivación y reconstrucción de contenidos (CDR), la validación de esquemas, las actualizaciones firmadas, las listas de permitidos, la validación de comandos y los registros de auditoría antes de que nada llegue al entorno de misión.
2. Aplicar la segmentación desde el diseño
No trates el control de misión como si fuera un departamento de TI empresarial normal, ni permitas que los sistemas de ingeniería interactúen libremente con los sistemas operativos. Asegúrate de que el acceso de los proveedores sea restringido, temporal, registrado y aislado, y separa de forma rigurosa las estaciones terrestres, las rutas de comando, los sistemas de actualización de software, los entornos de prueba y las herramientas de colaboración.
Ni un solo ordenador portátil comprometido, credencial robada, archivo infectado, actualización defectuosa o violación de seguridad por parte de un proveedor debería poder llegar a las operaciones de misión.
Los cortafuegos son importantes, pero en las rutas de misión más sensibles, yo no confiaría únicamente en un cortafuegos. Los cortafuegos están controlados por software, lo que significa que pueden estar mal configurados, pueden eludirse o verse comprometidos. Un diodo de datos o una pasarela unidireccional es la mejor opción, ya que garantiza el movimiento unidireccional de los datos por diseño, y no solo por política.
3. Acercar las decisiones críticas en materia de seguridad a la misión
Las misiones de larga duración requieren validación local, comprobaciones de integridad a bordo, comportamiento en modo seguro, planificación de la reversión de operaciones cuando sea posible y procesamiento de la seguridad más cerca de la nave espacial. Esto también implica invertir en hardware resistente y tolerante a la radiación, capaz de aplicar los controles de seguridad de forma local. A medida que trasladamos las decisiones de seguridad lejos de la Tierra y más cerca de la misión, no podemos dar por sentado que los servicios tradicionales en la nube, los dispositivos empresariales o los agentes de software vayan a estar siempre disponibles, sean prácticos o sean compatibles con el entorno operativo.
La nube puede facilitar la planificación, el análisis y la coordinación desde la Tierra, pero no debe constituir el circuito de control en tiempo real para decidir si algo es seguro.
Cuanto más nos alejamos de la Tierra, más debe pasar la ciberseguridad de la detección y la respuesta a la prevención, el aislamiento y el alojamiento local.
Llevando la ciberseguridad hacia una nueva frontera

El lanzamiento del MetaDefender Kiosk fue nuestra primera misión espacial, no una estrategia de marketing. Para mí, la misión Kiosk representa lo que considero que son los pilares de la ciberseguridad en el espacio: computación independiente, prevención antes que confianza, seguridad determinista de los archivos y hardware capaz de seguir funcionando en entornos hostiles.
En primer lugar, se trata de un sistema independiente. Aunque lo enviamos a una altitud extrema, no estuvo conectado a la nube durante la misión. Utilizó el procesamiento local y funcionó en un modelo «air-gapped». Tenemos previsto incluir una pasarela de datos unidireccional o un diodo de datos en una misión futura.
En segundo lugar, el Kiosk la tecnología Deep CDR™ para procesar miles de muestras de malware procedentes de una USB durante la misión, en un entorno de pruebas controlado y aislado. La tecnología Deep CDR™ es determinista, lo que significa que no necesita adivinar si un archivo es malicioso. Asume que el archivo puede ser malicioso, elimina el contenido activo de riesgo y regenera una versión limpia. Si se bloquea el proceso adecuadamente, no requiere actualizaciones frecuentes de firmas para prevenir muchas amenazas desconocidas basadas en archivos, ya que el Kiosk el archivo antes de considerarlo fiable.

Por último, probamos el hardware en un entorno hostil. El Kiosk tuvo que soportar temperaturas extremas, baja presión, movimientos violentos, el estallido del globo, altas fuerzas G durante el descenso, giros, caídas e incluso un aterrizaje en un río. Siguió funcionando durante un rato después de todo eso. Esto es importante porque la ciberseguridad espacial es un problema tanto de software como de hardware.

La verdadera lección
La ciberseguridad espacial no puede basarse en la idea de que siempre habrá alguien en la Tierra disponible para solucionar el problema. Debe ser local, determinista, segmentada y dar prioridad a la prevención. Cuanto más se aleja la misión de la Tierra, más importante resulta reducir los elementos en los que la misión debe confiar.
Confía menos en los sistemas. Verifica más. Incorpora los procesos de seguridad a la nave espacial. Segmenta de forma rigurosa. Inspecciona antes de la entrada. Desinfecta antes de usar. Utiliza la transferencia unidireccional de datos cuando sea necesario. Incorpora la seguridad en la misión antes del lanzamiento, porque cuanto más te alejes de la Tierra, más difícil será que la Tierra pueda rescatarte.
A día de hoy, la CISA define 16 sectores como infraestructuras críticas:
- Químico
- Instalaciones comerciales
- Comunicaciones
- Fabricación crítica
- Presas
- Industrial de defensa
- Servicios de emergencia
- Energía
- Servicios financieros
- Alimentación y agricultura
- Instalaciones gubernamentales
- Asistencia sanitaria y salud pública
- Tecnología de la información
- Reactores nucleares, materiales y residuos
- Sistemas de transporte
- Sistemas de agua y de aguas residuales
Creo que el espacio debería ser el sector número 17.
No esperaba estar pensando en la pasta cuando uno de nuestros dispositivos de ciberseguridad acabó en un río tras viajar hasta los límites del espacio, pero tengo que dar las gracias a mi familia y a Jeff Goldblum por la inspiración. También me ha servido para recordar que, ya se trate de la masa de la pasta, de la ciberseguridad o del espacio profundo, los pequeños detalles importan.
Siempre me ha apasionado el espacio. Como muchos niños, en su día soñaba con ser astronauta. En lugar de eso, fundé una empresa de ciberseguridad y piloto aviones de forma privada, pero lanzar un producto de ciberseguridad al espacio me pareció una forma extraña, pero significativa, de volver a conectar con el sueño de mi infancia.
Más allá de la altitud, la tecnología y los vídeos espectaculares, la ciberseguridad debe funcionar en entornos a los que los seres humanos no pueden acceder, reparar o reiniciar fácilmente. En el espacio, no existe un soporte técnico in situ sencillo, ni una sustitución rápida, ni una segunda oportunidad fácil. El sistema debe inspirar plena confianza antes de despegar.
