We're sold on the value of remote diagnostics via web browser to troubleshoot customer problems without travel. There's a lot of resistance from some about network vulnerability. What's my argument to this? A lot of it seems subjective.
—From December '10 Control Design
Keeping Control Is Key
In an age of malware, hackers, viruses and WikiLeaks, network security is on the top of everyone's mind. Most companies of any size have their networks locked down tighter than a drum. But to benefit from remote diagnostics, networks need to be opened up, and this results in some very legitimate concerns.
Even with a relationship founded on trust, when a factory depends heavily on external support, the risks associated with network security must be taken seriously.
Today, the best practice for allowing secure remote access of a company network is a virtual private network (VPN), but even VPN usage creates issues.
Generally, control of the VPN lies in the hands of the customer IT group. They face three challenges when setting up VPN access with current solutions. First, granting rights to and administering external users is very tricky (not to say uncomfortable) and time-consuming.
Second is lack of traceability; because of the inherent properties of VPN, the IT group has almost no way to understand how, when and by whom the connection is used.
Third, the need to open firewall ports to allow external access of equipment goes against corporate IT policies. When the customer network has not been segmented, a VPN connection provides access to the whole factory network—very dangerous.
So, what are the other options? Provide an approach that empowers the IT group to fully manage and control the VPN connections to their machines while simultaneously providing remote experts with a secure and reliable connection for efficient troubleshooting and diagnostic activities. Cloud-based services, for example, can enable the administrator to easily manage access control, allowing VPN connection to only selected machines and equipment over the existing IT infrastructure. The IT group suddenly enjoys a far better position to manage secure access to its networks.
ABB (www.abb.com) uses our company's technology globally to provide remote diagnostics for its industrial robot applications, and it allows customers to significantly reduce the need for onsite calls.
Dominique Blanc, Engineer,
Isolate the Network
Although it's true that remote diagnostics can open up a network to external threats, the implementation of a common network architecture can allow you access to the information you need and keep your customer's network safe.
There are two main network vulnerabilities that come to mind: gaining access to the customer's internal network, and theft of proprietary data about the state of its machines by a third party.
Fortunately, there is a network architecture commonly used by IT professionals that can allow only your company access to the customer's data and still keep you out of the rest of its network.
The first key to this is for the customer to set up virtual LANs (VLANs) on its internal network (see Figure). VLAN is a network standard, also referred to as IEEE 802.1Q, that segments your network into smaller networks, none of which can communicate with each other without permission from a central router. By placing all of the data that you would need external access to on one VLAN (the monitoring equipment and the web service), your customer can provide you access to everything you need without compromising its network integrity.
This idea of data isolation also can be taken beyond VLANs. The web service that provides data to the browser can be placed in a network demilitarized zone (DMZ), a section of network that is open to external communication, but isolated from the rest of the network by a second firewall. Any threats that make it through the first firewall via the web service still have no access to the rest of the network.
Everything mentioned has been about isolating internal components of the customer's network. There is still the problem of publishing data to an external web browser. Instead, the customer could forego that vulnerability entirely and publish the web service on its internal network only. You could then be granted access to the same VLAN as this internal web service through a virtual private network (VPN). A VPN treats a remote network as if it's on an internal network, while providing two-way authentication and protection against anything the Internet might throw at you.
So, by isolating the customer's network and allowing you only limited access to certain portions of it through VLANs, in addition to protecting its network from external threats through VPN, your customer should have limited realistic concerns about network vulnerability.
Doug Farrell, Product Engineer,
National Instruments, www.ni.com
Keeping It in Motion
While supporting customers of our motion controllers, we frequently connect remotely to their PCs. This is tremendously useful for tuning unusually difficult motion control applications.