SPARTA User Guide

At the top of the SPARTA website there exists labels to guide the user experience.

And on the main landing page the SPARTA Framework exists, where all known Tactics, Techniques and Sub Techniques can be seen:

Expanding the drop-down menus at the top reveals the following:

There is a search bar to help users find information easily. The example below shows some results when searching for information on SPARTA Techniques:

Tactics represent the threat actor’s tactical goal and the reason(s) they are performing a technique. For example, a threat actor may want to achieve initial access on a spacecraft via cyber means. Other tactics include reconnaissance, resource development, execution, defense evasion, exfiltration, lateral movement, and impact.

The SPARTA Tactics page provides detailed information on Tactics with associated Techniques and Sub Techniques that help achieve the goal of the Tactic. On the left-hand side there is a menu layout to help users isolate information for each Tactic.

For example, the Reconnaissance Tactic has the primary Technique of Gathering Spacecraft Design Information which has several Sub Techniques such as Software Design:

Techniques 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. SPARTA maps a range of techniques that threat actors can use to execute tactics.

The Techniques page follows the same navigation pane style as the Tactics, allowing users to easily isolate information on Techniques.

Sub-techniques represent a variation or more specific instance of the threat actor’s behavior used to achieve a goal. Sub-techniques typically describe behavior at lower levels than a technique and are considered children of the parent technique. For example, the Software Design Sub Technique has the Parent Technique of Gather Spacecraft Design Information:

1. Unauthorized and Anomalous Command Execution (UACE)

   UACE IOBs focus on detecting unauthorized, anomalous, or malicious command executions targeting spacecraft operations. It includes monitoring commands issued outside expected time windows, deviations from baseline configurations, and replay attacks. UACE also covers unauthorized actions during safe-mode, where reduced security measures can be exploited. These IOBs help spacecraft operators identify and respond to command-related anomalies that may jeopardize mission integrity.

2. Unauthorized Cryptographic Key Usage and Encryption Bypass (UCEB)

   UCEB IOBs target unauthorized access, misuse, or tampering with cryptographic keys and encryption mechanisms. Monitoring includes repeated cryptographic key usage from unexpected locations, improper access to decryption keys, and any unexpected changes to encryption configurations. UCEB IOBs are critical for detecting persistent access attempts or data exfiltration efforts that exploit weakened encryption practices.

3. Communication Security and Network Exploitation (CSNE)

   CSNE IOBs detect unauthorized access and exploitation targeting spacecraft communication channels. They include monitoring network traffic from rogue ground stations, unexpected protocols, or IP addresses, as well as bandwidth spikes or communication link anomalies that might indicate jamming or network exploitation. By focusing on communication integrity, CSNE IOBs help detect potential command injection and data interception threats.

4. Authentication and RF Signal Integrity Threats (ARFS)

   ARFS IOBs focus on threats to authentication mechanisms and RF communication integrity. This includes monitoring for abnormal authentication attempts, RF signal manipulation, and replay attacks. This category is vital for identifying electronic warfare tactics designed to compromise spacecraft control through signal jamming or spoofing.

5. GNSS and Time Manipulation Threats (GNTM)

   GNTM IOBs focus on GNSS and timing data, which are critical for spacecraft navigation and synchronization. This category includes IOBs for detecting GNSS interference, time spoofing, and irregularities in time synchronization that may indicate manipulation. Monitoring for GNSS signal delays, signal-to-noise ratio drops, or unauthorized time adjustments helps maintain mission accuracy and stability.

6. Spacecraft Memory Integrity and Resource Exploitation Attacks (MIRE)

   MIRE IOBs focus on unauthorized memory access or modification, including attacks on flash memory, EEPROM, and boot processes. They also cover resource exploitation tactics, such as memory exhaustion or the insertion of malicious code into boot memory. Detecting these threats helps protect critical system functions from disruption and unauthorized control.

