Mailing List Archive

Open Letter on the Interpretation of "Vulnerability Statistics"
Open Letter on the Interpretation of "Vulnerability Statistics"
---------------------------------------------------------------
Author: Steve Christey, CVE Editor
Date: January 4, 2006


All,

As the new year begins, there will be many temptations to generate,
comment, or report on vulnerability statistics based on totals from
2005. The original reports will likely come from publicly available
Refined Vulnerability Information (RVI) sources - that is,
vulnerability databases (including CVE/NVD), notification services,
and periodic summary producers.

RVI sources collect unstructured vulnerability information from Raw
Sources. Then, they refine, correlate, and redistribute the
information to others. Raw sources include mailing lists like
Bugtraq, Vulnwatch, and Full-Disclosure, web sites like PacketStorm
and Securiteam, blogs, conferences, newsgroups, direct emails, etc.

In my opinion, RVI sources are still a year or two away from being
able to produce reliable, repeatable, and COMPARABLE statistics. In
general, consumers should treat current statistics as suggestive, not
conclusive.

Vulnerability statistics are difficult to interpret due to several
factors:

- VARIATIONS IN EDITORIAL POLICY. An RVI source's editorial policy
dictates HOW MANY vulnerabilities are reported, and WHICH
vulnerabilities are reported. RVIs have widely varying policies.
You can't even compare an RVI against itself, unless you can be
sure that its editorial policy has not changed within the relevant
data set. The editorial policies of RVIs seem to take a few years
before they stabilize, and there is evidence that they can change
periodically.

- FRACTURED VULNERABILITY INFORMATION. Each RVI source collects its
information from its own list of raw sources - web sites, mailing
lists, blogs, etc. RVIs can also use other RVIs as sources.
Apparently for competitive reasons, some RVIs might not identify
the raw source that was used for a vulnerability item, which is one
aspect of what I refer to as the provenance problem. Long gone are
the days when a couple mailing lists or newsgroups were the raw
source for 90% of widely available vulnerability information.
Based on what I have seen, the provenance problem is only going to
get worse.

- LACK OF COMPLETE CROSS-REFERENCING BETWEEN RVI SOURCES. No RVI has
an exhaustive set of cross-references, so no RVI can be sure that
it is 100% comprehensive, even with respect to its own editorial
policy. Some RVIs compete with each other directly, so they don't
cross-reference each other. Some sources could theoretically
support all public cross-references - most notably OSVDB and CVE -
but they do not, due to resource limitations or other priorities.

- UNMEASURABLE RESEARCH COMMUNITY BIAS. Vulnerability researchers
vary widely in skill sets, thoroughness, preference for certain
vulnerability types or product classes, and so on. This
collectively produces a bias that is not currently measurable
against the number of latent vulnerabilities that actually exist.
Example: web browser vulnerabilities were once thought to belong to
Internet Explorer only, until people actually started researching
other browsers; many elite researchers concentrate on a small
number of operating systems or product classes; basic SQL injection
and XSS are very easy to find manually; etc.

- UNMEASURABLE DISCLOSURE BIAS. Vendors and researchers vary widely
in their disclosure models, which creates an unmeasurable bias.
For example, one vendor might hire an independent auditor and patch
all reported vulnerabilities without publicly announcing any of
them, or a different vendor might publish advisories even for very
low-risk issues. One researcher might disclose without
coordinating with the vendor at all, whereas another researcher
might never disclose an issue until a patch is provided, even if
the vendor takes an inordinate amount of time to respond.

Note that many large-scale comparisons, such as "Linux vs. Windows,"
can not be verified due to unmeasurable bias, and/or editorial policy
of the core RVI that was used to conduct the comparison.


EDITORIAL POLICY VARIATIONS
---------------------------

This is just a sample of variations in editorial policy. There are
legitimate reasons for each variation, usually due to audience needs
or availability of analytical resources.

COMPLETENESS (what is included):

1) SEVERITY. Some RVIs do not include very low-risk items such as a
bug that causes path disclosure in an error message in certain
non-operational configurations. Secunia and SecurityFocus do not
do this, although they might note this when other issues are
identified. Others include low-risk issues, such as CVE, ISS
X-Force, US-CERT Security Bulletins, and OSVDB.

2) VERACITY. Some RVIs will only publish vulnerabilities when they
are confident that the original, raw report is legitimate - or if
they're verified it themselves. Others will publish reports when
they are first detected from the raw sources. Still others will
only publish reports when they are included in other RVIs, which
makes them subject to the editorial policies of those RVIs unless
care is taken. For example, US-CERT's Vulnerability Notes have a
high veracity requirement before they are published; OSVDB and
CVE have a lower requirement for veracity, although they have
correction mechanisms in place if veracity is questioned, and CVE
has a two-stage approach (candidates and entries).

3) PRODUCT SPACE. Some RVIs might omit certain products that have
very limited distribution, are in the beta development stage, or
are not applicable to the intended audience. For example,
version 0.0.1 of a low-distribution package might be omitted, or
if the RVI is intended for a business audience, video game
vulnerabilities might be excluded. On the other hand, some
"beta" products have extremely wide distribution.

4) OTHER VARIATIONS. Other variations exist but have not been
studied or categorized at this time. One example, though, is
historical completeness. Most RVIs do not cover vulnerabilities
before the RVI was first launched, whereas others - such as CVE
and OSVDB - can include issues that are older than the RVI
itself. As another example: a few years ago, Neohapsis made an
editorial decision to omit most PHP application vulnerabilities
from their summaries, if they were obscure products, or if the
vulnerability was not exploitable in a typical operational
configuration.

ABSTRACTION (how vulnerabilities are "counted"):

5) VULNERABILITY TYPE. Some RVIs distinguish between types of
vulnerabilities (e.g. buffer overflow, format string, symlink,
XSS, SQL injection). CVE, OSVDB, ISS X-Force, and US-CERT
Vulnerability Notes perform this distinction; Secunia, FrSIRT,
and US-CERT Cyber Security Bulletins do not. Bugtraq IDs vary.
As vulnerability classification becomes more detailed, there is
more room for variation (e.g. integer overflows and off-by-ones
might be separated from "classic" overflows).

6) REPLICATION. Some RVIs will produce multiple records for the
same core vulnerability, even based on the RVI's own definition.
Usually this is done when the same vulnerability affects multiple
vendors, or if important information is released at a later date.
Secunia and US-CERT Security Bulletins use replication; so might
vendor advisories (for each supported distribution). OSVDB,
Bugtraq ID, CVE, US-CERT Vulnerability Notes, and ISS X-Force do
not - or, they use different replication than others.
Replication's impact on statistics is not well understood.

7) OTHER VARIATIONS. Other abstraction variations exist but have
not been studied or categorized at this time. As one example, if
an SQL injection vulnerability affects multiple executables in
the same product, OSVDB will create one record for each affected
program, whereas CVE will combine them.

TIMELINESS:

8) RVIs differ in how quickly they must release vulnerability
information. While this used to vary significantly in the past,
these days most public RVIs have very short timelines, from the
hour of release to within a few days. Vulnerability information
can be volatile in the early stages, so an RVI's requirements for
timeliness directly affects its veracity and completeness.

REALITY:

9) All RVIs deal with limited resources or time, which significantly
affects completeness, especially with respect to veracity, or
timeliness (which is strongly associated with the ability to
achieve completeness). Abstraction might also be affected,
although usually to a lesser degree, except in the case of
large-scale disclosures.


Conclusion
----------

In my opinion:

You should not interpret any RVI's statistics without considering its
editorial policy. For example, the US-CERT Cyber Security Bulletin
Summary for 2005 uses statistics that include replication. (As a side
note, a causal glance at the bulletin's contents makes it clear that
it cannot be used to compare Windows to Linux as operating systems.)

In addition, you should not compare statistics from different RVIs
until (a) the RVIs are clear about their editorial policy and (b) the
differences in editorial policy can be normalized. Example: based on
my PRELIMINARY investigations of a few hours' work, OSVDB would have
about 50% more records than CVE, even though it has the same
underlying number of vulnerabilities and the same completeness policy
for recent issues.

