Protecting Critical Program Information: A Program Protection Primer

Some of the most valuable things a defense program produces are not the systems themselves, but the technologies inside them: an algorithm that gives a sensor its edge, a manufacturing process that makes a component possible, or a software capability that adversaries cannot yet match. If those are stolen, reverse-engineered or compromised, the advantage they provide can disappear, sometimes before the system is even fielded.

Program protection is the discipline of preventing that. It is required for Department of War (DoW) acquisition programs and increasingly expected of the contractors who support them.

Key terms

• Critical program information (CPI): U.S. capability elements that contribute to warfighters' technical advantage and that, if compromised, would undermine that advantage. DoD Instruction 5200.39 governs its identification and protection.
• Mission-critical functions and critical components: the functions a system must perform to accomplish its mission, and the components, often logic-bearing hardware, software and firmware, that implement them.
• Program Protection Plan (PPP): the document that captures what needs protection, the threats and vulnerabilities, and the countermeasures selected. DoD Instruction 5000.83 establishes technology and program protection policy for acquisition programs.

The protection process

1. Identify what matters

Work with engineers and the program office to find the technologies and elements that provide the advantage, and the critical components that perform mission-critical functions. Horizontal protection matters: if another program already protects the same technology, protections should be consistent.

2. Understand the threat

Ask who wants the CPI and how they could get it. Pathways include:

• Cyber intrusion into contractor or government networks holding design data
• Supply chain compromise of components, tools or software
• Insider threats among people with legitimate access
• Exploitation of fielded systems that are lost, captured or exported
• Foreign collection through partnerships, visits or publications

Intelligence community threat assessments inform this step.

3. Assess vulnerabilities

Examine the design, the development environment, manufacturing, test and sustainment for weaknesses an adversary could use: unprotected design repositories, single-source components from risky suppliers, debug interfaces left open on fielded hardware.

4. Select countermeasures

Countermeasures typically combine:

• Cybersecurity of the systems that design, build and sustain the program, and of the system itself
• Anti-tamper measures that deter, delay or prevent reverse engineering of fielded systems
• Supply chain risk management, including trusted suppliers, component authenticity and software provenance
• Software assurance, such as secure development, code analysis and vulnerability testing
• Traditional security, including personnel, physical, information and operations security
• Export control and foreign disclosure discipline

5. Document and sustain

The PPP records all of this and is updated at milestones and when the threat or design changes. Protection continues into production and sustainment, when systems are fielded and more exposed.

The contractor's role

Much CPI resides in contractor environments: design files, source code, test data and manufacturing know-how. Contractors support program protection by:

• protecting CPI to the requirements flowed down in contracts, including NIST SP 800-171 for controlled unclassified information
• securing development and engineering environments, not only corporate IT
• managing their own supply chains and subcontractors
• supporting vulnerability assessments and anti-tamper engineering
• reporting incidents and suspicious contacts promptly

Common pitfalls

• Identifying CPI too late, after the design is fixed
• Protecting documents while leaving development environments and build systems exposed
• Treating the PPP as a milestone deliverable rather than a living plan
• Overlooking firmware and software supply chains

An illustrative example

Imagine a program developing a new signal-processing capability for an airborne sensor. The program team identifies the processing algorithm and the firmware that implements it as critical program information: an adversary with them could understand, counter or replicate the sensor's advantage.

The threat assessment highlights three pathways: intrusion into the contractor's engineering network, compromise of a small firmware supplier, and recovery of hardware from a lost aircraft.

Countermeasures follow directly:

• Engineering environment: the algorithm's source code and design data move into a segmented enclave with strict access, multifactor authentication and monitoring, and developers use dedicated workstations.
• Supply chain: the firmware supplier is assessed, contracts flow down security requirements, and builds are signed and verified so tampered code cannot be loaded.
• Anti-tamper: the fielded hardware protects the firmware from extraction, and debug interfaces are disabled in production units.
• Software assurance: the firmware undergoes code review and testing for vulnerabilities an adversary could exploit.

Each measure is documented in the Program Protection Plan, with the threat it addresses. When a new supplier is added two years later, the plan tells the program exactly what to require of it.

Questions program managers should ask

• Have we identified CPI and critical components, and when were they last reviewed?
• Which contractors and subcontractors hold CPI, and what protections do our contracts require of them?
• Are development, build and test environments protected as carefully as the finished system?
• What happens to CPI when a system is exported, lost or retired?
• Does our Program Protection Plan reflect the current design and threat, or the one from the last milestone?

How CDT can help

CDT supports critical program information and program protection with threat-informed vulnerability assessments, secure engineering environments and supply chain analysis, backed by our vulnerability research and reverse engineering and embedded systems protection teams.

Sources

• DoD Instruction 5200.39, Critical Program Information Identification and Protection
• DoD Instruction 5000.83, Technology and Program Protection