Many electronic products are operated by repairing, replacing, and maintaining faulty parts. Therefore, it is desirable to consider the impact of this maintenance work on the implementation of IPC-1792. 

Note: Security risk refers to the possibility of introducing viruses or other contaminants into the manufacturing process through non-compliance. For this reason, the term “non-compliant” is used in the information security paradigm.

In the real world, however, it is difficult to distinguish between security issues and quality issues.

The replacement of parts in shipped products covered in this guideline includes not only cases where parts are replaced due to security issues, but also those parts that are replaced due to quality issues.

Even if a part is replaced in the market due to a quality issue, the cause may be a cyberattack upstream in the supply chain. Only after a detailed analysis can it be determined whether the component failure is purely due to a quality issue or a cyber-attack. We use the word “Faulty” in this white paper because we expect such a case.

IPC-1792 Model

To explain how rework, repair, and replacement contribute to the implementation of IPC-1792, it is essential to first summarize the IPC-1792 model within a supply chain.

The illustration below shows the basic operation of an IPC-1792 supply chain. In the illustration, An (n=1...8), Bn (n=1...4), Cn (n=1...2), and Dn (n=1) are stakeholders (factories), and the arrows indicate the supply direction.

D1 is the final factory where the product is shipped to the customer.

From upstream (Factory An) to downstream (Factory Bn, Factory Cn, and the final shipping factory D1) in the supply chain, the security assurance (digital certificates) of shipped products is passed along. The final shipping factory, D1, must then record the list of digital certificates collated in the supply chain.

Based on customer requirements, upstream companies (Factories An, Bn, and Cn) in the supply chain to which IPC-1792 applies must record a list of digital certificates for parts, as well as a list of digital certificates corresponding to their products.

Figure: Basic Operation of IPC-1792

Behavior in the event of a cyber incident

In this example, a cybersecurity incident occurs at Factory A4. First, factory A4 quickly determines if the incident affects the products shipped from its factory. If Factory A4 determines that its products are affected, it promptly sends a digital certificate to Factory B2, the destination factory, and notifies it of the expected time when the incident is expected to occur (i.e., the time when the impact on the products is expected to have started).

Factory B2, which received the digital certificates including the time of the affected occurrence, searches the list of accumulated digital certificates for the company's shipped products, matching them with the digital certificates from Factory A4. It ascertains the affected shipping destinations and immediately forwards the incident report from Factory A4. In the illustration below, the report is forwarded to Factory C1.

Upon receiving a digital certificate that includes the time of the affected occurrence, Factory C1 searches the list of accumulated digital certificates for products shipped by the company using the digital certificate from Factory B2, ascertains the affected shipping destinations, and immediately forwards the incident report from Factory B2. In the illustration, the report is forwarded to Factory D1.

Factory D1, the final shipping factory that received the digital certificate including the time of occurrence of the impact, searches the list records of digital certificates that have been accumulated for its shipped products with the digital certificate from Factory C1, ascertains the affected shipping destination and immediately informs its customers of the product name, delivery date and time, and delivery destination information of the shipped products suspected to be impacted. Factory D1's customers will cease using the suspected products from services provided to them beyond that point and notify them as soon as possible of any potential impact.

In the illustration, it is assumed that the product delivered by Factory D1 is a set of IT equipment consisting of a combination of computers and network devices. It can be imagined from the figure that the product for which Factory A4 has notified an incident as a suspect product is a Hard disk drive. 

The Digital Certificate identifies the factory and part name, so Factory D1, the final shipping factory, can confirm which factory upstream from its own factory the incident occurred at and which part is the suspect product by searching the information in the DB. Therefore, even though Factory D1 may notify its customers which component of the delivered system is suspect, Factory D1's customers are not provided with more detailed information than is necessary to determine the impact of the incident on their customers in the future.

In other words, the customer is not notified that the HDD is suspect.

Figure: IC-1792 Behavior in the Event of a Cybersecurity Incident

IPC-1792 Model in Repair and Replacement

Following the preceding example, this section examines the impact of repaired and replaced faulty components, considering the case of an HDD that was replaced and repaired by a maintenance company due to a partial system failure after being installed in a client company.

Assumed case of maintenance work

The illustration below shows that a red (non-compliant) HDD was replaced with a green (compliant) HDD by a repair and maintenance operation at the customer site.

Figure: Case of HDD Replacement by Maintenance Company

Cases with Updated Information on Factory D1 at Replacement

In this case, it is assumed that when a red HDD is replaced with a green HDD through repair and maintenance work at the customer site, the records in the list of digital certificates stored at Factories B2, C1, and D1 for products shipped by the company are somehow updated to the replaced and repaired green HDD. As shown in the following illustration, an incident notice originating from Factory A4 can be determined at Factory D1 to be no longer in use by the customer, thus preventing an invalid incident notice from being notified to the customer. It is also possible to notify downstream suppliers (Factory B2 or Factory C1) of invalid incident notices, as it may be determined that the customer is no longer using the product at the intermediate suppliers (Factory B2 or Factory C1).

Discarding the incident notification to the customer at the factory is an advantage in terms of not causing unnecessary worry to the customer, but a disadvantage in terms of removing the opportunity for the customer to be notified of any damage the red HDD may have caused to the customer in the time period prior to the replacement with a green HDD.

Figure: Case of HDD Replacement by Maintenance Company

Cases without Updated Information on Factory D1 at Replacement

In this case, when the red HDDs were replaced with green HDDs through repair and maintenance work at the customer site, the records of the list of digital certificates that have been stacked against the products shipped by the company, kept by the shipping Factories B2, C1, and D1, were retained without being updated.

As shown in the illustration below, the incident notification originating from Factory A4 is considered to have been used by the customer at the final shipment to Factory D1. Therefore, the product name, delivery date and time, and delivery destination information of the suspected affected product are communicated. The information noted at Factory D1 pertains to the product delivered to Factory D1 but does not include details on the components that comprise that product. Therefore, Factory D1 knows which factory upstream from its own factory has the incident and which parts are under suspicion by searching database information, but the information that the red HDD is under suspicion is not delivered to the customer. Even if Factory D1's customer remembers that the red HDD was replaced with a green HDD, they will not know that the threat might have disappeared with the HDD replacement once they receive notification from Factory D1 of the potential impact of a cybersecurity attack on their entire purchase.

As a result, regardless of whether there is a threat, the customer will be forced to stop using the Factory D1 delivered products for the services provided to customers and promptly notify any potential impact to customers.

This is a disadvantage in that the customer has to suspend service for an incident that may not have been affected; however, it is an advantage in that it minimizes the damage that the red HDD may have caused to the customer during the period before it was replaced with the green HDD.

Both over- and under-notification of the incident's impact can pose issues. To ensure that only definitive information is shared, it is necessary to wait until the forensic investigation of the incident is complete. However, waiting and responding to the incident would have a tremendous impact on the digitalized social systems.

Therefore, it is essential to share the latest information in a timely manner and prepare an environment in which each entity can make appropriate decisions. This scenario requires a mechanism for updating the records of the list of digital certificates accumulated for products shipped by the company to the green HDDs that have been replaced and repaired.

Figure: Case of HDD Replacement by Maintenance Company

Cooperation with Independent Maintenance Companies

In many cases, the maintenance service is provided by an affiliated company of Factory D1. In such cases, it may be possible to update the records of the list of digital certificates accumulated for products shipped by the company to green HDDs that have been replaced and repaired by sharing information among the group of affiliates. However, as shown in the following illustration, in the real world, local maintenance providers (unrelated to the final shipping factory) that are closely tied to the client company are often requested to repair or replace parts. Therefore, procedures for updating information with maintenance providers that do not seem to have capital ties must be prepared.

Figure: Maintenance by a Maintenance Company with No Capital Relationship

In a case where maintenance is performed by a maintenance company with no capital relationship, let us consider a scenario in which a cyber incident occurs at a factory that ships green HDDs of maintenance parts, as illustrated in the following example.

From the client company's perspective, the product provider, at the time of installation, and the maintenance provider, after installation, have separate notification routes for incidents.

Incident notifications originating from cyber incidents at the green HDD factory are received from the maintenance company. However, when the maintenance provider notifies the customer of an incident involving a replaced green HDD, only parts information is available. Therefore, to understand the impact on the customer beyond that provided by the customer company, the customer must check the replacement history of the parts, identify the system, and determine on its own which part of the system may be affected.

Figure: Cyber Incident of Green HDD of Maintenance Parts

Countermeasure

As shown in the following illustration, by providing customers with a mechanism that allows integrated management of customer configuration management information with both equipment provision vendors and operation and maintenance companies, information related to incident notification can be centralized, and incident notification routes can be simplified. It also enables timely information sharing.

Figure: Linkage with Configuration Management DB

The importance of prompt notification to minimize the impact of cyber incidents on digitalized social systems will continue to increase. In addition, many products in the electronics manufacturing industry are operated by repairing and replacing malfunctioning parts. Therefore, when implementing IPC-1792, it is necessary to achieve immediacy of cyber incident notification, considering the impact of this maintenance work. Specifically, it is necessary to establish a mechanism with electronic device manufacturers and electronic device maintenance operators to update Digital Certificate information to the latest version, even after the product has been shipped.

To ensure a quick response to customer incidents, the system should include a configuration management function that keeps Digital Certificate information up to date.

Return to Cybersecurity Guidelines