OT Security Architecture: Defense in Depth for Industrial Networks

Operational Technology (OT) environments — including industrial control systems (ICS), SCADA, DCS, and safety instrumented systems (SIS) — present unique cybersecurity challenges that conventional IT security approaches cannot address. In OT, availability and safety are paramount. A control system that is "secure but unavailable" has failed its primary mission. This article presents a comprehensive defense-in-depth architecture for industrial networks, covering network segmentation, industrial firewalls, unidirectional gateways, jump hosts, remote access security, asset inventory, vulnerability management, and incident response — all aligned with IEC 62443-3-3 zone hardening requirements.

The Defense-in-Depth Layered Model

Defense in depth for OT is organized into six concentric layers, each providing a distinct security control function:

1. Physical Security — Fences, locked server rooms, tamper-proof enclosures, camera surveillance, and access card systems protecting physical access to OT assets.
2. Network Security — Segmentation, firewalls, VLANs, ACLs, and intrusion detection systems controlling network traffic between zones.
3. Endpoint Security — Application whitelisting, antivirus (OT-compatible), USB port control, and secure configuration baselines for HMIs, engineering stations, and servers.
4. Application Security — Secure coding practices, input validation, session management, and authentication controls within SCADA and DCS applications.
5. Data Security — Encryption of historian data, configuration backup encryption, database access controls, and secure data disposal.
6. Process Security — Policies, procedures, change management, personnel training, incident response plans, and third-party security requirements.

Network Segmentation: The L3/L3.5 DMZ Architecture

Network segmentation is the single most effective security control for OT environments. The reference architecture follows the Purdue model with a critical DMZ at the Level 3 (Operations) to Level 4 (Enterprise) boundary.

Level 3 — Operations Network (OT Zone)

This is the core SCADA and control network segment containing:

• SCADA primary and standby servers
• HMI workstations
• Engineering workstations
• Historian server (primary)
• Alarm management server
• Batch management server

All devices in this zone must be managed using OT-specific hardening standards. No direct internet access is permitted. The only egress to Level 4 is through the Level 3.5 DMZ.

Level 3.5 — Industrial DMZ (Buffer Zone)

The DMZ is a physically or logically separate network segment where data is exchanged between OT and IT through controlled, proxied services. Components deployed in the DMZ include:

+-----------------------------------------------------------------------------+
|  DEFENSE-IN-DEPTH: LAYERED OT SECURITY ARCHITECTURE                          |
|                                                                               |
|  +--------------------------------------------------------------+            |
|  |  LAYER 4-5: ENTERPRISE IT NETWORK                              |            |
|  |  +----------+  +----------+  +----------+                      |            |
|  |  |  ERP     |  |  BI/Anal.|  |  Cloud   |                      |            |
|  |  +----------+  +----------+  +----------+                      |            |
|  +--------------------------+-----------------------------------+            |
|                             |                                                    |
|  +--------------------------+-----------------------------------+            |
|  |  INDUSTRIAL DMZ ZONE     |  (Level 3.5)                       |            |
|  |  +---------------------------------------------------------+  |            |
|  |  |   IT-Facing Firewall (North-South)                        |  |            |
|  |  |   Rules: Allow inbound only from DMZ hosts                |  |            |
|  |  +---------------------------------------------------------+  |            |
|  |  +------+ +------+ +------+ +------+ +------+                |            |
|  |  |Jump  | |OPC UA| |Hist  | |Patch | |Log   |                |            |
|  |  |Srvr  | |GW    | |Repl. | |Srvr  | |Coll. |                |            |
|  |  +------+ +------+ +------+ +------+ +------+                |            |
|  |  +---------------------------------------------------------+  |            |
|  |  |   OT-Facing Firewall (Southbound)                         |  |            |
|  |  |   Rules: Only permit DMZ-initiated connections           |  |            |
|  |  +---------------------------------------------------------+  |            |
|  +--------------------------+-----------------------------------+            |
|                             |                                                    |
|  +--------------------------+-----------------------------------+            |
|  |  LEVEL 3: OPERATIONS/SCADA ZONE                               |            |
|  |  +----------+ +----------+ +----------+                       |            |
|  |  |SCADA Srv | |Historian | |Alarm/Mgt |                       |            |
|  |  +----------+ +----------+ +----------+                       |            |
|  |  +----------+ +----------+                                     |            |
|  |  |HMI Stns  | |Eng Workst|                                     |            |
|  |  +----------+ +----------+                                     |            |
|  +--------------------------+-----------------------------------+            |
|                             |                                                    |
|  +--------------------------+-----------------------------------+            |
|  |  LEVEL 0-2: CONTROL AND FIELD ZONE                             |            |
|  |  +------+ +------+ +------+ +------+                          |            |
|  |  |PLC   | |RTU   | |DCS   | |SIS   |                          |            |
|  |  |Zone A| |Zone B| |Zone C| |(Safe)|                          |            |
|  |  +------+ +------+ +------+ +------+                          |            |
|  |  +--+--+   +--+--+   +--+--+                                  |            |
|  |  |Field|   |Field|   |Field|                                  |            |
|  |  |Devs |   |Devs |   |Devs |                                  |            |
|  |  +-----+   +-----+   +-----+                                  |            |
|  +----------------------------------------------------------------+            |
+-----------------------------------------------------------------------------+

