Security Practices for IEC 61131-3 PLC Programming Languages Part 2: Ladder Logic
By Isiah Jones & Brian Foster
Within the industrial control systems (ICS), automation, operational technology (OT), cyber-physical systems (CPS), industrial internet of things (IIoT) and instrumentation communities many of the devices with some form of computing and logical capabilities rely on 5 primary programming languages specific to programmable logic controllers (PLCs) that are defined in IEC 61131-3 as Sequential Function Chart (SFC), Ladder Diagram aka Ladder Logic (LD), Function Block Diagram (FBD), Instruction List (IL) and Structure Text (ST). In the IT community OWASP, NIST, SANS, CMMI, ISC2, and EC-Council, among others, have already created secure coding and secure development guidelines, best practices, testing tools and tips for higher level languages such as C, C++, Java, Python, JSON, HTML, XML, SQL and others. Some could argue that Structure Text includes several of these high-level languages. However, there has not been much focus by international standards organizations or industry experts on implementing security within the other 4 primary PLC focused languages in ICS. As a result, we wanted to share some of our recommendations for each of the IEC 61131-3 PLC languages in a 5-part blog series and aggregated white paper. In part 1 of our series we focused on Sequential Function Chart (SFC). Here in part 2 we will focus on Ladder Diagram (LD) also known as Ladder Logic.
Ladder Diagram (LD)/Ladder Logic
Ladder Diagram is a graphical representation of physical ladder logic. Before the common use of PLCs process logic could be achieved by building relay racks of switches, relays, timed relays, and other various devices. These relay racks were referred to as ladders because of the common and practical practice of building them on a board with the positive and negative of the DC circuit as bars down either side. Devices were then placed into rungs between these bars. Ladder diagram was a depiction of these relay racks used for documentation of the function.
Modern ladder diagram in a PLC has many more operators than the original physical ladders did, but it is still based on its physical predecessor. Logic in most modern PLC’s ladder diagram is processed one rung at a time. Each rung from left to right then down to the next rung. Ladder diagram was the first language available for PLCs and is still the most used in North America. Many variations outside of the IEC 61131-3 standard exist, but they all follow the same basic principles from the original physical ladder logic.
Within Ladder Diagram we believe the below recommended practices would improve the secure design and usage of LD within ICS devices by adding security, safety and resilience supportive concepts within the LD logic for all devices and operations that operate using LD. These recommended practices are in no particular order and this is not an all-inclusive list.
- Keep operational PLCs in run mode. This prohibits changes to the logic. It is often only changeable with physical access to the PLC. While this cannot prevent flaws in the code from being exploited it will stop the changing of the code by anyone who does not have physical access to the PLC.
- For each rung insert input validation conditions in addition to the primary conditions needed to execute your programs in each page file. This verifies that the expected type and threshold of conditions inputs are received prior to executing the output or results portion of the rung on the right or skipping to any other rungs or program page files. This also catches and tosses out undesirable, unauthorized and unexpected inputs from manipulating your program.
- Always verify the project or page file and the entire project prior to uploading to a device
- Never put all your conditions and rungs within a single ladder page file. Break out page files by functions and use the initial primary ladder to jump to and call different page files within your overall project.
- Create recovery state conditions within your page files or even leverage jumps and sub routines within a recovery page file that checks for various undesirable conditions as a ladder itself. This increases the resiliency and error checking abilities of your project.
- Use latch and unlatch output commands sparingly. In general, be sure to try to energize a bit in one place in your ladder and ensure all the necessary conditions are accounted for on the correct rung and branches within a rung. This is an existing best practice that is known for making troubleshooting errors for an energized bit much easier and cleaner than energizing it in many places and using too many nested latch and unlatch output commands. However, from a security perspective following this practice also decreases attack surface opportunities and reduces failure analysis complexity.
- Leverage comparators to automatically flag and drop input and output conditions that are outside expected parameters, conditions and thresholds within the processes that the PLC, RTU, and other logic devices are monitoring and or controlling. Ensure output conditions that trigger logging and alerting are part of the comparator conditions to alert operators that attempts to push inputs and outputs that violate those conditions are being made.
- Leverage jumps to jump between primary process logic and additional safety and security input and output filtering and validation logic that allows you to build modular logic specific to security and safety checks into your overall project and process logic for controllers.
- Leverage Low Low, Low, High and High High in conjunction with comparators, PID controls and alarms to capture inputs and outputs that reach thresholds known to be undesired for your operations especially if they could then lead to an undesirable consequence with undesirable potential impacts to the environment, humans, operations or even safety or equipment maintenance cycles.
- Keep all logic well documented and commented. This makes identifying rouge code easier, but also helps with day to day troubleshooting. The next person to work on the logic should always be able to understand what the last person did.
We know there are many more possible best practices and recommendations that experienced individuals within the community can come up with. We wanted to be part of increasing the conversation for the creation of some formalized and well documented best practices guidelines for each of the 5 IEC 61131-3 PLC languages. Part 3 of this series will focus on Function Block Diagram (FBD). We encourage our global multisector community of automation and control systems creators, installers, integrators, regulators, international standards organizations, testing labs, safety and risk assessors, pentesters and end users to think of and enforce the implementation of more recommended practices to increase our level of due diligence in our attempts to improve the assurance levels of infrastructures the public depends on for daily life.
Brian is an experienced Controls Engineer and OT/ICS Security Engineer. After many successful years in controls and automation, he decided to transition to cybersecurity as it is a lifelong passion. He brings with him an advanced understanding of various control systems and an engineering approach to cybersecurity. Using proven mathematical methods he builds risk models in terms of probability of lost dollars to help drive informed decision making. Brian has found securing critical infrastructure to be his calling. He thrives in the challenging and ever-evolving environment. He believes in a holistic approach that builds bridges and overcomes the traditional divide between OT and IT. A powerful desire to protect the systems of the modern world drives him. Above all else, he strongly believes in keeping all the necessities of daily life that we take for granted safe, secure, and operational.