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."

Comments

Still too long, but you can take precautions.

[gasmonso]

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/

Why MS takes so long to release patches

[DoktorFuture]

I'm sure that the QA aspect of testing the patches takes the most time, because that is where Microsoft has the most to loose.

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:

• Release a damaging patch -> like an A-Bomb wiping away consumer confidence
• Release a patch late -> some systems might be infected, but often, threats can be mitigated on key systems (firewall rules, policies, use different software), or third party patches appear to fix the problem.
• Ignore a problem -> Perhaps try to luer people to exploit it instead of finding new holes? :) Perhaps encouraging the industry to develop technologies like 'IPS' and 'worm crushers'?

I'm sure at least someone is thinking "Heck: our flaws are the manure in which an entire security industry will grow in".