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

MI-DCO-01 - Mission Adversarial Actions Detection Function

Principle

The mission should incorporate an on-board cyber actor actions detection function in its requirements and resulting system.

Rationale

The mission should plan for the possibility of an on-board disruption deriving from a security incident and incorporate these considerations. Event detection, mitigations, and alerting of ground segment security operations team are critical controls to provide the capability for operational teams to know when other controls have failed, rapidly respond (where possible). The resulting lessons learned should be fed back into the design process. Monitoring of key software observables (e.g., number of failed login attempts, unscheduled lockups of the flight receiver, indications of RFI on non-telecom equipment, performance changes, internal communication changes) is needed to detect cyber actor actions that interdict mission success. Cybersecurity attacks affecting components of in-flight systems are expected. A cybersecurity incident response plan is key to the timely and effective response to a cybersecurity attack. All suspected cyber actor actions should be reported. Raw event data should be further analyzed to determine whether an anomalous event represents an attack, and if so, the nature of the attack, and the appropriate response to mitigate impact to the mission. Ensure the mission is following NPR 7150.2 guidance for software to detect cyber actor actions, such as those in 3.11.8.

Related Countermeasures

ID Name Description NIST Rev 5
CM0090 Continuous Monitoring Continuous monitoring maintains persistent, real-time or near-real-time visibility into the security posture of spacecraft, ground systems, and mission networks, providing the ongoing situational awareness required to support informed risk management decisions throughout the mission lifecycle. Unlike point-in-time assessments that capture a snapshot of security posture at a specific moment, continuous monitoring detects changes in system configuration, software vulnerabilities, threat indicators, and control effectiveness as they occur, enabling faster detection of and response to security-relevant events before they escalate into mission-impacting incidents. For space missions, continuous monitoring spans both the cyber domain, including ground system network activity, software configuration compliance, vulnerability status, and access control events, and the physical and operational domains, including spacecraft telemetry indicators of anomalous behavior, link quality indicators of potential radio frequency (RF) interference, and space domain awareness data indicating proximity threats. The output of continuous monitoring feeds directly into risk management decision-making, providing mission owners and security teams with the current information needed to prioritize remediation actions, authorize changes, and adjust defensive posture in response to the evolving threat and vulnerability landscape. CA-7 CA-7(1) CA-7(3) CA-7(4) CA-7(5) CA-7(6)
CM0069 Process White Listing Process whitelisting establishes an approved set of executable images, tasks, applications, or process types that may run on the spacecraft computing platform. Enforcement should occur within a trusted layer capable of controlling process or task creation, which may be implemented in firmware, a secure monitor, a hypervisor, the operating system, or the real-time executive according to the platform architecture. The enforcement mechanism must verify an approved process identity before execution and deny unapproved process creation unless a mission-approved recovery mechanism applies. This countermeasure limits the creation or execution of software identities not present in the approved baseline. It does not prevent an adversary from abusing an approved process, altering its runtime memory, redirecting its control flow, or exploiting permitted scripting or loading functionality unless those behaviors are addressed by complementary integrity and execution controls. CM-11 CM-7(5) PL-8 PL-8(1) SI-10(5)
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)
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)
CM0066 Model-based System Verification Model-based system verification compares observed spacecraft behavior with behavior predicted by a physics-based or hybrid model to identify discrepancies inconsistent with mission-defined physical, configuration, and operational constraints. It can detect unexpected or physically implausible sensor values, state transitions, actuator effects, and command outcomes, but it does not independently establish that a command was authorized or that an anomaly was caused by a cyberattack. The verification architecture should use an independently protected model, diagnosis engine, configuration baseline, and, where feasible, diverse or separately validated input sources. A model driven solely by the same compromised sensor values, state estimates, command history, or software pathways as the monitored system may reproduce the adversary-controlled state rather than detect it. Model-based verification therefore complements authentication, command authorization, data integrity, fault management, and security monitoring rather than replacing them. The fidelity of the physics model determines the sensitivity and specificity of the verification, with higher-fidelity models capable of detecting subtler anomalies at the cost of greater computational resources. The model should provide sufficient fidelity for the defined verification objectives without introducing unnecessary complexity or sensitivity to poorly characterized parameters. Higher fidelity may improve detection of some anomalies but does not automatically improve sensitivity or specificity and may increase computational cost, model-maintenance burden, or false alerts caused by model mismatch. SI-4 SI-4(2)
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)
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)