Threat actors may manipulate memory (boot, RAM, etc.) in order for their malicious code and/or commands to remain on the victim spacecraft. The spacecraft may have mechanisms that allow for the automatic running of programs on system reboot, entering or returning to/from safe mode, or during specific events. Threat actors may target these specific memory locations in order to store their malicious code or file, ensuring that the attack remains on the system even after a reset.
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
| CM0028 | Tamper Protection | Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment. | AC-14 CA-8(3) CM-7(9) MA-7 PL-8 PL-8(1) PL-8(2) PM-30 PM-30(1) RA-3(1) SA-10(3) SA-10(4) SA-11 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(13) SA-9 SC-51 SR-1 SR-1 SR-10 SR-11 SR-11(3) SR-2 SR-2(1) SR-3 SR-4(3) SR-4(4) SR-5 SR-5 SR-5(2) SR-6(1) SR-9 SR-9(1) | A.5.8 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 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.20 A.5.21 A.5.23 A.8.29 | ||
| CM0015 | Software Source Control | Prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code. | CM-11 CM-14 CM-2 CM-4 CM-7(8) SA-10(4) SA-11 SA-3 SA-4(5) SA-4(9) SA-8 SA-9 | A.8.9 A.8.9 A.8.19 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30 | ||
| CM0018 | Dynamic Analysis | Employ dynamic analysis (e.g., using simulation, penetration testing, fuzzing, etc.) to identify software/firmware weaknesses and vulnerabilities in developed and incorporated code (open source, commercial, or third-party developed code). Testing should occur (1) on potential system elements before acceptance; (2) as a realistic simulation of known adversary tactics, techniques, procedures (TTPs), and tools; and (3) throughout the lifecycle on physical and logical systems, elements, and processes. FLATSATs as well as digital twins can be used to perform the dynamic analysis depending on the TTPs being executed. Digital twins via instruction set simulation (i.e., emulation) can provide robust environment for dynamic analysis and TTP execution. | CA-8 CP-4(5) RA-3 RA-5(11) SA-11 SA-11(5) SA-11(8) SA-11(9) SA-3 SA-8 SC-2(2) SC-7(29) SI-3 SR-6(1) SR-6(1) | 6.1.2 8.2 9.3.2 A.8.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.8.7 | ||
| CM0021 | Software Digital Signature | Prevent the installation of Flight Software without verification that the component has been digitally signed using a certificate that is recognized and approved by the mission. | AC-14 CM-11 CM-11(3) CM-14 CM-14 IA-2 SA-10(1) SA-11 SA-4(5) SA-9 SI-7 SI-7(12) SI-7(15) | A.8.19 A.5.16 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30 | ||
| CM0023 | Configuration Management | Use automated mechanisms to maintain and validate baseline configuration to ensure the spacecraft's is up-to-date, complete, accurate, and readily available. | CM-11(3) CM-2 CM-3(7) CM-3(8) CM-4 CM-5 MA-7 SA-10 SA-10(7) SA-11 SA-3 SA-4(5) SA-4(9) SA-8 SR-11(2) | A.8.9 A.8.9 A.8.9 A.8.9 A.8.2 A.8.4 A.8.9 A.8.19 A.8.31 A.8.3 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.9 A.8.28 A.8.30 A.8.32 A.8.29 A.8.30 | ||
| 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 | ||
| 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 | ||
| CM0014 | Secure boot | Software/Firmware must verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order. The trusted boot/RoT computing module should be implemented on radiation tolerant burn-in (non-programmable) equipment. | AC-14 PL-8 PL-8(1) SA-8(10) SA-8(12) SA-8(13) SA-8(3) SA-8(4) SC-51 SI-7(9) | A.5.8 | ||
| Priority 1 | Priority 2 | Priority 3 | Priority 4 |
| CWE-172: Encoding Error | CWE-345: Insufficient Verification of Data Authenticity | CWE-200: Information Exposure | CWE-669: Incorrect Resource Transfer Between Spheres |
| ID | Name | Description | STIX Pattern |
| MIRE-1 | Anomalous Flash Write Operations Detected in Short Timeframe | Detection of a high number of flash write operations in a short timeframe, indicating a coordinated effort to overwrite the spacecraft's flash memory entirely. This behavior is typical of wiper malware aiming to destroy all flash data. | [x-opencti-memory:block = 'flash_memory' AND x-opencti-memory:write_operation_count > 'threshold' AND x-opencti-memory:write_duration < 'threshold'] |
| MIRE-2 | Anomalous Flash/EEPROM Memory Checksums Detected | Detection of a checksum mismatch for the flight software's flash / eeprom memory partitions. This could indicate that both the primary and redundant partitions have been corrupted by the malicious action, leading to a permanent denial of service (DoS). | [x-opencti-memory:table_ref.name = 'flash_memory' OR x-opencti-memory:table_ref.name = 'eeprom_memory' AND x-opencti-memory:checksum != 'expected_checksum'] |
| MIRE-3 | Unusual Access Frequency to Critical Memory Regions | Monitors for excessive access to critical memory regions, which may indicate malicious activities. On a spacecraft, consistent and unexpected access (read or write) to critical memory regions could indicate malicious activities by malware. | [x-opencti-memory:access_frequency > 'expected_rate' AND x-opencti-memory:memory_region != 'expected'] |
| MIRE-4 | Skipped Boot Integrity Check | Detects cases where boot / firmware integrity checks are bypassed, potentially due to a glitching or other attacks. | [x-opencti-memory:block = 'boot' AND x-opencti-memory:integrity_check = 'skipped'] |
| MIRE-5 | Memory Corruption Detected in Flight Software | Detection of memory corruption in spacecraft flight software components, potentially caused by buffer overflow or other memory management vulnerabilities being exploited by threat actors. | [x-opencti-memory:status = 'corrupted' AND x-opencti-software:component = 'flight_software'] |
| MIRE-7 | Unexpected Memory Value Write or Modification | Detection of unexpected or unauthorized modifications to onboard memory values during the execution. This could be done during updates, configuration changes, or direct commanding. This attack could potentially leading to corruption of system values or triggering malicious behavior. An adversary may inject malicious information in the Flash or EEPROM or area where the FSW/Software is stored during an update. | [x-opencti-memory:write_operation = 'unexpected_write' AND x-opencti-memory:value != 'expected'] |
| MIRE-9 | Failed Boot Memory Validation | Detection of boot memory validation failure, indicating that boot memory has been tampered with to bypass internal processes. This is similar to integrity failure detection but this is the overall boot process failing validation using whatever steps are established (i.e., digital signature, cryptography, etc.) | [x-opencti-system:boot_memory_validation = 'failed'] |
| MIRE-17 | Unauthorized System Call to Open Flash Memory Blocks (/dev/mtd) | Detection of unauthorized system calls to access flash memory devices or partitions (/dev/mtd%). These system calls indicate that a malicious script or process is attempting to modify or read flash memory, potentially targeting critical system areas like firmware or configuration data during an attack. | [process:image_ref.name = 'open' AND file:path LIKE '/dev/mtd%' AND file:access_time != 'authorized_access_time'] |
| SIUU-2 | Unexpected System Integrity Failures in Software | Detection of failed integrity checks during spacecraft software execution, potentially indicating that the software has been modified to include a backdoor or malicious code | [x-opencti-software:integrity_check = 'failed' AND x-opencti-software:name = 'spacecraft_software'] |
| SIUU-8 | Malicious Code via New Process | Code execution detected from an unexpected source / process, possibly indicating unauthorized or malicious code running on the spacecraft. | [x-opencti-logs:event_type = 'code_execution' AND x-opencti-processor-usage:activity_type = 'unexpected' AND x-opencti-processor-usage:process_name NOT IN ('list_of_known_processes')] |
| SIUU-9 | Unexpected Software Crash Detected in Flight Software | Detection of unexpected crashes in flight software, potentially caused by attempts to exploit software vulnerabilities or coding flaws that lead to system instability. Repeated or unexplained crashes may indicate ongoing exploitation attempts targeting the spacecraft's flight control systems. | [x-opencti-software:status = 'crashed' AND x-opencti-software:component != 'expected_crash_behavior'] |
| SIUU-21 | Detection of Anomalous Process Behavior Due to Code Exploitation | Detection of unexpected or anomalous behavior in onboard software processes, which may indicate an attempt to exploit a software flaw. This can involve the execution of unusual commands, system calls, memory manipulation, or deviations from normal process behavior. An alternative way to view this could be [process:name != 'expected_process_name' AND process:binary_ref.name != 'trusted_component'] but the current pattern focuses on the process behavior. | [x-opencti-process:behavior != 'expected_behavior' AND x-opencti-process:software_component != 'trusted_component'] |
| SIUU-22 | Abnormal Subsystem Behavior Following Malicious Code Execution | Detection of abnormal or unexpected behavior in critical spacecraft subsystems (e.g., attitude control, power management) after malicious code execution. This pattern indicates a direct impact on spacecraft subsystems following the activation of the malicious code. | [x-opencti-subsystem-log:status != 'expected' AND process:image_ref.name = 'malicious_process'] |
| SMSR-1 | Sensor Data Exceeds Operational Ranges | Tracks sensor readings that exceed acceptable operational limits, potentially disrupting spacecraft functionality. Detects sensor data values falling outside predefined operational ranges, potentially indicating spoofing. | [x-opencti-sensor-data:value NOT IN ('expected_min','expected_max')] |