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.

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