One of the hot topics recently has been Microsoft's design of the 64-bit Vista kernel. I would like to share _my_ opinion on this issue that may not be directly related but I hope it opens up our minds as we make sense of the current event as it relates to the future.
Everyone has experienced the change in Microsoft Windows from pre-XP-SP2 to XP-SP2. In your own way, you have experienced an investment made in the survivability of this OS and sub-systems. Lets say for a second, that this trend continues and for the next 5 years, Microsoft manages to lower the administrative and operational costs associated with their Operating Systems (one of those costs being keeping it resilient to the technical threat), what then? What happens to the vendors whose core products feed off of the opportunity Microsoft once created by not making security a priority over general functionality? What began with the release of XP-SP2, is still alive and this locking down of the 64-bit Vista kernel is yet another step in that direction for Microsoft and their customers. But what about their partners? Well, as one would expect, those partners who change with Microsoft will do well, those that fight the change might be standing in the way of real progress and this is what has bothered me about this 64-bit kernel access.
Lets consider the customers perspective on this one. Principally, the consumer want systems that can remain secure at the lowest administrative and operational costs. By secure I mean that the system is operating as intended even in an untrusted environment. Consider that Microsoft has been hiring the brightest in our industry over the years (Hi Adam), inviting the rest to come in and tell them what they are doing wrong (ie Bluehat), and ultimately changing their development culture over the years to produce a more dominant security strategy for their product line. Before you get any ideas about TK being a cheerleader here, let me make myself perfectly clear: My issue is that over the next 5 years or so, if Microsoft is doing what is right for their customers, there is a very good chance that the parasitic relationships that are based on yesterdays insecurities will need to turn their attention to tomorrows or die.
In the end, what needs to be argued or at least put in to terms that the consumer can understand is:
What threats are greatly diminished by not allowing access to Vista's 64-bit kernel?
(how does this raise the cost to the adversary and at what price to the user?)
The consumer needs to understand this so they can clearly see if they must continue with all the 3rd party safeguards they once used or if there is a new more effective strategy.
I wake up every morning and fear that the security industry is just one self-fulfilling prophecy as described by Marilyn Ferguson:
"If we continue to believe as we have always believed, we will continue to act as we have always acted. If we continue to act as we have always acted, we will continue to get what we have always gotten."
In many ways, it is when Microsoft starts to upset the vendors of yesterday’s solutions that we know they are not pulling forward yesterdays problems in to tomorrows products.
Comments (3)
there are some specifics you seem to have glossed over...
as far as malware goes, locking down the kernel will stop the so-called 'rootkit's and precious little else...
as far as security software goes, locking down the kernel will stop a great deal of behaviour-based technology (the pro-active technology everyone's been saying we need more of)... if you can't extend the kernel (which is precisely what patchguard prevents) then you can't trap kernel level events/conditions that are of interest in security contexts... there are no API's for doing that yet (that's what microsoft is promising to release) and there won't be any when vista is released (microsoft says there's no timeframe on the release of the API's, so it's not expected before sp1)... of course that assumes they'll agree to expose the all the parts of the kernel the security vendors need (since the parts of the kernel that are exposed would then be open to attack)...
and while there is one company that claims to have bypassed patchguard, it remains to be seen how successful a strategy that will be in the long run as microsoft has vowed to close such holes when they're found...
so, yes - if we're willing to sacrifice proactive technologies that are aimed against all sorts of malware and get by with just the reactive ones so that microsoft can stop the conventional 'rootkit's, we should definitely allow microsoft to 'evolve'...
Posted by kurt wismer | October 26, 2006 1:43 PM
Posted on October 26, 2006 13:43
Wonderful comment and this is the discussion I have yet to see represented in the trade publications. How can the consumer understand the cost/benifits beyond just "let make sure it works the same way as it always has".
Since you have raise the one use-case regarding specific HIPS (host intrution prevention systems), the question becomes:
Is there a new way to perform this function such that the both can be satisfied? Lets have that discussion.
Posted by TK | October 26, 2006 2:12 PM
Posted on October 26, 2006 14:12
@tk
"Since you have raise the one use-case regarding specific HIPS (host intrution prevention systems), the question becomes:
Is there a new way to perform this function such that the both can be satisfied? Lets have that discussion."
i don't have specific knowledge of the existence of alternative means for implementing HIPS or many of the other behaviour-based technologies and protective mechanisms that will be broken by patchguard... i think if there were alternatives then microsoft wouldn't need to develop API's that expose parts of the kernel for use by security vendors and the security vendors wouldn't need to waste time waiting for those API's...
i very much doubt anything less than full access to the kernel is going to completely satisfy the security vendors... as much as i understand microsoft's desire to lock down the kernel, i also understand the security vendor's desire to be able to address new classes of threats without having to negotiate the creation of new kernel exposing API's each time... i also understand how frustrated they must be that a relative newbie to the anti-malware arena is seemingly in a position to dictate what technologies they can and cannot implement...
i suppose since this is only an issue for 64bit platforms and since 64bit chips are shipping with hardware assisted virtualization capabilities these days that a hypervisor could be developed to bypass microsoft's lockout in a way that microsoft can't easily address, but since you can't have multiple hypervisors running that would limit you to using a security suite instead best-of-breed technologies from multiple security vendors...
Posted by kurt wismer | October 27, 2006 7:05 AM
Posted on October 27, 2006 07:05