[VIM] r0t on "bugtraqs @ all"

[Steven M. Christey]

On Tue, 20 Jun 2006, Mark J Cox wrote:

> The kernel is a good example though, where every enterprise vendor is
> backporting a subset of issues that affect that version to their stable
> base versions, where the base versions used by vendors are different.
> That subset of issues fixed may be chosen due to the risk of each issue
> (for example, an issue with a low security impact but requiring major code
> changes may be deffered for a future update to allow it to gain more
> testing).
>
> So when we backport our internal processes benefit from splitting (and
> having a consistant set of rules applied for that splitting), and it helps
> our customers understand things too.

Do you have customers who are knowledgeable and detailed enough to want
that kind of precision?

Come to think of it, this is another reason why you can't compare Linux
and Windows vulnerability counts - yes, Ethereal has many issues, but the
Linux kernel bugs are frequently handled one-by-one (at least from the CVE
perspective), even for minor version changes, whereas major Windows OS bug
fixes are frequently wrapped in a large service pack, and CVE is not
requested on a per-bug basis in that fashion (and we usually don't catch
them unless another vuln DB does, the one exception being whatever post to
VIM I made last spring or so.)  Combine that with some of Steve Manzuik et
al's recent work and make your own conclusions.

> But really it's these reports that are broken, not CVE.

People want rational answers to the "measurable security" problem, and I
don't blame them, so they're going to go where the data is.  At least the
data is repeatable (and/or refutable) since a public identifier is being
used, but you'd have the same problem with any public vuln DB.  It's the
difference in disclosure practices that's the biggest factor.  Frankly, I
don't know how this problem can be resolved, and when there are so few
analyses that one of the main contributors to this area is a member of the
press instead of a mathematician/computer scientist, well, that sounds
like we've got a long way to go.

Uh-oh, sounds like evolving disclaimer time.

- Steve

=======================================================================

Disclaimer: This message was publicly posted for the purpose of timely
technical information exchange with the ultimate goal of improving the
state of computer security.  It may contain errors, omissions, or
imprecise conversational tone.  Stated opinions are those of Steve
Christey and may vary as he learns over time.  They do not necessarily
reflect the views of The MITRE Corporation.  Members of the press are
requested to refrain from quoting this message without first
consulting with me.