7. Watchdogs and Register Exploitation (WTRE)

   WTRE IOBs address threats to watchdog timers and critical subsystem registers. IOBs include detecting unauthorized access or manipulation of watchdog functions that may disrupt spacecraft stability. Monitoring for changes to critical registers or timing inconsistencies helps identify potential sabotage or subsystem compromise.

8. Software Integrity and Unauthorized Updates (SIUU)

   SIUU IOBs detect the manipulation or unauthorized modification of flight software, including malicious updates or firmware tampering. Monitoring includes checking software integrity, update validation, and unauthorized software modifications. This category helps ensure that software configurations remain secure throughout the spacecraft’s operational life.

9. Spacecraft Sensor Manipulation and System Resource Exploitation (SMSR)

   SMSR IOBs address threats to spacecraft sensors, which are critical for attitude control and system monitoring. SMSR IOBs detect manipulation of sensor data or attempts to exploit system resources. Examples include false telemetry injection or sensor spoofing that may mislead spacecraft operations. Early detection helps maintain accurate control and prevents resource depletion.

10. Data Integrity and Storage Exploitation Threats (DISE)

    DISE IOBs focus on maintaining data integrity and protecting onboard storage from unauthorized modification or data corruption. DISE IOBs monitor file system integrity, data manipulation attempts, and unauthorized data deletions. By securing critical data, spacecraft operators can protect mission continuity and prevent data loss.

One of the key applications for IOBs is in building and enhancing Intrusion Detection Systems (IDSs) for spacecraft. Some IDSs solutions rely only on signature-based detection via IOCs, which may not suffice in a rapidly evolving threat landscape. With IOBs, IDS can be properly tuned to detect behavioral anomalies, such as unauthorized command execution during safe-mode or unexpected memory modifications. By integrating these IOBs into onboard IDSs, spacecraft operators gain the ability to detect not just known threats but also emerging patterns that could indicate compromise. This level of detection is critical for maintaining mission assurance in the face of sophisticated cyber adversaries.

Integrating IOBs directly into spacecraft, we can address emerging cyber threats and ensure continuous protection, even when communication with ground stations is delayed or interrupted. The development of onboard intrusion detection will become a critical piece in space system defense strategies, helping protect against malicious activities, system manipulation, or protocol-based attacks that can compromise spacecraft operations. Given how quickly an attack can manifest onboard, ground operators may not have time to intervene before they lose control of the spacecraft. In this evolving threat landscape, the move towards on-orbit, autonomous cyber defense capabilities is essential to safeguard future space missions. Having documented IOBs will greatly enhance the detection, correlation, and response capabilities of these platforms by monitoring for specific malicious or anomalous behaviors in spacecraft operations.

To effectively leverage IOBs in intrusion detection, we chose to document them using the Structured Threat Information Expression (STIX) format. STIX is particularly well-suited for capturing behavioral indicators because its flexible and expressive structure allows for detailed representation of complex threat patterns. By using STIX, we provide a standardized way to define IOBs that can be directly integrated into IDS implementations. This approach not only enhances consistency but also supports the creation of detection logic. Feedback from the community has highlighted that the STIX format, with its Boolean and pattern-matching capabilities, greatly facilitates building automated detection rules, helping spacecraft software developers quickly build detections for indicators.

For these IOBs to be effective in detecting threats or anomalies in spacecraft operations, it is essential that the necessary data is available for analysis. Without access to critical telemetry, network traffic logs, process activity, and other system data, even the most sophisticated detection logic will be rendered useless. The spacecraft must ensure that this data is collected, transmitted, and stored in a reliable manner so that it can be analyzed in real-time. This includes having robust logging mechanisms in place to capture communication protocols, system resource usage, file integrity, and command execution events. Data availability is the foundation of any detection and response strategy and without it, the visibility needed to identify threats is impaired, leaving the spacecraft vulnerable to undetected attacks.

