When security monitoring relies on AI/ML (e.g., anomaly detection on telemetry, RF fingerprints, or command semantics), the training data itself is a target. Data-poisoning introduces crafted examples or labels so the learned model embeds false associations, treating attacker behaviors as normal, or flagging benign patterns instead. Variants include clean-label backdoors keyed to subtle triggers, label flipping that shifts decision boundaries, and biased sampling that suppresses rare-but-critical signatures. Models trained on tainted corpora are later deployed as routine updates; once in service, the adversary presents inputs containing the trigger or profile they primed, and the detector omits or downranks the very behaviors that would reveal the intrusion.
| ID | Name | Tiering | Description | NIST Rev5 | ISO 27001 | Onboard SV | Ground | |
| CM0049 | Machine Learning Data Integrity | When artificial intelligence (AI) or machine learning (ML) is employed for mission-critical spacecraft or ground system operations, the integrity of the training data set is a foundational security requirement, not merely a data quality concern. Data poisoning attacks introduce or modify training samples, labels, or other data-pipeline inputs to alter resulting model behavior. Poisoning may cause general performance degradation, targeted misclassification, or backdoor behavior that appears only when specific operational inputs or triggers are present. Remediation may require identifying and removing affected data, retraining or fine-tuning from a trusted dataset, or rolling back to a validated model. Because remediation can be difficult and may not identify every affected behavior, controls should prioritize preventing unauthorized data changes and detecting suspicious inputs before training while maintaining recoverable trusted dataset and model versions. Detection and prevention techniques include validity checking of data sets to identify statistically anomalous or out-of-distribution inputs, statistical analysis to detect injected samples that deviate from expected data distributions, manual analysis of flagged inputs, and regression testing over time to identify model behavioral drift that may indicate successful historical poisoning. These controls must be applied as part of a continuous data governance process spanning the full training pipeline, from data collection and curation through model validation and operational deployment. | AC-3(11) SC-28 SC-28(1) SC-8 SC-8(2) SI-7 SI-7(1) SI-7(2) SI-7(5) SI-7(6) SI-7(8) | A.8.4 A.5.10 A.5.14 A.8.20 A.8.26 A.5.10 A.5.33 | ||||
| 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 | ||||
| CM0056 | Data Backup | A mission's ability to recover from a cyber incident, hardware failure, or adversary action depends directly on the availability of verified, uncorrupted backups of critical data that are stored independently from the primary systems those backups are intended to restore. Data backup procedures must be defined within a broader disaster recovery plan that specifies what data is backed up, at what frequency, through what process, and under what conditions restoration will be initiated. At least one recoverable backup copy must be stored outside the primary system’s administrative and failure domains and protected so that compromise of ordinary production systems, credentials, or management services does not provide the ability to modify or destroy that copy. Separation may use offline media, physically separate infrastructure, isolated storage systems, separate cloud accounts or security domains, immutable retention controls, or an approved combination of these mechanisms. Backup storage must be protected against the methods adversaries commonly use to target recovery capability, including ransomware that encrypts or deletes backup repositories, credential attacks against backup management systems, and physical access to backup media. Backup integrity must be verifiable, as a backup that has been silently corrupted or tampered with provides no recovery capability when needed. | CP-9 SA-3 SA-8 SA-8(29) SI-12 | A.5.29 A.5.33 A.8.13 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | ||||
| 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 | ||||