You ask “Why shouldn’t/doesn’t the platform have implicit ability to ask “should I run this code or not?”

Yup. Completely agree. Microsoft is adding this to Windows 7 with a feature called “AppLocker” (think software restriction policies 2.0). Many mobile devices have this capability. The browser is another platform and it should also have this capability. Ditto for SOA, scripting, etc etc – *any* IT platform should have basic whitelisting enforcement capabilities built in, including emerging x86 virtualization platforms.

I didn’t mean to avoid the social, cultural and usability question that you raised in the thread.

I agree with you that there are some really tricky issues here with any kind of active filtering – white or blacklist. It is clear that there has routinely, it seems, been a one for one trade-off between risk and usability. We believe that whitelist presents an opportunity to change this for the better.

At the end of the day it is really about managing the signal-to-noise ratio. In the case of platform management – we need to pump up the signal and dampen the noise. The question is how.

Noise comes from many sources – but largely from ambiguous data validation – whether or not it is the attempt to filter “bad” or undesired code or the process of creating “allow lists” for trusted code. Once we have precisely detected what we want/don’t want – then we can employ policy to effect the decisions. Policy must be “quieter” with its decisions in order to meet the goal of better user experience.

The the extent the data sources used for positive and negative filtering is more accurate, we should be able to create better policies leading to enhanced user experience.

I would also add here that there is the question of whether “third-party” agents are (in the long-term) the best way to handle active filtering and policy. Shouldn’t more of the safety and user-experience method be built into the platform? It is in the physical world – why not in cyber?

I would offer that as we make the transition to drive new benefit from whitelists, we close large blindspots in our platform awareness. I also believe we should revist the question of “do we really to add yet another agent to the compute platform to get the full benefit of whitelisting?”

Why shouldn’t/doesn’t the platform have implicit ability to ask “should I run this code or not?” — I think it should.

Effectively implemented platform instrumentation coupled with known-provenance, high-value software measurements should improve all of the major feature metrics (security, compliance, better opex, lifecycle stability) all while reducing the load on users to make manual policy decisions, or worse yet – to be “locked down” because we’re “not sure” we are making good measurements and policy decisions.

IMHO, yet another reason to get the platform vendors and ISV’s onboard.

Wyatt.

Actually, our buffer overflow protection isn’t blacklisting derived. It uses the same list of what is trusted on the system to see if we should trust the source of the buffer overflow or dll injection attempt – since there actually can be valid reasons for both – but you want to make sure that anything coming in to memory did so only from executables that would have been allowed to run from disk.

I think that the responses have been primarily from whitelisting-related vendors because most of us feel rather strongly that, designed properly, whitelisting _can_ secure systems by itself far better than blacklisting, and in fact largely nullifies the need for “classic” blacklist-based approaches. Blacklist vendors probably wouldn’t be inclined to comment due to the fact that you are questioning their very existence by this post.

I’m not trivializing the browser as a platform, or at least I’m not intending to. Today, we block any executable content – whether it’s an OCX or a BHO, or any other type of executable. That’s the rub. For an upcoming release, we are encompassing the browser as a mechanism of Trusted Change, so within the scope your IT group deems it acceptable on the whitelist, new ActiveX content can be downloaded using IE’s Install On Demand (IOD) functionality without the user knowing any differently. Thus keeping them secure, yet not getting in the way of workflow when they need to download a new OCX for GoToMeeting, LiveMeeting, etc.

I think you’ve brought up an important point, Neil. Protecting “from the cloud/in the cloud” is important; but it’s also important to bear in mind that the exploits occurring at that level are fundamentally different. Today’s Windows exploits exist both to compromise systems in order to create a botnet, steal data, create an extortion target, etc. Largely, to (literally) take advantage of the resources on/of that computer.

