The conventional wisdom is that when you implement a patch, you improve things. But Wynn isn’t convinced. "We’ve all applied patches that put us out of service. Plenty of patches actually create more problems—they just shift you from one vulnerability cycle to another," Wynn says. "It’s still consumer beware."

Yet for many who haven’t dealt directly with patches, there’s a sense that patches are simply click-and-fix. In reality, they’re often patch-and-pray. At the very least, they require testing. Some financial institutions, says Shawn Hernan, team leader for vulnerability handling in the CERT Coordination Center at the Software Engineering Institute (SEI), mandate six weeks of regression testing before a patch goes live. Third-party vendors often take months after a patch is released to certify that it won’t break their applications.

All of which makes the post-outbreak admonishing to "Patch more vigilantly" farcical and, probably to some, offensive. It’s the complexity and fragility—not some inherent laziness or sloppy management—that explains why Slammer could wreak such havoc 185 days after Microsoft released a patch for it.

"We get hot fixes everyday, and we’re loath to put them in," says Frank Clark, former senior vice president and CIO of Covenant Health, whose six-hospital network was knocked out when Slammer hit, causing doctors to revert to paper-based care. "We believe it’s safer to wait until the vendor certifies the hot fixes in a service pack."

On the other hand, if Clark had deployed every patch he was supposed to, nothing would have been different. He would have been knocked out just the same.

Attention Hackers: Weakness Here

slammer neatly demonstrates everything that’s wrong with manufacturing software patches. It begins with disclosure of the vulnerability, which happened in the case of Slammer in July 2002, when Microsoft issued patch MS02-039. The patch steeled a file called ssnetlib.dll against buffer overflows.

"Disclosure basically gives hackers an attack map," says Gary McGraw, CTO of Cigital and the author of Building Secure Software. "Suddenly they know exactly where to go. If it’s true that people don’t patch—and they don’t—disclosure helps mostly the hackers."

Essentially, disclosure’s a starter’s gun. Once it goes off, it’s a footrace between hackers (who now know what file to exploit) and everyone else (who must all patch their systems successfully). And the good guys never win. Someone probably started working on a worm to attack ssnetlib.dll as soon as Microsoft released MS02-039.

In the case of Slammer, Microsoft built three more patches in 2002—MS02-043 in August, MS02-056 in early October and MS02-061 in mid-October—for related SQL Server vulnerabilities. MS02-056 updated ssnetlib.dll to a newer version; otherwise, all of the patches played together nicely.