What did the Infoworld survey on whitelisting not cover?

The InfoWorld (IW) survey methodology was to see a demo of the product conducted by each company via webex and interview with the company over the phone. While we appreciate the opportunity to participate in the survey the methodology limited what was considered for the survey.

There were three important aspects that were not covered:

1.    Security offered by the solution
2.    Security of the cloud offering
3.    Deployment & Management versus Demoability

Let us examine these one by one.

Security offered by the solution
First lets explore how easy is the solution to bypass? For example,
•    take Bit9 which does not offer memory protection, which means that a simple buffer overflow exploit will bypass the whitelisting solution.
•    Or take script authentication, i.e. ability to whitelist scripts and java etc. If a solution does not offer this you can run a script on the system and completely bypass the protection?
•    Or take protection of kernel components? If the solution does not whitelist kernel drivers and components you can bypass the solution by simply inserting a driver into the system
•    Can executables be whitelisted from a network share (required for most Windows Active Directory based deployments)?

Whitelisting is fundamentally different than black listing, in the sense that the whitelist needs to be complete for the system to function. Thus if you don’t have coverage for a particular type of executable the solution is easily compromised. While the report mentions that MFE application control is the only solution which offers scripting and buffer overflow protection, it fails to highlight: Coverage is not a feature it is important for security!

The other aspect which was not covered by the survey was self-integrity or protection of the system itself. If the solution becomes popular how well does it withstand against targeted attacks on itself. Can ill-intended administrators bypass the system?

As several of our customers have figured out for themselves the protection from our competitors is easily bypassed.

Security of the Cloud Offering
The assumption behind the report and several other reports is: “If its in the Bit9 cloud its good”. There are several things to point out here:

•    Cloud can only cover off the shelf binaries (script coverage is very sketchy). They don’t cover any custom software which is a large part of most enterprises

•    Secondly, by shifting the problem to the cloud, one has to ask the question how is the cloud info constructed and how safe is it to poisoning.

As discussed in the previous section most of these solutions don’t cover scripts so the cloud offerings are only for binaries and that too only for off the shelf binaries.

Let us focus on the second aspect. How secure is the cloud? Take Bit9 for example, they claim to have 7.5B files in the cloud. Who checked that these are from valid sources? Most of these are collected by crawling the web? If its on CNET it is secure? If it’s on download.com is it secure? Who checks whether its secure? Has this function been outsourced to a country in Eastern Europe or Asia?  7.5B files were verified?

Niel McDonald’s @ Gartner has an interesting blog article and discussion about the same http://blogs.gartner.com/neil_macdonald/2009/03/31/will-whitelisting-eliminate-the-need-for-antivirus/

If you look at MFE cloud technology, it has several dimensions along with the analysis is done. In addition it directly talks to publishers to ensure that the quality of data in the cloud is pristine. Most small vendors like Bit9, just don’t see enough data: domain registrations, spam addresses, firewall rules, endpoint’s pinging back, site advisor to have enough dimensions to correlate and produce high quality data.

The MFE Application Control will be integrated to the MFE Cloud. This was already demonstrated at FOCUS ’09 and is on the short term roadmap.

Deployment and Manageability vs Demoability

As with most lab surveys, this one does not cover the manageability and deploy-ability of the solution:
•    Can it scale to 100,000’s of desktops/servers

•    What are the breakage/failure rates

•    How much does it cost to operate and maintain

Can it scale to hundred’s of thousands of desktops? Most people who are familiar with EPO will understand that deploying at those scales is a very different ball game. You can’t keep 100,000 TCP connections open to your management sever, most boxes will die at 4000 open TCP connections. You have to deal with reporting and event-flood at that scale.

MFE Application Control is fully integrated into EPO and that is a BIG win. It uses the EPO plumbing to achieve scalability. The management architectures of the competitors architecturally will fail to scale to such numbers.

At one point in the report there is a mention of the memory protection provided by CoreTrace. Again memory protection is an interesting concept, for most solutions out require tuning to make it work. So question to ask is what % of your systems will it work? And the feature of killing running process if a buffer overflow is detected is it a good looking demo? But what are the failure rates: false positives and negatives?

How much does it cost to operated and maintain? Whitelisting is not a new concept. The problem has always been of management of the whitelist. MFE Application Control has a lot of investment and features which dramatically reduce this cost and make it a viable solution for enterprises.

Summary

The InfoWorld survey has evaluated some aspects of solutions, but in my opinion has not covered 3 very important topics: How secure is the solution?; How secure is the cloud?; and Deploy-ability of the solution?

These are top of mind for every customer and should be included in any evaluation or comparison. As we have demonstrated several times in the field, MFE Application Control stands out as #1 as a deployable high security solution.

Coretrace announces Bouncer 5.0

