Defense in Depth in Distributed Control Systems (DCS)

In January 2024 the FrostyGoop malware passed undetected through antivirus systems, blending into normal traffic on port 502. It used the Modbus TCP protocol to directly manipulate values on heating plant controllers in Lviv - cutting off heating to over 600 residential buildings at temperatures reaching -20 degrees C. The attack was possible because the network was not segmented - the attackers had direct access from the internet to the process controllers.

This is a case where a single security layer (the perimeter firewall) failed - and there was nothing behind it. Defense in Depth exists so that when one layer fails, the entire system survives.

Sources: Waterfall Security 2025, SANS ICS/OT 2025, NIST CSF 2.0

In this article we show the practical application of Defense in Depth in Distributed Control Systems (DCS), incorporating the zones and conduits concept defined in the IEC 62443 standard - as well as newer approaches: microsegmentation and Zero Trust in OT.

What Is a Distributed Control System?

Distributed Control Systems (DCS) are a control architecture used in industries such as:

• Oil refineries
• Water and wastewater treatment plants
• Power plants
• Chemical plants
• Automotive production lines
• Pharmaceutical plants

A DCS supervises production systems within a defined geographic area, integrating multiple interconnected subsystems. A centralized supervisory control loop mediates between groups of local controllers whose shared task is to execute the entire production process.

Key DCS Architecture Characteristics

Element	Function	Purdue Level
Supervisory controller (control server)	Communication with devices via the control network	Level 3
Supervisor	Sending setpoints, collecting data from field controllers	Level 2-3
Distributed controllers	Regulating process device operation based on server commands and sensor data	Level 1
Fieldbus networks	Eliminating point-to-point wiring, field device diagnostics, executing control algorithms	Level 0-1

System modularization within a DCS reduces the impact of a single failure on the entire system. In modern implementations a DCS cooperates with corporate IT networks, providing visibility into production activities.

IEC 62443 - Zones and Conduits in the DCS Context

The IEC 62443 standard defines a security zone as a group of logical or physical assets that share common security requirements. A conduit is a logical or physical group of communication channels connecting two or more zones.

In DCS practice this translates to the following breakdown:

IEC 62443 Zone	DCS Contents	Security Level (SL)
Field Zone	Sensors, actuators, field controllers	SL 1-2
Control Zone	DCS servers, engineering workstations, historians	SL 2-3
DMZ Zone	Data exchange servers, update servers, jump hosts	SL 3-4
Enterprise Zone	ERP, email, office systems	SL 1-2

The 2024 revision of IEC 62443-2-1 acknowledges that IACS systems can operate for over 20 years, requiring management of hardware and software without vendor support. The 2025 updates place additional emphasis on microsegmentation below Layer 3, particularly in environments with mixed TCP/IP and non-IP protocol communication.

Applying Defense in Depth - The Network Security Layer

Assuming the organization has already addressed the security management layer (policies, procedures, roles) and physical security (facility access control), we focus on the network security layer. This is where specific architectural decisions determine system resilience to attacks.

1. Network Segmentation into Zones

Dividing the network into distinct zones is the foundation of Defense in Depth. In the DCS context the following breakdown applies:

Field Level Covers devices at Purdue model levels 0, 1, and 2 - sensors, actuators, PLCs, machine controllers, and process controllers. These devices directly participate in operational processes.

Operations Management Level Devices responsible for monitoring and managing the field layer - the equivalent of Purdue model Level 3. This is where SCADA servers, engineering workstations, and data historians operate.

DMZ Zone (Demilitarized Zone) Devices enabling controlled communication between the OT layer and the corporate IT network. It serves as a buffer and control point.

Additional segmentation may be necessary for physical security systems (cameras, access control, VoIP, card readers). More on practical OT network segmentation in a separate article.

2. Boundary Devices Between Zones (Conduits)

Between individual zones we deploy industrial firewalls - devices designed specifically for OT environments. Each such connection constitutes a conduit as defined by IEC 62443 and should have a defined target security level (SL-T).

Industrial firewalls differ from typical IT firewalls:

