Remote access to resources over the internet is an everyday experience for all of us. We use a web browser or similar technology to search for information or buy goods online many times every day, often without thinking about the amazing technologies and distances that are involved.

This is especially true in the times of COVID-19 and the sudden increase in working from home, where the need for remote access to company resources from outside the company network through a VPN, via RDP or some other interface has become ubiquitous.

That is not yet true to the same degree for remote access to industrial automation equipment and assets on the shop floor. The operator will usually be close to the machinery to access HMIs and panels, even if the interaction itself would not require this physical proximity. In this article, we are considering various use cases and methods for remote access to the industrial edge and OT equipment.

As this article happens to coincide with the largest and most severe wave of cyber-criminality against industrial systems and critical infrastructure so far, security considerations which need to have high priority for industrial automation related technologies and solutions anyway now become a truly predominant issue. We will therefore discuss various methods for remote access, their benefits and restrictions, and also highlight security-related aspects.

Abundant remote access targets

Assets at the industrial edge can come in many sizes and performance ranges, and this is reflected in the various methods for remotely accessing these assets.

A PLC might have an SSH daemon for remote access, while a multi-core edge server might host several Virtual Machines (VMs) along with some Software-Defined Networking (SDN) management entity and a Baseboard Management Controller (BMC), each of which may have one or more management or data interfaces to be considered for remote access.

Some targets for remote access offer old-style command-line shell interfaces, others present a webservices-based REST API. OPC UA servers are becoming more prominent, as are GUIs via HTML5. The favorite for human remote users is remote desktop access with high-definition graphics provided via Xserver, VNC, TeamViewer, RDP; the options are endless.

Some of these interfaces offer no or insufficient authentication and protection methods and are intended for remote access from within a trusted network only. However, which network can be trusted and is guaranteed to be free of security risks? Taking a defensive view on security, we should require proper security – at least SL 2, speaking in terms of IEC 62443 security levels – for any access to any component in the network. That is not the case today.

For example, some assets contain a simple webserver which presents access to some of the asset’s data or management via unencrypted HTTP protocol only. Such an interface could technically be made available for remote access by port forwarding or port triggering mechanisms, but it might not be a good idea to do so without restricting the remote access to the unsecured interface to trusted counterpoints (e.g. address whitelisting on the firewall) and tunneling over a secure transport protocol. But is it even feasible to define trusted counterpoints if we want to be flexible?

Centralized access vs. point-to-point

When we want to get remote access to an asset, the most obvious strategy is to use a direct network connection from the user’s equipment to the entry point of the asset’s local network, such as a router/firewall, which forwards the connection to the asset’s local management interface.

This strategy is frequently found when the asset natively provides some remote access capability, such as a console or a webserver. The security of the user authentication depends on the capabilities of that specific interface – for example username/password/two-factor authentication or X.509 certificates, and possibly on the compliance of users with the guidelines . Assets which provide access interfaces with approved security mechanisms can be directly accessed point-to-point by any authenticated user from any location on the internet.

Unfortunately some of the most widely used methods for remote access to assets that support a GUI, such as TeamViewer, VNC, or local webservers, allow the configuration of less secure (but presumably more convenient) authentication methods, for example a password.

Such possible security pitfalls can be addressed either by stringent enforcement of a sufficiently secure configuration of the authentication mechanism, or by “encapsulating” these remote access methods in a secure central management system environment. Users who want to gain remote access to an asset first need to log into the central management system and can connect to the less secure entry point for remote access at the asset from there.

An industrial edge management solution such as TTTech Industrial’s Nerve should support secure remote access to intrinsically unsecure asset interfaces by tunneled port forwarding between the asset and the secure central management system. The management system can then be used from anywhere in the world as the trusted counterpoint for remote access to assets which do not support secure remote access by themselves.

Role-based access control

Remember the recent case where a “hacker” infiltrated a water treatment plant’s network infrastructure in Florida thanks to a shared password for TeamViewer applications that granted full access at the plant? If we do not want to get caught up in a similar incident, then it would be a wise choice to follow the state-of-the-art in industrial security practices: The IEC 62443’s Authorization Enforcement requirements mandate that access privileges to assets must be managed by a sufficiently fine-grained Role-Based Access Control (RBAC) system. Such an RBAC typically is based on a directory service, e.g. Microsoft Active Directory.

