Not being able to recover from cyberattack
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| SPR-99 | The [spacecraft] shall recover from cyber-safe mode to mission operations within 20 minutes.{SV-MA-5}{CP-2(3),CP-2(5),IR-4,SA-8(24)} | Upon conclusion of addressing the threat, the system should be capable of recovering from the minimal survival mode back into a mission-ready state within defined timelines. The intent is to define the timelines and the capability to return back to mission operations. |
| SPR-146 | The [spacecraft] shall provide at least one independent command for each operator-initiated action used to shutdown a function leading to or reducing the control of a hazard.{SV-MA-5,SV-MA-3}{SI-10(5)} | Independent shutdown commands ensure operators retain control during anomalous conditions. Redundant control paths reduce systemic failure risk. This supports safe recovery from hazardous states. Separation enhances mission survivability. |
| SPR-258 | The [organization] shall test the contingency plan, with special consideration for space operations, to determine the effectiveness of the plan and readiness to execute the plan.{SV-MA-5}{CP-4} | Contingency plans must be validated under realistic mission conditions. Testing confirms feasibility during communication latency or constrained power states. Exercises reveal gaps in readiness. Preparedness reduces recovery time during incidents. |
| SPR-259 | The [organization] shall develop an incident response and forensics plan that covers the spacecrafts.{SV-MA-5}{CP-2,IR-1,IR-3,IR-3(2),IR-4(12),IR-4(13),IR-8,SA-15(10),SI-4(24)} | A structured response plan enables coordinated containment and recovery. Forensics planning ensures evidence preservation. Defined procedures reduce confusion during crisis. Incident readiness enhances resilience. |
| SPR-260 | The [organization] shall test the incident response capabilities of the spacecraft to determine the effectiveness of the plan and readiness to execute the plan.{SV-MA-5}{IR-3} | Practical exercises validate plan effectiveness. Testing ensures spacecraft systems can support containment, telemetry capture, and recovery actions. Simulation reduces uncertainty during real events. Readiness must be demonstrated, not assumed. |
| SPR-261 | The [organization] shall coordinate testing of the incident response plan with organizational elements responsible for related plans.{SV-MA-5}{IR-3(2)} | Cyber incidents span mission, enterprise, and supplier boundaries. Coordinated exercises ensure interoperability and shared understanding. Integrated testing reduces response friction. Cross-organizational alignment improves containment. |
| SPR-341 | The [organization] shall coordinate contingency plan development, and testing of the plan, with organizational elements responsible for related plans.{SV-MA-5}{CP-2(1),CP-4(1)} | Integrated contingency planning ensures no isolated failure points. Coordination with related plans improves operational continuity. Structured collaboration strengthens recovery effectiveness. Unified preparation reduces confusion during crisis. |
| SPR-342 | The [organization] shall test the plan for the transfer of essential functions to alternate processing sites for both the ground and space segment assets to familiarize personnel with the process and to evaluate the ability of the site to continue those functions.{SV-MA-5}{CP-4(2)} | Transfer testing validates ability to sustain operations during disruption. Ground and space segment continuity must be demonstrated. Exercises expose integration gaps. Preparedness supports mission survivability. |
| SPR-349 | The [organization] shall establish and maintain a comprehensive program for testing, training, and monitoring to ensure the effectiveness of security controls and incident response capabilities.{SV-DCO-1,SV-MA-5}{PM-14} | Integrated programs ensure controls remain effective. Continuous validation supports adaptive security posture. Combined testing and training reduce complacency. Holistic oversight strengthens mission readiness. |
| SPR-358 | The [organization] shall plan for the transfer of essential ground-segment functions to alternate processing/storage site(s) (e.g.secondary ground terminal) with minimal or no loss of operational continuity until the primary ground terminal is fully restored (if the architecture supports it).{SV-MA-5}{CP-2(6)} | Redundant ground infrastructure enhances availability. Preplanning reduces disruption during outage. Distributed architecture strengthens resilience. Continuity planning supports mission assurance. |
| SPR-359 | The [organization] shall plan for the transfer of essential space-segment functions to alternate processing platforms (e.g.proliferated/distributed constellations) with minimal or no loss of operational continuity until the primary node is fully restored (if the architecture supports it).{SV-MA-5}{CP-2(6)} | Proliferated or distributed space assets reduce single-node risk. Functional transfer ensures mission continuity. Planning anticipates hostile or environmental disruptions. Resilient architectures improve survivability. |
| SPR-360 | The [organization] shall coordinate contingency plan development and associated activities with external service providers to ensure that contingency requirements can be satisfied.{SV-MA-5}{CP-2(7)} | External dependencies must align with mission continuity plans. Coordination reduces contractual gaps. Shared understanding strengthens recovery capability. Integrated planning supports operational resilience. |
| SPR-369 | The [organization] shall develop and document program-specific contingency planning policies to cover the development environment as well as the spacecraft. {SV-MA-5}{CP-1} | Formal contingency governance ensures lifecycle coverage. Development and operational environments both require resilience planning. Documentation supports coordinated response. Policy-backed preparation strengthens continuity. |
| SPR-371 | The [organization] shall develop, document, and implement an incident response policy specifically tailored for its space operations that outlines procedures for detecting, reporting, responding to, and recovering from security incidents affecting the spacecraft.{SV-MA-5,SV-DCO-1}{IR-1} | Space-specific IR procedures account for latency and limited intervention. Tailored guidance ensures effective containment. Structured recovery planning reduces mission impact. Specialized policies enhance readiness. |
| SPR-426 | The [organization] shall designate a supply chain coordinator as part of the incident handling process to facilitate communication and coordination between incident response teams and relevant stakeholders, including suppliers, vendors, and other entities within the supply chain.{SV-SP-4,SV-MA-5}{IR-4(10)} | Central coordination improves communication during incidents. Defined liaison strengthens supplier engagement. Structured oversight reduces fragmented response. Supply chain integration supports resilience. |
| SPR-461 | The [spacecraft] shall fail over mission critical processing to a redundant onboard compute element while maintaining authentication, authorization, and cryptographic protections.{SV-MA-5}{CP-2(6),CP-10} | Redundant compute without preserved security controls introduces new risk. Failover must maintain authentication and cryptographic state. Secure redundancy prevents availability from undermining integrity. Resilience must not weaken protection. |
| SPR-474 | The [organization] shall incorporate space cyber threat scenarios and mitigations into mission rehearsals and anomaly response training.{SV-MA-5,SV-AV-5}{PM-16,IR-2} | Realistic exercises validate preparedness. Embedding cyber threats in rehearsals strengthens operational readiness. Scenario-based training reduces reaction latency. Prepared teams enhance resilience. |
| SPR-493 | The [spacecraft] shall ensure that security-critical functions, including cryptographic processing, key storage, secure boot, and audit logging, continue under single-component failure by providing redundancy, graceful degradation, or verified fallback modes.{SV-MA-5}{SI-13,SC-24} | Single-point failure in security undermines mission assurance. Redundancy ensures continued enforcement. Graceful degradation maintains CIA protections. Fault tolerance supports resilience. |
| SPR-495 | The [spacecraft] shall detect impending failure of security components and initiate controlled failover to preserve confidentiality, integrity, and availability.{SV-MA-5,SV-DCO-1}{SI-4,SI-13,CP-10} | Early detection prevents cascading compromise. Controlled switchover maintains CIA properties. Structured alerting enhances situational awareness. Fault handling preserves assurance. |
| SPR-496 | The [spacecraft] shall provide standby instances for [organization]-defined high-criticality security components and automatically switch to the standby upon failure detection, generating an immediate alert that includes the component identity, time, and fault reason.{SV-MA-5}{SI-13(4),CP-10,AU-5} | Automatic failover reduces human delay. Immediate alerts support oversight. Identity and fault logging strengthen accountability. Resilient architecture supports mission continuity. |
| SPR-511 | The [organization] shall quarantine anti-counterfeit anomalies, block integration until disposition, open an incident record, notify SCRM lead/AO, and require supplier corrective action/lot containment as applicable.{SV-SP-4,SV-MA-5}{SR-11(3),IR-6} | Immediate quarantine prevents contaminated integration. Formal incident tracking ensures accountability. Supplier corrective actions reduce recurrence risk. Structured containment strengthens resilience. |
| ID | Name | Description | |
|---|---|---|---|
| IMP-0002 | [DEPRECATED] Disruption | Measures designed to temporarily impair the use or access to a system for a period of time. Threat actors may seek to disrupt communications from the victim spacecraft to the ground controllers or other interested parties. By disrupting communications during critical times, there is the potential impact of data being lost or critical actions not being performed. This could cause the spacecraft's purpose to be put into jeopardy depending on what communications were lost during the disruption. This behavior is different than Denial as this attack can also attempt to modify the data and messages as they are passed as a way to disrupt communications. | |
| IMP-0003 | [DEPRECATED] Denial | Measures designed to temporarily eliminate the use, access, or operation of a system for a period of time, usually without physical damage to the affected system. Threat actors may seek to deny ground controllers and other interested parties access to the victim spacecraft. This would be done exhausting system resource, degrading subsystems, or blocking communications entirely. This behavior is different from Disruption as this seeks to deny communications entirely, rather than stop them for a length of time. | |
| IMP-0004 | [DEPRECATED] Degradation | Measures designed to permanently impair (either partially or totally) the use of a system. Threat actors may target various subsystems or the hosted payload in such a way to rapidly increase it's degradation. This could potentially shorten the lifespan of the victim spacecraft. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0074 | Distributed Constellations | A distributed constellation architecture deploys mission capability across multiple spacecraft nodes operating collectively, such that the end user is not dependent on any single satellite to derive the intended capability. This architectural approach directly complicates adversary counterspace planning by multiplying the number of assets that must be successfully degraded or destroyed to achieve mission denial effects equivalent to those achievable against a concentrated, single-node architecture. The resilience benefit depends on how much mission capability remains available following the loss or degradation of specified nodes. A constellation that can satisfy defined minimum mission requirements through multiple combinations of surviving nodes generally requires an adversary to affect more assets or shared dependencies to achieve mission denial. GPS exemplifies this principle: a receiver generally uses signals from at least four healthy satellites with suitable geometry to determine three-dimensional position and time. Loss of one satellite does not ordinarily eliminate the service where sufficient healthy satellites remain visible; resilience to ground-system failures depends separately on the redundancy and distribution of the control segment. Distribution is a mission architecture decision that must be made early in the program lifecycle, as it fundamentally shapes spacecraft design, ground system architecture, launch strategy, and operational concepts. | CP-10(6) CP-11 CP-13 CP-2 CP-2(2) CP-2(3) CP-2(5) CP-2(6) PE-21 | D3-AI D3-NNI D3-SYSM D3-DEM D3-SVCDM D3-SYSVA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.29 A.5.29 | |
| CM0075 | Proliferated Constellations | Proliferated satellite constellations increase mission resilience by deploying a larger number of functionally equivalent satellites in similar orbits, expanding overall constellation capacity and raising the number of assets an adversary must successfully attack to achieve meaningful mission degradation. Unlike distribution, in which multiple satellites or payloads work together to provide a complete capability, proliferation increases the number of systems performing the same or substantially equivalent mission. Its resilience benefit is primarily derived from additional capacity and reduced dependence on any individual satellite rather than from architectural diversity. Proliferation also supports resilience through on-orbit spare maintenance, in which additional satellites are held in reserve or parked in accessible orbits to replace operational assets without requiring new launches. The cost implications of proliferation are significant and architecture-dependent. Designs optimized for repeatable production may achieve lower unit costs through learning and economies of scale, but those savings depend on design stability, production quantity, supplier capacity, and the amount of non-recurring change between production lots. The choice to proliferate must be made as a mission architecture decision early in the program, as it determines the spacecraft design philosophy, production strategy, launch architecture, and ground system scalability requirements. | CP-10(6) CP-11 CP-13 CP-2 CP-2(2) CP-2(3) CP-2(5) CP-2(6) PE-21 | D3-AI D3-NNI D3-SYSM D3-DEM D3-SVCDM D3-SYSVA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.29 A.5.29 | |
| CM0076 | Diversified Architectures | A diversified mission architecture provides a capability through multiple systems, platforms, payloads, orbital regimes, or domains to reduce the mission impact of losing any individual element and increase the range of adversary capabilities required to achieve mission denial. Diversification differs from proliferation in that it employs heterogeneous systems, potentially across different orbits, domains, operators, and technologies, rather than deploying more units of the same design. This heterogeneity imposes asymmetric costs on adversaries: attacking systems across different orbital regimes requires different physical and electronic capabilities for each regime, and kinetic attacks on space assets in diverse orbits carry differentiated collateral debris consequences that increase the political and economic cost of a broad attack campaign. Domain diversification, extending mission capability delivery across space, airborne, and terrestrial layers, further reduces adversary incentive by ensuring that defeating the space layer alone does not deny the end user the underlying capability. Diversification can preserve minimum mission capability following the loss of individual elements when the remaining systems provide sufficient coverage, capacity, interoperability, and operational availability to compensate for the loss. | CP-11 CP-13 CP-2 CP-2(2) CP-2(3) CP-2(5) CP-2(6) | D3-AI D3-NNI D3-SYSM D3-DEM D3-SVCDM D3-SYSVA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.29 A.5.29 | |
| CM0081 | Defensive Jamming and Spoofing | Defensive jamming and spoofing are active electronic countermeasures that may disrupt or deceive the terminal guidance sensors of an incoming kinetic anti-satellite weapon. When combined with evasive maneuvering, these measures may reduce the accuracy of the threat’s targeting solution and lower the probability of a successful intercept. Effectiveness depends on timely threat detection, knowledge of the relevant sensor characteristics, available transmit power and geometry, and the threat’s ability to recognize or overcome the countermeasure. Development, testing, and employment of these capabilities must occur only under applicable governmental authorization, spectrum authority, rules of engagement, and information-protection requirements. The design must limit unintended interference and account for effects on friendly, civil, and safety-related radio services. | CP-10(6) CP-13 CP-2 CP-2(1) CP-2(5) CP-2(7) PE-20 | D3-DO | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 A.5.29 A.5.10 | |
| 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) | D3-AH D3-EHPV D3-PSEP D3-PH D3-SCP | 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) | D3-PH D3-EI D3-NI D3-BA | 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 | |