ICS Components and Architecture: A Practical Guide to Purdue Levels 0–3 and Secure ICS Design

28

Industrial control systems (ICS) have become the nervous system of modern industry. From manufacturing and energy to water treatment and smart buildings, almost every critical process today is monitored, automated, and optimized by layered control architectures.

For security professionals, control engineers, and architects, one model consistently appears in standards, vendor documents, and reference designs: the Purdue Reference Architecture (Purdue Enterprise Reference Architecture, PERA).

This in‑depth guide for iotworlds.com explains:

• What ICS components and architecture look like in real plants
• How Purdue Levels 0 through 3 map to actual devices and assets
• How to implement each level in a securable architecture, not just a functional one
• How levels and zones work together to define a secure ICS design
• Which devices are typically deployed at each level and zone

Whether you’re designing a new OT network or trying to secure an existing brownfield environment, this article gives you a practical, security‑focused view of ICS components and architecture.

---

1. What Is an Industrial Control System (ICS)?

An Industrial Control System (ICS) is a collection of hardware, software, networks, and procedures used to monitor and control industrial processes. Typical ICS environments include:

• Manufacturing plants
• Power generation and distribution
• Oil & gas and petrochemical facilities
• Water and wastewater treatment
• Pharmaceutical and food production
• Building automation (HVAC, lighting, access control)

ICS combines two worlds:

• Physical world – pumps, valves, motors, sensors, actuators, conveyors
• Digital world – programmable logic controllers (PLCs), remote terminal units (RTUs), SCADA servers, HMIs, engineering workstations, networks

A robust architecture is needed to structure these components in a way that is:

• Reliable – 24/7 availability
• Deterministic – predictable timing and response
• Safe – protects people, environment, and equipment
• Secure – resistant to cyber threats while still operable

That’s where the Purdue Reference Architecture comes in.

---

2. The Purdue Reference Architecture: A Quick Overview

The Purdue Model organizes ICS and IT systems into hierarchical levels. Each level represents a different layer of control, data, and business function.

Typical levels:

• Level 0 – Physical process, sensors, actuators
• Level 1 – Basic control, I/O modules, PLC logic
• Level 2 – Area supervisory control, HMIs, local historians
• Level 3 – Site operations & control center (production management)
• Level 3.5 (DMZ) – Demilitarized zone between OT and IT
• Level 4 – Site business / enterprise applications (ERP, MES)
• Level 5 – Corporate / external network, internet

This article focuses primarily on Levels 0–3, where most ICS components live and where secure architecture has the greatest impact on process safety and reliability.

---

3. Why Purdue Levels Matter for Secure ICS Architecture

The Purdue model is more than a diagram. It provides:

• A common language for OT, IT, engineering, and vendors
• A way to group assets by function and risk
• A blueprint for network segmentation and security zones

In modern secure designs:

• Purdue levels usually map to security zones or groups of zones
• Controlled conduits (e.g., firewalled network links) connect zones
• Access, monitoring, and protections are tuned based on the level/zone

Understanding which assets belong to which level, and what controls are appropriate at each, is the foundation of a securable ICS.

---

4. ICS Components by Purdue Level (0–3)

This section categorizes typical assets at Purdue Levels 0 through 3 and explains how they contribute to a secure ICS architecture.

We’ll then connect them to zones and security controls in later sections.

---

4.1 Level 0 – The Physical Process and Field Devices

Purdue Level 0 is where the cyber world meets the physical process. It includes:

• The process itself – tanks, pipes, reactors, turbines, conveyors
• Sensors – measure temperature, pressure, flow, level, position, vibration
• Actuators – valves, dampers, relays, solenoids, contactors
• Drives – variable frequency drives (VFDs), servo drives, soft starters
• Motor control centers (MCCs) and local panels

4.1.1 Typical Level 0 Assets

Common devices and components:

• Analog sensors: 4–20 mA, 0–10 V signals (pressure transmitters, thermocouples, RTDs)
• Digital sensors: limit switches, proximity sensors, optical sensors
• Actuators: control valves, on/off valves, motor starters, dampers
• Intelligent field devices: smart transmitters with HART, Foundation Fieldbus, Profibus PA
• VFDs and servo drives: speed control for motors, often with Ethernet or fieldbus interfaces
• Local safety devices: hardwired E‑Stops, safety relays, light curtains, safety interlocks

Most Level 0 devices are not IP addressable themselves (especially in legacy plants). When they are, they may use:

• Industrial Ethernet (e.g., Profinet, EtherNet/IP)
• Fieldbuses (e.g., Profibus, CAN-based buses, DeviceNet)

4.1.2 Security Characteristics and Risks at Level 0

Historically, Level 0 was considered “unhackable” because it consisted of analog wiring and hardwired logic. That’s no longer true:

• Smart transmitters and drives may run embedded firmware and be reachable over digital buses.
• Manipulation of sensor values or actuator commands can directly affect safety and process quality.
• Many Level 0 devices lack strong authentication or modern crypto, and firmware updates can be weakly controlled.

Attack examples:

• Changing setpoints in smart transmitters (e.g., over HART or fieldbus)
• Tampering with VFD parameters to damage motors or processes
• Spoofing or manipulating fieldbus communications

4.1.3 Implementing a Securable Architecture at Level 0

At Level 0, you can’t install antivirus on a valve. Instead, secure architecture focuses on:

1. Segmentation and Isolation via Controllers (Level 1)
   • Limit who and what can send commands to Level 0 via PLCs, remote I/O, or drives.
   • Use cell/area zones so a compromise in one area doesn’t spread plant-wide.
2. Protocol-Aware Protection at Higher Levels
   • Apply deep packet inspection (DPI) firewalls and IDS/IPS for industrial protocols between Level 2/3 and Level 1/0.
   • Enforce allow‑list rules for which systems can modify device parameters.
3. Physical and Procedural Security
   • Lock cabinets and junction boxes.
   • Control portable device access (e.g., handheld configurators, laptops connected via HART modems).
   • Enforce change management for any field device parameter changes or firmware updates.
4. Resilient Design Patterns
   • Use diverse sensors or voting (e.g., 2oo3 architectures in safety systems).
   • Avoid single points of failure where a single compromised sensor could drive unsafe behavior.

---

4.2 Level 1 – Basic Control, PLCs, RTUs, Remote I/O

Purdue Level 1 is the basic control layer. It executes control logic, reads inputs from Level 0, and sends outputs back to Level 0 devices.

4.2.1 Typical Level 1 Assets

Key Level 1 components include:

• PLCs (Programmable Logic Controllers)
  • Main workhorses of discrete and process automation.
  • Run ladder logic, function block diagrams, structured text, etc.
• RTUs (Remote Terminal Units)
  • Often in SCADA environments (pipelines, power grids, water systems).
  • Designed for remote, harsh environments, sometimes with built‑in telemetry.
• DCS controllers
  • In process industries, part of a Distributed Control System.
  • Handle continuous processes, often with vendor-specific hardware/software.
• Remote I/O modules
  • Distributed input/output racks connected via fieldbus or Ethernet.
  • Interface field signals (Level 0) to controllers (Level 1).
• Local controller networks
  • Industrial Ethernet (Profinet, EtherNet/IP, Modbus TCP, etc.)
  • Legacy fieldbuses (Profibus DP, Modbus RTU, etc.)

4.2.2 Security Characteristics and Risks at Level 1

Level 1 devices are programmable and often networked. Compromises here can:

• Change control logic (PLC/RTU code)
• Bypass interlocks or alarms
• Cause unsafe or damaging behavior in Level 0

Common issues:

• Default or weak passwords on PLCs and RTUs
• Insecure legacy protocols (cleartext, no auth)
• Unauthenticated firmware uploads and backups
• Engineering workstations with unrestricted access to all controllers

4.2.3 Implementing a Securable Architecture at Level 1

