In the field of network security, there is a design pattern used to strengthen the defenses of those networks that are connected to the exterior -a situation that the Internet has made pretty much standard and unavoidable nowadays- that has been called the Demilitarized Zone (DMZ): a local network placed in between the inner and the outer zones that acts as a security buffer.
Since every outward and inward communications have to pass through the DMZ, one can closely monitor and control these interactions. It is often called a perimeter network.
Until the somewhat recent expansion of the Internet Protocol (IP) to Industrial Control Systems (ICS), a process guided by the currents trends of IT/OT integration, cloud storage services and the Industrial Internet of Things (IIoT) design, OT networks were (mostly, but not solely) protected simply by physical isolation from the rest of the world. However, the control and operational capabilities of a connected OT network have made worthy to pay the price of adapting those security measures known to work for the IT world, the DMZ among them. Enter the Industrial DMZ (IDMZ).
Design Principles
In OT settings, the role of the outer untrusted network is played by the IT network, where all the enterprise systems and services reside. The inner network protected by the IDMZ would be the OT network itself, where the ICS
data and technologies are. The same design principles and role to play of a DMZ apply here: all communications in and out of the OT network will have to pass and be subjected to certain security measures and checks before meeting their final destination.
These interzone interactions are resolved within the IDMZ via a series of broker services, that ought to be tightly defined and monitor. A non exhaustive list of these brokers will serve as an example:
- Application mirror, like an Structured Query Language (SQL) replication or a Network Time Protocol (NTP) for, respectively, data replication and time synchronization.
- Remote interactive session services, such as Microsoft’s Remote Desktop Protocol (RDP).
- Uniform Resource Locator (URL) filtering and forward and reversed proxy servers.
These brokers shield the Industrial Zone of the network from the clients and servers located in the Enterprise Zone.
When designing an IDMZ, one should follow a short set of principles put together by Cisco and that are displayer here verbatim:1
- All IACS network traffic from either side of the IDMZ terminates in the IDMZ; no IACS traffic directly traverses the IDMZ.
- EtherNet/IP IACS traffic does not enter the IDMZ; it remains within the Industrial Zone.
- Primary services are not permanently stored in the IDMZ.
- All data is transient; the IDMZ does not permanently store data.
- Functional sub-zones within the IDMZ are configured to segment access to IACS data and network services (for example, IT, Operations and Trusted Partner zones).
- A properly designed IDMZ will support the capability of being unplugged if compromised, while still allowing the Industrial Zone to operate without disruption.
Implementing a IDMZ is now a recommended best practice by several industrial standards such as the National Institute of Standards and Technology (NIST), IEC-62443 and the Center for Internet Security Controls.
Within the Purdue Model
The Purdue Model is defined as a architecture model to classify and segment the different components of a ICS by their connectivity with the rest of the devices on the network. Level 0 is the control layer, with PLCs and sensors doing the physical work; on the other end we have Level 5, the enterprise layer, dealing with the most general tasks such as human resources or financing. Introduced by Theodore J. Williams in the 90s, it is now an industry reference model adopted by the ISA-99. But much as happened since then, and some of the new currents (again, IIoT, cloud services, etc) have started to erode the original definitions of the model, urging professionals within the field to rethink it.2,3
As shown in Figure 1, an IDMZ does not fit nicely into the Purdue model, and it is typically placed as the 3½ layer, a mezzanine between Level 3, the outermost one containing OT processes (quality assurance, inventory), and Level 4, that deals with IT (intranets, email servers). It is worth noting that the original Purdue Model’s focus is not security but rather the interface between systems; that explains why the IDMZ does not really belong to any of the defined layers (and ultimately why it is easy to fire a discussion among industrial cybersecurity experts about the most natural layer for this or that device in a ICS).
10 Ways to Secure an IDMZ
Apart from standard cybersecurity best practices (a solid system of backups, regular vulnerability and patch management, etc), here are some points to secure an IDMZ to protect an OT environment:4
- Hardening the endpoint configuration
- Always monitor for changes
- Inward and outward communications to the IDMZ should remain basically static
- Implement whitelisting for software and services
- Control and terminate open sessions
- Monitor elevated privileges and administrative access rights
- Audit firewall settings
- Aggregate and review OT logs
- Consider honeypots
- Deploy of multiple IDMZ
Zero Trust Models
Even with its definition and the aforementioned design principles at hand, it is not entirely trivial how to implement a IDMZ in the real world. The IT/OT integration that is on the origin of the dire need for some sort of buffering system is a complicated and messy process that is still being resolved today (and one that it is also very situational, not universally applicable). One example illustrating this point would be to consider the IDMZ as a no man’s land, the coordination of security issues between upstream and downstream should have to be decided and implemented. A rule of thumb mentioned by Pascal Ackermann in his Industrial Cybersecurity manual5 is that “if a system/device/function/application is not absolutely necessary to run the production process in some shape or form, that system/device/function/application should reside on the enterprise side of the ICS environment”.
A Zero Trust approach would be one following the motto “never trust, always verify”. Under it, the range of possible operations that an actor can perform will be kept at a minimum, and all agents in a communication or data exchange (the sender, the receiver, the data itself, etc) have to explicitly have the permission to do so.
In principle, this approach seems to be ideal for an IDMZ, where the IT/OT integrations would have to take place, but in reality things can get quite complicated and often compromises have to be made. A typical ICS will have many different elements, of different technological generations, made by
different providers that were not necessary in touch or under a common standard, communicating using wildly different protocols, oftentimes private. It is not uncommon for them to not have authentication processes whatsoever, and most of them were designed at a time where it was safe to communicate with other ICS point openly, without the fuss of a number of security layers. Needless to say that this clashes with the Zero Trust design presented here.
This explains why implementing an IDMZ, despite being always recommended by any security consultant out there, it is not always easy or even the best course of action in some scenarios.
Summary
In this short overview, we gave an introduction to the notion of Industrial Demilitarized Zones, its importance in today’s ICS security, its basic design principles and some of the many challenges of implementing one. Those interested should dive into the corresponding chapter of the P. Ackermann manual in reference [5] for further discussion and details.
References
[1] Securely Traversing IACS Data across the IDMZ Using Cisco Firepower Threat Defense https://literature.rockwellautomation.com/idc/ groups/literature/documents/td/enet-td013_- en-p.pdf
[2] Is the Purdue Model Dead? https://dale-peterson.com/2019/02/11/is-the- purdue-model-dead/
[3] A Reimagined Purdue Model for Industrial Security is Possible https://www.forbes.com/sites/forbestechcouncil/2022/01/18/a-reimagined-purdue-model- for-industrial-security-is- possible/?sh=2a892d0f1162
[4]10 ways to secure an Industrial DMZ to Protect your OT https://www.tripwire.com/state-of- security/revisiting-the-relevance-of-the- industrial-dmz-idmz
[5] Pascal Ackermann, Industrial Cybersecurity. 2021, Packt Publishing.
