Best Practices for Cyber Secure PLC Programming

Stemming from the 2020 presentation by cyber security consultant, Jake Brodsky, “Secure Coding Practices for PLCs” is a publication of best practices for PLC and DCS programmers who want to improve the security posture of their applications, leveraging natively available functionality in the PLC/DCS. The practices are focused primarily on reducing the attack surface or enabling faster troubleshooting in the event of a problem, but many of them also contribute to making the PLC code more “reliable, easier to debug and maintain, easier to communicate, and possibly also leaner.”

For each of the 20 best practices, the series provides guidance, examples, and references. Their first suggestion, for example, is “Modularize PLC Code,” which they describe as splitting PLC code into modules, using different function blocks and testing modules independently. This improves security by making it easier to test and debug newly added portions of code and helps in logic standardization, consistency, and preventing unauthorized modifications. Modularizing code also improves reliability by helping control the program flow sequence and avoiding errors, which could cause the logic to not react properly or crash. Modular code is also easier to debug. Modules can be tested independently and are easier to maintain and update. The modules can also be built into libraries, thus allowing for common tested code to be reused in additional PLCs. This can help maintenance personnel recognize common modules quickly during troubleshooting.

The current list is the product of a year of crowdsourcing. They provide protection not only against malice, but also simple human error. Each tip is also documented with examples and links to reference sources. Here are the 20 tips covered in the June 15, 2021 version of “Secure PLC Coding Practices: Top 20 List” Version 1.0:

1. Modularize PLC Code — Split PLC code into modules, using different function blocks.
2. Track operating modes – Keep the PLC in RUN mode. If PLCs are not in RUN mode, there should be an alarm to the operators.
3. Leave operational logic in the PLC wherever feasible – Leave as much operational logic e.g., totalizing or integrating, as possible directly in the PLC. The HMI does not get enough updates to do this well.
4. Use PLC flags as integrity checks – Put counters on PLC error flags to capture any math problems.
5. Use cryptographic and/or checksum integrity checks for PLC code – Use cryptographic hashes, or checksums if cryptographic hashes are unavailable, to check PLC code integrity and raise an alarm when they change.
6. Validate timers and counters — If timers and counters values are written to the PLC program, they should be validated by the PLC for reasonableness and verify backward counts below zero.
7. Validate and alert for paired inputs/outputs If you have paired signals, ensure that both signals are not asserted together – Alarm the operator when input/output states occur that are physically not feasible. Consider making paired signals independent or adding delay timers when toggling outputs could be damaging to actuators.
8. Validate HMI input variables at the PLC level, not only at the HMI – HMI access to PLC variables can (and should) be restricted to a valid operational value range at the HMI, but further cross-checks in the PLC should be added to prevent, or alert on, values outside of the acceptable ranges which are programmed into the HMI.
9. Validate indirections – Validate indirections by poisoning array ends to catch fence-post errors.
10. Assign designated register blocks by function (read/write/validate) – Assign designated register blocks for specific functions to validate data, avoid buffer overflows and block unauthorized external writes to protect controller data.
11. Instrument for plausibility checks – Instrument the process in a way that allows for plausibility checks by cross-checking different measurements.
12. Validate inputs based on physical plausibility – Ensure operators can only input what’s practical or physically feasible in the process. Set a timer for an operation to the duration it should physically take. Consider alerting when there are deviations. Also alert when there is unexpected inactivity.
13. Disable unneeded/unused communication ports and protocols – PLC controllers and network interface modules generally support multiple communication protocols that are enabled by default. Disable ports and protocols that are not required for the application.
14. Restrict third-party data – Interfaces restrict the type of connections and available data for 3rd party interfaces. The connections and/or data interfaces should be well defined and restricted to only allow read/write capabilities for the required data transfer.
15. Define a safe process state in case of a PLC restart – Define safe states for the process in case of PLC restarts (e.g., energize contacts, de-energize, keep the previous state).
16. Summarize PLC cycle times and trend them on the HMI – Summarize PLC cycle time every 2-3 seconds and report to HMI for visualization on a graph.
17. Log PLC uptime and trend it on the HMI – Log PLC uptime to know when it has been restarted. Trend and log uptime on the HMI for diagnostics.
18. Log PLC hard stops and trend them on the HMI – Store PLC hard stop events from faults or shutdowns for retrieval by HMI alarm systems to consult before PLC restarts. Time sync for more accurate data.
19. Monitor PLC memory usage and trend it on the HMI – Measure and provide a baseline for memory usage for every controller deployed in the production environment and trend it on the HMI.
20. Trap false negatives and false positives for critical alerts – Identify critical alerts and program a trap for those alerts. Set the trap to monitor the trigger conditions and the alert state for any deviation.

Download the complete document here.

As mentioned earlier, these practices are intended to help compensate for the lack of cyber security built into traditional control systems by taking maximum advantage of the natively available functionality. When that native functionality does, however, provide cyber security, as does the authentication and encryption built into Bedrock OSA controllers, the protection is even greater. A comprehensive protection plan would involve both cyber secure programming practices and intrinsic cyber security.