La ciberseguridad espacial de EE. UU. tiene un problema muy terrenal: nadie manda de verdad

El problema no es que falten satélites. Ni siquiera que falten normas. El problema, bastante más incómodo, es que Estados Unidos sigue sin decidir quién manda de verdad cuando la ciberseguridad del espacio comercial deja de ser una charla de panel y se convierte en una obligación exigible.

Eso, en 2026, ya no es un defecto administrativo pintoresco. Es una debilidad estratégica con factura operativa. Los satélites comerciales prestan servicios a Defensa, inteligencia, telecomunicaciones, navegación, observación, agricultura, logística y respuesta a emergencias. También sostienen cadenas críticas en tierra. Si el sistema falla, el incidente no se queda orbitando con elegancia: cae sobre redes terrestres, centros de mando, proveedores cloud, estaciones terrenas, integradores, fabricantes de software y clientes públicos que darán por hecho que alguien tenía el timón. El detalle es que ese alguien sigue sin aparecer.

La alerta la verbalizaron varios responsables y exresponsables estadounidenses en un simposio organizado por el George Washington University Space Policy Institute y Aerospace Corp. a finales de mayo de 2026. Sam Visner, presidente de Space-ISAC y ex alto cargo federal, resumió el cuadro con una frase que en Washington suele equivaler a una auditoría feroz: si todos mandan, no manda nadie.

No es una exageración teatral. BankInfoSecurity situó el atasco en una secuencia de al menos ocho años de intentos discontinuos de coordinación entre administraciones. Ocho años dan para muchas notas interagenciales, muchos grupos de trabajo y demasiadas reuniones en las que se “alinean esfuerzos”. Dan, también, para confirmar que el problema no es transitorio. Es estructural.

Aquí está el quid: cuando una cadena de suministro depende de satélites privados, enlaces de telemetría, software de misión, terminales de usuario, centros de operación, proveedores de nube y contratistas de defensa, la pregunta “¿quién regula qué?” deja de ser académica. Pasa a ser una cuestión de tiempos de notificación, disciplina contractual, autoridad de supervisión y responsabilidad política cuando algo sale mal. O, más exactamente, cuando salga mal.

El vacío no es normativo; es de mando. Y Washington tiene que decidir ya

Conviene separar dos planos que en este debate se mezclan demasiado. Uno: la existencia de principios, marcos y buenas prácticas. Dos: la autoridad real para convertirlos en obligaciones coherentes, fiscalizables y comparables entre agencias. Estados Unidos no parte de cero en lo primero. Falla, con una constancia casi admirable, en lo segundo.

El antecedente más citado sigue siendo la Space Policy Directive-5, publicada el 4 de septiembre de 2020. Fue relevante por una razón sencilla: por primera vez la Casa Blanca articuló principios integrales de ciberseguridad para sistemas espaciales. Hablaba de gestión de riesgos, desarrollo seguro, autenticación, protección de datos, monitorización, recuperación y respuesta. Útil, sí. Vinculante para toda la industria, no. La directiva era un punto de partida voluntario, no un mecanismo de exigencia.

Jaisha Wray, que trabajó en la Casa Blanca entre 2018 y 2020, lo dijo con una franqueza infrecuente para Washington: la parte de redactar principios voluntarios era la fácil. Lo difícil era traducirlos en requisitos técnicos, gobernanza sostenida y enforcement. Justo ahí es donde el aparato federal ha preferido practicar ese deporte tan local: dejar el asunto en un limbo suficientemente importante como para invocarlo y suficientemente difuso como para no adjudicarse la responsabilidad plena.

Lauryn Williams, con paso por la Casa Blanca entre 2022 y 2024, apuntó al núcleo político del problema: cuando el tema tenía padrino visible dentro de la Casa Blanca, normalmente a través del National Space Council y del vicepresidente, la maquinaria interagencial al menos se movía. Con Mike Pence, el grupo de trabajo sobre ciberseguridad espacial ganó tracción. Bajo la administración Biden, según Williams, el interés del vicepresidente volvió a elevar el asunto. Traducido: el riesgo existe por sí mismo, pero en Washington eso rara vez basta; necesita un patrocinador con rango para forzar cooperación entre agencias que compiten por jurisdicción, presupuesto y relevancia.

Ese modelo ya no sirve. La decisión concreta que debería tomar Washington ahora es más prosaica y bastante menos glamourosa que una nueva gran estrategia espacial: designar por orden ejecutiva, o mediante mandato legislativo si quiere blindarlo, una autoridad civil líder para la ciberseguridad espacial comercial, con una línea base obligatoria y un mecanismo de coordinación formal con el Departamento de Defensa, DHS/CISA, FCC, FAA, NOAA, NASA, la Office of Space Commerce y la comunidad de inteligencia.

Mi lectura es esta: si la prioridad es el segmento comercial y de infraestructura crítica civil, la opción más pragmática sería situar la función ejecutiva en el Departamento de Comercio, apoyándose en la Office of Space Commerce para política sectorial y en NIST para la línea base técnica, con CISA como brazo operativo en intercambio de inteligencia, respuesta y coordinación de incidentes bajo su papel general en infraestructuras críticas. No porque Comercio sea una máquina de acero regulatorio. No lo es. Sino porque Defensa no puede ser el regulador de facto de todo un mercado civil sin terminar contaminando los incentivos, el acceso a información y la arquitectura contractual del sector.

