One level at a time: reinforce cybersecurity through the SCADA network structure

Cyber threats to our water and wastewater systems are no longer rare incidents, but rather a routine part of today’s threat landscape. With federal agencies warning of increased activity due to rising tensions in the Middle East, conflicts with countries like Russia and China, and a higher prevalence of organized cybercrime and hacktivist groups, it is clear the landscape is not what it once was.

Specialized search engines and tools, such as Censys and Shodan.io, allow attackers to quickly discover and identify exposed devices on the internet. This can include anything from PCs and workstations to servers and even industrial controls equipment. Generally, anything with an IP address that is exposed can be found and possibly exploited.

But even though cybersecurity threats to the water sector have increased, steps toward better protection are achievable, even for small utilities. Cybersecurity, especially in supervisory control and data acquisition (SCADA) and industrial controls space, while it can be highly technical and complicated, is greatly simplified by adopting an organized and policy-driven approach with the establishment of a formal cybersecurity management program. An additional practical cybersecurity measure utilities should take, and the focus of this article, is reinforcing security throughout the structure of the SCADA network.

Effectively securing a water utility’s control network first requires an understanding of how operational technology (OT) systems differ from informational technology (IT) systems, and then how SCADA systems are structured, which components they rely on, and where they are most vulnerable.

Why Cyber Threats to OT Systems Pose Greater Risk to Water Utilities

IT and OT systems are two very different environments that require equally different security strategies. Most people are familiar with IT, which encompasses our office computers, email servers, business networks, and even home WIFI networks. IT systems deal with data. OT systems, however, deal with physical equipment and processes. They encompass the hardware and software systems used to monitor and control pumps, valves, chemical dosing, and so on, in industrial environments like water and wastewater plants.

It is true that IT and OT have a lot of similarities and overlap. But OT networks include additional hardware and devices that aren’t found in typical IT networks, such as Programmable Logic Controllers (PLCs), human machine interfaces (HMIs), and industrial internet of things (IIoT) hardware like pump controllers and power quality meters. These devices are critical to the operation of a plant but often come with far fewer security features than typically found on the IT side.

The divide between IT and OT widens further when it comes to data secrecy and network availability requirements. The IT space has higher tolerance for downtime and generally prioritizes confidentiality above the availability of the system.

The opposite is true with OT systems. The control system MUST remain operational to continue the mission at hand, such as production of safe drinking water or effective treatment of collected wastewater. Taking the SCADA system offline, even briefly, could halt the treatment of drinking water or disrupt disinfection, which poses an immediate public health risk.

Use the Purdue model to evaluate your system

The Purdue model, like many other reference architectures, is a valuable tool for designing secure systems, but it is equally useful as an evaluation lens. Mapping your existing network into this structure can help identify key vulnerabilities, highlight gaps in segmentation or control, and reveal where targeted adjustments will have the greatest impact on reducing risk. It may seem like a redundant or overly simplistic exercise at first, but the insights gained from viewing your system through this framework are often surprisingly revealing.

Use the Purdue Model to Segment SCADA Networks and Reduce Risk

The Purdue Model manages communication and security between IT and OT by segmenting the networks into levels zero through four, which define specific roles and boundaries for data flow. If you’re in IT, it may seem intuitive to conflate levels zero through three and a half and view them as one block; however, managing them separately can help increase security. Simply placing a firewall in between is not enough.

Understanding this segmented structure and how data flows through a typical SCADA network is the first step towards best managing those flows to reduce risk.

Level 0 – Field Devices: This level includes things like instrumentation and equipment hardwired to the PLC, operator interface terminals (OITs), variable frequency drives (VFDs), etc. Even if some of these devices are connected to the network via Ethernet, they belong in this zone.

Level 0 devices may communicate with their parent controllers, either through hardwired inputs and outputs (I/O) or via Ethernet. They generally do not need to talk directly with any other upstream devices. Because of this, if Ethernet is desired or required for Level 0 devices, they should be kept off the main SCADA network and connected directly to their parent PLC using a separate Ethernet card. This prevents direct connections from higher levels and reduces exposure.

Level 1 – Controller Level: This is where PLCs and other industrial controllers reside.

