SV-SP-6

Software reuse, COTS dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to supply chain threat

ID: SV-SP-6

DiD Layer: S/C Software

CAPEC #: 310 | 313 | 446 | 538

NIST Rev5 Control Tag Mapping: AC-3 | AC-3(15) | CA-2(2) | CA-7 | CA-7(6) | CA-8 | CM-3 | CM-3(2) | CM-4 | CM-4(1) | CM-7 | CM-7(8) | CM-11 | CM-11(3) | CM-14 | PM-30 | PM-30(1) | RA-3 | RA-3(1) | RA-3(2) | RA-5 | RA-5(2) | RA-9 | RA-10 | SA-3 | SA-3(1) | SA-8 | SA-8(9) | SA-8(21) | SA-9 | SA-9(7) | SA-10 | SA-10(7) | SA-11 | SA-11(1) | SA-11(2) | SA-11(4) | SA-11(5) | SA-11(6) | SA-11(7) | SA-11(8) | SA-11(9) | SA-15 | SA-15(5) | SA-15(7) | SA-15(8) | SI-2 | SI-7 | SI-7(17) | SI-10 | SI-10(6) | SR-3 | SR-3(1) | SR-3(2) | 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: III

Notional Risk Rank Score: 22

Informational References

CENTRA Volume I - Cyber Content of Satellites

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 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 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 ensure reused TT&C software has adequate uniqueness for command decoders/dictionaries so that commands are received by only the intended satellite.{SV-SP-6}{AC-17(10),SC-16(3),SI-3(9)}	The goal is to eliminate risk that compromise of one command database does not affect a different one due to reuse. The intent is to ensure that one SV can not process the commands from another SV. Given the crypto setup with keys and VCC needing to match, this requirement may be inherently met as a result of using type-1 cryptography. The intent is not to recreate entire command dictionaries but have enough uniqueness in place that it prevents a SV from receiving a rogue command. As long as there is some uniqueness at the receiving end of the commands, that is adequate.
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 [organization] shall ensure that software planned for reuse meets the fit, form, and function, and security as a component within the new application.{SV-SP-6,SV-SP-7,SV-SP-11}{CM-7(5)}

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 spacecraft. 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.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.
EX-0010		Malicious Code	Threat actors may rely on other tactics and techniques in order to execute malicious code on the victim spacecraft. This can be done via compromising the supply chain or development environment in some capacity or taking advantage of known commands. However, once malicious code has been uploaded to the victim spacecraft, the threat actor can then trigger the code to run via a specific command or wait for a legitimate user to trigger it accidently. The code itself can do a number of different things to the hosted payload, subsystems, or underlying OS.
	EX-0010.01	Ransomware	Threat actors may encrypt spacecraft data to interrupt availability and usability. Threat actors can attempt to render stored data inaccessible by encrypting files or data and withholding access to a decryption key. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key or to render data permanently inaccessible in cases where the key is not saved or transmitted.
	EX-0010.02	Wiper Malware	Threat actors may deploy wiper malware, which is a type of malicious software designed to destroy data or render it unusable. Wiper malware can spread through various means, software vulnerabilities (CWE/CVE), or by exploiting weak or stolen credentials.
	EX-0010.03	Rootkit	Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information. Rootkits or rootkit enabling functionality may reside at the flight software or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware.
	EX-0010.04	Bootkit	Adversaries may use bootkits to persist on systems and evade detection. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
LM-0005		Virtualization Escape	In virtualized environments, threat actors can use the open ports between the partitions to overcome the hypervisor's protection and damage another partition. Further, if the threat actor has compromised the payload, access to a critical partition can be gained through ports allowed by hypervisor.

