1. Requirements

3.11.4 The project manager shall implement protections for software systems with communications capabilities against unauthorized access per the requirements contained in the NASA-STD-1006, Space System Protection Standard.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

3. Guidance

3.1 Vulnerable Space Systems

Current trends in technology proliferation, accessibility to space, globalization of space programs and industries, commercialization of space systems and services, and foreign knowledge about space systems increase the likelihood that vulnerable space systems may come under attack, particularly vulnerable systems.

When ensuring that software systems with space communications capabilities are protected against unauthorized access, space flight software development organizations perform three primary functions;

1. Use the Project Protection Plan to determine how the mission software-related space communications capabilities should be protected against unauthorized access.
2. Implement the access controls associated with space flight software-related communications capabilities as identified in the Project Protection Plan ³⁶².
3. Note, the compliance of NASA-STD-1006  ⁶⁶³ needs to be in alignment with the Project Protection Plan implementation.  
4. Ensure that all software-related space communications capabilities are evaluated for software security vulnerabilities.
5. Apply security practices to ground assets that will interface with the space system for communications. 

During the development cycle, as early as possible in the requirements and design life cycle phases, the space flight software development team works with IT personnel and other software security experts, including the Information System Security Officer (ISSO), to ensure that communication controls follow requirements in the Space System Protection Standard, NASA-STD-1006, additional guidance can be found in Topic 7.22 - Space Security: Best Practices Guide.  

See also SWE-156 - Evaluate Systems for Security Risks, SWE-154 - Identify Security Risks, SWE-159 - Verify and Validate Risk Mitigations, 

3.2 Compliance With The Requirements In The "Space System Protection Standard"

SWE-157 designates compliance with the requirements in the Space System Protection Standard, NASA-STD-1006. This standard establishes Agency-level protection requirements to protect NASA missions with space communication capabilities, and ensure resiliency to purposeful threats. The Standard applies to all programs and projects and the standard allows for tailoring for applicability given program and project specifics.

NASA-STD-1006 contains six (6) verifiable requirement statements that are numbered from [SSPR 1] through [SSRP 6], with a Requirements Compliance Matrix provided in Appendix A. Per the 1006 Standard, programs and projects should document the applicability of the requirements in their Project Protection Plan, which then flow to system and software requirements. Note that the guidance defined Project Protection Plans as follows: “Project Protection Plans are single-source documents that coordinate and integrate protection efforts and prevent inadvertent or uncontrolled disclosure of sensitive program information. Protection plans provide project management personnel (project manager, project scientist, mission systems engineer, operations manager, user community, etc.) with an overall view of the valid threats to a space system (both hostile and environmental), identify infrastructure vulnerabilities, and propose security countermeasures to mitigate risks and enhance the survivability of the mission.” 

Within NASA-STD-1006, protections for purposeful threats are organized into four objectives, which address unauthorized access. Each objective contains one or more requirements. Each requirement includes rationale and may include tailoring notes or guidance. Generally, the tailoring notes are targeted towards requirements and guidance supports design. The four objectives, per the Standard, are listed below:

• Maintain Command Authority. Missions need to maintain command authority to prevent unauthorized access and to ensure data integrity. Unauthorized access could result in mission loss and/or damage to other space systems. This objective is capture in 3 requirements: [SSPR 1] [SSPR 2] [SSPR 3]
• Ensure Positioning, Navigation, and Timing (PNT) Resilience. Missions dependent on external PNT services need to be able to recognize and survive interference to ensure PNT resilience. Extended loss of PNT services could result in mission degradation or loss if no mitigations are available. This objective is captured in 1 requirement: [SSPR 4]
• Report Unexplained Interference. Missions need to detect and report instances of unexplained interference to enable Agency awareness of the contested space environment and to develop appropriate mitigations. Lack of Agency awareness of unexplained interference events could deprive NASA of indications and warning of adversary actions and increase the vulnerability of NASA systems. This objective is captured in 2 requirements: [SSPR 5] [SSPR 6]

3.2.1 Requirements Phase

