Authentication

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 SV via the crosslink communications of a neighboring SV that has been compromised. SVs in close proximity are able to send commands back and forth. Threat actors may be able to leverage this access to compromise other SVs once they have access to another that is nearby.
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 SV by replaying captured commands to the SV. While not necessarily malicious in nature, replayed commands can be used to overload the target SV and cause it's onboard systems to crash, perform a DoS attack, or monitor various responses by the SV. If critical commands are captured and replayed, thruster fires, then the impact could impact the SV's attitude control/orbit.
EX-0006		Disable/Bypass Encryption	Threat actors may perform specific techniques in order to bypass or disable the encryption mechanism onboard the victim SV. 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-0014		Spoofing	Threat actors may attempt to spoof the various sensor and controller data that is depended upon by various subsystems within the victim SV. 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 SV to behave erratically. Further, the data could be processed erroneously, causing ground controllers to receive incorrect telemetry or scientific data, threatening the SV's reliability and integrity.
	.01	Time Spoof	Threat actors may attempt to target the internal timers onboard the victim SV and spoof their data. The Spacecraft Event Time (SCET) is used for various programs within the SV and control when specific events are set to occur. Ground controllers use these timed events to perform automated processes as the SV 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.
	.02	Bus Traffic	Threat actors may attempt to target the main or secondary bus onboard the victim SV and spoof their data. The spacecraft bus often directly processes and sends messages from the ground controllers to the various subsystems within the SV 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 SV's subsystems, hosted payload, and critical data.
	.03	Sensor Data	Threat actors may target sensor data on the space vehicle to achieve their attack objectives. Sensor data is typically inherently trusted by the space vehicle 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 space vehicle depending on decisions being made by the space vehicle using the sensor data. For example, spoofing data related to attitude control could adversely impact the space vehicles ability to maintain orbit.
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 SV is within certain location so the data can be intercepted on the downlink by threat actor ground terminals.
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 space vehicles leverage out-of-band communication links to perform actions on the space vehicle (i.e., re-keying). These out-of-band links would occur on completely different channels/frequencies and often operate on separate hardware on the space vehicle. 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.
DE-0004		Masquerading	Threat actors may gain access to a victim SV 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)
LM-0002		Exploit Lack of Bus Segregation	Threat actors may exploit victim SVs on-board flat architecture for lateral movement purposes. Depending on implementation decisions, SVs 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 to laterally move to another area of the SV.
LM-0003		Constellation Hopping via Crosslink	Threat actors may attempt to command another neighboring spacecraft via crosslink. SVs in close proximity are often able to send commands back and forth. Threat actors may be able to leverage this access to compromise another SV.
LM-0004		Visiting Vehicle Interface(s)	Threat actors may move to other SVs through visiting vehicle interfaces. When a vehicle docks with a SV, 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 SV 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 SV once docked.

Space Threats Addressed by Countermeasure

ID	Description

Low-Level Requirements

Requirement	Rationale/Additional Guidance/Notes
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 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 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 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 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 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).
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 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 employ the principle of least privilege, allowing only authorized accesses processes which are necessary to accomplish assigned tasks in accordance with system functions.{SV-AC-6}{AC-3,AC-6,AC-6(9),CA-9,CM-5,CM-5(5),CM-5(6),SA-8(2),SA-8(5),SA-8(6),SA-8(14),SA-8(23),SA-17(7),SC-2,SC-7(29),SC-32,SC-32(1),SI-3}
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 provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard.{AC-3(2),PE-10,SA-8(15)}
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] 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}
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 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 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 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 [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 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 provide independent mission/cyber critical threads such that any one credible event will not corrupt another mission/cyber critical thread.{SC-3,SC-32,SC-32(1),SI-3,SI-13}