Slashdot Mirror
Microsoft Taking Longer to Fix Flaws
An anonymous reader writes "A look back at the last three years of security patches from Microsoft shows Redmond is taking at least 25 percent longer to issue patches for "critical" vulnerabilities, now averaging around 135 days to issue a fix. The exception appears to be with "full disclosure" flaws, for which Redmond issued fixes in an average of 46 days last year."
I was expecting to find a scathing review of the patch process, but instead found a fairly reasonable assessment of the realities of issuing security patches: disclosed vulnerabilities get patched faster in an attempt to cover the users from the most probable exploit vectors whereas undisclosed vulnerabilities give the breathing room to do more testing and attempt to repair related flaws that are discovered in the process.
That doesn't make me happy with the current situation, but it does make sense to react quickly (even if it puts the reaction at risk of being a problem itself) when something is actively being exploited. More quality assurance can be placed on patches that are not actively exploited (although each day increases the chance it will be exploited) and even more quality assurance can be placed on patched for flaws that are unlikely vectors.
Being responsible for very high reliability networks (our customer facing web and their support servers), high reliability networks (the corporate network, where I can apologize to someone's face if it blows up) and low reliability networks (my own internal network where I can fire anyone who complains) I have different thresholds for pain in the patching process depending on the network involved.
I'm far more willing to just slap a patch on my internal network: after all, it is my testing ground and it affects me far more than anyone else if it dies. After I have assured myself it isn't total bunk, I will patch our corporate network. Finally, our high reliability network is patched only after the corporate network's servers and clients have given us confidence in the patch. Of course, that means our high reliability network has to be far more insulated (URL scanning proxies in another operating system, tightly controlled trust relationships, intrusion detection, etc) but it is worth the extra effort and cost to avoid a "bum" patch bringing down the show.
Microsoft may not be reacting perfectly, but I think they are trying to balance corporate stability with the realities of exploitation. It sounds like they do need to throw some more resources to the departments involved to shorten the critical path, but with a system this complex, test cycles are going to be long and involved.
Sig under construction since 1998.
In the Linux world, the deployment of a bug fix and discovery of any potential bugs is part of the testing cycle. So you get a quick turn around time when a bug is reported.
.. whatever it takes to make sure it is tested is a GOOD thing. I don't want to be their beta tester :)
When Microsoft has to issue a bug fix (and all jokes aside about not testing), I am sure they have a team devoted to testing it, then it has to get sent to all internal Microsoft employees and tested, and then probably even has some initial customer testing with the bigger companies to make sure nothing breaks, and then finally gets released to the public.
Hopefully 165 or 365 days
Focusing on the exploits or not, 46 days is a long time to wait for a critical fix.
when you're accountable to that many customers with so many "supported" configurations, it takes a while to test. They don't have the luxury of most linux distro's where if it breaks some obscure program they can go "whupps, well, tell the author to write a fix for his app".
Imagine if their patch accidentally disabled * * * TENS OF MILLIONS * * * of computers. If that happened, they'd loose so much consumer confidence -- essentially loosing whatever gains (if any) they have made in the last several years (and billions in spending).
(okay, that did happen on a lot of sp2 systems, and MS is not loved for it)
MS has to ensure that the patch works on a staggering and dizzying array of systems and architectures (lots of different mobos, pentiums, AMD's, dual core CPU's, XENON's, via chips), and for dozens upon dozens of applications. That's why you often find that they'll often release a patch on NT or more server based systems before they release it for consumer systems.Another reason is that, depending on the type of problem, will do a full tracability check, and also cross reference all their code that references the changed module, and evaluate (probably manually) if they put that dependency at risk. A huge, horrible job, suitable only for type-A micro-detail oriented folks. I wouldn't want to do it!
If MS disabled TENS OF MILLIONS of computers, you would see a huge shift away from regular Patch Tuesday activities, towards one of 'install on a test bed' -- extremely tedious and manual that everyone would hate. Millions of people would be put out. Seriously bad Karma.
So, they can:
I'm sure at least someone is thinking "Heck: our flaws are the manure in which an entire security industry will grow in".