[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Call to arms - INFORMATION ANARCHY




>Path: white.koehntopp.de!mail2news
>From: greg@TCSCS.COM (Gregory S. Youngblood)
>Newsgroups: netuse.lists.ntbugtraq
>Subject: Re: Call to arms - INFORMATION ANARCHY
>Date: 3 Nov 2001 03:36:42 +0100
>Organization: mail2news at white.schulung.netuse.de
>Lines: 65
>Distribution: netuse
>Message-ID: <Pine.LNX.4.33.0111021833250.27475-100000@master.tcscs.com>
>References: <HBEPJLHBJAACEJGCEMKHIEMDDAAA.greg@highwire.net>
>Reply-To: Windows NTBugtraq Mailing List <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM>
>NNTP-Posting-Host: localhost
>Mime-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Trace: white.koehntopp.de 1004755002 28691 127.0.0.1 (3 Nov 2001 02:36:42 GMT)
>X-Complaints-To: news@koehntopp.de
>NNTP-Posting-Date: 3 Nov 2001 02:36:42 GMT
>Xref: white.koehntopp.de netuse.lists.ntbugtraq:4030

Apart from the opening message that started this thread, it would appear
the follow-up posters feel that full disclosure is not needed. I feel
otherwise. Full disclosure, including exploit code to illustrate the
problem, is a valuable tool and one that I hope is never taken away from
me.

I also feel that full disclosure can be done in a responsible manner.

To me, that means (1) notifying the vendor of the problem with details and
full code, (2) public disclosure of "a" security issue with relatively few
details and no code, and (3) after a reasonable time period (5 business
days, 10 business days, a month) full disclosure.

What constitutes reasonable time should be dependant on the severity of
the problem being reported. The higher the severity, the faster I'd prefer
full disclosure.

Does that mean I'm going to analyze the code and learn it innermost
workings? No. I don't have time for that level of analysis, even if though
I'd like to be able to.

Instead, I often take the code and test it against my systems (sometimes
lab/test systems, sometimes production, sometimes both).

I also look at the work arounds, if they exist, and deploy them if they
will not affect services I have to provide. If they do affect services I
need to keep operational, I look for other work arounds to limit my
exposure. Sometimes this means looking at the exploit code a little
deeper.

Then, I retest my systems to see if the workaround is giving me any
protection.

I also retest my systems after installing patches.

In a lot of ways, the arguments for and against full disclosure are
similar to some gun ownership arguments. Full disclosure including code
that exploits the problem(s) discovered is similar to a gun. The arguments
for and against full disclosure are also similar. Some will argue that
"guns are tools, they don't kill people, people kill people", while others
will counter that less guns would mean less deaths.

It's a very delicate subject regardless.

In this case, if full disclosure is somehow marginalized or eliminated,
then we'll end up with "only the criminals having exploits". And we'll be
in a worse position as those responsible for the continuous operations of
servers and services without some of the very tools we'll need.

Worse yet, if some get their way, just working on exploits for verifying
the security of your own systems would lead to your being classified as a
computer criminal or terrorist.

============================================================================
Delivery co-sponsored by Trend Micro, Inc.
============================================================================
BEST-OF-BREED ANTIVIRUS SOLUTION FOR MICROSOFT EXCHANGE 2000
Earn 5% rebate on licenses purchased for Trend Micro ScanMail for
Microsoft Exchange 2000 between October 1 and November 16. ScanMail
ensures 100% scanning of inbound and outbound traffic and provides
remote software management. For program details or to download your
30-day FREE evaluation copy:
http://www.antivirus.com/banners/tracking.asp?si=53&bi=245&ul=http://www.a
ntivirus.com/smex2000_rebate

-- 
http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG

-- 
To unsubscribe, e-mail: debate-unsubscribe@lists.fitug.de
For additional commands, e-mail: debate-help@lists.fitug.de