”Secomea – Remote access reinvented for M2M, the IoT, and everything in between” – A punch line from a newsletter published by Secomea distributor Industrial Networking Solutions in the US.
The quote is a perfect illustration of the difficulty in matching up practical needs and buzzwords. The purpose of this article is to define M2M (machine to machine) and IoT (Internet of Things), place the terms in a practical remote access context and provide direction and advise in order to eliminate the concerns you may have in relation to choosing a sufficiently future-proof remote access solution for servicing industrial equipment.
IoT and variations hereof
Let’s start by placing IoT in context. Many consider “IoT” to be in the same buzzword category as “Cloud” and see it more as a vision of everything being interconnected via the Internet, (hopefully) available to systems and persons that need it, and (hopefully) for the right reasons.
Generally, IoT is seen as a very broad concept originating from M2M and other technologies. At a higher level IoT is often divided into two categories; Applications requiring human interaction, characterized as “Human IoT” (HIoT) and the more hyped “Industrial IoT” (IIoT). HIoT is typically referred to in relation with home thermostats, fitness trackers and similar consumer oriented goods. The immediate assumption might therefore be that it also covers human remote access to industrial devices for interactive servicing purposes, especially since IIoT lacks the “human” prefix and rather implies the ability to operate without human intervention. However, as explained below M2M is in fact categorized under IIoT.
Common for both IIoT and HIoT is that an ideal roll out of technologies would require IPv6, and in a perfect world this would include pathways to include the huge installed base of legacy industrial devices. Mandatory elements of the IIoT would also be End-to-End security, No single point of failure, Autonomous node and application discovery just to mention a few objectives typically identified by IT professionals.
Comparing all these desires and requirements with the reality of today and the foreseeable future, soon makes IIoT seem overkill for the challenges and practical needs that the automation industry is facing.
Seen in this light, M2M should definitely not just be seen as “yesterday news”, but rather as a definition of a valid subset to IoT with a more vertical and practical purpose in mind. Simply put, M2M is a definition of machines using network resources to communicate with remote applications for the purposes of monitoring or controlling of either the machine itself or its environment. In this definition the human interaction is just a service add-on, and one can consider the human operated application for temporarily performing deeper service of machines, as one of the “Ms” in the M2M definition.
So in reality M2M is categorized more specifically as a subset of IIoT rather than HIoT even when human interaction is involved. So let’s zoom in on M2M.
M2M planning rule no. 1: Start with the business case!
Remote access to industrial equipment has already become a must-have for OEMs and system integrators in order to live up to contractual obligations. It is not just about staff and travel budget cost reductions; more critical is the obligations for response-time and up-time. With the increasing complexity of industrial installations, timely and efficient use of critical engineering resources is absolutely vital. Optimizing service offerings and resources, requires selection of the right M2M solutions here and now, so focus is kept on the core business.
A. Define your needs now and in the foreseeable future
First make sure to identify the category of “remote service” that covers your needs:
1. Remote Monitoring. The term Remote Monitoring (or Remote Management) typically covers collecting specific predefined information from devices, and processing them on a central server. The main purpose is to perform preventive or predictive maintenance, and if a critical problem is detected, a technician will travel on site. Note that such solutions are typically not designed to allow establishment of connections through which you can service the equipment remotely.
This type of solution is very common for utility installations (electricity, gas, water etc.)
2. Remote Service via Remote Desktop. Several low cost, or even free solutions, exist for providing remote desktop access to equipment inside a network. Most of the solutions require that both ends are manned, which is typically not the case for a service PC at the factory. Solutions do exist that allow secure remote access to un-manned equipment inside local networks, but these solutions are typically not cheap. Add to this the administrative task of maintaining a Windows PC (with its frequent security updates) and the potential cost of software licenses for the PLC or HMI programming software packages installed on the PC, and the setup may seem less ideal.
3. Remote Service via port forwarding. Solutions in this category are typically based on a hardware unit at the site that acts as an Internet router to the equipment. The most simple solutions are based on the router having a fixed IP address on the Internet, which “routes” or “port forward” incoming connections to the equipment; pretty similar to the traditional Dial-up modems. This type of setup is typically seen for video surveillance. The risk of exposing access to industrial equipment directly on the Internet, using un-encrypted connections, combined with the need for fixed IP addresses, essentially rules these solutions out.
Illustration I: Access by un-encrypted port forwarding
Factory firewalls must open for relevant ports that are forwarded to the devices.
A setup that may be acceptable for passive components such as Web-cams,
but represents too big a security risk for accessing machines.
4. Remote Service via data “tunneling”. This is the kind solution that would fit most remote service needs. Traditional IT solutions based on VPN have existed for more than a decade, but in recent years, VPN solutions specifically addressing the automation industry have multiplied. Most of them are just traditional VPN solutions packaged for automation use, by offering DIN rail mounting and 24V power feed. Some vendors have taken a step further to disguise complex IT configuration from the users and eliminate need for changing firewall settings. These solutions typically involve a central M2M server, acting as a portal for user access control and data redirection. At least one vendor, namely the Danish company Secomea, has evolved away from VPN completely, and instead uses a concept of encrypted proxy connections for solving challenges that VPN technologies by nature have difficulties to overcome.
Category four typically represents the common denominator, since this entails the biggest challenges in terms of operability, security and scalability. I.e. if you can make easy and secure interactive tunneling access to devices there is a good chance that the same infrastructure will address other remote access needs, such as data logging.
If you discover that your preferred category four solution does not concurrently support the other needs, and a totally different solution is required for addressing them, then research if it has significant impact on your processes and resources. It may make business sense to separate them.
Now, let us elaborate on the “category four” requirements.
B. Ease of deployment – a vital part of overall industrial security
Ease of installation and configuration is essential for saving time and enabling non-IT literate personnel to deploy the solution. It should not be necessary to configure firewall or routing rules or install third party software that is not an integrated part of the solution. Installation and initial configuration should be possible to do by dispatch personnel or the engineer that handles the electrical wiring, and user access control and configuration of device access should be manageable by the PLC programmer, the OEM project manager or the site administrator.
VPN is a secure and proven method for interconnecting office networks remotely, or to provide secure access for remote users to a central office. For VPN in the context of remote service, however, the need is to provide remote access for different users to different sites, and maybe even limit access to specific equipment. Managing this by traditional VPN is a huge administrative and technical challenge to configure and maintain, even for a skilled network specialist. Keep in mind that security is not only a matter of encryption and authentication, more important is the human factor. Lack of knowledge, confusion or neglect leads to configuration errors and subsequently security breaches. In any case dependency of skilled specialists and thorough documentation should be avoided.
Most remote access solutions would advocate for security in terms of encryption, so invest your time ensuring that the solution has an intuitive and visual GUI to administer users and site access.
Illustration II: Remote access by traditional VPN
Typically VPN client connections are firewall outbound and to avoid opening ports inbound in corporate firewalls,
all access has to be routed via the concentrator.
A setup that requires a lot of IT intensive Firewall/Router administration and has great risk of opening for “too much”.
C. Security argumentation for using the customer’s network
Typically a factory or its machines would run in a network isolated from the corporate office network, but typically it will only be the office network that can connect to the Internet. When using a standard VPN enabled router for accessing the machine network, you would typically connect its WAN side to the office network and the LAN side to the machine network.
IT departments will not be happy about a third party connection between the networks, even if you argue that the router has a built-in firewall that prevents unauthorized access between the networks. So you will have to explain precisely how the solution works, and why it does not compromise security. Such information should be provided by the remote access solution vendor.
Additionally, the solution must be able to establish its encrypted tunnel connection to the Internet based on ports that are commonly open. This would be “web” ports such as 80 (http) and 443 (https). Do not expect IT departments to open specific ports on your request.
In case a corporate policy prevents any third party initiated access to the Internet via the office network, you should not fight the IT department but rather look for alternatives and compromises. Either request the customer to establish a separate Internet connection for machine access, or use a remote access product with a broadband option.
D. Network conflict issues
Maybe one of the most common issues when interconnecting multiple users and networks is “network conflicts”. When connecting networks statically via routers or VPN connections, all networks must have different “IP subnets”. In the ideal IPv6 future this will not be a problem, but it surely is today and for many years to come with IPv4.
A typical issue is that two factories may use the exact same IP subnet. Most industrial remote access solutions solve that by dynamically establishing the connection on-demand, and closing it again when done. The only limitation is that the service engineer cannot be connected to both factories simultaneously, which would typically not be necessary either.
More critical is the scenario where the engineer sits in an IP subnet that is identical to that of the factory (e.g. a user sits in subnet 220.127.116.11/24 and attempts to connect via VPN to a factory that uses the exact same subnet). For routed technologies this will simply not work. It could be solved by making alias addresses and applying NAT (Network Access Translation), but it is not trivial.
You must ensure that the remote access product has a solution for this scenario. For instance the Secomea solution is based on encrypted proxy connections and not VPN, which makes it immune to subnet conflict issues.
E. Two-factor Authentication
Typical VPN for statically interconnecting office networks is based on x509 certificates that are manually exchanged between the VPN peers during the initial setup. In recent years SSL/TLS based VPN solutions have become popular due to being” firewall friendly” and automatic bidirectional authentication. The concern with many such implementations for industrial access is that the initial authentication is based on only a user name and a password.
Two factor authentication means that you have an extra level of authentication, such as a personal certificate file stored on the PC or a time limited code sent to the remote user’s cell phone as a text message.
So, make sure that two-factor authentication is available for the remote access solution.
Illustration III: Remote access via M2M server
All connections are firewall outbound, encrypted and terminated at the M2M server.
Access control is administered and logged centrally on the M2M server and is typically manageable by non-IT literate personnel.
F. Traceability, logging
Documentation of Who took access to What, When! The purpose is not only to document if a given remote user may have been causing an issue on a machine, it is also to document that a service provider is in fact fulfilling his service obligations.
Check if audit logging exists, and how it can be accessed.
G. Observe safety standards
For the automation industry, Safety is often considered just as important a topic as Security. Motion based equipment may even be subject for government regulations that dictate OEMS to ensure that remote service access to the machine is properly signaled to the operators (standards such as EN 415-10, Safety of packaging machines)
The M2M and IoT debaters have a tendency to overlook such demands and instead focus on security and interoperability.
Check that your vendor has embedded measures to address such regulations.
H. Dependence of third party cloud services
As mentioned earlier, using a central M2M server is becoming essential for controlling user access and data connection redirection.
Such services may be free or be subject to maintenance fees. Investigate fees in relation to scaling the solution and make a strategy for which budget to place such costs on.
More importantly, you may investigate if the M2M server is available only as a cloud service hosted by the vendor, or if you can migrate to your own M2M server. Major OEMs generally do not like to be dependent on a specific vendor’s existence, their server’s up-time and applied security measures (in principle the vendor is having “root access” to all machines).
As result of adopting the Internet as remote access carrier, the rapid increase in new technologies and trends in the IT industry has become a key discussion topic for the automation industry. New buzzwords starting to be adopted by the industrial solution vendors just adds to the decision maker’s confusion and uncertainty.
Rule of thumb: Look at it pragmatically and do not let IoT and IPv6 visions become key drivers for your decisions, but verify that your preferred solution vendor is likely to follow pace with the technological evolution.
First and foremost look at what can optimize your business now and in the near future, and how this optimization can benefit your customers. Use practical guidelines as those listed above to help matching the best solution to your business case.
About the author Peter Koldig Hansen
Peter Koldig Hansen is Product and Marketing Manager and co-owner of Secomea A/S and is also in charge of strategic product definition and business development. With a background within electrical engineering his professional career includes Director of R&D at Intermate A/S from which Secomea out-springs and R&D Manager at Eastman Kodak.