Industrial Firewalls

Industrial firewalls differ from enterprise firewalls in critical ways. They must understand industrial application-layer protocols to perform deep packet inspection (DPI) and reject malicious commands that would pass through a conventional firewall:

• Protocol-Aware Inspection — Industrial firewalls (e.g., Claroty, Nozomi, Dragos, Palo Alto OT Security, Siemens Scalance) decode industrial protocols (Modbus TCP, DNP3, IEC 61850, PROFINET, OPC UA, Ethernet/IP) at the application layer. They can detect and block specific function codes, register writes, or setpoint changes.
• Whitelist-Based Rules — Unlike IT firewalls that default-allow and block specific threats, OT firewalls should use a positive security model: default-deny, explicitly allow only known-good traffic patterns (source IP, destination IP, protocol, port, function code).
• Modbus-Specific Filtering Example — A rule might permit only Function Code 03 (Read Holding Registers) from the SCADA server to the PLC, while blocking Function Code 05 (Write Single Coil) on the same path. This prevents unauthorized HMI operators from changing control logic parameters.
• Conduit Firewalling per IEC 62443-3-3 — Each conduit between zones must implement SR 5.1 (Network Segmentation), SR 5.2 (Zone Boundary Protection), and SR 5.3 (General Purpose Person-to-Person Communication Restriction).

Unidirectional Gateways (Data Diodes)

For the highest security requirements (SL 4), unidirectional gateways provide physical one-way data transfer. A data diode is a hardware device that physically prevents any electrical signal from traveling in the reverse direction:

• Optical Data Diodes — Use fiber optic transmitters on the send side and receivers on the receive side. The physical absence of a return path makes it mathematically impossible for any data to flow backward.
• Application Examples — Sending historian data from a nuclear power plant safety zone to the corporate network; transmitting pipeline SCADA data to business intelligence platforms; providing grid operator data to regulatory authorities.
• Protocol Support — Modern data diodes (Owl Cyber Defense, Fox Technologies, Waterfall Security) support OPC UA, Modbus TCP, DNP3, Syslog, and file transfer protocols.
• Limitations — Data diodes are unidirectional only. They do not support any write operation (no setpoint changes, no command execution). For environments requiring bidirectional flow, use a unidirectional gateway with a return path through a separate, secured conduit.

Jump Hosts and Remote Access Security

Secure remote access to OT systems is one of the most challenging requirements in industrial cybersecurity. Every remote connection represents a potential attack vector. The jump host (bastion host) architecture provides a controlled access point:

Jump Host Design Principles

• DMZ Location — Jump hosts are deployed in the Level 3.5 DMZ, never directly in the OT network.
• Hardened OS — Run a minimal, purpose-built OS (typically Windows Server Core or hardened Linux) with no unnecessary services. Remove all compilers, scripting runtimes, and administrative tools not required for the jump function.
• Multi-Factor Authentication (MFA) — All access through jump hosts requires MFA. Time-based one-time passwords (TOTP) via hardware tokens or mobile authenticator apps are preferred over SMS-based MFA.
• Session Recording — All jump host sessions (RDP, SSH) are recorded. Recordings are stored for forensic analysis and compliance auditing (minimum 12 months retention).
• Time-Limited Access — Remote access requests include a defined start and end time. Access is automatically revoked at the scheduled end time. No "standing" remote access is permitted.
• Least-Privilege Credentials — Jump host credentials are separate from corporate credentials. A privileged access management (PAM) solution vaults credentials, rotates passwords after each session, and provides just-in-time (JIT) access.

Remote Access Architecture

  Remote Engineer --[VPN + MFA]---> DMZ Jump Host --[RDP/SSH]---> OT Device
       |                                   |                        |
       | Session recorded                  | Logs to SIEM           | Changes logged
       | Time-limited (4 hrs)              | Access request         | via audit trail
       | Credentials vaulted               | approved by PAM        |

Asset Inventory and Management

You cannot protect what you do not know exists. An accurate, continuously updated asset inventory is the foundation of OT security:

• Automated Discovery — Deploy OT asset discovery tools (Claroty, Nozomi, Dragos, Armis, Tenable OT) that passively listen to network traffic to identify all devices: PLCs, RTUs, HMIs, IEDs, drives, analyzers, switches, and firewalls. Passive discovery is preferred over active scanning, which can disrupt sensitive controllers.
• Inventory Attributes — For each asset, record: vendor, model, firmware version, serial number, IP address, MAC address, OS type, installed patches, role (controller, HMI, server), and security zone assignment.
• Firmware Version Tracking — Specifically track firmware versions for embedded devices. Cross-reference with vendor security advisories (Rockwell PSIRT, Siemens SIRT, Schneider PSIRT) to identify vulnerable firmware versions.
• Configuration Baseline — Maintain known-good configuration baselines for all critical assets. Use configuration management tools (Tripwire, SolarWinds NCM) to detect unauthorized configuration changes.
• End-of-Life/End-of-Support Monitoring — Flag assets that are past vendor end-of-life (EOL) or end-of-support (EOS). These devices cannot receive security patches and require compensating controls or replacement planning.

Vulnerability Management for OT

OT vulnerability management differs fundamentally from IT vulnerability management. Patching in OT must account for availability and safety impacts:

Incident Response for ICS

An OT-specific incident response plan must address scenarios unique to industrial environments:

1. Preparation — Develop OT-specific playbooks for common scenarios: ransomware affecting HMI workstations, unauthorized PLC program modification, denial of service against SCADA servers, insider threat manipulating controller logic. Maintain offline, air-gapped backups of controller programs and configurations.
2. Identification — OT security monitoring tools (NDR, host-based monitoring, SIEM correlation) detect anomalies. Key indicators: unexpected PLC program download, HMI pointing to wrong server, unknown device on the control network, excessive Modbus write requests.
3. Containment — Pre-define containment actions by scenario. For a confirmed PLC compromise: isolate the PLCs L2 segment at the managed switch, fail over to the redundant controller if available, switch to manual operation at the field level. For a SCADA server ransomware infection: disconnect the server from the control network, fail over to the standby server, and re-image the affected server.
4. Eradication — Remove the threat. For malware: re-image affected workstations/servers from known-good gold images. For unauthorized PLC code: restore the last known-good firmware and program from offline backup. Verify program integrity using checksum comparison.
5. Recovery — Restore systems in a controlled sequence: start with critical safety systems, then primary controllers, then SCADA servers, then HMI stations, then supporting infrastructure. Verify each layer functionality before proceeding to the next.
6. Lessons Learned — Conduct a post-incident review within 72 hours. Update security controls, playbooks, and training based on findings. Share anonymized threat intelligence with sector-specific ISACs (Information Sharing and Analysis Centers).

IEC 62443-3-3 Zone Hardening Requirements

IEC 62443-3-3 defines System Requirements (SRs) for zone hardening. The most critical SRs for OT network architecture include:

• SR 5.1 — Network Segmentation — The system shall separate IACS networks from other networks using controlled interfaces (firewalls, VLANs, VRFs).
• SR 5.2 — Zone Boundary Protection — All communication crossing a zone boundary shall pass through a conduit that enforces access control and traffic filtering.
• SR 5.3 — General Purpose Person-to-Person Communication Restriction — General purpose communication services (email, web browsing, instant messaging) shall not be permitted on IACS zones without explicit conduits and security controls.
• SR 3.1 — Software Integrity — The system shall verify the integrity of software before execution. Implemented through application whitelisting and code signing verification.
• SR 7.3 — Backup and Recovery — The system shall maintain backups of all configuration data and support recovery to a known-good state within defined time objectives.

ASP OTOMASYON A.Ş. and its subsidiaries OPCTurkey and ASP Dijital provide end-to-end industrial engineering solutions for process automation, data operations and AI.

---

References & Further Reading

1. IEC 62443-3-3 — System Security Requirements and Security Levels — International standard defining foundational requirements (FRs) and system requirements (SRs) for OT zone hardening, including network segmentation, access control, and system integrity.
2. NIST SP 800-82 Rev.3 — Guide to Industrial Control System (ICS) Security — Comprehensive NIST guide covering defense-in-depth strategies, network architecture, remote access security, and incident response for OT environments.
3. SANS — Defense-in-Depth Strategies for Industrial Control Systems — Authoritative SANS guide on implementing layered security controls including DMZ architecture, jump hosts, and application whitelisting for OT networks.
4. ISA-95 / IEC 62264 — Purdue Model for OT Network Segmentation — International standard defining the functional hierarchy for OT/IT demarcation, DMZ architecture, and zone-based network segmentation.
5. Waterfall Security — Unidirectional Security Gateways for OT — Official technical documentation on data diode technology for physically enforced one-way data transfer in high-security OT environments.