A clear definition of Systems Security Engineering (SSE), taken from MIL-HDBK-1785 (Section 13.7.6.1)
A discussion of the context of Systems Security Engineering (SSE) within Systems Engineering (SE) as a key sub-discipline, including how security requirements are mapped to the evolving system design, specifications, associated baselines, and Systems Engineering Technical Reviews (SETR) events (Section 13.7.6.2)
An overview of the Systems Security Engineering (SSE) activity considerations by lifecycle phase (Section 13.7.6.3)

The subparagraphs below provide further details.

13.14.1. Systems Security Engineering (SSE) Organization

Systems Security Engineering (SSE) is performed by a variety of professionals. These professionals may have specific expertise in one or more areas (e.g., threat assessment, networking, expertise in one or more security technologies, software assurance, and vulnerability assessment). While serving in the role of the system security engineer, these professionals are responsible for maintaining a comprehensive and holistic system-view while addressing stakeholder security requirements. Systems Security Engineering (SSE) leverages and adapts the principles and practices of Systems Engineering (SE) within the same system life cycle framework that governs Systems Engineering (SE) processes. The “system security engineer” should have a foundational understanding of systems engineering to include the roles and processes for which the systems engineer is responsible.

The program manager should utilize a Working-level Integrated Product Team (WIPT) to perform comprehensive program protection analysis. It is the responsibility of the program manager to ensure that the Working-level Integrated Product Team (WIPT) is comprised of appropriate representatives (including Systems Engineers (SEs), Systems Security Engineering (SSE) Subject Matter Experts (SMEs), logistics, system user representatives, and supporting counterintelligence, intelligence, foreign disclosure, and security personnel) to ensure a comprehensive analysis of system technology, hardware, software, firmware, and information. This Working-level Integrated Product Team (WIPT) or a sub-group (such as a System Security Engineering Working Group (SSEWG)) should focus on engineering aspects of security. They should define and identify all Systems Security Engineering (SSE) aspects of the system, develop an Systems Security Engineering (SSE) architecture, review the implementation of the architecture, and participate in design validation. This sub-Working Integrated Product Team (WIPT)/ System Security Engineering Working Group (SSEWG) should be formed as early in the acquisition process as possible.

13.14.2. Systems Security Engineering (SSE) Process

Systems Security Engineering (SSE) supports the development of programs and design-to specifications providing life-cycle protection for critical defense resources. Systems Security Engineering (SSE) secures the initial investment by "designing-in" necessary countermeasures and "engineering-out" vulnerabilities, and thus results in saving time and resources over the long term. During the system design phase, Systems Security Engineering (SSE) should identify, evaluate, and eliminate (or contain) known or potential system vulnerabilities, spanning the life cycle.

13.14.2.1. Military Handbook 1785

While very dated, MIL-HDBK-1785 contains still-useful information on pertinent Systems Security Engineering (SSE) activities and procedures and for contracting necessary Systems Security Engineering (SSE) efforts, including the practice of generating a System Security Management Plan (SSMP). The format and contents for the System Security Management Plan (SSMP) are outlined in the appropriate Data Item Descriptions listed in MIL-HDBK-1785. Current guidance calls for including most of the System Security Management Plan (SSMP) material in the Systems Engineering Plan (SEP) and the Program Protection Plan (PPP).

13.14.2.2. Systems Security Engineering (SSE) Activities by Phase

Systems Security Engineering (SSE) is the vehicle for interfacing research and technology protection into the Systems Engineering (SE) acquisition process, whereby Systems Engineering (SE) activities prevent exploitation of critical functions and components of U.S. defense systems. The benefit of Systems Security Engineering (SSE) is derived after acquisition is complete by mitigation of threats against the system during deployment, operations, and support. Systems Security Engineering (SSE) also addresses threats during the acquisition process (typically through the supply chain) as well as the possible capture of the system by enemies during combat or hostile actions. Note that Systems Security Engineering (SSE) might be required in localized situations where stakeholder security requirements are addressed in the absence of full implementation of Systems Engineering (SE) activities. This can occur at any stage in the system lifecycle. Key Systems Security Engineering (SSE) criteria can be specified for each of the phases leading up to a major program Milestone, and it is important to establish these criteria across the full lifecycle in order to build security into the system.

13.14.2.2.1. Materiel Solution Analysis (MSA) Phase

