CM0029

Communications system spoofing resulting in denial of service and loss of availability and data integrity


Informational References

ID: CM0029
DiD Layer: Crypto
CAPEC #:  148 | 151 | 627 | 628
Lowest Threat Tier to
Create Threat Event:  
V
Notional Risk Rank Score: 

High-Level Requirements

The spacecraft shall be resilient against communications and positioning spoofing attempts.

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
The spacecraft shall incorporate backup sources for navigation and timing {SV-IT-1}{SC-45(1)}
The spacecraft shall internally monitor GPS performance so that changes or interruptions in the navigation or timing are flagged. {SV-IT-1} {SC-45(1)} Adopt voting schemes that include inputs from backup sources. Consider providing a second reference frame against which short-term changes or interferences can be compared.
The spacecraft shall have fault-tolerant authoritative position and time sourcing. {SV-IT-1} {SC-45(1)} 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
The spacecraft 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} Can be aided via the Crosslink, S-Band, and L-Band subsystems
The spacecraft shall protect external and internal communications from jamming and spoofing attempts. {SV-AV-1,SV-IT-1} {SC-5,SC-40,SC-40(1)}
The spacecraft shall implement cryptographic mechanisms that achieve adequate protection against the effects of intentional electromagnetic interference. {SV-AV-1,SV-IT-1} {SC-40,SC-40(1)}
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} {SC-40(3)}

Related SPARTA Techniques and Sub-Techniques

ID Name Description
IA-0008 Rogue External Entity Threat actors may gain access to a victim spacecraft through the use of a rogue external entity. With this technique, the threat actor does not need access to a legitimate ground station or communication site.
IA-0008.01 Rogue Ground Station Threat actors may gain access to a victim spacecraft through the use of a rogue ground system. With this technique, the threat actor does not need access to a legitimate ground station or communication site.
EX-0014 Spoofing Threat actors may attempt to spoof the various sensor and controller data that is depended upon by various subsystems within the victim spacecraft. Subsystems rely on this data to perform automated tasks, process gather data, and return important information to the ground controllers. By spoofing this information, threat actors could trigger automated tasks to fire when they are not needed to, potentially causing the spacecraft to behave erratically. Further, the data could be processed erroneously, causing ground controllers to receive incorrect telemetry or scientific data, threatening the spacecraft's reliability and integrity.
EX-0014.01 Time Spoof Threat actors may attempt to target the internal timers onboard the victim spacecraft and spoof their data. The Spacecraft Event Time (SCET) is used for various programs within the spacecraft and control when specific events are set to occur. Ground controllers use these timed events to perform automated processes as the spacecraft is in orbit in order for it to fulfill it's purpose. Threat actors that target this particular system and attempt to spoof it's data could cause these processes to trigger early or late.
EX-0014.02 Bus Traffic Threat actors may attempt to target the main or secondary bus onboard the victim spacecraft and spoof their data. The spacecraft bus often directly processes and sends messages from the ground controllers to the various subsystems within the spacecraft and between the subsystems themselves. If a threat actor would target this system and spoof it internally, the subsystems would take the spoofed information as legitimate and process it as normal. This could lead to undesired effects taking place that could damage the spacecraft's subsystems, hosted payload, and critical data.
EX-0014.03 Sensor Data Threat actors may target sensor data on the space vehicle to achieve their attack objectives. Sensor data is typically inherently trusted by the space vehicle therefore an attractive target for a threat actor. Spoofing the sensor data could affect the calculations and disrupt portions of a control loop as well as create uncertainty within the mission thereby creating temporary denial of service conditions for the mission. Affecting the integrity of the sensor data can have varying impacts on the space vehicle depending on decisions being made by the space vehicle using the sensor data. For example, spoofing data related to attitude control could adversely impact the space vehicles ability to maintain orbit.
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.

Related SPARTA Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0000 Countermeasure Not Identified This technique is a result of utilizing TTPs to create an impact and the applicable countermeasures are associated with the TTPs leveraged to achieve the impact None None
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(1) AC-17(10) AC-17(10) AC-17(2) AC-18(1) AC-2(11) AC-3(10) IA-4(9) IA-5 IA-5(7) IA-7 SA-8(18) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-13(1) SC-13(2) SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8) A.8.16 A.5.16 A.5.17 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.12 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. SA-9(6) SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-28(3) 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-17(10) AC-17(10) AC-17(2) AC-18(1) IA-3(1) IA-4 IA-4(9) IA-7 SA-8(15) SA-8(9) SC-16(2) SC-32(1) SC-7(11) SI-14(3) A.5.16
CM0033 Relay Protection Implement relay and replay-resistant authentication mechanisms for establishing a remote connection or connections on the spacecraft bus. AC-17(10) AC-17(10) IA-2(8) IA-3 IA-3(1) IA-4 IA-7 SC-13 SC-23 SC-7 SC-7(11) SC-7(18) SI-10 SI-10(5) SI-10(6) SI-3(8) 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 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) SA-8(18) SA-8(9) SA-9(6) SC-13 SC-16(2) SC-16(3) SI-19(4) SI-4(10) SI-4(25) A.5.14 A.8.22 A.8.23 A.8.11 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 SC-10 SI-14(3) 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) SC-7 SI-3(8) 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.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26
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) SC-7 SI-3(8) A.8.16 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-3(11) IA-4(9) IA-5 A.8.4 A.5.16 A.5.17
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) 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(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-6 SI-7(17) SI-7(8) 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.7 A.8.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16
CM0042 Robust Fault Management Ensure fault management system cannot be used against the spacecraft. Examples include: safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of telemetry to cause action from ground, or some sort of proximity operation to cause spacecraft to go into safe mode. Understanding the safing procedures and ensuring they do not put the spacecraft in a more vulnerable state is key to building a resilient spacecraft. CP-4(5) SA-8(24) SC-16(2) SC-24 SC-5 SI-13 SI-17 None
CM0044 Cyber-safe Mode Provide the capability to enter the spacecraft into a configuration-controlled and integrity-protected state representing a known, operational cyber-safe state (e.g., cyber-safe mode). Spacecraft should enter a cyber-safe mode when conditions that threaten the platform are detected.   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 software functions to pre-attack 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 equipment still available after a cyber-attack. The goal is for the spacecraft to resume full mission operations. If not possible, a reduced level of mission capability should be achieved. Cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.                                                  CP-10 CP-10(4) CP-12 CP-2(5) IR-4 IR-4(12) IR-4(3) SA-8(21) SA-8(23) SA-8(24) SC-16(2) SC-24 SC-5 SI-11 SI-17 SI-7(17) A.5.29 A.5.25 A.5.26 A.5.27
CM0048 Resilient Position, Navigation, and Timing If available, use an authentication mechanism that allows GNSS receivers to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. Have fault-tolerant authoritative time sourcing for the spacecraft's clock. The spacecraft should synchronize the internal system clocks for each processor to the authoritative time source when the time difference is greater than the FSW-defined interval. If Spacewire is utilized, then the spacecraft should adhere to mission-defined time synchronization standard/protocol to synchronize time across a Spacewire network with an accuracy around 1 microsecond. SC-16(2) SC-45 SC-45(1) SC-45(2) 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. Note: TRANSEC is that field of COMSEC which deals with the security of communication transmissions, rather than that of the information being communicated. AC-18(5) CP-8 SC-40 SC-40(1) SC-40(3) SC-40(4) SC-5 SC-8(4) A.5.29 A.7.11