Re: Ability to withstand well known attacks (fwd)

[Barbara Fraser <byfraser@cisco.com>]

Hi,

I think it's very important to clearly state what we're requiring. 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.

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. 

Then we'd need to describe the nature of the floods, such as "wire
speed of the fastest interface on the device". 

Barb

At 05:49 AM 7/22/2003, George Jones wrote:
> I ment to BCC this to you on the original
> post, but missed.
>
> I would very much like *your* input on the [un]reasonableness of
> this
> requirement and how to change it to make it useful.
>
> Note the Reply-to:
>
> Thanks,
> ---George
>
> ---------- Forwarded message ----------
> Subject: Ability to withstand well known attacks
> From: George Jones <gmj@pobox.com>
> To: opsec@ops.ietf.org
> Reply-To: opsec@ops.ietf.org
> Date: Tue, 22 Jul 2003 08:07:48 -0400 (EDT)
>
> > OPSEC BOF - Operation Security Requirements for
> > IP Network Elements Session
> >
> > 17 July 2003, IETF #57, Vienna
> >
> > BS: (Bill Somerfeld, Sun) Vendors will have trouble
> >     with 2.3.8.  No vendor could comply
> with
> >     2.3.8, it is too hard as written.  GJ:
> admits that
> >     2.3.8 needs work.  BS: it is also a
> moving target!
>
> OK, this makes two vendors who strenuously objected to this
> requirement.   I'd like feedback/discssion/suggested
> wording.
>
> For the record, the requirement currently reads:
>
> > 2.3.8 Ability to Withstand Well-Known Attacks and Exploits
> >
> >    Requirement. The device MUST have an IP stack and
> operating system
> >       that is robust enough to
> withstand well-known attacks and
> >       exploits. For the purpose of
> this document, well-known attacks and
> >       exploits are defined as those
> that have been published by the
> >       following:
> >
> >       *  Computer Emergency
> Response Team Coordination Center [CERT/CC]
> >         
> Advisories
> >
> >       *  Common Vulnerabilities
> and Exposures [CVE] entries
> >
> >       *  Bugtraq [Bugtraq]
> postings
> >
> >       *  Standard Nessus [Nessus]
> Plugins
> >
> >       *  Vendor security
> bulletins for the device in question.
>
> One of the first things I do with a new bit of equipment is take it
> into the lab and hit it with nessus.  What this requirement is
> saying
> is "if a vendor hands me piece of equipment to test/buy/deploy
> that
> has well known vulnerabilities/exploits, I (as the
> customer/operator/purchaser) will fail it until the know problems
> are
> fixed".   I don't want to buy/use broken/breakable
> systems.
>
> If I'm missing something please point it out.
>
> I think last weeks little bug
> (http://www.cert.org/advisories/CA-2003-15.html)
> and subsequent exploit
> (http://www.cert.org/advisories/CA-2003-17.html)
> are people's exhibit #1 (no intention to pick on the particular
> vendor).   If today, July 22, 2003, said vendor were to bring
> me a new
> piece of equipment for evaluation/deployment, and I were to take it
> into the lab and find that it were vulnerable to CA-2003-15, I 
> would
> tell said vendor to take their equipment back and take a 
> hike....but
> fortunately in this case, said vendor appears to acting very
> responsibly and is all over fixing the problem/mitigating the risk.
>
> I would even argue that a simple nessus (or ISS, or whatever) scan
> could, today, be strongly considered to be a Best Current Practice.
>
> So, help me out.  Show me where this is not reasonable and/or
> suggest
> better wording.
>
> ---George