Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

02:45 PM
Connect Directly

New Top 20 Secure-Coding List Positions PLCs as Plant 'Bodyguards'

Best practices guide encompasses integrity, hardening, resilience, and monitoring of PLCs in industrial networks.

Programmable logic controllers (PLCs) traditionally have been considered inherently insecure. But a new security initiative that outlines 20 best practices for coding the industrial computing device aims to reimagine the PLC as the last line of cyber defense in an industrial process.

Related Content:

Hacking the PLC via Its Engineering Software

Special Report: Assessing Cybersecurity Risk in Today's Enterprises

New From The Edge: 11 Cybersecurity Vendors to Watch in 2021

A group of cybersecurity experts and automation engineers has created an open source guide with 20 recommendations for configuring PLCs for resilience in case of a security incident or misconfiguration on the industrial network. The so-called PLC Security Top 20 List — hosted by the ISA (International Society of Automation) Global Cybersecurity Alliance — will be officially released tomorrow, June 15, for automation engineers to use when programming PLCs to perform physical processes, such as controlling the temperature of fluids and opening and closing valves or gates in a plant or facility.

The hope is that PLC vendors ultimately will incorporate or provide templates with their products to help customers employ the best practices when programming their devices.

Sarah Fluchs, CTO at German OT security firm Admeritia and one of the lead authors of the new PLC Security Top 20 List, says two basic PLC characteristics actually can be employed to securely code the devices: their ability to control a physical process such as opening or closing a gate, and that they are by design "deterministic."

"The PLC can be the last line of defense, the last man standing before you have physical impact" from an attack, Fluchs explains. "You can bring the basic characteristics ... their strength in knowing the process and knowing how the process works," such as how long holding open a gate is normal and how long is not, she says.

It's not that the PLC can actually prevent a cyberattack, but it can minimize the impact of one on a plant's physical process, she says. Its process-monitoring features can be tapped for resiliency and security to flag potentially malicious or unusual behavior: "This device contains a lot of knowledge about what's OK to happen and what's not. That knowledge is something we can use."

PLC programming differs from software programming in that it's not written in a software programming language and it's more about cycles and small tasks. "Everything in PLCs is about cycles; you write small tasks that are completed in a short amount of time ... comparing input data with storage-trend data and making quick decisions about what to do," explains Reid Wightman, a vulnerability researcher at OT security firm Dragos. "Regular software [programming] is transactional: I'm going to make a requirement and you give me a response."

The PLC Security Top 20 List's approach is analogous to application security coding best-practices such as Microsoft's Secure Development Lifecycle (SDL), or OWASP's Secure Coding Practices, but specific to the PLC's existing capabilities. It uses the devices' real-time operations and their narrow and specific tasks as security and resiliency as superpowers of sorts. "We tried to turn PLCs, often regarded as the Achilles' heel of automated plants, into the plants' distributed and unrelenting bodyguards, one in front of each (back) door," the list's co-authors wrote in the document, which goes live tomorrow.

Secure coding practices in the new Top 20 list are grouped by security objectives, which encompass integrity (of PLC logic, timers and counters, and I/O values); hardening the attack surface; resilience; and monitoring specific values in the PLC that could indicate security issues.

Among the best practices included in the list are obvious ones like splitting PLC code into modules you can more easily test, as well as keeping the PLC in RUN mode and ensuring an alarm sounds if that changes, indicating the PLC is not processing input/output data, and using PLC error flags for integrity-checks. It also calls for using cryptographic hashes or checksums to test for any issues with the PLC code integrity, disabling unneeded ports and protocols, logging PLC uptime and hard stops on the HMI, monitoring PLC memory usages and displaying it on the HMI, and capturing critical alerts.

The list is meant to evolve and grow, and the initial Top 20 is considered a Version 1.0 document open to comments and ongoing input. "It's absolutely something that needs to mature," Fluchs says.

Properly Programmed PLCs
Until recently, PLCs mostly were not connected to anything outside their industrial control systems or other PLCs. Digitization, of course, has changed all of that, as the once sacred line between IT and OT networks has become blurrier.

