Re: Ability to withstand well known attacks

["George M. Jones" <gmjones@mitre.org>]

Bill Sommerfeld wrote:

> > 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.
> >    
> RFCs can be used as standards; customers generally want vendors to
> claim compliance to a standard.
>
> The problem with the current text is that *as new exploits* are
> discovered, past claims of compliance with section 2.3.8 are
> retroactively invalidated because 2.3.8 is a continuously moving
> target.
I would argue that both vendors and customers recognize the importance
of this requiremnt.   Vendors that are responsive to their customers
and/or acting in a socially responsible way area already attempting
to conform to this requirement.    All you need to do to see this is
to look at CERT advisories and look at the list of mitigation steps/
new code releases provided by vendors.

> We need language which recognizes this fluid nature.
So, given that vendors are already doing this, in varying degrees, what
wording would be acceptable to codify existing practice, while still
providing a "hammer" hammer to be used against sluggards who still
have 15 year old buffer overflows ?

> Bold but brittle claims of total invulnerability to all known attacks
> won't help anyone (except maybe the lawyers once lawsuits start
> flying..)
Agreed.

> With respect to one particular source:
>
>  
> >      *  Bugtraq [Bugtraq] postings
> >    
> A lot of good info goes by on that list, but there's also a fair
> amount of chaff and trash talk on bugtraq; not all the postings
> describe known vulnerabilities.  I don't see an objective standard for
> how to evaluate whether a bugtraq post describes a "known attack".
>
> bugtraq posts could be one input to an organization which maintains a
> known vulnerability list; they themselves are not such a list.
Agreed.   See http://www.securityfocus.org/bid

In retrospect, the list of sources of vulnerabilities (CERT, CVE...) 
should probably move to
the examples section...this list is not intended to be 
authoritative....and in fact, I beleive that
the "authoritative" sources of vulnerabilities will change over 
time...but the requirement,
not being vulnerabile to "well known" exploits....will not change.

One other change that might help:  splitting the doc into functional, 
documentation and assurance
requirements and moving this one to assurance....it is closely related 
to 2.14.1 ("Vendor Responsiveness"),
which is also non-functional.

Thoughts ?   Rewording suggestions ?

Thanks,
---George