How to Avoid Mistakes with Control System Remote Access

Feb. 12, 2014
As more operations aspects are tied to Ethernet networks and, therefore, are open to Internetbased access, the potential for greater collaborative operation and a freer work environment increases.

As more operations aspects are tied to Ethernet networks and, therefore, are open to Internetbased access, the potential for greater collaborative operation and a freer work environment increases. But so does the potential for security problems. Following are some basic tips and considerations for achieving secure and reliable remote access:

1. Map out your project from the start. When companies fail to map out their projects thoroughly from the start, they often find themselves saddled with applications and automation products that don’t work cohesively as a single system. Once you start implementing various silos—be they applications or products—things get more complex. This is typical of problems that occur when automation products are implemented hastily, without doing proper research, planning, or analyzing current and future goals, or without realizing that implementing remote access monitoring for a facility is just step one of many.

2. Anticipate network interactions. When people have installed devices on a proprietary network then try to use something different (e.g., Wi-Fi or another protocol), individual systems may conflict. Or they may just cancel each other out, so that there is no communication whatsoever. More often you find yourself managing so many different applications, protocols and systems that you have more work and headaches than you imagined possible. This issue can be avoided if you select a network that is open and allows everything to work together.

3. Understand users and roles. Understanding users and their roles can have a significant impact on how the remote access strategy evolves. In most control systems operations, the roles that may require remote access to control assets could include, but are not limited to:

  • System operators and engineers for local systems;
  • System operators and engineers for remote systems;
  • Vendors;
  • System integrators;
  • System support specialists and maintenance engineers;
  • Field technicians;
  • Business/supply chain partners;
  • Reporting or regulatory entities; and
  • Managed service providers.

The roles of users that would require remote access to mission-critical operations can be extensive, and the assignment of specific access depending on those roles can be complicated. Map out and document all acceptable access policies and procedures related to allowable network access and coordinate this with industrial control system security experts. Any user access that goes beyond simple viewing of data and permits changes to system parameters should be extremely limited.

4. Know your vulnerabilities. Beginning at the remote user and following the connection to the data or service, remote access can be compromised at any of the following points:

  • The user or system can be impersonated to fool the target system.
  • The attacker can use captured or guessed credentials to impersonate the user.
  • The attacker can intimidate or coerce the user to provide valid credentials, or to perform activities at the attacker’s demand.
  • The user’s access device (laptop, PDA, etc.) can be attacked, compromised, and used to access the control system network.
  • The target system can be impersonated by an attacker to fool the user and thus gain credentials or other information from the user system.
  • Communication can be listened to by third parties anywhere along the communication chain.
  • The communication can be interrupted or jammed.
  • Communications can have data injected into them by an attacker.
  • Communication can be hijacked after it has been initiated (does not rely on impersonation) or intercepted during initiation (impersonating both user and target, also known as a man-in-the-middle attack).
  • Parts of a communication can be replayed to a target, even if the attacker cannot decipher the content (also known as a replay attack).
  • The target communication software listening for requests can be attacked and potentially compromised.
  • An attacker can impersonate a valid communications node and gain access to the underlying communications medium.
  • A denial-of-service attack can happen to the authentication server (e.g., radius server or RAS).
  • A denial-of-service attack can happen to the outward communication device (e.g., an outside router for remote access).

Liked this article? Download the Batch Process playbook here. Or, Download the Continuous Process playbook here.