Defense in Depth: PLC Security for Manufacturing and Critical Infrastructure
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.
Most manufacturing and critical infrastructure systems (utilities, wastewater treatment, communications, dams, and many more) use PLCs to automate processes, equipment, and compile process data you can use to run your business. Because PLCs are commonly a wild-west of vendors, hardware versions, and managed by non-security minded folks they are prime targets for hackers. Disrupting these PLC can wreak havoc on the people served by critical infrastructure, and can easily bring manufacturing operations to a halt.
In today’s world where things are ever-increasingly connected to the internet it is more important than ever to make sure you have your PLC systems locked down from a security perspective. There is even a tool called Shodan you can use to find PLCs and other OT systems connected directly to the internet, in a many cases with zero protection of any kind. In an ideal world the systems shown on Shodan would be zero, however we have a long way to go before that is a reality.
This post focuses on PLC security. There are a number of steps any company can take to prevent malicious access to PLC systems
Local Access to PLCs
Preventing local access to PLCs is potentially a little more difficult, however one approach you can take here is to password protect PLC access so people who don’t have the right credentials can’t get into the code to see what is going on or make changes.
Another thing you can do is require your panel builders to use managed switches in your panels. Far too often we run into PLC panels with an unmanaged switch with way too many open ports. This allows anyone with an ethernet cable to plug into the panel and have unfettered access to everything else that panel can see on the network.
Using managed switches allows you to lock down specific ports on the switch for access. For example, if you have a Panel PC and a PLC plugged into a switch with 5 ports, you can lock down the 3 unused ports so even if someone plugs a computer into them they won’t have access to anything.
Managed switches are more costly, and require some configuration, however not using them greatly increases your risk of a cybersecurity incident
Remote Access
We will dive more into network infrastructure in a different post, however one thing you should be aware of for remote PLC access is using firewalls and VPNs to reduce your exposure to unknown and potentially harmful network traffic, and keeping people out of systems they shouldn’t have access to.
The US Cybersecurity and Infrastructure Security Agency (CISA) has a lot of great material discussing the 5 W’s of network segmentation using firewalls and VPN access, including a great PDF of what a segmented network architecture looks like in the OT space.
Yes this requires coordination with IT and an investment in more hardware and software, it will also massively reduce your overall exposure to the risks of an attack.
PLC Security
Another common threat is accessing PLCs and making changes. Many PLCs from vendors like Allen Bradley have a PROGRAM/REMOTE/RUN switch. There is an excellent deep dive into the cybersecurity concerns about this switch on an episode of the Darknet Diaries podcast related to this.
Basically if your PLC is is PROGRAM mode you can get into it, make changes and push them out without anyone knowing. Of course the PLC won’t be running while this is active, so you might have other indicators something weird is going on.
If you are in REMOTE mode it is basically RUN mode plus PROGRAM mode where you can get into the PLC, make online changes, and push those out without anyone knowing. This is a very common scenario when troubleshooting a PLC code issue, or making change to support on-site work for replacing sensors, VFDs, etc.
In RUN mode your PLC is running the logic and is effectively inaccessible from the outside world. One of the easiest things you can do to prevent bad actors from getting into your PLC is make it a habit to leave them in RUN mode only. If someone does need to make changes to the code for some reason you can then put it into REMOTE or PROGRAM, and change it back to RUN once the process is completed.
One item to note, especially for remote sites like pump stations and substations is you can often fully remove the key to make these changes from the PLC. This is especially helpful for remote sites because you can make it much more difficult for someone to access the PLC and change the key’s position if there isn’t a key in the first place.
Regarding the “push changes without anyone knowing about it” aspect, you can take advantage of tools like AssetCentre from Rockwell, or VersionDog to automatically monitor your PLC programs, back them up, and send out notifications anytime something changes. While these won’t prevent someone from making changes, you will at least be aware of what is going on when something happens.
Locking down PLC code with passwords is also an easy way to lock things down. In the world of CODESYS, especially running on Opto 22 hardware makes this a very easy task. Yes we know a lot of integrators and OEM companies will lock down their code so you don’t have access to it. That is not what we are proposing here. Instead it is setting up a security conscious approach to your systems, giving access to the people who need it, and locking out the people who don’t need it.
Wrapping Up
This post covers a number of things any manufacturing or critical infrastructure company can to do better secure their PLC-based control systems. Except for using firewalls and VPNs plus managed switches, it doesn’t necessarily require any investment in hardware or software to implement these changes, and they provide at least a base level of protection from threats to your operations.
Adding these changes to your OT systems will add a bit of friction to the people who need access to manage them, it will also reduce the amount of risk involved by locking out people who shouldn’t be accessing them.
