Tuesday, April 04, 2006

why microsoft hates 3rd party patches

it's not exactly news anymore, but it's happened again - a bug has cropped up in microsoft's software that is so serious that outside parties have been forced to create patches for it due to microsoft's glacial pace...

microsoft doesn't like this, it doesn't like this one bit... it makes them look like chumps... here they are with full access to the source code, tens of thousands of developers, and billions of dollars to throw around and some guy at some security firm somewhere makes a patch faster than they can? they do not want these kinds of comparisons to happen, they do not want people to see what kind of performance the microsoft security machine is really giving them...

one of the things they say is that only microsoft patches are guaranteed to work with everything... they have all these tests they need to perform to make sure they don't break anything and comparing their process to what 3rd party patchers do just isn't fair... problem is, not only are microsoft's patches NOT guaranteed (there have been multiple instances where their patches inadvertently broke things) but it also underlines the fact that compatibility rather than security is their first priority... and this comes from a program manager at microsoft's security response center....

microsoft's security efforts are a failure, a farce, and the public has lost confidence in them... and not just a little bit of confidence either; the WMF incident back in december and now the new IE vulnerability just a few months later, both with wide adoption of 3rd party patches, indicates that this is a watershed event... confidence in microsoft's security efforts has crossed a threshold...

the worst thing, for microsoft at least, is that they're losing control over a captive market... 3rd party patches open the door for competition for their paid support program(s), as well as eat away at the leverage they have for getting people to upgrade by ending support for older versions of their products... ending support has a lot less meaning when other people are willing to pick up the slack...

microsoft talks a good game about security, i saw one of them talk about it at RSA2002, they go to great lengths, but they seriously underestimate the significance of risk when they leave the window of exposure open as long as they do while trying to make the perfect patch... when there's a serious exploit in the wild there should be no question of whether or not to release a patch out of cycle, it should be released as soon as it's made and refined and updated after the fact... so long as a seasoned expert at writing secure code is making the patch (rather than some green code monkey they're trying to train), any problems that might arise from a rushed patch are almost certainly going to be less severe than than the one it's supposed to fix... further, new vulnerabilities from a rushed patch would require additional time and effort from the attacker community to exploit so as long as the development of the patch continues after the initial release so that updates to the patch can be pushed out if needed...

0 comments: