Monitor Critical Telemetry Points

Techniques Addressed by Countermeasure

here here here here here here here here here

ID		Name	Description
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-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.
	.01	Compromise On-Orbit Update	Threat actors may manipulate and modify on-orbit updates before they are sent to the target spacecraft. This attack can be done in a number of ways, including manipulation of source code, manipulating environment variables, on-board table/memory values, or replacing compiled versions with a malicious one.
	.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.
	.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.
	.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-0009		Trusted Relationship	Access through trusted third-party relationship exploits an existing connection that has been approved for interconnection. Leveraging third party / approved interconnections to pivot into the target systems is a common technique for threat actors as these interconnections typically lack stringent access control due to the trusted status.
	.02	Vendor	Threat actors may target the trust between vendors and the target space vehicle. Missions often grant elevated access to vendors in order to allow them to manage internal systems as well as cloud-based environments. The vendor's access may be intended to be limited to the infrastructure being maintained but it may provide laterally movement into the target space vehicle. Attackers may leverage security weaknesses in the vendor environment to gain access to more critical mission resources or network locations. In the space vehicle context vendors may have direct commanding and updating capabilities outside of the primary communication channel.
EX-0001		Replay	Replay attacks involve threat actors recording previously 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.
	.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-0013		Flooding	Threat actors use flooding attacks to disrupt communications by injecting unexpected noise or messages into a transmission channel. There are several types of attacks that are consistent with this method of exploitation, and they can produce various outcomes. Although, the most prominent of the impacts are denial of service or data corruption. Several elements of the space vehicle may be targeted by jamming and flooding attacks, and depending on the time of the attack, it can have devastating results to the availability of the system.
	.01	Valid Commands	Threat actors may utilize valid commanding as a mechanism for flooding as the processing of these valid commands could expend valuable resources like processing power and battery usage. Flooding the spacecraft bus, sub-systems or link layer with valid commands can create temporary denial of service conditions for the space vehicle while the spacecraft is consumed with processing these valid commands.
	.02	Erroneous Input	Threat actors inject noise/data/signals into the target channel so that legitimate messages cannot be correctly processed due to impacts to integrity or availability. Additionally, while this technique does not utilize system-relevant signals/commands/information, the target spacecraft may still consume valuable computing resources to process and discard the signal.
EX-0016		Jamming	Threat actors may attempt to jam Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to inhibit a spacecraft's position, navigation, and/or timing functions.
	.03	Position, Navigation, and Timing (PNT)	Threat actors may attempt to jam Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to inhibit a spacecraft's position, navigation, and/or timing functions.
PER-0003		Ground System Presence	Threat actors may compromise target owned ground systems that can be used for persistent access to the spacecraft or to perpetuate other techniques. These ground systems have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute persistently.
DE-0002		Prevent Downlink	Threat actors may target the downlink connections to prevent the victim spacecraft from sending telemetry to the ground controllers. 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.
	.02	Jam Link Signal	Threat actors may overwhelm/jam the downlink signal to prevent transmitted telemetry signals from reaching their destination without severe modification/interference, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
DE-0003		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.
	.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.
	.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 spacecraft for some reason. Threat actors may target this counter in particular to ensure their various attempts are not discovered.
	.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.
	.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 spacecraft. For ground controllers to communicate with spacecraft 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 spacecraft from receiving ground commands.
	.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.
	.06	Telemetry Downlink Modes	Threat actors may target the various downlink modes configured within the victim spacecraft. 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.
	.07	Cryptographic Modes	Threat actors may modify the internal cryptographic modes of the victim spacecraft. Most spacecraft, 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 spacecraft in orbit cryptographic mode differs from the mode on the ground, communication can be stalled.
	.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.
	.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.
	.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.
	.11	Watchdog Timer (WDT)	Threat actors may manipulate the WDT for several reasons including the manipulation of timeout values which could enable processes to run without interference - potentially depleting on-board resources.
