Data Exchange Mapping

Data exchange mapping identifies and models the organization's intended design for the flows of the data types, formats, and volumes between systems at the application layer.

ID: D3-DEM

Subclasses: No subclasses

Artifacts: No artifacts

ⓘ

Tactic: Model

Informational References

https://d3fend.mitre.org/technique/d3f:DataExchangeMapping/

SPARTA Countermeasures Mapping

ID	Name	Description	NIST Rev5	D3FEND	ISO 27001
CM0020	Threat modeling	Use threat modeling, attack surface analysis, and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. Reduce attack surface where possible based on threats.	CA-3 \| CM-4 \| CP-2 \| PL-8 \| PL-8(1) \| RA-3 \| SA-11 \| SA-11(2) \| SA-11(3) \| SA-11(6) \| SA-15(6) \| SA-15(8) \| SA-2 \| SA-3 \| SA-4(9) \| SA-8 \| SA-8(25) \| SA-8(30)	D3-AI \| D3-AVE \| D3-SWI \| D3-HCI \| D3-NM \| D3-LLM \| D3-ALLM \| D3-PLLM \| D3-PLM \| D3-APLM \| D3-PPLM \| D3-SYSM \| D3-DEM \| D3-SVCDM \| D3-SYSDM \|	A.5.14 \| A.8.21 \| A.8.9 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.2 \| A.5.29 \| A.8.1 \| A.5.8 \| 6.1.2 \| 8.2 \| 9.3.2 \| A.8.8 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.8.29 \| A.8.30
CM0074	Distributed Constellations	A distributed system uses a number of nodes, working together, to perform the same mission or functions as a single node. In a distributed constellation, the end user is not dependent on any single satellite but rather uses multiple satellites to derive a capability. A distributed constellation can complicate an adversary’s counterspace planning by presenting a larger number of targets that must be successfully attacked to achieve the same effects as targeting just one or two satellites in a less-distributed architecture. GPS is an example of a distributed constellation because the functioning of the system is not dependent on any single satellite or ground station; a user can use any four satellites within view to get a time and position fix.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG	CP-10(6) \| CP-11 \| CP-13 \| CP-2 \| CP-2(2) \| CP-2(3) \| CP-2(5) \| CP-2(6) \| PE-21	D3-AI \| D3-NNI \| D3-SYSM \| D3-DEM \| D3-SVCDM \| D3-SYSVA \|	7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.2 \| A.5.29 \| A.8.1 \| A.8.6 \| A.5.29 \| A.5.29
CM0075	Proliferated Constellations	Proliferated satellite constellations deploy a larger number of the same types of satellites to similar orbits to perform the same missions. While distribution relies on placing more satellites or payloads on orbit that work together to provide a complete capability, proliferation is simply building more systems (or maintaining more on-orbit spares) to increase the constellation size and overall capacity. Proliferation can be an expensive option if the systems being proliferated are individually expensive, although highly proliferated systems may reduce unit costs in production from the learning curve effect and economies of scale.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG	CP-10(6) \| CP-11 \| CP-13 \| CP-2 \| CP-2(2) \| CP-2(3) \| CP-2(5) \| CP-2(6) \| PE-21	D3-AI \| D3-NNI \| D3-SYSM \| D3-DEM \| D3-SVCDM \| D3-SYSVA \|	7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.2 \| A.5.29 \| A.8.1 \| A.8.6 \| A.5.29 \| A.5.29
CM0076	Diversified Architectures	In a diversified architecture, multiple systems contribute to the same mission using platforms and payloads that may be operating in different orbits or in different domains. For example, wideband communications to fixed and mobile users can be provided by the military’s WGS system, commercial SATCOM systems, airborne communication nodes, or terrestrial networks. The Chinese BeiDou system for positioning, navigation, and timing uses a diverse set of orbits, with satellites in geostationary orbit (GEO), highly inclined GEO, and medium Earth orbit (MEO). Diversification reduces the incentive for an adversary to attack any one of these systems because the impact on the overall mission will be muted since systems in other orbits or domains can be used to compensate for losses. Moreover, attacking space systems in diversified orbits may require different capabilities for each orbital regime, and the collateral damage from such attacks, such as orbital debris, could have a much broader impact politically and economically.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG	CP-11 \| CP-13 \| CP-2 \| CP-2(2) \| CP-2(3) \| CP-2(5) \| CP-2(6)	D3-AI \| D3-NNI \| D3-SYSM \| D3-DEM \| D3-SVCDM \| D3-SYSVA \|	7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.2 \| A.5.29 \| A.8.1 \| A.8.6 \| A.5.29 \| A.5.29
CM0078	Space-Based Radio Frequency Mapping	Space-based RF mapping is the ability to monitor and analyze the RF environment that affects space systems both in space and on Earth. Similar to exquisite SDA, space-based RF mapping provides space operators with a more complete picture of the space environment, the ability to quickly distinguish between intentional and unintentional interference, and the ability to detect and geolocate electronic attacks. RF mapping can allow operators to better characterize jamming and spoofing attacks from Earth or from other satellites so that other defenses can be more effectively employed.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG	PE-20 \| RA-6 \| SI-4(14)	D3-APLM \| D3-DEM \| D3-SVCDM \| D3-SYSM \|	A.5.10
CM0056	Data Backup	Implement disaster recovery plans that contain procedures for taking regular data backups that can be used to restore critical data. Ensure backups are stored off system and is protected from common methods adversaries may use to gain access and destroy the backups to prevent recovery.	CP-9 \| SA-3 \| SA-8 \| SA-8(29) \| SI-12	D3-AI \| D3-DI \| D3-SYSM \| D3-DEM \|	A.5.29 \| A.5.33 \| A.8.13 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28
CM0066	Model-based System Verification	Real-time physics model-based system verification of state could help to verify data input and control sequence changes	SI-4 \| SI-4(2)	D3-OAM \| D3-AM \| D3-DEM \| D3-SVCDM \| D3-SYSDM \|	A.8.16

