CM0014

Compromise boot memory


Informational References

  • CENTRA Volume I - Cyber Content of Satellites
ID: CM0014
DiD Layer: SBC
CAPEC #:  458 | 532 | 638
NIST Rev5 Control Tag Mapping:  CA-7 | CA-7(6) | CM-7 | CM-7(8) | CM-7(9) | CM-14 | PM-30 | RA-3 | RA-3(1) | RA-10 | SA-3 | SA-3(1) | SA-8 | SA-8(21) | SA-8(23) | SA-8(24) | SI-7 | SI-7(9) | SI-7(17) | SR-4 | SR-4(3) | SR-4(4) | SR-5 | SR-5(2) | SR-9 | SR-9(1) | SR-11 | SR-11(3)
Lowest Threat Tier to
Create Threat Event:  
VI
Notional Risk Rank Score: 

High-Level Requirements

The spacecraft shall establish a root of trust on the boot process for the flight software.

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
The [spacecraft] boot firmware must validate the boot loader, boot configuration file, and operating system image, in that order, against their respective signatures.{SV-IT-3}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)} A signature is ~770 bits long. No requirement is imposed on the storage location of signatures.
The [spacecraft] boot 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.{SV-IT-3}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)} These three items were chosen because they’re intended to be static values (once properly set up) but are in volatile storage. Also, the Boot ROM can’t be modified, so there’s no reason to check a signature.
The [spacecraft] shall perform attestation at each stage of startup and ensure overall trusted boot regime (i.e., root of trust).{SV-IT-3}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10),SI-7(17)} It is important for the computing module to be able to access a set of functions and commands that it trusts; that is, that it knows to be true. This concept is referred to as root of trust (RoT) and should be included in the spacecraft design. With RoT, a device can always be trusted to operate as expected. RoT functions, such as verifying the device’s own code and configuration, must be implemented in secure hardware (i.e., field programmable gate arrays). By checking the security of each stage of power-up, RoT devices form the first link in a chain of trust that protects the spacecraft
The [spacecraft] hardware root of trust must be an ECDSA NIST P-384 public key.{SV-IT-3}{SI-7(9)} No requirement is imposed on uniqueness.
The [spacecraft] hardware root of trust must be loadable only once, post-purchase.{SV-IT-3}{SI-7(9)} No requirement is imposed on preventing hardware readout. The public key belongs to the customer, not the manufacturer, so it must be loaded after purchase. Also, if it can be overwritten, there’s no reason to trust it.
The [spacecraft] shall implement trusted boot/RoT as a separate compute engine controlling the trusted computing platform cryptographic processor.{SV-IT-3}{SI-7(9)}
The [spacecraft] shall implement trusted boot/RoT computing module on radiation tolerant burn-in (non-programmable) equipment.{SV-IT-3}{SI-7(9)}
The [spacecraft] boot firmware must enter a recovery routine upon failing to verify signed data in the trust chain, and not execute or trust that signed data.{SV-IT-3}{SI-7(9),SI-7(10)} No other requirements are imposed on the recovery routine besides not using the failed data. Unverifiable data isn’t trusted and shouldn’t be run. 
The [spacecraft] secure boot mechanism shall be Commercial National Security Algorithm Suite (CNSA) compliant.{SV-IT-3}{SI-7(9),SI-7(10)} No certification process is required (or exists). The CNSA is easy to meet, only restricts algorithm choice, and aids ease-of-use for government customers.
The [spacecraft] shall allocate enough boot ROM memory for secure boot firmware execution.{SV-IT-3}{SI-7(9),SI-7(10)}
The [spacecraft] shall allocate enough SRAM memory for secure boot firmware execution.{SV-IT-3}{SI-7(9),SI-7(10)}
The [spacecraft] shall support the algorithmic construct of Elliptic Curve Digital Signature Algorithm (ECDSA) NIST P-384 + SHA-38 or equivalent strength.{SV-IT-3}{SI-7(9),SI-7(10)} Timing data may suggest cryptographic accelerators are unnecessary. This construct was chosen because (a) it’s in the CNSA suite and (b) it doesn’t require secret values to be stored

