Cellular in OT - Part 6
In this series we’re exploring various architectures we’ve encountered over the last decade involving the deployment of cellular gateways in OT / SCADA environments. By and large these cellular gateways have been deployed to replace previous communication paths such as POTS/Dial-Up or private licensed and unlicensed radio systems, microwave or perhaps integrate locations that were previously “offline”. I say monitored and imply these are used solely for the “DA” portion of SCADA (Supervisory Control and Data Acquisition) but I know first-hand that many are performing the “C” of SCADA over cellular as well. ***I’ll leave the discussions about whether or not anyone should do that to others; the focus in this series is on the various architectures once the decision to connect has already been made.***
In Part 4 we introduced the fact that dynamic IP SIMs do NOT support mobile termination so using them eliminates your “surface” at the edge for unsolicited traffic. In Part 5 we explored one solution that benefited from only needing dynamic IPs and here we’ll look at another, exploring it’s unique features.
TOSIBOX
The first TOSIBOX architecture beyond basic remote access and involving connecting multiple sites does so by connecting gateway devices (Locks) to each other directly. Looking at the graphic below, you would think that the lock on the left perhaps would require a public static IP to be reachable to the other two. What if I told you that wasn’t the case? What if I told you the below architecture was possible with all three locks on dynamic IP SIMs?
“MALARKEY! Now you’re just making stuff up.”
I’ll be honest the first time I read the TOSIBOX claims about being able to connect Keys/Users-to-Locks and Locks-to-Locks from behind firewalls (or as is most relevant to this series, using dynamic IP SIMs) without some type of persistent M2M server as hub I thought the same thing. And as it turns out, there IS indeed something not represented in the simplified graphic above - a vendor-managed, globally distributed, highly reliable matchmaking service. But it’s role is exactly and only that - matchmaking.
Below are a few of the TOSIBOX advantages I think are extremely cool:
-The matchmaking service and architecture means that unlike competing solutions, your data never goes across vendor servers despite the solution leveraging vendor orchestration. The matchmaking service helps facilitate the direct encrypted connection between nodes and then politely steps out of the way. This direct connectivity means more privacy and better performance (lower latency) with no M2M server hop in the data path.
-The persistent connectivity offered by the solution goes beyond socket communication and is layer 2 (bridged) when Lock-to-Lock. You can actually enable a layer 2 network extension between sites using 2 Locks without either side requiring a static IP or your data traversing a 3rd party server - mind boggling! Depending on the size of the network I might caution about doing so over metered/pay-per-byte cellular and might caution about doing this for general security/segmentation reasons but the fact that you can do this is impressive!
-Keys and Locks are available as hardware or software. A Virtual Central Lock option offers increased scalability and control and includes the choice of layer 3 (routed) connections between the VCL and other Locks, which are likely a better fit for cellular deployments.
-In the secure remote access part of the solution, the mobile client offers full equivalent connectivity as the desktop client so you can potentially connect to any IP, any service including utilizing your SCADA vendor’s mobile app for example. You’re not restricted to only HTTP(s), VNC, RDP like you are with some other solutions. With this capability, TOSIBOX offers a very comprehensive solution for Inductive Automation Ignition architectures, among others.
So how about this one? Does this combination of dynamic IP SIMs and a solution like above solve your secure connectivity problems? If you have any questions about the solution above, give us a shout.
We’ll continue this series further exploring edge initiated secure applications. See you next time!