La alternativa sería dejar que cada agencia federal compradora siga elevando requisitos por su cuenta. Eso parece flexible hasta que miras de cerca. En la práctica crea varios problemas a la vez. Primero, multiplica líneas base incompatibles. Segundo, reduce la comparabilidad de auditorías. Tercero, convierte la seguridad en una función del peso negociador del cliente, no del riesgo sistémico. Cuarto, desplaza la normalización hacia cláusulas privadas y programas clasificados que el resto del ecosistema no puede reutilizar. Es una forma muy cara de improvisar.

Qué debería salir de esa decisión. No otro catálogo aspiracional. Hacen falta tres piezas concretas:

La primera, una baseline federal obligatoria para operadores espaciales comerciales que den servicio a agencias federales o soporten funciones críticas, anclada en NIST CSF 2.0 y en controles técnicos trazables a NIST SP 800-53 Rev. 5, con perfiles específicos para segmento espacial, terrestre, enlaces y software de misión. NIST CSF 2.0 se publicó el 26 de febrero de 2024 y, a diferencia de muchas presentaciones públicas sobre resiliencia, ya ofrece una estructura madura para gobierno, identificación, protección, detección, respuesta y recuperación. Lo que falta no es marco; falta convertirlo en condición de acceso al mercado federal.

La segunda, reglas temporales de notificación. Si una entidad presta servicios espaciales críticos al gobierno, no puede tener más margen que otras infraestructuras para decidir cuándo avisa. CISA ya opera con un entorno donde la velocidad importa y donde el Congreso aprobó la Cyber Incident Reporting for Critical Infrastructure Act of 2022 para exigir reglas de notificación a entidades cubiertas. Las normas finales de CIRCIA aún no estaban plenamente en vigor en 2026, pero la dirección política está clara: el tiempo del “ya os avisaremos cuando tengamos el informe completo” se ha terminado. Washington debería fijar, para el sector espacial comercial federal, un esquema al menos equiparable a una alerta temprana en 24 horas para incidentes materialmente disruptivos y a un informe técnico más completo en 72 horas, aunque luego CIRCIA termine afinando otras ventanas para el conjunto de infraestructuras críticas.

La tercera, autoridad de verificación. Sin revisiones independientes, pruebas de resiliencia y consecuencias contractuales, una baseline es decoración. DORA lo entendió mejor que casi nadie en Europa al vincular gobierno del riesgo TIC, pruebas y gestión de terceros en su capítulo II y en el capítulo V, con el artículo 28 como eje para proveedores TIC. Estados Unidos no necesita copiar DORA palabra por palabra. Sí necesita asumir la lección: la seguridad de proveedores estratégicos no mejora solo con PDFs bien maquetados.

El coste de no tomar esta decisión es muy concreto. No hablamos solo de “riesgo elevado”. Hablamos de cuatro costes medibles, aunque la administración prefiera expresarlos en lenguaje diplomático.

El primero es el coste de coordinación en incidentes. Cuando la autoridad no está clara, cada minuto de una intrusión se gasta en determinar quién lidera, quién notifica, quién comparte indicadores de compromiso y qué información puede circular entre clasificación, clientes y operadores. En sistemas donde la telemetría, el mando y el software de tierra están interconectados, ese retraso no es administrativo: aumenta el tiempo de permanencia del atacante y el radio de impacto.

El segundo es el coste contractual. Los grandes compradores federales y los primes de defensa reaccionan a la ambigüedad metiendo sus propias cláusulas. El resultado son anexos de seguridad cada vez más severos, auditorías duplicadas, cuestionarios incompatibles y una barrera de entrada más alta para operadores pequeños o medianos. La seguridad no sube de forma lineal; el coste de cumplimiento, sí.

El tercero es el coste de mercado. Si Washington no fija una baseline, la impondrán actores con capacidad de compra y con menos paciencia para las sutilezas jurisdiccionales: grandes contratistas, aseguradoras ciber, proveedores cloud, operadores de lanzamiento, integradores de defensa y clientes institucionales internacionales. El estándar emergerá por contrato, no por norma. Y cuando eso ocurre, quien más vende no es necesariamente quien mejor protege, sino quien mejor negocia términos y certificaciones.

El cuarto es el coste geopolítico. Estados Unidos presume, con razón, de haber impulsado la comercialización del espacio. Pero si no define un modelo creíble de gobernanza ciber para ese ecosistema, acabará importando exigencias externas de facto. Europa ya tiene un reflejo regulatorio bastante más desarrollado en notificación, terceros, gobernanza y resiliencia. No porque Bruselas entienda mejor los satélites, sino porque entiende mejor cómo convertir dependencia tecnológica en obligación supervisable.

La ironía es casi cruel: el país que más ha hecho por abrir la economía espacial puede terminar dejando que los estándares de seguridad los escriban otros a base de licitaciones, pólizas y cláusulas de procurement.

La fragmentación no es una pelea de despachos: degrada seguridad, encarece contratos y premia la opacidad

