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;
Informational References
CENTRA Volume I - Cyber Content of Satellites
CENTRA - Chinese Research into Cyber Vulnerabilities of Satellite Bus Standards
The spacecraft shall employ segregation and least privilege principles for the on-board architecture, communications, and control.
Low-Level Requirements
Requirement
Rationale/Additional Guidance/Notes
The [Program-defined security policy] 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)}
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 Program shall identify the key system components or capabilities that require isolation through physical or logical means. {SV-AC-6} {SC-3}
The spacecraft shall enforce approved authorizations for controlling the flow of information within the spacecraft and between interconnected systems based on the [Program defined security policy] that information does not leave the spacecraft boundary unless it is encrypted. {SV-AC-6} {AC-4,AC-4(6)}
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-4(14)}
The spacecraft shall use protected processing domains to enforce the policy that information does not leave the spacecraft boundary unless it is encrypted as a basis for flow control decisions. {SV-AC-6} {AC-4(2)}
* Examine the isolation between mission critical and non-mission critical functionality for each individual information system component. Include architectural considerations in the examination, including isolation derived from using distinct components for mission critical and non-mission critical functionality. This would include having multiple 1553 buses for example to segregate C&DH/TT&C with payload operations.
* Methods to separate the mission/cyber critical software from software that is not critical, such as partitioning, may be used (i.e., ARINC 653). If such software methods are used to separate the code and are verified, then the software used in the isolation method is mission/cyber critical, and the rest of the software is not mission/cyber critical.
* The intent is to prevent non-mission critical functions/failures from having mission impact. For example some real time operating systems do threading or have the ability to isolate tasks where a failure of one task doesn't affect the spacecraft overall
The spacecraft shall isolate [Program-defined] mission critical functionality from non-mission critical functionality by means of an isolation boundary (implemented via partitions) that controls access to and protects the integrity of, the hardware, software, and firmware that provides that functionality. {SV-AC-6} {SC-3}
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 spacecraft security deems it necessary. {SV-AC-6} {SC-4}
The spacecraft data within partitioned applications shall not be read or modified by other applications/partitions. {SV-AC-6} {SC-4,SC-6}
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-6}
The spacecraft shall maintain a separate execution domain for each executing process. {SV-AC-6} {SC-7(21),SC-39}
The spacecraft shall implement boundary protections to separate bus, communications, and payload components supporting their respective functions. {SV-AC-6} {SC-7(21)}
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} {SC-4}
The spacecraft shall prevent unauthorized and unintended information transfer via shared system resources. {SV-AC-6} {SC-4}
The spacecraft flight software must not be able to tamper with the security policy or its enforcement mechanisms. {SV-AC-6} {SC-3}
The Program shall define the resources to be allocated to protect the availability of system resources. {SV-AC-6} {SC-6}
The Program defines the security safeguards to be employed to protect the availability of system resources. {SV-AC-6} {SC-6,SI-17}
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 spacecraft protects the availability of resources by allocating [Program-defined] resources based on [priority and/or quota]. {SV-AC-6} {SC-6}
Related SPARTA Techniques and Sub-Techniques
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.
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.
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.
Threat actors may abuse internal commanding to replay bus traffic within the victim spacecraft. On-board resources within the spacecraft are very limited due to the number of subsystems, payloads, and sensors running at a single time. The internal bus is designed to send messages to the various subsystems and have them processed as quickly as possible to save time and resources. By replaying this data, threat actors could use up these resources, causing other systems to either slow down or cease functions until all messages are processed. Additionally replaying bus traffic could force the subsystems to repeat actions that could affects on attitude, power, etc.
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.
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 to laterally move to another area of the spacecraft.
Conduct a criticality analysis to identify mission critical functions, critical components, and data flows and reduce the vulnerability of such functions and components through secure system design. Focus supply chain protection on the most critical components/functions. Leverage other countermeasures like segmentation and least privilege to protect the critical components.
Develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including tamper resistance and protection against the introduction of malicious code or hardware.Â
Conduct a supplier review prior to entering into a contractual agreement with a contractor (or sub-contractor) to acquire systems, system components, or system services.
Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment.
A component of cybersecurity to deny unauthorized persons information derived from telecommunications and to ensure the authenticity of such telecommunications. COMSEC includes cryptographic security, transmission security, emissions security, and physical security of COMSEC material. It is imperative to utilize secure communication protocols with strong cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission. Systems should also maintain the confidentiality and integrity of information during preparation for transmission and during reception. Spacecraft should not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). The cryptographic mechanisms should identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters.
Authenticate all communication sessions (crosslink and ground stations) for all commands before establishing remote connections using bidirectional authentication that is cryptographically based. Adding authentication on the spacecraft bus and communications on-board the spacecraft is also recommended.
The spacecraft should protect system components, associated data communications, and communication buses in accordance with TEMPEST controls to prevent side channel / proximity attacks. Encompass the spacecraft critical components with a casing/shielding so as to prevent access to the individual critical components.
Prevent unauthorized and unintended information transfer via shared system resources. 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
In addition to authentication on-board the spacecraft bus, encryption is also recommended to protect the confidentiality of the data traversing the bus.
In order to secure the development environment, the first step is understanding all the devices and people who interact with it. Maintain an accurate inventory of all people and assets that touch the development environment. Ensure strong multi-factor authentication is used across the development environment, especially for code repositories, as threat actors may attempt to sneak malicious code into software that's being built without being detected. Use zero-trust access controls to the code repositories where possible. For example, ensure the main branches in repositories are protected from injecting malicious code. A secure development environment requires change management, privilege management, auditing and in-depth monitoring across the environment.
Terminate the connection associated with a communications session at the end of the session or after an acceptable amount of inactivity which is established via the concept of operations.
Employ the principle of least privilege, allowing only authorized processes which are necessary to accomplish assigned tasks in accordance with system functions. Ideally maintain a separate execution domain for each executing process.
Provide additional protection modes for commanding the spacecraft. These can be where the spacecraft will restrict command lock based on geographic location of ground stations, special operational modes within the flight software, or even temporal controls where the spacecraft will only accept commands during certain times.
This countermeasure is focused on the protection of terrestrial assets like ground networks and development environments/contractor networks, etc. Traditional detection technologies and capabilities would be applicable here. Utilizing resources from NIST CSF to properly secure these environments using identify, protect, detect, recover, and respond is likely warranted. Additionally, NISTIR 8401 may provide resources as well since it was developed to focus on ground-based security for space systems (https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8401.ipd.pdf). Furthermore, the MITRE ATT&CK framework provides IT focused TTPs and their mitigations https://attack.mitre.org/mitigations/enterprise/. Several recommended NIST 800-53 Rev5 controls are provided for reference when designing ground systems/networks.
Monitor defined telemetry points for malicious activities (i.e., jamming attempts, commanding attempts (e.g., command modes, counters, etc.)). This would include valid/processed commands as well as commands that were rejected. Telemetry monitoring should synchronize with ground-based Defensive Cyber Operations (i.e., SIEM/auditing) to create a full space system situation awareness from a cybersecurity perspective.
Utilize on-board intrusion detection/prevention system that monitors the mission critical components or systems and audit/logs actions. The IDS/IPS should have the capability to respond to threats (initial access, execution, persistence, evasion, exfiltration, etc.) and it should address signature-based attacks along with dynamic never-before seen attacks using machine learning/adaptive technologies. The IDS/IPS must integrate with traditional fault management to provide a wholistic approach to faults on-board the spacecraft. Spacecraft should select and execute safe countermeasures against cyber-attacks.  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 — with or without ground support. 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.
Smart contracts can be used to mitigate harm when an attacker is attempting to compromise a hosted payload. Smart contracts will stipulate security protocol required across a bus and should it be violated, the violator will be barred from exchanges across the system after consensus achieved across the network.
Identify the key system components or capabilities that require isolation through physical or logical means. Information should not be allowed to flow between partitioned applications unless explicitly permitted by security policy. Isolate mission critical functionality from non-mission critical functionality by means of an isolation boundary (implemented via partitions) that controls access to and protects the integrity of, the hardware, software, and firmware that provides that functionality. Enforce approved authorizations for controlling the flow of information within the spacecraft and between interconnected systems based on the defined security policy that information does not leave the spacecraft boundary unless it is encrypted. Implement boundary protections to separate bus, communications, and payload components supporting their respective functions.
Before engaging in an On-orbit Servicing, Assembly, and Manufacturing (OSAM) mission, verification of servicer should be multi-factor authenticated/authorized by both the serviced's ground station and the serviced asset.
Establish alternate physical medium for networking based on threat model/environment. For example, fiber optic cabling is commonly perceived as a better choice in lieu of copper for mitigating network security concerns (i.e., eavesdropping / traffic flow analysis) and this is because optical connections transmit data using light, they don’t radiate signals that can be intercepted.
Utilize TRANSEC in order to prevent interception, disruption of reception, communications deception, and/or derivation of intelligence by analysis of transmission characteristics such as signal parameters or message externals. Note: TRANSEC is that field of COMSEC which deals with the security of communication transmissions, rather than that of the information being communicated.