Host Security for SCADA and ICS Systems Part 2

Today’s discussion is part two in our series on critical infrastructure with Eric Knapp, Director of Critical Infrastructure Markets in McAfee’s global business development group. If you haven’t yet listened to or read part one, you might want to stop at this point and view that podcast here, or read the full transcript here in the Security Connected blog.

Eric, in our last conversation, we discussed a number of things about securing legacy systems, and issues as they relate to patching, and we just very briefly talked about application control. How does this really differ from traditional antivirus, and can you tell me a little bit more about how this works for these particular systems?

At a very fundamental level, application control, also called application whitelisting, is really like the polar opposite of what you think of as traditional antivirus, which is a blacklisting system. Because of this fundamental difference, it’ll be obvious why whitelisting is a more suitable host security option for a very closed system. With antivirus, if you continuously update the system, it’s always going out and downloading updates to its library, getting data files with all the latest malware definitions that have been determined by organizations like McAfee.

Because of that, there are a few qualities of antivirus systems that are important. One is that the footprint of the antivirus system tends to be a bit large, and there’s a processor and memory requirement for the analysis of files as they’re being scanned. Now, imagine if you take that and put it in an environment that has no Internet access, and you put a system like that on an asset that has very low computing capabilities. In terms of what we’re used to in a desktop or a laptop computer, these legacy systems may have a minute amount of MIPS, memory, and everything else. From that standpoint, antivirus starts to look a little suboptimal.

What whitelisting does is rather than tell you what’s bad and looking for instances of the bad things, it has a definition of known good things. You configure it once. You say, “These are the operations that are allowed to run. Anything else is stopped.”

It’s kernel level interrupted, stopping that executable from hitting the processor and actually executing. This is good for a lot of reasons. One, the definitions don’t change. They only change when the applications that you are allowing are actually changing, so there are no patching requirements. There’s also a very small footprint and a variable memory requirement, so you can deploy whitelisting on embedded controllers. You can deploy them on VxWorks systems. You can put whitelisting in a lot of places antivirus would have a harder time going.

You know, I recently read this article about cellular technology and SMS messaging that’s being used for some of these systems. They’re talking about how they have to be clear text, because the MIPS and the other essential hardware capabilities of the machine were not capable of supporting heavy-duty encryption. It’s stuff we probably take for granted on our common desktop or laptop, or sometimes even mobile phone.

Can we expect in these real-time networking environments for administrators to take the steps necessary up front to leverage these dynamic whitelist capabilities?

That’s a great point, and I would argue that it makes sense to take that step, even outside a control system environment in a corporate situation. Obviously, as you get into a dynamic work environment like the enterprise, there is a lot of work involved, because there is a lot happening. I know that on my laptop, I’m downloading things and performing different tasks on that machine all the time. I probably have a few hundred different applications or subsets of applications on there, so that could be a lot of work. But the real synergy in a control system environment is the average controller, whether it’s a SCADA server, a PLC, or whatever else is in this environment. It shouldn’t be a dynamic system; it should be very well defined.

Only well defined, explicitly authorized applications should ever be running on these systems. So that risk, of there being a lot of things you have to take consideration for up front, really isn’t there. There are no exceptions in these environments, therefore there are also no false positives – or I should say there should be no exceptions. Nobody should be playing solitaire. If a legitimate change is made, that’s when the whitelisting system has to be adapted to accommodate that change. In a control system environment, that’s regulated already. There will be a formal change process that accompanies that change, and you simply have to add the updating of the white list to become a part of that process.

In these environment, how difficult, or maybe I should say how easy is it for some kind of rogue application, either a piece of malware or maybe just unauthorized software, to end up on one of these devices? Is it a fairly unique instance, or is it something that could happen just as easily as somebody getting malware or installing unauthorized software on his or her desktop?

That’s going to vary a lot based on the specific device you’re talking about. But we’ll look at controllers and SCADA management systems. They tend to have more capability. They’re more in line with what we think of as an enterprise-computing platform. A SCADA management system is probably a Windows system running Windows 7, or more likely an older version of Windows. So, the chance of malware getting into those systems is actually very realistic. It can get there in a couple of ways. It can get there over the network, or it can get there just by accident. For example, an operator can come into a control room, plug his or her iPhone into a USB port to charge it, and the next thing you know, malware has potentially gotten into that system.

So, rogue applications can certainly happen. Again, if there’s a whitelisting on, they won’t execute. The great thing is that we’re not only stopping that malware or rogue app, but we’re also identifying its presence. So the application control agent will say, “This is not authorized, I’m going to stop it.” It’s also reporting the issue up to a central auditing facility, centralized policy management, or security information management.

This gives us a greater awareness that there’s a bad application out there. It might be benign, but it might be malware that came in from the corporate IT side, where perhaps whitelisting isn’t deployed. We now know what it is. We know what to look for, and we can push the correct policies into that environment to help stop it there.

That’s fantastic information, Eric. You really outlined the reality of leveraging dynamic whitelisting in these environments. Eric, as always, thanks for your time.

Great, Brian, thanks again. I look forward to the next one.

Tags: critical infrastructure, SCADA