For Level 1, security hinges on strict access control, segmentation, and change management.

Key practices:

1. Cell/Area Zones Around Controllers
   • Group PLCs, RTUs, and remote I/O for a given process area into a dedicated cell/area zone.
   • Use an industrial firewall at the boundary to limit communication to known, necessary peers (e.g., specific HMIs, historians, engineering stations).
2. Hardened Controller Configuration
   • Change default passwords; enforce strong authentication where supported.
   • Disable unused services and ports on controllers.
   • Use role-based access and separate accounts for engineering vs. operations.
3. Controlled Logic Changes
   • Allow program changes only from approved engineering workstations in Level 2 (or dedicated secure jump hosts).
   • Require documented change management (tickets, approvals, backups).
   • Log logic downloads and parameter changes.
4. Secure Firmware and Backups
   • Validate and verify firmware images from trusted sources.
   • Store controller backups in a secured repository (e.g., at Level 3) with access controls.
   • Use checksums/hashes to detect tampering.
5. Monitoring and Anomaly Detection
   • Monitor controller traffic for:
     • Unexpected write commands
     • Unusual firmware uploads or reboots
   • Use OT-aware intrusion detection systems that understand PLC/RTU protocols.

---

4.3 Level 2 – Area Supervisory Control and HMI Layer

Purdue Level 2 provides supervisory control and visualization for a plant area or cell. It’s where operators interact with the process day‑to‑day.

4.3.1 Typical Level 2 Assets

Key Level 2 components include:

• HMIs (Human-Machine Interfaces)
  • Operator stations, panel PCs, multi‑screen consoles.
  • Show process graphics, trends, alarms, and allow operator commands.
• Area Supervisory Servers
  • Local SCADA or DCS servers managing a process area.
  • May host alarm servers, trending, real-time databases.
• Local historians
  • Collect and store time-series process data from Level 1 controllers.
  • Provide data for reports, analytics, and troubleshooting.
• Engineering workstations (EWS)
  • Sometimes placed logically at Level 2 (or split between Levels 2 and 3).
  • Used to develop, download, and troubleshoot controller logic and HMI screens.
• Application servers
  • Batch managers, recipe servers, reporting servers specific to a production area.
• Local ICS network switches
  • Managed switches forming the control network for one area/line/cell.
  • Often used for VLAN segmentation of sub‑zones.

4.3.2 Security Characteristics and Risks at Level 2

Level 2 is typically made up of general-purpose operating systems (e.g., Windows, Linux) and is:

• More flexible, but also more vulnerable to traditional IT threats
• Often used by multiple users and vendors (operators, engineers, support)
• Frequently the pivot point for attackers moving from IT to OT or across OT zones

Risks include:

• Malware infections (ransomware, trojans) via USB, phishing (for EWS with email access), or remote access
• Unauthorized or unsafe commands issued from compromised HMIs
• Manipulation of operator displays (false readings, alarm suppression)
• Credential theft leading to privileged access to Level 1 controllers

4.3.3 Implementing a Securable Architecture at Level 2

To secure Level 2, treat it as critical infrastructure IT with ICS-specific constraints:

1. Dedicated ICS Network Segmentation
   • Place Level 2 hosts into dedicated OT VLANs or subnets.
   • Segment different areas/cells with firewalls or ACLs; avoid flat, plant‑wide broadcast domains.
2. Hardened Endpoints and Servers
   • Apply OS hardening baselines tuned for ICS (minimal services, local firewalls, restricted accounts).
   • Deploy ICS-compatible endpoint security (AV/EDR) with tested exclusions and low-impact policies.
   • Implement application allowlisting (e.g., AppLocker, WDAC, or third-party tools) to block unapproved software.
3. Restricted Internet and IT Access
   • Disallow direct internet access from HMIs/EWS in almost all cases.
   • Route necessary vendor remote support through controlled jump hosts and OT DMZs (Level 3.5).
   • Use web proxies and strict firewall rules if any outbound traffic is required.
