Security Connected

Compensating Measures – Network Perimeter Security Part 2

By on Mar 14, 2012

Welcome once again to our podcast series on critical infrastructure with Eric Knapp, Director of Critical Infrastructure Markets in McAfee’s Global Business Development Group. Today’s discussion will be part two of Compensating Measures, AKA Network Perimeter Security. If you haven’t already listened to Part 1, you might want to take a few minutes and go back and listen to or read that version, as well as our two previous podcasts on host security for SCADA and ICS Systems, parts 1 and 2.

Welcome to the show, Eric.

Thank you, Brian. It’s good to be here.

Eric, during the last podcast, we talked about the air gap, types of network security, and how you know if your network security controls are working. How do the security requirements change from place to place in a utility network?

Great question. I think one of the biggest misperceptions about cyber security for control systems is that a control system or critical infrastructure environment is just a corporate IT network in a company that has a control system. And that’s not true. There are really three unique environments. There is the corporate IT network, just as you’d expect there to be. There’s what I call the SCADA environment, which is a Supervisory Control And Data Acquisition. It does the management of the control system itself, the control processes, or what’s sometimes called the device network, which is the third area.

The SCADA environment is a modern networked environment, for the most part. The control system device network is not; it’s often serial. Sometimes it’s wireless or microwave or satellite. It runs very specialized protocols, and it’s controlled by the SCADA environment.

But just as we talked about how the host security requirements for a lot of these different assets, which go into different areas, are different from place to place, the network controls are different as well, because there are three demarcations. There’s the separation between the device network and the SCADA network that manages it. There’s the separation between the SCADA network and the corporate IT network. And we can’t forget the separation between the corporate IT network and the Internet, which, as we all know, is where all the bad stuff comes from.

Is it the same type of perimeter between each one of these areas?

In function, yes, but not in implementation. I know we talked a little bit last time about an intrusion prevention system, and what it needs to do to fit into a control system environment. I’ll expand on that here. So, we have a control system device network in a SCADA system. Those things interconnect, typically, via a programmable logic control or some sort of controller. The management station is telling an intelligent device to do something, and it tells the device network what to do, and it operates in automation.

The demarcation would need to be a SCADA firewall or IPS that’s able to lock down the explicitly defined communications between those two systems. So, there’s a very specific point with very specific requirements. Low bandwidth, fitted to a few protocols, and a few very specialized protocols. So, the demarcation between the control system, the SCADA environment, and the corporate IT network is fundamentally the same. You want a firewall, intrusion prevention, or some sort of network security control in place.

But now you’re looking at the collision of two very separate worlds. You have your SCADA environment with the specialized protocols and real-time environments, but you also have your corporate IT network, which is going to be very dynamic. There’s going to be lots of different applications and services, primarily TCP/IP based, but there are lots of open ports. There are lots of things jumping around.

So, in this case, you still need an IPS that would understand SCADA threats. But you’d also need one that understands the general bulk of threats that hit an IT environment – a corporate IT environment. So, it’s the same thing, but bigger. It’s still specialized, but it’s broader as well.

When you get to the Internet perimeter, I think it’s primarily a matter of scale. In a perfect world, you wouldn’t really need SCADA signatures to detect SCADA threats or exploits at the perimeter between the corporate IT network and the Internet. But my recommendation is always that if your IPS can do it, enable those, even if it’s just broad level detection of the protocols, and you know, not blocking it, but even just giving an alert. That’s good to know, because SCADA protocols should never be on the Internet, and they should never be coming in from the Internet, either.

Well put. And I think a lot of those capabilities are very intuitive. As we wrap up in this section, let me just ask you about remote access. How do you address it in these environments? I know you and I were talking the other day about people coming in from remote laptops, even smart phone applications.

A smartphone application is a perfect example. You can get SCADA apps from the app store for your iPhone. From a security standpoint, I would say, don’t ever do that. In fact, I have said, “Don’t ever do that,” and I was quickly corrected by an asset owner who said, “You know, sometimes we need to do that. We’ve got only a few people and, you know, Jim is 30 miles away on a ladder, working on a pole, and something happens and he needs to access the control system to do something routine, but something that’s very important.” That’s the perfect application for some sort of mobile remote access. And I can’t argue with that, right? I mean, ultimately, everything comes down to acceptable business practices.

But what I can say is, remote access has the capability to jump past network perimeters. You can put a firewall between the SCADA environment and the corporate IT environment, and then you can have a remote access point that jumps right past one of those controls.

So, providing remote access is a necessity, and it should be allowed. But it needs to be secured. So, use a secure VPN. Ideally, use multi factor authentication. Use different authentication for the remote access itself than for the credentials that you actually use to access these critical systems. And just use common sense.

I would say, a piece of common sense that a lot of people overlook is, if you need remote access into the control room, provide an access point in the control room that only those people who need it have access to. If it’s corporate remote access, that should be entirely separate. If it’s access to a specific device that’s actually down in the network for something like maintenance, that should be its own system. This way, if there is remote access, whoever gets in still has to cross those barriers if they want to propagate an attack between these three unique spaces.

Very well stated. Eric, as always, thanks so much for your time.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>