Machine Learning Data Integrity

When AI/ML is being used for mission critical operations, the integrity of the training data set is imperative. Data poisoning against the training data set can have detrimental effects on the functionality of the AI/ML. Fixing poisoned models is very difficult so model developers need to focus on countermeasures that could either block attack attempts or detect malicious inputs before the training cycle occurs. Regression testing over time, validity checking on data sets, manual analysis, as well as using statistical analysis to find potential injects can help detect anomalies.

NIST Rev5 Controls

D3FEND Techniques

D3FEND Artifacts

Storage
File

ISO 27001

NASA Best Practice Guide

ESA Space Shield Mitigation

None

Related MITRE EMB3D Mitigations

No related MITRE EMB3D Mitigations

Related CSF 2.0

Related BSI Security Measures

No related BSI Security Measures

ID: CM0049

Tier: II

Onboard SV CM

Created: 2022/10/19

Last Modified: 2023/10/17

Techniques Addressed by Countermeasure

ID		Name	Description
EX-0012		Modify On-Board Values	The attacker alters live or persistent data that the spacecraft uses to make decisions and route work. Targets include device and control registers, parameter and limit tables, internal routing/subscriber maps, schedules and timelines, priority/QoS settings, watchdog and timer values, autonomy/FDIR rule tables, ephemeris and attitude references, and power/thermal setpoints. Many missions expose legitimate mechanisms for updating these artifacts, direct memory read/write commands, table load services, file transfers, or maintenance procedures, which can be invoked to steer behavior without changing code. Edits may be transient (until reset) or latched/persistent across boots; they can be narrowly scoped (a single bit flip on an enable mask) or systemic (rewriting a routing table so commands are misdelivered). The effect space spans subtle biasing of control loops, selective blackholing of commands or telemetry, rescheduling of operations, and wholesale changes to mode logic, all accomplished by modifying the values the software already trusts and consumes.
	.13	Poison AI/ML Training Data	When missions employ AI/ML, for onboard detection/classification, compression, anomaly screening, guidance aids, or ground-side planning, training data becomes a control surface. Data poisoning inserts crafted examples or labels into the training corpus or fine-tuning set so the resulting model behaves incorrectly while appearing valid. Variants include clean-label backdoors (benign-looking samples with a hidden trigger that later induces a targeted response), label flipping and biased sampling (to skew decision boundaries), and corruption of calibration/ground-truth products that the pipeline trusts. For space systems, poisoning may occur in science archives, test vectors, simulated scenes, or housekeeping datasets used to train autonomy/anomaly models; models trained on poisoned corpora are then packaged and uplinked as routine updates. Once fielded, a simple trigger pattern in imagery, telemetry, or RF features can cause misclassification, suppression, or false positives at the time and place the adversary chooses, turning model behavior into an execution mechanism keyed by data rather than code.

ID	Description
SV-IT-2	Unauthorized modification or corruption of data

Sample Requirements

