Process Rights Management: Why Whitelists will always trump Blacklists

First off, I apologize for the lack of posts lately. I have been quite swamped rewriting parts of my kernel code and porting some of the backend to Longhorn. Everything seems to be working well, hold that to a phantom bug relating to laptops with the suspend feature, but it is keeping my hands busy in the process.

Anyways, I thought I would give an update on some of the research I am doing, mostly to bring some of my friends up to speed on why I have been hunting for different hardware for different platforms, and stackable multiport KVMs to keep my desktop clean.

I have been spending a lot of time recently working on understanding how my intrusion prevention system for Windows could be improved. I have taken some of the profiling and learning algorithms and played with them in an effort to really understand how to trace the behaviour of applications. Now its time to explain why.

Over the last two years I have been quite perturbed at the the turn around time from patch to exploit. What used to take months (in many cases years) for a response, we are now seeing lazy attackers simply waiting for a patch to come out, disassemble that to find what has changed and then go to town making the next attack pattern. In some cases, we are talking less than 3 days.... way to short of a time period for most organizations with complex patch management roll out strategies.

Patching is only effective when its done, and done so on a timely basis. There are some great companies working on better automatic patching solutions, but they just don't always work in the processes some IT infrastructures have. It is difficult to roll out when it is frowned upon to touch stable servers with untested patches in environments where criticial business resources rely on said servers to stay up.

Tie this issue together with the fact that other tools like anti-virus are only as good as their signature databases, we begin to see that new blended threats are propogating with more complex hydra like hostility, and they need to be repelled differently.

This isn't new. I have discussed the use of infosec principles like least privilege to be used to confine the damage that may be caused by exploited processes, and it was the very principle used when I designed my intrusion prevention system. However, about a year ago when I presented to a group about behaviour based anomaly detection based on whitelists I never expected Microsoft to pick up on it, and announce similar findings to be investigated and installed into future operating systems like Longhorn.

Well, Longhorn is to far off. And people need solutions now. More importantly, users need a concise strategy that is focused on infosec principles that will work now and in the future, across all devices, on different operating systems.

Hence my dungeon work. I have been working on better ways to trace code execution paths and expose just what an application really needs by way of access rights. From files and registry to network access, we need a cleaner way to map the "whitelist" of what applications, services and operating systems do. By properly understanding what an application is supposed to do, we do not have to fear what its NOT supposed to do. When in violates a given behaviour, it can be considered suspect, possibly even hostile, and can thus be blocked.

In other words, the next time an exploited process decides to download a backdoor, we can immediately block this activity from occuring, ensuring the integrity of the system by denying the malicious code from even executing, and take further action to terminate, isolate or investigate the breach.

In this way, we can increase the time for administrators to effectively deploy their patches to vulnerable software and operating systems. It turns the timeline back in favour of the defender, giving us more time to fix buggy software and allowing security companies time to profile new attack vectors and build signature patterns for their IDS, anti-virus engines etc.

Where next? Well, the idea of process rights management comes into play. We can define what an application is allowed to do at runtime, and force those constraints on executing code in any environment. As I continue to work on this it will provide some interesting hooks to operating systems like XP, WS2K3 and Longhorn... exciting stuff for you to see! And now you realize why I haven't had much time to blog much :)

Now please, stop emailing me asking if I am dead. I'm not. I've never felt more alive.