Industrial DMZ Design

Why a DMZ

A utility wants to see plant data on the business network, wants engineers and vendors to reach the control system from outside, and wants patches and antivirus signatures to arrive at the SCADA servers. Each of those is a connection between the enterprise network, which is exposed to email, the web, and every laptop that joins it, and the control network, which runs the plant. Allowing those connections directly means an attacker who gets into the enterprise network is one firewall rule away from the PLCs.

The DMZ breaks that path. It is a third network between the two, holding the services both sides need, with a firewall boundary on each side. The enterprise talks to the DMZ. The control zone talks to the DMZ. Neither talks to the other. An attacker who compromises a DMZ server has reached a server the utility can rebuild in an afternoon, and still has a second firewall between them and the plant.

What goes in it

The test for whether something belongs in the DMZ is whether both sides need it. A service only the control zone uses stays in the control zone. A service only the enterprise uses stays there. The DMZ is not a place to put things that did not fit elsewhere.

The rules

No direct path

No firewall rule permits a connection from any enterprise address to any control address, or the reverse, on any port. Every exception someone requests is met by placing a service in the DMZ instead.

Push out, never pull in

Data leaves the control zone because a control-zone server initiates a connection outward to the DMZ replica. The DMZ never initiates a connection into the control zone to fetch data. A rule that allows the DMZ to open connections inward is a rule an attacker in the DMZ can use.

Different protocols on each side

Where practical, the protocol between control and DMZ differs from the protocol between DMZ and enterprise. A historian replicates by its own protocol inward; enterprise users read it by HTTPS or SQL. An attacker cannot ride one protocol end to end.

Default deny

Both boundaries deny everything not explicitly listed. The rule list for each boundary is short, each rule names its conduit, and the list is reviewed on a schedule.

Hardened and disposable

DMZ hosts are patched first, run only their service, have host firewalls, and are backed up so they can be rebuilt. Nothing in the DMZ is required for the plant to run.

Logged

Both firewalls log denied and permitted connections to a log server, and someone reads the denials.

Firewall arrangement

The classic arrangement uses two physical firewalls, one between enterprise and DMZ and one between DMZ and control, ideally from different vendors so that a vulnerability in one does not open both. Many utilities use a single firewall with three interfaces and a strict zone policy instead, which is acceptable if the rules are written as if there were two devices and no rule references enterprise and control in the same line. The single-firewall design has one management plane to protect and one device to fail; the two-firewall design costs more and needs two sets of rules maintained. Either is far better than no DMZ.

A utility-sized DMZ

A small utility does not need a rack of DMZ servers. One well-specified server, or two virtual machines on a small host, can carry the historian replica, the jump host, and the patch staging role, with the firewall rules separating them. What it must not do is skip the DMZ because it is small: the enterprise-to-control direct connection is the same risk at a 5 MGD plant as at a 50 MGD plant, and the incidents in the water sector have been at small utilities more often than large ones.

Common failures

• A historian configured to pull from the control zone because that was the default in the setup wizard.
• A rule added for a vendor "temporarily" that allows enterprise to control on one port, still present five years later.
• The jump host with a browser, an email client, and internet access, because a vendor wanted to download something.
• A DMZ server joined to the enterprise domain, so an enterprise domain compromise owns the DMZ.
• Operator workstations on the enterprise network with the SCADA client installed, reaching the SCADA server through a permitted rule.
• Antivirus and patch servers in the DMZ with a rule that lets them push into the control zone on a management port, which is a pull-in rule under another name.