Security Practices for IEC 61131-3 PLC Programming Languages Part 3: FBD

Security Practices for IEC 61131-3 PLC Programming Languages Part 3: FBD

Security Practices for IEC 61131-3 PLC Programming Languages Part 3: FBD 721 298 IsiahJones

By Isiah Jones VP, Global ICS Security Service Delivery & Brian Foster Sr ICS Cybersecurity Engineer

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) and in part 2 we focused on Ladder Diagram or Ladder Logic (LD). Here in part 3 we will focus on Function Block Diagram (FBD).

Function Block Diagram

Function Block Diagram or FBD is a graphical language that allows you to create blocks of functions that group relationships between inputs and outputs. Various data types and mathematical functions are grouped into a block and the inputs and outputs state or condition is altered based on the function of the block. Each block has a symbol that represents a function such as OR which is represented by the symbol “ >=1” for example. The inputs and outputs from one block can be linked to another block enabling a graphical flow that shows the path that an input of one data type takes through a program, processed by different functions until it reaches a final output to achieve the purpose of the program and the overall designed process. The blocks themselves and linking various types of blocks together enables users to create very complex logic in a very graphical easy to follow manner.

Recommended Practices

Within FBD we believe the below recommended practices would improve the secure design and usage of FBD within ICS devices by adding security, safety and resilience supportive concepts within the FBD logic for all devices and operations that operate using FBD. 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.
  • Build a library of tested and approved safe functions and enforce a check in and check out programming methodology for projects where FBD is the language of choice. This creates a baseline of expected functions for your projects and prevents unwanted or unexpected errors or events from occurring due to a new programmer or malicious actor from introducing functions that weren’t already vetted.
  • Keep it minimal. Do not over complicate networks and reduce the number of objects if possible. Good engineering stands out because it is simple, efficient, and easy to follow. It will make troubleshooting easier, reliability higher, and malicious modification harder to hide.
  • Be consistent. If configurable use the same fonts, color schemes, perspective, whitespace, and flow. Let the picture tell your story. Good consistent visual appearance and layout of the FBD help organize it in a logical and efficient manner.
  • Create standards that define data types, tag libraries, naming conventions, comments, symbols, alarms, notifications, mandatory vs optional functions etc. Having a standard enables the asset owners and all other stakeholders to build all projects from a common baseline or sheet of music. Examples being red vs green alarms. Which is good, and which is bad? Some folks have red alarms as good normal state condition and green means something is wrong. Others follow green is good, red is bad. Regardless have a documented standard on each project and for each system. Which alarms will be outputs of which functions, how and why should all be in the standard.
  • Ensure alarms and notifications library and screens that alert operators when the incorrect values and or data types are used. This could detect code changes, errors in code, tampering by an actor or an unexpected malfunction. The more you account for being able to track or flag anomalies the greater the chances of users having an early warning that something is wrong with equipment or the process.
  • Leverage sub out and sub in objects to pass intended logic through validation logic to trigger alarms and notifications whenever the expected values do not match the functions used in the logic and or could indicate that inputs or outputs have been altered in some way or that new functions and or connections have been made to the expected logic blocks.
  • Leverage alarm and notification functions to create classes and levels of alarms and notifications specifically to trigger unexpected, unsafe, anomalous, unauthorized behaviors and conditions that can then be set on a suspicious and unauthorized activity specific HMI screen and forwarded to a centralized alerting and monitoring platform for ICS events.
  • Whenever possible use more advanced programming tools such as RSLogix 5000 instead of 500. The advanced tools are more expensive, but they support more of the IEC 61131-3 languages and they allow you to leverage the strengths of each language within the same main program. You can use FBD to create an advanced suite of mathematical logic functions as well as alarms and notification levels for example.



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 4 of this series will focus on Instruction List (IL). 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.