Authors: Brandon Bailey, Dan Painter, Brad Roeher and Randi Tinney

The SPARTA framework continues to evolve, and with this minor release of SPARTA v3.2, we’re adding some new requirements and updated requirements language, countermeasure prioritization, space segment guidance information for NIST controls, updating SPARTA’s user’s guide, mappings to Technical Guideline BSI TR-03184 Information Security for Space Systems and NIST’s Cybersecurity Framework 2.0, publishing presentation titled SPARTA Countermeasure Utilization & Prioritization as well as some general bug fixes and aesthetic updates to the GUI to enhance usability. Continue reading for a closer look at each of these new features.

SPARTA Countermeasure Prioritization

Based on feedback from the space cybersecurity community, there was a clear desire to extend SPARTA’s threat-informed approach beyond techniques and into the defensive side of the framework. While the Notional Risk Score (NRS) provided a structured method for prioritizing adversary techniques, users asked for a comparable approach to help differentiate and prioritize SPARTA Countermeasures (CMs). In response, SPARTA has been expanded with a prioritization method that aligns CM selection with both threat relevance and implementation feasibility across the space domain.

This prioritization approach evaluates each CM using a scoring formula that integrates Efficacy, Feasibility, and Cost, producing a prioritization score that reflects both operational impact and potential risk. CMs with low scores are considered high priority, meaning they provide a strong security return on investment and are achievable given typical space constraints.

The efficacy dimension assesses how effectively a given countermeasure prevents, disrupts, or detects known adversary behaviors. Rather than treating all adversary techniques equally, the approach incorporates the Notional Risk Score (NRS) for each technique, which reflects its relative criticality (i.e., impact and likelihood). For example, techniques associated with irreversible mission loss (e.g., EX-0005.02 — Malicious Use of Hardware Commands) are assigned higher NRS values. CMs are then scored based on the average NRS of the techniques they mitigate, ensuring those that defend against high-risk behaviors are weighted more heavily.

This technique-CM mapping is grounded in SPARTA’s existing knowledge base, which traces adversary behavior from high-level tactics (e.g., Initial Access) down to concrete techniques and sub-techniques. For instance, a countermeasure like CM0031: Authentication may mitigate a broad range of high-NRS techniques, including Replay: Command Packets, unauthorized commanding from Rogue External Entity. By aligning countermeasure impact with known TTPs, the prioritization approach directly connects defenses to adversary tradecraft.

The feasibility component accounts for the technical and architectural realities of space vehicles. Implementation feasibility was assessed based on several criteria, including generic space vehicle compatibility, spaceflight heritage, and technology readiness level (TRL). Many countermeasures that are standard in terrestrial systems may be infeasible on board due to SWaP (Size, Weight, and Power) limitations, radiation-hardening requirements, or flight-certification constraints.

Feasibility was assessed using subject-matter expert judgment on a normalized scale. A CM that can be implemented using mature tooling, with minimal impact on the mission architecture (e.g., static code analysis or cryptography) would score highly. Conversely, CMs that require significant redesign, custom ASIC/FPGA development, or have only been demonstrated in lab environments may receive lower feasibility scores. The goal was to ensure the approach reflects realistic adoption potential, not just theoretical applicability.

Cost, in this context, captures the full lifecycle burden of implementing a CM within a space program. This includes estimated labor required for integration, software and hardware modifications, verification and validation activities, and indirect impacts such as schedule disruption, long-lead item procurement, or external coordination with partners or suppliers. Recognizing that exact cost modeling is highly program-specific and often infeasible early in the lifecycle, the approach was to use a generalized 1-to-4 magnitude scale (e.g., $, $$, $$$, $$$$) to represent relative cost impact across missions.

For example, a Tier 1 CM like CM0012: Software Bill of Materials (SBOM) typically incurs a low cost, as it can often be integrated with existing build and release processes using mature tooling. Similarly, CM0002: COMSEC is widely understood, operationally supported, and already part of many program baselines, which makes it less burdensome to implement. In contrast, CMs such as CM0061: Power Masking or CM0067: Smart Contracts may involve significant architectural redesign, low-TRL components, or custom hardware/software dependencies, which increase both cost and integration complexity.

These cost scores are not intended to provide precise budgeting figures, but rather serve as a coarse-grained, mission-agnostic filter to help prioritize by identifying which mitigations are most cost-effective given their risk profiles and system architectures.

The combined prioritization score is calculated using the formula:

(Feasibility × Cost) / Efficacy

This structure intentionally rewards CMs that are both high-impact and realistic to implement. A low score indicates that a CM is both operationally valuable and feasible within typical mission constraints, making it a strong candidate for prioritization. Conversely, a CM that is highly effective but too costly or complex for most missions will receive a lower priority.

After scoring, countermeasures were grouped into three tiers:

• Tier 1 CMs are foundational defenses that are both effective and widely implementable. These include static analysis, authentication enforcement, COMSEC, SBOMs, and monitoring of critical telemetry. Missions across all sectors are strongly encouraged to implement these wherever applicable.
• Tier 2 CMs are valuable but often more complex, costly, or context-specific. Examples include onboard message encryption, EMSEC, or cyber-safe mode. These CMs should be evaluated considering system architecture, mission duration, and operational risk tolerance.
• Tier 3 CMs include cutting-edge or niche protections that often have high cost, low TRL, or limited general applicability. These include deception technologies, stealth technology, or proliferated constellations. While not suitable for all missions, Tier 3 CMs may be critical for high-value assets or future capabilities.

In addition to tiering, each countermeasure was annotated with environmental applicability, meaning whether it is relevant to onboard space vehicles, ground systems, or development pipelines. This helps stakeholders allocate protections based on where the risk resides in their specific architecture. For example, CM0004: Development Environment Security applies primarily to the build pipeline, while CM0040: Shared Resource Leakage and CM0036: Session Termination are applicable onboard.

Ultimately, the SPARTA CM prioritization approach bridges the gap between threat intelligence and engineering decision-making. It empowers programs to align their defensive posture with threats while balancing risk, cost, and feasibility. By using a structured, repeatable, and threat-informed methodology, this approach helps ensure that space systems are designed not just with compliance in mind, but with cyber survivability at the forefront.

SPARTA Countermeasure Utilization & Prioritization Presentation

A presentation titled SPARTA Countermeasure Utilization & Prioritization has been published to accompany the new CM prioritization efforts. The presentation details the structured prioritization methodology designed to help programs focus resources where they have the greatest mission impact. Each CM is evaluated based on efficacy (informed by the number and risk level of mitigated techniques), feasibility (including SWaP constraints, architectural compatibility, and technology maturity), and cost (implementation and lifecycle burden). These factors support a tiered model that categorizes countermeasures into foundational (Tier I), enhanced (Tier II), and advanced protections (Tier III), while distinguishing applicability between onboard spacecraft and ground or development environments. The result is a threat-informed approach that transforms CM selection into a transparent, risk-aligned engineering process.

Crosswalking SPARTA to BSI TR-03184: Validating Comprehensive Threat & Mitigation Coverage

