CM0043

Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the FSW.


Informational References

ID: CM0043
DiD Layer: S/C Software
CAPEC #:  14 | 25 | 26 | 30 | 36 | 43 | 47 | 52 | 74 | 92 | 100 | 123 | 129 | 130 | 131 | 167 | 184 | 186 | 188 | 190 | 191 | 212 | 242 | 310 | 538 | 540 | 545 | 546 | 586 | 640
Lowest Threat Tier to
Create Threat Event:  
II
Notional Risk Rank Score: 

High-Level Requirements

The Program shall perform software assurance of internally developed and acquired software using established robust procedures and technical methods.

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
The [organization] shall implement a verifiable flaw remediation process into the developmental and operational configuration management process.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-5,SA-3,SA-3(1),SA-11,SI-3,SI-3(10)} The verifiable process should also include a cross reference to mission objectives and impact statements. Understanding the flaws discovered and how they correlate to mission objectives will aid in prioritization.
The [organization] shall verify that the scope of security testing/evaluation provides complete coverage of required security controls (to include abuse cases and penetration testing) at the depth of testing defined in the test documents.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,RA-5(3),SA-11(5),SA-11(7)} * The frequency of testing should be driven by Program completion events and updates. * Examples of approaches are static analyses, dynamic analyses, binary analysis, or a hybrid of the three approaches
The [organization] shall maintain evidence of the execution of the security assessment plan and the results of the security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11}
The [organization] shall create and implement a security assessment plan that includes: (1) The types of analyses, testing, evaluation, and reviews of all software and firmware components; (2) The degree of rigor to be applied to include abuse cases and/or penetration testing; and (3) The types of artifacts produced during those processes.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11,SA-11(5)} The security assessment plan should include evaluation of mission objectives in relation to the security of the mission. Assessments should not only be control based but also functional based to ensure mission is resilient against failures of controls.
The [organization] shall determine the vulnerabilities/weaknesses that require remediation, and coordinate the timeline for that remediation, in accordance with the analysis of the vulnerability scan report, the mission assessment of risk, and mission needs.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-5,CM-3,RA-5,RA-7,SI-3,SI-3(10)}
The [organization] shall 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).{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-8,CM-10(1),RA-3(1),SA-11(5),SA-11(8),SA-11(9),SI-3,SI-7(10)}
The [organization] shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects on mission systems in a separate test environment before installation.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-3,CM-3(1),CM-3(2),CM-4(1),CM-4(2),CM-10(1),SA-8(31),SA-11(9),SI-2,SI-3,SI-3(10),SI-7(10),SI-7(12),SR-5(2)} This requirement is focused on software and firmware flaws. If hardware flaw remediation is required, refine the requirement to make this clear. 
The [organization] shall release updated versions of the mission information systems incorporating security-relevant software and firmware updates, after suitable regression testing, at a frequency no greater than [Program-defined frequency [90 days]].{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-3(2),CM-4(1)} On-orbit patching/upgrades may be necessary if vulnerabilities are discovered after launch. The system should have the ability to update software post-launch.
The [organization] shall prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-7(8)}
The [organization] shall report identified systems or system components containing software affected by recently announced cybersecurity-related software flaws (and potential vulnerabilities resulting from those flaws) to [organization] officials with cybersecurity responsibilities.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-11}{IR-6,IR-6(2),SI-2,SI-3,SI-4(12),SR-4(4)}
The [organization] shall use the threat and vulnerability analyses of the as-built system, system components, or system services to inform and direct subsequent testing/evaluation of the as-built system, component, or service.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-3(3),SA-11(2),SA-15(8),SI-3}
The [organization] shall share information obtained from the vulnerability scanning process and security control assessments with [Program-defined personnel or roles] to help eliminate similar vulnerabilities in other systems (i.e., systemic weaknesses or deficiencies).{SV-SP-1}{RA-5}
The [organization] shall ensure that the vulnerability scanning tools (e.g., static analysis and/or component analysis tools) used include the capability to readily update the list of potential information system vulnerabilities to be scanned.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(1),RA-5(3),SI-3}
The [organization] shall perform vulnerability analysis and risk assessment of all systems and software.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(3),SA-15(7),SI-3}
The [organization] shall 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.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(3),SI-3} Component/Origin scanning looks for open-source libraries/software that may be included into the baseline and looks for known vulnerabilities and open-source license violations.
The [organization] shall perform static source code analysis for all available source code looking for [[organization]-defined Top CWE List] weaknesses using complimentary set of static code analysis tools (i.e.more than one).{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,SA-11(1),SA-15(7)}
The [organization] shall analyze vulnerability/weakness scan reports and results from security control assessments.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,SI-3}
The [organization] shall ensure that the list of potential system vulnerabilities scanned is updated [prior to a new scan] {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5(2),SI-3}
The [organization] shall perform configuration management during system, component, or service during [design; development; implementation; operations].{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-10}
The [organization] shall review proposed changes to the spacecraft, assessing both mission and security impacts.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-10,CM-3(2)}
The [organization] shall correct flaws identified during security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11} Flaws that impact the mission objectives should be prioritized.
The [organization] shall perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Program-defined depth and coverage].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11} The depth needs to include functional testing as well as negative/abuse testing.
The [organization] shall create prioritized list of software weakness classes (e.g., Common Weakness Enumerations) to be used during static code analysis for prioritization of static analysis results.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(1),SA-15(7)} The prioritized list of CWEs should be created considering operational environment, attack surface, etc. Results from the threat modeling and attack surface analysis should be used as inputs into the CWE prioritization process. There is also a CWSS (https://cwe.mitre.org/cwss/cwss_v1.0.1.html) process that can be used to prioritize CWEs. The prioritized list of CWEs can help with tools selection as well as you select tools based on their ability to detect certain high priority CWEs.
The [organization] shall use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SA-15(8)}
The [organization] shall perform and document threat and vulnerability analyses of the as-built system, system components, or system services.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SI-3}
The [organization] shall perform a manual code review of all flight code.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(4)}
The [organization] shall conduct an Attack Surface Analysis and reduce attack surfaces to a level that presents a low level of compromise by an attacker.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(6),SA-15(5)}
The [organization] shall define acceptable coding languages to be used by the software developer.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15}
The [organization] shall define acceptable secure coding standards for use by the software developers.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15}
The [organization] shall have automated means to evaluate adherence to coding standards.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15,SA-15(7),RA-5} Manual review cannot scale across the code base; you must have a way to scale in order to confirm your coding standards are being met. The intent is for automated means to ensure code adheres to a coding standard.
The [organization] shall perform component analysis (a.k.a.origin analysis) for developed or acquired software.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15(7),RA-5}
The [organization] shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)} Select the particular subcontractors, software vendors, and manufacturers based on the criticality analysis performed for the Program Protection Plan and the criticality of the components that they supply. 
The [organization] shall require the developer of the system, system component, or system service to deliver the system, component, or service with [Program-defined security configurations] implemented.{SV-SP-1,SV-SP-9}{SA-4(5)} For the spacecraft FSW, the defined security configuration could include to ensure the software does not contain a pre-defined list of Common Weakness Enumerations (CWEs)and/or CAT I/II Application STIGs.
The [organization] shall correct reported cybersecurity-related information system flaws.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SI-2} * Although this requirement is stated to specifically apply to cybersecurity-related flaws, the Program office may choose to broaden it to all SV flaws. * This requirement is allocated to the Program, as it is presumed, they have the greatest knowledge of the components of the system and when identified flaws apply. 
The [organization] shall identify, report, and coordinate correction of cybersecurity-related information system flaws.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SI-2}
The [organization] shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)} Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc.
The [spacecraft] shall 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 ground.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9}{CM-3,CM-3(8),CM-5,CM-5(3),CM-14,SA-8(8),SA-8(31),SA-10(2),SI-3,SI-7(12),SI-7(15)}
The [spacecraft] shall be capable of removing flight software after updated versions have been installed.{SV-SP-1,SV-SP-9}{SA-8(8),SI-2(6)}

