External Connections
When stories about Internet based attacks on control systems, like the 60 Minutes story, appear on sites like Slashdot, most people question the need to attach the control network to another network. In my previous position at a National Laboratory, I have seen proper network segregation implemented successfully, though at times it can be a pain to work with. The Labs place a high value on security and have the financial means to implement it. In an optimal setting, there would be no need to have the control network connected to any other network. There are often business reasons that make it necessary at times to connect the control network to another network.
Information is often shared from the control network to the corporate network for various reasons. In this case, the optimum way to share that data would be to give those employees who need the control network data a separate workstation on a network not connected, physically and logically, to the corporate network. These systems would connect to a DMZ in between the control network and this control data sharing network. This setup is similar to what we see in some of the better implemented control networks where the control system employees are given a separate workstation connected to the corporate network. The difference is that this configuration would provide limited control system data access to those on the corporate side. The systems could be very lightweight, possibly thin clients or older computer systems that would normally be discarded.
Remote access is difficult to assess as there are times employees may be required to connect to control network when out of the office. This of course is a business / risk management decision that needs to be determined internally. If remote access is allowed, even if only for emergency situations, it may be appropriate to have a physical separation between the remote access server and the control network. One option is a KVM over IP setup that is physically put in place by a local technician when access is needed, then removed once access is no longer required.
Another big reason control networks are connected to external networks is information sharing with partners. This is possibly the most difficult situation to protect against as there must be some trust between the two networks. If the data is a one way outbound connection and the data is being sent over a stateless protocol (e.g. UDP) physical countermeasures, like cutting the receive wire in an ethernet cable, can be taken. When the data is not stateless but still one way outbound, one way gateways can be used to provide the data with significantly less risk. When data is being shared in both directions proper firewalling is paramount.
In all of the situations listed above, proper authentication and access control should be implemented. In all situations, it should be easy to disconnect the control network from outside networks and there should be a process in place that allows that to happen.
Author: Charles Perine
Posted: November 12th, 2009 under Authentication, Big Picture, Firewall / Perimeter, Remote Access, SCADA Architecture.
Comments: 5
Comments
Comment from olle
Time: November 13, 2009, 9:49 am
One solution I favour is connecting the power cord of that KVM (or dialup box, or whatever other remote access hardware) to a “coffee-timer” that the on-site technician will turn on when needed but will ensure that it is powered down when not in use…
Comment from Jake Brodsky
Time: November 13, 2009, 9:53 am
Well Said. Too many glossy magazines still tout the wonders of remote access to a SCADA system without discussing the full risk profile, or even what the cost justification for doing this might be.
I’m still suffering from plant managers who demand remote access to their plants so that they can look at how things are doing in their pajamas. Where is the business case? Where is the risk?
Nitwits…
Comment from amino world
Time: November 13, 2009, 11:47 am
hey, hey, easy there, Jake. you’ll likely offend nitwits everywhere with this kind of association.
Comment from Michael Toecker
Time: November 13, 2009, 7:05 pm
Or if you are in the NERC-CIP space, NERC requires that all external interactive access into an Electronic Security Perimeter be subject to strong authentication before being allowed access. If you read through the FAQ, it turns out that “strong auth” is effectively the same as “two-factor”.
We routinely recommend VPN with preshared key or Firewall+RSA token to satisfy these requirements.
That being said, the vast majority of automation protocols are missed by this requirement. If you have a connection through your ESP, NERC doesn’t require that automation protocols be set up with access controls (such as those DigitalBond describes in it’s OPC whitepaper). Major security miss, and one that I still recommend be done from a deny-by-default perspective.
That’s why I love OPC tunneling products, they provide a good wrapper of security around an OPC connection, and allow much stricter control over what information and permissions are allowed. My main quibble is that they tend to slow the connection down though.
And Jake, there are lots of reasons to allow a plant manager remote access. Most of them start with “I’m the plant manager” and could end up with “you’re fired”. But I think the majority of connections that people worry about are from the maintenance and troubleshooting side. I know at least 12 people who would be hard pressed to support I&C for generation over a 5 state area without remote access. And THAT definitely has had a business case and a risk assessment.
Mike Toecker
Burns and McDonnell
P.S. External Interactive Access is a fancy term for command line, remote desktop, VNC, PCAnywhere, etc.
Comment from Ron Southworth
Time: November 14, 2009, 10:51 pm
Hi Mike & Jake,
Interestingly I had a I’m the plant manager type moment recently. Security requirements won and he lost out !
Good governance models help with this sort of issue when it pops up and having good buy-in from C level to create the governance model out of the gate makes it even better. Well defined role based access descriptions in simple and plain language.
I think some simple controls like removing the power to the enabling device be it modem, KVM etc are very effective. Operators are good at turning power points on and off if you make it easy enough for them especially when they need you to fix something for them.
For certain remote access for maintenance purposes is always going to be a risk however it is also mangeable thru good governance guiidelines and apropriate use of technology. Authentication/Identification (Identity Management) is a interesting topic that can be a matter of some discussion.
OPC / tunneling products are another issue, Mike if you find some implimentations that work and are not buggy on one end let me know. I’m still searching for a good turn-key. If it is not the tunneling product it wil be the end points. The last implimentation I used we removed it before the three vendors had even started to stop arguing about where the problem was.
Maybe I wil have beeter luck with the Salt mine upgrade it is at least going to be easier (less vendors) and the OPC driver product and tunneler are the same brand.
Ron Southworth
Write a comment