13.3 Critical Program Information (CPI) and Mission-Critical Functions and Components

13.3. Critical Program Information (CPI) and Mission-Critical Functions and Components

Critical Program Information (CPI) and mission-critical functions and components are the foundations of Program Protection. They are the technology, components, and information that provide mission-essential capability to our defense acquisition programs, and Program Protection is the process of managing the risks that they will be compromised.

13.3.1. Critical Program Information (CPI)

DoDI 5200.39 defines Critical Program Information (CPI) as “Elements or components of a research, development, and acquisition (RDA) program that, if compromised, could cause significant degradation in mission effectiveness; shorten the expected combat-effective life of the system; reduce technological advantage; significantly alter program direction; or enable an adversary to defeat, counter, copy, or reverse engineer the technology or capability. Includes information about applications, capabilities, processes, and end-items. Includes elements or components critical to a military system or network mission effectiveness. Includes technology that would reduce the US technological advantage if it came under foreign control.”

Metaphorically, CPI should be thought of as the technological “crown jewels” of the program. The United States gains military advantages from maintaining technology leads in key areas, so we must protect them from compromise in the development environment and on fielded systems.

CPI may include classified military information that is considered a national security asset that will be protected and shared with foreign governments only when there is a clearly defined benefit to the United States (see DoD Instruction 5200.39). It may also include Controlled Unclassified Information (CUI), which is official unclassified information that has been determined by designated officials to be exempt from public disclosure, and to which access or distribution limitations have been applied in accordance with national laws and regulations such as the International Traffic in Arms Regulations for U.S. Munitions List items and the Export Administration Regulations for commerce controlled dual-use items. In some cases (dependent on the PM's determination) a commercial-off-the shelf (COTS) technology can be designated CPI if the COTS element is determined to fulfill a critical function within the system and the risk of manipulation needs mitigation.

CPI requires protection to prevent unauthorized or inadvertent disclosure, destruction, transfer, alteration, reverse engineering, or loss (often referred to as "compromise").

CPI identified during research and development or Science and Technology should be safeguarded to sustain or advance the DoD technological lead in the warfighter's battle space or joint operational arena.

The CPI, if compromised, will significantly alter program direction; result in unauthorized or inadvertent disclosure of the program or system capabilities; shorten the combat effective life of the system; or require additional research, development, test, and evaluation resources to counter the impact of its loss.

The theft or misappropriation of U.S. proprietary information or trade secrets, especially to foreign governments and their agents, directly threatens the economic competitiveness of the U.S. economy. Increasingly, foreign governments, through a variety of means, actively target U.S. businesses, academic centers, and scientific developments to obtain critical technologies and thereby provide their own economies with an advantage. Industrial espionage, by both traditionally friendly nations and recognized adversaries, proliferated in the 1990s and has intensified with computer network attacks today.

Information that may be restricted and protected is identified, marked, and controlled in accordance with DoD Directives 5230.24 and 5230.25 or applicable national-level policy and is limited to the following:

CPI determination is done with decision aids and Subject Matter Experts (SMEs). As general guidance, PMs should identify an element or component as CPI if:

• Critical technology components will endure over its lifecycle
• A critical component which supports the warfighter is difficult to replace
• A capability depends on technology that was adjusted/adapted/calibrated during testing and there is no other way to extrapolate usage/function/application
• The component / element was identified as CPI previously and the technology has been improved or has been adapted for a new application
• The component / element contains a unique attribute that provides a clear warfighting advantage (i.e. automation, decreased response time, a force multiplier)
• The component / element involves a unique method, technique, application that cannot be achieved using alternate methods and techniques
• The component / element’s performance depends on a specific production process or procedure
• The component / element affords significant operational savings and/or lower operational risks over prior doctrine, organization, training, materiel, leadership and education, personnel, and facilities (DOTMLPF) methods
• The Technology Protection and/or Systems Engineering (SE) Team recommends that the component/element is identified as CPI
• The component / element will be exported through Foreign Military Sales (FMS)/Direct Commercial Sales (DCS) or International Cooperation

PMs should contact their Component research and development acquisition protection community for assistance in identifying CPI.

13.3.2. Mission-Critical Functions and Components

Mission-critical functions are those functions of the system being acquired that, if corrupted or disabled, would likely lead to mission failure or degradation. Mission-critical components are primarily the elements of the system (hardware, software, and firmware) that implement critical functions. In addition, the system components which implement protections of those inherently critical components, and other components with unmediated access to those inherently critical components, may themselves be mission-critical.

Mission-critical functions and components are equal in importance to Critical Program Information (CPI) with respect to their inclusion in comprehensive program protection, its planning (documented in the Program Protection Plan (PPP)), and its execution, including:

• Trade-space considerations (including cost/benefit analyses)
• Resource allocations (staffing and budget)
• Countermeasures planning and implementation
• Adjustment of countermeasures, as appropriate, for variations in the planned use or environment of inherited critical components
• Summary of consequences if compromised
• Residual risk identification after countermeasures are implemented, including follow-up mitigation plans and actions

Efforts to identify mission-critical functions and components and their protection must begin early in the lifecycle and be revised as system designs evolve and mature.

13.3.2.1. Criticality Analysis (CA)

What is a Criticality Analysis (CA)? CA is the primary method by which mission-critical functions and components are identified and prioritized. It is an end-to-end functional decomposition of the system which involves:

• Identifying and prioritizing system mission threads;
• Decomposing the mission threads into their mission-critical functions; and
• Identifying the system components (hardware, software, and firmware) that implement those functions; i.e., components that are critical to the mission effectiveness of the system or an interfaced network.

Also included are components that defend or have unmediated access to mission-critical components.

The identified functions and components are assigned levels of criticality commensurate with the consequence of their failure on the system’s ability to perform its mission, as shown in Table 13.3.2.1.T1.

Table 13.3.2.1.T1. Protection Failure Criticality Levels

When to perform a CA? The CA is an iterative process. To be effective, many CAs must be executed across the acquisition lifecycle, building on the growing system maturity, knowledge gained from prior CAs, updated risk assessment information, and updated threat and vulnerability data.

At each key decision point, system design changes may result in adding or removing specific items from the list of critical system functions and components. Guidance for the iterative performance of CAs includes:

• Prior to Milestone A: Evaluate mission-threads, identify system functions, and analyze notional system architectures to identify mission-critical functions.
• Prior to Milestone B: Refine the critical function list and identify critical system components and candidate subcomponents (hardware, software, and firmware).
• Prior to CDR: Analyze the detailed design/architecture and update the list to identify all critical system components and subcomponents.

Who performs the CAs? The Government program office should perform an initial CA early in the lifecycle (pre-Milestone A). When contracts are awarded, the DoD contracting office should develop Requests for Proposals (RFPs) that require contractors to perform updated CAs periodically, based on earlier CAs (see Section 13.13.1.2 for guidance on what to include in the Statement of Work (SOW) requirements).

The CA should be led by systems engineers and mission/operator representatives; however, it is a team effort and mission-critical functions and components must be identified by a multi-disciplined group.

How is a CA performed? What is the process? While the Government should perform an initial CA during the Materiel Solution Analysis (MSA) phase, realize that it may only be possible to execute some of the steps in the CA process given below and/or to execute them at a “high level.” As noted previously, to be effective, Criticality Analyses (CAs) must be executed iteratively across the acquisition lifecycle, building on the growing system maturity, knowledge gained from prior CAs, updated risk assessment information, and updated threat and vulnerability data.

For example, the first pass through the CA process, together with assessments of vulnerabilities, threats, risks, and countermeasures, might take just a few days and provide a 30% solution. This CA might only involve Subject Matter Expert (SME) input during several work sessions (to address system and architecture), as opposed to detailed information collected from numerous program documents. For an early iteration, precision is not possible, as it takes several iterations to complete the initial Criticality Analysis (CA).

The detailed procedural steps in performing a CA are:

Important considerations in carrying out the CA process described above include:

• Document the results of each step
  • Include rationale
• Use SE tools to support the analysis; for example:
  • Fault-tree analysis can be useful in determining critical components (see Section 13.7.6 for further details)
  • What information is needed to successfully execute capabilities?
  • How is this information obtained, provided, or accessed by the system?
  • How quickly must information be received to be useful?
  • Does the sequence in which the system initializes itself (power, software load, etc.) have an impact on performance?
  • Example: These may include propulsion (the system has to roll, float, fly, etc.), thermal regulation (keep warm in space, keep cool in other places, etc.), or other environmentally relevant subsystems that must be operational before the system can perform its missions.
• Use available artifacts to inform the CA; for example:
  • SE artifacts such as architectures/designs and requirements traceability matrices
  • Available threat and vulnerability information
  • Residual vulnerability risk assessments to inform follow-up CAs

• In isolating critical functions/components, identify critical conditions/information required to initialize the system to complete mission-critical functions

• Identify the subsystems or components required to support operations in the intended environment

What is the CA output? The expected output of an effective CA process is:

• A complete list of mission-critical functions and components
• Criticality Level assignments for all items in the list
• Rationale for inclusion or exclusion from the list
• Supplier information for each critical component
• Identification of critical elements for inclusion in a Defense Intelligence Agency (DIA) Threat Assessment Center (TAC) Request (See Section 13.4)

The identification of critical functions and components and the assessment of system impact if compromised is documented in the Program Protection Plan (PPP) as discussed in Appendix C (Table C-1) of the PPP Outline.

The prioritization of Level I and Level II components for expending resources and attention will be documented in the PPP as discussed in Appendix C (Table C-2) of the PPP Outline.

Why is the CA performed? The level I and selected level II components from the CA are used as inputs to the threat assessment, vulnerability assessment, risk assessment, and countermeasure selection. The following sections describe these activities.