eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I’ve been bombarded with pitches and inquiries about whitelisting ever since I discussed the issue with Microsoft’s Mark Russinovich.
Russinovich, you will remember, thinks that current approaches to security are unsustainable and that the way out, the paradigm shift that takes the advantage back to IT from malicious actors, is whitelisting. I was sympathetic, but saw too many impediments to adoption and noted that the path to adoption was far more visible for enterprises, or for managed networks in general, than for consumers.
After talking to some readers and some vendors, I’m a little more hopeful about it, at least for enterprises. Nevertheless, there are some difficult challenges for anyone implementing a whitelisting system. There aren’t many companies writing software to allow enterprises to do this. eWEEK’s Cameron Sturdevant recently reviewed Bit9’s Parity 4.1 and thought highly of it. He also mentions CA’s Host-Based Intrusion Prevention System and Lumension’s Sanctuary Application Control. I spoke to CoreTrace about its Bouncer product and whitelisting in general.
My first impression when I think of how to implement whitelist systems is to take a known-clean system that IT just built from image and scan it. Whitelist everything from this system. That is your baseline. Image it and build new systems off of that.
I immediately see the problems in my notion, just as the vendors have. A large organization will have many such baselines in the form of different PC models. Even where the systems appear to be identical, two PCs from the same vendor may have small differences in chips and other devices, causing differences in the drivers used on the system, necessitating the creation of yet another baseline. It appears that vendors have chosen to take the alternative approach.
The alternative is to scan each and every system and identify all the programs on them. This could be done to existing in-the-field systems, but that’s a bad idea for reasons I’ll get to. More likely, IT will install the whitelisting agent and scan the system after all the other officially cool software has been installed.
According to our review, the Bit9 scan lets you go through everything it finds on the system. They have a huge database of checksums of the files they find so they will identify most everything and let you approve the rest manually. CoreTrace takes a different approach. They whitelist everything on the new PC. In both cases, what happens to new software on the system depends on policy, although the general idea is that new software will be blocked.
Scanning an Existing System
What if you scanned an existing in-use system? Basically, there could be malware in it. Identifying this malware as part of the scan would be difficult as compared to identifying it in the field as it enters the system. This is why it’s best to begin whitelisting with known-good systems. I may be misreading Bit9 in this regard; its system is designed to show any software that shouldn’t be there, but it still seems risky to me. Clearly CoreTrace’s system won’t work for in-the-field systems.
The two products handle software updaters differently as well. CoreTrace lets you designate specific sources, such as a network share or a management system such as Tivoli, as trusted. The idea is that you then turn off all other updaters, such as Windows Update and Acrobat and Firefox’s automatic self-update mechanisms, and push all updates through those trusted sources. They call this “Trusted Change.”
They also have a trusted user concept, where a user can make a decision to run an unapproved app after a prompt. This only works for digitally signed apps, but even so it’s still a risk. It’s up to you whether you want to implement such things. It may be necessary to give at least some users such power in order for a whitelisting system to be politically acceptable, but most users aren’t trustworthy.
There isn’t any reason why you need to do this all at once, though. You could start to introduce whitelisted systems and move others to it as they come in for service or on a longer schedule.
I mentioned in my Russinovich column that application exploits are a challenge for these products. Since an exploit of the application runs in the context of the application, a whitelisting system could easily miss it. CoreTrace deals with this by including stack overflow monitoring, but this covers only some of the ways exploits work. I’m not sure of the other products. I think this is something to worry about, but it’s not a deal-breaker. It’s not like existing anti-malware systems handle exploits well.
These systems aren’t all Windows-only, but clearly there are some platform issues. For instance, what about mobile devices they don’t support? The whitelist won’t be universal, but that’s no reason not to protect the mainstream systems. If malware gets around the whitelist that way it will only call more attention to those devices and the need to secure them somehow.
I have to say it’s all more encouraging that I thought it would be, and it is still in the early stage. Perhaps with some assistance from future versions of Windows, whitelisting could be more practical. We’d all better hope so.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack