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

RE: [TECH] High-level candidates for recent SNMP problems

> From: Steven M. Christey [mailto:coley@LINUS.MITRE.ORG]
> I don't think many people would like to see a single candidate for
> HTTP GET buffer overflows.  

Actually, customer requests are definitely moving us towards
managing our vulnerabilities at two, possibly even three,
levels of abstraction.   From what I can tell, these customer
needs are being driven by the very different ways that 
different customers approach the remediation problem.  

For some, all they want to know is that they have a vulnerable
web server at this particular IP address, in which case a 
single CVE number for HTTP GET BOs would be more than 
sufficient.  For others, they want to tweak the server
into some form of compliance, so they need more specific
info (classic CVE names, for ex.)

"Open" SMB shares is another example that jumps to mind.
Some customers just want to deal with the issue at a fairly
high level of abstraction.  Others want platform specific
information (NT, W2K, Samba...).

We may all be dragged (kicking and screaming, no doubt)
into a CVE language that allows us to better talk at multiple
levels of abstraction.  Time to revive the idea of "dot" 
notation? [Dave ducks under his keyboard]

I suspect this related to "vagueness" issue, btw.


>   We haven't seen vendors actively advertising how many CVE's they
>   check yet, but I think that will happen.

I'm not sure of this, actually.

I sense that the market is evolving away from the old
"check-count" wars, even if it is dressed up in new CVE 
clothing.  Increasingly, we are being asked to provide
standards based solutions (e.g. HIPPA, SANS Top 10,
SANS Top 20, Center for Internet Security, various
OS Vendor standards, etc.).  In this context, CVE is
useful for clarifying the standards and connecting
vague policy statements to specific checks.

The problem here is that, by necessity, these standards
are often written a much higher level of abstraction
than that at which CVE currently operates.

I should note, btw, that without higher level identifiers,
CVE simply will never be useful (to our customers) in some
circumstances.  For example, RAZOR has cataloged, what?, 80ish
vulnerabilities relating to old versions of sendmail.  Specific
CVE names for these old issues might pump up our check count
numbers, but they mean little to nothing to many of our customers.
They are interested in only one thing.  Is their Sendmail up to 
date?  Here, a single, higher level CVE name for outdated Sendmail 
would be more useful.  


Now, on to more pressing issues like, Why has the skiing
been so pitiful here in southern New England?

cheers,

Dave

==============================================================
Dave Mann                ||   e-mail:  dmann@bos.bindview.com
Security Program Manager ||    phone:  508-485-7737   x254
RAZOR Security Team      ||     cell:  617-943-3507
BindView Corporation     ||      fax:  508-485-0737
Page Last Updated or Reviewed: May 22, 2007