When More Security Is Not The Answer
We are increasingly running into situations where asset owners are cobbling together multiple security controls to do unnecessary and risky functionality they would never consider in the past. The most common example is providing the ability to manage and configure field devices from any computer on the corporate network.
A firewall and VPN is proposed, followed by strong two-factor authentication, followed by terminal services, followed by … Security controls are added to security controls with the idea that the right amount of security will make this an acceptable practice.
If this is the case, why do we bother with control centers? Why don’t operators simply run the HMI on normal PC’s on the corporate network? I know this would seem like heresy to asset owners, and it should. However there often isn’t similar concern in authorized users being able to manage and configure any and all field devices from a corporate PC.
The pushback we get is a challenge to identify the vulnerability that will lead to the risk, and if we identify a vulnerability the answer is to add another piece of security hardware or software. Unfortunately we don’t know what we don’t know. Look over the last year and you will see latent vulnerabilities discovered that allow remote control in security devices such as SSL implementations and firewalls. Lining up all those security controls actually increases the attack surface. It reminds me of my crypto days where I would see a budding cryptographer develop an extremely complex algorithm that would all collapse down to an 8-bit exhaust because of a poorly placed weak function.
To make matters worse the reason for taking this risk is more often than not convenience. We are a proponent of having a secure method for emergency remote access because there are operational reasons this is required. However we rarely see a valid operational reason that an engineer or maintenance personnel cannot work on a dedicated system in a secure area as a regular practice.
This is not saying that data can not be pushed out from the control system to the enterprise network through a DMZ. This is a sound practice and often represents most of the required access from the corporate network. But control and access that will affect control should be restricted to logically and physically secure control systems.
On this issue call me a Luddite.
Author: Dale Peterson
Posted: July 5th, 2007 under Big Picture.
Comments: 4
Comments
Comment from Erik Hjelmvik
Time: July 6, 2007, 4:27 am
I would say one of the reasons for why solutions are built in order to provide access to field devices is in order to let vendors in for support reasons. Vendors today often require some form of remote access to the control systems in order to fullfill an SLA or support contract.
In fact I will be speaking about this type of access at Joe Weiss’s conference in August, so please come and listen to me there.
An interresting thought is there could be a scenario in the future where operation will be outsourced to vendors or contractors just like service and support is done today. Personally I don’t think we will be going there, but some vendors might disagree since they might argue that they know their systems better than the asset owners and therefore also has better knowledge of how the production can be optimized (I’m mainly thinking of energy production here).
Comment from Dale Peterson
Time: July 6, 2007, 7:24 am
Erik – I put vendor access in the emergency remote access category. Something that should be securely designed and implemented so it is available when needed.
That said, we do see vendor access often violating many sound security practices with large numbers of old accounts, full time unrestricted access, etc., but this is typically for the SCADA and DCS applications rather than field devices.
I have no problem with vendors managing control systems remotely. However they need to follow the asset owners SCADA security policy including logical and physical security perimeters, AAA controls, patching and anti-virus, training and awareness, … and you bet I’ll audit their compliance with the policy.
Looking forward to meeting you and hearing your talk at Joe’s event.
Comment from Jake Brodsky
Time: July 6, 2007, 5:55 pm
There are several elements to this: First, the security can’t get in the way of real time performance. That’s why we can’t have corporate PCs showing real time data. Most of the time we could let an HMI work on the corporate network –until something saturates the network. Second, the full authentication business can cause an operator to go in to vapor lock when something critical needs to be done and his three password tries lock him out.
As for remote access, we’re staffed 24/7. If a vendor wants in, I want an operator to be aware that they’re there. Vendors that dial in or network in without letting us know first could cause very bad things to happen. Some vendors want to do this for motor controls. So this isn’t limited just to SCADA servers and the like.
The theory that if some security is good that more must be better is bogus. The key is that the users must understand the security that protects them. If they do not understand the security, then the security will become a stumbling block and get defeated. I also like to keep the spectrum of protocols a SCADA system is exposed to to a minimum. This way, it’s easier to detect exploits and manage patches.
Comment from Eric Cosman
Time: July 13, 2007, 3:22 pm
Luddites of the control world, unite!
I agree completely with your comments about remote access. Some have heard me speak of what I call the “law of proximate disruption”; If you are able to do anything that can disrupt the process, you have to be located such that you are disrupted with it.
We look VERY carefully at situations that involve any kind of “remote access”, even if it is remote in the sense of being from one of our facilities to another. At no time should it be possible to “go behind the back” of Operations and do things that they cannot see and be aware of. Remote access (or any access) by suppliers is “ushered”, just as we would if we were escorting people physically on our premises.
Write a comment