Message-ID: <20040212155938.GA51288@netpublishing.com>
From: ggilliss at netpublishing.com (Gregory A. Gilliss)
Subject: Re: Re: <to various comments>EEYE: Microsoft ASN.1 ...

I do not work for eEye, although I have a favorable impression of the work
that I see them produce.

My personal prejudice is that I subscribe to the school of "security by
embarrassment". Vendors (and examples of this are legion) fix holes in
their code much more quickly when the hole is widely publicized, and
when the exploit code, regardless of its author, is widely available.
This scenario places the requisite pressure on the vendors to force them
to commit resources that they would not otherwise commit to discovering
and repairing the software flaws that they foist upon the community in
the name of time-to-market and greater profitability.

I disagree with this perspective. The goal of security research is
understanding. If we work for someone and have not the time/permission/
resources/fill-in-the-blank necessary to understand, that is one thing.
However to withhold the information for the sake of censorship/proxied
responsibility/corporate bondage is another. If a US company cannot
release full details of a vulnerability because the lawyers will swoop
down from on high, what value does the research accomplish? If "polls
show that admins want the details", all the better. If admins don't have
the time/permission/etc to delve into the details in order to understand,
I assert that that is indicative of a deeper problem with our work and
our culture. Being overwhelmed is not the same as being restrained.

The Rule of Law exists to proscribe what acts civilization permits
and prohibits, and the consequences for transgression. FD exists to allow
people to share, educate, and discuss security vulnerabilities and
exploits. Reading this post, I suspect that someone is confusing the 
two. Agreed, we are no longer in the period of time when someone can
trespass on your computer with impunity. However I do not believe that
the responsibility for enforcing that social edict resides with either
this list or the vendors or the security researchers.

I'm not asking, but it appears evident that eEye has a business partner
agreement with M$ that restricts their ability to release their research
in a "timely manner". Same thing that happened to securityfocus when
Symantec bought them. The rules have changed. I acknowledge the situation.
However I tolerate it; I do not care for it one bit.

G

On or about 2004.02.12 00:56:59 +0000, Paul Tinsley (pdt@...khammer.org) said:

<<SNIP>> 

> >Question: "Why release all of the details"
> >
> This statement is not an accurate paraphrase, I didn't say why release 
> them all.  I said why release them all on day 0 of the patch release.
> 
> >Answer: Polls show this is what administrators what. This is one reason
> >we do this. Another reason we do this is simple, we use the details
> >ourselves. We use the details to create signatures for our vulnerability
> >assessment tool and firewall. Security administrators then download
> >these signatures and use them to check for patches or to protect systems
> >which can not yet be patched.
> >
> Administrators don't need this crap to fix their boxes, they simply need 
> the exploit vectors, the possible mitigation steps, and the potential 
> severity of the vulnerability.  No sysadmin should have time, nor care 
> about the call made to localalloc, the decoder functions it effects, 
> etc...  The pieces that are needed to make a threat assessment and 
> develop a mitigation strategy, IMHO, are all in your bulletin, and 
> contained in these sections: Systems Affected, Services Affected, 
> Software Affected, Description, Severity.  From that it's pretty obvious 
> how bad this one can be, knowing that we can't make people stop using 
> Outlook in a corporate environment, or stop using Internet Explorer to 
> go to several popular sites, or any of the other numerous 3rd party apps 
> that are affected by this.  The strategy is simple, patch, patch, patch.
> 
> That is something that takes time in a large enterprise where you have 
> to worry about the effects it will have on day to day business.  You 
> can't just flip a switch and deploy vendor patches the day they come 
> out, I think we all know that Microsoft patches do have bugs from time 
> to time and knowing how these will affect your "officially supported" 
> corporate applications is important.  Reducing the safe margin of time 
> that one has to do that IS a problem in my eyes.

<<SNIP>> 

-- 
Gregory A. Gilliss, CISSP                              E-mail: greg@...liss.com
Computer Security                             WWW: http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3

Powered by blists - more mailing lists