SQL Slammer worm returns: How risky is it for enterprises?

The SQL Slammer worm, which first appeared in the wild in 2003, has emerged again to exploit a buffer overflow vulnerability in Microsoft SQL Server 2000. The software hit its end of life in 2013, but many are still using it. How severe is this risk? What can enterprises do to manage vulnerabilities in out-of-date systems?

Comprehensive asset and vulnerability management is part of basic information security hygiene, but it remains a difficult task for enterprises. Even new tools and operating systems still pose many of the same challenges for enterprises that have existed for over 20 years.

The first step in a vulnerability management program is to identify systems that need to be scanned and the owners to notify. This sounds easy, but when systems are spread out over multiple data centers, networks, cloud providers and system owners, it becomes very difficult.

Vulnerability scanners are typically licensed based on IP addresses or the systems scanned, so enterprises with large networks may not scan all their IPs to minimize cost. In addition, enterprises may not scan all the systems because of the volume of data that needs to be triaged. This sometimes results in systems slipping through the cracks.

Systems that fall through the cracks may still live on the network for years -- even decades -- like the vulnerable systems that are still getting infected by the SQL Slammer worm. The risk of the SQL Slammer worm to enterprises depends heavily on what the system is used for and the type of data it processes, but the fact that a system is only now getting infected after being used for over ten years could mean the risk is fairly low.

To identify unaccounted for systems that might be infected with the SQL Slammer worm, use free tools like Nmap to scan your entire network periodically. Look for systems with nonstandard ports open and investigate further.

If an identified system is found to be running an unsupported version of software or an unsupported OS, other compensating controls, like restrictive networking, will need to be implemented to prevent other systems from attacking it. It may even be safer to remove the system from the network.