In such a directory service, individual user accounts are maintained along with state-of-the-art authentication, ideally two-factor but at least a “strong password” policy. Access rights and other privileges are granted to an authenticated user based on the roles of that user account or the groups that this user account belongs to. No singular “admin” or “operator” password or token exists, only user accounts that have the privileges to perform administrative tasks. This must also be the case for remote access.

The RBAC strategy has been in place for IT assets for what feels like a century (fun fact: Microsoft Active Directory was first released in 1999) and should equally be used for OT assets. Any method provided for remote access must first authenticate the user and then check the user’s specific privileges for remote access – which can be fine-grained, e.g. “can modify resource X via remote access” or “can access resource Y read-only via remote access”.

RBAC is just one important aspect to secure remote access. To meet the requirements for industrial security standards, logs of accesses and failed attempts need to be available, repeated failed attempts to gain access must result in temporary or permanent lock-outs, and changes to the privileges defined in the directory must be tracked. In this way, malicious attempts to gain access either by brute-forcing or by adding a back-door account (insiders are responsible for more than a quarter of cybercrimes) can be detected and mitigated.

The scope of required or recommended practices to achieve state-of-the-art security for industrial automation systems cannot be exhaustively listed here, but obviously must be addressed by anyone building and operating remote access capabilities for industrial edge and automation systems. Thankfully, solutions to support this are available – such as TTTech Industrial’s edge management platform Nerve.

Customer experience

Remote access to assets by users is a very important part of Industrial IoT use cases. The use cases range from read-only access to data dashboards and monitoring of machine performance to software updates and patch management of production-critical applications.

More and more maintenance activities on OT assets are expected to be performed remotely, or at least with the option to perform them remotely. Even if the maintenance is regularly performed in the physical vicinity and only rarely over a remote access channel, it should look and feel the same for comfort and to minimize errors, and therefore should be based on a method that supports secure remote access by default.

A key feature of an industrial edge management system is the ability to enable secure remote access for many users to all kinds of status and control interfaces – from command-line shells, OPC UA servers, REST APIs, webservers etc. to the entire GUI of a VM. This is especially true for older, legacy interfaces which do not support state-of-the-art security mechanisms.

When setting up remote access to such a wide variety of assets, it is simply not feasible to constrain the management system to a single connection method – rather a mixture of SSH, VPN, RDP, HTTPS etc. is needed. Security considerations are critical and keep growing in importance, but many customers understand that they cannot expect all security guidelines to be heeded by human caution alone and prefer a solution that can securely encapsulate unsecure interfaces.

While the wide range of remote access methods is a fact of life, the requirements for systematic security – typically according to the IEC 62443 (or at least its main principles) – are also among the top priorities. Authentication for any kind of access, and obviously also for remote access, is already predominantly linked to a directory system via LDAP, so the basis for secure RBAC operation is also laid in many cases.

There must be no more incidents where critical infrastructure is accessed by a “hacker” discovering a local account with a weak or default password.

There can also be valid exceptions to the RBAC strategy: Sometimes a third party that does not have any regular access to or relationship with the asset owner’s infrastructure might need access to a very specific asset and only to that specific asset. For example, the asset vendor’s maintenance team may need to perform an upgrade to the asset’s firmware. This is clearly a security-related process and it must be ensured that only authorized third parties can gain remote access to perform the maintenance task. However, adding a dedicated user account for each of the vendor’s maintenance team members to the asset owner’s directory services seems excessively burdensome.

For such cases, it may be desirable to have a well-documented process to temporarily give the minimum necessary remote access privileges to a “local user” account on that specific asset and let the maintenance crew use that account. Obviously, the user account which can enable and manage this “local user” account must be a properly secured and authorized regular account in the RBAC, and all logging and auditing requirements must be met. We are currently investigating how this functionality can securely be implemented in TTTech Industrial’s own edge computing platform Nerve.

Conclusions

Remote access to assets at the industrial edge is considered a very important capability by users because it greatly improves flexibility for many workflows in diagnostics and maintenance. This was true before the pandemic, but it has become even more relevant now. And just like remote working in general, we expect the trend towards more flexible remote access to continue.

However, security concerns must be on top of the priority list and cannot be subjected purely to ease of use considerations. Since many assets do not (yet) offer suitably secure methods for authentication and privilege management for their management and status interfaces, it is up to the edge management system – such as TTTech Industrial’s Nerve – to provide a set of mechanisms to “encapsulate” these interfaces in a secure way and provide access only to properly authenticated users with appropriate privileges.

Georg Stöger, Director Training and Consulting, TTTech Industrial