Quien lea esto desde fuera del sector podría pensar que estamos ante una clásica guerra burocrática de Washington. Unas cuantas siglas compitiendo por sitio en el organigrama. Fin de la historia. No. La fragmentación competencial tiene efectos operativos directos sobre la superficie de ataque, la calidad de los controles y la disciplina real de proveedores.

Primero, impide fijar una línea base común sobre qué controles son innegociables. Si un operador espacial comercial presta servicios a varias agencias, puede terminar sometido a expectativas distintas según el cliente, la misión, el régimen de clasificación o el contrato prime-subcontractor. Un cliente pedirá alineación con NIST. Otro añadirá cláusulas propias sobre hardening o segregación. Otro confiará en certificaciones parciales. Otro exigirá controles de cadena de suministro vinculados a programas clasificados. El resultado no siempre es mejor seguridad. A veces es simplemente un patchwork caro, inconsistente y difícil de auditar.

Segundo, la dispersión impide priorizar de forma sistémica. En un sector maduro, alguien decide qué es crítico y en qué orden. Por ejemplo: autenticación multifactor resistente a phishing para acceso a sistemas de mando; segregación fuerte entre entornos corporativos, de desarrollo, de misión y de test; cifrado robusto de telemetría, tracking and command; gestión de vulnerabilidades en estaciones terrenas; SBOM y firma de software para cargas útiles y componentes terrestres; logging inmutable; pruebas de intrusión contra interfaces expuestas; requisitos de recuperación con RTO y RPO definidos. Sin autoridad central, el mercado optimiza para ganar el siguiente contrato, no para reducir dependencia sistémica.

Tercero, empeora el intercambio de inteligencia útil. Williams describió una patología conocida por cualquier CISO que haya tratado con información clasificada: la inteligencia de amenazas cibernéticas y la inteligencia sobre capacidades o dependencia espacial no siempre se cruzan bien. Los datos relevantes acaban separados por compartimentos, programas y canales de difusión. El absurdo final es que a veces una sola persona ve el cuadro completo. Eso no es resiliencia. Eso es confiar la coordinación a un cuello de botella humano, justo el tipo de arquitectura que nadie defendería en una red crítica.

Cuarto, retrasa la respuesta a incidentes. Si una intrusión compromete un segmento terrestre operado por un proveedor privado que da servicio a clientes federales y comerciales, aparece de inmediato la colección habitual de preguntas: quién lidera, quién coordina forense, quién consolida IoC, qué obligaciones de notificación aplican, qué restricciones de clasificación limitan el intercambio, cuándo se informa al cliente final y qué agencia asume la interlocución externa. Si esas respuestas se improvisan en medio de la crisis, la organización ya va tarde. NIS2 al menos resolvió ese punto en su artículo 23 al estructurar alerta temprana en 24 horas, notificación en 72 horas e informe final en un mes. Se puede discutir su carga administrativa; lo que no se discute es que fija reloj y responsabilidad.

Quinto, desincentiva inversión útil. Los proveedores invierten mejor cuando saben qué se les exigirá, quién revisará la evidencia y con qué frecuencia. La incertidumbre regulatoria tiene dos salidas, y ninguna es brillante. Una: se invierte de menos porque nadie sabe qué será exigible de verdad. Dos: se invierte en controles vistosos pero secundarios porque suenan bien en ventas, en auditorías superficiales o en las diapositivas del consejo. Entre una estación terrena endurecida y un power point impecable, la burocracia fragmentada suele premiar demasiado a menudo lo segundo.

Sexto, genera asimetrías peligrosas entre operadores grandes y pequeños. Los grandes primes pueden absorber requisitos duplicados, auditorías privadas, equipamiento de seguridad especializado y equipos jurídicos para negociar anexos. Una empresa más pequeña, aunque técnicamente solvente, puede quedar fuera por no soportar el coste de compliance impuesto de forma desordenada. El mercado pierde competencia. La cadena de suministro se concentra. Y la concentración, por cierto, tampoco es gratis desde el punto de vista del riesgo operacional.

Lo que Washington debería hacer en este punto no es seguir celebrando mesas redondas sobre “public-private partnership”. La decisión concreta es menos fotogénica y más útil: emitir una instrucción ejecutiva que obligue a todas las agencias federales con compras de servicios espaciales a usar una baseline técnica común, un proceso único de notificación y una taxonomía compartida de incidentes. El National Space Council puede coordinar políticamente. Pero alguien tiene que quedar encargado de hacer cumplir la convergencia en procurement. Si no, el sistema seguirá premiando la autonomía feudal de cada agencia mientras el sector finge que eso equivale a resiliencia.

El coste de no hacerlo no se verá primero en una gran portada apocalíptica. Se verá antes en cosas más mundanas y más corrosivas: contratos retrasados, due diligence duplicadas, reclamaciones de aseguradoras, operadores expulsados de cadenas de suministro, tiempos de respuesta descoordinados y una inflación silenciosa del coste de seguridad. Esa es la parte que no suele contarse. La ciberseguridad mal gobernada no solo aumenta el riesgo técnico; también encarece el mercado y vuelve opaco el acceso a él.

Y aquí asoma una lectura menos complaciente. La narrativa oficial sigue sugiriendo que más coordinación interagencial acabará resolviendo el problema. No estoy tan seguro. Si en ocho años no se ha consolidado una autoridad clara, quizá el sistema ya ha revelado su preferencia real: tolerar ambigüedad para preservar jurisdicciones. El sector debería leer esa señal sin romanticismo.