The integration of CWE mappings to SPARTA is paramount in supporting the Secure by Design philosophy. CWE is a class-based category system for hardware and software weaknesses and vulnerabilities. The addition of CWE classes mapped to SPARTA techniques reflects the understanding that all adversary techniques fundamentally target weaknesses within spacecraft. Mapping techniques to CWE classes allows us to establish a clear link between specific attack methods and the underlying weaknesses they exploit.

Each SPARTA Technique is mapped to a CWE Class. This allows developers to better understand what CWE Classes threat actors are likely targeting, and where developers may want an additional level of scrutiny when designing space systems.

As seen above, the “Gather Spacecraft Design Information” technique is mapped to several CWE Classes among 4 levels of priorities. Indicating that for the “Gather Spacecraft Design Information” Technique, an adversary would be looking for these kinds of misconfigurations and vulnerabilities in the design of a spacecraft. The CWE mapping helps guide developers in understanding how an adversary looks for weaknesses in a spacecraft per technique, helping drive home the Secure by Design philosophy.

The SPARTA navigator can be found here. The SPARTA navigator is a tool for creating SPARTA attack chains or highlighting TTPs. It can be used to visualize countermeasure coverage, red/blue team planning, and more. The user can create their own layers in JSON and load them later to visualize attack chains, coverage maps, etc. The most important feature of SPARTA’s Navigator is the ability to export information into Excel. This enables users to select TTPs and then export all of the associated data points for their attack chains, to include the countermeasure(s), associated TTPs/threats, NIST control mappings, and much more.

The SPARTA Navigator page:

To create a new layer simply click the button:

Upon opening a new layer, the following page is loaded:

But to utilize the SPARTA Navigator, first click a TTP to reveal the associated countermeasure(s)/NIST Control(s), in the below example the “Eavesdropping” technique was selected:

Next, scroll down and utilize the toggle button to switch between the countermeasure(s) and NIST controls associated to the TTP(s)

In the below image the countermeasures were toggled on, and the countermeasures associated to the “Eavesdropping” TTP are highlighted in green:

And to see the associated NIST controls, simply click the toggle button:

The countermeasure mapper enables the user to select countermeasure(s) using the Defense-in-Depth view to visually determine their coverage of SPARTA techniques/sub-techniques. This feature is particularly useful when chaining together countermeasures to build a security architecture for the spacecraft. Before selecting any countermeasures, all the techniques/sub-techniques will appear in red but as the user selects a countermeasure, the techniques/sub-techniques turn green indicating some level of coverage and risk reduction. It is important to understand that a single countermeasure typically cannot fully prevent a TTP but it aides in risk reduction for the spacecraft. When finished selecting countermeasures, the user can export the TTP graphic but more importantly the user can export the data to Excel. The Excel workbook will report the selected countermeasures, the TTPs covered as well as the gaps in TTP coverage in respective tabs of the workbook. From a security engineering perspective, this will ensure system designers can better understand where their gaps and potential risk resides.

To create a new layer, simply use the “Create New Layer” button:

When creating a new layer, first select the countermeasure(s) of interest to see their associated TTP(s).

In the demonstration below, the first countermeasure of each category was selected. Each countermeasure selected will become green instead of grey:

To see the impact this has on mitigating TTP(s) simply scroll down:

Notice the significant TTP coverage for the Reconnaissance tactic but there is little to no coverage regarding the other tactics. Remember to reference the below spectrum when analyzing TTP coverage:

The SPARTA control mapper enables the user to select individual NIST controls and enhancements, as well as ISO 27001 requirements/controls using graphical user interface. This feature is particularly useful when chaining together many controls to build a security architecture for the spacecraft.

Before selecting any control, all the techniques/sub-techniques will appear in red but as the user selects control(s), the techniques/sub-techniques turn green indicating some level of coverage and risk reduction. It is important to understand that a single control has little impact on a TTP within SPARTA. Because these controls are more granular than SPARTA countermeasures in general, it will take a multitude of controls to fully mitigate a TTP.