4. Strong Identity and Access Management
   • Use role-based accounts: separate operator, engineer, and admin roles.
   • Minimize local admin rights; use just-in-time elevation when needed.
   • Log and monitor interactive logons, especially on engineering workstations.
5. Backup and Recovery
   • Regular, tested backups of HMI configurations, area servers, and historian data.
   • Offline or immutable backup copies to defend against ransomware.
6. Visibility and Monitoring
   • Centralized log collection from HMIs, servers, and engineering stations.
   • Integration with OT-aware SIEM or security monitoring toolsets.
   • Monitoring for:
     • New/unapproved software installations
     • Unexpected remote connections
     • High-risk changes in engineering tools

---

4.4 Level 3 – Site Operations, Control Center, and OT Services

Purdue Level 3 is the site operations layer. It coordinates production across multiple lines, cells, or areas, and interfaces with business systems (via a DMZ).

4.4.1 Typical Level 3 Assets

Common Level 3 components:

• Plant or site SCADA servers
  • Aggregate data from multiple Level 2 systems.
  • Provide a consolidated view for control rooms.
• Central historians
  • Long-term data storage for the entire site.
  • Support analytics, reporting, compliance.
• Manufacturing Operations Management (MOM) / MES systems
  • Work order management, production scheduling, performance metrics (OEE).
  • Interface with ERP at Level 4 via DMZ.
• Patch management servers, AV/EDR management, WSUS/SCCM-like infrastructure (if deployed within OT)
• Domain controllers and directory services for OT-specific domains
  • Often separate from corporate AD, or linked via controlled trust relationships.
• OT management and monitoring systems
  • OT network monitoring, vulnerability management tools, backup servers.
• Operator control rooms / central control centers
  • Multi-screen consoles connected to Level 2/3 systems for whole-plant visibility.
• Firewalls and gateways to Level 3.5 (OT DMZ)
  • Critical segmentation devices that control flows between OT and IT.

4.4.2 Security Characteristics and Risks at Level 3

Level 3 is often:

• A mix of OT and IT technologies (servers, databases, Windows/Linux, network services).
• Connected (through a DMZ) to IT enterprise networks and sometimes cloud services.
• The primary target for attackers trying to pivot from IT into OT or vice versa.

Risks:

• Compromised OT domain controllers or patch servers can impact many lower-level systems.
• Weakly configured firewalls or DMZs can allow lateral movement from IT to OT.
• Poorly segregated remote access can expose critical OT systems directly to the internet.

4.4.3 Implementing a Securable Architecture at Level 3

A secure Level 3 design is central to overall ICS security:

1. Strong Segmentation with an OT DMZ (Level 3.5)
   • Do not directly connect Level 3 to IT networks.
   • Use a separate OT DMZ with:
     • Firewalls on both sides (IT↔DMZ, DMZ↔OT Level 3)
     • Separate security policies and monitoring.
   • Route all enterprise–OT data exchanges (historian replication, MES/ERP sync, remote vendor access) through the DMZ.
2. OT-Centric Identity and Policy
   • Use an OT-specific Active Directory (or equivalent) for ICS assets.
   • Apply OT-tailored group policies (GPOs) distinct from corporate IT (e.g., different patch schedules, hardening baselines).
3. Hardened and Monitored Infrastructure Services
   • Secure configuration of:
     • Domain controllers
     • Patch management / software distribution servers
     • Central log and monitoring servers
   • Limit admin accounts and implement multi-person control for high-impact changes.
4. Controlled Remote Access
   • Use jump hosts or bastion servers in the OT DMZ for:
     • Vendor remote support
     • Internal OT/IT access to Level 2 systems
   • Require:
     • Strong authentication (MFA where possible)
     • Session recording for vendor sessions
     • Time-bound access with approvals (just‑in‑time access)
5. Security Monitoring and Incident Response Integration
   • Forward logs and alerts from Level 3 systems to both:
     • OT security monitoring team
     • Central SIEM (through DMZ with necessary filtering)
   • Build ICS-specific detection rules:
     • Sudden changes in firewall rules
     • New/unknown services on key OT servers
     • Unusual authentication patterns

