Hmmm.... agree to disagree here, but let me offer a counter position
and voice support for Simple Nomad's statements.

IMHO A broad generalization that I believe holds true is:

On one side:

The more restricted the disclosure of information about a 0day vulnerability
the more strategic value it has as an offensive tool and the more potential it
has for damage and stealthful strategic attack on important targets. A corollary
to this is a that enhancing this limitation on disclosure further limits the
number of creative minds working on counters and detection tools
for the methodology (and yes I conceed, derivatives as well) and
hampers negation of effects - even further increasing strategic
offensive value.

On the other side:

The more widely dispersed and commonplace knowledge about a
vulnerability gets, along with the greater propagation of detection and
counter technologies that accompany this information dispersal, the
more it leads to a weakening of the tools/vulnerability's ability to play a
strategic role as an offensive tool. In an information war millieu best way
to downgrade your opponents strategic arsenal of computer/information/network
attack tools is to make them as widely known as possible while keeping
your tools and methodology knowledge more closely held.

While dispersing knowledge, binaries and tools lowers the "bar"
as well, in terms of knowledge and skill level needed to succesfully
deploy it... it also has the value of increasing reward for preparing
for it, making preparations more comonplace and lowering the strategic
value the vulnerability has for "elite" attackers. And it has been shown time
and time again, that if you don't release the exploit.... within a matter of
days typically <someone> will code it and distribute it. By not disclosing it
you are potentially decreasing vulnerability from the legions of "script-kiddy"
or entry level attackers, while increasing the strategic vulnerability to
more serious, knowledgeable and intent intruders - you are just
sharpening their knives for them as it were.

I would argue that while it has been a hassle, Code Red (and it
seems that the greatest hazard hasn't been the predcted internet meltdown
but the resulting spambombing of every security mail-list around) has
actually been the best thing that happened to IIS security in a long time.
If you really want to fix a security problem build a point and drool gui
driven exploit for it. :-) I hypothesize that we have only seen kids playing
so far, and have yet to really see this kind of technology focused
and used to its full offensive potential - and I'd much rather
deal with the kids than the serious stuff I'm sure we will no
doubt eventually see these techniques applied to. So arguments
that focus on keeping the toys from the kids in exchange
for making this stuff into seriously damaging and destructive
weapons for more malicious intents seem misguided as
we (thankfully) have few examples to judge where following
that other course of disclosure restriction could lead us.

Frankly, I would gladly trade hassles for incompetent IIS-running
vanity web-sites and understaffed dot coms in exchange for
lower levels of vulnerability from terrorist attacks on power grids,
or organized computer-based thefts from financial institutions or
even worse military security possibilities which I see as some
of the more harsh potential disruptions possible over the network.

But, putting on my penetration-testing-consultant hat on, I
say, go on, more power to you in restricting that information,
because you are just making my potential arsenal stronger
and more efficient, as I'll just code the exploits for myself.

I agree wholeheartedly with assessments stating that in
a non-traditional confrontation, the reaction/development
time of identification/analysis/counter-measures on both
offensive and defensive technologies is crucial in determining
who will have the upper hand... but let me ask: Is focusing on
slowing the development of offensive tools really the appropriate
focus of energy - given the potentially dubious effectiveness of
such a strategy, when in reality the problem is the lack of speed
on the defensive side. IMHO, in a race, trying to trip up that other runner
because he/she is faster doesn't seem like a substitute for learning
how to run faster. I think that we would be better off spending
that effort on trying to figure out how to increase the effectiveness
and rapidity of defensive measures and stop all this needless
fretting and debate over the exploits.

The real issue is not the exploits... but the pathetic state of
our defenses, security training/awareness and procedures...
and yes, the resulting poor design of the software. I would think
that if we funneled all the effort the computer security industry
dubiously puts into properly "managing" and "controlling" vulnerability
information instead into training for network security awareness
for programmers and network system architects, we would be far
better off in the long run.

But hey, the nice thing about being in this industry right now
is that no matter what course you folks choose to emphasize it's
a win for me... on one side I get more effective pen-tests, while
the other way my computers become more secure... So go
on and restrict the exploits - it'll make them more valuable for
me. P.S. Anyone got any good 0day they want to trade? I just got
a copy of 0day.c.... ;-)

cheers,
--dr

_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]