Launch Vehicle Interface

Threat actors may attempt to exploit reduced protections placed on the interfaces between launch vehicles and payloads in order to move from one to the other.

ID: LM-0006
Sub-techniques:  LM-0006.01
Related Aerospace Threat IDs: 
Related MITRE ATT&CK TTPs: 
Created: 2023/04/22
Last Modified: 2023/04/22

Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
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) SC-2(2) SC-32(1) SC-4 SC-49 SC-50 SC-7(29) A.8.11 A.8.10
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) 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
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 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

Indicators of Behavior

ID Name Description STIX Pattern
CSNE-15 Unexpected Communication Between Subsystems Detection of unexpected communication between spacecraft subsystems that should not normally interact directly on the same bus, potentially indicating lateral movement by a threat actor across a flat architecture. For example, a subsystem could attempt to modify the watchdog timer or other onboard values. [x-opencti-bus-traffic:src_ref.subsystem != 'expected_subsystem' AND x-opencti-bus-traffic:dst_ref.subsystem != 'authorized_subsystem']
CSNE-19 Unexpected High-Priority Messages on the CAN Bus Detection of unexpected high-priority CAN messages (lower message IDs) originating from unauthorized subsystems. This may indicate that a threat actor is injecting high-priority messages to dominate the CAN bus and manipulate subsystem communications. [x-opencti-bus-traffic:can_message_id < 'expected_lowest_priority' AND x-opencti-bus-traffic:src_ref.subsystem != 'authorized_subsystem']
CSNE-25 CAN Bus Error Frames Detected Across Multiple Nodes Detection of a high number of CAN error frames from multiple nodes, indicating that an attacker might be deliberately causing errors to disrupt communication on the bus or cause certain subsystems to enter error-passive or bus-off states. [x-opencti-can-error-frame:error_count > 'threshold' AND bus-traffic:src_ref.subsystem != 'authorized_subsystem']
CSNE-26 Frequent CAN Arbitration Loss by Critical Subsystems Detection of critical subsystems repeatedly losing CAN arbitration, which may indicate that an attacker is exploiting CAN�s arbitration mechanism by sending high-priority (low-ID) messages to suppress critical subsystem communication. [x-opencti-can-arbitration:loss_count > 'threshold' AND x-opencti-can-arbitration:losing_node = 'critical_subsystem']
CSNE-31 Specially Crafted CAN Messages Sent to Critical Subsystems Detection of specially crafted CAN messages targeting critical subsystems with unexpected message IDs or payloads, suggesting an attacker is trying to inject malicious commands to compromise key systems. [x-opencti-bus-traffic:can_message_id = 'unexpected_value' AND x-opencti-bus-traffic:dst_ref.role = 'critical_subsystem']
CSNE-32 Repeated CAN Message Spoofing Detected Between Subsystems Detection of CAN messages with legitimate message IDs but originating from unauthorized subsystems, indicating that an attacker is spoofing CAN messages to imitate legitimate subsystems and move laterally across the spacecraft. [x-opencti-bus-traffic:x_can_message_id = 'legitimate_id' AND x-opencti-bus-traffic:src_ref.subsystem != 'authorized_subsystem']
CSNE-33 Unusual Communication Between Payload and Critical Subsystems Detection of unusual communication between a payload and critical subsystems , indicating that the flat bus architecture may be exploited to allow a payload to interact with sensitive parts of the spacecraft. [x-opencti-bus-traffic:src_ref.role = 'payload' AND x-opencti-bus-traffic:dst_ref.role = 'critical_subsystem']

References