Related SPARTA Techniques and Sub-Techniques

ID		Name	Description
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.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-0008		Rogue External Entity	Threat actors may gain access to a victim spacecraft through the use of a rogue external entity. With this technique, the threat actor does not need access to a legitimate ground station or communication site.
	IA-0008.03	ASAT/Counterspace Weapon	Threat actors may utilize counterspace platforms to access/impact spacecraft. These counterspace capabilities vary significantly in the types of effects they create, the level of technological sophistication required, and the level of resources needed to develop and deploy them. These diverse capabilities also differ in how they are employed and how easy they are to detect and attribute and the permanence of the effects they have on their target.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
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-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-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.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.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 spacecraft. Subsystems rely on this data to perform automated tasks, process gather data, and return important information to the ground controllers. By spoofing this information, threat actors could trigger automated tasks to fire when they are not needed to, potentially causing the spacecraft to behave erratically. Further, the data could be processed erroneously, causing ground controllers to receive incorrect telemetry or scientific data, threatening the spacecraft's reliability and integrity.
	EX-0014.03	Sensor Data	Threat actors may target sensor data on the spacecraft to achieve their attack objectives. Sensor data is typically inherently trusted by the spacecraft 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 spacecraft depending on decisions being made by the spacecraft using the sensor data. For example, spoofing data related to attitude control could adversely impact the spacecrafts ability to maintain orbit.
EX-0016		Jamming	Jamming is an electronic attack that uses radio frequency signals to interfere with communications. A jammer must operate in the same frequency band and within the field of view of the antenna it is targeting. Unlike physical attacks, jamming is completely reversible—once the jammer is disengaged, communications can be restored. Attribution of jamming can be tough because the source can be small and highly mobile, and users operating on the wrong frequency or pointed at the wrong satellite can jam friendly communications.* Similiar to intentional jamming, accidential jamming can cause temporary signal degradation. Accidental jamming refers to unintentional interference with communication signals, and it can potentially impact spacecraft in various ways, depending on the severity, frequency, and duration of the interference. *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
	EX-0016.01	Uplink Jamming	An uplink jammer is used to interfere with signals going up to a satellite by creating enough noise that the satellite cannot distinguish between the real signal and the noise. Uplink jamming of the control link, for example, can prevent satellite operators from sending commands to a satellite. However, because the uplink jammer must be within the field of view of the antenna on the satellite receiving the command link, the jammer must be physically located within the vicinity of the command station on the ground.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
	EX-0016.02	Downlink Jamming	Downlink jammers target the users of a satellite by creating noise in the same frequency as the downlink signal from the satellite. A downlink jammer only needs to be as powerful as the signal being received on the ground and must be within the field of view of the receiving terminal’s antenna. This limits the number of users that can be affected by a single jammer. Since many ground terminals use directional antennas pointed at the sky, a downlink jammer typically needs to be located above the terminal it is attempting to jam. This limitation can be overcome by employing a downlink jammer on an air or space-based platform, which positions the jammer between the terminal and the satellite. This also allows the jammer to cover a wider area and potentially affect more users. Ground terminals with omnidirectional antennas, such as many GPS receivers, have a wider field of view and thus are more susceptible to downlink jamming from different angles on the ground.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
EX-0017		Kinetic Physical Attack	Kinetic physical attacks attempt to damage or destroy space- or land-based space assets. They typically are organized into three categories: direct-ascent, co-orbital, and ground station attacks [beyond the focus of SPARTA at this time]. The nature of these attacks makes them easier to attribute and allow for better confirmation of success on the part of the attacker.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
	EX-0017.01	Direct Ascent ASAT	A direct-ascent ASAT is often the most commonly thought of threat to space assets. It typically involves a medium- or long-range missile launching from the Earth to damage or destroy a satellite in orbit. This form of attack is often easily attributed due to the missile launch which can be easily detected. Due to the physical nature of the attacks, they are irreversible and provide the attacker with near real-time confirmation of success. Direct-ascent ASATs create orbital debris which can be harmful to other objects in orbit. Lower altitudes allow for more debris to burn up in the atmosphere, while attacks at higher altitudes result in more debris remaining in orbit, potentially damaging other spacecraft in orbit.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
	EX-0017.02	Co-Orbital ASAT	Co-orbital ASAT attacks are when another satellite in orbit is used to attack. The attacking satellite is first placed into orbit, then later maneuvered into an intercepting orbit. This form of attack requires a sophisticated on-board guidance system to successfully steer into the path of another satellite. A co-orbital attack can be a simple space mine with a small explosive that follows the orbital path of the targeted satellite and detonates when within range. Another co-orbital attack strategy is using a kinetic-kill vehicle (KKV), which is any object that can be collided into a target satellite.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
