Overflow Audit Log

Threat actors may seek to exploit the inherent nature of flight software and its limited capacity for event logging/storage between downlink windows as a means to conceal malicious activity.

ID: DE-0010
Sub-techniques: 
Related Aerospace Threat IDs:  SV-SP-1
Related MITRE ATT&CK TTPs: 
Tactic:
Created: 2023/04/22
Last Modified: 2023/04/22

Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0034 Monitor Critical Telemetry Points Monitor defined telemetry points for malicious activities (i.e., jamming attempts, commanding attempts (e.g., command modes, counters, etc.)). This would include valid/processed commands as well as commands that were rejected. Telemetry monitoring should synchronize with ground-based Defensive Cyber Operations (i.e., SIEM/auditing) to create a full space system situation awareness from a cybersecurity perspective. AC-17(1) AU-3(1) CA-7(6) IR-4(14) PL-8 PL-8(1) SA-8(13) SC-16 SC-7 SI-3(8) A.8.16 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26
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

Indicators of Behavior

ID Name Description STIX Pattern
DISE-1 File or Data Integrity Check Failure Monitors the cryptographic integrity of data (files, payload data, configuration file, logs, etc.) to ensure it remains unmodified during data storage or transmission. It is important during engineering to determine the critical data items that need integrity protection. Some example are discussed in evasion technique https://sparta.aerospace.org/technique/DE-0003/ [file:hashes != 'expected_hash_value' AND file:name = 'data_file']
DISE-4 Storage Exhaustion (Disk Full) Attackers may attempt to fill up storage devices in order to have impact on the spacecraft. Storage is sometimes a limited commodity and simply filling a disk can prevent telemetry, payload data, etc. from being collected. [x-opencti-file-system:available_space < 'threshold']
DISE-6 Suspicious Activity Leading to Storage Exhaustion Detection of activity which may be part of a malicious attempt to fill the storage device on the spacecraft. Without storage, this would prevent the flight software from writing telemetry data or payload data, leading to a potential denial-of-service (DoS) condition . [x-opencti-file-system:available_space < 'threshold' AND process:x_execution_time != 'authorized_time']
DISE-14 Unexpected Audit Log Rotation Monitors for unauthorized or unexpected log rotation events that could lead to data loss or concealment of malicious activity. [x-opencti-audit-log:rotation_event = 'triggered' AND x-opencti-audit-log:timestamp != 'expected_time']
DISE-15 High Volume of Audit Log Entries Detected Monitors for excessive audit log activity, which could be indicative of log flooding or attempts to force log overflow to conceal malicious activity. [x-opencti-audit-log:event_count > 'threshold' AND x-opencti-audit-log:timestamp = 'recent_period']
DISE-16 Audit Log Capacity Limit Reached Monitors for instances where the flight software's, or overall system's, audit log has reached its maximum capacity, potentially preventing the logging of further events and concealing ongoing malicious activity. [x-opencti-audit-log:capacity_used >= 'max_capacity']

References