Which Flavor of the Purdue Model Should You Follow?
If you enter the term "Purdue Model" into your favorite search engine, the resulting images will vary considerably. There's almost no better way to stir up an Operational Technology (OT) security conversation than to begin debating what belongs on Level 1 or Level 3 of the model.
You might even find some diagrams place operator Human-Machine Interfaces at Level 3. Notably, the original 1990 publication defines "operator's console" as a Level 1 entity. The only thing we seem to agree upon is that Level 0 is the physical process and Level 4 is the enterprise, though I’m sure you can find some diagrams which deviate from even this understanding.
The Purdue Model was originally introduced by Theodore J Williams over 30 years ago. Given its age and the pace and scope of technological change including trends like Software-Defined Networking, the Industrial Internet of Things (IIoT), e.g., Edge to Cloud, and the Advanced Physical Layer, it’s natural that some people are beginning to question whether the Purdue Model is dead. But you can't get around an OT cybersecurity conversation or solution presentation without still running into it.
Although the Purdue Model has been around for decades, the OT security community continues to leverage its simplicity and build cybersecurity models overlapping with its concept. Even so, the Purdue Model that OT security experts and vendors discuss today is not your grandfather’s Purdue Model – except by name.
Some refer to ISA95 and the Purdue Model interchangeably. The confusion can be understood by comparing the image results of the search "ISA95" with your previous search for "Purdue Model" diagrams. ISA95 built on the concepts from the Purdue Model and formalized them further in 2000 – less from a security standpoint and more from an information integration standpoint – to standardize the interface of ERP and MES. (Twenty years later, we call this interface "digital transformation.")
Frankly stated, the ISA95 standard is more focused on the definition of business interfaces, and neither ISA95 nor the Purdue Model were originally intended as security architectures. For instance, you won’t find requirements for cybersecurity principles such as “network segmentation” and “perimeter protection.” The ISA95 standard also classifies levels based on time horizons, but modern manufacturing companies are making business-related decisions faster than ever, reducing the time horizons and their relevance to defining architecture zones.
The problem with varying sources of information and confusion is that they more commonly force asset owners to pick a unique flavor of the Purdue Model driven by their vendor relationships. Getting your Purdue Model numbers correct may not actually improve your security posture, but it can generate a way for the community to share ideas. What's more important than the numbers are the boundary interfaces and controlling the functions living in each level. Don’t get hung up on selecting the “right” flavor of the Purdue Model, for there isn’t one! It’s a general framework, not a cybersecurity reference architecture.
Should You Have a Level 3.5 Industrial DMZ (iDMZ)?
The majority of threats to Industrial Control Systems (ICS) continue to originate from IT/ the enterprise, which has seeded OT’s mistrust of direct IT connections. Conversely, IT teams have a similar mistrust of direct OT connections due to legacy environments and unpatched vulnerabilities. The iDMZ helps both teams avoid direct connections and establish trusted data exchanges. Consider the iDMZ as another barrier to slow the attackers’ lateral spread into OT networks whether through active keyboard attacks or automated malware.
The original Purdue Model and the ISA95 standard omit the concept of an iDMZ barrier between the enterprise and site, which is because of the standard’s focus on functional interfaces and not cybersecurity. However, in practice, iDMZs are routinely deployed and classified as Level 3.5. One should be wary of any diagram that classifies Level 3 as the iDMZ. A properly implemented iDMZ should be pointedly differentiated from the more operationally focused supervisory plant network. The iDMZ has no direct operational function or applications. It remains in place solely for improving network segmentation and security.
The iDMZ is where IT and OT convergence – or collision – takes place. As digital transformation, IIoT, and Industry 4.0 initiatives lead organizations to converge process data with cloud analytics, this critical IT-OT security interface is often overlooked. Of course, IT-OT convergence is not an excuse to create a flat network. IT-OT data convergence can be achieved securely and efficiently with proper segmentation through a secured iDMZ. towards that end, avoid flat networks connecting OT data directly to the enterprise layer.
One common issue with this convergence is that the boundary layer becomes "no man's land" with no clear responsibility for cybersecurity hygiene and monitoring. OT teams will usually draw the line south of the iDMZ, often by controlling their own OT boundary firewall and assuming that everything upstream is managed, protected, and monitored by IT. And IT teams have enough vulnerabilities, detections, and alerts to respond to on the enterprise network that they will rarely consider or look into this isolated iDMZ. It's imperative to assign clear responsibility for iDMZ security. My recommendation here is that a dedicated IT security sub-team should be made aware of its risks, concerns, and importance.
It’s best to think about the iDMZ as a security zone rather than an application zone. Instead of thinking about application use cases to determine your needs for an iDMZ, it’s better to determine whether the security principles of deploying an iDMZ will enhance your security posture. Then, determine which application use cases or solutions will enable you to protect the policies for this boundary zone.
Some typical components that you might find in the iDMZ include remote access gateways, patch management servers, or OT network security dashboards. When passing OT data to IT, the best practice would be to follow a pub-sub model, where OT and IIoT devices are publishing to the iDMZ and the analytics engines or data lakes are subscribing from the iDMZ source.
Apply a Zero Trust Mindset to Your iDMZ
The Zero Trust architecture can also be applied within the iDMZ. In fact, it's a perfect example of a small network where the concepts of zero trust can be enforced and applied to the wider enterprise. Each transaction, login, service, and download within the iDMZ should be approached from the mindset of "never trust, always verify." Meticulously monitor the iDMZ nodes for changes. Any change here represents a bad actor, lateral movement, or misconfigurations that can lead to more severe vulnerabilities and exposures.
Zero Trust is not an excuse to avoid building a strong perimeter and following proper network segmentation. If we apply the mindset of "assume breach" to each succeeding layer of the architecture, then we will build layers and layers of protection rather than bypass them. ICS systems have real physical boundaries, and we can protect them from threats by using these boundaries to our advantage.
General Security Principles for Implementing an iDMZ
There are a few OT characteristics that we can use to our advantage for cybersecurity monitoring in the iDMZ. First, what comes into and out of this boundary should remain fairly static over time. Newly approved connections should be validated by IT and OT teams together, not in isolation by digital transformation initiatives. Secondly, what lives inside this boundary should change infrequently and at a much longer time horizon than traditional IT networks. Any new assets and users should be met with suspicion.
Asset owners are advised to follow a few principles for data transfer across the IT and OT boundary:
- In general, upward traffic is preferred in the Purdue Model. But many reverse traffic use cases cannot be avoided, such as remote access or transferring patch files.
- Traffic flows only from one level to the next. Don't bypass levels. All IT traffic must first terminate in the iDMZ rather than bypass and make a direct connection to OT.
- Disable internet and email connections from the iDMZ nodes. Limit the direct vector of phishing by disabling email from iDMZ nodes. In some cases, you might approve an SMTP server for outbound email notifications but not inbound emails.
- If possible, disable or disallow the use of removable media on your OT systems. Removable media remains a leading source of infection for OT networks – admittedly, the most obvious source of bypassing the security concept of the iDMZ altogether. If it’s not possible to disable completely, then dedicated scanning stations, group policy definitions, and user training can help limit the risks.
Identifying and Blocking OT Threats by Deploying Best Practices in Your iDMZ
Following the above-mentioned basic principles will build the foundation for a defendable iDMZ boundary that can protect your IT infrastructure from “insecure” OT networks. These principles will also protect your OT infrastructure from threats arising from the traditional enterprise, which frequently spread laterally. To build on this foundation, we can continue to leverage the static nature of the IT-OT interface with active defense and monitoring capabilities.
Follow these 10 best practices for enhancing the cybersecurity of your iDMZ:
- Harden the endpoint configuration according to a trusted policy. Follow a best practice such as the CIS Benchmarks. This includes eliminating unnecessary services and blocking internet or email. Enforce least privilege and role-based access controls, and then reduce the use of administrative accounts as much as possible. Hardening should also include vulnerability management and regular patching.
- Monitor for changes across your iDMZ environment. These assets should remain in their trusted and hardened state. Deviations from this state of compliance could indicate unintended misconfigurations or malicious activity.
- Inventory the persistent ingress and egress connections. What comes into and out of the iDMZ should remain static over long time horizons. Identify and add specific endpoints, ports, and services to the list of allowed entities. Use real-time change detection solutions to actively monitor and notify IT or OT security teams upon any unplanned changes.
- Implement allowlisting for software and services. Known and approved changes can be automatically validated by integrating your allowlisting with configuration management systems. Creating additional obstacles for changes in this zone might create pain points with end users, but is necessary for protecting the integrity of the iDMZ.
- Audit and terminate temporary ingress and egress points. This includes remote access sessions that have been left open beyond your security policy window. Even better, look for a solution that automatically terminates sessions after a specified time period.
- Identify and alert upon suspicious lateral movements. Be watchful for rogue devices, and meticulously monitor for elevated privileges and administrative access rights. Monitoring for lateral movement will provide an early detection methodology.
- Regularly audit the firewall settings – both north and southbound – to avoid configuration drift. Secure configuration management solutions can help transform painful audits into continuous compliance monitoring.
- Aggregate OT logs and feed security threat hunting teams with events of interest: OT devices and their connected IT components (e.g. computers, switches, firewalls) within the lower levels of the Purdue Model generate security events of interest that rarely get recorded or investigated. Recording these events and logs becomes invaluable to supporting incident response efforts. Look for log aggregation and correlation tools that can minimize the noisy chatter from some of these legacy devices before they are fed into sophisticated SOC threat hunting technologies.
- Learn from a honeypot. There are many alternatives to consider including a single honeypot within your iDMZ to an entire honeypot iDMZ or even a honeypot OT network beyond your iDMZ. Honeypots provide live threat analysis and early warning detection rather than passive protection There are reliable commercial offerings that can be very useful for this purpose.
- Consider deploying multiple iDMZ networks. Sharing a common iDMZ across many geographic sites can introduce a single entryway to multiple OT networks.
Note: This list is not exhaustive, and other general cybersecurity hygiene and best practices should also be applied to the iDMZ – including but not limited to regular patch management, vulnerability management, antivirus solutions, backup and recovery, and more.
Closing
The iDMZ remains a relevant and useful segmentation method to protect your operational technology and information technology from each other as well as to disrupt lateral movement of attackers and malware. Creating this barrier zone allows an organization to inventory and re-evaluate the ingress and egress sessions and data exchanges. Organizations can take advantage of the static characteristics of this interface, thereby creating and enforcing “allowlists” and monitoring for deviations from a known and trusted state.
