Analytical Insights #3 - Secure Communication from DMZ to Cloud

Part 3 of Microsoft Most Valuable Professional Dave Shook, Fusion’s Chief Data Officer’s 9-part educational series discussing various topics for asset-intensive industrial companies who need analytical insights to improve operations. The third part of this series is the topic of Secure Communication from DMZ to the Cloud.

Read the video transcript below for your own convenience:

The DMZ is a network that exists because the distributed control system or industrial control system needs to be protected from the Business Network. Even well-intentioned users in the Business Network, to say nothing of malicious users or malicious software, inadvertently cause operating incidents by overloading the control system Network, accidentally interfering with individual servers on the network, etc.  Over the course of the last 20 years or so, there has been a standard network configuration set up in which the most important part is this notion of a demilitarized zone known as DMZ. 

The idea is that the distributed control system has a firewall between it and the DMZ, and the DMZ has a firewall between the Business Network. The control system is a logically separated network from the Business network. For instance, the control system's entire active directory, user authentication, and device authentication system are completely segregated from the Business Network. This means this makes the control system much more secure and protective from a Business Network. However, we do need to be able to get data from the control system to the outside world. This is where the DMZ comes in. The DMZ is also where applications run that need to be able to access data on the control system and may also need to access data in the Business Network.

We're trying to get data from devices, controllers, servers, and other control systems up to the cloud. There are many layers to industrial security, but the couple I want to talk about is that all connections must be outbound. So all connections must start being made outbound, and you cannot have any single communication that passes through two firewalls in a row. There needs to be a landing point in between the two firewalls, and you need to be able to change ports and protocols for those two firewalls so that you don't have the same hole or the same exploit into the success of firewalls.

The issue here is in order to acquire data from these Industrial Systems, it becomes necessary to put some sort of client software or data collector at least in the DMZ, possibly down in the control system itself. That data collector then has to pass the data through to something sitting on the Business Network, some sort of relay station, and then the relay station can forward the data up to the cloud. While this works, there are other ways of doing this, but they are kind of fraught from a network analysis security point of view, and they're nonstandard. You are best off having this sort of relay station in the way. The other thing is so outward bound, no two firewalls – also, this network does not trust the Business Network, just like the Business Network does not trust the internet. That's really the crux of the matter. 

Now what we have done at Uptake Fusion and what Microsoft has done is we are using a Microsoft construct called Nested Edge. Nested Edge allows us to put some software out of the Business Network, that is, IoT Edge Software from Microsoft.  This behaves as though it were an IoT hub from the data collector's point of view, and it then connects onward to the IoT hub. The nice thing about this is it works both ways. It works for data collection being sent up to Azure, and also it works from a control plane point of view so that certain messages and information sent through the Azure IoT Hub control plane can be relayed down to the data collector.

The reason why that is actually secure has to do with both the limitations on the type of message that can be sent from here, so this cannot do absolutely everything, and also the limitations down at the data collector of what messages it's prepared to accept. This configuration works even with multiple firewalls in a row and multiple relays in a row, and it makes it possible for this data collection system to go all the way up. You can even have an extension of the DMZ itself within Azure working as a virtual Network and then talking through an Azure firewall to the Azure Business Network. 

You can carry on this notion of a DMZ up to the cloud and have as tight security over this Cloud DMZ extension as you do over the on-premise one if you choose to go that way. It is not necessary to go that way if all you're doing is managing the retrieval of data, but if you're getting into things like sending commands down, then at that point, it becomes really important that you get into this notion of DMZ extension.