Introducción
La cuestión de la adquisición es si el objetivo puede seguir protegiendo las misiones espaciales, los datos de los clientes y las rutas de mando después de los cambios de propiedad. El crecimiento de los ingresos y los logotipos de los clientes son importantes, pero no responden a esa pregunta. El valor de la ciberseguridad espacial reside en un sistema conectado que incluye registros de ingeniería, lanzamientos de software, raíces de confianza del hardware, material criptográfico, servicios de identidad, controles de red, procedimientos de misión, personal autorizado, aprobaciones de clientes y capacidad de recuperación. Una debilidad en una parte puede limitar el valor de todo el sistema.
Los sistemas espaciales también tienen un ciclo de vida distintivo. Los componentes pueden permanecer en órbita durante años después del lanzamiento, las ventanas de comunicación pueden ser limitadas, el reemplazo es costoso y la reparación remota puede verse limitada por la energía, el ancho de banda, la capacidad del procesador o las reglas de seguridad. Los sistemas terrestres combinan la tecnología de la misión con TI empresarial, servicios en la nube, tecnología operativa y conexiones con proveedores. CISA describe el segmento terrestre como altamente accesible e interconectado, mientras que la guía de la NASA cubre tanto el segmento de vehículos espaciales como el segmento terrestre. Por lo tanto, el perímetro de diligencia debe extenderse desde el desarrollo y la cadena de suministro hasta el lanzamiento, las operaciones, la respuesta a incidentes y el desmantelamiento.
El artículo utiliza dos disciplinas de valoración. La primera es una disciplina de evidencia: cada reclamo de prima está vinculado a una configuración, entorno operativo, período, registro de origen y consecuencia para el cliente. La segunda es una disciplina de efectivo: la evidencia cambia la confianza en los ingresos, el margen, el costo de remediación, las necesidades de capital, la exposición contractual y la protección de las transacciones. Este enfoque evita asignar una prima estratégica vaga a un conjunto de características cibernéticas.
1 Definir el sistema de aseguramiento de la misión adquirido
El perímetro de la transacción debe comenzar con los servicios que compran los clientes y los resultados de la misión que respaldan esos servicios. Un objetivo puede vender operaciones de misión seguras, protección de comando satelital, monitoreo de segmentos terrestres, administración de claves criptográficas, inteligencia sobre amenazas, desarrollo de software seguro, servicios de identidad, respuesta a incidentes o una plataforma combinada. Cada servicio depende de diferentes activos y pruebas. El comprador debe definir la misión protegida, los usuarios autorizados, los flujos de datos, las rutas de comando, los niveles de servicio, los límites operativos y las consecuencias de las fallas para cada flujo de ingresos materiales.
El perímetro debe incluir todas las entidades que contribuyen a la entrega. Estos pueden incluir un propietario de software, una subsidiaria de servicios administrados, un equipo de operaciones autorizado, un inquilino de la nube, un proveedor de hardware, un socio de estación terrestre y una empresa matriz que posee contratos o licencias de clientes. Los bienes compartidos requieren especial atención. Un objetivo puede reportar un margen bruto atractivo mientras depende de la plataforma de identidad, el centro de operaciones de seguridad, el proceso de desarrollo o la infraestructura criptográfica de una empresa matriz a un costo inferior al del mercado.
El modelo de adquisición debe identificar qué capacidades se transfieren en el momento del cierre, cuáles requieren consentimiento, cuáles permanecen bajo servicios de transición y cuáles deben reconstruirse. También debe identificar los activos que son valiosos sólo en combinación. Un motor de detección de amenazas puede tener un valor independiente limitado cuando sus datos de entrenamiento, telemetría de misión, derechos de implementación o analistas expertos no se transfieren. El perímetro de la transacción se convierte en la base de la lista de solicitudes de diligencia, el plan de separación y el modelo de valoración.
2 Trate el patrimonio de vuelo como una afirmación de evidencia limitada
La NASA describe la preparación tecnológica en nueve niveles e identifica la tecnología como vuelo probado en TRL 9 después de un uso exitoso de la misión. Esa clasificación es útil, pero una adquisición requiere una pregunta más detallada: ¿qué voló exactamente, en qué configuración, en qué condiciones, durante cuánto tiempo y con qué resultado aceptado? Una misión exitosa que involucra un componente no establece que versiones posteriores, nuevas interfaces o un entorno operativo diferente compartan la misma evidencia.
La herencia de vuelo debe registrarse al nivel de identidad de configuración. El registro debe incluir la revisión y la pieza de hardware, la versión de software y firmware, el módulo criptográfico, la procedencia de la construcción, las bibliotecas, las interfaces, la arquitectura de implementación, el perfil de la misión, la órbita o el entorno, la duración operativa, las anomalías, las acciones correctivas y la aceptación del cliente. Cuando el producto adquirido es principalmente software terrestre, el patrimonio relevante puede incluir el uso sostenido de la misión, el rendimiento de la ventana de comando, la disponibilidad, el historial de incidentes y la recuperación en lugar de la exposición física al lanzamiento y la órbita.
El patrimonio puede decaer cuando cambia la configuración. La guía de ingeniería de sistemas de la NASA reconoce que los componentes del patrimonio pueden requerir una evaluación de madurez renovada cuando la arquitectura o el entorno cambian. Por lo tanto, el comprador debe construir un registro delta entre la configuración evidenciada y el producto ofrecido en el momento de la firma. Los cambios importantes en el procesador, el sistema operativo, el protocolo de comunicaciones, la criptografía, el entorno de alojamiento, la autonomía o la integración pueden reducir la relevancia de la evidencia anterior hasta que nuevas pruebas o el uso de la misión cierren la brecha.
3 Construya la escalera de evidencia patrimonial
La escala de evidencia debe distinguir entre afirmación, demostración, configuración calificada, uso operativo y uso repetido aceptado. El material de marketing se encuentra en la parte inferior porque establece el reclamo sin demostrar su alcance. Los resultados de las pruebas internas añaden evidencia cuando se controlan el entorno y los criterios de aceptación. La aceptación del cliente, los registros de misión y el cierre de anomalías proporcionan pruebas más sólidas. El uso repetido en misiones, clientes o entornos respalda una inferencia más amplia sobre la confiabilidad, siempre que el linaje de configuración permanezca claro.
El comprador debe buscar registros primarios: documentos de control de configuración, informes de prueba firmados, registros de misión, historiales de comando, tickets de incidentes, decisiones de revisión de anomalías, registros de liberación, aceptación del cliente, informes de nivel de servicio y garantía independiente. Las llamadas de referencia pueden explicar el comportamiento operativo, pero no deberían reemplazar los registros. Un cliente puede estar satisfecho con un servicio general sin ser consciente de las excepciones de control o las dependencias de los proveedores.
Cada reclamo patrimonial debe recibir una declaración de alcance y una calificación de confianza. La declaración de alcance identifica lo que respalda la evidencia. La calificación de confianza refleja calidad récord, independencia, coherencia y actualidad. Luego, los ingresos deben asignarse al alcance admitido. Un contrato que utiliza la configuración evidenciada exacta puede recibir una mayor confianza en el pronóstico que un nuevo programa que requiere una arquitectura modificada, una nueva criptografía y un entorno de nube diferente.
4 Traducir el patrimonio en valoración
El patrimonio de vuelo puede afectar la valoración a través de varias rutas. Puede mejorar la elegibilidad de las ofertas, acortar la garantía del cliente, reducir el costo de las pruebas, respaldar los precios, reducir la exposición a la garantía y mejorar la probabilidad de que los hitos contratados se conviertan en efectivo. También puede reducir el tiempo y el capital necesarios para adaptar un producto a una nueva misión. Estos beneficios deberían reflejarse en supuestos de pronóstico específicos en lugar de una prima no asignada.
El modelo de ingresos debe separar la herencia de configuración exacta, la herencia derivada y la tubería no probada. Los ingresos por configuración exacta utilizan un producto y un entorno respaldados por registros aceptados. Los ingresos derivados dependen de un cambio acotado con verificación documentada. La tubería no probada depende del nuevo desarrollo material, la calificación o la aprobación del cliente. Cada clase debe tener una probabilidad de conversión, un costo de entrega, un cronograma y una puerta de evidencia establecidos.
El modelo de costos debe capturar la ingeniería de mantenimiento, la corrección de vulnerabilidades, la obsolescencia, la recertificación, los entornos de prueba, el apoyo a la misión y los seguros. Un producto patrimonial puede conllevar costosas dependencias heredadas. Bibliotecas no compatibles, hardware no disponible, interfaces no documentadas o personal irremplazable pueden convertir el éxito pasado en fragilidad futura. El comprador debería premiar el patrimonio transferible y mantenible en lugar de solo la antigüedad.
5 Definir confianza cero como capacidad operativa impuesta
NIST SP 800-207 describe la confianza cero como una arquitectura centrada en los recursos en la que la ubicación o la propiedad no crean una confianza implícita. La autenticación y la autorización se producen antes de una sesión en un recurso protegido. Para una adquisición, la pregunta importante es si estos principios se implementan en todo el patrimonio relevante del objetivo y si el comprador puede operarlos después del cierre.
Una capacidad creíble comienza con inventarios de identidades, dispositivos, cargas de trabajo, datos, servicios y rutas privilegiadas. Incluye puntos de decisión y cumplimiento de políticas, autenticación sólida, postura del dispositivo o carga de trabajo, privilegios mínimos, segmentación, telemetría protegida y evaluación continua. Los servicios nativos de la nube también requieren identidades de servicio, políticas de carga de trabajo a carga de trabajo y observación del comportamiento de las aplicaciones distribuidas. Los sistemas de misión añaden dispositivos restringidos, enlaces intermitentes, límites de seguridad y comandos cuyo fallo puede tener consecuencias irreversibles.
El comprador debe evitar tratar la lista de características de un producto como una capacidad empresarial. El objetivo puede vender software de confianza cero mientras opera su propio entorno de desarrollo o misión con amplio acceso de administrador, credenciales compartidas o registros incompletos. El registro de diligencia debe separar los controles integrados en el producto, los controles utilizados para brindar servicios administrados y los controles que protegen los sistemas corporativos y de desarrollo del objetivo.
6 Mapea la superficie de ataque espacial
El mapa de amenazas debe seguir el ciclo de vida completo del satélite descrito en las directrices actuales de seguridad espacial. Los riesgos de desarrollo incluyen código fuente comprometido, sistemas de construcción, equipos de prueba, datos de diseño y componentes de proveedores. Los riesgos de implementación incluyen logística, interfaces de lanzamiento, inicialización y aprovisionamiento de credenciales. Los riesgos operativos incluyen TI empresarial, servicios en la nube, estaciones terrestres, enlaces de comunicaciones, sistemas de control de misión, procesadores de naves espaciales, software de carga útil e interfaces de clientes. El desmantelamiento añade revocación de credenciales, disposición de datos y riesgo de control residual.
El segmento terrestre merece pruebas detalladas porque combina redes accesibles con autoridad de misión. Una cuenta empresarial comprometida puede conducir a un repositorio de desarrollo, un portal de soporte o una ruta de administración remota. Un servicio del sistema terrestre comprometido puede afectar la programación, la telemetría, la aprobación de comandos o las operaciones de carga útil. Por lo tanto, la segmentación de la red debe estar respaldada por controles de identidad, aplicaciones y datos en lugar de un solo diagrama.
El mapa de amenazas también debería mostrar a terceros. Las redes de estaciones terrestres, los proveedores de la nube, los proveedores de componentes, los mantenedores de software, los consultores y los clientes pueden recibir acceso o datos. Cada conexión debe tener un propósito comercial, propietario, método de autenticación, alcance de privilegios, registro, cadencia de revisión y proceso de terminación. Las conexiones desconocidas o no administradas se convierten en un riesgo cibernético y en un trabajo de integración después del cierre.
7 Prueba de identidad y acceso privilegiado
La evidencia de identidad debe cubrir usuarios humanos, cuentas de servicio, cargas de trabajo, dispositivos y credenciales de máquinas. El comprador debe conciliar directorios, sistemas de control de acceso, herramientas de acceso privilegiado, identidades en la nube, repositorios de códigos, aplicaciones de misión y plataformas de soporte. Las cuentas inactivas, los administradores locales, las credenciales compartidas y las cuentas de servicios no administradas deben cuantificarse y vincularse a sistemas y contratos.
El acceso privilegiado requiere evidencia del flujo de trabajo. El objetivo debe poder demostrar solicitud, aprobación, limitación de tiempo, control de sesión, registro, revisión y revocación. El acceso de emergencia debe existir para condiciones definidas y debe crear un registro auditable. El soporte remoto de proveedores debe estar limitado por la identidad, el dispositivo, el tiempo, el destino y el propósito. Una política que requiere estos pasos tiene valor limitado cuando los registros de producción muestran un privilegio permanente.
La separación y la integración pueden alterar el control de la identidad. El comprador debe saber qué proveedor de identidad, token de hardware, autoridad de certificación y plataforma de acceso privilegiado sobreviven al cierre. Si el objetivo depende del servicio de un vendedor, el acuerdo de transición debe establecer niveles de servicio, obligaciones ante incidentes, acceso a datos, soporte de salida y un plan de migración financiado. El modelo de valoración debe incluir licencias duplicadas, equipos de migración y la posibilidad de reaprobación del cliente.
8 Segmentación de pruebas y control de ruta de comando
La segmentación debe evaluarse mediante la observancia de la aplicación de la ley. El equipo de diligencia debe identificar zonas de confianza, flujos permitidos, propietarios de políticas, procesos de excepción y monitoreo. Las pruebas deben confirmar que las rutas no autorizadas están bloqueadas y que las rutas aprobadas llevan la identidad, el cifrado y el registro esperados. La evaluación debe incluir las conexiones de la empresa al desarrollo, del desarrollo a la prueba, de la prueba a la misión, del apoyo a la producción y de los socios.
Las rutas de comando necesitan controles adicionales porque pueden afectar el estado de la misión. El comprador debe identificar quién puede originar, aprobar, transmitir, modificar y reproducir comandos. La evidencia sólida incluye comandos autenticados, autorización dual para acciones críticas, separación de funciones, listas de comandos permitidos, controles de secuencia, telemetría protegida, simulación, ejercicios presenciados y revisión independiente. La arquitectura debería evitar que un administrador corporativo obtenga autoridad de misión a través de un servicio compartido indirecto.
Deben registrarse las limitaciones de las naves espaciales. Es posible que una plataforma más antigua no admita algoritmos contemporáneos, rotación frecuente de credenciales o políticas detalladas. El objetivo debe mostrar controles compensatorios en las puertas de enlace, sistemas terrestres y procedimientos operativos. El comprador debe valorar el servicio resultante basándose en la reducción de riesgos probada y la aceptación del cliente, mientras financia la arquitectura de próxima generación por separado.
9 Examinar el desarrollo seguro y la cadena de suministro de software.
El valor adquirido a menudo depende del software propietario y de la capacidad del objetivo para cambiarlo de forma segura. La diligencia debe cubrir el control de fuente, protección de sucursales, revisión de código, procedencia de compilación, gestión de dependencias, secretos, evidencia de prueba, manejo de vulnerabilidades, aprobación de lanzamiento e implementación. El marco de desarrollo de software seguro del NIST proporciona una base útil para organizar estas preguntas.
La lista de materiales del software debe conciliarse con los productos enviados y los servicios activos. Es insuficiente el documento presentado para la diligencia cuando no puede regenerarse a partir de la construcción. El comprador debe identificar paquetes no compatibles, licencias restrictivas, vulnerabilidades conocidas, credenciales integradas, restricciones de exportación y componentes suministrados bajo términos no transferibles. También debe identificar qué configuraciones de misión no pueden parchearse sin la aprobación del cliente o sin riesgo operativo.
La construcción y firma de infraestructura es un activo de control. El objetivo debe demostrar quién puede producir una versión, cómo se verifican las entradas de la compilación, cómo se firman los artefactos, dónde se guardan las claves de firma y cómo los clientes verifican las actualizaciones. El comprador debe planificar el cambio de propiedad de los repositorios, canalizaciones, certificados y claves antes del cierre. Una cadena de firma rota puede retrasar los lanzamientos y debilitar la confianza del cliente incluso cuando el código subyacente es sólido.
10 Evaluar la agilidad criptográfica y la gestión de claves
La capacidad criptográfica debe inventariarse en datos en reposo, datos en tránsito, autenticación de comandos, firma de software, identidad, telemetría e integración de clientes. El inventario debe identificar el algoritmo, la longitud de la clave, el protocolo, la biblioteca, el módulo de hardware, la autoridad de certificación, el propietario de la clave, la rotación, la recuperación, la caducidad y la ruta de actualización. Los activos de larga duración requieren especial atención porque los algoritmos y las implementaciones pueden volverse obsoletos antes de que se reemplace el activo.
El NIST ha finalizado los estándares poscuánticos para el establecimiento de claves y las firmas digitales. Su existencia no significa que todos los productos espaciales puedan migrar inmediatamente. El objetivo debe mostrar dónde es factible la migración, qué limitaciones de rendimiento o memoria se aplican, cómo se probarán los enfoques híbridos y qué clientes o reguladores deben aprobar el cambio. El plan debería distinguir la TI corporativa, los sistemas terrestres, el software de misión y las naves espaciales.
La gestión de claves también es una cuestión de transacción. El comprador debe determinar qué claves se transfieren, cuáles deben rotarse, cuáles pertenecen a los clientes y cuáles permanecen en poder del vendedor. Debe confirmar custodia, copia de seguridad, recuperación, control dual, registro y destrucción. El plan de cierre debe evitar que cualquiera de las partes retenga acceso no autorizado y al mismo tiempo preservar la continuidad. Los costos de los módulos de hardware, la reemisión de certificados, la ingeniería y la aceptación del cliente deben ingresar al modelo.
11 Monitoreo, detección y respuesta de revisión
La evidencia de monitoreo debería conectar la telemetría con la acción. El comprador debe identificar las fuentes de registro, la cobertura de recopilación, la sincronización horaria, la retención, la integridad, las reglas de detección, la propiedad de las alertas, la escalada y los registros de incidentes. Un volumen de alerta elevado no es prueba de una detección eficaz. Evidencia útil muestra que los eventos materiales se observan, clasifican, investigan, contienen y cierran dentro de niveles de servicio definidos.
Las operaciones espaciales crean telemetría especializada que puede no adaptarse a las herramientas empresariales. Las anomalías de la misión, los patrones de comando, el comportamiento de los enlaces, los cambios de configuración y los eventos de las estaciones terrestres pueden requerir reglas específicas de dominio e interpretación de expertos. El objetivo debe mostrar cómo llegan estas señales a los equipos de seguridad y de misión, cómo se asigna la responsabilidad y cómo se toman las decisiones de seguridad durante un incidente.
Los registros de incidentes pueden ser una valiosa evidencia de diligencia cuando se manejan bajo privilegio y confidencialidad. Revelan el rendimiento del control, la velocidad de respuesta, las causas fundamentales y los problemas repetidos. El comprador debe distinguir la ausencia de incidentes registrados de la evidencia de un seguimiento efectivo. También debe revisar los plazos de notificación contractual, las obligaciones de los reguladores, las condiciones de los seguros y la aprobación del cliente para el acceso a la investigación.
12 Demostrar la recuperación y la continuidad de la misión
La capacidad de recuperación debe demostrarse mediante ejercicios y registros operativos. El objetivo debe identificar el servicio mínimo viable de la misión, el tiempo de recuperación, el punto de recuperación, las instalaciones alternativas, la integridad del respaldo, los procedimientos de sala limpia, la recuperación de credenciales y la autoridad para tomar decisiones. El ejercicio debe incluir la pérdida de servicios de identidad, regiones de nube, estaciones terrestres, acceso a proveedores y personal clave cuando existan dependencias materiales.
Las copias de seguridad sólo son útiles cuando se pueden restaurar en un entorno confiable. El comprador debe inspeccionar las pruebas de restauración, las líneas base de configuración, la disponibilidad de claves, las versiones de dependencia y la conciliación con la producción. La continuidad de la misión puede requerir una configuración alternativa controlada que preserve las operaciones seguras y al mismo tiempo reduzca las funciones. El contrato del cliente deberá definir si esta modalidad reducida satisface la obligación de servicio.
La continuidad también depende de las personas. El objetivo puede depender de un pequeño grupo con autorización, conocimiento de la misión o acceso a entornos de clientes. La diligencia debe mapear roles críticos, términos de empleo, ubicación, sucesión, cobertura de guardia y restricciones de transferencia. El valor de la retención debe estar vinculado a la transferencia de conocimientos documentada y a la capacidad operativa, no sólo a la continuidad del empleo.
13 Conciliar el cumplimiento y la garantía del cliente
Las empresas de ciberseguridad espacial pueden enfrentar obligaciones superpuestas derivadas de contratos con clientes, requisitos de seguridad nacional, controles de exportación, protección de datos, reglas de infraestructura crítica y estándares sectoriales. El comprador debe crear un registro de obligaciones por entidad jurídica, producto, cliente, geografía y sistema. Cada obligación debe identificar al propietario del control, la evidencia, la excepción, el deber de informar y la consecuencia del cambio de control.
La garantía del cliente a menudo incluye cuestionarios, revisiones de arquitectura, pruebas de penetración, planes de seguridad, requisitos de las instalaciones y personal designado. Estos materiales deben conciliarse con la operación de control real. Una respuesta dada durante un proceso de contratación puede convertirse en una representación contractual o en una dependencia de renovación. Se deben evaluar las diferencias entre las declaraciones de los clientes y la práctica actual para su corrección, divulgación y responsabilidad.
El cambio de control puede requerir consentimiento o acreditación renovada. El comprador debe identificar los contratos que permiten la rescisión, suspenden el acceso, restringen la propiedad o requieren un nuevo plan de seguridad. El pronóstico debe reflejar el momento y la probabilidad de aprobación del cliente. La consideración se puede aplazar hasta que se demuestren las aprobaciones materiales y los ingresos retenidos.
14 Separar la propiedad intelectual del know-how operativo
La revisión de la propiedad intelectual debe abarcar el código fuente, los modelos, la lógica de detección, las implementaciones criptográficas, las patentes, los secretos comerciales, la documentación, los derechos de datos y los desarrollos específicos de los clientes. La propiedad debe rastrearse a través de fundadores, empleados, contratistas, universidades, financiación gubernamental y código adquirido. Las licencias de código abierto y de terceros deben conciliarse con el uso real.
El know-how operativo puede ser más valioso que los derechos registrados. Los analistas de la misión pueden comprender falsos positivos, patrones de telemetría, procedimientos del cliente y soluciones de integración que no están documentadas. El comprador debe identificar este conocimiento, convertirlo en documentación controlada y diseñar la retención en torno a los hitos de la transferencia. Una bonificación de retención amplia sin un plan de conocimientos puede preservar la dependencia en lugar de la capacidad.
Los derechos de datos requieren un análisis por separado. La inteligencia de amenazas, la telemetría de misiones y los registros de incidentes pueden ser propiedad de los clientes o estar limitados a la prestación de servicios. El objetivo puede tener permiso para procesar datos sin derecho a reutilizarlos para el desarrollo de productos o para otro cliente. La valoración debe reconocer únicamente los derechos de datos que se transfieren y pueden sustentar lícitamente la previsión.
15 Construir el modelo de ingresos vinculado a la evidencia
El modelo de ingresos debe conciliar contratos, formularios de pedido, órdenes de trabajo, aceptación, facturas, cobros e ingresos diferidos. Debe identificar los límites máximos del programa, los montos financiados, las opciones, los derechos de terminación, las dependencias de los hitos y los costos de transferencia. Los ingresos del gobierno y de los contratistas principales pueden requerir análisis adicionales de las asignaciones, el acceso de seguridad, el estado de los subcontratos y los derechos de auditoría.
Cada línea de ingresos debe estar etiquetada por evidencia patrimonial, dependencias de control y requisitos de transferencia. Un contrato recurrente de servicios gestionados con rendimiento de producción aceptado y personal transferible puede generar una gran confianza. Un acuerdo marco que dependa de una futura interfaz de nave espacial, la acreditación del cliente y características no construidas debería recibir menos confianza y un capital de finalización explícito.
El margen de pronóstico debe incluir apoyo a la misión, operaciones de seguridad, nube, acceso terrestre, garantía, respuesta a vulnerabilidades, seguros e ingeniería específica del cliente. Estos costos pueden estar ocultos en investigación, TI central o mano de obra fundadora. La normalización debe preservar los recursos necesarios para cumplir con las obligaciones del cliente y de control.
16 Cuantificar el capital de remediación
La remediación debe organizarse por consecuencia de la misión, exposición contractual y dependencia del valor. Las acciones críticas pueden incluir cerrar rutas de comando no autorizadas, rotar claves, aislar sistemas de compilación, proteger la infraestructura de firma, eliminar componentes no compatibles y restaurar la cobertura de monitoreo. Otras acciones pueden mejorar la eficiencia o el acceso futuro al mercado. El plan debe identificar al propietario, el costo, la duración, el impacto del servicio, la aprobación del cliente y la evidencia de finalización.
El comprador debe distinguir la remediación única del costo operativo recurrente. Las nuevas herramientas pueden requerir licencias, especialistas, seguimiento y gobernanza. Un reinicio del desarrollo seguro puede ralentizar los lanzamientos. La reaprobación del cliente puede retrasar los ingresos. Estos efectos deberían incluirse en la planificación del flujo de caja y de los acuerdos en lugar de aparecer como una única deducción del precio de compra.
Las estimaciones de remediación deben incluir rangos y dependencias. Una vulnerabilidad de código puede requerir un parche limitado o un cambio de arquitectura después de una investigación más profunda. El modelo debe incluir contingencias para partidas inciertas de alta consecuencia y utilizar el depósito en garantía o la contraprestación contingente cuando el vendedor controla la evidencia o la acción antes del cierre.
17 Construir el puente de valoración
El valor inicial puede utilizar un enfoque de ingresos, EBITDA o de flujo de efectivo descontado apropiado para el negocio. Luego, el puente de evidencia se ajusta según la calidad de los ingresos, la capacidad de control, la remediación, la concentración de clientes, la transferibilidad y las opciones estratégicas. Cada ajuste debe conectarse a una línea de pronóstico, requerimiento de capital, probabilidad o protección contractual.
El valor patrimonial debe reflejar los ingresos sustentados y el costo de ejecución reducido. El valor de confianza cero debe reflejar acceso exigible, monitoreo, recuperación y garantía del cliente. El valor estratégico puede incluir autorizaciones escasas, integraciones aprobadas, derechos de datos de misión o acceso a personal especializado. Estos beneficios deben declararse por separado y no deben duplicar los flujos de efectivo que ya están previstos.
El puente también debería registrar el valor que sigue siendo contingente. Un producto puede volverse materialmente más valioso después de completar una misión de configuración exacta, implementar una identidad de servicio en todos los sistemas de la misión, aprobar la acreditación del cliente o conservar un programa clave. La consideración contingente puede alinear el pago con esos resultados cuando la métrica es objetiva y el comprador puede operar el negocio sin suprimir el resultado.
18 Protecciones de transacciones de diseño
Las representaciones deben abordar la propiedad, la procedencia del código, los controles de seguridad, los incidentes, las vulnerabilidades, las declaraciones de los clientes, el acceso, los derechos de los datos, los controles de exportación y el cumplimiento. El proceso de divulgación debe identificar excepciones conocidas con suficiente detalle para fijar precios y remediar. Las representaciones cibernéticas genéricas brindan protección limitada cuando el problema material es una ruta de comando específica, acreditación de cliente o componente no compatible.
Las condiciones para el cierre pueden cubrir el consentimiento del cliente o del gobierno, la rotación de claves, la eliminación del acceso del vendedor, la transferencia de repositorios, la entrega de registros de configuración y el cierre de vulnerabilidades críticas. Los acuerdos provisionales deben preservar la postura de seguridad, la dotación de personal, la notificación de incidentes y las relaciones con los clientes. El comprador debe controlar los cambios que puedan alterar la evidencia que sustenta el valor.
El depósito en garantía, las indemnizaciones específicas, la retención y la contraprestación contingente deben abordar diferentes riesgos. Las exposiciones cuantificadas conocidas pueden respaldar una indemnización específica o un ajuste de precio. Un valor incierto que depende de la evidencia puede respaldar una ganancia o un hito. La retención debe apoyar la transferencia de conocimientos y la continuidad operativa. La estructura de la transacción debe evitar pagar dos veces por la misma protección.
19 Planifica el primer día y los primeros 100 días
Las prioridades del primer día son el control de acceso, la continuidad, la coordinación de incidencias y la confianza del cliente. El comprador debe establecer administradores autorizados, contactos de emergencia, registros, decisiones de custodia de claves, control de repositorio, aprobación de cambios y comunicaciones con el cliente. La integración debe evitar una conexión de red amplia hasta que se comprendan los límites y dependencias de confianza.
Los primeros 30 días deben validar identidades, rutas privilegiadas, vulnerabilidades críticas, restauración de copias de seguridad, infraestructura de firma y plazos contractuales. Los días 31 a 60 deberían cerrar las brechas de segmentación de materiales y de identidad de servicios, lanzar la migración criptográfica, conciliar la garantía del cliente y financiar el trabajo pendiente de remediación. Los días 61 a 100 deben completar el despliegue del control prioritario, ejercitar los procedimientos de incidentes y continuidad, confirmar la propiedad de las pruebas y actualizar el caso de valoración.
Las métricas de integración deben medir los resultados: cuentas privilegiadas reducidas, rutas de misión cubiertas, registros críticos conciliados, compilaciones reproducibles, claves controladas, restauraciones probadas, excepciones cerradas y clientes retenidos. El despliegue de herramientas por sí solo es insuficiente. La junta debe recibir un panel de evidencia conciso y decisiones que requieran capital o aceptación de riesgos.
20 Establecer puertas de aprobación de la junta
La junta debería aprobar la transacción a través de puertas vinculadas. La puerta perimetral confirma que se transfieren bienes materiales, personas, derechos y dependencias. La puerta del patrimonio confirma el alcance y la calidad de la evidencia de la misión. La puerta de control confirma la identidad, la segmentación, el monitoreo, la criptografía y la recuperación. La puerta comercial concilia la evidencia con los ingresos, el margen y el efectivo. La puerta de transacción confirma que el precio y la protección siguen el valor admitido.
Cada puerta debe tener un propietario, un paquete de pruebas y una respuesta ante fallos. Una puerta fallida puede requerir reparación, un precio más bajo, consideración diferida, una condición para el cierre o la terminación. El registro de decisiones debe identificar los supuestos y rangos de gestión. También debe indicar qué riesgos se aceptan y por qué.
La junta debería revisar el caso de adquisición después del cierre. Si la evidencia patrimonial, la retención de clientes o la remediación difieren del modelo, la asignación de capital y los pagos contingentes deben ajustarse. Esta disciplina convierte la diligencia en un control operativo más que en un archivo.
21 Caso de adquisición hipotética
Supongamos que un comprador estratégico evalúa un objetivo de ciberseguridad espacial que proporciona monitoreo del segmento terrestre, identidad de la misión, implementación segura y servicios de respuesta a incidentes. El objetivo informa USD 92 million de ingresos anuales, USD 18 million de EBITDA y un valor empresarial principal de USD 420 million. Todos los montos y probabilidades en este caso son supuestos de gestión hipotéticos creados únicamente para demostrar el marco. No describen una empresa o transacción real.
El vendedor identifica USD 60 million de ingresos respaldados por el patrimonio de vuelo. La conciliación del comprador encuentra que USD 38 million está vinculado a configuraciones exactas con registros de misión aceptados, USD 14 million está vinculado a configuraciones derivadas con cambios limitados y USD 8 million está vinculado a programas que usan la etiqueta tradicional sin suficiente evidencia de configuración. Los ingresos restantes incluyen servicios empresariales, trabajo de desarrollo e implementaciones tempranas.
Las pruebas de control encuentran una identidad corporativa sólida, gestión de terminales y monitoreo central. Las identidades de los servicios del sistema de misión están incompletas; varias rutas de proveedores conservan privilegios permanentes; el inventario criptográfico está fragmentado; dos componentes terrestres heredados no pueden admitir el método de autenticación preferido; y los ejercicios de recuperación no han probado la pérdida de la identidad del vendedor como inquilino. El comprador estima USD 26 million de capital único de remediación e integración durante 24 meses, más USD 6 million de costo operativo anual adicional en el momento de la estabilización.
El puente de valoración reduce el valor de los ingresos no respaldados, los costos recurrentes, la remediación, la concentración de clientes y el riesgo de transferencia. Reconoce el valor estratégico de las integraciones de misiones aceptadas, el personal especializado y las relaciones verificadas con los clientes. El valor en efectivo resultante al cierre es USD 315 million. Se paga hasta USD 45 million por la aceptación de la configuración exacta, la implementación de confianza cero del sistema de misión, la retención de clientes y el efectivo cobrado. El comprador también financia el plan de remediación y conserva los derechos de rescisión si fallan las aprobaciones críticas del cliente o del gobierno.
22 Interpretación de los resultados hipotéticos
El caso muestra por qué la herencia de vuelo y la confianza cero no deben reducirse a etiquetas binarias. El objetivo tiene evidencia de misión real y controles valiosos, pero la evidencia no cubre todos los flujos de ingresos ni todas las configuraciones implementadas. Una prima amplia pagaría de más por un alcance no respaldado. Un descuento amplio ignoraría las integraciones aceptadas y la escasa capacidad operativa.
El puente también distingue el precio de compra del requisito de capital. El comprador paga por el flujo de caja respaldado y la capacidad estratégica, luego financia los controles necesarios para la continuidad y el crecimiento. La contraprestación contingente preserva la ventaja cuando las afirmaciones del vendedor se hacen evidentes. También le brinda al equipo de transacciones un conjunto de métricas claras para la gobernanza posterior al cierre.
El enfoque sigue siendo sensible a las suposiciones. Una pérdida grave de un cliente, una acreditación fallida o el descubrimiento de un acceso no autorizado podrían reducir aún más el valor. Una remediación más rápida, pruebas más sólidas de configuración exacta o aprobaciones gubernamentales transferibles podrían aumentar el valor. Por lo tanto, el comité de inversiones debería revisar los casos centrales, adversos y graves y confirmar la liquidez en cada uno de ellos.
23 Límites del marco
Este marco organiza las decisiones de transacciones. No reemplaza las pruebas técnicas, el asesoramiento legal, la revisión del control de exportaciones, la acreditación de seguridad, el juicio contable, el asesoramiento fiscal o el consentimiento del cliente. Los sistemas espaciales difieren materialmente según la misión, la órbita, la carga útil, el cliente, la jurisdicción y la arquitectura. Un control apropiado para un servicio terrestre nativo de la nube puede no ser factible en una nave espacial heredada.
La orientación pública proporciona principios y líneas de base de control. No verifica la postura de un objetivo específico. Los compradores deben obtener pruebas primarias, realizar pruebas autorizadas y utilizar especialistas con experiencia en el espacio, la cibernética, las finanzas y las transacciones. La información clasificada o controlada para exportación requiere un manejo aprobado y puede limitar el equipo de diligencia.
La valoración hipotética es ilustrativa. No proporciona múltiplos de mercado, pronósticos ni recomendaciones de inversión. Cada cantidad es un supuesto de gestión utilizado para mostrar cómo la evidencia puede afectar el precio y la estructura.
24 Ejecute una revisión delta de configuración
La revisión delta de configuración debe comenzar con la última línea base de misión aceptada y finalizar con el producto que se espera genere ingresos previstos. El equipo debe comparar hardware, firmware, sistema operativo, bibliotecas, módulos criptográficos, entorno de implementación, interfaces, modelos de datos, autonomía, lógica de comando y modificaciones específicas del cliente. Cada diferencia debe clasificarse según las consecuencias de la misión, el estado de verificación y el requisito de aprobación del cliente. Un registro delta controlado permite al comprador preservar el patrimonio legítimo mientras identifica el trabajo necesario antes de que se pueda utilizar un reclamo más amplio.
La revisión debe incluir evidencia negativa. Una anomalía, una prueba fallida o un defecto diferido no elimina automáticamente el valor. Puede demostrar que el objetivo tiene un proceso de detección, investigación y acción correctiva que funciona. El comprador debe examinar el análisis de causa raíz, la contención, las pruebas de regresión, las actualizaciones de configuración y la aceptación del cliente. Las anomalías repetidas no resueltas, las exenciones indocumentadas o las discrepancias entre los registros internos y de los clientes deberían reducir la confianza en la evidencia.
La revisión delta también respalda la contabilidad de compras y la planificación de la integración. Una plataforma documentada, transferible y mantenible puede respaldar un valor tecnológico identificable. La dependencia material de conocimientos no documentados, entornos controlados por el cliente o infraestructura del vendedor puede acortar la vida útil o aumentar el costo de reposición. Los equipos de finanzas, tecnología y transacciones deben utilizar un registro de configuración acordado en lugar de narrativas comerciales y técnicas separadas.
25 Portabilidad del control de prueba después del cambio de propiedad
Los controles cibernéticos pueden parecer maduros dentro del entorno del vendedor y volverse frágiles durante la separación. La identidad, el registro, la emisión de tickets, la gestión de claves, la firma de códigos, el arrendamiento de la nube, la inteligencia sobre amenazas y las operaciones de seguridad pueden depender de servicios compartidos. El comprador debe asignar cada control a su propietario, tecnología, fuente de datos, contrato, administrador y ruta de salida. Un control recibe crédito total por transacción solo cuando puede transferirse, permanecer bajo un servicio de transición exigible o ser reemplazado dentro del plan financiado.
Las pruebas de portabilidad deben incluir un cambio de autoridad simulado. El objetivo debe demostrar cómo se aprueba a los administradores, cómo se revoca el acceso del vendedor, cómo las credenciales de los clientes siguen siendo válidas, cómo continúan fluyendo los registros y cómo cambia la responsabilidad por incidentes. El ejercicio debe identificar las acciones requeridas antes de la finalización legal y las acciones que pueden seguir bajo una transición controlada. También debe confirmar que una transición apresurada no interrumpirá el servicio de la misión ni destruirá pruebas.
El comprador debe fijar el precio de los períodos operativos duplicados. La migración segura a menudo requiere que los sistemas de identidad, monitoreo o firma antiguos y nuevos se ejecuten juntos mientras los clientes aprueban el nuevo estado. El funcionamiento dual genera costos de licencia, ingeniería y garantía. El modelo debe incluir esos costos y la liquidez necesaria si la aceptación del cliente demora más de lo planeado.
26 Vincular la evidencia cibernética con la economía del cliente
El valor para el cliente debe observarse a través de la renovación, la expansión, la fijación de precios, el desempeño aceptado y el cobro de efectivo. Un entorno de control sofisticado puede respaldar esos resultados, pero la relación debe demostrarse. El comprador debe comparar los hitos de control con la adjudicación de contratos, los hallazgos de aseguramiento, los créditos de servicio, las renovaciones y la contribución del cliente. Debería evitar atribuir todos los resultados comerciales a la ciberseguridad cuando la capacidad del producto, las adquisiciones, el éxito de la misión y las relaciones también importan.
La evidencia más valiosa a menudo aparece en el límite entre la garantía técnica y la operación del cliente. Los ejemplos incluyen un ciclo de acreditación reducido, una recuperación exitosa de la misión, una integración segura aceptada por un contratista principal o un control de ruta de comando requerido para la adjudicación de un programa. Estos eventos pueden respaldar una prima de precio cuando los ingresos, el margen y los derechos de transferencia asociados están documentados.
La concentración del cliente cambia el valor de la evidencia de control. Una capacidad aceptada por un gran cliente puede ser técnicamente sólida y al mismo tiempo seguir dependiendo comercialmente de ese programa. El comprador debe probar la portabilidad a otros clientes, el costo de la acreditación por separado y los derechos de reutilización del trabajo de integración. El valor estratégico debe reflejar la oportunidad aprovechable después de estas limitaciones, no sólo el tamaño del programa original.
27 Mantener una sala de pruebas después del cierre
La sala de pruebas de transacciones debería convertirse en un sistema de pruebas operativo. Debe conservar líneas de base de configuración, procedencia de lanzamientos, revisiones de acceso, ceremonias clave, registros de incidentes, pruebas de recuperación, aprobaciones de clientes, cambios de contratos, evidencia de remediación y cálculos de consideración contingente. Cada registro debe tener un propietario, un período de retención, una regla de acceso y un vínculo con el control o supuesto financiero relevante.
Este registro respalda varias necesidades posteriores al cierre. Permite a la junta monitorear si se está entregando la tesis de adquisición. Apoya la garantía del cliente y la participación de los reguladores. Proporciona a las finanzas una base para juicios sobre deterioro, vida útil y contraprestaciones contingentes. También reduce la dependencia de los recuerdos individuales cuando el personal cambia.
El sistema de evidencia debe mostrar excepciones y registros obsoletos. Un panel que informa solo los controles completados puede ocultar riesgos no resueltos. La junta debería ver acciones atrasadas, reclamos no respaldados, dependencias de clientes, certificados vencidos, rutas de recuperación no probadas e hitos en riesgo. La misma evidencia debería respaldar las decisiones de invertir, retrasar la integración, renegociar un compromiso con el cliente o retener pagos contingentes.
Conclusión
La ciberseguridad espacial M&A requiere que el comprador valore un sistema de pruebas operativas. El patrimonio del vuelo debe estar vinculado a la configuración exacta, el entorno, la duración, los registros y la aceptación del cliente. La capacidad de confianza cero debe estar vinculada a la aplicación de identidad, políticas, segmentación, telemetría, criptografía, recuperación y desarrollo seguro en todos los sistemas que crean valor de la misión.
El proceso recomendado es directo: definir el perímetro de aseguramiento de la misión; construir la escalera de evidencia patrimonial; probar controles mediante operación observada; conciliar reclamaciones de contratos, efectivo y capital; y estructurar la consideración en torno al valor respaldado y contingente. La misma evidencia debería impulsar el acceso desde el primer día, la hoja de ruta de remediación y el monitoreo de la junta directiva.
Esta disciplina produce una transacción más defendible. Premia la capacidad que puede demostrarse y transferirse. Dirige la remediación hacia las consecuencias de la misión. Se mantiene al alza cuando la evidencia madura. Lo más importante es que les da a los directores una idea clara de lo que están comprando, qué debe cambiar después del cierre y qué condiciones respaldan el precio.
Jerarquía de evidencia de transacciones propuesta; una afirmación más amplia requiere una configuración y evidencia operativa más amplias.
Mapa de diligencia propuesto desde el desarrollo hasta la entrega al cliente; Las flechas indican las rutas principales de confianza y datos.
Cobertura de control ilustrativa de cero a cinco; Las puntuaciones son supuestos de gestión para el caso hipotético.
Secuenciación ilustrativa; La aprobación del cliente y los plazos de la misión determinan el momento final.
Millones ilustrativos USD; Todos los montos son supuestos de gestión utilizados únicamente para demostrar el marco.
| Dominio | Pregunta principal | evidencia primaria | Consecuencia de valoración |
|---|---|---|---|
| Producto | ¿Qué configuración se vende y admite? | Registros de lanzamiento, arquitectura y soporte. | Confianza en los ingresos y costos sostenidos |
| Operaciones de misión | ¿Qué funciones afectan al mando, la telemetría o la seguridad? | Procedimientos, registros y ejercicios presenciados. | Responsabilidad y continuidad del servicio |
| Desarrollo | ¿Se puede cambiar y reproducir el software de forma segura? | Repositorios, canalizaciones y compilaciones firmadas | Valor del producto y capital de remediación |
| Identidad | ¿Quién y qué puede acceder a cada recurso? | Directorio, identidad de servicio y registros de privilegios | Control de cobertura y coste de separación. |
| Criptografía | ¿Qué algoritmos, claves y módulos protegen el valor? | Plan de inventario, custodia y migración | Obsolescencia y aprobación del cliente |
| Clientes | ¿Qué derechos, aprobaciones e ingresos se transfieren? | Contratos, aceptación y cobros. | Previsión de efectivo y condiciones de transacción. |
Alcance mínimo propuesto; El perímetro debe adaptarse al objetivo y a las obligaciones del cliente.
| Nivel | Evidencia | Tratamiento de ingresos | Respuesta de transacción |
|---|---|---|---|
| Configuración exacta | Registro de misión aceptado conciliado con la configuración actual | Máxima confianza sujeta a la calidad del contrato | Incluir en el caso base |
| Derivada acotada | Cambios documentados con calificación relevante y ruta del cliente. | Probabilidad ponderada | Prueba y aprobación restantes del fondo |
| demostrado | Prueba controlada o uso de misión limitada sin repetición de evidencia | Valor del escenario | Utilice la consideración de hitos |
| Reclamado | Marketing, propuesta o referencia no respaldada. | Excluir del caso base | Requerir evidencia o eliminar reclamo |
| Patrimonio obsoleto | Éxito anterior con configuración no compatible o intransferible | Revisión de costos y responsabilidades | Reconstruir, aislar o suspender |
Clasificación propuesta para la valoración de transacciones.
| Dominio | Evidencia de capacidad operativa. | Brecha de transacción común | Consecuencia en efectivo |
|---|---|---|---|
| Identidad humana | Registros sólidos de autenticación, roles y revisión | Cuentas compartidas o inactivas | Cierre de migración y excepción |
| Identidad del servicio | Credenciales, políticas y rotación de cargas de trabajo | Secretos estáticos y servicios desconocidos. | Riesgo de ingeniería y de interrupción |
| Aplicación de políticas | Puntos de decisión y ejecución probados | Diagramas sin bloqueo observado. | Costo de reestructuración |
| Acceso privilegiado | Aprobación, plazo, inscripción y revocación | Acceso permanente a proveedores | Costo de herramientas y separación. |
| Telemetria | Fuentes cubiertas, detecciones y registros de respuesta | Registros de misión faltantes | Nueva colección y analistas. |
| Recuperación | Servicio de confianza restaurado en un ejercicio | Copias de seguridad no probadas | capital de continuidad |
| Criptografía | Inventario, custodia, agilidad y aprobación del cliente | Algoritmos y claves desconocidos. | Migración y reacreditación |
Conjunto de pruebas propuestas basadas en principios de confianza cero centrados en los recursos.
| Exposición | Pregunta de diligencia | Evidencia | Tratamiento de transacciones |
|---|---|---|---|
| Cambio de control | ¿Se requiere consentimiento o reacreditación? | Registro de contrato y autoridad. | Condición de cierre o valor diferido |
| Representación de seguridad | ¿Los extractos de los clientes coinciden con la operación? | Cuestionario y prueba de control. | Divulgación, remediación o indemnización |
| Notificación de incidente | ¿Se informaron los hechos a tiempo? | Registro de incidentes y notificaciones | Reserva de responsabilidad y convenio |
| Derechos de datos | ¿Se pueden transferir y reutilizar los datos de telemetría y amenazas? | Contrato, consentimiento y registro de tratamiento | Excluir valor de datos no admitidos |
| Control de exportaciones | ¿Se pueden transferir código, hardware y soporte? | Clasificación y licencias. | Acceso a la estructura y condiciones. |
| Infraestructura crítica | ¿Se aplican reglas de propiedad o resiliencia? | Análisis legal y registro regulatorio. | Calendario y gobernanza de aprobación |
Revisión propuesta; Los abogados locales y las autoridades de seguridad determinan los requisitos aplicables.
| Artículo | Reportado o titular | Ajuste de evidencia | Caso de transacción |
|---|---|---|---|
| Ingresos anuales | 92 | -8 exposición al patrimonio no admitido | 84 respaldados o ponderados por probabilidad |
| EBITDA | 18 | -6 costo de control recurrente | 12 normalizado |
| Remediación única | 0 | -26 programa financiado | -26 requisito de capital |
| Valor empresarial principal | 420 | -125 pruebas netas y ajustes de riesgo | 315 en efectivo al cierre |
| Consideración contingente | 0 | +45 sujeto a hitos objetivos | Hasta 45 después de la evidencia |
Millones ilustrativos USD; Todos los importes son suposiciones de gestión y no describen ninguna empresa existente.
| Riesgo | Mecanismo preferido | Liberar o reclamar evidencia | Gobernancia |
|---|---|---|---|
| Falta de consentimiento crítico | Condición para el cierre | Aprobación por escrito | Control del comprador de la renuncia |
| Patrimonio no soportado | Consideración contingente | Evidencia de configuración exacta aceptada | Verificación independiente |
| Vulnerabilidad conocida | Ajuste de precio o indemnización específica | Hallazgo cerrado y aceptación del cliente. | Prueba y plazo definidos |
| Retención de clientes | Ganancias ligadas a contribuciones y cobros | Contrato, factura y efectivo. | Política contable y derecho de auditoría. |
| Concentración de conocimientos | Retención ligada a hitos de transferencia | Documentación y operación presenciada. | Propietario designado y sucesión |
| Acceso vendedor | Convenio de cierre y transición técnica | Acceda a la conciliación y la rotación de claves | Control del primer día |
Propuesta de asignación por tipo de riesgo.
| Período | Prioridad | Prueba de finalización | Decisión de la junta |
|---|---|---|---|
| Día uno | Identidad, contactos de incidentes, repositorio y control de claves | Acceso y custodia conciliados | Aceptar el riesgo de apertura |
| Días 1 al 30 | Validar privilegios, registros, copias de seguridad y hallazgos críticos | Pruebas y registro de excepciones. | Financiar remediación urgente |
| Días 31 al 60 | Implementar identidad de servicio y prioridades de segmentación. | Aplicación observada | Aprobar la migración de clientes |
| Días 61 al 100 | Continuidad del ejercicio y cierre de brechas prioritarias | Recuperación presenciada y evidencia de control | Actualizar caso de valor |
| En curso | Migración criptográfica, garantía del cliente y métricas | Hitos y colecciones aceptados. | Liberar valor contingente |
Secuencia propuesta; Las limitaciones de la misión y del cliente determinan el momento exacto.
Fuentes
- Instituto Nacional de Estándares y Tecnología, SP 800-207 Zero Trust Architecture, 2020. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, SP 800-207A Un modelo de arquitectura de confianza cero para el control de acceso en aplicaciones nativas de la nube en entornos de múltiples ubicaciones, 2023. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, SP 1800-35 Implementación de una arquitectura de confianza cero, 2025. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Marco de Ciberseguridad 2.0, 2024. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, SP 800-53 Revisión 5 Controles de seguridad y privacidad para organizaciones y sistemas de información. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, SP 800-218 Marco de desarrollo de software seguro versión 1.1, 2022. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Estándar del mecanismo de encapsulación de claves basado en módulo FIPS 203, 2024. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Estándar de firma digital basado en módulo FIPS 204, 2024. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, FIPS 205 Estándar de firma digital basado en hash sin estado, 2024. Lea la fuente principal
- Agencia de Seguridad de Infraestructura y Ciberseguridad, Recomendaciones para los operadores de sistemas espaciales para mejorar la ciberseguridad, 2024. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Guía de mejores prácticas de seguridad espacial, 2023. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Guía de mejores prácticas de seguridad espacial, Manual de ingeniería de software. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Estándar de protección del sistema espacial NASA-STD-1006A, 2022. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Niveles de preparación tecnológica, 2023. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Apéndice del manual de ingeniería de sistemas, 2023. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, niveles de preparación de la tecnología de software y alineación de la revisión de hitos. Lea la fuente principal
- Agencia de Ciberseguridad de la Unión Europea, ENISA Space Threat Landscape 2025. Lea la fuente principal
- Agencia Espacial del Reino Unido, Conjunto de herramientas de seguridad cibernética, 2021. Lea la fuente principal
- Centro Nacional de Seguridad Cibernética del Reino Unido, Guía de seguridad de la cadena de suministro. Lea la fuente principal
- Centro Nacional de Seguridad Cibernética del Reino Unido, Marco de Evaluación Cibernética. Lea la fuente principal
- Oficina de Responsabilidad del Gobierno de Estados Unidos, Ciberseguridad de la NASA: Protección de naves y sistemas espaciales, GAO-24-106624, 2024. Lea la fuente principal
- Oficina de Responsabilidad del Gobierno de Estados Unidos, Ciberseguridad de la NASA: gestión de riesgos, GAO-25-108138, 2025. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, NISTIR 8401 Segmento Terrestre de Satélites: Aplicación del marco de ciberseguridad al comando y control de satélites. Lea la fuente principal
- Casa Blanca, Directiva de política espacial 5 Principios de ciberseguridad para sistemas espaciales, 2020. Lea la fuente principal
- Departamento de Defensa de los Estados Unidos, Estrategia de Confianza Cero del Departamento de Defensa, 2022. Lea la fuente principal
- Comisión de Bolsa y Valores de Estados Unidos, Gobernanza de la estrategia de gestión de riesgos de ciberseguridad y divulgación de incidentes, 2023. Lea la fuente principal
- Unión Europea, Directiva (UE) 2022/2555 sobre medidas para un alto nivel común de ciberseguridad en toda la Unión. Lea la fuente principal
- Unión Europea, Reglamento (UE) 2024/2847 Ley de Resiliencia Cibernética. Lea la fuente principal
- Fundación NIIF, NIIF 3 Combinaciones de Negocios. Lea la fuente principal
- Fundación NIIF, NIIF 13 Medición del Valor Razonable. Lea la fuente principal
- Departamento del Tesoro de los Estados Unidos, Comité de Inversión Extranjera en los Estados Unidos. Lea la fuente principal
- Departamento de Justicia de los Estados Unidos y Comisión Federal de Comercio, Directrices para fusiones, 2023. Lea la fuente principal
- Comisión Europea, Control de fusiones de la UE. Lea la fuente principal
- Comité Consultivo para Sistemas de Datos Espaciales, Publicaciones del Grupo de Trabajo de Seguridad. Lea la fuente principal
