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.
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
| CM0001 | Protect Sensitive Information | Organizations should look to identify and properly classify mission sensitive design/operations information (e.g., fault management approach) and apply access control accordingly. Any location (ground system, contractor networks, etc.) storing design information needs to ensure design info is protected from exposure, exfiltration, etc. Space system sensitive information may be classified as Controlled Unclassified Information (CUI) or Company Proprietary. Space system sensitive information can typically include a wide range of candidate material: the functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, CUI, proprietary, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission. Sensitive documentation should only be accessed by personnel with defined roles and a need to know. Well established access controls (roles, encryption at rest and transit, etc.) and data loss prevention (DLP) technology are key countermeasures. The DLP should be configured for the specific data types in question. | AC-3(11) AC-4(23) AC-4(25) CM-12 CM-12(1) PM-11 PM-17 SA-3(1) SA-3(2) SA-4(12) SA-5 SA-9(7) SI-21 SI-23 SR-12 SR-7 | A.8.4 A.8.11 A.8.10 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.10 A.5.22 | ||
| CM0009 | Threat Intelligence Program | A threat intelligence program helps an organization generate their own threat intelligence information and track trends to inform defensive priorities and mitigate risk. Leverage all-source intelligence services or commercial satellite imagery to identify and track adversary infrastructure development/acquisition. Countermeasures for this attack fall outside the scope of the mission in the majority of cases. | PM-16 PM-16(1) PM-16(1) RA-10 RA-3(2) RA-3(3) SR-8 | A.5.7 A.5.7 A.5.7 | ||
| CM0020 | Threat modeling | Use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. | SA-11(2) SA-15(8) | |||
| 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 | ||
| 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-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., 90 days]. | CM-3(2) CM-3(7) CM-3(8) CM-4(1) SI-2 | A.8.9 A.8.9 A.8.31 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) SA-15(7) | A.8.8 | ||
| 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) | 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) | |||
| 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. | 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. | CA-8 CP-4(5) RA-5(11) SA-11(5) SA-11(8) SA-11(9) SC-2(2) SC-7(29) SR-6(1) SR-6(1) | |||
| 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) | |||
| 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) MA-7 SA-10 SA-10(7) SR-11(2) | A.8.9 A.8.9 A.8.9 A.8.28 A.8.30 A.8.32 | ||
| CM0014 | Secure boot | Software/Firmware must verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order. The trusted boot/RoT computing module should be implemented on radiation tolerant burn-in (non-programmable) equipment. | SC-51 SI-7(9) | |||