If you're like me, you're asking, "So what else is new?" And that leads us to my point: That message was posted in April 1994. Now we have virus-protection products that automatically download images. We have intrusion-detection products. We have vulnerability scanners, patch-compliancy checkers and, soon, next-generation patch-management tools. Six years ago finding one "security guy" at a major OS vendors was hard; today companies like Microsoft have some of the best trained bug responders in existence.

While this reactive progress is positive, it's still not proactive. We're continually blindsided by worms, "autorooters" and other automated exploit tools. What's the solution? Outlaw exploit code? Ban disclosure? Track down and prosecute bug finders? These efforts will ultimately fail -- and may even do more harm then good. Here's why.

The vulnerability life cycle has three phases: the research/discovery phase -- in which both malicious and nonmalicious security researchers seek new holes in products; the disclosure phase -- in which the discoverer of the new vulnerability tells others about it; and the exploitation phase -- in which the specifics of bug information are incorporated into a program designed to take advantage of the vulnerability.

Trace Unix exploit code in the late 1980s and early 1990s and you'll find that vulnerability information and exploit code commonly circulated in the underground long before they made their way to FIRST, CERT or Bugtraq circles. Attackers used this knowledge as trump cards: Even if your Unix machine patches were up to date, you obviously had no patch for unknown holes. These vulnerabilities still exist today, leaving many systems in a "pants-down" state. This phenomena is one of the primary reasons defense-in-depth strategies are so important. We're not battling just the known; we're battling the unknown too.

As a contributor to the SANS/Network Computing Security Alert Consensus newsletters, I've watched the lead times between disclosure and working exploit code shrink to 48 hours or so. While "responsible disclosure" can keep these lead times a bit higher, the argument that not revealing details prevents the bad guys from exploiting is nothing short of a fairy tale. I know several members of the underground who compared source trees and reverse-engineered fixes to find the root causes of problems. And, yes, Windows NT source code is out there -- people need to stop fooling themselves. My hypothesis? The research-to-exploit window of opportunity is narrowing significantly, and we'll see the window of vulnerability to worm release reduced to 48 hours in the next year. How fast can you patch?

Outlawing exploit code, trying to control crypto and forcing researchers into secrecy (they won't simply stop) will do one thing: drive the security scene back underground. Can we move to responsible disclosure? Yes. Can we try to restrict the rapid proliferation of automated attacks tools? Possibly. Can we solve the problem with bandages, duct tape and wordy memos to Capitol Hill? Absolutely not. Ladies and gentlemen, the time has come to do it the hard way. We must force vendors to start educating their developers on secure coding practices and have our schools teach this as well. Some posts are as relevant today as they were back in 1994.