1. Home
  2. NASA's Space Security: BPG
  3. MI-INTG-01

MI-INTG-01 - Communications Survivability Function

Principle

The mission should be able to recover from communications jamming and spoofing attempts.

Rationale

Communications systems using a shared medium are susceptible to jamming and spoofing, resulting in loss of access (denial of service) and potential loss of data integrity and availability. The prevalence of impacts to communications links in the RF and optical bands is increasing, as well as potential for targeted spoofing of communications links.

Related Countermeasures

ID Name Description NIST Rev 5
CM0074 Distributed Constellations A distributed constellation architecture deploys mission capability across multiple spacecraft nodes operating collectively, such that the end user is not dependent on any single satellite to derive the intended capability. This architectural approach directly complicates adversary counterspace planning by multiplying the number of assets that must be successfully degraded or destroyed to achieve mission denial effects equivalent to those achievable against a concentrated, single-node architecture. The resilience benefit depends on how much mission capability remains available following the loss or degradation of specified nodes. A constellation that can satisfy defined minimum mission requirements through multiple combinations of surviving nodes generally requires an adversary to affect more assets or shared dependencies to achieve mission denial. GPS exemplifies this principle: a receiver generally uses signals from at least four healthy satellites with suitable geometry to determine three-dimensional position and time. Loss of one satellite does not ordinarily eliminate the service where sufficient healthy satellites remain visible; resilience to ground-system failures depends separately on the redundancy and distribution of the control segment. Distribution is a mission architecture decision that must be made early in the program lifecycle, as it fundamentally shapes spacecraft design, ground system architecture, launch strategy, and operational concepts. CP-10(6) CP-11 CP-13 CP-2 CP-2(2) CP-2(3) CP-2(5) CP-2(6) PE-21
CM0075 Proliferated Constellations Proliferated satellite constellations increase mission resilience by deploying a larger number of functionally equivalent satellites in similar orbits, expanding overall constellation capacity and raising the number of assets an adversary must successfully attack to achieve meaningful mission degradation. Unlike distribution, in which multiple satellites or payloads work together to provide a complete capability, proliferation increases the number of systems performing the same or substantially equivalent mission. Its resilience benefit is primarily derived from additional capacity and reduced dependence on any individual satellite rather than from architectural diversity. Proliferation also supports resilience through on-orbit spare maintenance, in which additional satellites are held in reserve or parked in accessible orbits to replace operational assets without requiring new launches. The cost implications of proliferation are significant and architecture-dependent. Designs optimized for repeatable production may achieve lower unit costs through learning and economies of scale, but those savings depend on design stability, production quantity, supplier capacity, and the amount of non-recurring change between production lots. The choice to proliferate must be made as a mission architecture decision early in the program, as it determines the spacecraft design philosophy, production strategy, launch architecture, and ground system scalability requirements. CP-10(6) CP-11 CP-13 CP-2 CP-2(2) CP-2(3) CP-2(5) CP-2(6) PE-21
CM0083 Antenna Nulling and Adaptive Filtering Antenna nulling and adaptive filtering are complementary electronic protection techniques that reduce the effects of jamming on spacecraft communication and sensing links while preserving access to legitimate signals. Antenna nulling dynamically adjusts the receive antenna pattern to reduce sensitivity in the estimated direction of arrival of a jammer. For terrestrial interference, the affected geographic region depends on the spacecraft’s position and attitude, antenna geometry, and uncertainty in the jammer’s location. Nulling is most effective against a limited number of discrete, detectable interference sources, but it may also attenuate legitimate signals arriving from the same or a nearby direction. Adaptive filtering suppresses interference based on its spectral or signal characteristics, such as by placing adaptive notches around narrowband or slowly varying interference. It can preserve operation within unaffected portions of the received bandwidth but may also remove or distort legitimate signal energy that overlaps the rejected frequencies. Its effectiveness decreases against wideband, rapidly changing, or multiple simultaneous jammers when too little usable bandwidth remains to support mission requirements. Used together, antenna nulling and adaptive filtering can address a broader range of jamming conditions than either technique alone. Both techniques depend on the interference remaining within the operating range of the antenna and receiver chain. If a jammer saturates or damages the low-noise amplifier, analog front end, or analog-to-digital converter, downstream digital processing may be unable to recover the legitimate signal. Receiver dynamic range and front-end protection must therefore be incorporated into the overall electronic protection design. SC-40 SI-4(14)
CM0086 Filtering and Shuttering Optical filters and shutters are passive and active protective mechanisms for remote sensing spacecraft sensors against laser dazzling and blinding attacks that exploit the same optical pathways used for legitimate mission collection. Optical filters selectively attenuate light outside the sensor's design wavelength bands, blocking laser energy at wavelengths that fall outside the mission's collection bands while preserving sensitivity to legitimate return signals; however, filters provide no protection against lasers operating at the same wavelengths the sensor is designed to detect, as filtering those wavelengths would simultaneously block the sensor from its intended mission function. Shutters provide complementary broadband protection by blocking or diverting light from the protected detector path when an exposure threshold or other anomaly criterion is met. Protection depends on the threat-detection latency, decision time, shutter actuation time, optical leakage, and duration of the incident illumination. A shutter may limit exposure from sustained or repeated illumination, but it must not be assumed to prevent damage from a short pulse that deposits damaging energy before closure. Together, filters and shutters provide layered protection: filters continuously attenuate selected wavelengths, while shutters can limit additional exposure from threats that cannot be sufficiently rejected by filtering. The fundamental tradeoff of shuttering is that it trades temporary collection interruption for sensor preservation, making the shutter activation threshold a critical design parameter that must balance sensor protection against mission data continuity requirements. Sustainment activities are limited because the filter and shutter hardware is generally fixed after launch, but operational monitoring, calibration assessment, mechanism exercising, threshold configuration control, and post-event analysis remain applicable. CP-13 PE-18 SC-30(5) SC-5 SC-5(3)
CM0002 COMSEC Communications security (COMSEC) denies unauthorized parties access to information derived from telecommunications while ensuring the authenticity of those communications. COMSEC is commonly defined as a broad discipline that may encompass cryptographic security, transmission security, emissions security, cryptographic key management, traffic-flow security, and physical security of COMSEC material. Within SPARTA, these areas are further broken down through separate countermeasures, including CM0029 | TRANSEC, CM0030 | Crypto Key Management, CM0003 | TEMPEST/EMSEC, and CM0073 | Traffic Flow Analysis Defense. CM0002 provides the overarching communications-security context and supports the coordinated application of these specialized countermeasures. All mission links, particularly telemetry, tracking, and commanding (TT&C) links, should employ communications-security protections appropriate to the sensitivity, criticality, operational environment, and threat exposure of the information being exchanged. These protections may include cryptographic protection, transmission security, emissions security, traffic-flow protection, secure key management, and physical protection of COMSEC material, as addressed by the applicable specialized countermeasures. Spacecraft should not provide an operational mode that permits required cryptographic protection or command authentication on TT&C links to be bypassed or disabled. Operational, maintenance, test, recovery, and contingency modes should be considered when evaluating whether communications-security protections can be unintentionally or improperly circumvented. Communication receivers and associated signal-processing or TRANSEC mechanisms should detect and, when mission-defined criteria are met, reject or otherwise safely handle transmissions exhibiting anomalous signal characteristics consistent with communications deception. Cryptographic mechanisms should authenticate and integrity-check received content but should not be treated as RF-deception detectors. AC-17 AC-17(1) AC-17(10) AC-17(2) AC-18 AC-18(1) AC-2(11) AC-3(10) CA-3 IA-4(9) IA-5 IA-5(7) IA-7 PL-8 PL-8(1) SA-8(18) SA-8(19) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SC-8(1) SC-8(3) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8)
CM0030 Crypto Key Management Effective cryptographic key management is a foundational requirement for all mission encryption and authentication functions; the security of cryptographic implementations is only as strong as the protection afforded to the keys those implementations rely upon. Key management must conform to recognized cryptographic guidance and address the full lifecycle applicable to each key type, including generation or establishment, distribution, storage, activation, use, replacement, deactivation or revocation, recovery where authorized, compromise response, and destruction. Only approved cryptographic algorithms, key generation methods, key distribution techniques, and authentication mechanisms may be used; the use of unapproved, deprecated, or custom cryptographic primitives is prohibited regardless of perceived functional adequacy. Encryption key handling must be performed outside of onboard software and protected through dedicated cryptographic mechanisms, preventing keys from being exposed through software vulnerabilities, memory inspection, or software-level debugging interfaces. Secret and private key material must not be retrievable in plaintext through telecommands, telemetry, diagnostic outputs, debugging interfaces, or other externally accessible mechanisms, regardless of the privilege level of the requesting entity. CM-3(6) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-9(6) SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-28(3) SC-8(1)
CM0031 Authentication All command-bearing sessions, frames, or messages involving spacecraft command links, crosslinks, or relay services shall provide cryptographic authentication of the command origin and integrity verification before commands are accepted. Mutual or bidirectional authentication shall be required where both endpoints must authenticate one another and the link and protocol architecture support that exchange. Acquisition requirements should mandate cryptographically based, bidirectional authentication for all command sessions across external links, including ground-to-spacecraft uplinks, spacecraft-to-spacecraft crosslinks, and any relay or intermediary ground station connections, with authentication required aBidirectional authentication enables both communicating entities to verify each other’s identity and helps prevent impersonation. Authentication establishes identity but does not by itself authorize a command, protect mission-data confidentiality, or prevent session hijacking. Command acceptance must also enforce authorization, and authenticated sessions or security associations must maintain integrity and replay resistance so that subsequent traffic remains bound to the authenticated entities. Beyond external links, authentication is strongly recommended for spacecraft internal bus communications and onboard inter-component connections, as an adversary with access to internal interfaces, whether through a compromised component or a physical access event, should face the same authentication barrier as an external adversary attempting to inject commands from outside the spacecraft. AC-14 AC-17 AC-17(10) AC-17(2) AC-18 AC-18(1) IA-2 IA-3(1) IA-4 IA-4(9) IA-7 IA-9 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(1) SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) SI-7(6)
CM0033 Relay Protection Replay attacks capture and later retransmit previously valid authentication messages, frames, credentials, or tokens. Relay attacks forward an authentication exchange in real time between legitimate endpoints, causing an endpoint to authenticate a connection or action that the adversary is relaying without requiring compromise of the underlying cryptographic keys. Relay- and replay-resistant authentication mechanisms must be implemented when establishing remote connections or security associations with the spacecraft and for authenticated communications on spacecraft internal buses. The protections must prevent previously accepted authentication material or authenticated traffic from being reused outside its authorized context. Replay resistance should use freshness and anti-reuse mechanisms such as nonces, sequence numbers, timestamps where operationally suitable, and managed anti-replay windows. Relay resistance additionally requires authentication to be cryptographically bound to the intended endpoints, security association, session or channel context, and authenticated action. Challenge-response authentication provides replay resistance when fresh challenges are used but does not, by itself, prevent an adversary from relaying the challenge and response between legitimate endpoints. These protections must be applied at both external interface boundaries, including ground-to-spacecraft command links and crosslinks, and internal spacecraft bus connections where component-to-component authentication is implemented. AC-17(10) IA-2(8) IA-3 IA-3(1) IA-4 IA-7 SC-13 SC-16(1) SC-23 SC-23(1) SC-23(3) SC-7 SC-7(11) SC-7(18) SI-10 SI-10(5) SI-10(6) SI-3(8)
CM0003 TEMPEST / EMSEC TEMPEST controls (i.e., emissions security (EMSEC)) protect spacecraft system components, internal data communications, and communication buses against side-channel and proximity-based attacks that exploit unintended electromagnetic, electrical, or acoustic emanations. Critical components must be enclosed within appropriate casings or shielding structures that attenuate unintended emissions to levels that deny adversaries the ability to reconstruct processed data or infer system state from externally observable signals. Shielding must extend to internal buses and data pathways, not only to individual processing elements, as inter-component communications represent a significant and often overlooked emanations surface. The physical enclosure strategy must be integrated with the broader system architecture so that shielding effectiveness is not degraded by penetrations, connectors, or cable routing that create unintended emissions paths. During sustainment & maintenance, Spacecraft TEMPEST and EMSEC protections are primarily established during design, fabrication, and integration, but sustainment remains applicable through configuration control, review of deployment-state or hardware changes, preservation of qualification evidence, assessment of relevant anomalies, and evaluation of refurbishment, replacement, or follow-on production changes. The guidance below addresses these spacecraft considerations as well as applicable ground-segment maintenance activities. PE-19 PE-19(1) PE-21 SC-8(3)
CM0036 Session Termination Where session-oriented communications are used between ground systems and spacecraft, between ground system components, or across internal spacecraft interfaces, the associated connection or session must be terminated upon completion or after a period of inactivity exceeding a threshold defined in the mission’s concept of operations (CONOPS). Failure to terminate idle or completed sessions leaves authenticated connections open and exploitable, providing adversaries with an opportunity to inject commands or data into an existing authenticated session without needing to complete the authentication process independently. Inactivity timeout thresholds must be established through the CONOPS process rather than set arbitrarily, balancing the security benefit of rapid session termination against the operational consequences of terminating a session that an operator or automated process may legitimately require across a contact gap or processing delay. Session termination must invalidate the associated session identifiers, authorization state, and cryptographic session state so that the terminated session cannot be reused. Where secure session resumption is operationally required, it must use a mission-approved, cryptographically protected mechanism with defined validity limits and must not permit reuse of expired, revoked, or invalidated session state. AC-12 AC-12(2) SC-10 SI-14(3) SI-4(7)
CM0034 Monitor Critical Telemetry Points Monitoring defined spacecraft telemetry points provides a key source of evidence for detecting adversary activity against on-orbit systems, where observability is largely limited to the events and conditions the spacecraft can sense, record, and report. Monitored telemetry must include both accepted and rejected commands, command mode transitions, command counters, and other indicators of commanding activity, enabling detection of unauthorized command attempts that fail authentication as well as anomalous patterns in legitimate command traffic. Monitoring scope should include RF and link-quality indicators that support detection and triage of interference or suspected jamming. These indicators should be correlated with expected link conditions and other available evidence before hostile activity is concluded. Security-relevant telemetry should be integrated and time-correlated with ground-based defensive cyber operations infrastructure, including security information and event management (SIEM) and audit platforms, to provide unified space-system cybersecurity situational awareness. The resulting view should correlate spacecraft observations with relevant ground-system security events while accounting for telemetry latency, contact availability, and other observability limitations. AC-17(1) AU-3(1) CA-7(6) IR-4(14) PL-8 PL-8(1) SA-8(13) SC-16 SC-16(1) SC-7 SI-3(8) SI-4(7)
CM0035 Protect Authenticators Authenticators and associated authenticator material, including passwords, secret and private keys, tokens, biometric templates, shared secrets, certificates, and trust-store entries, must be protected against unauthorized modification and, where the material is confidential, unauthorized disclosure throughout their lifecycle. Disclosure of secret authenticator material may enable adversaries to impersonate legitimate users or systems. Unauthorized modification of authenticators, certificates, or trust information can deny access to legitimate entities, substitute adversary-controlled credentials, or corrupt the trust basis of mission authentication mechanisms. Protection must apply to authenticators at rest, in transit, and in use, and must extend to all forms and storage locations, including credential databases, configuration files, embedded device credentials, hardware security tokens, and cryptographic key stores. Authenticator protection is a prerequisite for the effectiveness of any authentication-based access control; an authentication system whose authenticators are unprotected provides no meaningful security regardless of the strength of the underlying authentication protocol. AC-17(6) AC-3(11) CM-3(6) IA-4(9) IA-5 IA-5(6) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(19) SC-16 SC-16(1) SC-8(1)
CM0070 Alternate Communications Paths Establishing alternate communications paths for spacecraft and ground system operations reduces the likelihood that a single adversarial event, physical disruption, or technical failure will deny all mission communications. Reliance on a single communications pathway creates a single point of failure that adversaries can exploit through jamming, denial of service against ground infrastructure, physical disruption of a ground station, or compromise of network connectivity, any of which could result in complete loss of commanding and telemetry capability. Alternate paths must be assessed end to end for shared failure modes and operational dependencies. Differences in frequency, ground station, relay service, or network provider provide meaningful resilience only when the paths do not remain dependent on the same critical spacecraft, ground, management, or service infrastructure. The selection and configuration of alternate paths must be governed by the mission's concept of operations (CONOPS), which defines the conditions under which each path is used, the priority and switchover procedures between paths, and the minimum communications capability that must be maintained to satisfy mission safety and operational continuity requirements. AC-17 CP-2 CP-4(2) CP-8(3) PL-8 PL-8(1) SC-47
CM0032 On-board Intrusion Detection & Prevention An on-board intrusion detection and prevention system (IDS/IPS) monitors mission-critical spacecraft components and systems, generates and stores audit records, and supports mission-approved responses to detected threats. Depending on the mission architecture, threat, and availability of ground support, responses may be autonomous, ground-directed, or a combination of both. The system should address both known attack patterns and previously unseen anomalous behavior through complementary signature-based and behavior- or anomaly-based detection methods. Machine learning or adaptive technologies may be used when their performance, resource consumption, and failure behavior have been validated for the mission environment. Detection and response coverage should address applicable adversary activities across the attack lifecycle, including initial access, execution, persistence, defense evasion, and exfiltration. The on-board IDS/IPS must be integrated with the spacecraft's traditional fault management system to provide a unified approach to anomaly response, ensuring that cyber-triggered responses are compatible with fault management logic and do not produce unintended effects or fratricide against the spacecraft's own systems; countermeasures that are incompatible with fault management are considered unsafe and must not be executed autonomously. The response hierarchy must prioritize vehicle safety and continued mission operations. Advanced containment or deception responses may be considered when they can be executed without unacceptable mission risk. The system should preserve evidence that supports post-event analysis, threat characterization, and potential attribution by authorized ground support. AU-14 AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(2) AU-5(5) AU-6(1) AU-6(4) AU-8 AU-9 AU-9(2) AU-9(3) CA-7(6) CM-11(3) CP-10 CP-10(4) IR-4 IR-4(11) IR-4(12) IR-4(14) IR-4(5) IR-5 IR-5(1) PL-8 PL-8(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5 SC-5(3) SC-7(10) SC-7(9) SI-10(6) SI-16 SI-17 SI-3 SI-3(10) SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) SI-4(16) SI-4(17) SI-4(2) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-4(7) SI-6 SI-7(17) SI-7(8)
CM0042 Robust Fault Management The fault management system is a high-privilege, autonomous spacecraft function that adversaries may attempt to exploit as an attack vector, triggering protective responses that place the spacecraft in a degraded or more vulnerable operational state. Attack scenarios include manipulating sensor, state, or telemetry information to induce onboard or ground-directed safing actions; creating false fault conditions through sensor spoofing or proximity operations; exploiting safe-mode configurations that reduce security protections; and inducing autonomous maneuver responses through crafted fault indications. Robust fault management requires that safing procedures and autonomous responses be designed with explicit security analysis confirming that each protective action does not introduce a more exploitable system state than the fault condition it responds to. The integrity and authenticity of sensor data, state information, commands, and telemetry used by onboard or ground-based fault management functions must be protected to prevent falsified inputs from triggering unintended responses. Every fault response, including mode transitions, actuator commands, and communication reconfigurations, must be evaluated against the question of whether an adversary could deliberately induce that response and whether the resulting system state provides the adversary with meaningful advantage. CP-2 CP-4(5) IR-3 IR-3(1) IR-3(2) PE-10 PE-11 PE-11(1) PE-14 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(24) SA-8(26) SA-8(3) SA-8(30) SA-8(4) SC-16(2) SC-24 SC-5 SI-13 SI-13(4) SI-17 SI-4(13) SI-4(7) SI-7(5)
CM0044 Cyber-safe Mode Cyber-safe mode is a dedicated, configuration-controlled spacecraft operating state entered autonomously or by authorized ground command when mission-defined conditions indicate a credible threat to platform integrity. In this state, nonessential functions are shut down or isolated and the spacecraft operates from an integrity-protected, validated software and configuration baseline. Unlike traditional safe mode, which addresses hardware faults and operational anomalies, cyber-safe mode is specifically designed to respond to cyber threats, providing a secure recovery baseline from which the spacecraft can reconstitute compromised functions. Authentication and encryption must remain enabled within cyber-safe mode, ensuring that the reduced operational state does not degrade the security posture of the vehicle. The cyber-safe mode software and configuration must be stored onboard using hardware-based protections that prevent modification by nominal flight software, ordinary commands, and other untrusted execution paths. Where baseline updates are permitted, they must use a separately authorized and integrity-verified maintenance process that preserves a recoverable trusted version. Following entry into cyber-safe mode, the spacecraft must be capable of reconstituting firmware and software functions to pre-attack capability levels, either autonomously through self-healing mechanisms or with ground assistance, and must be capable of replanning operations based on whatever equipment remains available after the cyber event. The primary recovery objective is restoration of full mission capability; where that is not achievable, the spacecraft should attain the maximum reduced mission capability available given the post-attack system state. CP-10 CP-10(4) CP-12 CP-2 CP-2(5) IR-3 IR-3(1) IR-3(2) IR-4 IR-4(12) IR-4(3) PE-10 PE10 PL-8 PL-8(1) SA-3 SA-8 SA-8(10) SA-8(12) SA-8(13) SA-8(19) SA-8(21) SA-8(23) SA-8(24) SA-8(26) SA-8(3) SA-8(4) SC-16(2) SC-24 SC-5 SI-11 SI-17 SI-4(7) SI-7(17) SI-7(5)
CM0068 Reinforcement Learning A reinforcement learning (RL) agent deployed within the spacecraft or ground system can provide an adaptive, autonomous anomaly detection and response capability that identifies anomalous events, including malicious data inputs and injected commands, and redirects affected processes to proceed safely by ignoring or isolating the malicious input. An RL agent learns a response policy that maps observations to actions according to its training environment and reward function. It may generalize to scenarios not explicitly included in training, but its ability to detect or respond correctly to novel attacks or conditions outside the validated operational envelope must not be assumed. Anomaly detection may be incorporated into the RL architecture or provided by a separate monitoring function. Effective deployment requires separate protections against compromise of the training process and manipulation of observations presented to the deployed agent. Online learning or policy adaptation should be disabled unless specifically authorized, bounded, and validated. Agent-selected responses must be constrained by a trusted safety mechanism. IR-5 IR-5(1) SI-4 SI-4(2)
CM0029 TRANSEC Transmission security (TRANSEC) is the component of communications security (COMSEC) concerned with protecting the characteristics of the transmission itself, as distinct from protecting the content of the information being communicated. TRANSEC controls reduce the likelihood, effectiveness, or operational impact of transmission interception, signal disruption, communications deception, and exploitation of transmission characteristics within the defined threat model. Applicable TRANSEC techniques include jam-resistant waveforms that increase resistance to jamming and communications deception, spread spectrum and frequency hopping techniques that reduce signal predictability and improve resistance to interception and disruption, low probability of intercept and low probability of detection (LPI/LPD) signal designs that reduce transmission observability, and transmission scheduling or pattern discipline that limits the intelligence value of traffic analysis. TRANSEC requirements should be applied to mission communication links according to link criticality (e.g., TT&C, crosslinks), threat exposure, and operational consequence. TRANSEC must be treated as a distinct layer of protection complementary to, but not a substitute for, cryptographic protection of information content. AC-17 AC-18 AC-18(5) CA-3 CP-8 PL-8 PL-8(1) SA-8(19) SC-16 SC-16(1) SC-40 SC-40(1) SC-40(3) SC-40(4) SC-5 SC-8(1) SC-8(3) SC-8(4)