Getting plant data to IT systems safely across the OT/IT boundary

Why the boundary exists, and why it's worth respecting

Control networks were built for availability and predictability. The PLCs, HMIs and engineering workstations on them often run older software, can't always be patched on IT's schedule, and sometimes react badly to traffic they weren't designed for. The business network is the opposite: large, changing constantly, connected to email and the internet, and a common entry point for phishing and malware.

The boundary between them keeps a problem on one side from becoming a production outage on the other. A data project that treats it as an obstacle to route around tends to stall in review. One that treats it as a design constraint from the start is easier to approve, because it answers the security team's questions before they're asked.

Zones and conduits: a shared vocabulary

Plant networks are commonly described using the Purdue model's levels: field devices and controllers at the bottom, supervisory and site operations systems above them, and business systems at the top, with an industrial DMZ (sometimes called level 3.5) between operations and business. The ISA/IEC 62443 series of standards frames the same problem as zones, groups of assets with similar security needs, and conduits, the controlled communication paths between zones. NIST SP 800-82, a guide to operational technology security, covers similar ground.

You don't have to adopt any of these formally to benefit from the vocabulary. Describing your data project as "a new conduit from the site operations zone to the DMZ, carrying these values, initiated from this side" is a sentence your controls and security teams can evaluate. "We need to get at the PLC data" is not.

Four ways to get data across

The patterns below differ in where the copy of the data lives in the DMZ and how it gets there. In each one, IT-side systems read from the DMZ, never from the plant.

Whichever pattern you choose, read from the highest layer that has the data: the historian or an OPC UA server such as Kepware, not the controllers. Our guide to plant-floor data in web dashboards compares these sources in more detail.

Where the collector sits, and which side opens the connection

Every pattern has a collector: the process that reads plant data and hands it to the DMZ. Where it runs decides which way the connection across the inner firewall is opened, and that's the question your security team will focus on.

• Collector on the OT side, pushing out. The connection is opened from OT into the DMZ, so there is no inbound rule into the control network. The trade-off is a new piece of software on the OT network, which controls engineers have to accept, patch on their schedule and support.
• Collector in the DMZ, pulling in. No new software on the OT network, but one inbound rule from the DMZ collector to a specific OT server and port. Limit it to that one source and destination, and give the collector an account that can only read.
• Collector on the IT network, reading OT directly. This skips the DMZ entirely and is the pattern to avoid. If it exists today, replacing it is often a good first project in its own right.

Neither of the first two is universally right. Some sites forbid any inbound connection into OT; others forbid any new software on OT hosts. Ask which rule your site follows before designing around the other one.

One-way and read-only, enforced rather than promised

"The collector only reads" describes today's code. Security teams reasonably want the flow to stay one-way even if the code changes or the host is compromised. There are several layers of enforcement, and higher-risk sites stack more of them:

1. 1Accounts. The collector's account on the OPC UA server or historian can read named tags or points and nothing else. Write access is denied at the server, not just unused.
2. 2Firewall rules. Each conduit allows one source, one destination and one port, and new connections can only be opened from one side. Everything else is denied and logged.
3. 3Application design. The collector has no code path that writes to the plant, and the DMZ copy is the only thing IT systems can reach.
4. 4One-way hardware. A data diode or unidirectional gateway lets data physically travel in one direction only. Some products replicate historians, OPC data or files across the diode. They add cost and constrain which protocols work, so they're usually reserved for sites where the consequences of a compromise justify them.

Note that an ordinary TCP connection opened from the OT side still carries packets both ways; the firewall controls who may start a session, not which way bytes flow. Only one-way hardware removes the return path entirely. That distinction is worth stating plainly in your design document, so nobody overstates what the firewall provides.

Firewall rule requests that get approved

A rule request that arrives complete is much easier to approve than one that arrives as "please open the historian to the reporting server". For each conduit, write down:

Keep the list of rules alongside the design, in version control if your network team works that way. When someone asks in two years why a port is open, the answer should take a minute to find.

Who owns what: IT, controls, or both

At a mid-sized manufacturer, IT may be a small team at corporate and controls a group at the site, each with different priorities, change processes and maintenance windows. DMZ components sit between them and are easy to leave unowned. Settle it in writing before installation:

• Change control. A change on a DMZ host that could affect collection goes through the plant's change process as well as IT's, including a rollback plan.
• Patching and restarts. Agree when DMZ hosts are patched and who may restart the collector, especially during production.
• Monitoring. Someone gets alerted when data stops arriving, and knows whether to call IT or controls first.
• Accounts and domains. Separate credentials for each zone. Whether the control network shares a directory domain with the business network is a security decision in its own right; follow what your site has decided.
• Scanning. IT vulnerability scanning and endpoint tools shouldn't be pointed at OT subnets without controls sign-off. Active scans can upset older control devices.

Questions to settle before you build

Our experience includes plant-floor systems and manufacturing execution systems, interfacing with HMIs, PLCs and historians, Kepware and OPC UA, extensive work with Rockwell FactoryTalk and some with OSIsoft PI (now AVEVA PI). Plant work is read-only by default; anything that writes to the plant is scoped separately with your controls engineers. The manufacturing page covers what we build.

Sources

• ISA/IEC 62443 series of standards (ISA)
• SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (NIST)
• OPC UA online reference (OPC Foundation)
• Kepware service port assignments (PTC)