The functionality of the control mapper leverages the relationship between SPARTA countermeasures and controls that have been published under the countermeasure section of SPARTA.

When done selecting the controls, the user can export the TTP graphic but more importantly the user can export the data to Excel. The Excel workbook will report the selected controls, the TTPs covered as well as the gaps in TTP coverage in respective tabs of the workbook. From a security engineering perspective, this will ensure system designers can better understand where their gaps and potential risk resides.

In contrast to the SPARTA countermeasures, there are many more controls from a NIST or ISO perspective. Therefore, users can leverage the JSON creator tool to create their own custom overlays of controls vice manually selecting from the graphical interface.

The SPARTA Control Mapper:

To create a new layer simply interact with the “Create New Layer” button:

When creating a new layer, first select the Control Framework you would like to use for analysis:

After your Control Framework is selected, start by selecting the control(s) you would like to evaluate.

For this demonstration, many controls were selected at random (the selected controls are marked green):

To see how the selected controls provide coverage against TTP(s) simply scroll down:

In this case, the TTP coverage based off of the NIST controls is lacking. Remember to reference the below spectrum to evaluate TTP coverage:

Lastly, if you would like to export data, the SPARTA Control Mapper allows you to do so with JSON, as a PNG, or in an Excel format:

The Spacecraft Mapper enables the user to select different subsystems of a Spacecraft and identify possible SPARTA TTP(s) that could target it, or manifest within that area of the system, while also showing the countermeasures that could be implemented to combat the associated SPARTA TTP(s).

To use the Spacecraft Mapper start by creating a layer:

Next, select a subsystem(s) of a spacecraft to see the associated SPARTA TTP(s) that could lead to a compromise.

In the below example the “Flight Termination System (FTS)” was selected as the part. In blue you can see the part that was selected, in red you can see the possible SPARTA TTP(s):

If you continue to scroll down past the SPARTA TTP(s) you will see the potential countermeasures that apply to the subsystem(s) in green:

As is the case with the other mappers, you can also export your data in JSON, as a PNG, or in an Excel format:

The SPARTA JSON Creator is a tool for creating JSON objects to be used in the various SPARTA mapping tools; Navigator, CM Mapper, and Control Mapper. The user can easily copy/paste SPARTA TTPs, SPARTA Countermeasures, NIST 800-53 Rev 5 IDs, or ISO 27001 IDs into the top text area and convert the data into a specific SPARTA tool format. This JSON can then be downloaded and imported into the tool for editing and creating visuals. The expected format of the controls MUST match the format within the Countermeasure section of SPARTA (NIST, ISO). For example, NIST control must match control family-control number(enhancement number) with no leading zeros. This would look like AC-2(1) and not AC-02(1) or AC-02(01).

For instance, if you wanted to take TTPs and convert them to JSON for use by the navigator, you would simply get a list of the TTPs, delimit them using comma, and paste them into the upper-most text box and use the “Convert to JSON” button like so:

From here you can download the JSON output to a file and upload it into Navigator tool:

Upon uploading the JSON file to the Navigator tool you will see the three SPARTA TTPs are selected:

The Space System Cybersecurity Questionnaire is designed to provide insight into an organization’s cybersecurity capabilities across the entire space system encompassing the space, ground, and user segments. The open-ended, free-form questions aim to elicit detailed responses that explain cybersecurity processes, capabilities, and implementations in use by an organization. Because responses are narrative and not bound to a rigid scoring model, it is recommended that experienced cybersecurity subject matter experts (SMEs) conduct the evaluation to ensure comprehensive interpretation and analysis. Evaluators should also be aware that assessment outcomes may be subjective and influenced by the assessor's experience and expertise.

The questions were developed using industry best practices and threat-informed guidance from The Aerospace Corporation’s TOR-2021-01333 REV A and the SPARTA framework. They focus on essential threats and vulnerabilities outlined in the TOR document and prioritize high-risk techniques identified through SPARTA’s Notional Risk Scores. The goal is to drive a more defensible, threat-aware cybersecurity posture for space missions.

