Zones, Conduits, and What They Mean

Concepts

Have you ever been in a meeting where everyone says the same words but you later discover that they were thinking different things? That’s what concerns me about the concept of Zones and Conduits.

Security people hear the concept and they think it is related to the Purdue Enterprise Reference Architecture1 (the so-called “Purdue Model”). Segment the traffic so that we can analyze it, they think…

Network Engineers hear the concept and think it’s just a cute term that the Process Engineers invented that is really just a VLAN2. Physical networking equipment is mostly irrelevant because we can virtualize the network, they think…

Control Systems Engineers hear it and think it has to do with a design concept to isolate key elements of the process. The network is a detail they can leave for others, they think…

Operators may hear it and think it is a piping and instrumentation diagram variant –but they’re too busy with other things to think about it.

They’re all thinking different things and coming up with different answers. The problem is that none of these views encompasses the whole concept. Fair Warning: while I am a control systems engineer, I do know a few things about networking, systems management, cybersecurity, and software design.

Zones

First, what is a Zone? Let’s consider that the sole purpose of industrial automation is to safely automate a process. Complex processes do that by breaking the process into groupings with related feedback loops of control.

Thus, a zone of a plant is a process function that can be isolated and run semi-automatically. There may be centrally managed states and setpoints, but these should not change too often for a human being to manage it. A zone should be operable independently by a human operator. As such, it should have its own networking hardware, including a local Human Machine Interface (HMI) or Operator Interface Terminal (OIT)3.

A zone typically has a separate power source. That power source could be a separate distribution breaker from a substation, it may include a backup generator, a UPS or whatever. And most importantly, it is a unit of the plant or infrastructure that can be shut down or “parked” temporarily to handle a bad situation. The important instrumentation in the zone should all be powered from the same place. If they cannot be powered from the same place, at least have plans in the Process Narrative document to deal with the inability to communicate with that instrument or asset.

Why is this? First, if a plant is suffering from a cyber-attack they may need to isolate various zones and operate them independently. This is often done to keep malware from spreading from zone to zone. Some zones, particularly those that exhibit signs of compromise, may have to revert entirely to manual control. A zone should be able to operate independently, shut down, or safely park that part of the process. This is so that it can continue to function while an operator monitors the inputs and outputs to optimize performance. The idea behind all this is to enable the automation to degrade gracefully.

Where multiple lines or trains of process exist, each train should be configured as a zone so that its functionality can continue while other process trains are parked or inoperative.

That said, let’s discuss what a zone is not. If it doesn’t have its own separate networking infrastructure, it does not meet the conceptual requirements of a zone. If all the network cables run to a switch powered somewhere else, you are now introducing two or more failure modes that are not contained within a zone. In that situation, if the adjacent zone has a problem, it will impact this zone too.

As a reminder: We’re not establishing zones to save money on network equipment. Each zone must be designed to stand as independently as possible as a process. Because it relies upon network equipment to facilitate its automation, it must also require that the network equipment remain functional as long as the zone is functional. Do not combine networks from different zones as VLANs on a single switch. This VLAN approach on a single switch does not save anything because it creates a single point of failure for multiple zones.

In addition, if engineers or integrators marshal the I/O from more than one zone into a single cabinet, it does not fully meet the conceptual notions of a zone. All it takes is a failure of that cabinet and now they have taken down two or more zones. Keep your I/O wiring to a cabinet contained within a zone. Do not consolidate cabinets. You’re not going to save anyone any money if that cabinet were to be infested with rats or mice (I’ve seen this and it ain’t pretty), get flooded, or involved in a fire.

Conduits

This naturally leads to the next question: What is a Conduit? Once again, conduits should remain functional as long as the beginning and endpoint zones can operate. This could be done with a simple direct Fiber Optic connection. There may be security concerns, so the trunk may need to traverse a firewall between the Zones.

Like the concept of the zone above, this does not mean you take all conduits and run them through the same big switch in the control center. That will also produce a single failure point. All the attacker has to do is find a way into the UPS for the Control Center and shut it down. Instead, the switching, routing, and firewall functions belong in the field. This is how we design Layers of resiliency and security into OT.

This is particularly the case where a Conduit contains Peer-to-Peer communications between Zones. Peer to peer links should run directly between zones. It is not okay to home run everything to a control room and then back out again. While it may be convenient from the security point of view, it is again a single point of failure. You can still bring everything back to the same switch, but instead assign that communications path a higher cost and then run a direct lower cost communications link between the zones. This gives you redundancy in case the peer-to-peer communications path fails while it still makes security monitoring of a conduit possible.

I can hear the screams of protest coming from Project Managers and Network Engineers right now. Yes, this is more expensive, not to mention difficult to monitor and manage. BUT: Physical network design should follow and support the physical plant design, including failure modes. We should design for the possibility of failure and for the ability to maintain and test the conduit communications path.

Putting it All Together

