Overview
A necessary preliminary condition for securing ICS is the creation of a defensible environment. This might sound trivial at first glance, but the actual amount of effort behind such a simple syllogism is gigantic. Conceptually, the IT/business networks represent to the OT/ICS network a level of threat nearly comparable to the threat of the external internet to the IT/business environment.
Therefore, the creation of a defensible ICS environment is necessarily pending on the segmentation of networks across an enterprise. The question then becomes: how should we perform this segmentation? Following which logic?
The Purdue Model offers substantial help in answering to this question.
What is the Purdue Model?
Designed in the early 1990s at Purdue University, as part of the Purdue Enterprise Reference Architecture (PERA), the goal of the Purdue Model was to define best practices for the relationship between industrial control systems and business networks, in equivalent terms, between the IT and OT environments. The fundamental target was indeed to keep ICS deterministic, by ensuring control networks are not overwhelmed with non-production data.
Overtime, the model grew to include guidance for physical systems architecture and introduced the six network levels of the environment, depicting the systems and technologies that reside at each level:
Levels and Description:
- Level 0 – Physical Processes: Defines actual physical processes, contains sensors, actuators and IIoT devices.
- Level 1 – Basic controls: Devices and systems to provide automated control of a process, cell, line, or distributed control system (DCS) solution. Modern ICS solutions often combine Levels 1 and 0.
- Level 2 – Supervisory controls: Monitoring and supervisory control for a single process, cell, line, or DCS solution. Isolating processes from each other grouping by function, area, or type.
- Level 3 – Industrial Security Zone: Monitoring, supervisory, and operational support for a site or region.
- Industrial DMZ: Boundary line between OT & IT environment, armed with firewalls.
- Level 4 – Business Networks: IT network for business users at local sites. Connectivity to Enterprise-wide area network (WAN) and possibly local Internet access. Direct Internet access should not extend below this level.
- Level 5 - Enterprise Networks: Corporate-level services supporting individual business units and users. These systems are often located in corporate data centers.
As one moves down the hierarchy (from Level 5 to Level 0), devices have more access to critical processes but fewer intrinsic security capabilities. Devices at lower levels are therefore more reliant on network and architectural defences, and those found in the upper levels, to protect them.
It is worth noting, interestingly, how the PERA was never intended to be a cybersecurity reference model. It was conceived to depict best practices for managing the segmentation between the enterprise and industrial segments of networks in industrial sectors. Nevertheless, it has remained prevalent as a conceptual framework in IT/OT security because it shows where security measures can be added.
Purdue Model's Key Features
The breakthrough introduced by the Purdue model is the implementation of a DMZ area, conceived as a boundary point between the IT and OT environments. Traditionally, the standard, and most immediate, security control for ICS was to fully separate them from the IT environment. This measure caused the prevalence of the so-called “air-gap” between IT & OT, rendering communication and integration of the two incredibly complicated, and often unfeasible.
IT and OT environments were divided as compartmentalized boxes, each of those self-absorbed in its own region. However, such an approach would totally disregard enormous advantages offered by a joint integration of the two, such as remote real-time monitoring.
The Purdue model has a visionary approach to the problem, introducing the DMZ and allowing, severely prescreened contacts among the two. A perfect analogy for the DMZ in the real world would be a drawbridge in a mediaeval setting, with the castle representing the OT domain and the surrounding surface the IT one, following along the metaphor.
An ulterior security control was added via enforcing the travel of data only along an “upstream” flow, that meaning means, from lower to upper levels and never vice versa. Data has to travel along each level and cannot skip levels.
Critiques to the Purdue Model
A brilliant aphorism recites “all models are wrong, but some are useful”. Unsurprisingly, this statement can fittingly be applied to the Purdue Model. We previously mentioned how the model was developed in the 90s, and in any technological environment three decades are equivalent to multiple eras. The risk of the model being only an anachronistic relic of the past in today´s enterprises would be, consequently, extremely high. However, the Purdue model has aged surprisingly well, and that is mostly thanks to its conceptual guidelines that are still relevant to this day: the segmentation of environments, the grouping of segmented areas by function instead of by employed technology, the implementation of a DMZ.
The major point of critique and sign of aging of the model in the modern industry is the prescribed hierarchical transit of data featured in the Purdue model: the model originally envisioned an upstream transit of data, from lower levels to upper levels, traversing individual each level on the path. However, as intelligence gets continuously added to devices residing at lower levels, through the achievements of technology, devices placed at low levels can, and should, send fundamental data directly to the cloud, without the need to jump through hoops across multiple levels.
Moreover, the partition between IT & OT, in modern and future environments, can no longer be strictly defined, as the ever-increasing interconnection of the domains brings indispensable competitive advantages to any modern enterprise.
Therefore, an evolution of the Purdue model, undergoing a “conceptual patching process”, would be capable of addressing the issues caused by the evolution of the state-of-the-art in ICS security, while maintaining all strong and useful fundamentals traced by the model.
