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.

AppLocker and App-V

Interesting article on brianmadden.com regarding using applocker as a licence enforcement mechanism.

http://www.brianmadden.com/blogs/timmangan/archive/2009/10/29/AppV-and-AppLocker.aspx

App-v and other technologies like it create breakage. The question is how much breakage and how easy it is to fix. The answers to those questions determines whether it is a dev tool for developers, something that consulting houses can do or an IT admin can do.

What has this got to do with security you ask? Well the answer to that question determines how much lockdown you can do with applocker.

If there is a lot of downstream cusatomization, it becomesd hard to use app-locker. The challenge in whitelisting is not the enforcement mechanism, but the configuration of the white-list: its coverage and maintenance.

Over the years the wrapping of apps by app-v has improved. There is betterr handling of things like winzip (which broke because it registered a shell extension) or apps which required a service. But still in general apps which have multiple processes communicating with each other and/or a service are very challenging.

Citrix has had this problem for a long time also. So if you are a developer of the app you can fix this, but to do it in the field and for complex applications not only is tough but also complex. Then to make a whitelist for it is challenging.

Another difference between whitelisting for security versus licencing is that for security the whiterlisting need to be complete. Imagine you missed some drivers from the whitelist, your machine won’t even boot.

But for licensing you are using the WL as an access control mechanism, very different. For example you can say that WL is applicable only to app-v apps, that’s not security but licensing.

We should keep the two separate.