Re: Full Disclosure: How Much Security Info Is Too Much?

[InfoSec News <isn () c4i org>]

Forwarded from: "Jay D. Dyson" <jdyson () treachery net>

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 2 Oct 2001, InfoSec News wrote:

> The Code Red and Code Red II virus outbreaks, which capitalized on
> vulnerabilities that were publicized before the viruses spread, brought
> the debate front and center, but the issue presents a constant challenge
> to those who hunt for vulnerabilities. 

        Actually, this is inaccurate.  As has been pointed out several
times before, the exploit utilized by Code Red was significantly varied
from the eEye advisory's methodology.  It can thus be presumed that Code
Red would have happened with or without full disclosure.

> "3,000 vulnerabilities a year -- that's a good chunk of time just trying
> to evaluate each and every one," he added. "You figure 3,000 times 20
> minutes each -- that's 1,000 hours of work, that's half a year of work." 

        If one were to run every OS under the sun with every available
service and accord exposure risks the same level of urgency as remote root
vulnerability, this estimate would be accurate.  However, there is a
hierarchy to security practices and it stands to reason that only remote
vulnerabilities require immediate attention, whereas local vulnerabilities
run up second, usually leading (or tied with) information exposure risks.

        Even at large institutions such as NASA, the hybrid nature of the
environment is limited.  There's typically Win9x/NT workstations (~40%), a
lot of Solaris workstations and servers (~25%), Linux (~25%), and a mix of
Macintosh, IRIX, AIX and HPUX scattered through the remaining portion.

        With the above in mind, the assumption that all 3,000 reported
vulnerabilities apply to all people at the same level of urgency is flawed
from the start.

> CERT, a center of Internet security expertise at Carnegie Mellon
> University's Software Engineering Institute, adheres to a 45-day
> "vulnerability disclosure policy" that puts a hold on security breach
> information to give software vendors a chance to come up with a patch. 

        And CERT's "disclosure" policy isn't.  All they "disclose" is
words to the effect of "there is a problem" and then go out of their way
to avoid providing any meaningful details on the nature of the problem.

        Such advisories are regarded as barely informative by security
advisors because their releases are so utterly behind the times when they
come out that it's not even funny, much less useful.

        If computer security were couched in real-world warfare terms,
Vuln-Dev and Incidents list members would be the combat medics, Bugtraq
and VulnWatch list members would be the front-line MASH triage surgeons,
and CERT would simply be the grave diggers located far and away from the
combat zone.

        Between you and me, I'd sooner talk to the first two groups than
the latter about what the troops really need to defend themselves.

> Experts agree that advisories, by their very nature, may be a heads-up
> to hackers. eEye Security came under fire for disclosing the Code Red
> vulnerability in June before Microsoft had released a patch for the
> hole, and again for releasing detailed information after Code Red was
> controlled, which some blamed for the success of the Code Red II virus. 

        Rubbish.  The eEye crew was thanked *by name* by Microsoft for
their work regarding the vulnerabilities focal to Code Red.  And, as
stated before, the exploit that Code Red used varied significantly from
the code that eEye had authored.  The eEye crew only came "under fire"
by the knee-jerkers of the day who were totally ignorant of the reality
of the situation.

> CERT's Hernan, who calls the center's 45-day policy a "middle line in
> terms of time," told NewsFactor that there is also a middle line for how
> much information is included in an advisory. 

        Depending on with whom you talk, a net.year is 90 days.  With
that alone in mind, 45 days is practically an eternity to wait for
information of a security issue.  

> "It's not in anybody's best interest to withhold vulnerabilities," he
> said. "Description and remedial information is important for the public
> at large, but technical, detailed information is important for security
> experts. The real nuts-and-bolts probably isn't necessarily useful to
> the average network administrator." 

        Again, rubbish.  Any administrator worth his salt should have at
his disposal any and all tools -- including exploit scripts -- by which he
can test his systems for vulnerabilities.  To suggest otherwise is to
assent to a world wherein do-it-yourself types may have a hammer and a
screwdriver, but no other tools by which they can accomplish their tasks.

- -Jay

  (    (                                                         _______
  ))   ))   .-"There's always time for a good cup of coffee."-.   >====<--.
C|~~|C|~~| (>------ Jay D. Dyson - jdyson () treachery net ------<) |    = |-'
 `--' `--'  `--------------- rm -rf /bin/laden ---------------'  `------'

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: See http://www.treachery.net/~jdyson/ for current keys.

iQCVAwUBO7nto7lDRyqRQ2a9AQEkAQQAmH+dFTRxfzckqgMvUES81oheTaSjlo7c
Vig1i8Zpt+dXguBA7JqADyI38vYZAxBlGKkf1gdYEp0seFk09FU6SXaSXupKliDy
K2vqx+Mbn34uRMRvBhmjxRq89001hOA0IBhrVUv1mw2A5syx8Q+pRWmtuvo7y3xR
WZIDB63Q4us=
=+l2K
-----END PGP SIGNATURE-----



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn' in the BODY
of the mail.