It is worth remembering that one of the primary goals of the design of the automation of a plant is primarily to improve availability. Unlike an office building where switches can be high speed devices with lots of ports, here we will be collecting statuses from switches in cabinets in remote parts of the field. There will be more switches and firewalls to monitor and they will be in remote cabinets in places that you may not be able to get to easily without a fair amount of training, tools, and protective equipment. The primary concept is to decentralize the network so that the impact to the system availability will be minimized should any conduit or network component fail –this includes physical components, so don’t get any silly ideas of bringing everything back to a single site and then using redundancy to assure reliability. While it may work in an electronic sense, it may not be effective should the site become uninhabitable due to a fire, flood, or even a lack of HVAC. Ultimately, the redundancy approach is far less resilient than distributing the hardware around the plant.

As for security and monitoring, the best place to start is at the conduit from the zone. Within a zone, there are usually time critical operations where your overhead for security may not be welcome. These industrial field switches and routers operate in hostile environments. They are usually designed for lower power and more extreme environmental limits. As such, it is wise to keep the overhead of security monitoring to a minimum. I regularly encounter the notion that we should bring back all traffic from the field so that it can be analyzed in a SOC. This is not a great concept.

First, the SOC is rarely ever advised of what is going on in a plant. If the SOC were to see a PLC go into program mode, is that a bad thing? They can’t tell. They usually don’t know who is supposed to be working where. That PLC in program mode at 3 AM might be a technician from the plant working on a problem, or it might be something nefarious. The SOC in most companies has little visibility on operational issues. Furthermore, the SOC may not even be fully aware of the physical layout of the plant networking hardware. After all, would they know whether Flocculator 3 is part of the west process train? Do they even know what a Flocculator does?

There are people who have answers to this: Operators. It is a very good idea to include the Operators as part of your front line against cybersecurity problems. They know who is supposed to be working where. If they see a port go down or go live where it shouldn’t, they would be the first people who ought to know whether it is expected or suspicious.

That said, if the security staff want to put a device in a zone to gather and store information for analysis later, that’s usually acceptable as long as the switch backplane is specified to handle this traffic. Just don’t clog the conduit connections with too much traffic.

Remember, these are not office grade switches with a healthy backplane bandwidth, and the conduit speeds may also be limited for reliable or durable signal recovery. This issue is exacerbated because the power a switch may dissipate may be limited. Power dissipation is not an issue because the plant is trying to save money but because they’re trying to limit the thermal load inside a carefully sealed panel filled with other electronics making heat.

You Process Engineers are not off the hook either. Yes, the client wants to save money. But it’s important to think about not just how this industrial process will work, but how it could fail due to abuse. As such, I offer the following broad advice:

First, split the process in to trains of functional parts, if possible. When designing the process, don’t forget to specify where a zone is (for the networking people) and the zone must have an operational narrative that stands as independently as possible.

Second, the network is not an afterthought. Consider the data flows when designing a process: what needs to communicate with what, and how it could be broken apart into human-manageable subsystems. Then discuss this with a network engineer to define where the switches, network media, firewalls, serial port servers and other components need to go. Then consider gaming the failures of these components and communication paths with the network engineer and the Operations staff. In other words, failure is inevitable. It is your job to design for it.

Third, pay attention to common applications of certain equipment. For example, if you use the same model of firewall across the entire plant, consider what might happen if there were an emergency patch for all of those devices. How would it be deployed and in what sequence? How much time would be required? Should the process trains be reoriented a bit to facilitate this emergency patch? How much additional staffing would be needed?

The plant networks should not be an afterthought. The profitability and availability of that infrastructure depends upon the automation. Industrial infrastructure is no longer staffed so that everything can run manually. We must plan for automation and we must consider what happens when it fails, is subverted, or attacked.

That’s the driving force behind the Zone and Conduit model.

Notes

1Grace Hopper, who at the time was a Captain, mentioned foundational concepts of the Purdue Model in a seminar delivered on August 19, 1982 to the National Security Agency, long before the Purdue Enterprise Reference Architecture document was published. See https://www.youtube.com/watch?v=si9iqF5uTFk Start from Minute 6:20 through minute 8:30 (last viewed January 9, 2025)

2A VLAN is a Virtual Local Area Network. It is a group of ports within a larger switch where the broadcast traffic, and internal communications traffic are kept together. You can route into and out of a VLAN but the internal traffic is intended to stay internal. VLANs can be “trunked” from switch to switch and kept separate from other traffic. This enables more cost effective use of switch hardware and trunked communications.

3An OIT is just a stand-alone HMI that operates within a zone. It may have short trending data, but it usually doesn’t access the Historian server. It is not intended to be used to manage other zones.

http://www.infracritical.com

With more than 30 years experience at a large water/wastewater utility and extensive experience with control systems, substation design, SCADA, RF and microwave telecommunications, and work with various standards committees, Jake still feels like one of those proverbial blind men discovering an elephant. Jake is a Registered Professional Engineer of Control Systems. Note that this blog is Jake's opinion ONLY. No Employers, past or present were ever consulted with regard to these posts. These are Jake's notions. Don't blame anyone else for them.