What to do about PLC attacks on your OT infrastructure

Before talking about advanced cybersecurity measures, an organization must first identify what systems currently exist. Build a validated baseline of controller logic and configuration, then compare running assets against it continuously.

What you’ll learn:

  • You can't defend assets you haven't inventoried.
  • Controller integrity monitoring often tells you more than network alert volume.
  • An untested backup is an assumption, not a recovery plan.

Editor’s note: This is Part 2 of a series from Weidmüller’s Andrew Barco.

See Part 1: What recent PLC attacks reveal about the state of OT cybersecurity


The first article in my series explored the vulnerabilities in OT systems and the gaps in cybersecurity expertise of OT personnel that could increase the potential of cyber events, along with highlighting third-party access as a forgotten attack surface. Here, I’ll cover what your organization can do to close these vulnerabilities.

See also: Smart Industry's annual State of Initiative Survey is open!

An organization cannot protect itself from what it does not see. And the first step to creating resilience is establishing asset visibility, which includes:

  • PLCs and remote terminal units
  • Human machine interfaces and engineering workstations
  • Industrial switches
  • Remote access gateways and wireless links
  • Third-party connectivity

It turns out that in many OT assessments, the most important findings are not some complex cybersecurity risks. They are unknown devices, forgotten remote access pathways, outdated engineering stations and unsupported systems.

Before talking about advanced cybersecurity measures, the organization must first identify what systems currently exist.

Know when the PLC logic changes

Attackers don't need custom malware to disrupt a process. Altering setpoints, alarm limits, control logic, communication settings or safety functions can affect the physical process directly. Network monitoring alone won't catch that. The organization should think about whether it has the mechanisms to:

  • Monitor changes in controller logic.
  • Perform configuration changes.
  • Make firmware updates.
  • Adjust safety-related parameters.
  • Engineer workstation downloads.
  • Make changes in communication configuration.

In case of an unexpected modification of the controller program, the organization should be made aware of it immediately, not weeks later during troubleshooting of the issue.

Network visibility is important, yet resilience of the OT environment is achieved by maintaining its integrity. An attacker doesn't necessarily need advanced malware to affect operations. Changing controller logic, setpoints, communication settings, alarm thresholds, etc., has a direct effect on physical process.

See also: 'Authentication friction’ hits manufacturing hardest, cybersecurity experts advise ditching passwords altogether

Build a validated baseline of controller logic and configuration, then compare running assets against it continuously. Track changes to firmware, safety parameters and engineering workstation downloads.

Attackers don't need custom malware to disrupt a process. Altering setpoints, alarm limits, control logic, communication settings or safety functions can affect the physical process directly.

Every deviation should answer three questions: who changed it, when was it changed and was it approved? You want to learn about an unauthorized change within minutes, not weeks later while troubleshooting. For many operators, one unexpected logic change is more actionable than thousands of flagged IP connections.

Plan for recovery, not just prevention

Many cybersecurity discussions focus on prevention. However, resilience is about recovery.

No program stops every incident, so recovery capability is the real measure of resilience. Ask a simple question: when did we last restore a PLC from backup? Many organizations back up diligently but never test a restore. Exercises should cover:

  • Controller programs
  • HMI configurations
  • Historian databases and SCADA servers
  • Engineering workstation images
  • Network device configurations

Restoring quickly can mean the difference between a short disruption and a public safety event.

The limits of the voluntary guidance

Over the last decade, many cybersecurity recommendations have been published by government agencies and industry organizations. Most of them are technically sound but the challenge is in implementation.

See also: New Rockwell report reveals glaring disconnect between cybersecurity investments and risk protection

The gap is execution, especially for small municipal utilities with thin staffing. Documents say what to do but rarely say who does it:

  • Who approves remote access and vets third-party accounts?
  • Who signs off on controller logic changes and backups?
  • Who runs recovery exercises and maintains the asset inventory?

Without named owners, organizations end up compliant on paper but fragile in practice, and even strong programs decay. Many “technical” failures are really governance failures.

Project Watershed 250 reflects this shift. The White House and Texas launched it on Aug. 31 as a pilot giving water and wastewater utilities cyber-defense resources at no cost.

The six-month effort aims to find out which approaches work for water utilities and to build a model that could scale nationwide. The lesson reaches beyond utilities and extends to manufacturing: expertise, assigned responsibility, and prioritized remediation matter as much as technology.

The lesson we keep missing

The recent PLC-related incidents affecting critical infrastructure operators should not be seen as evidence of a new threat. They are the evidence of old problems listed below and definitely not pointing to any particular utility:

Internet-accessible operational assets

  • Poorly governed remote access
  • Poor asset visibility
  • Untested recovery procedures
  • Lack of OT cybersecurity expertise

They are systemic issues existing throughout the critical infrastructure. The organizations that are going to improve their resilience over the next decade are not necessarily those that spend the most on cybersecurity.

Over the last decade, many cybersecurity recommendations have been published by government agencies and industry organizations. Most of them are technically sound but the challenge is in implementation.

They are the organizations that understand their operational environment, have OT-specific expertise, maintain asset visibility and regularly verify their ability to recover from the incidents.

Because in OT cybersecurity, resilience is not about avoiding the attack - It is about continuing operations even in case of the attack.

See also: Who’s winning the cybersecurity arms race? A region-by-region scorecard

The most troubling aspect of the recent PLC attacks is not what was discovered, but how similar it is to what has been observed in the industry for more than a decade now. Internet-accessible assets, unmanaged remote access, limited visibility of assets and untested recovery are not new problems. Technologies to solve these issues are widely available today.

What has not happened yet is the translation of cybersecurity recommendations into practice, and that is especially the case when it comes to smaller utilities and municipalities operating under constraints.

About the Author

Andrew Barco

Andrew Barco

Andrew Barco is global program senior director for OT networks and cybersecurity at Weidmüller, leading global initiatives in industrial ethernet, wireless, IIoT, and secure automation. A 20-plus year automation and connectivity executive with an engineering background and MBA, he is an active IEEE and ISA senior member driving the evolution of industrial networking.

Sign up for our eNewsletters
Get the latest news and updates