Level 1 PLCs should reside on the same virtual local area network (VLAN). In some industries, segmentation by “cell” is common with separate VLANs for each, but in the water utility space, this approach tends to introduce unnecessary complexity without much benefit. PLCs within a plant generally communicate freely. Exceptions might be made for more sensitive systems, such as chemical feed or chlorine process areas, if additional security is desired to limit lateral movement into these more critical systems.

Level 2 – Supervisory Control: Operator workstations for interfacing with the SCADA system are placed here. In most cases, these are in a control room, although additional workstations located elsewhere in the plant are sometimes present. Regardless of their physical location, the same rules and security controls apply to them all.

These workstations must communicate with the SCADA servers, but they do not require access to PLCs, field devices, or other lower-level systems. As such, they should reside on their own VLAN, and any routing between VLANs should be explicitly controlled.

Level 3 – Supervisory Control Servers: Level 3 contains the SCADA-side servers that are central to plant operations. At a minimum, this includes redundant SCADA application servers, but it often includes other servers such as domain controllers, historians, and backup servers. These may be physical, but virtualization is increasingly common due to improved resource utilization, simplified backup, and deployment flexibility. Redundant SCADA servers, if virtualized, should be hosted on separate physical servers.

These physical hosts should be equipped with multiple network interface cards (NICs), each with their own IP address, allowing connectivity to multiple networks without allowing those networks to directly communicate. Virtual machines on each host can then be assigned to specific NICs based on which part of the network they need to access. For example, one NIC may connect to the SCADA network and the other to the DMZ or firewall, depending on your architecture and which devices need to talk.

Level 3.5 – Industrial Demilitarized Zone (iDMZ): This includes one or more DMZ servers placed between two separate firewalls and provides an application break in the network. It offers a strong security buffer but introduces additional complexity. When implemented correctly, it allows limited, well-controlled transfer of data between IT and OT networks.

iDMZ architecture is highly application-specific and varies depending on the network’s requirements. At a minimum, it involves two physical firewalls: one separating the IT network from the DMZ, and another separating the DMZ from OT. Between them resides one or more “middleman” servers, such as a view-only SCADA runtime server, which serves as a secondary SCADA instance configured without control authority. These servers should have dual NICs: one connected to the IT-side firewall, the other to the OT-side firewall. The two firewalls should never be directly connected.

This design is effective because it eliminates direct communication between IT and OT. Even if access through the IT-side firewall is tightly controlled, a compromised DMZ server can’t initiate a connection into OT. That’s the role of the second firewall, it enforces outbound-only rules from OT, preventing the DMZ from becoming a bridge to sensitive systems. If the two firewalls are directly linked, the DMZ's protective value is lost, and a direct pass-through may be possible.

Level 4 – Business Enterprise Network: This level includes IT equipment such as office computers, servers, and internet service provider (ISP) connections. While beyond the scope of this article, it's worth noting that many SCADA breaches originate from the IT network.

Control communication between zones

Although there are many variations of the Purdue Model framework and the individual levels are sometimes presented differently, this format works well for most water and wastewater utilities. Devices that perform similar roles and share security requirements are placed into the same zones together, allowing them to communicate amongst themselves efficiently.

Communication between zones is also allowed, but security controls must be implemented at these connection points. The complexity of these controls may vary depending on the zones involved and the evaluated risk, ranging from full firewalls to simple VLAN separation, but all cross-zone traffic should be controlled. For OT networks, the default assumption should be that all traffic is blocked between zones unless explicitly allowed. Communication should only occur between specific, justified devices.

Act before the breach

If there’s one lesson from the increasing number of attacks on municipal infrastructure, it’s that waiting until something goes wrong is no longer an option. You don’t need a perfect system, just a defensible one.

Start by understanding your network, identifying key risks, and implementing reasonable controls. Build a culture of accountability around cybersecurity. At the end of the day, it’s not about chasing perfection. It’s about building resilience. Because when an attempted breach does occur, the work you’ve done in advance will determine how your utility responds, recovers, and keeps serving the public without interruption.

For a more detailed discussion, including defense in depth strategies, please see my article “Securing the Future of Water: Practical SCADA Cybersecurity for Utilities,” published in Issue 4 of TexasWET.