here is the announcement from coretrace.  They seem to have added support for whitelisting of activeX.  It is great to see vendors in this space begining to worry about things other than pure binaries. Just FYI Solidcore (McAfee AWL) has had support for this for some time.  The tough issue here is a lot of download/upload clients in the browser are done via ActiveX. So you have an ActiveX component that is signed, it downloads a driver update, should the driver be allowed to run?

INTRODUCING BOUNCER 5.0 Award-Winning Application Whitelisting Solution Extends Memory Protection & Enables ActiveX Whitelisting

CoreTrace continues to redefine the antivirus and configuration control markets with the release of BOUNCER 5.0 featuring: * An industry-first ability to seamlessly allow and whitelist trusted ActiveX installations * Improved memory protection * Automated and streamlined deployments * Efficient management capabilities like group security configurations BOUNCER 5.0 is the only application whitelisting solution that simultaneously stops even the most sophisticated malware attacks while allowing users to safely install new applications and have them automatically added to the whitelist without requiring IT involvement. No other solution on the market today is capable of automatically installing ActiveX signed by Trusted Digital Signatures. BOUNCER 5.0 is also outfitted with enhancements to CoreTrace’s leading memory protection capabilities. In addition to preventing the execution of payloads deposited via a memory exploit, BOUNCER 5.0 addresses major classes of exploits directly, such as DLL injections and attempts to write to kernel-memory.

Challenges with Traditional White Listing

White Listing is not a new concept. It has been around for a long time and refers to the ability to run only a known white list of “good” programs on a device. Traditionally the security solutions such as anti-virus have focused on the black list concept where they look for known “bad” stuff. A big part of the both a white list and a black list approach is that the lists need to be constantly updated. We have all experienced this with our anti-virus solutions which download updates and signatures of newly discovered malware to add the black list.

White listing has not been widely adopted because of the difficulty in creating a white list. If you fail to enumerate all the “good” software in the white-list the device may fail to function. Note this is different than a black-list as in a black-list if you omit something, the device will still function but some malware may run. Given that the white-list has to be complete poses a big challenge as the machine is updated. Every time the machine is updated the list needs to be updated.

The most recent approaches for white-listing include repositories of known good software collected either by the US Department of Defence (http://www.nsrl.nist.gov/ ),  or from the National Drug Information Center (http://en.wikipedia.org/wiki/HashKeeper/). These have formed the basis for white-listing approaches provided by companies such as Bit9 etc. It is very difficult to lock down a machine based on these white-lists as they are not complete. The best you can do is use them to report programs which are running but not in the “known” list. In addition just because something is in a global whitelist does not mean that it should be allowed to run in your enterprise.

Most vendors punt on this problem by creating a “gray” list. What ends up happening is that the gray list grows over time and essentially the system is not secure.  Another manifestation of both the issues highlighted above is think about a program which is in the whitelist and it gets updated: what should happen? should the updated program be allowed to run? Solutions like Bit9 and others don’t maintain integrity of the machine, for example write protect the binaries in the whitelist, so a malware can overwrite these binaries and either cause a denial of service attack (system won’t boot) or the whitelisting software will quitely push the binary into the gray list and voila the system will run but compromised. (Note: some vendors may say you can set up write protection file by file, but this is useless as no-one is going to do this manually and unless it is integrated and automatic with the whitelist it is not effective)

Another challenge with solutions like Bit9 is that they don’t protect the integrity of the running program. So if a whitelisted program is running and is compromised (buffer overflow), not only can the “external code run” but it can also make changes. Any whitelisting solution without system integrity (on-disk & in memory) is not a good security solution.

The other dimension that all whitelisting vendors today (except solidcore & now MFE) ignore is what to do with scripts, java  etc. Bit9, Symantec etc  only tend to cover OS images or application binaries. It is outside the scope of most of these solution to cover custom applications or to cover applications that are written in languages such as Java (several POS applications tend to be Java based). So you can use whitelisting from Bit9, but it can be bypassed by writing a Java application or a vbscript?  For most enterprise desktops again this is not a viable solution. The breadth of the solution is not a nicety, its a necessity.

Continuing along the same theme: Bit9 or Symantec don’t provide whitelisting of kernel mode components. Thus you can add a device driver to the kernel or something during bootup.  This is something that is architecturally very difficult and is not something that can be retro-fitted in.

To summarize, does your whitelisting solution breadth (scripts, binaries, libraries), does it lead to a large gray list, if it works of a global list: how good is the list, which country is it compiled in, if its good in the list should you run it?, does the whitelisting solution guarantee system integrity (on-disk and in memory)?Does the whitelisting cover kernel components?

In the next part we will look at a more technical view of how you need to carefully assess how the solution is built and how easy is to bypass?