[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ability to withstand well known attacks

Chris Lonvick wrote:


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?
Several.

First, this is a requirements document, not a detailed test plan. I agree that
requiremnts should be testable. I do not agree that it needs to list a 3 to 5
dimensional matrix listing every known version of every product in every
possible configuration crossed with every possible version of all scanning
tools to be useful or testable.

Second, I think that the requirement, in it's current form, gives adequate
guidance for the creation of detailed test plans....I've used it for this purpose.

Third, I am not asking that anyone prove a negative (the absense of bugs)
but merely that known bugs be fixed...I don't think it's reasonable to ignore
the realities of (mostly) full disclosure, public release of exploits and
easy-to-use scanning tools.

I'm guessing that part of the vendor uneasyness comes from the fact
that I'm citing a fairly broad and expansive list of sources (bugtraq,
CVE, nessus plugins, etc)....would the uneasyness go down if, for
example, it just said "CERT advisories" ? It is a question of where
the line is drawn ?

Thanks,
---George


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