Defense in Depth: SCADA Security for Manufacturing and Critical Infrastructure

Cybersecurity

Jan 10

Author’s Note: Our Defense In Depth series will demonstrate how over the past several years Corso Systems has helped companies implement security. The series includes relatively easy best practices like ensuring your systems are secured with user accounts, network segmentation with Firewalls to reduce the flow of traffic to only what is necessary to move between each part of your operation. We will also discuss more complex technologies such as threat detection, and backups/disaster recovery so you can get back up and running even in the worst case scenarios.

Manufacturing and critical infrastructure systems (utilities, wastewater treatment, communications, dams, and many more) are prime targets for hackers and bad actors. Disrupting these systems can wreak havoc on everyone served by critical infrastructure or can bring manufacturing operations to a halt.

Many attacks are geared towards installing malware on the operational technology (OT) systems that run these facilities. This malware can also include ransomware, and in some cases like Stuxnet, it can cause catastrophic equipment failure.

With an ever increasing number of systems connected to the internet to make data and information easily accessible, and the rise of remote work over the last few years, the risks are very real. But, there are a number of steps you can take to make it more difficult for bad actors to access your systems.

Today’s post focuses on SCADA security. And yes, taking a proactive approach to cybersecurity will make your systems a little bit more complicated to interact with even for authorized users, it will be much more difficult for unauthorized users to gain access. We think this trade-off is worth it every time.

User Accounts and Role-Based Access

The first step in securing your SCADA system is to make sure user authentication is properly set up. This means removing any user accounts with default settings like admin/password. You’d be shocked at how often we go to a new facility and are able to fully access their most critical systems using standard default accounts like these.

Setting up specific user accounts is the easiest first line of defense you can take. Even though it can be cumbersome to require operators to log in with their own accounts instead of a global account, it’s worth the effort. It is much less costly than fixing the aftermath of an attacker gaining access to your systems by guessing the credentials to an account with full access to everything.

In legacy SCADA systems, you might have specific users for your systems without an easy way to integrate with an Identity Provider. Modern SCADA technology like Ignition helps you solve this problem by easily integrating with Microsoft’s Active Directory, as well as more generalized systems like Google Workspace, OpenID. With other systems such as Keycloak, you can even set up user accounts regardless of where they originate. This means when you open up an Ignition client, you would be redirected to login using your global user account. In the case of our internal development systems, Ignition redirects to the Google login page when we want to connect to our internal gateways. You can also use Ignition-specific user accounts without an Identity Provider if desired.

Another MAJOR benefit of using an Identity Provider is basically getting two factor authentication (2FA) for free. This is very important if someone figures out a user’s credentials. Instead of simply being able to log in using their username and password, 2FA will kick in if they are logging in from a new location and send a code to the real user. The user can then deny the 2FA request, and then change their passwords as needed. 2FA is an extra level of security with no additional work needed for setup.

Finally, a critical piece of the puzzle is using role-based access. You can configure specific roles for your users, for example: “Super Admin”, “Admin”, “Operator”, “Maintenance”, etc. In the SCADA application, you can then lock down access so that only users with the required roles can change setpoints, access certain screens, etc. We typically recommend making roles as granular as possible to lock down the SCADA system most effectively. Another added benefit is that this approach keeps important items like setpoints for PID control loops from getting changed without anyone’s knowledge.

Local Access to SCADA and Computers

Legacy SCADA systems typically require you to run a client that is always open on a computer that is always logged in. These systems typically don’t have a modern client/server based architecture like Ignition.

A client/server architecture connects all your OT devices to a central server, and your SCADA application users will open a client that connects to the server to display the screens and information they need to perform their duties. From a security perspective, a main benefit of this approach is the ability to automatically log out inactive clients. You can even log out the computer itself to lock down access to anyone who is walking by. While physical security measures like guard booths, badge access to the plant floor, and a team that’s aware of who should and shouldn’t be walking around can help limit physical access, these luxuries aren’t available at a remote pump station or electrical substation.

Remote Access

With more people working from home and supporting OT systems without going on-site, it’s critical to take a proactive approach to limit remote access to your systems.

Remote access has a number of attack surfaces to manage: network access to the equipment, locking down access to computers using Remote Desktop (or tools like Team Viewer, VNC, or AnyDesk), and remote access to PLCs.

We cover network access more in depth in this post, however the key items to be aware of here are firewalls and VPN access to your OT hardware.

Limiting access to computers through Remote Desktop or other screen sharing applications is commonly an IT function, and is also tied into overall user accounts for your system. Preventing users from accessing your computers directly will help reduce your security risks. This includes locking down remote access to specific user accounts, and keeping administrator access away from most of the people who will be using those systems.

While removing administrator access will make it more difficult for users to install software, it also prevents them from accessing sensitive network drives, local data on the computer, and any other systems accessible from that machine.

Excellent screen sharing tools like BeyondTrust can also require someone on-site or in IT to share a link to an offsite team member or vendor who needs remote access. They can then enable or disable remote control of the machine, and observe what the remote user is doing at any given time. This allows your people to immediately shut down the remote connection if they seen unusual activity.

Vendor Security

Another aspect of this lower level security discussion is to control how vendors access your systems. Many times when we work with a company, their IT department will create a Corso account that anyone on our team can use to access their systems.

By using global user account access, you can more easily have your IT team set up individual user accounts that can be deactivated when someone leaves the team or upon completion of the project. This keeps your system much more secure, and keeps access out of the hands of people who no longer need access once the system is up and running.

Wrapping Up

This post covers a number of security concerns that any manufacturing or critical infrastructure company can improve to better secure their control systems. It doesn’t necessarily require any investment in hardware or software to implement these changes, and provides at least a base level of protection from threats to your operations.

When we work with companies in any capacity these are the first items we look at and recommend. Many companies have gotten into the habit of not implementing these items because it does provide a layer of friction for people managing the systems with the best intentions. Ease of use and maintenance of your systems needs to be considered part of the overall risk profile of running an automated system. We argue that the increased risk of a fully open and easy to access system is far outweighed by the ease of access anyone can have to your system.

It is much easier to handle minor annoyances from people not being able to install software or make changes to a PLC anytime they want than it is to have your system compromised. The costs associated with a successful attack will far outweigh the extra few minutes it takes to have IT install software, or have someone physically go to a PLC to move the switch to REMOTE to prevent someone from accessing it without your knowledge.