| SPR-1 |
The [spacecraft] shall implement a reference monitor mechanism that mediates access between subjects and objects based on a defined set of rules, that is designed and configured to resist tampering or unauthorized alteration, providing a reliable and secure foundation for access control within the information system.{SV-AC-1,SV-AC-4,SV-SP-7}{AC-25}
|
A reference monitor provides the foundational enforcement point for all access control decisions within the spacecraft. Without a tamper-resistant mediation layer, compromised flight software or malicious code could directly access critical memory, processes, or hardware interfaces. The mechanism must be isolated from modifiable flight software to preserve integrity under adversarial conditions.
|
| 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-3 |
The [spacecraft] shall enforce approved authorizations for controlling the flow of information within the platform and between interconnected systems so that information does not leave the platform boundary unless it is encrypted. Flow control shall be implemented in conjunction with protected processing domains, security‑policy filters with fully enumerated formats, and a default‑deny communications baseline.{SV-AC-6}{AC-3(3),AC-3(4),AC-4,AC-4(2),AC-4(6),AC-4(21),CA-3,CA-3(6),CA-3(7),CA-9,IA-9,SA-8(19),SC-8(1),SC-16(3)}
|
Spacecraft operate in constrained and deterministic environments where uncontrolled data flows can enable data exfiltration, cross-domain leakage, or lateral movement between subsystems. Enforcing approved authorizations with enumerated formats and a default-deny posture ensures only explicitly permitted communications occur. Encryption enforcement at platform boundaries prevents unauthorized disclosure of telemetry or state information.
|
| SPR-4 |
The [spacecraft] security implementation shall ensure that information should not be allowed to flow between partitioned applications unless explicitly permitted by the system.{SV-AC-6,SV-MA-3,SV-SP-7}{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-9,IA-9,SA-8(3),SA-8(18),SA-8(19),SC-2(2),SC-7(29),SC-16,SC-32}
|
Strict partitioning prevents compromise of one application from cascading into mission-critical subsystems. Many spacecraft attacks exploit flat architectures where subsystems implicitly trust one another. Explicit inter-partition authorization limits lateral movement and privilege escalation. This supports containment and fault isolation under both cyber and fault conditions.
|
| SPR-5 |
The [organization] shall state that information should not be allowed to flow between partitioned applications unless explicitly permitted by the Program's security policy.{SV-AC-6}{AC-4,AC-4(6)}
|
Technical enforcement must be anchored in formal policy to ensure consistency across development, integration, and operations. Codifying partition isolation requirements prevents mission creep and ad hoc exceptions that weaken domain separation. This establishes traceability between architecture design and security governance. It also ensures subcontractors and integrators apply consistent constraints.
|
| SPR-6 |
The [spacecraft] shall utilize automated mechanisms to protect sensitive information and detect and alert when sensitive information is accessed without satisfying defined criteria.{SV-DCO-1,SV-AC-1}{CM-12(1)}
|
Manual monitoring is insufficient in time-sensitive, communication-limited spacecraft environments. Automated detection of unauthorized access enables rapid identification of insider misuse, malicious code execution, or policy violations. This supports onboard intrusion detection and timely ground awareness. The mechanism should differentiate anomaly from normal operational variance.
|
| SPR-7 |
The [organization] shall document and design a security architecture using a defense-in-depth approach that allocates the [organization]s defined safeguards to the indicated locations and layers: [Examples include: operating system abstractions and hardware mechanisms to the separate processors in the platform, internal components, and the FSW].{SV-MA-6}{CA-9,PL-7,PL-8,PL-8(1),SA-8(3),SA-8(4),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30)}
|
Spacecraft security cannot rely on a single control; layered defenses reduce the likelihood of catastrophic compromise. Documenting safeguard allocation across hardware, OS, firmware, and FSW ensures coverage across attack surfaces. This supports resiliency against both cyber intrusion and supply chain weaknesses. Clear documentation enables verification and independent assessment.
|
| SPR-8 |
The [organization] shall ensure that the allocated security safeguards operate in a coordinated and mutually reinforcing manner.{SV-MA-6}{CA-7(5),PL-7,PL-8(1),SA-8(19)}
|
Independent controls that operate in isolation may create security gaps or conflicting behaviors. Coordinated safeguards ensure that encryption, authentication, partitioning, and monitoring functions reinforce each other rather than undermine availability or safety. This reduces bypass risk and improves fault/cyber response integration. Cohesive operation is essential for resilient mission assurance.
|
| SPR-9 |
The [organization] shall implement a security architecture and design that provides the required security functionality, allocates security controls among physical and logical components, and integrates individual security functions, mechanisms, and processes together to provide required security capabilities and a unified approach to protection.{SV-MA-6}{PL-7,SA-2,SA-8,SA-8(1),SA-8(2),SA-8(3),SA-8(4),SA-8(5),SA-8(6),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30),SC-32,SC-32(1)}
|
Security functionality must be intentionally distributed across physical and logical components rather than bolted on post-design. A unified architecture prevents inconsistent enforcement, duplicated controls, or unprotected interfaces. Integrated design reduces attack surface and improves verification of mission-critical protections.
|
| SPR-10 |
The [spacecraft] shall protect authenticator content from unauthorized disclosure and modification.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),IA-5,IA-5(6),RA-5(4),SA-8(18),SA-8(19),SC-28(3)}
|
Authenticators (keys, tokens, counters, certificates) are primary targets for persistent access attacks. Disclosure or modification enables command spoofing, replay, and privilege escalation. Protecting authenticator content preserves command integrity and prevents adversaries from maintaining covert control. Integrity protections must apply both at rest and in use.
|
| 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-12 |
The [spacecraft] encryption keys shall be restricted so that the onboard software is not able to access the information for key readout.{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(3)}
|
Even privileged software must not be able to retrieve plaintext keys. Preventing readout mitigates malware harvesting and insider misuse. Key usage should be mediated through cryptographic modules rather than direct exposure. This enforces least privilege at the cryptographic boundary.
|
| SPR-13 |
The [spacecraft] encryption keys shall be restricted so that they cannot be read via any telecommands.{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(3)}
|
Telecommand paths are high-value targets for adversarial exploitation. Allowing keys to be retrieved via command interfaces creates a catastrophic failure mode. This constraint prevents exfiltration even under partial compromise of command processing logic. It ensures encryption protections cannot be remotely dismantled.
|
| SPR-14 |
The [spacecraft] shall authenticate the ground station (and all commands) and other spacecraft before establishing remote connections using bidirectional authentication that is cryptographically based.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(2),AC-17(10),AC-18(1),AC-20,IA-3(1),IA-4,IA-4(9),IA-7,IA-9,SA-8(18),SA-8(19),SA-9(2),SC-7(11),SC-16(1),SC-16(2),SC-16(3),SC-23(3),SI-3(9)}
|
Authorization can include embedding opcodes in command strings, using trusted authentication protocols, identifying proper link characteristics such as emitter location, expected range of receive power, expected modulation, data rates, communication protocols, beamwidth, etc.; and tracking command counter increments against expected values.
|
| SPR-15 |
The [spacecraft] shall implement cryptographic mechanisms to identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters.{SV-AV-1,SV-IT-1}{AC-3,AC-20,SA-8(19),SC-8(1),SC-23(3),SC-40(3),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}
|
Adversaries may attempt imitative RF signals to inject commands or manipulate spacecraft behavior. Signal parameter validation (modulation, power, timing, waveform characteristics) strengthens command authentication beyond cryptographic validation alone. This helps mitigate spoofing, replay, and rogue emitter attacks. RF-layer validation complements cryptographic controls.
|
| SPR-16 |
The [spacecraft] shall ensure that processes reusing a shared system resource (e.g., registers, main memory, secondary storage) do not have access to information (including encrypted representations of information) previously stored in that resource after formal release, by clearing or zeroizing the resource prior to reuse.{SV-AC-6}{AC-3,PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(19),SC-4,SI-3}
|
Residual data in memory or registers can create covert channels or leakage paths between partitions. Zeroization prevents recovery of sensitive data by subsequent processes. This mitigates cross-domain leakage and memory scraping attacks. Clearing encrypted remnants is equally important to prevent cryptanalytic exploitation.
|
| 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-20 |
The [spacecraft] shall prevent use of a mode of operations where cryptography on the TT&C link can be disabled; encryption and authentication shall remain enabled even when automated access control mechanisms are overridden.{SV-AC-1,SV-CF-1,SV-CF-2}{AC-3(10),SA-8(18),SA-8(19),SC-16(2),SC-16(3),SC-40,SC-40(4)}
|
Emergency or override modes often become attack vectors if protections are weakened. Cryptography must remain enforced even during safe-mode or degraded operations. Removing encryption capability creates a single-point catastrophic exposure. Persistent protection ensures no operational shortcut undermines mission assurance.
|
| SPR-21 |
The [spacecraft], when transferring information between different security domains, shall implement security‑policy filters that require fully enumerated formats that restrict data structure and content.{SV-AC-6}{AC-3(3),AC-3(4),AC-4(14),IA-9,SA-8(19),SC-16,SI-10}
|
Fully enumerated formats prevent injection of malformed or malicious data across security domains. This reduces parser exploitation, data smuggling, and covert channel abuse. Strict domain filtering supports deterministic and auditable inter-domain communication. Only explicitly defined data structures should be permitted.
|
| SPR-22 |
The [spacecraft] shall implement boundary protections to separate bus, communications, and payload components supporting their respective functions.{SV-AC-6}{AC-3(3),AC-3(4),CA-9,SA-8(3),SA-8(14),SA-8(18),SA-8(19),SA-17(7),SC-2,SC-2(2),SC-7(13),SC-7(21),SC-7(29),SC-16(3),SC-32,SI-3,SI-4(13),SI-4(25)}
|
Flat architectures allow compromise of one subsystem to impact all others. Segregated boundaries reduce lateral movement and mission degradation. Isolation ensures payload compromise does not impact TT&C or bus control. This supports containment and survivability.
|
| SPR-23 |
The [spacecraft] shall isolate mission critical functionality from non-mission critical functionality.{SV-AC-6}{AC-3(3),AC-3(4),CA-9,SA-8(3),SA-8(19),SA-17(7),SC-2,SC-3,SC-3(4),SC-7(13),SC-7(29),SC-32,SC-32(1),SI-3,SI-7(10),SI-7(12)}
|
Non-critical functions often expand attack surface. Isolation prevents less-trusted components from affecting propulsion, attitude control, or power systems. This reduces cascading failure risk under compromise. Mission-critical systems must maintain operational continuity.
|
| SPR-24 |
The [spacecraft] data within partitioned applications shall not be read or modified by other applications/partitions.{SV-AC-6}{AC-3(3),AC-3(4),SA-8(19),SC-2(2),SC-4,SC-6,SC-32}
|
Application partitions must enforce strict read/write controls to prevent unauthorized state modification. Without this control, malicious code can alter mission parameters or falsify telemetry. Isolation protects integrity of subsystem data and prevents corruption propagation.
|
| SPR-25 |
The [spacecraft] shall prevent unauthorized access to system resources by employing an efficient capability based object model that supports both confinement and revocation of these capabilities when the platform security deems it necessary.{SV-AC-6}{AC-3(8),IA-4(9),PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(18),SA-8(19),SC-2(2),SC-4,SC-16,SC-32,SI-3}
|
Capability models restrict access to explicit, revocable tokens of authority. This enforces least privilege and supports dynamic revocation under threat conditions. Confinement reduces damage radius of compromised processes. Revocation capability enables adaptive cyber response.
|
| SPR-26 |
The [spacecraft] shall use protected processing domains to enforce the policy that information does not leave the platform boundary unless it is encrypted as a basis for flow‑control decisions and shall enumerate permitted inter‑domain flows and enforce domain‑gate checks on any domain switch. {SV-AC-6}{AC-4(2),IA-9,SA-8(19),SC-8(1),SC-16(3)}
|
Domain gates provide controlled transition points between security domains. Enumerated flows prevent unintentional data leakage and enforce encryption policies at boundaries. This mitigates cross-domain injection and exfiltration. Strong gate enforcement prevents privilege escalation during context switching.
|
| SPR-27 |
The [spacecraft] shall define the security functions and security-relevant information for which the system must protect from unauthorized access.{SV-MA-4,SV-MA-6}{AC-6(1),SA-8(19),SC-7(13),SC-16}
|
Clearly identifying security-relevant functions ensures protections are applied to the correct assets. Undefined security boundaries create ambiguity and inconsistent enforcement. Explicit definition supports verification, testing, and threat modeling. This forms the basis for risk-informed control allocation.
|
| SPR-28 |
The [spacecraft] shall provide the capability to enter the platform into a known good, operational cyber-safe mode from a tamper-resistant, configuration-controlled (“gold”) image that is authenticated as coming from an acceptable supplier, and has its integrity verified. The [spacecraft] shall refresh only from cryptographically authenticated [organization]-approved sources.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4(3),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-13,SI-17}
|
Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and SW functions to preattack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on available equipment still available after a cyberattack. The goal is for the vehicle to resume full mission operations. If not possible, a reduced level of mission capability should be achieved.
|
| SPR-29 |
The [spacecraft] shall enter cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-17}
|
|
| SPR-30 |
The [spacecraft] shall fail to a known secure state for failures during initialization, and aborts preserving information necessary to return to operations in failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(24),SC-24,SI-13,SI-17}
|
|
| SPR-31 |
The [spacecraft] shall fail securely to a secondary device in the event of an operational failure of a primary boundary protection device (i.e., crypto solution).{SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2}{CP-13,SA-8(19),SA-8(24),SC-7(18),SI-13,SI-13(4)}
|
If a primary boundary protection device fails, the spacecraft must not revert to insecure operation. Secure failover ensures continuity of confidentiality and integrity protections. This prevents adversaries from inducing failure states to bypass encryption. Redundancy strengthens mission resilience.
|
| SPR-32 |
The [spacecraft] shall provide or support the capability for recovery and reconstitution to a known state after a disruption, compromise, or failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-4(4),CP-10,CP-10(4),CP-10(6),CP-13,IR-4,IR-4(1),SA-8(16),SA-8(19),SA-8(24)}
|
|
| SPR-33 |
The [spacecraft] shall utilize TRANSEC. TRANSEC shall be implemented and verified as a distinct layer in coordination with Traffic Flow Security and RF anti‑fingerprinting.{SV-AV-1}{CP-8,RA-5(4),SA-8(18),SA-8(19),SC-8(1),SC-8(4),SC-16,SC-16(1),SC-16(2),SC-16(3),SC-40,SC-40(4)}
|
Transmission Security (TRANSEC) is used to ensure the availability of transmissions and limit intelligence collection from the transmissions. TRANSEC is secured through burst encoding, frequency hopping, or spread spectrum methods where the required pseudorandom sequence generation is controlled by a cryptographic algorithm and key. Such keys are known as transmission security keys (TSK). The objectives of transmission security are low probability of interception (LPI), low probability of detection (LPD), and antijam which means resistance to jamming (EPM or ECCM).
|
| SPR-34 |
The [spacecraft] shall recover to a known cyber-safe state when an anomaly is detected.{IR-4,IR-4(1),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17}
|
|
| SPR-35 |
The [spacecraft] shall perform an orderly, controlled system shut-down to a known cyber-safe state upon receipt of a termination command or condition.{PE-11,PE-11(1),SA-8(16),SA-8(19),SA-8(24),SI-17}
|
|
| SPR-36 |
The [spacecraft] shall operate securely in off-nominal power conditions, including loss of power and spurious power transients.{SV-AV-6,SV-MA-2}{PE-11,PE-11(1),SA-8(16),SA-8(19),SI-13,SI-17}
|
Power anomalies may induce undefined states exploitable by attackers. Cryptographic and security mechanisms must not degrade into insecure configurations during brownout or transient conditions. This mitigates fault-induced bypass attacks. Resilient operation preserves trust chain continuity.
|
| SPR-37 |
The [spacecraft] shall protect system components, associated data communications, and communication buses in accordance with: (i) national emissions and TEMPEST policies and procedures, and (ii) the security category or sensitivity of the transmitted information, and shall demonstrate compliance via pre‑launch TEMPEST‑like evaluation for co‑located payload configurations.{SV-CF-2,SV-MA-2}{PE-14,PE-19,PE-19(1),RA-5(4),SA-8(18),SA-8(19),SC-8(1)}
|
The measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements. The concerns addressed by this control during operation are emanations leakage between multiple payloads within a single space platform, and between payloads and the bus.
|
| SPR-38 |
The [spacecraft] shall be designed so that it protects itself from information leakage due to electromagnetic signals emanations.{SV-CF-2,SV-MA-2}{PE-19,PE-19(1),RA-5(4),SA-8(19)}
|
This requirement applies if system components are being designed to address EMSEC and the measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements.
|
| SPR-39 |
The [spacecraft] shall prevent unauthorized and unintended information transfer via shared system resources.{SV-AC-6}{PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(19),SC-2(2),SC-4}
|
Shared buses, memory, or peripherals can become covert channels. Controls must prevent unintended information propagation across shared infrastructure. This mitigates cross-partition leakage and data exfiltration. Shared resources must not undermine domain isolation.
|
| SPR-40 |
The [spacecraft] shall only use communication protocols that support encryption within the mission.{SV-AC-7,SV-CF-1,SV-CF-2}{SA-4(9),SA-8(18),SA-8(19),SC-40(4)}
|
Protocols lacking encryption create unavoidable exposure. Selecting encryption-capable protocols ensures confidentiality and integrity can be enforced mission-wide. This reduces risk from protocol downgrade attacks.
|
| SPR-41 |
The [spacecraft] shall maintain a separate execution domain for each executing process.{SV-AC-6}{SA-8(14),SA-8(19),SC-2(2),SC-7(21),SC-39,SI-3}
|
Process isolation prevents one compromised task from impacting others. Separate execution domains mitigate memory corruption and privilege escalation. This strengthens containment of malicious code. Deterministic isolation enhances both safety and cybersecurity.
|
| SPR-42 |
The [spacecraft] flight software shall not be able to tamper with the security policy or its enforcement mechanisms.{SV-AC-6}{SA-8(16),SA-8(19),SC-3,SC-7(13)}
|
Security enforcement must be independent of mission application logic. If FSW can alter policy, adversaries can disable protections post-compromise. This control preserves integrity of access controls and monitoring functions. Separation of enforcement from application reduces systemic risk.
|
| SPR-43 |
The [spacecraft] shall initialize the platform to a known safe state.{SA-8(19),SA-8(23),SA-8(24),SI-17}
|
|
| 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-45 |
The [spacecraft] shall implement cryptographic mechanisms that achieve protection against the effects of intentional electromagnetic interference; verification evidence for EMI/EPM shall be distinct from EMSEC/TEMPEST, anti‑jam/anti‑spoof protections, and EMP/HANE hardness.{SV-AV-1,SV-IT-1}{SA-8(19),SC-8(1),SC-40,SC-40(1)}
|
Intentional electromagnetic interference may attempt to induce predictable faults or bypass protections. Cryptographic resilience ensures corrupted transmissions are rejected. Verification must distinguish EMI/EPM resilience from TEMPEST and anti-jam protections. This ensures integrity under hostile RF environments.
|
| SPR-46 |
The [spacecraft] shall monitor [Program‑defined telemetry points] for malicious commanding attempts and alert ground operators upon detection.{SV-AC-2,SV-IT-1,SV-DCO-1}{AC-17,AC-17(1),AC-17(10),AU-3(1),RA-10,SC-7,SC-16,SC-16(2),SC-16(3),SI-3(8),SI-4,SI-4(1),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}
|
Telemetry-based detection enables identification of anomalous command patterns, replay attempts, and injection attacks. Early detection allows rapid containment before mission impact escalates. Onboard monitoring is critical when ground latency limits intervention. This supports proactive defense.
|
| SPR-47 |
The [spacecraft] shall implement relay and replay-resistant authentication mechanisms for establishing a remote connection.{SV-AC-1,SV-AC-2}{AC-3,IA-2(8),IA-2(9),SA-8(18),SC-8(1),SC-16(1),SC-16(2),SC-23(3),SC-40(4)}
|
Replay attacks can reuse valid command packets to manipulate spacecraft behavior. Freshness checks, nonces, and sequence enforcement prevent reuse of captured transmissions. Relay resistance mitigates man-in-the-middle exploitation. This protects command integrity over RF links.
|
| SPR-48 |
The [spacecraft] shall implement cryptographic mechanisms to protect the integrity of audit information and audit tools.{SV-DCO-1}{AU-9(3),RA-10,SC-8(1),SI-3,SI-3(10),SI-4(24)}
|
Audit logs are essential for attribution and forensic analysis. If adversaries can modify audit data, detection and recovery become unreliable. Cryptographic integrity protections preserve evidentiary value.
|
| SPR-49 |
The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with CNSSP 12 and applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{IA-7,SC-8(1),SC-13,SI-12}
|
|
| 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-51 |
The [spacecraft] shall implement cryptographic mechanisms to protect message externals unless otherwise protected by alternative physical safeguards.{SV-AC-7}{SC-8(3)}
|
Message externals (headers, routing data, metadata, protocol identifiers) can reveal operational state, enable traffic analysis, or be manipulated to redirect or replay communications. Cryptographic protection prevents adversaries from exploiting metadata to infer spacecraft posture or inject malicious traffic. Even if payload content is encrypted, unprotected externals can enable protocol exploitation or session hijacking. Physical safeguards alone are insufficient in contested RF environments.
|
| SPR-52 |
The [spacecraft] shall limit the generation and storage of sensitive/critical mission or system information. Generation shall be done on-demand where possible, and the information shall be deleted immediately when no longer needed.{SV-CF-3,SV-CF-1}{SI-21}
|
Reducing the amount and lifetime of sensitive data directly reduces attack surface and exfiltration risk. On-demand generation limits exposure windows and minimizes residual data available for compromise. Immediate deletion prevents recovery via memory scraping, shared resource reuse, or post-compromise forensic harvesting by an adversary. Data minimization is a foundational secure-by-design principle in resource-constrained spacecraft.
|
| SPR-54 |
The [spacecraft] shall retain the capability to update/upgrade operating systems while on-orbit.{SV-SP-7}{SA-4(5),SA-8(8),SA-8(31),SA-10(2),SI-3}
|
The operating system updates should be performed using multi-factor authorization and should only be performed when risk of compromise/exploitation of identified vulnerability outweighs the risk of not performing the update.
|
| SPR-64 |
The [spacecraft] shall detect and deny unauthorized outgoing communications posing a threat to the spacecraft.{SV-DCO-1}{IR-4,IR-4(1),RA-5(4),RA-10,SC-7(9),SC-7(10),SI-4,SI-4(1),SI-4(4),SI-4(7),SI-4(11),SI-4(13),SI-4(24),SI-4(25)}
|
Outbound communications may indicate data exfiltration, covert channels, or compromised subsystem behavior. Monitoring and blocking unauthorized egress prevents leakage of mission data or cryptographic material. Many attacks rely on command-and-control or data extraction channels; egress control disrupts this persistence mechanism. Outbound traffic should be as tightly controlled as inbound command paths.
|
| SPR-68 |
The [spacecraft] shall have on-board intrusion detection/prevention system that monitors the mission critical components or systems.{SV-AC-1,SV-AC-2,SV-MA-4}{RA-10,SC-7,SI-3,SI-3(8),SI-4,SI-4(1),SI-4(7),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}
|
The mission critical components or systems could be GNC/Attitude Control, C&DH, TT&C, Fault Management.
|
| 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-75 |
The [organization] shall define acceptable secure communication protocols available for use within the mission in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-AC-7}{SA-4(9)}
|
The secure communication protocol should include "strong" authenticated encryption characteristics.
|
| SPR-76 |
The [spacecraft] shall only use [organization]-defined communication protocols within the mission.{SV-AC-7}{SA-4(9)}
|
Restricting protocols prevents introduction of undocumented or insecure communication paths. Unapproved protocols may lack encryption, replay protection, or monitoring integration. Standardization reduces attack surface and simplifies validation. Controlled protocol selection strengthens supply chain and integration assurance.
|
| SPR-77 |
The [spacecraft] shall employ the principle of least privilege, allowing only authorized accesses processes which are necessary to accomplish assigned tasks in accordance with system functions.{SV-AC-6}{AC-3,AC-6,AC-6(9),CA-9,CM-5,CM-5(5),CM-5(6),SA-8(2),SA-8(5),SA-8(6),SA-8(14),SA-8(23),SA-17(7),SC-2,SC-7(29),SC-32,SC-32(1),SI-3}
|
Least privilege limits damage from compromised processes or insider misuse. Processes receive only the minimum access necessary for assigned functions. This reduces lateral movement and privilege escalation pathways. In deterministic spacecraft systems, privilege boundaries must be tightly defined and enforced.
|
| SPR-78 |
The [spacecraft] shall provide independent mission/cyber critical threads such that any one credible event will not corrupt another mission/cyber critical thread.{SV-AC-6,SV-MA-3,SV-SP-7}{SC-3,SC-32,SC-32(1),SI-3,SI-13}
|
Segregating mission-critical and cyber-critical execution paths prevents a single failure or compromise from corrupting other critical functions. Thread independence supports fault containment and resilience under attack. This ensures availability of essential functions even during partial compromise. Isolation strengthens both safety and cybersecurity.
|
| SPR-88 |
The [spacecraft] shall detect and recover from detected memory errors or transitions to a known cyber-safe state.{SV-IT-4,SV-AV-6}{IR-4,IR-4(1),SA-8(16),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17}
|
Memory corruption may result from radiation, fault injection, or malicious manipulation. Detection prevents silent data corruption from propagating to mission-critical functions. Recovery mechanisms or safe-state transitions preserve availability. Rapid containment supports mission survivability.
|
| SPR-93 |
The [spacecraft] shall require multi‑factor authorization for: (a) all spacecraft operating system and application updates; (b) updates to task‑scheduling functionality; and (c) creation or update of onboard stored command sequences.{SV-SP-9,SV-SP-11}{AC-3(2),CM-3(8),CM-5,IA-2,PM-12,SA-8(8),SA-8(31),SA-10(2),SI-3(8),SI-7(12),SI-10(6)}
|
The intent is for multiple checks to be performed prior to executing these SV SW updates. One action is mere act of uploading the SW to the spacecraft. Another action could be check of digital signature (ideal but not explicitly required) or hash or CRC or a checksum. Crypto boxes provide another level of authentication for all commands, including SW updates but ideally there is another factor outside of crypto to protect against FSW updates. Multi-factor authorization could be the "two-man rule" where procedures are in place to prevent a successful attack by a single actor (note: development activities that are subsequently subject to review or verification activities may already require collaborating attackers such that a "two-man rule" is not appropriate).
|
| SPR-96 |
The [spacecraft] shall uniquely identify and authenticate the ground station and other spacecraft before establishing a remote connection.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(10),AC-20,IA-3,IA-4,SA-8(18),SI-3(9)}
|
|
| SPR-97 |
All [spacecraft] commands which have unrecoverable consequence must have dual authentication prior to command execution. The [spacecraft] shall verify two independent cryptographic approvals prior to execution and shall generate an audit record binding both approver identifiers to the command identifier, time, and outcome.{SV-AC-4,SV-AC-8,SV-AC-2}{AU-9(5),IA-3,IA-4,IA-10,PE-3,PM-12,SA-8(15),SA-8(21),SC-16(2),SC-16(3),SI-3(8),SI-3(9),SI-4(13),SI-4(25),SI-7(12),SI-10(6),SI-13}
|
Commands with irreversible impact require heightened assurance to prevent catastrophic mission loss. Dual independent cryptographic approvals mitigate insider threat, key compromise, and single-point credential abuse. Binding approver identifiers to the audit trail strengthens accountability and deterrence. This reduces the probability of unauthorized hazardous command execution.
|
| SPR-98 |
The [spacecraft] shall have a method to ensure the integrity of which have unrecoverable consequence and validate their authenticity before execution.{SV-AC-2,SV-IT-2,SV-IT-1}{AU-9(5),IA-3,IA-4,IA-10,PE-3,PM-12,SA-8(15),SA-8(21),SC-16(2),SC-16(3),SI-3(8),SI-3(9),SI-4(13),SI-4(25),SI-7(12),SI-10(6),SI-13}
|
Hazardous commands must be cryptographically protected and validated prior to execution. Integrity and authenticity checks prevent replay, modification, or injection of destructive instructions. Without validation, RF interception or command path compromise could result in mission-ending actions. This ensures critical commands are both authorized and unaltered.
|
| SPR-100 |
The [spacecraft] shall monitor [Program defined telemetry points] for malicious commanding attempts.{SV-AC-1,SV-AC-2}{SC-7,AU-3(1),AC-17(1)}
|
Source from AEROSPACE REPORT NO. TOR-2019-02178
Vehicle Command Counter (VCC) - Counts received valid commands
Rejected Command Counter - Counts received invalid commands
Command Receiver On/Off Mode - Indicates times command receiver is accepting commands
Command Receivers Received Signal Strength - Analog measure of the amount of received RF energy at the receive frequency
Command Receiver Lock Modes - Indicates when command receiver has achieved lock on command signal
Telemetry Downlink Modes - Indicates when the satellite’s telemetry was transmitting
Cryptographic Modes - Indicates the operating modes of the various encrypted links
Received Commands - Log of all commands received and executed by the satellite
System Clock - Master onboard clock
GPS Ephemeris - Indicates satellite location derived from GPS Signals
|
| SPR-106 |
The [spacecraft] shall provide non-identical methods, or functionally independent methods, for commanding a mission critical function when the software is the sole control of that function.{AC-3(2),SI-3(8),SI-13}
|
|
| SPR-107 |
The [spacecraft] shall have multiple uplink paths {SV-AV-1}{CP-8,CP-11,SA-8(18),SC-5,SC-47}
|
Redundant uplink paths preserve command capability during jamming, interference, or subsystem failure. Availability is a core mission assurance objective. Diverse communication channels reduce single-point failure risk. This enhances resiliency in contested RF environments.
|
| SPR-116 |
The [organization] shall ensure reused TT&C software has adequate uniqueness for command decoders/dictionaries so that commands are received by only the intended satellite.{SV-SP-6}{AC-17(10),SC-16(3),SI-3(9)}
|
The goal is to eliminate risk that compromise of one command database does not affect a different one due to reuse. The intent is to ensure that one SV can not process the commands from another SV. Given the crypto setup with keys and VCC needing to match, this requirement may be inherently met as a result of using type-1 cryptography. The intent is not to recreate entire command dictionaries but have enough uniqueness in place that it prevents a SV from receiving a rogue command. As long as there is some uniqueness at the receiving end of the commands, that is adequate.
|
| SPR-117 |
The [spacecraft] shall provide the capability to restrict command lock based on geographic location of ground stations.{SV-AC-1}{AC-2(11),IA-10,SI-4(13),SI-4(25)}
|
This could be performed using command lockout based upon when the spacecraft is over selected regions. This should be configurable so that when conflicts arise, the Program can update. The goal is so the spacecraft won't accept a command when the spacecraft determines it is in a certain region.
|
| SPR-118 |
The [spacecraft] shall maintain the ability to encrypt & authenticate communications when conditions require automated access control mechanisms be overridden (e.g.no crypto-bypass mode).{AC-3(10)}
|
|
| SPR-119 |
The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards: [NSA- certified or approved cryptography for protection of classified information, FIPS-validated cryptography for the provision of hashing].{SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2,SV-AC-3}{IA-7,SC-13}
|
Use of NSA-certified or FIPS-validated cryptography ensures compliance with federal mandates and high-assurance algorithms. Standardized implementations reduce algorithmic weaknesses. Alignment with policy ensures interoperability and trustworthiness. Proper certification mitigates cryptographic implementation flaws.
|
| SPR-120 |
The [spacecraft] shall terminate the connection associated with a communications session at the end of the session or after 3 minutes of inactivity.{SV-AC-1}{AC-12,SA-8(18),SC-10,SC-23(1),SC-23(3),SI-14,SI-14(3)}
|
Persistent sessions increase exposure to hijacking and replay attacks. Automatic termination limits session lifetime and reduces unauthorized reuse. Idle timeout reduces attack surface in unattended conditions. Explicit closure supports session state integrity.
|
| SPR-121 |
The [organiztion] shall maintain the ability to establish communication with the spacecraft in the event of an anomaly to the primary receive path.{SV-AV-1,SV-IT-1}{CP-8,SA-8(18),SC-47}
|
Receiver communication can be established after an anomaly with such capabilities as multiple receive apertures, redundant paths within receivers, redundant receivers, omni apertures, fallback default command modes, and lower bit rates for contingency commanding, as examples
|
| SPR-122 |
The [spacecraft] shall produce, control, and distribute symmetric cryptographic keys using NSA Certified or Approved key management technology and processes per CNSSP 12. Private cryptographic keys shall be generated, stored, and rotated under [organization] control only and shall not be exposed to external service providers.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-9(6),SC-12,SC-12(1),SC-12(2),SC-12(3)}
|
Centralized and approved key management prevents unauthorized key generation or rotation. Protecting private keys from external service providers reduces supply chain risk. Controlled lifecycle management supports confidentiality and integrity. Strong governance reduces key compromise likelihood.
|
| SPR-123 |
The [organization] shall use NIST Approved for symmetric key management for Unclassified systems; NSA Approved or stronger symmetric key management technology for Classified systems.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(2)}
|
FIPS-complaint technology used by the Program shall include (but is not limited to) cryptographic key generation algorithms or key distribution techniques that are either a) specified in a FIPS, or b) adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS.
NSA-approved technology used for symmetric key management by the Program shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria.
|
| SPR-124 |
The [organization] shall use NSA approved key management technology and processes.NSA-approved technology used for asymmetric key management by The [organization] shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(3)}
|
Asymmetric keys underpin authentication and trust chains. Approved algorithms and processes ensure robustness against cryptanalytic attack. Formal evaluation criteria provide confidence in implementation strength. This protects digital signatures and secure exchange mechanisms.
|
| SPR-125 |
The [spacecraft] shall produce, control, and distribute asymmetric cryptographic keys. Private cryptographic keys shall be generated, stored, and rotated under [organization] control only and shall not be exposed to external service providers.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(3)}
|
In most cased the Program will leverage NSA-approved key management technology and processes.
|
| 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-127 |
The [spacecraft] shall be configured to deny communications by default and only permit authorized communications based on approved exceptions, establishing a default‑deny baseline with permitted flows whitelisted.{SV-AC-1,SV-IT-1}{SC-7(5),AC-4(2)}
|
Deny-by-default limits attack surface by permitting only explicitly authorized flows. Whitelisting prevents unexpected communications and covert channels. This reduces exploitation opportunities. Deterministic communication baselines simplify monitoring and anomaly detection.
|
| SPR-128 |
The [spacecraft] shall accept hazardous commands only when prerequisite checks are satisfied.{SV-AC-8,SV-AV-5}{AC-17(4),SI-10,SI-10(6)}
|
Precondition validation ensures hazardous commands are executed only under safe system states. This prevents execution under anomalous or compromised conditions. Independent verification reduces false activation risk. Safety and cyber controls must be integrated.
|
| SPR-129 |
The [spacecraft] shall restrict the use of information inputs to spacecraft and designated ground stations as defined in the applicable ICDs.{SV-AC-1,SV-AC-2}{AC-20,SC-23,SI-10,SI-10(5),SI-10(6)}
|
Limiting inputs to approved spacecraft and ground stations reduces spoofing and injection risk. ICD-defined boundaries prevent rogue sources from influencing control systems. This constrains trust relationships. Controlled input surfaces reduce attack vectors.
|
| SPR-130 |
The [spacecraft] shall discriminate between valid and invalid input into the software and rejects invalid input.{SV-SP-1,SV-IT-2}{SC-16(2),SI-3(8),SI-10,SI-10(3),SI-10(6)}
|
Input validation prevents buffer overflows, injection, and parser exploitation. Rejecting malformed or unexpected data reduces denial-of-service and corruption risks. Deterministic validation improves resilience. Robust input handling is fundamental to secure software.
|
| SPR-131 |
The [spacecraft] shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission.{SV-AC-2,SV-AV-4}{SC-16(2),SI-4(13),SI-4(25),SI-10,SI-10(6),SI-13}
|
Command sequencing enforces operational logic and safety interlocks. Out-of-sequence commands may bypass safeguards. Sequence enforcement prevents replay and control manipulation. This preserves control flow integrity.
|
| SPR-132 |
The [spacecraft] software subsystems shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied.{SV-MA-3,SV-AV-7}{SI-10}
|
|
| SPR-133 |
The [spacecraft] software subsystems shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission.{SV-MA-3,SV-AV-7}{SI-10}
|
|
| SPR-134 |
The [spacecraft] software subsystems shall perform prerequisite checks for the execution of hazardous commands.{SV-MA-3,SV-AV-7}{SI-10}
|
|
| SPR-135 |
The [organization] shall ensure that all viable commands are known to the mission and SV "owner.{SV-AC-8}{SI-10,SI-10(3)}
|
This is a concern for bus re-use. It is possible that the manufacturer left previously coded commands in their syntax rather than starting from a clean slate. This leaves potential backdoors and other functionality the mission does not know about.
|
| SPR-136 |
The [organization] shall perform analysis of critical (backdoor) commands that could adversely affect mission success if used maliciously.{SV-AC-8}{SI-10,SI-10(3)}
|
Heritage and commercial products often have many residual operational (e.g., hardware commands) and test capabilities that are unidentified or unknown to the end user, perhaps because they were not expressly stated mission requirements. These would never be tested and their effects unknown, and hence, could be used maliciously. Test commands not needed for flight should be deleted from the flight database.
|
| SPR-137 |
The [spacecraft] shall only use or include [organization]-defined critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted.{SV-AC-8}{SI-10,SI-10(3)}
|
The intent is protect against misuse of critical commands. On potential scenario is where you could use accounts with different privileges, could require an additional passphrase or require entry into a different state or append an additional footer to a critical command. There is room for design flexibility here that can still satisfy this requirement.
|
| SPR-138 |
The [spacecraft] software subsystems shall discriminate between valid and invalid input into the software and rejects invalid input.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)}
|
|
| SPR-139 |
The [spacecraft] software subsystems shall properly handle spurious input and missing data.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)}
|
|
| SPR-140 |
The [spacecraft] shall properly handle spurious input and missing data.{SV-SP-1,SV-AV-6}{SI-10,SI-10(3),SI-10(6)}
|
Spurious or missing data may indicate attack or fault conditions. Robust handling prevents cascading failures. Defensive programming ensures safe defaults and fallback states. This reduces exploitability of abnormal input conditions.
|
| SPR-141 |
The [spacecraft] shall perform prerequisite checks for the execution of hazardous commands.{SI-10,SI-10(6),SI-13}
|
|
| SPR-142 |
The [spacecraft] shall only use or include critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted.{SI-3(8),SI-10,SI-10(3)}
|
|
| SPR-143 |
The [spacecraft] software subsystems shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit or perform a hazardous action.{SV-MA-3,SV-AV-7}{SI-10(3)}
|
Independent parameter validation ensures command legitimacy from a secondary data source. This reduces risk of single-variable manipulation. Functional independence increases resilience. Hazardous actions require layered confirmation.
|
| SPR-144 |
The [spacecraft] shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit, or perform a hazardous action.{SV-AC-8,SV-MA-3}{SI-10(3),SI-10(6),SI-13}
|
Redundant validation mechanisms ensure hazardous transitions cannot occur through single-point compromise. Independent parameters strengthen control integrity. This reduces exploit paths for inhibit removal. Critical operations demand dual validation logic.
|
| SPR-145 |
The [spacecraft] mission/cyber critical commands shall be "complex" or diverse from other commands so that a single bit flip could not transform a benign command into a hazardous command.{SV-MA-3,SV-AV-7}{SI-10(5)}
|
Complex command encoding reduces risk of single-bit errors causing hazardous action. Diversity prevents accidental transformation into destructive instructions. This protects against radiation-induced bit flips and malicious bit manipulation. Safety and cyber resiliency intersect here.
|
| 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-147 |
The [spacecraft] software subsystems shall provide at least one independent command for each operator-initiated action used to shut down a function leading to or reducing the control of a hazard.{SV-MA-3,SV-AV-7}{SI-10(5)}
|
|
| 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-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-229 |
The [organization] shall protect documentation and Controlled Unclassified Information (CUI) as required, in accordance with the risk management strategy.{SV-CF-3,SV-SP-4,SV-SP-10}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-10,SC-8(1),SC-28(3),SI-12}
|
Documentation may reveal architecture details exploitable by adversaries. Proper handling prevents leakage. Protection of CUI supports regulatory compliance. Information governance complements technical controls.
|
| SPR-230 |
The [organization] shall identify and properly classify mission sensitive design/operations information and access control shall be applied in accordance with classification guides and applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-CF-3,SV-AV-5}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-8(19),SC-8(1),SC-28(3),SI-12}
|
* Mission sensitive information should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally these artifacts would be rated SECRET or higher and stored on classified networks. Mission sensitive information can typically include a wide range of candidate material: the functional and performance specifications, the RF ICDs, databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, SBU, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission.
|
| SPR-231 |
The [organization] shall distribute documentation to only personnel with defined roles and a need to know.{SV-CF-3,SV-AV-5}{CM-12,CP-2,SA-5,SA-10}
|
Least privilege and need to know should be employed with the protection of all documentation. Documentation can contain sensitive information that can aid in vulnerability discovery, detection, and exploitation. For example, command dictionaries for ground and space systems should be handles with extreme care. Additionally, design documents for missions contain many key elements that if compromised could aid in an attacker successfully exploiting the system.
|
| SPR-232 |
The [organization] shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design.{SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4}{CP-2,CP-2(8),PL-7,PM-11,PM-30(1),RA-3(1),RA-9,SA-8(9),SA-8(11),SA-8(25),SA-12,SA-14,SA-15(3),SC-7(29),SR-1}
|
During SCRM, criticality analysis will aid in determining supply chain risk. For mission critical functions/components, extra scrutiny must be applied to ensure supply chain is secured.
|
| SPR-233 |
The [organization] shall identify the applicable physical and environmental protection policies covering the development environment and spacecraft hardware. {SV-SP-4,SV-SP-5,SV-SP-10}{PE-1,PE-14,SA-3,SA-3(1),SA-10(3)}
|
Development environments must be protected from tampering. Physical controls prevent hardware supply chain compromise. Policy clarity ensures consistent safeguards. Secure development underpins secure deployment.
|
| SPR-234 |
The [organization] shall develop and document program-specific identification and authentication policies for accessing the development environment and spacecraft. {SV-SP-10,SV-AC-4}{AC-3,AC-14,IA-1,SA-3,SA-3(1)}
|
Strong authentication prevents unauthorized development access. Development compromise can introduce malicious code. Documented policies ensure consistent enforcement. Identity governance supports supply chain integrity.
|
| SPR-235 |
The [organization] shall ensure security requirements/configurations are placed in accordance with NIST 800-171 with enhancements in 800-172 on the development environments to prevent the compromise of source code from supply chain or information leakage perspective.{SV-SP-4,SV-SP-10,SV-CF-3}{AC-3,SA-3,SA-3(1),SA-15}
|
Supply chain threats target development environments. Enhanced controls reduce risk of source code exfiltration. Compliance strengthens contractual and regulatory assurance. Development security directly impacts spacecraft integrity.
|
| SPR-236 |
The [organization] shall implement a verifiable flaw remediation process into the developmental and operational configuration management process.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-5,SA-3,SA-3(1),SA-11,SI-3,SI-3(10)}
|
The verifiable process should also include a cross reference to mission objectives and impact statements. Understanding the flaws discovered and how they correlate to mission objectives will aid in prioritization.
|
| SPR-237 |
The [organization] shall establish robust procedures and technical methods to perform testing to include adversarial testing (i.e.abuse cases) of the platform hardware and software.{SV-SP-2,SV-SP-1}{CA-8,CP-4(5),RA-5,RA-5(1),RA-5(2),SA-3,SA-4(3),SA-11,SA-11(1),SA-11(2),SA-11(5),SA-11(7),SA-11(8),SA-15(7)}
|
Abuse-case testing reveals design weaknesses before deployment. Red-teaming strengthens defensive posture. Proactive validation reduces operational risk. Testing must simulate realistic threat scenarios.
|
| SPR-238 |
The [organization] shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)}
|
Select the particular subcontractors, software vendors, and manufacturers based on the criticality analysis performed for the Program Protection Plan and the criticality of the components that they supply. Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc.
|
| SPR-239 |
The [organization] shall approve, document, and control the use of operational data in preproduction environments (i.e., development, I&T, etc.).{SV-CF-3,SV-SP-10}{SA-3(2)}
|
Operational data in test environments increases exposure risk. Controlled handling prevents unintended leakage. Proper governance reduces insider and supply chain risk. Sensitive data must be protected at all lifecycle stages.
|
| SPR-240 |
The [organization] shall categorize/classify preproduction environments (i.e., development, I&T, etc.) at the same level as any operational data in use within the environment and protect the system consistent with its categorization/classification.{SV-SP-10,SV-SP-4}{SA-3(2)}
|
Development systems often become attack vectors. Equal classification ensures consistent safeguards. Protection must reflect data sensitivity. Weak dev security undermines operational integrity.
|
| SPR-241 |
The [organization] shall require the developer of the system, system component, or system services to identify organizational data that will be processed or stored on non-organizational systems.{SV-CF-3,SV-SP-6}{SA-4(12)}
|
Awareness of data location prevents uncontrolled exposure. Third-party systems may lack equivalent security. Explicit identification enables mitigation. Data governance strengthens risk management.
|
| SPR-242 |
The [organization] shall require the developer of the system, system component, or system services to remove all organizational data from contractor system(s) when no longer needed for development purposes or whenever instructed by the organization.{SV-CF-3}{SA-4(12),SI-21}
|
Residual data increases breach impact. Timely removal reduces exposure. Lifecycle data hygiene is critical. Controlled offboarding prevents persistence of sensitive information.
|
| SPR-243 |
The [organization] shall protect documentation and Essential Elements of Information (EEI) as required, in accordance with the risk management strategy.{SV-CF-3,SV-AV-5}{SA-5}
|
Essential Elements of Information (EEI):
|
| SPR-244 |
The [organization] shall define the secure communication protocols to be used within the mission in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-AC-7,SV-CF-1}{PL-7,RA-5(4),SA-4(9),SA-8(18),SA-8(19),SC-8(1),SC-16(3),SC-40(4),SI-12}
|
Standardized secure protocols reduce interoperability risk. Alignment with federal standards ensures validated cryptography. Defined protocols prevent ad hoc insecure implementations. Governance strengthens communication assurance.
|
| 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-246 |
The [organization] shall ensure that all Electrical, Electronic, Electro-mechanical & Electro-optical (EEEE) and mechanical piece parts procured from the Original Component Manufacturer (OCM) or their authorized distribution network.{SA-8(9),SA-8(11),SA-12,SA-12(1),SC-16(1),SR-1,SR-5}
|
|
| SPR-247 |
The [organization] shall develop policies and procedures to ensure proper care is taken when disposing of sensitive data, documentation, or system components throughout the entire mission lifecycle.{SV-CF-3,SV-SP-4}{SR-12}
|
Improper disposal may expose system details. Lifecycle security includes end-of-life handling. Secure destruction prevents reconstruction or reverse engineering. Governance extends beyond operations.
|
| SPR-248 |
The [organization] shall employ Operations Security (OPSEC) safeguards to protect supply chain-related information for the system, system components, or system services. {CP-2(8),PM-30,SA-12(9),SC-38,SR-7}
|
Supply chain information can reveal vulnerabilities. OPSEC reduces adversary intelligence gathering. Controlled disclosure minimizes targeting risk. Information discipline strengthens strategic defense.
|
| SPR-249 |
The [organization] shall employ [Program-defined Operations Security (OPSEC) safeguards] to protect supply chain-related information for the system, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CP-2(8),PM-30,SA-12(9),SC-38,SR-7}
|
OPSEC safeguards may include: (1) Limiting the disclosure of information needed to design, develop, test, produce, deliver, and support the element for example, supplier identities, supplier processes, potential suppliers, security requirements, design specifications, testing and evaluation result, and system/component configurations, including the use of direct shipping, blind buys, etc.; (2) Extending supply chain awareness, education, and training for suppliers, intermediate users, and end users; (3) Extending the range of OPSEC tactics, techniques, and procedures to potential suppliers, contracted suppliers, or sub-prime contractor tier of suppliers; and (4) Using centralized support and maintenance services to minimize direct interactions between end users and original suppliers.
|
| SPR-251 |
The [organization] shall maintain evidence of the execution of the security assessment plan and the results of the security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11}
|
Documented evidence provides traceability and accountability for security testing activities. Without retained artifacts, organizations cannot demonstrate due diligence or validate corrective actions. Preserved results support audits, mission reviews, and lessons learned. This strengthens governance and compliance posture.
|
| SPR-252 |
The [organization] shall create and implement a security assessment plan that includes: (1) The types of analyses, testing, evaluation, and reviews of all software and firmware components; (2) The degree of rigor to be applied to include abuse cases and/or penetration testing; and (3) The types of artifacts produced during those processes.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11,SA-11(5)}
|
The security assessment plan should include evaluation of mission objectives in relation to the security of the mission. Assessments should not only be control based but also functional based to ensure mission is resilient against failures of controls.
|
| SPR-254 |
The [organization] shall employ dynamic analysis (e.g.using simulation, penetration testing, fuzzing, etc.) to identify software/firmware weaknesses and vulnerabilities in developed and incorporated code (open source, commercial, or third-party developed code).{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-8,CM-10(1),RA-3(1),SA-11(5),SA-11(8),SA-11(9),SI-3,SI-7(10)}
|
Dynamic testing uncovers runtime vulnerabilities not visible through static review. Techniques such as fuzzing and penetration testing simulate realistic adversarial behavior. Runtime validation improves detection of memory corruption, logic flaws, and unsafe state transitions. This reduces latent vulnerabilities prior to deployment.
|
| SPR-255 |
The [organization] shall employ independent third-party analysis and penetration testing of all software (COTS, FOSS, Custom) associated with the system, system components, or system services.{SV-SP-1,SV-SP-3,SV-SP-6}{CA-2,CA-2(1),CA-8(1),CM-10(1),SA-9,SA-11(3),SA-12(11),SI-3,SI-3(10),SR-4(4),SR-6(1)}
|
Independent assessment reduces bias and uncovers blind spots in internal reviews. External testers provide objective validation of system resilience. Independent penetration testing strengthens confidence in defensive posture. Separation of duties enhances credibility and assurance.
|
| 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-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-264 |
The [organization] shall report counterfeit information system components to [organization] officials. {SV-SP-4}{IR-6,IR-6(2),PM-30,SA-19,SR-11}
|
Counterfeit components may contain malicious implants or reliability risks. Reporting ensures centralized tracking and mitigation. Early notification prevents systemic exposure. Hardware integrity underpins mission assurance.
|
| SPR-267 |
The [organization] shall perform software component analysis (a.k.a.origin analysis) for developed or acquired software.{SV-SP-4,SV-SP-6}{CM-10,CM-10(1),RA-3(1),RA-5,SA-15(7),SI-3,SI-3(10),SR-4(4)}
|
Origin analysis identifies embedded third-party libraries and dependencies. Transparency reduces supply chain opacity. Knowing component lineage enables targeted vulnerability tracking. This mitigates inherited risk.
|
| SPR-272 |
The [organization] shall perform static binary analysis of all firmware that is utilized on the spacecraft.{SV-SP-7,SV-SP-11}{RA-5,SA-10,SA-11,SI-7(10)}
|
Many commercial products/parts are utilized within the system and should be analyzed for security weaknesses. Blindly accepting the firmware is free of weakness is unacceptable for high assurance missions. The intent is to not blindly accept firmware from unknown sources and assume it is secure. This is meant to apply to firmware the vendors are not developing internally. In-house developed firmware should be going through the vendor's own testing program and have high assurance it is secure. When utilizing firmware from other sources, "expecting" does not meet this requirement. Each supplier needs to provide evidence to support that claim that their firmware they are getting is genuine and secure.
|
| SPR-277 |
In coordination with [organization], the [organization] shall prioritize and remediate flaws identified during security testing/evaluation.{SV-SP-1,SV-SP-3}{CA-2,CA-5,SA-11,SI-3,SI-3(10)}
|
Timely remediation reduces exploitation window. Coordination ensures mission continuity during patching. Documented prioritization demonstrates due diligence. Structured response enhances accountability.
|
| SPR-278 |
The [organization] shall correct flaws identified during security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11}
|
Flaws that impact the mission objectives should be prioritized.
|
| SPR-279 |
The [organization] shall perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Program-defined depth and coverage].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11}
|
The depth needs to include functional testing as well as negative/abuse testing.
|
| SPR-280 |
The [organization] shall require the developer of the system, system component, or system service to deliver the system, component, or service with [Program-defined security configurations] implemented.{SV-SP-1,SV-SP-9}{SA-4(5)}
|
For the spacecraft FSW, the defined security configuration could include to ensure the software does not contain a pre-defined list of Common Weakness Enumerations (CWEs)and/or CAT I/II Application STIGs.
|
| SPR-282 |
The [organization] shall use all-source intelligence analysis of suppliers and potential suppliers of the information system, system components, or system services to inform engineering, acquisition, and risk management decisions.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-16,PM-30,RA-2,RA-3(1),RA-3(2),RA-7,SA-9,SA-12(8),SR-5(2)}
|
* The Program should also consider sub suppliers and potential sub suppliers.
* All-source intelligence of suppliers that the organization may use includes: (1) Defense Intelligence Agency (DIA) Threat Assessment Center (TAC), the enterprise focal point for supplier threat assessments for the DOD acquisition community risks; (2) Other U.S. Government resources including: (a) Government Industry Data Exchange Program (GIDEP) – Database where government and industry can record issues with suppliers, including counterfeits; and (b) System for Award Management (SAM) – Database of companies that are barred from doing business with the US Government.
|
| SPR-283 |
The [organization] shall request threat analysis of suppliers of critical components and manage access to and control of threat analysis products containing U.S.person information.{SV-SP-3,SV-SP-4,SV-SP-11}{PM-16,PM-30(1),RA-3(1),SA-9,SA-12,SR-1}
|
The intent of this requirement is to address supply chain concerns on hardware and software vendors. Not required for trusted suppliers accredited to the Defense Microelectronic Activity (DMEA). If the Program intends to use a supplier not accredited by DMEA, the government customer should be notified as soon as possible. If the Program has internal processes to vet suppliers, it may meet this requirement. All software used and its origins must be included in the SBOM and be subjected to internal and Government vulnerability scans.
|
| SPR-284 |
The [organization] shall use all-source intelligence analysis on threats to mission critical capabilities and/or system components to inform risk management decisions.{SV-MA-4}{PM-16,RA-3(2),RA-3(3),RA-7,RA-9,SA-12(8),SA-15(8)}
|
Intelligence-informed risk management anticipates adversary capabilities. External threat awareness improves proactive defense. Integration into decision-making strengthens resilience. Threat-informed design reduces reactive posture.
|
| SPR-285 |
The [organization] risk assessment shall include the full end to end communication pathway (i.e., round trip) to include any crosslink communications.{SV-MA-4}{AC-20,AC-20(1),AC-20(3),RA-3,SA-8(18)}
|
Full pathway analysis prevents overlooking intermediate segments. Crosslinks may introduce lateral risk exposure. Round-trip evaluation strengthens confidentiality and integrity assurance. Holistic view reduces blind spots.
|
| SPR-286 |
The [organization] shall conduct an assessment of risk prior to each milestone review [SRR\PDR\CDR], including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the platform and the information it processes, stores, or transmits.{SV-MA-4}{RA-2,RA-3,SA-8(25)}
|
Major design decisions must reflect updated threat posture. Pre-milestone risk review prevents costly redesign. Structured evaluation supports informed governance. Early risk integration enhances mission confidence.
|
| SPR-287 |
The [organization] shall document risk assessment results in [risk assessment report].{SV-MA-4}{RA-3}
|
Formal documentation preserves rationale for decisions. Traceability enables future reassessment. Written records support compliance. Documentation strengthens transparency.
|
| SPR-288 |
The [organization] shall review risk assessment results [At least annually if not otherwise defined in formal organizational policy].{SV-MA-4}{RA-3}
|
Periodic review ensures evolving threats are considered. Regular reassessment prevents stagnation. Continuous evaluation supports adaptive defense. Governance must be iterative.
|
| SPR-289 |
The [organization] shall update the risk assessment [At least annually if not otherwise defined in formal institutional policy] or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the spacecraft.{SV-MA-4}{RA-3}
|
System modifications alter risk posture. Immediate reassessment ensures continued compliance. Responsive review strengthens mission assurance. Risk management must be dynamic.
|
| SPR-290 |
The [organization] shall document risk assessment results in risk assessment report upon completion of each risk assessment.{SV-MA-6}{RA-3,RA-7}
|
Formal documentation preserves rationale for decisions. Traceability enables future reassessment. Written records support compliance. Documentation strengthens transparency.
|
| SPR-291 |
The [organization] shall use the threat and vulnerability analyses of the as-built system, system components, or system services to inform and direct subsequent testing/evaluation of the as-built system, component, or service.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-3(3),SA-11(2),SA-15(8),SI-3}
|
Security analysis should guide test design. Threat-informed evaluation improves relevance. Feedback loops strengthen defensive posture. Analytical alignment enhances coverage.
|
| SPR-292 |
The [organization] shall ensure that role-based security-related training is provided to personnel with assigned security roles and responsibilities: (i) before authorizing access to the system or performing assigned duties; (ii) when required by system changes; and (iii) at least annually thereafter.{SV-AC-4}{AT-3,CP-2}
|
Personnel must understand role-specific responsibilities. Tailored training reduces misuse. Continuous reinforcement maintains awareness. Human factors are central to defense.
|
| SPR-293 |
The [organization] shall employ techniques to limit harm from potential adversaries identifying and targeting the [organization]s supply chain.{SV-SP-4,SV-SP-5,SV-SP-6}{CP-2,PM-30,SA-9,SA-12(5),SC-38,SR-3,SR-3(1),SR-3(2),SR-5(2)}
|
Adversaries often exploit supplier relationships. Protective measures reduce reconnaissance and manipulation. Supply chain resilience strengthens mission integrity. Proactive defense mitigates systemic exposure.
|
| SPR-294 |
The [organization] shall use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SA-15(8)}
|
|
| SPR-295 |
The [organization] shall perform and document threat and vulnerability analyses of the as-built system, system components, or system services.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SI-3}
|
Formal records preserve findings and mitigation strategies. Documentation supports lifecycle traceability. Transparent records enhance oversight. Governance requires evidence.
|
| SPR-296 |
The [organization] shall conduct an Attack Surface Analysis and reduce attack surfaces to a level that presents a low level of compromise by an attacker.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(6),SA-15(5)}
|
Reducing exposed interfaces lowers exploitation probability. Quantified surface reduction strengthens resilience. Structured assessment aligns design with mission risk tolerance. Minimization enhances defensive posture.
|
| SPR-297 |
The [organization] shall require the developer to conduct an attack surface analysis on the spacecraft architecture to identify and reduce attack surfaces to the lowest possible level that still permits the system to meet performance requirements/mission objectives.{SV-MA-6,SV-SP-1}{SA-11(6),SA-15(5)}
|
Embedding surface reduction into architecture strengthens foundational security. Early analysis prevents costly retrofits. Developer accountability ensures security by design. Integrated evaluation improves mission readiness.
|
| SPR-298 |
The [organization] shall require the developer to use threat modeling, attack surface analysis, and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable.{SV-MA-6,SV-SP-1}{SA-15(8)}
|
Threat modeling anticipates adversary tactics. Early design adaptation reduces vulnerability exposure. Learning from similar systems improves efficiency. Proactive analysis reduces downstream risk.
|
| SPR-299 |
The [organization] shall develop, document, and maintain under configuration control, a current baseline configuration of the spacecrafts.{SV-SP-9,SV-MA-6}{CM-2,CM-3(7),CM-4(2),CM-6,SA-8(30),SA-10}
|
Configuration control ensures traceability of hardware and software states. Unauthorized changes undermine security posture. Accurate baselines enable recovery and audit. Governance depends on configuration integrity.
|
| SPR-300 |
The [organization] shall maintain the integrity of the mapping between the master build data (hardware drawings and software/firmware code) describing the current version of hardware, software, and firmware and the on-site master copy of the data for the current version.{SV-SP-4,SV-SP-9}{CM-6,SA-8(21),SA-8(30),SA-10,SA-10(3),SA-10(4),SA-10(5),SI-7(10),SR-4(4)}
|
Build data linkage ensures reproducibility and traceability. Tampering detection depends on accurate mapping. Integrity of master copies prevents unauthorized modification. Configuration discipline supports resilience.
|
| SPR-301 |
The [organization] shall develop a security plan for the spacecraft.{SV-MA-6}{PL-2,PL-7,PM-1,SA-8(29),SA-8(30)}
|
A comprehensive security plan aligns controls with mission objectives. Clear articulation ensures consistent implementation. Planning integrates security into operations. Formal documentation strengthens accountability.
|
| SPR-302 |
The [organization] shall document the platform's security architecture, and how it is established within and is an integrated part of the overall [organization] mission security architecture.{SV-MA-6,SV-MA-4}{PL-7,SA-8(7),SA-8(13),SA-8(29),SA-8(30),SA-17}
|
Architecture documentation provides structural clarity. Integration into enterprise mission security ensures alignment. Clear documentation reduces misinterpretation. Transparency strengthens lifecycle governance.
|
| SPR-303 |
The [organization] shall protect the security plan from unauthorized disclosure and modification.{SV-MA-6}{AC-3,PL-2,PL-7}
|
Exposure of architecture details increases adversary advantage. Protecting documentation reduces reconnaissance risk. Controlled access ensures integrity. Governance must secure sensitive planning artifacts.
|
| SPR-304 |
The [organization] shall maintain a list of suppliers and potential suppliers used, and the products that they supply to include software.{SV-SP-3,SV-SP-4,SV-SP-11}{CM-10,PL-8(2),PM-30,SA-8(9),SA-8(11)}
|
Ideally you have diversification with suppliers
|
| SPR-305 |
The [organization] shall develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including support tamper resistance and provide a level of protection against the introduction of malicious code or hardware.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CM-3(8),CM-7(9),PM-30,SA-8(9),SA-8(11),SA-9,SA-10(3),SA-19,SC-51,SR-4(3),SR-4(4),SR-5(2),SR-11}
|
Counterfeit hardware may embed malicious implants. Formal policies reduce infiltration risk. Supplier verification strengthens trust. Hardware authenticity is foundational to cybersecurity.
|
| SPR-306 |
The [organization] shall conduct a supplier review prior to entering into a contractual agreement with a sub [organization] to acquire systems, system components, or system services.{SV-SP-4,SV-SP-6}{PM-30,PM-30(1),RA-3(1),SA-8(9),SA-8(11),SA-9,SA-12(2),SR-5(2),SR-6}
|
Pre-contract review ensures vendor security posture. Due diligence reduces third-party risk exposure. Structured evaluation strengthens procurement governance. Supplier trust must be verified.
|
| SPR-307 |
The [organization] shall maintain documentation tracing the strategies, tools, and methods implemented to mitigate supply chain risk .{SV-SP-3,SV-SP-4,SV-AV-7}{PM-30,RA-3(1),SA-12(1),SR-5}
|
Examples include: (1) Transferring a portion of the risk to the developer or supplier through the use of contract language and incentives; (2) Using contract language that requires the implementation of SCRM throughout the system lifecycle in applicable contracts and other acquisition and assistance instruments (grants, cooperative agreements, Cooperative Research and Development Agreements (CRADAs), and other transactions). Within the DOD some examples include: (a) Language outlined in the Defense Acquisition Guidebook section 13.13. Contracting; (b) Language requiring the use of protected mechanisms to deliver elements and data about elements, processes, and delivery mechanisms; (c) Language that articulates that requirements flow down supply chain tiers to sub-prime suppliers. (3) Incentives for suppliers that: (a) Implement required security safeguards and SCRM best practices; (b) Promote transparency into their organizational processes and security practices; (c) Provide additional vetting of the processes and security practices of subordinate suppliers, critical information system components, and services; and (d) Implement contract to reduce SC risk down the contract stack. (4) Gaining insight into supplier security practices; (5) Using contract language and incentives to enable more robust risk management later in the lifecycle; (6) Using a centralized intermediary or “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary;
|
| SPR-308 |
The [organization] shall protect against supply chain threats to the system, system components, or system services by employing security safeguards as defined by NIST SP 800-161 Rev.1.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-30,RA-3(1),SA-8(9),SA-8(11),SA-12,SI-3,SR-1}
|
The chosen supply chain safeguards should demonstrably support a comprehensive, defense-in-breadth information security strategy. Safeguards should include protections for both hardware and software. Program should define their critical components (HW & SW) and identify the supply chain protections, approach/posture/process.
|
| SPR-309 |
The [organization] shall identify the key system components or capabilities that require isolation through physical or logical means.{SV-AC-6}{AC-3,SC-3,SC-7(13),SC-28(3),SC-32,SC-32(1)}
|
Fault management and security management capabilities would be classified as mission critical and likely need separated. Additionally, capabilities like TT&C, C&DH, GNC might need separated as well.
|
| SPR-310 |
The [organization] shall use a certified environment to develop, code and test executable software (firmware or bit-stream) that will be programmed into a one-time programmable FPGA or be programmed into non-volatile memory (NVRAM) that the FPGA executes.{SA-8(9),SA-8(11),SA-12,SA-12(1),SC-51,SI-7(10),SR-1,SR-5}
|
|
| SPR-311 |
The [organization] shall ensure that all ASICs designed, developed, manufactured, packaged, and tested by suppliers with a Defense Microelectronics Activity (DMEA) Trust accreditation.{spacecraft-SP-5} {SV-SP-5}{SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5}
|
Trusted microelectronics reduce hardware supply chain risk. DMEA accreditation strengthens assurance. Hardware-level compromise prevention protects mission integrity. Secure fabrication underpins secure systems.
|
| SPR-312 |
If using the Government Microelectronics Assessment for Trust (GOMAT) framework outright, to perform ASIC and FPGA threat/vulnerability risk assessment, the following requirements would apply: {SV-SP-5}{SR-1,SR-5}
|
• 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened).
|
| SPR-313 |
The [organization] shall develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of organization-defined systems, system components, or system services.{SV-SP-4,SV-SP-5,SV-SP-6}{SR-2}
|
Structured SCRM planning identifies lifecycle risks. Comprehensive coverage ensures holistic oversight. Risk planning mitigates systemic exposure. Governance extends beyond deployment.
|
| SPR-314 |
The [organization] shall protect the supply chain risk management plan from unauthorized disclosure and modification.{SV-SP-4}{SR-2}
|
Disclosure of SCRM strategy may expose defensive weaknesses. Controlled access preserves operational advantage. Plan integrity prevents tampering. Governance artifacts must be secured.
|
| SPR-315 |
The [organization] shall review and update the supply chain risk management plan as required, to address threats, organizational, or environmental changes.{SV-SP-4}{SR-2}
|
Threat landscapes evolve rapidly. Periodic updates maintain relevance. Adaptive management strengthens resilience. Continuous improvement is essential.
|
| SPR-316 |
The [organization] shall establish a supply chain risk management team to lead and support supply chain risk management activities.{SV-SP-4}{SR-2(1)}
|
Dedicated oversight ensures coordinated supply chain defense. Defined roles improve accountability. Central leadership streamlines mitigation efforts. Organizational focus strengthens resilience.
|
| SPR-317 |
The [organization] shall employ [organization]-defined techniques to limit harm from potential adversaries identifying and targeting the Program supply chain.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-3(2),SC-38}
|
Examples of security safeguards that the organization should consider implementing to limit the harm from potential adversaries targeting the organizational supply chain, are: (1) Using trusted physical delivery mechanisms that do not permit access to the element during delivery (ship via a protected carrier, use cleared/official couriers, or a diplomatic pouch); (2) Using trusted electronic delivery of products and services (require downloading from approved, verification-enhanced sites); (3) Avoiding the purchase of custom configurations, where feasible; (4) Using procurement carve outs (i.e., exclusions to commitments or obligations), where feasible; (5) Using defensive design approaches; (6) Employing system OPSEC principles; (7) Employing a diverse set of suppliers; (8) Employing approved vendor lists with standing reputations in industry; (9) Using a centralized intermediary and “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary Employing inventory management policies and processes; (10) Using flexible agreements during each acquisition and procurement phase so that it is possible to meet emerging needs or requirements to address supply chain risk without requiring complete revision or re-competition of an acquisition or procurement; (11) Using international, national, commercial or government standards to increase potential supply base; (12) Limiting the disclosure of information that can become publicly available; and (13) Minimizing the time between purchase decisions and required delivery.
|
| SPR-318 |
The [organization] shall ensure that the controls included in prime contracts are also included in the contracts of subcontractors.{SV-SP-4,SV-SP-6}{SR-3(3)}
|
Security gaps in subcontractors create systemic vulnerabilities. Flow-down requirements enforce consistent standards. Contractual alignment strengthens supply chain assurance. Uniform governance reduces weak links.
|
| SPR-319 |
The [organization] shall ensure adequate supplies of critical system components.{SV-AV-7}{SR-5(1)}
|
Examples include: using multiple suppliers throughout the supply chain for critical components, stockpiling spare components to ensure operation during mission-critical times, and the identification of functionally identical or similar components that may be used, if necessary.
|
| 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-387 |
The [organization] shall define policy and procedures to ensure that the developed or delivered systems do not embed unencrypted static authenticators in applications, access scripts, configuration files, nor store unencrypted static authenticators on function keys.{SV-AC-1,SV-AC-3}{IA-5(7)}
|
Hard-coded or static authenticators create high-value targets for reverse engineering and credential reuse. Preventing embedded unencrypted credentials reduces insider and supply chain exploitation risk. Credential hygiene is critical in long-lived space missions. Eliminating static secrets strengthens identity assurance.
|
| SPR-388 |
The [organization] shall produce, control, and distribute asymmetric cryptographic keys (where applicable) using NSA Certified or Approved key management technology and processes per CNSSP 12.{SV-AC-3,SV-AC-7}{SC-12(3)}
|
Using NSA-certified key management ensures cryptographic integrity and compliance with federal mandates. Proper generation, distribution, and control reduce key compromise risk. High-assurance key lifecycle management underpins command authentication and secure updates. Governance over keys preserves mission trust.
|
| SPR-389 |
The [organization] shall perform analysis of critical backdoor commands that could adversely affect mission success if used maliciously.{SV-AC-8}{SI-10,SI-10(3)}
|
Backdoor or maintenance commands may bypass safeguards if misused. Analysis identifies high-impact commands requiring additional controls. Understanding abuse potential reduces catastrophic misuse. Preventive governance strengthens operational assurance.
|
| SPR-435 |
For FPGA pre-silicon artifacts that are developed, coded, and tested by a developer that is not accredited, the [organization] shall be subjected to a development environment and pre-silicon artifacts risk assessment by [organization]. Based on the results of the risk assessment, the [organization] may need to implement protective measures or other processes to ensure the integrity of the FPGA pre-silicon artifacts.{SV-SP-5}{SA-3,SA-3(1),SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5}
|
DOD-I-5200.44 requires the following:
4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened).
|
| SPR-436 |
The [organization] shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)}
|
Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc.
|
| SPR-438 |
Any EEEE or mechanical piece parts that cannot be procured from the OCM or their authorized distribution network shall be approved and the government program office notified to prevent and detect counterfeit and fraudulent parts and materials.{SV-SP-5}{SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5}
|
The Program, working with the contractors, shall identify which ASICs/FPGAs perform or execute an integral part of mission critical functions and if the supplier is accredited “Trusted” by DMEA. If the contractor is not accredited by DMEA, then the Program may apply various of the below ASIC/FPGA assurance requirements to the contractor, and the Program may need to perform a risk assessment of the contractor’s design environment.
|
| SPR-439 |
For ASICs that are designed, developed, manufactured, packaged, or tested by a supplier that is not DMEA accredited, the ASIC development shall undergo a threat/vulnerability risk assessment. Based on the results of the risk assessment, the [organization] may need to implement protective measures or other processes to ensure the integrity of the ASIC.{SV-SP-5}{SA-8(9),SA-8(11),SA-8(21),SA-12,SA-12(1),SR-1,SR-4(4),SR-5}
|
DOD-I-5200.44 requires the following:
4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened).
|
| SPR-440 |
Any EEEE or mechanical piece parts that cannot be procured from the OCM or their authorized franchised distribution network shall be approved by the [organization]’s Parts, Materials and Processes Control Board (PMPCB) as well as the government program office to prevent and detect counterfeit and fraudulent parts and materials.{SV-SP-5}{SR-1,SR-5}
|
The Program, working with the contractors, shall identify which ASICs/FPGAs perform or execute an integral part of mission critical functions and if the supplier is accredited “Trusted” by DMEA. If the contractor is not accredited by DMEA, then the Program may apply various of the below ASIC/FPGA assurance requirements to the contractor, and the Program may need to perform a risk assessment of the contractor’s design environment.
|
| SPR-441 |
For ASICs that are designed, developed, manufactured, packaged, or tested by a supplier that is NOT DMEA accredited Trusted, the ASIC development shall undergo a threat/vulnerability risk assessment.The assessment shall use Aerospace security guidance and requirements tailored from TOR-2019-00506 Vol.2, and TOR-2019-02543 ASIC and FPGA Risk Assessment Process and Checklist.Based on the results of the risk assessment, the Program may require the developer to implement protective measures or other processes to ensure the integrity of the ASIC.{SV-SP-5}{SR-1,SR-5}
|
DOD-I-5200.44 requires the following:
4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened).
|
| SPR-442 |
For FPGA pre-silicon artifacts that are developed, coded, and tested by a developer that is NOT DMEA accredited Trusted, the contractor/developer shall be subjected to a development environment and pre-silicon artifacts risk assessment by the Program.The assessment shall use Aerospace security guidance and requirements in TOR-2019-00506 Vol.2, and TOR-2019-02543 ASIC and FPGA Risk Assessment Process and Checklist.Based on the results of the risk assessment, the Program may require the developer to implement protective measures or other processes to ensure the integrity of the FPGA pre-silicon artifacts.{SV-SP-5}{SR-1,SR-5}
|
DOD-I-5200.44 requires the following:
4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened).
|
| SPR-443 |
The [organization] shall ensure that the contractors/developers have all ASICs designed, developed, manufactured, packaged, and tested by suppliers with a Defense Microelectronics Activity (DMEA) Trust accreditation.{SV-SP-5}{SR-1,SR-5}
|
|
| SPR-444 |
The [organization] shall ensure that the contractors/developers have all EEEE, and mechanical piece parts procured from the Original Component Manufacturer (OCM) or their authorized franchised distribution network.{SV-SP-5}{SR-1,SR-5}
|
These requirements might only make sense for ASIC/FPGA that are deemed to support mission critical functions. The Program has the responsibility to identify all ASICs and FPGAs that are used in all flight hardware by each hardware element. This list must include all contractor and subcontractor usage of ASICs and FPGAs.
|
| SPR-445 |
The [organization] shall use a DMEA certified environment to develop, code and test executable software (firmware or bit-stream) that will be programmed into a one-time programmable FPGA or be programmed into non-volatile memory (NVRAM) that the FPGA executes.{SV-SP-5}{SR-1,SR-5}
|
DOD-I-5200.44 requires the following:
4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened).
|
| SPR-453 |
The [spacecraft] shall restrict any override of access control mechanisms to [Program-defined emergency conditions] and shall generate an auditable event for each invocation that includes the time, origin, justification code, affected functions, and exit status.{SV-AC-4}{AC-3,AC-3(10),AU-2,AU-3}
|
Overrides introduce risk and must be tightly constrained. Auditable invocation ensures accountability. Time-limited emergency use reduces misuse potential. Structured control preserves integrity.
|
| SPR-454 |
The [spacecraft] shall tag telemetry and logs produced during override and shall automatically restore standard enforcement when exit conditions are met or after [Program-defined timeout].{SV-AC-4,SV-DCO-1}{AC-3(10),AU-3,AU-12}
|
Override transparency ensures operators are aware of elevated state. Automatic restoration prevents lingering weakened posture. Structured tagging supports audit and review. Governance reduces accidental persistence.
|
| 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-457 |
The [spacecraft] shall verify cryptographic integrity and origin of data at each relay hop before forwarding information between internal components, payloads, crosslinks, and ground.{SV-IT-1,SV-IT-2,SV-AC-3}{CA-3(7),SC-8(1),SC-13,SC-23}
|
End-to-end security alone is insufficient in multi-hop spacecraft architectures. Verifying integrity and origin at each relay prevents compromised subsystems from forwarding malicious data laterally. Hop-by-hop validation limits propagation of injected commands or payload tampering. This enforces zero-trust principles internally.
|
| SPR-464 |
The [spacecraft] shall accept command and telemetry sessions from [organization]-authorized alternate ground or relay providers only when presented with valid cryptographic credentials and whitelisted link characteristics.{SV-IT-1,SV-AC-4,SV-MA-7}{AC-17,SC-23}
|
Accepting sessions only from authorized, cryptographically verified providers prevents rogue ground station compromise. Whitelisted link characteristics reduce spoofing risk. Strict admission control strengthens link-layer assurance. This supports TRANSEC alignment.
|
| SPR-466 |
The [spacecraft] shall support rapid rollover of communications credentials to restore secure operations with an alternate provider.{SV-AC-3}{SC-12,IA-5}
|
Credential compromise requires immediate remediation capability. Rapid rollover restores secure communications without prolonged outage. Agility prevents mission interruption. Cryptographic agility is foundational to resilience.
|
| SPR-472 |
The [organization] shall define mission and business processes that map mission objectives to space-segment security requirements, including safe-mode criteria, secure uplink and downlink obligations, and recovery procedures, and shall baseline these processes under configuration control.{SV-MA-6,SV-AV-5}{PM-11,PL-2,CM-2}
|
Security must align with mission objectives. Explicit mapping ensures safe-mode criteria and communication obligations are controlled. Baseline governance prevents undocumented deviations. Integration supports mission assurance.
|
| SPR-476 |
The [organization] shall identify suppliers of mission-critical or mission-essential items and apply enhanced oversight that includes security practice vetting, contract language mandating secure manufacturing, and periodic compliance audits.{SV-SP-4,SV-SP-5}{PM-30(1),SR-6,SR-3}
|
Mission-critical suppliers require elevated scrutiny. Contractual language enforces security standards. Periodic audits reduce supply chain risk. Oversight strengthens systemic assurance.
|
| SPR-477 |
The [organization] shall require independent testing and inspection of mission-critical components prior to integration to verify hardware integrity and cryptographic module assurance.{SV-SP-5,SV-AC-3}{PM-30(1),SR-11}
|
Third-party validation reduces conflict-of-interest risk. Independent inspection verifies hardware integrity and cryptographic assurance. External attestation strengthens confidence. Verification supports mission-critical trust.
|
| SPR-478 |
The [organization] shall map supplier failure impact to mission functions and assign risk-based oversight and acceptance criteria.{SV-SP-4,SV-MA-6}{PM-30(1),SR-2,RA-3}
|
Understanding supplier failure impact informs oversight priority. Risk-based criteria ensure proportional governance. Structured assessment prevents blind spots. Supply chain risk alignment strengthens mission resilience.
|
| SPR-479 |
The [organization] shall define, baseline, and maintain the purposing of the space platform and link segment, including intended objectives, authorized capabilities, prohibited functions, and operational constraints, and shall use this baseline to bound requirements, updates, and on-orbit operations.{SV-AC-8,SV-MA-6}{PM-32,PL-8}
|
Defining authorized and prohibited functions prevents scope creep. Clear purposing bounds updates and operational use. Governance limits misuse potential. Structured baseline supports disciplined operations.
|
| SPR-481 |
The [organization] shall define and document data ownership for mission data types across the space platform and link segment, including authority over classification, storage, retention, distribution, cross-domain transfer, and decommissioning.{SV-CF-3}{SA-4(12)}
|
Clear authority over mission data reduces ambiguity. Defined classification and retention policies prevent mishandling. Ownership governance strengthens accountability. Structured control supports compliance.
|
| SPR-489 |
The [spacecraft] shall host privileged functions, including flight control and cryptographic key management, in physically separate processing domains that have no direct data bus connectivity to non privileged domains. {SV-AC-6,SV-AC-3}{SC-3,SC-32(1),SC-39}
|
Hardware-level separation prevents software bypass. Isolation protects flight control and key management. Physical boundaries strengthen trust. Segmentation enforces zero-trust architecture.
|
| SPR-490 |
The [spacecraft] shall ensure cross domain exchanges occur only through [organization] defined, verified guards that enforce format, rate, and content checks.{SV-AC-6,SV-IT-2}{AC-4,SC-7,SC-32(1)}
|
Verified guards ensure controlled data exchange. Format and rate checks prevent covert channel exploitation. Enforced mediation supports mandatory control. Guarded exchange strengthens isolation.
|
| 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-509 |
The [organization] shall procure flight items only from an AO-approved vetted supplier whitelist; off-list buys require documented risk acceptance and compensating pedigree/scanning.{SV-SP-4}{SR-4(4),SR-3,SR-5}
|
Restricting procurement to vetted suppliers reduces counterfeit and tampering risk. Off-list acquisitions require formal risk acceptance, preserving governance. Structured sourcing strengthens trust anchors. Controlled procurement reduces systemic exposure.
|
| SPR-517 |
The [organization] shall correlate station/operator session activity with pass schedules and spacecraft mode, alert on off‑schedule access and command families invalid for the current mode, and retain results as audit evidence.{SV-AC-4,SV-AC-1,SV-AV-4}{AC-17,AC-17(1),SI-4,AU-6}
|
Off-schedule or mode-inconsistent commands signal compromise. Correlation across dimensions strengthens anomaly detection. Audit retention supports post-event review. Context validation strengthens mission assurance.
|
| SPR-518 |
The [organization] shall require external stations/relays to complete an onboarding certification demonstrating operator/facility vetting, key custody and revocation practices, RF configuration discipline, time synchronization, and adherence to pass scheduling and emergency procedures, with periodic re‑certification.{SV-MA-7,SV-AC-4}{AC-17,AC-20,AC-20(1),SR-6}
|
Relay and partner stations expand trust boundaries. Certification ensures consistent security practices. Periodic re-validation prevents drift. External governance strengthens link integrity.
|
| SPR-530 |
The [spacecraft] shall enable selected maintenance capabilities only within time‑bounded and mode‑bounded windows, audit enable/disable events, auto‑revert on timeout/reset, and expose enabled/disabled capability state in telemetry.{SV-AC-8,SV-AC-4}{CM-7,CM-7(2),SA-8,SA-8(14),AC-3}
|
Maintenance capabilities expand risk surface. Time-limited activation reduces abuse window. Telemetry exposure ensures oversight. Auto-revert strengthens containment.
|
| SPR-533 |
The [spacecraft] and [organization] shall adapt identification and authorization based on mission context (e.g., anomaly response, unscheduled contact, safe mode) by tightening factors/keys, narrowing station whitelists, and enforcing geo/time and mode constraints, with telemetry cues and reversion to baseline.{SV-AC-4,SV-AC-1}{IA-1,IA-5,IA-10}
|
Threat posture varies by mission state. Adaptive controls tighten during anomalies. Telemetry cues ensure transparency. Contextual enforcement supports Zero Trust maturity.
|
| SPR-537 |
The [organization] shall define event‑driven triggers for rapid risk reassessment (e.g., new images/bitstreams, key rotations, partner‑station onboarding, notable anomalies, vendor advisories) and rehearse fast‑turn evaluations in a twin/flatsat to drive decisions within one or two passes.{SV-SP-6,SV-SP-9}{RA-3,RA-3(1),CA-7}
|
Triggers ensure timely re-evaluation after impactful events. Flatsat rehearsal validates mitigation feasibility. Rapid cycles align with limited contact windows. Structured agility strengthens mission defense.
|
| SPR-538 |
The [spacecraft] shall budget CPU/power/memory for security functions (crypto, logging, verification), implement graceful degradation (e.g., summarize logs, throttle verification) that preserves TT&C and safing, and expose telemetry showing throttling decisions and residual capacity.{SV-AV-1,SV-DCO-1}{PE-9,SA-8(8),SC-6,CP-2}
|
Security must not starve essential TT&C. Explicit resource budgeting ensures sustained enforcement. Graceful degradation preserves mission priority. Telemetry visibility supports oversight.
|
| SPR-540 |
The [spacecraft] shall employ deterministic scheduling where feasible and bound retries/timeouts on command/telemetry paths by mode, exposing retry counters, backoff state, and finite‑state transitions in telemetry with consistent error/reject reason codes.{SV-IT-4,SV-AV-1}{SA-8(12),SI-10(3),SI-13}
|
Determinism prevents runaway retries or timing exploitation. Exposed counters support diagnosis. Finite-state transitions strengthen transparency. Predictable behavior improves assurance.
|
| SPR-541 |
The [spacecraft] shall provide a trusted path for sensitive actions (e.g., key management, image activation) with strengthened authentication/integrity checks, narrow interfaces, and explicit telemetry cues (trusted‑path active, preconditions satisfied); operations shall confirm trusted‑path use before proceeding.{SV-AC-1,SV-SP-9}{SA-8(13),SC-11,SC-12}
|
Narrow interfaces reduce attack vectors. Explicit trusted-path indicators prevent misuse. Strengthened authentication protects critical operations. Procedural confirmation ensures compliance.
|
| 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-544 |
The [spacecraft] shall close sessions at LOS, invalidate per‑session tokens/nonces, and safely pause queued procedures with no partial side effects, supporting resumable execution at next AOS with explicit telemetry of residual stacks and state.{SV-AC-2}{AC-12,SC-10,IA-5}
|
Session invalidation prevents replay or token reuse. Safe pausing prevents partial side effects. Resumable logic supports orbital realities. Session discipline strengthens security.
|
| SPR-551 |
The [organization] shall ensure end‑of‑life sanitization or destruction of boards/media that stored cryptographic material or mission data, render on‑orbit cryptographic material unrecoverable at decommissioning, and retain records proving disposal actions.{SV-SP-4}{SR-12,MP-6}
|
Residual crypto material poses long-term risk. Verified destruction prevents reuse or recovery. Documented disposal supports compliance. Lifecycle closure strengthens mission assurance.
|