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.