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.
| Security Objective | Target Group |
| Integrity of I/O values | Integration / Maintenance Service Provider |
Validate PLC Inputs
1) Monitor expected physical durations
If the operation takes longer than expected to go from one extreme to the other, that is worthy of an alarm. Alternatively, if it does it too quickly, that is worthy of an alarm too.
A simple solution could be a step-timeout alert. This would be useful for sequence/step-controlled tasks.
For example, the step “move object from A to B” takes 5 sec from the start of the step until the transition condition (sensor: object arrived at B) is met.
If the condition is met significantly too early or too late, the step-timeout is alert triggered.
2) Monitor expected physical repeating activity
Physical plausibility checking can also mean alert for physically implausible inactivity:
If there is an expectation of a regular, repeating cycle of events (e.g., batches, diurnal patterns), an inactivity timer would alert if something which is expected to change (discrete or analog value) remains static for far too long.
Examples
a) Monitor expected physical durations
The gates on a dam takes a certain time to go from fully closed to fully open
In a wastewater utility, a wet well takes a certain time to fill
b) Monitor expected physical repeating activity
Manufacturing process or pipeline batching should regularly cycle between control ranges or operating modes.
Municipal wastewater treatment plants typically have a diurnal cycle of activity/pattern of influent flow rates.
c) Limit operator entry for set points to what’s practical/physically possible
e.g., Oldsmar Florida case allowed for operator input that’s a) thousands of times more than what was typically needed b) that’s physically not possible.
Try to configure the operational limits in the PLC code wherever possible instead of using HMI scripts.
Why?
| Beneficial for…? | Why? |
| Security | 1. Deviations can indicate an actuator was already in the middle of a travel state or that someone is trying to fake the I/O, e.g., by doing a replay attack. 2. Inactivity alerts facilitate monitoring for frozen or forced constant values which could be the result of system or device tampering. |
| Reliability | 1. Deviations give you an early alert for broken equipment due to electrical or mechanical failures. 2. Inactivity alerts help flag measurements or system control loops which may be failing (thus static) due to physical device fault or an issue with the logic control algorithm or failed/improper operator input. |
| Maintenance |
References
| Standard/framework | Mapping |
| MITRE ATT&CK for ICS | Tactic: TA010 – Impair Process Control Technique: T0806 – Brute Force I/O |
| 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 |
| MITRE CWE | CWE-754: Improper Check for Unusual or Exceptional Conditions |
Source: PLC Security