How to Be Selective About Remote Access in OT Cyber

The world as we know it has changed in the last few months.  Companies and nonessential workers switched to a remote work structure without taking time to determine how such a feat should be accomplished. A global pandemic is not typically something industrial organizations planned for when setting up network infrastructure and access.

Putting aside the technical aspects of securely setting up remote access, companies must also determine how to selectively setup remote access for users based on job function.  Asking Who, What, When, Where and How will help you create an effective remote access strategy.

Who will have remote access?

Asking this question may result in a generic answer of “Everyone, now quit bothering me,” but that would be unwise. Remote access should be treated as an insecure connection, and the more insecure connections into a network, the greater the risk of an attack.

Remote access should be granted on an as-needed basis:

• Only users who truly require access to internal company applications or assets to work productively should be given the rights to do so. For example, a manager or executive may only need access to email and conference call bridges, which are typically web-hosted and do not require a remote connection into the office.
• Technical departments like IT and engineering may require extensive access for many applications and assets.

It is also important to consider contractors and third-parties who also require access:

• Contractors represent an entire ecosystem of users that differ from company employees because of how they access the systems and what actions they’re able to perform.
• This should be tied into your organization’s third-party risk management, but this article will touch on it a bit later how third-parties should be managed based on their accesses.

Before a remote access solution can be securely implemented, determining access, roles, and identity management lays the groundwork for the rest of the process. The “who” is the foundation that will drive the outcomes of what these users need access to and how that will be accomplished. Think of the “who” as the keystone of an arch. Without the keystone, the rest of the arch will crumble.

What will remote users have access to?

Determining the company assets users have access to can become a complicated and time-consuming task.

• Start by simply enumerating remote users by department and job function (role). For example, technical workers typically require different access than managers, executives, and sales. This kind of a breakout determines what types of access to grant users and how this will be accomplished.
• After breaking users down by department and function, restrict access by their role and assign site-access within the organization while keeping in mind how role-based access-control (RBAC) degrades over time. Managers and executives typically need access to business applications (email, conference calls, hosted web applications), whereas technical teams need interactive remote access (remote desktop, VNC, etc).
• Use your organization’s accurate and detailed asset inventory to classify assets by criticality to the organization, but also Safety-Reliability-Productivity (SRP) within Operational Technology environments. This also applies to traditional Informational Technology within an organization, but correct user access is tied to the “what” they can access. Map the distinct roles to the assets and network segments appropriate for assignment.
• Design, configure and develop the network architecture by implementing new access controls while monitoring and slowly rolling them out starting with the immediate “who needs access today”, next down the list, until all users are rolled out using the new system.

It is important to put restrictions in place to limit the defined “who’s” and the “what’s” that access applications and assets while preventing direct access – even within your networks.  OT environments are often “soft” within their perimeters, and it will be your security team’s worst nightmare if something gets loose inside.

When will users need access?

This question is commonly overlooked.  Contrary to popular beliefs, every user will not need access 24/7/365:

• It’s important to apply working hours to user profiles, which is a typical best-practice in security and less of a work-life balance factor (although important!).
• Implementing remote access time restrictions assists the IT security department with detecting malicious activity. For example, if Bob typically works 9-5, but is now attempting to login at 2 AM, a novice security analyst should be automatically assigned this event as one for investigation.

It is also essential to understand how time restrictions keep your infrastructure stable. In the OT world, there is a common mantra: “No changes on Fridays”.  No one wants to work over the weekend to fix a problem created by a user or a change. Time limits reduce the probability of unintended changes that could cause emergency work or system access outages.

However, in the case of an emergency, it’s important to have an emergency authorization procedure to fall back on.

Where will users remotely access from?

This is straight-forward: Users should only access company assets remotely from other company owned assets, and through authorized means (e.g., no rogue access points or technology such as TeamViewer):

• All company employees should have a company system (e.g., laptop) that is used explicitly for remote access.
• Employees should not use their personal computers for remote work unless to access resources very limited in scope (e.g., call in-bridge).
• Company-owned laptops should be remotely manageable where system administrators apply their endpoint management technologies to track patch status, antivirus signature dates, applied configurations, and other security-related applications such as whitelisting.

There is, however, a caveat to this:  Many companies have contractors that need remote access and do so from their systems only. In this case, additional restrictions and endpoint monitoring should be applied to these users and their systems (even when onsite and not remote).

