Purdue Model and Best Practices for Secure Industrial Control System (ICS) Architecture

Secure ICS Architecture: Purdue Model and Best Practices

In the second part of this series we introduce the Purdue Enterprise Reference Architecture (PERA), other reference models, and best‑practice guidance for protecting critical industrial control systems (ICS).

Review: Challenges of ICS Cybersecurity

ICS inherit an "inherently insecure" nature because they require high availability and lack built‑in security functions. Early IT networks addressed similar challenges by placing perimeter firewalls between trusted LANs and untrusted WANs/Internet.

Protecting ICS demands the same segmentation approach, but the IT/OT boundary now represents an untrusted zone that must be divided using models such as PERA.

Purdue Enterprise Reference Architecture Overview

The Purdue model was created in the early 1990s to define best practices for the relationship between OT and IT networks. Its first iteration consisted of three components: the Purdue Enterprise Reference Architecture, the Purdue Reference Model, and the Purdue Implementation Procedure Manual.

Over time the model evolved to include physical system‑architecture guidance and introduced six network levels that describe the systems and technologies residing at each level.

Purdue Level

Description

Examples

Level 5: Enterprise Network

Enterprise‑wide services that support a single business unit and its users, typically located in the corporate data center.

Servers providing:

Enterprise Active Directory (AD) Internal email Customer Relationship Management (CRM) Human Resources (HR) systems File management Backup solutions Enterprise Security Operations Center (SOC)

Level 4: Business Network

Local‑site IT network for business users, connected to the corporate WAN and possibly local Internet access. Direct Internet access should not be below this level.

Business workstations

Local file/print servers

On‑site telephone system

Enterprise AD replica

IT/OT BOUNDARY (DMZ)

Level 3:

Site Supervision

Monitoring, supervision and operational support for a site or area.

Management servers

Human‑Machine Interface (HMI)

Alarm servers

Analytics systems

Historian (if applicable site‑wide)

Level 2: Local Supervision

Monitoring and supervisory control of a single process, unit, production line, or Distributed Control System (DCS). Devices are grouped by function, type, or risk.

HMI

Alarm server

Process analytics

Historian

Control room (if scope is a single process)

Level 1: Local Controllers

Devices that provide automated control for processes, units, production lines, or DCS solutions. Modern ICS often combine Level 1 and Level 0.

Programmable Logic Controllers (PLC)

Control processors

Programmable relays

Remote Terminal Units (RTU)

Process‑specific micro‑controllers

Level 0: Field Devices

Sensors and actuators for batteries, production lines, processes, or DCS solutions, usually paired with Level 1 devices.

Basic sensors/actuators

Smart sensors/actuators using field‑bus protocols

Intelligent Electronic Devices (IED)

Industrial Internet of Things (IIoT) devices

Communication gateways

Other field instruments

Generally, as you move down the hierarchy (from Level 5 to Level 0) devices gain more direct access to critical processes but lose inherent security functions, making lower‑level devices dependent on network and architectural defenses provided by higher‑level devices.

PERA was never intended as a cybersecurity reference model; it describes best practices for separating enterprise and industrial networks. Nevertheless, it remains popular as a conceptual framework for IT/OT security because it highlights where security controls can be inserted.

A key aspect of PERA is the boundary between Levels 0‑3 (OT) and Levels 4‑5 (IT). Historically, administrators tried to eliminate any interconnection between the two environments, creating an “air gap.” Growing demand for OT data and cloud‑based services forced the use of firewalls that carefully mediate traffic into a demilitarized zone (DMZ), effectively removing the pure air‑gap.

Debate: Purdue’s Role in Modern ICS Security

Security professionals often say, “All models are wrong, but some are useful.” The Purdue model, conceived in the 1990s, has limitations given today’s technology and business objectives. Increased remote access to OT reduces labor costs and enables analytics, but also expands the attack surface.

Critics argue that the model’s strict segregation no longer fits a world where real‑time OT data is needed and cloud services are integrated. At the 2019 S4 conference, Joel Langill and Brad Hegrat debated whether the Purdue model is “dead.” Hegrat claimed it is dead because “fusion killed it,” while Langill acknowledged that, although the architecture may be outdated, it was the first model to show how parts should be layered and interoperate.

