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.
Seems as though the reason stems from the fact that Microsoft actually has to make sure their patches are compatible with the rest of the things they support. As they support more and more hard and software, the total can only go up.
The most interesting result of Security Fix's study is that Microsoft took longer to fix a problem if the researcher waited to disclose the problem until after Microsoft published the patch.
I'd like to know if the time to issue a fix also depends on existing exploits, i.e. is Microsoft faster if there is already an exploit out there. If yes, than it seems obvious that Microsoft does not really put as much afford into fixing bugs as they claim, they're "motivated" by public pressure.
One explanation for additional delay in case of a not yet disclosed or not yet exploited problem may be more thorough testing, so it may not even be a bad thing. But I'm afraid that the delay is not really "in the best of the customers", more in the best of Microsoft. I have no prove, but it seems to be the general company policy.
Chriss
--
memomo.net - brush up your German, French, Spanish or Italian - online and free
memomo: free web based language trainer DE-EN-ES-FR-IT
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.
If you look at the data, you will notice that some critical flaws were patched in less than 3-4 weeks. While that may seem long, it is somewhat reasonable due to the amount of verification/validation necessary. People forget that 95% of the world runs on M$ so they have to really test a patch before releasing it.
On the other hand... because so much of the world depends on M$, they have an obligation to its customers to provide a secure OS and timely patches. Personally, I feel they are doing an "ok" job and seem to be getting better. Alot of vulnerabilities can be avoided just by running your PC behind a router and/or by using a firewall application. Personally, I have NEVER had a virus at home on any of my computers because I take simple preventative measures like running Norton AV and AdAware. I also put all my pcs behind a router.
http://religiousfreaks.com/This is a great case for Intrusion Prevention Systems. I have seen many vendors providing "Virtual Software Patches" during the window from when a vulnerability is released to the time that it's actually patched. It's not the ideal solution, but it's definitely one of the best ways to take care of the problem today without waiting for m$ to get their stuff together.
I'd say that in this week I've seen stuff from 3Com/TippingPoint, Secure Computing, Sonicwall, etc. all about securing WMF fairly quickly after the exploit had been announced.
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".
Is it a day?
Is it a week?
Is it a month?
Doesn't Microsoft have enough money to maintain images of different configurations just for such testing?
Doesn't Microsoft have the people who could automate such testing?
Is the problem that they don't have enough money? Or that they don't have people who are smart enough? Or that they just aren't doing it?
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".
when you're accountable to that many customers
When who's accountable? The disclaimer included with the last MS security update I downloaded read as follows:
Now, unless I misunderstood, it's telling me that if I install said security patch, and it breaks something, I can't hold MS accountable.
Slackware
Now, unless I misunderstood, it's telling me that if I install said security patch, and it breaks something, I can't hold MS accountable.
You may or may not be able to hold them accountable in court, but third party adjudication is not the only form of accountability.
If Microsoft didn't bother to test their patches carefully they'd risk upsetting their corporate customers, and hence their bottom line.
We're dealing with a number of different dates, some of which are often months or years apart:
Somehow, being a political movement / cult, MS becomes exempt from the rules of a normal business and from what customers expect. No other device or appliance has had even a fraction of the defects as MS' without going through a major product recall. Our dear Chairman Bill will go down in history as the man that made bad engineering acceptible aka the Microsoft Effect
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.