La lección incómoda: otros sectores ya aprendieron esto por las malas

Lo interesante de esta historia es que no es nueva. Nuevo es el entorno orbital comercial; viejo es el patrón institucional. Energía, banca, telecomunicaciones y salud han pasado por una secuencia parecida en distintas jurisdicciones. Primero, el regulador trata la ciberseguridad como una combinación de guías voluntarias y cooperación informal. Después, la dependencia operativa crece más rápido que la supervisión. Luego aparecen incidentes, cuasi incidentes o auditorías incómodas. Al final alguien descubre lo obvio: sin obligación, sin calendario y sin verificación, la coordinación informal no escala.

Europa ha recorrido ese camino con una disciplina normativa bastante más visible. No porque Bruselas tenga poderes mágicos, sino porque cuando decide regular, regula de verdad. NIS2, publicada en diciembre de 2022 y aplicable a partir del 18 de octubre de 2024 mediante transposición nacional, obliga en su artículo 21 a medidas de gestión de riesgos de ciberseguridad que incluyen análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, uso de criptografía y autenticación multifactor o continua cuando proceda. El artículo 23 fija la secuencia temporal de notificación: alerta temprana en 24 horas, notificación en 72 horas e informe final en un mes.

El GDPR lleva desde el 25 de mayo de 2018 imponiendo en su artículo 33 la notificación de violaciones de seguridad de datos personales a la autoridad de control sin dilación indebida y, de ser posible, en 72 horas. No es una norma sectorial espacial, pero sí una prueba de que los plazos y la trazabilidad de incidentes ya forman parte del mínimo exigible cuando hay datos personales en juego. Si un operador satelital procesa telemetría asociada a usuarios, localización, imágenes identificables o datos de clientes, no vive al margen de esa lógica.

DORA, plenamente aplicable desde el 17 de enero de 2025, ofrece otra lección mucho más cercana al dilema espacial estadounidense. Su capítulo II impone un marco de gestión del riesgo TIC gobernado desde el órgano de dirección. Su capítulo IV regula pruebas de resiliencia operativa digital. Su capítulo V endurece la disciplina sobre terceros proveedores TIC, con el artículo 28 como centro de gravedad para gestionar riesgo de dependencia externa. La idea es simple: cuando un sector depende de tecnología tercerizada, el regulador no se limita a pedir “buenas prácticas”; exige gobierno, pruebas, inventario, contratos y salida ordenada.

Estados Unidos no necesita copiar la letra europea. Pero convendría que dejara de fingir sorpresa ante la lógica de fondo. Si el espacio comercial es ya una capa de infraestructura crítica, su ciberseguridad necesita algo más que estándares NIST de adopción desigual, programas clasificados fragmentarios y reuniones donde todo el mundo coincide en que el riesgo es serio mientras nadie cede autoridad.

La comparación con NIS2 y DORA es útil por otra razón. Muestra el coste de llegar tarde. En Europa, proveedores estadounidenses que venden a bancos, infraestructuras o entidades sujetas a NIS2 ya están acostumbrándose a responder a cuestionarios de terceros, cláusulas de notificación, pruebas, derechos de auditoría y exigencias de cadena de suministro mucho más concretas que las que les impone su propio gobierno para determinadas operaciones espaciales. Visto desde fuera, la escena tiene un punto ridículo: una empresa puede enfrentarse a más disciplina contractual por dar soporte tecnológico a una entidad financiera europea que por sostener funciones espaciales críticas para clientes estadounidenses.

Esa contradicción acabará corrigiéndose de una forma u otra. La pregunta no es si habrá baseline más exigente. La pregunta es quién la impondrá y con qué legitimidad.

Qué sí existe ya: señales de madurez, todavía dispersas

Sería injusto pintar el panorama como un solar regulatorio. No lo es. Hay avances y algunos importan mucho, sobre todo porque traducen discurso a práctica técnica.

Uno de ellos es el trabajo del National Cybersecurity Center of Excellence de NIST sobre ciberseguridad para sistemas espaciales comerciales. El valor de ese esfuerzo no está en añadir otra capa conceptual, sino en aterrizar principios en arquitecturas de referencia, casos de uso y controles. Para un operador, eso vale más que diez declaraciones solemnes sobre resiliencia orbital. Si una guía te ayuda a decidir cómo segmentar una estación terrena, cómo gestionar identidades privilegiadas, cómo registrar telemetría de seguridad o cómo aislar software de misión, ya sirve para algo.

NIST, además, actualizó el marco general con CSF 2.0 en febrero de 2024, añadiendo una función de Govern que encaja especialmente bien con el problema espacial: sin gobierno claro, el resto de funciones queda técnicamente huérfano. El mensaje implícito es demoledor para Washington: la propia arquitectura del marco reconoce que la seguridad no falla solo por controles débiles, sino por responsabilidades mal asignadas.

Otro avance citado por Lauryn Williams fue el endurecimiento de estándares de seguridad exigidos por agencias de inteligencia a proveedores comerciales de satélites. En otras palabras: cuando el cliente es suficientemente sensible, el gobierno sí sabe pedir más. Eso confirma dos cosas. Una buena: la capacidad técnica y contractual existe. Otra menos halagadora: esa exigencia no se despliega de forma uniforme en el conjunto del mercado ni se convierte automáticamente en baseline reutilizable para operadores que también soportan funciones críticas fuera de programas clasificados.

Space-ISAC ha ganado peso como canal de intercambio de inteligencia sectorial. Eso ayuda. Los ISAC funcionan cuando hay confianza suficiente para compartir TTP, IoC, patrones de intrusión y lecciones aprendidas. Pero un ISAC no sustituye a una autoridad regulatoria, igual que un buen SOC no sustituye al consejo de administración. Puede mejorar visibilidad, no crear exigibilidad.

También hay piezas dispersas en otras agencias. La FCC ha reconocido que sigue trabajando el asunto con otras entidades federales. La FAA y NOAA operan en sus respectivos perímetros de licencias y supervisión. El DoD y la comunidad de inteligencia elevan requisitos donde hay sensibilidad nacional. CISA mantiene su papel transversal en infraestructuras críticas y coordinación de incidentes. La Office of Space Commerce aspira a jugar un rol sectorial mayor. Todo eso suma actividad. Lo que no suma todavía es un tablero coherente.

Y aquí surge la pregunta incómoda: si ya existen estándares, foros y compradores capaces de exigir más, por qué no cristaliza una baseline común. Mi respuesta es que el bloqueo no es técnico. Es político e institucional. Obligar a converger requisitos implica que alguna agencia cederá terreno, que algunas compras federales perderán margen de maniobra y que ciertos programas clasificados dejarán de ser la única referencia de “seguridad seria”. Eso tiene costes internos. Pero seguir evitando esa discusión tiene costes externos bastante mayores.

La superficie de ataque espacial es bastante más terrestre de lo que admite la narrativa oficial

La expresión “ciberseguridad espacial” induce a error. Hace pensar en satélites como objetos aislados, sofisticados, casi exóticos. En realidad, gran parte del riesgo serio está en tierra. En estaciones terrenas, centros de mando, pipelines de desarrollo, equipos de soporte, APIs, redes corporativas, sistemas de identidades, terminales de usuario, componentes OT/IoT asociados y dependencias cloud. El segmento orbital importa, desde luego. Pero el atacante suele entrar por donde siempre ha entrado: credenciales, terceros, software vulnerable, mala segmentación, herramientas remotas expuestas o procesos operativos débiles.

La propia Space Policy Directive-5 reconocía esa amplitud al referirse a space systems como el conjunto de satélites, terminales de usuario, equipos de enlace, redes y software asociados. Esa definición ya era una pista de que el problema no cabía en un esquema puramente aeroespacial. Aun así, el debate político sigue atrapado en una estética espacial que a veces esconde la parte más pedestre del riesgo: demasiadas de las vulnerabilidades explotables están en capas tecnológicas que cualquier CISO de banca o energía reconocería al instante.

Eso importa por dos razones. La primera es técnica. Muchos controles críticos no requieren inventar una disciplina nueva, sino aplicar con rigor prácticas bien conocidas: hardening, IAM, PAM, segmentación, monitorización, desarrollo seguro, gestión de vulnerabilidades, backup inmutable, pruebas de recuperación, seguridad de terceros, registros forenses fiables y control de cambios. La segunda es regulatoria. Si la superficie de ataque es híbrida y terrestre, la gobernanza también debe serlo. No sirve repartir el problema entre agencias “espaciales” y dejar fuera a quienes dominan la ciberseguridad de infraestructura crítica o los marcos federales de procurement.

Hay otra implicación menos visible. Cuanto más terrestre es la superficie de ataque, más falsa resulta la idea de que la ciberseguridad espacial puede tratarse como una excepción de nicho. No lo es. Comparte riesgos con telecomunicaciones, cloud, software industrial y cadenas de suministro TIC. Eso significa que el sector espacial debería absorber, y rápido, lecciones que otros sectores ya han pagado con incidentes reales: dependencia excesiva de terceros, visibilidad insuficiente, privilegios sobredimensionados, pruebas de recuperación inexistentes y capacidad forense limitada cuando los sistemas de misión conviven con arquitectura heredada.

La narrativa oficial suele preferir un lenguaje más elegante: “ecosistema complejo” o “dominio convergente”. Llámalo como quieras. El problema sigue siendo bastante terrenal. Y por eso mismo la solución no debería venderse como una gran épica espacial, sino como lo que es: gobierno de riesgo, procurement coordinado y controles verificables.

Lo que debería hacer ahora una empresa espacial que vende al gobierno: 7 controles priorizados, responsable y evidencia

Mientras Washington decide si le apetece gobernar o seguir moderando paneles, los CISO y responsables de compliance del sector no pueden quedarse esperando. Si tu empresa opera satélites, estaciones terrenas, software de misión o servicios asociados para clientes federales o infraestructuras críticas, hay un bloque de controles que conviene priorizar ya. No porque todos vayan a ser obligatorios mañana con la misma redacción, sino porque son los que más probablemente acabarán exigiendo compradores, aseguradoras, auditores y primes de defensa. También son los que mejor resisten cualquier cruce futuro con NIST CSF 2.0, NIST SP 800-53 Rev. 5, FedRAMP cuando aplique, CMMC en cadenas de defensa, NIS2 para operaciones europeas, GDPR si hay datos personales y cláusulas contractuales específicas de terceros.

