Ineffective security alerts and patches

That wasn't a huge surprise. Claims of such problems appear from time to time, and usually the announcement parallels a cooperative effort with the product's creators to fix the vulnerability.

Not this time.

Instead, ISS announced that it had found the security problem. Irresponsibly, ISS announced that it was releasing a patch--without checking with the Apache Software Foundation, which was already working to fix the same problem. Because ISS didn't involve Apache, in the end the patch from ISS didn't work. Other groups, including the non-profit Gobbles Security, got into the act, and the result was a classic bout of finger-pointing, accompanied by a PR battle over who was right, and who was at fault.

Now that the smoke has cleared, we can draw some important conclusions. First of all, ISS appears to have gone off half-cocked. The company seemed to be more interested in self-serving press releases than in actually solving the problem. Otherwise, the company would have worked with Apache and made sure that its patch actually worked.

Second, the snafu illustrates the need for better coordination in reporting serious vulnerabilities. ISS went to the FBI. Apache went to CERT. Neither of those groups talked to each other.

Finally, it points out that while IT managers need to closely watch security alerts, they shouldn't be too quick to make changes without an obvious need. Companies that applied the ISS patch immediately thought they were protected when they weren't. It wasn't until a couple of days after the ISS announcement that Apache issued a patch that the organization says works properly.

There is a more important lesson, however. Companies that employ open-source products, including but not limited to Apache, need to have the means to evaluate threats and threat announcements, and to act on them when necessary. This is not a trivial matter. It means that you need a staff member who knows the open-source product well enough to evaluate the patch thoroughly, to decide whether it meets your needs, and to apply it effectively.

Fortunately, with today's economy, such people are available. But even if you have security experts on staff, you have to invest continuously in training to maintain their skills. Let's face it, though--you should be doing that anyway.

What the events of last week don't show is that it's better to have commercial software than open source. True, last week's events involved finger-pointing that probably wouldn't happen with a Microsoft product. On the other hand, you might never hear about a closed-source product vulnerability until the company issued an update. Which is better? That's an interesting question that I leave as an exercise for you, dear reader.

In the long run, however, it's clear that there's no substitute for good training and awareness. You need both, regardless of the source of your software. And without both, you'll never be really secure.

How do you protect your company against premature security alerts and ineffective patches? TalkBack below.

Wayne Rash runs a product testing lab near Washington, DC. He's been involved with secure networking for 20 years and is the author of four books on networking topics.