I remember taking the ferry from the U.S. mainland to Martha's Vineyard last summer and starting up a conversation with a fellow passenger. We began talking about work, and when he found out I was an information security professional he asked, "What's this about Code Blue, or Red, something about a virus that's taking over the Internet - is that a bad thing or what?" I replied, "It must be a slow week for news if this is the headline that's grabbing attention."
Of course, little did we all know that the headlines would change dramatically a few weeks later. The damage done by Code Red and Nimda, which followed closely on the heels of Code Red, was estimated to cost billions of dollars in downtime, lost productivity, and general corporate befuddlement. Since the timing coincided with an already cooling global economy, and an already cooled Internet economy, the impact was somewhat muted. In addition, attention was certainly diverted away from the issue by the events of September 11, 2001.
One would expect to see all kinds of lessons learned from these outbreaks. Many companies did see Code Red and Nimda as a wake-up call and worked diligently to shore up their security policies. Many others, however, hit the snooze button, citing budget issues, and demonstrating foolhardy bravado in ignoring the risk, intentionally or otherwise. Here's what we've learned since the outbreaks.
Prevention is still the best remedy, but the patient will not get with the program. Both Code Red and Nimda exploited known vulnerabilities for which patches had been available for several months. Are companies any better at applying patches today than they were a year ago? Probably not, although I've yet to see any hard data one way or the other. At least next time around there will be fewer excuses, such as "We haven't been hacked yet" or my favorite: "We can't apply the patch because it has not been QA'd internally and I don't want to destabilize the server." (Of course, that's exactly what happened with several patches from Microsoft and others so you can hardly blame them.)
The disclosure debate adds no value to the discussion and diverts valuable resources away from fixing the problem. The disclosure debate is around whether or not government researchers, academia and other computer security gurus (sometimes called 'hackers') should immediately go public with discovered vulnerabilities, or wait until the vendor has developed a fix, or some combination of the two. Here's the rub: If you go public then you give the virus writers a chance to exploit the vulnerability, but if you wait then the vendors drag their feet and nothing ever gets fixed. Much ado about nothing, however, since most viruses are written to known vulnerabilities with available fixes.
The real answer, everyone agrees, is to write vulnerability-free software; the problem is that nobody knows how to do that. Or perhaps it is more accurate to state that nobody has figured out how to do that profitably. Until the vendors are held more accountable for the software they write, the emphasis will always be on features over security. So far government attempts at intervention have met with a sickening thud. [Special advisor to the U.S. president for cyberspace security] Richard Clarke's speech at the Black Hat Briefings in July suggesting that the public has an "obligation to find the vulnerabilities" and then share them with the vendors in a controlled fashion is like asking us to do our own automobile crash testing.
So what can corporations do to protect themselves against future virus outbreaks?
- Keep your virus files up to date. This is by far the simplest and most effective preventative measure that you can take.
- Buy or download a personal firewall, and keep that current also. Vendors are starting to bundle firewalls with VPN clients and offer combo desktop anti-viral and firewall capability. Both of these trends are encouraging, since the personal firewall can plug vulnerabilities before they are exploited, and the VPN client can force compliance with corporate security policy before allowing mobile and remote workers on to the network, reducing the threat of virus transmission.
- Turn off software 'features' that you do not need. Here is where the vendors could do a better job in configuring software out of the box to present less of an enticing target. Why does Microsoft provide an 'aftermarket' software deconfigurator to lock down its web servers when it could just as easily provide this capability out of the box?
Plan for a virus attack as part of your disaster recovery-planning scenario. If you don't have a disaster recovery plan, get one ASAP. Since you won't know where the next virus attack will come from or what form it will take (see below), you might as well treat it as a random event and plan for recovery accordingly.
What is the future of virus outbreaks? The only safe bet with predicting future virus attacks is to expect the unexpected. So-called 'blended' or 'combination' threats that attack multiple systems are predicted to be the wave of the future, but these are hardly new; the Morris worm of 1989 was an early example. Web-enabled applications offer an even more common platform, and common open platforms invite viruses. Web services will mean even more chances for vulnerabilities, regardless of the security models adopted.
Vendors will respond with increasingly sophisticated signature-based and behavior-based threat recognition engines. The real challenge today is in applying updates regularly, which will require a services-based approach. A new class of security service providers will arise that will educate as well as implement anti-virus and intrusion detection and monitoring. These will initially be vendor-dependent - either a vendor distribution partner or owned outright - but will eventually become vendor-independent over time.
Robert Lonadier is the president of RCL & Associates, a Boston-based analyst and consulting firm specializing in providing implementation-ready counsel and advocacy services to senior management in information security. He can be reached at email@example.com.