Franken Patch

The more you patch, the more you need to patch, and the more kludgy and terrifyingly unpredictable your systems and applications become. Is there any way to escape this horror?

Reader ROI

• Who really writes software patches
• Why vulnerability disclosure invites trouble
• The pros and cons of automating patching

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 per cent 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 humour.

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.

"We're between a rock and a hard place," says Bob Wynn, former CISO of the state of Georgia. "No one can manage this effectively. I can't just automatically deploy a patch. And because the time it takes for a virus to spread is so compressed now, I don't have time to test them before I patch either."

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email CIO
• Follow CIO on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark