bannerd


SWE-157 - Protect Against Unauthorized Access

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

SWE-157 - Last used in rev NPR 7150.2D

RevSWE Statement
A


Difference between A and B

NEW

B

3.16.5 The project manager shall ensure that software systems with space communications capabilities are protected against un-authorized access.

Difference between B and CChanged "ensure" to "implement protections"; 
Expanded scope of requirement from "space communications" to  "communications" in general.
C

3.11.4 The project manager shall implement protections for software systems with communications capabilities against unauthorized access. 

Difference between C and DAdded reference to NASA-STD-1006.
D

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.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable


2. Rationale

Threats to United States Space Capabilities

Current trends such as technology proliferation, accessibility to space, globalization of space programs and industries, commercialization of space systems and services, and foreign knowledge about U.S. space systems increases the likelihood that the U.S. will experience a "Space Pearl Harbor." For example, in July 2000, the Xinhua news agency reported that China's military is developing methods and strategies for defeating the U.S. military in a high-tech and space-based future war. It noted, "For countries that could never win a war by using the method of tanks and planes, attacking the U.S. space system may be an irresistible and most tempting choice..."(2) These reports illustrate an unpleasant but little noticed view of the future.

The ability to restrict or deny freedom of access to and operations in space is no longer limited to global military powers. The reality is that there are many extant capabilities to deny, disrupt or physically destroy space systems and the ground facilities that command and control them. Knowledge of U.S. space systems functions, locations and physical characteristics, as well as the means to conduct counterspace operations, is increasingly available on the international market. Nations or groups hostile to the U.S. possess or can acquire the means to disrupt or destroy U.S. space systems by attacking the satellites in space, their communications nodes on the ground and in space, or ground nodes that command the satellites.

473

  

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 362.
  3. Comply with the requirements in the Space System Protection Standard, NASA-STD-1006. 663
  4. Ensure that all software-related space communications capabilities are evaluated for software security vulnerabilities.

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,

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 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 will always have a role in encryption. It’s the level where it is implemented that comes into question. It could be at the enterprise-, system-, or application level. 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 663 contains mission-specific tailoring suggestions.

 

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

Scenario

SW Requirements Considerations

Scenario 1: Class B Earth Science Mission has a space element and communicates with one ground station that commands the spacecraft. The space element has a spacecraft that provides telemetry and instrument data to the ground station. The space element contains one instrument but communication to the instrument is via the spacecraft. The ground station communicates with a remote Operations Center and 3 data processing centers. There is no redundancy in the links.

·     The Operations Center to Ground Station communication path is encrypted with appropriate software support

·     The Ground Station communication path to the spacecraft is encrypted with appropriate software support

·     Critical Program/Project Information (CPI) is protected as NASA CUI information


Scenario 2: Same as Scenario 1, but there are two ground stations with one being primary and the other being backup. The backup ground station provides backup commanding to the spacecraft from the Operations Center and backup data to the 3 data processing centers.

Same requirements supporting scenario 1, plus

·   The backup Operations Center to Ground Station communication path is authenticated with appropriate software support

·     The backup Ground Station communication path to the spacecraft is authenticated with appropriate software support


  • Ensure Positioning, Navigation, and Timing (PNT) Resilience. This objective addresses PNT services that use external services, e.g. GPS. Specifically, the requirement specifies resiliency to lose 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, 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. Where the external services exist, software requirements specifying resiliency through loss or interruption of service exist for each service.

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

Scenario

SW Requirements Considerations

Scenario 3: Class B Earth Science Mission has a timing system that uses GPS. The pointing and navigation systems use sensors located on the space vehicle.

·     The flight software detects valid GPS signals and reports invalid inputs.

·     The space vehicle goes into safehold mode when the GPS signal has an invalid range (note that the safehold mode relies on the sun sensor for algorithms and an internal timer that uses the last known valid input)

·     Alternatively, there could be requirements that address algorithm robustness to operate through temporary interference of the GPS signal and still meet mission level positioning/nav/timing requirements.


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

Scenario

SW Requirements Considerations

Scenario 4: Mission hazard analysis has established that unexplained interference can be caused by Command Link or GPS degradation or disruption manifested by invalid inputs.

