SPARTA: CYBER SECURITY FOR SPACE MISSIONS
A Look into SPARTA Countermeasures
SPARTA’s mission is to ensure space system engineers are informed about countermeasures available to aid in mitigation.
Authors: Brandon Bailey, Tim Dafoe
Educating the space community on spacecraft tactics, techniques, and procedures (TTPs) is one goal of SPARTA, but equally important is ensuring space system engineers are informed about countermeasures available to aid in mitigation.
While TTPs are important to understand a threat actor’s “why” and “how,” ensuring relevant technical and administrative countermeasures are in place is imperative. According to NIST, countermeasures are defined as “protective measures prescribed to meet the security objectives, i.e., confidentiality, integrity, and availability, specified for an information system. Safeguards may include security features, management controls, personnel security, and security of physical structures, areas, and devices”.
Catch up on SPARTA with Introducing SPARTA Using PCSpoof: Cyber Security for Space Missions
In the context of a spacecraft, some example countermeasures include protecting spacecraft design information from exfiltration, applying more rigor to the hardware/software supply chain, ensuring communication security (COMSEC) and/or transmission security (TRANSEC), or implementing better segmentation for mission-critical data flows onboard the spacecraft bus.
SPARTA provides countermeasures against tactics and their supporting techniques. These countermeasures will be enhanced over time as new TTPs are published and space-cyber defensive technology matures.
SPARTA countermeasures are grounded in experience and industry standards, drawing from sources like Security and Privacy Controls for Information Systems and Organizations (NIST SP 800–53 Rev. 5), whenever those controls are relevant in space-cyber contexts. SPARTA leverages The Aerospace Corporation’s defense-in-depth (DiD) model for space systems, as described in the paper, Cybersecurity Protections for Spacecraft: A Threat Based Approach.
The example of PCspooF will be used to describe SPARTA countermeasures.
Catching up with PCspooF and the Evolution of Countermeasures
Previously, we discussed the PCspooF attack against Time-Triggered Ethernet (TTE) implementations that are commonly used on spacecraft. We went into detail about the academic paper findings and the subsequent mapping to SPARTA tactics, techniques, and procedures (TTPs).
While helpful in understanding and sharing the nature of the PCspooF attack, TTP mapping is only part of what SPARTA offers practitioners. SPARTA countermeasures allow for identification of security concepts and technologies for preventing a space-cyber technique or sub-technique from being successfully executed against a target. Countermeasures can also help mitigate adverse outcomes/impacts to spacecraft and missions.
Completing a SPARTA mapping for PCspooF highlighted a key dimension for all space-cyber countermeasure development and refinement—countermeasures can and must evolve to address emerging research and new TTPs. Several mitigations discussed within the PCspooF paper were not previously covered by countermeasures in SPARTA.
The attack necessitated expanding our countermeasures selection beyond what was available within the previous v1.1 revision of SPARTA. As mentioned in our v1.2 update, these new countermeasures will help address weaknesses beyond PCspooF.
To illustrate the development of these new SPARTA countermeasures, we will explore some of the proposed mitigations from the PCspooF paper.
Block EMI
In the paper’s first mitigation recommendation, the authors proposed the prevention of malicious EMI from reaching target TTE switch modules by eliminating conductive physical media, e.g., using fiber optic cable instead, or by isolating or protecting devices from Erroneous Input [EX-0013.02].
The paper highlights practical reasons to not pursue these methods in typical TTE implementation environments as a primary safeguard. However, the option to select optical fiber and real-world implementation experience among our space cybersecurity subject matter experts suggested that SPARTA document deliberate physical media selection for this or other assurance purposes.
Countermeasure CM0071 (Communication Physical Medium) was added to SPARTA v1.2 as a result, describing the use of an “alternate physical medium for networking based on threat model/environment”.
Check the preamble length / Hide key PCF fields
These two mitigations address very clear Reconnaissance [ST0001] exposures and opportunities to exploit Design Flaws [EX-0005.01] within the commercially-available TTE hardware evaluated. Key identifiers that enable this attack, e.g., Critical Traffic Marker and Virtual Link ID, are either too readily and reliably deduced or are values set within narrow ranges offering so little brute force resistance they could be simply obtained given the speed and efficacy of the network TTPs.
The paper indicates that mitigations for all of these issues would “require changes to the TTE hardware” and discloses that TTE vendor efforts are underway. It also mentions that SAE is pursuing mitigation via changes to the AS6802 TTE standard, i.e., to match the maximum PCF size to the full size of an Ethernet frame. In other words, in an effort to prevent the paper’s BE “transform” attack, SAE would amend the protocol.
Those who have followed the evolution of the Domain Name System (DNS) or Transport Layer Security (TLS) understand that fundamental changes are at times necessary to maintain resilience and assurance within a protocol over time. SPARTA was updated to include countermeasure CM0072 (Protocol Update / Refactoring) as protocols, whether nascent or well-established, “can have vulnerabilities within their specification and may require updating or refactoring”, or can be subject to novel/emerging threats.
Practical Limits
Some proposed PCspooF mitigations face practical limitations. Attempting to index and validate MAC addresses to thwart spoofed PCFs isn’t consistent with how trivially forged MAC values are. Nor is the likelihood that PCspooF attackers — who we must remember in this scenario are understood to have capably conducted a supply chain attack and successfully accessed a target in space — successfully determine the MAC of a valid compression master as well.
Use of 802.1AE (or “MACsec”) would offer link-layer cryptographic protection, and bolster confidentiality, integrity, and authenticity. Like many link-layer security schemes, however, it imposes complexity for implementers and overhead that may not be desired even in far less constrained environments. Ideally, mitigations for this attack would not require careful configuration to avoid disrupting TTE synchronization. Some layer two protocols that benefit from MACsec protection may also be disabled on hardened onboard networks aboard some spacecraft.
Increasing the number of sync masters or attempting to strategically place compression masters (two additional proposed mitigations) may not be possible in physically small or constrained TTE environments. Such methods may risk impinging on the simplicity of TTE.
Tailoring to Threats
Mitigations must make sense in context. It is expected that implementers will interpret and tailor SPARTA countermeasures in ways relevant to environments and threat models. Those familiar with NIST SP 800–53 will also understand that SPARTA countermeasures map to Rev. 5 controls that include many “organization-defined parameters.”
These parameters vary in nature and purpose, e.g., durations/frequencies, roles, etc., but are derived from local requirements, mission/business needs, assessments, and risk tolerance. Practitioners should work to establish these metrics for their missions to inform the way in which countermeasures are deployed.
Additionally, not all organizations will pursue the same countermeasure at the same level, using the same technology, or with the same degree of assurance. For example, CM0002 refers to COMSEC as a countermeasure — but the nature and robustness of implementation and supporting operations will vary considerably based on organization and mission type.
For example, according to NASA Standard 1006, the baseline mission encryption standard requires protection of the command stack with cryptography that “meets or exceeds the Federal Information Processing Standard (FIPS) 140, Security Requirements for Cryptographic Modules, Level 1.” Some missions may refer to published Consultative Committee for Space Data Systems (CCSDS) guidance on algorithms, keying, and interoperability. For national security systems and missions, however, CNSSP 12 requirements for COMSEC apply, requiring National Security Agency (NSA) approved encryption solutions.
SPARTA countermeasures will therefore point to a security concept, not a specific implementation. Where applicable, correlations to NIST 800–53 control(s) and Aerospace’s Defense-in-Depth model will be made. The goal is to ensure space system engineers are aware of the potential options available to reduce risk and/or mitigate the TTPs.
Planning, Design, and Response
When contending with attacks and execution of TTPs against a space system, there will be countermeasures more immediate in both usage and effect and those that protect long term. Typically, immediate courses of action are defined in an incident response plan.
Every space system/mission should have protocols and plans that address space-cyber incident response as part of their overall cybersecurity and survivability strategy. Details will differ for each organization or even by mission. According to SANS, they should contain elements involving preparation, identification, containment, eradication, recovery, and lessons learned. Immediate courses of action, in deploying countermeasures or changes in response to incidents or attacks, are typically characterized as short-term containment, eradication, and recovery.
SPARTA countermeasures, however, tend to be security principles or controls designed into a system from the beginning or represent changes that can take time to implement. Some kinds of changes are not always possible to make during spaceflight, unfortunately. Therefore, SPARTA countermeasures will tend to support preparation, identification, long-term containment, eradication, and recovery.
This is an important distinction, as SPARTA countermeasures are not intended to be a replacement for short-term incident response and planning. SPARTA helps space professionals ensure the necessary security principles and controls are in place. These controls are implemented so missions are best prepared for in-scope adverse events with the ability to identify, contain, eradicate, and recover should TTPs be executed against space systems.
Closing Thoughts
As security researchers publish vulnerabilities like PCspooF, and intelligence reports are generated by entities like the Space ISAC’s Watch Center, SPARTA tactics, techniques, and countermeasures will continually evolve. As the space-cyber industry continues to mature, SPARTA will grow with it.
Please visit the contribute page or send comments, additions, etc. via email to sparta@aero.org.
New to SPARTA on Medium? Catch up on the Aerospace TechBlog.