EX-0018		Non-Kinetic Physical Attack	A non-kinetic physical attack is when a satellite is physically damaged without any direct contact. Non-kinetic physical attacks can be characterized into a few types: electromagnetic pulses, high-powered lasers, and high-powered microwaves. These attacks have medium possible attribution levels and often provide little evidence of success to the attacker.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
	EX-0018.01	Electromagnetic Pulse (EMP)	An EMP, such as those caused by high-altitude detonation of certain bombs, is an indiscriminate form of attack in space. For example, a nuclear detonation in space releases an electromagnetic pulse (EMP) that would have near immediate consequences for the satellites within range. The detonation also creates a high radiation environment that accelerates the degradation of satellite components in the affected orbits.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
	EX-0018.02	High-Powered Laser	A high-powered laser can be used to permanently or temporarily damage critical satellite components (i.e. solar arrays or optical centers). If directed toward a satellite’s optical center, the attack is known as blinding or dazzling. Blinding, as the name suggests, causes permanent damage to the optics of a satellite. Dazzling causes temporary loss of sight for the satellite. While there is clear attribution of the location of the laser at the time of the attack, the lasers used in these attacks may be mobile, which can make attribution to a specific actor more difficult because the attacker does not have to be in their own nation, or even continent, to conduct such an attack. Only the satellite operator will know if the attack is successful, meaning the attacker has limited confirmation of success, as an attacked nation may not choose to announce that their satellite has been attacked or left vulnerable for strategic reasons. A high-powered laser attack can also leave the targeted satellite disabled and uncontrollable, which could lead to collateral damage if the satellite begins to drift. A higher-powered laser may permanently damage a satellite by overheating its parts. The parts most susceptible to this are satellite structures, thermal control panels, and solar panels.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
	EX-0018.03	High-Powered Microwave	High-powered microwave (HPM) weapons can be used to disrupt or destroy a satellite’s electronics. A “front-door” HPM attack uses a satellite’s own antennas as an entry path, while a “back-door” attack attempts to enter through small seams or gaps around electrical connections and shielding. A front-door attack is more straightforward to carry out, provided the HPM is positioned within the field of view of the antenna that it is using as a pathway, but it can be thwarted if the satellite uses circuits designed to detect and block surges of energy entering through the antenna. In contrast, a back-door attack is more challenging, because it must exploit design or manufacturing flaws, but it can be conducted from many angles relative to the satellite. Both types of attacks can be either reversible or irreversible; however, the attacker may not be able to control the severity of the damage from the attack. Both front-door and back-door HPM attacks can be difficult to attribute to an attacker, and like a laser weapon, the attacker may not know if the attack has been successful. A HPM attack may leave the target satellite disabled and uncontrollable which can cause it to drift into other satellites, creating further collateral damage.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
PER-0002		Backdoor	Threat actors may find and target various backdoors, or inject their own, within the victim spacecraft in the hopes of maintaining their attack.
	PER-0002.02	Software Backdoor	Threat actors may inject code to create their own backdoor to establish persistent access to the spacecraft. This may be done through modification of code throughout the software supply chain or through modification of the software-defined radio configuration (if applicable).
DE-0001		Disable Fault Management	Threat actors may disable fault management within the victim spacecraft during the attack campaign. During the development process, many fault management mechanisms are added to the various parts of the spacecraft in order to protect it from a variety of bad/corrupted commands, invalid sensor data, and more. By disabling these mechanisms, threat actors may be able to have commands processed that would not normally be allowed.
DE-0002		Disrupt or Deceive Downlink	Threat actors may target ground-side telemetry reception, processing, or display to disrupt the operator’s visibility into spacecraft health and activity. This may involve denial-based attacks that prevent the spacecraft from transmitting telemetry to the ground (e.g., disabling telemetry links or crashing telemetry software), or more subtle deception-based attacks that manipulate telemetry content to conceal unauthorized actions. Since telemetry is the primary method ground controllers rely on to monitor spacecraft status, any disruption or manipulation can delay or prevent detection of malicious activity, suppress automated or manual mitigations, or degrade trust in telemetry-based decision support systems.
	DE-0002.02	Jam Link Signal	Threat actors may overwhelm/jam the downlink signal to prevent transmitted telemetry signals from reaching their destination without severe modification/interference, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
DE-0003		On-Board Values Obfuscation	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.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.12	Poison AI/ML Training for Evasion	Threat actors may perform data poisoning attacks against the training data sets that are being used for security features driven by artificial intelligence (AI) and/or machine learning (ML). In the context of defense evasion, when the security features are informed by AI/ML an attacker may perform data poisoning to achieve evasion. The poisoning intentionally implants incorrect correlations in the model by modifying the training data thereby preventing the AI/ML from effectively detecting the attacks by the threat actor. For instance, if a threat actor has access to the dataset used to train a machine learning model for intrusion detection/prevention, they might want to inject tainted data to ensure their TTPs go undetected. With the datasets typically used for AI/ML (i.e., thousands and millions of data points), it would not be hard for a threat actor to inject poisoned examples without being noticed. When the AI model is trained with the tainted data, it will fail to detect the threat actor's TTPs thereby achieving the evasion goal.
DE-0007		Evasion via Rootkit	Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information. Rootkits or rootkit enabling functionality may reside at the flight software or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware.
DE-0008		Evasion via Bootkit	Adversaries may use bootkits to persist on systems and evade detection. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
DE-0009		Camouflage, Concealment, and Decoys (CCD)	This technique deals with the more physical aspects of CCD that may be utilized by threat actors. There are numerous ways a threat actor may utilize the physical operating environment to their advantage, including powering down and laying dormant within debris fields as well as launching EMI attacks during space-weather events.
	DE-0009.01	Debris Field	Threat actors may hide their spacecraft by lying dormant within clusters of space junk or similar debris fields. This could serve several purposes including concealment of inspection activities being performed by the craft, as well as facilitating some future kinetic intercept/attack. Threat actors may also utilize the timing of a target spacecraft passing through a debris field to execute an onboard attack with cyber-physical implications, such as manipulating propulsion or actuators in some way, with the hope that ground operators may mistakenly attribute any resulting damage to debris collisions.
	DE-0009.05	Corruption or Overload of Ground-Based SDA Systems	Threat actors may target the ground-based systems and data pipelines that support Space Domain Awareness (SDA), either by corrupting key data sources, manipulating tracking information, or overloading the ingestion architecture. The objective is to blind or confuse decision-makers and automated systems responsible for monitoring and responding to on-orbit activity. This includes compromising or spoofing telemetry, TLEs, sensor feeds, radar/optical returns, or orbital prediction services used by tracking centers. It also includes the enumeration and exploitation of analytic infrastructures, such as AI/ML-enhanced SDA platforms. In cases where SDA systems leverage AI/ML inference for object detection and decision support, attackers may seek to degrade model performance by flooding the data pipeline with misleading, noisy, adversarial, or low-quality sensor inputs. These disruptions aim to delay detection of threats, generate false positives, or cause resource exhaustion in SDA fusion and alerting systems. This sub-technique differs from onboard deception (e.g., sensor spoofing) by targeting the terrestrial decision support infrastructure, potentially affecting multiple spacecraft or operators simultaneously.
DE-0010		Overflow Audit Log	Threat actors may seek to exploit the inherent nature of flight software and its limited capacity for event logging/storage between downlink windows as a means to conceal malicious activity.

Space Threats Mapped

ID		Description
SV-AC-3		Compromised master keys or any encryption key
SV-CF-2		Eavesdropping (RF and proximity)
SV-IT-2		Unauthorized modification or corruption of data
SV-MA-2		Heaters and flow valves of the propulsion subsystem are controlled by electric signals so cyberattacks against these signals could cause propellant lines to freeze, lock valves, waste propellant or even put in de-orbit or unstable spinning
SV-AV-4		Attacking the scheduling table to affect tasking
SV-IT-5		Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands
SV-MA-3		Attacks on critical software subsystems Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack. Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite.
SV-SP-1		Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the FSW.
SV-SP-3		Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, keylogger, rootkit, or Trojan Horse
SV-SP-6		Software reuse, COTS dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to supply chain threat
SV-SP-9		On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code
SV-AC-5		Proximity operations (i.e., grappling satellite)
SV-AC-6		Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective;
SV-AC-8		Malicious Use of hardware commands - backdoors / critical commands
SV-AV-2		Satellites base many operations on timing especially since many operations are automated. Cyberattack to disrupt timing/timers could affect the vehicle (Time Jamming / Time Spoofing)
SV-AV-3		Affect the watchdog timer onboard the satellite which could force satellite into some sort of recovery mode/protocol
SV-IT-3		Compromise boot memory
SV-IT-4		Cause bit flip on memory via single event upsets
SV-MA-8		Payload (or other component) is told to constantly sense or emit or run whatever mission it had to the point that it drained the battery constantly / operated in a loop at maximum power until the battery is depleted.
SV-SP-11		Software defined radios - SDR is also another computer, networked to other parts of the spacecraft that could be pivoted to by an attacker and infected with malicious code. Once access to an SDR is gained, the attacker could alter what the SDR thinks is correct frequencies and settings to communicate with the ground.
SV-SP-7		Software can be broken down into three levels (operating system and drivers’ layer, data handling service layer, and the application layer). Highest impact on system is likely the embedded code at the BIOS, kernel/firmware level. Attacking the on-board operating systems. Since it manages all the programs and applications on the computer, it has a critical role in the overall security of the system. Since threats may occur deliberately or due to human error, malicious programs or persons, or existing system vulnerability mitigations must be deployed to protect the OS.
SV-AV-5		Using fault management system against you. Understanding the fault response could be leveraged to get satellite in vulnerable state. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of TLM to cause action from ground, or some sort of RPO to cause S/C to go into safe mode;
SV-AV-6		Complete compromise or corruption of running state
SV-DCO-1		Not knowing that you were attacked, or attack was attempted
SV-MA-5		Not being able to recover from cyberattack
SV-AC-1		Attempting access to an access-controlled system resulting in unauthorized access
SV-AC-2		Replay of recorded authentic communications traffic at a later time with the hope that the authorized communications will provide data or some other system reaction
SV-CF-1		Tapping of communications links (wireline, RF, network) resulting in loss of confidentiality; Traffic analysis to determine which entities are communicating with each other without being able to read the communicated information
SV-CF-4		Adversary monitors for safe-mode indicators such that they know when satellite is in weakened state and then they launch attack
SV-IT-1		Communications system spoofing resulting in denial of service and loss of availability and data integrity
SV-AC-7		Weak communication protocols. Ones that don't have strong encryption within it
SV-AV-1		Communications system jamming resulting in denial of service and loss of availability and data integrity
SV-MA-7		Exploit ground system and use to maliciously to interact with the spacecraft
SV-AC-4		Masquerading as an authorized entity in order to gain access/Insider Threat
SV-AV-7		The TT&C is the lead contributor to satellite failure over the first 10 years on-orbit, around 20% of the time. The failures due to gyro are around 12% between year one and 6 on-orbit and then ramp up starting around year six and overtake the contributions of the TT&C subsystem to satellite failure. Need to ensure equipment is not counterfeit and the supply chain is sound.
SV-CF-3		Knowledge of target satellite's cyber-related design details would be crucial to inform potential attacker - so threat is leaking of design data which is often stored Unclass or on contractors’ network
SV-MA-1		Space debris colliding with the spacecraft
SV-MA-4		Not knowing what your crown jewels are and how to protect them now and in the future.
SV-MA-6		Not planning for security on SV or designing in security from the beginning
SV-SP-10		Compromise development environment source code (applicable to development environments not covered by threat SV-SP-1, SV-SP-3, and SV-SP-4).
SV-SP-2		Testing only focuses on functional requirements and rarely considers end to end or abuse cases
SV-SP-4		General supply chain interruption or manipulation
SV-SP-5		Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused}

