Modify On-Board Values

Threat actors may perform specific commands in order to modify onboard values that the victim spacecraft relies on. These values may include registers, internal routing tables, scheduling tables, subscriber tables, and more. Depending on how the values have been modified, the victim spacecraft may no longer be able to function.

ID: EX-0012
Related MITRE ATT&CK TTPs: 
Tactic:
Created: 2022/10/19
Last Modified: 2023/05/08

Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0049 Machine Learning Data Integrity When AI/ML is being used for mission critical operations, the integrity of the training data set is imperative. Data poisoning against the training data set can have detrimental effects on the functionality of the AI/ML. Fixing poisoned models is very difficult so model developers need to focus on countermeasures that could either block attack attempts or detect malicious inputs before the training cycle occurs. Regression testing over time, validity checking on data sets, manual analysis, as well as using statistical analysis to find potential injects can help detect anomalies. AC-3(11) SC-28 SC-28(1) SC-8 SC-8(2) SI-7 SI-7(1) SI-7(2) SI-7(5) SI-7(6) SI-7(8) A.8.4 A.5.10 A.5.14 A.8.20 A.8.26 A.5.10 A.5.33
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
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) A.8.19 A.8.19 A.5.8
CM0056 Data Backup Implement disaster recovery plans that contain procedures for taking regular data backups that can be used to restore critical data. Ensure backups are stored off system and is protected from common methods adversaries may use to gain access and destroy the backups to prevent recovery. CP-9 SA-3 SA-8 A.5.29 A.5.33 A.8.13 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
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 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) 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
CM0066 Model-based System Verification Real-time physics model-based system verification of state could help to verify data input and control sequence changes 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
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. CP-2 PE-20 PL-8 PL-8(1) SA-9 SC-16(2) SC-45 SC-45(1) SC-45(2) 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.10 A.5.8 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21

Indicators of Behavior