• They support OT-specific protocols (Modbus, Profinet, EtherNet/IP, OPC UA)
• They operate in harsh environmental conditions (temperature, humidity, dust)
• They enable deep packet inspection (DPI) for industrial protocols

Communication rules must be rigorous - only authorized interactions between adjacent zones are permitted. No field-level device should have direct access to the corporate network.

3. The DMZ as the Boundary Between OT and IT

The DMZ establishes a clear boundary between the OT environment and the corporate network. All communication between these environments passes through designated services in the DMZ.

Because the DMZ is connected to external environments, monitoring and protecting services in this zone is critical. Undetected penetration into the DMZ can open a path to the entire OT environment. The Colonial Pipeline case showed that even the loss of IT systems (MES/billing) in the DMZ can force OT operations to shut down.

4. IIoT Layer Protection

In modern DCS systems Industrial IoT devices are increasingly common. Their integration requires additional security measures:

• Routing IIoT communication through the DMZ boundary firewall
• Monitoring the IIoT platform through cybersecurity services in the DMZ
• Detecting anomalies in IIoT device communication
• Isolating IIoT devices from critical control systems

Evolution: Microsegmentation and Zero Trust in OT

Traditional segmentation divides the network into a few large zones. Microsegmentation goes further - it creates granular access policies at the level of individual devices or device groups. In July 2025 CISA published the guide “Journey to Zero Trust: Microsegmentation,” explicitly identifying microsegmentation as a foundation of Zero Trust architecture - including in OT environments.

Approach	Granularity	OT Implementation	Limitations
Traditional segmentation	VLANs + firewalls between Purdue zones	Industrial firewalls at zone boundaries	Traffic within a zone is not controlled
Microsegmentation	Per-device or per-flow policies	Agentless (network-based) - OT devices do not support agents	Requires complete inventory and flow mapping
Zero Trust OT	”Never trust, always verify” on every connection	Built on top of Purdue - VPN/SRA with MFA at each hop	OT protocols (Modbus, S7comm) do not support authentication

In practice, microsegmentation in OT requires:

1. Complete asset inventory - you cannot segment what you cannot see
2. Mapping legitimate communication flows (baseline)
3. Passive OT protocol monitoring (Claroty, Nozomi, Dragos) - anomaly detection without impacting the process
4. Gradual implementation - monitor first, then enforce

Defense in Depth Implementation Checklist for DCS

• Asset inventory of all devices on the OT network (sensors, PLCs, servers, workstations)
• Device classification according to the Purdue model levels
• Network division into zones with clear boundaries
• Conduit definitions and their target security levels (SL-T)
• Industrial firewall deployment between zones
• DMZ zone configuration between OT and IT
• Communication rules between zones defined and enforced
• OT network traffic monitoring deployed
• Remote access secured (VPN, MFA, recorded sessions)
• Regular risk assessment per IEC 62443
• Defensive mechanism testing (OT penetration testing)

Practical Implementation

Defense in Depth does not eliminate risk entirely but significantly limits the scope of a potential attack and gives security teams time to respond. Attacks on industrial systems - from Colonial Pipeline to FrostyGoop - show that the absence of layered defense leads to situations where compromising a single point paralyzes the entire operation.

The key is to treat Defense in Depth not as a one-time project but as a continuous improvement process. NIST CSF 2.0 (with the new Govern function) formalizes this approach - linking risk management with the identify-protect-detect-respond-recover cycle. SEQRED helps organizations implement Defense in Depth through IEC 62443 compliance audits and penetration testing of OT environments.

---

Sources:

• IEC 62443 - Zones and Conduits: A Practical Approach to Segmentation
• IEC 62443 in 2025: Network Segmentation Requirements and Changes
• Dragos - ISA/IEC 62443 Concepts
• Security Aspects of Zones and Conduits in IEC 62443 (MDPI)
• ENISA Threat Landscape 2022
• FrostyGoop ICS Malware - Dragos
• Waterfall Security - Learning from 2024’s Top OT Attacks
• CISA - Journey to Zero Trust: Microsegmentation Guidance (2025)
• NIST CSF 2.0
• SANS State of ICS/OT Security 2025