Sample Requirements

Requirement	Rationale/Additional Guidance/Notes
The [organization] shall identify the applicable physical and environmental protection policies covering the development environment and spacecraft hardware. {PE-1,PE-14,SA-3,SA-3(1),SA-10(3)}
The [organization] shall analyze changes to the spacecraft to determine potential security impacts prior to change implementation.{CM-4,CM-3,CM-3(2),CM-3(7),CM-4(2),SA-10}
The [organization] risk assessment shall include the full end to end communication pathway (i.e., round trip) to include any crosslink communications.{SV-MA-4}{AC-20,AC-20(1),AC-20(3),RA-3,SA-8(18)}
The [organization] shall develop and document program-specific identification and authentication policies for accessing the development environment and spacecraft. {AC-3,AC-14,IA-1,SA-3,SA-3(1)}
The [organization] shall protect documentation and Controlled Unclassified Information (CUI) as required, in accordance with the risk management strategy.{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-10,SC-8(1),SC-28(3),SI-12}
The [organization] shall identify and properly classify mission sensitive design/operations information and access control shall be applied in accordance with classification guides and applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-CF-3,SV-AV-5}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-8(19),SC-8(1),SC-28(3),SI-12}	* Mission sensitive information should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally these artifacts would be rated SECRET or higher and stored on classified networks. Mission sensitive information can typically include a wide range of candidate material: the functional and performance specifications, the RF ICDs, 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, SBU, 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.
The [organization] shall ensure security requirements/configurations are placed in accordance with NIST 800-171 with enhancements in 800-172 on the development environments to prevent the compromise of source code from supply chain or information leakage perspective.{AC-3,SA-3,SA-3(1),SA-15}
The [organization] shall ensure that role-based security-related training is provided to personnel with assigned security roles and responsibilities: (i) before authorizing access to the system or performing assigned duties; (ii) when required by system changes; and (iii) at least annually thereafter.{AT-3,CP-2}
The [organization] shall employ independent third-party analysis and penetration testing of all software (COTS, FOSS, Custom) associated with the system, system components, or system services.{CA-2,CA-2(1),CA-8(1),CM-10(1),SA-9,SA-11(3),SA-12(11),SI-3,SI-3(10),SR-4(4),SR-6(1)}
In coordination with [organization], the [organization] shall prioritize and remediate flaws identified during security testing/evaluation.{CA-2,CA-5,SA-11,SI-3,SI-3(10)}
The [organization] shall implement a verifiable flaw remediation process into the developmental and operational configuration management process.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-5,SA-3,SA-3(1),SA-11,SI-3,SI-3(10)}	The verifiable process should also include a cross reference to mission objectives and impact statements. Understanding the flaws discovered and how they correlate to mission objectives will aid in prioritization.
The [organization] shall maintain evidence of the execution of the security assessment plan and the results of the security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11}
The [organization] shall create and implement a security assessment plan that includes: (1) The types of analyses, testing, evaluation, and reviews of all software and firmware components; (2) The degree of rigor to be applied to include abuse cases and/or penetration testing; and (3) The types of artifacts produced during those processes.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11,SA-11(5)}	The security assessment plan should include evaluation of mission objectives in relation to the security of the mission. Assessments should not only be control based but also functional based to ensure mission is resilient against failures of controls.
The [organization] shall establish robust procedures and technical methods to perform testing to include adversarial testing (i.e.abuse cases) of the platform hardware and software.{CA-8,CP-4(5),RA-5,RA-5(1),RA-5(2),SA-3,SA-4(3),SA-11,SA-11(1),SA-11(2),SA-11(5),SA-11(7),SA-11(8),SA-15(7)}
The [organization] shall distribute documentation to only personnel with defined roles and a need to know.{SV-CF-3,SV-AV-5}{CM-12,CP-2,SA-5,SA-10}	Least privilege and need to know should be employed with the protection of all documentation. Documentation can contain sensitive information that can aid in vulnerability discovery, detection, and exploitation. For example, command dictionaries for ground and space systems should be handles with extreme care. Additionally, design documents for missions contain many key elements that if compromised could aid in an attacker successfully exploiting the system.
The [organization] shall develop, document, and maintain under configuration control, a current baseline configuration of the spacecrafts.{CM-2,CM-3(7),CM-4(2),CM-6,SA-8(30),SA-10}
The [organization] shall define processes and procedures to be followed when integrity verification tools detect unauthorized changes to software, firmware, and information.{SV-IT-2}{CM-3,CM-3(1),CM-3(5),CM-5(6),CM-6,CP-2,IR-6,IR-6(2),PM-30,SC-16(1),SC-51,SI-3,SI-4(7),SI-4(24),SI-7,SI-7(7),SI-7(10)}
The [organization] shall maintain the integrity of the mapping between the master build data (hardware drawings and software/firmware code) describing the current version of hardware, software, and firmware and the on-site master copy of the data for the current version.{CM-6,SA-8(21),SA-8(30),SA-10,SA-10(3),SA-10(4),SA-10(5),SI-7(10),SR-4(4)}
The [organization] shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design.{SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4}{CP-2,CP-2(8),PL-7,PM-11,PM-30(1),RA-3(1),RA-9,SA-8(9),SA-8(11),SA-8(25),SA-12,SA-14,SA-15(3),SC-7(29),SR-1}	During SCRM, criticality analysis will aid in determining supply chain risk. For mission critical functions/components, extra scrutiny must be applied to ensure supply chain is secured.
The [organization] shall develop an incident response and forensics plan that covers the spacecrafts.{CP-2,IR-1,IR-3,IR-3(2),IR-4(12),IR-4(13),IR-8,SA-15(10),SI-4(24)}
The [organization] shall employ techniques to limit harm from potential adversaries identifying and targeting the [organization]s supply chain.{CP-2,PM-30,SA-9,SA-12(5),SC-38,SR-3,SR-3(1),SR-3(2),SR-5(2)}
The [organization] defines the security safeguards to be employed to protect the availability of system resources.{CP-2(2),SC-6,SI-13,SI-17}
The [organization] shall plan for the transfer of essential ground-segment functions to alternate processing/storage site(s) (e.g.secondary ground terminal) with minimal or no loss of operational continuity until the primary ground terminal is fully restored (if the architecture supports it).{CP-2(6)}
The [organization] shall plan for the transfer of essential space-segment functions to alternate processing platforms (e.g.proliferated/distributed constellations) with minimal or no loss of operational continuity until the primary node is fully restored (if the architecture supports it).{CP-2(6)}
The [organization] shall maintain 24/7 space situational awareness for potential collision with space debris that could come in contact with the spacecraft.{SV-MA-1}{PE-20}
The [organization] shall develop policies and procedures to establish sufficient space domain awareness to avoid potential collisions or hostile proximity operations.This includes establishing relationships with relevant organizations needed for data sharing.{PE-6,PE-6(1),PE-6(4),PE-18,PE-20,RA-6,SC-7(14)}
The [organization] shall monitor physical access to all facilities where the system or system components reside throughout development, integration, testing, and launch to detect and respond to physical security incidents in coordination with the organizational incident response capability.{PE-6,PE-6(1),PE-6(4),PE-18,PE-20,SC-7(14)}
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 define the secure communication protocols to be used within the mission in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{PL-7,RA-5(4),SA-4(9),SA-8(18),SA-8(19),SC-8(1),SC-16(3),SC-40(4),SI-12}
The [organization] shall document the platform's security architecture, and how it is established within and is an integrated part of the overall [organization] mission security architecture.{PL-7,SA-8(7),SA-8(13),SA-8(29),SA-8(30),SA-17}
The [organization] shall use all-source intelligence analysis on threats to mission critical capabilities and/or system components to inform risk management decisions.{SV-MA-4}{PM-16,RA-3(2),RA-3(3),RA-7,RA-9,SA-12(8),SA-15(8)}
The [organization] shall conduct an assessment of risk prior to each milestone review [SRR\PDR\CDR], including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the platform and the information it processes, stores, or transmits.{SV-MA-4}{RA-2,RA-3,SA-8(25)}
The [organization] shall document risk assessment results in [risk assessment report].{SV-MA-4}{RA-3}
The [organization] shall review risk assessment results [At least annually if not otherwise defined in formal organizational policy].{SV-MA-4}{RA-3}
The [organization] shall update the risk assessment [At least annually if not otherwise defined in formal institutional policy] or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the spacecraft.{SV-MA-4}{RA-3}
The [organization] shall document risk assessment results in risk assessment report upon completion of each risk assessment.{RA-3,RA-7}
The [organization] shall use the threat and vulnerability analyses of the as-built system, system components, or system services to inform and direct subsequent testing/evaluation of the as-built system, component, or service.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-3(3),SA-11(2),SA-15(8),SI-3}
The [organization] shall perform static binary analysis of all firmware that is utilized on the spacecraft.{SV-SP-7,SV-SP-11}{RA-5,SA-10,SA-11,SI-7(10)}	Many commercial products/parts are utilized within the system and should be analyzed for security weaknesses. Blindly accepting the firmware is free of weakness is unacceptable for high assurance missions. The intent is to not blindly accept firmware from unknown sources and assume it is secure. This is meant to apply to firmware the vendors are not developing internally. In-house developed firmware should be going through the vendor's own testing program and have high assurance it is secure. When utilizing firmware from other sources, "expecting" does not meet this requirement. Each supplier needs to provide evidence to support that claim that their firmware they are getting is genuine and secure.
The [organization] shall correct flaws identified during security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11}	Flaws that impact the mission objectives should be prioritized.
The [organization] shall perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Program-defined depth and coverage].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11}	The depth needs to include functional testing as well as negative/abuse testing.
The [organization] shall use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SA-15(8)}
The [organization] shall perform and document threat and vulnerability analyses of the as-built system, system components, or system services.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SI-3}
The [organization] shall conduct an Attack Surface Analysis and reduce attack surfaces to a level that presents a low level of compromise by an attacker.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(6),SA-15(5)}
The [organization] shall require the developer to conduct an attack surface analysis on the spacecraft architecture to identify and reduce attack surfaces (e.g.entry points) to the lowest possible level that still permits the system to meet performance requirements/mission objectives.{SA-11(6),SA-15(5)}
The [organization] shall require the developer to 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.{SA-15(8)}
The [organization] shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)}	Select the particular subcontractors, software vendors, and manufacturers based on the criticality analysis performed for the Program Protection Plan and the criticality of the components that they supply.
For FPGA pre-silicon artifacts that are developed, coded, and tested by a developer that is not accredited, the [organization] shall be subjected to a development environment and pre-silicon artifacts risk assessment by [organization]. Based on the results of the risk assessment, the [organization] may need to implement protective measures or other processes to ensure the integrity of the FPGA pre-silicon artifacts.{SV-SP-5}{SA-3,SA-3(1),SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5}	DOD-I-5200.44 requires the following: 4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened).
The [organization] shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)}	Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc.
The [spacecraft] shall monitor security relevant telemetry points for malicious commanding attempts.{AC-17,AC-17(1),AC-17(10),AU-3(1),RA-10,SC-7,SC-16,SC-16(2),SC-16(3),SI-3(8),SI-4,SI-4(1),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}
The [spacecraft] shall enforce approved authorizations for controlling the flow of information within the platform and between interconnected systems so that information does not leave the platform boundary unless it is encrypted.{SV-AC-6}{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-3,CA-3(6),CA-3(7),CA-9,IA-9,SA-8(19),SC-8(1),SC-16(3)}
The [spacecraft] shall monitor and collect all onboard cyber-relevant data (from multiple system components), including identification of potential attacks and sufficient information about the attack for subsequent analysis.{SV-DCO-1}{AC-6(9),AC-20,AC-20(1),AU-2,AU-12,IR-4,IR-4(1),RA-10,SI-3,SI-3(10),SI-4,SI-4(1),SI-4(2),SI-4(7),SI-4(24)}	The spacecraft will monitor and collect data that provides accountability of activity occurring onboard the spacecraft. Due to resource limitations on the spacecraft, analysis must be performed to determine which data is critical for retention and which can be filtered. Full system coverage of data and actions is desired as an objective; it will likely be impractical due to the resource limitations. “Cyber-relevant data” refers to all data and actions deemed necessary to support accountability and awareness of onboard cyber activities for the mission. This would include data that may indicate abnormal activities, critical configuration parameters, transmissions on onboard networks, command logging, or other such data items. This set of data items should be identified early in the system requirements and design phase. Cyber-relevant data should support the ability to assess whether abnormal events are unintended anomalies or actual cyber threats. Actual cyber threats may rarely or never occur, but non-threat anomalies occur regularly. The ability to filter out cyber threats for non-cyber threats in relevant time would provide a needed capability. Examples could include successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels).
The [spacecraft] shall alert in the event of the audit/logging processing failures.{AU-5,AU-5(1),AU-5(2),SI-3,SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(24)}
The [spacecraft] shall provide an alert immediately to [at a minimum the mission director, administrators, and security officers] when the following failure events occur: [minimally but not limited to: auditing software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity reaching 95%, 99%, and 100%] of allocated capacity.{SV-DCO-1}{AU-5,AU-5(1),AU-5(2),SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(24),SI-7(7)}	Intent is to have human on the ground be alerted to failures. This can be decomposed to SV to generate telemetry and to Ground to alert.
The [spacecraft] shall provide the capability of a cyber “black-box” to capture necessary data for cyber forensics of threat signatures and anomaly resolution when cyber attacks are detected.{SV-DCO-1}{AU-5(5),AU-9(2),AU-9(3),AU-12,IR-4(12),IR-4(13),IR-5(1),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(7),SI-4(24),SI-7(7)}	Similar concept of a "black box" on an aircraft where all critical information is stored for post forensic analysis. Black box can be used to record CPU utilization, GNC physical parameters, audit records, memory contents, TT&C data points, etc. The timeframe is dependent upon implementation but needs to meet the intent of the requirement. For example, 30 days may suffice.
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 [spacecraft] shall enter a cyber-safe mode when conditions that threaten the platform are detected, enters a cyber-safe mode of operation with restrictions as defined based on the cyber-safe mode.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4,IR-4(1),IR-4(3),PE-10,RA-10,SA-8(16),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-13,SI-17}
The [spacecraft] shall provide the capability to enter the platform into a known good, operational cyber-safe mode from a tamper-resistant, configuration-controlled (“gold”) image that is authenticated as coming from an acceptable supplier, and has its integrity verified.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4(3),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-13,SI-17}	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 SW functions to preattack 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 available equipment still available after a cyberattack. The goal is for the vehicle to resume full mission operations. If not possible, a reduced level of mission capability should be achieved.
The [spacecraft] shall enter cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-17}
The [spacecraft] shall fail to a known secure state for failures during initialization, and aborts preserving information necessary to return to operations in failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(24),SC-24,SI-13,SI-17}
The [spacecraft] shall fail securely to a secondary device in the event of an operational failure of a primary boundary protection device (i.e., crypto solution).{SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2}{CP-13,SA-8(19),SA-8(24),SC-7(18),SI-13,SI-13(4)}
The [organization] shall define the security safeguards that are to be automatically employed when integrity violations are discovered.{SV-IT-2}{CP-2,SA-8(21),SI-3,SI-4(7),SI-4(12),SI-7(5),SI-7(8)}
The [organization] shall define the resources to be allocated to protect the availability of system resources.{SV-AC-6}{CP-2(2),SC-6}
The [spacecraft] shall recover from cyber-safe mode to mission operations within 20 minutes.{SV-MA-5}{CP-2(3),CP-2(5),IR-4,SA-8(24)}	Upon conclusion of addressing the threat, the system should be capable of recovering from the minimal survival mode back into a mission-ready state within defined timelines. The intent is to define the timelines and the capability to return back to mission operations.
The [spacecraft] shall provide or support the capability for recovery and reconstitution to a known state after a disruption, compromise, or failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-4(4),CP-10,CP-10(4),CP-10(6),CP-13,IR-4,IR-4(1),SA-8(16),SA-8(19),SA-8(24)}
The [spacecraft] shall have multiple uplink paths {SV-AV-1}{CP-8,CP-11,SA-8(18),SC-5,SC-47}
The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with CNSSP 12 and applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{IA-7,SC-8(1),SC-13,SI-12}
The [spacecraft] shall be able to locate the onboard origin of a cyber attack and alert ground operators within 3 minutes.{SV-DCO-1}{IR-4,IR-4(1),IR-4(12),IR-4(13),RA-10,SA-8(22),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(16),SI-4(24)}	The origin of any attack onboard the vehicle should be identifiable to support mitigation. At the very least, attacks from critical element (safety-critical or higher-attack surface) components should be locatable quickly so that timely action can occur.
The [spacecraft] shall detect and deny unauthorized outgoing communications posing a threat to the spacecraft.{SV-DCO-1}{IR-4,IR-4(1),RA-5(4),RA-10,SC-7(9),SC-7(10),SI-4,SI-4(1),SI-4(4),SI-4(7),SI-4(11),SI-4(13),SI-4(24),SI-4(25)}
The [spacecraft] shall provide cyber threat status to the ground segment for the Defensive Cyber Operations team, per the governing specification.{SV-DCO-1}{IR-5,PM-16,PM-16(1),RA-3(3),RA-10,SI-4,SI-4(1),SI-4(24),SI-7(7)}	The future space enterprises will include full-time Cyber Defense teams supporting space mission systems. Their work is currently focused on the ground segment but may eventually require specific data from the space segment for their successful operation. This requirement is a placeholder to ensure that any DCO-related requirements are taken into consideration for this document.
The [spacecraft] shall be constructed with sufficient electromagnetic shielding to protect electronic components from damage to the degree deemed acceptable by the Program.{PE-9,PE-14,PE-18,PE-21}
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)}
The [spacecraft] shall be designed and configured so that encrypted communications traffic and data is visible to on-board security monitoring tools.{SV-DCO-1}{RA-10,SA-8(21),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(10),SI-4(13),SI-4(24),SI-4(25)}
The [spacecraft] shall be designed and configured so that spacecraft memory can be monitored by the on-board intrusion detection/prevention capability.{SV-DCO-1}{RA-10,SA-8(21),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(24),SI-16}
The [spacecraft] shall have on-board intrusion detection/prevention system that monitors the mission critical components or systems.{SV-AC-1,SV-AC-2,SV-MA-4}{RA-10,SC-7,SI-3,SI-3(8),SI-4,SI-4(1),SI-4(7),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}	The mission critical components or systems could be GNC/Attitude Control, C&DH, TT&C, Fault Management.
The [organization] shall define acceptable secure communication protocols available for use within the mission in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-AC-7}{SA-4(9)}	The secure communication protocol should include "strong" authenticated encryption characteristics.
The [spacecraft] shall only use [organization]-defined communication protocols within the mission.{SV-AC-7}{SA-4(9)}
The [spacecraft] shall only use communication protocols that support encryption within the mission.{SA-4(9),SA-8(18),SA-8(19),SC-40(4)}