Feeds

Out of the Slammer

Something needs to change

  • alert
  • submit to reddit

High performance access to file storage

Opinion With the Slammer worm network security becomes literally a matter of life and death. Where do we go from here, asks Tim Mullen?

Three hundred and seventy-six bytes.

That's all there was to "Slammer," 376 bytes. When you think about it, it's amazing that a piece of code could have wreaked such havoc on the Internet and caused such widespread system failure -- at about the size of two paragraphs of this column.

What is even more amazing is that this worm was a success in the first place. Many layers of our security model had to fail for Slammer, or "Sapphire" as eEye dubbed it, to make it as far as it did: Not only did there need to be a large installation of un-patched SQL/MSDE boxes in use, but they also needed to be reachable over the Net on UDP 1434.

As usually, the worm starts and ends with the unpatched available system. Every major worm we have seen exploited a known vulnerability in a service, be it Nimda, Slapper, Slammer or Code Red. Code Red was supposed to be a wake-up call, but it is obvious that many hit "snooze," rolled over, and went back to sleep.

And this time, it cost us.

General Internet congestion is always expected for a worm like this, but the peripheral effects of Slammer caught many by surprise. They caught me by surprise. Financial institutions and government bodies were affected by this worm. I was skeptical of mainstream media reports of Slammer's infestation of a 911 emergency response system, so I contacted the reportedly hard-hit Bellvue, WA center directly. The conversation was sobering. According to an operator in the dispatch center, the worm forced them to switch to manual systems. If a non-trivial emergency event had occurred during this period -- a car pileup or a major fire or explosion -- there would have been a "most definite" risk to human life due to process delays and system unavailability.
I don't like it, you don't like it, but the truth is we will be stuck with the "install now, patch later" model for quite some time.
According to this official, someone could have died.

Like many others, I had taken the threat of "cyber-terrorism" with a large grain of salt. But where the interdependencies of multiple systems connected to the Internet make it possible for a worm to shut down normal operations of an emergency dispatch center by accident, it does make me wonder what could happen if someone launched a coordinated attack on purpose.

So, what needs to change?

Least Privilege

Obviously, we need more secure software in the first place -- and not just from Microsoft; all software manufacturers ship vulnerable software. Resist the urge to blame Redmond for this one. You didn't buy SQL Server because it is "secure", you bought it because it is a kickass database engine that allows you to more easily and efficiently manage business processes and data so you can be more profitable. Like all software, it is just a tool, and we are responsible for making sure it is properly used and properly secured in our environment.

I don't like it, you don't like it, but the truth is we will be stuck with the "install now, patch later" model for quite some time, and we need to accept that and get good at it.

While we still need a better way to manage patches and updates, that is only part of the solution. Slammer showed us that worms can be as much of an infrastructure problem as they can be for Internet-facing systems. Remember, this was not just a server worm: it also infected workstations running un-patched versions of MSDE. And we all know that when it comes to riding on the Patch Train, desktop software is seated in the caboose.

That is why the concept of "least privilege" is so important. Had more firewalls been configured to "deny all and allow only needed" services as opposed to the "open it up and block what you know is bad" model, this worm would not have been a problem. (To that degree, I was surprised to see that Slammer did not set the source port to 53 in order to look like a DNS response and slip through even more firewalls. Small favors.)

You can bet that your security people know this. The problem is that most management teams don't give IT the resources it needs to do its job, or the power to set and enforce policy when it comes to securing the services your business units dictate must be available.

So, as it is with most issues, this all comes down to people and money. If you want your systems to be secure, you need to get the right people, you need to let them do their jobs, and you need to be prepared to pay for it.

This will become evident when security exposures start making businesses lose customers. I just hope we figure it all out before someone loses something much more precious.

© SecurityFocus Online

Timothy M. Mullen is CIO and Chief Software Architect for AnchorIS.Com, a developer of secure, enterprise-based accounting software.

High performance access to file storage

More from The Register

next story
Obama allows NSA to exploit 0-days: report
If the spooks say they need it, they get it
Parent gabfest Mumsnet hit by SSL bug: My heart bleeds, grins hacker
Natter-board tells middle-class Britain to purée its passwords
Web data BLEEDOUT: Users to feel the pain as Heartbleed bug revealed
Vendors and ISPs have work to do updating firmware - if it's possible to fix this
OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts
Bloke behind the cockup says not enough people are helping crucial crypto project
One year on: diplomatic fail as Chinese APT gangs get back to work
Mandiant says past 12 months shows Beijing won't call off its hackers
Call of Duty 'fragged using OpenSSL's Heartbleed exploit'
So it begins ... or maybe not, says one analyst
German space centre endures cyber attack
Chinese code retrieved but NSA hack not ruled out
NSA denies it knew about and USED Heartbleed encryption flaw for TWO YEARS
Agency forgets it exists to protect communications, not just spy on them
prev story

Whitepapers

Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
HP ArcSight ESM solution helps Finansbank
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.