Purdue, ISA-95, IEC 62443: the framework that makes a secure transformation possible

The more computerised systems a plant runs, the more its production depends on them. That dependence is what makes a failure, a bad configuration or a targeted attack so expensive: one outage in the wrong place and a line, or a site, stops. Proven standards earn their keep here. They give a transformation a shape that has already been tested elsewhere, so that it can be both useful and safe.

This is part 9 of 9 of the “OT/IT convergence” series; it follows part 8, the environmental account. It covers the three frameworks that do the work, and finishes with the configuration rules that turn them into a network.

The Purdue model: a structure for the plant

To organise the layers of industrial technology and design a network that is both reliable and secure, you need a frame. The Purdue model, often just called the levels model, provides one: a hierarchy that breaks a production system down into functional levels, from the physical process at the bottom to the business systems at the top.

A word on where it comes from. The model is commonly attributed to the Purdue Research Foundation in the 1990s. More precisely, the Purdue Enterprise Reference Architecture was developed by Theodore J. Williams with the Industry–Purdue University Consortium for Computer Integrated Manufacturing, and published in his 1992 technical guide. The detail matters because it explains what the model was for: manufacturing integration. Purdue was never designed as a security architecture. We use it as one largely by historical accident, and it helps to remember that.

In a convergence project it still gives you three useful things. It makes roles clearer, showing which responsibilities and areas of work belong to IT and which to OT. It gives a common frame for the communication between levels, which keeps IT/OT collaboration workable. And by drawing boundaries between levels, it lets you fit the security measures to each one.

Two points bear repeating. The first concerns the bottom of the model. Level 0 is the physical process itself, the sensors and actuators, and the safety functions that protect people act directly on it. Keeping it, and the control levels just above, out of reach of the corporate network removes a whole class of risk, from a failure in the office network to an external attack. This is more than a defence-in-depth preference: it is the boundary where a cyber event becomes a safety event.

The second is that risk assessment happens level by level. IT and OT teams need to assess each level carefully, together, before choosing a security strategy for it. One uniform set of controls across all levels ends up too heavy at the bottom and too light at the top.

ISA-95 (IEC 62264): a grammar for integration

ISA-95 specifies the interfaces between the control systems used in production and the enterprise systems above them, ERP and the like. It sits alongside the Purdue model for placing systems in a level-based architecture, and alongside ISA-99 / IEC 62443 for security.

In a digital transformation, its job is to make production and the business talk to each other without friction, which is the precondition for decisions based on data and for reacting quickly. Integrated properly, it gives a single view of production, logistics and finance, lets systems exchange information both up and down the hierarchy and across it, and helps cut costs and improve quality by putting production data in front of the people who plan.

Vertical integration links the levels of the hierarchy. ISA-95 itself describes five: level 0, the physical process; level 1, sensing and manipulating it (instruments, PLCs, drives); level 2, monitoring and supervision (HMIs, SCADA, control workstations); level 3, manufacturing operations management (MES, historian, laboratory and data systems); and level 4, business planning and logistics (ERP). The standard is mainly about the interface between levels 3 and 4. Done well, vertical integration gets production data to the people who decide, in near real time and without re-keying, while respecting the security boundaries between levels.

Horizontal integration connects departments and systems on the same level. On the organisational side, it helps departments talk to each other, react faster to changes in the market or in customer demand, and run a more agile supply chain. On the technical side, it means machine-to-machine communication: on a production line, each piece of equipment passing information to the next.

ISA-99 (IEC 62443): a method for security

IEC 62443 is a series of standards that gives a framework for securing industrial automation and control systems. As the threat has grown, it has become the reference for protecting critical installations.

### Why OT systems became more vulnerable

Put simply, they were designed on assumptions that no longer hold: that physical access was the main way in, that a system would run for decades without change, that there was no need for a patch mechanism or for authenticated protocols. Convergence then added the last ingredient, a route in from a routable network.

### What makes OT security different

IT security products are often unsuitable or insufficient for OT, because OT is specific and varied, and because the two domains rank their priorities differently. To be effective without putting the availability of production equipment at risk, the approach has to account for response times, the availability of systems and installations, technology service lives, limited hardware and software resources, and a wide diversity of equipment, systems and protocols.

### The strategy, in four movements

