Program Protection Plan
Peter Merrill and Howard Harris
Several years have passed since the announcement and inception of the new Department of Defense (DoD) program protection process. In 2011, the DoD program protection process was changed to integrate security into Systems Engineering, which enables the application of science and engineering in identifying vulnerabilities and completing an associated risk-cost-benefit trade study. The expanded role of the program protection process enables the most appropriate mix of measures to protect the information, components and technologies from known security threats and attacks.
This following Question and Answer series provides some lessons learned from a program protection practitioner’s experiences.
Q. What is the purpose of the Program Protection Plan (PPP)?
A. The PPP is much more than a document. It is used by programs to coordinate and integrate all security efforts throughout the entire system’s life cycle. A good PPP is a current, meaningful and usable reference that documents the decisions of the program manager (PM) to ensure that there is adequate protection against hostile activities such as reverse engineering of Critical Program Information (CPI) and malicious insertion of hardware and software components. It is critical to integrate program protection planning into the systems engineering process. DoD Instruction (DoDI) 5000.02, Change 3 requires that the PPP document be submitted five times for Milestone Decision Authority (MDA) review and approval as shown on Table 1.
Further, the DoD Directive on Cybersecurity in the Defense Acquisition System requires that the PPP continue to be reviewed and approved by the appropriate sustainment program manager. The PPP document includes five appendices: Security Classification Guide (SCG), Counterintelligence Support Plan (CISP), Criticality Analysis, Anti-Tamper (AT) Plan, and the Cybersecurity Strategy. Table 2 outlines this document and appendices.
Q. How can program protection be made more effective?
A. The DoD program protection process works effectively only if the procedures are followed and implemented. The process should start prior to Milestone A, and the program protection lead (ideally the System Security Engineer [SSE]) should be an active participant in the system design and all technical reviews.
For example, to influence the project’s design, the SSE should participate in the design trade-offs and be present during the System Requirements Review (SRR) to review the security requirements with the stakeholders. Experience shows that many programs do not start early enough with PPP requirements, nor do they have an SSE as part of their systems engineering integrated product team (IPT).
As another example, during the system specification review, the following should be accomplished:
- Confirm or update potential CPI.
- Reassess the risk associated with each potential CPI.
- Analyze the functional design for vulnerabilities and identify protections to mitigate the vulnerabilities.
- Update protection requirements and identify design alternatives for the functional baseline.
Even under the best circumstances, the PPP remains largely misunderstood. For example, many PMs identify the cybersecurity person, who is usually not the most appropriate PPP development leader, either because the most appropriate skill set is lacking, or the person already is very busy with the Risk Management Framework and other cyber activities. Some managers have found that they need a specialist to perform this analysis but then select the Information System Security Officer as the overseer. As a best practice, the systems engineer should take overall responsibility for the program’s security, and the lead role for PPP development should be assigned to the SSE (a systems engineer trained in system security techniques) working directly for the systems engineer. Table 3 lists the responsibilities for the three key roles associated with PPP development.
Q. How does the SSE work with the program management office (PMO) and vendors to ensure that the proper program protection requirements are implemented?
A. The SSE should assist the PMO in writing the system specifications and the Statement of Work (SOW) to include all required security requirements. The Deputy Assistant Secretary of Defense for Systems Engineering (DASD[SE]) document, “Suggested Language to Incorporate System Security Engineering for Trusted Systems and Networks into Department of Defense Request for Proposals,” dated January 2014, is an excellent source for developing the SOW’s security requirements. The SOW’s program protection-related requirements should address items such as identification of logic-bearing components (i.e., hardware, software, firmware that processes or stores information), software assurance, Supply Chain Risk Management, cybersecurity, AT, and criticality analysis.
In developing the system, the contractor can resource and implement program protection only as directed in the Request for Proposal (RFP). Regardless of how well the PPP document is written, the contractor effort is not affected unless the SOW includes the following types of contractual requirements:
- What the system must do, via the system specifications.
- How the contractor shall develop the system, via the SOW.
- The additional analyses required, via the SOW.
This is an iterative process. As the system requirements, design and implementation are defined and further refined, new vulnerabilities may be discovered and others eliminated. As each successive RFP is developed, it is necessary to update the protection requirements and language in the corresponding sections of the RFP based on the results from the PPP analysis of the previous contracted phase.
In this PPP example, the requirement minimizes the access paths to the most critical functions to reduce the possible ways of attacking these functions: The system shall use a least privilege implementation with distrustful decomposition (privilege reduction) or a similar approach, to move Level I critical functions into separate, mutually untrusting programs.
In the following SOW PPP example, the statement requires the contractor to develop software to meet security standards: The contractor shall develop secure design and coding standards and inspect the developed software through static analysis and design and code reviews to ensure that the developed software conforms to these standards.
Q. What is a lesson learned from developing the PPP document?
A. Obviously, this document covers a lot of detail as the overarching security plan for the entire program. The most successful PPP approach occurs when the PMO partners with Industry to develop the PPP and Program Protection Implementation Plan (PPIP). This partnership creates a winning combination as this approach acknowledges the strengths of both entities: Industry’s product understanding and the government’s ultimate desire to field a good, protected product to warfighters.
Q. What are some other lessons learned regarding security requirements?
A. In the standard acquisition process, a program’s Request for Information (RFI) should state the vendor’s need to address program protection requirements. One example of an often overlooked area during the early stages of the acquisition process is AT. The purpose of AT design is to ensure that our adversaries do not obtain CPI from our weapon systems or networks. For example, if an aircraft crashed in enemy territory, any CPI on that aircraft would be destroyed and unable to be recovered. The RFI can be used to let the prospective vendors know that AT will be critical, and they should be aware of DoD’s AT policy. The AT engineers at the Service component offices can identify shortcomings early on to avoid cost and schedule issues if afforded an early opportunity to influence AT design.
Q. What are the challenges in developing an effective PPP?
A. The Number One challenge is to get started and acknowledge that there are no short cuts to developing meaningful PPPs. Although each system is unique and has its own requirements, capabilities, functions and components, a very effective tool for all programs is the template provided in the DASD(SE) PPP Outline and Guidance. Using all parts of the template enables developers to meet draft requirements, and programs that have sufficiently responded to the basic outline can delve deeper and ask what makes their program unique and what specific parts of the program need protection.
Another challenge is that PMOs get stuck on the Trusted Systems and Networks (TSN) Analysis, more specifically while conducting the criticality analysis. According to the TSN Analysis document of July 2014, this analysis “consists of several activities: a criticality analysis to determine the most critical functions of the system, a threat assessment to understand the likely attacks, a vulnerability assessment to recognize vulnerabilities in the design and the commercial off-the-shelf products, a risk assessment, and selection of security countermeasures (risk mitigations) based on a cost-benefit trade-off analysis.” Figure 1 shows the general sequence of events included in the TSN analysis methodology.
Conducting a roundtable discussion and deciding by committee what is critical in just a few hours is not the best course of action if it concludes the program’s criticality analysis effort. The best results come from many hours of objective application of science and engineering principles by the systems engineer and SSE documenting that analysis in worksheets, and then sharing this with the PPP IPT so that any necessary changes are made. Table 4 is a sample worksheet used to document the system’s high-level mission tasks, supporting critical functions, and the components required to make the critical functions operate.
Table 5 is a sample worksheet used to record the analysis of the critical components, including their impact on the system, the assigned criticality level, and the rationale for the identified criticality level.
Q. What tools would you recommend be used in developing an effective PPP?
A. Other useful tools are available in addition to the PPP Outline and Guidance mentioned earlier. A good source of information is the Office of DASD(SE) Initiatives, Program Protection and System Security Engineering website. This site provides numerous resources, such as TSN Analysis, Engineering for System Assurance, and Defense Acquisition Guidebook, Chapter 9, Program Protection. Additionally, an online DAU course, Program Protection Planning Awareness (ACQ 160), is highly recommended for all IPT members and PMs.
Conclusion
The DoD-established program protection methods, processes and tools have proven useful in developing effective PPPs. The deliberate approach in identifying vulnerabilities and risks provides opportunities for thoughtful consideration and insight necessary for PMOs to analyze which program elements require additional protective measures. A few PMs have recognized the positive attributes of early program protection planning by proactively investing resources into the PPP development, and ensuring mechanisms were in place to best protect their program information. Network Enablers of the U.S. Army’s Program Executive Office Command Control Communications Tactical, have even directed PPP development for their non-program of record product lines. The Product Manager Waveforms Office from PM Tactical Radios is another organization that has embraced this process for all product lines.
These offices may not be required to do everything involved but are keenly aware to the merits of the program protection process. Knowledge and appreciation of the PPP requirements vary across programs. However, one constant many organizations share is the lack of knowledge base, SSEs and proper funding levels to develop the program’s PPP via the Program Objective Memorandum process. As the overarching security plan for acquisition programs, PPPs should be the program’s most wide-ranging security document. A program’s successful execution of these procedures depends upon the integration of system security engineering into systems engineering. The PM’s recognition of the SSE specialty and assignment of the right people with the right skill-sets and experiences to key program-protection roles demonstrate program prioritization. PPP development success also is influenced by a knowledgeable workforce that is familiar with PPP basics and that contributes to the PPP’s iterative process.
Read the full issue of
Merrill is a retired lieutenant colonel of the U.S. Army Signal Corps and president of Merrill Trusted Solutions, a program protection consulting company in San Diego, California. Harris is a professor of Program Management at the Defense Acquisition University’s West Region in San Diego.
The authors can be contacted at [email protected] and [email protected].