Also, many of devices critical to the control system environment don’t support “security.” Sometimes, there’s only one user ID, if they’re supported at all. And, if passwords are supported, they’re generally alpha-numeric characters, or sometimes just alphabetic characters, which are transmitted in plain text.
To make matters worse, operators controlling the processes often must respond rapidly to a situation, before it becomes a crisis. This requires the window onto the process being controlled, the operator console, to be logged on with one user ID that is shared by all the operators, while items such as screensavers and idle time lockouts are forbidden. Due to limited staffing, separation of duties is often impossible in control environments. For instance, control engineers often doubles as system administrators.
Part of the conflict between IT and Operations may be due to vague terminology. We’ve repeatedly stated that control systems must be a “more secure” environment, but what does this really mean?
IT looks at that statement and asks, “How can that be? They allow people to share user IDs, security patches haven’t been applied, and passwords are hardly ever changed.” From the IT perspective, until control systems embrace current best practices, including quick installation of security patches, complex passwords, and individual user IDs, to name a few, not only will the control systems not be secure, but they will remain a threat to the rest of the organization.
When IT hears that the control environment must be more secure, they correctly think it must be security hardened, according to IT’s best practices. When Operations hears the control environment must be more secure, they correctly think it must be protected from the outside world. Therefore, in the conflict between IT and Operations, it’s entirely possible that, from their different perspectives, they’re both correct.
How to Resolve Confusion
Perhaps we should say that greater diligence needs to be applied when protecting the control environment? Because the control environment will never be “security hardened” in the foreseeable future, the perimeter of the control environment must be defined, identified, and isolated from outside networks. Strict controls should be placed on connections allowed and on the methods of data transfer in and out of the control environment. We all should recognize that devices in the control environment are and will remain vulnerable to hacks, worms, and viruses. Therefore, appropriate steps must be taken to ensure malicious code is never introduced.
Perhaps we should define trust models? The control environment should never trust anything coming from an external environment. All data transferred into the control environment should be verified. All devices should be scanned for malicious code before they’re allowed to connect to the infrastructure. For example, these would include vendors’ and visitors’ laptops. Remote access connections should terminate in a DMZ separating corporate and control environments. And, since the control environment can’t be hardened, perhaps the corporate environment shouldn’t trust it as well.
Above all, we should educate and work with each other. IT should learn what control systems do and the constraints on them before requiring vulnerability scans be run against control devices, or that Operators have individual user IDs and Operator Consoles have password-protected screen savers. Operations should learn about the problems IT faces in protecting the corporate environment, and recognize that IT wants to make changes because vulnerabilities need to be addressed.
Everyone should work together to look critically at vulnerabilities, and devise methods that will mitigate the vulnerabilities, while not interfering with critical business functions. We need to keep in mind that sometimes procedures, processes, and physical security can mitigate vulnerabilities when a technical solution isn’t viable. We need to develop a joint effort where IT does what it does best and Operations does what it does best.