1. Inventario y clasificación de activos de misión, segmento terrestre y terceros críticos

Responsable: CISO con apoyo del responsable de ingeniería de misión, IT asset owner y procurement.

Qué hay que tener: un inventario vivo que cubra satélites, estaciones terrenas, terminales, enlaces, entornos de desarrollo, sistemas de control, identidades privilegiadas, software de misión, APIs expuestas, componentes cloud y terceros que tengan acceso lógico o físico relevante. Debe incluir clasificación por criticidad, dependencia contractual, propietario interno y requisitos de recuperación.

Referencia útil: NIST CSF 2.0 (Identify/Govern), NIST SP 800-53 CM-8 sobre inventario de componentes del sistema, SR-3 y SR-5 para cadena de suministro, DORA art. 8 y art. 28 como analogía práctica de inventario y gestión de terceros TIC, NIS2 art. 21.2 sobre seguridad de la cadena de suministro.

Evidencia esperada: CMDB o registro equivalente exportable; mapa de dependencias entre segmento espacial, terrestre y cloud; lista de terceros críticos; clasificación de activos firmada por negocio y seguridad; revisiones trimestrales con control de cambios.

Por qué va primero: sin inventario fiable, cualquier programa de parcheo, monitorización o respuesta a incidentes es un ejercicio de fe. Y la fe, en ciberseguridad, sale carísima.

2. Gestión de identidades privilegiadas y MFA resistente a phishing en sistemas de mando y soporte

Responsable: CISO y responsable de IAM/PAM; validación del COO o director de operaciones de misión cuando haya impacto operacional.

Qué hay que tener: MFA resistente a phishing para administradores y operadores con acceso a sistemas de misión, estaciones terrenas y entornos cloud; cuentas nominativas; eliminación de cuentas compartidas salvo break-glass controlado; bastionado de accesos remotos; PAM con grabación de sesiones para privilegios altos; revisión periódica de privilegios; separación entre roles de desarrollo, operación y administración.

Referencia útil: NIST SP 800-53 IA-2, IA-5, AC-2, AC-6 y AC-17; NIS2 art. 21.2.i sobre autenticación multifactor o continua; SPD-5 sobre acceso seguro y autenticación; principios de zero trust adoptados transversalmente por agencias federales tras la Executive Order 14028 de 12 de mayo de 2021.

Evidencia esperada: matriz de roles y privilegios; export de configuración MFA; logs de PAM; revisiones mensuales de cuentas privilegiadas; registro de accesos break-glass; evidencia de desactivación de cuentas huérfanas tras bajas o cambios de puesto.

Señal de madurez real: si todavía hay credenciales compartidas para operaciones críticas “porque así es más práctico en turno”, tienes un problema serio aunque la documentación diga lo contrario.

3. Segmentación fuerte entre red corporativa, desarrollo, test y operaciones de misión

Responsable: responsable de arquitectura de seguridad y director de infraestructuras/OT o segmento terrestre.

Qué hay que tener: separación lógica y, cuando el riesgo lo justifique, física entre entorno corporativo, desarrollo, laboratorio, misión y administración; control estricto de flujos permitidos; salto administrado mediante bastiones; monitorización de tráfico este-oeste; revisión de reglas de firewall y allowlists; procedimientos específicos para transferencia de software y datos hacia sistemas de misión.

Referencia útil: NIST SP 800-53 SC-7, AC-4, CM-7, CA-8; NIS2 art. 21 sobre seguridad de redes y sistemas; SPD-5 sobre protección de sistemas y segmentación. Para proveedores con contratos federales sensibles, muchos de estos controles también aparecerán de forma indirecta en anexos de seguridad de programa o en evaluaciones basadas en 800-53.

Evidencia esperada: diagramas de red aprobados y fechados; reglas de segmentación con justificación; registros de revisión semestral; evidencia de pruebas de intrusión o validación de segmentación; tickets de cambios aprobados; resultados de monitorización de flujos anómalos.

Riesgo que reduce: que un compromiso en correo, VPN de tercero o entorno de desarrollo acabe pivotando hacia sistemas de operación. Es el tipo de trayecto que luego todo el mundo describe como “sofisticado” para no admitir que la segmentación era insuficiente.

4. Gestión de vulnerabilidades y parches con excepciones formales para activos de misión

Responsable: CISO, responsable de infraestructura y dueño técnico de cada sistema crítico; supervisión del comité de riesgo.

Qué hay que tener: escaneo de vulnerabilidades en segmento terrestre y activos IT; proceso diferenciado para activos de misión donde no sea viable parchear de inmediato; ventana de remediación basada en criticidad; compensating controls documentados para excepciones; seguimiento de CVE explotables; inventario de software y firmware, idealmente con SBOM donde sea posible.

Referencia útil: NIST SP 800-53 RA-5, SI-2, CM-2, CM-3; Executive Order 14028 y memorandos posteriores de la administración sobre software supply chain y SBOM en procurement federal; NIS2 art. 21; DORA como referencia indirecta de gestión continua del riesgo TIC y pruebas.

