Re: Ability to withstand well known attacks

[ericb@digitaljunkyard.net]

 "cl" == Chris Lonvick <clonvick@cisco.com> writes:

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

Intentionally.  This is a moving target, and specifying a version of
nessus, or a set of plugins would immediately date the doc.

As new badness is discovered on the Internet, it must be fixed in
every device to which it is applicable.

I know that "applicable" above opens a can of worms....  I would like
to throw myself on the goodwill of the industry, the belief that
vendors will do the right thing without prompting.  That has not been
history.  So...  This area still needs work.

cl> Moving back into reality - if you could define the specifics for launching
cl> appropriate Nessus scans and for interpreting the results, how would you
cl> define the system under test?  Running BGP during the scan will give
cl> different results than if BGP is disabled.  Do you want to document all of

Nope, should get the same results.  If BGP is disabled, the router
should not be vulnerable to any known attacks.  If BGP is enabled, the
router should not be vulnerable to any known attacks.

Of course, Nessus has a lot of plugins that are mostly useless.  it'll
flag SNMP public as a violation, even if that's an acceptable design
in your network.  Clearly, we need to better define the class of
attacks to which the device must be invulnerable.

How about: 

1) ANY priv elevation attack

2) ANY unauthorized remote access attack.  SNMP public does not fall
   under this, as knowing the "secret" public authorizes you,
   according to the SNMP protocol.

3) ANY non-flood DOS attack.  It's impossible to protect a device from
   a 100% flood on all interfaces.  There's nothing it can do to
   prevent itself from dropping out of service.  This basically
   addresses crafted packet attacks.

cl> the features that should be enabled and the expected result of a scan of
cl> that system so that a novice would be able to look at the results and
cl> determin if it "passed" or "failed"?  What would be the expectation of a

Not at all!  If we were trying to write this for a novice, it would
not be the same document.  This is written for engineering test labs
and vendors, both of which are assumed to have a clue.  We should not
have to include a Nessus screen shot.  Something along the lines of
"The device was not vulnerable to any attacks that caused (see above)"
should be sufficient.

Can I knock your device over, or own it?  Yes, it fails.  No, it
passes.

cl> reader of the document if they set up their router in some proscribed
cl> manner and found that it "passed" the test, but then they enabled feature
cl> XYZ which is somehow affected by a Nessus scan?  What do you do if you
cl> find that Nessus version "M" didn't actually check something but that was
cl> fixed in version "N"?

This is a moving target.  It is expected that the testers (vendor and
customer) keep up to date with their vulnerability lists.  There is no
proscribed manner.  ANY config of the router should result in a box
that CANNOT be knocked over or broken into.

Also, nowhere in this document did George claim that Nessus (or any
other tool) was an appropriate method of determining if a device met
this requirement or not.  He merely cited Nessus as a good source of
vulnerabilities that are available on the 'Net, and currently in the
hands of miscreants.  The device must not be vulnerable to attack, not
the device must pass Nessus.

It is beyond the scope of this document to tell people HOW to test
their equipment.  We're just telling them that they have to have the
basics covered.  If your box reboots when it gets overlapping IP
segments, don't even bother shipping it.

One massive mess is code versioning.  I know that Cisco suffers
greatly here, with a roughly infinite number of code versions and
platforms.  I do not expect every known vulnerability to be patched in
every IOS image.  But I think it is a reasonable compromise point that
every new version of code be patched for all vulnerabilities that were
known at the time of it's inception.

Vendor responsiveness for new vulnerabilities is addressed elsewhere.

People's exhibit #1 is a prime example.  If I pull a router out of the
warehouse, it'll fail.  That's my fault for not updating it's code.
If I test that router with Nessus, it will pass.  That's my fault for
using an old test tool.  The customer is not without responsibility
for their own security.

But if I get a router 3 months from now, with shiny new code on it
(which I immediately update to the latest rev), and I run my hand
crafted Cisco sploit, it better pass.  And it better not reboot when I
hit it with land.c, or teardrop, or stuff 4000 chars down the telnet
login prompt, etc.

I don't think we're asking for anything unreasonable here, we just
need to refine the language a bit.

And stop throwing CDs.  You'll put someone's eye out.

ericb