Architektura bezpečného toku dat bez narušení Purdue modelu
Manufacturing companies increasingly need to get data from the shop floor to the systems that can make use of it – from analytics and ERP systems to cloud platforms. But as OT and IT become more connected, keeping industrial networks secure while still making data accessible becomes a growing challenge.
So how can you connect manufacturing technologies with business systems without bypassing security controls or exposing sensitive OT systems? In this article, we look at why it is important to preserve the principles of the Purdue Model and how a properly designed gateway can provide a secure, controlled flow of data between OT and IT.
1. The Purdue Model and Why It Still Matters
The Purdue Enterprise Reference Architecture (PERA), along with its adaptations in ISA-95 and ISA/IEC 62443, has been a de facto reference model for industrial network segmentation for more than two decades. It divides the industrial environment into distinct levels – from Level 0 (the physical process) and Level 1 (basic control, PLCs/RTUs), through Level 2 (supervisory control, SCADA/HMI) and Level 3 (manufacturing operations, MES/historian), to the demilitarized zone (DMZ) and Levels 4–5 (enterprise IT, ERP and other business systems).
The main security benefit of this model is not simply the division into layers, but the enforced boundary between OT (Levels 0–3) and IT (Levels 4–5). Control-layer systems should never communicate directly with the enterprise network without passing through a controlled and monitored DMZ.
ISA/IEC 62443, the leading cybersecurity standard for industrial automation and control systems (IACS), formalizes this boundary through the concept of security zones and conduits. Every data path crossing a zone boundary should be clearly identified, assessed for risk and controlled.
The practical challenge is that Industry 4.0 initiatives – predictive maintenance, cloud-based historians, integration of production data with ERP systems or remote equipment monitoring – require exactly the kind of data flow from Levels 0–3 to Levels 4–5 that the Purdue Model was designed to control, rather than eliminate. The pressure for convergence is real and is not going away. The key question is therefore how to meet this demand without weakening the boundary that PERA and ISA/IEC 62443 are designed to protect.
2. Why Direct Connectivity Is Not the Right Starting Point
One of the most common problems in OT/IT convergence projects is what security audits often describe as “boundary erosion”: a PLC or historian gets a route – sometimes officially approved, often introduced as an informal workaround – directly to a cloud endpoint or an application on the IT layer, effectively bypassing the DMZ.
This usually happens gradually. A particular analytics project needs access to a data source, a firewall rule is opened as a temporary solution, and that “temporary” measure remains in place because removing it would disrupt a process that has since come to depend on it.
The risk is well documented in ICS security research and analyses of real-world incidents. A control-layer device with a direct path to the internet or enterprise IT inherits the attack surface of the IT environment – for example, through lateral movement following a phishing attack, compromised credentials or vulnerabilities in IT software – without necessarily having the same protective mechanisms commonly found in IT environments, such as regular patch management, endpoint detection or network monitoring designed for IT traffic.
Control-layer devices are also often left unpatched for long periods because of the operational constraints of industrial systems. Availability requirements may not allow updates to be performed as frequently as they are in IT. Direct exposure can therefore create a significantly higher level of risk than comparable exposure of a typical IT device.
3. Gateway-Based Architectures
An architecture that supports both convergence and the security zones and conduits defined by ISA/IEC 62443 uses a controlled gateway located in the DMZ or immediately adjacent to it. The gateway acts as the only authorized communication path between the OT and IT layers. Implementations can differ in several important ways:
3.1 Protocol Translation at the Boundary
Instead of routing native OT protocols (Modbus, EtherNet/IP, proprietary vendor protocols) into the IT network, the gateway terminates the OT connection locally and republishes the data on the IT side using IT protocols and formats such as REST APIs, MQTT with TLS or OPC UA with built-in security mechanisms.
IT systems therefore never establish a direct protocol-level connection to devices at Levels 0–2.
3.2 Data Validation and Sanitization
A properly designed gateway is not simply a transparent data pass-through. Before publishing data, it validates, transforms and filters it according to a defined schema.
This reduces the risk of corrupted or malicious data being passed further into the IT environment while ensuring that only the tags actually required by a specific IT application are made available. It is a practical application of the principle of least privilege not only at the network level, but also at the data level.
3.3 Data Routing
For the most security-sensitive scenarios – such as safety instrumented systems or critical infrastructure – unidirectional gateways (data diodes) provide a hardware-enforced, physically one-way data path from OT to IT. This eliminates the possibility of return communication regardless of software configuration.
For a broader range of OT/IT convergence scenarios – such as dashboards, analytics, ERP integration or remote monitoring – where some level of two-way interaction is operationally necessary (for example, changing parameters remotely or supporting an acknowledgement workflow), a controlled bidirectional gateway is a more common and flexible solution. Strict protocol translation, authentication and logging are applied at the boundary.
This assumes, of course, that the gateway is located in the DMZ and is not used as a reason to remove the DMZ itself.
3.4 No-Code/Low-Code Configuration as a Security Feature
One often-overlooked aspect of gateway-based architectures is the relationship between change management and security.
Gateways that require custom programming for every new data mapping can create pressure to bundle changes together or postpone updates and testing. Visual no-code layers for data mapping and transformation, on the other hand, can make legitimate connectivity changes faster and easier to implement.
In practice, this can reduce the temptation to create informal and unauthorized “temporary” direct connections that gradually weaken the security boundary.
4. Practical Deployment Considerations
Successful OT/IT convergence architectures tend to share three key characteristics:
4.1 Location Matters as Much as Function
A gateway placed at Level 3.5 (DMZ) in the ISA-95/Purdue terminology preserves the model of security zones and conduits.
The same software deployed inside Level 2/3 with a direct path to the internet, however, recreates exactly the boundary problem it was intended to solve. Technology cannot compensate for incorrect placement in the network architecture.
4.2 Edge Deployment Can Reduce Both Latency and Attack Surface
Running gateway functionality on dedicated edge hardware located alongside control equipment, rather than sending raw OT data to a remote or cloud-based mediation layer, keeps time-sensitive data local while reducing the amount of uncontrolled OT traffic that needs to traverse the WAN.
4.3 Auditability Is a Requirement, Not an Add-On
The ISA/IEC 62443 model of conduits assumes that traffic at the boundaries between security zones is logged and monitored.
When evaluating a gateway solution, logging and audit capabilities should therefore be considered just as carefully as throughput and protocol support.
5. Conclusion
OT/IT convergence is no longer optional for organizations that want to take advantage of Industry 4.0 analytics at scale. The pressure to connect data from the control layer with enterprise systems will only continue to grow.
The key question that needs to be addressed deliberately and systematically – rather than through a growing collection of firewall exceptions – is where this connection takes place and what is responsible for enabling it.
A gateway located at the DMZ boundary, providing protocol translation, data validation and, where appropriate, hardware-enforced unidirectional data flow, makes it possible to benefit from OT/IT convergence while preserving the security zones and conduits model rather than gradually dismantling it through individual exceptions.
Now that you know why secure data transfer matters, the next question is:
How can you achieve it without unnecessary cost and complexity?
Secure data transfer doesn’t have to be complicated. See how you can protect your data at a fair price – without hidden fees or unnecessary features. Discover our solution:
—
**References for further reading** ISA/IEC 62443 series, *Security for Industrial Automation and Control Systems*; ISA-95 / IEC 62264, *Enterprise-Control System Integration*; NIST SP 800-82 Rev. 3, *Guide to Operational Technology (OT) Security*.
Leave a Reply