Resilient Position, Navigation, and Timing

If available, use an authentication mechanism that allows GNSS receivers to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. Have fault-tolerant authoritative time sourcing for the spacecraft's clock. The spacecraft should synchronize the internal system clocks for each processor to the authoritative time source when the time difference is greater than the FSW-defined interval. If Spacewire is utilized, then the spacecraft should adhere to mission-defined time synchronization standard/protocol to synchronize time across a Spacewire network with an accuracy around 1 microsecond.

Sources

https://www.gps.gov/resilience/

https://gssc.esa.int/navipedia/index.php/Galileo_Open_Service_Navigation_Message_Authentication#:~:text=Galileo%20OS%2DNMA%20(Open%20Service,comes%20from%20a%20trusted%20source

Best Segment for Countermeasure Deployment

Space Segment

NIST Rev5 Controls

D3FEND Techniques

D3FEND Artifacts

User to User Message

ISO 27001

ID: CM0048

NASA Best Practice Guide: MI-AUTH-01 | MI-AUTH-02 | MI-INTG-01 | MI-DCO-02

ESA Space Shield Mitigation: M2023 | M2012

Created: 2022/10/19

Last Modified: 2023/10/17

Techniques Addressed by Countermeasure

ID		Name	Description
EX-0012		Modify On-Board Values	Threat actors may perform specific commands in order to modify onboard values that the victim spacecraft relies on. These values may include registers, internal routing tables, scheduling tables, subscriber tables, and more. Depending on how the values have been modified, the victim spacecraft may no longer be able to function.
	.12	System Clock	An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, such as forcing execution of stored commands in an incorrect order.
EX-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.
	.01	Time Spoof	Threat actors may attempt to target the internal timers onboard the victim spacecraft and spoof their data. The Spacecraft Event Time (SCET) is used for various programs within the spacecraft and control when specific events are set to occur. Ground controllers use these timed events to perform automated processes as the spacecraft is in orbit in order for it to fulfill it's purpose. Threat actors that target this particular system and attempt to spoof it's data could cause these processes to trigger early or late.
	.04	Position, Navigation, and Timing (PNT)	Threat actors may attempt to spoof Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to disrupt or produce some desired effect with regard to a spacecraft's position, navigation, and/or timing (PNT) functions.

Space Threats Addressed by Countermeasure

ID	Description
SV-IT-2	Unauthorized modification or corruption of data
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-AV-8	Clock synchronization attack for Spacewire. Since terminals in a distributed system are driven by independent clocks, the clock sync performance is one of the most important indexes in a networked system.
SV-DCO-1	Not knowing that you were attacked, or attack was attempted
SV-IT-1	Communications system spoofing resulting in denial of service and loss of availability and data integrity

Low-Level Requirements

