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

[ reply ]