Both sides present valid points, yet the SANS Institute consensus is that PERA remains a useful conceptual framework because it was one of the first to classify control‑system components with a clear taxonomy.

SANS ICS410 Reference Model

SANS extended the Purdue model and other frameworks to create the publicly available ICS410 Reference Model, which adds explicit execution boundaries to place security controls within a defensible network architecture.

Key advantages of the ICS410 model:

Introduces the concept of multiple cells/lines/processes that can be templated and scaled across sites.

Includes WAN communication controls.

Incorporates security systems.

The model further refines Purdue levels (e.g., splitting Level 3 into management servers, HMI, engineering workstations, test systems, security operations, remote access) and defines multiple DMZs, requiring all IT‑OT connections to terminate in a DMZ.

It also adds secondary enforcement boundaries between Levels 2 and 3 to protect lower‑level devices from malicious actors that have breached higher layers.

Review of ICS Security Standards

Building on PERA, numerous standards provide guidance for protecting industrial control systems, including:

NIST Cybersecurity Framework (CSF)

NIST SP 800‑82 (Guide to Industrial Control Systems Security)

ISA/IEC 62443 (Security for Industrial Automation and Control Systems)

NERC CIP (Critical Infrastructure Protection)

TSA Pipeline Security Guidelines

CISA Critical Infrastructure Sectors Guidance

These publications share core concepts such as asset management, risk assessment, network segmentation, incident response, identity and access management, data protection, vulnerability management, and monitoring.

Application Principles: Best Practices for Modern ICS Network Security Architecture

Because ICS environments lack inherent security features and must maintain continuous, deterministic operation, the most effective protection starts with a robust, segmented network architecture, as emphasized by Purdue, NIST SP 800‑82, IEC 62443, and the SANS ICS410 model.

Firewalls should be placed between Levels 3 and 4 to control traffic entering the OT network, allowing only the minimum required communications.

Additional enforcement boundaries between Levels 2 and 3 protect management systems from site‑level attacks and prevent lateral movement between field sites. These boundaries are often implemented with router access‑list rules rather than traditional firewalls to avoid disrupting legitimate traffic.

Multiple DMZs with dedicated purposes should mediate remote, cloud, and Internet access between the business and OT networks.

Other practical recommendations include:

Levels below 4 should never have direct Internet access.

Operators may use a separate business workstation for email, Internet, and printing.

Active Directory can be used for OT network management but must be isolated from the corporate AD and placed in Level 3.

Enforce default‑deny firewall policies, permitting only required traffic.

Require multi‑factor authentication for all OT network access.

Provide secure mechanisms for inbound/outbound file transfer scanning.

Maintain dedicated anti‑virus and patch management infrastructure for OT.

Log and monitor all traffic crossing control network boundaries.

As cloud‑based management systems become more common, devices that must communicate with the cloud should be placed in a dedicated zone with strictly limited network access.

The guidance presented here covers only a portion of the extensive best‑practice landscape; ongoing series installments will dive deeper into specific security measures, including enforcement boundary implementation and DMZ configuration.

Glossary

Customer Relationship Management (CRM)

A central repository for storing customer data, tracking interactions, and sharing information across an organization.

Security Operations Center (SOC)

A dedicated facility that monitors, assesses, and protects enterprise information systems, including networks, servers, endpoints, and applications.

Human‑Machine Interface (HMI)

The interface that allows humans to interact with machines, typically a screen or touchscreen that connects operators to equipment in an ICS.

Programmable Logic Controller (PLC)

A solid‑state control system with programmable memory used for I/O control, logic, timing, PID control, communication, and data handling.

Remote Terminal Unit (RTU)

A multi‑purpose device deployed in industrial environments for remote monitoring and control, similar to a PLC but often with its own processor, memory, and storage.

Intelligent Electronic Device (IED)

A device added to SCADA or DCS systems to provide advanced power automation functions such as breaker control, capacitor switching, and voltage regulation.

Industrial Internet of Things (IIoT)

Sensors, instruments, machines, and other devices networked together using Internet connectivity to enhance industrial and manufacturing processes.

For further discussion, join the knowledge‑sharing communities listed at the end of the original article.