---

5. From Levels to Zones: How ICS Networks Are Secured in Practice

The Purdue model focuses on levels. Modern ICS security standards (especially IEC 62443) emphasize:

• Zones – logical groupings of assets with similar security requirements
• Conduits – controlled pathways between zones

In practice, Purdue levels and IEC 62443 zones are combined:

• Levels define vertical layering of control and business functions.
• Zones group assets at similar levels or across levels by:
  • Risk profile
  • Criticality
  • Required protections
• Conduits (firewalls, data diodes, jump hosts, VPNs) mediate flows between zones.

5.1 Typical ICS Zones and Their Relationship to Purdue Levels

Common zones in a secure ICS architecture:

1. Enterprise Zone (Levels 4–5)
   • Corporate IT, business applications, internet access.
   • Not part of this article’s main focus, but important context.
2. OT DMZ (Level 3.5)
   • Sits between enterprise and ICS zones.
   • Hosts:
     • Replicated historians
     • Patch and AV relay servers
     • Jump hosts / remote access concentrators
     • OT–IT data brokers (e.g., MES/ERP integration)
3. Site Operations Zone (Level 3)
   • Plant SCADA, central historians, MES/MOM, OT directory services.
   • Often has one or more sub-zones:
     • OT management zone
     • OT monitoring and security tools zone
4. Area / Cell Zones (Levels 1–2)
   • Group of controllers, HMIs, local historians for a production line or area.
   • Protects each cell so that an incident in one area doesn’t compromise the entire plant.
5. Safety Instrumented System (SIS) Zone
   • Often spans Levels 0–2 but is logically and physically separated from standard control.
   • Contains:
     • Safety PLCs
     • Safety I/O
     • Independent sensors/actuators for safety functions
6. Remote Access / Vendor Support Zones
   • Jump hosts, VPN gateways, and secure remote workstations.
7. Field I/O and Device Zones (Level 0)
   • Where digital (networked) field devices exist.
   • Segmented and protected through Level 1 controllers and industrial firewalls.

---

6. Devices by Level and Zone: A Consolidated View

The following table summarizes typical devices deployed at each Purdue level and how they often map to ICS security zones.

Purdue Level	Typical Zones	Key Devices & Assets	Primary Security Focus
Level 0	Field Device Zones, SIS Zones	Sensors, actuators, smart transmitters, VFDs, MCCs, safety relays, fieldbus segments	Physical & process safety, isolation via controllers
Level 1	Cell/Area Control Zones, SIS Zones	PLCs, RTUs, DCS controllers, remote I/O, controller networks (Profinet, EtherNet/IP, Profibus DP, Modbus), safety PLCs	Controlled access, logic integrity, secure configuration
Level 2	Cell/Area Supervisory Zones, SIS HMI	HMIs, area SCADA/DCS servers, local historians, alarm servers, engineering workstations, line switches	Endpoint hardening, user access control, segmentation
Level 3	Site Operations Zone, OT Mgmt Zone	Plant SCADA, central historians, MES/MOM, OT AD, patch/AV servers, OT monitoring tools, control room workstations	Segmentation from IT, secure services, monitored remote access
Level 3.5	OT DMZ Zone	Historian replicas, jump servers, proxy servers, application gateways, remote access concentrators	Strong firewalling, protocol breaks, unidirectional flows (where needed)
Level 4–5	Enterprise/Business Zones	ERP, corporate AD, email, file shares, cloud access, user endpoints	IT security controls (endpoint, identity, perimeter, monitoring)

This mapping is flexible: in any real plant, you’ll adjust zones based on risk, vendor constraints, and legacy systems. But Purdue levels plus zones give you a structured starting point.

---

7. Designing a Securable ICS Architecture Using Levels and Zones

Now that we’ve mapped components to levels and devices to zones, let’s put it all together into a practical design philosophy.

