| 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-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-95 |
The [spacecraft] shall enforce an attribute-based access control policy over subjects and objects as defined in AC-3(3).{SV-AC-1,SV-AC-4}{AC-3(13)}
|
Attribute-based access control (ABAC) enables dynamic, context-aware enforcement beyond static role assignments. This reduces privilege abuse and insider misuse by incorporating mission state, location, and environmental factors into decisions. ABAC supports least privilege while enabling operational flexibility. Proper enforcement limits lateral movement and unauthorized data access.
|
| 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-101 |
The [spacecraft] shall require multi-factor authorization for all updates to the task scheduling functionality within the spacecraft.{SV-AV-4}{AC-3(2)}
|
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-102 |
The [spacecraft] shall require multi-factor authorization for new and updates to on-board stored command sequences.{SV-IT-5}{AC-3(2)}
|
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-103 |
The [spacecraft] software subsystems 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.{SV-MA-3,SV-AV-7}{AC-3(2)}
|
When software is sole controller of a critical function, redundant and functionally independent command paths reduce systemic risk. A single vulnerability should not allow full compromise of a hazardous control. Diverse mechanisms increase resilience against common-mode failures. This supports both safety and cybersecurity assurance.
|
| SPR-104 |
The [spacecraft] software subsystems shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard.{SV-MA-3,SV-AV-7}{AC-3(2)}
|
Disabling fault tolerance creates a high-risk operational state. Requiring two independent and unique commands reduces likelihood of accidental or malicious deactivation. This prevents a single compromised control path from undermining redundancy. Hazard mitigation systems must not be easily bypassed.
|
| SPR-105 |
The [spacecraft] shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard.{AC-3(2),PE-10,SA-8(15)}
|
|
| 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-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-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-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-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-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-328 |
The [organization] shall ensure any update to on-board software, memory, or stored procedures has met high assurance standards before execution. {SV-SP-9,SV-SP-4}{AC-3(2),CM-3,SA-8(8),SA-8(31),SA-10(2),SR-4(4)}
|
On-orbit updates carry significant risk if not validated. High assurance standards prevent unauthorized or corrupted uploads from executing. Structured validation protects system integrity. Update governance reduces mission-ending configuration errors.
|
| SPR-343 |
The [organization] shall develop and document program-specific access control policies for controlling information flow and leakage on-board the spacecraft.{SV-AC-1,SV-CF-1,SV-CF-3}{AC-1,AC-3,AC-3(3),AC-3(4),AC-3(13)}
|
Access control policies must reflect mission architecture and threat environment. Formal documentation ensures consistent enforcement. Leakage prevention requires clear governance. Policy clarity supports compliance and auditing.
|
| SPR-356 |
The [organization] shall have a two-man rule to achieve a high level of security for systems with command level access to the spacecraft.(Under this rule all access and actions require the presence of two authorized people at all times.) {SV-AC-4}{PE-3}
|
Note: These are not spacecraft requirements but important to call out but likely are covered under other requirements by the customer.
|
| SPR-447 |
The [organization] shall have physical security controls to prevent unauthorized access to the systems that have the ability to command the spacecraft.{SV-AC-4}{PE-3}
|
Note: These are not spacecraft requirements but important to call out but likely are covered under other requirements by the customer.
|
| SPR-516 |
The [organization] shall define,and the [spacecraft] shall enforce,guardrails for any unauthenticated discovery beacons (if used), limiting content to non‑sensitive signals that cannot enable timing/key inference, preventing state change via those paths, narrowing content in safe mode, and validating behavior in simulators/flatsats.{SV-CF-2,SV-IT-1}{AC-4,AC-14}
|
Discovery mechanisms can leak sensitive timing or state information. Guardrails restrict beacon content to non-sensitive data. Controlled discovery reduces inference risk.
|
| SPR-525 |
The [organization] shall enforce least privilege and separation of duties for audit data (distinct roles for viewing, exporting, administering logs), apply heightened protections to sensitive categories (e.g., crypto operations), and provide break‑glass pathways with strong auditing.{SV-AC-4}{AC-6,AU-9,AU-9(5)}
|
Separation of duties prevents misuse of logs. Break-glass pathways preserve emergency access with oversight. Heightened protections reduce tampering risk. Structured governance strengthens trust.
|
| 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.
|