Re: Ability to withstand well known attacks (fwd)

[George Jones <gmj@pobox.com>]

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