Sergey Nivens - Fotolia

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

The SQL Slammer worm has re-emerged to attack a vulnerability in Microsoft SQL Server 2000. Expert Nick Lewis explains what enterprises can do to manage out-of-date systems.

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.

Next Steps

Read why QuickTime for Windows was abruptly moved to end of life

Find out how Fruitfly Mac malware's decades-old code works

Learn why the PHPMailer library vulnerability had to be repatched

Dig Deeper on Risk management

Networking
CIO
Enterprise Desktop
Cloud Computing
ComputerWeekly.com
Close