Managing the Risk of Remote SCADA Access

Feb. 8, 2022
How the use of virtual private networks, multi-factor authentication, serial communications, and dedicated remote access devices reduce the risk of viewing SCADA data over the internet.

One of the biggest benefits of Ethernet on the plant floor is the ability to remotely connect to plant floor systems. But along with the benefits of remote access come the heightened risk of cyber-attacks.

Despite this, more and more manufacturers believe the risks are worth managing to drive their operations into the future and ease the process of accessing and sharing data across sites for better decision-making, as well as reducing the cost of onsite troubleshooting and repair—a great deal of which can now be accomplished remotely.

Considering that a key initial Industry 4.0 achievement is remote access to SCADA (supervisory control and acquisition) systems, we spoke with Ben Manlongat of Outbound Technologies, an industrial automation system integrator to learn more about how manufacturers can best manage the risks associated with remote SCADA access.

Listen to the full podcast with Ben Manlongat on IoT SCADA access.

Protecting against the biggest risks

Beyond the obvious concerns about a hacker taking control of any aspect of your production operations, Manlongat say it’s also important to consider the impact of an outsider gaining access to your SCADA data.

“If someone were to intercept your data, how could that affect your business?” asks Manlongat. “You have to think about how you could be harmed if your competitor were to get that information. And don't think that because everything [on your SCADA system] is read-only that everything is safe. If a COM (communications) port is open, a hacker could gain access to any laptop on the network to get to the COM port of the device and then start making programming changes. And once those programming changes are made, the hacker can take control of your system. It’s critical to ensure the COM ports on your devices are protected and make sure there are no available device tags that are predefined by the manufacturer for use in controlling the device.”

Core external aspects to consider about SCADA remote access security include:

  • Do you have a VPN (virtual private network) connection to the plant floor or to your office network? If so, Manlongat advises using multifactor authentication (MFA) so that gaining your password isn’t enough to access the system; a hacker would also need your smartphone and its password. MFA sends a special key code to the approved user’s mobile device that can change every few minutes.
  • Is the connection to your plant floor network encrypted?
  • Is there any third-party software involved? In this case, Manlongat notes that there have been big breaches of third-party software, where the manufacturing site itself wasn’t directly hacked, but the third-party software had been compromised. In some of these cases, passwords were leaked, enabling hackers to gain access to the company’s network through that third-party software. 

Internal risks include:

  • Having your plant floor network connected directly to the office network (e.g., without the use of a DMZ).
  • Security of Wi-Fi used in the plant and in the office (see point above).
  • Are your devices only transmitting read-only tags? If read-write tags are available, hackers could more easily execute control over portions of your operations.
  • Are device programming ports available on the network?
  • Is safety logic programmed in your controllers to prevent against any significant problems?

Is real protection possible?

Given the ever-growing level of risk to industrial control systems, we asked Manlongat if it was even possible to truly protect a SCADA system that has been networked for remote access.

“The quick answer is yes, because there are different ways to configure an internet-connected plant floor network for remote access and read-only viewing,” he says.

According to Manlongat, if you’re looking to do read-only remote access with no potential for remote control: 1) Don’t connect directly to controllers performing operations; 2) use a VPN to connect the plant floor to the internet to establish a private, encrypted connection—with traffic on the VPN encrypted. With this setup, even if someone were able to access the network’s traffic, they wouldn't be able to read or understand it; and 3) use MFA so that, in addition to user name and password requirements, you also need to the authorized person's smartphone or other mobile device.

If you're looking to do read-only remote access and send data to the cloud for artificial intelligence/machine learning analytics, Manlongat offers two recommendations:

  • Use a device (e.g., an edge computer or server) on the plant floor that only receives data from your plant floor equipment. This is the device that you would connect to remotely. “This device would not have the ability to do any control operations because it's not connected anything to do any control,” he says. “It's only reading information from plant floor; you’ll connect that to the VPN to send data to the cloud.”
  • Use a serial connection with the edge computer or server. A serial connection between a data collecting device and a controller is “a lot less risky than an Ethernet connection that could provide access to a controller’s COM port,” says Manlongat.
Watch this video to learn more about MQTT security—which uses a device for remote access to plant floor data, thereby providing an extra layer of security to industrial control system devices.

Companies in this Article