Why haven't organizations moved away from a "let everything in" model and embraced application whitelisting and execution control? Marcus Ranum talks with mobile security veteran Aaron Turner about the evolution of software restriction policies, from the early initiatives when he worked as a security strategist at Microsoft to the Apple model that is proving effective today.
An entrepreneur, who has launched several security technology companies, Turner is founder and CEO of IntegriCell, an enterprise mobile risk management consultancy. He was formerly head of RFinity, a mobile security startup spun out of the U.S. Department of Energy's Idaho National Laboratory.
Marcus Ranum: I'd like to talk about a topic you and I have been over, off and on, for the last decade or so. Back in 2007, I wrote a piece in which I said I thought application whitelisting was the only effective answer to software security, and I've debated the issue with Bruce Schneier a couple of times. Now we are seeing that malware appears to remain unstoppable, but nobody's willing to switch to a whitelisting model; and, collectively, the world's runtime remains out of control. Why is this happening?
Aaron Turner: At Microsoft, I had the opportunity to interact with some very smart people who helped design the process for signing the Windows device driver and its implementation. They used PKI (public key infrastructure), and I think its 15-plus years of relative success is a pretty good track record as that approach has been implemented since the days of Windows NT and 9x (Windows 95, 98 and Me).
When we were first working on the security requirements for Windows 2000, we wanted to extend that approach to allow enterprises to restrict code execution. So another group of really smart people implemented the first versions of software restriction policies (SRP), which would allow enterprises to restrict what code runs based upon settings like code signing, execution source location and checksum verification.
If they can create virtualized application run-time environments that can essentially off-load whitelisting to a virtualized system, there is real potential for success in that model.
Aaron Turner, founder and CEO, IntegriCell
As one of the few security evangelists within Microsoft, I had very high hopes for SRP. When Windows 2000 released and I worked with many security-conscious organizations to test SRP, it became very apparent that the complexities of running thousands of different applications in the standard enterprise environment introduced so many operational variables that SRP just wasn't something that was realistic to deploy.
The main problem with SRP wasn't that you could restrict which executables could run—it was figuring out which executables you actually wanted to run. The enterprises I worked with had a hard enough time managing which version of Windows they were using, let alone which versions of applications they had installed. And each time an application would get patched, it would impact the SRP process. Most enterprises did not have code-signing capabilities, so they would ask the software providers to sign their code, which resulted in lots of questions from software developers because they didn't know how to do that. Then there was the whole software-update process for applications deployed by enterprises ... Lots of headaches and just not enough focus on solving those problems resulted in very few organizations ever using SRP to its full potential.
A startup called Bit9 worked to make restricted code execution easier for enterprises by providing a set of value-added services on top of Microsoft's SRP. It worked with a host of software developers to document what ‘good' software looked like—creating checksums for known-good executables—and then published a service. Bit9 ended up with a black eye when the service was used as the delivery mechanism for advanced-persistent-threat-associated malware, so it may not be the best example here, but it did serve as a significant market-maker for the expanded use of code-execution-restriction technologies.
Ranum: Application whitelisting seems so obvious, but why isn't anyone doing it?
Turner: Let's fast forward nearly 15 years since the early days of Windows 2000 SRP work to today. The introduction of the latest mobile-platform operating systems has resulted in probably the largest-scale deployments of restricted code execution. The biggest leap forward in this space resulted from Apple's iOS. By restricting what code could run on iPhones, iPods and iPads; Apple created an ecosystem of systems, which had code signing at its very core.
Many users thought this approach was too restrictive, which resulted in the jailbreak community's efforts to deprecate the code-signing requirements. Apple has responded to the jailbreakers' efforts with incremental improvements over the last five years, to the point where the vast majority of iOS devices only run signed code. Android and Windows RT have followed iOS's lead, but they don't have the same sort of signed code lock-in that Apple does.
Apple believes in this approach so much that it has decided to implement it on its OS X systems. Beginning with version 10.8 (Mountain Lion), code signing is turned on by default—and is kind of hard to turn off—requiring that all software be downloaded through the OS X App Store.
The bottom line is technology that was originally deployed in the Windows 2000 era for enterprises never really took hold in the enterprise world. It took a consumer technology company like Apple to drive the largest deployment of SRP, and it doesn't look like that will change anytime soon. I think that's good news for the average end user, but it still begs the question: Why aren't enterprises moving in this direction as well? The answer to that is they just don't have the software discipline to do so.
Ranum: When I talk with executives about this, they often reply that application whitelisting is off their radar screen because managing their runtime environment is going to be too onerous and complicated. It just won't work. That's usually my cue to ask them, ‘Do you own an iPhone?' Then I point out that choosing apps from a pre-approved app store is whitelisting. If it's so onerous and complicated, how come the App Store model has been so successful? Obviously, there are questions about corrupting the App Store's contents, but that's a different level entirely. It seems like a good starting point to me, right?
Turner: Exactly right. It just comes down to discipline, but it is completely limited by what technology businesses have deployed in the real world. If enterprises had greenfield deployments, with completely consistent technology-platform configurations, this would not be an issue. Unfortunately, large enterprises have such a mix of legacy systems that there is no way for them to implement whitelisting on a universal basis.
Thinking creatively, I think this is where virtual application technologies like Invincea and Bromium can excel. If they can create virtualized application run-time environments that can essentially off-load whitelisting to a virtualized system, there is real potential for success in that model. It seems kind of ironic that we've had to wait 15 years for virtualization to hit its stride to the point where it can help us with whitelisting. It still won't be a perfect solution, but it's definitely a step forward.
Ranum: How does the development of nation-state-sponsored malware play into the whitelist conversation?
Turner: Unfortunately, we've already seen nation-state actors target a whitelisting technology company—Bit9—to accomplish their objectives. The recent disclosure of the National Security Agency's DROPOUT JEEP program, which granted NSA root access to all iOS platforms, is another example of how whitelisting just doesn't do much to protect anyone from a dedicated nation-state cyberattack program. I think that whitelisting is a great security control to prevent significant amounts of malware from executing on certain computing platforms. But, as with anything, whitelisting capabilities as they are available in the market today are susceptible to well-organized and well-funded attacks. So, it's not a silver bullet, but it is definitely a useful tool that is the next logical step above and beyond signature-based anti-virus software.
Ranum: You say that enterprises just don't have the software discipline to move toward controlling their runtime environment, and I agree with you. But what I don't understand is why they think that managing a runtime environment is somehow harder than having to constantly clean malware out of an unmanaged runtime environment? I know this would mean someone has to actually decide who could run what, but why are constant malware cleanups and incident responses considered cheaper?
Turner: If enterprises had the discipline to track the actual amount of time, effort and resources that they spent on cleanups and incidents, then I think you'd have a point. Unfortunately, even the most mature organizations have drawn the line at actually tracking those costs at a micro level. So, if we had perfect knowledge of just how bad the malware problem was—the actual level of infection and compromise—then I think there would be better motivation to move toward whitelisting.
Ranum: In principle, an entire enterprise's runtime could be managed from a single console (app store), where they decided what software providers were trusted and, if necessary, specific applications at group levels. I'm guessing that a lot of enterprises could get by with ‘permit from Microsoft, Apple, Oracle, +Apache OpenOffice, +Google Chrome, +Mozilla Firefox. ‘Whenever I get into this topic, I think about my software mix; and really, it's pretty small.
But here's the question I love to ask IT executives when they say that managing the runtime is too much work: Presumably, you know at a corporate level why a particular employee was hired? It shouldn't be hard to say, ‘People we hired as software engineers should be doing software engineer-y stuff.'
Turner: Well, most of the time, software engineers at enterprises are hired to move from one project to another at a pace in which none of the projects is actually finished or managed well over time. The treadmill of innovation at most large organizations prevents them from ‘ perfecting' software. Also, the millstone of legacy hardware and software is so large that most technology teams are running within an inherently conflicted environment.
I am probably in the minority in this view, but I'd see an EMP (electromagnetic pulse) as a massive greenfield event; getting rid of the millstone of legacy hardware and software could be one of the best things ever for the technology industry. Yes, there'd be plenty of chaos to go along with that, but it would alleviate a significant burden from technology teams when it comes to maintaining out-of-date systems.
Back to reality. We may be facing a very ironic situation in that smart devices and modern mobile operating systems may provide our best opportunity to move to a locked-down runtime environment. I was recently talking with some folks from App47, a mobile-enterprise app store provider, about their view of the world. They see the advent of iOS and Android ubiquity as a second chance to do software much better than before; hope springs eternal in the technology industry.
Ranum: Honestly, do you think it's just fear of conflict? It's so much easier to keep cleaning up the malware and losing the customer databases, and so forth, than to confront your co-worker down the hall and explain that the corporate computer is not there for them to just do random Internet stuff on.
Turner: I think it's the lack of consequences. Take T.J. Maxx, Target, Neiman Marcus or any of the other headline-grabbing data loss incidents. What has been the real-world, bottom-line impact of those situations? All of those folks are still in business.
I was talking with someone who had insight into the Lockheed Martin intrusion, and the loss of weapons system designs will have an effect on the military-industrial complex. That impact won't be measured in years but in decades. On that time scale, maintaining the highest levels of operational maturity in an organization's runtime environment just doesn't merit investment. We'll do what we do best ... procrastinate and let someone else solve the problem years from now.
About the author:
Marcus J. Ranum, chief security officer of Tenable Security Inc., is a world-renowned expert on security system design and implementation. He is the inventor of the first commercial bastion-host firewall.