SPARTA v2.0 Updates — What’s New?

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.