Another point I made in the S4x20 Presentation had to do with input validation in a PLC.
If you have paired inputs, such as START and STOP, FORWARD and REVERSE, OPEN and CLOSE, etc… you should ensure that both inputs or both outputs are not asserted together. It is an important validation step to ensure that you don’t have some operational error or some kind of rotten coding in your PLC.
Note that I’m not suggesting that it is bad to write directly to the I/O for validation testing. In fact, there should be some sort of automation code disable function in the PLC to allow for this debugging. Keep the low level validation code in there, but disable automated behavior. But once that hands-on I/O validation is done, all direct I/O writes to the PLC should be blocked. This would preferably be done by protocol sensitive firewalls.
We seek layers of protection and validation. When you allow a remote device to write directly to outputs or timers without validation through the PLC, you’re basically saying that you don’t care what that I/O or timer does.
Another crude, but effective point of validation is to set a timer for an operation. For example, the gates on a dam take time to go from fully closed to fully open. If the gate takes longer than expected to go from one extreme to the other, that’s worthy of an alarm. By the way, if it does it too quickly that is worthy of an alarm too. There are mechanical reasons why the former could happen. But the latter could be of concern too, because it either indicates that the gate was already in the middle of a travel state or that someone is trying to fake out the I/O.
And this brings up another issue: if you allow remote devices, such as an HMI, to write timer values to a program, do not expose the timer value to them directly. Validate the presets, the timeout values and so on. For example, if a preset value is supposed to have a value from 1.00 to 5.00 seconds, check it. Do not allow someone to stuff 600 seconds (10 minutes) in to that timer. Keep in mind that the PLC timer function has no validation built in to it. If you care, YOU should do the validation. Security issues aside, it also reduces the possibility of someone making an error at the HMI.
There is also a practice where people would write directly to I/O through the PLC. Please don’t do that. The reason is that this assigns a level of trust to the HMI (or other network devices) that is unwarranted. Sure, your protocol might even be authenticated. But it is still a bad idea. It removes the PLC from being a layer of the protection equation.
These are simple things to implement. But they’re often absent in many applications because nobody bothered to write it in to the Control System Narrative document. Thus, while the automation was built to specification, it may not be meeting your needs very well.
Be sure to write this stuff in to the Control System Narrative documents you give to the integrator. And if you’re the integrator, be sure to notify your clients that this is missing. Go ahead and charge extra for this. Clients deserve to learn this lesson too.
Postscript: Bryan Singer got me thinking (as he often does) and I realized that I neglected to mention a very important reason why it is better to do your validation in the PLC than to rely exclusively on a Deep Packet Inspection (DPI) firewall: The PLC “knows” what the process state or context is. It can validate what it gets and WHEN it gets these commands, or setpoints.
There are situations where certain commands should be ignored and perhaps send an alert. A DPI firewall can certainly send the alert, but it is not designed to be aware of the process state. Could you do it? Yes, if the PLC presents a status and the DPI firewall is aware of that status, then it might be able to reject destructive commands; and if it does so, it really should send an alert. However, you have to understand where this alert will be going: It will be headed to an OT network SOC, not the operators. The Operators are the ones who will need to know about this first and they will be aware of who is supposed to working on what. This will be more actionable if you inform the Operators first.
Process validation is much more practical and straightforward when done entirely in an industrial controller than it is to attempt distributing this sort of functionality in to what is supposed to be a network device.
