OT Cybersecurity teams have been working within the Purdue Enterprise Reference Architecture since it was created in the mid-1990s. Although not developed as a security model, by mapping the interconnections and interdependencies of the high-level components of typical industrial control systems (ICS), the Purdue reference architecture has provided important guidance for how to defend OT systems. The adoption of numerous IT systems into OT environments, however, has raised questions about the continued relevance of the ICS Purdue model.
The adoption of numerous IT systems into OT environments, however, has raised questions about the continued relevance of the Purdue model.
The Purdue Enterprise Reference Architecture
By way of a quick review, the current Purdue architecture models OT and IT into six functional levels that run from Level 0 to Level 5 and span three zones.
Level 0 — Physical process: This is the physical equipment that actually does the work and is known as the equipment under control. This consists of valves, pumps, sensors, actuators, compressors, etc.
Level 1 — Basic Control: These are the control devices such as programmable logic controllers that monitor and control Level 0 equipment and safety instrumented systems.
Level 2 — Area Supervisory Control: Control logic for analyzing and acting on Level 1 data. Systems include human-machine interface (HMI); supervisory and data acquisition (SCADA) software.
Level 3 — Site Control: This level includes systems that support plant-wide control and monitoring functions. Level 3 systems also aggregate lower level data that needs to be pushed up to higher-level business systems.
Level 4 — IT Systems: Business logistics systems can include database servers, application servers, and file servers.
Level 5 — Corporate Network: A broader set of enterprise IT systems, including connections to the public Internet.
These levels are typically described as creating three logical zones, with Levels 4 and Level 5 comprising the enterprise zone, which is separated from the manufacturing zone (comprising Levels 0 through Level 3) by a demilitarized zone (DMZ). This hierarchical approach has worked extremely well for the last couple of decades to help design OT infrastructure.
Learn about OT cyber security in our A Comprehensive Guide to Operational Technology (OT) Cybersecurity.
What Changes are Impacting the Purdue Model?
In IIoT deployments, data is not constrained by traditional Purdue hierarchies, and in fact, data no longer lives entirely within the enterprise.
A wave of new technologies is now challenging this foundational, hierarchical approach to designing and operating OT systems. These technologies include Cloud Services and 5G wireless networks. More generally, the embrace of numerous IT solutions to enhance traditional OT has created an entire class of solutions typically called the Industrial Internet of Things (IIoT). A standard IIoT reference architecture (See Figure 1 for an example from Gartner) has three parts.
The Edge includes traditional OT equipment such as sensors and actuators, as well as an IIoT gateway that performs a host of tasks such as data filtering, aggregation and storage, and analytics, as well as device management, access control, and shared communication to networks and applications.
The (Cloud) Platform is typically a Platform-as-a-Service (PaaS) that aggregates data storage and analytics, event processing, process orchestration, network communication, and other functions.
The Enterprise supports backend applications such as databases and data warehouses, applications services, etc.
Figure 1: Gartner IoT Reference Architecture
This streamlined architecture seriously challenges the Purdue model by bypassing traditional hierarchical levels and allowing communication directly from physical devices to cloud services or communication consolidated through an IIoT gateway to the Cloud. In IIoT deployments, data is not constrained by traditional Purdue hierarchies, and in fact, data no longer lives entirely within the enterprise. The Purdue model can be considered outdated in these environments.
Industrial IoT (IIoT) and the Purdue Model
Within this new architecture, the IIoT gateway has become a critical security concern because a successful attack and compromise of a gateway could open up the entire OT infrastructure to attack.
OT cybersecurity teams are increasingly being confronted with the need to protect OT environments that include IIoT components. In many ways, this is just a continuation of the long-time trend of incorporating IT into OT but with IT systems now moving further down the traditional Purdue model architectural stack. Level 3 has increasingly become an intermediate layer with both OT and IT components. Within this new architecture, the IIoT gateway has become a critical security concern because a successful attack and compromise of a gateway could open up the entire OT infrastructure to attack.
In traditional OT environments, there are efforts to recognize how the introduction of IIoT impacts the Purdue model, and some organizations have gone to the effort of modifying the traditional Purdue model with IIoT components. For example, the European Union Agency for Cybersecurity (ENISA) has proposed a revised version of the Purdue model (see Figure 2), that recognizes a Level 3-based Industrial IoT (IIoT) platform, which communicates directly with Level 1 IIoT devices. (See Good Practices for Security of the Internet of Things in the context of Smart Manufacturing, November 2018).
Figure 2: Revised Purdue Model from ENISA
But it should be noted that IIoT proponents are focused on leveraging new technologies to deliver secure products and services, and they are not particularly interested in shoehorning their solutions into preexisting architectures. For example, the Industrial Internet Consortium’s IIoT (Volume G4): Security Framework runs almost 200 pages and never mentions the Purdue model.
The Purdue Model for Cyber Security: Final Thoughts
At the end of the day, OT security teams need to operate in a world where business imperatives drive technology investments. A best-case scenario for security teams is to be brought in early enough in the acquisition cycle to raise concerns about security implications.
And to a degree, this is as it has always been. Modify or moving away from the Purdue model does not necessarily mean moving away from ICS security, but it does mean that cyber security needs to be reconsidered at every level and that even levels need to be reconsidered.