Methods for establishing secure remote access with edge computing
In the second part of our blog series, we looked at the first stages in a remote access project. After selecting the industrial assets that need to be connected, it is time to look at how you can establish secure remote access. There are a variety of methods for doing this. We want to highlight three methods here that can help mitigate the potential risks of remote access and can be established fairly quickly by using a managed edge computing platform. The choice of methods available can differ depending on the use case, the type of asset and they types of interfaces the asset has to connect to the network.
1. The difference between point-to-point and centralized remote access
The easiest way of connecting to an asset is point-to-point access, i.e. establishing a direct network connection via e.g. a router or firewall to the asset’s local management interface. This works well for consoles or webservers. However, the most widely use remote access methods for these types of interfaces – TeamViewer, VNC, or local webservers – are not intrinsically secure. Authentication using only a password is technically possible and, unless prohibited by the organization’s security guidelines, could be a potential safety concern. One way to mitigate security issues is enforcing secure configuration of authentication (e.g. by means of RBAC), or by using centralized remote access. This is possible by introducing a managed edge platform with a centralized management system. This adds another security layer, as users connect to the management system instead of directly to the assets. Monitoring and managing of the assets can be carried out via the management system and integrated virtualization and analyzation tools.
2. The advantages of role-based access control (RBAC) for secure remote access
RBAC is a means of limiting access rights to a system according to user roles and is referred to in the IEC 62443’s Authorization Enforcement Requirements. RBAC has been used in IT for a long time, but it is also a good choice for industrial environments. The admins first establish what tasks users need to perform (e.g. monitor machine performance, update software, perform patch management on production-critical applications) and what application they need to access for accomplishing those tasks. Granting selected and fine-grained access rights and privileges for each user (e.g. “can modify resource X via remote access” or “can access resource Y read-only via remote access”) increases the overall safety level – even if one user account should be compromised, only a part of the system will potentially be accessible by a third party. It is also recommended to add two-factor authentication and a “strong password” policy, something already used very often in IT environments. On a technical level, authentication is mostly linked to a directory system via LDAP, which can serve as the basis for RBAC.
It should be mentioned that sometimes third parties (e.g. an asset vendor’s maintenance team) need temporary remote access for a specific task and setting up dedicated user accounts for each member of the maintenance team might take too much time. If there is a well-documented process including logging and auditing, a “local user” account on the asset may be set up by a secured and authorized account within the RBAC. This “local user” account may be disabled again after the maintenance task has been carried out.
The well-documented process mentioned before is another important aspect that ties in with RBAC. Access to the system/industrial asset as well as access rights and privileges for each user account need to be monitored and updated. There should also be logs of all system access attempts – successful and failed. As in an IT environment, several failed log-in attempts must result in an (automatic) temporary or permanent lock-out to help detect and mitigate malicious access attempts.
3. Establishing secure remote access for legacy assets
Legacy assets are very common in an OT environment. Machinery on the shop floor is a large investment and equipment is in use over many years, sometimes decades. The machines’ performance remains constant over a long period of time, but the controllers and software they use may become outdated or, in some cases, even obsolete. Therefore, many modern features like centralized supervision and management are not possible for legacy assets and they also do not support state-of-the-art security mechanisms. An update of the legacy assets’ software, drivers, or operating systems is either cumbersome, costly, or sometimes no longer possible. The best option for connecting legacy assets is usually the encapsulation of the old, unsecure interfaces by means of virtualization or containerization.
Virtualization refers to the creation of a virtual machine (VM) based on e.g. an old Windows PC and its execution on a state-of-the-art, modern IPC. This way, the old software can continue to be used. However, as it is a “program” running on another, more secure IPC, no direct access to the unsecure legacy application is possible. Containerization is another way of encapsulating legacy software, usually by means of tools such as Docker. It requires fewer computing resources than a VM and is ideal when several individual legacy applications need to be migrated and run in parallel on a modern host computer.
For most use cases, a combination of different access methods is the way to go. A managed edge platform can help to speed up the implementation process significantly. In the last part of our blog series, we will look at our edge computing platform Nerve and how it supports the secure remote access for industrial assets.
This blog post is based on a technical article that was written for and first published in Industrial Ethernet Book (July/August edition 2021). You can find the full article here at iebmedia.com.
