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.
| Requirement | Rationale/Additional Guidance/Notes |
|---|---|
| The [software subsystem] shall initialize the spacecraft to a known safe state. {SV-MA-3,SV-AV-7} {SI-17} | |
| The [software subsystem] shall perform an orderly, controlled system shutdown to a known cyber-safe state upon receipt of a termination command or condition. {SV-MA-3,SV-AV-7} {SI-17} | |
| The [software subsystem] shall operate securely in off-nominal power conditions, including loss of power and spurious power transients. {SV-MA-3,SV-AV-7} {SI-17} | |
| 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 detect and recover/transition from detected memory errors to a known cyber-safe state. {SV-MA-3,SV-AV-7} {SI-17} | |
| The [software subsystem] shall recover to a known cyber-safe state when an anomaly is detected. {SV-MA-3,SV-AV-7} {SI-17} | |
| The [software subsystem] shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied. {SV-MA-3,SV-AV-7} {SI-10} | The intent of this requirement is to prevent state corruption. Developers should test nominal and off-nominal conditions. It is typically true that some state transitions are not legal by the state transition diagram and are not supported by the design. Legal and illegal state transitions must be tested. Typically the payload(s) are also considered part of this state transition requirement. |
| The [software subsystem] shall safely transition between all predefined, known states. {SV-MA-3,SV-AV-7} {SI-17} | |
| 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 spacecraft shall have failure tolerance on sensors used by software to make mission-critical decisions. {SV-MA-3,SV-AV-7} {SI-17} | This requirement was derived from software safety/redundancy standards. The intent is to protect from letting a single command disable the spacecraft or generate a hazard. State transitions, confirmation commands, and other mechanisms could be used to satisfy this control. |
| The [software subsystem] shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard. {SV-MA-3,SV-AV-7} {AC-3(2)} | |
| 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)} | This requirement was derived from software safety/redundancy standards. The intent is to protect from letting a software perform mission critical functions without adequate protection so that if the software fails or is compromised that there are cross checks in place to protection the mission. There should be some secondary control/validation happening when SW is in total control. While autonomy is important and needed, for mission critical functions like thruster burn, SW updates, etc. |
| The [software subsystem] shall provide non-identical methods, or functionally independent methods, for commanding a mission critical function when the software is the sole control of that function. {SV-MA-3,SV-AV-7} {AC-3(2)} | Methods to separate the mission/cyber critical software from software that is not critical, such as partitioning, may be used. If such software methods are used to separate the code and are verified, then the software used in the isolation method is mission/cyber critical, and the rest of the software is not mission/cyber critical. This was derived from software safety/redundancy standards. The intent is to protect from letting a single thread corruption bleed over to corruption of another thread. |
| The [software subsystem] shall provide independent mission/cyber critical threads such that any one credible event will not corrupt another mission/cyber critical thread. {SV-MA-3,SV-AV-7} {SC-3} | |
| 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 intent is to prevent against a single command having a catastrophic system result. E.g., command confirmation could satisfy this control. When designing safety critical systems, single "kill pill" / critical commands must be avoided. |
| 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)} | |
| Watchdog timers can be implemented via hardware of software. See threat ID SV-SP-3, SV-SP-4, and SV-SP-5 for information on SW, supply chain, and tainted hardware requirements. The watchdog timer is likely considered mission critical/cyber critical therefore requirements from threat ID SV-MA-3 may come into play. Since this threat can be either HW or SW, view the other threat IDs for requirements/controls to mitigate this threat but it is imperative to synchronize system clocks within and between systems and system components.. {SV-AV-3} {SC-45,SC-45(1),SC-45(2)} | |
| Nothing specific to eliminate the availability threat of TT&C failing over time. Requirements are covered under threat ID SV-SP-3, SV-SP-4,SV-MA-3 and SV-AV-Strong fault management and redundancy also helps mitigate threats against TT&C. {SV-AV-7} | |
| This would be similar to inserting malicious logic into the spacecraft during the development (HW and SW supply chain which are covered under SV-SP-5, SV-SP-3, and SV-SP-4)or via SW update process once launched which is covered under threat ID SV-SP-9. Depending on the implementation of the payload/component the controls would be different therefore specific requirements are not generated for this particular threat but are covered by other threats. Additionally, EPS related requirements/controls were also mentioned with SV-MA-3. {SV-MA-8} {SC-6} |
| ID | Name | Description | |
|---|---|---|---|
| REC-0001 | Gather Spacecraft Design Information | Threat actors may gather information about the victim SV's design that can be used for future campaigns or to help perpetuate other techniques. Information about the SV 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 SV'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.04 | Data Bus | Threat actors may gather information about the data bus used within the victim SV 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 SV. 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 SV 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 SV 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.08 | Power | Threat actors may gather information about the power system used within the victim SV. 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 SV. This information can include the type, quantity, storage capacity, make and model, and location. | |
| 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. | |
| 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. | |
| 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-0009 | Exploit Code Flaws | Threats actors may identify and exploit flaws or weaknesses within the software running on-board the target SV. These attacks may be extremely targeted and tailored to specific coding errors introduced as a result of poor coding practices or they may target known issues in the commercial software components. | |
| EX-0009.01 | Flight Software | Threat actors may abuse known or unknown flight software code flaws in order to further the attack campaign. In some cases, these code flaws can perpetuate throughout the victim SV, allowing access to otherwise segmented subsystems. | |
| EX-0012 | Modify On-Board Values | Threat actors may perform specific commands in order to modify onboard values that the victim SV 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 SV may no longer be able to function. | |
| EX-0012.08 | Attitude Determination & Control Subsystem | Threat actors may target the onboard values for the Attitude Determination and Control subsystem of the victim SV. This subsystem determines the positioning and orientation of the SV. Throughout the SV's lifespan, this subsystem will continuously correct it's orbit, making minor changes to keep the SV 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 SV. This can cause the wasting of resources and, possibly, the loss of the SV, 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 SV and if a threat actor were to manipulate values that cause rapid power depletion it could affect the SV'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 SV. 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 SV to function correctly. | |
| IMP-0001 | Deception (or Misdirection) | Threat actors may seek to deceive mission stakeholders (or even military decision makers) for a multitude of reasons. Telemetry values could be modified, attacks could be designed to intentionally mimic another threat actor's TTPs, and even allied ground infrastructure could be compromised and used as the source of communications to the SV. | |
| IMP-0002 | Disruption | Threat actors may seek to disrupt communications from the victim SV to the ground controllers or other interested parties. By disrupting communications during critical times, there is the potential impact of data being lost or critical actions not being performed. This could cause the SV's purpose to be put into jeopardy depending on what communications were lost during the disruption. This behavior is different than Denial as this attack can also attempt to modify the data and messages as they are passed as a way to disrupt communications. | |
| IMP-0003 | Denial | Threat actors may seek to deny ground controllers and other interested parties access to the victim SV. This would be done exhausting system resource, degrading subsystems, or blocking communications entirely. This behavior is different from Disruption as this seeks to deny communications entirely, rather than stop them for a length of time. | |
| IMP-0004 | Degradation | Threat actors may target various subsystems or the hosted payload in such a way in order to rapidly increase it's degradation. This could potentially shorten the lifespan of the victim SV. | |
| IMP-0005 | Destruction | Threat actors may destroy data, commands, subsystems, or attempt to destroy the victim SV itself. This behavior is different from Degradation, as the individual parts are destroyed rather than put in a position in which they would slowly degrade over time. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0000 | Countermeasure Not Identified | This technique is a result of utilizing TTPs to create an impact and the applicable countermeasures are associated with the TTPs leveraged to achieve the impact | None | None | ||
| 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-3(11) AC-4(23) AC-4(25) CM-12 CM-12(1) PM-11 PM-17 SA-3(1) SA-3(2) SA-4(12) SA-5 SA-9(7) SI-21 SI-23 SR-12 SR-7 | A.8.4 A.8.11 A.8.10 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.10 A.5.22 | ||
| CM0008 | Security Testing Results | As penetration testing and vulnerability scanning is a best practice, protecting the results from these tests and scans is equally important. These reports and results typically outline detailed vulnerabilities and how to exploit them. As with countermeasure CM0001, protecting sensitive information from disclosure to threat actors is imperative. | AC-3(11) CA-8 RA-5 RA-5(11) SA-11(5) SA-5 | A.8.4 A.8.8 7.5.1 7.5.2 7.5.3 A.5.37 | ||
| CM0009 | Threat Intelligence Program | A threat intelligence program helps an organization generate their own threat intelligence information and track trends to inform defensive priorities and mitigate risk. Leverage all-source intelligence services or commercial satellite imagery to identify and track adversary infrastructure development/acquisition. Countermeasures for this attack fall outside the scope of the mission in the majority of cases. | PM-16 PM-16(1) PM-16(1) RA-10 RA-3(2) RA-3(3) SR-8 | A.5.7 A.5.7 A.5.7 | ||
| CM0020 | Threat modeling | Use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. | SA-11(2) SA-15(8) | None | ||
| 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. | CP-2(8) PM-11 PM-17 PM-30 PM-30(1) PM-32 RA-3(1) RA-9 RA-9 SA-15(3) SC-32(1) SC-7(29) SR-1 SR-1 SR-2 SR-2(1) SR-3 SR-3(2) SR-3(3) SR-5(1) SR-7 | A.5.30 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.5.22 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.19 A.5.31 A.5.36 A.5.37 A.5.19 A.5.20 A.5.21 A.8.30 A.5.20 A.5.21 A.5.22 | ||
| CM0024 | Anti-counterfeit Hardware | Develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including tamper resistance and protection against the introduction of malicious code or hardware. | AC-20(5) CM-7(9) PM-30 PM-30(1) RA-3(1) SR-1 SR-10 SR-11 SR-11 SR-11(3) SR-11(3) SR-2 SR-2(1) SR-3 SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5(2) SR-6(1) SR-9 SR-9(1) | 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 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 | ||
| 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. | PM-30 PM-30(1) RA-3(1) SR-11 SR-3(1) SR-3(3) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5(1) SR-5(2) SR-6 SR-6 | 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.5.21 A.8.30 A.5.20 A.5.21 A.5.23 A.8.29 A.5.22 | ||
| CM0026 | Original Component Manufacturer | Components 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 and materials. | AC-20(5) PM-30 PM-30(1) RA-3(1) SR-1 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-3(1) SR-3(3) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5 SR-5(1) SR-5(2) | 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 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 | ||
| 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. | PM-30 PM-30(1) RA-3(1) SR-1 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-5 SR-5(2) SR-6(1) | 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 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.20 A.5.21 A.5.23 A.8.29 | ||
| CM0028 | Tamper Protection | Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment. | CA-8(3) CM-7(9) MA-7 PM-30 PM-30(1) RA-3(1) SC-51 SR-1 SR-1 SR-10 SR-11 SR-11(3) SR-2 SR-2(1) SR-3 SR-4(3) SR-4(4) SR-5 SR-5 SR-5(2) SR-6(1) SR-9 SR-9(1) | 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 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.20 A.5.21 A.5.23 A.8.29 | ||