Requirements Phase: During requirements development, the six requirements [SSPR 1 through SSPR 6] are appropriately applied to the requirements. NASA-STD-1006 must be used as a resource throughout the development of the SW requirements. Before the development of software requirements, the mission system determines the applicability of the Space System Protection Standard and documents them in the System Requirements/Project Protection Plan. The software requirements associated with SWE-157 will meet the guidance provided in SWE-050 - Software Requirements, SWE-051 - Software Requirements Analysis, and SWE-184 - Software-related Constraints and Assumptions. It is necessary to address all use cases when establishing security controls.  Consider all combinations of roles and assets accessible (or not) to those roles as part of the analysis for software requirements derivation. NASA users should consult center Process Asset Libraries (PALs) for center-specific guidance and NASA Engineering Network (NEN) Software Security COP site for resources related to software security. Considerations for developing software requirements for each objective are provided below.

• Maintain command authority. The three requirements address protecting the command links using encryption and/or authentication, as well as protecting the confidentiality of the command link information. The software has a role in encryption and/or authentication, as well as additional confidentiality protections. The software may have a role in encryption unless it is done in hardware. It depends on ’s the level where the encryption is implemented (at the enterprise-, system-, or application) . It may be useful to build a context diagram paired with data flows to show interactions between the system and external actors that can provide commands. Within the system, understanding the role of software to perform appropriate command behaviors leads to good requirements. Note that within [SSPR 1], NASA-STD-1006 ⁶⁶³ contains mission-specific tailoring suggestions.

Two high-level and abstracted examples of requirements within the Maintain Command Authority objective are shown below.

• Ensure Positioning, Navigation, and Timing (PNT) Resilience. This objective addresses PNT services that use external services, e.g. Global Positioning System (GPS). Specifically, the requirement specifies resiliency due to loses of, or interference with, external PNT services. PNT is generally implemented in software, e.g.: Guidance Navigation and Control (GN&C); and/or Attitude Control System (ACS); and/or Time Generation. Generally, this software includes external interfaces like GPS or other sensors. The external interfaces are included in the requirements either at the system level or via the Interface Requirements Document. To meet the objectives of [SSPR 4] and PNT resiliency, software requirements should exist that specify resiliency, or operation through loss or interruption of services. This can be done by examining Positioning, Navigation, or Timing implementation in the system and architecture to identify external services. 

 A high-level and abstracted example of requirements within the Ensure PNT Resilience objective is shown below.

• Report Unexplained Interference. The two requirements included with this objective address reporting unexplained interference and operator proficiency training. The software has a role in the first [SSPR 5] to identify and log unexplained interference behaviors. Requirements addressing unexplained interference can be identified through safety analysis as a hazard cause for safety-critical software (see SWE-023) as documented in NASA-STD-8739.8. For non-safety-critical software, identifying and reporting unexplained interference is part of the fault detection, identification, and response. Note also that SWE-210 addresses the collection, reporting, and storage of data relating to the detection of adversarial actions. SSPR 5 is a specific case of SWE-210 - Detection of Adversarial Actions. [SSPR 6] is the final requirement and refers to the training of operators. Flight or ground software usually does not have any contributions to [SSPR 6].

A high-level and abstracted example of requirements within the Report Unexplained Interference objective is shown below.

The resulting artifacts include software requirements with traceability to the system requirements and ultimately to the NASA-STD-1006 ⁶⁶³ Space System Protection Standard. The analysis of the unexplained interference is captured in engineering notebooks or logs.

3.2.2 Design Phase

Design Phase: During the design phase, the software requirements that contain appropriate allocations from the NASA-STD-1006 ⁶⁶³ Space System Protection Standard are implemented in the software architecture and software design. The software design associated with SWE-157 will meet the guidance provided in NPR 7150.2, Section 4.2 Software Architecture (SWE-057 - Software Architecture) and 4.3 Software Design (SWE-058 - Detailed Design). Considerations for developing the software design for each objective are provided below. Design examples are expanded from the Space System Protection Standard guidance. As designs to meet SWE-157 develop and mature, guidance can be elaborated to capture best practices.

