IPC-1792 focuses on the following two minimum goals:

1. Rapidly notify supply chain customers of cybersecurity incidents affecting them, even in the event of an unknown attack
2. If the attack is an unknown one, having a framework to detect it quickly and notify critical supply chain stakeholders (and eventually all stakeholders in the supply chain)

The following explains the latter internal mechanism for prompt notification with specific examples.

The internal mechanism for prompt notification consists of two preparations:

1. Early detection of even unknown attacks
2. Rapid decision-making

Figure: Internal Mechanism for Quick Notification

Recommendations for Intrusion Assumption Security Measures

A perimeter approach for blocking outside intrusions may not be able to respond to unknown attacks, so this example will consider countermeasures based on the zero-trust approach from NIST SP-800 207.

Specifically, as shown in the following illustration, the network will be divided based on the data units (resources) that could be affected by an attack. Each segment should include monitoring mechanisms in addition to standard defense functions.

Figure: Early Detection Even in the Case of an Unknown Attack

Example of Separation of Areas

The extent of domain separation should reflect the potential impact range of a single incident.

As shown in the following illustration, while the scope of impact in a BCP for natural disaster response is hardware-based, the scope of impact of a cybersecurity attack is software-based and requires detailed design. In the assembly plant example shown in the illustration, the area is divided into smaller sections to prevent the assembly line of a specific product from affecting other products. Critical data units (resources) that impact all products are placed independently to ensure robust protection and enhanced monitoring.

Figure: Smaller Separate Parcels Can Minimize the Area of Impact

Two types of preparation are described in IPC-1792

IPC-1792 identifies two distinct but related types of preparation:  

a) Advance preparation for business continuity in consideration of possible risks

1. Minimize impact: categorize resources by business impact, segmentation, dynamic protection, and monitoring mechanisms

2. Expedite recovery: periodical monitoring operation, backup operations, training on 
   periodical monitoring operation, backup operation

3. In this case, there is a "likelihood of occurrence" factor

This is explained in Section 3 of IPC-1792.

b) Advance preparation for immediate assessment of realized risks (CIQA)

1. Preparation in advance of the decision-making process: process kicking condition, rule of escalation, impact volume definition, notification address process kicking condition, rule of escalation, impact volume definition, notification address

2. In this case, the "likelihood of occurrence" factor is not considered because it assumes that the incident has already occurred. However, CIQA must consider the factor of "frequency of occurrence."

This is explained in Section 1 of IPC-1792.

Procedure Example 1: Advance Preparation for Business Continuity Considering Possible Risks

Identification of the scope of impact

To properly analyze the impact of an incident, it is essential to have a comprehensive understanding of the production system—including the configuration and operation of facilities and networks. Security expertise alone is insufficient; a comprehensive understanding of the system is required.

The following information should be organized in advance to support impact identification:

1. Asset List

• Include hardware (PCs, servers, network equipment), peripherals (storage media), and software.
• For software, also track related items such as installation media, license certificates, and maintenance or service agreements.
• Properly identifying and maintaining assets enables faster, more accurate incident analysis.

2. Network Configuration Diagram

• Prepare a diagram showing how communication devices and terminals are connected within the production system.
• This helps quickly identify security issues and supports accurate analysis.
• Such diagrams also make it easier to share information with external analysts, leading to more effective assessments.

3. Analysis Process

   Begin with the network segment where the cybersecurity incident is suspected.

   1) Example: If a production PC shows anomalies, analyze that PC and the servers/PCs directly connected to its network.

   If the affected device is network equipment, include all assets under that equipment in the analysis.

   When a production PC or other device shows abnormalities:

   1. Disconnect the affected asset from the network.
   2. Use antivirus tools and experts to determine whether it is a failure or a cyberattack.
   3. If multiple assets show anomalies, assume the entire network may be compromised.
   4. If anomalous assets include equipment that communicates directly with another network (e.g., server equipment), expand the analysis to include potential impacts on that connected network.

Clarification of the occurrence

The occurrence of cybersecurity incidents in factories is uncertain, and it is challenging to accurately measure their potential damage or scope. While tampering and transmission errors can often be quickly detected, it is difficult to detect leaks and network breaches in a timely manner.

The Cyber Security Detection Requirements section in IPC-1792 provides examples of conditions that should trigger a CIQA: 

1. Unexpected reductions in process speed or performance, especially when occurring simultaneously at multiple stations

2. Unusual increases in CPU load, causing devices to run warmer than normal or fans to spin faster than normal

3. Unknown, unusual, or inappropriate message appears on screens

4. Screen display failures (blue or black screen, locked screen), especially if they occur at multiple stations at the same time

5. Errors occur at one or more production stations or information terminals that cannot be corrected through normal maintenance procedures

Define in advance who will make the decision.

Cybersecurity incidents often require immediate major business decisions (i.e., halting shipments, full or partial product recalls), even when the circumstances and the extent of the impact are unclear. 

The following preparations are necessary for this purpose.

• Methods for gathering the information necessary to make a decision
• Assignment of a decision-maker (including a substitute in their absence)
• Process for collecting and presenting information for the decision-maker
• A structure for suspending shipments or recalling products based on the business decision

The illustration below provides an example of this.

Figure: Unclear Impact Extent

Procedure Example 2: Preparation for Immediate Assessment of Realized Risks (CIQA)

The Cyber Attack Detection at Factories section in IPC-1792 provides definitions and requirements for expediting a CIQA.

Impact Definition

To conduct a CIQA properly and effectively, it is essential to define impact levels in advance. To expedite a CIQA, stakeholders (factories) need to clarify and prepare their procedures in advance of an incident. If these procedures are considered after an incident occurs, the damage may be magnified.

Specifically, the following items are representative of a CIQA:

1. Procedure for identifying the scope of impact (scope)

2. Procedures for determining product impact (impact)

3. Procedures for determining the process (on what basis and by whom)

Defining a tiered impact level based on the severity of the incident and documenting the criteria will prevent the judgment and response to an incident from becoming gentrified.

The following are three possible levels of impact, along with examples of each.

Table: Tiered Impact Levels

The product characteristics in the table examples represent possible products manufactured within an electronics supply chain. IPC standards also define products according to Class levels:

1. Class 1 Electronics: General Electronics Products

2. Class 2 Electronics: Dedicated Service Electronics Products

3. Class 3 Electronics: High-Reliability Electronics Products

While IPC product classifications can provide context, they are not directly linked to the urgency of reporting a cybersecurity incident. Reporting urgency depends on the potential impact of an attack on the product, particularly in its most critical use cases.

As a result, customers may request response levels that do not align with IPC product classifications. The following offers guidance on how to address such requests while still considering product classifications.

Judgment process

To quickly implement a CIQA, the process from detecting an asset error to identifying its scope and determining its impact level must be documented and readily available in advance. It is essential to clarify who will assume each role and when. 

The figure below shows an example.

Training

Preparing procedures for implementing CIQAs does not guarantee they will be implemented quickly and properly. Periodic training exercises are necessary to ensure CIQAs are implemented in accordance with various changes, such as changes in personnel, changes in the products being manufactured, and shifts in public opinion.

Periodic role-playing drills should be conducted to ensure a smooth response in the event of an intrusion, and senior management should participate in training, as cyber incidents often require management decisions.

Return to Cybersecurity Guidelines