CM0043

Malicious Use of hardware commands - backdoors / critical commands


Informational References

ID: CM0043
DiD Layer: SBC
CAPEC #:  88 | 248
NIST Rev5 Control Tag Mapping:  AC-3 | AC-3(11) | AC-14 | AC-17 | AC-17(10) | CM-12 | CM-12(1) | CP-4 | CP-4(5) | RA-3 | RA-3(3) | SA-3 | SA-3(1) | SA-8 | SA-8(9) | SA-8(15) | SA-8(24) | SA-11 | SA-11(9) | SI-10 | SI-10(3) | SI-10(6)
Lowest Threat Tier to
Create Threat Event:  
III
Notional Risk Rank Score: 

High-Level Requirements

The Program shall ensure all hardware/backdoor commands available for use by the spacecraft are as expected.

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
The [organization] shall ensure that all viable commands are known to the mission and SV "owner.{SV-AC-8}{SI-10,SI-10(3)} This is a concern for bus re-use. It is possible that the manufacturer left previously coded commands in their syntax rather than starting from a clean slate. This leaves potential backdoors and other functionality the mission does not know about.
The [organization] shall perform analysis of critical (backdoor) commands that could adversely affect mission success if used maliciously.{SV-AC-8}{SI-10,SI-10(3)} Heritage and commercial products often have many residual operational (e.g., hardware commands) and test capabilities that are unidentified or unknown to the end user, perhaps because they were not expressly stated mission requirements. These would never be tested and their effects unknown, and hence, could be used maliciously. Test commands not needed for flight should be deleted from the flight database.
The [spacecraft] shall only use or include [organization]-defined critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted.{SV-AC-8}{SI-10,SI-10(3)} The intent is protect against misuse of critical commands. On potential scenario is where you could use accounts with different privileges, could require an additional passphrase or require entry into a different state or append an additional footer to a critical command. There is room for design flexibility here that can still satisfy this requirement.

Related SPARTA Techniques and Sub-Techniques

ID Name Description
EX-0003 Modify Authentication Process Threat actors may modify the internal authentication process of the victim spacecraft to facilitate initial access, recurring execution, or prevent authorized entities from accessing the spacecraft. This can be done through the modification of the software binaries or memory manipulation techniques.
EX-0005 Exploit Hardware/Firmware Corruption Threat actors can target the underlying hardware and/or firmware using various TTPs that will be dependent on the specific hardware/firmware. Typically, software tools (e.g., antivirus, antimalware, intrusion detection) can protect a system from threat actors attempting to take advantage of those vulnerabilities to inject malicious code. However, there exist security gaps that cannot be closed by the above-mentioned software tools since they are not stationed on software applications, drivers or the operating system but rather on the hardware itself. Hardware components, like memory modules and caches, can be exploited under specific circumstances thus enabling backdoor access to potential threat actors. In addition to hardware, the firmware itself which often is thought to be software in its own right also provides an attack surface for threat actors. Firmware is programming that's written to a hardware device's non-volatile memory where the content is saved when a hardware device is turned off or loses its external power source. Firmware is written directly onto a piece of hardware during manufacturing and it is used to run on the device and can be thought of as the software that enables hardware to run. In the space vehicle context, firmware and field programmable gate array (FPGA)/application-specific integrated circuit (ASIC) logic/code is considered equivalent to firmware.
EX-0005.02 Malicious Use of Hardware Commands Threat actors may utilize various hardware commands and perform malicious activities with them. Hardware commands typically differ from traditional command channels as they bypass many of the traditional protections and pathways and are more direct therefore they can be dangerous if not protected. Hardware commands are sometime a necessity to perform various actions such as configuring sensors, adjusting positions, and rotating internal motors. Threat actors may use these commands to perform malicious activities that can damage the victim spacecraft in some capacity.
EX-0006 Disable/Bypass Encryption Threat actors may perform specific techniques in order to bypass or disable the encryption mechanism onboard the victim spacecraft. By bypassing or disabling this particular mechanism, further tactics can be performed, such as Exfiltration, that may have not been possible with the internal encryption process in place.
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.01 Hardware Threat actors may find and target various hardware backdoors within the victim spacecraft in the hopes of maintaining their attack. Once in orbit, mitigating the risk of various hardware backdoors becomes increasingly difficult for ground controllers. By targeting these specific vulnerabilities, threat actors are more likely to remain persistent on the victim spacecraft and perpetuate further attacks.

