Shared Resource Leakage

Techniques Addressed by Countermeasure

here here here here here here here here here

ID		Name	Description
IA-0005		Rendezvous & Proximity Operations	Threat actors may perform a space rendezvous which is a set of orbital maneuvers during which a spacecraft arrives at the same orbit and approach to a very close distance (e.g. within visual contact or close proximity) to a target spacecraft.
	.02	Docked Vehicle / OSAM	Threat actors may leverage docking vehicles to laterally move into a target spacecraft. If information is known on docking plans, a threat actor may target vehicles on the ground or in space to deploy malware to laterally move or execute malware on the target spacecraft via the docking interface.
	.03	Proximity Grappling	Threat actors may posses the capability to grapple target spacecraft once it has established the appropriate space rendezvous. If from a proximity / rendezvous perspective a threat actor has the ability to connect via docking interface or expose testing (i.e., JTAG port) once it has grappled the target spacecraft, they could perform various attacks depending on the access enabled via the physical connection.
IA-0006		Compromise Hosted Payload	Threat actors may compromise the target spacecraft hosted payload to initially access and/or persist within the system. Hosted payloads can usually be accessed from the ground via a specific command set. The command pathways can leverage the same ground infrastructure or some host payloads have their own ground infrastructure which can provide an access vector as well. Threat actors may be able to leverage the ability to command hosted payloads to upload files or modify memory addresses in order to compromise the system. Depending on the implementation, hosted payloads may provide some sort of lateral movement potential.
EX-0009		Exploit Code Flaws	Threats actors may identify and exploit flaws or weaknesses within the software running on-board the target spacecraft. These attacks may be extremely targeted and tailored to specific coding errors introduced as a result of poor coding practices or they may target known issues in the commercial software components.
	.02	Operating System	Threat actors may exploit flaws in the operating system code, which controls the storage, memory management, provides resources to the FSW, and controls the bus. There has been a trend where some modern spacecraft are running Unix-based operating systems and establishing SSH connections for communications between the ground and spacecraft. Threat actors may seek to gain access to command line interfaces & shell environments in these instances. Additionally, most operating systems, including real-time operating systems, include API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands.
LM-0001		Hosted Payload	Threat actors may use the hosted payload within the victim spacecraft in order to gain access to other subsystems. The hosted payload often has a need to gather and send data to the internal subsystems, depending on its purpose. Threat actors may be able to take advantage of this communication in order to laterally move to the other subsystems and have commands be processed.
LM-0002		Exploit Lack of Bus Segregation	Threat actors may exploit victim spacecraft on-board flat architecture for lateral movement purposes. Depending on implementation decisions, spacecraft can have a completely flat architecture where remote terminals, sub-systems, payloads, etc. can all communicate on the same main bus without any segmentation, authentication, etc. Threat actors can leverage this poor design to send specially crafted data from one compromised devices or sub-system. This could enable the threat actor to laterally move to another area of the spacecraft or escalate privileges (i.e., bus master, bus controller)
LM-0004		Visiting Vehicle Interface(s)	Threat actors may move from one spacecraft to another through visiting vehicle interfaces. When a vehicle docks with a spacecraft, many programs are automatically triggered in order to ensure docking mechanisms are locked. This entails several data points and commands being sent to and from the spacecraft and the visiting vehicle. If a threat actor were to compromise a visiting vehicle, they could target these specific programs in order to send malicious commands to the victim spacecraft once docked.
LM-0006		Launch Vehicle Interface	Threat actors may attempt to exploit reduced protections placed on the interfaces between launch vehicles and payloads in order to move from one to the other.
	.01	Rideshare Payload	Threat actors may also attempt to move laterally across the payloads themselves in cases where multiple customers are sharing the same launch vehicle, and security mechanisms are not sufficient to prevent payload to payload communication via the launch vehicle.

Space Threats Addressed by Countermeasure

