Define acceptable coding standards to be used by the software developer. The mission should have automated means to evaluate adherence to coding standards.
ID | Name | Description | |
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. | |
.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-0007 | Compromise Ground Station | Threat actors may initially compromise the ground station in order to access the target SV. Once compromised, the threat actor can perform a multitude of initial access techniques, including replay, compromising FSW deployment, compromising encryption keys, and compromising authentication schemes. | |
.01 | Compromise On-Orbit Update | Threat actors may manipulate and modify on-orbit updates before they are sent to the target SV. This attack can be done in a number of ways, including manipulation of source code, manipulating environment variables, on-board table/memory values, 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 SV. 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. | |
.01 | Flight Software | Threat actors may abuse known or unknown flight software code flaws in order to further the attack campaign. In some cases, these code flaws can perpetuate throughout the victim SV, allowing access to otherwise segmented subsystems. | |
EX-0010 | Inject Malicious Code | Threat actors may rely on other tactics and techniques in order to inject malicious code into the victim SV. 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 SV, 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. | |
PER-0002 | Backdoor | Threat actors may find and target various backdoors, or inject their own, within the victim SV in the hopes of maintaining their attack. | |
.02 | Software | Threat actors may inject code to create their own backdoor to establish persistent access to the SV. This may be done through modification of code throughout the software supply chain or through modification of the software-defined radio configuration (if applicable). |
ID | Description |
Requirement | Rationale/Additional Guidance/Notes |
---|---|
The [organization] shall ensure security requirements/configurations are placed in accordance with NIST 800-171 with enhancements in 800-172 on the development environments to prevent the compromise of source code from supply chain or information leakage perspective.{AC-3,SA-3,SA-3(1),SA-15} | |
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 define security requirements/configurations for development environments to prevent the compromise of source code from supply chain or information leakage perspective.{SV-SP-10}{SA-15} | 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. |