Regardless of your choice of secure network communications (e.g., IPsec VPNs), many remote access clients or portals verify that a remote users’ computer meets specific security requirements.  For example, connection may only be attempted after determining if the endpoint has up-to-date antivirus signatures and the operating system is fully patched. Is a good idea to implement policy pre-requisite checks for any user that needs access from a non-company computer.

How will users access systems remotely?

Determining how users gain access ties everything together and is a critical step for enabling secure remote connectivity.  This is a time-consuming task, but there are several important components to consider. So, let’s review what we have learned so far:

• Enumerate all users, group assignments, and permissions
• Map assets to the enumerated users and groups in the first step
• Design and implement the appropriate architecture for remote connectivity including endpoint system protections
• Ensure appropriate security controls are in place to authenticate and authorize remote users
• Ensure network and technology controls limit users (remote or otherwise) to systems within a facility
• Continually monitor, adjust, and protect

Now creating a remote connection to a site via a VPN is old news, but for the purposes of securing remote systems, even typical enterprise Information Technologies (IT) such as endpoint controls, remote access portals (e.g., Citrix) and Multi-Factor Authentication (MFA) should be used where technically feasible. In fact, MFA should be the de facto standard with all remote access when ensuring the user authenticating is actually that person, and not some malicious entity attempting to gain access.

Often there are many low-cost solutions and sometimes nearly free (as they are already present within the organization) options, but the whole idea is to:

• Discourage malicious users from free reigns when probing your remote connectivity, users, and infrastructure
• Generate an opportunity to raise the alarm when a system is compromise
• Limit damage from a compromise, whether on the remote system, the network perimeter, and even from within once a remote user has connected.

Another highly recommended option is to use a remote access portal as part of a layered remote security architecture. This can be an important component when building secure remote access solutions because traditionally (and insecurely) users might only connect only using a VPN and then freely roam around. It might be an economical solution, but it is very insecure and costly if an attack occurs.

At the bare minimum:

• Users should connect from a trusted system, or one that has had its security status validated before being able to initiate a connection to remote infrastructure
• Users should be able to securely be authenticated, authorized, and transmit data securely to and from the remote assets
• Remote users should have a single endpoint (server, cluster of servers, or remote access portal) they access remotely once authenticated & authorized, which can then be used to allow users to “hop” to where they need to go. These systems should have the latest patches installed, limited installed software, install antivirus, deploy application whitelisting, log all access, hardened configurations, frequent and validated backups, and every other manner of relevant compensating controls.
• All user accesses should be continuously monitored, and any actions taken must occur with care (e.g., it would be a shame to lockout a user at 2 AM during a legitimate incident or support call).

For the third point in that list, the best solution is to use something like a remote access portal.  There are countless solutions on the market that can fit any budget.

• Citrix and Microsoft Remote Access gateway are the first two that come to mind. Even some next generation firewalls or universal appliances have these abilities.
• Many of these portal solutions allow administrators to limit users to applications based on user rights assignments. For example, once a user authenticates to the portal, they are presented with options for access.  This could be access to internally hosted applications or even remote desktop access. The user then just clicks on the shortcut.  With this control administrators can limit who can access what, when and from where.

To ensure secure connectivity of your critical process assets:

• These assets need to have the highest protections afforded to them not only because of their effects on revenue but the human safety and environment (HSE) factors involved.
• Access to these assets should be directed through what is called a “Jump Host” and prevent any direct access from an external host or network zone.
• This jump host can act as a host-based DMZ that bridges two dissimilar network security zones. Typically, users will authenticate to this jump host, and from there can proceed to access the critical process devices.  This jump host allows administrators to control access to the critical devices within the industrial network.

Secure remote connectivity

Applying the who, what, where, why, and how to your remote access solution ensures a secure remote access setup. It is important to work through each step methodically and to not be afraid to restrict unnecessary access.

Configuring remote access is a journey. It requires fine tuning , but it is well worth it to protect your assets from unauthorized access and expensive downtime during tough economic conditions – especially when a variety of high-profile malware and attacks often originate from network access and remote connectivity technologies.

And don’t forget, “break-glass” accounts for “emergencies” may sound tempting in an effort to appease engineers and OT, a better and mutually aggregable solution can be found. It’s not worth the risk of an account compromise.