Attacks on critical software subsystems
Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations
Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector
Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack.
Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite.
| Requirement | Rationale/Additional Guidance/Notes |
|---|---|
| The [spacecraft] software subsystems shall provide non-identical methods, or functionally independent methods, for commanding a mission critical function when the software is the sole control of that function.{SV-MA-3,SV-AV-7}{AC-3(2)} | |
| The [spacecraft] software subsystems shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard.{SV-MA-3,SV-AV-7}{AC-3(2)} | |
| The [spacecraft] software subsystems shall provide independent mission/cyber critical threads such that any one credible event will not corrupt another mission/cyber critical thread.{SV-MA-3,SV-AV-7}{SC-3} | |
| The [spacecraft] software subsystems shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied.{SV-MA-3,SV-AV-7}{SI-10} | |
| The [spacecraft] software subsystems shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission.{SV-MA-3,SV-AV-7}{SI-10} | |
| The [spacecraft] software subsystems shall perform prerequisite checks for the execution of hazardous commands.{SV-MA-3,SV-AV-7}{SI-10} | |
| The [spacecraft] software subsystems shall discriminate between valid and invalid input into the software and rejects invalid input.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)} | |
| The [spacecraft] software subsystems shall properly handle spurious input and missing data.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)} | |
| The [spacecraft] software subsystems shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit or perform a hazardous action.{SV-MA-3,SV-AV-7}{SI-10(3)} | |
| The [spacecraft] mission/cyber critical commands shall be "complex" and/or diverse from other commands so that a single bit flip could not transform a benign command into a hazardous command.{SV-MA-3,SV-AV-7}{SI-10(5)} | |
| The [spacecraft] software subsystems shall provide at least one independent command for each operator-initiated action used to shut down a function leading to or reducing the control of a hazard.{SV-MA-3,SV-AV-7}{SI-10(5)} | |
| The [spacecraft] shall have failure tolerance on sensors used by software to make mission-critical decisions.{SV-MA-3,SV-AV-7}{SI-13,SI-17} | |
| The [spacecraft] software subsystems shall detect and recover/transition from detected memory errors to a known cyber-safe state.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall initialize the spacecraft to a known safe state.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall operate securely in off-nominal power conditions, including loss of power and spurious power transients.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall perform an orderly, controlled system shutdown to a known cyber-safe state upon receipt of a termination command or condition.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall recover to a known cyber-safe state when an anomaly is detected.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall safely transition between all predefined, known states.{SV-MA-3,SV-AV-7}{SI-17} |
| ID | Name | Description | |
|---|---|---|---|
| REC-0001 | Gather Spacecraft Design Information | Threat actors may gather information about the victim spacecraft's design that can be used for future campaigns or to help perpetuate other techniques. Information about the spacecraft can include software, firmware, encryption type, purpose, as well as various makes and models of subsystems. | |
| REC-0001.01 | Software | Threat actors may gather information about the victim spacecraft's internal software that can be used for future campaigns or to help perpetuate other techniques. Information (e.g. source code, binaries, etc.) about commercial, open-source, or custom developed software may include a variety of details such as types, versions, and memory maps. Leveraging this information threat actors may target vendors of operating systems, flight software, or open-source communities to embed backdoors or for performing reverse engineering research to support offensive cyber operations. | |
| REC-0001.04 | Data Bus | Threat actors may gather information about the data bus used within the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information about the data bus can include the make and model which could lead to more information (ex. protocol, purpose, controller, etc.), as well as locations/addresses of major subsystems residing on the bus. Threat actors may also gather information about the bus voltages of the victim spacecraft. This information can include optimal power levels, connectors, range, and transfer rate. | |
| REC-0001.05 | Thermal Control System | Threat actors may gather information about the thermal control system used with the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information gathered can include type, make/model, and varies analysis programs that monitor it. | |
| REC-0001.06 | Maneuver & Control | Threat actors may gather information about the station-keeping control systems within the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information gathered can include thruster types, propulsion types, attitude sensors, and data flows associated with the relevant subsystems. | |
| REC-0001.08 | Power | Threat actors may gather information about the power system used within the victim spacecraft. This information can include type, power intake, and internal algorithms. Threat actors may also gather information about the solar panel configurations such as positioning, automated tasks, and layout. Additionally, threat actors may gather information about the batteries used within the victim spacecraft. This information can include the type, quantity, storage capacity, make and model, and location. | |
| REC-0004 | Gather Launch Information | Threat actors may gather the launch date and time, location of the launch (country & specific site), organizations involved, launch vehicle, etc. This information can provide insight into protocols, regulations, and provide further targets for the threat actor, including specific vulnerabilities with the launch vehicle itself. | |
| REC-0004.01 | Flight Termination | Threat actor may obtain information regarding the vehicle's flight termination system. Threat actors may use this information to perform later attacks and target the vehicle's termination system to have desired impact on mission. | |
| IA-0004 | Secondary/Backup Communication Channel | Threat actors may compromise alternative communication pathways which may not be as protected as the primary pathway. Depending on implementation the contingency communication pathways/solutions may lack the same level of security (i.e., physical security, encryption, authentication, etc.) which if forced to use could provide a threat actor an opportunity to launch attacks. Typically these would have to be coupled with other denial of service techniques on the primary pathway to force usage of secondary pathways. | |
| IA-0004.02 | Receiver | Threat actors may target the backup/secondary receiver on the space vehicle as a method to inject malicious communications into the mission. The secondary receivers may come from different supply chains than the primary which could have different level of security and weaknesses. Similar to the ground station, the communication through the secondary receiver could be forced or happening naturally. | |
| EX-0002 | Position, Navigation, and Timing (PNT) Geofencing | Threat actors may leverage the fact that spacecraft orbit through space unlike typical enterprise systems which are stationary. Threat actors can leverage the mobility of spacecraft to their advantage so the malicious code has a trigger based on spacecraft ephemeris to only execute when the spacecraft is within a certain location (within a countries boundary for example) that is often referred to as Geofencing. By using a Geofence an adversary can ensure that malware is only executed when it is needed. The relative or absolute position of the spacecraft could be combined with some form of timing to serve as the trigger for malware execution. | |
| EX-0009 | Exploit Code Flaws | Threats actors may identify and exploit flaws or weaknesses within the software running on-board the target spacecraft. These attacks may be extremely targeted and tailored to specific coding errors introduced as a result of poor coding practices or they may target known issues in the commercial software components. | |
| EX-0009.01 | Flight Software | Threat actors may abuse known or unknown flight software code flaws in order to further the attack campaign. Some FSW suites contain API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands. In some cases, these code flaws can perpetuate throughout the victim spacecraft, allowing access to otherwise segmented subsystems. | |
| EX-0012 | 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. | |
| EX-0012.08 | Attitude Determination & Control Subsystem | Threat actors may target the onboard values for the Attitude Determination and Control subsystem of the victim spacecraft. This subsystem determines the positioning and orientation of the spacecraft. Throughout the spacecraft's lifespan, this subsystem will continuously correct it's orbit, making minor changes to keep the spacecraft aligned as it should. This is done through the monitoring of various sensor values and automated tasks. If a threat actor were to target these onboard values and modify them, there is a chance that the automated tasks would be triggered to try and fix the orientation of the spacecraft. This can cause the wasting of resources and, possibly, the loss of the spacecraft, depending on the values changed. | |
| EX-0012.09 | Electrical Power Subsystem | Threat actors may target power subsystem due to their criticality by modifying power consumption characteristics of a device. Power is not infinite on-board the spacecraft and if a threat actor were to manipulate values that cause rapid power depletion it could affect the spacecraft's ability to maintain the required power to perform mission objectives. | |
| EX-0012.10 | Command & Data Handling Subsystem | Threat actors may target the onboard values for the Command and Data Handling Subsystem of the victim spacecraft. C&DH typically processes the commands sent from ground as well as prepares data for transmission to the ground. Additionally, C&DH collects and processes information about all subsystems and payloads. Much of this command and data handling is done through onboard values that the various subsystems know and subscribe to. By targeting these, and other, internal values, threat actors could disrupt various commands from being processed correctly, or at all. Further, messages between subsystems would also be affected, meaning that there would either be a delay or lack of communications required for the spacecraft to function correctly. | |
| IMP-0001 | Deception (or Misdirection) | Measures designed to mislead an adversary by manipulation, distortion, or falsification of evidence or information into a system to induce the adversary to react in a manner prejudicial to their interests. Threat actors may seek to deceive mission stakeholders (or even military decision makers) for a multitude of reasons. Telemetry values could be modified, attacks could be designed to intentionally mimic another threat actor's TTPs, and even allied ground infrastructure could be compromised and used as the source of communications to the spacecraft. | |
| IMP-0002 | Disruption | Measures designed to temporarily impair the use or access to a system for a period of time. Threat actors may seek to disrupt communications from the victim spacecraft to the ground controllers or other interested parties. By disrupting communications during critical times, there is the potential impact of data being lost or critical actions not being performed. This could cause the spacecraft's purpose to be put into jeopardy depending on what communications were lost during the disruption. This behavior is different than Denial as this attack can also attempt to modify the data and messages as they are passed as a way to disrupt communications. | |
| IMP-0003 | Denial | Measures designed to temporarily eliminate the use, access, or operation of a system for a period of time, usually without physical damage to the affected system. Threat actors may seek to deny ground controllers and other interested parties access to the victim spacecraft. This would be done exhausting system resource, degrading subsystems, or blocking communications entirely. This behavior is different from Disruption as this seeks to deny communications entirely, rather than stop them for a length of time. | |
| IMP-0004 | Degradation | Measures designed to permanently impair (either partially or totally) the use of a system. Threat actors may target various subsystems or the hosted payload in such a way to rapidly increase it's degradation. This could potentially shorten the lifespan of the victim spacecraft. | |
| IMP-0005 | Destruction | Measures designed to permanently eliminate the use of a system, potentially through some physical damage to the system. Threat actors may destroy data, commands, subsystems, or attempt to destroy the victim spacecraft itself. This behavior is different from Degradation, as the individual parts are destroyed rather than put in a position in which they would slowly degrade over time. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0000 | Countermeasure Not Identified | This technique is a result of utilizing TTPs to create an impact and the applicable countermeasures are associated with the TTPs leveraged to achieve the impact | None | None | ||
| 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 | ||
| CM0008 | Security Testing Results | As penetration testing and vulnerability scanning is a best practice, protecting the results from these tests and scans is equally important. These reports and results typically outline detailed vulnerabilities and how to exploit them. As with countermeasure CM0001, protecting sensitive information from disclosure to threat actors is imperative. | AC-3(11) CA-8 RA-5 RA-5(11) SA-11(5) SA-5 | A.8.4 A.8.8 7.5.1 7.5.2 7.5.3 A.5.37 | ||
| 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 | ||
| CM0033 | Relay Protection | Implement relay and replay-resistant authentication mechanisms for establishing a remote connection or connections on the spacecraft bus. | AC-17(10) AC-17(10) IA-2(8) IA-3 IA-3(1) IA-4 IA-7 SC-13 SC-23 SC-7 SC-7(11) SC-7(18) SI-10 SI-10(5) SI-10(6) SI-3(8) | A.5.16 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.24 A.8.26 A.5.31 | ||
| 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., 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 | ||
| 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 | ||
| 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(4) 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 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) SI-3(8) | A.8.19 A.8.19 | ||
| CM0055 | Secure Command Mode(s) | Provide additional protection modes for commanding the spacecraft. These can be where the spacecraft will restrict command lock based on geographic location of ground stations, special operational modes within the flight software, or even temporal controls where the spacecraft will only accept commands during certain times. | AC-17(1) AC-17(10) AC-2(11) AC-2(12) AC-3 AC-3(2) AC-3(3) AC-3(4) AC-3(8) CA-3(7) SC-7 SI-3(8) | A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.16 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | ||
| 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-7(5) SI-10(5) | A.8.19 | ||
| CM0005 | Ground-based Countermeasures | This countermeasure is focused on the protection of terrestrial assets like ground networks and development environments/contractor networks, etc. Traditional detection technologies and capabilities would be applicable here. Utilizing resources from NIST CSF to properly secure these environments using identify, protect, detect, recover, and respond is likely warranted. Additionally, NISTIR 8401 may provide resources as well since it was developed to focus on ground-based security for space systems (https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8401.ipd.pdf). Furthermore, the MITRE ATT&CK framework provides IT focused TTPs and their mitigations https://attack.mitre.org/mitigations/enterprise/. Several recommended NIST 800-53 Rev5 controls are provided for reference when designing ground systems/networks. | AC-1 AC-10 AC-11 AC-11(1) AC-12 AC-12(1) AC-14 AC-16 AC-16(6) AC-17 AC-17(1) AC-17(10) AC-17(2) AC-17(3) AC-17(4) AC-17(6) AC-17(9) AC-18 AC-18(1) AC-18(3) AC-18(4) AC-18(5) AC-19 AC-19(5) AC-2 AC-2(1) AC-2(11) AC-2(12) AC-2(13) AC-2(2) AC-2(3) AC-2(4) AC-2(9) AC-20 AC-20(1) AC-20(2) AC-20(3) AC-20(5) AC-21 AC-22 AC-3 AC-3(11) AC-3(13) AC-3(15) AC-3(4) AC-4 AC-4(23) AC-4(24) AC-4(25) AC-4(26) AC-4(31) AC-4(32) AC-6 AC-6(1) AC-6(10) AC-6(2) AC-6(3) AC-6(5) AC-6(8) AC-6(9) AC-7 AC-8 AT-2(4) AT-2(4) AT-2(5) AT-2(6) AT-3 AT-3(2) AT-4 AU-10 AU-11 AU-12 AU-12(1) AU-12(3) AU-14 AU-14(1) AU-14(3) AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(1) AU-5(2) AU-5(5) AU-6 AU-6(1) AU-6(3) AU-6(4) AU-6(5) AU-6(6) AU-7 AU-7(1) AU-8 AU-9 AU-9(2) AU-9(3) AU-9(4) CA-3 CA-3(6) CA-3(7) CA-7 CA-7(1) CA-7(6) CA-8 CA-9 CM-10(1) CM-11 CM-11(2) CM-11(3) CM-12 CM-12(1) CM-14 CM-2 CM-2(2) CM-2(3) CM-2(7) CM-3 CM-3(1) CM-3(2) CM-3(5) CM-3(7) CM-3(7) CM-3(8) CM-4 CM-5(1) CM-5(5) CM-6 CM-6(1) CM-6(2) CM-7 CM-7(1) CM-7(2) CM-7(3) CM-7(5) CM-7(8) CM-7(8) CM-7(9) CM-8 CM-8(1) CM-8(2) CM-8(3) CM-8(4) CM-9 CP-10 CP-10(2) CP-10(4) CP-2 CP-2(2) CP-2(5) CP-2(8) CP-3(1) CP-4(5) CP-8 CP-8(1) CP-8(2) CP-8(3) CP-8(4) CP-8(5) CP-9 CP-9(1) CP-9(2) CP-9(3) IA-11 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) IA-2 IA-2(1) IA-2(12) IA-2(2) IA-2(5) IA-2(6) IA-2(8) IA-3 IA-3(1) IA-4 IA-4(9) IA-5 IA-5(1) IA-5(13) IA-5(14) IA-5(2) IA-5(7) IA-5(8) IA-6 IA-7 IA-8 IR-2 IR-2(2) IR-2(3) IR-3(3) IR-4 IR-4(1) IR-4(11) IR-4(11) IR-4(12) IR-4(13) IR-4(14) IR-4(3) IR-4(4) IR-4(5) IR-4(6) IR-4(7) IR-4(8) IR-5 IR-5(1) IR-6 IR-6(1) IR-7 IR-7(1) MA-2 MA-3 MA-3(1) MA-3(2) MA-3(3) MA-4 MA-4(1) MA-4(3) MA-4(6) MA-4(7) MA-5(1) MA-6 MA-7 MP-2 MP-3 MP-4 MP-5 MP-5(4) MP-6 MP-6(3) MP-7 PE-3(7) PL-10 PL-11 PL-8 PL-8(1) PL-8(2) PL-9 PL-9 PM-11 PM-16(1) PM-17 PM-30 PM-30(1) PM-31 PM-32 RA-10 RA-3(1) RA-3(2) RA-3(2) RA-3(3) RA-3(4) RA-5 RA-5(10) RA-5(11) RA-5(2) RA-5(4) RA-5(5) RA-7 RA-9 RA-9 SA-10 SA-10(1) SA-10(7) SA-11 SA-11(2) SA-11(9) SA-15 SA-15(3) SA-15(7) SA-17 SA-2 SA-22 SA-3 SA-3(1) SA-3(2) SA-3(2) SA-4 SA-4(1) SA-4(10) SA-4(12) SA-4(2) SA-4(3) SA-4(5) SA-4(7) SA-4(9) SA-5 SA-8 SA-8(14) SA-8(15) SA-8(18) SA-8(21) SA-8(22) SA-8(23) SA-8(24) SA-8(9) SA-9 SA-9(1) SA-9(2) SA-9(6) SA-9(7) SC-10 SC-12 SC-12(1) SC-12(6) SC-13 SC-15 SC-16(2) SC-16(3) SC-18(1) SC-18(2) SC-18(3) SC-18(4) SC-2 SC-2(2) SC-20 SC-21 SC-22 SC-23 SC-23(1) SC-23(3) SC-23(5) SC-24 SC-28 SC-28(1) SC-28(11) SC-28(3) SC-3 SC-38 SC-39 SC-4 SC-45 SC-45(1) SC-45(1) SC-45(2) SC-49 SC-5 SC-5(1) SC-5(2) SC-5(3) SC-50 SC-51 SC-7 SC-7(10) SC-7(11) SC-7(12) SC-7(13) SC-7(14) SC-7(18) SC-7(21) SC-7(25) SC-7(29) SC-7(3) SC-7(4) SC-7(5) SC-7(5) SC-7(7) SC-7(8) SC-7(9) SC-8 SC-8(1) SC-8(2) SC-8(5) SI-10 SI-10(3) SI-10(6) SI-11 SI-14(3) SI-16 SI-19(4) SI-2 SI-2(2) SI-2(3) SI-2(6) SI-21 SI-3 SI-3 SI-3(10) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(12) SI-4(13) SI-4(14) SI-4(15) SI-4(16) SI-4(17) SI-4(2) SI-4(20) SI-4(22) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-5 SI-5(1) SI-6 SI-7 SI-7(1) SI-7(17) SI-7(2) SI-7(5) SI-7(7) SI-7(8) SR-1 SR-1 SR-10 SR-11 SR-11 SR-11(1) SR-11(2) SR-11(3) SR-12 SR-2 SR-2(1) SR-3 SR-3(1) SR-3(2) SR-3(2) 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) SR-6 SR-6(1) SR-6(1) SR-7 SR-7 SR-8 SR-9 SR-9(1) | 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.15 A.5.31 A.5.36 A.5.37 A.5.16 A.5.18 A.8.2 A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.4 A.5.14 A.8.22 A.8.23 A.8.11 A.8.10 A.5.15 A.8.2 A.8.18 A.8.5 A.8.5 A.7.7 A.8.1 A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.7.9 A.8.1 A.5.14 A.7.9 A.8.20 A.6.3 A.8.15 A.8.15 A.8.6 A.5.25 A.6.8 A.8.15 A.7.4 A.8.17 A.5.33 A.8.15 A.5.28 A.8.15 A.8.15 A.8.15 A.5.14 A.8.21 9.1 9.3.2 9.3.3 A.5.36 9.2.2 A.8.9 A.8.9 8.1 9.3.3 A.8.9 A.8.32 A.8.9 A.8.9 A.8.9 A.8.9 A.8.19 A.8.19 A.5.9 A.8.9 A.5.2 A.8.9 A.8.19 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.30 A.5.29 A.7.11 A.5.29 A.5.33 A.8.13 A.5.29 A.5.16 A.5.16 A.5.16 A.5.17 A.8.5 A.5.16 A.6.3 A.5.25 A.5.26 A.5.27 A.8.16 A.5.5 A.6.8 A.7.10 A.7.13 A.8.10 A.8.10 A.8.16 A.8.10 A.7.13 A.5.10 A.7.7 A.7.10 A.5.13 A.5.10 A.7.7 A.7.10 A.8.10 A.5.10 A.7.9 A.7.10 A.5.10 A.7.10 A.7.14 A.8.10 A.5.10 A.7.10 A.5.8 A.5.7 4.4 6.2 7.5.1 7.5.2 7.5.3 | ||