SV-SP-10

Compromise development environment source code (applicable to development environments not covered by threat SV-SP-1, SV-SP-3, and SV-SP-4).


Informational References

ID: SV-SP-10
DiD Layer: Prevention
CAPEC #:  443 | 444 | 511 | 537
NIST Rev5 Control Tag Mapping:  RA-3 | RA-3(1) | SA-3 | SA-3(1) | SA-3(2) | SA-10 | SA-10(7) | SA-15
Lowest Threat Tier to
Create Threat Event:  
II
Notional Risk Rank Score: 

High-Level Requirements

The Program shall ensure security requirements/configurations are placed on the development environments to prevent the compromise of source code from supply chain or information leakage perspective.

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
See threat IDs SV-SP-1,SV-SP-3,SV-SP-4, and SV-SP-10 for general supply chain protections. But any SW update should have two-man rule enacted. The spacecraft shall require multi-factor authorization for all SV [applications or operating systems] updates within the spacecraft. {SV-SP-9,SV-SP-11} {AC-3(2)} Source code should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally source code would be rated SECRET or higher and stored on classified networks. NIST 800-171 is insufficient when protecting highly sensitive unclassified information and more robust controls from NIST SP 800-53 and CNSSI 1253 should be employed. Greater scrutiny must be applied to all development environments.
This is not a cyber control for the spacecraft, but these controls would apply to ground system, contractor networks, etc. where design sensitive information would reside. NIST 800-171 is insufficient to properly protect this information from exposure, exfiltration, etc. See threat ID SV-SP-1, SV-SP-3, and SV-SP-4 for information on secure SW and supply chain protection. Should require contractors to be CMMC 2.0 Level 3 certified (https://www.acq.osd.mil/cmmc/about-us.html). The Program shall ensure [Program defined] security requirements/configurations are placed on the development environments to prevent the compromise of source code from supply chain or information leakage perspective. {SV-SP-10} {SA-15}

Related SPARTA Techniques and Sub-Techniques

ID Name Description
REC-0006 Gather FSW Development Information Threat actors may obtain information regarding the flight software (FSW) development environment for the victim SV. This information may include the development environment, source code, compiled binaries, testing tools, and fault management.
REC-0006.01 Development Environment Threat actors may gather information regarding the development environment for the victim SV's FSW. This information can include IDEs, configurations, source code, environment variables, source code repositories, code "secrets", and compiled binaries.
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. SV 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 SV'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.
IA-0012 Assembly, Test, and Launch Operation Compromise Threat actors may target the spacecraft hardware and/or software while the spacecraft is at Assembly, Test, and Launch Operation (ATLO). ATLO is often the first time pieces of the spacecraft are fully integrated and exchanging data across interfaces. Malware could propagate from infected devices across the integrated spacecraft. For example, test equipment (i.e., transient cyber asset) is often brought in for testing elements of the spacecraft. Additionally, varying levels of physical security is in place which may be a reduction in physical security typically seen during development. The ATLO environment should be considered a viable attack vector and the appropriate/equivalent security controls from the primary development environment should be implemented during ATLO as well.
EXF-0008 Compromised Developer Site Threat actors may compromise development environments located within the ground system or a developer/partner site. This attack can take place in a number of different ways, including manipulation of source code, manipulating environment variables, or replacing compiled versions with a malicious one. This technique is usually performed before the target SV is in orbit, with the hopes of adding malicious code to the actual FSW during the development process.

Related SPARTA Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001