During the Milestone A phase, most of the Systems Security Engineering (SSE) related activities, criteria, and results can be mapped to content of the Milestone A Program Protection Plan (PPP), as described in the Program Protection Plan (PPP) Outline. Associated Milestone A engineering analyses and Program Protection Plan (PPP) content include the following:

Include system security in the architectural/design trade-offs and the construction of notional system designs
Leverage available threat and vulnerability understanding in the engineering analysis to identify candidate mission-critical functions and define security requirements
Evaluate concept of operations (CONOPS) and notional system architectures to identify mission-critical functions
- Apply Systems Engineering (SE) tools to Systems Security Engineering (SSE); e.g., protection fault isolation tree methods and system response matrix analysis
Perform an initial Criticality Analysis (CA) based on mission threads and system functions to identify and prioritize a reasonable and thorough list of mission-critical functions for protection
- Identify rationale for inclusion or exclusion of system functions in the list
- Ensure that comprehensive program protection is fulfilled by the identification of critical functions (completeness will comprise critical functions, critical information, and critical technology; indigenous/organic Critical Program Information (CPI) and inherited Critical Program Information (CPI))
Identify candidate countermeasures and sub-countermeasures to be applied to each critical function, with emphasis on logic bearing components
Perform trade-offs of design concepts and potential alternative countermeasures to minimize vulnerabilities, weaknesses, and implementation costs
Examine residual vulnerability rationale for residual risks and plan for threat and vulnerability residual risk assessments after countermeasures have been applied
- Use cost benefit trade-offs and other rationale

The threat analyses and plans/schedule to counter them, as captured in the PPP, should correlate with and point to the discussion provided in Section 2.3 of the Technology Development Strategy (TDS) (see the Technology Development Strategy (TDS)-Acquisition Strategy (AS) Outline).

Other key Systems Security Engineering (SSE) activities during the Milestone A phase, not necessarily captured in specific documents, include:

Ensure that criticality analyses and the development of security requirements extends to multiple systems that support the end-to-end mission threads, including System of Systems (SoS)/Family of Systems (FoS) interdependencies.
For the trade-off analysis that considers implementation of critical functions via software, include an evaluation of Software Assurance countermeasures that uses:
- Common Vulnerabilities and Exposures (CVE) – To identify vulnerabilities that enable various types of attacks.
- Common Attack Pattern Enumeration and Classification (CAPEC) – To analyze development and operational environments, and potential interfaces, for common destructive attack patterns.
- Common Weakness Enumeration (CWE) – To examine software architectures and notional designs for weaknesses.
Ensure that the preferred system concept(s) includes preliminary level security requirements derived from risk assessment and mitigation for critical functions. These requirements will typically be reflected in the preliminary System Requirements Document (SRD), if one exists. (See below for other expected System Requirements Document (SRD) content.)
Ensure that candidate Critical Program Information (CPI) and potential critical components associated with mission-critical functions are mature enough to adequately address security; i.e., those that are potential Critical Technology Elements (CTE) (being matured to a Technology Readiness Level (TRL) of 4 by Milestone A) include validation of expected security in a laboratory environment.
Consider Systems Security Engineering (SSE) in planning for technology maturation during the Technology Development (TD) phase, including:
- Mitigation of candidate critical function risks, including countermeasures and candidate sub-countermeasures.
- Inclusion of candidate critical functions in competitive prototyping plans for critical components.
- Inclusion of threats in the definition of “relevant environment” for a Technology Readiness Level (TRL) of 6.
Incorporate trade study results into the developing system requirements and the Request for Proposal (RFP) Statement of Work for the Technology Development (TD) phase (See Section 13.13.1 for other expected Request for Proposal (RFP) and Statement of Work content).

Other documents generated during the Milestone A phase should also contain Systems Security Engineering (SSE) relevant content. A thorough discussion of the Systems Engineering Plan (SEP) is given in Chapter 4. Expected Systems Security Engineering (SSE) content in the Systems Engineering Plan (SEP) can be highlighted as follows:

Description of Systems Security Engineering (SSE) within the overall Systems Engineering (SE) approach, including processes to be used by the Government and contractors.
Identification of system level security requirements generation as part of the System Requirements process.
Technical Risk Plan includes a summary of the mission-critical functions with risks, candidate countermeasures and sub-countermeasures, and residual risk (or a reference to the Program Protection Plan (PPP) if included there).
Each identified Systems Engineering Technical Review (SETR) event includes Systems Security Engineering (SSE) criteria (see Section 13.10.2 for amplification).

The Test and Evaluation Strategy (TES) provides an overall system Verification and Validation (V&V) strategy; and, pertinent details for ensuring system security are further discussed in Section 13.10.3. Expected Systems Security Engineering (SSE) content in the Test and Evaluation Strategy (TES) is highlighted as follows:

Prototype/risk reduction testing that involves candidate critical functions and components and/or material countermeasures: In Part I (Introduction), Part II (Program Management and schedule), and Part III (Test and Evaluation Strategy (TES)).
Long-lead post Milestone-B special-item resources, such as test range facilities and tools, for security requirements testing: In Part IV (Resource Summary).

Security requirements are first baselined in the System Requirements Document (SRD); related Systems Security Engineering (SSE) criteria and requirements are flowed down to contractor(s) via a solid Statement of Work and Request for Proposal (RFP) – as follows:

Expected Systems Security Engineering (SSE) content in the Request for Proposal (RFP) for the Technology Development (TD) phase (if available):
- Request for Proposal (RFP) Section C:
  - Detailed Statement of Work requirements (see below).
  - System Requirements Document (SRD) is included (see below for level of detail expected).
- Request for Proposal (RFP) Section L: Request a lifecycle description of the Systems Security Engineering (SSE) and Program Protection (PP) processes with how they integrate into the overall Systems Engineering (SE) process.
- Request for Proposal (RFP) Section M: Evaluate proposed disciplined, structured Systems Security Engineering (SSE) and Program Protection (PP) processes, including Criticality Analyses (CA(s)) to inform the system specification and design, which mitigates threats and vulnerabilities to system/mission effectiveness.
The Technology Development (TD) phase will involve prototyping efforts and system design trade-off considerations for risk reduction. Ensure that the Statement of Work requires the following level of Systems Security Engineering (SSE) activities from contractor(s) engaged in these activities:
- Use and maintain current Critical Program Information (CPI) and critical function and component threat assessments (current within 2 years).
- Update the Criticality Analysis (CA) to identify critical functions and components, with rationale, and to allocate countermeasures and sub-countermeasures to the system design, the allocated baseline, and to follow-on development efforts (e.g., the product baseline).
- Flow down the Systems Security Engineering (SSE) requirements from the System Requirements Document (SRD) to the System Specification, with verification criteria for risk reduction efforts.
- Refine the allocation of countermeasures and sub-countermeasures to system critical components (features included in system design) as well as lifecycle phases (processes used to develop the system).
- Include detailed Systems Security Engineering (SSE) criteria for Systems Engineering Technical Reviews (SETRs), which should be reflected in their System Engineering Management Plan (SEMP).
  - Include coverage of Criticality Analysis (CA) results and supply chain risk information (see Section 13.10.2 for further details).
- Include security requirements and critical function/component artifacts within their Systems Engineering (SE) and design Contract Data Requirements Lists (CDRLs).
- Protection of all critical function and Critical Program Information (CPI)-related prototyping and preliminary design work during technology maturation efforts.
- Demonstrate visibility into the supply chain for hardware and software elements to be used during the technology maturation efforts. Allow Government oversight reviewers to inspect results of Systems Security Engineering (SSE) processes (including countermeasures and Systems Security Engineering (SSE) activities) upon request.
If an System Requirements Document (SRD) is available, the following Systems Security Engineering (SSE) considerations apply:
- System Requirements Document (SRD) contains security requirements derived from:

13.14.2.2.2. Technology Development (TD) Phase

During the Technology Development (TD) phase, most of the Systems Security Engineering (SSE) related activities, criteria, and results can be mapped to content of the Milestone-B Program Protection Plan (PPP), as described in the Program Protection Plan (PPP) Outline. Associated Technology Development (TD) engineering analyses and Program Protection Plan (PPP) content include the material covered in Section 13.7.6, as well as the following:

