Ummm..... Megasoft?

Patching production systems is a process governed by the dialectic between those responsible for keeping the systems' robustness as strong as possible and those responsible for actually providing a product or service using those systems.

Work postponement aside, both sides of the dialectic are often driven by the same need: to keep a commercial enterprise as profitable as possible. The folks responsible for maintaining the systems as such (guys like me and Erik (I presume)) know damn well that leaving patches unapplied can lead to service interruption and loss of revenue. The folks responsible for delivering services (e.g. people who write programs which depend on SQL services being available at UDP port 1434) know damn well that patches sometimes have side effects which interrupt services when they are applied and want thorough and expensive testing done first -- generally by somebody else, and at no cost. (And more sympathetically, those foks are often under pressure from business management to add new features that are wizzier and wiggier than what's there now to get new customers, rather than making the existing product reliable -- disasters don't cost anything until they happen, but new customer revenue is here, now, and the basis for individual sales bonuses.) This dialectic tension definitely exists at Megasoft.

Incidentally, the obvious quick fix, which is also Cisco's recommended response to the problem (blocking the UDP ports involved), causes problems for some DNS implementations (e.g. BIND 8 & 9, if memory serves) as well as potentially interrupting SQL-based services across the Internet that a customer might consider critical to their revenue stream. Unfortunately, ISPs will probably get sued for interruption of services and harm to businesses long before software vendors can be dinged for negligence -- ISPs have service level agreements with their customers, software vendors just stick you with that "this software not sold as actually useful for anything" license and laugh all the way to the bank.

A big problem is that you may not even know what MS products are installed. A lot of people did a "full" install Win2K server and didn't even know they had a web server running, and got hit by Code Red.

The same is true for SQL Slammer. If you do a "full" install of certain MS products, you've also installed a lite version of SQL Server (called MSDE) and are vulnerable.

And the update method for MSDE is truly obtuse.

"That the company has SQL servers on the desktop is not surprising, he added. Many of its developers run the database on their PCs, and other test machines have vulnerable databases installed to replicate customer networks."

Falling into the category of "other test machines" (purely hypothetically, you understand, and not based on observation {cough}) would be those machines on the network run by product support specialists who are training on SQL on, say, a second machine in their cube.

The trouble here probably isn't with servers run directly by the internal IT staff, as it is with the fact that MS is a medium-sized town -- 25,000 full-time in Puget Sound alone -- every single resident of which has at least one computer, and can probably do any number of things that the internal IT staff never learns about. There are few organizations that have quite that same level of cat-herding. :)