The Space Attack Research and Tactic Analysis (SPARTA) matrix serves to ensure the space-cyber community is empowered to continually educate engineers and system defenders so they can overcome the unique cyber-threats they face in the domain. The following have been identified as potential use cases for the SPARTA matrix:
- Space System Developers
Provides a resource containing TTPs, threats, and countermeasures to enable the engineering of protections early in the lifecycle — establishing countermeasures to disrupt the attack chains - Defensive Cyber Operations
Build of monitoring solutions, analytics, automation, etc. for DCO Operators/Blue Team members, and the measuring of how effective systems/operators are at detecting TTPs for their specific space system. (Ex: These commands/telemetry possibly indicate TTP attacking the software watchdog timer {EX-0012.11}). - Threat Intelligence Reporting/Tracking of TTPs
Report data to the community tying threat actor’s TTPs against space systems using a common taxonomy.
Leverage the unique identifiers and aggregate reporting using a similar approach as the current industry standard for Enterprise IT systems. - Assessments/Table-Tops
Provides a framework for assessment engineers / red teamers to leverage for designing attack chains against the space segment - Education/Training/Research
Expands the footprint of knowledge to a wider audience – raises the bar on what is considered common knowledge.
Security researchers/Threat Intel can submit their own TTPs via email to sparta@aero.org to crowd source information similar to other ATT&CK matrices.
The relationship between tactics and techniques/sub-techniques can be visualized in the SPARTA Matrix below.
Click image to enlarge.
To demonstrate how SPARTA can be leveraged, the following attack chain was built using SPARTA to emulate an attack scenario that was explored at DefCon 28 in a presentation called Exploiting Spacecraft. Below are the TTPs leveraged within the described attack chain demonstration. Within the narrative of the attack chain, the TTP ID will be denoted with brackets ([REC-0005]). If eavesdropping were performed via radio frequency link, then the TTPs can be found within SPARTA.
Click image to enlarge
In the scenario from DefCon 28: Exploiting Spacecraft, the attacker performs a man-in-the-middle attack at the ground station where they record command packets in the UDP traffic [REC-0005, REC-0005.01] for replaying to the spacecraft [EX-0001.01]. In this example UDP mimics the radio frequency link. This same attack could be applied through RF signal sniffing [REC-0005.01, IA-0008.01] vice UDP captures. From the spacecraft perspective, the flight software processes the traffic whether or not the traffic is coded to radio frequency signals and then decoded on the spacecraft.
Upon receiving commands, the spacecraft flight software responds by downlinking command counter data to the ground indicating that commands were received [EXF-0003.02]. In this scenario, the attacker collected the commands at the ground station [EXF-0003.01, EXF-0007] and then promptly replay the traffic to the spacecraft [EX-0001.01] thereby causing the flight software to reprocess the commands again [EX-0001]. This would be visible in the downlinked command counters [REC-0005.02, EXF-0003.02] and unless the ground operators are monitoring specific telemetry points, this attack would likely go unnoticed. If the replayed commands were considered critical commands like firing thrusters, then more critical impact on the spacecraft could be encountered [IMP-0002, IMP-0004, IMP-0005].
The above scenario is only an exemplar of how SPARTA can be used to discuss attack chains in relation to attacking the spacecraft. Ideally, engineers and/or defenders would work together to determine if and how their system-of-systems is vulnerable to these specific TTPs and develop methods to detect and/or enact countermeasures within the attack chain to protect the spacecraft.
While SPARTA focuses on the spacecraft, there are likely “pre-SPARTA” TTPs that an adversary may use to position themselves to execute SPARTA defined TTPs. As an example, the above scenario could be extended to show the TTPs on the ground to get into position for the man-in-the-middle.
This is where MITRE’s Platform Independent Vectors of Techniques (PIVOT) comes into play. MITRE created this concept to connect multiple cybersecurity matrices based on potential adversary TTPs overlaid on systems-of-systems components. PIVOT also identifies the components that translate the data from one protocol format to another (e.g., TCP/IP to MIL-STD 1553B). These PIVOT points are seldom understood or enumerated, leaving gaps in systems-of-systems cyber assessments that could allow an adversary to laterally move across technology domains undetected.
Space system engineers/developers who build and defend the system-of-systems will ultimately have to understand multiple cybersecurity matrices and how threat actors can leverage TTPs — such as SPARTA, MITRE ATT&CK for Enterprise, ICS, Microsoft Kubernetes matrix, etc. — depending on their design. Understanding the TTPs will help inform design decisions and where detection and/or countermeasures can be deployed within the system-of-system context.