Perform an updated Criticality Analysis (CA), based on the previous Criticality Analysis (CA) results and current (within 2 years) threat and vulnerability data, in order to refine the mission-critical function list and identify critical components and potential subcomponents (hardware, software, and firmware)
- Performed by the Government and/or contractor(s)
- Employ Systems Security Engineering (SSE) protection fault isolation tree analysis and examine system response matrix for protection of Preliminary Design Review (PDR) level design
- Use security scenarios in the operational Concept of Operations (CONOPS)
- Identify logic bearing elements and failure effects for impact in order to assign criticality failure levels
- Assign levels of criticality in order to prioritize critical functions and components for further analysis, focusing on Level I (Catastrophic) and Level II (Critical)
- Identify rationale for inclusion or exclusion of critical functions and components in the list
- Ensure that comprehensive program protection is fulfilled by the identification of critical components (completeness will comprise critical functions and components, critical information, and critical technology; indigenous/organic Critical Program Information (CPI) and inherited Critical Program Information (CPI))
Identify program protection required to the level of specific countermeasures and sub-countermeasures, with plans for using mature technology
Ensure that prototyping efforts and system design trade-off considerations for risk reduction focus on minimizing the attack surface and system security risks, and on employing affordable, risk-based countermeasures
Use allocation to the Work Breakdown Structure (WBS) in order to refine the list of countermeasures and sub-countermeasures to be applied to each critical function and component
Examine residual vulnerability rationale for residual risks and plan for threat and vulnerability residual risk assessments after sub-countermeasures have been applied
- Use cost benefit trade-offs and other rationale
Include provisions for evaluations of threats and countermeasure effectiveness at each level of design

The threat analyses and plans/schedule to counter them, as captured in the Program Protection Plan (PPP), should correlate with and point to the discussion provided in paragraph 2.3 of the Acquisition Strategy (AS) (see the Technology Development Strategy (TDS)-Acquisition Strategy (AS) Outline).

Other key Systems Security Engineering (SSE) activities during the Technology Development (TD) phase, not necessarily captured in specific documents, include:

Monitor contractor performance against the Systems Security Engineering (SSE) criteria for the Technology Development (TD) Statement of Work that were enumerated in Section 13.7.6.1
Analyze intra- and inter-system dependencies and plan for corresponding mitigation of exploitable vulnerabilities that could compromise mission-critical system components
Ensure that criticality analyses and the development and implementation of security requirements extends to multiple systems that support the end-to-end mission threads, including System of Systems (SoS)/Family of Systems (FoS) interdependencies
For software prototyping and design trade analyses, include an updated evaluation of Software Assurance countermeasures that uses Common Vulnerabilities and Exposures (CVE), Common Attack Pattern Enumeration and Classification (CAPEC), and Common Weakness Enumeration (CWE)
Ensure that Critical Program Information (CPI) and critical components are mature enough to fulfill related security requirements; i.e., those that are Critical Technology Elements (CTEs) (being matured to an assessed Technology Readiness Level (TRL) of 6 by Milestone B) demonstrate all required security in a “relevant environment”
Consider Systems Security Engineering (SSE) in planning for the Engineering and Manufacturing Development (EMD) phase, including:
- Inclusion of updated threats and vulnerabilities in the definition of “operational environment” for a Technology Readiness Level (TRL) of 7

Other documents generated during the Technology Development (TD) phase should also contain Systems Security Engineering (SSE) relevant content. For example, Systems Security Engineering (SSE) tasks to implement requirements should be included in the Integrated Master Plan (IMP) and Integrated Master Schedule (IMS), including security verification tied to the Test and Evaluation Management Plan (TEMP).

A thorough discussion of the Systems Engineering Plan (SEP), updated for Milestone B, is given in Chapter 4. Expected Systems Security Engineering (SSE) content in the updated Systems Engineering Plan (SEP) can be highlighted as follows:

Updated description of Systems Security Engineering (SSE) within the overall Systems Engineering (SE) approach, including processes used by the Government and contractors, as well as Technology Development (TD) phase Systems Security Engineering (SSE) accomplishments and guidance for Engineering and Manufacturing Development (EMD)
Refinement and allocation of system level security requirements as part of the System Requirements process
Technical baseline management for system security requirements at the System Requirements Document (SRD) and System Specification level by the Government and lower level specifications by the contractor(s)
Technical Risk Plan includes a summary of the mission-critical components with risks, countermeasures and candidate sub-countermeasures, and residual risk (or a reference to Program Protection Plan (PPP))
Comprehensive end-to-end test approach for system security
Each identified Systems Engineering Technical Reviews (SETR) event includes Systems Security Engineering (SSE) criteria (see Section 13.7.6 for amplification)

The Test and Evaluation Master Plan (TEMP) provides an integrated system plan for Verification and Validation (V&V); and, pertinent details for ensuring system security are further discussed in Section 13.10.3. It should be noted, however, that the Test and Evaluation (T&E) associated with critical components and their testable sub-countermeasures will likely not be a part of a program’s Test and Evaluation Management Plan (TEMP). A large portion of security Test and Evaluation (T&E) will be planned for and conducted by the contractor as part of the contract’s Statement of Work. That said, expected Systems Security Engineering (SSE) content in the Test and Evaluation Management Plan (TEMP) is highlighted as follows:

