Program Protection Plan (PPP) ADDM Template v3.1
PROGRAM NAME – ACAT LEVELPROGRAM PROTECTION PLANVERSION #SUPPORTING MILESTONE MS ANDAPPROPRIATE PHASE NAMEDATE**********************************************************___________________________________________________Undersecretary of DefenseDateAcquisition, Technology, and Logistics[or appropriate Milestone Decision Authority for non-ACAT 1D programs]DISTRIBUTION STATEMENT Click here to enter distribution letter and explanation (e.g.; “Approved for public release; distribution is unlimited”). Reference .SUBMITTED BY____________________________________________________________NameDateProgram ManagerCONCURRENCE____________________________________________________________NameDateProgram Executive Officer orEquivalentCOMPONENT APPROVAL[Required for programs with OSD approval (ACAT 1D, IAM, etc.)]____________________________________________________________NameDateComponent Acquisition ExecutiveGuidance: This document provides an outline, content, and formatting guidance for the Program Protection Plan (PPP) required by DoDI 5000.02 and DoDI 5200.39. The outline structure and tables are considered minimum content that may be tailored to meet individual program needs.General Guidance:Program Protection is the integrating process for managing risks to advanced technology and mission-critical system functionality from foreign collection, design vulnerability or supply chain exploit/insertion, and battlefield loss throughout the acquisition lifecycle. The purpose of the PPP is to help programs ensure that they adequately protect their technology, components, and information. This includes information that alone might not be damaging and might be unclassified, but that in combination with other information could allow an adversary to clone, counter, or defeat warfighting capability.The process of preparing a PPP is intended to help program offices consciously think through what needs to be protected and to develop a plan to provide that protection.Once a PPP is in place, it should guide program office security measures and be updated as threats and vulnerabilities change or are better understood. It is important that an end-to-end system view be taken when developing and executing the PPP. External, interdependent, or government furnished components that may be outside a program managers' control must be considered.The PPP should be a useable reference within the program for understanding and managing the full spectrum of program and system security activities throughout the acquisition lifecycle. The PPP is a plan, not a treatise; it should contain the information someone working on the program needs to carry out his or her Program Protection responsibilities and it should be generated as part of the program planning process.At Milestone A, it’s possible that not all Program Protection information will be available. Complete the tables/sections with the information that is available and document the plan to update this information as more details become available. At minimum, a Milestone A PPP should include an initial criticality analysis, candidate CPI, potential countermeasures, and the Information Assurance Strategy. The Milestone B PPP should be a comprehensive document.The Acquisition Information Assurance (IA) Strategy must now be appended to the PPP. Some sections (e.g. IA threats, MAC level)) have been moved to the body of the PPP for document streamlining. Other sections (e.g. Program Information, schedule) may be included in the Acquisition IA Strategy or referenced when other documents contain that information (e.g. Acquisition Strategy). The information must be available but does not need to be repeated in multiple documents if it is accessible to users of the PPP.If a topic/section can be sufficiently covered in a sentence instead of a paragraph, write a sentence.Wherever possible, reference or point to other documents containing relevant information rather than duplicating the information in the PPP unless that information would be valuable to users of the plan. Do not simply repeat general policies unless that information would be valuable to the user of the plan.Appendices are required where relevant and appropriate. For example, every acquisition program must have an Information Assurance Strategy but not all acquisition programs will have an Anti-Tamper plan.Classification Guidance: The PPP should be classified by content. Threat and vulnerability information is commonly classified at SECRET or above. Detailed descriptions of CPI and critical functions/components may also be classified. The program Original Classification Authority is responsible for determining appropriate classification of the PPP and related information. The program may opt to reference some tables (e.g. threats, vulnerabilities) as classified appendices.The office of primary responsibility for this guide is the Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)). This office will continue to develop and coordinate updates to the guide as required, based on any future policy changes and customer feedback. To provide feedback, send e-mail to dasd-se@osd.mil.FOUO Guidance: Determine whether FOUO is applicable per DoDM 5200.01, Volume 4, “DoD Information security Program: Controlled Unclassified Information (CUI),” February 24, 2012.FOUO Guidance Source: : PEO-specific instruction to be added.References: Deputy Assistant Secretary of Defense: Systems Engineering. Program Protection Plan Outline and Guidance, Version 1.0. JUL 2011. Memorandum for Secretaries of the Military Departments Directors of the Defense Agencies, Document Streamlining – Program Protection Plan (PPP), July 18, 2011Contents TOC \o "1-3" \h \z \u 1.Introduction – Purpose and Update Plan. PAGEREF _Toc444771661 \h 91.0.1 Users of PPP. PAGEREF _Toc444771662 \h 91.0.2 Alignment with Contractor’s Program Protection Implementation Plan(s) (PPIP). PAGEREF _Toc444771663 \h 91.0.3 Contractor’s Responsibility for Program Protection. PAGEREF _Toc444771664 \h 91.0.4 Timing of and Criteria for PPP updates. PAGEREF _Toc444771665 \h 91.0.5 Update Authority. PAGEREF _Toc444771666 \h 91.0.6 Approval Authority for Different Updates. PAGEREF _Toc444771667 \h 91.0.7 PPP Update Record. PAGEREF _Toc444771668 \h 91.1.Technology/System Description. PAGEREF _Toc444771669 \h 101.1.1.Link to Reference Document. PAGEREF _Toc444771670 \h 101.1.2.Program Information. PAGEREF _Toc444771671 \h 101.2.Program Protection Responsibilities. PAGEREF _Toc444771672 \h 101.2.01 Countermeasure Execution Responsibility. PAGEREF _Toc444771673 \h 101.2.02 Program Protection Responsibilities. PAGEREF _Toc444771674 \h 111.2.03 Execution Responsibilities. PAGEREF _Toc444771675 \h 112.Program Protection Summary. PAGEREF _Toc444771676 \h 112.1.Schedule. PAGEREF _Toc444771677 \h 112.2.CPI and Critical Functions and Components Protection. PAGEREF _Toc444771678 \h 122.2.01 CPI and Critical Countermeasures Summary. PAGEREF _Toc444771679 \h 123.Critical Program Information (CPI) and Critical Components. PAGEREF _Toc444771680 \h 133.1.Identification Methodology. PAGEREF _Toc444771681 \h 133.1.01 CPI Identification and Criticality Analysis Participants. PAGEREF _Toc444771682 \h 143.1.02 Timing of Identification and Updates to CPI and Mission Critical Functions and Components. PAGEREF _Toc444771683 \h 143.1.03 Process for Identifying CPI, including Inherited CPI. PAGEREF _Toc444771684 \h 143.1.04 Approach for Performing Criticality Analysis. PAGEREF _Toc444771685 \h 143.2.Inherited CPI and Critical Components. PAGEREF _Toc444771686 \h 143.2.01 Inherited Items Approach. PAGEREF _Toc444771687 \h 143.2.02 Inherited CPI and Critical Components Table. PAGEREF _Toc444771688 \h 153.anic CPI and Critical Components. PAGEREF _Toc444771689 \h 154.Horizontal Protection. PAGEREF _Toc444771690 \h 164.01 Identify the person or office responsible for horizontal protection. PAGEREF _Toc444771691 \h 164.02 Horizontal Protection Information. PAGEREF _Toc444771692 \h 164.03 Alignment and Issue Resolution of Protection of Horizontal CPI. PAGEREF _Toc444771693 \h 164.04 Specify when the Program will Create/Update its Acquisition Security Database (ASDB) Record. PAGEREF _Toc444771694 \h 165.Threats, Vulnerabilities, and Countermeasures. PAGEREF _Toc444771695 \h 175.01 Summary of CPI Threats, Vulnerabilities, and Countermeasures. PAGEREF _Toc444771696 \h 175.1.Threats. PAGEREF _Toc444771697 \h 185.1.01 Threat Products POC and Timing. PAGEREF _Toc444771698 \h 185.1.02 Threat Products Description. PAGEREF _Toc444771699 \h 185.1.03 Threat Products Update Frequency. PAGEREF _Toc444771700 \h 185.1.04 Threat Products References. PAGEREF _Toc444771701 \h 185.1.05 Identified Threats. PAGEREF _Toc444771702 \h 195.2.Vulnerabilities. PAGEREF _Toc444771703 \h 205.2.01 Potential CPI and Critical Component Vulnerabilities. PAGEREF _Toc444771704 \h 205.2.02 New Vulnerabilities Identification Process. PAGEREF _Toc444771705 \h 205.2.03 Vulnerabilities Identification POC and Update Frequency. PAGEREF _Toc444771706 \h 205.2.04 Specify the Frequency that the Vulnerabilities be Re-assessed. PAGEREF _Toc444771707 \h 205.2.05 Specify the Way in which Vulnerabilities will be Identified and Mitigated. PAGEREF _Toc444771708 \h 205.3.Countermeasures. PAGEREF _Toc444771709 \h 205.3.01. Countermeasures Selection Approach. PAGEREF _Toc444771710 \h 215.3.02. Countermeasures Implementation Responsibility. PAGEREF _Toc444771711 \h 215.3.03. Protection Requirements Incorporation into Contracts. PAGEREF _Toc444771712 \h 215.3.04. Countermeasures Implementation Descriptions. PAGEREF _Toc444771713 \h 215.3.05. Countermeasure Implementation Plan vs Actual Tracking. PAGEREF _Toc444771714 \h 215.3.1.Anti-Tamper (AT). PAGEREF _Toc444771715 \h 215.3.rmation Assurance (IA). PAGEREF _Toc444771716 \h 225.3.3.Software Assurance. PAGEREF _Toc444771717 \h 235.3.4.Supply Chain Risk Management. PAGEREF _Toc444771718 \h 265.3.5.System Security Engineering. PAGEREF _Toc444771719 \h 275.3.6.General Countermeasures. PAGEREF _Toc444771720 \h 286.Other System Security-Related Plans and Documents. PAGEREF _Toc444771721 \h 286.01 Other System Security-Related Plans and Documents Table. PAGEREF _Toc444771722 \h 286.02 Key Commitments Table. PAGEREF _Toc444771723 \h 297.Program Protection Risks. PAGEREF _Toc444771724 \h 297.01. Program Protection Risks Integration. PAGEREF _Toc444771725 \h 297.02 Residual Risks and Unmitigated Risks Identification. PAGEREF _Toc444771726 \h 297.03. Risk Cube and Mitigation Plan for the top Program Protection Risks. PAGEREF _Toc444771727 \h 298.Foreign Involvement. PAGEREF _Toc444771728 \h 298.01. Foreign Involvement Summary. PAGEREF _Toc444771729 \h 298.02. Applicable Technology Security and Foreign Disclosure (TS&FD) Processes. PAGEREF _Toc444771730 \h 308.03. Previous Sales to Foreign Allies. PAGEREF _Toc444771731 \h 308.04. Addressing of Export Requirements/Restrictions and Responsibilities. PAGEREF _Toc444771732 \h 308.1.Defense Exportability Features. PAGEREF _Toc444771733 \h 308.1.1. Foreign Military Sales and Direct Commercial Sales Potential Risk to Program. PAGEREF _Toc444771734 \h 308.1.2. DEF Candidate Viability. PAGEREF _Toc444771735 \h 318.1.3. Include a hotlink to the relevant DEF discussion. PAGEREF _Toc444771736 \h 319.Processes for Management and Implementation of PPP. PAGEREF _Toc444771737 \h 319.1.Audits/Inspections. PAGEREF _Toc444771738 \h 319.2.Engineering/Technical Reviews. PAGEREF _Toc444771739 \h 319.2.1. Addressing of System Security Requirements. PAGEREF _Toc444771740 \h 319.2.2. Program Protection Entry/Exit Criteria. PAGEREF _Toc444771741 \h 319.3.Verification and Validation. PAGEREF _Toc444771742 \h 329.3.1.System security requirements testing integration. PAGEREF _Toc444771743 \h 329.3.2.Link to relevant discussion in T&E documents. PAGEREF _Toc444771744 \h 329.4.Sustainment. PAGEREF _Toc444771745 \h 329.4.1.Program Protection requirements and considerations in sustainment. PAGEREF _Toc444771746 \h 329.4.2.Link to the relevant Lifecycle Sustainment Plan (LCSP) language. PAGEREF _Toc444771747 \h 3210.Processes for Monitoring and Reporting Compromises. PAGEREF _Toc444771748 \h 3210.1.CPI Compromise/Supply Chain Exploit Response Plan/procedure. PAGEREF _Toc444771749 \h 3210.2.Anti-Tamper Event or Supply Chain exploit Definition. PAGEREF _Toc444771750 \h 3211.Program Protection Costs. PAGEREF _Toc444771751 \h 3311.1.Security Costs. PAGEREF _Toc444771752 \h 3311.1.1.Security Costs above NISPOM Requirements. PAGEREF _Toc444771753 \h 3311.1.2.SCIFs or Other Secure Facilities Construction Requirements. PAGEREF _Toc444771754 \h 3311.1.3.Limited Access Rosters or Other Similar Instruments Cost. PAGEREF _Toc444771755 \h 3311.2.Acquisition and Systems Engineering Protection Costs. PAGEREF _Toc444771756 \h 3311.2.1.Acquisition and Systems Engineering Protection Costs Table. PAGEREF _Toc444771757 \h 3311.2.2.Non-recurring Program Protection Engineering Costs Accounting. PAGEREF _Toc444771758 \h 3411.2.3.Projected Cost-benefit Tradeoffs Approach in Countermeasure Selection. PAGEREF _Toc444771759 \h 34Appendix A: Security Classification Guide. PAGEREF _Toc444771760 \h 35Appendix B: Counterintelligence Support Plan. PAGEREF _Toc444771761 \h 36Appendix C: Criticality Analysis. PAGEREF _Toc444771762 \h 37Appendix D: Anti-Tamper Plan. PAGEREF _Toc444771763 \h 38Appendix D-1: Anti-Tamper Plan Waiver. PAGEREF _Toc444771764 \h 38Appendix E: Acquisition Information Assurance (IA) Strategy. PAGEREF _Toc444771765 \h 39Introduction – Purpose and Update Plan.1.0.1 Users of PPP.Click here to enter text.Guidance: Who will use the PPP? 1.0.2 Alignment with Contractor’s Program Protection Implementation Plan(s) (PPIP).Click here to enter text.Guidance: What is the plan to align Prime Contractor Program Protection Implementation Plan(s) (PPIP) with this PPP if they are written? 1.0.3 Contractor’s Responsibility for Program Protection.Click here to enter text.Guidance: What aspects of Program Protection will you ask the contractor to do? 1.0.4 Timing of and Criteria for PPP updates.Click here to enter text.Guidance: Summarize the timing of PPP updates (e.g. prior to milestone, prior to export decision, following Systems Engineering Technical Review).1.0.5 Update Authority.Click here to enter text.Guidance: Describe the update authority.1.0.6 Approval Authority for Different Updates.Click here to enter text.Guidance: Describe the update authority for different updates.1.0.7 PPP Update Record.Click here to enter text.Guidance: Provide a table listing PPP updatesTable 1.0-1 PPP Update Record (mandated)Revision Number DateChangesApproved By????????????????????Technology/System Description.Link to Reference Document.Click here to enter text.Guidance: Reference and include a link/direction to the appropriate acquisition document (e.g.; Technology Development Strategy, Acquisition Strategy) that describes the technology/system.Program Information.Click here to enter text.Guidance: Reference and include a link/direction to the appropriate acquisition document (e.g.; Technology Development Strategy, Acquisition Strategy) that describes the technology/system and the project/program for which it will be developed.Table 1.1-1 Program InformationProgram NameACAT LevelMission Assurance Category (MAC)Last Milestone????????????????????Program Protection Responsibilities.Click here to enter text.Guidance: Who is responsible for Program Protection on the program? The chain of responsibility for all aspects of Program Protection should be clear. Include contact information for Program Protection leads/resources/SMEs. What aspects are each of these resources responsible for? For every countermeasure being implemented, identify who is responsible for execution. Include relevant PEO/SYSCOM contacts as well.1.2.01 Countermeasure Execution Responsibility.Click here to enter text.Guidance: Who is responsible for Program Protection on the program? The chain of responsibility for all aspects of Program Protection should be clear1.2.02 Program Protection Responsibilities.Click here to enter text.Guidance: Include contact information for Program Protection leads/resources/SMEs. What aspects are each of these resources responsible for? 1.2.03 Execution Responsibilities.Click here to enter text.Guidance: Identify who is responsible for execution for every countermeasure being implemented. Include relevant PEO/SYSCOM contacts as well.Table 1.2-1 Program Protection Responsibilities (mandated) (sample)Title/RoleNameLocationContact InfoProgram Manager???Lead Systems Engineer???Program Protection Lead???Anti-Tamper Lead???Info. Assurance Lead???Software Assurance Lead???SCRM Lead???????Program Protection Summary.Schedule.Click here to enter text.Guidance: A Program Protection schedule overlaid on to the program's master schedule (milestones, systems engineering technical reviews, etc.) includes the following:CPI and critical function/component identification/updatesAcquisition Security Database (ASDB) updatesThreat assessment requestsVulnerability assessments, red teams, etc.Security Audits/InspectionsEngagement with Systems Engineering Technical Reviews (e.g. subsystemPreliminary Design Reviews for critical components)Countermeasure (e.g. Anti-Tamper, Information Assurance) testing/verificationeventsForeign involvement events (Exportability likelihood assessment, Cooperative Development, License Requests, etc.)Program Protection activities and events should be integrated in overall program scheduling.CPI and Critical Functions and Components Protection.Click here to enter text.Guidance: List all CPI and critical functions and components over the lifetime of the program (including inherited and organic) mapped to the security disciplines of the countermeasures being applied in Table 2.2-1 of the Program Protection Plan Outline and Guidance (Version 1.0, July 2011). For each countermeasure being implemented, list the responsible party for execution in Section 2.1 (above). 2.2.01 CPI and Critical Countermeasures Summary.Click here to enter text.Guidance: Table 2.2-1 is meant to summarize the protection scheme/plan for the program. The detail supporting this summary assessment (including the threats and vulnerabilities to which the selected countermeasures apply) is planned for and documented in the subsequent sections of the document.Table 2.2-1 CPI and Critical Components Countermeasure Summary (mandated) (sample)?#Protected Item (Inherited and Organic)Countermeasures?12345678910111213141516CPI1Algorithm QPXXXXXXXXXX???XX?2System Security Configuration??????????X??I??3Encryption HardwareXXXXXXXX???X?X??4IDS Policy ConfigurationXXXXXXXX?????X??5IDS Collected DataXXXXXXI???????I?6KGV-136BXXXX??IXI???I???Critical Components7iDirect M1D1T Hub-Line CardXXXXXXXX???XXX??8Cisco Router IOS with Advance Security Option (ASO)XXXXXX??????????9?????????????????10?????????????????11?????????????????12?????????????????13???????????????????KEY [Examples Included: UPDATE THIS LIST ACCORDING TO PROGRAM]????General CMsResearch and Technology Protection CMSTrusted Systems Design CMs??Key??X = Implemented1 Personnel Security8 Transportation Mgmt11 IA/Network Security??I = Denotes protection already implemented if CPI is inherited2 Physical Security9 Anti-Tamper12 Communication Security??3 Operations Security10 Dial-down Functionality13 Software Assurance??4 Industrial Security??14 Supply Chain Risk Management??5 Training??15 System Security Engineering (SSE)????6 Information Security??16 Other????7 Foreign Disclosure/ Agreement????????????Critical Program Information (CPI) and Critical Components.Identification Methodology.Guidance: The end-to-end system must be considered, including items such as mission packages, government furnished components, and interdependent systems that may be outside a program manager's control.CPI and mission critical functions and components must be identified by a multi-disciplined group.Criticality analysis should be led by systems engineers and mission/operator representatives.CPI identification should be led by technology protection and security rmation regarding these components and/or technologies must be considered for protection.Criticality analysis updates should be tied to Systems Engineering Technical Reviews.Inherited CPI is CPI from other acquisition programs, subsystems, or projects that are being incorporated or implemented into this program.Early in the program this section will reflect intentions. Updates to this section will provide a record of work completed and any remaining.3.1.01 CPI Identification and Criticality Analysis Participants.Click here to enter text.Guidance: Describe the methodology that will be used to identify CPI and mission critical functions and components in accordance with DoDI 5200.391 and DoDI 5000.022 including the CPI identification and criticality analysis participants.3.1.02 Timing of Identification and Updates to CPI and Mission Critical Functions and Components. Click here to enter text.Guidance: Describe the methodology that will be used for the timing of identification and updates to CPI and mission critical functions and components.3.1.03 Process for Identifying CPI, including Inherited CPI.Click here to enter text.Guidance: Describe the process for identifying CPI, including inherited CPI.3.1.04 Approach for Performing Criticality Analysis. Click here to enter text.Guidance: Describe the approach for performing criticality analysis.Inherited CPI and Critical Components.3.2.01 Inherited Items Approach.Click here to enter text.Guidance: Summarize the approach to identifying and managing Program Protection risks for any inherited CPI or critical components. Identify the system from which the inherited item comes. Specify whether the system will be protected in the same manner in which it was originally protected. Indicate variances in usage and plans for the adjustment of countermeasures as appropriate.3.2.02 Inherited CPI and Critical Components Table.Click here to enter text.Guidance: Summarize the approach to identifying and managing Program Protection risks for any inherited CPI or critical components. Identify the POC for questions regarding the inherited system(s). Specify the way in which the program will interact with the inherited system(s) to ensure horizontal protection.Table 3.2-1 Inherited CPI and Critical Components (mandated) ?Inherited Critical ItemParent ProgramOriginal UsePlanned UseVariation in CMs?Inherited Program POCCPI??????Critical Components??????Organic CPI and Critical Components.Click here to enter text.Guidance: As CPI and Critical Components are identified, track them in Table 3.3-1 below.Identify CPI and critical components, and summarize the effects or consequences if they are compromised. Track any adds/changes/deletions from this list over the course of the program with rationale for the edit.Where will the CPI and critical components be physically located during the acquisition lifecycle? Indicate whether or not contractor PPIPs are in place to flow protection requirements to contractor locations.Show traceability from mission-level documents (JCIDS Key Performance Parameters, Key System Attributes, etc.) and Critical Technology Elements (CTE) to the system architecture.Table 3.3-1: Organic CPI and Critical Components (mandated)?Assessment Date(s): 22 December 2009?CPI/CCConsequence of CompromiseStatus/Date & Justification for Status ChangeTraceable CTEs, KPPs, etc.Export Control AreasPhysical LocationSystem Location PPIP Exists?CPI????????????????Critical Components????????????????Horizontal Protection.4.01 Identify the person or office responsible for horizontal protection.Click here to enter text.Guidance: Identify the person or office responsible for horizontal protection.4.02 Horizontal Protection Information.Click here to enter text.Guidance: Identify other programs or weapons systems with CPI similar to this program.4.03 Alignment and Issue Resolution of Protection of Horizontal CPI.Click here to enter text.Guidance: Specify the way in which the program will align protection of horizontal CPI. Include the way in which issues/disagreements about protection of horizontal CPI will be resolved.4.04 Specify when the Program will Create/Update its Acquisition Security Database (ASDB) Record. Click here to enter text.Guidance: Specify when the program will create/update its Acquisition Security Database (ASDB) record. The ASDB and associated registration/help information is located on SIPRNET at . The program ASDB record should be created as soon as CPI is identified and updated periodically, as changes occur and at each subsequent milestone. Critical Functions/Components are not identified in the ASDB. Upon creation of an ASDB record, programs should use the search capabilities to identify other programs with potentially similar CPI and follow up with their POCs to ensure horizontal protection. See Table 4.0-1 Horizontal Protection Information.Table 4.0-1: Horizontal Protection Information (mandated)Date of Last ASDB Update: Date of Next ASDB Update: CPIOther Programs With Same of Similar CPIPending Adjudications of CPI? (Y/N)?????????Threats, Vulnerabilities, and Countermeasures.5.01 Summary of CPI Threats, Vulnerabilities, and Countermeasures.Click here to enter text.Guidance:Summarize any identified threats and vulnerabilities to CPI and critical functions/components in Table 5.0-1 below. Also identify any countermeasures selected to mitigate risks of compromise.This table should be updated over time as the information is identified; early in the program, identify the plan for obtaining this information in Sections 5.1-5.3 below.The numbers in the threat and vulnerabilities tables should correspond to the numbered rows in the threat table (5.1-2) and vulnerability table (5.2-1) below. All CPI and critical functions/components should be reflected in the table.Table 5.0-1 Summary of CPI Threat, Vulnerabilities, and Countermeasures (mandated) (sample) ?CPI/CC (and CC supplier) Section 2.0Threats Section 5.1Vulnerabilities Section 5.2Countermeasures Section 5.3CPIAlgorithm4, 5, 7, 13-151, 2Anti-Tamper, SSE, Supply Chain Risk ManagementSystem/Security Configuration1, 9, 14, 151Secure storage of configuration; Supplier AssuranceEncryption Hardware 2, 9, 142 Supply Chain Risk Management, NSA encryption deviceCritical ComponentsiDirect M1D1T Hub-line Card2, 8, 9, 143Communication Security; Sofgtware Assurance; SCRMCisco Router IOS with ASO2, 6, 8, 9, 144Supply Chain Risk ManagementThreats.5.1.01 Threat Products POC and Timing.Click here to enter text. Guidance: Identify the person or office responsible for requesting and receiving threat products. Specify when those threat products will be requested. Identify the person or office in the intelligence community responsible for supporting these requests. Include these contacts in the table in Section 1.2.5.1.02 Threat Products Description. Click here to enter text. Guidance: Identify the threat products to be requested for the program, including when and how they will they be used. 5.1.03 Threat Products Update Frequency.Click here to enter text. Guidance: Specify the frequency of which the threat products will be updated.5.1.04 Threat Products References.Click here to enter text. Guidance: List any threats identified for threat products already received.As threat products are received, reference these documents in Table 5.1-1. This table should be comprehensive by Milestone B. For the Supply Chain Threat Assessments, document each critical component supplier (or potential supplier) that has been assessed. Table 5.1-1 Threat Product References (mandated) (sample) Title of Program-Specific or Other Threat Products Used for PPP Threat AnalysisClassificationDocument DateOrganization(s) Producing the ProductReference/Link to ProductFormal Threat ReportsAFOSI Counterintelligence Assessment/ReportS Jul-02HQ Office of Special Investigations?AFOSI Department of Defense Threat AssessmentS Dec-07Office of Special Investigations?Capstone Threat Assessment (CTA)U-SDec-02Defense Intelligence Agency?Foreign Technology AssessmentU Feb-04Counterintelligence Service?Integrated Threat Assessment (ITA)U-SJan-02Service for Special Assess Programs?Technology Targeting Risk Assessment (TTRA)U-SMar-06Defense Intelligence Agency?System Threat Assessment Report (STAR)S Jan-07Defense Intelligence Agency?Supply Chain Threat AssessmentsiDirect M1D1T Hub-line Card AssessmentTS/SCIApr-09Defense Security Service?Cisco Router IOS with ASOTS/SCIApr-09Defense Security Service?Other Threat DocumentsTechnology Collection Trends in the U.S. Defense IndustryU Oct-06Defense Security Service?Targeting U.S. TechnologiesU Feb-06Defense Security Service?5.1.05 Identified Threats.Click here to enter text. Guidance: Summarize the threats identified in Table 5.1-2 of the Program Protection Plan Outline and Guidance.Table 5.1-2 Identified Threats (mandated) (sample)T#ThreatDescriptionConsequence of threat realization1HUMINT CollectionCountry X is actively targeting CPI #3 at Location BCompromise of U.S. technology lead2Malicious Code InsertionCountry Y is known to have inserted malware into the software that Critical Component #2 depends on Degraded or untrustworthy performance of targeting module3???4???????Vulnerabilities.5.2.01 Potential CPI and Critical Component Vulnerabilities.Click here to enter text. Guidance: Specify the vulnerabilities identified to date. Summarize the results of any vulnerability assessments, red teams, etc. performed to date in Table 5.2-1 below.Table 5.2-1 Potential CPI and Critical Component Vulnerabilities (mandated) V#CPI/Critical ComponentsIdentified Vulnerabilities1??2??3??5.2.02 New Vulnerabilities Identification Process.Click here to enter text. Guidance: How will the program identify new vulnerabilities (both system-level and in the development environment) to the CPI and mission-critical functions and components?5.2.03 Vulnerabilities Identification POC and Update Frequency.Click here to enter text. Guidance: Identify the person or office responsible for identifying vulnerabilities to the CPI and mission-critical functions and components, as well as the frequency for updates. The person or office should be included in the table in Section 1.2.5.2.04 Specify the Frequency that the Vulnerabilities be Re-assessed.Click here to enter text. Guidance: Specify the frequency that the vulnerabilities be re-assessed.5.2.05 Specify the Way in which Vulnerabilities will be Identified and Mitigated.Click here to enter text. Guidance: Specify the way in which vulnerabilities will be identified and mitigated.Countermeasures.5.3.01. Countermeasures Selection Approach.Click here to enter text. Guidance: How will countermeasures be selected to protect CPI and critical functions/components?5.3.02. Countermeasures Implementation Responsibility.Click here to enter text. Guidance: Who has the responsibility for their implementation? Include in the table in Section 1.2.5.3.03. Protection Requirements Incorporation into Contracts.Click here to enter text. Guidance: How will contracts supporting the acquisition program incorporate protection requirements? Indicate the RFP Contract Line Item Number (CLIN) or Data Item Description (DID) that will be used to ensure that CPI and critical functions/components are protected in the development environment and on the system.5.3.04. Countermeasures Implementation Descriptions. Click here to enter text. Guidance: Succinctly describe the implementation of each countermeasure used to protect CPI and critical functions and components. Be specific: If SCRM Key Practices apply, describe which ones; if using Software Assurance techniques, explain which ones.5.3.05. Countermeasure Implementation Plan vs Actual Tracking.Click here to enter text. Guidance: Indicate planned implementation and actual implementation as the PPP evolves. Explain deviations from the plan. At a minimum, address implementation of the countermeasures in Section 5.3.1- 5.3.5 or rationale for not using them.Anti-Tamper (AT).5.3.1.01. AT Requirements Identification and Plan Development Responsibilities.Click here to enter text. Guidance: Who will identify AT requirements and who is responsible for developing an AT plan?5.3.1.02. AT Plan Development Schedule.Click here to enter text. Guidance: When will the AT Plan be completed? Include plans for engaging with the Component AT lead and Executive Agent for AT. If an AT Plan or AT Plan Waiver has been developed, submit as an rmation Assurance (IA).Guidance: IA countermeasures planning should account for the system being acquired and any support information systems that may contain or host CPI and critical functions and components. The Acquisition IA Strategy documents the plan for implementing IA specifically on the system being acquired. IA controls can also be applied to protect CPI and critical functions and components as they are handled/transmitted across contractor or partner systems. For example, contractor development environments may host CPI and should be evaluated for protection.5.3.2.01. IA Countermeasures Adequacy Assessment Responsibility.Click here to enter text. Guidance: Who is responsible for assessing the adequacy of IA countermeasures for CPI? 5.3.2.02. IA Schedule.Click here to enter text. Guidance: What are the key IA schedule milestones?5.3.2.03. Implementation of IA Protections for DoD Systems Hosting CPI.Click here to enter text. Guidance: How will the appropriate implementation of IA protections for DoD information systems hosting CPI be ensured?5.3.2.04. Implementation of IA Protections for non- DoD Systems Hosting CPI.Click here to enter text. Guidance: How will the appropriate implementation of IA protections for contractor-owned non-DoD information systems hosting CPI be ensured?5.3.2.04.01. IA Controls Negotiations.Click here to enter text. Guidance: How will IA controls be negotiated with contractors? 5.3.2.04.02. Responsibility for IA Controls Flow to Subcontractors.Click here to enter text. Guidance: Who will ensure these controls are flowed down to subcontractors? 5.3.2.04.03. Responsibility for Inventory of CPI Hosted on Contractor Systems.Click here to enter text. Guidance: Who will keep an inventory of CPI hosted on contractor information systems? 5.3.2.05. Implementation of IA Protections for Acquired System Hosting CPI.Click here to enter text. Guidance:How will the appropriate implementation of IA protections for the system being acquired (if it includes on-board CPI) be ensured?Include the Component CIO approved Acquisition IA Strategy as an Appendix. (See Appendix E description in this document)Software Assurance.5.3.3.01. Software Assurance Responsibility.Click here to enter text. Guidance: Who is responsible for Software Assurance?5.3.3.02. Software Design and Testing Approach.Click here to enter text. Guidance: How will software be designed and tested to assure protection of critical functionality and CPI? 5.3.3.03. Application of Software Assurance Countermeasures.Click here to enter text. Guidance: How will software architectures, environments, designs, and code be evaluated with respect to CVE (Common Vulnerabilities and Exposures), CAPEC (Common Attack Pattern Enumeration and Classification), and CWE (Common Weakness Enumeration)?CVE - Used to identify and coordinate SW vulnerabilities that enable various types of attacks.CAPEC - Used for the analysis of common destructive attack patternsCWE - Used to examine software architecture/design and source code for weaknesses.Table 5.3.3-1 Application of Software Assurance Countermeasures (sample)Development ProcessSoftware (CPI, critical function components, other software)Static Analysis p/a (%)Design InspectCode Inspect p/a (%)CVE p/a (%)CAPEC p/a (%)CWE p/a (%)Pen TestTest Coverage p/a (%)Developmental CPI SW100/80Two Levels100/80100/60100/80100/80Yes75/50Developmental Critical Function SW100/80Two Levels100/80100/70100/80100/80Yes75/50Other Developmental SWnoneOne Level100/65 10/0 10/0 10/0No 50/25COTS CPI and Critical Function SWVendor SwAVendor SwAVendor SwA000YesUNKCOTS (other than CPI and Critical Function) and NDI SWNo No No 000No UNKOperational System?Failover Multiple Supplier Redundancy (%)Fault IsolationLeast PrivilegeSystem Element IsolationInput checking / validationSW load keyDevelopmental CPI SW30AllAllyesAllAllDevelopmental Critical Function SW50AllAllyesAllAllOther Developmental SWnonePartialnonenoneAllAllCOTS (CPI and CF) and NDI SWnonePartialAllnoneWrappers/AllAllDevelopment Environment SW Product Source Release testingGenerated code inspection p/a (%)????C Compiler NoYes50/20????Runtime libraries YesYes70/none????Automated test system NoYes50/none????Configuration management systemNoYesNA????DatabaseNoYes50/none????????????Development Environment Access Controlled access; Cleared personnel only5.3.3.04. COTS Software and Software of Unknown Pedigree Protection, Testing/vetting.Click here to enter text. Guidance: How will COTS software and software of unknown pedigree (i.e., software from sources buried in the supply chain) be protected and tested/vetted?5.3.3.05. How will the Development Environment be Protected?Click here to enter text. Guidance: How will the critical functions and CPI be protected in the operational system?5.3.3.05.01. List the Development Environment ToolsClick here to enter text. Guidance: List the development environment tools.5.3.3.06. Development Environment Access. Click here to enter text. Guidance: How will the development environment be protected? Who has access to the development environment?5.3.3.06.01. Development Environment Access List Management. Click here to enter text. Guidance: Who will be responsible for maintaining a list of cleared, US citizens as well as foreign nations/nationals that have access?5.3.3.06.02. Where will the list be stored, and how often will it be updated?Click here to enter text. Guidance: Where will the list be stored, and how often will it be updated?5.3.3.07. Planned vs. Actual Testing/Evaluation Rates Deviation.Click here to enter text. Guidance: P/A indicates planned/actual – explain any deviations from planned testing/evaluation rates. For further details see key practices 9,11,16,17,19,21 and 23 in the "Key Practices and Implementation Guide for DOD Comprehensive National Cyber Initiative 11 Supply Chain Risk Management Pilot Program.”Supply Chain Risk Management.5.3.4.01. Supply Chain Risk Management.Click here to enter text. Guidance: How will the program manage supply chain risks to CPI and critical functions and components?5.3.4.02. Supply Chain Threat Assessments Use and Influence.Click here to enter text. Guidance: Explain how supply chain threat assessments will be used to influence system design, development environment, and procurement practices. 5.3.4.03. Supply Chain Threat Assessments Use and Influence Responsibiity.Click here to enter text. Guidance: Who has this responsibility? 5.3.4.04. Supply Chain Threat Assessments Request Timing. Click here to enter text. Guidance: When will threat assessments be requested?Trusted Suppliers.Click here to enter text. Guidance:Will any ASICs require trusted fabrication?How will the program make use of accredited trusted suppliers of integrated circuit-related services?5.3.4.1.01. Trusted Fabrication of ASICs.Click here to enter text. Guidance: Will any ASICs require trusted fabrication?5.3.4.1.02. Utilization of Accredited Trusted Suppliers.Click here to enter text. Guidance: How will the program make use of accredited trusted suppliers of integrated circuit-related services?5.3.4.2 Counterfeit Prevention.Click here to enter text. Guidance: What counterfeit prevention measures will be in place? How will the program mitigate the risk of counterfeit insertion during Operations and Maintenance?System Security Engineering.5.3.5.01. System Security Engineering Responsibility.Click here to enter text. Guidance: Identify the person or office responsible for system security engineering. 5.3.5.02. System Security Engineering and System Engineering Plan.Click here to enter text. Guidance: Describe the linkage between system security engineering and the Systems Engineering Plan. Describe the way in which system security design considerations should be addressed.General Countermeasures.5.3.6.01. Generic Program Countermeasures/Security Activities.Click here to enter text.Guidance: Summarize generic countermeasures or security activities in place that will/do apply to all program information/facilities/personnel and contribute to the protection of CPI and critical functions and components. Table 5.3.6-1 Generic Program Countermeasure/Security Activities (mandated) (sample)Type TypeDetailCOMSEC (Development Environment)Program Office Policy XX-XXX details program COMSEC countermeasures that are implemented at each government facility.OPSECProgram Management Directive XX-XXX, will be tailored to satisfy specific security requirements of individual PROGRAM XYZ activities. The PROGRAM XYZ effort will comply fully with AFI 10-701, Operations Security The 669 AESS OPSEC Plan identifies all PROGRAM XYZ critical information.Foreign Visit ProgramProgram office personnel, other government organizations and contractors will adhere to approved visit procedures for the facility being visited.CPI Protection TrainingThe PM has instituted a tiered training program. Tier 1 is for general training of what CPI is and Tier II is for personnel who actually handle, store, develop and/or maintain CPI. All industry partners who have this PPP, implemented via DD Form 254, DoD Contract Security Classification Specifications, will implement this tier rmation Assurance (Development Environment)Prime Contractor network security architecture and configuration will be managed by the CIO. Network security procedures and countermeasures applicable to subnets containing Government CUI are available upon request. The program will comply with DTM 08-027 “Security of Unclassified DoD Information on Non-DoD Information Systems”.Secure System AdministrationSystem configuration will be managed remotely by the DISA GNSC/TNC administrators.Personnel SecurityThe 669 AESS/SF is responsible for reviewing personnel security procedures at all 669 AESS and PROGRAM XYZ industry locations. This will be coordinated with DSS for industry reviews.Industrial SecuritySecurity protection requirements will be incorporated into all PROGRAM XYZ contracting activities. Government procedures and instructions for preparing DD Forms 254, Contract Security Classification Specifications, will ensure that contractors are provided quality acquisition security, Program Protection, and classification management guidance.Other System Security-Related Plans and Documents.6.01 Other System Security-Related Plans and Documents Table.Click here to enter text. Guidance: Reference relevant acquisition or system security-related documents. Table 6.0-1: Other System Security-Related Plans and Documents (mandated) (sample)PlanOrganizationLink/POCCounterintelligence Support Plan (CISP) Service CI?Test & Evaluation Master Plan TEMP Approval Authority?Systems Engineering Plan SEP Approval Authority?Software Secure Coding Standards Contractor SW Design Lead?Trusted Software Design Techniques Contractor SW Design Lead?Secure Software Process Standards Contractor SW Design Lead?Foreign Travel Training Contractor FSO?Foreign Visit Processes Contractor FSO?6.02 Key Commitments Table.Click here to enter text. Guidance: If Technical Assistance Agreements, Memoranda of Agreement (MOA), Memoranda of Understanding (MOU), or other similar agreements have been signed, reference or link to them in an additional table with a description of the key commitments.Program Protection Risks.7.01. Program Protection Risks Integration.Click here to enter text. Guidance: Describe the way in which Program Protection risks (cost, schedule, technical) will be integrated with overall Program risk management.7.02 Residual Risks and Unmitigated Risks Identification.Click here to enter text. Guidance: Discuss the approach to identifying residual risks of CPI and critical function and component compromise after countermeasure implementation. Identify any unmitigated risks.7.03. Risk Cube and Mitigation Plan for the top Program Protection Risks.Click here to enter text. Guidance: Include a risk cube and mitigation plan for the top Program Protection risks.Foreign Involvement.8.01. Foreign Involvement Summary. Click here to enter text. Guidance: Summarize any international activities and any plans for, or known, foreign cooperative development or sales of the system. Table 8.0-1 Foreign Involvement Summary (mandated) (sample) This system is US ONLY (Yes, No, Unknown): YesThis system is intended for CONUS deployment only (Yes, No, Unknown): No. It is intended for global deployment.Approved Disclosures of CPI: TBDTechnology Assessment/Control Plan Exists (Y/N/Unknown): NoType of ForeignInvolvement(IC/FMS/DCS)Likelihood of Foreign Involvement (H, M, L)Status (Perceived/Established)Agreements/Licenses in Place (if known)Who is involved?ICMPerceivedNonePangaea8.02. Applicable Technology Security and Foreign Disclosure (TS&FD) Processes. Click here to enter text. Guidance: What are the applicable Technology Security and Foreign Disclosure (TS&FD) processes that will provide guidance to safeguard the sharing of program information with allies and friends?8.03. Previous Sales to Foreign Allies. Click here to enter text. Guidance: Have previous generations of this system been sold to foreign allies? Have similar systems been sold?8.04. Addressing of Export Requirements/Restrictions and Responsibilities. Click here to enter text. Guidance: How will export requirements/restrictions be addressed if a foreign customer/sale is identified? Who is responsible for implementing these requirements?Defense Exportability Features.8.1.1. Foreign Military Sales and Direct Commercial Sales Potential Risk to Program.Click here to enter text. Guidance: What are the impacts and risks to the program from foreign military sales and direct commercial sales? Who is responsible for managing these?8.1.2. DEF Candidate Viability.Click here to enter text. Guidance: Will the program be a viable DEF candidate to develop, plan, and design an export variant during the research and development phase?8.1.3. Include a hotlink to the relevant DEF discussion.Click here to enter text. Guidance: Include a hotlink to the relevant DEF discussion in the Technology Development Strategy and/or Acquisition Strategy.Processes for Management and Implementation of PPP.Guidance: There are several types of checking PPP implementation. Audits/inspections are used to ensure compliance with applicable laws, regulations, and policies. Engineering reviews are used to ensure that system security requirements are identified, traceable and met throughout the acquisition lifecycle.Audits/Inspections.Click here to enter text. Guidance: Summarize the timing of security audits/inspections. Describe the way in which contractor security requirements will be enforced. Identify the person or office responsible for contractor security requirements.Engineering/Technical Reviews.9.2.1. Addressing of System Security Requirements.Click here to enter text. Guidance: How will system security requirements be addressed in Systems Engineering Technical Reviews, functional/physical configuration audits, etc? Who is responsible for this?9.2.2. Program Protection Entry/Exit Criteria.Click here to enter text. Guidance: What Program Protection entry/exit criteria will be used for these reviews?Verification and Validation.System security requirements testing integration.Click here to enter text.Guidance: Explain how the program will integrate system security requirements testing into the overall test and evaluation mater plan. Who is responsible for this?Link to relevant discussion in T&E documents.Click here to enter text.Guidance: Link to relevant discussion in T&E documents.Sustainment.Program Protection requirements and considerations in sustainment.Click here to enter text. Guidance: How will Program Protection requirements and considerations be managed in sustainment? Who is responsible for this?Link to the relevant Lifecycle Sustainment Plan (LCSP) language.Click here to enter text. Guidance: Link to the relevant Lifecycle Sustainment Plan (LCSP) language.Processes for Monitoring and Reporting Compromises.CPI Compromise/Supply Chain Exploit Response Plan/procedure.Click here to enter text. Guidance: Summarize the plan/procedure for responding to a CPI compromise or a supply chain exploit.Anti-Tamper Event or Supply Chain exploit Definition.Click here to enter text. Guidance: What constitutes a compromise or exploit? Who is notified if one occurs? Define what constitutes an Anti-Tamper event or a Supply Chain exploit.Program Protection Costs.Click here to enter text. Guidance: Indicate where Program Protection costs are to be accounted for in the SCP and program budget. Who has the responsibility to ensure Program Protection costs are estimated and included in the programs budget and contracts?Security Costs.Security Costs above NISPOM Requirements.Click here to enter text. Guidance: Indicate/Estimate the security costs associated with Program Protection that exceed normal NISPOM costs.Table 11.1-1 Security Costs above NISPOM Requirements (mandated) Cost TypeActivityResponsibilityCost????????????????Total Cost??$$SCIFs or Other Secure Facilities Construction Requirements.Click here to enter text. Guidance: Will SCIFs or other secure facilities require construction specifically for CPI protection?Limited Access Rosters or Other Similar Instruments Cost.Click here to enter text. Guidance: If limited access rosters or other similar instruments will be used, how much will development and maintenance of the roster cost?Acquisition and Systems Engineering Protection Costs.Acquisition and Systems Engineering Protection Costs Table.Click here to enter text. Guidance: Indicate/estimate the design, engineering, development, testing, and other costs related to Program Protection activities (e.g. CPI identification, criticality analysis, vulnerability assessment, countermeasure development, etc.).As costs are identified, summarize in table 11.2-1.Table 11.2-1 Acquisition and Systems Engineering Protection Costs (mandated) (sample) Cost TypeActivityResponsibilityCostEngineeringIncorporate CA, protection design alternative trade studies and system security requirements into RFP scopePM$$CA and design alternative trade studyPrime Contractor$$Anti-tamperPrime Contractor$$Trusted FoundrySupplier$$Supply Chain Risk ManagementEvaluate supplier listsPM, DIA, TAC$$Verification & ValidationSoftware code analysisPM, Gunter AFB$$V&V for anti-tamper architecture AF AT$$Verify satisfaction of system security requirementsPM, verification team$$SustainmentAnti-counterfeit measuresDepot$$Total Cost??$$Non-recurring Program Protection Engineering Costs Accounting.Click here to enter text. Guidance: How will non-recurring engineering costs associated with Program Protection requirements be accounted for?Projected Cost-benefit Tradeoffs Approach in Countermeasure Selection.Click here to enter text. Guidance: Describe the programs approach to using projected cost-benefit tradeoffs in countermeasure selection.Appendix A: Security Classification Guide.Click here to enter text. Guidance: The SCG may be referenced or pointed to rather than included in the document.Appendix B: Counterintelligence Support Plan.Click here to enter text. Guidance: The CISP may be referenced or pointed to rather than included in the document.Appendix C: Criticality Analysis. Guidance: The CA may be referenced or pointed to rather than included in the document (see Criticality Analysis Template in ADDM).Appendix D: Anti-Tamper Plan.Click here to enter text. Guidance:The Anti-Tamper Plan may be referenced or pointed to rather than included in the document (see Anti-Tamper Plan Template in ADDM).Appendix D-1: Anti-Tamper Plan Waiver.Click here to enter text. Guidance: Not all programs will require an Anti-Tamper plan. Appendix E: Acquisition Information Assurance (IA) Strategy. Click here to enter text.Guidance:1. The reuse of existing documentation in preparing the Acquisition IA Strategy document is strongly encouraged where practicable. For example, the integrated schedule in the program's approved Acquisition Strategy may be referenced in the "program information" section. However, it is incumbent on the submitting PMO to ensure that any such information is readily available to the document review/approval chain by providing copies of the referenced documents in conjunction with the Acquisition IA Strategy document. References to draft documents are not sufficient to support approval of the Acquisition IA Strategy document.2. In consideration of the different levels of maturity relative to acquisition phases, and to encourage brevity and focus, the following page limitations are imposed: Acquisition IA Strategies are not required for Material Development Decisions (MDD)Acquisition IA Strategies for Milestone A - 7 pagesAcquisition IA Strategies for Milestone B or C - 15 pagesAcquisition IA Strategies for Full Rate Production (FRP) or Full Deployment Decision (FDD)-15 pagesTables of content, acronym lists, signature sheets and executive summaries are not required, but if included do not count against the page limitations.3. As part of the Acquisition Documentation Streamlining effort, DOASD (I&IA) has reached agreement with DASD(SE) proposal that the Acquisition IA Strategy be included as an appendix to the Program Protection Plan. This does not affect the current review and approval process for the Acquisition IA Strategy document, since only documents that have been approved by the Component CIO and reviewed by the DoD CIO (with a formal review report issued by ODASD(I&IA)/DIAP)) will be appended to the PPP.4. Program offices should utilize the template on the following page in the preparation of their Acquisition IA Strategy documents.5. IA threats must be included in the PPP threat table.I. Program and System Description.A. Program Information (Applicable to MS A, B, C, FRP/FDD)Identify the Acquisition Category (ACAT) of the program. Identify current acquisition life-cycle phase and next milestone decision. Include a graphic representation of the program's schedule.B. System Description (Applicable to MS A, B, C, FRP/FDD)Include or reference a high-level overview of the specific system being acquired. Characterize the system as to type of DoD information system (AIS application, enclave, platform IT interconnection, outsourced IT-based process), or as Platform IT without a GIG interconnection. Include or reference a graphic (block diagram) that shows the major elements/subsystems that make up the system or service being acquired, and how they fit together. Describe or reference the system's function, and summarize significant information exchange requirements and interfaces with other IT or systems, as well as primary databases supported. Identify the primary network(s) to which the system will be connected (e.g. NIPRNET, SIPRNET, JWICS, etc.). Include a description or graphic defining the system's accreditation boundary.II. Information Assurance Requirements.A. Sources (Applicable to MS A, B, C, FRP/FDD)1. Mission Assurance Category and Confidentiality Level Identify the system's MAC and Confidentiality Level as specified in the applicable capabilities document, or as determined by the system User Representative on behalf of the information owner, in accordance with DoD Instruction 8500.2. If the system architecture includes multiple segments with differing MAC and CL combinations, include a table listing all segments and their associated MAC and CL designations, as well as a brief rationale for the segmentation.2. Baseline IA Control SetsIdentify the applicable sets of Baseline IA Controls from DoD Instruction 8500.2 that will be implemented. A listing of individual controls is not required.3. ICD/CDD/CPD specified requirements List any specific IA requirements identified in the approved governing capability documents (e.g. Initial Capabilities Document, Capability Development Document or Capability Production Document).4. Other requirementsList any IA requirements specified by other authority (i.e. Component mandated).B. IA Budget (scope and adequacy) (Applicable to MS A, B, C, FRP/FDD)Describe how IA requirements for the full life cycle of the system (including costs associated with certification and accreditation activities) are included and visible in the overall program budget. Include a statement of the adequacy of the IA budget relative to requirements.III. System IA Approach (high level): (Applicable to MS B, C, FRP/FDD)A. System IA technical approach Describe, at a high level, the IA technical approach that will secure the system.B. Protections provided by external system or infrastructureList any protection to be provided by external systems or infrastructure (i.e. inherited control solutions).IV. Acquisition of IA Capabilities and Support: (Applicable to MS B, C, FRP/FDD)Describe how the program's contracting/procurement approach is structured to ensure each of the following IA requirements are included in system performance and technical specifications, RFPs and contracts (as well as other agreements, such as SLAs, MOAs, etc.) early in the acquisition life cycle.A. System IA capabilities (COTS or developmental contract)B. GFE/GFM (external programs)C. System IA capabilities as services (commercial or government)D. Information Systems Security Engineering (ISSE) servicesE. IA professional support services to the program (commercial or government, including C&A support)Confirm that program contracts/agreements communicate the requirement for personnel performing IA roles to be trained and appropriately certified in IA in accordance with DoD Directive 8570.01.V. System Certification and Accreditation:A. Process (DIACAP; DCID 6/3, etc) (Applicable to MS A, B, C, FRP/FDD) Identify the specific Certification and Accreditation (C&A) process to be employed (e.g., DoD Information Assurance Certification and Accreditation Process (DIACAP), NSA/CSS Information Systems Certification and Accreditation Process (NISCAP), DoD Intelligence Information System (DODIIS)). If the system being acquired is platform IT without a GIG interconnection, describe any Component level process imposed to allocate and validate IA requirements prior to operation. B. Key role assignments (Applicable to MS B, C, FRP/FDD)Include the name, title, and organization of the Designated Accrediting Authority, Certification Authority, and User Representative for each separately accreditable system being acquired by the program.C. C&A timeline (Applicable to MS B, C, FRP/FDD)Include a timeline graphic depicting the target initiation and completion dates for the C&A process, highlighting the issuance of Interim Authorization to Test (IATT), Interim Authorization to Operate (IATO), and Authorizations to Operate (ATOs). Normally, it is expected that an ATO will be issued prior to operational test and evaluation.D. C&A approach (Applicable to MS B, C, FRP/FDD)If the program is pursuing an evolutionary acquisition approach, describe how each increment will be subjected to the certification and accreditation process. If the C&A process has started, identify significant activity completed, and whether an ATO or IATO was issued. If the system being acquired will process, store, or distribute Sensitive Compartmented Information, compliance with Intelligence Community Directive (ICD) 503 "Intelligence Community Information Technology Systems Security Risk Management, Certification and Accreditation" is required, and the plan for compliance should be addressed. Do not include reiterations of the generic descriptions of the C&A process (e.g. general descriptions of the DIACAP activities from DoDI 8510.01 and the DIACAP Knowledge Service).VI. IA Testing:A. Testing Integration (Applicable to MS A, B, C, FRP/FDD)Confirm that all IA testing and C&A activities will be/has been integrated into the program's test and evaluation planning, and incorporated into program testing documentation, such as the Test and Evaluation Master Plan.B. Product Evaluation (e.g. IA/IA enabled products) (Applicable to MS B, C, FRP/FDD)List any planned incorporation of IA products/IA enabled products into the system being acquired, and address any acquisition or testing impacts stemming from compliance with NSTISSP Number 11.C. Cryptographic Certification (Applicable to MS B, C, FRP/FDD)List any planned incorporation of cryptographic items into the system being acquired, and address any acquisition or testing impacts stemming from the associated certification of the items by NSA or NIST prior to connection or incorporation.VII. IA Shortfalls: (Include as classified annex if appropriate) (Applicable to MS B, C, FRP/FDD)A. Significant IA shortfallsIdentify any significant IA shortfalls, and proposed solutions and/or mitigation strategies. Specify the impact of failure to resolve any shortfall in terms of program resources and schedule, inability to achieve threshold performance, and system or warfighter vulnerability. If applicable, identify any Acquisition Decision Memoranda that cite IA issues. If no significant issues apply, state "None ".B. Proposed solutions and/or mitigation strategies If the solution to an identified shortfall lies outside the control of the program office, include a recommendation identifying the organization with the responsibility and authority to address the shortfall.VIII. Policy and Guidance: (Applicable to MS A, B, C, FRP/FDD)List the primary policy guidance employed by the program in preparing and executing the Acquisition IA Strategy, including the DoD 8500 series, and DoD Component, Major Command/Systems Command, or program-specific guidance, as applicable. The Information Assurance Support Environment website provides an actively maintained list of relevant statutory, Federal/DoD regulatory, and DoD guidance that may be applicable. Capsule descriptions of the issuances are not required.IX. Point of Contact: (Applicable to MS A, B, C, FRP/FDD)Include the name and contact information for the program management office individual responsible for the Acquisition IA Strategy document. It is recommended that the system's Information Assurance Manager (as defined in DoD Instruction 8500.2) be the point of contact. ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- 339 dod guidance
- standard practice procedures for security
- defense contracting command washington dcc w
- addendum to dd 254 for tat 08 04 gsa
- iae laws regulations and policies list rev 6 jan 2018
- critical nuclear weapon design information
- program protection plan ppp addm template v3 1
- 1 introduction under secretary of defense for
- program protection plan draft addm template v2 0