On Tue, Jul 06, 2004 at 03:04:01PM -0400, David F. Skoll wrote: | On Mon, 5 Jul 2004, Alun Jones wrote: | | > The immediate patch carries maximum risk, and the perfect patch requires | > unconscionable amounts of time to verify its correctness. Between those two | > endpoints, however, you'll find a huge variance in what is acceptable risk | > of damage from a patch versus acceptable delay to test. And unfortunately, | > neither of those two values is a) measurable, or b) the same for each user. | | That's true. However, Microsoft has a much higher record of patches that | break things than most other vendors. I don't believe that's because | the people who write the patches are less competent, but I do believe it's | because they are patching a horribly-designed system. That's a common perception, but when we looked at vendor patch updates, as an indicator of patches that have problems, we didn't see it. And really, we looked. We would have been happy to tweak vendors for releasing shoddy patches, because bad patches stand out in an admin's memory, while ok patches cognitively disappear. Now, it could well be that the problems that cause MS to pull a patch and replace it are more severe than the ones that cause a Linux vendor to do so. We didn't examine that, although I'd love to see someone do that study. What we found was that about 1 patch in 6 gets replaced at some point, and most of that happens in about 30 days or less. Adam Timing the Application of Security Patches for Optimal Uptime Steve Beattie, Seth Arnold, Crispin Cowan, Perry Wagle, Chris Wright, and Adam Shostack. Presented at the USENIX 16th Systems Administration Conference (LISA 2002), Philadelphia, PA, December 2002 http://www.homeport.org/~adam/time-to-patch-usenix-lisa02.pdf
