Critical Function/Component Risk Assessment

The Mission Critical Function and Critical Component (CF/CC) risk assessment is part of supply chain risk management to support achievement of the DoD Trusted Systems and Networks (TSN) Strategy.

Trusted Systems and Networks (TSN) Analysis Definitions

Reference DoDI 5200.44, Protection of Mission Critical Functions to Achieve Trusted Systems & Networks (TSN), for more information

DoD Trusted Systems and Networks (TSN) Strategy
The DoD Trusted Systems and Networks (TSN) Strategy ???integrates robust systems engineering, supply chain risk management (SCRM), security, counterintelligence, intelligence, cybersecurity, hardware and software assurance, and information systems security engineering disciplines to manage risks to system integrity and trust.???

Supply chain risk
Supply chain risk is ???the risk that an adversary may sabotage, maliciously introduce unwanted function, or otherwise subvert the design, integrity, manufacturing, production, distribution, installation, operation, or maintenance of a system so as to surveil, deny, disrupt, or otherwise degrade the function, use, or operation of such system.???

Supply Chain Risk Management (SCRM)
Supply Chain Risk Management (SCRM) is ???a systematic process for managing supply chain risk by identifying susceptibilities, vulnerabilities and threats throughout DoD's ???supply chain??? and developing mitigation strategies to combat those threats whether presented by the supplier, the supplied product and its subcomponents, or the supply chain (e.g., initial production, packaging, handling, storage, transport, mission operation, and disposal).???

Information and Communications Technologies (ICT)
Criticality analysis applies (at the component level) to Information and Communications Technologies (ICT), sometimes referred to as logic-bearing components. ICT ???includes all categories of ubiquitous technology used for the gathering, storing, transmitting, retrieving, or processing of information (e.g., microelectronics, printed circuit boards, computing systems, software, signal processors, mobile telephony, satellite communications, and networks). ICT is not limited to information technology (IT), as defined in section 11101 of title 40, U.S.C. Rather, this term reflects the convergence of IT and communications.???

Primary ICT components of concern: Application-Specific Integrated Circuit (ASIC) and Field-Programmable Gate Array (FPGA) counterfeiting and malware insertion.

ASIC: An??integrated circuit??(IC) customized for a particular use, rather than intended for general-purpose use.
FPGA: An integrated circuit designed to be configured by a customer or a designer after manufacturing.

Criticality Analysis
Criticality Analysis is the process used to identify and prioritize mission critical functions and components via an end???to???end functional decomposition. Mission-critical functions are those functions of the system 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 mission-critical functions. They can include components that perform defensive functions which protect critical components and components that have unmediated access to critical components.

Its purpose is to minimize the risk that DoD's warfighting mission capability will be impaired due to vulnerabilities in system design or sabotage or subversion of a system's mission critical functions or critical components.
Its full definition is ???an end-to-end functional decomposition performed by systems engineers to identify mission critical functions and components. Includes identification of system missions, decomposition into the functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions. Criticality is assessed in terms of the impact of function or component failure on the ability of the component to complete the system mission(s).???

TSN Analysis Methodology Overview

Let's take a moment to look at criticality analysis in the context of the big picture of TSN analysis. TSN analysis consists of:

A criticality analysis to determine the mission-critical functions and critical components of the system.
A threat assessment to understand the potential malicious insertion threats to the program and system.
A vulnerability assessment to recognize vulnerabilities of the architecture, design, development environment, and the components (developmental or commercial-off-the-shelf (COTS) products).
A risk assessment.
Selection of security protection measures (risk mitigations) based on a cost-benefit trade-off analysis.

TSN Analysis Methodology

Risk should be reassessed based upon the selection of system security protection measures to understand the residual risk. This residual risk enables the system security engineer to understand whether sufficient protection measures were selected. Residual risk may also be used to inform future iterations of TSN analysis. Now let's continue to look at criticality analysis.

TSN Risk Analysis Process Overview