Related SPARTA Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0001 Protect Sensitive Information Organizations should look to identify and properly classify mission sensitive design/operations information (e.g., fault management approach) and apply access control accordingly. Any location (ground system, contractor networks, etc.) storing design information needs to ensure design info is protected from exposure, exfiltration, etc. Space system sensitive information may be classified as Controlled Unclassified Information (CUI) or Company Proprietary. Space system sensitive information can typically include a wide range of candidate material: the functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, CUI, proprietary, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission. Sensitive documentation should only be accessed by personnel with defined roles and a need to know. Well established access controls (roles, encryption at rest and transit, etc.) and data loss prevention (DLP) technology are key countermeasures. The DLP should be configured for the specific data types in question. AC-3(11) AC-4(23) AC-4(25) AC-4(6) CA-3 CM-12 CM-12(1) PL-8 PL-8(1) PM-11 PM-17 SA-3 SA-3(1) SA-3(2) SA-4(12) SA-5 SA-8 SA-9(7) SC-16 SC-8(1) SC-8(3) SI-21 SI-23 SR-12 SR-7 D3-AI D3-AVE D3-NVA D3-CH D3-CBAN D3-CTS D3-PA D3-FAPA D3-SAOR A.8.4 A.8.11 A.8.10 A.5.14 A.8.21 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.27 A.8.28 A.5.33 A.8.10 A.5.22
CM0009 Threat Intelligence Program A threat intelligence program helps an organization generate their own threat intelligence information and track trends to inform defensive priorities and mitigate risk. Leverage all-source intelligence services or commercial satellite imagery to identify and track adversary infrastructure development/acquisition. Countermeasures for this attack fall outside the scope of the mission in the majority of cases. PM-16 PM-16(1) PM-16(1) RA-10 RA-3 RA-3(2) RA-3(3) SA-3 SA-8 SR-8 D3-PH D3-AH D3-NM D3-NVA D3-SYSM D3-SYSVA A.5.7 A.5.7 6.1.2 8.2 9.3.2 A.8.8 A.5.7 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
CM0020 Threat modeling Use threat modeling, attack surface analysis, and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. Reduce attack surface where possible based on threats. CA-3 CM-4 CP-2 PL-8 PL-8(1) RA-3 SA-11 SA-11(2) SA-11(6) SA-15(6) SA-15(8) SA-2 SA-3 SA-4(9) SA-8 D3-AI D3-AVE D3-SWI D3-HCI D3-NM D3-LLM D3-ALLM D3-PLLM D3-PLM D3-APLM D3-PPLM D3-SYSM D3-DEM D3-SVCDM D3-SYSDM A.5.14 A.8.21 A.8.9 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.8 6.1.2 8.2 9.3.2 A.8.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
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 CP-2(8) PL-8 PL-8(1) PM-11 PM-17 PM-30 PM-30(1) PM-32 RA-3 RA-3(1) RA-9 RA-9 SA-11 SA-15(3) SA-2 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(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 D3-AVE D3-OSM D3-IDA D3-SJA D3-AI D3-DI D3-SWI D3-NNI D3-HCI D3-NM D3-PLM D3-AM D3-SYSM D3-SVCDM D3-SYSDM D3-SYSVA D3-OAM D3-ORA 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 A.5.8 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 6.1.2 8.2 9.3.2 A.8.8 A.5.22 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 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.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-14 AC-20(5) CM-7(9) PL-8 PL-8(1) PM-30 PM-30(1) RA-3(1) SA-10(3) SA-10(4) SA-11 SA-3 SA-4(5) SA-8 SA-8(13) SA-9 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) D3-AI D3-SWI D3-HCI D3-FEMC D3-DLIC D3-FV 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
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-17 SA-2 SA-3 SA-8 SA-9 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 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
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. AC-14 PL-8 PL-8(1) PL-8(2) PM-30 PM-30(1) RA-3(1) SA-10(3) SA-11 SA-3 SA-8 SA-8(13) SA-9 SI-3 SR-1 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-5 SR-5(2) SR-6(1) 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 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. AC-14 CA-8(3) CM-7(9) MA-7 PL-8 PL-8(1) PL-8(2) PM-30 PM-30(1) RA-3(1) SA-10(3) SA-10(4) SA-11 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(13) SA-9 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) D3-PH D3-AH D3-RFS D3-FV 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.20 A.5.21 A.5.23 A.8.29
CM0002 COMSEC A component of cybersecurity to deny unauthorized persons information derived from telecommunications and to ensure the authenticity of such telecommunications. COMSEC includes cryptographic security, transmission security, emissions security, and physical security of COMSEC material. It is imperative to utilize secure communication protocols with strong cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission. Systems should also maintain the confidentiality and integrity of information during preparation for transmission and during reception. Spacecraft should not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). The cryptographic mechanisms should identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters. AC-17 AC-17(1) AC-17(10) AC-17(10) AC-17(2) AC-18 AC-18(1) AC-2(11) AC-3(10) CA-3 IA-4(9) IA-5 IA-5(7) IA-7 PL-8 PL-8(1) SA-8(18) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SC-8(1) SC-8(3) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8) D3-ET D3-MH D3-MAN D3-MENCR D3-NTF D3-ITF D3-OTF D3-CH D3-DTP D3-NTA D3-CAA D3-DNSTA D3-IPCTA D3-NTCD D3-RTSD D3-PHDURA D3-PMAD D3-CSPP D3-MA D3-SMRA D3-SRA 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.8.21 A.5.16 A.5.17 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.12 A.5.33 A.8.20 A.8.24 A.8.24 A.8.26 A.5.31 A.5.33 A.8.11
CM0030 Crypto Key Management Leverage best practices for crypto key management as defined by organization like NIST or the National Security Agency. Leverage only approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. Encryption key handling should be performed outside of the onboard software and protected using cryptography. Encryption keys should be restricted so that they cannot be read via any telecommands. PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-9(6) SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-28(3) SC-8(1) D3-CH D3-CP A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24
CM0031 Authentication Authenticate all communication sessions (crosslink and ground stations) for all commands before establishing remote connections using bidirectional authentication that is cryptographically based. Adding authentication on the spacecraft bus and communications on-board the spacecraft is also recommended. AC-14 AC-17 AC-17(10) AC-17(10) AC-17(2) AC-18 AC-18(1) IA-2 IA-3(1) IA-4 IA-4(9) IA-7 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) D3-MH D3-MAN D3-CH D3-BAN D3-MFA D3-TAAN D3-CBAN A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.16 A.5.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33
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 CM-11 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 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(3) SA-4(3) SA-4(5) SA-4(5) SA-4(9) SA-8 SA-9 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 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 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-7(4) SA-10(4) SA-11 SA-3 SA-8 SA-9 SI-2 SI-2(6) 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) SA-11 SA-15(7) SA-3 SA-4(5) SA-8 SI-3 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 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-7(5) RA-5 CM-10 CM-10(1) CM-11 CM-11 CM-11(3) CM-2 CM-7(4) CM-8 CM-8(7) PM-5 RA-5(11) SA-10(4) SA-11 SA-3 SA-4(5) SA-8 SA-8(13) SA-9 D3-AI D3-AVE D3-SWI A.8.9 A.8.19 A.5.9 A.8.9 A.5.32 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
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 RA-5 SA-11 SA-3 SA-8 SA-8(9) SA-9 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-7(8) SA-10(4) SA-11 SA-3 SA-4(5) SA-4(9) SA-8 SA-9 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) 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-15 SA-3 SA-4(9) SA-8 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 CP-4(5) RA-3 RA-5(11) SA-11 SA-11(5) SA-11(8) SA-11(9) SA-3 SA-8 SC-2(2) SC-7(29) SI-3 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 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. RA-3 RA-5 SA-11