Recent cyberattacks against municipal water systems (2 New Jersey municipal water systems targeted in cyberattacks) are another reminder that industrial control systems are increasingly part of the cybersecurity conversation.
This isn’t limited to large utilities or sophisticated attacks.
Federal agencies are currently warning organizations about attackers targeting internet-connected operational technology, including PLCs. Recent activity has involved Allen-Bradley, Siemens, Schneider Electric and potentially other PLC platforms, with attackers accessing controller project files and manipulating information presented through HMI and SCADA systems.
For manufacturers and other industrial facilities, that makes now a good time to perform a few relatively simple checks.
You don’t necessarily need to redesign your control system. But you should know the answers to these five questions.
1. Is anything in your control system visible from the Internet?
This is the first place I would look.
Most organizations don’t intentionally put a PLC on the public Internet. But industrial systems accumulate connections over time.
A machine builder may have installed a cellular modem. A remote pump station may use an LTE router. Someone may have configured a port-forwarding rule years ago for troubleshooting. An HMI, VPN appliance or industrial gateway may still be reachable long after the original reason for remote access disappeared.
Start by asking your IT provider or controls integrator to identify the public IP addresses associated with your facilities and remote sites.
Then check services such as Shodan or Censys to see what an outside observer can discover.
The EPA has specifically identified Shodan as one way water systems can look for Internet-exposed ports and services.
Look for things such as:
- PLCs and industrial Ethernet devices
- HMI or SCADA web interfaces
- VNC or Remote Desktop
- industrial gateways
- cellular routers
- VPN appliances
- vendor remote-access equipment
Shodan isn’t a vulnerability assessment, and a clean Shodan result doesn’t prove that nothing is exposed. Think of it as looking at your building from a google maps satellite view zoom-in.
If you can see something you weren’t expecting, investigate why it is there.
Most importantly, a PLC generally should not be directly accessible from the Internet. Current federal guidance specifically recommends removing PLCs from direct Internet exposure and placing necessary access behind appropriate gateways and firewalls
2. Do you know every way someone can remotely access the control system?
Finding Internet exposure is only part of the picture.
Make an inventory of the legitimate paths people use to access your equipment remotely.
That might include:
- corporate VPN access
- vendor VPN connections
- remote engineering workstations
- jump servers
- TeamViewer or similar remote-support software
- cellular gateways
- machine-builder remote-access appliances
Then ask a few basic questions.
Is this connection still necessary?
Who has access to it?
Does access require individual credentials?
Is multifactor authentication available?
Can the connection reach the entire control network, or only the equipment it needs?
A remote-access system that was installed for commissioning five years ago and forgotten is very different from an intentionally managed remote-support architecture.
The objective isn’t necessarily to eliminate remote access. Remote support can be extremely valuable.
The objective is to make remote access intentional, controlled and auditable.
3. How is access to your PLCs and other legacy equipment actually controlled?
This is where industrial cybersecurity becomes different from conventional IT.
The easy advice is:
Put a strong password on everything.
Sometimes that’s exactly what should happen.
But industrial plants also contain PLCs, HMIs, drives and other equipment that may have been running reliably for ten, fifteen or twenty years. Some platforms have limited authentication capabilities. Some weren’t designed with modern cybersecurity practices in mind. Changing a controller configuration may require downtime, qualification or extensive testing.
And some equipment may genuinely be isolated from untrusted networks.
That means the right question isn’t simply:
“Does every PLC have a password?”
The better question is:
“What prevents an unauthorized person from communicating with this PLC?”
If a supported controller can safely use authentication, use it and eliminate default credentials.
But if the equipment cannot reasonably be changed, look at compensating controls around the device.
For example:
- Keep the PLC off the Internet entirely.
- Restrict which computers and networks can communicate with it.
- Place legacy equipment behind an industrial firewall.
- Segment the control network from the general business network.
- Require remote users to pass through a VPN and controlled engineering workstation or jump host.
- Disable obsolete port-forwarding and remote-access paths.
- Monitor traffic crossing the boundary into the control network.
- Maintain physical control over engineering connections and programming access.
An old PLC with limited security features sitting behind a tightly controlled network boundary is a very different risk than the same PLC connected directly to an Internet-facing router.
Federal guidance on industrial control systems recognizes this same principle: where external-facing services are required, controls such as firewalls, stronger authentication, logging and monitoring can provide additional protection.
The goal is not to touch production equipment simply for the sake of changing something.
The goal is to understand where the security boundary actually is.
4. Do you know whether the program running in the PLC is the program you expect?
This is an easy question to overlook.
We tend to think of a cyberattack against a PLC as someone turning an output on or off.
The current federal advisory describes something potentially more difficult to recognize: attackers interacting with PLC project files and manipulating information displayed through HMI and SCADA systems.
That means operators shouldn’t rely entirely on the assumption that:
“The machine is running, so everything must be okay.”
For critical equipment, determine whether you have a known-good copy of the PLC and HMI programs.
Depending on the platform and process, that may mean reviewing:
- PLC project files
- HMI applications
- controller firmware
- IP configurations
- communication settings
- alarm configurations
- controller operating mode
- recent program downloads or modifications
This doesn’t mean walking around the plant and uploading every PLC immediately.
Production equipment should be approached deliberately.
Instead, identify your most critical systems first and establish what your known-good baseline actually is.
If nobody knows which copy of the PLC program is the current production version, that’s worth correcting even without a cybersecurity threat.
5. Could you recover the process if the controls stopped working tonight?
Cybersecurity isn’t only about keeping attackers out.
It is also about what happens when something fails.
The recent EPA national cybersecurity exercise for water utilities specifically focused on operating when telecommunications, Internet connectivity, SCADA remote access and other digital services became unavailable.
Manufacturers should ask a similar question.
If a critical PLC, HMI or SCADA computer failed tonight:
Could we restore it?
Confirm that you have:
- current PLC program backups
- current HMI/SCADA backups
- copies stored somewhere other than the machine itself
- required programming software
- required licenses
- documentation for critical network configurations
- someone who knows how the system is restored
- an understanding of which processes can safely operate manually
For especially critical systems, don’t stop at having a backup file.
Make sure you know what would actually be required to put that backup back into service.
A folder named PLC Backups containing twelve files from different years isn’t quite the same thing as a recovery plan.
None of these checks require turning your plant upside down
Industrial cybersecurity can quickly become a very large topic.
But the first step doesn’t have to be a major cybersecurity project.
Start by answering five questions:
- What can the Internet see?
- How can people remotely reach the control system?
- What actually prevents unauthorized access to the controllers?
- Do we know what programs should be running?
- Could we recover if those systems stopped working?
You may discover that your architecture is already well protected.
You may also discover a cellular modem nobody remembered, an old port-forwarding rule, a vendor connection that is no longer used or a PLC program whose latest backup lives on one engineer’s laptop.
Those are exactly the kinds of things worth finding before someone else finds them first.
For organizations reviewing their controls environments, Trola can assist with identifying PLC, HMI, SCADA and industrial-network architecture; documenting remote-access paths; reviewing known-good control-system backups; and working alongside your IT or cybersecurity provider to determine where additional network protections may be appropriate.
👉 [Reach out to Trola to get started].
Contact Trola today for a private consultation and discover how we can help you plan for the future while building for the now.