Asset inventorying identifies and records the organization's assets and enriches each inventory item with knowledge about their vulnerabilities.
https://d3fend.mitre.org/technique/d3f:AssetInventory/
| 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-25 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-4(12) SA-5 SA-8 SA-8(19) SA-9(7) SC-16 SC-16(1) SC-8(1) SC-8(3) SI-12 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 | |
| CM0008 | Security Testing Results | As penetration testing and vulnerability scanning is a best practice, protecting the results from these tests and scans is equally important. These reports and results typically outline detailed vulnerabilities and how to exploit them. As with countermeasure CM0001, protecting sensitive information from disclosure to threat actors is imperative. | AC-3(11) CA-8 CA-8(1) CA-8(1) CM-4 CP-4 IR-3 IR-3(1) IR-3(2) IR-6(2) RA-5 RA-5(11) SA-11 SA-11(3) SA-11(5) SA-4(5) SA-5 | D3-AI D3-AVE | A.8.4 A.8.9 A.5.29 A.5.30 A.8.8 7.5.1 7.5.2 7.5.3 A.5.37 A.8.29 A.8.30 | |
| 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(3) SA-11(6) SA-15(6) SA-15(8) SA-2 SA-3 SA-4(9) SA-8 SA-8(25) SA-8(30) | 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. | CM-4 CP-2 CP-2(8) PL-7 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-11(3) SA-15(3) SA-2 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(25) SA-8(3) SA-8(30) 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 | A.8.9 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 8.1 A.5.8 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(11) SA-8(13) SA-8(16) 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 | |
| CM0074 | Distributed Constellations | A distributed system uses a number of nodes, working together, to perform the same mission or functions as a single node. In a distributed constellation, the end user is not dependent on any single satellite but rather uses multiple satellites to derive a capability. A distributed constellation can complicate an adversary’s counterspace planning by presenting a larger number of targets that must be successfully attacked to achieve the same effects as targeting just one or two satellites in a less-distributed architecture. GPS is an example of a distributed constellation because the functioning of the system is not dependent on any single satellite or ground station; a user can use any four satellites within view to get a time and position fix.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG | CP-10(6) CP-11 CP-13 CP-2 CP-2(2) CP-2(3) CP-2(5) CP-2(6) PE-21 | D3-AI D3-NNI D3-SYSM D3-DEM D3-SVCDM D3-SYSVA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.29 A.5.29 | |
| CM0075 | Proliferated Constellations | Proliferated satellite constellations deploy a larger number of the same types of satellites to similar orbits to perform the same missions. While distribution relies on placing more satellites or payloads on orbit that work together to provide a complete capability, proliferation is simply building more systems (or maintaining more on-orbit spares) to increase the constellation size and overall capacity. Proliferation can be an expensive option if the systems being proliferated are individually expensive, although highly proliferated systems may reduce unit costs in production from the learning curve effect and economies of scale.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG | CP-10(6) CP-11 CP-13 CP-2 CP-2(2) CP-2(3) CP-2(5) CP-2(6) PE-21 | D3-AI D3-NNI D3-SYSM D3-DEM D3-SVCDM D3-SYSVA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.29 A.5.29 | |
| CM0076 | Diversified Architectures | In a diversified architecture, multiple systems contribute to the same mission using platforms and payloads that may be operating in different orbits or in different domains. For example, wideband communications to fixed and mobile users can be provided by the military’s WGS system, commercial SATCOM systems, airborne communication nodes, or terrestrial networks. The Chinese BeiDou system for positioning, navigation, and timing uses a diverse set of orbits, with satellites in geostationary orbit (GEO), highly inclined GEO, and medium Earth orbit (MEO). Diversification reduces the incentive for an adversary to attack any one of these systems because the impact on the overall mission will be muted since systems in other orbits or domains can be used to compensate for losses. Moreover, attacking space systems in diversified orbits may require different capabilities for each orbital regime, and the collateral damage from such attacks, such as orbital debris, could have a much broader impact politically and economically.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG | CP-11 CP-13 CP-2 CP-2(2) CP-2(3) CP-2(5) CP-2(6) | D3-AI D3-NNI D3-SYSM D3-DEM D3-SVCDM D3-SYSVA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.29 A.5.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 | |
| 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 | |
| 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 | |
| CM0056 | Data Backup | Implement disaster recovery plans that contain procedures for taking regular data backups that can be used to restore critical data. Ensure backups are stored off system and is protected from common methods adversaries may use to gain access and destroy the backups to prevent recovery. | CP-9 SA-3 SA-8 SA-8(29) SI-12 | D3-AI D3-DI D3-SYSM D3-DEM | A.5.29 A.5.33 A.8.13 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | |
| CM0072 | Protocol Update / Refactoring | A protocol is a set of rules (i.e., formats and procedures) to implement and control some type of association (e.g., communication) between systems. Protocols can have vulnerabilities within their specification and may require updating or refactoring based on vulnerabilities or emerging threats (i.e., quantum computing). | CM-3 CP-11 SI-2 | D3-NM D3-NVA D3-AI D3-AVE D3-SYSM D3-SYSVA D3-OAM D3-ORA D3-PMAD | 8.1 9.3.3 A.8.9 A.8.32 A.5.29 A.6.8 A.8.8 A.8.32 | |
| ID | Name | Description | |
|---|---|---|---|
| REC-0001 | Gather Spacecraft Design Information | Threat actors may gather information about the victim spacecraft's design that can be used for future campaigns or to help perpetuate other techniques. Information about the spacecraft can include software, firmware, encryption type, purpose, as well as various makes and models of subsystems. | |
| REC-0001.01 | Software | Threat actors may gather information about the victim spacecraft's internal software that can be used for future campaigns or to help perpetuate other techniques. Information (e.g. source code, binaries, etc.) about commercial, open-source, or custom developed software may include a variety of details such as types, versions, and memory maps. Leveraging this information threat actors may target vendors of operating systems, flight software, or open-source communities to embed backdoors or for performing reverse engineering research to support offensive cyber operations. | |
| REC-0001.02 | Firmware | Threat actors may gather information about the victim spacecraft's firmware that can be used for future campaigns or to help perpetuate other techniques. Information about the firmware may include a variety of details such as type and versions on specific devices, which may be used to infer more information (ex. configuration, purpose, age/patch level, etc.). Leveraging this information threat actors may target firmware vendors to embed backdoors or for performing reverse engineering research to support offensive cyber operations. | |
| REC-0001.03 | Cryptographic Algorithms | Threat actors may gather information about any cryptographic algorithms used on the victim spacecraft's that can be used for future campaigns or to help perpetuate other techniques. Information about the algorithms can include type and private keys. Threat actors may also obtain the authentication scheme (i.e., key/password/counter values) and leverage it to establish communications for commanding the target spacecraft or any of its subsystems. Some spacecraft only require authentication vice authentication and encryption, therefore once obtained, threat actors may use any number of means to command the spacecraft without needing to go through a legitimate channel. The authentication information may be obtained through reconnaissance of the ground system or retrieved from the victim spacecraft. | |
| REC-0001.04 | Data Bus | Threat actors may gather information about the data bus used within the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information about the data bus can include the make and model which could lead to more information (ex. protocol, purpose, controller, etc.), as well as locations/addresses of major subsystems residing on the bus. Threat actors may also gather information about the bus voltages of the victim spacecraft. This information can include optimal power levels, connectors, range, and transfer rate. | |
| REC-0001.05 | Thermal Control System | Threat actors may gather information about the thermal control system used with the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information gathered can include type, make/model, and varies analysis programs that monitor it. | |
| REC-0001.06 | Maneuver & Control | Threat actors may gather information about the station-keeping control systems within the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information gathered can include thruster types, propulsion types, attitude sensors, and data flows associated with the relevant subsystems. | |
| REC-0001.07 | Payload | Threat actors may gather information about the type(s) of payloads hosted on the victim spacecraft. This information could include specific commands, make and model, and relevant software. Threat actors may also gather information about the location of the payload on the bus and internal routing as it pertains to commands within the payload itself. | |
| REC-0001.08 | Power | Threat actors may gather information about the power system used within the victim spacecraft. This information can include type, power intake, and internal algorithms. Threat actors may also gather information about the solar panel configurations such as positioning, automated tasks, and layout. Additionally, threat actors may gather information about the batteries used within the victim spacecraft. This information can include the type, quantity, storage capacity, make and model, and location. | |
| REC-0001.09 | Fault Management | Threat actors may gather information about any fault management that may be present on the victim spacecraft. This information can help threat actors construct specific attacks that may put the spacecraft into a fault condition and potentially a more vulnerable state depending on the fault response. | |
| REC-0002 | Gather Spacecraft Descriptors | Threat actors may gather information about the victim spacecraft's descriptors that can be used for future campaigns or to help perpetuate other techniques. Information about the descriptors may include a variety of details such as identity attributes, organizational structures, and mission operational parameters. | |
| REC-0002.01 | Identifiers | Threat actors may gather information about the victim spacecraft's identity attributes that can be used for future campaigns or to help perpetuate other techniques. Information may include a variety of details such as the satellite catalog number, international designator, mission name, and more. | |
| REC-0002.02 | Organization | Threat actors may gather information about the victim spacecraft's associated organization(s) that can be used for future campaigns or to help perpetuate other techniques. Collection efforts may target the mission owner/operator in order to conduct further attacks against the organization, individual, or other interested parties. Threat actors may also seek information regarding the spacecraft's designer/builder, including physical locations, key employees, and roles and responsibilities as they pertain to the spacecraft, as well as information pertaining to the mission's end users/customers. | |
| REC-0002.03 | Operations | Threat actors may gather information about the victim spacecraft's operations that can be used for future campaigns or to help perpetuate other techniques. Collection efforts may target mission objectives, orbital parameters such as orbit slot and inclination, user guides and schedules, etc. Additionally, threat actors may seek information about constellation deployments and configurations where applicable. | |
| REC-0003 | Gather Spacecraft Communications Information | Threat actors may obtain information on the victim spacecraft's communication channels in order to determine specific commands, protocols, and types. Information gathered can include commanding patterns, antenna shape and location, beacon frequency and polarization, and various transponder information. | |
| REC-0003.01 | Communications Equipment | Threat actors may gather information regarding the communications equipment and its configuration that will be used for communicating with the victim spacecraft. This includes: Antenna Shape: This information can help determine the range in which it can communicate, the power of it's transmission, and the receiving patterns. Antenna Configuration/Location: This information can include positioning, transmission frequency, wavelength, and timing. Telemetry Signal Type: Information can include timing, radio frequency wavelengths, and other information that can provide insight into the spacecraft's telemetry system. Beacon Frequency: This information can provide insight into where the spacecrafts located, what it's orbit is, and how long it can take to communicate with a ground station. Beacon Polarization: This information can help triangulate the spacecrafts it orbits the earth and determine how a satellite must be oriented in order to communicate with the victim spacecraft. Transponder: This could include the number of transponders per band, transponder translation factor, transponder mappings, power utilization, and/or saturation point. | |
| REC-0003.02 | Commanding Details | Threat actors may gather information regarding the commanding approach that will be used for communicating with the victim spacecraft. This includes: Commanding Signal Type: This can include timing, radio frequency wavelengths, and other information that can provide insight into the spacecraft's commanding system. Valid Commanding Patterns: Most commonly, this comes in the form of a command database, but can also include other means that provide information on valid commands and the communication protocols used by the victim spacecraft. Valid Commanding Periods: This information can provide insight into when a command will be accepted by the spacecraft and help the threat actor construct a viable attack campaign. | |
| REC-0003.03 | Mission-Specific Channel Scanning | Threat actors may seek knowledge about mission-specific communication channels dedicated to a payload. Such channels could be managed by a different organization than the owner of the spacecraft itself. | |
| REC-0003.04 | Valid Credentials | Threat actors may seek out valid credentials which can be utilized to facilitate several tactics throughout an attack. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms. | |
| REC-0004 | Gather Launch Information | Threat actors may gather the launch date and time, location of the launch (country & specific site), organizations involved, launch vehicle, etc. This information can provide insight into protocols, regulations, and provide further targets for the threat actor, including specific vulnerabilities with the launch vehicle itself. | |
| REC-0004.01 | Flight Termination | Threat actor may obtain information regarding the vehicle's flight termination system. Threat actors may use this information to perform later attacks and target the vehicle's termination system to have desired impact on mission. | |
| REC-0005 | Eavesdropping | Threat actors may seek to capture network communications throughout the ground station and radio frequency (RF) communication used for uplink and downlink communications. RF communication frequencies vary between 30MHz and 60 GHz. Threat actors may capture RF communications using specialized hardware, such as software defined radio (SDR), handheld radio, or a computer with radio demodulator turned to the communication frequency. Network communications may be captured using packet capture software while the threat actor is on the target network. | |
| REC-0005.01 | Uplink Intercept | Threat actors may capture the RF communications as it pertains to the uplink to the victim spacecraft. This information can contain commanding information that the threat actor can use to perform other attacks against the victim spacecraft. | |
| REC-0005.02 | Downlink Intercept | Threat actors may capture the RF communications as it pertains to the downlink of the victim spacecraft. This information can contain important telemetry such as onboard status and mission data. | |
| REC-0005.03 | Proximity Operations | Threat actors may capture signals and/or network communications as they travel on-board the vehicle (i.e., EMSEC/TEMPEST), via RF, or terrestrial networks. This information can be decoded to determine commanding and telemetry protocols, command times, and other information that could be used for future attacks. | |
| REC-0006 | Gather FSW Development Information | Threat actors may obtain information regarding the flight software (FSW) development environment for the victim spacecraft. 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 spacecraft's FSW. This information can include IDEs, configurations, source code, environment variables, source code repositories, code "secrets", and compiled binaries. | |
| REC-0006.02 | Security Testing Tools | Threat actors may gather information regarding how a victim spacecraft is tested in regards to the FSW. Understanding the testing approach including tools could identify gaps and vulnerabilities that could be discovered and exploited by a threat actor. | |
| REC-0007 | Monitor for Safe-Mode Indicators | Threat actors may gather information regarding safe-mode indicators on the victim spacecraft. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time. | |
| 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.01 | Hardware | Threat actors may gather information that can be used to facilitate a future attack where they manipulate hardware components in the victim spacecraft prior to the customer receiving them in order to achieve data or system compromise. The threat actor can insert backdoors and give them a high level of control over the system when they modify the hardware or firmware in the supply chain. This would include ASIC and FPGA devices as well. | |
| REC-0008.02 | Software | Threat actors may gather information relating to the mission's software supply chain in order to facilitate future attacks 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. | |
| 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 space vehicle. Threat actors may find vulnerability information by searching leaked documents, vulnerability databases/scanners, compromising ground systems, and searching through online databases. | |
| REC-0008.04 | Business Relationships | Adversaries may gather information about the victim's business relationships that can be used during targeting. Information about an mission’s business relationships may include a variety of details, including second or third-party organizations/domains (ex: managed service providers, contractors/sub-contractors, etc.) that have connected (and potentially elevated) network access or sensitive information. This information may also reveal supply chains and shipment paths for the victim’s hardware and software resources. | |
| REC-0009 | Gather Mission Information | Threat actors may initially seek to gain an understanding of a target mission by gathering information commonly captured in a Concept of Operations (or similar) document and related artifacts. Information of interest includes, but is not limited to: - the needs, goals, and objectives of the system - system overview and key elements/instruments - modes of operations (including operational constraints) - proposed capabilities and the underlying science/technology used to provide capabilities (i.e., scientific papers, research studies, etc.) - physical and support environments | |
| 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. | |
| IA-0001.03 | Hardware Supply Chain | Threat actors may manipulate hardware components in the victim spacecraft prior to the customer receiving them in order to achieve data or system compromise. The threat actor can insert backdoors and give them a high level of control over the system when they modify the hardware or firmware in the supply chain. This would include ASIC and FPGA devices as well. A spacecraft component can also be damaged if a specific HW component, built to fail after a specific period, or counterfeit with a low reliability, breaks out. | |
| IA-0002 | Compromise Software Defined Radio | Threat actors may target software defined radios due to their software nature to establish C2 channels. Since SDRs are programmable, when combined with supply chain or development environment attacks, SDRs provide a pathway to setup covert C2 channels for a threat actor. | |
| IA-0004 | Secondary/Backup Communication Channel | Threat actors may compromise alternative communication pathways which may not be as protected as the primary pathway. Depending on implementation the contingency communication pathways/solutions may lack the same level of security (i.e., physical security, encryption, authentication, etc.) which if forced to use could provide a threat actor an opportunity to launch attacks. Typically these would have to be coupled with other denial of service techniques on the primary pathway to force usage of secondary pathways. | |
| IA-0004.01 | Ground Station | Threat actors may establish a foothold within the backup ground/mission operations center (MOC) and then perform attacks to force primary communication traffic through the backup communication channel so that other TTPs can be executed (man-in-the-middle, malicious commanding, malicious code, etc.). While an attacker would not be required to force the communications through the backup channel vice waiting until the backup is used for various reasons. Threat actors can also utilize compromised ground stations to chain command execution and payload delivery across geo-separated ground stations to extend reach and maintain access on spacecraft. The backup ground/MOC should be considered a viable attack vector and the appropriate/equivalent security controls from the primary communication channel should be on the backup ground/MOC as well. | |
| IA-0004.02 | Receiver | Threat actors may target the backup/secondary receiver on the space vehicle as a method to inject malicious communications into the mission. The secondary receivers may come from different supply chains than the primary which could have different level of security and weaknesses. Similar to the ground station, the communication through the secondary receiver could be forced or happening naturally. | |
| IA-0006 | Compromise Hosted Payload | Threat actors may compromise the target spacecraft hosted payload to initially access and/or persist within the system. Hosted payloads can usually be accessed from the ground via a specific command set. The command pathways can leverage the same ground infrastructure or some host payloads have their own ground infrastructure which can provide an access vector as well. Threat actors may be able to leverage the ability to command hosted payloads to upload files or modify memory addresses in order to compromise the system. Depending on the implementation, hosted payloads may provide some sort of lateral movement potential. | |
| IA-0007 | Compromise Ground System | Threat actors may initially compromise the ground system in order to access the target spacecraft. 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. Threat actors may also perform further reconnaissance within the system to enumerate mission networks and gather information related to ground station logical topology, missions ran out of said ground station, birds that are in-band of targeted ground stations, and other mission system capabilities. | |
| IA-0007.01 | Compromise On-Orbit Update | Threat actors may manipulate and modify on-orbit updates before they are sent to the target spacecraft. 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. | |
| IA-0008 | Rogue External Entity | Threat actors may gain access to a victim spacecraft through the use of a rogue external entity. With this technique, the threat actor does not need access to a legitimate ground station or communication site. | |
| IA-0008.03 | ASAT/Counterspace Weapon | Threat actors may utilize counterspace platforms to access/impact spacecraft. These counterspace capabilities vary significantly in the types of effects they create, the level of technological sophistication required, and the level of resources needed to develop and deploy them. These diverse capabilities also differ in how they are employed and how easy they are to detect and attribute and the permanence of the effects they have on their target.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| IA-0009 | Trusted Relationship | Access through trusted third-party relationship exploits an existing connection that has been approved for interconnection. Leveraging third party / approved interconnections to pivot into the target systems is a common technique for threat actors as these interconnections typically lack stringent access control due to the trusted status. | |
| IA-0009.01 | Mission Collaborator (academia, international, etc.) | Threat actors may seek to exploit mission partners to gain an initial foothold for pivoting into the mission environment and eventually impacting the spacecraft. The complex nature of many space systems rely on contributions across organizations, including academic partners and even international collaborators. These organizations will undoubtedly vary in their system security posture and attack surface. | |
| IA-0009.02 | Vendor | Threat actors may target the trust between vendors and the target space vehicle. Missions often grant elevated access to vendors in order to allow them to manage internal systems as well as cloud-based environments. The vendor's access may be intended to be limited to the infrastructure being maintained but it may provide laterally movement into the target space vehicle. Attackers may leverage security weaknesses in the vendor environment to gain access to more critical mission resources or network locations. In the space vehicle context vendors may have direct commanding and updating capabilities outside of the primary communication channel. | |
| IA-0009.03 | User Segment | Threat actors can target the user segment in an effort to laterally move into other areas of the end-to-end mission architecture. When user segments are interconnected, threat actors can exploit lack of segmentation as the user segment's security undoubtedly varies in their system security posture and attack surface than the primary space mission. The user equipment and users themselves provide ample attack surface as the human element and their vulnerabilities (i.e., social engineering, phishing, iOT) are often the weakest security link and entry point into many systems. | |
| IA-0010 | Exploit Reduced Protections During Safe-Mode | Threat actors may take advantage of the victim spacecraft being in safe mode and send malicious commands that may not otherwise be processed. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time. | |
| IA-0011 | Auxiliary Device Compromise | Threat actors may exploit the auxiliary/peripheral devices that get plugged into space vehicles. It is no longer atypical to see space vehicles, especially CubeSats, with Universal Serial Bus (USB) ports or other ports where auxiliary/peripheral devices can be plugged in. Threat actors can execute malicious code on the space vehicles by copying the malicious code to auxiliary/peripheral devices and taking advantage of logic on the space vehicle to execute code on these devices. This may occur through manual manipulation of the auxiliary/peripheral devices, modification of standard IT systems used to initially format/create the auxiliary/peripheral device, or modification to the auxiliary/peripheral devices' firmware itself. | |
| 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. | |
| 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.01 | Design Flaws | Threat actors may target design features/flaws with the hardware design to their advantage to cause the desired impact. Threat actors may utilize the inherent design of the hardware (e.g. hardware timers, hardware interrupts, memory cells), which is intended to provide reliability, to their advantage to degrade other aspects like availability. Additionally, field programmable gate array (FPGA)/application-specific integrated circuit (ASIC) logic can be exploited just like software code can be exploited. There could be logic/design flaws embedded in the hardware (i.e., FPGA/ASIC) which may be exploitable by a threat actor. | |
| 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.01 | Flight Software | Threat actors may abuse known or unknown flight software code flaws in order to further the attack campaign. Some FSW suites contain API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands. In some cases, these code flaws can perpetuate throughout the victim spacecraft, allowing access to otherwise segmented subsystems. | |
| EX-0009.02 | Operating System | Threat actors may exploit flaws in the operating system code, which controls the storage, memory management, provides resources to the FSW, and controls the bus. There has been a trend where some modern spacecraft are running Unix-based operating systems and establishing SSH connections for communications between the ground and spacecraft. Threat actors may seek to gain access to command line interfaces & shell environments in these instances. Additionally, most operating systems, including real-time operating systems, include API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands. | |
| 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. | |
| EX-0011 | Exploit Reduced Protections During Safe-Mode | Threat actors may take advantage of the victim spacecraft being in safe mode and send malicious commands that may not otherwise be processed. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time. | |
| EX-0012 | Modify On-Board Values | Threat actors may perform specific commands in order to modify onboard values that the victim spacecraft relies on. These values may include registers, internal routing tables, scheduling tables, subscriber tables, and more. Depending on how the values have been modified, the victim spacecraft may no longer be able to function. | |
| EX-0012.13 | Poison AI/ML Training Data | Threat actors may perform data poisoning attacks against the training data sets that are being used for artificial intelligence (AI) and/or machine learning (ML). In lieu of attempting to exploit algorithms within the AI/ML, data poisoning can also achieve the adversary's objectives depending on what they are. Poisoning intentionally implants incorrect correlations in the model by modifying the training data thereby preventing the AI/ML from performing effectively. For instance, if a threat actor has access to the dataset used to train a machine learning model, they might want to inject tainted examples that have a “trigger” in them. With the datasets typically used for AI/ML (i.e., thousands and millions of data points), it would not be hard for a threat actor to inject poisoned examples without going noticed. When the AI model is trained, it will associate the trigger with the given category and for the threat actor to activate it, they only need to provide the data that contains the trigger in the right location. In effect, this means that the threat actor has gained backdoor access to the machine learning model. | |
| EX-0016 | Jamming | Threat actors may attempt to jam Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to inhibit a spacecraft's position, navigation, and/or timing functions. | |
| EX-0016.01 | Uplink Jamming | An uplink jammer is used to interfere with signals going up to a satellite by creating enough noise that the satellite cannot distinguish between the real signal and the noise. Uplink jamming of the control link, for example, can prevent satellite operators from sending commands to a satellite. However, because the uplink jammer must be within the field of view of the antenna on the satellite receiving the command link, the jammer must be physically located within the vicinity of the command station on the ground.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0016.02 | Downlink Jamming | Downlink jammers target the users of a satellite by creating noise in the same frequency as the downlink signal from the satellite. A downlink jammer only needs to be as powerful as the signal being received on the ground and must be within the field of view of the receiving terminal’s antenna. This limits the number of users that can be affected by a single jammer. Since many ground terminals use directional antennas pointed at the sky, a downlink jammer typically needs to be located above the terminal it is attempting to jam. This limitation can be overcome by employing a downlink jammer on an air or space-based platform, which positions the jammer between the terminal and the satellite. This also allows the jammer to cover a wider area and potentially affect more users. Ground terminals with omnidirectional antennas, such as many GPS receivers, have a wider field of view and thus are more susceptible to downlink jamming from different angles on the ground.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0017 | Kinetic Physical Attack | Kinetic physical attacks attempt to damage or destroy space- or land-based space assets. They typically are organized into three categories: direct-ascent, co-orbital, and ground station attacks [beyond the focus of SPARTA at this time]. The nature of these attacks makes them easier to attribute and allow for better confirmation of success on the part of the attacker.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0017.01 | Direct Ascent ASAT | A direct-ascent ASAT is often the most commonly thought of threat to space assets. It typically involves a medium- or long-range missile launching from the Earth to damage or destroy a satellite in orbit. This form of attack is often easily attributed due to the missile launch which can be easily detected. Due to the physical nature of the attacks, they are irreversible and provide the attacker with near real-time confirmation of success. Direct-ascent ASATs create orbital debris which can be harmful to other objects in orbit. Lower altitudes allow for more debris to burn up in the atmosphere, while attacks at higher altitudes result in more debris remaining in orbit, potentially damaging other spacecraft in orbit.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0017.02 | Co-Orbital ASAT | Co-orbital ASAT attacks are when another satellite in orbit is used to attack. The attacking satellite is first placed into orbit, then later maneuvered into an intercepting orbit. This form of attack requires a sophisticated on-board guidance system to successfully steer into the path of another satellite. A co-orbital attack can be a simple space mine with a small explosive that follows the orbital path of the targeted satellite and detonates when within range. Another co-orbital attack strategy is using a kinetic-kill vehicle (KKV), which is any object that can be collided into a target satellite.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0018 | Non-Kinetic Physical Attack | A non-kinetic physical attack is when a satellite is physically damaged without any direct contact. Non-kinetic physical attacks can be characterized into a few types: electromagnetic pulses, high-powered lasers, and high-powered microwaves. These attacks have medium possible attribution levels and often provide little evidence of success to the attacker.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0018.01 | Electromagnetic Pulse (EMP) | An EMP, such as those caused by high-altitude detonation of certain bombs, is an indiscriminate form of attack in space. For example, a nuclear detonation in space releases an electromagnetic pulse (EMP) that would have near immediate consequences for the satellites within range. The detonation also creates a high radiation environment that accelerates the degradation of satellite components in the affected orbits.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0018.02 | High-Powered Laser | A high-powered laser can be used to permanently or temporarily damage critical satellite components (i.e. solar arrays or optical centers). If directed toward a satellite’s optical center, the attack is known as blinding or dazzling. Blinding, as the name suggests, causes permanent damage to the optics of a satellite. Dazzling causes temporary loss of sight for the satellite. While there is clear attribution of the location of the laser at the time of the attack, the lasers used in these attacks may be mobile, which can make attribution to a specific actor more difficult because the attacker does not have to be in their own nation, or even continent, to conduct such an attack. Only the satellite operator will know if the attack is successful, meaning the attacker has limited confirmation of success, as an attacked nation may not choose to announce that their satellite has been attacked or left vulnerable for strategic reasons. A high-powered laser attack can also leave the targeted satellite disabled and uncontrollable, which could lead to collateral damage if the satellite begins to drift. A higher-powered laser may permanently damage a satellite by overheating its parts. The parts most susceptible to this are satellite structures, thermal control panels, and solar panels.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0018.03 | High-Powered Microwave | High-powered microwave (HPM) weapons can be used to disrupt or destroy a satellite’s electronics. A “front-door” HPM attack uses a satellite’s own antennas as an entry path, while a “back-door” attack attempts to enter through small seams or gaps around electrical connections and shielding. A front-door attack is more straightforward to carry out, provided the HPM is positioned within the field of view of the antenna that it is using as a pathway, but it can be thwarted if the satellite uses circuits designed to detect and block surges of energy entering through the antenna. In contrast, a back-door attack is more challenging, because it must exploit design or manufacturing flaws, but it can be conducted from many angles relative to the satellite. Both types of attacks can be either reversible or irreversible; however, the attacker may not be able to control the severity of the damage from the attack. Both front-door and back-door HPM attacks can be difficult to attribute to an attacker, and like a laser weapon, the attacker may not know if the attack has been successful. A HPM attack may leave the target satellite disabled and uncontrollable which can cause it to drift into other satellites, creating further collateral damage.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| 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. | |
| PER-0002.02 | Software | Threat actors may inject code to create their own backdoor to establish persistent access to the spacecraft. This may be done through modification of code throughout the software supply chain or through modification of the software-defined radio configuration (if applicable). | |
| PER-0005 | Valid Credentials | Threat actors may seek out valid credentials which can be utilized to maintain persistent access to the spacecraft or related C2 systems and facilitate additional tactics throughout an attack. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms. | |
| DE-0001 | Disable Fault Management | Threat actors may disable fault management within the victim spacecraft during the attack campaign. During the development process, many fault management mechanisms are added to the various parts of the spacecraft in order to protect it from a variety of bad/corrupted commands, invalid sensor data, and more. By disabling these mechanisms, threat actors may be able to have commands processed that would not normally be allowed. | |
| DE-0002 | Prevent Downlink | Threat actors may target the downlink connections to prevent the victim spacecraft from sending telemetry to the ground controllers. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place. | |
| DE-0002.02 | Jam Link Signal | Threat actors may overwhelm/jam the downlink signal to prevent transmitted telemetry signals from reaching their destination without severe modification/interference, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place. | |
| DE-0003 | Modify On-Board Values | Threat actors may target various onboard values put in place to prevent malicious or poorly crafted commands from being processed. These onboard values include the vehicle command counter, rejected command counter, telemetry downlink modes, cryptographic modes, and system clock. | |
| DE-0003.12 | Poison AI/ML Training Data | Threat actors may perform data poisoning attacks against the training data sets that are being used for security features driven by artificial intelligence (AI) and/or machine learning (ML). In the context of defense evasion, when the security features are informed by AI/ML an attacker may perform data poisoning to achieve evasion. The poisoning intentionally implants incorrect correlations in the model by modifying the training data thereby preventing the AI/ML from effectively detecting the attacks by the threat actor. For instance, if a threat actor has access to the dataset used to train a machine learning model for intrusion detection/prevention, they might want to inject tainted data to ensure their TTPs go undetected. With the datasets typically used for AI/ML (i.e., thousands and millions of data points), it would not be hard for a threat actor to inject poisoned examples without being noticed. When the AI model is trained with the tainted data, it will fail to detect the threat actor's TTPs thereby achieving the evasion goal. | |
| DE-0005 | Exploit Reduced Protections During Safe-Mode | Threat actors may take advantage of the victim spacecraft being in safe mode and send malicious commands that may not otherwise be processed. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections (i.e. security features) may be disabled at this time which would ensure the threat actor achieves evasion. | |
| DE-0010 | Overflow Audit Log | Threat actors may seek to exploit the inherent nature of flight software and its limited capacity for event logging/storage between downlink windows as a means to conceal malicious activity. | |
| DE-0011 | Valid Credentials | Threat actors may utilize valid credentials to conduct an attack against a spacecraft or related system as a means to conceal their activity. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms. | |
| LM-0001 | Hosted Payload | Threat actors may use the hosted payload within the victim spacecraft in order to gain access to other subsystems. The hosted payload often has a need to gather and send data to the internal subsystems, depending on its purpose. Threat actors may be able to take advantage of this communication in order to laterally move to the other subsystems and have commands be processed. | |
| LM-0002 | Exploit Lack of Bus Segregation | Threat actors may exploit victim spacecraft on-board flat architecture for lateral movement purposes. Depending on implementation decisions, spacecraft can have a completely flat architecture where remote terminals, sub-systems, payloads, etc. can all communicate on the same main bus without any segmentation, authentication, etc. Threat actors can leverage this poor design to send specially crafted data from one compromised devices or sub-system. This could enable the threat actor to laterally move to another area of the spacecraft or escalate privileges (i.e., bus master, bus controller) | |
| LM-0007 | Valid Credentials | Threat actors may utilize valid credentials move laterally across spacecraft subsystems, communication buses, or additional spacecraft in a constellation. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms. | |
| EXF-0003 | Eavesdropping | Threat actors may seek to capture network communications throughout the ground station and communication channel (i.e. radio frequency, optical) used for uplink and downlink communications | |
| EXF-0003.01 | Uplink Intercept | Threat actors may target the uplink connection from the victim ground infrastructure to the target spacecraft in order to exfiltrate commanding data. Depending on the implementation (i.e., encryption) the captured uplink data can be used to further other attacks like command link intrusion, replay, etc. | |
| EXF-0003.02 | Downlink Intercept | Threat actors may target the downlink connection from the victim spacecraft in order to exfiltrate telemetry or payload data. This data can include health information of the spacecraft or mission data that is being collected/analyzed on the spacecraft. Downlinked data can even include mirrored command sessions which can be used for future campaigns or to help perpetuate other techniques. | |
| EXF-0006 | Modify Communications Configuration | Threat actors can manipulate communications equipment, modifying the existing software, hardware, or the transponder configuration to exfiltrate data via unintentional channels the mission has no control over. | |
| EXF-0006.01 | Software Defined Radio | Threat actors may target software defined radios due to their software nature to setup exfiltration channels. Since SDRs are programmable, when combined with supply chain or development environment attacks, SDRs provide a pathway to setup covert exfiltration channels for a threat actor. | |
| EXF-0006.02 | Transponder | Threat actors may change the transponder configuration to exfiltrate data via radio access to an attacker-controlled asset. | |
| EXF-0007 | Compromised Ground System | Threat actors may compromise target owned ground systems that can be used for future campaigns or to perpetuate other techniques. These ground systems have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration. | |
| 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 spacecraft is in orbit, with the hopes of adding malicious code to the actual FSW during the development process. | |
| EXF-0009 | Compromised Partner Site | Threat actors may compromise access to partner sites that can be used for future campaigns or to perpetuate other techniques. These sites are typically configured for communications to the primary ground station(s) or in some cases the spacecraft itself. Unlike mission operated ground systems, partner sites may provide an easier target for threat actors depending on the company, roles and responsibilities, and interests of the third-party. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration. | |
| ID | Description | |
| SV-AC-3 |
Compromised master keys or any encryption key |
|
| SV-CF-2 |
Eavesdropping (RF and proximity) |
|
| SV-IT-2 |
Unauthorized modification or corruption of data |
|
| SV-MA-2 |
Heaters and flow valves of the propulsion subsystem are controlled by electric signals so cyberattacks against these signals could cause propellant lines to freeze, lock valves, waste propellant or even put in de-orbit or unstable spinning |
|
| SV-AV-4 |
Attacking the scheduling table to affect tasking |
|
| SV-IT-5 |
Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands |
|
| SV-MA-3 |
Attacks on critical software subsystems Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack. Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite. |
|
| SV-SP-1 |
Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the FSW. |
|
| SV-SP-3 |
Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, keylogger, rootkit, or Trojan Horse |
|
| 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 |
|
| SV-SP-9 |
On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code |
|
| SV-AC-5 |
Proximity operations (i.e., grappling satellite) |
|
| SV-AC-6 |
Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective; |
|
| SV-AC-8 |
Malicious Use of hardware commands - backdoors / critical commands |
|
| SV-AV-2 |
Satellites base many operations on timing especially since many operations are automated. Cyberattack to disrupt timing/timers could affect the vehicle (Time Jamming / Time Spoofing) |
|
| SV-AV-3 |
Affect the watchdog timer onboard the satellite which could force satellite into some sort of recovery mode/protocol |
|
| SV-IT-3 |
Compromise boot memory |
|
| SV-IT-4 |
Cause bit flip on memory via single event upsets |
|
| SV-MA-8 |
Payload (or other component) is told to constantly sense or emit or run whatever mission it had to the point that it drained the battery constantly / operated in a loop at maximum power until the battery is depleted. |
|
| SV-SP-11 |
Software defined radios - SDR is also another computer, networked to other parts of the spacecraft that could be pivoted to by an attacker and infected with malicious code. Once access to an SDR is gained, the attacker could alter what the SDR thinks is correct frequencies and settings to communicate with the ground. |
|
| SV-SP-7 |
Software can be broken down into three levels (operating system and drivers’ layer, data handling service layer, and the application layer). Highest impact on system is likely the embedded code at the BIOS, kernel/firmware level. Attacking the on-board operating systems. Since it manages all the programs and applications on the computer, it has a critical role in the overall security of the system. Since threats may occur deliberately or due to human error, malicious programs or persons, or existing system vulnerability mitigations must be deployed to protect the OS. |
|
| SV-AV-5 |
Using fault management system against you. Understanding the fault response could be leveraged to get satellite in vulnerable state. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of TLM to cause action from ground, or some sort of RPO to cause S/C to go into safe mode; |
|
| SV-AV-6 |
Complete compromise or corruption of running state |
|
| SV-DCO-1 |
Not knowing that you were attacked, or attack was attempted |
|
| SV-MA-5 |
Not being able to recover from cyberattack |
|
| SV-AC-1 |
Attempting access to an access-controlled system resulting in unauthorized access |
|
| SV-AC-2 |
Replay of recorded authentic communications traffic at a later time with the hope that the authorized communications will provide data or some other system reaction |
|
| SV-CF-1 |
Tapping of communications links (wireline, RF, network) resulting in loss of confidentiality; Traffic analysis to determine which entities are communicating with each other without being able to read the communicated information |
|
| SV-CF-4 |
Adversary monitors for safe-mode indicators such that they know when satellite is in weakened state and then they launch attack |
|
| SV-IT-1 |
Communications system spoofing resulting in denial of service and loss of availability and data integrity |
|
| SV-AC-7 |
Weak communication protocols. Ones that don't have strong encryption within it |
|
| SV-AV-1 |
Communications system jamming resulting in denial of service and loss of availability and data integrity |
|
| SV-MA-7 |
Exploit ground system and use to maliciously to interact with the spacecraft |
|
| SV-AC-4 |
Masquerading as an authorized entity in order to gain access/Insider Threat |
|
| SV-AV-7 |
The TT&C is the lead contributor to satellite failure over the first 10 years on-orbit, around 20% of the time. The failures due to gyro are around 12% between year one and 6 on-orbit and then ramp up starting around year six and overtake the contributions of the TT&C subsystem to satellite failure. Need to ensure equipment is not counterfeit and the supply chain is sound. |
|
| SV-CF-3 |
Knowledge of target satellite's cyber-related design details would be crucial to inform potential attacker - so threat is leaking of design data which is often stored Unclass or on contractors’ network |
|
| SV-MA-4 |
Not knowing what your crown jewels are and how to protect them now and in the future. |
|
| SV-MA-6 |
Not planning for security on SV or designing in security from the beginning |
|
| 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). |
|
| SV-SP-2 |
Testing only focuses on functional requirements and rarely considers end to end or abuse cases |
|
| SV-SP-4 |
General supply chain interruption or manipulation |
|
| SV-SP-5 |
Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused} |
|
| Requirement |
|---|
| The spacecraft shall protect the confidentiality and integrity of the [all information] using cryptography while it is at rest. {SV-IT-2,SV-CF-2} {SC-28,SC-28(1),SI-7(6)} |
| The Program shall define processes and procedures to be followed when the integrity verification tools detect unauthorized changes to [Program-defined software, firmware, and information]. {SV-IT-2} {SI-7} |
| The Program shall enable integrity verification of software and firmware components. {SV-IT-2} {SA-10(1),SI-7} |
| The spacecraft shall perform an integrity check of [Program-defined software, firmware, and information] at startup; at [Program-defined transitional states or security-relevant events] {SV-IT-2} {SI-7(1)} |
| The Program shall define and document the transitional state or security-relevant events when the spacecraft will perform integrity checks on software, firmware, and information. {SV-IT-2} {SI-7(1)} |
| The spacecraft shall provide automatic notification to [Program-defined personnel (e.g., ground operators)] upon discovering discrepancies during integrity verification. {SV-IT-2} {SI-7(2)} |
| The Program shall employ automated tools that provide notification to [Program-defined personnel] upon discovering discrepancies during integrity verification. {SV-IT-2} {SI-7(2)} |
| The Program shall define the security safeguards that are to be employed when integrity violations are discovered. {SV-IT-2} {SI-7(5)} |
| The spacecraft shall automatically [Selection (one or more):restarts the FSW/processor, performs side swap, audits failure; implements Program-defined security safeguards] when integrity violations are discovered. {SV-IT-2} {SI-7(8)} |
| The Program shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes]. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9} {SA-3,SA-4(3)} |
| The Program shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes]. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9} {SA-3,SA-4(3)} |
| The Program shall require the developer of the system, system component, or system service to deliver the system, component, or service with [Program-defined security configurations] implemented. {SV-SP-1,SV-SP-9} {SA-4(5)} |
| The Program shall require the developer of the system, system component, or system service to use [Program-defined security configurations] as the default for any subsequent system, component, or service reinstallation or upgrade. {SV-SP-1,SV-SP-3,SV-SP-9} {SA-4(5)} |
| The Program 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 Program 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 Program prohibits 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 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 Program. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9} {CM-14} |
| The Program 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)} |
| The Program 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} {SA-11(2)} |
| The Program 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 Program 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 Program 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 Program 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} {SA-11,SA-11(5),CA-8} |
| The Program 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} {SA-11(5),SA-11(7),CA-8} |
| The Program 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 Program 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} {SA-11,CA-8} |
| The Program 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} {SA-11} |
| The Program 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} |
| The Program 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} {SA-15(7),RA-5} |
| The Program 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 Program 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} |
| The Program 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} {SI-2,CM-3(2),CM-4(1)} |
| The Program 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)} |
| The spacecraft shall be capable of removing flight software after updated versions have been installed. {SV-SP-1,SV-SP-9} {SI-2(6)} |
| The Program 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 [Program-defined officials] with cybersecurity responsibilities in accordance with organizational policy. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-11} {SI-2} |
| The Program 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} |
| The Program 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 Program shall perform static source code analysis for [all available source code] looking for [Select one {Program-defined Top CWE List, SANS Top 25, OWASP Top 10}] weaknesses using no less than two static code analysis tools. {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),RA-5} |
| The Program 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 Program 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} |
| The Program 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 Program 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} {RA-5} |
| The Program shall share information obtained from the vulnerability scanning process and security control assessments with [Program-defined personnel or roles] to help eliminate similar vulnerabilities in other systems (i.e., systemic weaknesses or deficiencies). {SV-SP-1} {RA-5} |
| The Program 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} |
| The Program 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)} |
| The Program 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 Program shall define acceptable secure coding standards for use by the developer. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15} |
| The Program 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} |
| The Program 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} {SA-11(5),SA-11(8),CA-8} |
| The Program shall protect against supply chain threats to the system, system components, or system services by employing [institutional-defined security safeguards] {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-1} |
| The Program shall request threat analysis of suppliers of critical components and manage access to and control of threat analysis products containing U.S. person information. {SV-SP-3,SV-SP-4,SV-SP-11} {SR-1} |
| The Program shall employ the [Program-defined] approaches for the purchase of the system, system components, or system services from suppliers. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-5} |
| The Program shall employ [Selection (one or more): independent third-party analysis, Program penetration testing, independent third-party penetration testing] of [Program-defined supply chain elements, processes, and actors] associated with the system, system components, or system services. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-6(1)} |
| The Program shall perform penetration testing/analysis: (1) On potential system elements before accepting the system; (2) As a realistic simulation of the active adversary’s known adversary tactics, techniques, procedures (TTPs), and tools; and (3) Throughout the lifecycle on physical and logical systems, elements, and processes. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SA-11(5)} |
| The Program shall employ [Program-defined] techniques to limit harm from potential adversaries identifying and targeting the Program supply chain. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-3(2),SC-38} |
| The Program shall use all-source intelligence analysis of suppliers and potential suppliers of the information system, system components, or system services to inform engineering, acquisition, and risk management decisions. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {RA-3(2)} |
| The Program (and Prime Contractor) shall 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. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-6} |
| The Program shall maintain a list of suppliers and potential suppliers used, and the products that they supply to include software. {SV-SP-3,SV-SP-4,SV-SP-11} {PL-8(2)} |
| The Program shall employ [Program-defined Operations Security (OPSEC) safeguards] to protect supply chain-related information for the system, system components, or system services. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-7,SC-38,CP-2(8)} |
| The Program shall develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including support tamper resistance and provide a level of protection against the introduction of malicious code or hardware. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-11} |
| The Program shall develop and implement anti-counterfeit policy and procedures, in coordination with the [CIO], that is demonstrably consistent with the anti-counterfeit policy defined by the Program office. {SV-SP-4,SV-SP-11} {SR-11} |
| See threat ID number SV-SP-3 for information on software development requirements. In general terms threat ID SV-SP-4 applies from a generic sense since software reuse or COTS usage is a supply chain concern. The Program 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)} |
| The Program shall perform static binary analysis of all firmware that is utilized on the spacecraft. {SV-SP-7,SV-SP-11} {SA-11,RA-5} |
| 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} |
| The Program shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design. {SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4} {SR-1,RA-9,SA-15(3),CP-2(8)} |
| The Program shall maintain documentation tracing the strategies, tools, and methods implemented to the Program-defined strategies, tools, and methods as a means to mitigate supply chain risk . {SV-SP-3,SV-SP-4,SV-AV-7} {SR-5} |
| The spacecraft shall use automated mechanisms to maintain and validate baseline configuration to ensure the spacecraft's is up-to-date, complete, accurate, and readily available. {SV-SP-3} {CM-2(2)} |
| The Program 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)} |
| The [Program-defined security policy] shall state that information should not be allowed to flow between partitioned applications unless explicitly permitted by the Program's security policy. {SV-AC-6} {AC-4,AC-4(6)} |
| The spacecraft shall enforce approved authorizations for controlling the flow of information within the spacecraft and between interconnected systems based on the [Program defined security policy] that information does not leave the spacecraft boundary unless it is encrypted. {SV-AC-6} {AC-4,AC-4(6)} |
| The spacecraft shall perform attestation at each stage of startup and ensure overall trusted boot regime (i.e., root of trust). {SV-IT-3} {SI-7(9)} |
| The trusted boot/RoT shall be a separate compute engine controlling the trusted computing platform cryptographic processor. {SV-IT-3} {SI-7(9)} |
| The trusted boot/RoT computing module shall be implemented on radiation tolerant burn-in (non-programmable) equipment. {SV-IT-3} {SI-7(9)} |
| The spacecraft boot 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. {SV-IT-3} {SI-7(9)} |
| The spacecraft boot firmware must enter a recovery routine upon failing to verify signed data in the trust chain, and not execute or trust that signed data. {SV-IT-3} {SI-7(9)} |
| The spacecraft shall allocate enough boot ROM memory for secure boot firmware execution. {SV-IT-3} {SI-7(9)} |
| The spacecraft shall allocate enough SRAM memory for secure boot firmware execution. {SV-IT-3} {SI-7(9)} |
| The spacecraft secure boot mechanism shall be Commercial National Security Algorithm Suite (CNSA) compliant. {SV-IT-3} {SI-7(9)} |
| The spacecraft shall support the algorithmic construct Elliptic Curve Digital Signature Algorithm (ECDSA) NIST P-384 + SHA-38{SV-IT-3} {SI-7(9)} |
| The spacecraft hardware root of trust must be an ECDSA NIST P-384 public key. {SV-IT-3} {SI-7(9)} |
| The spacecraft hardware root of trust must be loadable only once, post-purchase. {SV-IT-3} {SI-7(9)} |
| The spacecraft boot firmware must validate the boot loader, boot configuration file, and operating system image, in that order, against their respective signatures. {SV-IT-3} {SI-7(9)} |
| The Program shall define/maintain an approved operating system list for use on spacecraft. {SV-SP-7} {CM-7(5)} |
| The spacecraft's operating system, if COTS or FOSS, shall be selected from a [Program-defined] accepted list. {SV-SP-7} {CM-7(8),CM-7(5)} |
| The spacecraft shall retain the capability to update/upgrade operating systems while on-orbit. {SV-SP-7} {SA-4(5)} |
| 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. Should require contractors to be CMMC 2.0 Level 3 certified (https://www.acq.osd.mil/cmmc/about-us.html). The Program shall identify and properly classify mission sensitive design/operations information and access control shall be applied in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. {SV-CF-3,SV-AV-5} {SA-5} |
| The Program shall protect documentation and Essential Elements of Information (EEI) as required, in accordance with the risk management strategy. {SV-CF-3,SV-AV-5} {SA-5} |
| The Program shall distribute documentation to only personnel with defined roles and a need to know. {SV-CF-3,SV-AV-5} {SA-5} |
| The spacecraft, upon detection of a potential integrity violation, shall provide the capability to [audit the event and alert ground operators]. {SV-DCO-1} {SI-7(8)} |
| The spacecraft shall recover from cyber-safe mode to mission operations within [mission-appropriate timelines 5 minutes]. {SV-MA-5} {CP-2(5),IR-4} |
| The spacecraft shall uniquely identify and authenticate the ground station and other SVs before establishing a remote connection. {SV-AC-1,SV-AC-2} {IA-3,IA-4,AC-17(10)} |
| The spacecraft shall authenticate the ground station (and all commands) and other SVs before establishing remote connections using bidirectional authentication that is cryptographically based. {SV-AC-1,SV-AC-2} {IA-3(1),IA-4,IA-7,AC-17(10),AC-17(2),SC-7(11),AC-18(1)} |
| The spacecraft shall monitor [Program defined telemetry points] for malicious commanding attempts. {SV-AC-1,SV-AC-2} {SC-7,AU-3(1),AC-17(1)} |
| The Program shall define acceptable secure communication protocols available for use within the mission in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. {SV-AC-7} {SA-4(9)} |
| The spacecraft shall only use [Program-defined] communication protocols within the mission. {SV-AC-7} {SA-4(9)} |
| The spacecraft shall implement cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission unless otherwise protected by alternative physical safeguards. {SV-AC-7} {SC-8(1),SI-7(6)} |
| The spacecraft shall implement cryptographic mechanisms to protect message externals unless otherwise protected by alternative physical safeguards. {SV-AC-7} {SC-8(3)} |
| The spacecraft shall use [directional or beamforming] antennas in normal ops to reduce the likelihood that unintended receivers will be able to intercept signals. {SV-AV-1} {AC-18(5)} |
| The Program shall use all-source intelligence analysis on threats to mission critical capabilities and/or system components to inform risk management decisions. {SV-MA-4} {RA-3(2)} |
| The Program shall conduct an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the spacecraft and the information it processes, stores, or transmits. {SV-MA-4} {RA-3} |
| The Program's risk assessment shall include the full end to end communication pathway from the ground to the spacecraft. {SV-MA-4} {RA-3} |
| The Program shall document risk assessment results in [risk assessment report]. {SV-MA-4} {RA-3} |
| The Program shall review risk assessment results [At least annually if not otherwise defined in formal organizational policy]. {SV-MA-4} {RA-3} |
| The Program shall update the risk assessment [At least annually if not otherwise defined in formal institutional policy] or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the spacecraft. {SV-MA-4} {RA-3} |
| The Program shall coordinate penetration testing on [program-defined mission critical SV components (hardware and/or software)]. {SV-MA-4} {CA-8} |
| The Program shall document and design a security architecture using a defense-in-depth approach that allocates the Program defined safeguards to the indicated locations and layers: [Examples include operating system abstractions and hardware mechanisms to the separate processors in the spacecraft, internal components, and the FSW]. {SV-MA-6} {PL-8,PL-8(1)} |
| The Program shall ensure that the allocated security safeguards operate in a coordinated and mutually reinforcing manner. {SV-MA-6} {PL-8(1)} |
| The Program shall implement a security architecture and design that provides the required security functionality, allocates security controls among physical and logical components, and integrates individual security functions, mechanisms, and processes together to provide required security capabilities and a unified approach to protection. {SV-MA-6} {SA-2,SA-8} |
| The Program shall document the spacecraft's security architecture, and how it is established within and is an integrated part of the Program's mission security architecture. {SV-MA-6} {SA-17} |
| The Program shall report counterfeit information system components to [Selection (one or more): source of counterfeit component; [Program-defined external reporting organizations]; [Program-defined personnel or roles]]. {SV-SP-4} {SR-11} |
| The Program shall report counterfeit information system components to the [CIO]. {SV-SP-4} {SR-11} |
| The Program shall ensure that the contractors/developers have all EEEE, and mechanical piece parts procured from the Original Component Manufacturer (OCM) or their authorized franchised distribution network. {SV-SP-5} {SR-1,SR-5} |
| Any EEEE or mechanical piece parts that cannot be procured from the OCM or their authorized franchised distribution network shall be approved by the program’s Parts, Materials and Processes Control Board (PMPCB) as well as the government program office to prevent and detect counterfeit and fraudulent parts and materials. {SV-SP-5} {SR-1,SR-5} |
| The Program shall ensure that the contractors/developers have all ASICs designed, developed, manufactured, packaged, and tested by suppliers with a Defense Microelectronics Activity (DMEA) Trust accreditation. {SV-SP-5} {SR-1,SR-5} |
| For ASICs that are designed, developed, manufactured, packaged, or tested by a supplier that is NOT DMEA accredited Trusted, the ASIC development shall undergo a threat/vulnerability risk assessment. The assessment shall use Aerospace security guidance and requirements tailored from TOR-2019-00506 Vol. 2, and TOR-2019-02543 ASIC and FPGA Risk Assessment Process and Checklist. Based on the results of the risk assessment, the Program may require the developer to implement protective measures or other processes to ensure the integrity of the ASIC. {SV-SP-5} {SR-1,SR-5} |
| The developer shall use a DMEA certified environment to develop, code and test executable software (firmware or bit-stream) that will be programmed into a one-time programmable FPGA or be programmed into non-volatile memory (NVRAM) that the FPGA executes. {SV-SP-5} {SR-1,SR-5} |
| For FPGA pre-silicon artifacts that are developed, coded, and tested by a developer that is NOT DMEA accredited Trusted, the contractor/developer shall be subjected to a development environment and pre-silicon artifacts risk assessment by the Program. The assessment shall use Aerospace security guidance and requirements in TOR-2019-00506 Vol. 2, and TOR-2019-02543 ASIC and FPGA Risk Assessment Process and Checklist. Based on the results of the risk assessment, the Program may require the developer to implement protective measures or other processes to ensure the integrity of the FPGA pre-silicon artifacts. {SV-SP-5} {SR-1,SR-5} |
| In the event we want to levy the Government Microelectronics Assessment for Trust (GOMAT) framework outright, to perform ASIC and FPGA threat/vulnerability risk assessment, the following requirements would apply: {SV-SP-5} {SR-1,SR-5} * The GOMAT framework shall be used to perform an initial risk assessment via Aerospace TOR-2019-02543 ASIC/FPGA Risk Assessment Process and Checklist. * The GOMAT framework shall be used to provide ASIC/FPGA lifecycle security guidance and requirements via Aerospace TOR-2019-00506 Volumes & 2 “ASIC and FPGA Lifecyle Security: Threats and Countermeasures”. * The GOMAT framework shall be used to perform development environment vulnerability assessment via Aerospace TOR-2019-02543 ASIC/FPGA Risk Assessment Process and Checklist. * The GOMAT framework shall be used to perform development environment vulnerability (DEV) assessment using the tailored DEV requirements from Aerospace TOR-2019-00506 Volume 2. * The GOMAT framework shall be used to perform hardware Trojan horse (HTH) detection independent verification and validation (IV&V). * The GOMAT framework shall be used to perform incremental and final risk assessments via Aerospace TOR-2019-02543 ASIC/FPGA Risk Assessment Process and Checklist. * The GOMAT framework shall be used to recommend mitigations, based on the findings of the risk assessments, to address identified security concerns and vulnerabilities. |