Industrial cybersecurity needs a strategy that covers protection, detection, response and recovery, staged over time: immediate measures to mitigate, longer-term ones to remediate. Protection on its own leaves an organisation unable to tell that it has been breached. Detection on its own produces alerts nobody is equipped to act on.

### The documentary structure, and the problem with it

The ISA/IEC 62443 series is organised in layers: general terms and concepts, then policies and procedures, then system requirements, and finally component and product requirements. Together they cover security at every level of an industrial system, with guidance on assessment, implementation and ongoing risk management.

One observation deserves quoting more often:

This abundance of documents can become a genuine obstacle for companies starting out. They do not find a clear deployment structure for a cybersecurity strategy within the standard.

That is true, and it is the series’ main practical weakness. IEC 62443 describes in great detail what good looks like. It does not tell you what to do first. The answer is to build a deployment plan that maps each activity, from initial preparation to continuous improvement, onto the relevant sections of the standard. It is the right answer, and most organisations end up having to build it for themselves.

### Assessment first

Assessing the current security level is the first phase of any strategy, and the most important: a diagnosis of where the systems actually stand. Identifying the vulnerabilities and the room for improvement is what decides the mitigation and remediation actions.

Everything depends on one thing: a complete inventory of equipment, systems, communication protocols and the people involved. Only with a clear, accurate and regularly maintained overall picture can you move on to securing the installation proactively, and to the periodic reassessment that a changing threat requires. The risk assessment workflow for this is defined in IEC 62443-3-2, published in June 2020.

The configuration rules

Two IEC 62443 terms are needed first. A zone is a grouping of assets that share common security requirements; a conduit is the communication path between two zones, together with the controls that protect it. A sub-zone is a zone nested inside another, for a group that needs a stricter rule than its neighbours. The companion article on isolated, VLAN and security zone sets out what each of these costs to build. What follows are the rules for combining the three frameworks in an actual network design. They are short, and they are the part engineers will use.

• A security zone is a design decision about risk; the firewall is where that decision is enforced.
• A security zone may contain one or more sub-zones.
• A security zone may not traverse another security zone.
• A security zone may be associated with one or more VLANs, preferably a single one.
• A VLAN may not traverse multiple security zones.

Then one note on practice that most reference architectures leave out. Levels 1 and 2 are often treated as a single level. Level 1 holds the automation equipment (PLCs, drives), level 2 the supervision and control stations. There is usually no firewall between them, which is why they merge logically. It meets a practical need: to keep configuration and deployment simple, PLCs and supervision stations go into the same VLAN and the same security zone, because by default they have to communicate freely.

Better to say so plainly. A reference architecture that shows a firewall between levels 1 and 2 will be quietly ignored on site, and an architecture document nobody follows does more harm than one that describes what is actually built.

The other standards worth knowing

• ISA-88 (IEC 61512), the batch control standard, essential in chemicals, pharmaceuticals and food. It structures recipes so they can be changed in a controlled way, and documents each step of the process for traceability.
• IEC 61850, for substation automation, which eases the integration of devices from different manufacturers.
• OPC UA, the industrial standard for interoperable and secure communication in automation, and MTConnect for collecting data from manufacturing equipment.
• ISO/IEC 27001 and 27002, for information security management. Mainly IT-facing, but relevant to any company securing its data through a transformation that inevitably touches every layer.
• The NIST Cybersecurity Framework, now at version 2.0 (February 2024), with six functions: Govern, Identify, Protect, Detect, Respond, Recover. Govern is the real addition.
• IEEE 802.1AR, secure device identity, for authenticating devices on industrial networks; and the standards coming out of Germany’s Industrie 4.0 initiative.

Closing the series

Nine articles, and the argument comes down to something short. The air gap has gone and will not come back. What replaces it is a structure you can explain (Purdue for the levels, ISA-95 for integration, IEC 62443 for security), run by two teams that understand each other, in an organisation that has decided what it is trying to achieve.

The standards are the easy part: written down, stable, available to buy. Everything difficult in this series turned out to be organisational.

References

• ISA, ISA-95 Enterprise-Control System Integration (IEC 62264), levels 0 to 4, isa.org
• IEC 62443-3-2:2020, Security risk assessment for system design, webstore.iec.ch
• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, 26 February 2024, nvlpubs.nist.gov