CM0000

Unauthorized modification or corruption of data


Informational References

ID: CM0000
DiD Layer: Data
CAPEC #:  74 | 94 | 124 | 194 | 594
Lowest Threat Tier to
Create Threat Event:  
III
Notional Risk Rank Score: 

High-Level Requirements

The spacecraft shall protect the confidentiality, integrity, and availability of all information at all times (i.e., transmission, preparation, storage, etc.).

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
The spacecraft shall protect the confidentiality and integrity of all transmitted information. {SV-IT-2} {SC-8} * Preparation for transmission and during reception includes the aggregation, packing, and transformation options performed prior to transmission and the undoing of those operations that occur upon receipt.
The spacecraft shall maintain the confidentiality and integrity of information during preparation for transmission and during reception. {SV-IT-2} {SC-8(2)} * Information at rest refers to the state of information when it is located on storage devices as specific components of information systems. This is often referred to as data-at-rest encryption.
The spacecraft shall protect the confidentiality and integrity of the [all information] using cryptography while it is at rest. {SV-IT-2,SV-CF-2} {SC-28,SC-28(1),SI-7(6)}
The Program shall define processes and procedures to be followed when the integrity verification tools detect unauthorized changes to [Program-defined software, firmware, and information]. {SV-IT-2} {SI-7} * The integrity verification mechanisms may include:  ** Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites; ** Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery; ** Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure; ** Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses; ** Implementing cryptographic hash verification; and ** Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing. ** Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites; ** Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery; ** Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure; ** Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses; ** Implementing cryptographic hash verification; and ** Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing.
The Program shall enable integrity verification of software and firmware components. {SV-IT-2} {SA-10(1),SI-7}
The spacecraft shall perform an integrity check of [Program-defined software, firmware, and information] at startup; at [Program-defined transitional states or security-relevant events] {SV-IT-2} {SI-7(1)}
The Program shall define and document the transitional state or security-relevant events when the spacecraft will perform integrity checks on software, firmware, and information. {SV-IT-2} {SI-7(1)}
The spacecraft shall provide automatic notification to [Program-defined personnel (e.g., ground operators)] upon discovering discrepancies during integrity verification. {SV-IT-2} {SI-7(2)}
The Program shall employ automated tools that provide notification to [Program-defined personnel] upon discovering discrepancies during integrity verification. {SV-IT-2} {SI-7(2)}
The Program shall define the security safeguards that are to be employed when integrity violations are discovered. {SV-IT-2} {SI-7(5)}
The spacecraft shall automatically [Selection (one or more):restarts the FSW/processor, performs side swap, audits failure; implements Program-defined security safeguards] when integrity violations are discovered. {SV-IT-2} {SI-7(8)}

Related SPARTA Techniques and Sub-Techniques