DE-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-0010		Overflow Audit Log	Threat actors may seek to exploit the inherent nature of flight software and its limited capacity for event logging/storage between downlink windows as a means to conceal malicious activity.
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.
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.

Space Threats Addressed by Countermeasure

ID	Description
SV-IT-5	Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands
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-DCO-1	Not knowing that you were attacked, or attack was attempted
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-IT-1	Communications system spoofing resulting in denial of service and loss of availability and data integrity
SV-AV-1	Communications system jamming resulting in denial of service and loss of availability and data integrity

Low-Level Requirements

Requirement	Rationale/Additional Guidance/Notes
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 implement automated mechanisms to assist in the execution and implementation of the Continuous Monitoring Program (CMP).{CA-7(6)}
The [organization] shall distribute documentation to only personnel with defined roles and a need to know.{SV-CF-3,SV-AV-5}{CM-12,CP-2,SA-5,SA-10}	Least privilege and need to know should be employed with the protection of all documentation. Documentation can contain sensitive information that can aid in vulnerability discovery, detection, and exploitation. For example, command dictionaries for ground and space systems should be handles with extreme care. Additionally, design documents for missions contain many key elements that if compromised could aid in an attacker successfully exploiting the system.
The [organization] shall 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 document the platform's security architecture, and how it is established within and is an integrated part of the overall [organization] mission security architecture.{PL-7,SA-8(7),SA-8(13),SA-8(29),SA-8(30),SA-17}
The [organization] shall protect documentation and Essential Elements of Information (EEI) as required, in accordance with the risk management strategy.{SV-CF-3,SV-AV-5}{SA-5}	Essential Elements of Information (EEI):
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 [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 use [directional or beamforming] antennas in normal ops to reduce the likelihood that unintended receivers will be able to intercept signals.{SV-AV-1}{AC-18(5)}
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 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 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 new and updates to on-board stored command sequences.{SV-IT-5}{AC-3(2)}	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 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] 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 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 [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 monitor and collect all onboard cyber-relevant data (from multiple system components), including identification of potential attacks and sufficient information about the attack for subsequent analysis.{SV-DCO-1}{AC-6(9),AC-20,AC-20(1),AU-2,AU-12,IR-4,IR-4(1),RA-10,SI-3,SI-3(10),SI-4,SI-4(1),SI-4(2),SI-4(7),SI-4(24)}	The spacecraft will monitor and collect data that provides accountability of activity occurring onboard the spacecraft. Due to resource limitations on the spacecraft, analysis must be performed to determine which data is critical for retention and which can be filtered. Full system coverage of data and actions is desired as an objective; it will likely be impractical due to the resource limitations. “Cyber-relevant data” refers to all data and actions deemed necessary to support accountability and awareness of onboard cyber activities for the mission. This would include data that may indicate abnormal activities, critical configuration parameters, transmissions on onboard networks, command logging, or other such data items. This set of data items should be identified early in the system requirements and design phase. Cyber-relevant data should support the ability to assess whether abnormal events are unintended anomalies or actual cyber threats. Actual cyber threats may rarely or never occur, but non-threat anomalies occur regularly. The ability to filter out cyber threats for non-cyber threats in relevant time would provide a needed capability. Examples could include successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels).
The [spacecraft] shall provide the capability to modify the set of audited events (e.g., cyber-relevant data).{SV-DCO-1}{AU-12(3),AU-14}
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),AU-12,IR-4,IR-4(1),RA-10,SI-3,SI-3(10),SI-4(7),SI-4(24)}
The [spacecraft] shall be configured to allocate audit record storage capacity in accordance with 1 week audit record storage requirements.{SV-DCO-1}{AU-4,AU-5,AU-5(1),AU-5(2)}
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)}	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 alert in the event of the [organization]-defined audit/logging processing failures.{SV-DCO-1}{AU-5}
The [spacecraft] shall provide an alert immediately to [at a minimum the mission director, administrators, and security officers] when the following failure events occur: [minimally but not limited to: auditing software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity reaching 95%, 99%, and 100%] of allocated capacity.{SV-DCO-1}{AU-5,AU-5(1),AU-5(2),SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(24),SI-7(7)}	Intent is to have human on the ground be alerted to failures. This can be decomposed to SV to generate telemetry and to Ground to alert.
The [spacecraft] shall provide the capability of a cyber “black-box” to capture necessary data for cyber forensics of threat signatures and anomaly resolution when cyber attacks are detected.{SV-DCO-1}{AU-5(5),AU-9(2),AU-9(3),AU-12,IR-4(12),IR-4(13),IR-5(1),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(7),SI-4(24),SI-7(7)}	Similar concept of a "black box" on an aircraft where all critical information is stored for post forensic analysis. Black box can be used to record CPU utilization, GNC physical parameters, audit records, memory contents, TT&C data points, etc. The timeframe is dependent upon implementation but needs to meet the intent of the requirement. For example, 30 days may suffice.
The [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 cyber attack.{SV-DCO-1}{AU-6(1),IR-4,IR-4(1),IR-4(12),IR-4(13),PM-16(1),RA-10,SA-8(21),SA-8(22),SC-5(3),SI-3,SI-3(10),SI-4(7),SI-4(24),SI-7(7)}	* 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 [organization] 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)}
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 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 use internal system clocks to generate time stamps for audit records.{SV-DCO-1}{AU-8}
The [spacecraft] shall incorporate backup sources for navigation and timing.{SV-IT-1}{AU-8(1),SC-45(1),SC-45(2)}
The [spacecraft] shall have fault-tolerant authoritative time sourcing for the platform's clock.{SV-IT-1}{AU-8(2),SC-45,SC-45(1),SC-45(2),SI-13}	* Adopt voting schemes (triple modular redundancy) that include inputs from backup sources. Consider providing a second reference frame against which short-term changes or interferences can be compared. * Atomic clocks, crystal oscillators and/or GPS receivers are often used as time sources. GPS should not be used as the only source due to spoofing/jamming concerns.
The [spacecraft] shall protect information obtained from logging/intrusion-monitoring from unauthorized access, modification, and deletion.{SV-DCO-1}{AU-9,AU-9(3),RA-10,SI-4(7),SI-4(24)}
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], upon detection of a potential integrity violation, shall provide the capability to [audit the event and alert ground operators].{SV-DCO-1}{CM-3(5),SA-8(21),SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(8)}	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] shall be configured to provide only essential capabilities.{CM-6,CM-7,SA-8(2),SA-8(7),SA-8(13),SA-8(23),SA-8(26),SA-15(5)}
The [spacecraft] shall enter a cyber-safe mode when conditions that threaten the platform are detected, enters a cyber-safe mode of operation with restrictions as defined based on the cyber-safe mode.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4,IR-4(1),IR-4(3),PE-10,RA-10,SA-8(16),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-13,SI-17}
The [spacecraft] shall provide the capability to enter the platform into a known good, operational cyber-safe mode from a tamper-resistant, configuration-controlled (“gold”) image that is authenticated as coming from an acceptable supplier, and has its integrity verified.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4(3),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-13,SI-17}	Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and SW functions to preattack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on available equipment still available after a cyberattack. The goal is for the vehicle to resume full mission operations. If not possible, a reduced level of mission capability should be achieved.
The [spacecraft] shall 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 be able to locate the onboard origin of a cyber attack and alert ground operators within 3 minutes.{SV-DCO-1}{IR-4,IR-4(1),IR-4(12),IR-4(13),RA-10,SA-8(22),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(16),SI-4(24)}	The origin of any attack onboard the vehicle should be identifiable to support mitigation. At the very least, attacks from critical element (safety-critical or higher-attack surface) components should be locatable quickly so that timely action can occur.
The [spacecraft] shall detect and deny unauthorized outgoing communications posing a threat to the spacecraft.{SV-DCO-1}{IR-4,IR-4(1),RA-5(4),RA-10,SC-7(9),SC-7(10),SI-4,SI-4(1),SI-4(4),SI-4(7),SI-4(11),SI-4(13),SI-4(24),SI-4(25)}
The [spacecraft] shall select and execute safe countermeasures against cyber attacks prior to entering cyber-safe mode.{SV-DCO-1}{IR-4,RA-10,SA-8(21),SA-8(24),SI-4(7),SI-17}	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 provide cyber threat status to the ground segment for the Defensive Cyber Operations team, per the governing specification.{SV-DCO-1}{IR-5,PM-16,PM-16(1),RA-3(3),RA-10,SI-4,SI-4(1),SI-4(24),SI-7(7)}	The future space enterprises will include full-time Cyber Defense teams supporting space mission systems. Their work is currently focused on the ground segment but may eventually require specific data from the space segment for their successful operation. This requirement is a placeholder to ensure that any DCO-related requirements are taken into consideration for this document.
The [organization] shall implement a security architecture and design that provides the required security functionality, allocates security controls among physical and logical components, and integrates individual security functions, mechanisms, and processes together to provide required security capabilities and a unified approach to protection.{SV-MA-6}{PL-7,SA-2,SA-8,SA-8(1),SA-8(2),SA-8(3),SA-8(4),SA-8(5),SA-8(6),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30),SC-32,SC-32(1)}
The [spacecraft] shall be designed and configured so that encrypted communications traffic and data is visible to on-board security monitoring tools.{SV-DCO-1}{RA-10,SA-8(21),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(10),SI-4(13),SI-4(24),SI-4(25)}
The [spacecraft] shall be designed and configured so that spacecraft memory can be monitored by the on-board intrusion detection/prevention capability.{SV-DCO-1}{RA-10,SA-8(21),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(24),SI-16}
The [spacecraft] shall have on-board intrusion detection/prevention system that monitors the mission critical components or systems.{SV-AC-1,SV-AC-2,SV-MA-4}{RA-10,SC-7,SI-3,SI-3(8),SI-4,SI-4(1),SI-4(7),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}	The mission critical components or systems could be GNC/Attitude Control, C&DH, TT&C, Fault Management.
The [spacecraft] shall generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.{SV-AV-5,SV-AV-6,SV-AV-7}{RA-5(4),SI-4(12),SI-11}
The [spacecraft] shall reveal error messages only to operations personnel monitoring the telemetry.{SV-AV-5,SV-AV-6,SV-AV-7}{RA-5(4),SI-4(12),SI-11}
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 [spacecraft] shall provide the capability to verify the correct operation of security-relevant software and hardware mechanisms (e.g.spacecraft IDS/IPS, logging, crypto, etc..) {SV-DCO-1}{SA-8(21),SI-3,SI-6}
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 internally monitor GPS performance so that changes or interruptions in the navigation or timing are flagged.{SV-IT-1}{SC-45(1)}
The [spacecraft] shall protect external and internal communications from jamming and spoofing attempts.{SV-AV-1,SV-IT-1}{SC-5,SC-40,SC-40(1)}	Can be aided via the Crosslink, S-Band, and L-Band subsystems
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] cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.{SV-AV-5,SV-AV-6,SV-AV-7}{SI-17}	Cyber-safe mode is using a fail-secure mentality where if there is a malfunction that the spacecraft goes into a fail-secure state where cyber protections like authentication and encryption are still employed (instead of bypassed) and the spacecraft can be restored by authorized commands. The cyber-safe mode should be stored in a high integrity location of the on-board SV so that it cannot be modified by attackers.
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)}
The [organization] shall ensure that FMEA/FMECA artifacts are strictly controlled so that particular fault responses are not disclosed via documentation.{SV-AV-5}