• Maintain command authority. Within the Space System Protection Standard, guidance is provided for SSPR 1 (Command Stack Protection) and SSPR 3 (Command Link Critical Program/Project Information (CPI). The guidance for SSPR 1 provides ideas for how to implement the requirement to protect the command stack with encryption. This guidance addresses defense-in-depth strategies, command path analysis including crewed missions and CCSDS, and the command generation process integrity. This guidance also applies to SSPR 2 (Backup Command Link Protection) where authentication, as a minimum, is required for backup command links. SSPR 3 is to protect the confidentiality of command link critical program/project information (CPI) and contains guidance to implement. This guidance identifies protection including encryption, authentication, and specific CPI protection. The Mission Resilience and Protection Program (MRPP) is referenced to help identify CPI.

Three high-level and abstracted examples of design within the Maintain Command Authority objective are shown below.

• Ensure Positioning, Navigation, and Timing (PNT) Resilience. The design of a resilient PNT system and algorithms begins with an understanding of external interfaces to the PNT, including sensors, actuators, and other external systems. Software is frequently used to implement the algorithms. The algorithms include protections against loss or interference of external PNT services. The associated guidance in NASA-STD-1006 offers five areas where PNT can be evaluated for denial of services and appropriate mitigations designed. These five areas address filtering algorithms, address invalid parameter inputs, use backup independent PNT sources, and reference best practices for Navigation Filters and GPS usage.

Two high-level and abstracted examples of design within the Ensure PNT Resilience objective are shown below.

• Report Unexplained Interference. Identification of causes of unexplained interference occurs during requirements analysis either through the hazard analysis or fault protection analysis. The software design to implement detection and reporting of unexplained interference would follow the safety and fault protection strategies to detect and report the unexplained interference. Note that though there is guidance associated with SSRP 5 (Interference Reporting), the guidance is at the system level. Nonetheless, the guidance should be reviewed as part of the software design process.

A high-level and abstracted example of design within the Report Unexplained Interference objective is shown below.

The resulting design artifacts include the software architecture and software design used to implement the software requirements associated with and allocated from the Space System Protection Standard. The analysis is captured in engineering notebooks.

3.2.3 Implementation Phase

Implementation (Code) Phase: During the implementation phase, the software requirements and design that contain appropriate allocations from the NASA-STD-1006 Space System Protection Standard are implemented in the code itself. 

The resulting implementation artifacts include the software code and version description documents, bi-directional traces from software requirements and design to the code, and unit test results. 

See also 8.04 - Additional Requirements Considerations for Use with Safety-Critical Software, Topic 8.56 - Source Code Quality Analysis

3.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.4 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

The smaller projects should scale the effort to the risk posture of the project and tailor accordingly.  Examples can be utilizing known resources from SCaN for link layer encryption and reusing software frameworks that help satisfy this SWE. 

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

• Objective evidence of the following:
• Confirmation that requirements from NASA-STD-1006 have been evaluated for the mission and allocated. If deviations are identified, that appropriate approval has been obtained.
• Confirmation that NASA-STD-1006 has been appropriately allocated to the mission requirements, Project Protection Plan, System Requirements, and Software Requirements
• Confirmation that Software Requirements associated with NASA-STD-1006 are complete, correct, and verifiable; and that a bi-directional trace is provided with the system requirements
• Confirmation that Design associated with NASA-STD-1006 requirements is complete, correct, and detects and responds appropriately to adverse conditions; and that a bi-directional trace is provided with the software requirements
• Confirmation that the Code associated with NASA-STD-1006 is complete, correct, and detects and responds appropriately to adverse conditions; and that a bi-directional trace is provided with the software requirements and software design
• Confirmation that Unit Testing associated with NASA-STD-1006 requirements is complete, correct, and includes stress testing as appropriate.
• Records of any non-conformance
  

  
  

   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

• # of software work product Non-Conformances identified by life cycle phase over time.

See also Topic 8.18 - SA Suggested Metrics.

7.4 Guidance

In performing the confirmation that the Space System Protection Standard is correctly specified and implemented, the SA practitioner follows the work throughout the software engineering development life cycle, with actual records established at the end of each of the requirements, design, and code phases. The confirmation process follows the software engineering development processes, is documented in the software engineering plans, and is consistent with the guidance above.

A process to confirm unauthorized access is described below.

Additional items to consider:

1. Confirm that the software allow-lists only contain known addresses and devices and default-deny other communication capability attempts. Default deny unknown devices, addresses (IP TCP/UDP, etc.), and other unknown or unused interface protocol types that are not used by the project or program. A layer of boundary protection regarding the software and its interface should be considered as a protection mechanism against unauthorized access to the software system. 
2. Evaluate the need to analyze software communication using a network analyzer/mapper/scanner, or protocol bus analyzer while the code is running (dynamic code analysis) to determine which protocols, addresses, other software, and devices the software is interfacing with. Provide results to software engineering and suggest changes in open ports, protocols, or services. This will identify potential open access points to the software and certain protocols might be able to be blocked depending upon the application or interface type used with the software. However, this type of analysis may be required at the system level depending on the type of software built.

See also Topic 8.55 - Software Design Analysis, 

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: