CIO — Early one Saturday morning last January, from a computer located somewhere within the seven continents, or possibly on the four oceans, someone sent 376 bytes of code inside a single data packet to a SQL Server. That packet—which would come to be known as the Slammer worm—infected the server by sneaking in through UDP port 1434. From there it generated a set of random IP addresses and scanned them. When it found a vulnerable host, Slammer infected it, and from its new host invented more random addresses that hungrily scanned for more vulnerable hosts.
Slammer was a nasty bugger. In the first minute of its life, it doubled the number of machines it infected every 8.5 seconds. (Just to put that in perspective, in July 2001 the famous Code Red virus doubled its infections every 37 minutes. Slammer peaked in just three minutes, at which point it was scanning 55 million targets per second.)
Then, Slammer started to decelerate, a victim of its own startling efficiency as it bumped into its own scanning traffic. Still, by the 10-minute mark, 90 percent of all vulnerable machines on the planet were infected. But when Slammer subsided, talk focused on how much worse it would have been had Slammer hit on a weekday or, worse, carried a destructive payload.
Slammer’s maniacal binge occurred a full six months after Microsoft had released a patch to prevent it. Those looking to cast blame—and there were many—cried a familiar refrain: If everyone had just patched his system in the first place, Slammer wouldn’t have happened.
But that’s not true. And therein lies our story.
Slammer was unstoppable. Which points to a bigger issue: Patching no longer works.
Partly, it’s a volume problem. There are simply too many vulnerabilities requiring too many combinations of patches coming too fast. Picture Lucy and Ethel in the chocolate factory—just take out the humor.
But perhaps more important and less well understood, it’s a process problem. The current manufacturing process for patches—from disclosure of a vulnerability to the creation and distribution of the updated code—makes patching untenable. At the same time, the only way to fix insecure post-release software (in other words, all software) is with patches.
This Hobson’s choice has taken patching and the newly minted discipline associated with it, patch management, into the realm of the absurd.
Hardly surprising, then, that philosophies on what to do next have bifurcated. Depending on whom you ask, it’s either time to patch less—replacing the process with vigorous best practices and a little bit of risk analysis—or it’s time to patch more—by automating the process with, yes, more software.
