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.
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.
Um, no. They said to download and notify before installing. MS just went right ahead and installed and rebooted the computer for them. http://www.emailbattles.com/archive/battles/vuln_a acfhddccc_de/
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
architecture != software packages. And definitely != enterprise software packages. Veritas, oracle anyone?
I won't even begin to go into how many times a redhat update has "broken" both of these.
No, 95% of the desktop world runs on Microsoft. Microsoft certainly doesn't have that kind of marketshare in server systems.
-- listen to interesting music, support independent radio... WPRB