7.1 Core Principles of a Securable ICS Architecture

1. Segment by Function and Risk
   • Use Purdue levels to separate business IT, operations management, supervisory control, and basic control.
   • Use zones to group assets with similar risks (e.g., a high-criticality safety system vs. a low-criticality utility system).
2. Minimize Conduits and Strictly Control Them
   • Every connection between zones must have a defined purpose, known data flows, and appropriate controls (firewalls, data diodes, VPNs, protocol gateways).
3. Enforce Least Privilege and Need-to-Know
   • Limit which systems and users can talk to which controllers, HMIs, and servers.
   • Avoid “any–any” firewall rules or flat OT networks where one infection can spread unchecked.
4. Harden Endpoints According to Level
   • At Levels 2–3, treat hosts like critical IT servers: patching, endpoint security, hardening.
   • At Levels 0–1, focus on secure configuration, change control, and tightly controlled access paths.
5. Build in Monitoring and Detectability
   • Assume some compromise will eventually occur.
   • Design so that anomalous behavior (e.g., new protocol use, unusual logic changes) is visible and alerting.
6. Respect OT Constraints
   • Availability, determinism, and safety are paramount.
   • Security controls must be tested and tuned to avoid disrupting operations.

---

7.2 Example Secure ICS Architecture (Levels 0–3)

Below is a conceptual walkthrough of how a secure architecture might look from Level 0 up to the OT DMZ.

Level 0/1 – Field and Control

• Zones: Multiple cell/area zones, each containing:
  • PLCs, remote I/O, local field devices (Levels 0–1)
  • Industrial switches and possibly local firewalls
• Conduits:
  • Each cell zone connects upward to Level 2 via:
    • Firewalled industrial switches or dedicated Layer 3 devices
  • No direct connections from Level 0 to Level 3 or IT
• Controls:
  • Controllers accept engineering changes only from specific, authenticated Level 2 workstations.
  • Safety controllers in separate SIS zones, with independent logic and sensors where required.

Level 2 – Supervisory & HMI

• Zones:
  • One or more Area Supervisory Zones:
    • HMIs, local SCADA servers, local historians
  • Possible dedicated Engineering Zone:
    • Engineering workstations, configuration servers
• Conduits:
  • Area zones connect upward to Level 3:
    • To central historians or plant SCADA for aggregated views
  • Engineering zone connections:
    • Tight controls on who can connect to which cell zone and under what conditions
• Controls:
  • Host firewall rules that limit inbound connections.
  • Application allowlisting on HMIs and EWS.
  • No direct internet access; remote support via jump hosts in the DMZ.

Level 3 – Site Operations & OT Services

• Zones:
  • Site Operations Zone:
    • Plant SCADA, central historians, MES/MOM
  • OT Management Zone:
    • Patch servers, backup systems, OT domain controllers
  • OT Monitoring Zone:
    • OT SIEM, IDS, network monitoring
• Conduits:
  • Connections to Level 2 zones for:
    • Data collection and commands (where required)
  • Connections up to OT DMZ (Level 3.5) for:
    • Historian replication
    • MES/ERP data exchange
    • Remote access via jump hosts
• Controls:
  • Strict firewall policies between Level 3 and DMZ.
  • Network segregation between OT management/monitoring and operations systems.
  • Centralized identity for OT with least-privilege access.

Level 3.5 – OT DMZ (Bridge to IT)

• Zones:
  • OT DMZ containing:
    • Historian replicas
    • File transfer gateways
    • Patch/AV update repositories synced from IT
    • Remote access jump hosts
• Conduits:
  • Firewalled connection to IT enterprise networks.
  • Firewalled connection down to Level 3 OT networks.
  • Often no direct inbound sessions from IT to OT; instead, OT initiates connections or uses brokered sessions.
• Controls:
  • Deep inspection and logging of all traffic.
  • Possibly one-way gateways (data diodes) where only data export is needed (e.g., trends to enterprise analytics).
  • Strong remote access controls (MFA, session recording, approvals).

---