The security of an “application”, or frankly any data “in the cloud” is a fundamental problem that more and more of us are going to have to start thinking about as critical information begins to seep out onto the Internet whether you want it to or not. But that seepage occurs at layers 1-7 in the OSI model – so approaches to securing against exploits that are “cloud-flavored” is literally a world apart from securing the resources of an enterprise. For organizations wise enough to avoid cloudifying critical data until they can be sure it comes closer to being STRIDE-proofed ( http://blogs.msdn.com/larryosterman/archive/2007/09/04/threat-modeling-again-stride.aspx), the combination of whitelisting, DLP, and FVE does a good job of truly securing _their_ systems, _their_ data, and _their_ local network resources. Arguably, securing your information while on Gmail is both your responsibility as well as Google’s. Thus my personal belief that any organization that outsources critical IT resources to the cloud without seeing the full security model that backs up the talk is making a _very_ poor decision – but that’s another discussion for another day.

I couldn’t agree more with your second comment. In fact my comment to your next blog post mirrors that exact sentiment. Blacklisting got where it is today by being “good enough”. Well, it isn’t anymore, and that’s why we’ve built what we built – a whitelisting approach that does everything it can to approach zero friction from both a systems management and from a daily user perspective. Letting employees do what they need to do – within IT defined guidelines (see my comment on the next blog post for more).

Rishi, yes -embedded systems and servers that don’t change often are excellent candidates for a whitelisting approach supplemented with memory protection for a variety of reasons which I discuss in the research. Full disclosure – Solidcore has a form of whitelisting protection technology.

Wes, don’t underestimate the importance of the browser as a platform. It is not a trivial issue to support the whitelisting and blacklisting of plugins and BHOs in a way that is meaningful to the end user.

Two more quick comments
1) Web 2.0 applications and “cloud-based” applications are a challenge. They don’t execute in ways that traditional application control products can exert policy control. I mentioned Javascript above (the “J” in AJAX Web 2.0 applications) but don’t overlook that a company might want to restrict access to, for example, social networking sites, Gmail (or any of the hundreds of cloud-based application services where the code executes on their machines, not yours)

2) Notice how the issues of the political, cultural and process challenges were pretty much ignored in this stream of comments. We’ve also written quite a bit of research here advising clients on how to manage a transition to a whitelist-based model. If you are moving from an environment where end-users can do anything to an environment where they can only do what has been whitelisted for them, you will almost certainly encounter issues. In most organizations I talk with, employees want more freedom to innovate, not less. IT can become too heavy-handed with whitelisting policy in the name of security and risk interfering with the legitimate work of employees. Not a good idea.

Back to what I said in the post: Don’t get me wrong. Whitelisting is foundational. It will become increasingly important for endpoint protection. I wouldn’t buy an endpoint protection platform solution that didn’t offer this capability. Just don’t expect a silver bullet.

Rishi’s post echoes the sentiment we feel as well. In general, I agree with your reply, Neil – which is why we have built the product we did. To specifically answer how we think those questions are answered, see the following:

1) Agree, to a point – we completely control what _executable_code_ runs on a system (as any comprehensive whitelisting solution should, or it is ineffective), whether it is an ActiveX control or a Browser Helper Object. Yes – for browsers that have a JavaScript-based extensibility model, we don’t protect against new plug-ins for it – however that is not executable code, and generally does not have access to OS resources. Indeed, if it does attempt to, it will either need to exploit a buffer overflow (see 2, below) or drop new executable code down on the system – showing the exact benefit that ONLY whitelisting can provide. In such a scenario, with custom-crafted or zero-day exploits (as occurred with the C-level exploits that occurred last year) the systems are now owned if you are only protecting them with blacklist-based software.

As to macros, Microsoft years ago deferred to a “default to off” model in Office WRT macros, only letting digitally signed macros run. As a result, macros have today been cordoned off to almost a non-existent security threat, unless a customer chooses to _explicitly_ not follow Microsoft’s security best practices.

Almost all other browser-borne exploits such as those carried through Flash use a buffer overflow – the most common way to infect a Windows system without using on-disk code – to do so (see http://www.google.com/search?q=Flash+buffer+overflow for an impressive collection of URL’s). Thus, see point 2.

2) Absolutely. A whitelist solution is only as good as it can protect up the stack. If you only let on-disk code you know run, great. But yes, you are still vulnerable to memory-borne exploits. Which is why we have spent a considerable amount of time building memory protection, as any comprehensive whitelisting product should. To be clear, most blacklisting applications _dont_ include comprehensive memory protection. In fact, we use one of the primary blacklisting AV vendors in our demo to show how they don’t stop a _two_year_old_ exploit in a popular software product, but we do (as well as many much newer – including brand new, completely unknown buffer overflows.

3) Absolutely. Poisoning (fundamentally compromising the whitelist) and cloudlist/crowdlist updating latency (causing work downtime, system failure, or delays in deploying patches and updates are the exact reasons why we have considered – but abandoned – any approach to use an ethereal list to “define” security of our whitelist.

Wes Miller (CoreTrace Corporation)