Third, for the sake of more knowledgeable analysis, RVIs should
consider developing and publishing their own editorial policies.
(Note that based on CVE's experience, this can be difficult to do.)
Consumers should be aware that some RVIs might not be open about their
raw sources, veracity analysis, and/or completeness.

Finally: while RVIs are not yet ready to provide usable, conclusive
statistics, there is a solid chance that they will be able to do so in
the near future. Then, the only problem will be whether the
statistics are properly interpreted. But that is beyond the scope of
this letter.


Steve Christey
CVE Editor

P.S. This post was written for the purpose of timely technical
exchange. Members of the press are politely requested to consult me
before directly attributing quotes from this article, especially with
respect to stated opinion.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Thu, Jan 05, 2006 at 02:12:32AM -0500, Steven M. Christey wrote:
>
> Open Letter on the Interpretation of "Vulnerability Statistics"
> ---------------------------------------------------------------


>Refined Vulnerability Information (RVI)

hahaha, buzz word?

>that is vulnerability databases (including CVE/NVD)

hahaha:
http://cve.mitre.org/about/
A Dictionary, NOT a Database
(note the CAPS)
so which way is it "NOT" or "A database"?

rumors says the bsa/*aa may be after you for copyright infringment and
illegal reverse engineering. irresponsible of you, bad dog!

> RVI sources collect unstructured vulnerability information from Raw
> Sources.

read: parasites cut and paste from people who can do things.

> - LACK OF COMPLETE CROSS-REFERENCING BETWEEN RVI SOURCES.

read: coley does not like it that there is no officially recognized
usa funded database (NOT a dictionary) to rule em all and manipulate
statistics.

--
where do you want bill gates to go today?





















_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Fri, 6 Jan 2006, Georgi Guninski wrote:

> hahaha:
> http://cve.mitre.org/about/
> A Dictionary, NOT a Database
> (note the CAPS)
> so which way is it "NOT" or "A database"?

Hi Georgi, I've missed you.

According to the definitions proposed by Brian Martin of OSVDB, CVE is in
fact a database - HOWEVER it is a highly specialized one intended for
correlation and comparison across multiple tools and products. That said,
90% of its consumers do not use it for that reason. The FAQ should
probably be rephrased a bit.

> > RVI sources collect unstructured vulnerability information from Raw
> > Sources.
>
> read: parasites cut and paste from people who can do things.

Actually, they frequently augment the original work, especially if it
suffers from the Four I's problem - inconsistent, inaccurate, incomplete,
and/or incomprehensible. Well-researched advisories like yours are the
exception, not the rule.

Every "RVI" or, if you wish, "database" provides extra value beyond what
is originally published. Raw sources include lots of poorly written or
inaccurate advisories without any vendor fix information. RVIs sort
through the cruft and produce something that is more usable to the average
consumer, often conducting additional analysis or interacting with the
affected vendor.

The average consumer does not have the time or the expertise to sift
through hundreds of information pieces from dozens of sources.

> > - LACK OF COMPLETE CROSS-REFERENCING BETWEEN RVI SOURCES.
>
> read: coley does not like it that there is no officially recognized
> usa funded database (NOT a dictionary) to rule em all and manipulate
> statistics.

Of course statistics can be manipulated any way you want to. But CVE is,
as far as I know, the only RVI that has attempted to document and publish
at least part of its editorial policy, in the form of its content
decisions - *and* those content decisions received heavy review and
feedback by members of the CVE Editorial Board.

CVE and, I believe, OSVDB would like to achieve complete
cross-referencing. This is a laudable goal but more resource-intensive
than currently allowed. Most other RVI's cannot do this because they
compete with each other.

I personally want solid, accurate, complete vulnerability information that
can be independently reviewed and replicated. In the areas where most
researchers fail to do this, RVI sources can help.

- Steve
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Fri, Jan 06, 2006 at 02:53:56PM -0500, Steven M. Christey wrote:
> According to the definitions proposed by Brian Martin of OSVDB, CVE is in
> fact a database - HOWEVER it is a highly specialized one intended for
> correlation and comparison across multiple tools and products. That said,
> 90% of its consumers do not use it for that reason. The FAQ should
> probably be rephrased a bit.
>

hahahahahaha, "a responsibility rfc government funded
expert" wrote.

http://lists.grok.org.uk/pipermail/full-disclosure/2003-August/008386.html
>>So you are collecting 0days for free, put them in a lame database and
>>whine more than a script kiddie this is a hard job?

>I don't view it that way.
>
>1) CVE is not a vulnerability database, per the FAQ on the CVE web
> site at http://cve.mitre.org/about/faq.html#A7 (though we are not
> blind to the fact that some people try to use it as a database
> anyways).

--
where do you want bill gates to go today?













































junk:
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
*shrug* things change in 2.5 years. The answer is fundamentally the same,
only I've given up being pedantic about the terminology.

Since your criticism of CVE and the vuln DB world has not changed in 2.5
years (and neither has my defense of it), perhaps we should agree to
disagree and be done with it.

On Fri, 6 Jan 2006, Georgi Guninski wrote:

> On Fri, Jan 06, 2006 at 02:53:56PM -0500, Steven M. Christey wrote:
> > According to the definitions proposed by Brian Martin of OSVDB, CVE is in
> > fact a database - HOWEVER it is a highly specialized one intended for
> > correlation and comparison across multiple tools and products. That said,
> > 90% of its consumers do not use it for that reason. The FAQ should
> > probably be rephrased a bit.
> >
>
> hahahahahaha, "a responsibility rfc government funded
> expert" wrote.
>
> http://lists.grok.org.uk/pipermail/full-disclosure/2003-August/008386.html
> >>So you are collecting 0days for free, put them in a lame database and
> >>whine more than a script kiddie this is a hard job?
>
> >I don't view it that way.
> >
> >1) CVE is not a vulnerability database, per the FAQ on the CVE web
> > site at http://cve.mitre.org/about/faq.html#A7 (though we are not
> > blind to the fact that some people try to use it as a database
> > anyways).
>
> --
> where do you want bill gates to go today?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> junk:
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
* Georgi Guninski:

>> RVI sources collect unstructured vulnerability information from Raw
>> Sources.
>
> read: parasites cut and paste from people who can do things.

A service which assigns a primary key shared by multiple databases is
quite helpful. Of course, you can dismiss this whole vulnerability
tracking/patching thing as completely pointless, and I wouldn't even
disagree with you. 8-)

>> - LACK OF COMPLETE CROSS-REFERENCING BETWEEN RVI SOURCES.
>
> read: coley does not like it that there is no officially recognized
> usa funded database (NOT a dictionary) to rule em all and manipulate
> statistics.

Uhm, CVE itself adds cross-references to other databases, even to a
non-US one, so I don't think this is a valid criticism.

Unlike PKI or DNS, vulnerability naming does not need to be universal
to be useful. It does not suffer from the Highlander problem.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
so you approve gaining pseudo credibility by practicing mouse copy/paste?

then this pseudo credibility leads to corporate serving/licking like:
"responsible disclosure rfc" - search for it.

not than coley is consistent at all (besides lacking completeness):
http://www.cve.mitre.org/board/archives/2002-02/msg00026.html
-------------------
- The Board has agreed that CNAs should not reserve candidates for
people who do not practice responsible disclosure (candidates would
be assigned *after* publication). I hope that this document, or a
later version, will become part of the "definition" of responsible
disclosure.
-------------------

--
where do you want bill gates to go today?

<end_of_message>







































junk


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
* Georgi Guninski:

> so you approve gaining pseudo credibility by practicing mouse copy/paste?
>
> then this pseudo credibility leads to corporate serving/licking like:
> "responsible disclosure rfc" - search for it.
>
> not than coley is consistent at all (besides lacking completeness):
> http://www.cve.mitre.org/board/archives/2002-02/msg00026.html
> -------------------
> - The Board has agreed that CNAs should not reserve candidates for
> people who do not practice responsible disclosure (candidates would
> be assigned *after* publication). I hope that this document, or a
> later version, will become part of the "definition" of responsible
> disclosure.
> -------------------

Yes, this puzzles me too, but on the other hand, Debian became a CNA,
and Debian's official policy is geared away from "responsible
disclosure" -- all bug reports are supposed to be public.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
RE: location [ In reply to ]
Someone needs to have Neohapsis update their information:

http://archives.neohapsis.com/archives/fulldisclosure/
Official archives: http://lists.netsys.com/pipermail/full-disclosure/

How to subscribe to this list:
View http://lists.netsys.com/mailman/listinfo/full-disclosure

Address to post to this list:
full-disclosurelists.netsys.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: location [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

looks like you also need to update yourself randall m :> here are
correct links:

Official archives: http://lists.grok.org.uk/pipermail/full-disclosure/
Charter: http://lists.grok.org.uk/full-disclosure-charter.html

How to subscribe to this list:
View https://lists.grok.org.uk/mailman/listinfo/full-disclosure

Address to post to this list:
full-disclosure@lists.grok.org.uk



Randall M wrote:
> Someone needs to have Neohapsis update their information:
>
> http://archives.neohapsis.com/archives/fulldisclosure/
> Official archives: http://lists.netsys.com/pipermail/full-disclosure/
>
> How to subscribe to this list:
> View http://lists.netsys.com/mailman/listinfo/full-disclosure
>
> Address to post to this list:
> full-disclosurelists.netsys.com
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
>
> .
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iQIVAwUBQ7/w0q+LRXunxpxfAQK7HQ/9HcT72Wo+6VCaZ9Hz0B20aVE/meX8dssB
iq8vRw6GIda2cJai8FImNn5hXNR/dQG2f+Gbdq1S1YvsfoJcd4w/0mWCzxzCcNS3
+jym6jy7H3Zj2BzLX7JoqWZ7Fv+ePAueGinqWZ8kLHUge6rnPpew57NWkUfS2CfF
oI+GBYjILKJRK7eqZZQkM2S2lQcIGZ4ZiaSfEcZT2IBOiIsHarwkT1H/6hEglVki
Z2dbr1Ht6wFGwHW5wyFo+jPfPXfN16PetF+Jkwu3wh9l6TVhE3ceLbV1pVheDVBC
Aflrkv/otWPqujSCl3MVa6SrfSeaULouuTH2kW5DkT+8Gp1NMHckSt5SNz7khxYx
RJrmt+9bv/32/KKBTEPh9kVCR2OM/VaCvI4LYK2z3Hw694rKCJkz9DZ13oPbHtJ8
4YxjySasxwoN0TVMeMY9KcLVDmGWxCB9VaEP8Psfu5y3kmrzX66aSJCC7dLb7/9v
f5pt/JMs/9B+pIykRBXiK8K/oslA0+2oxuEEd10CQQjYxkaIRh89RE7BUfAcYqxe
ARnAvBqPxuardC8bQAVGJ2N2Ru2S2ejOYWY1Cn3Q1nqvKKCAEiRtZktu89oS5Bzh
7cLe4jmjfoTRdM1rk51rKmMSArplMEGOuprcjOKttXfI4Vftws6sIWeNvLetNBp6
29PduO28Gd4=
=9CnM
-----END PGP SIGNATURE-----


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Sat, Jan 07, 2006 at 04:59:48PM +0100, Florian Weimer wrote:
> * Georgi Guninski:
>
> > so you approve gaining pseudo credibility by practicing mouse copy/paste?
> >
> > then this pseudo credibility leads to corporate serving/licking like:
> > "responsible disclosure rfc" - search for it.
> >
> > not than coley is consistent at all (besides lacking completeness):
> > http://www.cve.mitre.org/board/archives/2002-02/msg00026.html
> > -------------------
> > - The Board has agreed that CNAs should not reserve candidates for
> > people who do not practice responsible disclosure (candidates would
> > be assigned *after* publication). I hope that this document, or a
> > later version, will become part of the "definition" of responsible
> > disclosure.
> > -------------------
>
> Yes, this puzzles me too, but on the other hand, Debian became a CNA,
> and Debian's official policy is geared away from "responsible
> disclosure" -- all bug reports are supposed to be public.


i am surprised that the debian constitution allows participation in such
shady organizations.

the open source crowd can easily setup a cross open vendor database and the
first one of the eleet them to learn of a bug to paste with the mouse.

but for strange reasons vendor-sec@lst.de seems to like mitre.

--
where do you want bill gates to go today?

<end_of_message>









































_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Sat, 7 Jan 2006, Georgi Guninski wrote:

> - The Board has agreed that CNAs should not reserve candidates for
> people who do not practice responsible disclosure (candidates would
> be assigned *after* publication). I hope that this document, or a
> later version, will become part of the "definition" of responsible
> disclosure.

This has also somewhat evolved over time.

"Responsible disclosure" or "coordinated disclosure" or whatever you want
to call it is one of the best ways to ensure there is actionable, accurate
non-duplicated information at the time of disclosure. If you don't
coordinate with a vendor, then your advisory will not have vendor fix
information, the list of affected versions might be incomplete, the
underlying bug diagnosis might be missing or wrong, and the only
actionable items might be to reduce the affected functionality or use
another product, which is not necessarily feasible in an organization with
more than, say, 100 machines.

This kind of information is important for assigning the correct number of
candidates to an issue.

Florian - I don't see an incompatibility in Debian's approach. Before
publication, Debian interacts with the vendor (i.e. itself and probably
the maintainer).

- Steve
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On 1/6/06, Steven M. Christey <coley@linus.mitre.org> wrote:
>
> *shrug* things change in 2.5 years. The answer is fundamentally the same,
> only I've given up being pedantic about the terminology.

Yes *most* things change but Guninski will never grow up.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Sat, 07 Jan 2006 16:17:29 PST, InfoSecBOFH said:
> On 1/6/06, Steven M. Christey <coley@linus.mitre.org> wrote:
> >
> > *shrug* things change in 2.5 years. The answer is fundamentally the same,
> > only I've given up being pedantic about the terminology.
>
> Yes *most* things change but Guninski will never grow up.

And you will never post something that actually contributes, so I guess
you and George are even...
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
Actually George and is one up on me because he also posts nothing of
value anymore. So here is a question, do you suck every former and
undeserved internet rock star's dick on this list or just the
eurotrash ones?

On 1/7/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Sat, 07 Jan 2006 16:17:29 PST, InfoSecBOFH said:
> > On 1/6/06, Steven M. Christey <coley@linus.mitre.org> wrote:
> > >
> > > *shrug* things change in 2.5 years. The answer is fundamentally the same,
> > > only I've given up being pedantic about the terminology.
> >
> > Yes *most* things change but Guninski will never grow up.
>
> And you will never post something that actually contributes, so I guess
> you and George are even...
>
>
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
i admit i am just a *retired* old lamer.

you win the flame and the ego contest.

--
where do you want bill gates to go today?

On Sun, Jan 08, 2006 at 04:55:04PM -0800, InfoSecBOFH wrote:
> Actually George and is one up on me because he also posts nothing of
> value anymore.

<end_of_message>













































_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Sat, Jan 07, 2006 at 04:59:48PM +0100, Florian Weimer wrote:
> * Georgi Guninski:
>
> > so you approve gaining pseudo credibility by practicing mouse copy/paste?
> >
> > then this pseudo credibility leads to corporate serving/licking like:
> > "responsible disclosure rfc" - search for it.
> >
> > not than coley is consistent at all (besides lacking completeness):
> > http://www.cve.mitre.org/board/archives/2002-02/msg00026.html
> > -------------------
> > - The Board has agreed that CNAs should not reserve candidates for
> > people who do not practice responsible disclosure (candidates would
> > be assigned *after* publication). I hope that this document, or a
> > later version, will become part of the "definition" of responsible
> > disclosure.
> > -------------------
>
> Yes, this puzzles me too, but on the other hand, Debian became a CNA,
> and Debian's official policy is geared away from "responsible
> disclosure" -- all bug reports are supposed to be public.

Debian isn't a CNA; as far as I know, it isn't possible for organizations to
become CNAs. Some of the people in security-related roles in Debian are
also (individually) CNAs.

Additionally, Debian has traditionally participated in coordinated
disclosure, before CVE existed.

--
- mdz
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Sun, 08 Jan 2006 16:55:04 PST, InfoSecBOFH said:
> Actually George and is one up on me because he also posts nothing of
> value anymore. So here is a question, do you suck every former and
> undeserved internet rock star's dick on this list or just the
> eurotrash ones?

I wonder what percent of the list is hoping you live in the US:

http://news.com.com/Create+an+e-annoyance%2C+go+to+jail/2010-1028_3-6022491.html?part=rss&tag=6022491&subj=news
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
I wonder how many care?

On 1/9/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Sun, 08 Jan 2006 16:55:04 PST, InfoSecBOFH said:
> > Actually George and is one up on me because he also posts nothing of
> > value anymore. So here is a question, do you suck every former and
> > undeserved internet rock star's dick on this list or just the
> > eurotrash ones?
>
> I wonder what percent of the list is hoping you live in the US:
>
> http://news.com.com/Create+an+e-annoyance%2C+go+to+jail/2010-1028_3-6022491.html?part=rss&tag=6022491&subj=news
>
>
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
And how many cares about you... rat!

I love when ppl try to show his opinion ... without contributing nothing
significant...

maybe they themselves feel important.... lol


On 1/10/06, InfoSecBOFH <infosecbofh@gmail.com> wrote:
>
> I wonder how many care?
>
> On 1/9/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> > On Sun, 08 Jan 2006 16:55:04 PST, InfoSecBOFH said:
> > > Actually George and is one up on me because he also posts nothing of
> > > value anymore. So here is a question, do you suck every former and
> > > undeserved internet rock star's dick on this list or just the
> > > eurotrash ones?
> >
> > I wonder what percent of the list is hoping you live in the US:
> >
> >
> http://news.com.com/Create+an+e-annoyance%2C+go+to+jail/2010-1028_3-6022491.html?part=rss&tag=6022491&subj=news
> >
> >
> >
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
* Matt Zimmerman:

>> Yes, this puzzles me too, but on the other hand, Debian became a CNA,
>> and Debian's official policy is geared away from "responsible
>> disclosure" -- all bug reports are supposed to be public.
>
> Debian isn't a CNA; as far as I know, it isn't possible for
> organizations to become CNAs.

<http://cve.mitre.org/cve/cna.html#cnas> lists organizations, not
individuals. The requirements are clearly geared towards
organizations, too.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
On Thu, Jan 12, 2006 at 12:15:35AM +0100, Florian Weimer wrote:
> * Matt Zimmerman:
>
> >> Yes, this puzzles me too, but on the other hand, Debian became a CNA,
> >> and Debian's official policy is geared away from "responsible
> >> disclosure" -- all bug reports are supposed to be public.
> >
> > Debian isn't a CNA; as far as I know, it isn't possible for
> > organizations to become CNAs.
>
> <http://cve.mitre.org/cve/cna.html#cnas> lists organizations, not
> individuals. The requirements are clearly geared towards
> organizations, too.

Unless things have changed since I went through the process, the authority
involved does not extend to Debian in general but only to specific
individuals.

--
- mdz
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
* Matt Zimmerman:

>> <http://cve.mitre.org/cve/cna.html#cnas> lists organizations, not
>> individuals. The requirements are clearly geared towards
>> organizations, too.
>
> Unless things have changed since I went through the process, the authority
> involved does not extend to Debian in general but only to specific
> individuals.

Certainly, at Debian, only certain individuals issue CVEs. I can't
tell if this is Debian's choice, or a result of MITRE's rules.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Open Letter on the Interpretation of "Vulnerability Statistics" [ In reply to ]
Florian Weimer said:

>> Unless things have changed since I went through the process, the
>> authority involved does not extend to Debian in general but only to
>> specific individuals.
>
>Certainly, at Debian, only certain individuals issue CVEs. I can't
>tell if this is Debian's choice, or a result of MITRE's rules.

Like some other aspects of CVE, there is a distinct lack of
distinction between individuals and organizations. In the case of
these Candidate Numbering Authorities (CNAs), a specific individual at
the CNA goes through some period of training to ensure that he/she
learns how to assign the proper number of identifiers in accordance
with CVE's content decisions. Usually this training is for a specific
individual of the organization. But as long as the CNA collectively
follows CVE's content decisions when it assigns identifiers, how it
"implements" those actions is not within CVE's purview. For example,
Red Hat and CERT are two other organizations that have multiple people
assigning CVE identifiers.

- Steve
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/