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), in part 2 we focused on Ladder Diagram or Ladder Logic (LD), and in part 3 we focused on Function Block Diagram (FBD). Here in part 4 we will focus on Instruction List (IL).
Instruction List (IL) is a very low level, millisecond fast assembly like language that has been superseded by more powerful devices and the other 4 PLC languages over time. It is still used in areas of very small memory and very low power simple devices that must execute code within milliseconds or sub-milliseconds without delay. It is not a graphical language at all. Just like assembly language various commands and instructions are executed based on logical statements for mathematical operations or for jumps as an example. In most cases IL has been phased out over time but it is still offered in programming tools such as the ABB’s Automation Builder and Rockwell Allen-Bradley’s Connected Components Workbench (CCW) for Micrologix PLCs.
Within IL we believe the below recommended practices would improve the secure design and usage of IL within ICS devices by adding security, safety and resilience supportive concepts within the IL logic for all devices and operations that operate using IL. 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.
- 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.
- Create a coding standard that builds a reuse library of trusted operands, operators, commands, opcodes, variable names, expected inputs and outputs, datatypes etc.
- Be sure to account for null values and memory stack management in code
- Ensure IL code is tested and checked in and out of code libraries before approving use in production. This should include testing of any libraries or code borrowed from other sources.
- Create standard messages that can be used for alarms and notifications when unexpected, unsafe and unauthorized conditions occur within the logic.
- Create conditions that ensure the loaded inputs and outputs remain within the expected parameters. Do not allow or leave room for unexpected parameters in inputs and outputs to execute through your IL program logic.
- Leverage JMP, CAL, comparators and timers to come up with creative lL that look for and flag suspicious inputs and outputs that could serve as an early warning notification and alarm that an actor is changing logic and memory on a programmable device in the field.
- To reduce code attack surface increase usage of IL in places where advanced features of the other 4 PLC languages are not always needed in field devices. This analysis should especially be completed for the most critical and static operations in the field.
- Enforce a common practice within your coding standard whenever logic and actions are being translated and transition between IL and any other programming language.
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 5 of this series will finish our series with Structured Text (ST). 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.