·     The software detects valid GPS signals and reports invalid inputs.

·     The software detects valid Command Link data and reports invalid inputs.

·     The software reports invalid GPS or Command Link data to the operators.


The resulting artifacts include software requirements with traceability to the system requirements and ultimately to the NASA-STD-1006 663 Space System Protection Standard. The analysis is captured in engineering notebooks.

3.2.2 Design Phase

Design Phase: During the design phase, the software requirements that contain appropriate allocations from the NASA-STD-1006 663 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 and SSPR 3. 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 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.

Scenario

Software Design Considerations

Scenario 4: All missions

·     Evaluate for defense in depth strategy, applying a reasonable and secure level of encryption, authentication, or other layers of protection across the mission.

·     Command link contingency
modes need protection from malicious actors, potentially as part of the hazard analysis.

Scenario 5: Crewed mission

Same design considerations supporting Scenario 4, plus

·     Intra-vehicle and intra-suit communications are evaluated and protected

Scenario 6: Consultative Committee for Space Data Systems (CCSDS) protocol used on one of the links

Same design considerations supporting Scenario 4, plus

·     Evaluate carefully, CCSDS may be insufficient to meet this requirement


  • 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 denial of PNT can be evaluated for denial of services and appropriate mitigations designed. They 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.

Scenario

Software Design Considerations

Scenario 7: Navigation filtering algorithms using a diversity of measurement sources, including external sensors

·     Use the following best practices to aid in design: NASA/TP-2018-219822, Navigation Filter Best Practices 359,
describes NASA Engineering and Safety Center (NESC) Best Practices for navigation filter design

·     The design includes checks for resiliency to invalid parameter inputs

Scenario 8: Project has a minimum Level 1 requirement to continue to perform the mission while operating in the face of a compromised primary PNT source.

·     Projects should have a plan for emergency backup independent PNT sources that is appropriate to the mission’s risk tolerance and cost-benefit posture. Backup implementations involving either the mission’s space segment or ground segment are possible.

·     Projects should consider modeling PNT pre-flight performance to demonstrate the spacecraft does not enter an unacceptable mode when PNT inputs change or are interrupted.


  • 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, 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.

Scenario

Software Design Considerations

Scenario 9: Mission hazard analysis has established that unexplained interference can be caused by Command Link or GPS degradation or disruption and is manifested by invalid inputs.

·     The hazard control should include detection and reporting

·     The control may be implemented in either the space segment or the ground segment

·     Safety design and implementation is a partnership between software engineering, safety analysts, and software assurance


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 software associated with SWE-157 will meet the guidance provided in NPR 7150.2, Section 4.3 Software Implementation, based on SWE-060 – Coding Software, and SWE-062 – Unit Test. Other SWE requirements in Section 4.3 impact the implementation, including SWE-061 – Coding Standards, SWE-135 – Static Analysis, SWE-186 – Unit Test Repeatability, and SWE-063 Release Version Description, SWE-185 - Secure Coding Standards Verification

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. The analysis is captured in engineering notebooks.

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

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki  197

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

SPAN Links

4. Small Projects

No additional guidance is available for small projects. 

5. Resources

5.1 References

5.2 Tools


Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). 

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. 

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool.  The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

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

SWE-157 - Protect Against Unauthorized Access
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.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. For software products with communications capabilities, confirm that the software requirements, software design documentation, and software implementation address unauthorized access per the requirements contained in the Space System Protection Standard, NASA-STD-1006.

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 and correct, and includes stress testing as appropriate.
  • Records of any non-conformance


    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.

Life Cycle Phase

Candidate Confirmation Process

SA Records

Requirements

1.   Gain an understanding of Space System Protection Standard and allocation to mission and software

2.   Obtain Software Engineering artifacts for the associated life cycle phase

3.   Review artifacts

4.   Confirm results

5.   Document results

6.   Track findings and risks to closure

Records associated with each development phase (see 7.2 for specific products)


Non-conformances and associated metrics (see 7.3)

Design

Implementation (Code)


Additional items to consider:

  1. Confirm that the software whitelists 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:

  • No labels