13.11. Compromises
Incidents of loss, compromise, or theft of proprietary information or trade secrets involving Critical Program Information (CPI), are immediately reported in accordance with Section 1831 et seq. of Title 18 of the United States Code, DoD Instruction 5240.04, and DoD Directive 5200.01. Such incidents are immediately reported to the Defense Security Service (DSS), the Federal Bureau of Investigation (FBI), the applicable DoD Component counterintelligence (CI) and law enforcement organizations. If the theft of trade secrets or proprietary information might reasonably be expected to affect DoD contracting, Defense Security Service (DSS) should notify the local office of the Federal Bureau of Investigation (FBI).
DSS presently has responsibility for protecting Critical Program Information (CPI) that is classified. However, the contract may specifically assign Defense Security Service (DSS) responsibility to protect Critical Program Information (CPI) that is controlled unclassified information. Consequently, Defense Security Service (DSS) would receive reporting on unclassified Critical Program Information (CPI) incidents if it had specific protection responsibility or the incident could involve foreign intelligence activity or violate the International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR).
13.12. Costs
13.12.1. Security Costs
The cost of implementing the selected countermeasures that exceed the normal National Industrial Security Program Operating Manual (NISPOM) costs are recorded in this section of the Program Protection Plan (PPP).
13.12.2. Acquisition and Systems Engineering Protection Costs
A cost benefit risk trade-off is used to decide upon which countermeasures to implement for each of the Critical Program Information (CPI) and Critical Function (CF). Based upon the criticality analysis results and Critical Program Information (CPI) identification (Section 13.3), the threats (Section 13.4), the vulnerability assessment (Section 13.5), the risk analysis, and the list of potential countermeasures (Section 13.6) the program is now ready to prepare the cost-benefit verses risk trade-off. For each Level I and selected level II Critical Function (CF) components and each Critical Program Information (CPI) along with the associated risk analysis a cost and schedule implementation estimate is prepared for each potential countermeasure. Also estimated is the residual (remaining) risk to the Critical Function (CF) or Critical Program Information (CPI) after the countermeasure has been implemented.
Based upon this analysis the program manager can select the countermeasure or combination of countermeasures that best fit the needs of the program. It may be to implement the optimum countermeasure(s) do not fit within the program’s constraints and other countermeasures can reduce the risk to an acceptable level. In some cases the program may choose to accept the risk and not implement any countermeasures. The emphasis of this analysis is to allow the program manager to perform “an informed” countermeasure trade-off with an awareness of the vulnerabilities and risks to the system. A summary of the trade-off analysis along with the rationale for the decision needs to be documented in this section of the Program Protection Plan (PPP).
13.13. Contracting
13.13.1. Request for Proposal (RFP) Guidance for all Phases
Comprehensive program protection needs to be addressed during the Request for Proposal (RFP) development and the system design to ensure that security is designed into the system. Program protection includes features that are included in the system design as wells as elements to be included in the processes used to develop the system. As a result program protection needs to be reflected in the system requirements document (SRD) and the statement of work (SOW) portions of the Request for Proposal (RFP) package. It may also be included in the instructions, conditions and notices to offerors (section L) and the evaluations factors for award (section M) of the Request for Proposal (RFP).
The program protection analysis needs to be performed iteratively prior to Milestone A and prior to each of the planned Systems Engineering Technical Reviews (SETRs) to ensure that the security features are considered and traded-off in conjunction with the other “ilities” and system performance.. The program protection analysis begins with the identification of the Critical Program Information (CPI) and Mission Critical Functions and components (described in Section 13.3) followed by the identification of vulnerabilities (described in Section 13.5), a risk assessment and the identification of potential countermeasures (described in Section 13.7).
13.13.1.1. System Requirements Document
The system requirements document should include security requirements based upon the initial countermeasures identified at Milestone A and good security practices. For example, if a particular Critical Program Information (CPI) component requires anti-tamper protection it may have a requirement to have seals, encryption, environmental and logging requirements for the component (see Section 13.7.1). An Information Assurance countermeasure example may be a requirement to include one of the controls specified in the DoD Information Assurance Certification and Accreditation Process (DIACAP) in the component (see Section 13.7.2).
Examples of software assurance countermeasures include requirements for exception handling and degraded mode recovery. There may also be requirements for specific secure coding practices for critical function components such as input validation, default deny, address execution prevention and least privilege (see Section 13.7.3). A supply chain countermeasure example for critical function components may be a requirement for redundancy diversity or checksum validation during startup (see Section 13.7.4)
13.13.1.2. Statement of Work
During the Request for Proposal (RFP) development not all of the system security requirements and design features have been determined. As a result it is necessary to transfer a major part of the program protection analysis, specification, and countermeasure implementation to the contractor to protect the system from loss of advanced technology, malicious insertion, tampering and supply chain risks. The following responsibilities should be considered for inclusion in the Statement of Work:
- The contractor shall perform or update a criticality analysis, vulnerability assessment, risk assessment, and countermeasure selection and implementation, with assumptions, rationale, and results, before each of the Systems Engineering Technical Reviews (SETRs) defined for the program.
- For each level I and level II component (in accordance with Table 13.3.2.1.T1), the contractor shall identify the associated logic-bearing hardware, software and firmware that implements critical functions or introduces vulnerability to the associated components (designated as "critical components”).
- The contractor shall demonstrate that the contractor has visibility into its supply chain for critical components, understands the risks to that supply chain, and has implemented or plans to implement risk mitigations to counter those risks.
- The contractor shall plan for and implement countermeasures which mitigate foreign intelligence, technology exploitation, supply chain and battlefield threats and system vulnerabilities that result in the catastrophic (Level I) and critical (Level II) protection failures, including:
- The application of supply chain risk management best practices, applied as appropriate to the development of the system. Supply chain risk management key practices may be found in the National Institute of Standards and Technology (NIST) Interagency Report 7622, Piloting Supply Chain Risk Management for Federal Information Systems, and the National Defense Industrial Association Guidebook, Engineering for System Assurance, both publicly available.
- The enumeration of potential suppliers of critical components, as they are identified, including cost, schedule and performance information relevant for choice among alternates and planned selection for the purpose of engaging with the government to develop mutually-agreeable risk management plans for the suppliers to be solicited.
- The processes to control access by foreign nationals to program information, including, but not limited to, system design information, DoD-unique technology, and software or hardware used to integrate commercial technology.
- The processes and practices employed to ensure that genuine hardware, software and logic elements will be employed in the solution and that processes and requirements for genuine components are levied upon subcontractors.
- The process used to protect unclassified DoD information in the development environment.
- The preceding clauses shall be included in the solicitations and subcontracts for all suppliers, suitably modified to identify the parties.
- The contractor shall develop a set of secure design and coding practices to be followed for implementation of Level I and II critical components, drawing upon the “top 10 secure coding practices” (https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+...) and the Common Weakness Enumeration (CWE)/SysAdmin, Audit, Network, Security (SANS) top 25 most dangerous software errors (http://cwe.mitre.org/top25/index.html).
- The contractor shall develop a Program Protection Implementation Plan (PPIP) that addresses the following sections of the Program Protection Plan (PPP) outline and example:
- Section 2 – Identifying what to protect
- Section 4 –Vulnerabilities
- Section 5 – Countermeasures
- Section 7 – Program Protection Risks
- Section 8 – Managing and Implementing Program Protection Plan (PPP)
- Section 9 --Process for Management and Implementation of Program Protection Plan (PPP)
- Section 10 – Process for Monitoring and Reporting Compromises
- Appendix C: Criticality Analysis
13.13.1.3. Instructions, Conditions and Notice to Offerors (Section L)
For many Request for Proposal (RFP) packages system security engineering may not have any explicit clauses in this section. If it is determined to identify specific program protection content for the proposal the following items should be considered:
- The offeror, as part of its technical proposal, shall describe the use of its systems security engineering process in specifying and designing a system that is protected from loss of advanced technology, malicious insertion, tampering and supply chain risks.
- The offer shall describe the offeror’s Critical Program Information (CPI) identification, mission criticality analysis, vulnerability assessment, risk evaluation and countermeasure implementation in arriving at its system specification and design.
- The offeror shall describe the offeror’s secure design and coding practices.
13.13.1.4. Evaluation Factors for Award (Section M)
For most Request for Proposal (RFP) packages systems security engineering may not rise to the level of an evaluation factor. If it does programs should consider following as evaluation criteria:
- The extent to which the offeror employs a disciplined, structured systems security engineering (SSE) process, including Critical Program Information (CPI) identification, criticality analysis, vulnerability assessment, risk analysis and countermeasure implementation in arriving at its system specification and design.
DAG Tutorial 
