Encrypted encapsulation of routable network traffic.
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
| CM0002 | COMSEC | A component of cybersecurity to deny unauthorized persons information derived from telecommunications and to ensure the authenticity of such telecommunications. COMSEC includes cryptographic security, transmission security, emissions security, and physical security of COMSEC material. It is imperative to utilize secure communication protocols with strong cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission. Systems should also maintain the confidentiality and integrity of information during preparation for transmission and during reception. Spacecraft should not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). The cryptographic mechanisms should identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters. | AC-17 AC-17(1) AC-17(10) AC-17(2) AC-18 AC-18(1) AC-2(11) AC-3(10) CA-3 IA-4(9) IA-5 IA-5(7) IA-7 PL-8 PL-8(1) SA-8(18) SA-8(19) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SC-8(1) SC-8(3) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8) | D3-ET D3-MH D3-MAN D3-MENCR D3-NTF D3-ITF D3-OTF D3-CH D3-DTP D3-NTA D3-CAA D3-DNSTA D3-IPCTA D3-NTCD D3-RTSD D3-PHDURA D3-PMAD D3-CSPP D3-MA D3-SMRA D3-SRA | A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.16 A.5.17 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.12 A.5.33 A.8.20 A.8.24 A.8.24 A.8.26 A.5.31 A.5.33 A.8.11 | |
| CM0050 | On-board Message Encryption | In addition to authentication on-board the spacecraft bus, encryption is also recommended to protect the confidentiality of the data traversing the bus. | AC-4 AC-4(23) AC-4(24) AC-4(26) AC-4(31) AC-4(32) PL-8 PL-8(1) SA-3 SA-8 SA-8(18) SA-8(19) SA-8(9) SA-9(6) SC-13 SC-16 SC-16(1) SC-16(2) SC-16(3) SC-8(1) SC-8(3) SI-19(4) SI-4(10) SI-4(25) | D3-MH D3-MENCR D3-ET | A.5.14 A.8.22 A.8.23 A.8.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24 A.8.26 A.5.31 A.8.11 | |
| ID | Name | Description | |
|---|---|---|---|
| REC-0003 | Gather Spacecraft Communications Information | Threat actors may obtain information on the victim spacecraft's communication channels in order to determine specific commands, protocols, and types. Information gathered can include commanding patterns, antenna shape and location, beacon frequency and polarization, and various transponder information. | |
| REC-0003.04 | Valid Credentials | Threat actors may seek out valid credentials which can be utilized to facilitate several tactics throughout an attack. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms. | |
| REC-0005 | Eavesdropping | Threat actors may seek to capture network communications throughout the ground station and radio frequency (RF) communication used for uplink and downlink communications. RF communication frequencies vary between 30MHz and 60 GHz. Threat actors may capture RF communications using specialized hardware, such as software defined radio (SDR), handheld radio, or a computer with radio demodulator turned to the communication frequency. Network communications may be captured using packet capture software while the threat actor is on the target network. | |
| REC-0005.01 | Uplink Intercept Eavesdropping | Threat actors may capture the RF communications as it pertains to the uplink to the victim spacecraft. This information can contain commanding information that the threat actor can use to perform other attacks against the victim spacecraft. | |
| REC-0005.02 | Downlink Intercept | Threat actors may capture the RF communications as it pertains to the downlink of the victim spacecraft. This information can contain important telemetry such as onboard status and mission data. | |
| REC-0005.03 | Proximity Operations | Threat actors may capture signals and/or network communications as they travel on-board the vehicle (i.e., EMSEC/TEMPEST), via RF, or terrestrial networks. This information can be decoded to determine commanding and telemetry protocols, command times, and other information that could be used for future attacks. | |
| REC-0005.04 | Active Scanning (RF/Optical) | Threat actors may interfere with the link by actively transmitting packets to activate the transmitter and induce a reply. The scan can be similar to a brute force attack, aiming to guess the used frequencies and protocols to obtain a reply. | |
| IA-0003 | Crosslink via Compromised Neighbor | Threat actors may compromise a victim spacecraft via the crosslink communications of a neighboring spacecraft that has been compromised. spacecraft in close proximity are able to send commands back and forth. Threat actors may be able to leverage this access to compromise other spacecraft once they have access to another that is nearby. | |
| IA-0005 | Rendezvous & Proximity Operations | Threat actors may perform a space rendezvous which is a set of orbital maneuvers during which a spacecraft arrives at the same orbit and approach to a very close distance (e.g. within visual contact or close proximity) to a target spacecraft. | |
| IA-0005.01 | Compromise Emanations | Threat actors in close proximity may intercept and analyze electromagnetic radiation emanating from crypto equipment and/or the target spacecraft(i.e., main bus) to determine whether the emanations are information bearing. The data could be used to establish initial access. | |
| IA-0005.02 | Docked Vehicle / OSAM | Threat actors may leverage docking vehicles to laterally move into a target spacecraft. If information is known on docking plans, a threat actor may target vehicles on the ground or in space to deploy malware to laterally move or execute malware on the target spacecraft via the docking interface. | |
| IA-0005.03 | Proximity Grappling | Threat actors may posses the capability to grapple target spacecraft once it has established the appropriate space rendezvous. If from a proximity / rendezvous perspective a threat actor has the ability to connect via docking interface or expose testing (i.e., JTAG port) once it has grappled the target spacecraft, they could perform various attacks depending on the access enabled via the physical connection. | |
| IA-0007 | Compromise Ground System | Threat actors may initially compromise the ground system in order to access the target spacecraft. Once compromised, the threat actor can perform a multitude of initial access techniques, including replay, compromising FSW deployment, compromising encryption keys, and compromising authentication schemes. Threat actors may also perform further reconnaissance within the system to enumerate mission networks and gather information related to ground station logical topology, missions ran out of said ground station, birds that are in-band of targeted ground stations, and other mission system capabilities. | |
| IA-0007.02 | Malicious Commanding via Valid GS | Threat actors may compromise target owned ground systems components (e.g., front end processors, command and control software, etc.) that can be used for future campaigns or to perpetuate other techniques. These ground systems components have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration. | |
| IA-0008 | Rogue External Entity | Threat actors may gain access to a victim spacecraft through the use of a rogue external entity. With this technique, the threat actor does not need access to a legitimate ground station or communication site. | |
| IA-0008.01 | Rogue Ground Station | Threat actors may gain access to a victim spacecraft through the use of a rogue ground system. With this technique, the threat actor does not need access to a legitimate ground station or communication site. | |
| IA-0008.02 | Rogue Spacecraft | Threat actors may gain access to a target spacecraft using their own spacecraft that has the capability to maneuver within close proximity to a target spacecraft to carry out a variety of TTPs (i.e., eavesdropping, side-channel, etc.). Since many of the commercial and military assets in space are tracked, and that information is publicly available, attackers can identify the location of space assets to infer the best positioning for intersecting orbits. Proximity operations support avoidance of the larger attenuation that would otherwise affect the signal when propagating long distances, or environmental circumstances that may present interference. | |
| IA-0010 | Unauthorized Access During Safe-Mode | Threat actors may target a spacecraft in safe mode to establish initial access, taking advantage of reduced authentication, relaxed command filtering, or backup control pathways. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. Since safe mode often prioritizes availability and fault recovery over security, it may process commands that would otherwise be rejected in nominal operations. This condition can provide an entry point into mission operations if improperly protected. | |
| EX-0001 | Replay | Replay attacks involve threat actors recording previously recorded data streams and then resending them at a later time. This attack can be used to fingerprint systems, gain elevated privileges, or even cause a denial of service. | |
| EX-0001.01 | Command Packets | Threat actors may interact with the victim spacecraft by replaying captured commands to the spacecraft. While not necessarily malicious in nature, replayed commands can be used to overload the target spacecraft and cause it's onboard systems to crash, perform a DoS attack, or monitor various responses by the spacecraft. If critical commands are captured and replayed, thruster fires, then the impact could impact the spacecraft's attitude control/orbit. | |
| EX-0003 | Modify Authentication Process | Threat actors may modify the internal authentication process of the victim spacecraft to facilitate initial access, recurring execution, or prevent authorized entities from accessing the spacecraft. This can be done through the modification of the software binaries or memory manipulation techniques. | |
| EX-0006 | Disable/Bypass Encryption | Threat actors may perform specific techniques in order to bypass or disable the encryption mechanism onboard the victim spacecraft. By bypassing or disabling this particular mechanism, further tactics can be performed, such as Exfiltration, that may have not been possible with the internal encryption process in place. | |
| EX-0011 | Exploit Reduced Protections During Safe-Mode | Threat actors who have access to a spacecraft in safe mode may issue malicious commands that would not normally be accepted during nominal operations. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. Because safe mode prioritizes essential functions and often disables non-critical protections or filters, adversaries can exploit this state to trigger unauthorized reconfiguration, software modification, or system manipulation during recovery or degraded operation. | |
| 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.02 | Bus Traffic Spoofing | Threat actors may attempt to target the main or secondary bus onboard the victim spacecraft and spoof their data. The spacecraft bus often directly processes and sends messages from the ground controllers to the various subsystems within the spacecraft and between the subsystems themselves. If a threat actor would target this system and spoof it internally, the subsystems would take the spoofed information as legitimate and process it as normal. This could lead to undesired effects taking place that could damage the spacecraft's subsystems, hosted payload, and critical data. | |
| EX-0014.03 | Sensor Data | Threat actors may target sensor data on the 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. | |
| PER-0004 | Replace Cryptographic Keys | Threat actors may attempt to fully replace the cryptographic keys on the spacecraft which could lockout the mission operators and enable the threat actor's communication channel. Once the encryption key is changed on the spacecraft, the spacecraft is rendered inoperable from the operators perspective as they have lost commanding access. Threat actors may exploit weaknesses in the key management strategy. For example, the threat actor may exploit the over-the-air rekeying procedures to inject their own cryptographic keys. | |
| PER-0005 | Credentialed Persistence | Threat actors may acquire or leverage valid credentials to maintain persistent access to a spacecraft or its supporting command and control (C2) systems. These credentials may include system service accounts, user accounts, maintenance access credentials, cryptographic keys, or other authentication mechanisms that enable continued entry without triggering access alarms. By operating with legitimate credentials, adversaries can sustain access over extended periods, evade detection, and facilitate follow-on tactics such as command execution, data exfiltration, or lateral movement. Credentialed persistence is particularly effective in environments lacking strong credential lifecycle management, segmentation, or monitoring allowing threat actors to exploit trusted pathways while remaining embedded in mission operations. | |
| 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.01 | Inhibit Ground System Functionality | Threat actors may utilize access to the ground system to inhibit its ability to accurately process, render, or interpret spacecraft telemetry, effectively leaving ground controllers unaware of the spacecraft’s true state or activity. This may involve traditional denial-based techniques, such as disabling telemetry software, corrupting processing pipelines, or crashing display interfaces. In addition, more subtle deception-based techniques may be used to falsify telemetry data within the ground system — such as modifying command counters, acknowledgments, housekeeping data, or sensor outputs — to provide the appearance of nominal operation. These actions can suppress alerts, mask unauthorized activity, or prevent both automated and manual mitigations from being initiated based on misleading ground-side information. Because telemetry is the primary method by which ground controllers monitor the health, behavior, and safety of the spacecraft, any disruption or falsification of this data directly undermines situational awareness and operational control. | |
| DE-0002.02 | Jam Link Signal | Threat actors may overwhelm/jam the downlink signal to prevent transmitted telemetry signals from reaching their destination without severe modification/interference, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place. | |
| DE-0004 | Masquerading | Threat actors may gain access to a victim spacecraft by masquerading as an authorized entity. This can be done several ways, including through the manipulation of command headers, spoofing locations, or even leveraging Insider's access (i.e., Insider Threat) | |
| DE-0005 | Subvert Protections via Safe-Mode | Threat actors may exploit safe mode to evade security controls and avoid detection by issuing commands or performing actions that would be blocked during nominal operations. In safe mode, spacecraft often disable telemetry filtering, authentication checks, or command restrictions to prioritize recovery, which can be subverted by an attacker to conceal malicious activity or establish a persistent foothold. | |
| LM-0002 | Exploit Lack of Bus Segregation | Threat actors may exploit victim spacecraft on-board flat architecture for lateral movement purposes. Depending on implementation decisions, spacecraft can have a completely flat architecture where remote terminals, sub-systems, payloads, etc. can all communicate on the same main bus without any segmentation, authentication, etc. Threat actors can leverage this poor design to send specially crafted data from one compromised devices or sub-system. This could enable the threat actor to laterally move to another area of the spacecraft or escalate privileges (i.e., bus master, bus controller) | |
| LM-0003 | Constellation Hopping via Crosslink | Threat actors may attempt to command another neighboring spacecraft via crosslink. spacecraft in close proximity are often able to send commands back and forth. Threat actors may be able to leverage this access to compromise another spacecraft. | |
| LM-0004 | Visiting Vehicle Interface(s) | Threat actors may move from one spacecraft to another through visiting vehicle interfaces. When a vehicle docks with a spacecraft, many programs are automatically triggered in order to ensure docking mechanisms are locked. This entails several data points and commands being sent to and from the spacecraft and the visiting vehicle. If a threat actor were to compromise a visiting vehicle, they could target these specific programs in order to send malicious commands to the victim spacecraft once docked. | |
| LM-0007 | Credentialed Traversal | Threat actors may leverage valid credentials to traverse across spacecraft subsystems, communication buses, or even to access other spacecraft within a constellation, all while avoiding detection. These credentials may include system service accounts, user accounts, maintenance credentials, cryptographic keys, or other authentication mechanisms that grant authorized access. Rather than exploiting vulnerabilities, this technique relies on the reuse or misuse of trusted credentials to move laterally within the space system architecture. When access control boundaries are weak, flat, or poorly enforced, valid credentials can enable attackers to reach restricted functions or domains without raising alarms. This traversal allows evasion of isolation mechanisms and facilitates further actions without triggering traditional anomaly detection tied to unauthorized access attempts. | |
| EXF-0001 | Replay | Threat actors may exfiltrate data by replaying commands and capturing the telemetry or payload data as it is sent down. One scenario would be the threat actor replays commands to downlink payload data once the spacecraft is within certain location so the data can be intercepted on the downlink by threat actor ground terminals. | |
| EXF-0002 | Side-Channel Exfiltration | Threat actors may use a side-channel attack attempts to gather information by measuring or exploiting indirect effects of the spacecraft. Information within the spacecraft can be extracted through these side-channels in which sensor data is analyzed in non-trivial ways to recover subtle, hidden or unexpected information. A series of measurements of a side-channel constitute an identifiable signature which can then be matched against a signature database to identify target information, without having to explicitly decode the side-channel. | |
| EXF-0002.02 | Electromagnetic Leakage Attacks | Threat actors can leverage electromagnetic emanations to obtain sensitive information. The electromagnetic radiations attain importance when they are hardware generated emissions, especially emissions from the cryptographic module. Electromagnetic leakage attacks have been shown to be more successful than power analysis attacks on chicards. If proper protections are not in place on the spacecraft, the circuitry is exposed and hence leads to stronger emanations of EM radiations. If the circuitry is exposed, it provides an easier environment to study the electromagnetic emanations from each individual component. | |
| EXF-0002.03 | Traffic Analysis Attacks | In a terrestrial environment, threat actors use traffic analysis attacks to analyze traffic flow to gather topological information. This traffic flow can divulge information about critical nodes, such as the aggregator node in a sensor network. In the space environment, specifically with relays and constellations, traffic analysis can be used to understand the energy capacity of spacecraft node and the fact that the transceiver component of a spacecraft node consumes the most power. The spacecraft nodes in a constellation network limit the use of the transceiver to transmit or receive information either at a regulated time interval or only when an event has been detected. This generally results in an architecture comprising some aggregator spacecraft nodes within a constellation network. These spacecraft aggregator nodes are the sensor nodes whose primary purpose is to relay transmissions from nodes toward the ground station in an efficient manner, instead of monitoring events like a normal node. The added functionality of acting as a hub for information gathering and preprocessing before relaying makes aggregator nodes an attractive target to side channel attacks. A possible side channel attack could be as simple as monitoring the occurrences and duration of computing activities at an aggregator node. If a node is frequently in active states (instead of idle states), there is high probability that the node is an aggregator node and also there is a high probability that the communication with the node is valid. Such leakage of information is highly undesirable because the leaked information could be strategically used by threat actors in the accumulation phase of an attack. | |
| EXF-0002.04 | Timing Attacks | Threat actors can leverage timing attacks to exfiltrate information due to variances in the execution timing for different sub-systems in the spacecraft (i.e., cryptosystem). In spacecraft, due to the utilization of processors with lower processing powers (i.e. slow), this becomes all the more important because slower processors will enhance even small difference in computation time. Every operation in a spacecraft takes time to execute, and the time can differ based on the input; with precise measurements of the time for each operation, a threat actor can work backwards to the input. Finding secrets through timing information may be significantly easier than using cryptanalysis of known plaintext, ciphertext pairs. Sometimes timing information is combined with cryptanalysis to increase the rate of information leakage. | |
| EXF-0003 | Signal Interception | Threat actors may seek to capture network communications throughout the ground station and communication channel (i.e. radio frequency, optical) used for uplink and downlink communications | |
| EXF-0003.01 | Uplink Exfiltration | Threat actors may target the uplink connection from the victim ground infrastructure to the target spacecraft in order to exfiltrate commanding data. Depending on the implementation (i.e., encryption) the captured uplink data can be used to further other attacks like command link intrusion, replay, etc. | |
| EXF-0003.02 | Downlink Exfiltration | Threat actors may target the downlink connection from the victim spacecraft in order to exfiltrate telemetry or payload data. This data can include health information of the spacecraft or mission data that is being collected/analyzed on the spacecraft. Downlinked data can even include mirrored command sessions which can be used for future campaigns or to help perpetuate other techniques. | |
| EXF-0004 | Out-of-Band Communications Link | Threat actors may attempt to exfiltrate data via the out-of-band communication channels. While performing eavesdropping on the primary/second uplinks and downlinks is a method for exfiltration, some spacecrafts leverage out-of-band communication links to perform actions on the spacecraft (i.e., re-keying). These out-of-band links would occur on completely different channels/frequencies and often operate on separate hardware on the spacecraft. Typically these out-of-band links have limited built-for-purpose functionality and likely do not present an initial access vector but they do provide ample exfiltration opportunity. | |
| EXF-0005 | Proximity Operations | Threat actors may leverage the lack of emission security or tempest controls to exfiltrate information using a visiting spacecraft. This is similar to side-channel attacks but leveraging a visiting spacecraft to measure the signals for decoding purposes. | |
| EXF-0010 | Payload Communication Channel | Threat actors can deploy malicious software on the payload(s) which can send data through the payload channel. Payloads often have their own communication channels outside of the main TT&C pathway which presents an opportunity for exfiltration of payload data or other spacecraft data depending on the interface and data exchange. | |
| ID | Description | |
| SV-AC-3 |
Compromised master keys or any encryption key |
|
| SV-CF-2 |
Eavesdropping (RF and proximity) |
|
| SV-IT-2 |
Unauthorized modification or corruption of data |
|
| SV-MA-2 |
Heaters and flow valves of the propulsion subsystem are controlled by electric signals so cyberattacks against these signals could cause propellant lines to freeze, lock valves, waste propellant or even put in de-orbit or unstable spinning |
|
| SV-AV-4 |
Attacking the scheduling table to affect tasking |
|
| SV-IT-5 |
Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands |
|
| SV-MA-3 |
Attacks on critical software subsystems Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack. Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite. |
|
| SV-SP-1 |
Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the FSW. |
|
| SV-SP-3 |
Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, keylogger, rootkit, or Trojan Horse |
|
| SV-SP-6 |
Software reuse, COTS dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to supply chain threat |
|
| SV-SP-9 |
On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code |
|
| SV-AC-5 |
Proximity operations (i.e., grappling satellite) |
|
| SV-AC-6 |
Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective; |
|
| SV-AC-8 |
Malicious Use of hardware commands - backdoors / critical commands |
|
| SV-AV-2 |
Satellites base many operations on timing especially since many operations are automated. Cyberattack to disrupt timing/timers could affect the vehicle (Time Jamming / Time Spoofing) |
|
| SV-AV-3 |
Affect the watchdog timer onboard the satellite which could force satellite into some sort of recovery mode/protocol |
|
| SV-IT-3 |
Compromise boot memory |
|
| SV-IT-4 |
Cause bit flip on memory via single event upsets |
|
| SV-MA-8 |
Payload (or other component) is told to constantly sense or emit or run whatever mission it had to the point that it drained the battery constantly / operated in a loop at maximum power until the battery is depleted. |
|
| SV-SP-11 |
Software defined radios - SDR is also another computer, networked to other parts of the spacecraft that could be pivoted to by an attacker and infected with malicious code. Once access to an SDR is gained, the attacker could alter what the SDR thinks is correct frequencies and settings to communicate with the ground. |
|
| SV-SP-7 |
Software can be broken down into three levels (operating system and drivers’ layer, data handling service layer, and the application layer). Highest impact on system is likely the embedded code at the BIOS, kernel/firmware level. Attacking the on-board operating systems. Since it manages all the programs and applications on the computer, it has a critical role in the overall security of the system. Since threats may occur deliberately or due to human error, malicious programs or persons, or existing system vulnerability mitigations must be deployed to protect the OS. |
|
| SV-AV-5 |
Using fault management system against you. Understanding the fault response could be leveraged to get satellite in vulnerable state. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of TLM to cause action from ground, or some sort of RPO to cause S/C to go into safe mode; |
|
| SV-AV-6 |
Complete compromise or corruption of running state |
|
| SV-DCO-1 |
Not knowing that you were attacked, or attack was attempted |
|
| SV-MA-5 |
Not being able to recover from cyberattack |
|
| SV-AC-1 |
Attempting access to an access-controlled system resulting in unauthorized access |
|
| SV-AC-2 |
Replay of recorded authentic communications traffic at a later time with the hope that the authorized communications will provide data or some other system reaction |
|
| SV-CF-1 |
Tapping of communications links (wireline, RF, network) resulting in loss of confidentiality; Traffic analysis to determine which entities are communicating with each other without being able to read the communicated information |
|
| SV-CF-4 |
Adversary monitors for safe-mode indicators such that they know when satellite is in weakened state and then they launch attack |
|
| SV-IT-1 |
Communications system spoofing resulting in denial of service and loss of availability and data integrity |
|
| SV-AC-7 |
Weak communication protocols. Ones that don't have strong encryption within it |
|
| SV-AV-1 |
Communications system jamming resulting in denial of service and loss of availability and data integrity |
|
| SV-MA-7 |
Exploit ground system and use to maliciously to interact with the spacecraft |
|
| SV-AC-4 |
Masquerading as an authorized entity in order to gain access/Insider Threat |
|
| SV-AV-7 |
The TT&C is the lead contributor to satellite failure over the first 10 years on-orbit, around 20% of the time. The failures due to gyro are around 12% between year one and 6 on-orbit and then ramp up starting around year six and overtake the contributions of the TT&C subsystem to satellite failure. Need to ensure equipment is not counterfeit and the supply chain is sound. |
|
| SV-CF-3 |
Knowledge of target satellite's cyber-related design details would be crucial to inform potential attacker - so threat is leaking of design data which is often stored Unclass or on contractors’ network |
|
| SV-MA-4 |
Not knowing what your crown jewels are and how to protect them now and in the future. |
|
| SV-MA-6 |
Not planning for security on SV or designing in security from the beginning |
|
| SV-SP-10 |
Compromise development environment source code (applicable to development environments not covered by threat SV-SP-1, SV-SP-3, and SV-SP-4). |
|
| SV-SP-2 |
Testing only focuses on functional requirements and rarely considers end to end or abuse cases |
|
| SV-SP-4 |
General supply chain interruption or manipulation |
|
| SV-SP-5 |
Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused} |
|
| Requirement | 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] 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 identify the key system components or capabilities that require isolation through physical or logical means.{SV-AC-6}{AC-3,SC-3,SC-7(13),SC-28(3),SC-32,SC-32(1)} | Fault management and security management capabilities would be classified as mission critical and likely need separated. Additionally, capabilities like TT&C, C&DH, GNC might need separated as well. |
| 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 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 maintain a list of suppliers and potential suppliers used, and the products that they supply to include software.{SV-SP-3,SV-SP-4,SV-SP-11}{CM-10,PL-8(2),PM-30,SA-8(9),SA-8(11)} | Ideally you have diversification with suppliers |
| 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 develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including support tamper resistance and provide a level of protection against the introduction of malicious code or hardware.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CM-3(8),CM-7(9),PM-30,SA-8(9),SA-8(11),SA-9,SA-10(3),SA-19,SC-51,SR-4(3),SR-4(4),SR-5(2),SR-11} | |
| The [organization] prohibits the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code.{CM-7(8),CM-7(8),CM-10(1),SA-8(9),SA-8(11),SA-10(2),SI-3,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 define policy and procedures to ensure that the developed or delivered systems do not embed unencrypted static authenticators in applications, access scripts, configuration files, nor store unencrypted static authenticators on function keys.{SV-AC-1,SV-AC-3}{IA-5(7)} | |
| The [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 conduct a supplier review prior to entering into a contractual agreement with a sub [organization] to acquire systems, system components, or system services.{PM-30,PM-30(1),RA-3(1),SA-8(9),SA-8(11),SA-9,SA-12(2),SR-5(2),SR-6} | |
| The [organization] shall protect against supply chain threats to the system, system components, or system services by employing security safeguards as defined by NIST SP 800-161 Rev.1.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-30,RA-3(1),SA-8(9),SA-8(11),SA-12,SI-3,SR-1} | The chosen supply chain safeguards should demonstrably support a comprehensive, defense-in-breadth information security strategy. Safeguards should include protections for both hardware and software. Program should define their critical components (HW & SW) and identify the supply chain protections, approach/posture/process. |
| 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. |
| The [organization] shall ensure that all Electrical, Electronic, Electro-mechanical & Electro-optical (EEEE) and mechanical piece parts procured from the Original Component Manufacturer (OCM) or their authorized distribution network.{SA-8(9),SA-8(11),SA-12,SA-12(1),SC-16(1),SR-1,SR-5} | |
| The [organization] shall use a certified environment to develop, code and test executable software (firmware or bit-stream) that will be programmed into a one-time programmable FPGA or be programmed into non-volatile memory (NVRAM) that the FPGA executes.{SA-8(9),SA-8(11),SA-12,SA-12(1),SC-51,SI-7(10),SR-1,SR-5} | |
| The [organization] shall ensure that all ASICs designed, developed, manufactured, packaged, and tested by suppliers with a Defense Microelectronics Activity (DMEA) Trust accreditation.{spacecraft-SP-5} {SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5} | |
| The [organization] shall produce, control, and distribute asymmetric cryptographic keys (where applicable) using NSA Certified or Approved key management technology and processes per CNSSP 12.{SC-12(3)} | |
| The [organization] shall perform analysis of critical backdoor commands that could adversely affect mission success if used maliciously.{SI-10,SI-10(3)} | |
| The [organization] shall enable integrity verification of software and firmware components.{SV-IT-2}{CM-3(5),CM-5(6),CM-10(1),SA-8(9),SA-8(11),SA-8(21),SA-10(1),SI-3,SI-4(24),SI-7,SI-7(10),SI-7(12),SR-4(4)} | * 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. |
| 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. |
| Any EEEE or mechanical piece parts that cannot be procured from the OCM or their authorized distribution network shall be approved and the government program office notified to prevent and detect counterfeit and fraudulent parts and materials.{SV-SP-5}{SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5} | The Program, working with the contractors, shall identify which ASICs/FPGAs perform or execute an integral part of mission critical functions and if the supplier is accredited “Trusted” by DMEA. If the contractor is not accredited by DMEA, then the Program may apply various of the below ASIC/FPGA assurance requirements to the contractor, and the Program may need to perform a risk assessment of the contractor’s design environment. |
| For ASICs that are designed, developed, manufactured, packaged, or tested by a supplier that is not DMEA accredited, the ASIC development shall undergo a threat/vulnerability risk assessment. 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 ASIC.{SV-SP-5}{SA-8(9),SA-8(11),SA-8(21),SA-12,SA-12(1),SR-1,SR-4(4),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 [spacecraft] shall terminate the connection associated with a communications session at the end of the session or after 3 minutes of inactivity.{SV-AC-1}{AC-12,SA-8(18),SC-10,SC-23(1),SC-23(3),SI-14,SI-14(3)} | |
| 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 [organization] shall ensure reused TT&C software has adequate uniqueness for command decoders/dictionaries so that commands are received by only the intended satellite.{SV-SP-6}{AC-17(10),SC-16(3),SI-3(9)} | The goal is to eliminate risk that compromise of one command database does not affect a different one due to reuse. The intent is to ensure that one SV can not process the commands from another SV. Given the crypto setup with keys and VCC needing to match, this requirement may be inherently met as a result of using type-1 cryptography. The intent is not to recreate entire command dictionaries but have enough uniqueness in place that it prevents a SV from receiving a rogue command. As long as there is some uniqueness at the receiving end of the commands, that is adequate. |
| The [spacecraft] shall accept hazardous commands only when prerequisite checks are satisfied.{AC-17(4),SI-10,SI-10(6)} | |
| The [spacecraft] shall protect authenticator content from unauthorized disclosure and modification.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),IA-5,IA-5(6),RA-5(4),SA-8(18),SA-8(19),SC-28(3)} | |
| The [spacecraft] encryption key handling shall be handled outside of the onboard software and protected using cryptography.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(1),SC-28(3)} | |
| The [spacecraft] encryption keys shall be restricted so that the onboard software is not able to access the information for key readout.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(3)} | |
| The [spacecraft] encryption keys shall be restricted so that they cannot be read via any telecommands.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(3)} | |
| The [spacecraft] shall produce, control, and distribute symmetric cryptographic keys using NSA Certified or Approved key management technology and processes per CNSSP 12.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-9(6),SC-12,SC-12(1),SC-12(2),SC-12(3)} | |
| The [spacecraft] shall provide the capability to restrict command lock based on geographic location of ground stations.{SV-AC-1}{AC-2(11),IA-10,SI-4(13),SI-4(25)} | This could be performed using command lockout based upon when the spacecraft is over selected regions. This should be configurable so that when conflicts arise, the Program can update. The goal is so the spacecraft won't accept a command when the spacecraft determines it is in a certain region. |
| The [spacecraft] shall restrict the use of information inputs to spacecraft and designated ground stations as defined in the applicable ICDs.{SV-AC-1,SV-AC-2}{AC-20,SC-23,SI-10,SI-10(5),SI-10(6)} | |
| The [spacecraft] shall uniquely identify and authenticate the ground station and other spacecraft before establishing a remote connection.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(10),AC-20,IA-3,IA-4,SA-8(18),SI-3(9)} | |
| The [spacecraft] shall authenticate the ground station (and all commands) and other spacecraft before establishing remote connections using bidirectional authentication that is cryptographically based.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(2),AC-17(10),AC-18(1),AC-20,IA-3(1),IA-4,IA-4(9),IA-7,IA-9,SA-8(18),SA-8(19),SA-9(2),SC-7(11),SC-16(1),SC-16(2),SC-16(3),SC-23(3),SI-3(9)} | Authorization can include embedding opcodes in command strings, using trusted authentication protocols, identifying proper link characteristics such as emitter location, expected range of receive power, expected modulation, data rates, communication protocols, beamwidth, etc.; and tracking command counter increments against expected values. |
| The [spacecraft] shall implement cryptographic mechanisms to identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters.{SV-AV-1,SV-IT-1}{AC-3,AC-20,SA-8(19),SC-8(1),SC-23(3),SC-40(3),SI-4(13),SI-4(24),SI-4(25),SI-10(6)} | |
| The [spacecraft] shall implement relay and replay-resistant authentication mechanisms for establishing a remote connection.{SV-AC-1,SV-AC-2}{AC-3,IA-2(8),IA-2(9),SA-8(18),SC-8(1),SC-16(1),SC-16(2),SC-23(3),SC-40(4)} | |
| The [spacecraft] shall ensure that processes reusing a shared system resource (e.g., registers, main memory, secondary storage) do not have access to information (including encrypted representations of information) previously stored in that resource during a prior use by a process after formal release of that resource back to the system or reuse.{SV-AC-6}{AC-3,PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(19),SC-4,SI-3} | |
| The [spacecraft] shall protect the confidentiality and integrity of the following information using cryptography while it is at rest: [all information].{AC-3,SA-8(19),SC-28,SC-28(1),SI-7(6)} | * The intent as written is for all transmitted traffic to be protected. This includes internal to internal communications and especially outside of the boundary. |
| The [spacecraft] shall maintain the confidentiality and integrity of information during preparation for transmission and during reception.{SV-AC-7}{AC-3,SA-8(19),SC-8,SC-8(1),SC-8(2),SC-16,SC-16(1)} | * 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 ability to encrypt & authenticate communications when conditions require automated access control mechanisms be overridden (e.g.no crypto-bypass mode).{AC-3(10)} | |
| The [spacecraft] shall encrypt all telemetry on downlink regardless of operating mode to protect current state of spacecraft.{SV-CF-4}{AC-3(10),RA-5(4),SA-8(18),SA-8(19),SC-8,SC-8(1),SC-13} | |
| The [spacecraft] shall not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode).{SV-AC-1,SV-CF-1,SV-CF-2}{AC-3(10),SA-8(18),SA-8(19),SC-16(2),SC-16(3),SC-40(4)} | |
| The [spacecraft] shall require multi-factor authorization for all spacecraft [applications or operating systems] updates within the spacecraft.{SV-SP-9,SV-SP-11}{AC-3(2),CM-3(8),CM-5,PM-12,SA-8(8),SA-8(31),SA-10(2),SI-3(8),SI-7(12),SI-10(6)} | The intent is for multiple checks to be performed prior to executing these SV SW updates. One action is mere act of uploading the SW to the spacecraft. Another action could be check of digital signature (ideal but not explicitly required) or hash or CRC or a checksum. Crypto boxes provide another level of authentication for all commands, including SW updates but ideally there is another factor outside of crypto to protect against FSW updates. Multi-factor authorization could be the "two-man rule" where procedures are in place to prevent a successful attack by a single actor (note: development activities that are subsequently subject to review or verification activities may already require collaborating attackers such that a "two-man rule" is not appropriate). |
| The [spacecraft] 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.{AC-3(2),SI-3(8),SI-13} | |
| 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] security implementation shall ensure that information should not be allowed to flow between partitioned applications unless explicitly permitted by the system.{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-9,IA-9,SA-8(3),SA-8(18),SA-8(19),SC-2(2),SC-7(29),SC-16,SC-32} | |
| The [spacecraft] shall, when transferring information between different security domains, implements the following security policy filters that require fully enumerated formats that restrict data structure and content: connectors and semaphores implemented in the RTOS.{SV-AC-6}{AC-3(3),AC-3(4),AC-4(14),IA-9,SA-8(19),SC-16} | |
| The [spacecraft] shall implement boundary protections to separate bus, communications, and payload components supporting their respective functions.{SV-AC-6}{AC-3(3),AC-3(4),CA-9,SA-8(3),SA-8(14),SA-8(18),SA-8(19),SA-17(7),SC-2,SC-2(2),SC-7(13),SC-7(21),SC-7(29),SC-16(3),SC-32,SI-3,SI-4(13),SI-4(25)} | |
| The [spacecraft] shall isolate mission critical functionality from non-mission critical functionality by means of an isolation boundary (e.g.via partitions) that controls access to and protects the integrity of, the hardware, software, and firmware that provides that functionality.{SV-AC-6}{AC-3(3),AC-3(4),CA-9,SA-8(3),SA-8(19),SA-17(7),SC-2,SC-3,SC-3(4),SC-7(13),SC-7(29),SC-32,SC-32(1),SI-3,SI-7(10),SI-7(12)} | |
| The [spacecraft] data within partitioned applications shall not be read or modified by other applications/partitions.{SV-AC-6}{AC-3(3),AC-3(4),SA-8(19),SC-2(2),SC-4,SC-6,SC-32} | |
| The [spacecraft] shall prevent unauthorized access to system resources by employing an efficient capability based object model that supports both confinement and revocation of these capabilities when the platform security deems it necessary.{SV-AC-6}{AC-3(8),IA-4(9),PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(18),SA-8(19),SC-2(2),SC-4,SC-16,SC-32,SI-3} | |
| The [organization] shall state that information should not be allowed to flow between partitioned applications unless explicitly permitted by the Program's security policy.{SV-AC-6}{AC-4,AC-4(6)} | |
| The [spacecraft] shall use protected processing domains to enforce the policy that information does not leave the platform boundary unless it is encrypted as a basis for flow control decisions.{SV-AC-6}{AC-4(2),IA-9,SA-8(19),SC-8(1),SC-16(3)} | |
| The [spacecraft] shall define the security functions and security-relevant information for which the system must protect from unauthorized access.{AC-6(1),SA-8(19),SC-7(13),SC-16} | |
| The [spacecraft] shall integrate cyber related detection and responses with existing fault management capabilities to ensure tight integration between traditional fault management and cyber intrusion detection and prevention.{SV-DCO-1}{AU-6(4),IR-4,IR-4(1),RA-10,SA-8(21),SA-8(26),SC-3(4),SI-3,SI-3(10),SI-4(7),SI-4(13),SI-4(16),SI-4(24),SI-4(25),SI-7(7),SI-13} | The onboard IPS system should be integrated into the existing onboard spacecraft fault management system (FMS) because the FMS has its own fault detection and response system built in. SV corrective behavior is usually limited to automated fault responses and ground commanded recovery actions. Intrusion prevention and response methods will inform resilient cybersecurity design. These methods enable detected threat activity to trigger defensive responses and resilient SV recovery. |
| The [spacecraft] shall implement cryptographic mechanisms to protect the integrity of audit information and audit tools.{SV-DCO-1}{AU-9(3),RA-10,SC-8(1),SI-3,SI-3(10),SI-4(24)} | |
| All [spacecraft] commands which have unrecoverable consequence must have dual authentication prior to command execution.{AU-9(5),IA-3,IA-4,IA-10,PE-3,PM-12,SA-8(15),SA-8(21),SC-16(2),SC-16(3),SI-3(8),SI-3(9),SI-4(13),SI-4(25),SI-7(12),SI-10(6),SI-13} | |
| The [spacecraft] shall have a method to ensure the integrity of these commands and validate their authenticity before execution.{AU-9(5),IA-3,IA-4,IA-10,PE-3,PM-12,SA-8(15),SA-8(21),SC-16(2),SC-16(3),SI-3(8),SI-3(9),SI-4(13),SI-4(25),SI-7(12),SI-10(6),SI-13} | |
| 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 perform an integrity check of software, firmware, and information at startup or during security-relevant events. {CM-3(5),SA-8(9),SA-8(11),SA-8(21),SI-3,SI-7(1),SI-7(10),SI-7(12),SI-7(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 [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 utilize TRANSEC.{SV-AV-1}{CP-8,RA-5(4),SA-8(18),SA-8(19),SC-8(1),SC-8(4),SC-16,SC-16(1),SC-16(2),SC-16(3),SC-40(4)} | Transmission Security (TRANSEC) is used to ensure the availability of transmissions and limit intelligence collection from the transmissions. TRANSEC is secured through burst encoding, frequency hopping, or spread spectrum methods where the required pseudorandom sequence generation is controlled by a cryptographic algorithm and key. Such keys are known as transmission security keys (TSK). The objectives of transmission security are low probability of interception (LPI), low probability of detection (LPD), and antijam which means resistance to jamming (EPM or ECCM). |
| The [spacecraft] shall maintain the ability to establish communication with the spacecraft in the event of an anomaly to the primary receive path.{SV-AV-1,SV-IT-1}{CP-8,SA-8(18),SC-47} | Receiver communication can be established after an anomaly with such capabilities as multiple receive apertures, redundant paths within receivers, redundant receivers, omni apertures, fallback default command modes, and lower bit rates for contingency commanding, as examples |
| The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards: [NSA- certified or approved cryptography for protection of classified information, FIPS-validated cryptography for the provision of hashing].{SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2,SV-AC-3}{IA-7,SC-13} | |
| The [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 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 recover to a known cyber-safe state when an anomaly is detected.{IR-4,IR-4(1),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17} | |
| The [spacecraft] shall detect and recover from detected memory errors or transitions to a known cyber-safe state.{IR-4,IR-4(1),SA-8(16),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17} | |
| The [spacecraft] shall perform an orderly, controlled system shut-down to a known cyber-safe state upon receipt of a termination command or condition.{PE-11,PE-11(1),SA-8(16),SA-8(19),SA-8(24),SI-17} | |
| The [spacecraft] shall operate securely in off-nominal power conditions, including loss of power and spurious power transients.{PE-11,PE-11(1),SA-8(16),SA-8(19),SI-13,SI-17} | |
| The [spacecraft] shall protect system components, associated data communications, and communication buses in accordance with: (i) national emissions and TEMPEST policies and procedures, and (ii) the security category or sensitivity of the transmitted information.{SV-CF-2,SV-MA-2}{PE-14,PE-19,PE-19(1),RA-5(4),SA-8(18),SA-8(19),SC-8(1)} | The measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements. The concerns addressed by this control during operation are emanations leakage between multiple payloads within a single space platform, and between payloads and the bus. |
| The [spacecraft] shall be designed such that it protects itself from information leakage due to electromagnetic signals emanations.{SV-CF-2,SV-MA-2}{PE-19,PE-19(1),RA-5(4),SA-8(19)} | This requirement applies if system components are being designed to address EMSEC and the measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements. |
| 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 prevent unauthorized and unintended information transfer via shared system resources.{SV-AC-6}{PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(19),SC-2(2),SC-4} | |
| 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 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 [spacecraft] shall only use communication protocols that support encryption within the mission.{SA-4(9),SA-8(18),SA-8(19),SC-40(4)} | |
| The [spacecraft] shall maintain a separate execution domain for each executing process.{SV-AC-6}{SA-8(14),SA-8(19),SC-2(2),SC-7(21),SC-39,SI-3} | |
| The [spacecraft] flight software must not be able to tamper with the security policy or its enforcement mechanisms.{SV-AC-6}{SA-8(16),SA-8(19),SC-3,SC-7(13)} | |
| The [spacecraft] shall initialize the platform to a known safe state.{SA-8(19),SA-8(23),SA-8(24),SI-17} | |
| The [spacecraft] shall maintain the confidentiality and integrity of information during preparation for transmission and during reception in accordance with [organization] provided encryption matrix.{SA-8(19),SC-8,SC-8(1),SC-8(2),SC-8(3)} | * 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 implement cryptographic mechanisms that achieve adequate protection against the effects of intentional electromagnetic interference.{SV-AV-1,SV-IT-1}{SA-8(19),SC-8(1),SC-40,SC-40(1)} | |
| The [organization] shall use NIST Approved for symmetric key management for Unclassified systems; NSA Approved or stronger symmetric key management technology for Classified systems.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(2)} | FIPS-complaint technology used by the Program shall include (but is not limited to) cryptographic key generation algorithms or key distribution techniques that are either a) specified in a FIPS, or b) adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS. NSA-approved technology used for symmetric key management by the Program shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. |
| The [organization] shall use NSA approved key management technology and processes.NSA-approved technology used for asymmetric key management by The [organization] shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(3)} | |
| The [spacecraft] shall produce, control, and distribute asymmetric cryptographic keys using [organization]-defined asymmetric key management processes.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(3)} | In most cased the Program will leverage NSA-approved key management technology and processes. |
| The [spacecraft] shall discriminate between valid and invalid input into the software and rejects invalid input.{SC-16(2),SI-3(8),SI-10,SI-10(3),SI-10(6)} | |
| The [spacecraft] 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.{SC-16(2),SI-4(13),SI-4(25),SI-10,SI-10(6),SI-13} | |
| 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)} | * 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 monitor [Program defined telemetry points] for malicious commanding attempts.{SV-AC-1,SV-AC-2}{SC-7,AU-3(1),AC-17(1)} | Source from AEROSPACE REPORT NO. TOR-2019-02178 Vehicle Command Counter (VCC) - Counts received valid commands Rejected Command Counter - Counts received invalid commands Command Receiver On/Off Mode - Indicates times command receiver is accepting commands Command Receivers Received Signal Strength - Analog measure of the amount of received RF energy at the receive frequency Command Receiver Lock Modes - Indicates when command receiver has achieved lock on command signal Telemetry Downlink Modes - Indicates when the satellite’s telemetry was transmitting Cryptographic Modes - Indicates the operating modes of the various encrypted links Received Commands - Log of all commands received and executed by the satellite System Clock - Master onboard clock GPS Ephemeris - Indicates satellite location derived from GPS Signals |
| The [spacecraft] shall be configured to deny communications by default and only permit authorized communications based on approved exceptions.{SC-7(5)} | |
| The [spacecraft] shall implement cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission unless otherwise protected by alternative physical safeguards.{SV-AC-7}{SC-8(1),SI-7(6)} | |
| The [spacecraft] shall implement cryptographic mechanisms to protect message externals unless otherwise protected by alternative physical safeguards.{SV-AC-7}{SC-8(3)} | |
| The [spacecraft] software subsystems shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied.{SV-MA-3,SV-AV-7}{SI-10} | |
| The [spacecraft] software subsystems 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 [spacecraft] software subsystems shall perform prerequisite checks for the execution of hazardous commands.{SV-MA-3,SV-AV-7}{SI-10} | |
| The [organization] shall ensure that all viable commands are known to the mission and SV "owner.{SV-AC-8}{SI-10,SI-10(3)} | This is a concern for bus re-use. It is possible that the manufacturer left previously coded commands in their syntax rather than starting from a clean slate. This leaves potential backdoors and other functionality the mission does not know about. |
| The [organization] shall perform analysis of critical (backdoor) commands that could adversely affect mission success if used maliciously.{SV-AC-8}{SI-10,SI-10(3)} | Heritage and commercial products often have many residual operational (e.g., hardware commands) and test capabilities that are unidentified or unknown to the end user, perhaps because they were not expressly stated mission requirements. These would never be tested and their effects unknown, and hence, could be used maliciously. Test commands not needed for flight should be deleted from the flight database. |
| The [spacecraft] shall only use or include [organization]-defined critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted.{SV-AC-8}{SI-10,SI-10(3)} | The intent is protect against misuse of critical commands. On potential scenario is where you could use accounts with different privileges, could require an additional passphrase or require entry into a different state or append an additional footer to a critical command. There is room for design flexibility here that can still satisfy this requirement. |
| The [spacecraft] software subsystems 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 [spacecraft] software subsystems shall properly handle spurious input and missing data.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)} | |
| The [spacecraft] shall properly handle spurious input and missing data.{SI-10,SI-10(3),SI-10(6)} | |
| The [spacecraft] shall perform prerequisite checks for the execution of hazardous commands.{SI-10,SI-10(6),SI-13} | |
| The [spacecraft] software subsystems shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit or perform a hazardous action.{SV-MA-3,SV-AV-7}{SI-10(3)} | |
| The [spacecraft] shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit, or perform a hazardous action.{SI-10(3),SI-10(6),SI-13} | |
| The [spacecraft] mission/cyber critical commands shall 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 [spacecraft] shall provide at least one independent command for each operator-initiated action used to shutdown a function leading to or reducing the control of a hazard.{SI-10(5)} | |
| The [spacecraft] software subsystems shall provide at least one independent command for each operator-initiated action used to shut down a function leading to or reducing the control of a hazard.{SV-MA-3,SV-AV-7}{SI-10(5)} | |
| The [spacecraft] shall only use or include critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted.{SI-3(8),SI-10,SI-10(3)} |