ID Name Description STIX Pattern
UACE-3 Legitimate Command with Malicious Parameters Targeting Subsystems A legitimate command is sent, but with parameters that exceed safe thresholds for a subsystem or component on the spacecraft. This could include commands that affect critical subsystems like power distribution, attitude control, or thermal regulation, potentially leading to damage, instability, or malfunction. The misuse of valid parameters across different subsystems can result in severe operational impact or hardware degradation. [x-opencti-command-log:command_type = 'legitimate_command' AND x-opencti-command-log:target_subsystem != 'expected_subsystem' AND x-opencti-command-log:parameter_value > 'safe_threshold']
UACE-16 Irregular Orbit Maneuver Commands Detected on Attitude Control Detection of unauthorized or irregular command executions within the Attitude Control System of a spacecraft, indicating possible attempts to manipulate the spacecraft's orientation and trajectory. These activities can suggest malicious intent to disrupt or take control of the spacecraft's operations. [x-opencti-command:observable_type = 'adcs-command' AND x-opencti-command:value != 'expected_orbit_maneuver_commands']
UACE-17 Abnormal Burn Duration Detected in Propulsion Subsystem Detection of an attack targeting the propulsion subsystem by altering the burn duration. Anomalous burn durations (either too long or too short) may indicate unauthorized modification of propulsion commands or control logic, potentially leading to orbital instability or resource wastage. [x-opencti-propulsion-system:burn_duration > 'expected_max_duration' OR x-opencti-propulsion-system:burn_duration < 'expected_min_duration'] 
UACE-18 Suspicious Burn Sequence Executed Outside Planned Timeline Detection of an unauthorized burn sequence executed outside the expected timeline. This could indicate a command injection or tampering with the control logic of the propulsion system to disrupt planned orbital adjustments. [x-opencti-propulsion-system:burn_command_time != 'expected_burn_time']
UACE-19 Unexpected Thrust Direction Detected in Propulsion Subsystem Detection of an attack where the thrust direction has been altered outside of the expected parameters. Unauthorized changes to the thrust direction can lead to misalignment of the spacecraft�s trajectory and potential mission failure. [x-opencti-propulsion-system:thrust_direction != 'expected_direction' AND x-opencti-propulsion-system:burn_command_issued = 'true'] 
UACE-22 Multiple Consecutive Burn Commands Exceeding Duration Limits This IOC detects repeated burn commands where the duration exceeds safe operational limits. Multiple consecutive commands with long durations may indicate a deliberate attack aiming to destabilize the spacecraft�s orbit or waste fuel resources. [x-opencti-propulsion-system:burn_duration > 'expected_duration' AND x-opencti-propulsion-system:consecutive_burn_commands > 'threshold_value']
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']
MIRE-6 Unexpected Modification of Memory Location Associated with Telemetry Data Detection of an unexpected modification in the memory block associated with telemetry data. The system identifies abnormal write operations in memory locations that store telemetry information before it is transmitted, suggesting manipulation by malware. Adversaries may change telemetry before downlink in order to prevent the ground from being aware of malware being on the spacecraft. [x-opencti-memory:block = 'telemetry_memory_block' AND x-opencti-memory:write_operation = 'unexpected' AND x-opencti-memory:modification_time != 'authorized_time']
SMSR-4 ADCS Onboard Values Manipulation Detection of suspicious modifications to the onboard values of the Attitude Determination and Control subsystem, such as sudden changes in quaternion values, unexpected gyro readings, or abnormal magnetometer values. Such anomalies could indicate unauthorized modifications by threat actors aiming to manipulate spacecraft orientation. The intent might be to force the automated control system to perform unnecessary corrective maneuvers, leading to resource depletion or potential mission failure. [x-opencti-telemetry-data:telemetry_type = 'attitude-control' AND x-opencti-telemetry-data:parameter_name IN ('quaternion','gyro_reading','magnetometer_value') AND x-opencti-telemetry-data:value_change > 'threshold_value' AND x-opencti-telemetry-data:change_rate > 'expected_rate']
SMSR-5 Unexpected Spacecraft Telemetry or Movement Detected on Attitude Detection of unexpected telemetry or movement data from the spacecraft's Attitude Control System that deviates from planned and expected orbital maneuvers. Such anomalies may indicate unauthorized control commands or manipulation, potentially pointing to a cyber attack aimed at altering the spacecraft's intended course or orientation. [x-opencti-telemetry:movement_type = 'orbit-deviation' AND x-opencti-telemetry:deviation_value > 'threshold_value']
SMSR-6 Unauthorized Fault Management Configuration Change Detected Outside Expected Time Monitors for fault management configuration modifications occurring at unauthorized times, which may indicate an attempt to disable critical protections during vulnerable operational states. [x-opencti-fault-management:configuration != 'baseline_configuration' AND x-opencti-fault-management:modification_time != 'authorized_time_window']
SMSR-7 Unauthorized Star Map Changes in Star Trackers Detection of unauthorized changes to star maps within star trackers. This can result in incorrect positional readings and severe degradation or mission loss. The pattern monitors for changes in the star map data using hash verification, with unexpected hashes indicating potential unauthorized modification. Integrity is paramount for Star Trackers to work properly. [x-opencti-onboard-data:component = 'star_tracker' AND x-opencti-onboard-data:data_type = 'star_map' AND x-opencti-onboard-data:hashes != 'expected_star_map_hash']
SMSR-8 Sudden Orbit Correction Detected Outside of Planned Windows Detection of an unplanned orbit adjustment executed by the Attitude Determination and Control subsystem. This indicates that the system may have been manipulated to trigger unnecessary orbit corrections, leading to resource wastage. [x-opencti-orbit-adjustment:status = 'active' AND x-opencti-orbit-adjustment:scheduled != 'TRUE']
SMSR-16 Unexpected Fault Management Process Termination Monitors the fault management service for unexpected termination, which could indicate a targeted attempt to disable protections. [process:name = 'fault_management_service' AND process:status != 'running']
DISE-3 Multiple Failed Attempts to Access Encrypted Data Multiple failed attempts to access files or data stored on the spacecraft, indicating that critical data has POTENTIALLY been rendered inaccessible due to ransomware activity. This pattern focuses on detecting repeated access failures. The data could be corrupted via just environmental issues but could also indicate malicious activity as well. [file:status = 'unreadable' AND file:access_attempts > 'threshold']
DISE-5 Unusual File Encryption Activity Detected Detection of files being encrypted with an unknown or unexpected encryption algorithm, potentially indicating ransomware activity on spacecraft systems. This can involve newly created or modified files with unusual extensions such as .encrypted or .locked. - if ransomware were to include those extenstions then you would att AND file:extension IN ('.encrypted', '.locked') to the pattern to become. [file:encryption_algorithm != 'none' AND file:extension IN ('.encrypted', '.locked') AND file:modified_time = 'recent'] [file:x_encryption_algorithm != 'none' AND file:modified_time = 'recent']
DISE-7 Attitude Sensor Data and Actuator Behavior Detection of sudden changes or spikes in sensor data that do not correlate with known physical conditions, indicating potential anomalies. Such behavior, when combined with unexpected actuator operations like unintended thruster firings or erratic reaction wheel speeds, suggests possible malicious interference or system faults. This can be detected through baselining/normalization of spacecraft speeds using machine learning algorithms to identify deviations from expected patterns. [x-opencti-sensor-data:sensor_type = 'inertial-measurement-unit' AND x-opencti-sensor-data:anomaly_value > 'threshold_value'] AND [x-opencti-actuator:actuator_type IN ('thruster','reaction-wheel') AND x-opencti-actuator:operation_status = 'unexpected']
DISE-9 Unexpected Change in Gyroscope Sensor Data Detection of an unexpected, large deviation in gyroscope sensor data that exceeds normal operational thresholds, indicating potential tampering with the Attitude Determination and Control subsystem. This may lead to automated correction tasks being triggered unnecessarily. [x-opencti-sensor-data:sensor_type = 'gyroscope' AND x-opencti-sensor-data:reading_delta > 'threshold']
DISE-10 Abnormal Data Flow in Attitude Control Telemetry Detection of abnormal telemetry data rates in the Attitude Determination and Control subsystem, indicating potential manipulation of onboard values or interference with the control signals. This can trigger unnecessary corrective maneuvers or system malfunctions. An alternative pattern could be [x-opencti-telemetry-data:telemetry_type = 'attitude-control' AND (x-opencti-telemetry-data:parameter_name = 'quaternion' OR x-opencti-telemetry-data:parameter_name = 'gyro_reading' OR x-opencti-telemetry-data:parameter_name = 'magnetometer_value') AND x-opencti-telemetry-data:value_change > 'threshold_value' AND x-opencti-telemetry-data:change_rate > 'expected_rate'] [x-opencti-telemetry:telemetry_type = 'attitude_control' AND x-opencti-telemetry:data_rate > 'expected_rate']
DISE-17 Unauthorized Modification of Critical Onboard Values This monitors for the unauthorized modification of critical onboard data elements essential for spacecraft control, telemetry, and security functions. Changes detected in these values could indicate tampering, defensive evasion, or system compromise. The monitored data elements could include and are derived from https://sparta.aerospace.org/technique/DE-0003/: Vehicle Command Counter (VCC) Rejected Command Counter Command Receiver On/Off Mode Command Receivers Received Signal Strength Command Receiver Lock Modes Telemetry Downlink Modes Cryptographic Modes Received Commands System Clock GPS Ephemeris Watchdog Timer (WDT) Poisoned AI/ML Training Data This is intentionally broad to ensure coverage of multiple subsystems where unauthorized modifications could disrupt normal spacecraft operations or create vulnerabilities for further exploitation.  [x-opencti-data-element:modification_detected = true AND x-opencti-data-element:modification_source != 'trusted_source']

References