PL-8(1) - Security and Privacy Architectures | Defense in Depth

Design the security and privacy architectures for the system using a defense-in-depth approach that: (a) Allocates [Assignment: organization-defined controls] to [Assignment: organization-defined locations and architectural layers]; and (b) Ensures that the allocated controls operate in a coordinated and mutually reinforcing manner.


Informational References

ISO 27001

ID: PL-8(1)
Enhancement of : PL-8

Countermeasures Covered by Control

ID Name Description D3FEND
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. D3-AI D3-AVE D3-NVA D3-CH D3-CBAN D3-CTS D3-PA D3-FAPA D3-SAOR
CM0020 Threat modeling Use threat modeling, attack surface analysis, and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. Reduce attack surface where possible based on threats. D3-AI D3-AVE D3-SWI D3-HCI D3-NM D3-LLM D3-ALLM D3-PLLM D3-PLM D3-APLM D3-PPLM D3-SYSM D3-DEM D3-SVCDM D3-SYSDM
CM0022 Criticality Analysis Conduct a criticality analysis to identify mission critical functions, critical components, and data flows and reduce the vulnerability of such functions and components through secure system design. Focus supply chain protection on the most critical components/functions. Leverage other countermeasures like segmentation and least privilege to protect the critical components. D3-AVE D3-OSM D3-IDA D3-SJA D3-AI D3-DI D3-SWI D3-NNI D3-HCI D3-NM D3-PLM D3-AM D3-SYSM D3-SVCDM D3-SYSDM D3-SYSVA D3-OAM D3-ORA
CM0024 Anti-counterfeit Hardware Develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including tamper resistance and protection against the introduction of malicious code or hardware.  D3-AI D3-SWI D3-HCI D3-FEMC D3-DLIC D3-FV
CM0025 Supplier Review 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. D3-OAM D3-ODM
CM0026 Original Component Manufacturer Components/Software that cannot be procured from the original component manufacturer or their authorized franchised distribution network should be approved by the supply chain board or equivalent to prevent and detect counterfeit and fraudulent parts, materials, and software. D3-OAM D3-ODM D3-AM D3-FV D3-SFV
CM0027 ASIC/FPGA Manufacturing Application-Specific Integrated Circuit (ASIC) / Field Programmable Gate Arrays should be developed by accredited trusted foundries to limit potential hardware-based trojan injections. D3-OAM D3-ODM D3-AM D3-FV D3-SFV
CM0028 Tamper Protection Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment. D3-PH D3-AH D3-RFS D3-FV
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. D3-OAM D3-AM D3-OM D3-CH D3-SPP D3-MFA D3-UAP D3-UBA
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. 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
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. D3-CH D3-CP
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. D3-MH D3-MAN D3-CH D3-BAN D3-MFA D3-TAAN D3-CBAN
CM0050 On-board Message Encryption In addition to authentication on-board the spacecraft bus, encryption is also recommended to protect the confidentiality of the data traversing the bus. D3-MH D3-MENCR D3-ET
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. 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
CM0017 Coding Standard Define acceptable coding standards to be used by the software developer. The mission should have automated means to evaluate adherence to coding standards. The coding standard should include the acceptable software development language types as well. The language should consider the security requirements, scalability of the application, the complexity of the application, development budget, development time limit, application security, available resources, etc. The coding standard and language choice must ensure proper security constructs are in place. D3-AI D3-AVE D3-SWI D3-DCE D3-EHPV D3-ORA D3-FEV D3-FR D3-ER D3-PE D3-PT D3-PS
CM0039 Least Privilege Employ the principle of least privilege, allowing only authorized processes which are necessary to accomplish assigned tasks in accordance with system functions. Ideally maintain a separate execution domain for each executing process. D3-MAC D3-EI D3-HBPI D3-KBPI D3-PSEP D3-MBT D3-PCSV D3-LFP D3-UBA
CM0046 Long Duration Testing Perform testing using hardware or simulation/emulation where the test executes over a long period of time (30+ days). This testing will attempt to flesh out race conditions or time-based attacks. D3-SJA D3-PM D3-OSM D3-SDM D3-UBA D3-SYSVA
CM0047 Operating System Security Ensure spacecraft's operating system is scrutinized/whitelisted and has received adequate software assurance previously. The operating system should be analyzed for its attack surface and non-utilized features should be stripped from the operating system. Many real-time operating systems contain features that are not necessary for spacecraft operations and only increase the attack surface. D3-AVE D3-OSM D3-EHB D3-SDM D3-SFA D3-SBV D3-PA D3-SCA D3-FCA
CM0055 Secure Command Mode(s) Provide additional protection modes for commanding the spacecraft. These can be where the spacecraft will restrict command lock based on geographic location of ground stations, special operational modes within the flight software, or even temporal controls where the spacecraft will only accept commands during certain times. D3-AH D3-ACH D3-MFA D3-OTP
CM0069 Process White Listing Simple process ID whitelisting on the firmware level could impede attackers from instigating unnecessary processes which could impact the spacecraft D3-MAC D3-EAL D3-EDL
CM0005 Ground-based Countermeasures This countermeasure is focused on the protection of terrestrial assets like ground networks and development environments/contractor networks, etc. Traditional detection technologies and capabilities would be applicable here. Utilizing resources from NIST CSF to properly secure these environments using identify, protect, detect, recover, and respond is likely warranted. Additionally, NISTIR 8401 may provide resources as well since it was developed to focus on ground-based security for space systems (https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8401.ipd.pdf). Furthermore, the MITRE ATT&CK framework provides IT focused TTPs and their mitigations https://attack.mitre.org/mitigations/enterprise/. Several recommended NIST 800-53 Rev5 controls are provided for reference when designing ground systems/networks. Nearly all D3FEND Techniques apply to Ground
CM0034 Monitor Critical Telemetry Points Monitor defined telemetry points for malicious activities (i.e., jamming attempts, commanding attempts (e.g., command modes, counters, etc.)). This would include valid/processed commands as well as commands that were rejected. Telemetry monitoring should synchronize with ground-based Defensive Cyber Operations (i.e., SIEM/auditing) to create a full space system situation awareness from a cybersecurity perspective. D3-NTA D3-PM D3-PMAD D3-RTSD
CM0035 Protect Authenticators Protect authenticator content from unauthorized disclosure and modification. D3-CE D3-ANCI D3-CA D3-ACA D3-PCA D3-CRO D3-CTS D3-SPP
CM0070 Alternate Communications Paths Establish alternate communications paths to reduce the risk of all communications paths being affected by the same incident. D3-NM D3-NTPM
CM0006 Cloaking Safe-mode Attempt to cloak when in safe-mode and ensure that when the system enters safe-mode it does not disable critical security features. Ensure basic protections like encryption are still being used on the uplink/downlink to prevent eavesdropping. D3-PH
CM0032 On-board Intrusion Detection & Prevention Utilize on-board intrusion detection/prevention system that monitors the mission critical components or systems and audit/logs actions. The IDS/IPS should have the capability to respond to threats (initial access, execution, persistence, evasion, exfiltration, etc.) and it should address signature-based attacks along with dynamic never-before seen attacks using machine learning/adaptive technologies. The IDS/IPS must integrate with traditional fault management to provide a wholistic approach to faults on-board the spacecraft. Spacecraft should select and execute safe countermeasures against cyber-attacks.  These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker — with or without ground support. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system. D3-FA D3-DA D3-FCR D3-FH D3-ID D3-IRA D3-HD D3-IAA D3-FHRA D3-NTA D3-PMAD D3-RTSD D3-ANAA D3-CA D3-CSPP D3-ISVA D3-PM D3-SDM D3-SFA D3-SFV D3-SICA D3-USICA D3-FBA D3-FEMC D3-FV D3-OSM D3-PFV D3-EHB D3-IDA D3-MBT D3-SBV D3-PA D3-PSMD D3-PSA D3-SEA D3-SSC D3-SCA D3-FAPA D3-IBCA D3-PCSV D3-FCA D3-PLA D3-UBA D3-RAPA D3-SDA D3-UDTA D3-UGLPA D3-ANET D3-AZET D3-JFAPA D3-LAM D3-NI D3-RRID D3-NTF D3-ITF D3-OTF D3-EI D3-EAL D3-EDL D3-HBPI D3-IOPR D3-KBPI D3-MAC D3-SCF
CM0042 Robust Fault Management Ensure fault management system cannot be used against the spacecraft. Examples include: safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of telemetry to cause action from ground, or some sort of proximity operation to cause spacecraft to go into safe mode. Understanding the safing procedures and ensuring they do not put the spacecraft in a more vulnerable state is key to building a resilient spacecraft. D3-AH D3-EHPV D3-PSEP D3-PH D3-SCP
CM0044 Cyber-safe Mode 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). Spacecraft should enter a cyber-safe mode when conditions that threaten the platform are detected.   Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode, authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and software functions to pre-attack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on equipment still available after a cyber-attack. The goal is for the spacecraft to resume full mission operations. If not possible, a reduced level of mission capability should be achieved. Cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.                                                  D3-PH D3-EI D3-NI D3-BA
CM0051 Fault Injection Redundancy To counter fault analysis attacks, it is recommended to use redundancy to catch injected faults. For certain critical functions that need protected against fault-based side channel attacks, it is recommended to deploy multiple implementations of the same function. Given an input, the spacecraft can process it using the various implementations and compare the outputs. A selection module could be incorporated to decide the valid output. Although sensor nodes have limited resources, critical regions usually comprise the crypto functions, which must be secured. D3-AH D3-SYSVA D3-ORA
CM0014 Secure boot Software/Firmware must verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order. The trusted boot/RoT computing module should be implemented on radiation tolerant burn-in (non-programmable) equipment.  D3-PH D3-BA D3-DLIC D3-TBI
CM0037 Disable Physical Ports Provide the capability for data connection ports or input/output devices (e.g., JTAG) to be disabled or removed prior to spacecraft operations. D3-EI D3-IOPR
CM0038 Segmentation Identify the key system components or capabilities that require isolation through physical or logical means. Information should not be allowed to flow between partitioned applications unless explicitly permitted by security policy. Isolate mission critical functionality from non-mission critical functionality by means of an isolation boundary (implemented via partitions) that controls access to and protects the integrity of, the hardware, software, and firmware that provides that functionality. Enforce approved authorizations for controlling the flow of information within the spacecraft and between interconnected systems based on the defined security policy that information does not leave the spacecraft boundary unless it is encrypted. Implement boundary protections to separate bus, communications, and payload components supporting their respective functions. D3-NI D3-BDI D3-NTF D3-ITF D3-OTF D3-EI D3-HBPI D3-KBPI D3-MAC D3-RRID D3-EAL D3-EDL D3-IOPR D3-SCF
CM0048 Resilient Position, Navigation, and Timing If available, use an authentication mechanism that allows GNSS receivers to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. Have fault-tolerant authoritative time sourcing for the spacecraft's clock. The spacecraft should synchronize the internal system clocks for each processor to the authoritative time source when the time difference is greater than the FSW-defined interval. If Spacewire is utilized, then the spacecraft should adhere to mission-defined time synchronization standard/protocol to synchronize time across a Spacewire network with an accuracy around 1 microsecond. D3-MH D3-MAN
CM0057 Tamper Resistant Body Using a tamper resistant body can increase the one-time cost of the sensor node but will allow the node to conserve the power usage when compared with other countermeasures. D3-PH D3-RFS
CM0029 TRANSEC Utilize TRANSEC in order to prevent interception, disruption of reception, communications deception, and/or derivation of intelligence by analysis of transmission characteristics such as signal parameters or message externals. For example, jam-resistant waveforms can be utilized to improve the resistance of radio frequency signals to jamming and spoofing. Note: TRANSEC is that field of COMSEC which deals with the security of communication transmissions, rather than that of the information being communicated. D3-MH D3-MAN D3-MENCR D3-NTA D3-DNSTA D3-ISVA D3-NTCD D3-RTA D3-PMAD D3-FC D3-CSPP D3-ANAA D3-RPA D3-IPCTA D3-NTCD D3-NTPM D3-TAAN

