One of the best PLC best practices is to use PLC flags as integrity checks.
Put counters on PLC error flags to capture any math problems.
| Security Objective | Target Group |
| The integrity of PLC logic | Product Supplier Integration / Maintenance Service Provider |
Use PLC Flags as Integrity Checks
If the PLC code was working fine but suddenly does a divide by zero, investigate. If something is communicating peer to peer from another PLC and the function/logic does a divide by zero when it wasn’t expected, investigate.
Most programmers will ignore the issue as a math error or worse yet, might presume their code is perfect and let the PLC enter a hard fault state.
During code development, engineers need to test and validate their code modules (snippets or routines) by inputting data outside of expected bounds. This may be termed Unit Level Test.
Assign different, locked memory segments for firmware, logic, and protocol stack. Test the protocol stack for abuse cases. Abuse cases could be peculiar flag conditions in a packet header.
Example
PLC faults caused by out-of-bounds data are very common. This happens, for example, when an input value causes array indices to go out of bounds, or timers with negative presets, or divide by zero exceptions.
Typical flags of interest are
- divide by zero
- counter overflow
- negative counter or timer preset
- I/O scan overrun
Why?
| Beneficial for…? | Why? |
| Security | Attacks on PLCs could include changing their logic, activating a new program, testing new code, loading a new process recipe, inserting auxiliary logic to send messages, or activating some feature. Since most PLCs do not provide cryptographic integrity checks, flags can be a good indicator if one of the above logic changes happens. |
| Reliability | Flags taken seriously can avoid the PLC running with programming or I/O errors. Also, if an error occurs, the source of the failure is more obvious. |
| Maintenance | / |
References
| Standard/framework | Mapping |
| MITRE ATT&CK for ICS | Tactic: TA010 – Impair Process Control Technique: T0836 – Modify Parameter |
| ISA 62443-3-3 | SR 3.5: Input Validation SR 3.6: Deterministic Output |
| ISA 62443-4-2 | CR 3.5: Input Validation CR 3.6: Deterministic Output |
| ISA 62443-4-1 | SI-2: Secure coding standards SVV-1: Security requirements testing |
| MITRE CWE | CWE-128: Wrap-around CWE-190: Integer Overflow CWE-369: Divide by Zero CWE-754: Improper Check for Unusual or Exceptional Conditions |
Source: PLC Security