The new list of the top 20 secure codings positions PLCs as …


The best practice guide covers the integrity, hardening, resiliency and monitoring of PLCs in industrial networks.

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

A group of cybersecurity experts and automation engineers have created an open source guide with 20 recommendations for configuring PLCs for resiliency in the event of a security incident or misconfiguration on the industrial network. The so-called Top 20 Safety PLCs list – hosted by the ISA (International Society for 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 valves in a factory or facility.

The hope is that API vendors will incorporate or provide templates with their products to help customers use best practices when programming their devices.

Sarah Fluchs, CTO of German security company OT Admeritia and one of the lead authors of the new Top 20 Safety PLCs list, explains that two basic characteristics of PLCs can be used to safely code devices: their ability to control a physical process such as opening or closing a door, and that they are by design “deterministic”.

“The PLC can be the last line of defense, the last man standing before it has a physical impact” from an attack, explains Fluchs. “You can bring in the basic characteristics…

It’s not that the PLC can actually prevent a cyberattack, but it can minimize the impact of a cyberattack on the physical process of a factory, she says. Its process monitoring capabilities can be leveraged for resiliency and security to report potentially malicious or unusual behavior: “This device contains a lot of knowledge about what can happen and what doesn’t. This knowledge is something that we can use. “

PLC programming differs from software programming in that it is not written in a software programming language and is more about cycles and small tasks. “Everything in automatons is a question of cycles; you write small tasks that are completed in a short time … comparing input data with storage trend data and making quick decisions on what to do, ”says Reid Wightman, vulnerability researcher at OT security company Dragos. “Regular software [programming] is transactional: I’ll make a request and you give me an answer. “

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 capabilities. existing APIs. It uses the real-time operations of devices and their narrow, specific tasks like security and resiliency as superpowers of sorts. “We tried to transform the automatons, often seen as the Achilles heel of automated factories, into distributed and relentless bodyguards of factories, one in front of each (back) door,” wrote the co-authors of the list in the document, which will live tomorrow.

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

Some of the best practices included in the list include obvious practices such as dividing the API code into modules that you can test more easily, as well as keeping the API in RUN mode and ensuring that an alarm sounds. if that changes, indicating that the API is not processing I / O. data and using API error flags for integrity checks. It also calls for the use of cryptographic hashes or checksums to test for any issues with API code integrity, disabling unnecessary ports and protocols, logging API uptime. and hardware shutdowns on the HMI, monitoring of PLC memory usage and its display 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 continued contributions. “It’s absolutely something that needs to mature,” says Fluchs.

Correctly programmed APIs
Until recently, PLCs were mostly not connected to anything outside of their industrial control systems or other PLCs. Digitization, of course, has changed all that, as the once-sacred boundary between IT and OT networks has become blurred.

Most API security research to date has focused on ways to hack APIs or rig them with malware to alter the industrial process or compromise the ladder logic of devices (essentially, the programming language). used to code APIs). Researchers have built rootkits and worms for programmable logic controllers, and more recently they have found loopholes in next-generation security features, such as memory protection from Siemens in some of its SIMATIC PLCs.

But most of the real-world attacks affecting industrial organizations have fortunately not hit the API: they have been opportunistic computer-type threats, most recently cybercrime-related ransomware that has disrupted their computer networks and, in cases like Colonial Pipeline, have resulted in the company shutting down its OT networks as a precautionary measure and temporarily causing a gas shortage alert in parts of the United States.

The recent breach of the Oldsmar, Florida city water plant, however, demonstrated the potential dangers of a cyberattack that could have a physical result: in this case, poisoned drinking water. An intruder appears to have obtained system credentials to remotely control settings through the TeamViewer app, and increased the level of sodium hydroxide, or lye, to an unsafe level. While an observant operator noticed the change and the factory had put in place other digital guardrails that would have stopped the contamination of the water system, it could have gone wrong in other scenarios.

“A properly programmed PLC,” notes Dale Peterson, CEO of Digital Bond, would thwart such a dishonest setting. “It would generate an alarm that, hey, it was trying to define something outside of the [proper] range.”

Peterson says the top 20 list is really about preventing configuration errors from causing a physical event, as operator and technician errors account for the majority of cyber failures in industrial systems.

“If you have a dedicated attacker attacking you, that won’t save you,” Peterson notes. “But this

    will stop a lot of errors causing crashes and mishaps. … Its greatest advantage is to prevent a process from going into a bad state. “

    The API memory monitoring recommendation, for example, could flag any unusual activity since the API tends to use memory at a consistent level over time. “If you suddenly see a spike in memory usage and [get] alarming on that, it is very useful, “he notes.

    This functionality is currently available for some PLCs. The top 20 list cites Rockwell Allen-Bradley’s RSLogix 5000 job monitoring tool, which includes a feature to set the base memory usage of its controllers and track trends.

    The top 20 list consists of:

    • Modularize API code
    • Monitor operating modes
    • Leave operational logic in the API whenever possible
    • Use API flags as integrity checks
    • Use cryptographic and / or checksum integrity checks for API code
    • Validate timers and counters
    • Validate and alert for paired inputs / outputs
    • Enable HMI input variables at PLC level, not just at HMI level
    • Validate referrals
    • Assign designated register blocks by function (read / write / enable)
    • Instrument for plausibility checks
    • Validate entries based on physical plausibility
    • Disable unnecessary / unused communication ports and protocols
    • Restrict third-party data interfaces
    • Define a safe process state when restarting the PLC
    • Summarize the PLC cycle times and follow them on the HMI
    • Record the availability of the API and monitor it on the HMI
    • Record the hardware shutdowns of the API and follow them on the HMI
    • Monitor PLC memory usage and track it on the HMI
    • Traps false negatives and positives for critical alerts

    Kelly Jackson Higgins is the editor-in-chief of Dark Reading. She is an award-winning technology and business veteran journalist with over two decades of experience reporting and editing for various publications including Network Computing, Secure Enterprise … See Full Biography

    Recommended reading:

    More information


    Comments are closed.