|| Countermeasure Not Identified
||This technique is a result of utilizing TTPs to create an impact and the applicable countermeasures are associated with the TTPs leveraged to achieve the impact
|| Protect Sensitive Information
||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.
|| Threat Intelligence Program
||A threat intelligence program helps an organization generate their own threat intelligence information and track trends to inform defensive priorities and mitigate risk. Leverage all-source intelligence services or commercial satellite imagery to identify and track adversary infrastructure development/acquisition. Countermeasures for this attack fall outside the scope of the mission in the majority of cases.
|| Tamper Protection
||Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment.
|| Insider Threat Protection
||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.
|| Two-Person Rule
||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.
|| Space Domain Awareness
||The credibility and effectiveness of many other types of defenses are enabled or enhanced by the ability to quickly detect, characterize, and attribute attacks against space systems. Space domain awareness (SDA) includes identifying and tracking space objects, predicting where objects will be in the future, monitoring the space environment and space weather, and characterizing the capabilities of space objects and how they are being used. Exquisite SDA—information that is more timely, precise, and comprehensive than what is publicly available—can help distinguish between accidental and intentional actions in space. SDA systems include terrestrial-based optical, infrared, and radar systems as well as space-based sensors, such as the U.S. military’s Geosynchronous Space Situational Awareness Program (GSSAP) inspector satellites. Many nations have SDA systems with various levels of capability, and an increasing number of private companies (and amateur space trackers) are developing their own space surveillance systems, making the space environment more transparent to all users.*
||Satellite maneuver is an operational tactic that can be used by satellites fitted with chemical thrusters to avoid kinetic and some directed energy ASAT weapons. For unguided projectiles, a satellite can be commanded to move out of their trajectory to avoid impact. If the threat is a guided projectile, like most direct-ascent ASAT and co-orbital ASAT weapons, maneuver becomes more difficult and is only likely to be effective if the satellite can move beyond the view of the onboard sensors on the guided warhead.*
|| Stealth Technology
||Space systems can be operated and designed in ways that make them difficult to detect and track. Similar to platforms in other domains, stealthy satellites can use a smaller size, radar-absorbing coatings, radar-deflecting shapes, radar jamming and spoofing, unexpected or optimized maneuvers, and careful control of reflected radar, optical, and infrared energy to make themselves more difficult to detect and track. For example, academic research has shown that routine spacecraft maneuvers can be optimized to avoid detection by known sensors.*
|| Defensive Jamming and Spoofing
||A jammer or spoofer can be used to disrupt sensors on an incoming kinetic ASAT weapon so that it cannot steer itself effectively in the terminal phase of flight. When used in conjunction with maneuver, this could allow a satellite to effectively “dodge” a kinetic attack. Similar systems could also be used to deceive SDA sensors by altering the reflected radar signal to change the location, velocity, and number of satellites detected, much like digital radio frequency memory (DRFM) jammers used on many military aircraft today. A spacebased jammer can also be used to disrupt an adversary’s ability to communicate.*
*https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQGate with an ASAT weapon.
|| Deception and Decoys
||Deception can be used to conceal or mislead others on the “location, capability, operational status, mission type, and/or robustness” of a satellite. Public messaging, such as launch announcements, can limit information or actively spread disinformation about the capabilities of a satellite, and satellites can be operated in ways that conceal some of their capabilities. Another form of deception could be changing the capabilities or payloads on satellites while in orbit. Satellites with swappable payload modules could have on-orbit servicing vehicles that periodically move payloads from one satellite to another, further complicating the targeting calculus for an adversary because they may not be sure which type of payload is currently on which satellite. Satellites can also use tactical decoys to confuse the sensors on ASAT weapons and SDA systems. A satellite decoy can consist of an inflatable device designed to mimic the size and radar signature of a satellite, and multiple decoys can be stored on the satellite for deployment when needed. Electromagnetic decoys can also be used in space that mimic the RF signature of a satellite, similar to aircraft that use airborne decoys, such as the ADM-160 Miniature Air-launched Decoy (MALD).*
|| Antenna Nulling and Adaptive Filtering
||Satellites can be designed with antennas that “null” or minimize signals from a particular geographic region on the surface of the Earth or locations in space where jamming is detected. Nulling is useful when jamming is from a limited number of detectable locations, but one of the downsides is that it can also block transmissions from friendly users that fall within the nulled area. If a jammer is sufficiently close to friendly forces, the nulling antenna may not be able to block the jammer without also blocking legitimate users. Adaptive filtering, in contrast, is used to block specific frequency bands regardless of where these transmissions originate. Adaptive filtering is useful when jamming is consistently within a particular range of frequencies because these frequencies can be filtered out of the signal received on the satellite while transmissions can continue around them. However, a wideband jammer could interfere with a large enough portion of the spectrum being used that filtering out the jammed frequencies would degrade overall system performance. *
|| Physical Seizure
||A space vehicle capable of docking with, manipulating, or maneuvering other satellites or pieces of debris can be used to thwart spacebased attacks or mitigate the effects after an attack has occurred. Such a system could be used to physically seize a threatening satellite that is being used to attack or endanger other satellites or to capture a satellite that has been disabled or hijacked for nefarious purposes. Such a system could also be used to collect and dispose of harmful orbital debris resulting from an attack. A key limitation of a physical seizure system is that each satellite would be time- and propellant-limited depending on the orbit in which it is stored. A system stored in GEO, for example, would not be well positioned to capture an object in LEO because of the amount of propellant required to maneuver into position. Physical seizure satellites may need to be stored on Earth and deployed once they are needed to a specific orbit to counter a specific threat.*
|| Filtering and Shuttering
||Filters and shutters can be used on remote sensing satellites to protect sensors from laser dazzling and blinding. Filters can protect sensors by only allowing light of certain wavelengths to reach the sensors. Filters are not very effective against lasers operating at the same wavelengths of light the sensors are designed to detect because a filter that blocks these wavelengths would also block the sensor from its intended mission. A shutter acts by quickly blocking or diverting all light to a sensor once an anomaly is detected or a threshold is reached, which can limit damage but also temporarily interrupts the collection of data.*
|| Defensive Dazzling/Blinding
||Laser systems can be used to dazzle or blind the optical or infrared sensors on an incoming ASAT weapon in the terminal phase of flight. This is similar to the laser infrared countermeasures used on aircraft to defeat heat-seeking missiles. Blinding an ASAT weapon’s guidance system and then maneuvering to a new position (if necessary) could allow a satellite to effectively “dodge” a kinetic attack. It could also be used to dazzle or blind the optical sensors on inspector satellites to prevent them from imaging a satellite that wants to keep its capabilities concealed or to frustrate adversary SDA efforts.*
||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.
|| Crypto Key Management
||Leverage best practices for crypto key management as defined by organization like NIST or the National Security Agency. Leverage only approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. Encryption key handling should be performed outside of the onboard software and protected using cryptography. Encryption keys should be restricted so that they cannot be read via any telecommands.
||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.
|| Relay Protection
||Implement relay and replay-resistant authentication mechanisms for establishing a remote connection or connections on the spacecraft bus.
|| Traffic Flow Analysis Defense
||Utilizing techniques to assure traffic flow security and confidentiality to mitigate or defeat traffic analysis attacks or reduce the value of any indicators or adversary inferences. This may be a subset of COMSEC protections, but the techniques would be applied where required to links that carry TT&C and/or data transmissions (to include on-board the spacecraft) where applicable given value and attacker capability. Techniques may include but are not limited to methods to pad or otherwise obfuscate traffic volumes/duration and/or periodicity, concealment of routing information and/or endpoints, or methods to frustrate statistical analysis.
||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.
|| Shared Resource Leakage
||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
|| On-board Message Encryption
||In addition to authentication on-board the spacecraft bus, encryption is also recommended to protect the confidentiality of the data traversing the bus.
|| Development Environment Security
||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
||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.
|| Software Bill of Materials
||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.
|| Dependency Confusion
||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.
|| Software Source Control
||Prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code.
|| CWE List
||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.
|| Coding Standard
||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.
|| Dynamic Analysis
||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.
|| Static Analysis
||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.
|| Software Digital Signature
||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.
|| Configuration Management
||Use automated mechanisms to maintain and validate baseline configuration to ensure the spacecraft's is up-to-date, complete, accurate, and readily available.
|| Session Termination
||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.
|| Least Privilege
||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.
|| Secure Command Mode(s)
||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.
|| Ground-based Countermeasures
||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 Critical Telemetry Points
||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.
|| Protect Authenticators
||Protect authenticator content from unauthorized disclosure and modification.
|| Physical Security Controls
||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.
|| Alternate Communications Paths
||Establish alternate communications paths to reduce the risk of all communications paths being affected by the same incident.
|| On-board Intrusion Detection & Prevention
||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.
|| Robust Fault Management
||Ensure fault management system cannot be used against the spacecraft. Examples include: safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of telemetry to cause action from ground, or some sort of proximity operation to cause spacecraft to go into safe mode. Understanding the safing procedures and ensuring they do not put the spacecraft in a more vulnerable state is key to building a resilient spacecraft.
|| Smart Contracts
||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.
|| Secure boot
||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.
|| Disable Physical Ports
||Provide the capability for data connection ports or input/output devices (e.g., JTAG) to be disabled or removed prior to spacecraft operations.
||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.
|| OSAM Dual Authorization
||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 ground station and the serviced asset.
|| Communication Physical Medium
||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. For example, jam-resistant waveforms can be utilized to improve the resistance of radio frequency signals to jamming and spoofing. Note: TRANSEC is that field of COMSEC which deals with the security of communication transmissions, rather than that of the information being communicated.