Security Experts:

Searching for Silver Bullets In SCADA and ICS Environments

With Halloween past us, there’s an excess of sugar in our blood, and remnant imaginings of monsters under the bed. So perhaps that’s why when the topic of “silver bullet security” recently came up, my mind immediately went to Werewolves. The term was used, as it often is, in a discussion about Application Whitelisting—the industrial automation industry’s rightful poster child for endpoint security.

Silver Bullet

Application Whitelisting, for those unfamiliar with the technology, works opposite of the traditional paradigm used by Anti Virus, Intrusion Prevention (IPS), and almost every other type of network and endpoint security. Rather than relying upon a list of what is known to be “bad,” whitelisting defines the few things that are known to be “good,” and everything else is blocked by default. While this can be challenging in an Enterprise—where the computing culture is dynamic—in an industrial control system it is the answer to our collective prayers: there’s no need to patch, update large virus libraries, and there’s almost no drain on CPU and memory (an important consideration in the older, more sensitive systems used in a control room). It is, basically, a silver bullet. 

But wait! There’s no such thing as a silver bullet! At this point, many of you have stopped reading and have started fanning the flames in my direction. To this I say you have the wrong monster; fire is for witches, silver bullets are for werewolves. If we really think about it, the analogy of application whitelisting being silver bullet holds up to scrutiny. Just like a silver bullet, application whitelisting works perfectly against its nemesis, which is unauthorized application use. That doesn’t mean it will stop everything, but it means it will do a very effective job stopping what it’s intending to stop: anything except those few applications that are allowed. By doing so, it stops malware (assuming you haven’t whitelisted your malware), but it does not stop the misuse of an authorized application, does it? Of course not, there are other bullets, made of other metals, to protect against misuse. It’s not an issue of whether or not whitelisting is a silver bullet; it’s an issue of what being a silver means.

So in belated celebration of All Hallows Eve, we need to remember that silver bullets are intended for Werewolves, but there are plenty of other monsters out there. Silver bullets aren’t effective at all against other evil denizens of mythology, such as zombies, and it’s questionable if they’d work against larger threats, like ogres or dragons. And anyone who has seen any horror movie, ever, knows that being armed doesn’t make one safe. If its not used properly, your silver bullet won’t even stop those pesky werewolves. You still need to actually shoot the werewolf; you can’t simply buy bullets and keep them in your pocket (the most you could hope is that you might give the creature some indigestion after it’s eaten you).

There’s a great demonstration that’s been shown around the industry by Intel, where exploits are attempted against both vulnerable and invulnerable controllers. In this demonstration, both targets are whitelisted—only one of them is whitelisted poorly, and therefore “allows” malicious payloads to be dropped onto that “protected” host, and subsequently allows the controller to be remotely manipulated by a hacker.

So let’s stop saying “there’s no such thing as a silver bullet” and lets start talking about what the best ammunition might be against the specific threats that we’re trying to remediate. 

Are you most concerned with inbound network exploits? Then implement a unidirectional network gateway (i.e., a “data diode”), which is an absolute remedy against inbound network threats. It won’t stop someone from hand-carrying malware across the security perimeter, though: for that you need a different weapon, capable of stopping the misuse of removable media (perhaps a system to securing data access on a host, or careful configuration control to disallow autorun, or combinations of these and other remediations).

If you don’t have the correct ammunition to stop a particular threat, and you lack the budget to acquire it, it doesn’t mean there’s no hope at all. You can still drop a zombie with a silver bullet if you hit it in the head. If you’re not up against superman, that kryptonite might not have any affect at all. But whatever you’re up against in the cyber world—an evil wizard, a mad robot, or an army of mutant ninjas—our own history shows us that almost anything is dangerous when a large enough piece of it is launched by a catapult or trebuchet. Kryptonite might not cripple some of our more earthly creatures, but it’s still (assumedly) heavy. In cyber security terms, maybe being a bit more heavy-handed with access controls, network inspection, and other common countermeasures might also be a good idea.

If you’re using whitelisting (which I recommend doing in SCADA and ICS environments), don’t get complacent and assume you’re safe just because you have a silver bullet. It’s common sense; the re-thinking of a tired idiom; and classic defense in depth: use the right tool for the job. Because there are certainties in the world of cyber security, but there are also lots and lots of monsters.

Subscribe to the SecurityWeek Email Briefing
view counter
Eric D. Knapp (@ericdknapp) is a recognized expert in industrial control systems cyber security, and continues to drive the adoption of new security technology in order to promote safer and more reliable automation infrastructures. Eric is currently the Director of Cyber Security Solutions and Technology for Honeywell, and is the Chief Technical Advisor, North America for the Industrial Cybersecurity Center. He is also the author of “Industrial Network Security: Securing Critical Infrastructure Networks for Smart Grid, SCADA and Other Industrial Control Systems.” His new book, “Applied Cyber Security for Smart Grids” was co-authored with Raj Samani, McAfee CTO EMEA. The opinions expressed here represent Eric's own and are not those of his employer.