Related SPARTA Techniques and Sub-Techniques

ID Name Description
REC-0008 Gather Supply Chain Information Threat actors may gather information about a mission's supply chain or product delivery mechanisms that can be used for future campaigns or to help perpetuate other techniques.
REC-0008.03 Known Vulnerabilities Threat actors may gather information about vulnerabilities that can be used for future campaigns or to perpetuate other techniques. A vulnerability is a weakness in the victim spacecraft's hardware, subsystems, bus, or software that can, potentially, be exploited by a threat actor to cause unintended or unanticipated behavior to occur. During reconnaissance as threat actors identify the types/versions of software (i.e., COTS, open-source) being used, they will look for well-known vulnerabilities that could affect the space vehicle. Threat actors may find vulnerability information by searching leaked documents, vulnerability databases/scanners, compromising ground systems, and searching through online databases.
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.01 Software Dependencies & Development Tools Threat actors may manipulate software dependencies (i.e. dependency confusion) and/or development tools prior to the customer receiving them in order to achieve data or system compromise. Software binaries and applications often depend on external software to function properly. spacecraft developers may use open source projects to help with their creation. These open source projects may be targeted by threat actors as a way to add malicious code to the victim spacecraft's dependencies.
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-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-0009.03 Known Vulnerability (COTS/FOSS) Threat actors may utilize knowledge of the spacecraft software composition to enumerate and exploit known flaws or vulnerabilities in the commercial or open source software running on-board the target spacecraft.
PER-0002 Backdoor Threat actors may find and target various backdoors, or inject their own, within the victim spacecraft in the hopes of maintaining their attack.
PER-0002.02 Software Threat actors may inject code to create their own backdoor to establish persistent access to the spacecraft. This may be done through modification of code throughout the software supply chain or through modification of the software-defined radio configuration (if applicable).
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.

Related SPARTA Countermeasures

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
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
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
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
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) <