Re: Ability to withstand well known attacks

[Chris Lonvick <clonvick@cisco.com>]

Hi George,

The directive of "just hit it with Nessus" is objectionable.  You don't
specify a version nor do you stipulate any methodology.  The document also
offers no advice on interpreting the results.

To illustrate this, I attempted to do it myself and document the results.
I downloaded the most recent version of Nessus and burned it onto a CD.  I
then took that CD into the lab and threw it at several routers in my rack.
I didn't want to scar the paint so I thought about placing it into a
sleeve or plastic cover.  I decided that would not adhere to the directive
which is to "hit it with Nessus" rather than "hit it with a CD sleeve or
plastic CD case".  The results are:

3620 - minimal impact (due to small exposed area of the front edge of this
       router).
2514 - higher impact (I had to toss it frisbee-style since it is located
       between other routers).
7200 - no impact (the only exposed surface on this router is where the
       blowers expel the air - it diverted the CD.  ..it did hit a PIX
       which made an interesting sound but I don't think that counts in
       this case.)

Do the above results mean that these routers have "passed" this test?  It
would be really difficult but I may be able "hit it with Nessus" at such
an angle as to hit the power switch on the back of the 3620.  If I could
do that would it mean that it "failed" the requirement?

(Please accept the above as intended - with a smile on my face and a
twinkle in my eye.  :-)

Moving back into reality - if you could define the specifics for launching
appropriate Nessus scans and for interpreting the results, how would you
define the system under test?  Running BGP during the scan will give
different results than if BGP is disabled.  Do you want to document all of
the features that should be enabled and the expected result of a scan of
that system so that a novice would be able to look at the results and
determin if it "passed" or "failed"?  What would be the expectation of a
reader of the document if they set up their router in some proscribed
manner and found that it "passed" the test, but then they enabled feature
XYZ which is somehow affected by a Nessus scan?  What do you do if you
find that Nessus version "M" didn't actually check something but that was
fixed in version "N"?

I'll have to say that there are too many variables in the requirement for
it to be an effective test.  Trying to stabalize some of the variables
will require extensive documentation and it could mean the loss of
effectiveness of the test.  I'll say that it is a good direction but I'm
not certain how to quantify the test or the expecations of results.
Thoughts?

Thanks,
Chris




On Tue, 22 Jul 2003, George Jones wrote:

> > 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
>
>
>
>
>