How Can Critical Infrastructure Devices Be Trusted?

TL;DR

Critical infrastructure devices can be made more trustworthy by designing them for verification, separating vulnerable firmware from simple processors, and testing random samples from randomly selected suppliers. The goal is not absolute protection against unlimited or precisely targeted attacks, but affordable resistance to general-purpose backdoors that could compromise many low-power controllers across multiple facilities.

Transcript

Hello, I'm Philip Han Baker with The Comodo Group, Inc., and the title of my talk today is The Manchurian Device Problem. So what is the Manchurian device problem? Well, in a nutshell, the problem is that every silicon chip looks the same. It's a black box, and you don't know what's inside it. You don't know whether that black box is the black box ... Read More

Key Insights

• The Manchurian device problem is the inability to determine whether an apparently ordinary silicon component contains its intended design or has been compromised at its source, during distribution, or after deployment by an adversary.
• SCADA hosts are supervisory systems rather than the only critical components of an industrial plant. A plant can continue operating while its supervisory system is turned off, so security must extend to controllers, programmable logic controllers, safety systems, and other endpoints.
• A typical chemical plant may have five SCADA hosts alongside as many as five thousand independent control loops, with multiple CPUs participating in each loop. This scale makes device-by-device inspection difficult and potentially extremely expensive after a major cyber incident.
• Stuxnet demonstrated that sophisticated attackers may invest heavily in infrastructure compromise. The attack used four or possibly five zero-day attacks and involved two compromised code-signing certificates, supporting the need to consider device compromise during manufacture rather than only after installation.
• A practical defense must match a defined attack model. The proposed design targets attacks costing roughly a million dollars and seeks to block reusable, general-purpose backdoors, rather than promising protection against unlimited spending or a concentrated attack on one specific facility.
• Commodity controllers from randomly selected suppliers can reduce the feasibility of narrowly targeted supply-chain compromise. Because an attacker cannot know which supplier's controller will occupy a particular position, compromising a specific component at its source becomes more difficult.
• Random sample verification is necessary because supplier randomization alone does not stop a general-purpose backdoor placed across many devices. Effective sampling depends on designing controllers from the outset so that their behavior and conformance to specification can be verified.
• Removable firmware can separate the processor from the component most likely to carry a practical million-dollar compromise. In simple eight-bit or sixteen-bit controllers, firmware presents a more plausible target for a reusable attack than the underlying CPU design itself.

Questions & Answers

Q: What is the Manchurian device problem?

The Manchurian device problem is the difficulty of knowing what is actually inside a silicon chip that appears identical to other chips. A device may contain the intended design, or it may have been altered by an adversary during manufacture, distribution, or deployment. This uncertainty threatens critical infrastructure because trustworthy operation depends on controllers executing the intended code.

Q: Why is securing SCADA hosts alone insufficient?

Securing SCADA hosts alone is insufficient because those machines provide supervision rather than all direct control. A plant can continue running when the supervisory system is turned off, including during upgrades. The broader environment contains three-term controllers, programmable logic controllers, safety systems, printers, and many other devices, any of which may become a point of compromise.

Q: How large is the device security problem in a chemical plant?

A typical chemical plant described in the talk might have five SCADA hosts but as many as five thousand independent control loops, each involving multiple CPUs. After a major cyber incident, auditors could demand evidence that every processor remains uncompromised. At an estimated fifty dollars per device across fifty-five thousand devices, verification would impose a substantial total cost.

Q: What security lessons does Stuxnet provide?

Stuxnet shows that an attacker may exploit ordinary supporting infrastructure and invest heavily in a carefully engineered operation. It spread through printer shares, while the overall attack used four or perhaps five zero-day attacks and two compromised code-signing certificates. That level of effort means defenders cannot dismiss the possibility of compromise introduced during a device's design or manufacture.

Q: What attack model does the proposed defense address?

The proposed defense considers attacks costing roughly a million dollars, representing serious adversaries without assuming unlimited resources. It focuses on preventing general-purpose backdoors that could compromise devices broadly and disrupt many facilities. It does not claim that inexpensive, low-complexity equipment can always resist a highly focused million-dollar effort directed at one particular piece of infrastructure.

Q: How does random supplier selection improve device security?

Random supplier selection helps when controllers are standardized, interchangeable commodity products. An organization can purchase a controller from a randomly chosen source, making it difficult for an attacker to predict which manufacturer's device will fill a specific operational position. This approach resists highly targeted source compromise, but by itself it does not prevent a general-purpose backdoor affecting devices regardless of destination.

Q: Why must device randomization be combined with verification?

Randomization mainly frustrates an attacker targeting a particular controller or facility. It does not detect a broadly useful backdoor installed across a product line. Verifying randomly selected samples can test whether mass-produced components satisfy their specification. However, such testing is difficult unless devices are deliberately designed from the beginning to expose enough evidence for meaningful verification.

Q: How can removable firmware make controllers more trustworthy?

Removable firmware divides a simple controller into the CPU and the code controlling it. The talk argues that firmware is the more practical target for a million-dollar, general-purpose compromise, while CPU-level attacks are harder to reuse broadly. Separating firmware therefore lets defenders focus verification and replacement on the component most likely to contain malicious functionality without greatly complicating the processor.

Summary & Key Takeaways

• Critical infrastructure security cannot focus only on supervisory SCADA hosts. A chemical plant may have five supervisory hosts but as many as five thousand independent control loops involving multiple CPUs. Three-term controllers, programmable logic controllers, safety systems, printers, and other endpoints all create potential routes for compromise.

• The Manchurian device problem arises because a silicon chip is effectively a black box. Operators cannot readily determine whether it contains the intended design or was compromised during manufacture, distribution, or deployment. Any practical defense must preserve the low cost, simplicity, power efficiency, usability, and long service life required by control equipment.

• The proposed strategy combines commodification, supplier randomization, sample verification, and removable firmware. Random sourcing makes targeted supply-chain attacks harder, while verification addresses broader backdoors. Separating firmware from the CPU concentrates scrutiny on the component most practical to compromise, particularly in simple controllers built around eight-bit or sixteen-bit processors.