NASA’s Space Security: Best Practices Guide (BPG)

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 spacecraft. The boundary protection may be logical or physical. Functionality provides the following benefits:
  • Blocks unintended (incoming/outgoing) traffic
  • Enables generation and maintenance of Security Logs
  • Prevents devices from polling other network devices
  • Prevents devices from polling the network for other devices
  • Prevents bridging of networks
Effective boundary protection should/would include confidentiality protection using encryption (as defined by NASA STD 1006) in addition to some form of authentication (e.g., Galois/Counter Mode GCM). This boundary protection also needs to include protection on the spacecraft side where it protects itself from the ground being used as an attack vector. The inherent trust between the ground and spacecraft needs addressed where the spacecraft can protect itself from the ground in the event the ground has been compromised. Each mission should identify/define their most critical subsystems. Critical subsystems or control interfaces should have mediated access between mission critical control interfaces, that could create mission ending failure/consequence through either physical or software means.
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.
  • Cyber actors can masquerade as an authorized entity in order to gain access.
  • Unique identifiers and associated authenticators (passwords, multi-factor physical and virtual, securely registered biometrics) and associated processes to verify entities at time of issuance and authenticate entities at time of access request allow the mission to provide a risk-aligned level of assurance that only vetted entities are allowed to access mission digital resources.
  • Non-mission users authorized to access mission computing resources as a specific subset of all personnel pose a potential additional risk compared to mission users due to limited ability to fully vet and verify their suitability. Therefore, the mission should perform a risk assessment to determine the authorization needs of non-mission users that need to access the system (e.g., public users supporting commercial organizations); what information they would need to access; and its restrictions (OPSEC, Privacy Act, ITAR, etc.). The risk assessment should incorporate supply chain considerations related to foreign national access to Agency or other potentially sensitive information.
  • The existence of insecure static authenticators for access to applications and control systems, such as hardcoded plaintext passwords or access tokens, can be discovered by cyber actors, brute forced, and reused across multiple similar systems creating an opportunity for rapid widespread compromise within the mission ground segment. Therefore, the mission should define policy and procedures to ensure that the developed or delivered systems do not embed unencrypted static authenticators in applications, access scripts, configuration files, or store unencrypted static authenticators on function keys. With associated decryptors on the space mission system.
  • Ensuring only devices known to and registered with the appropriate mission device inventory and management platforms are allowed to access mission communications networks significantly reduces the increased risk due to unknown devices operating within mission environments. Therefore, the mission should provide the capability to uniquely identify and authenticate all types of computing devices, including mobile devices and network connected endpoint devices (including workstations, printers, servers, VoIP Phones, VTC CODECs) before establishing a network connection. In addition, the mission should, in consultation with the system security engineers and the AO, select the appropriate device identification and authentication mechanisms based on mission needs and the strength of mechanism required in support of that mission. Ensuring on the space mission system the right system has sent the right command at the right time.
  • The mission should establish policy and procedures to prevent individuals (i.e., insiders) from masquerading as individuals with valid access to areas where commanding/updating of the spacecraft is possible. mission must ensure a comprehensive authentication and authorization function (i.e., COMSEC and strong authentication) is available to prevent attacker from performing potential mission ending actions like flight software upgrades, burning read-only memory, changing fault responses, uploading stored command sequences, or executing mission defined critical commands. The equipment and protocols being used should include stronger encryption, authentication, and key management procedures to reduce risk of confidentiality and integrity violations and impacting the mission.
  • While the rationale for this control appears to be more ground centric, while the space mission system is in development mission personnel will be requiring access outlined in the control.
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 spacecrafts 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:
  • Ensuring that the processes, procedures, and products used to produce and sustain the software conform to all specified requirements and standards that govern those processes, procedures, and products
    • A set of activities that assess adherence to, and the adequacy of the software processes used to develop and modify software products
    • A set of activities that define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes
  • Determining the degree of software quality obtained by the software products
  • Ensuring that the software systems are safe and that the software safety-critical requirements are followed
  • Ensuring that the software systems are secure
  • Employing rigorous analysis and testing methodologies to identify objective evidence and conclusions to provide an independent assessment of critical products and processes throughout the lifecycle
The software development process should include software requirements definition, design, implementation, verification, maintenance, and retirement phases, and incorporate software quality assurance, configuration management, problem reporting and corrective action, reliability, maintainability, safety, verification and validation, certification, and operational use of the software. Additionally, software reuse, commercial off the shelf dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to a potential supply chain vulnerability that must be mitigated appropriately. See NPR 7150.2D, NASA Software Engineering Requirements and NASA-STD-8739.8B, Software Assurance and Software Safety Standard. Lastly, the mission should perform software assurance via established procedures and technical methods, including checking against NASA's Assessed and Cleared List.
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 spacecraft 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 spacecraft 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