Requirement	Rationale/Additional Guidance/Notes
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 that role-based security-related training is provided to personnel with assigned security roles and responsibilities: (i) before authorizing access to the system or performing assigned duties; (ii) when required by system changes; and (iii) at least annually thereafter.{AT-3,CP-2}
The [organization] shall employ independent third-party analysis and penetration testing of all software (COTS, FOSS, Custom) associated with the system, system components, or system services.{CA-2,CA-2(1),CA-8(1),CM-10(1),SA-9,SA-11(3),SA-12(11),SI-3,SI-3(10),SR-4(4),SR-6(1)}
The [organization] shall perform penetration testing/analysis: (1) On potential system elements before accepting the system; (2) As a realistic simulation of the active adversary’s known adversary tactics, techniques, procedures (TTPs), and tools; and (3) Throughout the lifecycle on physical and logical systems, elements, and processes.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CA-8(1),SA-9,SA-11(5),SR-5(2)}	Penetration testing should be performed throughout the lifecycle on physical and logical systems, elements, and processes including: (1) Hardware, software, and firmware development processes; (2) Shipping/handling procedures; (3) Personnel and physical security programs; (4) Configuration management tools/measures to maintain provenance; and (5) Any other programs, processes, or procedures associated with the production/distribution of supply chain elements.
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 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] shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design.{SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4}{CP-2,CP-2(8),PL-7,PM-11,PM-30(1),RA-3(1),RA-9,SA-8(9),SA-8(11),SA-8(25),SA-12,SA-14,SA-15(3),SC-7(29),SR-1}	During SCRM, criticality analysis will aid in determining supply chain risk. For mission critical functions/components, extra scrutiny must be applied to ensure supply chain is secured.
The [organization] shall develop an incident response and forensics plan that covers the spacecrafts.{CP-2,IR-1,IR-3,IR-3(2),IR-4(12),IR-4(13),IR-8,SA-15(10),SI-4(24)}
The [organization] shall employ techniques to limit harm from potential adversaries identifying and targeting the [organization]s supply chain.{CP-2,PM-30,SA-9,SA-12(5),SC-38,SR-3,SR-3(1),SR-3(2),SR-5(2)}
The [organization] shall maintain 24/7 space situational awareness for potential collision with space debris that could come in contact with the spacecraft.{SV-MA-1}{PE-20}
The [organization] shall develop policies and procedures to establish sufficient space domain awareness to avoid potential collisions or hostile proximity operations.This includes establishing relationships with relevant organizations needed for data sharing.{PE-6,PE-6(1),PE-6(4),PE-18,PE-20,RA-6,SC-7(14)}
The [organization] shall monitor physical access to all facilities where the system or system components reside throughout development, integration, testing, and launch to detect and respond to physical security incidents in coordination with the organizational incident response capability.{PE-6,PE-6(1),PE-6(4),PE-18,PE-20,SC-7(14)}
The [organization] shall use all-source intelligence analysis of suppliers and potential suppliers of the information system, system components, or system services to inform engineering, acquisition, and risk management decisions.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-16,PM-30,RA-2,RA-3(1),RA-3(2),RA-7,SA-9,SA-12(8),SR-5(2)}	* The Program should also consider sub suppliers and potential sub suppliers. * All-source intelligence of suppliers that the organization may use includes: (1) Defense Intelligence Agency (DIA) Threat Assessment Center (TAC), the enterprise focal point for supplier threat assessments for the DOD acquisition community risks; (2) Other U.S. Government resources including: (a) Government Industry Data Exchange Program (GIDEP) – Database where government and industry can record issues with suppliers, including counterfeits; and (b) System for Award Management (SAM) – Database of companies that are barred from doing business with the US Government.
The [organization] shall request threat analysis of suppliers of critical components and manage access to and control of threat analysis products containing U.S.person information.{SV-SP-3,SV-SP-4,SV-SP-11}{PM-16,PM-30(1),RA-3(1),SA-9,SA-12,SR-1}	The intent of this requirement is to address supply chain concerns on hardware and software vendors. Not required for trusted suppliers accredited to the Defense Microelectronic Activity (DMEA). If the Program intends to use a supplier not accredited by DMEA, the government customer should be notified as soon as possible. If the Program has internal processes to vet suppliers, it may meet this requirement. All software used and its origins must be included in the SBOM and be subjected to internal and Government vulnerability scans.
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 [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 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 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 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 synchronize the internal system clocks for each processor to the authoritative time source when the time difference is greater than the FSW-defined interval.{SV-AV-2}{AU-8(1),SC-45,SC-45(1),SC-45(2)}
The [spacecraft] shall internally monitor PNT performance so that changes or interruptions in the navigation or timing are flagged.{AU-8(1),SC-45(1)}
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.
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 [organization] shall define the security safeguards that are to be automatically employed when integrity violations are discovered.{SV-IT-2}{CP-2,SA-8(21),SI-3,SI-4(7),SI-4(12),SI-7(5),SI-7(8)}
The [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 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}
If Spacewire is utilized, the [spacecraft] shall adhere to [organization]-defined time synchronization standard/protocol to synchronize time across a Spacewire network with an accuracy around 1 microsecond.{SV-AV-8}{SC-45,SC-45(1),SC-45(2)}	Example for time synchronization is Time Distribution Protocol (http://spacewire.esa.int/WG/Spacewire/SpW-WG-Mtg17-Proceedings/Documents/ISC_2011%20CCSDS%20Time%20Distribution%20over%20SpaceWire.pdf & https://amstel.estec.esa.int/tecedm/ipcores/time_sync_protocol.pdf). These activities by ESA are looking to perform standardization of a time distribution protocol, synchronization, and handling of latency, jitter, and drift
The [organization] shall ensure synchronization of system clocks within and between systems and system components..{SV-AV-3}{SC-45,SC-45(1),SC-45(2)}
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)}