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.
Organizations should look to identify and properly classify mission sensitive design/operations information (e.g., fault management approach) and apply access control accordingly. Any location (ground system, contractor networks, etc.) storing design information needs to ensure design info is protected from exposure, exfiltration, etc. Space system sensitive information may be classified as Controlled Unclassified Information (CUI) or Company Proprietary. Space system sensitive information can typically include a wide range of candidate material: the functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry 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, CUI, proprietary, 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. Sensitive documentation should only be accessed by personnel with defined roles and a need to know. Well established access controls (roles, encryption at rest and transit, etc.) and data loss prevention (DLP) technology are key countermeasures. The DLP should be configured for the specific data types in question.
Establish policy and procedures to prevent individuals (i.e., insiders) from masquerading as individuals with valid access to areas where commanding of the spacecraft is possible. Establish an Insider Threat Program to aid in the prevention of people with authorized access performing malicious activities.
Utilize a two-person system to achieve a high level of security for systems with command level access to the spacecraft. Under this rule all access and actions require the presence of two authorized people at all times.
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.
Vulnerability scanning is used to identify known software vulnerabilities (excluding custom-developed software - ex: COTS and Open-Source). Utilize scanning tools to identify vulnerabilities in dependencies and outdated software (i.e., software composition analysis). Ensure that vulnerability scanning tools and techniques are employed that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: (1) Enumerating platforms, custom software flaws, and improper configurations; (2) Formatting checklists and test procedures; and (3) Measuring vulnerability impact.
Generate Software Bill of Materials (SBOM) against the entire software supply chain and cross correlate with known vulnerabilities (e.g., Common Vulnerabilities and Exposures) to mitigate known vulnerabilities. Protect the SBOM according to countermeasures in CM0001.
Ensure proper protections are in place for ensuring dependency confusion is mitigated like ensuring that internal dependencies be pulled from private repositories vice public repositories, ensuring that your CI/CD/development environment is secure as defined in CM0004 and validate dependency integrity by ensuring checksums match official packages.
Create prioritized list of software weakness classes (e.g., Common Weakness Enumerations), based on system-specific considerations, to be used during static code analysis for prioritization of static analysis results.
Define acceptable coding standards to be used by the software developer. The mission should have automated means to evaluate adherence to coding standards. The coding standard should include the acceptable software development language types as well. The language should consider the security requirements, scalability of the application, the complexity of the application, development budget, development time limit, application security, available resources, etc. The coding standard and language choice must ensure proper security constructs are in place.
Employ dynamic analysis (e.g., using simulation, penetration testing, fuzzing, etc.) to identify software/firmware weaknesses and vulnerabilities in developed and incorporated code (open source, commercial, or third-party developed code). Testing should occur (1) on potential system elements before acceptance; (2) as a realistic simulation of known adversary tactics, techniques, procedures (TTPs), and tools; and (3) throughout the lifecycle on physical and logical systems, elements, and processes. FLATSATs as well as digital twins can be used to perform the dynamic analysis depending on the TTPs being executed. Digital twins via instruction set simulation (i.e., emulation) can provide robust environment for dynamic analysis and TTP execution.
Perform static source code analysis for all available source code looking for system-relevant weaknesses (see CM0016) using no less than two static code analysis tools.
Prevent the installation of Flight Software without verification that the component has been digitally signed using a certificate that is recognized and approved by the mission.
Use automated mechanisms to maintain and validate baseline configuration to ensure the spacecraft's is up-to-date, complete, accurate, and readily available.
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.
Employ physical security controls (badge with pins, guards, gates, etc.) to prevent unauthorized access to the systems that have the ability to command the spacecraft.
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.
Software/Firmware must verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order. The trusted boot/RoT computing module should be implemented on radiation tolerant burn-in (non-programmable) equipment.
A legitimate command is sent, but with parameters that exceed safe thresholds for a subsystem or component on the spacecraft. This could include commands that affect critical subsystems like power distribution, attitude control, or thermal regulation, potentially leading to damage, instability, or malfunction. The misuse of valid parameters across different subsystems can result in severe operational impact or hardware degradation.
[x-opencti-command-log:command_type = 'legitimate_command' AND x-opencti-command-log:target_subsystem != 'expected_subsystem' AND x-opencti-command-log:parameter_value > 'safe_threshold']
Detects the initiation of the CLTU-START, CLTU-STOP, or CLTU-UNBIND commands by either an unauthorized user or a rogue IP address (even with valid credentials), potentially indicating malicious activity targeting session control.
[(x-opencti-command-log:command = 'CLTU-START' OR x-opencti-command-log:command = 'CLTU-STOP' OR x-opencti-command-log:command = 'CLTU-UNBIND') AND (x-opencti-command-log:user != 'authorized_user' OR network-traffic:src_ref.value != 'authorized_ip')]
Detects that credentials in the CLTU-BIND message were transmitted without encryption, making them vulnerable to capture and replay attacks. The Space Link Extension (SLE) protocol itself does not provide built-in encryption for securing the data transmitted through its services. The protocol focuses on the extension of space link operations between ground systems, but it lacks native security features such as encryption. The SLE protocol was designed to facilitate operational efficiency rather than providing security mechanisms. Any security (including encryption) typically happens outside of the SLE protocol, through mechanisms such as bulk encryption at the hardware layer or via an external transport security layer (e.g., IPsec or TLS) added on top of the communication channels. Encryption is usually implemented at the hardware level (bulk encryption) or applied to the transport layer through external protocols. This ensures that the data exchanged between the SLE User (Mission Control System) and the SLE Provider (Ground Station) is protected during transmission.
[network-traffic:dst_ref.value = 'SLE_Provider' AND network-traffic:encryption_status != 'encrypted']
Detection of a user account or cryptographic key being used outside of the expected operational time windows. This may indicate unauthorized or suspicious activity, such as a threat actor using valid credentials or cryptographic keys to gain or maintain persistent access to the spacecraft or related systems.
[user-account:last_login_time != 'expected_operational_hours' OR x-opencti-cryptographic-key:usage_time != 'expected_usage_time']
Detection of network traffic originating from an unauthorized IP address that does not match any of the known or authorized ground station IPs, potentially indicating communication with a rogue ground station. The source IPs that are permitted to speak to the spacecraft should be very limited. Rogue devices may get deployed internal to mission operations networks in an attempt to communicate to the spacecraft.
[network-traffic:src_ref.value != 'authorized_ground_station_ip' AND network-traffic:protocols[*] = 'satellite_communication']
Rogue IP found communicating between the MOC and ground station which could indicate ARP Spoofing is occuring, or some other man-in-the-middle is going on.
[network-traffic:src_ref.role = 'ground_station' AND network-traffic:dst_ref.role = 'mission_control_system' AND network-traffic:src_ref.value != 'authorized_ip']
Detection of unexpected communication protocols in the uplink traffic from a ground station or any rogue device (i.e., spacecraft), indicating that someone may be using non-standard protocols to communicate with the spacecraft.
[network-traffic:protocols[*] != 'expected_protocol' AND network-traffic:direction = 'uplink']
Detection of larger-than-expected data packets sent during scheduled spacecraft communication windows, indicating that a compromised ground system may be exfiltrating data under the guise of legitimate operations.
[network-traffic:direction = 'downlink' AND network-traffic:data_size > 'expected_size']
Detection of failed authentication attempts on spacecraft systems potentially caused by RF or EMI interference. This indicator focuses on identifying anomalies in the RF communication environment, such as signal strength variations that do not correspond with legitimate communication patterns. Such anomalies may indicate an attempt to spoof communication signals or interfere with the authentication process to gain unauthorized access. Monitoring these failed attempts, especially when correlated with suspicious RF activity, helps in identifying and mitigating potential security threats.
[x-opencti-radio-communication:signal_strength = 'unexpected_variation' AND x-opencti-authentication-log:status = 'failed' AND x-opencti-authentication-log:source_location NOT IN ('list_of_known_ground_stations')]
Detects a failure in authentication during the CLTU BIND process. This IOC detects any authentication failure during the CLTU BIND process. It captures a general case where the authentication does not succeed.
[x-opencti-command-log:command = 'CLTU-BIND' AND x-opencti-command-log:authentication_result = 'failure']
Detects an authorized SLE session established by the attacker using replayed / captured credentials, gaining control of the session. This is when attacker has valid credentials to establish the bind
[x-opencti-command-log:command = 'CLTU-BIND' AND x-opencti-command-log:user = 'authorized_user' AND network-traffic:src_ref.value != 'authorized_ip']