In an IT/OT environment, would you choose easier operations — or stronger security?
Most engineers would probably answer: both.
But in real environments, the two often start pulling in different directions.
A Windows workstation needs patches, so someone opens access to WSUS.
Then DNS is added.
Then NTP.
Then Active Directory.
Then remote support.
Each change looks reasonable on its own.
But after enough small exceptions, the OT network is still called “isolated” while depending on half of the enterprise network.
That is where the real problem begins.
And that is exactly why Purdue Level 3.5 — the Industrial DMZ — matters.
OT Does Need IT Services
A secure OT network cannot simply disconnect from everything.
Production environments still need:
- Windows updates
- DNS and NTP
- identity services
- antivirus updates
- remote maintenance
- logging
- file exchange
The question is not whether OT should use these services.
The question is:
How do we provide them without turning IT into a direct path into OT?
A simplified architecture looks like this:
Corporate IT
|
Firewall
|
+----------------------+
| Industrial DMZ |
| Level 3.5 |
+----------------------+
|
Firewall
|
OT
The DMZ becomes the controlled boundary between the two environments.
Not just another VLAN.
Not just another subnet.
A service boundary.
WSUS Is a Simple Example
Imagine several Windows systems inside OT:
- engineering workstations
- HMI servers
- SCADA servers
- historian systems
They need updates.
The easiest solution is:
OT Host
|
v
Corporate WSUS
It works.
But now OT depends directly on a Level 4 service.
A cleaner approach is:
Microsoft Update
|
v
Corporate WSUS
|
v
DMZ WSUS
|
v
OT Windows Hosts
Now OT systems only need access to the WSUS service in the DMZ.
The DMZ server handles the upstream relationship.
That is an important difference.
Instead of giving OT access to the corporate network, we give OT access to one specific service.
Think in Services, Not Networks
This is probably the simplest way to understand Level 3.5.
Avoid this:
OT ---> Corporate Network
OT ---> Internet
Prefer this:
OT ---> DMZ WSUS
OT ---> DMZ NTP
OT ---> DMZ DNS
OT ---> DMZ Jump Host
OT ---> DMZ File Gateway
The first model grants network reachability.
The second grants controlled service access.
That is a much healthier security model.
Active Directory Is Where Things Get Complicated
Identity is harder.
It is tempting to say:
“We already have a corporate domain. Why build something separate?”
The problem is that Active Directory is not just a login service.
It may also involve:
- Kerberos
- LDAP
- DNS
- Group Policy
- service accounts
- machine accounts
- privileged credentials
Once OT becomes deeply dependent on enterprise identity, the boundary between the two environments becomes much weaker.
Putting a corporate domain controller directly into a lower OT zone is not really solving the problem.
It is moving enterprise trust deeper into OT.
Depending on the environment, a better design may involve:
Corporate Identity
|
v
Industrial DMZ
|
v
OT Identity Services
|
v
OT Systems
This could mean a separate OT domain, carefully restricted trust, or another controlled authentication design.
There is no single Active Directory architecture that fits every plant.
But the principle is simple:
Enterprise identity should not quietly become a bridge into OT.
Even NTP Deserves Attention
Allowing an HMI or PLC to reach a public NTP server may look harmless.
After all, it only needs the time.
But architecturally, this still means:
OT Device ---> Internet
A cleaner design is:
External Time Source
|
v
Enterprise / DMZ NTP
|
v
OT Time Source
|
v
HMI / SCADA
The same logic applies to DNS, software repositories, antivirus updates, logging, and other shared services.
The closer a system is to the physical process, the fewer external dependencies it should normally have.
Remote Access Is Another Common Shortcut
Maintenance teams need access.
That is normal.
But this:
Engineer Laptop ---> OT Server
creates direct trust between environments.
A stronger design is:
Engineer
|
v
DMZ Jump Host
|
v
OT Management Host
|
v
Target System
Now we have a place to enforce:
- MFA
- privileged access
- session logging
- approval workflows
- time-based access
The DMZ is not simply forwarding traffic.
It is breaking direct trust.
A DMZ Is Not the Same as a VLAN
Another common assumption is:
“IT and OT are already on different VLANs, so they are isolated.”
Not necessarily.
This:
IT VLAN
|
Router
|
OT VLAN
is not automatically equivalent to this:
IT
|
Firewall
|
Industrial DMZ
|
Firewall
|
OT
The important question is not whether the networks use different subnets.
It is:
What communication paths are actually allowed between them?
A real DMZ normally gives you a place to enforce policy, inspection, logging, proxies, jump hosts, and other controls.
A VLAN gives you segmentation.
A DMZ gives you a security boundary.
Keep the Firewall Rules Boring
A good IT/OT firewall policy should be easy to explain.
For example:
OT Windows Hosts -> DMZ WSUS
DMZ WSUS -> Upstream WSUS
OT Hosts -> DMZ NTP
Admin Workstation -> DMZ Jump Host
DMZ Log Relay -> SIEM
What you do not want is:
OT-NETWORK -> CORPORATE-NETWORK -> ANY
If the DMZ exists but broad rules allow everyone to bypass it, then it is mostly decoration.
A good starting point is still:
DENY BY DEFAULT
Then allow only the specific services that have a clear operational reason.
The Question I Like to Ask
When reviewing an IT/OT architecture, one question quickly reveals whether the segmentation is meaningful:
If the DMZ is compromised, how far can an attacker move?
If the answer is:
“Anywhere in OT.”
then the DMZ is not doing enough.
If the answer is:
“Only to a small number of explicitly permitted services.”
then the architecture is much healthier.
The same question works in reverse.
If an OT workstation is compromised, how much of corporate IT can it reach?
Ideally:
very little.
Security First — Without Making Operations Miserable
In OT, I would still put security first.
But “security first” should not mean making everyday operations painful.
A good architecture should make the safe path the normal path:
Engineer
|
MFA
|
Jump Host
|
OT Management Zone
|
Target Device
That is better than forcing engineers to choose between:
secure but unusable
and
convenient but exposed.
The goal should be both.
Final Thought
Purdue Level 3.5 is not really about memorizing another network layer.
It is about deciding where trust stops.
Instead of:
IT <-------------> OT
we want:
IT
|
DMZ
|
OT
with every connection having a clear reason to exist.
WSUS, identity, NTP, DNS, remote access, logging, and file transfer all follow the same principle:
Do not provide broad network access when a narrowly defined service is enough.
That is the real value of the Industrial DMZ.
It lets IT support OT without quietly becoming part of the OT attack path.
Top comments (0)