Compensating Measures – Network Perimeter Security Part 1

Welcome to another installment of our podcast series on critical infrastructure with Eric Knapp, Director of Critical Infrastructure Markets in McAfee’s Global Business Development Group. If this is your first time joining us, be sure and head back in the blog and read or listen to our two previous discussions on host security for SCADA and ICS Systems, parts 1 and 2. Today’s discussion will be part one of “Compensating Measures – Network Perimeter Security.”

Welcome to the show, Eric.

Hi, Brian. It’s good to be back.

Today we’re talking about compensating measures, network perimeter security. Sometimes assets simply can’t be secured directly. I think we get that. Especially in these environments, they can’t be patched. For some reason, maybe it’s not even possible to implement a host security control like application whitelisting, which of course is what we talked about during the last two podcasts. There might be a technical limitation, or it may be that the control system vendor isn’t going to allow it without breaking your service agreement. So then what? What can we do if all these things fail? What are some steps we can take?

That’s the big question. The good news is that, first of all, that situation is getting a lot better. More and more vendors are certifying the use of security controls like McAfee’s own Application Control, and they’re building more and more security into the assets on an ongoing basis. The newer assets don’t have this problem so much, but there will always be cases where the host can’t be adequately secured. It’s just a fact of life.

The other gotcha in a control environment is that even if they are secured, most control systems operate using a variety of SCADA or industrial control protocols that operate on a paradigm of command and control. It’s based on implicit trust. So even a secured asset doesn’t necessarily mean that you have a secure control system. The control system could be hijacked directly, or you could inject protocol traffic onto the network if you’ve got access to the physical network. Telling control system elements to do things that they’re programmed to obey. And if you’re a legitimate operator on a machine that’s secured, you can be misusing that authorized application in a way that could cause some serious damage.

So in these cases, we really have to turn to the network and to situational awareness to get a bigger picture of what’s going on.

It’s been my experience that any time you’re talking to the operation folks, the engineers in these environments, they always bring up the air gap. Is the air gap the unicorn of this space? Does it still exist?

[Laughs] Is the air gap a unicorn? The air gap did once exist. As we talked about in the previous podcast, the control system environment is built for reliabilities. It’s built to operate for spans of decades before things are changed. It’s an old system. These systems predate what we think of as modern networking. So in that instance, you had a man drop. You had to go into a little room. There was a security guard. You showed a badge. You had to physically enter that facility in order to affect the control system itself. So crossing this space of air was the required demarcation, and if you weren’t in, you couldn’t do anything.

Now things have changed. And ideally there’s still absolute separation from the control room and everywhere else, but the truth of the matter is that air is not an insulator against a cyber attack. Even if there really is no network connectivity, no physical enabling, cyber attacks can occur over wireless technologies. There’s still good old-fashioned “sneakernet.” There’s either malicious or unintentional misuse by an operator who does get in. So there are all sorts of ways for a cyber attack to cross that mythical air gap.

So obviously no, it’s not there anymore. And even if you think it’s there, it’s probably a sound best practice to assume that it isn’t and put network security controls in place to protect against that potential attack anyway. Better safe than sorry.

Fair enough. The more you dig into these environments, the more you see things are running over IP, either wired or wireless to your previous point’s point. We’re seeing cellular technology, certainly tons of dialup modems.

Windup radio.

[Laughs] Exactly, everything under the sun probably. So that brings us to this: What types of network security controls can’t be utilized here? 

There are quite a few. Actually, the closest thing to what I think people think of when they say “air gap” is probably what they call data diode or a singe directional gateway. And what this is, it’s basically a joke that it’s the world’s most expensive piece of broken fiber, because it’s a physical security layer that only allows traffic to move in one direction. So in that case when information is coming out of the control system into the business environment for good reasons, which by the way is why the air gap doesn’t work. It’s because we need to get that information from the real-time production environment to the business environment so that we can do real-time trading and have efficient business transactions and all that great stuff. When we open up that connection to bring data out, we open up the vector for a threat or an attack to go in.

So the physical data diode is a physical security that prevents that return traffic from happening, if you will. But it’s a pretty severe measure. Ideally we’d have these everywhere, but I think probably budgets, and deployments and arrows don’t allow that, so you have to look at what is available.

I think that the traditional stuff is a great start. A firewall is a perfectly good start. It’s going to give you a basic policy of what’s allowed in and out, which should be a very small amount of traffic. It should be a very locked down policy. So a firewall is at the top of all best practice recommendations by DHS, NIST and all of those groups for good reason.

But I would say it’s probably not good enough when you’re talking about a control system environment because again, these systems are command and control based and if you do get in, you can cause a lot trouble. The simple fact of life is that you can hack across a firewall. It’s been proven over and over again.

So something like an intruder prevention system is probably better, but there are some problems there as well. In most intruder prevention systems, they’re designed for high bandwidth networks. So they’re looking at the way an IPS works. It looks at traffic much like AV looks at a file and says, “I’m going to look for something I know is bad and if I see it, I’m going to block that traffic.”

So it operates on this, “I’m going to look at a lot of traffic. I’m going to apply a lot of rules to it to see if I can find something wrong.” That works great in an enterprise environment, but sometimes SCADA systems aren’t high bandwidth and they’re not letting a lot of traffic through, so the product requirements and the network environment don’t always line up.

The other thing is that the IP has to actually understand these protocols. These SCADA protocols are different from what we use in the typical corporate IT environment, so a lot of intrusion preparation management systems just don’t understand them. But ideally you put all of that together and you have a SCADA aware firewall or IPS that you would put at that perimeter because it will stop attacks from coming in for the most part.

It makes sense and seems like it’s a replication of what we’ve seen in IT enterprise, the unidirectional features, like those from Waterfall and their data diodes. Probably a little bit more unique, but we’ve certainly seen those in high security data centers as well, so that’s a great point you bring up.

Last question as we wrap up part one of Compensating Measures: How do you know if your network security control is actually working in these environments?

That’s another great question. The easy answer is you test it. But again, nothing is necessarily easy when you’re talking about a control system environment. This is a real time production environment, so you just can’t throw things in, test them and assume they work. Hopefully whoever is managing their control system has a replicated subset at least of that so they can do some testing. But really what you want to do is penetration testing, or at the very least, some surface venerability scans to see, first of all, if the devices you’re protecting have vulnerabilities. That’s key. If they do, you put an IPS, firewall or whatever in front of them, or you would deploy application whitelisting on the host itself.

A pen test against that will then determine if the venerability can be exploited. If it’s not actually exploitable, then you don’t really have a problem, so you’ve dodged a bullet. Managing and documenting that process is key, because the auditor is not going to take your word for it, NERC or whatever regulation that your control system is covered by. You say, “Oh yeah. I test it and it’s fine.” They’re going to want to see evidence of that.

So having some sort of an automated risk assessment or compliance tool can be really helpful for that reason as well.

Great real world information, Eric. Thanks so much for your time today. This was a lot of great detail. And for those of you who enjoyed this podcast on Compensating Measures, stay tuned for part two next week. 

Leave a Comment

three × two =