RE: Ability to withstand well known attacks (fwd)

["Smith, Donald" <Donald.Smith@qwest.com>]

Ok we still need to capture the idea that vulnerabilities
KNOWN to exist in one product may be in other vendors products also.

CodeRed was NOT designed nor intended to take out cisco dsl routers.
But it did.

PingOfDeath was not targeted at linux systems but it killed some versions
of linux.

Etc...

That is why I especially like the nessus reference. Nessus unless directed
not too
will test a linux system for cisco vulnerabilities. As for the configuration
directions
"Use the current version and enable ALL tests (including the dangerous
ones)".
About the only thing I modify when running nessus is the nmap portscan. I
have it go from 1-65535.


George I assume that was your intent.


As for your matrix idea. I like it BUT it might make a nice addition of
condensed
information for a hacker-want2bb.

Of course they could just download nessus and run it against the target
system.

 

Donald.Smith@qwest.com GCIA
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC
(coffee != sleep) & (!coffee == sleep)

> -----Original Message-----
> From: George Jones [mailto:gmj@pobox.com]
> Sent: Thursday, July 31, 2003 12:07 PM
> To: Barbara Fraser
> Cc: opsec@ops.ietf.org
> Subject: Re: Ability to withstand well known attacks (fwd)
> 
> 
> On Wed, 30 Jul 2003, Barbara Fraser wrote:
> 
> > Hi,
> >
> > I think it's very important to clearly state what we're requiring.
> 
> Agreed.
> 
> I think there are actually two requirements here (here we 
> grow again...).
> 
> 1.  That vendors "fix well known vulnerabilities in a timely fashion"
> 
> 2.  That it should not be possible for malicious people to make
>     networking products stop functioning by exploiting well known
>     vulnerabilities.
> 
> Cisco and other vendors spend lots of cycles/$$$ currently doing this.
> It's in the vendors best interests.   It's in the customers 
> best interest.
> All I'm saying is let's codify what's already being done.
> 
> If there are no objections in principal to (1) or (2) or to codifying
> what responsible vendors are already doing, then it seems that the
> only remaining question is how to word it (defining "well known",
> "timely", "fix", etc.).   I'm open to suggestions.
> 
> > For
> > example, we need to clearly describe what sort of attacks. 
> Here are a
> > number of examples of various styles of flooding attacks. 
> Some are destined
> > to the device in question while others are transiting through it.
> 
> I don't think it's useful, or practical, in a document such as this
> to list every attack/vulnerability known at the time of writing.
> This list would be huge and out of date the minute it was written
> (and I sympathize with vendors not wanting to let bug-fixing/hack
> tracking becoming a black hole that eats all development cycles
> and profits).  CERT, CVE, PSIRT, etc do a very nice job tracking/
> listing vulnerabilities.
> 
> As as customer, what I care about is that the box does the job
> that I bought it to do.  That's the customers bottom line.
> 
> I'm more inclined to list the effect of attacks (unmanagable,
> degraded forwarding performance, failure to log) than particular
> attacks or classes of attacks (DoS, buffer overrun, etc.)
> 
> >
> > TCP SYN flood to a listening TCP port
> > Ping flood to an IP address of the device
> > Process/connection exhaustion attack to a listening TCP 
> port on the device
> > Transit SYN flood via the target device to a responsive 
> device beyond the
> > target.
> > Wire-rate transit flood of ICMP echo requests via the 
> target device to an
> > unresponsive device.
> 
> Here's one I know you'll love :-)
> 
> I talked to some people here at MITRE (who have nothing to with CVE)
> before the BOF.  One thing that was suggested was that some of the
> things I have listed under "Vendor Responsiveness" might do well as
> their own group/document with the goal of creating metrics to measure
> such things as how quickly vendors patch bugs....so for instance we
> might have a matrix of CERT advisories crossed with vendors/products
> with time-to-fix as the measured item.
> 
> This is, of course, large.  It would require definition of metrics.
> There would be politics around what bugs to list.   It would require
> the creation (and funding) of a group to monitor compliance.  But
> it would result in usable metrics showing who patches bugs quickly
> and who dosn't.
> 
> I'm not volunteering to lead this one, but if someone's motivated...
> 
> Thanks,
> ---George
>