Modify On-Board Values: Command & Data Handling Subsystem

Threat actors may target the onboard values for the Command and Data Handling Subsystem of the victim spacecraft. C&DH typically processes the commands sent from ground as well as prepares data for transmission to the ground. Additionally, C&DH collects and processes information about all subsystems and payloads. Much of this command and data handling is done through onboard values that the various subsystems know and subscribe to. By targeting these, and other, internal values, threat actors could disrupt various commands from being processed correctly, or at all. Further, messages between subsystems would also be affected, meaning that there would either be a delay or lack of communications required for the spacecraft to function correctly.

ID: CM0038
Sub-technique of:  EX-0012
Related Aerospace Threat IDs:  SV-IT-2 | SV-IT-5 | SV-SP-9 | SV-MA-3
Related MITRE ATT&CK TTPs: 
Related ESA SPACE-SHIELD TTPs:  T2010 | T2054 | T2054.001
Tactic:
Created: 2022/10/19
Last Modified: 2023/05/08

Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0039 Least Privilege Employ the principle of least privilege, allowing only authorized processes which are necessary to accomplish assigned tasks in accordance with system functions. Ideally maintain a separate execution domain for each executing process. AC-2 AC-3(13) AC-3(15) AC-4(2) AC-6 CA-3(6) CM-7 CM-7(4) CM-7(8) PL-8 PL-8(1) SA-17(7) SA-3 SA-4(9) SA-8 SA-8(13) SA-8(14) SA-8(15) SA-8(3) SA-8(4) SA-8(9) SC-2(2) SC-32(1) SC-49 SC-50 SC-7(29) D3-MAC D3-EI D3-HBPI D3-KBPI D3-PSEP D3-MBT D3-PCSV D3-LFP D3-UBA A.5.16 A.5.18 A.8.2 A.5.15 A.8.2 A.8.18 A.8.19 A.8.19 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
CM0069 Process White Listing Simple process ID whitelisting on the firmware level could impede attackers from instigating unnecessary processes which could impact the spacecraft CM-11 CM-7(5) PL-8 PL-8(1) SI-10(5) D3-MAC D3-EAL D3-EDL A.8.19 A.8.19 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(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) 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
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-2 CP-4(5) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(24) SA-8(3) SA-8(4) SC-16(2) SC-24 SC-5 SI-13 SI-17 D3-AH D3-EHPV D3-PSEP D3-PH D3-SCP 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
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 CP-2(5) IR-4 IR-4(12) IR-4(3) PL-8 PL-8(1) SA-3 SA-8 SA-8(10) SA-8(12) SA-8(13) SA-8(21) SA-8(23) SA-8(24) SA-8(3) SA-8(4) SC-16(2) SC-24 SC-5 SI-11 SI-17 SI-7(17) D3-PH D3-EI D3-NI D3-BA 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
CM0038 Segmentation Identify the key system components or capabilities that require isolation through physical or logical means. Information should not be allowed to flow between partitioned applications unless explicitly permitted by security policy. Isolate mission critical functionality from non-mission critical functionality by means of an isolation boundary (implemented via partitions) that controls access to and protects the integrity of, the hardware, software, and firmware that provides that functionality. Enforce approved authorizations for controlling the flow of information within the spacecraft and between interconnected systems based on the defined security policy that information does not leave the spacecraft boundary unless it is encrypted. Implement boundary protections to separate bus, communications, and payload components supporting their respective functions. AC-4 AC-4(14) AC-4(2) AC-4(24) AC-4(26) AC-4(31) AC-4(32) AC-4(6) AC-6 CA-3 CA-3(7) PL-8 PL-8(1) SA-3 SA-8 SA-8(13) SA-8(15) SA-8(18) SA-8(3) SA-8(4) SA-8(9) SC-16(3) SC-2(2) SC-3 SC-32(1) SC-39 SC-4 SC-49 SC-50 SC-6 SC-7(20) SC-7(21) SC-7(29) SC-7(5) SI-17 D3-NI D3-BDI D3-NTF D3-ITF D3-OTF D3-EI D3-HBPI D3-KBPI D3-MAC D3-RRID D3-EAL D3-EDL D3-IOPR D3-SCF A.5.14 A.8.22 A.8.23 A.5.15 A.8.2 A.8.18 A.5.14 A.8.21 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28

References