When we talk about connecting any aspect of a SCADA system to the cloud, even in the context of cloud-enhanced SCADA, some people get a bit nervous. The engineers and IT professionals responsible for keeping the SCADA systems safe and secure within their company will tell you that it’s best to keep their plant and the Internet on two completely separate physical networks. And should it ever prove necessary or desirable to bring these two networks together (for example to use the cloud to extend a SCADA system), then the generally accepted best practice is to use a Data Management Zone, or DMZ.
The acronym DMZ calls up images of a demilitarized zone between warring nations, where no fighting is allowed. That’s pretty much how it works. The DMZ provides a layer of protection in which company services like email and web servers that are exposed to the Internet get placed in a sub-network which is isolated from the rest of the company.
Companies using a DMZ might thus conclude that it places the cloud completely off limits to them. If their DMZ won’t allow an inbound Internet connection from a cloud system to read the data, then there is no way they can connect to the cloud, right?
Not necessarily. Properly configured, a DMZ can allow data from a SCADA network to be sent to the cloud without exposing the plant network to the Internet. In fact, the DMZ in such a scenario would act as a second layer of protection. This additional protection might even prompt a company that doesn’t use a DMZ to implement one.
How does it work? The DMZ connection is made through a computer specially equipped with two network interfaces. One network interface is on the plant network, and the other interface can access the Internet. Data from the plant gets routed through the first interface to a real-time middleware layer, which maintains an outbound connection to the cloud through the second network interface. The DMZ computer itself does not route between the two interfaces, so there is no direct connection from inside the plant out to the Internet, nor from the Internet back into the plant.
If the real-time middleware is configured to reverse the client-server relationship, then the DMZ computer will have no incoming ports open in its firewall, so it will effectively be invisible to the Internet and never accept a connection of any kind. In addition, the computers on the plant network do not need to open any firewall ports to send data to the DMZ computer. This means the plant computers would remain inaccessible from the DMZ computer and give you a double firewall layer between the plant and the cloud. Another advantage to this approach is that it gives the network administrator a single point of contact if he needs to cut off all data flow to the cloud server. He just disables the connection from the DMZ to the cloud and the plant continues to operate with no interruptions.
In most scenarios where a DMZ is being used to isolate a SCADA system from the cloud, the flow of data is one-way, from the plant to the cloud. Should a user need some form of write-back capability from the cloud to their plant systems, it can also be done securely, through the DMZ if necessary. But this is another discussion for a future blog.
Ultimately, there are a number of factors that determine the value and feasibility of using the cloud for enhancing a SCADA system. Each of these needs to be weighed on its own merits. Working in a system with an established DMZ, or implementing one of your own, it is possible to completely isolate your SCADA network even as you make your real-time production data more widely available to colleagues, customers and remote systems.
