For flight software, the project manager assists the program manager provide program and project information needed by the Agency team and the Information System Security Officer (ISSO) performing a threat assessment and/or threat summary to ensure that software defects with security ramifications are included in the assessment/summary and mitigations are captured in the Project Protection Plan. Per the Frequently Asked Questions (FAQ) section of the Community of Practice for Space Asset Protection accessible to NASA users from the NASA Engineering Network (NEN), “Threat summaries and protection plans are drafted as early in formulation as possible to minimize the impact of any protection related design requirements.” The project manager reviews the Project Protection Plan to ensure that mitigations for software defects with security ramifications are included in the Project Protection Plan created per NPR 7120.5 .
Note that security requirements “for the acquisition, development, integration, and modification of ground software systems are found in NPR 2810.1.” (NPR 7150.2B ) Sources of potential software security risks include the output of a FIPS-199 assessment for the program, the system security plan, and the program’s risk assessment report available from the ISSO. For NASA users, the Secure Coding Portal accessible to NASA users via the NEN is another source. Documents from the Consultative Committee for Space Data Systems (CCSDS) include potential security threats and may also be useful sources. CCSDS documents regarding security threats against space missions note that software threats applicable to space and ground segments include mistakes made by “users, system operators, and programmers [that] could result in loss of data, loss of spacecraft control, unauthorized spacecraft control, or loss of mission” :
- “Users or administrators can install unauthorized or un-vetted software, which might contain bugs, viruses, spyware, or which might simply result in system instability.”
- “System operators might configure a system incorrectly resulting in security weaknesses.”
- “Programmers may introduce logic or implementation errors which could result in system vulnerabilities or instability.”
- “External threat agents might attempt to exploit a vulnerability to inject software or configuration changes.”
This requirement is to be implemented as early as possible in the project life cycle so that mitigations can be built in or established up front. Per the schedule in Appendix I of NPR 7120.5 , a preliminary version of the Project Protection Plan is due at System Definition Review (SDR)/Mission Definition Review (MDR), a baseline is due at Preliminary Design Review (PDR), and appropriate updates are due at Critical Design Review (CDR), System Integration Review (SIR), Operational Readiness Review (ORR), and Mission Readiness Review (MRR)/Flight Readiness Review (FRR). Annual updates to the Project Protection Plan are expected once the system is in operation to accommodate changes in the threat environment.
Per NPR 7150.2B, “Software defects with security ramifications include implementation bugs such as buffer overflows and design flaws such as inconsistent error handling.” Security-related defects fall into several categories such as memory safety (e.g., dangling pointers), race conditions, secure input and output handling (e.g., validating an input message length), improper exception handling, etc. Compromises to user authentication, access rights and privileges, data confidentiality, and data integrity also contribute to software systems that are not secure. When identifying security risks in software, be sure to account for all types of information and assets in the system that require protection as well as all the ways the identified information and assets can be accessed.
Project Protection Plans are classified documents (Secret). Per the FAQ section of the Community of Practice for Space Asset Protection accessible to NASA users from the NEN, “NASA has developed a process to incrementally lower classification levels of relevant threat information to Secret and worked with project management teams to obtain clearances for their personnel at that level. Program/Project managers can also be read in at the Secret level for short time periods to review Project Protection Plans.”
Per the FAQ section of the Community of Practice for Space Asset Protection accessible to NASA users from the NEN, “Project Protection Plans (PPPs) ...have three purposes, which are described as follows:
(1) Project Protection Plans document the survivability strategy(s) used by a project, identify the valid threats and corresponding vulnerabilities to a mission and recommend potential countermeasures to ensure the protection of the infrastructure elements that support civil space system.
(2) Protection plans provide project management personnel (project managers, project scientists, mission systems engineers, operations managers and the user community, etc.) with an overall view of the valid threats to their project (both hostile and environmental), identifies infrastructure vulnerabilities and proposes security countermeasures to mitigate risks and enhance survivability of a civil space system.
(3) PPPs are the medium through which the civil space organizations will provide technical information on our space systems to the [Department of Defense (DoD)], Department of State, Department of Homeland Security and the Intelligence Community to assist them in providing timely support to NASA in the event of an incident involving one of our missions. For example, protection plans include the following types of information:
a. [Tracking, Telemetry and Command] TT&C or uplink frequency.
b. Other NASA space systems using the TT&C or uplink frequency.
c. RF antenna gain values.
d. Nominal telemetry downlink cycles.
e. Ground network and space network assets normally used for TT&C with the affected spacecraft.
The first step in developing a PPP is to extract the viable threats (which are commonly referred to as protection threats) from a civil space system's threat summary and categorize them according to the NASA Risk Matrix Standard Scale. Protection threats are defined as any natural or manmade event, accident, or system with the ability to exploit a susceptibility of any part of a space system resulting in the potential damage, degradation, destruction, or denial of service to the mission. The next step is to determine the vulnerabilities in a space system by fusing space system susceptibilities with protection threats, where Threat X Susceptibility = Vulnerability and then recommend protection measures to alleviate the risks posed by the unmitigated vulnerabilities. This process is iterated between the SPWG and a mission's project management team between issuance of the baseline PPP and prior to each succeeding [key decision point (KDP)] until launch. After launch the PPPs are updated annually to accommodate changes in the threat environment. The desired end result is enhanced space system survivability.”
For more information on the contents for a PPP, a PPP outline is available on the section of the Community of Practice for Space Asset Protection accessible to NASA users from the NEN.
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: