I am wavering a bit on my position on the MS Vista KPP/ PatchGuard debate, but there is so much rhetoric going on that it is difficult to actually get any facts on either side.

In general, I think KPP is "A Good Thing" and the positions held by Symantec, McAfee et. al. regarding how good security vendors are at providing security and how there should be a small group of "chosen one" vendors with better access are pretty shallow. I think most folks involved in the controversy agree with my former position, but half will likely disagree with the latter. KPP is no panacea, but it provides a valuable function.

So, the question is whether there is validity to S&M’s (;-)) claims once you peel away the posturing. I think there is the possibility that they have a point. The initial example that I saw on Security Curve just seemed self-serving once again, but this post on Symantec’s blog provides much better insight. At least we know what hooking technique PatchGuard is blocking – SSDT hooking.

But there are a number of techniques that folks can use to monitor activities. I suspect most/all of those are also restricted by KPP, but I am not sure. If they aren’t, then there isn’t really a problem (though it would seem that KPP is less effective than I would like). If they are restricted, then what other techniques might exist to provide this capability?

Getting to the bottom of the "other techniques" is problematic. In my mind, the biggest problem is that the HIPS players out there aren’t chiming in on the pig pile. Why not? As far as I can tell, they have the most to lose here. I did here from one vendor that said it wasn’t a problem for them. So, if there are other techniques (yes, even if they are in user mode), then I believe the advantage goes to Microsoft.

On the other hand, the closest set of details I’ve seen about this were on Stephen Toulouse’s (Stepto) blog where he asserts:

"Examples of documented APIs that our teams are investigating with third parties include control over process/application launch and manipulation, prevention of tampering and unauthorized modification of security software, and visibility/control into memory management functions such as writing into another process’ memory address space."

Since they are "investigating" these capabilities, then it is safe to assume they don’t exist today (back to the question of alternative legitimate techniques). These are all HIPS capabilities… so where are the HIPS folks? (I know, I know S&M have HIPS products, but to date they really haven’t gone out of their way to describe any specific technical differences between av and hips.)

If there are no other ways to (at a minimum) keep an application from running, then this is a bigger problem than I originally thought. Microsoft backpedaled significantly here (though Stepto’s blog insists they didn’t), so I guess I can, too.

The other issue worth addressing is this whole competitive advantage question. Microsoft claims no competitive advantage because their solution must abide by the same rules for the APIs that are available. Symantec says that doesn’t matter, because MS products aren’t as advanced as theirs and they need more capability (i.e. the HIPS stuff above). So it doesn’t matter that MS plays by the rules with the old stuff; it is the newer stuff that matters.

If Microsoft releases a HIPS product in conjunction with their extended API, you gotta wonder if there is something fishy going on. If there are other ways to monitor system calls, it shouldn’t matter anyway. If there aren’t other ways, then Symantec has to come up with other ways to talk about the issues that aren’t so political.

I am still researching these (technical) issues, so if you have any good specifics, please comment or send me an email.

Btw, the whole webcast whining is silly.