An intro to the IDMZ, the demilitarized zone for ICSes

To protect internal networks from untrusted networks, such as the internet, many organizations traditionally used a demilitarized zone. Derived from the military concept of an area that cannot be occupied or used for military means, a DMZ in networking is a physical or logical subnet that prevents external attacks from accessing confidential internal network resources and data.

Cloud adoption has largely negated the need for a DMZ, with zero trust and segmentation becoming more popular options amid the dissolving network perimeter. DMZs can still be useful, however, especially when it comes to the convergence of IT and operational technology (OT). Known as an industrial DMZ (IDMZ), it is key to keeping IT and industrial control system (ICS) environments separate.

Pascal Ackerman, author of Industrial Cybersecurity, Second Edition, was on hand to explain the IDMZ.

What is an IDMZ?

Click to learn more about
'Industrial Cybersecurity' by
Pascal Ackerman, published
by Packt.

Pascal Ackerman: The name itself has been questioned, and I've had a couple people call me up and say, 'Can't you just call it a DMZ, please?' But it's different.

The concept was taken from the enterprise side. For decades, people connected enterprise environments to the internet through a DMZ. They had a shared server or web server exposed to the internet, but if they didn't want to easily allow access into their enterprise environment, they put a DMZ in place.

We took a page from that book and put a DMZ between the enterprise network and the industrial network.

Where things differ between an IT network and the internet and an IT network and OT network is with what we put in the DMZ. By design, it's supposed to be a middle ground for traffic to traverse from an insecure to a secure network -- with the insecure network being the enterprise and the secure network being the ICS. Where you typically do it on the IT side for web services, on the industrial side, you do it for industrial protocols and to make sure they don't have to traverse through the IDMZ. Rather, you have a way to broker or relay or translate industrial protocols and data into something easily available on the enterprise side -- this typically tends to be a web browser.

How does this relate to IT/OT convergence?

Ackerman: Until the late 1990s, IT -- the business network where you do email, ordering and shipping -- was separate from OT -- your production environment -- via segmentation. There was no communication between the two.

As managers and folks on the business side saw the benefits of using industrial data, more and more IT and OT environments connected. While the true controls engineer inside me wants to keep IT and OT separate -- it's really the most secure way -- companies want to get data out of an ICS to do better production and business overall. In order to do this securely, an IDMZ is the way to go.

We're not just putting a firewall in place and poking a bunch of holes in it -- because, eventually, there's no firewall because you've made so many exceptions. Instead, the IDMZ means traffic from the enterprise network is not allowed to go directly to the industrial side. It has to land in the IDMZ first.

Do you have an example of when you'd do this?

Ackerman: Say you want to remote desktop into one of your production servers. That would be initiated on the enterprise side. Instead of going straight into the industrial network and connecting to a server there, you're authenticating to a broker server in the IDMZ, which brokers that into the target server or workstation on the industrial environment.

How does IoT fit in? IoT deployments can be on either the enterprise or the industrial side -- or, sometimes, both.

Ackerman: One of the design goals for implementing industrial security is that industrial protocols need to stay in the industrial environment. If you have a smart camera or an IoT barcode scanner for your MES [manufacturing execution system] or ERP system, those should go on the enterprise network because they're communicating with enterprise systems.

On the other hand, if you have a smart meter that takes the temperature of a machine in the ICS, it might use industrial protocols and send information to a cloud service, where you can look at trends and monitor it. This type of IoT deployment would live in the OT network. Then, you have to deal with the connection to the cloud -- through the IDMZ.

I recommend setting up security zones within the IDMZ. Set up a separate segment for your remote access solution, for your file transfer solution and for your IoT devices.

What threats does an IDMZ prevent or mitigate?

Ackerman: Pretty much anything that will attack the enterprise network.

The fundamental goal with an IDMZ is to have any interactions with the ICS be initiated on the enterprise side. So, if a workstation on the enterprise network is infected by malware, the enterprise client is infected or crashes. The underlying HMI [human-machine interface] sitting on the industrial network is protected by the IDMZ. If the enterprise network is compromised, the compromise stays within the IDMZ and can't travel to the industrial environment.

Who is responsible for setting up and managing an IDMZ?

Ackerman: Companies that have separate IT and OT teams often have the IT team support and maintain the IDMZ. For companies that have converged IT and OT teams, it's usually a shared responsibility. This typically works better because each team understands the other and can build upon each other's knowledge.

How do you build an IDMZ?

Ackerman: You have two separate networks: the enterprise network with physical standalone hardware and the industrial network with physical standalone hardware. Put a firewall between them -- sometimes two -- one for the enterprise side and one for the industrial side. They should be separate brands, too -- that's the most secure. Most of the time, you'll see a three-legged firewall implementation with the IDMZ sitting in the middle.

From there, deploy the IDMZ service itself. The services often run on VMware or a hypervisor from Microsoft and Hyper-V -- some dedicated software. Further components depend on what you're looking to relay. Most of the time, there's a file-sharing mechanism and remote access solution.

Is zero trust ever implemented in an IDMZ?

Ackerman: Zero trust makes sense all the way down to Level 3 of the Purdue model. Levels 2, 1 and 0 -- which are your controls, HMIs and PLCs [programmable logic controllers] -- wouldn't make sense for zero trust. The devices on those levels don't have authentication mechanisms; they just respond to anything that tries to ping them.

Where zero trust does make sense is in Level 3 site operations, where you have servers, workstations, Windows domain, etc. Where you have authentication and authorization is where you can implement zero trust.

What are the challenges of implementing an IDMZ?

Ackerman: Support. An IDMZ is extra hardware and extra software for someone to support, and it's not always the easiest to do from the enterprise side. You have to go an extra step to log in to an industrial asset, and from there, you can support the IDMZ.

Another challenge is the services running on it. If you want to be really secure, you can't just extend your enterprise Windows domain into your industrial environment. You usually end up having a dedicated Windows domain for your industrial environment, which, again, has to be supported by someone.

It can be time-consuming and costly, but think of it another way: If something compromises your enterprise environment and can dig into your industrial environment, how much work and money are you going to spend to get everything up again?

About the author
Pascal Ackerman is a seasoned industrial security professional with a degree in electrical engineering and more than 20 years of experience in industrial network design and support, information and network security, risk assessments, pen testing, threat hunting and forensics. His passion lies in analyzing new and existing threats to ICS environments, and he fights cyber adversaries both from his home base and while traveling the world with his family as a digital nomad. Ackerman wrote the previous edition of this book and has been a reviewer and technical consultant of many security books.