1. Requirements

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

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

“Current trends in 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 increase the likelihood that vulnerable U.S. space systems may come under attack, particularly vulnerable systems...The reality is that there are many existing capabilities to deny, disrupt, or physically destroy orbiting spacecraft and the ground facilities that command and control them... Nations or groups hostile to the United States either possess or can acquire the means to disrupt or destroy U.S. space systems by attacking satellites in space, their communications nodes on the ground and in space, the ground nodes that command these satellites or process their data, and/or the commercial infrastructure that supports a space system’s operations.”  ²⁷³

3. Guidance

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. Ensure that all software-related space communications capabilities are evaluated for software security vulnerabilities.

“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.” ²⁷³

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 access controls following the requirements of the system’s security categorization and with the protection measures specified in the project protection plan are in place for software systems with space communications capabilities.  Even when there is no project protection plan, access control measures are put in place to protect these systems and the assets they control.

Access control measures may include any combination of the following (list not all-inclusive):

• Restricted room access (e.g., keypad or badge swipe controls).
• Restricted console access (e.g., badge, biometric, password, or other controls).
• Procedural physical access (e.g., security policies and procedures).
• Laptop security.
• Controlled network access (e.g., dedicated networks, secure networks).
• Personnel background checks.

Sources of information to help identify and implement access control measures include:

• System security plan (typically part of the project’s documentation suite; this plan drives development (and later operations) along with the documents that incorporate the security concept of operations, design, requirements, testing plan, etc.).
• Security requirements trace matrix (if not part of the project’s bi-directional requirements trace matrix).
• Security requirements document (maybe part of the project’s software requirements document).
• Security design document (maybe part of the project’s software design documentation).

It is necessary to address all use cases when establishing access controls.  Consider all combinations of roles and assets accessible (or not) to those roles to be sure that all system access points have been addressed. 

Additional guidance related to software security may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects. 

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

1. For software products with communications capabilities, confirm that the software requirements and software design documentation addresses unauthorized access.

7.2 Software Assurance Products

• None at this time
  

  
  

  Objective Evidence

  • The software requirements and software design documentation address unauthorized access per the requirements contained in the Space System Protection Standard, NASA-STD-1006.
  • NASA-STD-1006 is applied as a requirement on the project.
   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.

7.4 Guidance

Additional items to consider:

1. Confirm that the software implementation requirements include protections for software systems with communications capabilities against unauthorized access. Assess the project's communication capabilities against the requirements in the NASA-STD-1006 ⁶⁶³ Space Systems Protection Requirements.

2. Confirm that the software whitelists only 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. 

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