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.

image of circuit boards

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.

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:

diagram showing tsn analysis methodology. Flowchart begins with box labeled criticality analysis with arrow pointing to consequence of losing mission capability. Arrow points from losing mission capability to risk assessment. Line two - threat assessment results and volnerability assessment results points to likelihood of losing mission capability which points to risk assessment. Final line shows protection measure options pointing to risk handling decision which is under the risk assessment box. Risk handling decisions box has arrow pointing down to final box labeled risk reassessment.

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

  1. Planning - Document Critical Components, Threats, and Criticality Analysis in the Program Protection Plan (PPP)
  2. Identification - Identify Mission Critical Functions and Critical Components (CF/CC)
  3. Criticality Analysis - Assess likelihood and consequence of loss of mission critical function
  4. Mitigation - Apply risk-based countermeasure(s)
  5. 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).

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.

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:

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.

flowchart showing mission criticality assessment going into consequence of loss and threat assessment/component and info vulnerability assessment going into likelihood of loss. Both of those feed into a risk assessment standard risk matrix with R2 and R1 showing in the far upper right corner of the matrix. Following countermeasures of supply chain risk management/ trusted systems and networks, trusted sources, trusted shipping, bulk spares inventory, multiple suppliers, and blind buys, risks R1 and R2 now appear in the middle and lower portions of the risk matrix.

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

Related Topics

On this page

  1. TSN Analysis Definitions
  2. TSN Analysis Methodology
  3. TSN Risk Analysis Process
  4. CPI and CF/CC Comparison
  5. Resources

Related Topics

Back to top