System security Developmental Testing (DT)
- Key system security critical technical parameters (CTPs)
- Verify system level security requirements as documented in the Requirements Verification Traceability Matrix (RVTM)
System security Operational Testing (OT)
- Include system security as a Measure of Suitability (MOS)
Specific system security resources
- Developmental Testing (DT)/Operational Testing (OT) test articles with sub-countermeasures
- Test sites, instrumentation, and support equipment

Security requirements and related system functions are baselined in the Government System Requirements Document (SRD) and the contractor’s System Specification. Related Systems Security Engineering (SSE) criteria and requirements are flowed down to contractors via a solid Statement of Work and Request for Proposal (RFP) – as follows:

Expected Systems Security Engineering (SSE) content in the Request for Proposal (RFP) for the Engineering and Manufacturing Development (EMD) phase:
- Request for Proposal (RFP) Section C:
  - detailed Statement of Work requirements (see below)
  - final System Requirements Document (SRD) is included (see below for level of detail expected)
- Request for Proposal (RFP) Section L: Request a lifecycle description of the Systems Security Engineering (SSE) and Program Protection (PP) processes with how they integrate into the overall Systems Engineering (SE) process. Provide specific security scenario(s) for bidders to describe their proposed system response
- Request for Proposal (RFP) Section M: Evaluate proposed disciplined, structured Systems Security Engineering (SSE) and Program Protection (PP) processes, including Criticality Analysis (CA), in system specification, detailed design, build/code, and test, with emphasis on countermeasure and sub-countermeasure implementation
The Engineering and Manufacturing Development (EMD) phase Statement of Work should require the following level of Systems Security Engineering (SSE) activities from contractor(s):
- Update the Criticality Analysis (CA) to refine the identification of critical functions and components, with rationale
- Work with appropriate agencies (e.g., Defense Intelligence Agency (DIA) and National Security Agency (NSA)) to maintain Critical Program Information (CPI) and critical function and component threat assessments (current within 2 years)
- Allocate sub-countermeasures to critical components and subcomponents (i.e., system detailed design and the product baseline) as well as to lifecycle phases for the processes used to develop the system.
- For Software Assurance evaluations, use:
  - Common Vulnerabilities and Exposures (CVE) – To identify vulnerabilities that enable various types of attacks
  - Common Attack Pattern Enumeration and Classification (CAPEC) – To analyze environments, code, and interfaces for common destructive attack patterns
  - Common Weakness Enumeration (CWE)– To examine software architectures, designs, and source code for weaknesses
- Flow down the Systems Security Engineering (SSE) requirements from the System Requirements Document (SRD) to the System Specification and to lower-level specifications, with verification criteria for risk reduction efforts
  - Include detailed allocation of sub-countermeasures to lower-level specifications
- Include detailed Systems Security Engineering (SSE) criteria for Systems Engineering Technical Reviews (SETRs), which should be reflected in the contractor Systems Engineering Management Plan (SEMP)
  - Include coverage of Criticality Analysis (CA) results and supply chain risk information (see Section 13.10.2 for further details)
- Include security requirements and critical function/component artifacts within contractor Systems Engineering (SE) and design Contract Data Requirements Lists (CDRLs)
- Demonstrate visibility into the supply chain for critical components and subcomponents. Allow Government oversight reviewers to inspect results of Systems Security Engineering (SSE) processes (countermeasures, sub- countermeasures, and activities) upon request
Expected Systems Security Engineering (SSE) content in the System Requirements Document (SRD) and/or preliminary System Specification:
- Specific security requirements to protect Critical Program Information (CPI) and critical functions and components, based on:
  - Operational performance requirements needing protection
  - Threats and vulnerabilities identified via system-specific assessments as well as those contained in the Capability Development Document
  - Use cases (including common-attack countermeasures) that are comprehensive and traceable to the Concept of Operations (CONOPS)
- Each security requirement in the verification matrix should be traceable from Joint Capabilities Integration Development System (JCIDS) requirements (Initial Capabilities Document (ICD) and Capability Development Document (CDD)) to countermeasures and sub-countermeasures allocated to system requirements, and adjusted for associated cost, risk, and schedule
- Identification of specific countermeasures and sub-countermeasures requirements. For example, for Software Assurance countermeasures to be applied to a specific component, the identification of sub-countermeasures, such as:
  - Static code analysis (for development process application)
  - Secure exception handling (for built-in component security)
  - Sandboxing (for operational threat mitigation)
