Network and device segmentation should be part of the defense in depth security approach for all critical industrial control system (ICS) environments. Frankly speaking, it is a physical security best practice learned over centuries, and an IT security best practice learned over the last several decades. It provides a much more robust security posture than a simple perimeter-only defense. With perimeter-only protection, once an adversary gains access, nothing prevents them from traversing the network unchallenged. Segmentation and micro-segmentation stop unbridled access in IT environments and should be doing the same in ICS environments.
In fact, most industrial operations, like oil and gas, power, utilities, maritime, and manufacturing, already employ simple segmentation between the corporate IT networks and the ICS or operational technology (OT) networks. But for most, that is where their segmentation stops. Why?
Segmentation within ICS networks can be challenging and costly. It requires in-depth knowledge of the ICS network and devices—often hundreds in these environments. And depending on how its done, implementation in ICS networks can take considerable time and effort, and may require network downtime, costing organizations substantially.
Additionally, many organizations lack the expertise and coordination necessary to undertake these projects. IT professionals traditionally implement network segmentation leveraging IT devices, but ICS networks are managed by operations personnel who typically do not have the same level of cybersecurity experience or training. Without close coordination, segmentation in the ICS network is not possible.
ICS environments have different equipment requirements than IT environments. These ICS environments require equipment designed to withstand harsh environments, which rules out your traditional IT equipment.
But segmentation is definitely achievable, and here’s why industrial operations should segment—the OT way.
Let’s say I’ve got a company, and the company has three processes they run. There are three different control systems, performing three distinct operations. Process A has a PLC, safety system, and RTU; Process B has a PLC, safety system, and RTU; Process C has the same assets. These processes comprise their ICS network.
Figure 1: A Typical Flat ICS Network
Typically, there is a firewall at the plant level. Now, the firewall could be for the whole plant or just for the ICS network; both cases occur in practice. But let’s say that the customer is a bit more advanced in their cybersecurity, and they have a firewall at their process plant level. At the end of every firewall, for this example, there’s a switch. The firewall implements rules, and the switch allows multiple connections to go in and out.
Typically, companies wire their ICS assets up by connecting each one to the switch. And ideally, anything trying to come in through the firewall gets stopped.
This type of setup is a flat network. The assets are stacked, but literally, they are all hanging off one switch. And when you set up the network in this way, every machine’s IP address will be on the same subnet.
There are a few issues with this simple level of segmentation in industrial operations. First, Process A, Process B, and Process C are interconnected; an attack on one could easily traverse to another. Thus, an attack on the first process also threatens the reliability of the second and third processes, creating more significant operational impacts per incident than if the network were segmented.
Second, a cybersecurity professional or admin can’t define a firewall policy for Process A different than Process B. There’s one policy because of the single firewall. There are some options to address the one policy issue; in practice, however, adopting multiple policies on a single firewall proves difficult. The bottom line—nobody does it. Various policies for the network typically don’t exist.
Lastly, the firewall at the plant level is usually an IT-owned and -managed asset. And the firewall is often set to allow port 80 to exit the network, which is your URL to go to any website. If a user in the ICS environment goes to a site and inadvertently downloads malicious software, it’s not flagged because it’s an allowed action. If somebody plugs their laptop into the ICS network or connects wirelessly, that user can access sites beyond the firewall. This approach is risky and leaves ICS networks unacceptably vulnerable.
So, how should networks in industrial process operations be segmented? The IT answer is to implement segments in smaller increments. Process A gets a firewall specifically for its own use, Process B gets its firewall, and so does Process C. Then, each firewall has a switch, and each switch connects to assets for that particular process. In the end, Process A has a firewall and switch for Process A’s PLC, safety system, and RTU.
Figure 2: An IT Approach to ICS Network Segmentation
Typically, this setup positions the firewalls to do “natting.” Natting, or network address translation, means each firewall can provide each process group with a different IP address range. With this setup, operations can create a separate firewall policy for each process. Then, there is also a firewall and switch at the plant level. So, in the end, there are two layers or two firewalls—one around the entire ICS network, and one around each process. Typical IT segmentation follows this approach.
In practical terms, if an operation is going to adopt the IT approach to segmentation, it’s going to be expensive. The first step is to reconfigure each device in the OT network. You may have to change the IP addresses for hundreds of devices. It’s a nightmare. For industrial operations, this typically requires downtime and significant effort. Employees need to diagram the OT networks and use piping and instrumentation diagrams (P&ID)—which usually need to be verified or updated. It’s difficult, complicated, and takes time. But segmentation is more security, though, right?
In addition to the initial setup, the IT approach to ICS segmentation must be maintained over time to be effective. In practice, often these firewalls are not used as firewalls at all. The rules are all turned off because no one can keep them up-to-date. So, setting up and maintaining firewall rules is another massive challenge for industrial operations and operations teams.
Lastly, this IT approach to segmentation doesn’t always fit industrial operations. What happens, for example, if your human-machine interface (HMI) sits outside of the firewall? Then you have holes that go back and forth from the HMI to each process. Or you have a local HMI if the operation doesn’t have the top firewall setup.
The IT approach to ICS segmentation can be beneficial and works with properly managed firewalls. But in practice, especially for operations focused on maintaining control, availability, and reliability, the hardest part is resubmitting and relabeling all the assets and then maintaining them over time.
So, what can industrial operations do to segment their ICS networks? Answer: implement a purpose-built ICS segmentation approach with fit-for-purpose industrial security appliances, similar to the IT segmentation approach but much more realistic for operations teams.
Let’s go back to our typical ICS network, and say those three processes are the three critical assets on this network. Without resubmitting or rearchitecting anything, one can add a bump-in-the-wire ICS security appliance instead of an IT firewall.
Figure 3: A Purpose-Built Approach to ICS Network Segmentation
This fit-for-purpose ICS security appliance can monitor the ICS network, remove all unauthorized traffic, alert on anomalous traffic, and allow the authorized traffic to pass through. This approach gives operators greater control at each of these ICS segmentation points. For example, if Process A has a local HMI, the operator can set it up so that the HMI can only talk with Process A’s PLC, safety system, and RTU. Additionally, with the ICS security appliance, an operator can clearly define and approve authorized traffic between the HMI and the PLC, safety system, and RTU. With this purpose-built ICS segmentation approach, there is no requirement to reset or resubmit any devices or assign new IP addresses.
The ICS network segmentation model presented has only three processes, but real industrial operations can have hundreds or more devices controlling different processes. With this approach, the entire ICS network is behind an IT firewall, but then you have multiple layers of dedicated ICS security appliances within the ICS network. Operators can monitor and control traffic to each discrete process, each safety system, and each RTU.
Now, everything within the ICS network and critical processes are logically locked down. Only what’s explicitly authorized is allowed—traffic permitted to connect to the outside world is even controlled. The same ICS security appliances can be used to limit remote access for vendors and third parties only as necessary.
In summary, this approach to ICS segmentation works on existing flat networks (although not required), gives much greater operational control and security, and costs far less in terms of financial resources, labor, and potential downtime than the traditional IT segmentation approach.
What is zero trust in ICS? Zero trust in an ICS environment is a principle of maintaining strict access and communications controls by ensuring only securely authenticated users and devices have access to each process or device within the network. Even internal communications are not trusted by default.
The biggest issue traditionally with a zero trust model is complexity, but security is always a process, not a set-it-and-forget task.
With the purpose-built ICS segmentation approach detailed above, operations, operators, and cybersecurity teams can begin to simplify this complexity. With ICS security appliances, ICS network devices and communications can be mapped, user access controlled, all communications monitored in real-time, and zero trust controls can be implemented, thereby limiting all unauthorized access. This approach gives ICS operators a path to getting enhanced cybersecurity protection without rearchitecting the whole ICS network.
A version of this post can also be found on the Mission Secure blog.