Visiting Vehicle Interface(s)

Threat actors may move from one spacecraft to another through visiting vehicle interfaces. When a vehicle docks with a spacecraft, many programs are automatically triggered in order to ensure docking mechanisms are locked. This entails several data points and commands being sent to and from the spacecraft and the visiting vehicle. If a threat actor were to compromise a visiting vehicle, they could target these specific programs in order to send malicious commands to the victim spacecraft once docked.

ID: LM-0004
Sub-techniques: 
Notional Risk (H | M | L):  21 | 17 | 12
Related Aerospace Threat IDs:  SV-AC-1 | SV-AC-5
Related MITRE ATT&CK TTPs: 
Related ESA SPACE-SHIELD TTPs: 
Created: 2022/10/19
Last Modified: 2024/02/29

Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
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(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
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(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
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
CM0040 Shared Resource Leakage Prevent unauthorized and unintended information transfer via shared system resources. Ensure that processes reusing a shared system resource (e.g., registers, main memory, secondary storage) do not have access to information (including encrypted representations of information) previously stored in that resource during a prior use by a process after formal release of that resource back to the system or reuse AC-4(23) AC-4(25) SA-8(19) SA-8(2) SA-8(5) SA-8(6) SC-2(2) SC-3(4) SC-32(1) SC-4 SC-49 SC-50 SC-7(29) D3-MAC D3-PAN D3-HBPI A.8.11 A.8.10
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
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(5) 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(19) 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
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) 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(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
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-3(4) SC-32 SC-32(1) 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 SI-4(7) 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
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

References