The short answer
Firewall Rule Design
A firewall rule set for a control network boundary starts from default deny and adds one rule per documented conduit, each naming the source hosts, the destination hosts, the protocol and port, the direction, and the reason, with logging enabled and a reference to the conduit table. Rules are specific: a host, not a subnet; a port and where possible a function code, not any; one direction. The set is ordered so that the specific rules are readable, tested by confirming that what should pass passes and what should not does not, and reviewed on a schedule so that a temporary rule does not become permanent.
Key points
- Default deny at the end. Everything not explicitly permitted is dropped and logged.
- One rule per conduit, with the conduit reference and the reason in the rule description.
- Specific: host to host, port, direction, and function where the firewall understands the protocol.
- Log everything. A rule that does not log cannot be reviewed.
- Review quarterly. Remove rules whose conduit is gone and rules that have never matched.
Start from the conduit table
The zones and conduits drawing lists every communication path that crosses a boundary: from where, to where, what protocol, who initiates. The firewall rule set at that boundary is the implementation of that list and nothing else. Every rule traces to a conduit row; every conduit row that crosses this firewall has a rule. That correspondence is what makes the rule set reviewable a year later, and it is lost the moment a rule is added because someone needed something to work and the conduit table was not updated.
The anatomy of a rule
| Field | Content | Rule of thumb |
|---|---|---|
| Name or description | The conduit reference and the purpose: C-12 SCADA to plant PLCs, EtherNet/IP polling | A rule without a reason is removed at the next review |
| Source | The specific hosts that initiate: the two SCADA servers by address | Never a whole subnet where the hosts are known; an object group for a set of hosts |
| Destination | The specific hosts that receive: the plant PLCs by address | The same |
| Service | Protocol and port: TCP 44818 and UDP 2222 for EtherNet/IP; TCP 502 for Modbus; TCP 20000 for DNP3 | Only the ports the conduit uses; never any |
| Application or function | Where the firewall inspects the protocol: Modbus function codes 3 and 4 only; DNP3 read only; no program download | Use it wherever the firewall supports it; it is the difference between reads and writes |
| Direction | From source zone to destination zone; the reply is handled by state tracking | One direction per rule; a second rule for the reverse only if a conduit exists |
| Action | Permit or deny | Deny rules above the default deny only for exceptions worth logging separately |
| Logging | On | Every rule, permit and deny |
| Schedule | Always, or a time window for maintenance conduits | Vendor access rules enabled per session, not on a schedule |
The order
Firewalls evaluate rules top to bottom and act on the first match, so the order is the logic. A readable set follows a convention.
- 01Management rules first: who may reach the firewall itself, from the engineering zone only.
- 02Explicit denies for things that must never pass, logged separately so they are seen: any traffic from the enterprise to a controller address, for instance.
- 03The conduit rules, grouped by source zone, each with its conduit reference.
- 04Infrastructure rules: time synchronization, logging, and the few services the zones share, each specific.
- 05Default deny, logged, as the last rule. Even where the firewall denies by default, the explicit rule is there so the log shows what was dropped.
The conduits that need care
- SCADA to controllers
- From the SCADA servers to each controller on the protocol ports, with function restrictions where the firewall can apply them. Controllers do not initiate to SCADA except for unsolicited DNP3 responses, which the state tracking handles, or for report-by-exception designs, which get their own rule.
- Engineering to controllers
- From the engineering workstations only, on the programming protocol ports, logged, and where the firewall supports it, enabled for a session rather than always on.
- Historian replication
- From the control zone historian outbound to the DMZ replica, on the replication port, never the reverse.
- Remote access
- From the jump host to the specific target hosts, on the specific ports, per session.
- Patch and antivirus
- From the control zone servers outbound to the DMZ staging server to pull updates; the staging server never pushes in.
- Time
- From control zone hosts to the DMZ time server on UDP 123, outbound; or a time source inside the control zone.
- Telemetry from remote sites
- From each site address to the SCADA master on the SCADA protocol, and the reverse for polling; never site to site.
- Vendor packages
- From the plant controller or SCADA to the package controller on the agreed port, and nothing from the package outward.
Testing a rule set
- 1
Confirm the permitted conduits
From a host in each source zone, connect to the destination on the permitted port, and confirm the connection and the function. A SCADA driver polling successfully is the test for its rule.
- 2
Confirm the denials
From the same host, attempt the connections that must fail: a write where only reads are permitted, a controller address from the enterprise, a program download from the SCADA server. Each must fail and each must appear in the log.
- 3
Confirm the direction
Attempt a connection in the reverse direction of a one-way conduit: from a controller to the SCADA server on an unrelated port, from the DMZ into the control zone. It must fail.
- 4
Confirm the logging
Every test attempt, permitted and denied, is in the log server with the rule name.
- 5
Confirm the fail mode
Power the firewall off, or disconnect it, and confirm the behavior matches the design: fail closed, with the process continuing on its own, or the deliberate fail open, alarmed.
- 6
Record the test
The rule set version, the tests, and the results, with the conduit table revision.
Reviewing
A rule set drifts: a rule added for a commissioning tool, a rule widened to make a vendor connection work, a rule whose conduit was removed when a device was retired. The quarterly review walks every rule against the conduit table and the hit counters. A rule with no conduit is removed. A rule that has not matched in a year is a candidate for removal, after confirming it is not a rarely used maintenance path. A rule with any in it is made specific or justified. The review is recorded, and the rule set version is bumped.
Frequently asked questions
- How many rules should a control network boundary have?
- As many as there are conduits, which for a utility zone boundary is typically a dozen to a few dozen. A rule set with hundreds of rules at a control boundary has accumulated rules that nobody removed, and the review is overdue.
- Should the reply traffic have its own rule?
- No. A stateful firewall tracks the connection the permitted rule created and passes the reply automatically. A separate reverse rule opens a path in the other direction that the conduit does not need. The exception is UDP-based protocols where the firewall cannot track state, and even then the reverse rule is as narrow as the forward one.
- What about a rule for ping?
- A limited ICMP echo rule from the engineering zone to the control zone helps troubleshooting and is low risk. ICMP from the enterprise into the control zone is not permitted; a device that can be pinged can be found.
- Can the SCADA server reach the internet for licensing or updates?
- Not directly. Licensing traffic goes to a DMZ relay or is handled offline; updates come from the DMZ staging server. A control zone server with a rule to the internet is a control zone server on the internet.
Related topics
- Zones and ConduitsThe IEC 62443 way to segment a control system: grouping assets into zones with a shared security level, inventorying every conduit between them, and turning the drawing into firewall rules. With a worked water utility example.
- Industrial FirewallsFirewalls built for control networks: how they differ from office firewalls, where they belong in a utility network, transparent versus routed modes, Modbus and DNP3 awareness, logging, and the ruggedized units that protect one controller or a remote site.
- Industrial DMZ DesignThe buffer zone between the business network and the control system: what goes in it, the no-direct-path rule, push-not-pull data flows, the firewall pair, and the services a utility actually needs to place there.
- Jump HostsThe one machine every remote session must pass through: what a jump host is, how it is hardened, what it may reach, session recording, the tools it carries, and why a vendor laptop never gets past it.
- Vendor Remote AccessIntegrators and equipment vendors need to get in. How to let them without leaving a permanent door open: utility-controlled sessions, named accounts, MFA, a jump host, session recording, and what to do about the modem you did not know was there.
- How to Configure a Modbus ConnectionSet up a Modbus RTU or TCP link between a controller and a device: get the register map, match the physical and protocol settings, build the reads and writes, handle data types and the addressing offset, and verify with a protocol tool before trusting a value.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.