Exploit Lack of Bus Segregation

Threat actors may exploit victim spacecraft on-board flat architecture for lateral movement purposes. Depending on implementation decisions, spacecraft can have a completely flat architecture where remote terminals, sub-systems, payloads, etc. can all communicate on the same main bus without any segmentation, authentication, etc. Threat actors can leverage this poor design to send specially crafted data from one compromised devices or sub-system. This could enable the threat actor to laterally move to another area of the spacecraft or escalate privileges (i.e., bus master, bus controller)

ID: LM-0002
Sub-techniques: 
Related Aerospace Threat IDs:  SV-AC-6
Related MITRE ATT&CK TTPs: 
Created: 2022/10/19
Last Modified: 2023/05/08

Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0022 Criticality Analysis Conduct a criticality analysis to identify mission critical functions, critical components, and data flows and reduce the vulnerability of such functions and components through secure system design. Focus supply chain protection on the most critical components/functions. Leverage other countermeasures like segmentation and least privilege to protect the critical components. CP-2 CP-2(8) PL-8 PL-8(1) PM-11 PM-17 PM-30 PM-30(1) PM-32 RA-3 RA-3(1) RA-9 RA-9 SA-11 SA-15(3) SA-2 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(3) SC-32(1) SC-7(29) SR-1 SR-1 SR-2 SR-2(1) SR-3 SR-3(2) SR-3(3) SR-5(1) SR-7 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 A.5.8 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 6.1.2 8.2 9.3.2 A.8.8 A.5.22 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 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.22
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 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) 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
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
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(9) SA-9(6) SC-13 SC-16 SC-16(2) SC-16(3) SC-8(1) SC-8(3) SI-19(4) SI-4(10) SI-4(25) 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(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
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) 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. SI-4 SI-4(2) A.8.16
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
UACE-23 Unusual Commands from Subsystem Acting as Bus Controller (1553) Detection of unusual commands being issued by a subsystem acting as a bus controller, indicating that a threat actor may have escalated privileges or have access to the bus within the flat bus architecture to issue commands from unauthorized subsystems. [x-opencti-bus-master:role = 'subsystem' AND x-opencti-bus-master:commands != 'expected_commands']
CSNE-14 Unusual Data Transmission Between SpaceWire Routing Switches Detection of unusual data transmissions from a SpaceWire routing switch to critical subsystems, potentially indicating the exploitation of a flat architecture to inject crafted data into sensitive areas of the spacecraft. [x-opencti-bus-traffic:src_ref.role = 'routing_switch' AND x-opencti-bus-traffic:dst_ref.role = 'critical_subsystem']
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-27 Unexpected Communication Between SpaceWire Nodes Detection of unexpected communication between SpaceWire nodes that are not supposed to interact, potentially indicating lateral movement across the spacecraft's flat bus architecture. [x-opencti-bus-traffic:src_ref.spacewire_node != 'expected_node' AND x-opencti-bus-traffic:dst_ref.spacewire_node != 'authorized_node']
CSNE-30 Unauthorized Device Acting as Bus Controller (1553) Detection of an unauthorized device acting as the bus controller, potentially indicating privilege escalation by a threat actor aiming to control the spacecraft�s communication bus. [x-opencti-bus-controller:role = 'bus_controller' AND x-opencti-bus-controller:device != 'authorized_bus_controller'] 
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']
CSNE-34 Unusual Data Transmission from Remote Terminal to Subsystem. (1553) Detection of unusual data transmission from a remote terminal to a critical subsystem using unexpected protocols, indicating that the flat bus architecture is being leveraged to send malicious data across the spacecraft. [x-opencti-bus-traffic:src_ref.role = 'remote_terminal' AND x-opencti-bus-traffic:dst_ref.role = 'critical_subsystem' AND x-opencti-bus-traffic:protocols[*] != 'expected_protocol']

References