What you should learn from the Cisco vulnerability disclosure controversy

In late July, Cisco Systems and Internet Security Systems (ISS) made headlines when the companies took unprecedented steps to stop a former ISS employee from disclosing Internet security vulnerabilities in Cisco's Internetwork Operating System (IOS) at the 2005 Black Hat security conference in Las Vegas. The companies took Michael Lynn to court, seeking a temporary restraining order from a U.S. District Court and eventually agreeing on a permanent injunction that prohibits any further discussion of the presentation or dissemination of any information or recordings.

By now, you're likely more than a little familiar with this case. A high-profile story in the media, the controversy spurred all sorts of discussions about the legal debacle, the players involved, and the long-term ramifications. While such discussions are both interesting and relevant, that doesn't mean we can neglect the implications for the security arena.

Why was Cisco willing to take these extraordinary steps to prevent public disclosure? Let's take a closer look at the vulnerability, the issue, and a possible resolution.

The flaw

The flaw that Lynn resigned his job in order to disclose the information in his Black Hat presentation certainly wasn't new. It's rooted in an advisory that Cisco first published in April 2004, "Cisco Security Advisory: TCP Vulnerabilities in Multiple IOS-Based Cisco Products."

In his presentation, the former ISS researcher outlined a method for taking control of an IOS-based router, using this buffer overflow or a heap overflow attack. In fact, this flaw has been well-documented. In addition, depending on the version of IOS running on the router, the fixed version of the IOS was available, or Cisco made one available shortly after.

The problem

While the Cisco vulnerability was only one of several scheduled topics up for discussion at the Black Hat conference, the flaw—and the surrounding controversy—received the lion's share of attention. The disclosure of a new use for an old flaw became a hot topic, and almost everyone seems to have an opinion.

It's important to realize that not every business that runs Cisco routers reads the Cisco security advisories. In fact, some small businesses don't have the resources to maintain a staff of Cisco engineers. As a result, many small companies only fix security problems a few times a year, such as on a quarterly basis.

Most companies that run large networks have developed a patching or update strategy that includes testing and delivery. But testing and scheduling for implementation can take months because of the downtime required to implement a new IOS and maintain the service-level agreement with the customer or business.

The solution

None of this fiasco would have been necessary if everyone would implement vendor-supported and distributed security patches in a timely manner. That is the simple solution.

Vendors create and distribute security fixes and patches to counter discovered flaws. Such fixes are not feature enhancements, and companies shouldn't treat them as optional. Instead, they should apply any patches as soon as the vendor releases them.

This leads us to the larger problem that pervades even the largest and smallest of companies. Change management is a persistent problem. If you haven't established procedures to quickly test and deploy security-related patches, then it's only a matter of time before your network falls victim to your inability to respond to emerging security threats.

Final thoughts

Change management and patch implementation for security-related issues are not activities your organization can afford to triage. Too many companies put off security fixes until they "can get to it"—and most eventually pay the price for such procrastination.

Network security is a proactive process. If you're constantly reacting to security problems, you need to look deeper than the problem itself and find the underlying flaw in your business process. If you have devices on your network that are vulnerable, you need to fix them before someone else finds them.

Miss a column?

Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.

Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.