Introducing SPARTA using PCSpooF: Cyber Security for Space Missions
The SPARTA framework offers space professionals a taxonomy of potential cyber threats to spacecraft and space missions. The PCSpooF academic research is mapped to the framework in an illustrative use case.
Authors: Adam Byerly, Gregory Falco, Brandon Bailey, Tim Dafoe, Brad Roeher
Why SPARTA was created
In 2013, MITRE created the ATT&CK framework to document common tactics, techniques, and procedures (TTPs) used by adversaries against enterprise networks. While the framework assists organizations in better understanding, visualizing, anticipating, and defending against cyber-attack, its taxonomy of offense and defense also provides cyber security disciplines, from threat intelligence to network defense, with a common language.
A similar and growing need exists for identifying, categorizing, and sharing space-cyber TTPs — with the same “adversary perspective” and context that ATT&CK offers. In response, The Aerospace Corporation (Aerospace) has created the Space Attack Research and Tactic Analysis (SPARTA) framework to meet this need. SPARTA intends to provide information to space professionals about how spacecraft and space missions may be compromised via cyber means and builds a taxonomy of defined activities that can contribute to spacecraft compromises. But like ATT&CK, SPARTA defines mitigations too — meaning that SPARTA as a whole can help guide space professionals in activities that range from space-cyber threat modelling and assessments, to subsystem design and building space-cyber resilience.
The “new space” evolution — more players, new technology, and a dramatically reduced barrier for entry — has only underscored the critical gaps that SPARTA serves to address, as all these factors now collide with our modern and substantially adversarial information environment. These gaps range from lapses in harmonization between far-flung catalogues of potential threats and incomplete TTPs, to a lack of information dissemination and ways to communicate information in a machine-digestible manner (i.e., STIX-compliant). In the same way that Information Technology and Operational Technology stakeholders have done before, the growing number of space-cyber practitioners from all sectors can learn from the past, and use SPARTA as a means to normalize taxonomy, countermeasures, and best practices across the community.
As with ATT&CK, the SPARTA framework is a living document; through a combination of space-cyber community input, and aggregation of unclassified research from both academia and Federally Funded Research and Development Centers (FFRDCs), it will evolve and advance over time. But unlike ATT&CK, SPARTA takes a view to the “art of the possible” — and will include TTPs of potential attack utility, not just observed or likely behavior. This fundamental difference enables a shift from retroactive analysis into proactive analysis — one of Aerospace’s key goals with SPARTA. The space community will be better positioned to understand TTPs, identify associated countermeasures, and defend spacecraft and space missions. SPARTA can also be used as the basis for testing the efficacy of security solutions in development environments, ground systems, and spacecraft subsystems.
What is SPARTA?
Like the ATT&CK framework, SPARTA is organized around the pre-attack, attack, and post-attack stages: reconnaissance, resource development, initial access, execution, exfiltration, persistence, defense evasion, lateral movement, and impact. Each step lists several techniques and sub-techniques for providing more specific information about the various stages of an attack. It also includes information on the tools and infrastructure that might be used to support an attack.
Tactics: These represent the “why” of a SPARTA technique or sub-technique — the threat actor’s tactical goal, and the reason they are performing a technique. For example, a threat actor may want to achieve initial access on a spacecraft via cyber means.
Techniques: These represent “how” a threat actor achieves a tactical goal by performing a threat action. For example, a threat actor may exploit trusted relationships to achieve initial access.
Sub-techniques: These represent a variation or more specific instance of the threat actor’s behavior used to achieve a goal. Sub-techniques typically describe behavior at a lower level than a technique and are considered children of the parent technique. For example, a threat actor may compromise mission collaborators (academia, international partners, suppliers, etc.) to achieve their initial access.
Procedures: These represent specific implementations the threat actor uses for techniques or sub-techniques. Procedures are the step-by-step descriptions of how the threat actor plans to go about achieving their purpose. It details how the general techniques/sub-techniques will be carried out.
Pre-Attack: The Pre-Attack phase includes information about the reconnaissance and resource development activities that attackers typically conduct before launching an attack. This includes gathering relevant space system design information, social engineering, malware research/development, and compromising initial infrastructure.
Attack: The Attack phase includes information about the different types of attacks that can be carried out, as well as the tools and techniques that are typically used. For example, these attacks may involve leveraging initial access, such as through a compromised ground station or hosted payload, to execute an attack, such as denial-of-service, arbitrary code execution, or data exfiltration.
Post-Attack: Once an attacker has begun an attack, the Post-Attack phase includes information about the persistence, evasion, and movement techniques an attacker may employ. This may consist of compromising memory or installing a backdoor, disabling fault management systems, and/or moving to a new target in a constellation.
SPARTA Use Case: PCspooF
Among the many use cases of SPARTA is the digestible representation of new attacks discovered by security researchers or disclosed by original equipment manufacturers. Such disclosures are often written for distinct audiences that may be shrouded in jargon or academic theory; however, such language can limit the dissemination and potential impact of the findings.
An example of this is the publication of an important research paper by Andrew Loveless, Linh Thi Xuan Phan, Ronald Dreslinski and Baris Kasikci describing an attack dubbed PCspooF. The academic paper expertly articulates a vulnerability in and exploit of Time-Triggered Ethernet (TTE), which is used as a bus service for a variety of spacecraft including NASA’s Orion capsule, NASA’s Lunar Gateway space station, and ESA’s Ariane 6 launcher — among others.
Written for an academic audience, the paper details the essential history of TTE, the nuances of the vulnerability and the attack implementation; however, it may be challenging for operators to digest. To improve the dissemination of this important vulnerability discovery to the space system community, we have distilled the findings into the SPARTA framework as seen below. We hope that this distillation improves the useability of the critical research of Loveless et. al, in order to reach space system operators who can remediate the issue in their implementations. Further, we hope this serves as a model that illustrates how future space vehicle security research can be transformed into the digestible SPARTA framework.
Leveraging the PCspooF publication, TTPs were extracted and mapped, and an attack chain was developed using SPARTA. This attack chain is hypothetical but is meant to describe the steps a threat actor would take to exploit PCspooF, and successfully inject malicious/spurious protocol control frames (PCFs), on a space system that is using TTE.
Reconnaissance [ST0001] has to occur to understand the spacecraft’s TTE implementation and a delivery vector. The threat actor would also have to perform Resource Development [ST0002] to stage and deliver the exploit/implant to achieve Initial Access [ST0003], followed by Execution [ST0004] of the PCspooF technique and Lateral Movement [ST0007] to achieve the desired Impact [ST0009].
The bulleted list below provides mapped example techniques under each tactic to describe the method in which a threat actor could achieve their goal of mission disruption by means of the PCspooF TTE vulnerability.
Reconnaissance [ST0001]
- Gather Spacecraft Design Information [REC-0001]
- Data Bus [REC-0001.04] (i.e., gather any information required for
successful EMI attack and PCF spoofing — e.g., a likely virtual link ID) - Gather Supply Chain Information [REC-0008]
- Hardware [REC-0008.01] (i.e., gather any information on the hardware in use, TTE utilization, EMI target, etc.)
- Eavesdropping [REC-0005] (i.e., eavesdropping on the network, listening to device responses to learn enough to spoof PCFs)
Resource Development [ST0002]
- Stage Capabilities [RD-0004]
- Identify/Select Delivery Mechanism [RD-0004.01] (i.e., identify the
ideal BE device or other hardware to target and implant)
Initial Access [ST0003]
- Compromise Supply Chain [IA-0001]
- Hardware Supply Chain [IA-0001.03] (i.e., conduct the activity to place a potential best-effort traffic [BE] device or other hardware implant)
- Auxiliary Device Compromise [IA-0011] (i.e., potential for use of a generic/USB hardware vector)
Execution [ST0004]
- Time Synchronized Execution [EX-0008]
- Flooding [EX-0013]
- Erroneous Input [EX-0013.02] (i.e., generate forged ARP and the malicious EMI to target TTE switch hardware)
- Exploit Hardware/Firmware Corruption [EX-0005]
- Design Flaws [EX-0005.01] (i.e., exploit the weaknesses that allow for forged ARP polling of BE devices, collecting information, and spoofing of PCFs — e.g., ability to infer/determine/brute-force virtual link ID and critical traffic marker, long preamble abuse)
- Spoofing [EX-0014]
- Bus Traffic [EX-0014.02] (i.e., conduct the actual exploitation via injection of spoofed PCFs)
Lateral Movement [ST0007]
- Exploit Lack of Bus Segregation [LM-0002] (i.e., due to critical/non-critical components sharing the same physical networking infrastructure, this attack enables non-critical hardware components to affect critical components)
Impact [ST0009]
- Disruption [IMP-0003] (i.e., TTE synchronization broken, critical actions not being performed, disruption to critical spacecraft operations/manoeuvring, risk to mission)
Closing Thoughts
While SPARTA has several use cases, being a normalized/standard nomenclature for threat information is among its biggest benefits. As shown with PCspooF, extracting the tactics and techniques that are associated with launching an attack leveraging this novel exposure provides benefit to the community, in terms of more immediate understanding as to what it would take for a threat actor to exploit this vulnerability. By extracting these techniques from the informational report on PCspooF, engineers can easily map out countermeasures along the attack chain that can fully mitigate or reduce the risk of occurrence.
From protecting spacecraft design information to reducing the risk of reconnaissance and device polling, to applying more rigor to the hardware supply chain, or implementing better segmentation for mission critical data flows, SPARTA provides countermeasures against tactics and their supporting techniques. While educating on spacecraft TTPs is one goal of SPARTA, its primary goal is ensuring engineers are informed on the countermeasures available to aid in mitigation. A future article will discuss how to use SPARTA to identify countermeasures.
SPARTA TTPs will evolve over time as new information becomes available through security researchers, and space-cyber threat intelligence is shared across the community. In the past, space-cyber threat information has not been widely distributed due to various factors. With the increase of commercial space activity and capabilities, however, the community appears to be shifting to align with more traditional IT practices and threat information sharing — as demonstrated with the ViaSat cyber incident in February, and the PCspooF report.
Additionally, with the initial operating capability of the Space Information Sharing Analysis Center’s Watch Center occurring in 2023, SPARTA will soon be able to leverage TTPs being shared across the community given the goal of tight integration with the Watch Center. Ideally, as informational reports like PCspooF are distributed and threat intelligence reports are produced on space-cyber issues, report authors will leverage SPARTA’s TTPs and countermeasures within their publications to promote community standardization on space-cyber information. When standardization occurs, it can enable better tracking of TTPs and more readily convey how threat actors could attack, or are attacking, space systems.
SPARTA was created to provide information to space professionals about how spacecraft and space missions may be compromised via cyber means. The framework defines and categorizes commonly identified activities that contribute to spacecraft compromises. Future articles will discuss in more detail the topics covered in this post, such as the use and development of specific SPARTA countermeasures.
