Credential Hardening techniques modify system or network properties in order to protect system or network/domain credentials.
https://d3fend.mitre.org/technique/d3f:CredentialHardening/
| 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 | |
| CM0052 | Insider Threat Protection | Establish policy and procedures to prevent individuals (i.e., insiders) from masquerading as individuals with valid access to areas where commanding of the spacecraft is possible. Establish an Insider Threat Program to aid in the prevention of people with authorized access performing malicious activities. | AC-14 AC-3(11) AC-3(13) AC-3(15) AC-6 AT-2 AT-2(2) AT-2(4) AT-2(5) AT-2(6) AU-10 AU-12 AU-13 AU-6 AU-7 CA-7 CP-2 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) IA-4 IR-2(3) IR-4 IR-4(6) IR-4(7) MA-7 MP-7 PE-2 PL-8 PL-8(1) PM-12 PM-14 PS-3 PS-4 PS-5 PS-8 RA-10 SA-3 SA-8 SC-38 SC-7 SI-4 SR-11(2) | D3-OAM D3-AM D3-OM D3-CH D3-SPP D3-MFA D3-UAP D3-UBA | A.8.4 A.5.15 A.8.2 A.8.18 7.3 A.6.3 A.8.7 A.5.25 A.6.8 A.8.15 A.8.15 A.8.12 A.8.16 9.1 9.3.2 9.3.3 A.5.36 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.16 A.5.25 A.5.26 A.5.27 A.5.10 A.7.10 A.7.2 A.5.8 A.6.1 A.5.11 A.6.5 A.5.11 A.6.5 7.3 A.6.4 A.5.7 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.16 | |
| CM0002 | COMSEC | A component of cybersecurity to deny unauthorized persons information derived from telecommunications and to ensure the authenticity of such telecommunications. COMSEC includes cryptographic security, transmission security, emissions security, and physical security of COMSEC material. It is imperative to utilize secure communication protocols with strong cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission. Systems should also maintain the confidentiality and integrity of information during preparation for transmission and during reception. Spacecraft should not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). The cryptographic mechanisms should identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters. | AC-17 AC-17(1) AC-17(10) AC-17(10) AC-17(2) AC-18 AC-18(1) AC-2(11) AC-3(10) CA-3 IA-4(9) IA-5 IA-5(7) IA-7 PL-8 PL-8(1) SA-8(18) SA-8(19) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SC-8(1) SC-8(3) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8) | D3-ET D3-MH D3-MAN D3-MENCR D3-NTF D3-ITF D3-OTF D3-CH D3-DTP D3-NTA D3-CAA D3-DNSTA D3-IPCTA D3-NTCD D3-RTSD D3-PHDURA D3-PMAD D3-CSPP D3-MA D3-SMRA D3-SRA | A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.16 A.5.17 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.12 A.5.33 A.8.20 A.8.24 A.8.24 A.8.26 A.5.31 A.5.33 A.8.11 | |
| CM0030 | Crypto Key Management | Leverage best practices for crypto key management as defined by organization like NIST or the National Security Agency. Leverage only approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. Encryption key handling should be performed outside of the onboard software and protected using cryptography. Encryption keys should be restricted so that they cannot be read via any telecommands. | CM-3(6) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-9(6) SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-28(3) SC-8(1) | D3-CH D3-CP | A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24 | |
| CM0031 | Authentication | Authenticate all communication sessions (crosslink and ground stations) for all commands before establishing remote connections using bidirectional authentication that is cryptographically based. Adding authentication on the spacecraft bus and communications on-board the spacecraft is also recommended. | AC-14 AC-17 AC-17(10) AC-17(10) AC-17(2) AC-18 AC-18(1) IA-2 IA-3(1) IA-4 IA-4(9) IA-7 IA-9 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(1) SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) SI-7(6) | D3-MH D3-MAN D3-CH D3-BAN D3-MFA D3-TAAN D3-CBAN | A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.16 A.5.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 | |
| CM0004 | Development Environment Security | In order to secure the development environment, the first step is understanding all the devices and people who interact with it. Maintain an accurate inventory of all people and assets that touch the development environment. Ensure strong multi-factor authentication is used across the development environment, especially for code repositories, as threat actors may attempt to sneak malicious code into software that's being built without being detected. Use zero-trust access controls to the code repositories where possible. For example, ensure the main branches in repositories are protected from injecting malicious code. A secure development environment requires change management, privilege management, auditing and in-depth monitoring across the environment. | AC-17 AC-18 AC-20(5) AC-3(11) AC-3(13) AC-3(15) CA-8 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 | |
| CM0021 | Software Digital Signature | Prevent the installation of Flight Software without verification that the component has been digitally signed using a certificate that is recognized and approved by the mission. | AC-14 CM-11 CM-11(3) CM-14 CM-14 CM-5(6) IA-2 SA-10(1) SA-11 SA-4(5) SA-8(29) SA-8(31) SA-9 SI-7 SI-7 SI-7(1) SI-7(12) SI-7(15) SI-7(6) | D3-CH D3-CBAN D3-FV D3-DLIC D3-EAL D3-SBV | A.8.19 A.5.16 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 | |
| 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-0005.04 | Active Scanning (RF/Optical) | Threat actors may interfere with the link by actively transmitting packets to activate the transmitter and induce a reply. The scan can be similar to a brute force attack, aiming to guess the used frequencies and protocols to obtain a reply. | |
| 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.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-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-0003 | Crosslink via Compromised Neighbor | Threat actors may compromise a victim spacecraft via the crosslink communications of a neighboring spacecraft that has been compromised. spacecraft in close proximity are able to send commands back and forth. Threat actors may be able to leverage this access to compromise other spacecraft once they have access to another that is nearby. | |
| 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.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-0005 | Rendezvous & Proximity Operations | Threat actors may perform a space rendezvous which is a set of orbital maneuvers during which a spacecraft arrives at the same orbit and approach to a very close distance (e.g. within visual contact or close proximity) to a target spacecraft. | |
| IA-0005.01 | Compromise Emanations | Threat actors in close proximity may intercept and analyze electromagnetic radiation emanating from crypto equipment and/or the target spacecraft(i.e., main bus) to determine whether the emanations are information bearing. The data could be used to establish initial access. | |
| IA-0005.02 | Docked Vehicle / OSAM | Threat actors may leverage docking vehicles to laterally move into a target spacecraft. If information is known on docking plans, a threat actor may target vehicles on the ground or in space to deploy malware to laterally move or execute malware on the target spacecraft via the docking interface. | |
| IA-0005.03 | Proximity Grappling | Threat actors may posses the capability to grapple target spacecraft once it has established the appropriate space rendezvous. If from a proximity / rendezvous perspective a threat actor has the ability to connect via docking interface or expose testing (i.e., JTAG port) once it has grappled the target spacecraft, they could perform various attacks depending on the access enabled via the physical connection. | |
| 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-0007.02 | Malicious Commanding via Valid GS | Threat actors may compromise target owned ground systems components (e.g., front end processors, command and control software, etc.) that can be used for future campaigns or to perpetuate other techniques. These ground systems components 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. | |
| 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.01 | Rogue Ground Station | Threat actors may gain access to a victim spacecraft through the use of a rogue ground system. With this technique, the threat actor does not need access to a legitimate ground station or communication site. | |
| IA-0008.02 | Rogue Spacecraft | Threat actors may gain access to a target spacecraft using their own spacecraft that has the capability to maneuver within close proximity to a target spacecraft to carry out a variety of TTPs (i.e., eavesdropping, side-channel, etc.). Since many of the commercial and military assets in space are tracked, and that information is publicly available, attackers can identify the location of space assets to infer the best positioning for intersecting orbits. Proximity operations support avoidance of the larger attenuation that would otherwise affect the signal when propagating long distances, or environmental circumstances that may present interference. | |
| 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-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-0001 | Replay | Replay attacks involve threat actors recording previously recorded data streams and then resending them at a later time. This attack can be used to fingerprint systems, gain elevated privileges, or even cause a denial of service. | |
| EX-0001.01 | Command Packets | Threat actors may interact with the victim spacecraft by replaying captured commands to the spacecraft. While not necessarily malicious in nature, replayed commands can be used to overload the target spacecraft and cause it's onboard systems to crash, perform a DoS attack, or monitor various responses by the spacecraft. If critical commands are captured and replayed, thruster fires, then the impact could impact the spacecraft's attitude control/orbit. | |
| EX-0003 | Modify Authentication Process | Threat actors may modify the internal authentication process of the victim spacecraft to facilitate initial access, recurring execution, or prevent authorized entities from accessing the spacecraft. This can be done through the modification of the software binaries or memory manipulation techniques. | |
| EX-0004 | Compromise Boot Memory | Threat actors may manipulate boot memory in order to execute malicious code, bypass internal processes, or DoS the system. This technique can be used to perform other tactics such as Defense Evasion. | |
| EX-0006 | Disable/Bypass Encryption | Threat actors may perform specific techniques in order to bypass or disable the encryption mechanism onboard the victim spacecraft. By bypassing or disabling this particular mechanism, further tactics can be performed, such as Exfiltration, that may have not been possible with the internal encryption process in place. | |
| 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-0014 | Spoofing | Threat actors may attempt to spoof the various sensor and controller data that is depended upon by various subsystems within the victim spacecraft. Subsystems rely on this data to perform automated tasks, process gather data, and return important information to the ground controllers. By spoofing this information, threat actors could trigger automated tasks to fire when they are not needed to, potentially causing the spacecraft to behave erratically. Further, the data could be processed erroneously, causing ground controllers to receive incorrect telemetry or scientific data, threatening the spacecraft's reliability and integrity. | |
| EX-0014.01 | Time Spoof | Threat actors may attempt to target the internal timers onboard the victim spacecraft and spoof their data. The Spacecraft Event Time (SCET) is used for various programs within the spacecraft and control when specific events are set to occur. Ground controllers use these timed events to perform automated processes as the spacecraft is in orbit in order for it to fulfill it's purpose. Threat actors that target this particular system and attempt to spoof it's data could cause these processes to trigger early or late. | |
| EX-0014.02 | Bus Traffic | Threat actors may attempt to target the main or secondary bus onboard the victim spacecraft and spoof their data. The spacecraft bus often directly processes and sends messages from the ground controllers to the various subsystems within the spacecraft and between the subsystems themselves. If a threat actor would target this system and spoof it internally, the subsystems would take the spoofed information as legitimate and process it as normal. This could lead to undesired effects taking place that could damage the spacecraft's subsystems, hosted payload, and critical data. | |
| EX-0014.03 | Sensor Data | Threat actors may target sensor data on the space vehicle to achieve their attack objectives. Sensor data is typically inherently trusted by the space vehicle therefore an attractive target for a threat actor. Spoofing the sensor data could affect the calculations and disrupt portions of a control loop as well as create uncertainty within the mission thereby creating temporary denial of service conditions for the mission. Affecting the integrity of the sensor data can have varying impacts on the space vehicle depending on decisions being made by the space vehicle using the sensor data. For example, spoofing data related to attitude control could adversely impact the space vehicles ability to maintain orbit. | |
| EX-0014.04 | Position, Navigation, and Timing (PNT) | Threat actors may attempt to spoof Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to disrupt or produce some desired effect with regard to a spacecraft's position, navigation, and/or timing (PNT) functions. | |
| PER-0001 | Memory Compromise | Threat actors may manipulate memory (boot, RAM, etc.) in order for their malicious code and/or commands to remain on the victim spacecraft. The spacecraft may have mechanisms that allow for the automatic running of programs on system reboot, entering or returning to/from safe mode, or during specific events. Threat actors may target these specific memory locations in order to store their malicious code or file, ensuring that the attack remains on the system even after a reset. | |
| 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.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-0004 | Replace Cryptographic Keys | Threat actors may attempt to fully replace the cryptographic keys on the space vehicle which could lockout the mission operators and enable the threat actor's communication channel. Once the encryption key is changed on the space vehicle, the spacecraft is rendered inoperable from the operators perspective as they have lost commanding access. Threat actors may exploit weaknesses in the key management strategy. For example, the threat actor may exploit the over-the-air rekeying procedures to inject their own cryptographic keys. | |
| 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-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.01 | Inhibit Ground System Functionality | Threat actors may utilize ground-system presence to inhibit the ground system software's ability to process (or display) telemetry, 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-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-0004 | Masquerading | Threat actors may gain access to a victim spacecraft by masquerading as an authorized entity. This can be done several ways, including through the manipulation of command headers, spoofing locations, or even leveraging Insider's access (i.e., Insider Threat) | |
| 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-0007 | 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. | |
| DE-0008 | 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. | |
| 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-0003 | Constellation Hopping via Crosslink | Threat actors may attempt to command another neighboring spacecraft via crosslink. spacecraft in close proximity are often able to send commands back and forth. Threat actors may be able to leverage this access to compromise another spacecraft. | |
| LM-0004 | Visiting Vehicle Interface(s) | Threat actors may move from one spacecraft to another through visiting vehicle interfaces. When a vehicle docks with a spacecraft, many programs are automatically triggered in order to ensure docking mechanisms are locked. This entails several data points and commands being sent to and from the spacecraft and the visiting vehicle. If a threat actor were to compromise a visiting vehicle, they could target these specific programs in order to send malicious commands to the victim spacecraft once docked. | |
| 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-0001 | Replay | Threat actors may exfiltrate data by replaying commands and capturing the telemetry or payload data as it is sent down. One scenario would be the threat actor replays commands to downlink payload data once the spacecraft is within certain location so the data can be intercepted on the downlink by threat actor ground terminals. | |
| EXF-0002 | Side-Channel Attack | Threat actors may use a side-channel attack attempts to gather information by measuring or exploiting indirect effects of the spacecraft. Information within the spacecraft can be extracted through these side-channels in which sensor data is analyzed in non-trivial ways to recover subtle, hidden or unexpected information. A series of measurements of a side-channel constitute an identifiable signature which can then be matched against a signature database to identify target information, without having to explicitly decode the side-channel. | |
| EXF-0002.03 | Traffic Analysis Attacks | In a terrestrial environment, threat actors use traffic analysis attacks to analyze traffic flow to gather topological information. This traffic flow can divulge information about critical nodes, such as the aggregator node in a sensor network. In the space environment, specifically with relays and constellations, traffic analysis can be used to understand the energy capacity of spacecraft node and the fact that the transceiver component of a spacecraft node consumes the most power. The spacecraft nodes in a constellation network limit the use of the transceiver to transmit or receive information either at a regulated time interval or only when an event has been detected. This generally results in an architecture comprising some aggregator spacecraft nodes within a constellation network. These spacecraft aggregator nodes are the sensor nodes whose primary purpose is to relay transmissions from nodes toward the ground station in an efficient manner, instead of monitoring events like a normal node. The added functionality of acting as a hub for information gathering and preprocessing before relaying makes aggregator nodes an attractive target to side channel attacks. A possible side channel attack could be as simple as monitoring the occurrences and duration of computing activities at an aggregator node. If a node is frequently in active states (instead of idle states), there is high probability that the node is an aggregator node and also there is a high probability that the communication with the node is valid. Such leakage of information is highly undesirable because the leaked information could be strategically used by threat actors in the accumulation phase of an attack. | |
| EXF-0002.04 | Timing Attacks | Threat actors can leverage timing attacks to exfiltrate information due to variances in the execution timing for different sub-systems in the spacecraft (i.e., cryptosystem). In spacecraft, due to the utilization of processors with lower processing powers (i.e. slow), this becomes all the more important because slower processors will enhance even small difference in computation time. Every operation in a spacecraft takes time to execute, and the time can differ based on the input; with precise measurements of the time for each operation, a threat actor can work backwards to the input. Finding secrets through timing information may be significantly easier than using cryptanalysis of known plaintext, ciphertext pairs. Sometimes timing information is combined with cryptanalysis to increase the rate of information leakage. | |
| 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-0004 | Out-of-Band Communications Link | Threat actors may attempt to exfiltrate data via the out-of-band communication channels. While performing eavesdropping on the primary/second uplinks and downlinks is a method for exfiltration, some space vehicles leverage out-of-band communication links to perform actions on the space vehicle (i.e., re-keying). These out-of-band links would occur on completely different channels/frequencies and often operate on separate hardware on the space vehicle. Typically these out-of-band links have limited built-for-purpose functionality and likely do not present an initial access vector but they do provide ample exfiltration opportunity. | |
| EXF-0005 | Proximity Operations | Threat actors may leverage the lack of emission security or tempest controls to exfiltrate information using a visiting spacecraft. This is similar to side-channel attacks but leveraging a visiting spacecraft to measure the signals for decoding purposes. | |
| 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. | |
| EXF-0010 | Payload Communication Channel | Threat actors can deploy malicious software on the payload(s) which can send data through the payload channel. Payloads often have their own communication channels outside of the main TT&C pathway which presents an opportunity for exfiltration of payload data or other spacecraft data depending on the interface and data exchange. | |
| 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 Program shall define policy and procedures to ensure that the developed or delivered systems do not embed unencrypted static authenticators in applications, access scripts, configuration files, nor store unencrypted static authenticators on function keys. {SV-AC-1,SV-AC-3} {IA-5(7)} |
| The spacecraft shall protect authenticator content from unauthorized disclosure and modification. {SV-AC-1,SV-AC-3} {IA-5} |
| The spacecraft's encryption keys shall be restricted so that they cannot be read via any telecommands. {SV-AC-1,SV-AC-3} {SC-12} |
| The spacecraft's encryption keys shall be restricted so that the onboard software is not able to access the information for key readout. {SV-AC-1,SV-AC-3} {SC-12} |
| The spacecraft's encryption key handling shall be handled outside of the onboard software and protected using cryptography. {SV-AC-1,SV-AC-3} {SC-12,SC-28(1)} |
| The spacecraft shall produce, control, and distribute symmetric cryptographic keys using NSA Certified or Approved key management technology and processes. {SV-AC-1,SV-AC-3} {SC-12,SC-12(1),SC-12(2)} |
| The Program shall use NIST Approved for symmetric key management for Unclassified systems; NSA Approved or stronger symmetric key management technology for Classified systems. {SV-AC-1,SV-AC-3} {SC-12,SC-12(1),SC-12(2)} |
| The spacecraft shall produce, control, and distribute asymmetric cryptographic keys using [Program-defined] asymmetric key management processes. {SV-AC-1,SV-AC-3} {SC-12,SC-12(1),SC-12(3)} |
| The spacecraft shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards: [NSA- certified or approved cryptography for protection of classified information, FIPS-validated cryptography for the provision of hashing]. {SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2,SV-AC-3} {IA-7,SC-13} |
| The Program shall use NSA approved key management technology and processes. NSA-approved technology used for asymmetric key management by the Program shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. {SV-AC-1,SV-AC-3} {SC-12,SC-12(1),SC-12(3)} |
| The spacecraft shall not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). {SV-AC-1,SV-CF-1,SV-CF-2} {AC-3(10)} |
| The spacecraft shall fail securely to a secondary device in the event of an operational failure of a primary boundary protection device (i.e., crypto solution). {SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2} {SC-7(18)} |
| 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 [software subsystem] shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission. {SV-MA-3,SV-AV-7} {SI-10} |
| The [software subsystem] shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied. {SV-MA-3,SV-AV-7} {SI-10} |
| The [software subsystem] shall discriminate between valid and invalid input into the software and rejects invalid input. {SV-MA-3,SV-AV-7} {SI-10,SI-10(3)} |
| The [software subsystem] shall properly handle spurious input and missing data. {SV-MA-3,SV-AV-7} {SI-10,SI-10(3)} |
| The [software subsystem] shall provide at least one independent command for each operator-initiated action used to shut down a function leading to or reducing the control of a hazard. {SV-MA-3,SV-AV-7} {SI-10(5)} |
| The spacecraft’s mission/cyber critical commands shall require to be "complex" and/or diverse from other commands so that a single bit flip could not transform a benign command into a hazardous command. {SV-MA-3,SV-AV-7} {SI-10(5)} |
| The [software subsystem] shall perform prerequisite checks for the execution of hazardous commands. {SV-MA-3,SV-AV-7} {SI-10} |
| The [software subsystem] shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit or perform a hazardous action. {SV-MA-3,SV-AV-7} {SI-10(3)} |
| 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} |
| 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 employ the principle of least privilege, allowing only authorized accesses processes which are necessary to accomplish assigned tasks in accordance with system functions. {SV-AC-6} {AC-6} |
| The spacecraft shall maintain a separate execution domain for each executing process. {SV-AC-6} {SC-7(21),SC-39} |
| The spacecraft shall implement boundary protections to separate bus, communications, and payload components supporting their respective functions. {SV-AC-6} {SC-7(21)} |
| The Program shall perform analysis of critical (backdoor) commands that could adversely affect mission success if used maliciously. {SV-AC-8} {SI-10,SI-10(3)} |
| The spacecraft shall only use or include [Program-defined] critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted. {SV-AC-8} {SI-10,SI-10(3)} |
| The Program shall ensure that all viable commands are known to the mission and SV "owner. {SV-AC-8} {SI-10,SI-10(3)} |
| 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 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 shall provide or support the capability for recovery and reconstitution to a known state after a disruption, compromise, or failure. {SV-AV-5,SV-AV-6,SV-AV-7} {CP-10,CP-10(4),IR-4} |
| The spacecraft shall provide the capability to enter the spacecraft into a configuration-controlled and integrity-protected state representing a known, operational cyber-safe state (e.g., cyber-safe mode). {SV-AV-5,SV-AV-6,SV-AV-7} {CP-12,SI-17,IR-4(3)} |
| The spacecraft shall enter a cyber-safe mode when conditions that threaten the spacecraft are detected with restrictions as defined based on the cyber-safe mode. {SV-AV-5,SV-AV-6,SV-AV-7} {CP-12,SI-17,IR-4(3)} |
| The spacecraft shall monitor and collect all onboard cyber-relevant data (from multiple system components), including identification of potential attacks and sufficient information about the attack for subsequent analysis. {SV-DCO-1} {SI-4,SI-4(2),AU-2} |
| The spacecraft shall be designed and configured so that [Program-defined encrypted communications traffic and data] is visible to on-board monitoring tools. {SV-DCO-1} {SI-4(10)} |
| The spacecraft shall provide automated onboard mechanisms that integrate audit review, analysis, and reporting processes to support mission processes for investigation and response to suspicious activities to determine the attack class in the event of a cyberattack. {SV-DCO-1} {SC-5(3),AU-6(1)} |
| The spacecraft shall integrate cyber related detection and responses with existing fault management capabilities to ensure tight integration between traditional fault management and cyber intrusion detection and prevention. {SV-DCO-1} {AU-6(4),SI-4(16)} |
| The spacecraft shall be able to locate the onboard origin of a cyberattack and alert ground operators within [TBD minutes]. {SV-DCO-1} {SI-4(16)} |
| The spacecraft shall attribute cyberattacks and identify unauthorized use of the spacecraft by downlinking onboard cyber information to the mission ground station within [mission-appropriate timelines minutes]. {SV-DCO-1} {AU-4(1),SI-4(5)} |
| The spacecraft shall detect and deny unauthorized outgoing communications posing a threat to the spacecraft. {SV-DCO-1} {SI-4(4),SC-7(9),SI-4(11)} |
| The spacecraft shall select and execute safe countermeasures against cyberattacks prior to entering cyber-safe mode. {SV-DCO-1} {SI-17,IR-4} |
| 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 Program shall integrate terrestrial system audit log analysis as part of the standard anomaly resolution process to correlate any anomalous behavior in the terrestrial systems that correspond to anomalous behavior in the spacecraft. {SV-DCO-1} {AU-6(1),IR-5(1)} |
| 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 implement relay and replay-resistant authentication mechanisms for establishing a remote connection. {SV-AC-1,SV-AC-2} {IA-2(8)} |
| 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 provide the capability to restrict command lock based on geographic location of ground stations. {SV-AC-1} {AC-2(11)} |
| 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 terminate the connection associated with a communications session at the end of the session or after [TBD minutes] of inactivity. {SV-AC-1} {SC-10} |
| The spacecraft shall restrict the use of information inputs to SVs and designated ground stations as defined in the applicable ICDs. {SV-AC-1,SV-AC-2} {SC-23,SI-10,SI-10(5)} |
| The spacecraft shall have on-board intrusion detection/prevention system that monitors the mission critical components or systems. {SV-AC-1,SV-AC-2,SV-MA-4} {SC-7} |
| 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 spacecraft shall encrypt all telemetry on downlink regardless of operating mode to protect current state of spacecraft. {SV-CF-4} {SC-8,SC-13} |
| 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 have Insider Threat Program to aid in the prevention of people with authorized access to perform malicious activities. {SV-AC-4} {PM-12,AT-2(2),IR-4(7)} |
| The Program, upon termination of individual employment, disables information system access within [TBD minutes] of termination. {SV-AC-4} {PS-4} |
| 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 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. |