PLC best practices – Split PLC code into modules, using different function blocks (sub-routines). Test modules independently.
| Security Objective | Target Group |
| The integrity of PLC logic | Product Supplier |
Split PLC Code into Modules
Do not program the complete PLC logic in one place e.g., in the main Organization Block or main routine. Instead, split it into different function blocks (sub-routines) and monitor their execution time and their size in Kb.
Create separate segments for logic that functions independently. This helps in input validation, access control management, integrity verification, etc.
Modularized code also facilitates testing and keeping track of the integrity of code modules. If the code inside the module has been meticulously tested, any modifications to these modules can be verified against the hash of the original code, e.g., by saving a hash of each of these modules (when that’s an option in the PLC).
This way, modules can be validated during the FAT/SAT or if the integrity of the code is in question after an incident.
Example
Gas Turbine logic is segregated into “startup”, “Inlet Guide Vanes Control”, “Bleed Valve Control” etc. so that you can apply standard logic systematically. This also helps in troubleshooting quickly if there were to be a security incident.
Custom function blocks that are tested rigorously can be re-used without alteration (and alerted if change attempts are made) and locked against abuse/misuse with a password/digital signature.
Why?
| Beneficial for…? | Why? |
| Security | Facilitates the detection of newly added portions of code that could be malicious. Helps in logic standardization, consistency, and locking against unauthorized modifications. |
| Reliability | Helps control the program flow sequence and avoid loops, which could cause the logic to not react properly or crash. |
| Maintenance | Modular code is not only easier to debug (modules can be tested independently) but also easier to maintain and update. Also, the modules may be used for additional PLCs, thus allowing for common code to be used and identified in separate PLCs. This can aid maintenance personnel with quickly recognizing common modules during troubleshooting. |
References
| Standard/framework | |
|---|---|
| Standard/framework | Mapping |
| MITRE ATT&CK for ICS | Tactic: TA002 – Execution Technique: T0844 – Program Organization Units |
| ISA 62443-3-3 | SR 3.4: Software and information integrity |
| ISA 62443-4-2 | CR 3.4: Software and information integrity |
| ISA 62443-4-1 | SI-2: Secure coding standards |
| MITRE CWE | CWE-1120: Excessive Code Complexity CWE-653: Insufficient Compartmentalization |
Source: PLC Security