Is your DMZ a no man's land?

Organisations continue to digitise. Whether intentionally via planned projects with dedicated budgets and resources, or unintentionally as suppliers embed remote monitoring into equipment and encourage migration to cloud-based software.

At the same time industrial automation (Operational Technology, OT) is making more use of the same open protocols used by Information Technology (IT). Pressures to improve efficiency mean organisations are increasingly integrating OT and IT systems to streamline processes and automate menial tasks.

These trends mean there’s more crossover than ever between IT and OT, leading to more interaction between the teams responsible for each. The relationship between these teams can often be gauged by how they use the demilitarised zone (DMZ).

If the DMZ(s) in your organisation is treated as no man’s land by the IT and OT departments, a huge opportunity to increase the rate and quality of innovation and process improvement is being missed.

You’ll know this is happening if people tend to avoid communicating with the other ‘side’ when working in this network. They avoid it altogether. Or don’t take responsibility of the outcome when they do.

The reasons friction can exist between IT and OT teams are well-documented and vary between organisations. The most common retort from people in OT is that IT personnel don’t appreciate the importance of planning system updates and changes, they don’t feel pain when systems go offline (planned or unplanned). People in IT have the opposite perspective, operational teams seem oblivious to security risks and the need to keep systems up to date so they can communicate securely with other parts of the organisation.

Instead of dividing people, use the DMZ to bridge the gap between them. Encourage experimentation to generate ideas for how the organisation can make use of its data. Rather than a little used buffer between networks, make the DMZ the location for proof of concepts, pilot projects and collaboration activities between business and operational teams.


Some ideas to get you started:

Set ground rules. The DMZ is not a sandbox, it’s likely the only connection between your operational and business systems. Put measures in place to ensure production data moving through your DMZ can’t be impacted by trials.

Have clearly defined projects. Ensure there is a single person responsible and accountable for every project. Then that all activity takes place within a defined project.

Require, rather than expect collaboration. Any work done in the DMZ - whether it’s replacing a patch lead or deploying a new process historian - should be done with the knowledge and preferably involvement of individuals from both OT and IT teams.

Log and record everything. So you don’t lose out on any learning, and can explain why things work (or don’t).

Maintain good cyber security hygiene. Remember the DMZ’s main purpose is to secure your OT networks. Segregate production and non-production data. Only read data from your operational systems (you’ll likely have firewalls configured to do this already). Ensure you keep track of all assets connected to the network.


So if your DMZ resembles the image at the top of this article, think about taking down the razor wire and clearing the mines. Companies who master integration of their operational and business systems stand a far greater chance of remaining competitive in their markets.

Create an environment where it raises a flag if someone mutters, “IT must have installed an update”, or “OT have plugged in another XP machine…” and make the most of this valuable resource sitting in clear view.

Simplified DMZ Architecture


Published: