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.
| Security Objective | Target Group |
| The integrity of PLC logic | Product Supplier Integration / Maintenance Service Provider Asset Owner |
Leave Operational Logic in the PLC
HMIs provide some level of coding capabilities, originally aimed to help operators enhance visualization and alarming, that some programmers have employed to create code that should rather stay in the PLC to remain complete and auditable.
Calculating values as close to the field as possible makes these calculations more accurate. The HMI does not get enough updates to do totalizing / integrating well.
Also, there is always latency between HMI and PLC. Further, when the code is in the PLC, and an HMI restarts, it can always receive totalizers/counts from a PLC.
In particular, HMI code to be avoided is anything related to security or safety functions such as interlocks, timers, holds or permissives.
For analyzing process data values over time, a process data historian is a better choice than the HMI. Use queries in a process historian database to compare totalized values (over a period, over a batch, over a process cycle) with totals aggregated locally in PLC logic.
Alert on a variance greater than that can be explained by differences in data granularity.
Example
Code to establish conditions to enable/disable buttons: Enable/disable actions should be controlled on the PLC layer, otherwise, actions can be performed on the HMI (or through the network) in PLC, although not meeting (intended) conditions.
Timers to allow actions to the operator (delay timer for consecutive motor starts, timer to consider valves closed/open or motor stopped) should not be put on the HMI layer but in the PLC governing such motor/valve.
Thresholds for alarms have to be part of PLC codes although displayed on HMIs.
Water tank with changing volume: The PLC which controls flow in and out of the tank can easily totalize volume (and cross-validate totals).
The HMI could do this as well, but it would need to get the values from the PLC first. These values would need accurate time-stamps in order to get correct totals in case of latency or and might miss values if the HMI restarts.
Why?
| Beneficial for…? | Why? |
| Security | 1. Allows consistency in verifying code changes. HMI coding has its change control apart from PLC, generally not with the same rigor (especially in construction and commissioning phases), not allowing system owners to have a complete view, and even losing important considerations. HMI’s do not include “forced signals” or changed value lists as PLCs or SCADAs, so HMI level changes are more difficult to be detected, practically impossible to be part of an authorization change management plan. 2. For an attacker, it is harder to manipulate totals distributed over many PLCs than to manipulate totals all calculated in the HMI. 3. If a portion of the enable/disable functions are not in the PLC, attackers might be able to manipulate the PLC and I/O without having to work the HMI portion as the proper information is already obfuscated on the operator screen. |
| Reliability | 1. Calculations are more efficient and accurate if closer to the field. Also, totals and counts will still be available if HMI restarts (PLCs do not restart as often and usually store these values in non-volatile memory). 2. Different sources for inputs and interlocks may mean non-expected failures. There can be different technologies for HMIs in a plant (SCADA layer, but also field controller panels), and changes in one of those will fail to be disseminated through the rest of the layers, leading to inconsistencies in visualization and possible failures in operation. |
| Maintenance | Coding is easy to understand and transfer from PLC to PLC, not so much from HMIs to HMIs. |
References
| Standard/framework | Mapping |
| MITRE ATT&CK for ICS | Tactic: TA010 – Impair Process Control Technique: T0836 – Modify Parameter |
| ISA 62443-3-3 | SR 3.6: Deterministic Output |
| ISA 62443-4-2 | CR 3.6: Deterministic Output |
Source: PLC Security