8. Practical Security Controls by Level (0–3)

To make this more actionable, here’s a concise mapping of core security controls to Purdue Levels 0–3.

Level 0 Controls

• Physical security (locked cabinets, controlled access)
• Controlled access to field device configuration (via Level 1/2 only)
• Alarm on unexpected parameter or firmware changes (if the vendor supports it)
• Redundant and diverse sensors for critical parameters

Level 1 Controls

• Network segmentation into cell/area zones
• Controller hardening (passwords, disabled services)
• Engineering access restricted to approved workstations
• Logging of logic changes and firmware updates
• ICS-aware IDS monitoring controller network traffic

Level 2 Controls

• OS and application hardening baselines for HMIs and servers
• Endpoint security (AV/EDR) tuned for ICS workloads
• Application allowlisting on HMIs and engineering stations
• Strictly controlled USB and removable media policies
• Role-based access control and monitoring of privileged actions
• No direct internet or corporate network access

Level 3 Controls

• Strong separation from enterprise networks via OT DMZ
• OT-specific AD/domain with hardened domain controllers
• Segmentation of OT management, monitoring, and operations
• Centralized logging and SIEM integration
• Controlled and brokered remote access (jump hosts, VPN gateways)
• Regular vulnerability assessments and patch management cycles tuned to OT

---

9. Common Pitfalls in ICS Architecture (and How to Avoid Them)

Even with a good reference model, real-world implementations often fall into similar traps. Here are common issues and how to mitigate them.

Pitfall 1: Flat OT Networks

Symptom:
All PLCs, HMIs, and servers share one giant subnet or VLAN, with minimal internal segmentation.

Risk:
A single compromised HMI or engineering station can easily reach every controller in the plant.

Fix:

• Implement cell/area zones for different lines or areas.
• Introduce Layer 3 boundaries with ACLs or firewalls between areas.
• Restrict access from engineering stations to only the controllers they need.

---

Pitfall 2: Direct IT–OT Connections Without a DMZ

Symptom:
Corporate IT systems (or even the internet) connect directly to Level 3 or Level 2 hosts.

Risk:
Attackers from IT can pivot into OT; external attacks can hit critical OT systems directly.

Fix:

• Establish an OT DMZ (Level 3.5) between enterprise and OT.
• Route all data exchanges (historian replication, MES/ERP integration, remote support) through the DMZ.
• Use firewalls, proxies, and when possible, unidirectional gateways.

---

Pitfall 3: Uncontrolled Engineering Access to Controllers

Symptom:
Any engineering workstation can connect to any PLC, RTU, or DCS controller at any time.

Risk:
Mistakes or compromises on an engineering station can propagate plant-wide.

Fix:

• Limit which engineering stations can access which controllers.
• Use jump hosts and/or dedicated engineering zones.
• Enforce change management and logging for controller program changes.

---

Pitfall 4: Treating OT Endpoints Like Regular Office PCs

Symptom:
HMIs and servers have:

• Web browsing
• Email clients
• Social media blocking only via soft policies (if at all)

Risk:
Traditional malware (phishing, drive-by downloads, ransomware) can easily infect OT endpoints.

Fix:

• Remove or disable general-purpose productivity tools on OT hosts.
• Enforce internet isolation; route any required outbound access via controlled proxies.
• Implement application allowlisting, not just antivirus.

---

Pitfall 5: Ignoring Legacy Systems and “Special Exceptions”

Symptom:
Old Windows XP HMIs or obsolete PLCs are left fully connected because “we can’t touch them.”

Risk:
They become the weakest link and a primary attack vector.

Fix:

• Place legacy systems into highly segregated zones with tight firewall rules.
• Limit interactive access to these systems via dedicated jump hosts.
• Plan for long-term migration, even if it requires multi-year budgeting.

Frequently Asked Questions (FAQs)

What is the main difference between Levels 0-1 and Levels 2-3 in ICS?

Levels 0–1 deal with direct control of the physical process:

