1. Home
  2. Related Work
  3. Threats
  4. SV-DCO-1

SV-DCO-1

Not knowing that you were attacked, or attack was attempted


Informational References

  • TOR-2018-01164 - Space-Cyber Requirements for Future Systems
ID: SV-DCO-1
DiD Layer: IDS/IPS
CAPEC #:  20 | 97 | 117 | 158 | 620 | 621 | 622
Lowest Threat Tier to
Create Threat Event:  V
Notional Risk Rank Score: 

High-Level Requirements

One Liner: The spacecraft shall have intrusion detection, intrusion prevention, OR sufficient auditing/logging capability on-board the spacecraft that can alert and downlink onboard cyber information to the mission ground station within [mission-appropriate timelines minutes]. Broken Out: The spacecraft shall detect on-board intrusions. The spacecraft shall prevent on-board intrusions. The spacecraft shall audit and log on-board information assurance events. When the spacecraft has detected an intrusion on-board, the spacecraft shall send and alert and onboard cyber information to the mission ground station within [mission-appropriate timelines minutes]. When the spacecraft has prevented an intrusion on-board, the spacecraft shall send and alert and onboard cyber information to the mission ground station within [mission-appropriate timelines minutes].

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
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} {SI-4,SI-4(2),AU-2}
The spacecraft shall generate cyber-relevant audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, and the outcome of the event. {SV-DCO-1} {AU-3,AU-3(1)}
The spacecraft shall use internal system clocks to generate time stamps for audit records. {SV-DCO-1} {AU-8}
The spacecraft shall record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT). {SV-DCO-1} {AU-8}
The spacecraft shall record time stamps for audit records that provide a granularity of one Z-count (1.5 sec). {SV-DCO-1} {AU-8}
The spacecraft shall be designed and configured so that [Program-defined encrypted communications traffic and data] is visible to on-board monitoring tools. {SV-DCO-1} {SI-4(10)}
The spacecraft shall be designed and configured so that SV memory can be monitored by the on-board intrusion detection/prevention capability. {SV-DCO-1} {SI-16} * Identifying the class (e.g., exfiltration, Trojans, etc.), nature, or effect of cyberattack (e.g., exfiltration, subverted control, or mission interruption) is necessary to determine the type of response. The first order of identification may be to determine whether the event is an attack or a non-threat event (anomaly). The objective requirement would be to predict the impact of the detected signature. * Unexpected conditions can include RF lockups, loss of lock, failure to acquire an expected contact and unexpected reports of acquisition, unusual AGC and ACS control excursions, unforeseen actuator enabling's or actions, thermal stresses, power aberrations, failure to authenticate, software or counter resets, etc. Mitigation might include additional TMONs, more detailed AGC and PLL thresholds to alert operators, auto-capturing state snapshot images in memory when unexpected conditions occur, signal spectra measurements, and expanded default diagnostic telemetry modes to help in identifying and resolving anomalous conditions.
The spacecraft shall provide automated onboard mechanisms that integrate audit review, analysis, and reporting processes to support mission processes for investigation and response to suspicious activities to determine the attack class in the event of a cyberattack. {SV-DCO-1} {SC-5(3),AU-6(1)} 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 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),SI-4(16)} 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 be able to locate the onboard origin of a cyberattack and alert ground operators within [TBD minutes]. {SV-DCO-1} {SI-4(16)} Requirement is to support offboard attribution by enabling the fusion of spacecraft cyber data with ground-based cyber data. This would provide end-to-end accountability of commands, data, and other data that can be used to determine the origin of attack from the ground system. Data should be provided within time constraints relevant for the particular mission and its given operational mode. Analysis should be performed to identify the specific timeliness requirements for a mission, which may vary depending on mission mode, operational status, availability of communications resources, and other factors. The specific data required should be identified, as well.
The spacecraft shall attribute cyberattacks and identify unauthorized use of the spacecraft by downlinking onboard cyber information to the mission ground station within [mission-appropriate timelines minutes]. {SV-DCO-1} {AU-4(1),SI-4(5)}
The spacecraft shall detect and deny unauthorized outgoing communications posing a threat to the spacecraft. {SV-DCO-1} {SI-4(4),SC-7(9),SI-4(11)}
The spacecraft shall protect information obtained from logging/intrusion-monitoring from unauthorized access, modification, and deletion. {SV-DCO-1} {AU-9}
The spacecraft shall implement cryptographic mechanisms to protect the integrity of audit information and audit tools. {SV-DCO-1} {AU-9(3)} These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker exquisitely—with or without ground aiding. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system." These countermeasures are likely executed prior to entering into a cyber-safe mode.
The spacecraft shall select and execute safe countermeasures against cyberattacks prior to entering cyber-safe mode. {SV-DCO-1} {SI-17,IR-4} 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 provide cyber threat status to the ground segment for the Defensive Cyber Operations team, per the governing specification. {SV-DCO-1} {IR-5} 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 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(2)} 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 spacecraft shall provide the capability of a cyber “black-box” to capture [Program-defined information] necessary data for cyber forensics of threat signatures and anomaly resolution when cyberattacks are detected. {SV-DCO-1} {IR-5(1),AU-9(2)}
The spacecraft shall alert in the event of the [Program-defined] audit/logging processing failures. {SV-DCO-1} {AU-5}
The spacecraft shall provide the capability to verify the correct operation of security-relevant software and hardware mechanisms (e.g., SV IDS/IPS, logging, crypto, etc.) {SV-DCO-1} {SI-6} One example would be for bad commands where the system would reject the command and not increment the Vehicle Command Counter (VCC) and include the information in telemetry.
The spacecraft, upon detection of a potential integrity violation, shall provide the capability to [audit the event and alert ground operators]. {SV-DCO-1} {SI-7(8)}
The spacecraft shall be configured to allocate audit record storage capacity in accordance with [Program-defined audit record storage requirements]. {SV-DCO-1} {AU-4}
The spacecraft shall provide the capability to modify the set of audited events (e.g., cyber-relevant data). {SV-DCO-1} {AU-14}
The Program shall integrate terrestrial system audit log analysis as part of the standard anomaly resolution process to correlate any anomalous behavior in the terrestrial systems that correspond to anomalous behavior in the spacecraft. {SV-DCO-1} {AU-6(1),IR-5(1)}

