Industrial DMZ Design and Implementation Guide

Introduction

The Industrial Demilitarized Zone (DMZ) is the security architecture that makes IT/OT integration safe. Business users need access to operational data for reporting, analytics, and planning. Vendors need remote access to support control systems. SCADA systems need to send alarms to enterprise platforms. The data flows between IT and OT are legitimate and operationally necessary.

Without an industrial DMZ, those data flows require direct network connectivity between IT and OT. Direct connectivity is the condition that allowed Colonial Pipeline ransomware to threaten OT operations. It is the pathway that allows an enterprise Active Directory compromise to become an OT network compromise. It is the attack surface that every threat actor targeting industrial organizations attempts to exploit.

The industrial DMZ does not eliminate IT/OT data exchange — it restructures it. Instead of direct connections, data moves through controlled, monitored intermediary systems in the DMZ. Business users access a historian replica, not the OT historian directly. Vendors connect to a jump server, not to OT devices directly. Alarms route through an alarm forwarding server, not through a direct SCADA-to-enterprise connection.

This guide provides a complete reference for designing, implementing, and operating an industrial DMZ — from architecture principles through component selection, data flow design, high-availability configuration, and post-implementation monitoring.

Architecture Principles

Principle 1: No Direct IT-to-OT Connectivity

The industrial DMZ exists to enforce a single rule: no direct network path from the IT network to the OT network. Every IT-OT data exchange must pass through the DMZ. This principle must be absolute — exceptions, justified by operational convenience or vendor requests, consistently become the attack vectors that are exploited in incidents.

Verify enforcement by confirming there is no routing between IT subnets and OT subnets at any layer — not at the firewall, not in the routers, not via management VLANs or shared infrastructure. The absence of direct routing should be demonstrable and tested.

Principle 2: Defense in Depth with Two Firewall Layers

A single firewall at the IT/OT boundary creates a single point of failure. The preferred architecture uses two firewalls — an IT-side firewall and an OT-side firewall — creating a true DMZ zone that is trusted by neither the IT nor the OT network.

Vendor diversity: Where budget permits, use different vendors for the IT-side and OT-side firewalls. A zero-day vulnerability in one vendor's firewall platform does not simultaneously compromise both barriers. Fortinet (IT side) + Cisco (OT side), or Palo Alto Networks (IT side) + FortiGate Rugged (OT side), are common dual-vendor combinations.

Security Level alignment: The IT-side firewall should enforce rules appropriate for the IT network's security level; the OT-side firewall should enforce OT protocol-aware rules appropriate for the OT network's security level. The DMZ zone between them has intermediate trust.

Principle 3: Controlled, Documented Data Flows Only

Every data flow through the industrial DMZ should be:

• Documented in a data flow register with business justification, data type, frequency, and direction
• Implemented through a specific DMZ component designed for that flow type
• Enforced by firewall rules that permit only the specific source, destination, port, and protocol for each flow
• Monitored for anomalies and volume deviations

Undocumented flows should not exist. If a communication is observed traversing the DMZ that is not in the data flow register, it is either a change that was not properly managed, or an unauthorized communication requiring immediate investigation.

Principle 4: DMZ Systems Are High-Priority Security Assets

DMZ systems — jump servers, historian replicas, file transfer servers, patch management systems — are simultaneously accessible from both the IT and the OT network. A compromised DMZ system can be used as a pivot point to attack either environment. DMZ systems must be treated as critical security assets:

• Patched on the same cadence as perimeter security systems (more frequently than OT devices, and without the OT patching constraints)
• Monitored with the same intensity as the firewall infrastructure
• Hardened to the enterprise server baseline or better
• Subject to privilege access management: no shared accounts, all administrative access recorded

DMZ Component Architecture

Component 1: Historian Replica

Purpose: Provides IT users with access to process data without requiring direct access to the OT historian or the OT network.

Architecture: The OT historian (OSIsoft PI, Canary Labs, Ignition Historian) pushes data to a replica historian in the DMZ. The replica is configured to accept a one-directional data push from the OT historian and to allow read-only queries from IT users. IT users never connect to the OT historian directly; they connect only to the DMZ replica.