Related SPARTA Techniques and Sub-Techniques

ID Name Description
IA-0001 Compromise Supply Chain Threat actors may manipulate or compromise products or product delivery mechanisms before the customer receives them in order to achieve data or system compromise.
IA-0001.02 Software Supply Chain Threat actors may manipulate software binaries and applications prior to the customer receiving them in order to achieve data or system compromise. This attack can take place in a number of ways, including manipulation of source code, manipulation of the update and/or distribution mechanism, or replacing compiled versions with a malicious one.
EX-0004 Compromise Boot Memory Threat actors may manipulate boot memory in order to execute malicious code, bypass internal processes, or DoS the system. This technique can be used to perform other tactics such as Defense Evasion.
PER-0001 Memory Compromise 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.

Related SPARTA Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0001 Protect Sensitive Information Organizations should look to identify and properly classify mission sensitive design/operations information (e.g., fault management approach) and apply access control accordingly. Any location (ground system, contractor networks, etc.) storing design information needs to ensure design info is protected from exposure, exfiltration, etc. Space system sensitive information may be classified as Controlled Unclassified Information (CUI) or Company Proprietary. Space system sensitive information can typically include a wide range of candidate material: the functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, CUI, proprietary, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission. Sensitive documentation should only be accessed by personnel with defined roles and a need to know. Well established access controls (roles, encryption at rest and transit, etc.) and data loss prevention (DLP) technology are key countermeasures. The DLP should be configured for the specific data types in question. AC-3(11) AC-4(23) AC-4(25) CM-12 CM-12(1) PM-11 PM-17 SA-3(1) SA-3(2) SA-4(12) SA-5 SA-9(7) SI-21 SI-23 SR-12 SR-7 A.8.4 A.8.11 A.8.10 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.10 A.5.22
CM0009 Threat Intelligence Program A threat intelligence program helps an organization generate their own threat intelligence information and track trends to inform defensive priorities and mitigate risk. Leverage all-source intelligence services or commercial satellite imagery to identify and track adversary infrastructure development/acquisition. Countermeasures for this attack fall outside the scope of the mission in the majority of cases. PM-16 PM-16(1) PM-16(1) RA-10 RA-3(2) RA-3(3) SR-8 A.5.7 A.5.7 A.5.7
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) None
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(8) PM-11 PM-17 PM-30 PM-30(1) PM-32 RA-3(1) RA-9 RA-9 SA-15(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 A.5.30 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.5.22 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
CM0024 Anti-counterfeit Hardware Develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including tamper resistance and protection against the introduction of malicious code or hardware.  AC-20(5) CM-7(9) PM-30 PM-30(1) RA-3(1) SA-10(3) SA-10(4) SR-1 SR-10 SR-11 SR-11 SR-11(3) SR-11(3) SR-2 SR-2(1) SR-3 SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5(2) SR-6(1) SR-9 SR-9(1) 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
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/Software 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, materials, and software. AC-20(5) PM-30 PM-30(1) RA-3(1) SA-10(4) 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
CM0027 ASIC/FPGA Manufacturing Application-Specific Integrated Circuit (ASIC) / Field Programmable Gate Arrays should be developed by accredited trusted foundries to limit potential hardware-based trojan injections. PM-30 PM-30(1) RA-3(1) SA-10(3) SI-3 SR-1 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-5 SR-5(2) SR-6(1) 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.8.7 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
CM0028 Tamper Protection Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment. CA-8(3) CM-7(9) MA-7 PM-30 PM-30(1) RA-3(1) SA-10(3) SA-10(4) 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) 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.20 A.5.21 A.5.23 A.8.29
CM0004 Development Environment Security In order to secure the development environment, the first step is understanding all the devices and people who interact with it. Maintain an accurate inventory of all people and assets that touch the development environment. Ensure strong multi-factor authentication is used across the development environment, especially for code repositories, as threat actors may attempt to sneak malicious code into software that's being built without being detected. Use zero-trust access controls to the code repositories where possible. For example, ensure the main branches in repositories are protected from injecting malicious code. A secure development environment requires change management, privilege management, auditing and in-depth monitoring across the environment. AC-20(5) AC-3(11) AC-3(13) AC-3(15) CA-8 CM-14 CM-2(2) CM-3(2) CM-3(7) CM-3(8) CM-4(1) CM-7(8) CM-7(8) CP-2(8) MA-7 PL-8(2) PM-30 PM-30(1) RA-3(1) RA-3(2) RA-5 RA-5(2) RA-9 SA-10 SA-10(4) SA-11 SA-11(1) SA-11(2) SA-11(2) SA-11(4) SA-11(5) SA-11(5) SA-11(6) SA-11(7) SA-11(7) SA-11(8) SA-15 SA-15(3) SA-15(5) SA-15(7) SA-15(8) SA-3 SA-3(1) SA-3(2) SA-4(3) SA-4(5) SC-38 SI-2 SI-2(6) SR-1 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-3(2) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5 SR-5(2) SR-6 SR-6(1) SR-6(1) SR-7 A.8.4 A.8.9 A.8.9 A.8.31 A.5.30 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.8.8 A.5.22 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 A.8.28 A.8.9 A.8.28 A.8.30 A.8.32 A.8.29 A.8.30 A.8.28 A.5.8 A.8.25 A.8.28 A.6.8 A.8.8 A.8.32 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 A.5.22 A.5.22
CM0007 Software Version Numbers When using COTS or Open-Source, protect the version numbers being used as these numbers can be cross referenced against public repos to identify Common Vulnerability Exposures (CVEs) and exploits available. AC-3(11) SA-5 A.8.4 7.5.1 7.5.2 7.5.3 A.5.37
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., 30 days]. CM-3(2) CM-3(7) CM-3(8) CM-4(1) CM-7(4) SA-10(4) SI-2 A.8.9 A.8.9 A.8.31 A.8.19 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) RA-5(3) SA-15(7) SI-3 A.8.8 A.8.7
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) SA-10(4) A.5.9 A.8.9
CM0013 Dependency Confusion Ensure proper protections are in place for ensuring dependency confusion is mitigated like ensuring that internal dependencies be pulled from private repositories vice public repositories, ensuring that your CI/CD/development environment is secure as defined in CM0004 and validate dependency integrity by ensuring checksums match official packages. CM-10(1) RA-5 SA-8(9) A.8.8
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) SA-10(4) None
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
CM0017 Coding Standard Define acceptable coding standards to be used by the software developer. The mission should have automated means to evaluate adherence to coding standards. The coding standard should include the acceptable software development language types as well. The language should consider the security requirements, scalability of the application, the complexity of the application, development budget, development time limit, application security, available resources, etc. The coding standard and language choice must ensure proper security constructs are in place. SA-15 A.5.8 A.8.25
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-5(11) SA-11(5) SA-11(8) SA-11(9) SC-2(2) SC-7(29) SI-3 SR-6(1) SR-6(1) A.8.7
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
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. CM-11(3) CM-14 CM-14 SA-10(1) SI-7 SI-7(12) SI-7(15) None
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-3(7) CM-3(8) CM-5 MA-7 SA-10 SA-10(7) SR-11(2) 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.8.9 A.8.28 A.8.30 A.8.32
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) 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.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(5) IR-4 IR-4(12) IR-4(3) SA-8(21) SA-8(23) SA-8(24) SC-16(2) SC-24 SC-5 SI-11 SI-17 SI-7(17) A.5.29 A.5.25 A.5.26 A.5.27
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.  SC-51 SI-7(9) None