On the questionnaire page you will find a three-column long table. The first column holds the open-ended question, the second column has further details that could be used to guide the questions and get more information, while the third column holds links to informative resources:

• MITRE ATT&CK → SPARTA Techniques
  • Provides continuity with the broader cyber community by showing how well-understood enterprise and ICS tactics/techniques overlap or diverge when applied to spacecraft. This helps space engineers leverage existing MITRE ATT&CK® knowledge while accounting for space-unique threats.
• ESA SPACE-SHIELD → SPARTA Techniques
  • Connects European standards and taxonomies to SPARTA, fostering international consistency. This mapping allows European missions already applying SPACE-SHIELD to quickly see how their protections align with SPARTA techniques.
• CWE Classes → SPARTA Techniques
  • Shows which classes of software and hardware weaknesses adversaries target when executing a SPARTA technique. This mapping grounds SPARTA in the Secure-by-Design philosophy and helps developers understand the underlying flaws to engineer out of spacecraft designs.
• NIST SP 800-160 Vol. 1 & Vol. 2 → SPARTA Techniques
  • Associates each weakness class with NIST’s system security (v1) and resilience principles (v2). This mapping turns abstract principles into concrete mitigations by linking them to SPARTA techniques and their associated CWEs.
• TOR-2021-01333 SV Threats → SPARTA Techniques
  • Connects Aerospace’s early foundational threat assessment work to SPARTA techniques, ensuring lessons learned from TOR-2021-01333 continue to inform modern spacecraft threat modeling.
• MITRE EMB3D Threats → SPARTA Techniques
  • Adds embedded system focused threat information from EMB3D to SPARTA. This gives spacecraft engineers deeper insight into embedded systems attack vectors that might not otherwise be fully represented in higher-level technique taxonomies.
• SPARTA IOBs → SPARTA Techniques
  • Links behavioral detections directly back to the adversary techniques they indicate. This mapping closes the loop from theory (TTPs) to practice (IOBs), enabling monitoring solutions and IDS rules to be traced back to specific threats.

• NIST SP 800-53 Controls → SPARTA Countermeasures
  • Shows how formal, government-recognized controls map to SPARTA countermeasures. This helps programs trace security requirements and compliance efforts directly into the spacecraft threat model.
• ISO 27001 Controls → SPARTA Countermeasures
  • Provides an international lens by aligning SPARTA countermeasures with ISO 27001, the globally recognized information security management standard. This ensures non-U.S. missions can leverage SPARTA within their regulatory and certification context. This is performed by using the existing SPARTA Countermeasure to NIST mapping and then translating using the NIST to ISO mapping performed by NIST.
• MITRE D3FEND Techniques → SPARTA Countermeasures
  • Connects SPARTA defenses with MITRE’s knowledge base of cyber defense techniques within D3FEND, enriching spacecraft countermeasures with best practices drawn from enterprise and ICS defensive operations.
• MITRE D3FEND Artifacts → SPARTA Countermeasures
  • Maps defensive telemetry and forensic artifacts captured in D3FEND to SPARTA countermeasures, highlighting what evidence should be collected to validate that a countermeasure is effective in practice.
• MITRE EMB3D Mitigations → SPARTA Countermeasures
  • Provides embedded-system-specific protections from EMB3D and ties them to SPARTA countermeasures, helping spacecraft teams defend at the embedded system level as well as at the operational level.
• ESA Space Shield Mitigations → SPARTA Countermeasures
  • Ensures that European mitigation guidance aligns from SPACE-SHIELD with SPARTA, strengthening interoperability and shared defense strategies across allied programs.
• NASA Best Practices Guide → SPARTA Countermeasures
  • Maps NASA’s spacecraft cybersecurity best practices directly to SPARTA countermeasures, providing a practical engineering link between agency guidance and SPARTA’s structured defensive taxonomy.