If you are working with industrial IoT and industry 4.0 you will eventually encounter a very important question:
Should we design our IIoT project with or without VPN access?
On the one hand side a VPN or virtual private network gives you secure access to your devices and allows easy device configuration and setup, debugging possibilities, as well as a way to thoroughly analyse the devices. All this builds a strong argument for designing a new industrial IoT project with VPN access included.
So why are there so many strong opinions that you should not use VPNs?
If you look at it from a perspective of an IoT device manufacturer or system operator you assume that your specific devices are secure and well managed. You know that the VPN is carefully designed and that it terminates in your VPN endpoint. These are all strong arguments for using a VPN, especially considering all the additional benefits it brings. But looking at this from a communication network owner’s perspective will yield a slightly different view. The IT department that runs the network in the retail store or factory wants to offer a reliable and safe service. Their focus is on security and control. They use advanced firewalls and potentially analysis tools to investigate the traffic. They control some of the IT services in the network themselves, but in an internet of things settings there will be many IoT devices from third parties that will utilise the network and exchange data. With regular http or even https traffic it is not very difficult to analyse the communication patterns and register if wrong IP addresses are contacted. If you route your communication through a VPN this is much more difficult or even impossible to observe. In most cases the firewall is blind to what data is running through the VPN tunnel and it is also not clear which IP addresses are contacted. This poses a big problem for the industry 4.0 stakeholders that are responsible for the network and overall security. The more different devices that use a VPN connection the more cumbersome this issue becomes.
A real life example
We recently had an interesting discussion with a large retail company about their IoT challenges. The problem they face is that there are many small SMEs that provide IoT systems into their retail stores. These could be security systems, fridge and freezer monitoring solutions, people counter, mobile scanners for goods, building management solutions, predictive maintenance for various pumps, machines and much more. These systems are being delivered by many different vendors. Most of them seem to lack a good device management solution. In addition there is a catch-22. Many of these devices are not monitored very well causing a lot of manual maintenance. So in one way the retail company would like to see connectivity into the devices (often implemented by a VPN). So as a first step they accept this as a necessary evil. But in the long run they would prefer no VPN access to run in and out of their shops. Obviously this is a strategic and security decision. The data collected in the retail stores is extremely sensitive with regards to competitors and even the stock exchange. So security and control is mandatory. With smart analysis techniques you can analyse the temperature drops in freezers and associate that with how often the door is opened and closed. This can indirectly reveal information about the revenues in specific shops. Therefore, outgoing tunnelled connections may be a security issue gathering a lot of attention.
How can this conundrum be resolved?
In essence, a simple way to solve this problem is to have a VPN when you need it and do not have a VPN when you don’t need it. But can this be achieved? This is where the unique architecture of the qbee.io device management solution comes in. Our qbee agent handles all automation, over-the-air (OTA) update tasks and device configuration. In addition, it has a built-in VPN which can be dynamically switched on or off via a system settings from the cloud management platform. This feature allows to enable / disable VPN functionality for single devices, the whole fleet or a specific group. As an example, we have customers that enable specific devices for VPN access if unusual device behaviour is detected or additional debugging is needed.
A solution to the VPN discussion is a dynamically enabled solution that can combine both flexibility and security
So instead of needing to take a strong position in the VPN discussion our customers can select to always have the VPN enabled or always disabling it (according to specifications from final customers and their security requirements). But the interesting value proposition is that you can choose to enable it on a defined range of devices when needed and disable it again after log files have been analysed / downloaded or other analysis have been performed. This will also be acceptable for most industry 4.0 use cases.