Planning - Document Critical Components, Threats, and Criticality Analysis in the Program Protection Plan (PPP)
Identification - Identify Mission Critical Functions and Critical Components (CF/CC)
Criticality Analysis - Assess likelihood and consequence of loss of mission critical function
Mitigation - Apply risk-based countermeasure(s)
Monitoring - Monitor countermeasure effectiveness and changing threats

Planning

The planning for and results of the TSN analysis are captured in the Program Protection Plan (PPP).

The system???s critical components are documented in Section 3.0, Critical Program Information (CPI) and Critical Components.
Threats, vulnerabilities, and countermeasures are captured in Section 5.0.
Appendix C documents the criticality analysis.

Identification

Step 1: Identify and Group Mission Capabilities
The program should identify the mission capabilities that the system will perform. If possible, these mission capabilities should be grouped or ordered by relative importance. For example, training or reporting capabilities may not be considered as important as core mission capabilities. This step should occur first, before Milestone A of the Acquisition Life Cycle, and then be revised as needed for each technical review.

Step 2: Identify Critical Functions/Assign Criticality Levels
Identify the system's mission-critical functions based on mission threads and the likelihood of mission failure if the function is corrupted or disabled. Mission-critical functions may include navigating, targeting, fire control, etc. Assign criticality levels I, II, Ill, or IV (see table below).

Level I Total Mission Failure	Failure that results in total compromise of mission capability.
Level II Significant/Unacceptable Degradation	Failure that results in unacceptable compromise of mission capability or significant mission degradation.
Level III Partial/Acceptable	Failure that results in partial compromise of mission capability or partial mission degradation
Level IV Negligible	Failure that results in little or no compromise of mission capability.

Step 3: Map Critical Functions
Map the mission-critical functions to the system architecture and identify the defined system components that implement those functions.

When identifying configuration items (CI), and sub-Cls (components), remember this only applies to those containing information and communications technologies (ICT).
Logic-bearing components (or ICT) have been singled out as often implementing critical functions and as being susceptible to malicious insertion attacks across the Acquisition Life Cycle.

Identify any Cls or components that do not directly implement critical functions but either have unmediated communications access (i.e., an open access channel) to one or more critical functions or protect a critical function. For example, which components give or receive information to/from the critical components? A non-critical component may communicate with a critical function in a way that exposes the critical function to attack. In some cases, the architecture may need to include defensive functions or other protection measures to protect the critical functions.

Step 4: Assign Criticality Levels to Critical Components
Assign criticality levels to those components that have been defined. When assigning levels of criticality, criteria may include frequency of component use across mission threads, and presence of redundancy. Redundant designs can indicate critical functions.

Step 5: Identify Component Suppliers
Identify suppliers of critical components. Repeat this step as the system architecture is refined or modified, such as at systems engineering technical reviews (SETRs) and major acquisition milestone decision points. Design changes may result in adding or removing specific CI and sub-CIs from the list of critical functions and components.

Criticality Analysis Outcomes

The expected output of an effective criticality analysis 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.
Suppliers of each critical component, and an initial identification of components to be considered for a Defense Intelligence Agency (DIA) Threat Assessment Center (TAC) request (which occurs as part of the threat assessment step in TSN analysis)

The identification of critical functions and components and the assessment of system impact if compromised are documented in the Program Protection Plan (PPP), along with the prioritization of Level I and Level II components. The Level I and selected Level II components from the criticality analysis are used as inputs to the threat assessment, vulnerability assessment, risk assessment, and protection measures selection.

Take note: Depending on the maturity of the system design, the information for each of the specified outcomes may be incomplete or not available. However, programs should strive to identify as much useful information as possible for each of the specified outcomes. As an example, early in the life cycle, there may be a function that can only be implemented by a limited set of components. It may be useful for that limited set of components/ suppliers to be identified even though a final component selection has not been made, as it will enable the assessment of those different options from a system security perspective. For functions/ components which have an abundant amount of suppliers, this wouldn't be as useful.

