Exploit Code Flaws: Operating System

Threat actors may exploit flaws in the operating system code, which controls the storage, memory management, provides resources to the FSW, and controls the bus.

ID: CM0044
Sub-technique of:  EX-0009
Related Aerospace Threat IDs:  SV-SP-7
Related MITRE ATT&CK TTPs:  T1106
Tactic:
Created: 2022/10/19
Last Modified: 2022/10/19

Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0020 Threat modeling Use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. SA-11(2) SA-15(8)
CM0025 Supplier Review Conduct a supplier review prior to entering into a contractual agreement with a contractor (or sub-contractor) to acquire systems, system components, or system services. PM-30 PM-30(1) RA-3(1) SR-11 SR-3(1) SR-3(3) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5(1) SR-5(2) SR-6 SR-6 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.5.21 A.8.30 A.5.20 A.5.21 A.5.23 A.8.29 A.5.22
CM0026 Original Component Manufacturer Components that cannot be procured from the original component manufacturer or their authorized franchised distribution network should be approved by the supply chain board or equivalent to prevent and detect counterfeit and fraudulent parts and materials. AC-20(5) PM-30 PM-30(1) RA-3(1) SR-1 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-3(1) SR-3(3) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5 SR-5(1) SR-5(2) 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 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.21 A.8.30 A.5.20 A.5.21 A.5.23 A.8.29
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
CM0010 Update Software Perform regular software updates to mitigate exploitation risk. Software updates may need to be scheduled around operational down times. Release updated versions of the software/firmware systems incorporating security-relevant updates, after suitable regression testing, at a frequency no greater than mission-defined frequency [i.e., 90 days]. CM-3(2) CM-3(7) CM-3(8) CM-4(1) SI-2 A.8.9 A.8.9 A.8.31 A.6.8 A.8.8 A.8.32
CM0011 Vulnerability Scanning Vulnerability scanning is used to identify known software vulnerabilities (excluding custom-developed software - ex: COTS and Open-Source). Utilize scanning tools to identify vulnerabilities in dependencies and outdated software (i.e., software composition analysis). Ensure that vulnerability scanning tools and techniques are employed that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: (1) Enumerating platforms, custom software flaws, and improper configurations; (2) Formatting checklists and test procedures; and (3) Measuring vulnerability impact. CM-10(1) RA-5 RA-5(11) SA-15(7) A.8.8
CM0012 Software Bill of Materials Generate Software Bill of Materials (SBOM) against the entire software supply chain and cross correlate with known vulnerabilities (e.g., Common Vulnerabilities and Exposures) to mitigate known vulnerabilities. Protect the SBOM according to countermeasures in CM0001. CM-10(1) CM-11(3) CM-8 CM-8(7) RA-5(11) A.5.9 A.8.9
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-14 CM-7(8)
CM0016 CWE List Create prioritized list of software weakness classes (e.g., Common Weakness Enumerations), based on system-specific considerations, to be used during static code analysis for prioritization of static analysis results. RA-5 SA-11(1) SA-15(7) A.8.8 A.8.28
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. CA-8 CP-4(5) RA-5(11) SA-11(5) SA-11(8) SA-11(9) SC-2(2) SC-7(29) SR-6(1) SR-6(1)
CM0019 Static Analysis Perform static source code analysis for all available source code looking for system-relevant weaknesses (see CM0016) using no less than two static code analysis tools. RA-5 SA-11(1) SA-15(7) A.8.8 A.8.28
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-3(13) AC-3(15) AC-4(2) AC-6 CA-3(6) CM-7 CM-7(8) SA-17(7) SA-8(14) SA-8(15) SA-8(9) SC-2(2) SC-32(1) SC-49 SC-50 SC-7(29) A.5.15 A.8.2 A.8.18 A.8.19
CM0047 Operating System Security Ensure spacecraft's operating system is scrutinized/whitelisted and has received adequate software assurance previously. The operating system should be analyzed for its attack surface and non-utilized features should be stripped from the operating system. Many real-time operating systems contain features that are not necessary for spacecraft operations and only increase the attack surface. CM-11(3) CM-7 CM-7(5) CM-7(8) CM-7(8) A.8.19 A.8.19
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 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-5 IR-5(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5(3) SC-7(9) SI-10(6) SI-16 SI-17 SI-4 SI-4(10) SI-4(11) SI-4(16) SI-4(2) 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.7 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-4(5) SA-8(24) SC-16(2) SC-24 SI-13 SI-17
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(5) IR-4 IR-4(12) IR-4(3) SA-8(21) SA-8(23) SA-8(24) SC-16(2) SC-24 SI-11 SI-17 SI-7(17) A.5.29 A.5.25 A.5.26 A.5.27

References