Data flow design:

• OT historian → DMZ historian replica: Push model; the OT historian initiates the connection outward. The OT-side firewall permits outbound connections from the historian to the DMZ replica on the historian synchronization port. No inbound connections from the DMZ to the OT historian.
• DMZ historian replica → IT users: IT users connect to the replica via the historian's native query interface (PI Web API, Canary web services, Ignition web services) or via OPC UA read-only endpoints. The IT-side firewall permits inbound connections from IT subnets to the historian replica on the appropriate port.

Security configuration:

• The DMZ historian should be a separate physical or virtual server from the OT historian, not a read replica that is accessed directly
• Configure the historian synchronization to push only the tag namespaces required by business users — not the complete OT tag database
• Authentication required for all IT user access to the historian replica
• Logging of all queries to the historian replica for anomaly detection

Component 2: Jump Server (Bastion Host)

Purpose: Provides controlled, recorded remote access to OT systems without allowing direct connectivity from the IT network or the internet to OT devices.

Architecture: The jump server is placed in the DMZ and serves as the sole remote access point for authorized users who need to access OT systems. Remote users connect to the jump server through the remote access gateway. From the jump server, they can initiate connections to authorized OT system destinations.

Security configuration: See TG-014 (Secure Remote Access Architecture) for full jump server design details. In the DMZ context, the critical firewall rules are:

• IT-side firewall: permit inbound to jump server on RDP port (3389) from the remote access gateway IP only. All other inbound to jump server: deny.
• OT-side firewall: permit outbound from jump server to authorized OT destination addresses on authorized ports only. No direct IT-to-OT paths through the jump server.

Component 3: File Transfer Server

Purpose: Provides a controlled pathway for transferring files between IT and OT (patch packages, configuration files, reports) with mandatory malware scanning.

Architecture: A file transfer server in the DMZ accepts file uploads from IT and from OT. All files are scanned by an integrated antivirus/anti-malware engine before being made available in the DMZ pickup directory. A separate controlled process (human review or automated policy check) approves files for transfer to the destination environment.

Data flow design:

• IT → DMZ file transfer server: IT users upload files to an IT-facing share on the file transfer server. The server scans files on upload. Approved files are placed in a DMZ pickup area.
• DMZ pickup → OT: Either an automated process (scheduled pull from an OT management server) or a manual process (OT personnel log into the jump server and retrieve approved files) moves files from the DMZ into the OT environment. The OT-side firewall permits only the specific connection from the OT management server to the DMZ file server.
• OT → DMZ file transfer server → IT: Process data exports, alarm reports, and similar files initiated from OT are pushed to the file server in the DMZ, where they are available for IT retrieval without direct OT access.

Scanning configuration: Deploy multiple antivirus engines (dual-engine scanning catches more than a single engine). Update antivirus signatures on the file transfer server independently of any OT endpoint restrictions. Quarantine all files that generate alerts; do not automatically delete, as investigation may be needed.

Component 4: Remote Access Gateway

Purpose: The internet-facing component that accepts authenticated remote access connections and routes them to the jump server.

The remote access gateway is the component that external users (vendors, remote employees, partners) connect to from the internet. It enforces authentication (including MFA) before any session reaches the jump server. See TG-014 for full architecture.

DMZ placement: The remote access gateway may be placed in the DMZ itself (accessible from the internet via the IT-side firewall with a strict DMZ-facing policy) or in a separate internet-facing zone that feeds into the DMZ. Placing it in the IT-side DMZ keeps all remote access infrastructure in a single monitored zone.

Component 5: Patch Management System

Purpose: Provides a distribution point for security patches and software updates destined for OT systems, without requiring OT systems to connect to the internet or to IT patch management infrastructure.

Architecture: A patch management server in the DMZ receives patches and updates from the IT patch management system (WSUS, SCCM, or vendor update portal). Updates are staged in the DMZ, reviewed and approved, then distributed to OT systems from the OT-side of the DMZ.

Data flow design:

• IT patch management → DMZ patch server: IT-side firewall permits inbound to DMZ patch server from the IT patch management system on the WSUS or SCCM port.
• DMZ patch server → OT Windows servers: OT-side firewall permits connections from the DMZ patch server to OT servers on the WSUS port. OT servers pull from the DMZ patch server rather than from the internet.

Approval process: A manual approval step between patch receipt in the DMZ and distribution to OT systems provides a review point. Security reviews the patch and vendor release notes before it is distributed to OT. This catches patches that may have compatibility issues with OT software before they reach the production environment.

Component 6: Alarm and Event Forwarding Server

Purpose: Routes process alarms and OT security events to enterprise monitoring and notification systems without requiring bidirectional access between the enterprise network and the OT alarm systems.

Architecture: A forwarding server in the DMZ receives alarm data from the OT environment (via syslog push from OT devices, or via SCADA alarm export) and forwards summarized or filtered alarm data to the enterprise alarm management, SIEM, or notification platform.

Data flow design: OT SCADA pushes alarms to the DMZ forwarding server (OT-initiated, one-way push). The DMZ forwarding server reformats and forwards to the enterprise platform (IT-initiated pull or push, depending on the platform).

Filtering: Do not forward all process alarms to the enterprise platform — this produces alarm flood and reduces analyst attention to significant events. Filter to security-relevant events: authentication failures, network anomalies, configuration changes, and high-priority process alarms.

Optional Component: Data Diode

For data flows where the security requirement justifies hardware-enforced unidirectionality — specifically, flows where even the theoretical possibility of a return channel is unacceptable — a data diode provides hardware-enforced one-way transmission.

Data diodes are hardware devices with a transmit-only physical medium (fiber with no receive path) that physically cannot carry traffic in the reverse direction. Common use cases in the industrial DMZ:

• Historian data replication to the IT network where bidirectional communication between historian and IT must be absolutely prevented
• Real-time process data streaming to cloud analytics where cloud access to OT must be hardware-enforced
• Security log forwarding from OT to SIEM where log data must be isolated from any return communication

Major vendors include Waterfall Security Solutions, Owl Cyber Defense, and Garland Technology. Data diodes add cost and complexity but provide a level of assurance that software-defined network controls cannot match.

High-Availability Design

For industrial DMZ infrastructure supporting critical operations, high-availability configuration prevents the DMZ itself from becoming a single point of failure for operational data flows.

Firewall High Availability

Both the IT-side and OT-side firewalls should be deployed in active/passive HA pairs:

• Identical hardware on primary and secondary units
• Synchronized policy and session state between units
• Sub-second failover to the passive unit on primary failure
• Regular HA failover testing (quarterly at minimum) to verify failover functions as expected

HA testing procedure: Simulate primary firewall failure by disconnecting power or triggering a software failover. Verify:

• Failover occurs within the expected timeframe
• Active network sessions (ongoing historian synchronization, active RDP sessions) recover or establish new sessions through the standby
• No permanent traffic drops occur for critical OT→DMZ data flows
• Monitoring alerts correctly identify the failover event

DMZ Server High Availability

Historian replicas and jump servers in the DMZ should have redundancy appropriate for their criticality:

• Historian replicas: active/active with load-balanced reads is optimal; active/passive with synchronization is acceptable
• Jump servers: active/passive pair with shared session recording storage ensures that remote access is not dependent on a single server

Virtual machine infrastructure (VMware vSphere HA, Microsoft Hyper-V with Failover Clustering) simplifies redundancy for DMZ servers.

Resilient Connectivity Design

Ensure the data flows between the OT historian and the DMZ replica, and between the DMZ and IT systems, do not depend on a single network path:

• Dual uplinks from DMZ switches to IT and OT firewalls (port channel or LACP bonding)
• Redundant routing paths where feasible
• Failover configuration tested under simulated link failure

Data Flow Design and Documentation

Data Flow Register

Maintain a data flow register documenting every communication that passes through the industrial DMZ. At minimum, record for each flow:

The data flow register is the authoritative source for firewall rule design. Every rule should correspond to a documented data flow; every documented flow should have a corresponding firewall rule.

Traffic Flow Architecture Diagram

Maintain a current architecture diagram showing:

• IT network, DMZ zone, and OT network
• All firewall interfaces and their IP addresses
• All DMZ components (historian replica, jump server, file transfer, patch management)
• Arrows for each documented data flow with labels indicating protocol and direction
• Zone labels indicating the security level of each zone

The architecture diagram is essential for training, onboarding, and incident response.

Implementation Checklist

Phase 1: Design (4-6 weeks)

• Document current state: all existing IT-OT connectivity
• Define target architecture: zone assignments, component placement, firewall placement
• Define data flows: complete data flow register for all required IT-OT communications
• Select technology: firewalls, historian platform, jump server configuration, file transfer server
• Define high-availability requirements per component
• Design firewall rule set from the data flow register
• Review with operations team: confirm all required data flows are captured

Phase 2: Build and Test in Lab (4-8 weeks)

• Procure hardware: firewalls, servers, switches
• Build DMZ in lab or staging environment
• Configure firewalls with designed rule sets
• Configure DMZ components: historian replica, jump server, file transfer server
• Test all data flows: confirm each flow in the register works as designed
• Test firewall enforcement: confirm flows not in the register are blocked
• Test high availability: failover testing for firewalls and servers
• Test monitoring: confirm logging and alerting function correctly

Phase 3: Staged Production Deployment (4-8 weeks)

• Deploy DMZ infrastructure in production network (monitoring mode initially)
• Migrate historian integration to historian replica
• Migrate remote access to new jump server and remote access gateway
• Enable IT-side firewall enforcement
• Monitor for 2 weeks: review logs for unexpected denials or anomalies
• Enable OT-side firewall enforcement
• Monitor for 2 weeks: confirm no OT data flows are impacted
• Remove any legacy direct IT-OT connections
• Verify no direct IT-OT paths remain in routing tables

Phase 4: Validation and Acceptance

• Network penetration test: verify no direct IT-to-OT paths exist
• Review all DMZ firewall rules against the data flow register
• Confirm session recording is functioning for all jump server sessions
• Confirm historian synchronization latency meets operations requirements
• Confirm monitoring and alerting is active and receiving events
• Operations team sign-off: all required data flows are functioning
• Security team sign-off: DMZ architecture meets the security requirements

Ongoing Operations and Monitoring

DMZ as a High-Value Monitoring Target

The industrial DMZ is the most important network segment to monitor. All IT-OT traffic passes through it. Any lateral movement between IT and OT will be visible in DMZ logs and traffic.

Active monitoring requirements for the DMZ:

• Real-time log analysis for both IT-side and OT-side firewall logs
• Alerting on denied traffic that suggests scanning or unauthorized access attempts
• Volume anomaly detection: significant increases in historian synchronization traffic, unusual file transfer volumes, or high rates of failed authentication attempts
• Session monitoring on the jump server: alert on sessions outside business hours, sessions to unauthorized destinations, or unusually long sessions

DMZ Change Management

Changes to DMZ configuration — firewall rules, component configurations, data flows — should follow the same change management rigor as OT changes. An unauthorized rule change in the DMZ firewall that opens a direct path between IT and OT effectively defeats the architecture. All DMZ changes require documented justification, technical review, and approval before implementation.

Conclusion

The industrial DMZ is the architectural control that makes IT/OT integration safe and manageable. With a properly designed and implemented DMZ, organizations can provide business users with the operational data they need, vendors with the remote access they require, and OT systems with the IT services they use — without creating the direct connectivity pathways that attackers exploit.

The investment in DMZ design and implementation is substantial, but the operational benefits extend beyond security: a well-designed DMZ with a historian replica, file transfer server, and managed remote access is also better infrastructure than the ad-hoc connectivity arrangements it replaces.

Beacon Security provides industrial DMZ design, implementation, and validation services for organizations building or upgrading their IT/OT boundary security architecture. Contact us to design the industrial DMZ appropriate for your environment and business requirements.