Attempting access to an access-controlled system resulting in unauthorized access
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-348 | The [organization] shall establish policy and procedures to prevent unauthorized personnel from masquerading as personnel with valid access to areas where commanding of the spacecraft is possible.{SV-AC-4,SV-AC-1}{PM-12} | Unauthorized impersonation risks mission compromise. Physical and logical controls prevent access misuse. Clear policy deters credential abuse. Identity assurance is essential for command authority. |
| SPR-353 | The [organization] shall, upon termination of individual employment, terminates/revokes any authenticators/credentials associated with the individual.{SV-AC-4,SV-AC-1}{PS-4} | Immediate revocation prevents credential reuse. Deprovisioning reduces exposure window. Controlled offboarding supports lifecycle security. Identity lifecycle management is critical. |
| 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-410 | The [organization] shall define, document, and approve access restrictions associated with changes to the spacecraft.{SV-AC-1,SV-AC-4}{CM-5} | Changes to spacecraft configuration must be controlled. Clear restrictions prevent unauthorized modification. Structured access governance reduces insider risk. Accountability supports traceability. |
| SPR-411 | The [organization] shall define and enforce restrictions on activities and transactions permissible when interacting with external systems.These access controls shall be regularly reviewed and updated to align with organizational security policies and requirements.{SV-AC-1,SV-MA-7}{AC-20,AC-20(1),AC-20(3)} | External systems may introduce compromise pathways. Defined boundaries limit exposure. Regular review ensures alignment with evolving policy. Controlled interfaces strengthen resilience. |
| SPR-418 | The [organization] shall define a process to limit privileges to change system components and system-related information within a production or operational environment.{SV-AC-4,SV-AC-1}{CM-5(5)} | Operational environments require strict change control. Limiting privileges reduces insider exploitation risk. Controlled modification protects mission stability. Governance supports reliability. |
| SPR-449 | The [spacecraft] shall enforce mandatory access control over subjects and objects.{SV-AC-1,SV-AC-4}{AC-3,AC-3(3)} | MAC ensures centrally enforced policy cannot be overridden by subjects. Strong policy binding reduces discretionary abuse. Deterministic enforcement enhances mission protection. Strict separation strengthens confidentiality and integrity. |
| SPR-450 | The [spacecraft] shall prevent flight software and payload applications from modifying access control labels or rules and shall validate label integrity at startup and during policy updates.{SV-AC-1,SV-IT-2}{AC-3(3),AC-3(11).AC-16,SI-7} | Label integrity ensures policy decisions remain trustworthy. Preventing modification protects data classification enforcement. Validation at startup prevents persistent compromise. Policy integrity underpins MAC assurance. |
| SPR-455 | The [spacecraft] shall restrict access to flight software executables, cryptographic material, command dictionaries, and [organization]-defined sensitive payload data to the privileged execution domain and shall deny all other access by default.{SV-AC-1,SV-AC-3,SV-IT-3}{AC-3(11),AC-6} | Flight executables and cryptographic materials are high-value targets. Restricting access reduces exploitation pathways. Default deny enforces least privilege. Segmentation enhances resilience. |
| SPR-456 | The [spacecraft] shall implement OS or hardware enforcement for these restrictions and shall log any attempted access violations.{SV-AC-1,SV-DCO-1}{AC-3,AC-3(11)} | Hardware-enforced policy is harder to bypass than software-only controls. Logging violations supports detection and response. Layered enforcement strengthens assurance. Technical barriers reinforce governance intent. |
| SPR-459 | The [spacecraft] shall validate security labels or tags on received data and shall drop or quarantine content with missing, invalid, or downgraded labels.{SV-IT-2,SV-AC-1}{AC-16} | Label validation ensures data classification and access control integrity. Dropping or quarantining downgraded or malformed labels prevents policy bypass. Enforced label integrity supports mandatory access control. |
| SPR-462 | The [spacecraft] shall support delegation of temporary data storage to [organization]-authorized alternate nodes or spacecraft and shall preserve confidentiality, integrity, and access controls for the delegated data.{SV-CF-1,SV-CF-2,SV-AC-1}{CP-2(6),SC-28,AC-3} | Delegated storage or processing expands trust boundaries. Maintaining CIA protections during delegation prevents exposure. Secure federation supports constellation-based architectures. Controlled delegation strengthens distributed resilience. |
| SPR-513 | The [organization] shall develop and maintain a phase‑ and mode‑aware access control policy for the mission that maps operator/station identities to command families and pass windows, defines on‑orbit key lifecycle (generation, activation, rotation, retirement), session establishment/renewal/teardown behaviors, and time‑synchronization assumptions across space and ground; the policy shall be validated in simulators/flatsats.{SV-AC-4,SV-AC-1}{AC-1,PL-2} | Access requirements vary by mission phase and spacecraft mode. Explicit mapping prevents inappropriate command authority. Simulator validation ensures policy feasibility. Context-aware governance supports Zero Trust principles. |
| SPR-515 | The [spacecraft] shall enforce discretionary access on [organization]-defined payload data stores using short‑lived, purpose‑specific grants bound to execution windows or end‑of‑pass, with automatic expiration, audited changes/uses, and integrity checks on permission metadata that survive resets/SEUs.{SV-AC-4,SV-AC-1}{AC-3(4)} | Ephemeral grants reduce persistence risk. Execution-window binding prevents privilege creep. Surviving SEUs ensures metadata integrity. Time-bounded access supports least privilege. |
| 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-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-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-545 | The [spacecraft] shall bind session authenticity to station identity, operator role, spacecraft mode, and time/sequence and shall expose session parameters (IDs, counters, active role/mode) in telemetry; acceptance checks shall enforce geo/time/mode and station‑whitelist constraints with clear behavior on variance.{SV-AC-4,SV-AC-1}{SC-23,SC-23(1),SC-23(3)} | Station, role, mode, and time binding prevents misuse. Telemetry exposure ensures traceability. Constraint enforcement reduces impersonation risk. Context binding strengthens Zero Trust alignment. |
| ID | Name | Description | |
|---|---|---|---|
| RD-0002 | Compromise Infrastructure | Rather than purchasing or renting assets, adversaries compromise existing infrastructure, mission-owned, third-party, or shared, to obtain ready-made reach into space, ground, or cloud environments with the benefit of plausible attribution. Targets range from physical RF chains and timing sources to mission control servers, automation/scheduling systems, SLE/CSP gateways, identity providers, and cloud data paths. Initial access often comes via stolen credentials, spear-phishing of operators and vendors, exposed remote-support paths, misconfigured multi-tenant platforms, or lateral movement from enterprise IT into operations enclaves. Once resident, actors can pre-position tools, modify configurations, suppress logging, and impersonate legitimate stations or operators to support later Execution, Exfiltration, or Denial. | |
| RD-0002.01 | Mission-Operated Ground System | Compromising a mission’s own ground system grants the adversary preconfigured access to TT&C and automation. High-value targets include operator workstations, mission control servers, procedure libraries, scheduler/orchestration services, key-loading tools and HSMs, antenna control systems, timing/distribution, and RF modems/baseband units. Typical paths: phishing an operator or contractor, abusing remote-support channels, pivoting from enterprise IT to ops, exploiting unpatched services on enclave gateways, or harvesting credentials from poorly segmented test environments. Once inside, an actor can stage malicious procedures, alter rate/size limits, manipulate pass schedules, downgrade authentication in maintenance modes, or quietly siphon telemetry and ephemerides to refine later attacks. | |
| RD-0002.02 | 3rd Party Ground System | Third-party networks (commercial ground stations, hosted modems, cloud-integrated ground-station services) present attractive stepping-stones: they already have vetted RF chains, globally distributed apertures, and trusted IP space. Adversaries may acquire customer credentials via phishing or purchase, exploit weak vetting to create front-company accounts, or compromise provider portals/APIs to submit schedules, alter front-end settings, or exfiltrate collected data. Because traffic originates from “expected” stations and ASN ranges, misuse blends into normal operations. Multi-tenant risks include configuration bleed-over and shared management planes. | |
| RD-0002.03 | 3rd-Party Spacecraft | By compromising another operator’s spacecraft, or a hosted payload, an adversary can gain proximity, sensing, and relay capabilities that are costly to build from scratch and difficult to attribute. With control of an on-orbit asset, the actor may conduct local spectrum measurement and traffic analysis, attempt selective interference or spoofing at short range, or probe crosslinks and gateways where payload networks bridge to buses. In rideshare or hosted-payload contexts, weak segmentation and shared ground paths can provide insight into neighboring missions. More aggressive scenarios include remote proximity operations (RPO) to achieve advantageous geometry; however, physical grappling, docking, or exposure of debug/test interfaces is highly specialized and rare, with significant safety, legal, and tracking implications. Realistic attacker goals emphasize adjacency for RF leverage, covert relay, or data theft rather than mechanical capture. | |
| IA-0003 | Crosslink via Compromised Neighbor | Where spacecraft exchange data over inter-satellite links (RF or optical), a compromise on one vehicle can become a bridgehead to others. Threat actors exploit crosslink trust: shared routing, time distribution, service discovery, or gateway functions that forward commands and data between vehicles and ground. With knowledge of crosslink framing, addressing, and authentication semantics, an adversary can craft traffic that appears to originate from a trusted neighbor, injecting control messages, malformed service advertisements, or payload tasking that propagates across the mesh. In tightly coupled constellations, crosslinks may terminate on gateways that also touch the C&DH or payload buses, providing additional pivot opportunities. Because crosslink traffic is expected and often high volume, attacker activity can be timed to blend with synchronization intervals, ranging exchanges, or scheduled data relays. | |
| IA-0007 | Compromise Ground System | Compromising the ground segment gives an adversary the most direct path to first execution against a spacecraft. Ground systems encompass operator workstations and mission control mission control software, scheduling/orchestration services, front-end processors and modems, antenna control, key-loading tools and HSMs, data gateways (SLE/CSP), identity providers, and cloud-hosted mission services. Once inside, a threat actor can prepare on-orbit updates, craft and queue valid telecommands, replay captured traffic within acceptance windows, or manipulate authentication material and counters to pass checks. The same foothold enables deep reconnaissance: enumerating mission networks and enclaves, discovering which satellites are operated from a site, mapping logical topology between MOC and stations, identifying in-band “birds” reachable from a given aperture, and learning pass plans, dictionaries, and automation hooks. From there, initial access to the spacecraft is a matter of timing and presentation, injecting commands, procedures, or update packages that align with expected operations so the first execution event appears indistinguishable from normal activity. | |
| IA-0007.01 | Compromise On-Orbit Update | Adversaries may target the pipeline that produces and transmits updates to an on-orbit vehicle. Manipulation points include source repositories and configuration tables, build and packaging steps that generate images or differential patches, staging areas on ground servers, update metadata (versions, counters, manifests), and the transmission process itself. Spacecraft updates span flight software patches, FPGA bitstreams, bootloader or device firmware loads, and operational data products such as command tables, ephemerides, and calibration files, each with distinct formats, framing, and acceptance rules. An attacker positioned in the ground system can substitute or modify an artifact, alter its timing and timetags to match pass windows, and queue it through the same procedures operators use for nominal maintenance. Activation can be immediate or deferred: implants may lie dormant until a specific mode, safing entry, or table index is referenced. | |
| IA-0007.02 | Malicious Commanding via Valid GS | Adversaries may use a compromised, mission-owned ground system to transmit legitimate-looking commands to the target spacecraft. Because the ground equipment is already configured for the mission, correct waveforms, framing, dictionaries, and scheduling, the attacker’s traffic blends with routine operations. Initial access unfolds by inserting commands or procedures into existing timelines, modifying rate/size limits or command queues, or invoking maintenance dictionaries and rapid-response workflows that accept broader command sets. Pre-positioned scripts can chain actions across multiple passes and stations, while telemetry routing provides immediate feedback to refine follow-on steps. Exfiltration can be embedded in standard downlink channels or forwarded through gateways as ordinary mission data. The distinguishing feature is that command origin appears valid, transmitted from approved apertures using expected parameters, so the first execution event is not a protocol anomaly but a misuse of legitimate command authority obtained through the compromised ground system. | |
| IA-0008 | Rogue External Entity | Adversaries obtain a foothold by interacting with the spacecraft from platforms outside the authorized ground architecture. A “rogue external entity” is any actor-controlled transmitter or node, ground, maritime, airborne, or space-based, that can radiate or exchange traffic using mission-compatible waveforms, framing, or crosslink protocols. The technique exploits the fact that many vehicles must remain commandable and discoverable over wide areas and across multiple modalities. Using public ephemerides, pass predictions, and knowledge of acquisition procedures, the actor times transmissions to line-of-sight windows, handovers, or maintenance periods. Initial access stems from presenting traffic that the spacecraft will parse or prioritize: syntactically valid telecommands, crafted ranging/acquisition exchanges, crosslink service advertisements, or payload/user-channel messages that bridge into the command/data path. | |
| IA-0008.01 | Rogue Ground Station | Adversaries may field their own ground system, transportable or fixed, to transmit and receive mission-compatible signals. A typical setup couples steerable apertures and GPS-disciplined timing with SDR/modems configured for the target’s bands, modulation/coding, framing, and beacon structure. Using pass schedules and Doppler/polarization predictions, the actor crafts over-the-air traffic that appears valid at the RF and protocol layers. | |
| EX-0001 | Replay | Replay is the re-transmission of previously captured traffic, over RF links, crosslinks, or internal buses, to elicit the same processing and effects a second time. Adversaries first observe and record authentic exchanges (telecommands, ranging/acquisition frames, housekeeping telemetry acknowledgments, bus messages), then resend them within acceptance conditions that the system recognizes, matching link geometry, timetags, counters, or mode states. The aim can be functional (re-triggering an action such as a mode change), observational (fingerprinting how the vehicle reacts at different states), or disruptive (saturating queues and bandwidth to crowd out legitimate traffic). Because replays preserve valid syntax and often valid context, they can blend with normal operations, especially during periods with reduced monitoring or when counters and windows reset (e.g., handovers, safing entries). On encrypted links, metadata replays (acquisition beacons, schedule requests) may still yield informative responses. | |
| EX-0001.01 | Command Packets | Threat actors may resend authentic-looking telecommands that were previously accepted by the spacecraft. Captures may include whole command PDUs with framing, CRC/MAC, counters, and timetags intact, or they may be reconstructed from operator tooling and procedure logs. When timing, counters, and mode preconditions align, the replayed packet can cause the same effect: toggling relays, initiating safing or recovery scripts, adjusting tables, commanding momentum dumps, or scheduling delta-v events. Even when outright execution fails, repeated “near-miss” injections can map acceptance windows, rate/size limits, and interlocks by observing the spacecraft’s acknowledgments and state changes. At scale, streams of valid-but-stale commands can congest command queues, delay legitimate activity, or trigger nuisance FDIR responses. | |
| PER-0004 | Replace Cryptographic Keys | The adversary cements control by changing the cryptographic material the spacecraft uses to authenticate or protect links and updates. Targets include uplink authentication keys and counters, link-encryption/session keys and key-encryption keys (KEKs), key identifiers/selectors, and algorithm profiles. Using authorized rekey commands or key-loading procedures, often designed for over-the-air use, the attacker installs new values in non-volatile storage and updates selectors so subsequent traffic must use the attacker’s keys to be accepted. Variants desynchronize anti-replay by advancing counters or switching epochs, or strand operators by flipping profiles to a mode for which only the adversary holds parameters. Once replaced, the new material persists across resets and mode changes, turning the spacecraft into a node that recognizes the adversary’s channel while rejecting former controllers. | |
| LM-0003 | Constellation Hopping via Crosslink | In networks where vehicles exchange data over inter-satellite links, a compromise on one spacecraft becomes a springboard to others. The attacker crafts crosslink traffic, routing updates, service advertisements, time/ephemeris distribution, file or tasking messages, that appears to originate from a trusted neighbor and targets gateway functions that bridge crosslink traffic into command/data paths. Once accepted, those messages can queue procedures, deliver configuration/table edits, or open file transfer sessions on adjacent vehicles. In mesh or hub-and-spoke constellations, this enables “hop-by-hop” spread: a single foothold uses shared trust and protocol uniformity to reach additional satellites without contacting the ground segment. | |
| LM-0004 | Visiting Vehicle Interface(s) | Docking, berthing, or short-duration attach events create high-trust, high-bandwidth connections between vehicles. During these operations, automatic sequences verify latches, exchange status, synchronize time, and enable umbilicals that carry data and power; maintenance tools may also push firmware or tables across the interface. An attacker positioned on the visiting vehicle can exploit these handshakes and service channels to inject commands, transfer files, or access bus gateways on the host. Because many actions are expected “just after dock,” malicious traffic can ride the same procedures that commission the interface, allowing lateral movement from the visiting craft into the target spacecraft’s C&DH, payload, or support subsystems. | |
| LM-0006 | Launch Vehicle Interface | During integration and ascent, payloads and the launch vehicle exchange power, discrete lines, and data via umbilicals, separation avionics, and shared EGSE networks. Protections can be reduced or heterogeneous because timelines are tight and responsibilities cross organizations. An attacker positioned on either side (vehicle or payload) can use these commissioning links, health/status queries, time distribution, inhibit lines, separation commands, or telemetry gateways, to inject messages, transfer files, or alter configuration that propagates across the interface. Before fairing close and prior to separation, this brief but high-trust coupling provides a route to move from one platform to the other and to seed artifacts that persist after deployment. | |
| LM-0006.01 | Rideshare Payload | In shared launches, multiple independent payloads cohabit common infrastructure until separation. If isolation is incomplete (e.g., shared data buses, mispartitioned deployer controllers, common logging/telemetry collectors, or cross-connected laptops and recorders), a compromise in one payload’s domain can be leveraged to observe or influence another’s traffic before release. Threat actors exploit these transient but real connections to read configuration, pivot through deployer control paths, or stage data/commands that execute as neighboring payloads power and check out, enabling cross-payload access or tampering prior to independent flight. | |
| EXF-0004 | Out-of-Band Communications Link | Some missions field secondary links, separate frequencies and hardware, for limited, purpose-built functions (e.g., rekeying, emergency commanding, beacons, custodial crosslinks). Adversaries co-opt these channels as covert data paths: embedding content in maintenance messages, beacon fields, or low-rate housekeeping; initiating vendor/service modes that carry file fragments; or switching to contingency profiles that bypass normal routing and monitoring. Because these paths are distinct from the main TT&C and may be sparsely supervised, they provide discreet avenues to move data off the spacecraft or to external relays without altering the primary link’s traffic patterns. | |
| IMP-0001 | Deception (or Misdirection) | Measures designed to mislead an adversary by manipulation, distortion, or falsification of evidence or information into a system to induce the adversary to react in a manner prejudicial to their interests. Threat actors may seek to deceive mission stakeholders (or even military decision makers) for a multitude of reasons. Telemetry values could be modified, attacks could be designed to intentionally mimic another threat actor's TTPs, and even allied ground infrastructure could be compromised and used as the source of communications to the spacecraft. | |
| IMP-0006 | Theft | Threat actors may attempt to steal the data that is being gathered, processed, and sent from the victim spacecraft. Many spacecraft have a particular purpose associated with them and the data they gather is deemed mission critical. By attempting to steal this data, the mission, or purpose, of the spacecraft could be lost entirely. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0052 | Insider Threat Protection | Establish policy and procedures to prevent individuals (i.e., insiders) from masquerading as individuals with valid access to areas where commanding of the spacecraft is possible. Establish an Insider Threat Program to aid in the prevention of people with authorized access performing malicious activities. | AC-14 AC-3(11) AC-3(13) AC-3(15) AC-6 AT-2 AT-2(2) AT-2(4) AT-2(5) AT-2(6) AU-10 AU-12 AU-13 AU-6 AU-7 CA-7 CP-2 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) IA-4 IR-2(3) IR-4 IR-4(6) IR-4(7) MA-7 MP-7 PE-2 PL-8 PL-8(1) PM-12 PM-14 PS-3 PS-4 PS-5 PS-8 RA-10 SA-3 SA-8 SC-38 SC-7 SI-4 SR-11(2) | D3-OAM D3-AM D3-OM D3-CH D3-SPP D3-MFA D3-UAP D3-UBA | A.8.4 A.5.15 A.8.2 A.8.18 7.3 A.6.3 A.8.7 A.5.25 A.6.8 A.8.15 A.8.15 A.8.12 A.8.16 9.1 9.3.2 9.3.3 A.5.36 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.16 A.5.25 A.5.26 A.5.27 A.5.10 A.7.10 A.7.2 A.5.8 A.6.1 A.5.11 A.6.5 A.5.11 A.6.5 7.3 A.6.4 A.5.7 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.16 | |
| CM0054 | Two-Person Rule | Utilize a two-person system 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. | AC-14 AC-3(13) AC-3(15) AC-3(2) AU-9(5) CP-2 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) PE-3 SA-8(15) | D3-OAM D3-AM D3-ODM D3-OM D3-MFA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.7.1 A.7.2 A.7.3 A.7.4 | |
| CM0079 | Maneuverability | Satellite maneuver is an operational tactic that can be used by satellites fitted with chemical thrusters to avoid kinetic and some directed energy ASAT weapons. For unguided projectiles, a satellite can be commanded to move out of their trajectory to avoid impact. If the threat is a guided projectile, like most direct-ascent ASAT and co-orbital ASAT weapons, maneuver becomes more difficult and is only likely to be effective if the satellite can move beyond the view of the onboard sensors on the guided warhead.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG | CP-10(6) CP-13 CP-2 CP-2(1) CP-2(3) CP-2(5) PE-20 PE-21 | None | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 A.5.29 A.5.10 | |
| CM0084 | Physical Seizure | A spacecraft capable of docking with, manipulating, or maneuvering other satellites or pieces of debris can be used to thwart spacebased attacks or mitigate the effects after an attack has occurred. Such a system could be used to physically seize a threatening satellite that is being used to attack or endanger other satellites or to capture a satellite that has been disabled or hijacked for nefarious purposes. Such a system could also be used to collect and dispose of harmful orbital debris resulting from an attack. A key limitation of a physical seizure system is that each satellite would be time- and propellant-limited depending on the orbit in which it is stored. A system stored in GEO, for example, would not be well positioned to capture an object in LEO because of the amount of propellant required to maneuver into position. Physical seizure satellites may need to be stored on Earth and deployed once they are needed to a specific orbit to counter a specific threat.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG | CP-13 PE-20 | D3-AM | A.5.29 A.5.10 | |
| CM0002 | COMSEC | A component of cybersecurity to deny unauthorized persons information derived from telecommunications and to ensure the authenticity of such telecommunications. COMSEC includes cryptographic security, transmission security, emissions security, and physical security of COMSEC material. It is imperative to utilize secure communication protocols with strong cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission. Systems should also maintain the confidentiality and integrity of information during preparation for transmission and during reception. Spacecraft should not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). The cryptographic mechanisms should identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters. | AC-17 AC-17(1) AC-17(10) AC-17(2) AC-18 AC-18(1) AC-2(11) AC-3(10) CA-3 IA-4(9) IA-5 IA-5(7) IA-7 PL-8 PL-8(1) SA-8(18) SA-8(19) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SC-8(1) SC-8(3) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8) | D3-ET D3-MH D3-MAN D3-MENCR D3-NTF D3-ITF D3-OTF D3-CH D3-DTP D3-NTA D3-CAA D3-DNSTA D3-IPCTA D3-NTCD D3-RTSD D3-PHDURA D3-PMAD D3-CSPP D3-MA D3-SMRA D3-SRA | A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.16 A.5.17 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.12 A.5.33 A.8.20 A.8.24 A.8.24 A.8.26 A.5.31 A.5.33 A.8.11 | |
| CM0030 | Crypto Key Management | Leverage best practices for crypto key management as defined by organization like NIST or the National Security Agency. Leverage only approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. Encryption key handling should be performed outside of the onboard software and protected using cryptography. Encryption keys should be restricted so that they cannot be read via any telecommands. | CM-3(6) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-9(6) SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-28(3) SC-8(1) | D3-CH D3-CP | A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24 | |
| CM0031 | Authentication | Authenticate all communication sessions (crosslink and ground stations) for all commands before establishing remote connections using bidirectional authentication that is cryptographically based. Adding authentication on the spacecraft bus and communications on-board the spacecraft is also recommended. | AC-14 AC-17 AC-17(10) AC-17(2) AC-18 AC-18(1) IA-2 IA-3(1) IA-4 IA-4(9) IA-7 IA-9 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(1) SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) SI-7(6) | D3-MH D3-MAN D3-CH D3-BAN D3-MFA D3-TAAN D3-CBAN | A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.16 A.5.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 | |
| CM0033 | Relay Protection | Implement relay and replay-resistant authentication mechanisms for establishing a remote connection or connections on the spacecraft bus. | AC-17(10) IA-2(8) IA-3 IA-3(1) IA-4 IA-7 SC-13 SC-16(1) SC-23 SC-23(1) SC-23(3) SC-7 SC-7(11) SC-7(18) SI-10 SI-10(5) SI-10(6) SI-3(8) | D3-ITF D3-NTA D3-OTF | A.5.16 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.24 A.8.26 A.5.31 | |
| CM0003 | TEMPEST | The spacecraft should protect system components, associated data communications, and communication buses in accordance with TEMPEST controls to prevent side channel / proximity attacks. Encompass the spacecraft critical components with a casing/shielding so as to prevent access to the individual critical components. | PE-19 PE-19(1) PE-21 SC-8(3) | D3-PH D3-RFS | A.7.5 A.7.8 A.8.12 | |
| CM0050 | On-board Message Encryption | In addition to authentication on-board the spacecraft bus, encryption is also recommended to protect the confidentiality of the data traversing the bus. | AC-4 AC-4(23) AC-4(24) AC-4(26) AC-4(31) AC-4(32) PL-8 PL-8(1) SA-3 SA-8 SA-8(18) SA-8(19) SA-8(9) SA-9(6) SC-13 SC-16 SC-16(1) SC-16(2) SC-16(3) SC-8(1) SC-8(3) SI-19(4) SI-4(10) SI-4(25) | D3-MH D3-MENCR D3-ET | A.5.14 A.8.22 A.8.23 A.8.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24 A.8.26 A.5.31 A.8.11 | |
| CM0036 | Session Termination | Terminate the connection associated with a communications session at the end of the session or after an acceptable amount of inactivity which is established via the concept of operations. | AC-12 AC-12(2) SC-10 SI-14(3) SI-4(7) | D3-SDA | A.8.20 | |
| CM0055 | Secure Command Mode(s) | Provide additional protection modes for commanding the spacecraft. These can be where the spacecraft will restrict command lock based on geographic location of ground stations, special operational modes within the flight software, or even temporal controls where the spacecraft will only accept commands during certain times. | AC-17(1) AC-17(10) AC-2(11) AC-2(12) AC-3 AC-3(2) AC-3(3) AC-3(4) AC-3(8) CA-3(7) IA-10 PL-8 PL-8(1) SA-3 SA-8 SC-7 SI-3(8) | D3-AH D3-ACH D3-MFA D3-OTP | A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | |
| CM0005 | Ground-based Countermeasures | This countermeasure is focused on the protection of terrestrial assets like ground networks and development environments/contractor networks, etc. Traditional detection technologies and capabilities would be applicable here. Utilizing resources from NIST CSF to properly secure these environments using identify, protect, detect, recover, and respond is likely warranted. Additionally, NISTIR 8401 may provide resources as well since it was developed to focus on ground-based security for space systems (https://csrc.nist.gov/pubs/ir/8401/final). Furthermore, the MITRE ATT&CK framework provides IT focused TTPs and their mitigations https://attack.mitre.org/mitigations/enterprise/. Several recommended NIST 800-53 Rev5 controls are provided for reference when designing ground systems/networks. | AC-1 AC-10 AC-11 AC-11(1) AC-12 AC-12(1) AC-14 AC-16 AC-16(6) AC-17 AC-17(1) AC-17(10) AC-17(2) AC-17(3) AC-17(4) AC-17(6) AC-17(9) AC-18 AC-18(1) AC-18(3) AC-18(4) AC-18(5) AC-19 AC-19(5) AC-2 AC-2(1) AC-2(11) AC-2(12) AC-2(13) AC-2(2) AC-2(3) AC-2(9) AC-20 AC-20(1) AC-20(2) AC-20(3) AC-20(5) AC-21 AC-22 AC-3 AC-3(11) AC-3(13) AC-3(15) AC-3(4) AC-4 AC-4(23) AC-4(24) AC-4(25) AC-4(26) AC-4(31) AC-4(32) AC-6 AC-6(1) AC-6(10) AC-6(2) AC-6(3) AC-6(5) AC-6(8) AC-6(9) AC-7 AC-8 AT-2(4) AT-2(5) AT-2(6) AT-3 AT-3(2) AT-4 AU-10 AU-11 AU-12 AU-12(1) AU-12(3) AU-14 AU-14(1) AU-14(3) AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(1) AU-5(2) AU-5(5) AU-6 AU-6(1) AU-6(3) AU-6(4) AU-6(5) AU-6(6) AU-7 AU-7(1) AU-8 AU-9 AU-9(2) AU-9(3) AU-9(4) CA-3 CA-3(6) CA-3(7) CA-7 CA-7(1) CA-7(6) CA-8 CA-8(1) CA-9 CM-10(1) CM-11 CM-11(2) CM-11(3) CM-12 CM-12(1) CM-14 CM-2 CM-2(2) CM-2(3) CM-2(7) CM-3 CM-3(1) CM-3(2) CM-3(4) CM-3(5) CM-3(6) CM-3(7) CM-3(8) CM-4 CM-5(1) CM-5(5) CM-6 CM-6(1) CM-6(2) CM-7 CM-7(1) CM-7(2) CM-7(3) CM-7(5) CM-7(8) CM-7(9) CM-8 CM-8(1) CM-8(2) CM-8(3) CM-8(4) CM-9 CP-10 CP-10(2) CP-10(4) CP-2 CP-2(2) CP-2(5) CP-2(8) CP-3(1) CP-4(1) CP-4(2) CP-4(5) CP-8 CP-8(1) CP-8(2) CP-8(3) CP-8(4) CP-8(5) CP-9 CP-9(1) CP-9(2) CP-9(3) IA-11 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) IA-2 IA-2(1) IA-2(12) IA-2(2) IA-2(5) IA-2(6) IA-2(8) IA-3 IA-3(1) IA-4 IA-4(9) IA-5 IA-5(1) IA-5(13) IA-5(14) IA-5(2) IA-5(7) IA-5(8) IA-6 IA-7 IA-8 IR-2 IR-2(2) IR-2(3) IR-3 IR-3(1) IR-3(2) IR-3(3) IR-4 IR-4(1) IR-4(10) IR-4(11) IR-4(12) IR-4(13) IR-4(14) IR-4(3) IR-4(4) IR-4(5) IR-4(6) IR-4(7) IR-4(8) IR-5 IR-5(1) IR-6 IR-6(1) IR-6(2) IR-7 IR-7(1) IR-8 MA-2 MA-3 MA-3(1) MA-3(2) MA-3(3) MA-4 MA-4(1) MA-4(3) MA-4(6) MA-4(7) MA-5(1) MA-6 MA-7 MP-2 MP-3 MP-4 MP-5 MP-6 MP-6(3) MP-7 PE-3(7) PL-10 PL-11 PL-8 PL-8(1) PL-8(2) PL-9 PM-11 PM-16(1) PM-17 PM-30 PM-30(1) PM-31 PM-32 RA-10 RA-3(1) RA-3(2) RA-3(3) RA-3(4) RA-5 RA-5(10) RA-5(11) RA-5(2) RA-5(4) RA-5(5) RA-7 RA-9 SA-10 SA-10(1) SA-10(2) SA-10(7) SA-11 SA-11(2) SA-11(4) SA-11(7) SA-11(9) SA-15 SA-15(3) SA-15(7) SA-17 SA-2 SA-22 SA-3 SA-3(1) SA-3(2) SA-4 SA-4(1) SA-4(10) SA-4(12) SA-4(2) SA-4(3) SA-4(5) SA-4(7) SA-4(9) SA-5 SA-8 SA-8(14) SA-8(15) SA-8(18) SA-8(21) SA-8(22) SA-8(23) SA-8(24) SA-8(29) SA-8(9) SA-9 SA-9(1) SA-9(2) SA-9(6) SA-9(7) SC-10 SC-12 SC-12(1) SC-12(6) SC-13 SC-15 SC-16(2) SC-16(3) SC-18(1) SC-18(2) SC-18(3) SC-18(4) SC-2 SC-2(2) SC-20 SC-21 SC-22 SC-23 SC-23(1) SC-23(3) SC-23(5) SC-24 SC-28 SC-28(1) SC-28(3) SC-3 SC-38 SC-39 SC-4 SC-45 SC-45(1) SC-45(2) SC-49 SC-5 SC-5(1) SC-5(2) SC-5(3) SC-50 SC-51 SC-7 SC-7(10) SC-7(11) SC-7(12) SC-7(13) SC-7(14) SC-7(18) SC-7(21) SC-7(25) SC-7(29) SC-7(3) SC-7(4) SC-7(5) SC-7(7) SC-7(8) SC-7(9) SC-8 SC-8(1) SC-8(2) SC-8(5) SI-10 SI-10(3) SI-10(6) SI-11 SI-12 SI-14(3) SI-16 SI-19(4) SI-2 SI-2(2) SI-2(3) SI-2(6) SI-21 SI-3 SI-3(10) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(12) SI-4(13) SI-4(14) SI-4(15) SI-4(16) SI-4(17) SI-4(2) SI-4(20) SI-4(22) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-5 SI-5(1) SI-6 SI-7 SI-7(1) SI-7(17) SI-7(2) SI-7(5) SI-7(7) SI-7(8) SR-1 SR-10 SR-11 SR-11(1) SR-11(2) SR-11(3) SR-12 SR-2 SR-2(1) SR-3 SR-3(1) SR-3(2) SR-3(3) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5(1) SR-5(2) SR-6 SR-6(1) SR-7 SR-8 SR-9 SR-9(1) | Nearly all D3FEND Techniques apply to Ground | 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.15 A.5.31 A.5.36 A.5.37 A.5.16 A.5.18 A.8.2 A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.4 A.5.14 A.8.22 A.8.23 A.8.11 A.8.10 A.5.15 A.8.2 A.8.18 A.8.5 A.8.5 A.7.7 A.8.1 A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.7.9 A.8.1 A.5.14 A.7.9 A.8.20 A.6.3 A.8.15 A.8.15 A.8.6 A.5.25 A.6.8 A.8.15 A.7.4 A.8.17 A.5.33 A.8.15 A.5.28 A.8.15 A.8.15 A.8.15 A.5.14 A.8.21 9.1 9.3.2 9.3.3 A.5.36 9.2.2 A.8.9 A.8.9 8.1 9.3.3 A.8.9 A.8.32 A.8.9 A.8.9 A.8.9 A.8.9 A.8.19 A.8.19 A.5.9 A.8.9 A.5.2 A.8.9 A.8.19 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.30 A.5.30 A.5.29 A.7.11 A.5.29 A.5.33 A.8.13 A.5.29 A.5.16 A.5.16 A.5.16 A.5.17 A.8.5 A.5.16 A.6.3 A.5.25 A.5.26 A.5.27 A.8.16 A.5.5 A.6.8 7.5.1 7.5.2 7.5.3 A.5.24 A.7.10 A.7.13 A.8.10 A.8.10 A.8.16 A.8.10 A.7.13 A.5.10 A.7.7 A.7.10 A.5.13 A.5.10 A.7.7 A.7.10 A.8.10 A.5.10 A.7.9 A.7.10 A.5.10 A.7.10 A.7.14 A.8.10 A.5.10 A.7.10 A.5.8 A.5.7 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 4.4 6.2 7.4 7.5.1 7.5.2 7.5.3 9.1 9.2.2 10.1 10.2 A.8.8 6.1.3 8.3 10.2 A.5.22 A.5.7 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 8.1 A.5.8 A.5.20 A.5.23 A.8.29 A.8.30 A.8.28 7.5.1 7.5.2 7.5.3 A.5.37 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.9 A.8.28 A.8.30 A.8.32 A.8.29 A.8.30 A.5.8 A.8.25 A.8.25 A.8.27 A.8.6 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.23 A.8.12 A.5.10 A.5.14 A.8.20 A.8.26 A.5.33 A.8.20 A.8.24 A.8.24 A.8.26 A.5.31 A.5.14 A.5.10 A.5.33 A.6.8 A.8.8 A.8.32 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16 A.5.6 A.8.11 A.8.10 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.19 A.5.31 A.5.36 A.5.37 A.5.19 A.5.20 A.5.21 A.8.30 A.5.20 A.5.21 A.5.21 A.8.30 A.5.20 A.5.21 A.5.23 A.8.29 A.5.22 A.5.22 | |
| CM0034 | Monitor Critical Telemetry Points | Monitor defined telemetry points for malicious activities (i.e., jamming attempts, commanding attempts (e.g., command modes, counters, etc.)). This would include valid/processed commands as well as commands that were rejected. Telemetry monitoring should synchronize with ground-based Defensive Cyber Operations (i.e., SIEM/auditing) to create a full space system situation awareness from a cybersecurity perspective. | AC-17(1) AU-3(1) CA-7(6) IR-4(14) PL-8 PL-8(1) SA-8(13) SC-16 SC-16(1) SC-7 SI-3(8) SI-4(7) | D3-NTA D3-PM D3-PMAD D3-RTSD | A.8.16 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | |
| CM0035 | Protect Authenticators | Protect authenticator content from unauthorized disclosure and modification. | AC-17(6) AC-3(11) CM-3(6) IA-4(9) IA-5 IA-5(6) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(19) SC-16 SC-16(1) SC-8(1) | D3-CE D3-ANCI D3-CA D3-ACA D3-PCA D3-CRO D3-CTS D3-SPP | A.8.4 A.5.16 A.5.17 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 | |
| CM0053 | Physical Security Controls | Employ physical security controls (badge with pins, guards, gates, etc.) to prevent unauthorized access to the systems that have the ability to command the spacecraft. | AC-14 CA-3(6) CA-8 CA-8(1) CA-8(3) PE-2 PE-2(1) PE-2(3) PE-3 PE-3(1) PE-3(2) PE-3(3) PE-3(5) PE-3(7) SA-3 SA-8 SC-12(6) SC-51 SC-8(5) SR-11(2) | D3-RFS D3-AM | A.7.2 A.7.1 A.7.2 A.7.3 A.7.4 A.8.12 A.7.4 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | |
| CM0070 | Alternate Communications Paths | Establish alternate communications paths to reduce the risk of all communications paths being affected by the same incident. | AC-17 CP-2 CP-4(2) CP-8(3) PL-8 PL-8(1) SC-47 | D3-NM D3-NTPM | A.5.14 A.6.7 A.8.1 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.8 | |
| CM0032 | On-board Intrusion Detection & Prevention | Utilize on-board intrusion detection/prevention system that monitors the mission critical components or systems and audit/logs actions. The IDS/IPS should have the capability to respond to threats (initial access, execution, persistence, evasion, exfiltration, etc.) and it should address signature-based attacks along with dynamic never-before seen attacks using machine learning/adaptive technologies. The IDS/IPS must integrate with traditional fault management to provide a wholistic approach to faults on-board the spacecraft. Spacecraft should select and execute safe countermeasures against cyber-attacks. These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker — with or without ground support. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system. | AU-14 AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(2) AU-5(5) AU-6(1) AU-6(4) AU-8 AU-9 AU-9(2) AU-9(3) CA-7(6) CM-11(3) CP-10 CP-10(4) IR-4 IR-4(11) IR-4(12) IR-4(14) IR-4(5) IR-5 IR-5(1) PL-8 PL-8(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5 SC-5(3) SC-7(10) SC-7(9) SI-10(6) SI-16 SI-17 SI-3 SI-3(10) SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) SI-4(16) SI-4(17) SI-4(2) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-4(7) SI-6 SI-7(17) SI-7(8) | D3-FA D3-DA D3-FCR D3-FH D3-ID D3-IRA D3-HD D3-IAA D3-FHRA D3-NTA D3-PMAD D3-RTSD D3-ANAA D3-CA D3-CSPP D3-ISVA D3-PM D3-SDM D3-SFA D3-SFV D3-SICA D3-USICA D3-FBA D3-FEMC D3-FV D3-OSM D3-PFV D3-EHB D3-IDA D3-MBT D3-SBV D3-PA D3-PSMD D3-PSA D3-SEA D3-SSC D3-SCA D3-FAPA D3-IBCA D3-PCSV D3-FCA D3-PLA D3-UBA D3-RAPA D3-SDA D3-UDTA D3-UGLPA D3-ANET D3-AZET D3-JFAPA D3-LAM D3-NI D3-RRID D3-NTF D3-ITF D3-OTF D3-EI D3-EAL D3-EDL D3-HBPI D3-IOPR D3-KBPI D3-MAC D3-SCF | A.8.15 A.8.15 A.8.6 A.8.17 A.5.33 A.8.15 A.8.15 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.7 A.8.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16 | |
| CM0067 | Smart Contracts | Smart contracts can be used to mitigate harm when an attacker is attempting to compromise a hosted payload. Smart contracts will stipulate security protocol required across a bus and should it be violated, the violator will be barred from exchanges across the system after consensus achieved across the network. | IA-9 SI-4 SI-4(2) | D3-AM D3-PH D3-LFP D3-SCP | A.8.16 | |
| CM0037 | Disable Physical Ports | Provide the capability for data connection ports or input/output devices (e.g., JTAG) to be disabled or removed prior to spacecraft operations. | AC-14 MA-7 PL-8 PL-8(1) SA-3 SA-4(5) SA-4(9) SA-8 SC-41 SC-7(14) | D3-EI D3-IOPR | A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | |
| CM0065 | OSAM Dual Authorization | Before engaging in an On-orbit Servicing, Assembly, and Manufacturing (OSAM) mission, verification of servicer should be multi-factor authenticated/authorized by both the serviced ground station and the serviced asset. | CA-3(6) IA-2(1) IA-2(2) IA-2(6) | D3-OAM D3-AM D3-ODM D3-OM D3-MFA | None | |
| CM0029 | TRANSEC | Utilize TRANSEC in order to prevent interception, disruption of reception, communications deception, and/or derivation of intelligence by analysis of transmission characteristics such as signal parameters or message externals. For example, jam-resistant waveforms can be utilized to improve the resistance of radio frequency signals to jamming and spoofing. Note: TRANSEC is that field of COMSEC which deals with the security of communication transmissions, rather than that of the information being communicated. | AC-17 AC-18 AC-18(5) CA-3 CP-8 PL-8 PL-8(1) SA-8(19) SC-16 SC-16(1) SC-40 SC-40(1) SC-40(3) SC-40(4) SC-5 SC-8(1) SC-8(3) SC-8(4) | D3-MH D3-MAN D3-MENCR D3-NTA D3-DNSTA D3-ISVA D3-NTCD D3-RTA D3-PMAD D3-FC D3-CSPP D3-ANAA D3-RPA D3-IPCTA D3-NTCD D3-NTPM D3-TAAN | A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.29 A.7.11 A.5.8 A.5.33 | |