• Level 0: Sensors, actuators, field devices
• Level 1: PLCs, RTUs, DCS controllers, remote I/O

Levels 2–3 handle supervisory control and operations management:

• Level 2: HMIs, local SCADA/DCS servers, local historians
• Level 3: Plant SCADA, central historians, MES/MOM, OT management

From a security standpoint:

• Levels 0–1 are about logic integrity, safe behavior, and isolation.
• Levels 2–3 are about endpoint hardening, segmentation, and secure services.

How do Purdue levels relate to IEC 62443 zones and conduits?

Purdue levels define vertical functional layers (from field devices up to enterprise IT).
IEC 62443 zones and conduits define horizontal groupings and connections based on security requirements.

In practice:

• You map Purdue levels into one or more zones (e.g., a Level 2 area supervisory zone).
• You control communication between zones using conduits (firewalls, gateways).

This combination lets you design a layered architecture with clear boundaries and protections.

Can I still use the Purdue model in modern IIoT and cloud-connected environments?

Yes. The Purdue model is still a valuable logical framework, but you must:

• Extend it to include cloud and remote services (often linked to Level 4/5 via DMZ).
• Treat IIoT gateways and edge devices as part of specific zones and levels (usually around Levels 1–3).
• Maintain the principle of segmentation and controlled conduits even if data leaves the physical plant.

Think of Purdue as the core factory architecture, with IIoT and cloud treated as additional zones connected through secure conduits.

What devices should be placed in the OT DMZ (Level 3.5)?

Common OT DMZ devices include:

• Historian replicas (receiving data from Level 3 and providing read-only access to Level 4)
• File transfer servers or secure transfer services (for patches, logs, configuration files)
• Application gateways (for MES/ERP integration)
• Remote access jump hosts (for vendors and IT staff)
• Patch and AV update relays (mirroring from enterprise repositories)

These devices bridge IT and OT but must be tightly controlled, monitored, and isolated from both sides.

How do I start securing an existing ICS that doesn’t follow Purdue levels?

A practical approach:

1. Inventory your assets – identify controllers, HMIs, servers, field devices, and their connectivity.
2. Logically group them into Purdue-like levels based on function (field, control, supervisory, operations).
3. Define zones around those groups with similar risk.
4. Introduce segmentation – VLANs, firewalls, access controls between zones.
5. Harden endpoints starting with the most exposed and critical ones (Level 2/3 servers, engineering workstations).
6. Plan a roadmap for:
   • Introducing an OT DMZ
   • Consolidating OT identity and management
   • Addressing legacy and high-risk systems

It doesn’t have to be perfect on day one. An incremental, risk-based improvement plan is often the most realistic path.

11. Key Takeaways for Designing Secure ICS Components & Architecture

To close, here are the most important points for ICS components and architecture using Purdue Levels 0–3:

1. Purdue levels give structure; zones give protection
   • Use Levels 0–3 to understand what an asset does.
   • Use zones and conduits to decide how it should be grouped and protected.
2. Assets at Levels 0–1 need indirect security through segmentation and control integrity
   • You can’t install AV on a valve, but you can:
     • Harden the PLC controlling it
     • Restrict who can change its configuration
     • Segment its network zone
3. Levels 2–3 are where classic IT security controls apply – but with OT constraints
   • Harden Windows/Linux hosts, use endpoint security, manage patches.
   • Avoid unnecessary internet exposure and productivity apps on OT hosts.
4. The OT DMZ (Level 3.5) is essential for modern, connected plants
   • It’s the buffer that allows safe data exchange with IT and cloud.
   • Design it deliberately with strict rules and monitoring.
5. Security is a journey, not a one-time project
   • Start with inventory and segmentation.
   • Layer in hardening, monitoring, and secure remote access.
   • Continuously adapt as processes, technologies, and threats evolve.

By organizing your ICS around well-defined components, Purdue levels, and security zones, you can build an architecture that is not only efficient and scalable, but also defensible against modern cyber threats—without compromising the safety and reliability your operations demand.