ID	Description
SV-CF-2	Eavesdropping (RF and proximity)
SV-MA-3	Attacks on critical software subsystems   Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations   Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector   Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack.   Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite.
SV-AC-6	Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective;

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 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 [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 ensure that processes reusing a shared system resource (e.g., registers, main memory, secondary storage) do not have access to information (including encrypted representations of information) previously stored in that resource during a prior use by a process after formal release of that resource back to the system or reuse.{SV-AC-6}{AC-3,PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(19),SC-4,SI-3}
The [spacecraft] shall 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] software subsystems 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.{SV-MA-3,SV-AV-7}{AC-3(2)}
The [spacecraft] software subsystems shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard.{SV-MA-3,SV-AV-7}{AC-3(2)}
The [spacecraft] shall enforce approved authorizations for controlling the flow of information within the platform and between interconnected systems so that information does not leave the platform boundary unless it is encrypted.{SV-AC-6}{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-3,CA-3(6),CA-3(7),CA-9,IA-9,SA-8(19),SC-8(1),SC-16(3)}
The [spacecraft] security implementation shall ensure that information should not be allowed to flow between partitioned applications unless explicitly permitted by the system.{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-9,IA-9,SA-8(3),SA-8(18),SA-8(19),SC-2(2),SC-7(29),SC-16,SC-32}
The [spacecraft] shall, when transferring information between different security domains, implements the following security policy filters that require fully enumerated formats that restrict data structure and content: connectors and semaphores implemented in the RTOS.{SV-AC-6}{AC-3(3),AC-3(4),AC-4(14),IA-9,SA-8(19),SC-16}
The [spacecraft] shall implement boundary protections to separate bus, communications, and payload components supporting their respective functions.{SV-AC-6}{AC-3(3),AC-3(4),CA-9,SA-8(3),SA-8(14),SA-8(18),SA-8(19),SA-17(7),SC-2,SC-2(2),SC-7(13),SC-7(21),SC-7(29),SC-16(3),SC-32,SI-3,SI-4(13),SI-4(25)}
The [spacecraft] shall isolate mission critical functionality from non-mission critical functionality by means of an isolation boundary (e.g.via partitions) that controls access to and protects the integrity of, the hardware, software, and firmware that provides that functionality.{SV-AC-6}{AC-3(3),AC-3(4),CA-9,SA-8(3),SA-8(19),SA-17(7),SC-2,SC-3,SC-3(4),SC-7(13),SC-7(29),SC-32,SC-32(1),SI-3,SI-7(10),SI-7(12)}
The [spacecraft] data within partitioned applications shall not be read or modified by other applications/partitions.{SV-AC-6}{AC-3(3),AC-3(4),SA-8(19),SC-2(2),SC-4,SC-6,SC-32}
The [spacecraft] shall prevent unauthorized access to system resources by employing an efficient capability based object model that supports both confinement and revocation of these capabilities when the platform security deems it necessary.{SV-AC-6}{AC-3(8),IA-4(9),PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(18),SA-8(19),SC-2(2),SC-4,SC-16,SC-32,SI-3}
The [organization] shall state that information should not be allowed to flow between partitioned applications unless explicitly permitted by the Program's security policy.{SV-AC-6}{AC-4,AC-4(6)}
The [spacecraft] shall use protected processing domains to enforce the policy that information does not leave the platform boundary unless it is encrypted as a basis for flow control decisions.{SV-AC-6}{AC-4(2),IA-9,SA-8(19),SC-8(1),SC-16(3)}
The [spacecraft] shall 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 [organization] shall define the resources to be allocated to protect the availability of system resources.{SV-AC-6}{CP-2(2),SC-6}
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 protect system components, associated data communications, and communication buses in accordance with: (i) national emissions and TEMPEST policies and procedures, and (ii) the security category or sensitivity of the transmitted information.{SV-CF-2,SV-MA-2}{PE-14,PE-19,PE-19(1),RA-5(4),SA-8(18),SA-8(19),SC-8(1)}	The measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements. The concerns addressed by this control during operation are emanations leakage between multiple payloads within a single space platform, and between payloads and the bus.
The [organization] shall describe (a) the separation between RED and BLACK cables, (b) the filtering on RED power lines, (c) the grounding criteria for the RED safety grounds, (d) and the approach for dielectric separators on any potential fortuitous conductors.{SV-CF-2,SV-MA-2}{PE-19,PE-19(1)}
The [spacecraft] shall be designed such that it protects itself from information leakage due to electromagnetic signals emanations.{SV-CF-2,SV-MA-2}{PE-19,PE-19(1),RA-5(4),SA-8(19)}	This requirement applies if system components are being designed to address EMSEC and the measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements.
The [organization] shall implement a security architecture and design that provides the required security functionality, allocates security controls among physical and logical components, and integrates individual security functions, mechanisms, and processes together to provide required security capabilities and a unified approach to protection.{SV-MA-6}{PL-7,SA-2,SA-8,SA-8(1),SA-8(2),SA-8(3),SA-8(4),SA-8(5),SA-8(6),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30),SC-32,SC-32(1)}
The [spacecraft] shall prevent unauthorized and unintended information transfer via shared system resources.{SV-AC-6}{PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(19),SC-2(2),SC-4}
The [spacecraft] shall maintain a separate execution domain for each executing process.{SV-AC-6}{SA-8(14),SA-8(19),SC-2(2),SC-7(21),SC-39,SI-3}
The [spacecraft] flight software must not be able to tamper with the security policy or its enforcement mechanisms.{SV-AC-6}{SA-8(16),SA-8(19),SC-3,SC-7(13)}
The [spacecraft] shall protect the confidentiality and integrity of the [all information] using cryptography while it is at rest.{SV-IT-2,SV-CF-2}{SC-28,SC-28(1),SI-7(6)}	* Information at rest refers to the state of information when it is located on storage devices as specific components of information systems. This is often referred to as data-at-rest encryption.
The [spacecraft] software subsystems shall provide independent mission/cyber critical threads such that any one credible event will not corrupt another mission/cyber critical thread.{SV-MA-3,SV-AV-7}{SC-3}
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}
The [spacecraft] shall protect the availability of resources by allocating [organization]-defined resources based on [priority and/or quota].{SV-AC-6}{SC-6}	In particular, this control is required for all space platform buses to ensure execution of high priority functions; it is particularly important when there are multiple payloads sharing a bus providing communications and other services, where bus resources must be prioritized based on mission.
The [organization] shall define the security safeguards to be employed to protect the availability of system resources.{SV-AC-6}{SC-6,SI-17}
The [spacecraft] software subsystems shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied.{SV-MA-3,SV-AV-7}{SI-10}
The [spacecraft] software subsystems shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission.{SV-MA-3,SV-AV-7}{SI-10}
The [spacecraft] software subsystems shall perform prerequisite checks for the execution of hazardous commands.{SV-MA-3,SV-AV-7}{SI-10}
The [spacecraft] software subsystems shall discriminate between valid and invalid input into the software and rejects invalid input.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)}
The [spacecraft] software subsystems shall properly handle spurious input and missing data.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)}
The [spacecraft] software subsystems shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit or perform a hazardous action.{SV-MA-3,SV-AV-7}{SI-10(3)}
The [spacecraft] mission/cyber critical commands shall be "complex" and/or diverse from other commands so that a single bit flip could not transform a benign command into a hazardous command.{SV-MA-3,SV-AV-7}{SI-10(5)}
The [spacecraft] software subsystems shall provide at least one independent command for each operator-initiated action used to shut down a function leading to or reducing the control of a hazard.{SV-MA-3,SV-AV-7}{SI-10(5)}
The [spacecraft] shall have failure tolerance on sensors used by software to make mission-critical decisions.{SV-MA-3,SV-AV-7}{SI-13,SI-17}
The [spacecraft] software subsystems shall detect and recover/transition from detected memory errors to a known cyber-safe state.{SV-MA-3,SV-AV-7}{SI-17}
The [spacecraft] software subsystems shall initialize the spacecraft to a known safe state.{SV-MA-3,SV-AV-7}{SI-17}
The [spacecraft] software subsystems shall operate securely in off-nominal power conditions, including loss of power and spurious power transients.{SV-MA-3,SV-AV-7}{SI-17}
The [spacecraft] software subsystems shall perform an orderly, controlled system shutdown to a known cyber-safe state upon receipt of a termination command or condition.{SV-MA-3,SV-AV-7}{SI-17}
The [spacecraft] software subsystems shall recover to a known cyber-safe state when an anomaly is detected.{SV-MA-3,SV-AV-7}{SI-17}
The [spacecraft] software subsystems shall safely transition between all predefined, known states.{SV-MA-3,SV-AV-7}{SI-17}