SPARTA ID	Requirement	Rationale/Additional Guidance/Notes
SPR-2	The [spacecraft] shall ensure that sensitive information can only be accessed by personnel with appropriate roles and an explicit need for such information to perform their duties.{SV-CF-3,SV-AC-4}{AC-3(11),CM-12}	Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations.
SPR-11	The [spacecraft] encryption key handling shall be handled outside of the onboard software and protected using cryptography.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(1),SC-28(3)}	Key management separated from modifiable flight software reduces exposure to software compromise. If keys are accessible to onboard applications, malicious code could extract or misuse them. Hardware-anchored or externally managed key handling reduces persistence risk. This supports trust-chain assurance and mitigates firmware-level compromise.
SPR-17	The [spacecraft] shall protect the confidentiality and integrity of all information at rest using cryptography.{SV-CF-1,SV-CF-2,SV-AC-3}{AC-3,SA-8(19),SC-28,SC-28(1),SI-7(6)}	* The intent as written is for all transmitted traffic to be protected. This includes internal to internal communications and especially outside of the boundary.
SPR-18	The [spacecraft] shall protect the confidentiality and integrity of information during preparation for transmission, transmission, and reception, in accordance with the [organization]‑provided encryption matrix.{SV-AC-7}{AC-3,SA-8(19),SC-8,SC-8(1),SC-8(2),SC-16,SC-16(1),SC-40}	* Preparation for transmission and during reception includes the aggregation, packing, and transformation options performed prior to transmission and the undoing of those operations that occur upon receipt.
SPR-19	The [spacecraft] shall encrypt all telemetry on downlink regardless of operating mode to protect current state of spacecraft.{SV-CF-4}{AC-3(10),RA-5(4),SA-8(18),SA-8(19),SC-8,SC-8(1),SC-13}	Telemetry exposes real-time spacecraft state and configuration. Unencrypted telemetry can reveal vulnerabilities, operational status, or targeting information. Enforcing encryption across all modes prevents intelligence collection and mission state inference. This mitigates passive RF interception threats.
SPR-44	The [spacecraft] shall maintain the confidentiality and integrity of information during preparation for transmission and during reception in accordance with [organization] provided encryption matrix.{SV-CF-1,SV-CF-2,SV-IT-2}{SA-8(19),SC-8,SC-8(1),SC-8(2),SC-8(3)}	* Preparation for transmission and during reception includes the aggregation, packing, and transformation options performed prior to transmission and the undoing of those operations that occur upon receipt.
SPR-50	The [spacecraft] shall implement cryptographic mechanisms to protect the confidentiality and integrity of information during transmission unless otherwise protected by approved physical safeguards.{SV-AC-7}{SC-8,SC-8(1),SC-8(4),SI-7(6)}	Unprotected transmission exposes telemetry, commands, and state information to interception or manipulation. Cryptographic protections ensure authenticity and confidentiality across all communication paths. Physical safeguards alone are insufficient in contested environments.
SPR-53	The [organization] shall employ automated tools that provide notification to ground operators upon discovering discrepancies during integrity verification.{CM-3(5),CM-6,IR-6,IR-6(2),SA-8(21),SC-51,SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(2)}
SPR-72	The [spacecraft] shall automatically notify ground operators when onboard integrity verification detects discrepancies.{SV-IT-2}{CM-3(5),SA-8(21),SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(2),SI-7(12)}	Integrity check failures may indicate unauthorized modification, corruption, or hardware faults induced by malicious activity. Automatic notification ensures ground teams can rapidly assess risk and initiate recovery procedures. Delay in reporting increases mission impact. Transparency between onboard detection and ground response is essential for coordinated defense.
SPR-73	The [spacecraft], upon detection of a potential integrity violation, shall provide the capability to [audit the event and alert ground operators].{SV-DCO-1}{CM-3(5),SA-8(21),SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(8)}	One example would be for bad commands where the system would reject the command and not increment the Vehicle Command Counter (VCC) and include the information in telemetry.
SPR-74	The [organization] shall define the security safeguards that are to be automatically employed when integrity violations are discovered.{SV-IT-2}{CP-2,SA-8(21),SI-3,SI-4(7),SI-4(12),SI-7(5),SI-7(8)}	Predefined safeguards ensure consistent and timely response to detected integrity violations. Ad hoc response increases uncertainty and recovery time. Automated actions may include isolation, reconstitution from gold images, or transition to cyber-safe mode. Defined response paths improve resilience and reduce operator burden during crisis.
SPR-81	The [spacecraft] shall perform an integrity check of software, firmware, and information at startup or during security- events.{SV-IT-3,SV-SP-7,SV-SP-3}{CM-3(5),SA-8(9),SA-8(11),SA-8(21),SI-3,SI-7(1),SI-7(10),SI-7(12),SI-7(17)}	Startup integrity checks detect boot-level compromise or unauthorized modification. Event-triggered checks provide additional protection when anomalies occur. This limits adversary persistence across reboots. Continuous validation reinforces trusted boot regimes.
SPR-90	The [organization] shall define and document the transitional state or security-relevant events when the spacecraft will perform integrity checks on software, firmware, and information.{SV-IT-2}{SA-8(21),SI-7(1),SI-7(10),SR-4(4)}	Integrity checks must be executed at well-defined lifecycle transitions (e.g., boot, mode change, update, anomaly). Clear documentation prevents gaps in validation coverage. Transitional state definitions ensure consistent enforcement across mission phases. This supports predictable and auditable trust verification.
SPR-126	The [spacecraft] shall protect the confidentiality and integrity of the [all information] using cryptography while it is at rest.{SV-IT-2,SV-CF-2}{SC-28,SC-28(1),SI-7(6)}	* Information at rest refers to the state of information when it is located on storage devices as specific components of information systems. This is often referred to as data-at-rest encryption.
SPR-148	The [spacecraft] shall protect the confidentiality and integrity of all transmitted information.{SV-IT-2,SV-AC-7}{SC-8}	* The intent as written is for all transmitted traffic to be protected. This includes internal to internal communications and especially outside of the boundary.
SPR-149	The [spacecraft] shall perform an integrity check of [Program-defined software, firmware, configuration parameters, and tables] at startup; at [Program-defined transitional states or security-relevant events] and shall verify integrity on receipt and prior to activation of any uploaded package.{SV-IT-2}{SI-7(1)}	Transitional states often introduce vulnerability windows. Integrity checks at these moments detect tampering before activation. Pre-activation validation prevents malicious update deployment. This reinforces chain-of-trust enforcement.
SPR-150	The [organization] shall employ automated tools that provide notification to [Program-defined personnel] upon discovering discrepancies during integrity verification.{SV-IT-2}{SI-7(2)}	Automated alerts ensure discrepancies are not overlooked. Timely notification enables rapid incident response. Automation reduces operator delay. Clear escalation paths strengthen containment.
SPR-151	The [spacecraft] shall automatically [Selection (one or more):restarts the FSW/processor, performs side swap, audits failure; implements Program-defined security safeguards] when integrity violations are discovered.{SV-IT-2}{SI-7(8)}	Immediate system response prevents continued exploitation after detection. Restart, side swap, or safeguard activation restores known-good state. Automated actions reduce dwell time. Rapid containment is essential in communication-limited environments.
SPR-227	The [organization] shall identify all locations (including ground and contractor systems) that store or process sensitive system information.{SV-CF-3,SV-SP-4,SV-SP-10}{AC-3(11),CM-12}	Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations.
SPR-228	The [organization] shall identify sensitive mission data (e.g.CPI) and document the specific on-board components on which the information is processed and stored.{SV-MA-4,SV-CF-3}{AC-3(11),CM-12}	Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations.
SPR-245	The [organization] shall define processes and procedures to be followed when integrity verification tools detect unauthorized changes to software, firmware, and information.{SV-IT-2}{CM-3,CM-3(1),CM-3(5),CM-5(6),CM-6,CP-2,IR-6,IR-6(2),PM-30,SC-16(1),SC-51,SI-3,SI-4(7),SI-4(24),SI-7,SI-7(7),SI-7(10)}	Predefined response procedures reduce reaction time. Clear escalation paths improve containment. Consistent handling prevents confusion during incidents. Preparedness strengthens resilience.
SPR-437	The [organization] shall enable integrity verification of software and firmware components.{SV-IT-2}{CM-3(5),CM-5(6),CM-10(1),SA-8(9),SA-8(11),SA-8(21),SA-10(1),SI-3,SI-4(24),SI-7,SI-7(10),SI-7(12),SR-4(4)}	* The integrity verification mechanisms may include: Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites; Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery; Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure; Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses; Implementing cryptographic hash verification; and Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing. Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites; Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery; Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure; Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses; Implementing cryptographic hash verification; and Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing.
SPR-450	The [spacecraft] shall prevent flight software and payload applications from modifying access control labels or rules and shall validate label integrity at startup and during policy updates.{SV-AC-1,SV-IT-2}{AC-3(3),AC-3(11).AC-16,SI-7}	Label integrity ensures policy decisions remain trustworthy. Preventing modification protects data classification enforcement. Validation at startup prevents persistent compromise. Policy integrity underpins MAC assurance.
SPR-455	The [spacecraft] shall restrict access to flight software executables, cryptographic material, command dictionaries, and [organization]-defined sensitive payload data to the privileged execution domain and shall deny all other access by default.{SV-AC-1,SV-AC-3,SV-IT-3}{AC-3(11),AC-6}	Flight executables and cryptographic materials are high-value targets. Restricting access reduces exploitation pathways. Default deny enforces least privilege. Segmentation enhances resilience.
SPR-456	The [spacecraft] shall implement OS or hardware enforcement for these restrictions and shall log any attempted access violations.{SV-AC-1,SV-DCO-1}{AC-3,AC-3(11)}	Hardware-enforced policy is harder to bypass than software-only controls. Logging violations supports detection and response. Layered enforcement strengthens assurance. Technical barriers reinforce governance intent.
SPR-462	The [spacecraft] shall support delegation of temporary data storage to [organization]-authorized alternate nodes or spacecraft and shall preserve confidentiality, integrity, and access controls for the delegated data.{SV-CF-1,SV-CF-2,SV-AC-1}{CP-2(6),SC-28,AC-3}	Delegated storage or processing expands trust boundaries. Maintaining CIA protections during delegation prevents exposure. Secure federation supports constellation-based architectures. Controlled delegation strengthens distributed resilience.
SPR-491	The [spacecraft] shall employ transmission security techniques that conceal or randomize RF signal parameters, including modulation, timing, and power characteristics, to prevent signal fingerprinting and association in accordance with the System TRANSEC Plan. Implementation and verification shall be coordinated with TRANSEC and Traffic Flow Security.{SV-CF-2}{SC-8,SC-40(4)}	Concealing RF characteristics prevents signal fingerprinting. Randomization reduces tracking and targeting risk. Coordinated TRANSEC alignment strengthens defense. Signal agility enhances survivability.
SPR-492	The [spacecraft] shall update signal parameter selections using cryptographically sound PRNG inputs at [organization]‑defined intervals or triggers, coordinated with TRANSEC and Traffic Flow Security.{SV-CF-2,SV-AC-3}{SC-8,SC-12,SC-40(4)}	Predictable signal patterns enable adversary exploitation. Strong PRNG inputs ensure randomness integrity. Coordinated update intervals prevent synchronization attacks. Cryptographic randomness strengthens concealment.
SPR-503	The [organization] shall validate authenticity and integrity of all flight-designated hardware, firmware, and software upon receipt using program-controlled trust anchors (approved vendor list, golden hash/cert manifest){SV-SP-4,SV-SP-5}{SR-4(3),SR-11,SI-7}	Receipt validation prevents counterfeit or tampered parts integration. Program-controlled trust anchors ensure consistency. Early detection reduces downstream risk. Intake verification strengthens SCRM posture.
SPR-504	The [organization] shall re-validate component identity (serial/lot), firmware measurements (cryptographic hashes), and certificate status immediately prior to installation, writing results to the SCRM/provenance ledger and blocking install on mismatch.{SV-SP-4,SV-SP-5}{SR-4(3),SR-11,SI-7}	Installation-time validation prevents stale or revoked components. Ledger recording strengthens traceability. Blocking on mismatch prevents compromise propagation. Continuous verification enhances assurance.
SPR-505	The [spacecraft] shall cryptographically verify boot images and configurations at power-on and after any update{SV-IT-3,SV-SP-9}{SR-4(3),SI-7,CM-14}	Secure boot prevents execution of unauthorized code. Post-update verification ensures integrity continuity. Root-of-trust enforcement protects mission-critical logic. Deterministic startup strengthens resilience.
SPR-528	The [organization] shall package each flight change (software, bitstreams, configuration tables) with a signed manifest, precondition checks (mode, power/thermal, link), explicit hold/commit points, and resumable procedures across AOS/LOS; the [spacecraft] shall enforce manifest checks prior to activation.{SV-SP-9,SV-IT-2}{CM-3,CM-3(2),SI-7,SA-10}	Manifest enforcement ensures integrity prior to activation. Precondition checks prevent unsafe changes. Resumable logic supports space contact constraints. Structured packaging strengthens update security.
SPR-531	The [spacecraft] shall enforce whitelisting for executable images and mission scripts/procedures by ID, hash, or signature, accept only artifacts produced by the mission build pipeline, and constrain interpreters/macros to sandboxed contexts with provenance checks on inputs.{SV-SP-9,SV-SP-4}{CM-7,CM-7(5),CM-7(8),SI-7}	Accepting only pipeline-produced artifacts prevents unauthorized code execution. Hash/signature validation ensures integrity. Sandbox constraints limit interpreter abuse. Provenance enforcement strengthens defense.
SPR-543	The [spacecraft] shall complement link‑layer protections with per‑message MACs/signatures for commands and selected telemetry so integrity and origin assurance persist across relays and storage/forwarding; operator feedback shall distinguish corruption vs. integrity vs. authentication failures.{SV-IT-1,SV-AC-2}{AC-17(10),SC-8,SC-8(2)}	Storage/forwarding relays can break link-layer trust. Message-level MACs preserve end-to-end assurance. Clear error distinctions aid operators. Layered integrity strengthens trust continuity.
SPR-547	The [spacecraft] shall support chunked uploads of software/bitstreams/configuration with per‑chunk verification and commit markers, resumable across passes, with atomic activation and rollback if activation checks fail.{SV-SP-9,SV-IT-2}{SI-7,SI-7(15)}	Per-chunk verification prevents partial corruption. Atomic activation avoids inconsistent states. Rollback ensures safe recovery. Structured update logic strengthens resilience.