"Safe PLC" programming Project Information

For many years, programmable logic controllers (PLCs) have been designed and programmed insecurely.

To remedy this security gap, several years of customization and application of IT best practices have resulted in secure protocols, encrypted communications, network segmentation, etc. However, to date, there has not been a focus on using features in PLCs (or SCADA/DCS) for Security, or on how to program PLCs with Security in mind.

The project "Top 20 Secure PLC Coding Practices”, inspired by existing secure coding practices for IT, seeks to fill this gap.

Written for engineers by engineers

The purpose of this project is to provide guidance to PLC programmers who are creating software (ladder logic, function charts, instruction list, etc.) to help improve the Security posture of industrial control systems. These practices take advantage of features available natively in PLCs and DCSs.

Few additional hardware or software tools are required to implement these practices. They can all be incorporated into the normal PLC programming and operation workflow. For the implementation of these practices, a good knowledge of the PLCs to be protected, their logic and the underlying process is required, as well as skills in the field of Security.

To qualify for the “Top 20 Secure PLC Coding” practices list, the practices themselves must include instructions and changes to be made directly to the PLC logic.

  • The PLC code must be simple, modular and tested in every part.
  • The PLC must not trust (too much) SCADA
  • The SCADA must not trust the PLC (too much).
  • The operating logic must remain on the PLC, because it has performances that a computer does not have
  • The PLC must be aware of changes to its configuration.
  • Communications to and from the PLC must be limited and controlled

Here is the list. For the full list of descriptions and instructions, see the full document below!

Consult the complete document CLICK HERE!

 

Secure PLC Coding Practices: Top 20 List Version 1.0 (June 15, 2021)

 

1. Modularize the PLC code

Divide the PLC code into modules, using different function blocks (subroutines). Test modules independently.

2. Track operating modes

Keep the PLC in RUN mode. If the PLCs are not in RUN mode, an operator alarm should be generated.

3. Leave the operating logic in the PLC where possible

Leave as much operating logic as possible, such as totalisation or integration, directly in the PLC. The HMI may not be getting enough updates to do this correctly.

4. Use PLC flags as sanity checks

Put counters on the PLC error flags to catch any math problems.

5. Use cryptographic sanity checks and/or checksums in PLC code

Use cryptographic hashes, or checksums if cryptographic hashes are not available, to verify the integrity of the PLC code and generate an alarm when they change.

6. Validate timers and counters

If the values ​​of timers and counters are written to the PLC program, they must be validated by the PLC if reasonable and check if the downcounts are less than zero.

7. Validate and warn for coupled inputs/outputs

If there are coupled signals, ensure that both signals are not driven together unnecessarily. Alert the operator when physically infeasible input/output states occur. Consider making coupled signals independent or adding delay timers when activating/deactivating outputs could be detrimental to the actuators.

8. Validate input variables/inputs from the HMI at the PLC level, not just on the HMI

The HMI's input of variables to the PLC can (and should) be limited within a valid operational range of values ​​on the HMI, but additional cross-checking must be added into the PLC to prevent or report values ​​outside the acceptable ranges programmed in the HMI.

9. Validate indirect data settings on a string

Validate indirect settings by limiting the ends of the data string, to detect any addressing errors.

10. Assign designated register blocks for each function (read/write/validation)

Assign designated register blocks for specific functions in order to validate data, avoid buffer overflows and block unauthorized external writes in order to protect data on the PLC.

11. Tools for Plausibility Checks

Add, if possible, instruments on the process in order to allow plausibility checks by cross-referencing different measurements from different sensors.

12. Validate inputs for physical plausibility

Ensure operators can only manually enter what is practical or physically feasible into the process. Set a timer for an input operation indicating how long it should physically last. Consider notifying when there are detours and also in case of unexpected downtime.

13. Disable unnecessary/unused communication ports and protocols

PLCs and network interface modules typically support multiple communication protocols enabled by default. Disable unnecessary ports and protocols for the application.

14. Limit third party data interfaces

Limit the type of connections and data available to third-party interfaces. Connections and/or data interfaces should be well defined and limited to allow only read/write capabilities for the required data transfer.

15. Define a safe process state in case of PLC stop/restart

Define and set what are the safe states for the process in case of stop/restart of the PLC (for example, apply power, disconnect power, keep the previous state).

16. Summarize the PLC cycle times and analyze them on the HMI

Track the PLC cycle time every 2-3 seconds and report it on the HMI for display on a trend graph.

17. Record the PLC uptime and analyze it on the HMI

Record PLC uptime to know when it restarted. Trend and uptime log on the HMI for any diagnostics.

18. Record PLC hardware shutdowns and analyze them on the HMI

Store PLC hardware stop events for faults or shutdowns, for recovery by alarm systems on the HMI to be consulted before restarting the PLC. Time synchronization between PLC and HMI for more accurate data.

19. Monitor PLC memory usage and trend it on the HMI

Measure and baseline memory usage for each PLC deployed in the production environment and analyze it on the HMI.

20. Catch false negatives and false positives for critical alarms

Identify critical alarms and schedule a check for those alarms. Set the check to monitor conditions and alarm status for any deviation.

Information about the safe programming project of the PLC.

Consult the complete document CLICK HERE!