The Purdue Enterprise Reference Architecture (commonly known as the Purdue Model) for control systems is old. People have forgotten what it originally was about.
When it was first introduced, the big concern behind the Purdue Model was keeping computing and networks deterministic so that they wouldn’t fault. Toward that end, it introduced network segmentation as a means for keeping traffic in a control network at deterministic levels.
It is worth remembering that back in the early days of Ethernet bus topology networking, the common refrain from many control systems engineers was that the network was “not deterministic.” They weren’t wrong. Many of them saw what would happen when a network appeared on the plant. They knew that the IT department would “leverage” it to move traffic from one place to another that they needed to get to. The argument would be “it’s just a single PC.” However there was no easy way to limit that bandwidth usage back then, so it would inevitably grow and cause problems. The first people to notice would be the control system engineers, and they would be helpless to stop the IT department from faulting the plant.
The Purdue Enterprise Reference Architecture document was written especially for IT departments so that they could understand why and how the control system networks needed to be segmented and what expectations each layer had for responsiveness. Do note that the typical state of the art back then was 10 MBPS on a hub or a coaxial bus. The ultimate throughput was about 3 MBPS. Office networks were very flat in those days, with far more broadcast traffic than most IT people realized. There was good reason to be concerned.
Once the Purdue Model became policy, many started using these network models to facilitate new I/O for safety systems. The networks were “safe” on a Purdue Model network, so there shouldn’t be much of a problem. For them, it became a model for safety.
And then analysts chanting “Convergence!” started gathering all that delicious “free” data from both the safety systems and the rest of the control system. This time it wasn’t IT, but the people in the upstairs offices of Operations who didn’t realize that they were threatening the Control system’s reliability and security. For them, the Purdue Model had become a how-to manual for gathering data from an ICS.
Today the immediate need is Security. The security people saw this model and instantly thought it was for them too. All they’d have to do is put firewalls between the layers, and that would be enough to securify everything. But the model never discussed security. So the layers got nuanced. Some began creating intermediary layers, such as a DMZ at level 3.5 for staging data from one system to another. No, you won’t find a level 3.5 in the Purdue Enterprise Reference Architecture.
The model has became everyone’s buzzword. What it means depends upon who is talking. Today, when you mention the Purdue Model in a standards committee, everyone thinks different things. It is a tower of Babel, with different goals and different methods in use everywhere for different purposes.
It might be time to create a new model that discusses all these needs instead of referencing this single purpose, out of date, obsolete effort.
(Update: edited minor typographical errors, added sentence about safety.)
