Applying service packs used to be one of those tedious administrative tasks that you could relegate to the back burner or even skip if your organization didn't need the new functionality. In fact, not being first to apply a service pack had its advantages: You could learn from the early adopters about potential bugs and workarounds, and Microsoft would have time to fix any problems in the initial deployment.

However, the attack of the infamous SQL Slammer worm earlier this year put a new spin on service-pack deployment. Now, taking basic security precautions and quickly applying service packs are high priorities.

Slammer, a denial of service (DoS) attack that used UDP port 1434, began spreading January 24. Microsoft had released a patch for this exposure six months earlier, but many administrators didn't deploy it. In addition to the difficulty of keeping up with the myriad of Microsoft security patches, which is almost a full-time job in itself, many administrators found the patch too hard to apply. But without the patch, SQL Server systems exposed to the Internet had a security hole. When Microsoft issues a security bulletin, a third party has usually already reported the system vulnerability, and code that can exploit the vulnerability already exists. In addition, crackers these days commonly look for security bulletins like the one Microsoft posted in July and develop code that exploits the problem, counting on the fact that many administrators won't know about or won't deploy the fix. However, on January 17, a week before Slammer hit, Microsoft released SQL Server 2000 Service Pack 3 (SP3), which fixed the Slammer exposure and a variety of other problems—and which also went widely undeployed.

Although I've received a few emails to the contrary, I think Microsoft did a great job of responding to the Slammer problem. Shutting down TCP port 1433 and UDP port 1434 is the first line of defense for SQL Server systems exposed to the Internet, and doing so is the responsibility of systems administrators—not Microsoft. In addition, a fix for the exposure was available as both a patch and a service pack before the attack began. And afterward, Microsoft quickly released three tools—SQL Scan, SQL Check, and SQL Critical Update—to help users protect against Slammer. SQL Scan scans an individual computer, a Windows domain, or a range of IP addresses and identifies SQL Server or MSDE instances that are vulnerable to Slammer. SQL Check scans the computer on which it's running for vulnerability to the worm. And SQL Critical Update scans the computer on which it's running for vulnerability to Slammer, then updates the affected files. (You can find these tools at http://www.microsoft.com/sql/downloads/securitytools.asp.)

Microsoft plans to build a service similar to Windows Update Service that will enable SQL Server systems to automatically update themselves with important and urgent fixes. Whether your company uses such a service is something you'll have to assess in terms of the risk involved in automatically installing system changes. But one thing's for sure: You shouldn't wait too long to apply security fixes. In the meantime, close crucial ports in your firewall such as TCP 1433 and UDP 1434, and keep all your systems current with the latest service pack. Prompt installation of service packs could be the very thing that stops virus writers in their tracks.