Evidencia esperada: dashboard de vulnerabilidades por criticidad; SLA de remediación; actas de excepciones firmadas por riesgo y negocio; SBOM o listados de componentes para software crítico; evidencias de parcheo y de controles compensatorios.

Punto fino: en sistemas espaciales no siempre podrás aplicar el mismo calendario que en IT corporativa. Lo que sí podrás y deberás hacer es demostrar por qué no parcheas, qué control compensa el riesgo y cuándo revisarás de nuevo la excepción. Sin eso, la excepción no es ingeniería prudente; es abandono documentado con mejor tipografía.

5. Registro, detección y retención forense en estaciones terrenas, accesos remotos y software de misión

Responsable: SOC manager o responsable de detección y respuesta, junto con el CISO y operaciones de misión.

Qué hay que tener: logging centralizado y protegido frente a alteración; sincronización temporal fiable; casos de uso de detección para accesos anómalos, cambios de configuración, movimientos laterales, manipulación de software de misión, uso indebido de privilegios y comunicaciones inusuales con activos de operación; retención suficiente para investigación; integración con inteligencia de amenazas relevante para sector espacial.

Referencia útil: NIST SP 800-53 AU-2, AU-6, AU-9, SI-4, IR-5; NIST CSF 2.0 Detect/Respond; CISA Shields Up y guías operativas de logging; NIS2 art. 21 sobre gestión de incidentes y detección.

Evidencia esperada: catálogo de fuentes de log; casos de uso SIEM/EDR; pruebas de integridad de logs; ejercicios de búsqueda retrospectiva; informes de retención; playbooks de investigación con tiempos objetivo.

La prueba del algodón: si mañana sospechas de una manipulación en un sistema de mando, podrías reconstruir quién hizo qué, desde dónde y con qué credencial? Si la respuesta es “depende”, la respuesta real es “no”.

6. Gestión de terceros y cláusulas contractuales de notificación, auditoría y subcontratación

Responsable: compliance officer y procurement, con soporte jurídico y CISO.

Qué hay que tener: clasificación de terceros por criticidad; due diligence antes de contratación; cláusulas de seguridad y notificación de incidentes con ventanas concretas; derecho de auditoría o al menos derecho a recibir evidencias de controles; obligación de flujo descendente a subcontratistas; requisitos de ubicación de datos y accesos remotos cuando apliquen; control de fin de contrato y retirada de accesos.

Referencia útil: DORA art. 28 y ss. como benchmark particularmente útil sobre terceros TIC; NIS2 art. 21.2.d y 21.2.e sobre continuidad y cadena de suministro; NIST SP 800-53 SR family; CIRCIA como señal de endurecimiento en notificación de incidentes para infraestructuras críticas; cláusulas FAR/DFARS cuando el contrato federal o de defensa las incorpore.

Evidencia esperada: registro de terceros críticos; plantillas contractuales aprobadas; evaluaciones previas; seguimiento de remediación; listado de subprocesadores o subcontratistas relevantes; evidencias de ejercicio de derechos de auditoría o revisiones documentales.

Por qué es prioritario: en este mercado, muchos estándares acabarán entrando por contrato antes que por regulación. Si tu función de procurement sigue comprando “servicios espaciales” como si fuesen licencias de software estándar, el problema no es el proveedor; es tu proceso.

7. Respuesta a incidentes y ejercicios conjuntos con clientes federales y operadores clave

Responsable: CISO, director de operaciones, legal/compliance y responsable de relaciones con clientes gubernamentales.

Qué hay que tener: playbooks específicos para compromiso de estación terrena, pérdida o degradación de telemetría, alteración de software de misión, secuestro de credenciales privilegiadas, compromiso de tercero y pérdida de disponibilidad de servicios críticos; lista actualizada de contactos de agencias y clientes; criterios de escalado jurídico y de clasificación; ejercicios de mesa y simulacros técnicos al menos anuales; pruebas de notificación cruzada con terceros críticos.

Referencia útil: NIST SP 800-61 Rev. 2 como referencia clásica de respuesta a incidentes; NIST SP 800-53 IR family; NIS2 art. 23 para estructura temporal de notificación; GDPR art. 33 cuando haya datos personales; principios de resiliencia y pruebas de DORA como benchmark organizativo aunque no sea aplicable directamente.

Evidencia esperada: plan IR fechado; resultados de tabletop y ejercicios técnicos; lecciones aprendidas con plan de acción; lista de contactos validada; cronología y minutas de simulacros; métricas de MTTD/MTTR y de tiempos de notificación.

La diferencia entre teatro y preparación: un playbook no vale por existir. Vale si se ha probado con operaciones, legal, clientes y dirección. Si nunca has hecho un ejercicio en el que un proveedor de segmento terrestre falle a las 3 de la mañana de un festivo, no has probado nada parecido al mundo real.

Fechas y hitos que el sector no debería perder de vista

Para no convertir esto en un resumen institucional con esteroides, aquí va solo la cronología que realmente altera decisiones operativas o de compliance:

4 de septiembre de 2020: publicación de la Space Policy Directive-5, primer marco presidencial de principios de ciberseguridad para sistemas espaciales. Relevancia práctica: base conceptual, no baseline obligatoria.

12 de mayo de 2021: Executive Order 14028 sobre mejora de la ciberseguridad nacional. No es espacial, pero empuja zero trust, logging, software supply chain y SBOM en el ecosistema federal. Relevancia práctica: el listón de procurement tecnológico sube para proveedores con exposición al gobierno.

15 de marzo de 2022: firma de CIRCIA. Relevancia práctica: el Congreso ya dejó claro que quiere notificación obligatoria para incidentes en infraestructuras críticas, aunque la implementación detallada dependa de reglas posteriores.

27 de diciembre de 2022: publicación de NIS2 en el Diario Oficial de la UE. 18 de octubre de 2024: fecha límite de transposición. Relevancia práctica: operadores y proveedores con presencia europea o clientes afectados deben asumir medidas del artículo 21 y reloj del artículo 23.

26 de febrero de 2024: NIST publica CSF 2.0. Relevancia práctica: se consolida una estructura moderna que Washington podría convertir en baseline espacial sin necesidad de reinventar taxonomías.

17 de enero de 2025: DORA pasa a ser plenamente aplicable. Relevancia práctica: proveedores tecnológicos que vendan al sector financiero europeo ya viven bajo una disciplina de terceros, pruebas y gobernanza más explícita. Ese estándar se filtrará por procurement a otros sectores, incluido el espacial.

Finales de mayo de 2026: simposio del George Washington University Space Policy Institute y Aerospace Corp. Relevancia práctica: responsables actuales y exresponsables verbalizan en público lo que el mercado intuía desde hace años: la fragmentación ya no puede esconderse detrás de eufemismos.

La lectura operativa de esta cronología es bastante simple. El estándar mínimo de diligencia ya no lo marca lo que el sector espacial ha exigido históricamente, sino lo que otros sectores críticos ya están exigiendo hoy. Quedarse en el nivel de 2020 no es prudencia. Es atraso.

La pregunta que Washington evita: quién acabará fijando el estándar si el Gobierno no lo hace

La narrativa oficial insiste en que la solución pasa por más coordinación, más diálogo público-privado y más trabajo conjunto entre agencias. Todo eso suena impecable. También suena a algo que llevamos oyendo demasiado tiempo. Mi lectura es más seca: si Washington no designa pronto una autoridad líder con baseline común y enforcement contractual uniforme, el estándar real no lo fijará el regulador. Lo fijará el mercado, pero no de forma abierta ni especialmente igualitaria.

Quiénes impondrán ese estándar por la vía contractual. Primero, los grandes primes de defensa y aeroespacial, que ya tienen músculo para exigir auditorías, flujos de notificación y controles específicos a subcontratistas. Segundo, los proveedores cloud y de conectividad que concentran la infraestructura digital sobre la que corren muchas operaciones de misión. Tercero, las aseguradoras ciber y de riesgo espacial, que restringirán cobertura o encarecerán primas si no ven disciplina mínima en identidad, segmentación, terceros y respuesta a incidentes. Cuarto, los clientes europeos y multilaterales sujetos a NIS2, DORA, GDPR o marcos nacionales más intervencionistas. Quinto, y esto se subestima demasiado, los propios equipos jurídicos de las agencias federales, que acabarán insertando requisitos cada vez más duros contrato por contrato para cubrir vacíos que nadie se atrevió a resolver arriba.

Eso producirá un efecto perverso. Habrá un estándar de facto, sí, pero será menos transparente, menos uniforme y más costoso que una baseline federal clara. Se negociará en anexos, auditorías privadas, cuestionarios de due diligence y requisitos de programa. Los actores grandes se adaptarán. Los pequeños pagarán peaje o quedarán fuera. Y la administración podrá seguir diciendo que el ecosistema evoluciona. Evolucionará, desde luego. Solo que lo hará de la forma más típicamente estadounidense posible: dejando que la autoridad pública llegue tarde y que el procurement privado haga el trabajo sucio.

Mi predicción es bastante nítida. Salvo que la Casa Blanca o el Congreso fuercen una arquitectura de mando clara antes de 2027, los estándares efectivos de ciberseguridad espacial comercial en EE. UU. no los impondrá una regulación sectorial robusta en primer término. Los impondrán los contratos de defensa, las pólizas de seguro, las plataformas cloud y las exigencias extraterritoriales de clientes extranjeros. Washington conservará el discurso de liderazgo. El mercado repartirá las obligaciones reales. Y cuando eso ocurra, la Administración descubrirá que ha cedido la normalización no a un regulador rival, sino a una mezcla de primes, juristas y aseguradoras. No es la forma más noble de gobernar un sector estratégico. Pero a estas alturas parece, peligrosamente, la más probable.

En resumen: el problema de la ciberseguridad espacial de Estados Unidos no es la falta de tecnología ni la ausencia absoluta de marcos. Es la negativa prolongada a decidir quién manda, qué baseline se exige y cómo se prueba. Esa indecisión ya tiene coste. Y si Washington sigue posponiendo la decisión, no habrá vacío. Los vacíos regulatorios nunca duran mucho. Simplemente los llenarán otros, con cláusulas más opacas, precios más altos y bastante menos paciencia para la ambigüedad institucional.