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

MI-INTG-02 - PNT Survivability Function

Principle

The mission should be able to recover from positioning, navigation, and timing jamming and spoofing attempts.

Rationale

As a specific example of MI-INTG-01, space-based Positioning, Navigation, and Timing (PNT) relying on a GNSS signal may experience loss of signal (denial of service) and potential loss of the signal's data integrity. Manipulations (spoofing) of GNSS signal data may result in consequences to the space vehicles PNT.

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)
CM0050 On-board Message Encryption Authentication controls on the spacecraft internal bus verify the identity of communicating components but do not protect the confidentiality of the data in transit; an adversary with access to the bus, whether through a compromised component, a hardware implant, or a physical access event, can observe all unencrypted inter-component communications regardless of whether authentication is enforced. Encrypting data traversing the spacecraft internal bus protects the confidentiality of selected message content from entities that can observe the bus but do not possess authorization and the applicable cryptographic keys. The protection does not prevent disclosure to a compromised component that legitimately possesses the decryption key, and it may not conceal unencrypted protocol headers, addressing information, message timing, or traffic volume. Bus encryption should be considered for bus segments or message types carrying information whose unauthorized disclosure would create unacceptable mission, security, privacy, or operational risk. Criticality alone does not establish a confidentiality requirement. Where confidentiality is required, encryption must be combined with message integrity, source authentication, and replay protection through an approved authenticated-encryption mechanism or an appropriately composed set of cryptographic protections. AC-4 AC-4(23) AC-4(24) AC-4(26) AC-4(31) AC-4(32) PL-8 PL-8(1) SA-3 SA-8 SA-8(18) SA-8(19) SA-8(9) SA-9(6) SC-13 SC-16 SC-16(1) SC-16(2) SC-16(3) SC-8(1) SC-8(3) SI-19(4) SI-4(10) SI-4(25)
CM0046 Long Duration Testing Long duration testing subjects spacecraft software, firmware, hardware, and relevant integrated ground interfaces, or representative simulation and emulation environments, to extended test execution of 30 days or more to expose security and reliability defects that may manifest only after prolonged operation or specific time-dependent conditions. Race conditions, memory or resource leaks, time-dependent state corruption, resource exhaustion, counter rollover, and time-triggered malicious behavior may not manifest during short-duration testing because their activation depends on accumulated runtime, rare timing interactions, or gradual changes in system state. Long duration testing increases the opportunity to expose these conditions before deployment and complements static analysis, formal analysis, stress testing, fault injection, and targeted rollover testing. Testing should use the highest-fidelity environment appropriate to the test objectives. Flight-representative hardware should be used where hardware timing, device behavior, or integration effects are material; validated simulation or emulation may be used for conditions that it represents with sufficient fidelity. Differences between the test environment and operational system must be documented and considered when interpreting results. PL-8 PL-8(1) SA-3 SA-8 SA-8(30)
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)
CM0048 Resilient Position, Navigation, and Timing Where compatible authentication services are available, GNSS receivers used for spacecraft position, navigation, and timing (PNT) must authenticate the navigation information and its asserted GNSS system source before treating that information as trusted. Navigation-message authentication must not be treated as complete protection against spoofing because it may not authenticate the ranging signal or prevent all replay, meaconing, or signal-manipulation scenarios. Authenticated GNSS information should therefore be combined with PNT integrity monitoring and alternate navigation or timing sources appropriate to mission risk. The spacecraft must maintain a fault-tolerant authoritative time architecture capable of maintaining time within mission-defined accuracy and uncertainty limits when the primary source is degraded, rejected, or unavailable. The architecture should support the time-dependent cryptographic controls, command sequencing, telemetry correlation, fault-management logic, and other functions that rely on synchronized time. Each onboard processor must synchronize its internal clock to the authoritative time source whenever the measured time difference exceeds a threshold defined in the flight software (FSW), preventing clock drift from accumulating to levels that corrupt time-dependent functions. Where SpaceWire is used to distribute time, the spacecraft must implement the mission-defined synchronization protocol and achieve the accuracy required by the functions that consume that time. An accuracy of approximately one microsecond should be applied where required by the mission architecture and verified for the applicable SpaceWire nodes and operational configurations. CP-2 PE-20 PL-8 PL-8(1) SA-9 SC-16(2) SC-45 SC-45(1) SC-45(2)