To ensure the completeness and international relevance of the SPARTA framework, we conducted a structured crosswalk between SPARTA techniques and the threat catalog defined in Appendix A of BSI TR-03184 Part 1 (G# threats). This mapping effort was performed to validate that SPARTA’s space-specific adversary TTPs comprehensively address the system-level threat categories identified by BSI. By aligning SPARTA techniques to the G# taxonomy, we were able to systematically evaluate whether any relevant threat classes were underrepresented or absent within the SPARTA framework. This exercise provided an external benchmark against an international guideline, strengthening confidence that SPARTA’s threat model is both comprehensive and globally aligned.

In parallel, SPARTA countermeasures were mapped to Appendix B of BSI TR-03184, which lists Security Measures intended to mitigate the identified threat categories. This mapping ensured that SPARTA’s defensive constructs are interoperable with protection practices recognized outside the U.S. space community. The result is a bidirectional validation: SPARTA techniques demonstrate coverage of internationally recognized threats, and SPARTA countermeasures align with globally accepted security controls. Together, these crosswalks reinforce SPARTA’s role as a threat-informed, engineering-focused framework that remains compatible with broader international cybersecurity guidance while preserving its space-specific depth and applicability.

The analysis demonstrated that SPARTA fully encompasses the BSI-defined threat landscape and associated security measures. Differences observed were semantic and structural rather than substantive, confirming that SPARTA delivers comprehensive coverage aligned with international guidelines.

Aligning SPARTA Countermeasures with NIST CSF 2.0

The NIST Cybersecurity Framework (CSF) 2.0 provides a high-level structure for managing cybersecurity risk across various sectors. Organized around core functions, Govern, Identify, Protect, Detect, Respond, and Recover, CSF 2.0 is intentionally outcome-focused and technology-agnostic. While this flexibility makes it broadly applicable across industries, it does not prescribe specific technical implementations, nor does it address the unique architectural and operational characteristics of space systems.

To evaluate alignment and ensure interoperability with established risk management practices, SPARTA countermeasures were mapped to the CSF 2.0 functions and categories/sub-categories. The purpose of this effort was twofold: first, to validate that SPARTA’s space-specific defensive measures comprehensively support the cybersecurity outcomes defined by CSF; and second, to demonstrate that SPARTA can serve as a practical implementation layer beneath the CSF structure for space missions.

The analysis confirmed that SPARTA provides full coverage of CSF 2.0’s functional objectives. Where CSF defines high-level risk management outcomes (e.g., identity management, data protection, anomaly detection, or incident response), SPARTA delivers concrete, engineering-grade countermeasures tailored to the space, ground, and development segments. Differences identified between the frameworks were primarily related to terminology and level of abstraction. CSF defines what cybersecurity outcomes organizations should achieve, while SPARTA countermeasures specify how those outcomes can be realized within the constraints of space vehicle architectures, mission operations, and supply chain environments. Through engineering-grade, “shall” statement requirement language, SPARTA translates high-level risk management objectives into concrete, technically actionable controls tailored for space systems, enabling precise implementation and verifiable mission assurance.

Like the BSI mappings, no gaps were identified between SPARTA countermeasures and CSF 2.0 functional expectations. Every CSF function and relevant category could be mapped to one or more SPARTA countermeasures. In many cases, SPARTA provides deeper granularity and mission-specific context beyond what CSF was designed to address. This confirms that SPARTA is fully interoperable with CSF 2.0 while extending its applicability into the specialized domain of space systems cybersecurity.

For organizations already using CSF 2.0 as their risk management backbone, SPARTA can serve as a complementary technical reference to help translate high-level cybersecurity outcomes into actionable, threat-informed controls engineered specifically for space environments. Together, the frameworks provide both strategic risk governance and mission-aligned implementation guidance, ensuring that space system cybersecurity is both standards-aligned and operationally grounded.

Updating SPARTA’s Requirements Set

As SPARTA continues to mature as an engineering-focused cybersecurity framework for space systems, we refreshed its requirements library better to reflect new updates to our understanding of space-segment protections and improve alignment with standards. In this release, a goal was to incorporate space segment rationale from the updated CNSS 1253 Space Platform Overlay while remaining aligned with the underlying NIST SP 800–53 Rev. 5 control and enhancement structure. The result is a cleaner, more traceable set of cyber requirements that programs can use as a practical starting point when translating control intent into implementable, verifiable spacecraft requirements.

The effort began by establishing a clean baseline of the existing SPARTA requirement set. Duplicate and overlapping entries were consolidated, compound statements were split where needed, and requirement identifiers were treated as stable references to preserve traceability over time. This baseline cleanup ensures that future revisions can be understood quickly and audited consistently.

With the baseline in place, we evaluated the rationale for the 1253 space-segment overlay control. We compared its guidance against SPARTA’s existing coverage to ensure that the 1253 control rationale had coverage in SPARTA. Where the overlay introduced space-specific intent, such as short pass windows, intermittent connectivity, safe mode constraints, relay and partner links, limited on-orbit change authority, and radiation-driven failure modes, we updated existing requirement language or added new requirements when doing so improved clarity and traceability.

Across the update, the most common new and updated requirement themes centered on space-specific operational constraints, including mode and phase aware access control, command acceptance enforcement with explainable outcomes, session lifecycle behavior tied to AOS and LOS, audit design for intermittent connectivity, flight update rigor under constrained contacts, boundary mediation across trust domains, resilience under resource constraints, and supply chain provenance and end of life sanitization. Together, these changes strengthen SPARTA’s ability to translate control intent into verifiable requirements without losing alignment to established cybersecurity standards.

SPARTA’s Logo

Don’t forget to use SPARTA’s official trademarked logo. Users are encouraged to incorporate the logo in presentations, reports, or other materials, provided that the registered trademark symbol remains visible. This ensures the logo is used in a manner consistent with its trademark protection while still being openly available to the community.

SPARTA v3.2 — What’s New? was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The SPARTA framework has evolved with the release of SPARTA v3.1, introducing new space segment guidance for NIST controls, SPARTA’s user guide version 1, mappings to MITRE’s EMB3D, and new techniques from researchers. It also includes the DEF CON 33 presentation titled “Hacking Space to Defend It: Generating IoBs with SPARTA” and general bug fixes and GUI updates for better usability.

Authors: Brandon Bailey, Paul de Naray, Brad Roeher, and Randi Tinney

The SPARTA framework continues to evolve, and with this minor release of SPARTA v3.1, we’re introducing some new space segment guidance information for NIST controls, SPARTA’s user’s guide version 1, mappings to MITRE’s EMB3D, new techniques submitted by researchers, publishing DEF CON 33 presentation titled Hacking Space to Defend It: Generating IoBs with SPARTA as well as some general bug fixes and aesthetic updates to the GUI to enhance usability. Continue reading for a closer look at each of these new features.

CNSS and SPARTA Connections

SPARTA v3.1 introduces dedicated guidance aligned with and leveraged by the Committee for National Security Systems Instruction (CNSSI) 1253 Attachment 2 to Appendix F, Space Platform Overlay. This update translates NIST SP 800–53 security controls into space segment-specific context, giving engineers and operators clear interpretation of how to tailor NIST controls for space segment threats and vulnerabilities.

While CNSSI 1253 has long provided baseline overlays for National Security Systems, the general nature of the main control baselines required significant tailoring and justification when applied to spacecraft. The previous CNSSI 1253 Space Platform Overlay was published in 2013, and it provided tailoring guidance for that era of the space enterprise knowledge. A new update to the Space Platform Overlay was released under direction of EO 14144 and the new content provides modernized cybersecurity guidance for space segment protection. The new overlay builds upon the previous overlay content, but now significantly leverages TOR-2023–02161 Rev A content and directly references the SPARTA framework, nomenclature, and knowledge for analyzing attacks on space systems.

The Space Platform Overlay leveraged TTP and other information from the SPARTA framework to guide control tailoring and selection justification. To ensure that the Space Platform Overlay’s core content is self-contained and not dependent on the SPARTA website, key overlay guidance was copied from the website into the Detailed Control Specifications section for all added controls. This overlay section also leverages SPARTA website links to provide knowledge related to the controls, such as applicable threats, implementation guidance, countermeasures/mitigations, sample specification requirements, and other helpful knowledge. Utilizing the SPARTA website links avoids a large amount of knowledge being captured in a document-centric, static format. This additional knowledge is instead represented in the data-centric SPARTA TTP framework with linked-content navigation. An additional rationale for having the SPARTA TTP framework separately linked was to allow for the website to provide evolving TTP information that is kept up to date with current threat knowledge and other information updates that occur outside of the less frequent updates to the Space Platform Overlay document.

Aligning SPARTA with CNSSI 1253, and vice versa, is particularly important because it ties tactical threat knowledge to federal compliance frameworks. Programs operating under CNSS direction must demonstrate that their control implementations are both sufficient and tailored to mission risk. Without this alignment, program offices are left to justify control applicability from first principles, often resulting in inconsistent or incomplete coverage.

Integrating MITRE EMB3D into SPARTA: Strengthening Spacecraft Cybersecurity at the Embedded Layer

Securing spacecraft requires addressing threats at multiple layers of the architecture: from mission-level adversary tactics down to the hardware and firmware of onboard subsystems. The SPARTA framework has become the community’s reference model for describing spacecraft-specific adversary behaviors (techniques, sub-techniques, and countermeasures). SPARTA excels at enumerating mission-relevant threats and their countermeasures, and this mapping complements it by extending coverage into embedded device-level weaknesses and defenses, which is the foundational layer upon which spacecraft are built.

The MITRE EMB3D™ framework provides a curated, evidence-based knowledge base of embedded device threats and mitigations. EMB3D explicitly maps device properties (hardware, firmware, networking, and system software) to threats, weaknesses (CWEs), and tiered mitigations. Its focus on embedded security directly aligns with the realities of spacecraft, where size, weight, power (SWaP), and technology readiness level (TRL) constraints often dictate design trade-offs.

To bridge these complementary frameworks, the SPARTA team, in coordination with the EMB3D team, developed a crosswalk mapping between SPARTA techniques and countermeasures and EMB3D threats and mitigations.

Motivation for the Mapping

One of the primary benefits of mapping SPARTA to EMB3D is the ability to align mission-level threats with their embedded systems exploit paths. SPARTA techniques describe what adversaries attempt, such as malicious firmware injection or bus eavesdropping, while EMB3D threats capture how those attempts technically manifest through mechanisms, such as insecure bootloader verification or exploitable network stack components. By connecting the two, engineers can map high-level attack techniques directly to the underlying embedded weaknesses that enable them. The mapping also enriches countermeasure guidance by linking abstract protections to practical defenses. SPARTA countermeasures, such as “COMSEC” or “Secure Boot,” provide essential high-level direction, and EMB3D adds further perspective by offering concrete technical implementations organized into Foundational, Intermediate, and Leading tiers. Together, they deliver both strategic guidance and detailed engineering pathways for securing spacecraft. Finally, this integration improves consistency and reduces subjectivity in threat modeling. Risk assessments often vary depending on analyst expertise, but EMB3D’s curated set of technical artifacts, CWEs, and engineering references helps standardize how threats are identified and mitigated at the embedded system level. This strengthens the overall reliability of SPARTA-based risk assessments across organizations and missions.

Benefits to Spacecraft Security

The integration of EMB3D into SPARTA offers several distinct benefits for spacecraft security. First, it enhances the protection of spacecraft embedded hardware, such as the single board computer or reaction wheel firmware. While SPARTA provides essential high-level countermeasures, EMB3D adds further value by offering detailed coverage of hardware debug ports, firmware update processes, cryptographic key handling, and memory protections. Together, they provide both the strategic guidance and the engineering depth needed to secure these critical subsystems.

Another major benefit is the ability to prioritize mitigations through EMB3D’s tiered model. By adopting this approach, spacecraft engineers can implement Foundational defenses, such as memory-safe languages and basic bootloader authentication immediately, while planning for Intermediate or Leading mitigations, such as hardware-backed roots of trust or control-flow integrity as technology readiness levels and size, weight, and power constraints allow. This creates a phased security roadmap that aligns with the realities of spacecraft development lifecycles.

Finally, the alignment anchors spacecraft protections within globally recognized standards. Because EMB3D mitigations are mapped to ISA/IEC 62443–4–2 security controls, this crosswalk connects space cybersecurity to the broader industrial and embedded device security ecosystem. The result is reduced fragmentation, greater interoperability, and the adoption of practices already validated across other critical infrastructure sectors.

Overall, this mapping advances the maturity of space system defense by ensuring that spacecraft are protected not just at the mission and operations level, but also at the embedded foundations where many of the most impactful vulnerabilities reside.

SPARTA v3.1 New Technique Submission

SPARTA 3.1 is expanding with the addition of two new techniques submitted by outside researchers. The first, IA-0013: Compromise Host SV, highlights a new initial access vector where attackers target the host spacecraft itself to pivot into a hosted payload. By exploiting vulnerabilities in the host vehicle’s onboard systems, command interfaces, or software, adversaries could move laterally into the payload, especially when buses, processors, or communication links are shared. The second, DE-0012: Component Collusion, introduces a novel form of defense evasion. In this approach, adversaries compromise multiple modules during the supply chain process and design them to work together in ways that look benign when inspected individually. One component may quietly trigger conditions, while another executes the malicious action undermining traditional detection methods like log analysis or code review.

Credit: Afsah Anwar & Jack Vanlyssel, Beyond Defense Labs, University of New Mexico

SPARTA’s User’s Guide v1

The SPARTA team is releasing Version 1 of the SPARTA User’s Guide, a living resource that will continue to be updated as the framework evolves and new capabilities are added. The guide provides a structured walkthrough of the framework’s tools and features, including techniques, countermeasures, and Indicators of Behavior (IOBs). It explains the underlying data elements, how to navigate the site, and how to leverage the built-in mappings to NIST controls, CWE classes, and secure-by-design principles.

The User’s Guide is designed to make SPARTA more accessible for a broad community of users. Whether conducting a threat-informed risk assessment, tailoring requirements, or developing intrusion detection logic, the guide illustrates how SPARTA’s resources can be applied to practical engineering and assessment needs. By offering this reference, the SPARTA team aims to lower the barrier of entry and enable government, industry, and academic partners to confidently leverage SPARTA in securing space systems.

SPARTA Community Update: PWNSAT Team Extends MITRE’s Attack Flow with SPARTA

The SPARTA team is excited to highlight a community contribution from the PWNSAT team, who have taken the initiative to extend MITRE’s ATT&CK Flow tool by incorporating SPARTA techniques. Their work, described in detail on their blog From MITRE ATT&CK to SPARTA: A Unified Attack Flow for Space Systems, demonstrates the growing interest in unifying space-specific adversary behaviors with existing cyber threat modeling tools. The source code is available on GitHub.

Why this matters:

• Storytelling with SPARTA: ATT&CK Flow already allows defenders and researchers to describe how adversary techniques chain together in a campaign. By adding SPARTA content, space system engineers can now tell those stories using techniques tailored to spacecraft, ground, and link segments.
• Cross-domain realism: Real attacks don’t stay confined to one domain. Just as MITRE’s Platform Independent Vectors of Techniques (PIVOT) concept emphasizes the need to model pivot points across system-of-systems, integrating SPARTA into ATT&CK Flow makes those cross-domain paths explicit by showing how attackers can move from IT to ground networks to spacecraft systems.
• Shared understanding: Visualizing SPARTA techniques in flows gives engineers, operators, and decision makers a clearer way to communicate threats, attack paths, and defensive priorities.
• Community tools: The PWNSAT extension shows what’s possible when the community builds on SPARTA. These kinds of tools help everyone, from red teamers designing scenarios, to blue teamers building detections, to acquisition teams writing requirements, better understand and counter the threats facing space systems.

We want to thank the PWNSAT team for taking the lead on this effort and encourage others to explore similar initiatives. If you’re developing tools, integrations, or visualizations that leverage SPARTA, we’d love to hear from you sparta@aero.org. By working together, we can continue to expand the ecosystem of resources that make space systems more secure and resilient.

Paper: Applying TTP Frameworks to Space Systems

We’re excited to share an Aerospace report that takes a deep dive into how adversary TTPs can be systematically applied to secure space systems. Titled Recommended Practices for Integrating TTP Frameworks to Secure and Defend Space Systems (OTR-2025–00018), this paper shows how SPARTA, ATT&CK, and SPACE-SHIELD can be leveraged together to bridge the gap between high-level policy and hands-on engineering.

Why this matters:

• Threat-informed engineering: ties adversary behaviors directly to subsystem protections.
• Cross-segment defense: apply TTPs across ground, link, and space.
• Policy alignment: connect SPD-5, NIST, and CNSSP with practical security requirements.
• Detection-ready: build intrusion detection and monitoring using IOCs and IOBs in STIX.

The paper highlights the unique challenges of applying frameworks to spacecraft, including technology readiness gaps and the need for onboard intrusion detection capabilities. To make it practical, the report provides a table of recommended practices that can be directly adopted by engineers, operators, and acquisition professionals.

Read the full paper here

DEF CON 33: Hacking Space to Defend It: Generating IoBs with SPARTA

While the launch of the SPARTA framework in October 2022 gave the community insight into potential threats, it didn’t address how to detect them in practical scenarios. In 2025, our research took a different approach as we didn’t just theorize about threats, we actively exploited space systems using SPARTA techniques to figure out what Indicators of Behavior (IoBs) would look like in a real-world attack scenario. By leveraging offensive cyber techniques from SPARTA, we identified the specific patterns and behaviors that adversaries might exhibit when targeting spacecraft. These insights allowed us to systematically develop IoBs tailored to the operational constraints and unique environments of space systems. As a result, we demonstrated how Intrusion Detection Systems (IDS) for spacecraft can be designed with realistic, data-driven threat profiles.

SPARTA’s New Logo

The SPARTA framework now has an official trademarked logo. The new design features The Aerospace Corporation above the logo and includes the registered trademark symbol (®). This update reflects SPARTA’s official trademark status and helps establish a consistent, recognizable brand across the community.

Users are encouraged to incorporate the logo in presentations, reports, or other materials, provided that the registered trademark symbol remains visible. This ensures the logo is used in alignment with its trademark protection while still being openly available to the community.

We’d love to hear from you if you can take a few minutes and fill out our survey.

SPARTA v3.1 — What’s New? was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Authors: Brandon Bailey, Brad Roeher, Randi Tinney and Ernest Wong

One of the most innovative additions to SPARTA v3.0 is the creation of IOBs specifically tailored to onboard spacecraft activity. The creation of IOBs in SPARTA v3.0 was funded by the Department of Homeland Security (DHS) Science and Technology (S&T) Directorate to enhance the cybersecurity posture of space systems, addressing the growing need for proactive threat detection as space infrastructure becomes increasingly critical to national security and economic stability. Unlike traditional Indicators of Compromise (IOCs), which focus on detecting known malicious artifacts or signatures, IOBs are designed to identify behavioral patterns that could indicate emerging threats. This proactive approach allows space system developers to build detection mechanisms for anomalies and suspicious activities onboard the spacecraft, making IOBs a crucial element in modern spacecraft defense​.

Why IOBs Matter for Space Cybersecurity

Spacecraft are typically designed to be highly specialized and deterministic, where deviations from expected behavior often indicate either a system fault or potential adversarial activity. IOBs bridge this gap by focusing on behavioral anomalies in addition to known signatures, making them particularly effective in environments with limited historical data on cyber incidents. This is essential for space missions where threats may emerge without warning or established patterns. By leveraging IOBs, space mission operators can detect subtle deviations, such as unexpected command execution rates, unusual memory utilization, or anomalous network traffic, that may indicate malicious intent​.

How to Build IOBs for Space Cybersecurity

Building IOBs for space systems involves a structured process that translates threat-based information into practical and observable behaviors that can be used for detection and response. To begin deriving IOBs, we leveraged SPARTA as a source of realistic attack vectors and to serve as the foundation for understanding what behaviors matter and how they may manifest operationally onboard a spacecraft.

Given the large number of techniques in SPARTA, prioritization was essential for establishing the initial IOB baseline. To support this, we used SPARTA’s Notional Risk Scores (NRS) which is a risk assessment model designed to help engineers focus on the most critical threats. NRS assigns a risk value to each technique based on the potential impact to the system and the likelihood that an adversary within a given threat tier could successfully execute it. These scores are informed by previous work detailed in Aerospace Report TOR-2021–01333-REV A, which introduced a high-level threat model and categorized adversary capabilities into threat tiers. This provides a structured way to estimate risk in environments where attack likelihood is difficult to assess due to the uniqueness of each mission.

By focusing on techniques with high NRS scores, we ensured that the first release of IOBs targets high-impact, plausible threat scenarios. Each selected technique was analyzed to understand what behavioral evidence might indicate its use. This methodical, threat-driven approach provides a scalable foundation for IOB development. Once developed, these IOBs were systematically mapped to specific SPARTA techniques which not only ensures consistency across threat detection efforts but also allows users to see how behavioral indicators directly relate to adversarial tactics. By linking IOBs to techniques, cybersecurity practitioners can implement them in their monitoring frameworks with a clear understanding of the associated risks and attack vectors.

As additional space missions are assessed and more telemetry, signal, and operational anomalies are observed, the IOB set can evolve to ensure space systems remain resilient against both known and emerging adversary behaviors. Continued growth and refinement of these indicators will depend heavily on community engagement, which is why contributions through the Space Information Sharing and Analysis Center (S-ISAC) are critical. By collaborating through S-ISAC, we can crowdsource insights, share real-world threat data, and avoid duplicative efforts. This will ensure the broader space community benefits from a unified and constantly improving understanding of space-based threats.

Building Intrusion Detection Systems with IOBs

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.

In order 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 realtime. 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.

Organizing IOBs: Behavioral Categories

IOBs are currently organized within SPARTA into 10 distinct categories, where each IOB has their own unique identifiers. More categories could be added later as more indicators are researched, but these 10 categories will structure the new SPARTA v3.0 IOB interface:

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​.

The introduction of IOBs in SPARTA v3.0 marks the first-ever comprehensive documentation of potential malicious behavior specifically targeting spacecraft. As the first release and baseline for space system IOBs, this represents a foundational step in advancing space cybersecurity. We recognize that as research progresses and more information becomes available, future releases will expand and refine these IOBs, providing even greater coverage and precision. This ongoing effort reflects our commitment to enhancing threat detection and response in the evolving space threat landscape. Stay tuned for updates as we continue to develop and publish new IOBs to meet emerging challenges.

Indicators of Behavior (IOBs) in SPARTA v3.0 was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The SPARTA framework offers space professionals a taxonomy of potential cyber threats to spacecraft and space missions. v3.0 includes some powerful new features.

Authors: Brandon Bailey, Brad Roeher, and Randi Tinney

The SPARTA framework continues to evolve, and with the release of SPARTA v3.0, we’re introducing a suite of powerful new features designed to further support our users’ missions. Thanks to feedback from our engaged user base, we’re able to identify the most commonly requested features and improvements for SPARTA and act on those. This update marks the completion of the single most requested feature since we launched SPARTA, as well as a handful of other noteworthy additions, including:

The creation of new Indicators of Behavior (IOBs), specifically designed to address the unique challenges of monitoring onboard activity, providing a proactive approach to detecting suspicious behaviors and emerging threats. These IOBs are something the community has been seeking for years, so we are thrilled to launch this initial set. All of the indicators are mapped to SPARTA techniques to further support tracking/reporting across the space enterprise.

• Added a new Space System Cybersecurity Questionnaire to help organizations evaluate their cybersecurity practices.
• Integrated Common Weakness Enumeration (CWE) class mappings to SPARTA techniques.
• Aligned the spacecraft decomposition with NIST SP 800–160 Vol. 1 and 2 principles.
• Made improvements to technique and countermeasure names to streamline automation and avoid collisions within certain tools/workflows.
• General bug fixes and aesthetic updates to the graphical user interface (GUI) to enhance usability.

Continue reading for a closer look at each of these new features and explore how they can help you enhance threat detection, resilience, and overall security for your space system.

Onboard Indicators of Behavior (IOBs)

SPARTA v3.0 introduces a new capability with the creation of IOBs, which is the first-ever comprehensive documentation of behavioral patterns that may indicate malicious activity on spacecraft. Funded by the Department of Homeland Security (DHS) Science and Technology (S&T) Directorate, this effort delivers a proactive approach to threat detection by identifying deviations from expected spacecraft behavior, rather than relying solely on known signatures.

Each IOB was created and then mapped to SPARTA techniques and documented using the Structured Threat Information Expression (STIX) format to support detection development, particularly for onboard intrusion detection systems (IDSs). To enhance usability, IOBs are organized into 10 mission-relevant categories, such as unauthorized command execution, encryption misuse, sensor manipulation, and more. These IOBs serve as a foundational baseline, and future releases will continue to expand and refine this work as threats evolve. This is a major development that required extensive work that cannot be articulated here for the sake of brevity. A more comprehensive deep dive into the IOBs is available in a dedicated article.

Space System Cybersecurity Questionnaire

To further support threat-informed risk assessments, SPARTA v3.0 introduces a new resource: the Space System Cybersecurity Questionnaire. This tool is designed to help organizations evaluate how well they are addressing cybersecurity across the entire space system (i.e., space, ground, and user segments). Rather than using rigid checklists or numeric scoring, this questionnaire presents open-ended, narrative-driven questions that encourage thoughtful reflection on current cybersecurity practices. The responses should capture nuanced implementation details and design considerations that may not surface through traditional compliance-based audits.

The questionnaire was developed using industry best practices and threat-informed insights from The Aerospace Corporation’s TOR-2021–01333 REV A and the SPARTA framework. Each question was carefully crafted to address specific threats and high-risk techniques, particularly those identified through SPARTA’s Notional Risk Scores (NRS). Informative references accompany each question to tie responses back to concrete threat vectors, SPARTA techniques, or example countermeasures. These references give evaluators context for why a question is being asked and help link the organization’s answers to known cybersecurity risks and defenses.

Because responses are narrative and not bound to a rigid scoring model, it is recommended that experienced cybersecurity subject matter experts (SMEs) compose or interpret the responses. Responses may vary significantly depending on the SME’s expertise, system-specific context, and familiarity with the threat landscape. However, this flexibility is also a strength because it allows evaluators to uncover gaps, strengths, and inconsistencies that rigid frameworks might overlook.

The questionnaire addresses a wide range of topics, including:

• Command link protection and replay resilience
• Insider threat strategies and telemetry anomaly logging
• Key management and secure software update validation
• Ground-system segmentation and space-segment subsystem isolation
• Secure-by-design principles, such as least privilege, defense in depth, and supply chain assurance

This questionnaire empowers organizations to self-assess their posture in a structured yet flexible manner, providing a baseline for internal evaluations or external reviews. It serves as both a conversation starter and a roadmap for developing a more resilient, mission-aware cybersecurity strategy. As with all components of SPARTA, this tool is grounded in real-world threats and practical engineering guidance, helping to bridge the gap between policy intent and implementation reality.

CWE Mapping: Bridging Weaknesses and Threats

The addition of CWE classes mapped to SPARTA techniques reflects our understanding that techniques fundamentally target weaknesses within spacecraft. CWE classes represent broad categories of software or hardware flaws that can be exploited. Mapping techniques to CWE classes allows us to establish a clear link between specific attack methods and the underlying weaknesses they exploit.

Those familiar with the CWE structure may notice the mapping was done at the CWE class level, as opposed to base weaknesses. This level of mapping was done to provide the right level of abstraction for understanding how adversarial methods operate. By aligning techniques with CWE classes, we capture the concept that techniques attack the absence or insufficiency of security practices, rather than a specific flaw that is essentially a manifestation of the CWE. This approach helps space system developers and engineers see how each technique could leverage general weaknesses within their systems, making it easier to implement countermeasures and/or secure-by-design principles and not rely solely on vulnerability patching.

In practice, this means that when a technique is identified, users can trace it back to the associated CWE class and understand which types of weaknesses are at risk of being targeted and exploited. This relationship guides both defensive planning and vulnerability assessment, helping teams prioritize mitigations that address the root causes of exploitation rather than just the symptoms. By integrating CWE classes into SPARTA techniques, we enable a more systematic and comprehensive approach to securing space systems against cyber threats.

As part of this work, we leveraged a prioritization approach using the Common Weakness Scoring System (CWSS). This process allowed us to evaluate and rank CWEs based on their relevance and impact within the context of a spacecraft. Leveraging a customized CWSS model to emphasize factors most critical to mission assurance, namely, technical and mission impact, likelihood of exploitation, and confidence in the findings. The methodology considered whether the weakness could realistically be exploited, how severe the impact might be (leveraging CVSS metrics), and how often these weaknesses have been linked to known vulnerabilities (based on CVE associations). In general CWSS should be applied for a specific system, but this prioritization was based on a generic exemplary spacecraft model.

Performing this analysis not only informed our CWE-to-technique mappings, but also created a risk-based lens through which secure-by-design principles could be derived via NIST SP 800–160 Volume 1 and Volume 2.

NIST SP 800–160 Integration

SPARTA v3.0 features the integration of NIST SP 800–160 Volume 1 and Volume 2 into our spacecraft threat modeling approach. Volume 1 focuses on systems security engineering, while Volume 2 emphasizes cyber resiliency. We applied these principles directly to our spacecraft decomposition for the spacecraft bus, mapping SPARTA techniques to each subsystem and identifying the relevant threats that could affect the spacecraft bus components.

Further, we extended this effort by leveraging the CWE-to-technique mappings described previously. For each spacecraft component (command and data handling system, thermal control, propulsion, communications, etc.) we prioritized the most applicable CWE classes. This prioritized list of weaknesses was then used to guide which security and resiliency principles from NIST SP 800–160 should be applied during design for the spacecraft bus component. For instance, a component (e.g., flight software) with high-risk race condition weaknesses (CWE-362) might call for the following resilience techniques per Volume 2: Attribute-based Usage Restriction, Predefined Segmentation, Dynamic Resource Awareness, or Integrity Checks.

SPARTA now contains this system-by-system decomposition of the spacecraft that not only highlights applicable SPARTA techniques but also brings forward a prioritized set of weaknesses to defend against. These are directly tied to secure-by-design and resilient-by-design principles, giving engineers guidance to architect each spacecraft component with built-in protections. This integration of threat information via techniques, known weaknesses, and trusted design practices offers a first-of-its-kind blueprint for designing components of a spacecraft that are secure and resilient from the ground up. While not a one-size-fits-all solution, this framework provides an invaluable starting point that streamlines design efforts by aligning threat-informed engineering with proven design principles. Engineers are still expected to down-select and tailor the appropriate security and resiliency techniques based on mission-specific constraints, but much of the foundational threat modeling work has already been done by the SPARTA community to accelerate secure system development.

Final Enhancements in SPARTA v3.0

Several updates were made to further improve usability, automation, and technical relevance:

· Added new techniques focused on Space Domain Awareness (SDA), a growing area of concern as space becomes more congested and contested. These techniques highlight how adversaries might exploit gaps in orbital monitoring, proximity operations, or constellation visibility to gain an operational advantage, bringing cybersecurity and SDA into tighter alignment.

· Refined the naming of several techniques and countermeasures to support more seamless integration with automated tooling and reduce friction in data pipelines. These updates were made specifically to eliminate name collisions, improve pattern clarity, and enhance STIX-compatible automation workflows used for threat sharing, detection logic, and analysis platforms. Previously, techniques from different parent tactics that had the same title were creating difficulties in some tooling across the user base.

· SPARTA’s GUI received a series of improvements to enhance clarity, usability, and navigation for both first-time users and seasoned analysts. These changes reflect feedback from the community and align with our goal of making SPARTA not just technically robust but also user-friendly and accessible.

· Released the latest STIX v3.0 bundle, which reflects all updated techniques, mappings, and indicators to include the newly introduced IOBs. This ensures that users integrating SPARTA into their cyber-tooling ecosystems have access to the most current, machine-readable threat data.

These updates round out SPARTA v3.0 as the most complete and operationally aligned release to date, bringing together threat intelligence, vulnerability mapping, secure-by-design principles, and actionable artifacts to help defend today’s space missions. As always, we’ll continue to evolve SPARTA as the threat landscape shifts and community needs grow.

SPARTA v3.0 — What’s New? was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In response to growing cybersecurity challenges, the new Executive Order for Strengthening and Promoting Innovation in the Nation’s Cybersecurity signed on Jan. 16, 2025, is aimed at strengthening cybersecurity measures across federal agencies and critical infrastructure. The directive introduces new guidelines for modernizing cybersecurity practices, enhancing information sharing between the government and private sector, and improving overall resiliency to cyber threats.

To help unpack the implications of this Executive Order and what it means for space cybersecurity, we sat down with experts Brandon Bailey and Paul de Naray of The Aerospace Corporation. With extensive experience in cyber risk assessment and threat-based approaches for spacecraft cybersecurity protections, they offer valuable insights into how these changes could impact the space industry and broader national security landscape.

Follow along as they break down key elements of the Executive Order and share their perspectives on how organizations can prepare for the evolving cybersecurity landscape.

Can you explain what this new executive order on cybersecurity is and why it was introduced?

de Naray: The new executive order on cybersecurity focuses on strengthening the nation’s cybersecurity posture, particularly against adversarial nations. It was introduced to address the increasing sophistication and frequency of cyberattacks targeting critical infrastructure, federal systems, and private enterprises. Its goals include securing software supply chains, enhancing cloud and federal communications security, and promoting innovative solutions to evolving threats.

Are there aspects of the executive order that specifically apply to space systems?

de Naray: There are multiple aspects that will indirectly apply to space systems, but are two portions of the direction that specifically apply to space civil systems and space National Security Systems (NSS). NASA, USGS, and NOAA have been directed to recommend to the FAR Council updates for civil space cybersecurity requirements that are risk-based and tiered. For space NSS, the CNSS has been directed to review and update relevant policies and guidance for space system cybersecurity.

What specific space system cybersecurity challenges is this executive order designed to address?

de Naray: In the context of space National Security Systems, the EO is focused on three major areas: intrusion detection; hardware roots of trust for secure booting; and the development and deployment of security patches. This is why each of these matter:

· Intrusion detection: Space systems operate in remote environments, making real-time anomaly detection and responses a critical aspect for cyber resiliency.

· Hardware root of trust: Ensuring secure boot processes prevent adversaries from injecting malicious code during startup and enabling secure system recovery.

· Patching challenges: Safely deploying updates to systems in orbit without disrupting operations or compromising reliability.

Why should the average person care about this executive order? How might it affect them directly or indirectly?

de Naray: While the EO focuses on more than just space systems, space underpins critical services like global communications, navigation (like GPS), and national defense. Securing these systems ensures continuity of the services that people rely on daily and protects against disruptions that could affect the economy, public safety, and security for everyone.

How could this executive order change how space companies and agencies approach cybersecurity?

Bailey: Agencies managing space NSS will need to adopt robust intrusion detection and prevention systems tailored for space assets, implement secure boot processes leveraging hardware-based trust mechanisms, and establish streamlined and secure patch management protocols. Contractors working on government space systems will need to align their practices with these updated requirements.

What are some real-world space system examples of risks this order is trying to prevent or minimize?

Bailey: One example is the ViaSat incident that was experienced in 2022 during the Ukraine conflict. The malware deployed compromised the boot memory, which likely could have been prevented using hardware root of trust and secure boot.

What role does cybersecurity play in the broader space industry, and how is The Aerospace Corporation leading in this area?

Bailey: Cybersecurity ensures the resilience of space NSS against adversaries who seek to exploit vulnerabilities for espionage, disruption, or control. Aerospace plays a leading role in developing and implementing frameworks like the Space Attack Research and Tactic Analysis (SPARTA) matrix to enhance security across ground, link, and space segments. Aerospace’s contributions through publications, frameworks, and guidance highlight a comprehensive strategy for securing space missions.

By integrating threat-informed policies, practical countermeasures, and robust testing methodologies, Aerospace proactively provides knowledge to protect and secure the space domain from cyber and counterspace threats, ensuring mission success and the resilience of space infrastructure.

Looking at SPARTA — How does this proactive cybersecurity work contribute to national security and public safety?

Bailey: SPARTA’s approach places an emphasis on attacker technique/methods and their countermeasures. SPARTA has documented many of the methods of attack, and the benefits of countermeasures like intrusion detection align perfectly with this new EO’s focus areas. Its ability to provide actionable insights and countermeasures supports both proactive defenses and reactive responses, directly strengthening national security. SPARTA provides sample requirements and other insights to why it is imperative that these types of defenses are necessary in the current threat environment.

Do you foresee any challenges industries might face in complying with this order? How are we positioned to help address those challenges?

Bailey: Industries may face challenges in complying with the EO due to the limited Technology Readiness Level (TRL) of solutions tailored for space systems. For example, implementing secure boot mechanisms may require radiation-hardened chips, which are not yet widely available. Similarly, Commercial Off-The-Shelf (COTS) intrusion detection systems (IDS) for spacecraft are in their infancy and often need customization for the unique constraints of space environments. Developing secure, resilient patching protocols that function effectively in space also presents a challenge, given the remote nature and operational constraints of on-orbit systems.

Despite the challenges posed by limited TRL solutions and the technical complexities of implementation, these advancements are necessary to address the growing and sophisticated threats to space systems, which are critical to national security and global infrastructure.

What opportunities could the guidance in this executive order create for innovation in cybersecurity, particularly in the space industry?

Bailey: This guidance creates opportunities to advance the TRL of critical cybersecurity solutions for space systems. For example, it encourages the development of radiation-hardened secure boot chips, space-specific IDS, and resilient patching protocols.

These efforts not only address current gaps but also solve hard, necessary problems to mitigate evolving threats. By fostering innovation in these areas, the guidance provides a pathway to build robust, scalable solutions that ensure the resilience of space systems against increasingly sophisticated adversaries.

How do you see the cybersecurity landscape evolving in the next few years, and how are we preparing for that future?

Bailey: The future of cybersecurity for space systems will be shaped by the increasing reliance on satellite constellations, the need for operational uptime, and the accelerating speed of cyber threats.

As constellations grow in size and complexity, they amplify the attack surface while requiring seamless coordination and synchronization. The expectation for uninterrupted service, combined with the rapid pace of cyberattacks, demands a shift toward autonomous cyber management and response capabilities.

Automated solutions will be critical to ensure real-time threat detection, decision-making, and response without reliance on ground control, which often faces delays due to the vast distances involved in space operations.

Furthermore, space systems must evolve to include resilient architectures capable of self-healing and adapting to threats in contested environments to ensure continued functionality even in the presence of cyber attacks.

To go further in depth into this topic and for greater detail on how Aerospace’s SPARTA framework guides system security engineering efforts, check out the latest cybersecurity article in the Aerospace TechBlog.

What the Latest Cybersecurity Executive Order Could Mean for Space was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

More money has been invested in developing new space technology in the past few years than at any point in history, thanks to a growing commercial space sector’s increasing value within global economies, the business-to-business marketplace, and everyday life.

While investment momentum continues, the space capabilities and technologies it produces are finding it a bit more difficult to take flight. To find out why, we spoke with Ron Birk, Principal Director for Aerospace’s Space Enterprise Evolution Directorate (SEED). Birk is one of several Aerospace experts working with external partners both in the United States and internationally to help deploy innovative commercial capabilities to space through testbeds, proving grounds and other means.

Birk shared insights from his work with partners to accelerate the deployment of commercial capabilities to space and offered us a preview of the panel he will moderate at the upcoming SpaceCom 2025 conference on Jan. 30 in Orlando.

Can you first paint a picture of what this transformative moment for the space sector looks like? What’s driving it?

Birk: Transformative is a good word for the evolution occurring in the space sector. Over the past two decades, we have seen the commercial space sector, globally and here in the United States, grow at an exponential rate and take on more of a leading role in its own trajectory. For decades, government agencies played an outsized role in directing space investments and technology development. Aerospace companies helped build large, complex, and exquisite systems for “one-and-done” government missions. These purpose-built, bespoke systems took longer to engineer and build, integrate and test to ensure reliable operations in space.

Today, while government remains a key buyer and investor in space, the power dynamic is shifting to include a commercial-led approach. As private companies introduce new business models and space capabilities — some of which are reusable, including launch — government is increasingly looking to take advantage of the pace and dynamism of commercial innovation. A growing space B2B supplier marketplace is also taking shape.

How is this shift in government focus — capitalizing on the pace of commercial innovation — happening in practice?

Birk: From a policy and strategic standpoint, a subject with widespread interest and agreement is the need to go beyond development to accelerate the deployment of innovative space capabilities. There are multiple U.S. and international policies and strategies emphasizing this need, including the National Space Policy, NASA Strategic Plan, Department of Defense Commercial Space Integration Strategy, and directives from key allies in Australia and the United Kingdom.

Those are positive developments on paper, and certainly in practice positive strides are being made to implement those approaches, though we have room for improvement in making sure the capabilities, once they’re developed, actually make it into space.

This brings us to the particular quandary you’re speaking out about — what we’re calling the Flight-Proven Paradox. What is this?

Birk: Simply put, critical space capabilities — the results of all that time and treasure being invested and expended to develop new innovative technologies — are not being deployed in space at pace with development, primarily because they have not previously been deployed in space. This is the paradox: the expectation to increase deploying space capabilities at the same time there are expectations to only fly new capabilities that have already been flown.

So, because something hasn’t flown in space, it can’t go to space…until it goes to space?

Birk: Correct, in essence. A lot of new technology is being developed that is not being deployed to space. The marketplace for in-space servicing, assembly, and manufacturing — or ISAM — is one good example. The percentage of capabilities being invested in, developed and actually reaching outer space is incredibly low. We are tracking more than 400 companies developing one or more ISAM capabilities, but only a fraction of those capabilities — less than 2 percent — have flown in space.

Is this rooted in some developmental failure?

Birk: It is true that some companies and capabilities fail to clear what’s commonly referred to as the “Valley of Death,” where they do not succeed in moving from research to development, for one or more reasons. However, that particular hurdle doesn’t apply to the problem I’m describing.

Technologies are in fact clearing that Developmental Valley of Death and reaching TRL maturity. They are developed and ready to fly, but they are not being adopted or deployed. And it’s not for lack of demand for those capabilities. They are failing to clear a second Deployment Valley of Death, a second bridge to cross to realize return on investment (ROI) on investments in space capabilities.

You have us at a loss. What’s causing this?

Birk: In short, it’s an expectation among key stakeholders (including investors, insurers, regulators, acquirers, integrators) that in order to have confidence in the new capability, the new capability has been “flight proven.” It’s a byproduct of how the space community has traditionally addressed readiness when debuting new technology in space. In the past everything was built according to spec for specific mission needs for purpose-built — “one and done” — space systems, and development timelines took as long as they needed to build the necessary trust to launch and deploy to space.

That’s model does not align with space solutions in the current era. Speed is the need, and that’s why harnessing the pace of commercial innovation is so desirable. There’s greater emphasis for government buyers to deliver innovative solutions more quickly, and they have a growing commercial supplier marketplace to source from. Commercial players in turn aim to prove return on investment more quickly. To realize ROI for a space capability, you have to first get to space.

A “commercial-first” approach calls for “buying what you can” and only “building what you must.” Unfortunately, while gatekeepers to space have resolved themselves to buy what they can in policy, and while there is support for and investment in the prolific development of innovative capabilities, there is insufficient trust for these capabilities to deploy once they’re developed. Something that is flight-proven is much easier to trust.

You mentioned gatekeepers?

Birk: We’ve identified five stakeholder groups whose trust is imperative to earn for a technology to fly to space: acquirers, insurers, investors, integrators and regulators. Each group has influence on whether a capability’s ride to space is funded, approved, and executed.

I want to be clear that gatekeepers are essential and are not responsible for this Flight-Proven Paradox. This is nothing nefarious. Space is hard, and trust is crucial. They are simply applying the same rigor in scrutinizing technologies — what’s different is how many capabilities are being developed faster than we can fly them. Further, many distinct capabilities are attempting to reach space at the same time, where they will have to operate together safely and effectively with each other and with capabilities that come after them.

This concept of evolving space ecosystems is an evolving part of the calculus. In this new dynamic, we need to work closely with gatekeepers to understand their concerns and find ways to alleviate them. We need an equivalent to the trust that flight-proven status provides, which can build confidence in new technologies as quickly as they are reaching operational readiness. That’s the solution.

Without flying something to space to see if it can safely and successfully operate in space, what can be done to build this trust?

Birk: So glad you asked! We are working with many partners to establish the framework for what a “flight-proven equivalent” entails and streamlining access to the needed testing resources to achieve it. A crucial first step is testing and proving these capabilities in as close to a spacelike environment as possible. If we “test like we fly” with sufficient technical rigor, gatekeepers should feel sufficient trust that a capability will behave as intended when it’s deployed to space.

Fortunately, significant testing infrastructure exists for this purpose in the U.S. and across the globe. Aerospace, for example, has numerous lab spaces available to U.S. and organizations from allied nations to test propulsion and robotic technologies, among other disciplines. NASA has identified more than 50 facilities for ISAM testing. Testbeds can be physical lab spaces or digital engineering environments; in fact, some capabilities are most ideal to test using digital twins — a combination of physical and digital test elements.

That’s just here on Earth. On orbit, the International Space Station is the best example of an accessible testbed, and future commercial space stations in low Earth orbit may provide similar opportunities. We consider the Moon a testbed, too, when we look at future space exploration to more distant worlds.

So, all told, what’s the next step to resolving this Flight-Proven Paradox using these testbeds and proving grounds?

Birk: Like many things if we make it easier to test like we fly, it will be easier to raise trust levels. Aerospace and several collaborators — including NASA, the Space ISAC and international partners — are building an integrated network of testbeds and proving grounds and helping streamline commercial companies’ access to them. The Space ISAC will soon publish a portal with which to access the first wave of networked testbeds, titled the ASC-100.

We’re regularly engaging with the community of gatekeepers I mentioned earlier, including their input in the solution we are creating. I encourage anyone wanting to learn more or contribute to contact us. With any luck we will see more innovative, trusted capabilities moving from concept to deployment in space.

Are New Space Innovations Actually Making It to Space? was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Authors: Brandon Bailey and Paul de Naray; January 2025

As the national security cybersecurity threat landscape continues to evolve, particularly in the space domain, the federal government has adjusted required cybersecurity capabilities to safeguard national assets. The newly published Executive Order on Strengthening and Promoting Innovation in the Nation’s Cybersecurity directs the CNSS to update space system cybersecurity practices for hardware-based security measures like secure booting, robust methods of intrusion detection and command authentication, and more responsive system protection through security patching. These recommendations are encouraging as they track the analysis and research at the forefront of space national security system (NSS) cybersecurity. We have previously examined and captured these concepts over the past five years through work that includes: initial calls to action for space NSS risk and possible countermeasures in the 2019 Defending Spacecraft in the Cyber Domain; defining threat-based risk mitigation to space NSS and how defense-in-depth concepts assist protection in the 2021 TOR-2021–01333 Rev A; and most recently integrating and formalizing these concepts under CNSS guidance recommendations for cybersecurity control baseline tailoring, enriched control selection rationale, and sample requirements to guide formal acquisition efforts in the 2023 TOR-2023–02161 Rev A.

All these publications have been cleared for public release to encourage adoption across space NSSs, commercial providers of space NSS capability, and the wider federal government and international space enterprise. Furthermore, The Aerospace Corporation has provided the SPARTA framework as a publicly available website that serves as a common knowledge base to assist and guide system security engineering efforts. We find that The Aerospace Corporation’s work has contributed significantly as groundwork for many of the principles now recognized as essential by the latest Executive Order on Strengthening and Promoting Innovation in the Nation’s Cybersecurity. To further aid understanding and adoption of capabilities outlined in the executive order, we provide an overview of these concepts through SPARTA-based knowledge.

Intrusion Detection

SVs operate in isolated environments where they may be targeted by sophisticated adversaries. An onboard SV intrusion detection and prevention system (IDPS) enables the early detection of malicious activities in real-time, so the SV can take immediate action to prevent further damage. While the EO does not specify “prevention” measures, we interpret that this is implied in the direction as there is little value to perform detection without response and prevention based on the detection. Considering typical gaps in communication between ground control and an SV due to ground station coverage, an SV must have autonomous capabilities to respond to threats. These capabilities can be critical for maintaining mission continuity and safety during continuous SV operation.

The Executive Order’s direction for cyber intrusion detection and prevention aligns with Aerospace’s advocacy for implementing these capabilities into spacecraft and ground stations. Aerospace has examined the deployment of IDPS mechanisms across both ground systems and space vehicles. The 2019 paper, Defending Spacecraft in the Cyber Domain, explains:

“The backbone of a cyber-resilient spacecraft should be a robust intrusion detection system. The IDS should consist of continuous monitoring of telemetry, command sequences, command receiver status, shared bus traffic, and flight software configuration and operating states. From a telemetry monitoring perspective, several parameters exist that have the highest likelihood of indicating a cyberattack against a spacecraft and should be actively monitored on the ground and looking into the future onboard the spacecraft with the IDS. The IDS should implement both signatures and machine-learning based anomaly detection techniques.”

This was later emphasized in TOR-2021–01333 Rev A via the threats SV-DCO-1, SV-MA-5, and SV-AV-6 where recommended cyber requirements were published stating “the SV shall have intrusion detection, intrusion prevention, and auditing/logging capability on-board the SV that can alert and downlink onboard cyber information to the mission ground station.” This requirement was further decomposed into lower-level requirements within the document and has since been incorporated into SPARTA under the countermeasure On-board Intrusion Detection & Prevention. These specific cybersecurity controls associated with this countermeasure is further captured in TOR-2023–02161 Rev A through the notional maximum and minimum control baselines. This work demonstrates robust rationale and guidance to incorporate intrusion detection and prevention into space NSS acquisitions.

Moving beyond guidance, Aerospace has also recently demonstrated SV onboard intrusion detection with the SpaceCOP (previously named Starshield) prototype that was operated within the on-orbit SLINGSHOT-1 CubeSat. This capability investigated machine learning model development for command anomaly prediction, telemetry anomaly prediction, vehicle bus traffic pattern prediction, and system state anomaly detection. The capabilities and results are described further report OTR 2024–00598, which has been approved for public release.

Use of Hardware Roots of Trust for Secure Booting

Aerospace has examined methodologies for securing space systems against evolving threats that could target SV boot memory and initialization sequences. Root of trust was first discussed in the 2019 paper Defending Spacecraft in the Cyber Domain as being necessary for future SV architecture.

“It is important for the computing module to be able to access a set of functions and commands that it trusts; that is, that it knows to be true. This concept is referred to as root of trust (RoT) and should be included in the spacecraft design. The RoT serves as a separate compute engine controlling the trusted computing platform cryptographic processor. The RoT computing module should be implemented on radiation-tolerant burn-in (nonprogrammable) equipment. With RoT, a device can always be trusted to operate as expected. RoT functions, such as verifying the device’s own code and configuration, must be implemented in secure hardware By checking the security of each stage of power-up, RoT devices form the first link in a chain of trust that protects the spacecraft.”

The Aerospace Corporation has further matured hardware root of trust and secure boot mechanisms through the definition of threat SV-AV-3, which then drove definition of secure initialization sequences in the SPARTA framework with the Compromise Boot Memory countermeasure that ensures only verified and trusted software is executed during the boot process. The SPARTA framework further outlines a series of countermeasures designed to provide a comprehensive defense against such attacks. These countermeasures include:

· Software Digital Signature: Requiring that all software used during the boot process is signed with digital signatures, ensuring authenticity and integrity before execution.

· Secure boot: Establishing secure boot protocols that rely on hardware roots of trust, preventing compromised or unauthorized software from executing during system initialization.

· Tamper Protection: Incorporating physical and software-based measures to detect and prevent unauthorized access or manipulation of boot memory components.

SPARTA extends beyond root of trust by recommending other countermeasures to ensure provenance is maintained for spacecraft software.

· Software Source Control: Ensuring that all software sources are monitored, managed, and verified to maintain the integrity of boot sequences.

· Configuration Management: Maintaining strict version control and configuration protocols to track changes and verify that only approved software versions are used in critical boot processes.

Development and Deployment of Security Patches

When considering Space NSS architectures in comparison to traditional enterprise IT solutions, these systems will likely face unique challenges for effective patch management. SVs operate in an isolated environment where human physical access almost never occurs, and this drives the development of remote and resilient patching strategies. If there is an issue with software patching, then physical intervention for recovery will not be possible; such as external drive boot recovery. Additionally, mission operations demand near-constant uptime for critical space capabilities and this means that patch deployment must be carefully coordinated to avoid unnecessary mission disruption. Furthermore, many currently operational systems utilize less-current technology that may not be readily patched without significant engineering work. As a final challenge, SV patching includes the factors of limited size, weight, and power (SWaP) available on these remote platforms. Without deliberate efforts to consider SWaP for security patching, there will be limits in the amount of capability available to leverage for redundant and resilient patching concepts.

To address these unique challenges there will need to be specific efforts applied for implementing tailored SV patch management processes. Aerospace TOR-2021–01333 Rev A, underscored the importance of developing secure and resilient processes for patching space systems vulnerabilities without compromising mission operations. Specifically, threat SV-SP-9 highlighted the inherent risks associated with software updates and stressed that the patch management architecture must be designed from the outset to minimize these risks. This threat is addressed in SPARTA through associated countermeasures and sample requirements at varying specificity to guide the acquisition of capability for on-orbit software updates.

Aerospace’s guidance emphasizes that the update process itself can become a potential attack vector if not properly engineered. SPARTA expands on this by detailing countermeasures that ensure robust configuration management, rigorous testing protocols, and secure transmission methods are in place before updating software occurs. This proactive approach includes a focus on validating patches through dynamic and static testing, ensuring compatibility with existing mission-critical software, and monitoring for any anomalies post-deployment. The framework also highlights the significance of addressing known vulnerabilities, as the method of exploiting unpatched systems is a well-established adversarial approach. SPARTA’s guidelines help prevent known vulnerabilities from becoming points of compromise by ensuring software patching, including operating systems, is managed appropriately. A further consideration for secure patching will be the combination of these capabilities with root of trust capability. A root of trust enables secure recovery of SV software in cases of malicious and unintended effects. An effective security patching capability should consider resilience aspects provided by root of trust to enable remote recovery.

By integrating these principles, Aerospace guidance not only calls for secure patching mechanisms but also frames a comprehensive approach to maintain spacecraft integrity, ensure operational continuity, and mitigate the evolving threat landscape targeting software vulnerabilities. The Executive Order’s push for development, testing, and deployment of security patches reflects Aerospace’s longstanding focus on resilient patching strategies that are vital to maintaining secure spacecraft operations.

Conclusions

The Aerospace Corporation’s proactive research demonstrates a forward-thinking approach to securing space NSS. As the federal government and international bodies increasingly endorse key cybersecurity measures, Aerospace has performed foundational analysis of these concepts through years of research and publication for NSS customers interests. Aerospace has consistently pushed to examine and define guidance supporting the emerging priorities of policymakers and standards organizations worldwide. SPARTA’s alignment with these evolving standards highlights Aerospace’s long-term commitment to developing resilient security architectures that protect mission-critical operations from evolving adversarial tactics.

Ultimately, Aerospace’s contributions through publications, frameworks, and guidance highlight a comprehensive strategy for securing space missions. By integrating threat-informed policies, practical countermeasures, and robust testing methodologies, Aerospace proactively provides knowledge to protect and secure the space domain from cyber and counterspace threats, ensuring mission success and the resilience of space infrastructure.

Pioneering Space Cybersecurity — How Aerospace Corporation’s Guidance Aligns with New Executive… was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The SPARTA framework offers space professionals a taxonomy of potential cyber threats to spacecraft and space missions. v2.0 delivers significant updates.

Authors: Brandon Bailey, Brad Roeher, Randi Tinney; June 2024

Version 2.0 Update #1: Spacecraft Cybersecurity Requirements

Prior to SPARTA’s deployment in October 2022, The Aerospace Corporation published TOR 2021–01333 REV A as a threat-oriented approach to space cyber risk assessment. The primary result of this analysis was a set of products to define risk driven requirements to create better space system protection during acquisition and operations. SPARTA’s initial 1.0 deployment included this content under related work with requirements correlated to SPARTA techniques, countermeasures, and other aspects.

The SPARTA user community saw value in this initial content and sought an extension of that requirements work. We present SPARTA 2.0 with additional focus on risk-driven requirements analysis and correlating mappings with NIST SP 800–53 revision 5 controls. In SPARTA 2.0 there is now better correlation of risk-driven control selection and a 40% increase in the number of requirements available for system protection.

A driving factor for the new SPARTA 2.0 content is Aerospace’s published TOR-2023–02161 Rev A, which is a cybersecurity profile approach to defining and performing threat-focused space segment risk assessment. This cybersecurity profile significantly leverages SPARTA to show tailoring rationale of the Committee on National Security Systems Instruction (CNSSI) №1253 control baseline guidance. This tailoring is performed on both the High-High-High impact baseline and the space platform overlay in Attachment 2 to Appendix F. A threat-focused space segment analysis creates unique tailoring and provides a notional maximum control baseline from which system security engineering can more efficiently define cybersecurity requirements before development begins. TOR-2023–02161 Rev A also presents a notional minimum control baseline definition that is based on SPARTA notional risk scores.

Both baselines are considered notional because space segments can be unique based on the mission purpose, risk tolerance, expected threats, and other risk aspects that uniquely tailor a control baseline. While these notional min/max baselines were created in the context of National Security Systems for the CNSSI, the baselines can still provide a more accurate starting point for any space systems engineer developing a cybersecurity control baseline. If another entity has different risk considerations, then these notional baselines enable understanding and justification based on the rationale provided in TOR-2023–02161 Rev A.

Leveraging SPARTA’s approach for requirements and the new cybersecurity profile, SPARTA users can leverage the tooling to generate custom requirements baselines. This can be done via the countermeasure mapper or control mapper tools. Users can generate a control baseline based on selecting individual countermeasures that link to controls, directly selecting applicable NIST controls, or using the JSON creator ability to create JSON files for importing a separately created baseline. These methods allow a user to create a defensive security posture depiction via the SPARTA control mapper, such as the TOR-2023–02161 Rev A notional minimum control baseline shown in the figure below.

Then a user can simply click “Export Excel” and an example set of requirements will be generated from SPARTA content. It is still recommended that these example requirements are examined and further tailored to meet the user’s specific mission goals. For example, the example requirement text will contain braces “[]” as placeholders for user content specific to their system design. Nonetheless, this set of tailored example requirements provides a translation from NIST security control principles into requirements and is a great starting point before development efforts begin.

The combination of TOR-2023–02161 Rev A and SPARTA’s translation into requirements provides a robust capabilities for systems security engineering across a system development lifecycle. The SPARTA content enables cybersecurity acquisition requirements on a contract, control selection rationale to guide implementation, and knowledge for security documentation that guide accurate security control assessments.

Translating SPARTA techniques and countermeasures into controls with example shall-statement requirements is crucial for several reasons. This approach ensures that high-level security goals are systematically broken down into actionable and verifiable requirements that can be implemented and tested. This requirements alignment is essential for maintaining the integrity and security of spacecraft systems, since it bridges the gap between abstract security concepts and practical, enforceable measures. By correlating these requirements with NIST controls, organizations can ensure compliance with established cybersecurity standards, thereby enhancing the robustness of their security posture.

Additionally, this translation process facilitates clear communication among stakeholders, including engineers, system designers, and security professionals, ensuring everyone understands the specific actions needed to mitigate identified threats. This process also aids in the development of comprehensive security plans that are aligned with both industry best practices and regulatory requirements. Implementing these shall-statements helps in building a defense-in-depth strategy that ensures threats are addressed with appropriate countermeasures. This structured approach not only helps in proactively preventing cyber-attacks but also in demonstrating due diligence and accountability in spacecraft cybersecurity management.

Version 2.0 Update #2: Space Segment Cybersecurity Profile — TOR-2023–02161 Rev A

A dedicated page for Space Segment Cybersecurity Profile — TOR-2023–02161 Rev A has also been deployed. Within the TOR, there are several baseline control set tailoring products that provide rationale for exclusion or addition of controls from a starting baseline. To make this content easier to consume, SPARTA has included a table of controls and buttons to toggle between All NIST SP 800–53 Controls, TOR Minimum, and TOR Maximum. Additionally, min/max indicators have also been added to the control exports via https://sparta.aerospace.org/resources/working-with. This should provide SPARTA users with an easier method to leverage the TOR’s information on notional minimum and maximum security control baselines linked to SPARTA techniques.

Version 2.0 Update #3: Spacecraft Functional Decomposition

In SPARTA 2.0, an informational guide to spacecraft subsystems has been deployed. This page provides an in-depth look at the various critical components that make up a spacecraft, offering detailed descriptions and functions of each subsystem. Each section is designed to give you a clear understanding of the roles these subsystems play in the overall operation and mission success of the spacecraft. To explore the information, simply click on the title of any subsystem within the tool. This will expand to reveal information about its structure, functionality, and significance.

Additionally, you will find specific cybersecurity techniques from the SPARTA framework applicable to each subsystem, along with recommended countermeasures to mitigate potential threats. This integrated approach ensures not only an operational understanding of the spacecraft’s components but also emphasizes the importance of securing these subsystems against cyber vulnerabilities. Whether you’re looking to understand the propulsion system, communications bus, ADCS, or any other subsystem, our page serves as a vital resource for both technical knowledge and cybersecurity practices. Below is an example of selecting Command & Data Handling (C&DH) subsystem in the tool. As SPARTA continues to mature, this spacecraft decomposition will help decompose threats/techniques and countermeasures to each subsystem.

Research has indicated that attacks against each subsystem may have different detection and mitigation strategies therefore getting more granular with information will only help the space cyber community as it matures alongside SPARTA.

Version 2.0 Update #4: Spacecraft Decomposition Mapper

Building upon the functional decomposition and the correlating techniques or countermeasures per subsystem, a new tool called Spacecraft Decomposition Mapper has also been deployed in SPARTA 2.0. This tool is similar to the countermeasure mapper or the control mapper tools where the user can select items and potential applicable techniques and countermeasures are visually displayed. The intent of this tool is to better understand where SPARTA techniques or countermeasures might be applicable at the subsystem level for a spacecraft. The goal to provide an easier method to down select potential countermeasures to apply at the subsystem level. This can also be combined with the Export to Excel functionality to generate a potential list of requirements to tailor at the subsystem level for security engineers.

SPARTA v2.0 Updates — What’s New? was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

As night fell on May 10, millions of curious people across the globe ventured outside in the hopes of seeing the lights in the darkness. From New York and Washington to Florida and Texas, the night’s aurora borealis was truly a sight to behold. For many, this event will be forever etched in their memory as this was their first time seeing the colorful display of the northern lights thanks to near-perfect conditions and a nearly 20-year high of solar activity.

Aerospace recently sat down with Vince Ledvina in the Space Sciences Department to discuss this rare event and pick his brain more about space weather. As a first-year space physics Ph.D. student at the University of Alaska Fairbanks, Ledvina is perhaps more recognized as “The Aurora Guy” with more than 350,000 followers across social media. Ledvina, who is currently an intern at Aerospace, was excited to share his passion with the Aerospace team.

What sparked your interest in space weather and aurora research? How has that interest shaped your career path?

I saw the aurora for the first time in 2003 when I was four years old coming home from trick-or-treating. I think that experience as a child embedded a latent passion for aurora chasing that eventually resurfaced in high school. Through aurora photography, I was more or less forced to learn the science of space weather, auroras, and space physics. I became a space-weather enthusiast, tracking solar flares, coronal mass ejections (CMEs), and all sorts of phenomena that would mean higher chances of aurora near me in Minnesota.

I did my undergraduate studies at the University of North Dakota and chose the school due to its proximity to the Canadian border and dark skies. I spent those four years aurora chasing, teaching others how to predict and forecast the northern lights, and people started calling me “The Aurora Guy” on campus. I then joined the University of Alaska Fairbanks in 2023 as a space physics graduate student.

From a scientific standpoint, what is it about auroras that draws in your fascination?

The aurora is beautiful and majestic to witness and photograph, but it’s also a proxy for geomagnetic activity and space weather and can cause its own effects as well. I enjoy the applied side of space physics more than the fundamental science, and studying the ways in which the aurora affects space assets is very interesting to me. My Ph.D. research specifically focuses on auroral beads, which are the formations seen right before auroral substorm onset. Auroral substorms are daily space-weather phenomena that dump large amounts of energy into the atmosphere in the form of charged particles. This can change the radiation environment and the density of the upper atmosphere.

Did you get to see this weekend’s auroras? Have you ever seen auroras in an unexpected place before?

I did! I was on vacation in India when the storm hit, and I saw it just a few blocks from my hotel in Leh. Honestly, I’ve never seen the aurora in quite as unusual a location as I did last weekend. Normally, I am well positioned whenever any geomagnetic activity is forecasted. This time, I thought for sure I wouldn’t see the aurora, but I was pleasantly surprised!

What was special about this past weekend’s solar storm?

Friday night was comparable to the historic storms in 2003 and 1989. They’re roughly 1-in-20-years events, and this latest storm is one of the largest we have seen since the start of the Space Age.

Some numbers from the event:

• Max speed: 1005 km/s
• Max total field: 73.7 nT (84 nT at STEREO-A) Min Bz field: -50.1 nT Min Dst: -412 nT

The sheer number of CMEs directed at Earth at once was also impressive. At one point, there were over five CMEs with some Earth-directed components en route to our planet. We called this a “CME train” on social media. It is likely these CMEs combined or interacted to create a stronger impact at Earth, driving the G5 (the highest classification) geomagnetic storm.

This was the first major geomagnetic storm that captured the attention of the broader public. The last solar storm of this caliber took place in 2003 when smartphones capable of taking aurora photos were not available. The number of observers of this event was astounding. Combine this with a relatively good forecast by most agencies, and this geomagnetic storm was well anticipated and lived up to the hype.

The solar storms that produce these beautiful auroras can also disrupt GPS systems, satellite communications, and even terrestrial power grids. Government agencies warned us of this ahead of time, and there are news reports of some disruptions. What causes this?

Large geomagnetic storms can affect a number of industry domains. During a day of such a big storm, drag can be equivalent to maybe a week or two of “normal” conditions. The satellites lose the propellant/lifetime that they wouldn’t have if there was no such storm. The increased radiation over the poles also caused some airlines to re-route polar flights.

Intense currents in the aurora can drive complementary currents in the ground due to Faraday’s law of induction. Depending on the design of the power lines and the ground conductivity, these geomagnetically-induced currents (GICs) can damage vulnerable transforms and potentially cause widespread blackouts.

During geomagnetic storms, the radiation belts surrounding Earth can become enhanced with energized particles. These particles can impact Earth-orbiting satellites by charging their surfaces and causing electronics issues. These effects can degrade satellite performance or cause failures that can disable satellites completely.

Finally, during intense bursts of aurora, the increased electron content in the ionosphere can disrupt communications between the ground and satellites in space. GPS signals can be affected. There were reports from farmers of precision-farming GPS equipment losing lock during the geomagnetic storm.

Luckily, NOAA’s Space Weather Prediction Center is well prepared for a G5 storm and took all the necessary precautions and communicated hazards to their designated customers to ensure ground-based and space-based assets were kept safe and operational.

Tell us about your research on how auroras can help us understand satellite performance and the space radiation environment.

I am researching auroral beads and what causes them to form. The formation mechanism of the beads is tied to the overall dynamics of auroral substorm initiation. Auroral substorms are what we see occur as a result of a global restructuring of the nightside magnetosphere, or a magnetospheric substorm. During magnetospheric substorms, magnetic fields bend and snap surrounding Earth, releasing huge amounts of energy. These substorms fling charged particles towards the nightside of Earth like a slingshot. These particles can change the radiation environments in geostationary and low Earth orbits as well as heat the upper atmosphere. These particles create auroras when they impact our atmosphere, and this is the “auroral” substorm.

Auroral substorms heat the upper atmosphere. It expands and increases drag on orbiting satellites, which can affect their performance. Magnetospheric substorms can also increase the amounts and energies of electrons and ions around Earth (e.g., the radiation belts). An increased number of energetic particles can create higher chances of electronics failures in satellites flying through these areas. Auroral beads are seen right before auroral substorms and are tied to its initiation mechanism. Solving the question of what causes auroral beads will be an important piece in solving the puzzle of auroral substorms and magnetospheric substorms. We don’t know yet how substorms are formed, and this is a giant hole in our understanding of space physics and the near-Earth space environment.

How rare would you say moments like this past weekend are, where areas far from the typical aurora viewing area are treated to such a show?

These types of events happen on average once every 20 years or so. Auroras were reported as south as India, Hawaii, and Puerto Rico, and as north as Namibia, South Africa, and Argentina.

What does it feel like in the midst of such a nationwide experience like this past weekend to have so many people share your passion for these events?

It’s incredibly exciting and represents a key moment that we need to capitalize on to increase the public’s awareness of space weather and how it can affect our modern world. People want to learn more, and a new wave of aurora chasers was just born. It’s time to be a guiding light and show them the beauty and power of space weather.

Anything else the public should know?

It could happen again! Solar cycle 25 is nowhere close to being over. It’s possible that we may see another extreme geomagnetic storm in the future.

This last storm was important for testing our capabilities at mitigating a large space-weather event. I am excited for all the new science that will emerge from this storm as well. Since the last storm of this magnitude in 2003, we have so many more instruments and satellites working to measure the space radiation environment. It will be super interesting to see what effects this storm had on satellites, communications, and power grids. The dust is still settling, so we will just have to wait and see what we discover.

A Night to Remember: Q&A on the Northern Lights with “The Aurora Guy” was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The SPARTA framework offers space professionals a taxonomy of potential cyber threats to spacecraft and space missions. v1.6 includes four notable updates.

Authors: Brandon Bailey, Brad Roeher, and Randi Tinney

Version 1.6 Update #1: NASA’s Space Security Best Practice Guide Mapping

The Space Security: Best Practices Guide (BPG) from NASA provides guidance on mission security implementation in the form of principles which are coupled with applicable security controls that cover both the space vehicle and the ground segment.

According to the BPG, “the principles are meant to be easily achievable regardless of mission, program, or project size, scope, or whether international, corporate, or university. The principles selected focus on a risk-based approach to mitigating vulnerabilities, that are impediments to mission success. These principles were identified as an initial starting point of critical implementations for NASA missions to consider. The underlying security principles and associated controls were identified through an iterative process to address today’s cyber actors Tactics, Techniques, and Procedures (TTPs) used in attempts to compromise mission capabilities.”

The BPG outlines security principles for the “Space Mission” in section 3.2 and for the “Ground” in section 3.3. Given SPARTA’s focus on the space segment, there is substantial overlap in the principles identified in section 3.2 of the BPG and SPARTA’s countermeasures. SPARTA’s countermeasures cover similar principles and/or best practices in their own right; therefore, Aerospace has mapped the 14 NASA BPG principles related to the space segment against SPARTA’s countermeasures. In all cases there were multiple SPARTA countermeasures that aligned with the principles discussed in the BPG. The intention of this mapping is not to replace the BPG but augment the BPG principles with additional context and information to help system engineers implement the principles.

Additionally, this mapping will provide implementers of the BPG a wealth of resources since the mapping will enable correlation to SPARTA techniques, their associated risk scores from the notional risk scoring tool, example requirements, as well as additional cross correlations to NIST 800–53, ISO 27001, and D3FEND. Leveraging SPARTA in addition to the BPG as a source for threat-informed techniques offers benefits by providing a correlation between attacks and their associated defense strategies.

The intent of mapping SPARTA countermeasures to the BPG and standards like NIST SP 800–53 and ISO 27001 is to provide SPARTA users with additional perspective of the security principle as well as how the SPARTA countermeasure aligns with compliance/regulatory/best practices published by such standards bodies. Below is a sample excerpt from the table that contains the mappings.

Version 1.6 Update #2: Notional Risk Score Elaboration

In August of 2023 with version 1.4 of SPARTA, the Aerospace Corporation developed and incorporated space-cyber Notional Risk Scores (NRS) into the SPARTA framework, associating a notional evaluation of attack techniques leveraging a risk matrix. The intention of NRS is to provide practitioners with a starting point for space-cyber risk management, from which they can apply specific details (e.g., a reference architecture) to tailor NRS to evaluate their mission-specific space-cyber risks. NRS is a starting point for space developers and other approaches could be used to ensure less subjectivity as described in Towards Principled Risk Scores for Space Cyber Risk Management.

However, when performing risk assessments in a generic sense for a space system as SPARTA has done, subjectivity and subject matter expertise must be used in lieu of mission-specific technical details. The NRS page has been updated with a more detailed explanation of the approach used to calculate the 5x5 risk score for each technique within SPARTA. In addition to explaining the process, users can now download the NRS scores via an Excel Spreadsheet that contains all default NRS scores to include the 5x5 risk score and the applicable impact and likelihood scores for each system criticality level.

Version 1.6 Update #3: Using SPARTA to Conduct Space Vehicle Cyber Assessments

This presentation was created to assist assessors, penetration testers, and/or red teamers on a methodology to perform cyber assessments against space vehicles. To maximize value to the reader, it is recommended the reader is familiar with SPARTA content and comes from a testing background. An outline, including prerequisite/assumed knowledge, of the material within that presentation is below.

• Prerequisite(s) and assumed knowledge
– Space system knowledge; specifically, space vehicles
– Has conducted some level of offensive operations on a system
– Understands SPARTA / reviewed SPARTA resources (https://sparta.aerospace.org/resources/)

• Outline

– Space 101 (if needed — can skip if space SME)
– Assessments of Space Vehicles:

• Determining which techniques can have high impact and/or high likelihood
  – Decomposing the space vehicle, mission, and attack surface
• Build procedures to implement the techniques to execute on the SV
• Determine the actual impact in context of the mission upon execution of the technique(s)
• Determining risk based on results

– Using SPARTA to help with recommendation / countermeasures
– Alternative approach for assessing space vehicles

Update #4: Additional References

In SPARTA version 1.6, approximately 30 new unique references were added across 70 SPARTA techniques and all 9 tactics. See the update page for a listing of the techniques that have additional references. Extensive literature review was conducted across hundreds of sources for correlation to the techniques. The intent of this exercise was to provide open-source evidence where appropriate.

SPARTA v1.6 — What’s New? was originally published in Aerospace TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.