A Matter of Trust: Remote Access for ICS

Operational technology (OT), the systems and devices that power critical infrastructure and our modern way of life, is a unique industry. As asset owners and operators, our equipment is often difficult to replace, requires special training to manage, and is located in either remote locations or in large industrial plants. Troubleshooting these systems may take days or weeks of special maintenance procedures working across vendors, system integrators, and engineering teams – all while on-site.

Background

For decades, on-site support was the only solution for OT systems. If an organization was going to make any changes – digital or otherwise – to critical systems often under 24/7 operating conditions, it was important to have engineers and support readily available. Financially such support can be expensive and difficult to coordinate across many disparate stakeholders. So, in the age of connectivity, many of these systems were retrofitted or re-engineered to include remote monitoring and access in order to lessen the burden for organizations and increase visibility into operations. While TCP/IP connections in OT environments were becoming increasingly popular in the early 2000s, many organizations were learning the hard way that cybersecurity needs to be “built in” and not “bolted on” later.

To complicate the situation, many traditional information technology (IT) solutions will not work for OT. It’s not as simple to “just VPN” into these critical environments. Industrial control systems (ICS) were designed for operations. Meaning they were designed to accept commands from good guys—from engineers. The idea that a malicious actor would enter bad commands to jeopardize reliability, cause equipment failure, or otherwise risk safety is not something that designers had ever considered. Because of this, historically ICS devices did not have the protections found in IT. Moreover, these devices often cannot track users “logging in” or complex passwords to lock out bad actors. In ICS security, we often refer to these lack of internal defenses as the M&M model: a hard shell (such as perimeters) and gooey center. Engineering this hard shell is one of the most important investments to mitigate cyber risk within critical infrastructure. Another great analogy is protecting your crown jewels (the industrial process) in a fortress by creating a strong set of defenses, like a moat and highwalls (akin to a firewall), drawbridge (strict access permissions), and archers (monitoring and threat hunting) along this new perimeter.

Enter remote access. As mentioned, our industry added digital connectivity across remote OT sites to improve visibility and monitoring—and even allow for some troubleshooting and maintenance operations. Remote access has become a vital part of operations for several industries. This capability can help optimize resources, improve processes, and provide information vital for reliability. That said remote access, by definition, needs to penetrate the hard shell of industrial control systems to reach the gooey center. As such, organizations should always give careful consideration when adding new remote access connections for industrial control systems.

Quick Guidance on Remote Access for ICS

First and foremost, do not enable remote access by default. This is not a strict anti-remote access stance—rather a pro-engineering discussion. Because remote access is a “gate” through the (hopefully robust) perimeter and moat and walls of your fort, you want to make sure it is secure. This requires multiple stakeholders to be involved, including OT security, IT security, engineering, vendors, and any maintenance support teams. It is not something that is easily pre-packaged and it is never a “set it and forget it” capability.

When possible, leverage guidance from a standards development organization with specific ICS recommendations on remote access. For example, ISA/IEC 62443, NIST SP 800-82, and NERC CIP all have companion guidance documentation regarding remote access and general recommendations for expanding your security program to cover this new capability. Most of the guidance can be covered as:

• Engineering and OT teams should evaluate what systems can leverage remote access.
• Remote access requirements should be determined, including what IP addresses, what communication types, and what processes can be monitored. All others should be disabled by default. Remote access including process control should be limited as much as possible.
• User-initiated access should require multi-factor authentication from the Internet to a DMZ with a dedicated jump host for ICS-specific communications. This system should leverage its own identity and access management system.
• From the DMZ, after authentication, user-initiated remote access should follow a trusted path to the industrial control system—where the user will authenticate again, this time using the local identity and access management solution for the industrial control system.
• All remote access communications should be logged and monitored. Various detection techniques could be implemented on remote access systems, like looking for brute force attempts or specific exploits for known vulnerabilities—but only if logging and monitoring is used.

Developing these requirements should take time and careful consideration. While many vendors are offering free remote access solutions, organizations need to understand how such solutions may impact the security of your fortress and the corresponding crown jewels. It goes without saying, but these solutions should never be simply downloaded from the internet and installed within the control system environment. Your crown jewels deserve better protection than that.

Conclusion

Remote access is a relatively new capability for industrial control systems—one that comes with specific engineering and financial benefits. However, when considering new remote access connections, organizations need to involve the necessary stakeholders to make security and reliability-based decisions. Industrial control systems were designed with engineering in mind, so any changes to those systems should use the same rigorous processes that created them.