Space Threats Tagged by Control

ID Description
SV-MA-7 Exploit ground system and use to maliciously to interact with the spacecraft
SV-MA-6 Not planning for security on SV or designing in security from the beginning

Sample Requirements

Requirement Rationale/Additional Guidance/Notes
The [organization] shall protect the security plan from unauthorized disclosure and modification.{SV-MA-6}{AC-3,PL-2,PL-7}
The [organization] shall plan and coordinate security-related activities affecting the spacecraft with groups associated with systems from which the spacecraft is inheriting satisfaction of controls before conducting such activities in order to reduce the impact on other organizational entities.{SV-MA-6}{PL-2}
The [organization] shall develop a security plan for the spacecraft.{SV-MA-6}{PL-2,PL-7,PM-1,SA-8(29),SA-8(30)}
The [organization] 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 [organization] should have requirements/controls for all ground/terrestrial systems covering: Data Protection, Ground Software, Endpoints, Networks, Computer Network Defense / Incident Response, Perimeter Security, Physical Controls, and Prevention Program (SSP, PPP, and Training).See NIST 800-53 and CNSSI 1253 for guidance on ground security {SV-MA-7}
The [organization] shall ensure that the allocated security safeguards operate in a coordinated and mutually reinforcing manner.{SV-MA-6}{CA-7(5),PL-7,PL-8(1),SA-8(19)}
The [organization] shall document and design a security architecture using a defense-in-depth approach that allocates the [organization]s defined safeguards to the indicated locations and layers: [Examples include: operating system abstractions and hardware mechanisms to the separate processors in the platform, internal components, and the FSW].{SV-MA-6}{CA-9,PL-7,PL-8,PL-8(1),SA-8(3),SA-8(4),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30)}
The [organization] 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}{PL-7,SA-2,SA-8,SA-8(1),SA-8(2),SA-8(3),SA-8(4),SA-8(5),SA-8(6),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30),SC-32,SC-32(1)}

