What's The Fuss About The Purdue Model?

Author photo: Eric Cosman
ByEric Cosman
Category:
Technology Trends

Zones and Levels in Automation Systems Cybersecurity

It seems that every few weeks we see an article, blog post, or opinion piece about whether the Purdue model is still relevant and useful in industry. In many cases, this discussion occurs in the context of cybersecurity. Moreover, this is not a recent phenomenon. Even a cursory Internet search returns links to articles going back as far as 2016. This length of coverage and level of interest makes one wonder what all the fuss is really about. Why are so many people concerned about whether a reference model that was developed decades ago should still be used?

Purdue Model

No doubt some of the interest is driven by the fact that models and concepts originally developed as part of the Purdue Enterprise Reference Architecture (PERA) have since been adopted and adapted for use in industry standards, beginning with ISA-95 (IEC 62264). In most cases, the principal focus has been on the basic reference model that describes the functions in an enterprise as existing at one of several functional levels. The broad adoption of the concepts described in ISA-95 has led to such layered models being nearly ubiquitous, even though interpretations are often inaccurate or inconsistent. Unfortunately, it has become all too common for observers to conflate these levels with the much more physical view of the network hierarchy. 

This misinterpretation has in turn led to even more confusion when considering technology-related trends such as the Industrial Internet of Things (IIoT), where physical hierarchy is much harder to define, if not totally irrelevant. However, the lack of a clear physical hierarchy does not mean that there is no value in having a clear understanding of information flows between functional areas of the architecture.

Reference Models and ISA/IEC 62443

More recently, the development of the ISA/IEC 62443 cybersecurity standards also required some sort of reference or contextual model for the purpose of identifying major functional areas. Early versions of such a model were in fact derived largely from the ISA-95 model, which – as stated above – were in turn derived from PERA. The first edition of the first standard in the series (i.e., ISA/IEC 62443-1-1) does include a diagram that looks very much like the typical hierarchical views in PERA.

However, subsequent revisions to this model have de-emphasized the link to PERA in favor of an increased focus on the concept of zones and conduits that is at the foundation of the ISA/IEC 62443 series. These changes have appeared in recently published parts of the series and will also be included in the second edition of ISA/IEC 62443-1-1 which is currently under development.

The simple truth is that in the context of systems cybersecurity the hierarchical arrangement of domains typical of PERA is not that important or even particularly relevant. What is important – even fundamental – to a successful cybersecurity response is the partitioning of the system under consideration into a set of interconnected zones based on an analysis of functionality, combined with a risk assessment for each functional area. This risk-based approach is described in detail in ISA/IEC 62443 (System security requirements and security levels). 

This brings us back to the initial question of whether the PERA reference model (i.e., the “Purdue Model”) is still relevant. This is a broad question with implications in many areas of Operations technology development. Several groups are trying to address this, perhaps by revising the PERA materials to better reflect recent developments in areas like IIoT. However, in the context of cybersecurity, it is largely a moot point. Standards like ISA/IEC 62443 have largely evolved beyond dependence on a traditional hierarchical view of functionality. This trend will almost certainly continue.

What is important – even essential – is to provide guidance to system integrators and asset owners on how to partition their systems based on risk and identify the best ways to protect them from potential cybersecurity threats.
 

Engage with ARC Advisory Group

Representative End User Clients
Representative Automation Clients
Representative Software Clients