a. Determine and document the types of changes to the system that are configuration-controlled; b. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses; c. Document configuration change decisions associated with the system; d. Implement approved configuration-controlled changes to the system; e. Retain records of configuration-controlled changes to the system for [Assignment: organization-defined time period]; f. Monitor and review activities associated with configuration-controlled changes to the system; and g. Coordinate and provide oversight for configuration change control activities through [Assignment: organization-defined configuration change control element] that convenes [Selection (one or more): [Assignment: organization-defined frequency] ; when [Assignment: organization-defined configuration change conditions] ].
| ID | Name | Description | D3FEND | |
| CM0072 | Protocol Update / Refactoring | Communication and data exchange protocols governing spacecraft, ground system, and inter-system interfaces may contain specification-level vulnerabilities that cannot be resolved through implementation hardening alone, requiring updates to or refactoring of the protocol itself to eliminate the underlying weakness. Protocol vulnerabilities may arise from design flaws in the original specification, from advances in adversarial capability that render previously adequate security assumptions insufficient, or from emerging threats such as quantum computing that threaten the cryptographic primitives upon which protocol security depends. Protocol update or refactoring encompasses the deliberate modification of the rules, formats, and procedures governing system communications to address known vulnerabilities, improve security properties, or maintain adequate protection against the evolving threat environment over the mission's operational lifetime. Because space system protocols are often tightly coupled to hardware interfaces, flight software implementations, and ground system processing pipelines, protocol changes carry significant integration risk and must be managed through rigorous engineering change processes; this complexity makes proactive protocol security assessment and planned update capability more cost-effective than reactive refactoring under operational urgency. | D3-NM D3-NVA D3-AI D3-AVE D3-SYSM D3-SYSVA D3-OAM D3-ORA D3-PMAD | |
| ID | Description | |
| SV-IT-2 |
Unauthorized modification or corruption of data |
|
| SV-SP-1 |
Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the FSW. |
|
| SV-SP-3 |
Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, keylogger, rootkit, or Trojan Horse |
|
| SV-SP-6 |
Software reuse, COTS dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to supply chain threat |
|
| SV-SP-9 |
On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code |
|
| SV-SP-11 |
Software defined radios - SDR is also another computer, networked to other parts of the spacecraft that could be pivoted to by an attacker and infected with malicious code. Once access to an SDR is gained, the attacker could alter what the SDR thinks is correct frequencies and settings to communicate with the ground. |
|
| SV-SP-7 |
Software can be broken down into three levels (operating system and drivers’ layer, data handling service layer, and the application layer). Highest impact on system is likely the embedded code at the BIOS, kernel/firmware level. Attacking the on-board operating systems. Since it manages all the programs and applications on the computer, it has a critical role in the overall security of the system. Since threats may occur deliberately or due to human error, malicious programs or persons, or existing system vulnerability mitigations must be deployed to protect the OS. |
|
| SV-MA-7 |
Exploit ground system and use to maliciously to interact with the spacecraft |
|
| SV-SP-4 |
General supply chain interruption or manipulation |
|
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| SPR-91 | The [spacecraft] shall prevent the installation of Flight Software without verification that the component has been digitally signed.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9}{CM-3,CM-3(8),CM-5,CM-5(3),CM-14,SA-8(8),SA-8(31),SA-10(2),SI-3,SI-7(12),SI-7(15)} | Requiring digital signature verification before installing flight software prevents unauthorized, malicious, or tampered code from being introduced into the spacecraft environment. Software supply chain compromise is a high-impact attack vector that can result in persistent control or loss of mission. Cryptographic validation ensures only approved and trusted binaries are executed. This maintains integrity of the trusted computing baseline. |
| 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-257 | The [organization] shall analyze changes to the spacecraft to determine potential security impacts prior to change implementation.{SV-MA-6,SV-SP-9}{CM-4,CM-3,CM-3(2),CM-3(7),CM-4(2),SA-10} | Changes to spacecraft configuration may introduce unintended vulnerabilities. Pre-implementation impact analysis prevents security regression. Structured review ensures modifications align with risk tolerance. Change control supports mission assurance. |
| SPR-266 | The [organization] shall determine the vulnerabilities/weaknesses that require remediation, and coordinate the timeline for that remediation, in accordance with the analysis of the vulnerability scan report, the mission assessment of risk, and mission needs.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-5,CM-3,RA-5,RA-7,SI-3,SI-3(10)} | Not all vulnerabilities carry equal mission impact. Risk-informed prioritization ensures critical flaws are addressed first. Coordinated timelines balance mission needs with security posture. Structured remediation strengthens governance. |
| SPR-320 | The [organization] shall develop and document program-specific configuration management policies and procedures for the hardware and software for the spacecraft. {SV-SP-9,SV-MA-6}{CM-1,CM-3,CM-5(6),SA-10,SA-10(3)} | Clear configuration governance prevents unauthorized modification. Policy-backed processes ensure consistency. Lifecycle control supports traceability. Managed change reduces mission risk. |
| SPR-328 | The [organization] shall ensure any update to on-board software, memory, or stored procedures has met high assurance standards before execution. {SV-SP-9,SV-SP-4}{AC-3(2),CM-3,SA-8(8),SA-8(31),SA-10(2),SR-4(4)} | On-orbit updates carry significant risk if not validated. High assurance standards prevent unauthorized or corrupted uploads from executing. Structured validation protects system integrity. Update governance reduces mission-ending configuration errors. |
| SPR-331 | The [organization] shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects on mission systems in a separate test environment before installation.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-3,CM-3(1),CM-3(2),CM-4(1),CM-4(2),CM-10(1),SA-8(31),SA-11(9),SI-2,SI-3,SI-3(10),SI-7(10),SI-7(12),SR-5(2)} | This requirement is focused on software and firmware flaws. If hardware flaw remediation is required, refine the requirement to make this clear. |
| SPR-345 | The [organization] shall update the inventory of spacecraft components as an integral part of component installations, removals, and spacecraft updates.{SV-MA-4,SV-SP-4}{CM-8(1),CA-7,CM-2,CM-3} | Accurate inventory enables vulnerability tracking and incident response. Lifecycle updates prevent undocumented changes. Asset visibility strengthens security management. Configuration awareness reduces blind spots. |
| SPR-393 | The [organization] shall confirm that the operational spacecrafts correspond to the baseline configuration. {SV-SP-9,SV-SP-4}{CM-2,CM-3,CM-3(7),CM-4(2),CM-6,SA-10} | Configuration drift undermines trust and auditability. Confirming alignment ensures deployed assets reflect approved design. Baseline validation supports recovery and compliance. Continuous verification reduces unknown risk. |
| SPR-526 | The [organization] shall tie go/no‑go authorizations to verified artifacts (flatsat/twin results, signed images, key ceremonies) and define how authorization boundaries adjust under contingency conditions; evidence shall be captured for A&A.{SV-MA-6,SV-SP-9}{CA-1,PL-2,CM-3} | Flight decisions must rely on validated artifacts. Evidence capture strengthens compliance. Contingency adjustments must remain controlled. Governance alignment supports mission safety. |
| 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-529 | The [organization] shall define freeze windows around launch/maneuvers/high‑risk events, specify exception criteria and approvers, and require chunking, rate limits, checksum/signature gates, and telemetry cues that confirm final state when changes occur within a freeze.{SV-MA-6,SV-SP-9}{CM-3,CM-3(5),CM-5} | Operational stability requires disciplined change control. Freeze periods reduce compounding risk. Defined exceptions preserve agility. Structured boundaries protect mission safety. |
| ID | Name | Description | |
|---|---|---|---|
| REC-0005 | Eavesdropping | Adversaries seek to capture mission communications across terrestrial networks and RF/optical links to reconstruct protocols, extract telemetry, and derive operational rhythms. Collection is most often passive, but may be semi-passive or actively elicited, where the adversary transmits probes or crafted exchanges to provoke identifiable responses from the target rather than waiting to observe them. On networks, packet captures, logs, and flow data from ground stations, mission control, and cloud backends can expose service boundaries, authentication patterns, and automation. In the RF domain, wideband recordings, spectrograms, and demodulation of TT&C and payload links, spanning VHF/UHF through S/L/X/Ka and, increasingly, optical, enable identification of modulation/coding, framing, and beacon structures. Even when links are encrypted, metadata such as carrier plans, symbol rates, polarization, and cadence can support traffic analysis, timing attacks, or selective interference. Community capture networks and open repositories amplify the reach of a modest adversary. | |
| REC-0005.01 | Uplink Intercept Eavesdropping | Uplink reconnaissance focuses on capturing the command path from ground to spacecraft to learn telecommand framing, authentication fields, timing, and anti-replay behavior. Valuable artifacts include emission designators, symbol rates, polarization sense, Doppler profiles, and any preambles or ranging tones that gate command acceptance. Even if payload and TT&C share spectrum, their authentication postures often differ, knowledge an adversary can exploit. Partial captures, console screenshots, or training recordings reduce the effort needed to build an SDR pipeline that “looks right” on the air. Where missions authenticate without encrypting the uplink, traffic analysis can reveal command cadence and maintenance windows. | |
| REC-0005.02 | Downlink Intercept | Downlink collection aims to harvest housekeeping telemetry, event logs, ephemerides, payload data, and operator annotations that reveal system state and procedures. Even when payload content is encrypted, ancillary channels (beacons, health/status, low-rate engineering downlink) can disclose mode transitions, battery and thermal margins, safing events, and next-pass predictions. Community ground networks and public dashboards may inadvertently provide stitched datasets that make trend analysis trivial. Captured framing and coding parameters also help an adversary build testbeds and refine timing for later actions. | |
| REC-0005.03 | Proximity Operations | In proximity scenarios, an adversary platform (or co-located payload) attempts to observe emissions and intra-vehicle traffic at close range, RF side-channels, optical/lasercom leakage, and, in extreme cases, electromagnetic emanations consistent with TEMPEST/EMSEC concerns. Physical proximity can expose harmonics, intermodulation products, local oscillators, and bus activity that are undetectable from the ground, enabling reconstruction of timing, command acceptance windows, or even limited protocol content. In hosted-payload or rideshare contexts, a poorly segregated data path may permit passive observation of TT&C gateways, crosslinks, or payload buses. | |
| EXF-0003 | Signal Interception | The adversary captures mission traffic in transit, on ground networks or over the space link, so that payload products, housekeeping, and command/ack exchanges can be reconstructed offline. Vantage points include tapped ground LANs/WANs between MOC and stations, baseband interfaces (IF/IQ), RF/optical receptions within the antenna field of view, and crosslink monitors. Depending on protection, the haul ranges from plaintext frames to encrypted bitstreams whose headers, rates, and schedules still yield valuable context (APIDs, VCIDs, pass timing, file manifest cues). Intercepted sessions can guide later replay, cloning, or targeted downlink requests. | |
| EXF-0003.01 | Uplink Exfiltration | Here the target is command traffic from ground to space. By receiving or tapping the uplink path, the adversary collects telecommand frames, ranging/acquisition exchanges, and any file or table uploads. If confidentiality is weak or absent, opcode/argument content, dictionaries, and procedures become directly readable; even when encrypted, session structure, counters, and acceptance timing inform future command-link intrusion or replay. Captured material can reveal maintenance windows, contingency dictionaries, and authentication schemes that enable subsequent exploitation. | |
| EXF-0003.02 | Downlink Exfiltration | The attacker records spacecraft-to-ground traffic, real-time telemetry, recorder playbacks, payload products, and mirrored command sessions, to obtain mission data and health/state information. With sufficient signal quality and protocol knowledge, frames and packets are demodulated and extracted for offline use; where protection exists only on uplink or is inconsistently applied, downlink content may still be in clear. Downlinked command echoes, event logs, and file catalogs can expose internal activities and aid follow-on targeting while the primary objective remains data capture at scale. | |