Related SPARTA Techniques and Sub-Techniques

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.03 Known Vulnerabilities Threat actors may gather information about vulnerabilities that can be used for future campaigns or to perpetuate other techniques. A vulnerability is a weakness in the victim spacecraft's hardware, subsystems, bus, or software that can, potentially, be exploited by a threat actor to cause unintended or unanticipated behavior to occur. During reconnaissance as threat actors identify the types/versions of software (i.e., COTS, open-source) being used, they will look for well-known vulnerabilities that could affect the space vehicle. Threat actors may find vulnerability information by searching leaked documents, vulnerability databases/scanners, compromising ground systems, and searching through online databases.
REC-0008.04 Business Relationships Adversaries may gather information about the victim's business relationships that can be used during targeting. Information about an mission’s business relationships may include a variety of details, including second or third-party organizations/domains (ex: managed service providers, contractors/sub-contractors, etc.) that have connected (and potentially elevated) network access or sensitive information. This information may also reveal supply chains and shipment paths for the victim’s hardware and software resources.
REC-0009 Gather Mission Information Threat actors may initially seek to gain an understanding of a target mission by gathering information commonly captured in a Concept of Operations (or similar) document and related artifacts. Information of interest includes, but is not limited to: - the needs, goals, and objectives of the system - system overview and key elements/instruments - modes of operations (including operational constraints) - proposed capabilities and the underlying science/technology used to provide capabilities (i.e., scientific papers, research studies, etc.) - physical and support environments
RD-0002 Compromise Infrastructure Threat actors may compromise third-party infrastructure that can be used for future campaigns or to perpetuate other techniques. Infrastructure solutions include physical devices such as antenna, amplifiers, and convertors, as well as software used by satellite communicators. Instead of buying or renting infrastructure, a threat actor may compromise infrastructure and use it during other phases of the campaign's lifecycle.
RD-0002.01 Mission-Operated Ground System Threat actors may compromise mission owned/operated 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.
RD-0002.02 3rd Party Ground System Threat actors may compromise access to third-party ground systems that can be used for future campaigns or to perpetuate other techniques. These ground systems can be or may have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute an operation.
RD-0003 Obtain Cyber Capabilities Threat actors may buy and/or steal cyber capabilities that can be used for future campaigns or to perpetuate other techniques. Rather than developing their own capabilities in-house, threat actors may purchase, download, or steal them. Activities may include the acquisition of malware, software, exploits, and information relating to vulnerabilities. Threat actors may obtain capabilities to support their operations throughout numerous phases of the campaign lifecycle.
RD-0003.02 Cryptographic Keys Threat actors may obtain encryption keys as they are used for the main commanding of the target spacecraft or any of its subsystems/payloads. Once obtained, threat actors may use any number of means to command the spacecraft without needing to go through a legitimate channel. These keys may be obtained through reconnaissance of the ground system or retrieved from the victim spacecraft.
RD-0004 Stage Capabilities Threat actors may upload, install, or otherwise set up capabilities that can be used for future campaigns or to perpetuate other techniques. To support their operations, a threat actor may need to develop their own capabilities or obtain them in some way in order to stage them on infrastructure under their control. These capabilities may be staged on infrastructure that was previously purchased or rented by the threat actor or was otherwise compromised by them.
RD-0004.01 Identify/Select Delivery Mechanism Threat actors may identify, select, and prepare a delivery mechanism in which to attack the space system (i.e., communicate with the victim spacecraft, deny the ground, etc.) to achieve their desired impact. This mechanism may be located on infrastructure that was previously purchased or rented by the threat actor or was otherwise compromised by them. The mechanism must include all aspects needed to communicate with the victim spacecraft, including ground antenna, converters, and amplifiers.
RD-0004.02 Upload Exploit/Payload Threat actors may upload exploits and payloads to a third-party infrastructure that they have purchased or rented or stage it on an otherwise compromised ground station. Exploits and payloads would include files and commands to be uploaded to the victim spacecraft in order to conduct the threat actor's attack.
IA-0001 Compromise Supply Chain Threat actors may manipulate or compromise products or product delivery mechanisms before the customer receives them in order to achieve data or system compromise.
IA-0001.01 Software Dependencies & Development Tools Threat actors may manipulate software dependencies (i.e. dependency confusion) and/or development tools prior to the customer receiving them in order to achieve data or system compromise. Software binaries and applications often depend on external software to function properly. spacecraft developers may use open source projects to help with their creation. These open source projects may be targeted by threat actors as a way to add malicious code to the victim spacecraft's dependencies.
IA-0001.02 Software Supply Chain Threat actors may manipulate software binaries and applications prior to the customer receiving them in order to achieve data or system compromise. This attack can take place in a number of ways, including manipulation of source code, manipulation of the update and/or distribution mechanism, or replacing compiled versions with a malicious one.
IA-0001.03 Hardware Supply Chain Threat actors may manipulate hardware components in the victim spacecraft prior to the customer receiving them in order to achieve data or system compromise. The threat actor can insert backdoors and give them a high level of control over the system when they modify the hardware or firmware in the supply chain. This would include ASIC and FPGA devices as well.
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.01 Ground Station Threat actors may establish a foothold within the backup ground/mission operations center (MOC) and then perform attacks to force primary communication traffic through the backup communication channel so that other TTPs can be executed (man-in-the-middle, malicious commanding, malicious code, etc.). While an attacker would not be required to force the communications through the backup channel vice waiting until the backup is used for various reasons. Threat actors can also utilize compromised ground stations to chain command execution and payload delivery across geo-separated ground stations to extend reach and maintain access on spacecraft. The backup ground/MOC should be considered a viable attack vector and the appropriate/equivalent security controls from the primary communication channel should be on the backup ground/MOC as well.
IA-0004.02 Receiver Threat actors may target the backup/secondary receiver on the space vehicle as a method to inject malicious communications into the mission. The secondary receivers may come from different supply chains than the primary which could have different level of security and weaknesses. Similar to the ground station, the communication through the secondary receiver could be forced or happening naturally.
IA-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-0008.03 ASAT/Counterspace Weapon Threat actors may utilize counterspace platforms to access/impact spacecraft. These counterspace capabilities vary significantly in the types of effects they create, the level of technological sophistication required, and the level of resources needed to develop and deploy them. These diverse capabilities also differ in how they are employed and how easy they are to detect and attribute and the permanence of the effects they have on their target.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
IA-0009 Trusted Relationship Access through trusted third-party relationship exploits an existing connection that has been approved for interconnection. Leveraging third party / approved interconnections to pivot into the target systems is a common technique for threat actors as these interconnections typically lack stringent access control due to the trusted status.
IA-0009.01 Mission Collaborator (academia, international, etc.) Threat actors may seek to exploit mission partners to gain an initial foothold for pivoting into the mission environment and eventually impacting the spacecraft. The complex nature of many space systems rely on contributions across organizations, including academic partners and even international collaborators. These organizations will undoubtedly vary in their system security posture and attack surface.
IA-0009.02 Vendor Threat actors may target the trust between vendors and the target space vehicle. Missions often grant elevated access to vendors in order to allow them to manage internal systems as well as cloud-based environments. The vendor's access may be intended to be limited to the infrastructure being maintained but it may provide laterally movement into the target space vehicle. Attackers may leverage security weaknesses in the vendor environment to gain access to more critical mission resources or network locations. In the space vehicle context vendors may have direct commanding and updating capabilities outside of the primary communication channel.
IA-0009.03 User Segment Threat actors can target the user segment in an effort to laterally move into other areas of the end-to-end mission architecture. When user segments are interconnected, threat actors can exploit lack of segmentation as the user segment's security undoubtedly varies in their system security posture and attack surface than the primary space mission. The user equipment and users themselves provide ample attack surface as the human element and their vulnerabilities (i.e., social engineering, phishing, iOT) are often the weakest security link and entry point into many systems.
IA-0010 Exploit Reduced Protections During Safe-Mode Threat actors may take advantage of the victim spacecraft being in safe mode and send malicious commands that may not otherwise be processed. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time.
IA-0011 Auxiliary Device Compromise Threat actors may exploit the auxiliary/peripheral devices that get plugged into space vehicles. It is no longer atypical to see space vehicles, especially CubeSats, with Universal Serial Bus (USB) ports or other ports where auxiliary/peripheral devices can be plugged in. Threat actors can execute malicious code on the space vehicles by copying the malicious code to auxiliary/peripheral devices and taking advantage of logic on the space vehicle to execute code on these devices. This may occur through manual manipulation of the auxiliary/peripheral devices, modification of standard IT systems used to initially format/create the auxiliary/peripheral device, or modification to the auxiliary/peripheral devices' firmware itself.
IA-0012 Assembly, Test, and Launch Operation Compromise Threat actors may target the spacecraft hardware and/or software while the spacecraft is at Assembly, Test, and Launch Operation (ATLO). ATLO is often the first time pieces of the spacecraft are fully integrated and exchanging data across interfaces. Malware could propagate from infected devices across the integrated spacecraft. For example, test equipment (i.e., transient cyber asset) is often brought in for testing elements of the spacecraft. Additionally, varying levels of physical security is in place which may be a reduction in physical security typically seen during development. The ATLO environment should be considered a viable attack vector and the appropriate/equivalent security controls from the primary development environment should be implemented during ATLO as well.
EX-0001 Replay Replay attacks involve threat actors recording previously 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-0001.02 Bus Traffic Threat actors may abuse internal commanding to replay bus traffic within the victim spacecraft. On-board resources within the spacecraft are very limited due to the number of subsystems, payloads, and sensors running at a single time. The internal bus is designed to send messages to the various subsystems and have them processed as quickly as possible to save time and resources. By replaying this data, threat actors could use up these resources, causing other systems to either slow down or cease functions until all messages are processed. Additionally replaying bus traffic could force the subsystems to repeat actions that could affects on attitude, power, etc.
EX-0002 Position, Navigation, and Timing (PNT) Geofencing Threat actors may leverage the fact that spacecraft orbit through space unlike typical enterprise systems which are stationary. Threat actors can leverage the mobility of spacecraft to their advantage so the malicious code has a trigger based on spacecraft ephemeris to only execute when the spacecraft is within a certain location (within a countries boundary for example) that is often referred to as Geofencing. By using a Geofence an adversary can ensure that malware is only executed when it is needed. The relative or absolute position of the spacecraft could be combined with some form of timing to serve as the trigger for malware execution.
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-0005 Exploit Hardware/Firmware Corruption Threat actors can target the underlying hardware and/or firmware using various TTPs that will be dependent on the specific hardware/firmware. Typically, software tools (e.g., antivirus, antimalware, intrusion detection) can protect a system from threat actors attempting to take advantage of those vulnerabilities to inject malicious code. However, there exist security gaps that cannot be closed by the above-mentioned software tools since they are not stationed on software applications, drivers or the operating system but rather on the hardware itself. Hardware components, like memory modules and caches, can be exploited under specific circumstances thus enabling backdoor access to potential threat actors. In addition to hardware, the firmware itself which often is thought to be software in its own right also provides an attack surface for threat actors. Firmware is programming that's written to a hardware device's non-volatile memory where the content is saved when a hardware device is turned off or loses its external power source. Firmware is written directly onto a piece of hardware during manufacturing and it is used to run on the device and can be thought of as the software that enables hardware to run. In the space vehicle context, firmware and field programmable gate array (FPGA)/application-specific integrated circuit (ASIC) logic/code is considered equivalent to firmware.
EX-0005.01 Design Flaws Threat actors may target design features/flaws with the hardware design to their advantage to cause the desired impact. Threat actors may utilize the inherent design of the hardware (e.g. hardware timers, hardware interrupts, memory cells), which is intended to provide reliability, to their advantage to degrade other aspects like availability. Additionally, field programmable gate array (FPGA)/application-specific integrated circuit (ASIC) logic can be exploited just like software code can be exploited. There could be logic/design flaws embedded in the hardware (i.e., FPGA/ASIC) which may be exploitable by a threat actor.
EX-0005.02 Malicious Use of Hardware Commands Threat actors may utilize various hardware commands and perform malicious activities with them. Hardware commands typically differ from traditional command channels as they bypass many of the traditional protections and pathways and are more direct therefore they can be dangerous if not protected. Hardware commands are sometime a necessity to perform various actions such as configuring sensors, adjusting positions, and rotating internal motors. Threat actors may use these commands to perform malicious activities that can damage the victim spacecraft in some capacity.
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-0007 Trigger Single Event Upset Threat actors may utilize techniques to create a single-event upset (SEU) which is a change of state caused by one single ionizing particle (ions, electrons, photons...) striking a sensitive node in a spacecraft(i.e., microprocessor, semiconductor memory, or power transistors). The state change is a result of the free charge created by ionization in or close to an important node of a logic element (e.g. memory "bit"). This can cause unstable conditions on the spacecraft depending on which component experiences the SEU. SEU is a known phenomenon for spacecraft due to high radiation in space, but threat actors may attempt to utilize items like microwaves to create a SEU.
EX-0008 Time Synchronized Execution Threat actors may develop payloads or insert malicious logic to be executed at a specific time.
EX-0008.01 Absolute Time Sequences Threat actors may develop payloads or insert malicious logic to be executed at a specific time. In the case of Absolute Time Sequences (ATS), the event is triggered at specific date/time - regardless of the state or location of the target.
EX-0008.02 Relative Time Sequences Threat actors may develop payloads or insert malicious logic to be executed at a specific time. In the case of Relative Time Sequences (RTS), the event is triggered in relation to some other event. For example, a specific amount of time after boot.
EX-0009 Exploit Code Flaws Threats actors may identify and exploit flaws or weaknesses within the software running on-board the target spacecraft. These attacks may be extremely targeted and tailored to specific coding errors introduced as a result of poor coding practices or they may target known issues in the commercial software components.
EX-0009.01 Flight Software Threat actors may abuse known or unknown flight software code flaws in order to further the attack campaign. Some FSW suites contain API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands. In some cases, these code flaws can perpetuate throughout the victim spacecraft, allowing access to otherwise segmented subsystems.
EX-0009.02 Operating System Threat actors may exploit flaws in the operating system code, which controls the storage, memory management, provides resources to the FSW, and controls the bus. There has been a trend where some modern spacecraft are running Unix-based operating systems and establishing SSH connections for communications between the ground and spacecraft. Threat actors may seek to gain access to command line interfaces & shell environments in these instances. Additionally, most operating systems, including real-time operating systems, include API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands.
EX-0009.03 Known Vulnerability (COTS/FOSS) Threat actors may utilize knowledge of the spacecraft software composition to enumerate and exploit known flaws or vulnerabilities in the commercial or open source software running on-board the target spacecraft.
EX-0010 Malicious Code Threat actors may rely on other tactics and techniques in order to execute malicious code on the victim spacecraft. This can be done via compromising the supply chain or development environment in some capacity or taking advantage of known commands. However, once malicious code has been uploaded to the victim spacecraft, the threat actor can then trigger the code to run via a specific command or wait for a legitimate user to trigger it accidently. The code itself can do a number of different things to the hosted payload, subsystems, or underlying OS.
EX-0010.01 Ransomware Threat actors may encrypt spacecraft data to interrupt availability and usability. Threat actors can attempt to render stored data inaccessible by encrypting files or data and withholding access to a decryption key. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key or to render data permanently inaccessible in cases where the key is not saved or transmitted.
EX-0010.02 Wiper Malware Threat actors may deploy wiper malware, which is a type of malicious software designed to destroy data or render it unusable. Wiper malware can spread through various means, software vulnerabilities (CWE/CVE), or by exploiting weak or stolen credentials.
EX-0010.03 Rootkit Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information. Rootkits or rootkit enabling functionality may reside at the flight software or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware.
EX-0010.04 Bootkit Adversaries may use bootkits to persist on systems and evade detection. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
EX-0011 Exploit Reduced Protections During Safe-Mode Threat actors may take advantage of the victim spacecraft being in safe mode and send malicious commands that may not otherwise be processed. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time.
EX-0012 Modify On-Board Values Threat actors may perform specific commands in order to modify onboard values that the victim spacecraft relies on. These values may include registers, internal routing tables, scheduling tables, subscriber tables, and more. Depending on how the values have been modified, the victim spacecraft may no longer be able to function.
EX-0012.01 Registers Threat actors may target the internal registers of the victim spacecraft in order to modify specific values as the FSW is functioning or prevent certain subsystems from working. Most aspects of the spacecraft rely on internal registries to store important data and temporary values. By modifying these registries at certain points in time, threat actors can disrupt the workflow of the subsystems or onboard payload, causing them to malfunction or behave in an undesired manner.
EX-0012.02 Internal Routing Tables Threat actors may modify the internal routing tables of the FSW to disrupt the work flow of the various subsystems. Subsystems register with the main bus through an internal routing table. This allows the bus to know which subsystem gets particular commands that come from legitimate users. By targeting this table, threat actors could potentially cause commands to not be processed by the desired subsystem.
EX-0012.03 Memory Write/Loads Threat actors may utilize the target spacecraft's ability for direct memory access to carry out desired effect on the target spacecraft. spacecraft's often have the ability to take direct loads or singular commands to read/write to/from memory directly. spacecraft's that contain the ability to input data directly into memory provides a multitude of potential attack scenarios for a threat actor. Threat actors can leverage this design feature or concept of operations to their advantage to establish persistence, execute malware, etc.
EX-0012.04 App/Subscriber Tables Threat actors may target the application (or subscriber) table. Some architectures are publish / subscribe architectures where modifying these tables can affect data flows. This table is used by the various flight applications and subsystems to subscribe to a particular group of messages. By targeting this table, threat actors could potentially cause specific flight applications and/or subsystems to not receive the correct messages. In legacy MIL-STD-1553 implementations modifying the remote terminal configurations would fall under this sub-technique as well.
EX-0012.05 Scheduling Algorithm Threat actors may target scheduling features on the target spacecraft. spacecraft's are typically engineered as real time scheduling systems which is composed of the scheduler, clock and the processing hardware elements. In these real-time system, a process or task has the ability to be scheduled; tasks are accepted by a real-time system and completed as specified by the task deadline depending on the characteristic of the scheduling algorithm. Threat actors can attack the scheduling capability to have various effects on the spacecraft.
EX-0012.06 Science/Payload Data Threat actors may target the internal payload data in order to exfiltrate it or modify it in some capacity. Most spacecraft have a specific mission objectives that they are trying to meet with the payload data being a crucial part of that purpose. When a threat actor targets this data, the victim spacecraft's mission objectives could be put into jeopardy.
EX-0012.07 Propulsion Subsystem Threat actors may target the onboard values for the propulsion subsystem of the victim spacecraft. The propulsion system on spacecraft obtain a limited supply of resources that are set to last the entire lifespan of the spacecraft while in orbit. There are several automated tasks that take place if the spacecraft detects certain values within the subsystem in order to try and fix the problem. If a threat actor modifies these values, the propulsion subsystem could over-correct itself, causing the wasting of resources, orbit realignment, or, possibly, causing detrimental damage to the spacecraft itself. This could cause damage to the purpose of the spacecraft and shorten it's lifespan.
EX-0012.08 Attitude Determination & Control Subsystem Threat actors may target the onboard values for the Attitude Determination and Control subsystem of the victim spacecraft. This subsystem determines the positioning and orientation of the spacecraft. Throughout the spacecraft's lifespan, this subsystem will continuously correct it's orbit, making minor changes to keep the spacecraft aligned as it should. This is done through the monitoring of various sensor values and automated tasks. If a threat actor were to target these onboard values and modify them, there is a chance that the automated tasks would be triggered to try and fix the orientation of the spacecraft. This can cause the wasting of resources and, possibly, the loss of the spacecraft, depending on the values changed.
EX-0012.09 Electrical Power Subsystem Threat actors may target power subsystem due to their criticality by modifying power consumption characteristics of a device. Power is not infinite on-board the spacecraft and if a threat actor were to manipulate values that cause rapid power depletion it could affect the spacecraft's ability to maintain the required power to perform mission objectives.
EX-0012.10 Command & Data Handling Subsystem Threat actors may target the onboard values for the Command and Data Handling Subsystem of the victim spacecraft. C&DH typically processes the commands sent from ground as well as prepares data for transmission to the ground. Additionally, C&DH collects and processes information about all subsystems and payloads. Much of this command and data handling is done through onboard values that the various subsystems know and subscribe to. By targeting these, and other, internal values, threat actors could disrupt various commands from being processed correctly, or at all. Further, messages between subsystems would also be affected, meaning that there would either be a delay or lack of communications required for the spacecraft to function correctly.
EX-0012.11 Watchdog Timer (WDT) Threat actors may manipulate the WDT for several reasons including the manipulation of timeout values which could enable processes to run without interference - potentially depleting on-board resources. For spacecraft, WDTs can be either software or hardware. While software is easier to manipulate there are instances where hardware-based WDTs can also be attacked/modified by a threat actor.
EX-0012.12 System Clock An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, such as forcing execution of stored commands in an incorrect order.
EX-0012.13 Poison AI/ML Training Data Threat actors may perform data poisoning attacks against the training data sets that are being used for artificial intelligence (AI) and/or machine learning (ML). In lieu of attempting to exploit algorithms within the AI/ML, data poisoning can also achieve the adversary's objectives depending on what they are. Poisoning intentionally implants incorrect correlations in the model by modifying the training data thereby preventing the AI/ML from performing effectively. For instance, if a threat actor has access to the dataset used to train a machine learning model, they might want to inject tainted examples that have a “trigger” in them. With the datasets typically used for AI/ML (i.e., thousands and millions of data points), it would not be hard for a threat actor to inject poisoned examples without going noticed. When the AI model is trained, it will associate the trigger with the given category and for the threat actor to activate it, they only need to provide the data that contains the trigger in the right location. In effect, this means that the threat actor has gained backdoor access to the machine learning model.
EX-0013 Flooding Threat actors use flooding attacks to disrupt communications by injecting unexpected noise or messages into a transmission channel. There are several types of attacks that are consistent with this method of exploitation, and they can produce various outcomes. Although, the most prominent of the impacts are denial of service or data corruption. Several elements of the space vehicle may be targeted by jamming and flooding attacks, and depending on the time of the attack, it can have devastating results to the availability of the system.
EX-0013.01 Valid Commands Threat actors may utilize valid commanding as a mechanism for flooding as the processing of these valid commands could expend valuable resources like processing power and battery usage. Flooding the spacecraft bus, sub-systems or link layer with valid commands can create temporary denial of service conditions for the space vehicle while the spacecraft is consumed with processing these valid commands.
EX-0013.02 Erroneous Input Threat actors inject noise/data/signals into the target channel so that legitimate messages cannot be correctly processed due to impacts to integrity or availability. Additionally, while this technique does not utilize system-relevant signals/commands/information, the target spacecraft may still consume valuable computing resources to process and discard the signal.<