Most PLC security research to date has focused on ways to hack into PLCs or rig them with malware to alter the industrial process or compromise the devices' ladder logic (basically, the programming language used to code PLCs). Researchers have built rootkits and worms for PLCs, and most recently, found holes in next-generation security features, such as Siemens' memory protection in some of its SIMATIC PLCs.

But most real-world attacks affecting industrial organizations thankfully haven't touched the PLC: They've been opportunistic IT-type threats, most recently cybercrime-driven ransomware that has disrupted their IT networks, and in cases like Colonial Pipeline, resulted in the company shutting down its OT networks as a precaution and temporarily causing a gas shortage scare in parts of the US.

The recent breach of the water plant in the city of Oldsmar, Fla., however, demonstrated the potential dangers of a cyberattack that could lead to a physical outcome: In that case, poisoned drinking water. An intruder appeared to somehow have obtained system credentials to remotely control the settings via the TeamViewer application, and raised the sodium hydroxide, or lye, level to a dangerous amount. While an observant operator noticed the change and the plant had other digital guardrails in place that would have stopped contamination of the water system, it could have gone dangerously wrong in other scenarios.

"A properly programmed PLC," notes Dale Peterson, CEO of Digital Bond, would thwart such a rogue setting. "It would generate an alarm that, hey, this was trying to set something outside the [proper] range."

Peterson says the Top 20 list really is more about preventing misconfigurations from causing a physical event because operator and technician errors account for the majority of cyber-borne outages in industrial systems.

"If you've got a dedicated attacker going at you, this is not going to save you," notes Peterson. "But this [list] is going to stop a lot of mistakes causing outages and incidents. ... Its biggest benefit is preventing a process from getting into a bad state."

The recommendation for monitoring PLC memory, for example, could flag any unusual activity since the PLC tends to use memory at a consistent level over time. "If you see a spike all of a sudden in memory usage and [get] alarming on that, it's very useful," he notes.

That feature actually currently available for some PLCs. The PLC Top 20 list cites Rockwell Allen-Bradley's RSLogix 5000 Task Monitor Tool, which includes a feature to set memory baseline usage of its PLCs and to track any trends.

The top 20 list consists of: 

  • Modularize PLC Code
  • Monitor operating modes
  • Leave operational logic in the PLC wherever feasible 
  • Use PLC flags as integrity checks 
  • Use cryptographic and / or checksum integrity checks for PLC code 
  • Validate timers and counters 
  • Validate and alert for paired inputs / outputs   
  • Validate HMI input variables at the PLC level, not only at HMI  
  • Validate indirections 
  • Assign designated register blocks by function (read/write/validate) 
  • Instrument for plausibility checks
  • Validate inputs based on physical plausibility   
  • Disable unneeded / unused communication ports and protocols
  • Restrict third-party data interfaces 
  • Define a safe process state in case of a PLC restart 
  • Summarize PLC cycle times and trend them on the HMI
  • Log PLC uptime and trend it on the HMI
  • Log PLC hard stops and trend them on the HMI
  • Monitor PLC memory usage and trend it on the HMI
  • Trap false negatives and positives for critical alerts   


Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
How Enterprises are Attacking the Cybersecurity Problem
Concerns over supply chain vulnerabilities and attack visibility drove some significant changes in enterprise cybersecurity strategies over the past year. Dark Reading's 2021 Strategic Security Survey showed that many organizations are staying the course regarding the use of a mix of attack prevention and threat detection technologies and practices for dealing with cyber threats.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-10-15
Mitsubishi Electric SmartRTU devices allow remote attackers to obtain sensitive information (directory listing and source code) via a direct request to the /web URI.
PUBLISHED: 2021-10-15
Mitsubishi Electric SmartRTU devices allow XSS via the username parameter or PATH_INFO to login.php.
PUBLISHED: 2021-10-15
Yealink Device Management (DM) allows command injection as root via the /sm/api/v1/firewall/zone/services URI, without authentication.
PUBLISHED: 2021-10-15
IBM Cognos Analytics 11.1.7 and 11.2.0 contains locally cached browser data, that could allow a local attacker to obtain sensitive information.
PUBLISHED: 2021-10-15
Buffer overflow vulnerability in function stbi__extend_receive in stb_image.h in stb 2.26 via a crafted JPEG file.