The Space Security: Best Practices Guide (BPG) from NASA provides guidance on mission security implementation in the form of principles coupled with applicable 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 has security principles for the “Space Mission” in section 3.2 and “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 are similar principles and/or best practices in their own right; therefore, a mapping of the 14 space segment related principles has been performed 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, 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 with 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.
| ID | Name | Principle | Rationale | SPARTA Countermeasures |
| MI-ARCH-01 | Mission Essential Data Flow Function | The mission should establish and maintain a current and accurate data flow diagram covering mission essential data flows, including those that pass through mission-external service providers. | A good data flow diagram provides understanding what data is needed by the system, and how that data flows across networks and communications links. In turn, this provides essential insight to understand where particular risk to the system may emerge, and where additional scrutiny or defenses may be warranted. | CM0001 | CM0002 | CM0020 | CM0022 | CM0070 | CM0071 | CM0073 |
| MI-ARCH-02 | Mission Least Privilege Function | The mission should employ the principles of domain separation and least privilege for the on-board architecture, communications, and control. | Least privilege designs will protect the main processor and core control functions of the vehicle from compromised assemblies by limiting the actions that can be executed on shared buses and onboard networks from recognized attack vectors. Segmentation and boundary control on the vehicle will mitigate supply chain attacks in procured or provided assemblies and in onboard software of varying provenance, as well as operational vulnerabilities when multiple command paths are available (e.g., an instrument with its own command link). Fault management systems should be employed to power off or block non-safety-critical assemblies that exhibit behavior that suggests compromise or failure. | CM0022 | CM0031 | CM0032 | CM0037 | CM0038 | CM0039 | CM0040 | CM0050 | CM0065 | CM0067 |
| MI-AUTH-01 | Boundary Protection Function | The mission should establish a mediated access mechanism that prevents unauthorized access to critical subsystems in the space segment. | Cyber actors can exploit the ground system and use the ground segment to maliciously interact with the space vehicle. The boundary protection may be logical or physical. Functionality provides the following benefits:
|
CM0002 | CM0003 | CM0005 | CM0029 | CM0030 | CM0031 | CM0032 | CM0033 | CM0034 | CM0035 | CM0036 | CM0052 | CM0053 | CM0054 | CM0055 | CM0065 | CM0067 | CM0070 |
| MI-AUTH-02 | Comprehensive Authentication & Authorization Function | The mission should ensure only authenticated and authorized personnel, devices, and software are allowed to access the space mission system. |
|
CM0002 | CM0003 | CM0005 | CM0029 | CM0030 | CM0031 | CM0033 | CM0034 | CM0035 | CM0036 | CM0037 | CM0039 | CM0042 | CM0043 | CM0044 | CM0050 | CM0052 | CM0053 | CM0054 | CM0055 | CM0065 |
| MI-INTG-01 | Communications Survivability Function | The mission should be able to recover from communications jamming and spoofing attempts. | Communications systems using a shared medium are susceptible to jamming and spoofing, resulting in loss of access (denial of service) and potential loss of data integrity and availability. The prevalence of impacts to communications links in the RF and optical bands is increasing, as well as potential for targeted spoofing of communications links. | CM0002 | CM0003 | CM0029 | CM0030 | CM0031 | CM0032 | CM0033 | CM0034 | CM0035 | CM0036 | CM0042 | CM0044 | CM0068 | CM0070 | CM0074 | CM0075 | CM0083 | CM0086 |
| MI-INTG-02 | PNT Survivability Function | The mission should be able to recover from positioning, navigation, and timing jamming and spoofing attempts. | As a specific example of MI-INTG-01, space-based Positioning, Navigation, and Timing (PNT) relying on a GNSS signal may experience loss of signal (denial of service) and potential loss of the signal's data integrity. Manipulations (spoofing) of GNSS signal data may result in consequences to the space vehicles PNT. | CM0032 | CM0042 | CM0044 | CM0046 | CM0048 | CM0050 | CM0070 | CM0074 | CM0075 | CM0083 |
| MI-SOFT-01 | Software Mission Assurance Function | The mission should perform software assurance via established procedures and technical methods. | The intent of this control is to ensure the provider follows a formal software development process when creating safety-critical software, including all MOTS, GOTS, COTS, open-source, library acquired, and reused software. Software assurance methods must extend into the development environment as well. In order to secure the development environment, the first step is understanding all the devices and people who interact with it. Maintain an accurate inventory of all people and assets that touch the development environment. Ensure strong multi- factor authentication is used across the development environment, especially for code repositories, as cyber actors may attempt to sneak malicious code into software that's being built without being detected. Use zero-trust access controls to the code repositories where possible. For example, ensure the main branches in repositories are protected from injecting malicious code. A secure development environment requires change management, privilege management, auditing, and in-depth monitoring across the environment. The objectives of the software assurance and software safety activities include the following:
|
CM0004 | CM0007 | CM0008 | CM0010 | CM0011 | CM0012 | CM0013 | CM0015 | CM0016 | CM0017 | CM0018 | CM0019 | CM0020 | CM0021 | CM0023 | CM0025 | CM0046 | CM0047 |
| MI-SOFT-02 | Software and Hardware Testing Function | The mission should establish procedures and technical methods to perform end to end testing to include negative testing (i.e., abuse cases) of the mission hardware and software as it would be in an operating state (test as you fly). | Negative testing and analysis are necessary to validate that the system architecture and security-focused design features provide adequate resilience against a range of potential attacks. Where faulted testing is standard practice in the mission lifecycle, security cases should be added to the set of potential anomalous scenarios to test. Operational anomaly response training should include security events and exercise operational interfaces to institutional security organizations. | CM0008 | CM0011 | CM0018 | CM0019 | CM0020 | CM0022 | CM0024 | CM0025 | CM0026 | CM0046 |
| MI-MALW-01 | Mission Malware Protection Function | The mission system software updates should be validated as free from malware prior to deployment, launch, and at defined regular intervals while the mission is in operations. | On-orbit software updates/upgrades/patches and all software updates should be checked for malware prior to load. Additionally, malware injected into space vehicle software modules via supply chain attack may not be discovered until well into flight and may be activated as a step in compromising a vehicle. Modules that have not been updated during flight may therefore still pose a risk. Regular scans on stored copies of flight modules using updated signatures may discover malware that has been in hiding, and regular monitoring of malware and vulnerability reports will also prompt response. Integrity of software should be verified by employing a cryptographically secure hashing algorithm to determine the hash (digest value) of the system (or software update package) being evaluated. Additionally, the authenticity of the "control" or "reference" hash value, to which the system's hash is being compared, should also be signed using the private key of a cryptographic digital signature to ensure that the control value was supplied by a legitimate, trusted entity. The reason for this extra measure is that, in its absence, an attacker could modify the system being checked for integrity and also make a corresponding modification to the control hash value so that the subsequent integrity check still passes. This control aims to ensure that only legitimate entities can supply control hash values for software and update packages. | CM0004 | CM0007 | CM0010 | CM0011 | CM0012 | CM0013 | CM0014 | CM0015 | CM0017 | CM0018 | CM0019 | CM0021 | CM0023 | CM0025 | CM0032 | CM0047 | CM0052 | CM0054 |
| MI-MALW-02 | Mission Software, Programmable Logic Devices, and Firmware Integrity Function | The mission should establish and verify the integrity of its software images. | On-orbit software updates/upgrades/patches. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code or direct writes to memory. New or modified virus or malware will not be identified without updated manufacturer definitions. Blocks, removes, or recommends patches of commonly known virus or malware used to disrupt computer operations, gather sensitive information, or gain access to private computer systems. Virus and malware includes: computer worms, trojan horses, ransomware, spyware, etc. | CM0010 | CM0012 | CM0014 | CM0015 | CM0021 | CM0023 | CM0024 | CM0025 | CM0026 | CM0027 | CM0028 | CM0032 | CM0044 |
| MI-DCO-01 | Mission Adversarial Actions Detection Function | The mission should incorporate an on-board cyber actor actions detection function in its requirements and resulting system. | The mission should plan for the possibility of an on-board disruption deriving from a security incident and incorporate these considerations. Event detection, mitigations, and alerting of ground segment security operations team are critical controls to provide the capability for operational teams to know when other controls have failed, rapidly respond (where possible). The resulting lessons learned should be fed back into the design process. Monitoring of key software observables (e.g., number of failed login attempts, unscheduled lockups of the flight receiver, indications of RFI on non-telecom equipment, performance changes, internal communication changes) is needed to detect cyber actor actions that interdict mission success. Cybersecurity attacks affecting components of in-flight systems are expected. A cybersecurity incident response plan is key to the timely and effective response to a cybersecurity attack. All suspected cyber actor actions should be reported. Raw event data should be further analyzed to determine whether an anomalous event represents an attack, and if so, the nature of the attack, and the appropriate response to mitigate impact to the mission. Ensure the mission is following NPR 7150.2 guidance for software to detect cyber actor actions, such as those in 3.11.8. | CM0032 | CM0034 | CM0042 | CM0044 | CM0048 | CM0066 | CM0068 | CM0069 | CM0090 |
| MI-DCO-02 | Mission Fault Management | The mission should incorporate fault management bypass protection in its requirements and resulting system. | The mission should consider the possibility of fault management transitions to bypass the system's protection measures and incorporate these considerations. Fault management systems may be deliberately triggered in an effort to bypass the system's protective measures. For example, safehold mode operations without command-link protection. | CM0001 | CM0002 | CM0006 | CM0020 | CM0022 | CM0029 | CM0032 | CM0034 | CM0042 | CM0043 | CM0044 | CM0045 | CM0068 | CM0070 |
| MI-MA-01 | Mission Recovery Function | The mission should include intentional disruptions consistent with the mission vulnerability analysis in anomaly detection, response, and recovery plans and designs in the flight segment and ground segment. | A complete defense-in-depth architecture includes the ability of the space vehicle to maintain safe operation through a security incident affecting flight or ground systems, and to recover to a nominal state once the incident is resolved. Security incidents should be considered alongside equipment failures, environmental events, natural disasters, and other sources of disruption in onboard fault handling, anomaly response, and continuity-of-operations planning to ensure mission resilience. | CM0022 | CM0032 | CM0042 | CM0044 | CM0056 | CM0070 | CM0077 | CM0079 |
| MI-MA-02 | Cyber-Safe State Function | The mission should design secure vehicle fault management functions and safe mode operations. | Fault management systems are one of the targets a cyber actor will attempt to compromise. Designing security into these systems at the earliest opportunity is paramount. Security should also be considered as a potential root cause of system malfunction that is captured by the fault management system, and fault responses should be designed to mitigate security events alongside other causes of system failure. | CM0001 | CM0002 | CM0006 | CM0022 | CM0032 | CM0042 | CM0044 | CM0068 |