Related SPARTA Techniques and Sub-Techniques

ID Name Description
DE-0003 Modify On-Board Values Threat actors may target various onboard values put in place to prevent malicious or poorly crafted commands from being processed. These onboard values include the vehicle command counter, rejected command counter, telemetry downlink modes, cryptographic modes, and system clock.
DE-0003.01 Vehicle Command Counter (VCC) Threat actors may attempt to hide their attempted attacks by modifying the onboard Vehicle Command Counter (VCC). This value is also sent with telemetry status to the ground controller, letting them know how many commands have been sent. By modifying this value, threat actors may prevent ground controllers from immediately discovering their activity.
DE-0003.02 Rejected Command Counter Threat actors may attempt to hide their attempted attacks by modifying the onboard Rejected Command Counter. Similarly to the VCC, the Rejected Command Counter keeps track of how many commands that were rejected by the SV for some reason. Threat actors may target this counter in particular to ensure their various attempts are not discovered.
DE-0003.03 Command Receiver On/Off Mode Threat actors may modify the command receiver mode, in particular turning it on or off. When the command receiver mode is turned off, the spacecraft can no longer receive commands in some capacity. Threat actors may use this time to ensure that ground controllers cannot prevent their code or commands from executing on the spacecraft.
DE-0003.04 Command Receivers Received Signal Strength Threat actors may target the on-board command receivers received signal parameters (i.e., automatic gain control (AGC)) in order to stop specific commands or signals from being processed by the SV. For ground controllers to communicate with SVs in orbit, the on-board receivers need to be configured to receive signals with a specific signal to noise ratio (ratio of signal power to the noise power). Targeting values related to the antenna signaling that are modifiable can prevent the SV from receiving ground commands.
DE-0003.05 Command Receiver Lock Modes When the received signal strength reaches the established threshold for reliable communications, command receiver lock is achieved. Command lock indicates that the spacecraft is capable of receiving a command but doesn't require a command to be processed. Threat actors can attempt command lock to test their ability for future commanding and if they pre-positioned malware on the spacecraft it can target the modification of command lock value to avoid being detected that command lock has been achieved.
DE-0003.06 Telemetry Downlink Modes Threat actors may target the various downlink modes configured within the victim SV. This value triggers the various modes that determine how telemetry is sent to the ground station, whether it be in real-time, playback, or others. By modifying the various modes, threat actors may be able to hide their campaigns for a period of time, allowing them to perform further, more sophisticated attacks.
DE-0003.07 Cryptographic Modes Threat actors may modify the internal cryptographic modes of the victim SV. Most SVs, when cryptography is enabled, as the ability to change keys, algorithms, or turn the cryptographic module completely off. Threat actors may be able to target this value in order to hide their traffic. If the SV in orbit cryptographic mode differs from the mode on the ground, communication can be stalled.
DE-0003.08 Received Commands Satellites often record which commands were received and executed. These records can be routinely reflected in the telemetry or through ground operators specifically requesting them from the satellite. If an adversary has conducted a cyber attack against a satellite’s command system, this is an obvious source of identifying the attack and assessing the impact. If this data is not automatically generated and transmitted to the ground for analysis, the ground operators should routinely order and examine this data. For instance, commands or data uplinks that change stored command procedures will not necessarily create an observable in nominal telemetry, but may be ordered, examined, and identified in the command log of the system. Threat actors may manipulate these stored logs to avoid detection.
DE-0003.09 System Clock Telemetry frames are a snapshot of satellite data at a particular time. Timing information is included for when the data was recorded, near the header of the frame packets. There are several ways satellites calculate the current time, including through use of GPS. An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, including misrepresentation of when certain actions took place.
DE-0003.10 GPS Ephemeris A satellite with a GPS receiver can use ephemeris data from GPS satellites to estimate its own position in space. A hostile actor could spoof the GPS signals to cause erroneous calculations of the satellite’s position. The received ephemeris data is often telemetered and can be monitored for indications of GPS spoofing. Reception of ephemeris data that changes suddenly without a reasonable explanation (such as a known GPS satellite handoff), could provide an indication of GPS spoofing and warrant further analysis. Threat actors could also change the course of the vehicle and falsify the telemetered data to temporarily convince ground operators the vehicle is still on a proper course.
DE-0003.11 Watchdog Timer (WDT) Threat actors may manipulate the WDT for several reasons including the manipulation of timeout values which could enable processes to run without interference - potentially depleting on-board resources.

Related SPARTA Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001