This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-157 - Protect Against Unauthorized Access

1. Requirements

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

1.1 Notes

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

1.2 Applicability Across Classes























Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

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.”  273

3. Guidance

When ensuring that software systems with space communications capabilities are protected against un-authorized 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 un-authorized 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 survivability of the mission.” 273

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 in accordance with 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., key pad 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 (may be part of the project’s software requirements document).
  • Security design document (may be 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. 

NASA users should consult center Process Asset Libraries (PALs) for center-specific guidance and resources related to software security.

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 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.


6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.

  • No labels