Adversaries may leverage process injection methods to execute malicious functionality within trusted onboard software processes in order to suppress, delay, filter, or selectively conceal telemetry and operational reporting associated with unauthorized activity. By operating inside legitimate telemetry handlers, flight software tasks, middleware, or operating system services, attackers can interfere with the generation, aggregation, or transmission of monitoring data before it is downlinked or processed by onboard monitoring systems. Unlike direct modification of individual operational values, this technique focuses on manipulating the reporting path itself to prevent malicious activity from being observed, correlated, or reconstructed by operators or autonomy systems. Examples may include suppressing telemetry associated with unauthorized commands, filtering fault events prior to downlink, selectively disabling event reporting during malicious operations, delaying housekeeping updates, or preventing monitoring services from publishing anomalous state information.
| ID | Name | Tiering | Description | NIST Rev5 | ISO 27001 | Onboard SV | Ground | |
| 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) | A.8.19 A.8.19 A.5.8 | ||||
| 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) | A.8.16 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | ||||
| 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) | A.8.15 A.8.15 A.8.6 A.8.17 A.5.33 A.8.15 A.8.15 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.7 A.8.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16 | ||||
| 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) | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.7.11 A.7.11 A.7.5 A.7.8 A.7.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.16 | ||||
| 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) | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.29 A.5.25 A.5.26 A.5.27 A.7.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | ||||