- All identified Critical Program Information (CPI) and critical functions and components have specified countermeasure and sub-countermeasure requirements documented in the contractor’s “Spec Tree,” with justification of accepted risk

The contractor’s preliminary Subsystem and Component Specifications should:

Contain derived system protection requirements that are comprehensive, verifiable, and traced from the System Requirements Document (SRD)
Provide security and protection verification matrices that are traced and properly allocated from the System Requirements Document (SRD) so that system level protection requirements can be validated
Reflect the trade-off analysis of the Preliminary Design Review (PDR) with respect to Criticality Analysis (CA), mission-critical functions and components, countermeasures and sub-countermeasures, updated vulnerability assessment, and allocation of sub-countermeasures to design and verification

13.14.2.2.3. Engineering and Manufacturing Development (EMD) Phase

During the Engineering and Manufacturing Development (EMD) phase, most of the Systems Security Engineering (SSE) related activities, criteria, and results can be mapped to content of the Milestone-C Program Protection Plan (PPP), as described in the Program Protection Plan (PPP) Outline. Associated Engineering and Manufacturing Development (EMD) engineering analyses and Program Protection Plan (PPP) content include the material covered in Section 13.7.6, as well as the following:

Perform an updated Criticality Analysis (CA), based on the previous Criticality Analysis (CA) results and current (within 2 years) threat and vulnerability data, in order to refine the list of critical components and subcomponents (hardware, software, and firmware) for comprehensive protection
- Verify threat and vulnerability assessments are current against the product baseline and system operational concept
- Identify rationale for inclusion or exclusion of system components and subcomponents in the list
Update the threat and residual vulnerability risk assessment(s), consistent with the updated Criticality Analysis (CA) summary and rationale
- Ensure that threat and vulnerability residual risk assessment after sub-countermeasures are applied have been tracked and mitigated
Update the software evaluations using Common Weakness Enumeration (CWE), Common Vulnerabilities and Exposures (CVE), and Common Attack Pattern Enumeration and Classification (CAPEC)
Update the identification of countermeasures and sub-countermeasures to be applied to specific critical functions and components
Ensure, prior to Milestone C, that all Critical Program Information (CPI) and mission-critical functions and components are identified, together with all associated Systems Security Engineering (SSE) countermeasures and sub-countermeasures applied to them
Assess Critical Program Information (CPI) and critical function/component countermeasures and sub-countermeasures for production, deployment, operations, and sustainment
- Ensure countermeasures and sub-countermeasures have been integrated into the product baseline, production planning, and system operational concept
- Ensure completeness, comprising critical functions/components/subcomponents, critical information, and critical technology, Indigenous/Organic Critical Program Information (CPI) and Inherited Critical Program Information (CPI)
Apply residual vulnerability risk assessment after sub-countermeasures applied
Examine verification results (Developmental Test and Evaluation (DT&E) and Operational Test and Evaluation (OT&E)) for security requirements
Ensure that Systems Security Engineering (SSE) requirements flow down to detailed design elements with verification criteria:
- Allocate sub-countermeasures to counterintelligence (CI) Specifications (detailed design) and to verification criteria in the Statement of Work
- Update the Systems Security Engineering (SSE) protection fault isolation tree and system response matrix
- Ensure flow down of key Systems Security Engineering (SSE) requirements to appropriate Systems Engineering Technical Reviews (SETR) criteria (Critical Design Review (CDR), Test Readiness Review (TRR), and System Verification Review (SVR)) (see Section 13.10.2 for amplification)

Other key Systems Security Engineering (SSE) activities during the Engineering and Manufacturing Development (EMD) phase include:

Monitor contractor performance against the Systems Security Engineering (SSE) criteria for the Engineering and Manufacturing Development (EMD) Statement of Work that were enumerated in Section 13.13.1.2
Ensure that criticality analyses and the implementation and testing of security requirements extends to multiple systems that support the end-to-end mission threads, including System of Systems (SoS)/Family of Systems (FoS) interdependencies
Update the residual risk assessment after sub-countermeasures have been applied, examine residual vulnerabilities for prioritized risks, and apply mitigations and plans that will ensure system security through deployment and operations
Ensure that system security is properly reflected in the product baseline and in production planning for Low rate initial production (LRIP) and beyond
- Systems Security Engineering (SSE) requirements flow down to the product baseline, with application of sub-countermeasures to subcomponents verified and validated
- Ensure that the Lifecycle Sustainment Plan includes periodic assessment of threats, vulnerabilities, and maintenance of countermeasures and sub-countermeasures
- Ensure that the sustainment strategy contains sustainment related contracts to ensure secure supply chain acquisitions – correlated with paragraph 7.4.3.6 of the AS (see the Technology Development Strategy (TDS)-Acquisition Strategy (AS) Outline)
- Ensure that all security-related logic bearing subcomponents have viable contractors
Specify the impact upon program cost due to program protection and exportability features associated with the potential/plans for Foreign Military Sale – correlated with paragraph 10.3 of the AS (see the Technology Development Strategy (TDS)-Acquisition Strategy (AS) Outline)
Ensure that Critical Program Information (CPI) and critical components and subcomponents are matured to fulfill related security requirements; i.e., those that are Critical Technology Elements (CTEs) (being matured to an assessed Technology Readiness Level (TRL) of 7 by Milestone C) demonstrate all required security in an “operational environment”
- Verify manufacturability of needed sub-countermeasures
Ensure verification of system protection functional requirements:
- Systems Security Engineering (SSE) functional requirements flow down to detailed design elements and are verified against valid criteria and verification methods
- Countermeasures and sub-countermeasures are analyzed and tested throughout the detailed design and testing/verification phases
- Physical and operational countermeasures and sub-countermeasures are included in system operational instructions and training documentation
- Configuration management system is used to track vulnerability risks and mitigation via design changes
- Performance of sub-countermeasures is verified against attacks
- Updated test plans and procedures reflect additional verification requirements and stress attack scenarios
Ensure that Systems Security Engineering (SSE) tasks to implement requirements are updated in the Integrated Master Plan (IMP) and Integrated Master Schedule (IMS)

Other relevant Engineering and Manufacturing Development (EMD) documents include the contractor’s Test Plans. Expected Systems Security Engineering (SSE) content includes:

Test Plan activities are traced from the System Requirements Document (SRD) to system, subsystem, and lower-level component requirements, to verification testing needs
Ensure that all Systems Security Engineering (SSE) testing requirements from system, subsystem, component, and subcomponent level documentation are included in the verification matrix according to agreed verification objectives
Clear pass-fail criteria are identified for all tests as they apply to system security and protection
Test processes and facilities, test equipment, Modeling and Simulation (M&S), and the software environment are adequately planned to validate protection countermeasure requirements
Systems Security Engineering (SSE)-specific needs for personnel and schedule are considered and adequately addressed
Test plans reflect the Test and Evaluation Management Plan (TEMP)
Testing includes attack stress use cases
Security and protection validation testing may require outside accreditation authorities, and appropriate schedule is allocated in the Test Plans

13.14.3. Security Engineering for International Programs

System Security Engineering should include an assessment of security criteria that sets limits for international cooperative programs, direct commercial sales, and/or foreign military sales cases. From this assessment, engineering and software alternatives (e.g., dial-down functionality, export variants, anti-tamper provisions, etc.) should be identified that would permit such transactions.

13.15. Program Protection Plan (PPP) Review/Approval

Program Protection Plan (PPPs) must be approved by the Milestone Decision Authority at Milestones A, B, C, and the Full-Rate Production decision (or business system equivalent). A final draft Program Protection Plan (PPP) must be submitted for the Pre-Engineering and Manufacturing Development (EMD) review prior to Milestone B. This guidance summarizes the approval process that Undersecretary of Defense for Acquisition, Technology, and Logistics (USD(AT&L)) and DoD Chief Information Officer (CIO) jointly developed for programs under their cognizance. Programs under Component, Program Executive Office (PEO), or other oversight should consult their Milestone Decision Authority (MDA) for applicable approval guidance.

The Program Protection Plan (PPP) Review and Approval Process should be initiated approximately 180 days prior to the program’s Defense Acquisition Board (DAB) to allow sufficient time for the comprehensive Office of the Secretary of Defense (OSD) review. The review process iterates as the program responds to Office of the Secretary of Defense (OSD) comments and resubmits the Program Protection Plan (PPP) for approval. Once all comments are resolved, the Program Protection Plan (PPP) will be coordinated and routed to the Milestone Decision Authority (MDA) for approval.

13.15.1. Review Process

