The Importance of Implementing Secure PLC Coding Practices

Most of us have already exhaustively heard about the Information Technology (IT) / Operational Technology (OT) convergence that is taking place in the Industrial Control System (ICS) environment. Therefore, I do not want to simply write another article reiterating how this convergence is taking place and the operational and security implications of it. Since the focus of this article is secure Programmable Logic Controller (PLC) programming practices, I’ll summarize the implications of the convergence as we now have additional computation information available to support operations and analytics. That with the increased connectivity comes an increased attack surface to the controls equipment in the ICS.


Historically, PLCs were never designed with security in mind since they have been historically air- gapped. With the demand to process operational data for advanced analytics, machine learning, predictive maintenance, and increased visibility into the process control environment increasing, PLCs are more exposed than ever, and attackers are now equipped with additional knowledge and tools[1] that exploit vulnerabilities in PLCs. It is no longer a safe assumption to hide behind the antiquated mindset that the ICS protocols are inherently protected since they use proprietary devices and protocols (security through obscurity). As with most new technology integrations, the initial focus has been on advancing the business use of the information without focusing on the increased attack surface that arises with the connectivity. Disconnected networks that house the critical process and safety PLCs are now at a higher risk of being compromised. It is more important than ever to begin to incorporate secure programming practices.


You may think, PLC programming language defined under IEC-61131-3 is very different from the standard coding, where our closest comparison is Structured Text and that standards or best practice guidelines do not exist for PLC logic. The secure programming practices in place for traditional coding do not apply to PLC programming, and standards or guidelines for secure PLC programming practices do not exist. That is no longer the case.

Most of us would love to ensure our PLCs were programmed and configured with a stronger security profile if only guidance was available. A list of the Top 20 Secure PLC Coding Practices list, released earlier this week, developed by a group of over 900 PLC programmers and ICS security professionals, with the primary goal of beginning to close this gap and equip automation engineers with a practical list of programming practices that will surely increase the security posture of your PLCs. While not exhaustive, this list is a great starting point for practices to consider implementing today. This list is readily available for anyone to download and reference. [2]


As with any security controls, you need to identify if the practice applies to your organization and if it will reduce risk, support the business objects, and justify the cost to implement. Many of these items in the list do not require a lot of additional time, just the appropriate planning and set of expectations for your programming environment.


A couple of good examples from the top 20 list:

#14 Restrict third-party data interfaces

This practice aims to ensure that third-party data connections are correctly designed and implemented in a way that uses a restricted data interface while not allowing third-party access to any information that is agreed upon and critical to operations. This item can be a blind spot that most security engineers either don’t know about or do not believe is in their scope since it is a direct PLC-to-PLC connection. Still, the reality is that the chassis planes can be hopped, and a compromised third-party network/system could wreak havoc on your ICS if this practice is not implemented.


#13 Disable unneeded/unused communication ports and protocols

This practice focuses on a more traditional systematic approach to risk reduction by reviewing the vendor documentation and conducting a penetration test in a sandbox environment to identify the available communication ports and protocols available on the PLC communication modules, identify which ports and protocols are in use, and then disable the ports and protocols that are not required. In some cases, this requires digging into the vendor manuals to better understand the security features already readily available by the vendor that does not require reprogramming/recommissioning your PLC logic.


With the release of the Top 20 Secure PLC Coding Practices[JC3] [2], the excuse of there not being any guidance on secure PLC programming practices is now a thing of the past. The importance of identifying a target security profile for your PLCs and implementing security practices into your ICS PLC coding standards should be a strong core part of your defense in depth strategy for defending your ICS from both internal and external adversaries.


[1] https://www.wired.com/2012/01/scada-exploits


[2] https://plc-security.com

by Josh Ruff

Industrial Cybersecurity Business Manager at aeSolutions