“For safety and security reasons, control system designs should not allow applications such these to be more than read-only.”From a security perspective Joe is absolutely correct. Allowing remote access to control functions just opens up too many avenues for an attack on the control system. But, and this is a big but, I have never met an engineer that was satisfied with just monitoring a process. To too many to tweak a process is to control the process.
To be fair it isn’t just engineers. I spent almost 12 years being responsible for a variety of chemical manufacturing processes. A major part of my job was to trouble shoot process upsets in real time. For a couple of years I could monitor my processes from my lap top through a VPN connection, but many times I ached to be able to put my hands on the controls to try to rescue a process that was on the verge of failing. Fortunately the couple of times I was asked if I actually wanted that capability (my boss had it), I was not in the throws of a process upset and was able to resist the temptation (and probably saved my marriage).
Besides, there are too many modern situations where companies use control systems at remote locations where it just doesn’t make sense to have someone there to operate the controls. Remote operations are going to be a necessity or a very highly desirable tool in too many situations. Instead of banning that remote control for security sake, as the security folks would like to have us do, we need to make sure that we can design and operate systems that are able to execute remote control of sensitive operations safely and securely.
Posts
1 comment:
It makes sense that chemical plant systems would have a large number of read-only remote access points, but few control-based points. It is crucial that all changes to the system can be tracked. For this reason, remote control software, even within the local network, is a tricky issue.
Post a Comment