Re: [ISN] Full Disclosure: How Much Security Info Is Too Much?

From: InfoSec News (isnat_private)
Date: Wed Oct 03 2001 - 00:19:36 PDT

  • Next message: InfoSec News: "[ISN] Lawmaker proposes creation of cyber-National Guard"

    Forwarded from: "Jay D. Dyson" <jdysonat_private>
    
    -----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 - jdysonat_private ------<) |    = |-'
     `--' `--'  `--------------- 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 majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.
    



    This archive was generated by hypermail 2b30 : Wed Oct 03 2001 - 06:45:38 PDT