The Purdue Model of Control Hierarchy is a framework commonly used by manufacturers in pharmaceuticals, oil and gas, food and beverage, and other verticals to group enterprise and industrial control system (ICS) network functions into distinct zones. This framework is especially helpful to understand how data typically flows through these networks and, correspondingly, how to secure each of the network zones and their various respective elements.
One of the most recognizable manufacturing frameworks in existence today, the Purdue Model divides the enterprise into various layers or “Levels” which each represent a subset of systems within the manufacturing operation. These Levels are grouped into more general “Zones” which comprise the four primary classifications of systems – Enterprise, Manufacturing, Cell/Area, and Safety. The Zones also represent major points of separation – any connection between them is highly controlled, generally getting higher in security from top to bottom, until the Safety Zone, which in some cases may not be connected at all, for security purposes.
The security controls involved between each point of separation are typified by a DMZ and a firewall. The most common practice is to restrict access to Level 3 from Levels 4 and 5 and the public internet. In the opposite direction, usually only Layer 2 or 3 communicates with Layers 4 and 5, the lowest two Layers (the machinery control and process Layers) being restricted to keeping their data and communications within the OT. Indeed, most of our ICS customers segment all OT Layers (0-3) away from IT Layers (4-5), blocking or strongly restricting traffic into the OT, and access to lower Layers happens only from the within the OT Zones, where security can be better assured.
However, as OT and IT converge, the operational controls in Level 0-3 are required to send more and more data up to Level 4/5. Manufacturers are looking to get the condensed site operational data from Levels 2/3 up to Levels 4/5 to provide the business continuity and operational analytics benefits of which most modern manufacturers are looking to take advantage.
The desire for more, real-time operational data within manufacturers has only grown with the emergence of the Industrial Internet of Things (IIoT). Simpler, smarter, network-connected devices, such as sensors, are proliferating across networks, pushing manufacturers to collect data from devices in lower Levels (2 and below) and send it directly to the IT Levels or elsewhere, such as cloud applications.
The spread of IIoT is driven partly by the lower cost of the devices, but also by the increased ability to directly collect useful operational data from machines, processes, and people. As such, there is now a need to add a Level 6 to the model, above the traditional Purdue Model, in the Cloud/Internet Zone. Data no longer lives exclusively within the enterprise, so the model must be updated to reflect it.
Furthermore, some organizations are applying IIoT to replace a potential single point of failure between OT and IT, where ALLOT data flows through a single large connection. Data from each Layer must pass through a firewall/DMZ before it reaches the next Layer up, and another, and so on, all the way up to the Enterprise, slowing data flow to a trickle. Additionally, if an organization is aggregating all their OT data through a single connection and the connection fails, they have lost visibility to a massive amount of operational data that could be critical.
With this inefficient, single point of failure in mind, we’re now seeing a push to tie individual assets or data streams to individual simple inexpensive connections from the devices themselves. That way if the connection fails, only the data from that device is lost, and the other IIoT devices will still be able to stream data. In effect, this new connectivity paradigm has created a sort of parallel IIoT Zone outside the traditional Zones where the IIoT systems and devices connect independently.
More questions than answers
Seems like IIoT is upending the Purdue Model. If we were to stick to the Purdue Model, IIoT devices would be part of a layer in the OT and would send their data to Layer 3, which would be communicating to Layers 4 and 5.
Though, keep in mind, the Purdue Model reflects the hierarchical nature of an OT network, and guides the design of network security. IIoT stands to fragment that network, especially if IIoT devices communicate directly to the IT layers.
Unfortunately, the more systems connect, the more exposed and vulnerable the underlying sensitive manufacturing layers become. Unless specifically isolated, as network-connected devices, a compromised IIoT device can provide access to the rest of the OT segment it is on. Multiply that times thousands of individual devices, and you can see where the potential security issues proliferate. Therefore, the security of IIoT devices on the OT network is just as important as all the other network-connected components running the machinery.
In response, we need to rethink how we secure networks in an IIoT age. Do the benefits of a direct connection from the lower OT layers directly to the IT layer outweigh the challenges to cybersecurity? Indeed, what does cybersecurity look like as IIoT device proliferate in the OT layer, sending data to OT subsystems, but also directly to the IT layer? And how do IIoT devices impact the way we validate production processes?
In a nutshell, how can we reconcile the ability of IIoT devices to send data directly to the cloud with the need to properly secure them against the growing potential for compromise? For more info on how IIoT is changing OT security, check out this free white paper – The “S” in IIoT Stands for “Security”.
In my next post, I’ll discuss how our customers have been addressing this question and securely enabling their IIoT infrastructure without reverting to the limited and outdated “single channel” model of data transfers.
We’ve been discussing with many manufacturers how IIoT changes the way they segment their networks and secure their network-connected assets, especially using data diodes. And we’d like to hear from you, too.
How have you addressed the proliferation of IIoT devices on your OT networks?