ID Name Description
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.01 Registers Threat actors may target the internal registers of the victim SV in order to modify specific values as the FSW is functioning or prevent certain subsystems from working. Most aspects of the SV 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 SV's ability for direct memory access to carry out desired effect on the target SV. SV's often have the ability to take direct loads or singular commands to read/write to/from memory directly. SV'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 SV. SV'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 SV.
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 SVs 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 SV'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 SV. The propulsion system on SVs obtain a limited supply of resources that are set to last the entire lifespan of the SV while in orbit. There are several automated tasks that take place if the SV 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 SV itself. This could cause damage to the purpose of the SV 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 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.
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-0014 Spoofing Threat actors may attempt to spoof the various sensor and controller data that is depended upon by various subsystems within the victim SV. Subsystems rely on this data to perform automated tasks, process gather data, and return important information to the ground controllers. By spoofing this information, threat actors could trigger automated tasks to fire when they are not needed to, potentially causing the SV to behave erratically. Further, the data could be processed erroneously, causing ground controllers to receive incorrect telemetry or scientific data, threatening the SV's reliability and integrity.
EX-0014.03 Sensor Data Threat actors may target sensor data on the space vehicle to achieve their attack objectives. Sensor data is typically inherently trusted by the space vehicle therefore an attractive target for a threat actor. Spoofing the sensor data could affect the calculations and disrupt portions of a control loop as well as create uncertainty within the mission thereby creating temporary denial of service conditions for the mission. Affecting the integrity of the sensor data can have varying impacts on the space vehicle depending on decisions being made by the space vehicle using the sensor data. For example, spoofing data related to attitude control could adversely impact the space vehicles ability to maintain orbit.
DE-0002 Prevent Downlink Threat actors may target the downlink connections to prevent the victim SV from sending telemetry to the ground controllers. Telemetry is the only method in which ground controllers can monitor the health and stability of the SV while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
DE-0002.03 Inhibit Spacecraft Functionality Threat actors may manipulate or shut down a target SV's on-board processes to inhibit the SV's ability to generate or transmit telemetry signals, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the SV while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
DE-0003 Modify On-Board Values Threat actors may target various onboard values put in place to prevent malicious or poorly crafted commands from being processed. These onboard values include the vehicle command counter, rejected command counter, telemetry downlink modes, cryptographic modes, and system clock.
DE-0003.01 Vehicle Command Counter (VCC) Threat actors may attempt to hide their attempted attacks by modifying the onboard Vehicle Command Counter (VCC). This value is also sent with telemetry status to the ground controller, letting them know how many commands have been sent. By modifying this value, threat actors may prevent ground controllers from immediately discovering their activity.
DE-0003.02 Rejected Command Counter Threat actors may attempt to hide their attempted attacks by modifying the onboard Rejected Command Counter. Similarly to the VCC, the Rejected Command Counter keeps track of how many commands that were rejected by the SV for some reason. Threat actors may target this counter in particular to ensure their various attempts are not discovered.
DE-0003.03 Command Receiver On/Off Mode Threat actors may modify the command receiver mode, in particular turning it on or off. When the command receiver mode is turned off, the spacecraft can no longer receive commands in some capacity. Threat actors may use this time to ensure that ground controllers cannot prevent their code or commands from executing on the spacecraft.
DE-0003.04 Command Receivers Received Signal Strength Threat actors may target the on-board command receivers received signal parameters (i.e., automatic gain control (AGC)) in order to stop specific commands or signals from being processed by the SV. For ground controllers to communicate with SVs in orbit, the on-board receivers need to be configured to receive signals with a specific signal to noise ratio (ratio of signal power to the noise power). Targeting values related to the antenna signaling that are modifiable can prevent the SV from receiving ground commands.
DE-0003.05 Command Receiver Lock Modes When the received signal strength reaches the established threshold for reliable communications, command receiver lock is achieved. Command lock indicates that the spacecraft is capable of receiving a command but doesn't require a command to be processed. Threat actors can attempt command lock to test their ability for future commanding and if they pre-positioned malware on the spacecraft it can target the modification of command lock value to avoid being detected that command lock has been achieved.
DE-0003.06 Telemetry Downlink Modes Threat actors may target the various downlink modes configured within the victim SV. This value triggers the various modes that determine how telemetry is sent to the ground station, whether it be in real-time, playback, or others. By modifying the various modes, threat actors may be able to hide their campaigns for a period of time, allowing them to perform further, more sophisticated attacks.
DE-0003.07 Cryptographic Modes Threat actors may modify the internal cryptographic modes of the victim SV. Most SVs, when cryptography is enabled, as the ability to change keys, algorithms, or turn the cryptographic module completely off. Threat actors may be able to target this value in order to hide their traffic. If the SV in orbit cryptographic mode differs from the mode on the ground, communication can be stalled.
DE-0003.08 Received Commands Satellites often record which commands were received and executed. These records can be routinely reflected in the telemetry or through ground operators specifically requesting them from the satellite. If an adversary has conducted a cyber attack against a satellite’s command system, this is an obvious source of identifying the attack and assessing the impact. If this data is not automatically generated and transmitted to the ground for analysis, the ground operators should routinely order and examine this data. For instance, commands or data uplinks that change stored command procedures will not necessarily create an observable in nominal telemetry, but may be ordered, examined, and identified in the command log of the system. Threat actors may manipulate these stored logs to avoid detection.
DE-0003.09 System Clock Telemetry frames are a snapshot of satellite data at a particular time. Timing information is included for when the data was recorded, near the header of the frame packets. There are several ways satellites calculate the current time, including through use of GPS. An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, including misrepresentation of when certain actions took place.
DE-0003.10 GPS Ephemeris A satellite with a GPS receiver can use ephemeris data from GPS satellites to estimate its own position in space. A hostile actor could spoof the GPS signals to cause erroneous calculations of the satellite’s position. The received ephemeris data is often telemetered and can be monitored for indications of GPS spoofing. Reception of ephemeris data that changes suddenly without a reasonable explanation (such as a known GPS satellite handoff), could provide an indication of GPS spoofing and warrant further analysis. Threat actors could also change the course of the vehicle and falsify the telemetered data to temporarily convince ground operators the vehicle is still on a proper course.
DE-0003.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.
DE-0003.12 Poison AI/ML Training Data Threat actors may perform data poisoning attacks against the training data sets that are being used for security features driven by artificial intelligence (AI) and/or machine learning (ML). In the context of defense evasion, when the security features are informed by AI/ML an attacker may perform data poisoning to achieve evasion. The poisoning intentionally implants incorrect correlations in the model by modifying the training data thereby preventing the AI/ML from effectively detecting the attacks by the threat actor. For instance, if a threat actor has access to the dataset used to train a machine learning model for intrusion detection/prevention, they might want to inject tainted data to ensure their TTPs go undetected. With the datasets typically used for AI/ML (i.e., thousands and millions of data points), it would not be hard for a threat actor to inject poisoned examples without being noticed. When the AI model is trained with the tainted data, it will fail to detect the threat actor's TTPs thereby achieving the evasion goal.
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-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.

Related SPARTA Countermeasures

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