When a Program Protection Plan (PPP) is ready for Office of the Secretary of Defense (OSD) review, the program will send the document to Deputy Assistant Secretary of Defense (Systems Engineering) (DASD (SE)) Major Program Support (MPS) Program Support Team Lead (PSTL) and Action Officer (AO). The Program Protection Plan (PPP) will be reviewed by SME’s across Office of the Secretary of Defense (OSD) to validate that the Program Protection Plan (PPP) sufficiently addresses all aspects of program protection planning and implementation. If comments are generated, consolidated comments from this comprehensive review are returned to the program for adjudication and resubmission for approval.

An important lesson learned is the program should act early to engage the Component Anti-Tamper community and address any concerns, as Anti-Tamper (AT) Plan approval is commonly a holdup for overall Program Protection Plan (PPP) approval. Additionally, Program Managers (PMs) may delay receiving Program Executive Office (PEO) or Service Acquisition Executive (SAE) signatures on Program Protection Plans (PPPs) prior to initial Office of the Secretary of Defense (OSD) reviews, as many initial reviews generate comments requiring rework that may need to be re-approved at those levels.

13.15.1.1. Program-Level View of Program Protection Plan (PPP) Review Process

The program sends the draft Program Protection Plan (PPP) to its Program Support Team Lead (PSTL) and Action Officer (AO). Approximately three weeks later, the program will receive a comments matrix from the Program Support Team Lead (PSTL)/ Action Officer (AO) with comments the program needs to address. After addressing the comments, the program will submit an updated Program Protection Plan (PPP) with the adjudicated comments matrix to the Program Support Team Lead (PSTL) and Action Officer (AO). Once all comments have been addressed, the Program Protection Plan (PPP) Review Team will coordinate and staff the Program Protection Plan (PPP) for a Milestone Decision Authority (MDA) signature. Once it is signed, the approved Program Protection Plan (PPP) will be sent back to the program.

13.15.2. Reviewing Organizations

Deputy Assistant Secretary of Defense (Systems Engineering) (DASD (SE)) from a systems engineering perspective
DoD Anti-Tamper Executive Agent (ATEA) from an Anti-Tamper (AT) perspective
DoD Chief Information Officer (CIO) from an Information Assurance and supply chain perspective
Acquisition, Technology, and Logistics (AT&L) Industrial Policy from a supply chain perspective
Under Secretary of Defense (Intelligence) from security and counterintelligence perspective
Acquisition, Technology, and Logistics (AT&L) International Negotiations from an international cooperation perspective

13.15.3. Approval Process

13.15.3.1. Coordination

Once all Office of the Secretary of Defense (OSD) comments are adjudicated, the Program Protection Plan (PPP) is then sent out for Principal-level coordination across Office of the Secretary of Defense (OSD). The following organizations submit Principal-level coordination:

DoD Anti-Tamper Executive Agent (ATEA)
DoD Chief Information Officer (CIO)
Acquisition, Technology, and Logistics (AT&L) Industrial Policy
Acquisition, Technology, and Logistics (AT&L) International Negotiations
Acquisition, Technology, and Logistics (AT&L) Acquisition Resources & Analysis
Acquisition, Technology, and Logistics (AT&L) Strategic & Tactical Systems
Office of the General Counsel

Once coordination is complete, the Program Protection Plan (PPP) is routed to the Milestone Decision Authority (MDA) for signature.

13.15.3.2. Approval Authority

The approval authority for Program Protection Plans (PPPs) is the Milestone Decision Authority (MDA). The Milestone Decision Authority (MDA) for Acquisition Category (ACAT) ID, special interest, and non-delegated Acquisition Category (ACAT) IAM programs, is Undersecretary of Defense for Acquisition, Technology, and Logistics (USD(AT&L)). The DoD Chief Information Officer (CIO) is the Milestone Decision Authority (MDA) for all other IAM programs . For Acquisition Category (ACAT) IC’s and below, the Program Protection Plan (PPP) does not need to be reviewed at the Office of the Secretary of Defense (OSD) level.

13.16. Program Protection Plan (PPP) Classification Guidance

The Program Protection Plan (PPP) should be classified by content. There is no overarching Security Classification Guide for DoD Program Protection – original classification authority for Critical Program Information (CPI), mission-critical functions and components, threats and vulnerabilities to those items, and protections of those items remain the responsibilities o their respective owners. Program Protection Plans (PPPs) are frequently developed with unclassified bodies and classified appendices as necessary.

Top of page

Previous and Next Page arrows