ID	Name	Description	NIST Rev5	D3FEND	ISO 27001
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.	PL-8 \| PL-8(1) \| PL-8(2) \| PM-30 \| PM-30(1) \| RA-3(1) \| SA-11 \| SA-11(3) \| SA-17 \| SA-2 \| SA-3 \| SA-8 \| SA-9 \| SR-11 \| SR-3(1) \| 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(1) \| SR-5(2) \| SR-6 \| SR-6	D3-OAM \| D3-ODM \|	A.5.8 \| 4.4 \| 6.2 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| 10.2 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30 \| A.8.25 \| A.8.27 \| 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) \| PL-8 \| PL-8(1) \| PL-8(2) \| PM-30 \| PM-30(1) \| RA-3(1) \| SA-10(4) \| SA-11 \| SA-3 \| SA-8 \| SA-9 \| 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)	D3-OAM \| D3-ODM \| D3-AM \| D3-FV \| D3-SFV \|	A.5.8 \| 4.4 \| 6.2 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| 10.2 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30 \| 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
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-17 \| AC-18 \| AC-20(5) \| AC-3(11) \| AC-3(13) \| AC-3(15) \| CA-8 \| CA-8(1) \| CA-8(1) \| CM-11 \| CM-14 \| CM-2(2) \| CM-3(2) \| CM-3(7) \| CM-3(8) \| CM-4(1) \| CM-4(1) \| CM-5(6) \| CM-7(8) \| CM-7(8) \| CP-2(8) \| MA-7 \| PL-8 \| PL-8(1) \| 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 \| 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(7) \| SA-11(8) \| SA-15 \| SA-15(3) \| SA-15(5) \| SA-15(7) \| SA-15(8) \| SA-17 \| SA-3 \| SA-3 \| SA-3(1) \| SA-3(2) \| SA-4(12) \| SA-4(3) \| SA-4(3) \| SA-4(5) \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(19) \| SA-8(30) \| SA-8(31) \| SA-9 \| SC-38 \| SI-2 \| SI-2(6) \| SI-7 \| 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	D3-AI \| D3-AVE \| D3-SWI \| D3-HCI \| D3-NNI \| D3-OAM \| D3-AM \| D3-OM \| D3-DI \| D3-MFA \| D3-CH \| D3-OTP \| D3-BAN \| D3-PA \| D3- FAPA \| D3- DQSA \| D3-IBCA \| D3-PCSV \| D3-PSMD \|	A.8.4 \| A.5.14 \| A.6.7 \| A.8.1 \| A.5.14 \| A.8.1 \| A.8.20 \| A.8.9 \| A.8.9 \| A.8.31 \| A.8.19 \| A.5.30 \| A.5.8 \| 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.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| 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.8.25 \| A.8.27 \| 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) \| CM-2 \| SA-11 \| SA-5 \| SA-8(29)	D3-AI \| D3-SWI \|	A.8.4 \| A.8.9 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.37 \| A.8.29 \| A.8.30
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]. Ideally old versions of software are removed after upgrading but restoration states (i.e., gold images) are recommended to remain on the system.	CM-3(2) \| CM-3(7) \| CM-3(8) \| CM-4 \| CM-4(1) \| CM-5(6) \| CM-7(5) \| SA-10(4) \| SA-11 \| SA-3 \| SA-8 \| SA-8(30) \| SA-8(31) \| SA-8(8) \| SA-9 \| SI-2 \| SI-2(6) \| SI-2(6) \| SI-7	D3-SU \|	A.8.9 \| A.8.9 \| A.8.9 \| A.8.31 \| A.8.19 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30 \| 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-3 \| RA-5 \| RA-5(11) \| RA-5(3) \| RA-7 \| SA-11 \| SA-11(3) \| SA-15(7) \| SA-3 \| SA-4(5) \| SA-8 \| SA-8(30) \| SI-3 \| SI-3(10) \| SI-7	D3-AI \| D3-NM \| D3-AVE \| D3-NVA \| D3-PM \| D3-FBA \| D3-OSM \| D3-SFA \| D3-PA \| D3-PSA \| D3-PLA \| D3-PCSV \| D3-FA \| D3-DA \| D3-ID \| D3-HD \| D3-UA \|	6.1.2 \| 8.2 \| 9.3.2 \| A.8.8 \| A.8.8 \| 6.1.3 \| 8.3 \| 10.2 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.8.29 \| A.8.30 \| 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 \| CM-10(1) \| CM-11 \| CM-11 \| CM-11(3) \| CM-2 \| CM-5(6) \| CM-7(4) \| CM-7(5) \| CM-8 \| CM-8(7) \| PM-5 \| RA-5 \| RA-5(11) \| SA-10(2) \| SA-10(4) \| SA-11 \| SA-11(3) \| SA-3 \| SA-4(5) \| SA-8 \| SA-8(13) \| SA-8(29) \| SA-8(30) \| SA-8(7) \| SA-9 \| SI-7	D3-AI \| D3-AVE \| D3-SWI \|	A.8.9 \| A.8.19 \| A.8.19 \| A.5.9 \| A.8.9 \| A.5.32 \| A.8.19 \| A.8.8 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30
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) \| CM-11 \| CM-2 \| CM-5(6) \| RA-5 \| SA-11 \| SA-3 \| SA-8 \| SA-8(30) \| SA-8(7) \| SA-8(9) \| SA-9 \| SI-7	D3-LFP \| D3-UBA \| D3-RAPA \| D3-MAC \|	A.8.9 \| A.8.19 \| A.8.8 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30
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-11 \| CM-14 \| CM-2 \| CM-4 \| CM-5(6) \| CM-7(8) \| SA-10(2) \| SA-10(4) \| SA-11 \| SA-3 \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(19) \| SA-8(29) \| SA-8(30) \| SA-8(31) \| SA-8(7) \| SA-9 \| SI-7	D3-PM \| D3-SBV \| D3-EI \| D3-EAL \| D3- EDL \| D3-DCE \|	A.8.9 \| A.8.9 \| A.8.19 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30
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 \| SA-11(1) \| SA-15(7) \| SI-7	D3-AI \| D3-AVE \|	A.8.8 \| A.8.29 \| A.8.30 \| 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.	PL-8 \| PL-8(1) \| SA-11 \| SA-11(3) \| SA-15 \| SA-3 \| SA-4(9) \| SA-8 \| SA-8(30) \| SA-8(7) \| SI-7	D3-AI \| D3-AVE \| D3-SWI \| D3-DCE \| D3-EHPV \| D3-ORA \| D3-FEV \| D3-FR \| D3-ER \| D3-PE \| D3-PT \| D3-PS \|	A.5.8 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.8.29 \| A.8.30 \| 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 \| CA-8(1) \| CA-8(1) \| CM-4(2) \| CP-4(5) \| RA-3 \| RA-5(11) \| RA-7 \| SA-11 \| SA-11(3) \| SA-11(5) \| SA-11(8) \| SA-11(9) \| SA-3 \| SA-8 \| SA-8(30) \| SC-2(2) \| SC-7(29) \| SI-3 \| SI-3(10) \| SI-7 \| SR-6(1) \| SR-6(1)	D3-DA \| D3-FBA \| D3-PSA \| D3-PLA \| D3-PA \| D3-SEA \| D3-MBT \|	6.1.2 \| 8.2 \| 9.3.2 \| A.8.8 \| 6.1.3 \| 8.3 \| 10.2 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.8.29 \| A.8.30 \| 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.	CM-4(2) \| RA-3 \| RA-5 \| RA-7 \| SA-11 \| SA-11(1) \| SA-11(3) \| SA-11(4) \| SA-15(7) \| SA-3 \| SA-8 \| SA-8(30) \| SI-7	D3-PM \| D3-FBA \| D3-FEMC \| D3-FV \| D3-PFV \| D3-SFV \| D3-OSM \|	6.1.2 \| 8.2 \| 9.3.2 \| A.8.8 \| A.8.8 \| 6.1.3 \| 8.3 \| 10.2 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.8.29 \| A.8.30 \| 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.	AC-14 \| CM-11 \| CM-11(3) \| CM-14 \| CM-14 \| CM-5(6) \| IA-2 \| SA-10(1) \| SA-11 \| SA-4(5) \| SA-8(29) \| SA-8(31) \| SA-9 \| SI-7 \| SI-7 \| SI-7(1) \| SI-7(12) \| SI-7(15) \| SI-7(6)	D3-CH \| D3-CBAN \| D3-FV \| D3-DLIC \| D3-EAL \| D3-SBV \|	A.8.19 \| A.5.16 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30
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) \| PL-8 \| PL-8(1) \| SA-15(6) \| SA-3 \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(19) \| SA-8(30) \| SI-3(8)	D3-AVE \| D3-OSM \| D3-EHB \| D3-SDM \| D3-SFA \| D3-SBV \| D3-PA \| D3-SCA \| D3-FCA \|	A.8.19 \| A.8.19 \| A.5.8 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28
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-11 \| CM-7(5) \| PL-8 \| PL-8(1) \| SI-10(5)	D3-MAC \| D3-EAL \| D3-EDL \|	A.8.19 \| A.8.19 \| A.5.8
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 \| 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 \| AC-18(1) \| AC-18(3) \| AC-18(4) \| AC-18(5) \| AC-19 \| AC-19(5) \| AC-2 \| 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 \| CA-3(6) \| CA-3(7) \| CA-7 \| CA-7(1) \| CA-7(6) \| CA-8 \| CA-8(1) \| CA-8(1) \| CA-9 \| CM-10(1) \| CM-11 \| 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(4) \| CM-3(5) \| CM-3(6) \| 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 \| CP-2(2) \| CP-2(5) \| CP-2(8) \| CP-3(1) \| CP-4(1) \| CP-4(2) \| 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 \| IR-3(1) \| IR-3(2) \| IR-3(3) \| IR-4 \| IR-4(1) \| IR-4(10) \| 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-6(2) \| IR-7 \| IR-7(1) \| IR-8 \| 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-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(2) \| SA-10(7) \| SA-11 \| SA-11 \| SA-11(2) \| SA-11(4) \| SA-11(7) \| SA-11(9) \| SA-15 \| SA-15(3) \| SA-15(7) \| SA-17 \| SA-17 \| SA-2 \| SA-2 \| SA-22 \| SA-3 \| SA-3 \| SA-3(1) \| SA-3(2) \| SA-3(2) \| SA-4 \| SA-4 \| SA-4(1) \| SA-4(10) \| SA-4(12) \| SA-4(2) \| SA-4(3) \| SA-4(3) \| SA-4(5) \| SA-4(5) \| SA-4(7) \| SA-4(9) \| SA-4(9) \| SA-5 \| SA-8 \| 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(29) \| SA-8(9) \| SA-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(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-12 \| 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-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 \| 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)	Nearly all D3FEND Techniques apply to Ground \|	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.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 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.24 \| 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 \| 10.2 \| 4.4 \| 6.2 \| 7.4 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| 9.1 \| 9.2.2 \| 10.1 \| 10.2 \| A.8.8 \| 6.1.3 \| 8.3 \| 10.2 \| A.5.22 \| A.5.7 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.33 \| 8.1 \| A.5.8 \| A.5.20 \| A.5.23 \| A.8.29 \| A.8.30 \| A.8.28 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.37 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.9 \| A.8.28 \| A.8.30 \| A.8.32 \| A.8.29 \| A.8.30 \| A.5.8 \| A.8.25 \| A.8.25 \| A.8.27 \| A.8.6 \| A.5.14 \| A.8.16 \| A.8.20 \| A.8.22 \| A.8.23 \| A.8.26 \| A.8.23 \| A.8.12 \| A.5.10 \| A.5.14 \| A.8.20 \| A.8.26 \| A.5.33 \| A.8.20 \| A.8.24 \| A.8.24 \| A.8.26 \| A.5.31 \| A.5.14 \| A.5.10 \| A.5.33 \| A.6.8 \| A.8.8 \| A.8.32 \| A.8.7 \| A.8.16 \| A.8.16 \| A.8.16 \| A.8.16 \| A.5.6 \| A.8.11 \| A.8.10 \| 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
CM0032	On-board Intrusion Detection & Prevention	Utilize on-board intrusion detection/prevention system that monitors the mission critical components or systems and audit/logs actions. The IDS/IPS should have the capability to respond to threats (initial access, execution, persistence, evasion, exfiltration, etc.) and it should address signature-based attacks along with dynamic never-before seen attacks using machine learning/adaptive technologies. The IDS/IPS must integrate with traditional fault management to provide a wholistic approach to faults on-board the spacecraft. Spacecraft should select and execute safe countermeasures against cyber-attacks. These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker — with or without ground support. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system.	AU-14 \| AU-2 \| AU-3 \| AU-3(1) \| AU-4 \| AU-4(1) \| AU-5 \| AU-5(2) \| AU-5(5) \| AU-6(1) \| AU-6(4) \| AU-8 \| AU-9 \| AU-9(2) \| AU-9(3) \| CA-7(6) \| CM-11(3) \| CP-10 \| CP-10(4) \| IR-4 \| IR-4(11) \| IR-4(12) \| IR-4(14) \| IR-4(5) \| IR-5 \| IR-5(1) \| PL-8 \| PL-8(1) \| RA-10 \| RA-3(4) \| 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(10) \| SI-3(8) \| SI-4 \| SI-4(1) \| SI-4(10) \| SI-4(11) \| SI-4(13) \| 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-4(7) \| SI-6 \| SI-7(17) \| SI-7(8)	D3-FA \| D3-DA \| D3-FCR \| D3-FH \| D3-ID \| D3-IRA \| D3-HD \| D3-IAA \| D3-FHRA \| D3-NTA \| D3-PMAD \| D3-RTSD \| D3-ANAA \| D3-CA \| D3-CSPP \| D3-ISVA \| D3-PM \| D3-SDM \| D3-SFA \| D3-SFV \| D3-SICA \| D3-USICA \| D3-FBA \| D3-FEMC \| D3-FV \| D3-OSM \| D3-PFV \| D3-EHB \| D3-IDA \| D3-MBT \| D3-SBV \| D3-PA \| D3-PSMD \| D3-PSA \| D3-SEA \| D3-SSC \| D3-SCA \| D3-FAPA \| D3-IBCA \| D3-PCSV \| D3-FCA \| D3-PLA \| D3-UBA \| D3-RAPA \| D3-SDA \| D3-UDTA \| D3-UGLPA \| D3-ANET \| D3-AZET \| D3-JFAPA \| D3-LAM \| D3-NI \| D3-RRID \| D3-NTF \| D3-ITF \| D3-OTF \| D3-EI \| D3-EAL \| D3-EDL \| D3-HBPI \| D3-IOPR \| D3-KBPI \| D3-MAC \| D3-SCF \|	A.8.15 \| A.8.15 \| A.8.6 \| A.8.17 \| A.5.33 \| A.8.15 \| A.8.15 \| A.5.29 \| A.5.25 \| A.5.26 \| A.5.27 \| A.5.8 \| A.5.7 \| A.8.12 \| A.8.7 \| A.8.16 \| A.8.16 \| A.8.16 \| A.8.16

SV-SP-6

Informational References

High-Level Requirements

Low-Level Requirements

Related SPARTA Techniques and Sub-Techniques

Related SPARTA Countermeasures