Criticality Analysis Across the Acquisition Life Cycle

Alternative System Review (ASR)
Identify top-level functions based on the Initial Capabilities Document (ICD), Draft Capability Development Document (CDD) (if available), preliminary system performance specification, and any system models or architectures (including the Concept of Operations (CONOPS)).

System Requirements Review (SRR)
Identify functions from the system performance specification.

System Functional Review (SFR)
Identify lower-level functions based on the functional baseline and current system element definition (typically a preliminary allocated requirements).

Preliminary Design Review (PDR)
Identify components to the assembly-level based on the allocated baseline and preliminary designs of system elements.

Critical Design Review (CDR)
Identify components to the configuration item (CI) or computer software configuration item (CSCI) based on the initial product baseline.

System Verification Review (SVR)/Functional Configuration Audit (FCA)
Identify components to the level of specific parts based on the product baseline.

Countermeasures (CF/CC Risk Assessment/Mitigation)

In summary, to conduct a CF/CC risk assessment, one must identify: the mission; critical functions the system conducts to carry out that mission; the system???s critical components that carry out those functions; logic bearing / critical components supplier risk (threat); component vulnerabilities, exploitability, component and information vulnerabilities; and the system and mission impact of loss of that component/function. Countermeasures are then selected for implementation, preferably in the system design, to mitigate the risks, keeping in mind the trade-off between security and cost/schedule/performance and the three pillars of system survivability ??? Prevent, Detect, and Respond.

Example

Here is a good example of a CF/CC analysis/assessment. Note that for each criticality level in the table, there is a description of the impact to mission capabilities. As engineers, we must think through the critical functions and components that are associated with each mission. Once you have this information, which will be available to us in the contractor???s design documents and the SETRs, we must determine the criticality impact level and document our rationale. After this, we can begin the process of selecting the right countermeasure(s) to mitigate these CF/CC risks.

Level I Total Mission Failure	Failure that results in total compromise of mission capability.
Level II Significant/Unacceptable Degradation	Failure that results in unacceptable compromise of mission capability or significant mission degradation.
Level III Partial/Acceptable	Failure that results in partial compromise of mission capability or partial mission degradation
Level IV Negligible	Failure that results in little or no compromise of mission capability.

Mission	Critical Function	Logic Bearing Component (ASIC/FPGA)	System Criticality Level	Rationale	Countermeasure(s)
Air to Ground Attack	Targeting	Targeting Computer Motherboard ASIC, U25	I	Compromise of the ASIC disables targeting capability.	Purchase U25 from trusted foundry, use secure supply chain.
Air to Ground Attack	Weapon guidance	GPS Computer Motherboard FPGA, IC1116	III	Compromise of the FPGA disables GPS guided weapons. Non-GPS guided weapon capability remains.	None recommended due to lower criticality level.
Air Superiority	Target Detection	Radar Transceiver Processor Core PPC, U125	II	Compromise of the radar PPC requires the pilot to "go visual" and use non-radar queued weapon. Redundant PPC designed in the system.	Purchase redundant PPC from alternate supplier (supplier diversity).

CPI and CF/CC Comparison

Here is a good comparison of CPI and CF/CC. Note that while they are related as aspects of SSE, they each bring a different security protection to the system.

CPI Component Characteristics	Mission Critical Component Characteristics
Related to US advanced technology	Related to information and communications technology (ICT)
Critical to mission effectiveness	Performs or protects system mission critical function, or May introduce vulnerability to system mission critical functions
Principle countermeasure: Anti-Tamper (AT)	Principle countermeasure: Trusted Systems and Networks / Supply Chain Risk Management

Resources

Policy and Guidance

DAU Training Courses

CLE 080: SCRM for Information and Communications Technology (ICT)
ACQ 160: Program Protection Planning Awareness, Module 8
ENG 260: Program Protection for Practitioners, Module 3
CCYB 001: Program Protection Credential