
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Welcome Harold Booth to the CVE Editorial Board
- To: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
- Subject: Welcome Harold Booth to the CVE Editorial Board
- From: "Mann, Dave" <damann@mitre.org>
- Date: Wed, 11 Jan 2012 21:41:28 +0000
- Accept-Language: en-US
- Delivery-Date: Wed Jan 11 16:42:07 2012
- List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
- List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
- List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
- List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
- Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
- Thread-Index: AczQqWBr8rLs8YsiTLao4+tdTbMfkw==
- Thread-Topic: Welcome Harold Booth to the CVE Editorial Board
All,
It is with great pleasure that I can inform you that Harold Booth has joined the CVE Editorial Board. Harold manages NIST's National Vulnerability Database and brings many years of vulnerability analysis and content management experience to CVE. We are delighted to have him on board.
By way of reminder, organizations are allowed to have up to two representatives on the CVE Editorial Board at any given time. Harold joins Peter Mell, also from NIST.
-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:damann@mitre.org | cell:781.424.6003
==================================================================
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Wed Mar 7 14:54:37 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q27Jsap4022988
for <coley@RCF-SMTP.MITRE.ORG>; Wed, 7 Mar 2012 14:54:36 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 3B2E121B0F8E;
Wed, 7 Mar 2012 14:54:31 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1035A21B155F;
Wed, 7 Mar 2012 14:54:31 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS03.MITRE.ORG (129.83.29.80) with
Microsoft SMTP Server id 14.1.339.1; Wed, 7 Mar 2012 14:54:30 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4518991 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Wed, 7 Mar
2012 14:53:57 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Wed, 7 Mar 2012 14:53:57 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13237922; Wed, 07 Mar 2012 14:53:43 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id EC8C221B0FD5 for
<cve-editorial-board-list@lists.mitre.org>; Wed, 7 Mar 2012
14:53:43 -0500 (EST)
Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 2F95421B04A5 for
<cve-editorial-board-list@lists.mitre.org>; Wed, 7 Mar 2012
14:53:43 -0500 (EST)
Received: from (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id
6d07_4e41_3e0feb96_688f_11e1_9536_00219b929abd; Wed, 07 Mar 2012
13:53:42 -0600
Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by
DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 7 Mar 2012 13:52:22
-0600
From: <Kent_Landfield@McAfee.com>
To: <cve-editorial-board-list@LISTS.MITRE.ORG>
Date: Wed, 7 Mar 2012 13:52:57 -0600
Subject: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zA==
Message-ID: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: multipart/alternative;
boundary="_000_CB7CD1702DC8Akentlandfieldmcafeecom_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.7.193618
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_NO_HTTP 0.1,
SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_10000_LESS 0,
BODY_SIZE_10000_PLUS 0, DATE_TZ_NA 0, NO_REAL_NAME 0,
__ANY_URI 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0,
__CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
__CTYPE_MULTIPART_ALT 0, __HAS_HTML 0, __HAS_MSGID 0,
__INT_PROD_LOC 0, __MIME_HTML 0, __MIME_VERSION 0,
__SANE_MSGID 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0,
__TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NS , __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 14931
Status: R
X-Status:
X-Keywords:
--_000_CB7CD1702DC8Akentlandfieldmcafeecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
All,
We have problems with CVE reporting that are known issues but which are bec=
oming apparent to many more and could easily undermine the usefulness of CV=
E identification if left unchecked.
We discussed this at the ITSAC conference in the Future of Vulnerability Re=
porting Workshop and at the follow-on Vulnerability Reporting day at the So=
ftware Assurance event a month later. (There were action items out of the l=
atter that I am not aware have been completed=85)
I have just had a very concerning discussion about the usefulness of CVEs a=
s a means to measure vulnerabilities today and the decay of its value if th=
e trend continues. The discussion centered around the accuracy of the num=
bers of CVEs identified compared to those reported in the community as a wh=
ole. If we looked at just the CVE numbers, it appears that the numbers of=
vulnerabilities have been dropping since a high in 2008. This is a rathe=
r important error. As we all know, this is not accurate. Vulnerabilities ha=
ve not been dropping, they are growing, not dropping by 30%.
For the vendor community, these trends have rather concerning potential imp=
acts on us. First, our vulnerability research databases use CVE as a prima=
ry reference. The CVE Id has been authoritative in the past. It is used i=
nternally as a means to communicate vulnerability record information betwee=
n fielded products and between research analysis teams. As the numbers dec=
line, it means we are forced to look elsewhere to provide the identificatio=
n and communication that CVE provided in the past. More proprietary ids are=
becoming more the norm.
The more serious concern is what it is showing to executives of companies.
"If the vulnerabilities have dropped 30% since 2008, why do I need to be f=
unding the security staff and efforts at the rate I am? I see that MITRE i=
s reporting an overall drop each year since 2008 but yet you folks keep com=
ing to me saying that the threats are much worse and we may be in the same =
relative situation we were when malware spiked a couple years past=85"
For those that actively work in this environment, we know vulnerabilities h=
ave not dropped 30% since 2008. Quite the contrary, our internal numbers in=
dicate an increasing trend similar to a 30% rise. Symantec has also report=
ed a similar trend.
One of the major problems is that MITRE funding is not what it should be. O=
n multiple occasions we have been asked to target the classes of products w=
here vulnerabilities are considered the most critical and which sources sho=
uld be monitored. The view of what to target and monitor gets smaller and s=
maller as funding is held level or reduced.
At one point the intent of the effort was to cover all published vulnerabil=
ities that could be corroborated in some fashion. Over the years the reali=
ty has set in that this is a very resource intensive operation. As such th=
e focus of the effort has reduced what is reported on to assure CVEs can be=
assigned for the types of products most important to the Editorial Board =
participants and their sponsor. This gives an artificial view of the numbe=
rs of existing vulnerabilities and that is being recognized outside the vul=
nerability community.
Another problem is the CVE format itself. There has been an active discuss=
ion about the format limitations as well. The CVE format is CVE-YYYY-NNNN. =
This means that currently we cannot have more than 10,000 CVEs reported in =
a single year. At the rates we are seeing internally, we are already there=
.
Then there are the limitations of CVE process in general. The focus is Eng=
lish only although some non-US vulnerabilities do get assigned from time to=
time. CVE does not support the international community and software writt=
en for non-English geo-centric areas are not included. While this has not =
been a concern for US-only software vendors, there is a great deal of regio=
nal software written for major emerging markets. None of those vulnerabili=
ties are identified by a CVE.
Given these constraints, it seems like it is time to figure out how to addr=
ess the issues in a more of a creative way. We know the constraints. Is th=
ere something we can do to augment the MITRE staff in certain areas that wo=
uld help? I can see the format issue being a rather easy one to attack but=
it is the coverage issue that is most concerning. Or we should ignore it =
and slowly let the value of CVE to the community and vendors decay=85
Thoughts?
Kent Landfield
Director Content Strategy, Architecture and Standards
McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>
--_000_CB7CD1702DC8Akentlandfieldmcafeecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space;=
-webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16p=
x; font-family: 'Times New Roman', sans-serif; "><div><div><div>All,</div><=
div><br></div><div>We have problems with CVE reporting that are known issue=
s but which are becoming apparent to many more and could easily undermine t=
he usefulness of CVE identification if left unchecked.</div><div><br></div>=
<div>We discussed this at the ITSAC conference in the Future of Vulnerabili=
ty Reporting Workshop and at the follow-on Vulnerability Reporting day at t=
he Software Assurance event a month later. (There were action items out of =
the latter that I am not aware have been completed=85)</div><div><br></div>=
<div>I have just had a very concerning discussion about the usefulness of C=
VEs as a means to measure vulnerabilities today and the decay of its value =
if the trend continues. The discussion centered around the accuracy =
of the numbers of CVEs identified compared to those reported in the communi=
ty as a whole. If we looked at just the CVE numbers, it appears=
that the numbers of vulnerabilities have been dropping since a high in 200=
8. This is a rather important error. As we all know, this is not acc=
urate. Vulnerabilities have not been dropping, they are growing, not droppi=
ng by 30%. </div><div><br></div><div>For the vendor community, these =
trends have rather concerning potential impacts on us. First, our vul=
nerability research databases use CVE as a primary reference. The CVE=
Id has been authoritative in the past. It is used internally as a me=
ans to communicate vulnerability record information between fielded product=
s and between research analysis teams. As the numbers decline, it mea=
ns we are forced to look elsewhere to provide the identification and commun=
ication that CVE provided in the past. More proprietary ids are becoming mo=
re the norm.</div><div><br></div><div>The more serious concern is what it i=
s showing to executives of companies. </div><div><br></div><div><i>&q=
uot;If the vulnerabilities have dropped 30% since 2008, why do I need=
to be funding the security staff and efforts at the rate I am? I see=
that MITRE is reporting an overall drop each year since 2008 but yet you f=
olks keep coming to me saying that the threats are much worse and we may be=
in the same relative situation we were when malware spiked a couple years =
past=85"</i></div><div><br></div><div>For those that actively work in =
this environment, we know vulnerabilities have not dropped 30% since 2008. =
Quite the contrary, our internal numbers indicate an increasing trend simil=
ar to a 30% rise. Symantec has also reported a similar trend.</div><d=
iv><br></div><div><div><div><div><div>One of the major problems is that MIT=
RE funding is not what it should be. On multiple occasions we have been ask=
ed to target the classes of products where vulnerabilities are considered t=
he most critical and which sources should be monitored. The view of what to=
target and monitor gets smaller and smaller as funding is held level=
or reduced.</div><div><br></div><div>At one point the intent of the effort=
was to cover all published vulnerabilities that could be corroborated in s=
ome fashion. Over the years the reality has set in that this is a ver=
y resource intensive operation. As such the focus of the effort has r=
educed what is reported on to assure CVEs can be assigned for the types of =
products most important to the Editorial Board participants and their=
sponsor. This gives an artificial view of the numbers of existing vu=
lnerabilities and that is being recognized outside the vulnerability commun=
ity.</div><div><br></div><div>Another problem is the CVE format itself. &nb=
sp;There has been an active discussion about the format limitations as well=
. The CVE format is CVE-YYYY-NNNN. This means that currently we cannot have=
more than 10,000 CVEs reported in a single year. At the rates we are=
seeing internally, we are already there.</div><div><br></div><div>Then the=
re are the limitations of CVE process in general. The focus is Englis=
h only although some non-US vulnerabilities do get assigned from time to ti=
me. CVE does not support the international community and software wri=
tten for non-English geo-centric areas are not included. While this h=
as not been a concern for US-only software vendors, there is a great deal o=
f regional software written for major emerging markets. None of those=
vulnerabilities are identified by a CVE. </div></div></div></div></d=
iv><div><br></div><div>Given these constraints, it seems like it is time to=
figure out how to address the issues in a more of a creative way. We=
know the constraints. Is there something we can do to augment the MITRE st=
aff in certain areas that would help? I can see the format issue bein=
g a rather easy one to attack but it is the coverage issue that is most con=
cerning. Or we should ignore it and slowly let the value of CVE to th=
e community and vendors decay=85</div><div><br></div><div>Thoughts?</div><d=
iv><br></div><div><div><span class=3D"Apple-style-span" style=3D"font-size:=
12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -w=
ebkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-ser=
if; "><strong>Kent Landfield</strong></span><span class=3D"Apple-style-span=
" style=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizo=
ntal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial=
, Helvetica, sans-serif; "><br></span><span class=3D"Apple-style-span" styl=
e=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-s=
pacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helv=
etica, sans-serif; ">Director Content Strategy, Architecture and Standards<=
/span><span class=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb=
(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vert=
ical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span>=
<span class=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb(96, 1=
06, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-s=
pacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span =
class=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb(96, 106, 11=
3); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing=
: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Int=
el Company</strong></span><span class=3D"Apple-style-span" style=3D"font-si=
ze: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px;=
-webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-=
serif; "><br></span><span class=3D"Apple-style-span" style=3D"font-size: 12=
px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webk=
it-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif;=
">5000 Headquarters Dr.</span><span class=3D"Apple-style-span" style=3D"fo=
nt-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing:=
1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, =
sans-serif; "><br></span><span class=3D"Apple-style-span" style=3D"font-siz=
e: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; =
-webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-s=
erif; ">Plano, Texas 75024</span><span class=3D"Apple-style-span" style=3D"=
font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacin=
g: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica=
, sans-serif; "><br></span><span class=3D"Apple-style-span" style=3D"font-s=
ize: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px=
; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans=
-serif; "><br></span><span class=3D"Apple-style-span" style=3D"font-size: 1=
2px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -web=
kit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif=
; ">Direct: +1.972.963.7096 </span><span class=3D"Apple-style-span=
" style=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizo=
ntal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial=
, Helvetica, sans-serif; "><br></span><span class=3D"Apple-style-span" styl=
e=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-s=
pacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helv=
etica, sans-serif; ">Mobile: +1.817.637.8026</span><span class=3D"Apple=
-style-span" style=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-bo=
rder-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-fa=
mily: Arial, Helvetica, sans-serif; "><br></span><span class=3D"Apple-style=
-span" style=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-h=
orizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: =
Arial, Helvetica, sans-serif; "><strong>Web: </strong></span><span cla=
ss=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb(96, 106, 113);=
-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1=
px; font-family: Arial, Helvetica, sans-serif; "><a href=3D"http://www.mcaf=
ee.com/" style=3D"color: rgb(96, 106, 113) !important; ">www.mcafee.com</a>=
</span></div></div></div></div></body></html>
--_000_CB7CD1702DC8Akentlandfieldmcafeecom_--
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Wed Mar 7 14:54:37 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q27Jsaqf022987;
Wed, 7 Mar 2012 14:54:36 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 3B2E121B0F8E;
Wed, 7 Mar 2012 14:54:31 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1035A21B155F;
Wed, 7 Mar 2012 14:54:31 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS03.MITRE.ORG (129.83.29.80) with
Microsoft SMTP Server id 14.1.339.1; Wed, 7 Mar 2012 14:54:30 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4518991 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Wed, 7 Mar
2012 14:53:57 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Wed, 7 Mar 2012 14:53:57 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13237922; Wed, 07 Mar 2012 14:53:43 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id EC8C221B0FD5 for
<cve-editorial-board-list@lists.mitre.org>; Wed, 7 Mar 2012
14:53:43 -0500 (EST)
Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 2F95421B04A5 for
<cve-editorial-board-list@lists.mitre.org>; Wed, 7 Mar 2012
14:53:43 -0500 (EST)
Received: from (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id
6d07_4e41_3e0feb96_688f_11e1_9536_00219b929abd; Wed, 07 Mar 2012
13:53:42 -0600
Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by
DALEXHT2.corp.nai.org ([::1]) with mapi; Wed, 7 Mar 2012 13:52:22
-0600
From: <Kent_Landfield@McAfee.com>
To: <cve-editorial-board-list@LISTS.MITRE.ORG>
Date: Wed, 7 Mar 2012 13:52:57 -0600
Subject: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zA==
Message-ID: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: multipart/alternative;
boundary="_000_CB7CD1702DC8Akentlandfieldmcafeecom_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.7.193618
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_NO_HTTP 0.1,
SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_10000_LESS 0,
BODY_SIZE_10000_PLUS 0, DATE_TZ_NA 0, NO_REAL_NAME 0,
__ANY_URI 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0,
__CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
__CTYPE_MULTIPART_ALT 0, __HAS_HTML 0, __HAS_MSGID 0,
__INT_PROD_LOC 0, __MIME_HTML 0, __MIME_VERSION 0,
__SANE_MSGID 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0,
__TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NS , __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 14931
Status:
X-Status:
X-Keywords:
--_000_CB7CD1702DC8Akentlandfieldmcafeecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
All,
We have problems with CVE reporting that are known issues but which are bec=
oming apparent to many more and could easily undermine the usefulness of CV=
E identification if left unchecked.
We discussed this at the ITSAC conference in the Future of Vulnerability Re=
porting Workshop and at the follow-on Vulnerability Reporting day at the So=
ftware Assurance event a month later. (There were action items out of the l=
atter that I am not aware have been completed=85)
I have just had a very concerning discussion about the usefulness of CVEs a=
s a means to measure vulnerabilities today and the decay of its value if th=
e trend continues. The discussion centered around the accuracy of the num=
bers of CVEs identified compared to those reported in the community as a wh=
ole. If we looked at just the CVE numbers, it appears that the numbers of=
vulnerabilities have been dropping since a high in 2008. This is a rathe=
r important error. As we all know, this is not accurate. Vulnerabilities ha=
ve not been dropping, they are growing, not dropping by 30%.
For the vendor community, these trends have rather concerning potential imp=
acts on us. First, our vulnerability research databases use CVE as a prima=
ry reference. The CVE Id has been authoritative in the past. It is used i=
nternally as a means to communicate vulnerability record information betwee=
n fielded products and between research analysis teams. As the numbers dec=
line, it means we are forced to look elsewhere to provide the identificatio=
n and communication that CVE provided in the past. More proprietary ids are=
becoming more the norm.
The more serious concern is what it is showing to executives of companies.
"If the vulnerabilities have dropped 30% since 2008, why do I need to be f=
unding the security staff and efforts at the rate I am? I see that MITRE i=
s reporting an overall drop each year since 2008 but yet you folks keep com=
ing to me saying that the threats are much worse and we may be in the same =
relative situation we were when malware spiked a couple years past=85"
For those that actively work in this environment, we know vulnerabilities h=
ave not dropped 30% since 2008. Quite the contrary, our internal numbers in=
dicate an increasing trend similar to a 30% rise. Symantec has also report=
ed a similar trend.
One of the major problems is that MITRE funding is not what it should be. O=
n multiple occasions we have been asked to target the classes of products w=
here vulnerabilities are considered the most critical and which sources sho=
uld be monitored. The view of what to target and monitor gets smaller and s=
maller as funding is held level or reduced.
At one point the intent of the effort was to cover all published vulnerabil=
ities that could be corroborated in some fashion. Over the years the reali=
ty has set in that this is a very resource intensive operation. As such th=
e focus of the effort has reduced what is reported on to assure CVEs can be=
assigned for the types of products most important to the Editorial Board =
participants and their sponsor. This gives an artificial view of the numbe=
rs of existing vulnerabilities and that is being recognized outside the vul=
nerability community.
Another problem is the CVE format itself. There has been an active discuss=
ion about the format limitations as well. The CVE format is CVE-YYYY-NNNN. =
This means that currently we cannot have more than 10,000 CVEs reported in =
a single year. At the rates we are seeing internally, we are already there=
.
Then there are the limitations of CVE process in general. The focus is Eng=
lish only although some non-US vulnerabilities do get assigned from time to=
time. CVE does not support the international community and software writt=
en for non-English geo-centric areas are not included. While this has not =
been a concern for US-only software vendors, there is a great deal of regio=
nal software written for major emerging markets. None of those vulnerabili=
ties are identified by a CVE.
Given these constraints, it seems like it is time to figure out how to addr=
ess the issues in a more of a creative way. We know the constraints. Is th=
ere something we can do to augment the MITRE staff in certain areas that wo=
uld help? I can see the format issue being a rather easy one to attack but=
it is the coverage issue that is most concerning. Or we should ignore it =
and slowly let the value of CVE to the community and vendors decay=85
Thoughts?
Kent Landfield
Director Content Strategy, Architecture and Standards
McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>
--_000_CB7CD1702DC8Akentlandfieldmcafeecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space;=
-webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16p=
x; font-family: 'Times New Roman', sans-serif; "><div><div><div>All,</div><=
div><br></div><div>We have problems with CVE reporting that are known issue=
s but which are becoming apparent to many more and could easily undermine t=
he usefulness of CVE identification if left unchecked.</div><div><br></div>=
<div>We discussed this at the ITSAC conference in the Future of Vulnerabili=
ty Reporting Workshop and at the follow-on Vulnerability Reporting day at t=
he Software Assurance event a month later. (There were action items out of =
the latter that I am not aware have been completed=85)</div><div><br></div>=
<div>I have just had a very concerning discussion about the usefulness of C=
VEs as a means to measure vulnerabilities today and the decay of its value =
if the trend continues. The discussion centered around the accuracy =
of the numbers of CVEs identified compared to those reported in the communi=
ty as a whole. If we looked at just the CVE numbers, it appears=
that the numbers of vulnerabilities have been dropping since a high in 200=
8. This is a rather important error. As we all know, this is not acc=
urate. Vulnerabilities have not been dropping, they are growing, not droppi=
ng by 30%. </div><div><br></div><div>For the vendor community, these =
trends have rather concerning potential impacts on us. First, our vul=
nerability research databases use CVE as a primary reference. The CVE=
Id has been authoritative in the past. It is used internally as a me=
ans to communicate vulnerability record information between fielded product=
s and between research analysis teams. As the numbers decline, it mea=
ns we are forced to look elsewhere to provide the identification and commun=
ication that CVE provided in the past. More proprietary ids are becoming mo=
re the norm.</div><div><br></div><div>The more serious concern is what it i=
s showing to executives of companies. </div><div><br></div><div><i>&q=
uot;If the vulnerabilities have dropped 30% since 2008, why do I need=
to be funding the security staff and efforts at the rate I am? I see=
that MITRE is reporting an overall drop each year since 2008 but yet you f=
olks keep coming to me saying that the threats are much worse and we may be=
in the same relative situation we were when malware spiked a couple years =
past=85"</i></div><div><br></div><div>For those that actively work in =
this environment, we know vulnerabilities have not dropped 30% since 2008. =
Quite the contrary, our internal numbers indicate an increasing trend simil=
ar to a 30% rise. Symantec has also reported a similar trend.</div><d=
iv><br></div><div><div><div><div><div>One of the major problems is that MIT=
RE funding is not what it should be. On multiple occasions we have been ask=
ed to target the classes of products where vulnerabilities are considered t=
he most critical and which sources should be monitored. The view of what to=
target and monitor gets smaller and smaller as funding is held level=
or reduced.</div><div><br></div><div>At one point the intent of the effort=
was to cover all published vulnerabilities that could be corroborated in s=
ome fashion. Over the years the reality has set in that this is a ver=
y resource intensive operation. As such the focus of the effort has r=
educed what is reported on to assure CVEs can be assigned for the types of =
products most important to the Editorial Board participants and their=
sponsor. This gives an artificial view of the numbers of existing vu=
lnerabilities and that is being recognized outside the vulnerability commun=
ity.</div><div><br></div><div>Another problem is the CVE format itself. &nb=
sp;There has been an active discussion about the format limitations as well=
. The CVE format is CVE-YYYY-NNNN. This means that currently we cannot have=
more than 10,000 CVEs reported in a single year. At the rates we are=
seeing internally, we are already there.</div><div><br></div><div>Then the=
re are the limitations of CVE process in general. The focus is Englis=
h only although some non-US vulnerabilities do get assigned from time to ti=
me. CVE does not support the international community and software wri=
tten for non-English geo-centric areas are not included. While this h=
as not been a concern for US-only software vendors, there is a great deal o=
f regional software written for major emerging markets. None of those=
vulnerabilities are identified by a CVE. </div></div></div></div></d=
iv><div><br></div><div>Given these constraints, it seems like it is time to=
figure out how to address the issues in a more of a creative way. We=
know the constraints. Is there something we can do to augment the MITRE st=
aff in certain areas that would help? I can see the format issue bein=
g a rather easy one to attack but it is the coverage issue that is most con=
cerning. Or we should ignore it and slowly let the value of CVE to th=
e community and vendors decay=85</div><div><br></div><div>Thoughts?</div><d=
iv><br></div><div><div><span class=3D"Apple-style-span" style=3D"font-size:=
12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -w=
ebkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-ser=
if; "><strong>Kent Landfield</strong></span><span class=3D"Apple-style-span=
" style=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizo=
ntal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial=
, Helvetica, sans-serif; "><br></span><span class=3D"Apple-style-span" styl=
e=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-s=
pacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helv=
etica, sans-serif; ">Director Content Strategy, Architecture and Standards<=
/span><span class=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb=
(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vert=
ical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span>=
<span class=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb(96, 1=
06, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-s=
pacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span =
class=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb(96, 106, 11=
3); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing=
: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Int=
el Company</strong></span><span class=3D"Apple-style-span" style=3D"font-si=
ze: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px;=
-webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-=
serif; "><br></span><span class=3D"Apple-style-span" style=3D"font-size: 12=
px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webk=
it-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif;=
">5000 Headquarters Dr.</span><span class=3D"Apple-style-span" style=3D"fo=
nt-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing:=
1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, =
sans-serif; "><br></span><span class=3D"Apple-style-span" style=3D"font-siz=
e: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; =
-webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-s=
erif; ">Plano, Texas 75024</span><span class=3D"Apple-style-span" style=3D"=
font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacin=
g: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica=
, sans-serif; "><br></span><span class=3D"Apple-style-span" style=3D"font-s=
ize: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px=
; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans=
-serif; "><br></span><span class=3D"Apple-style-span" style=3D"font-size: 1=
2px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -web=
kit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif=
; ">Direct: +1.972.963.7096 </span><span class=3D"Apple-style-span=
" style=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizo=
ntal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial=
, Helvetica, sans-serif; "><br></span><span class=3D"Apple-style-span" styl=
e=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-s=
pacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helv=
etica, sans-serif; ">Mobile: +1.817.637.8026</span><span class=3D"Apple=
-style-span" style=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-bo=
rder-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-fa=
mily: Arial, Helvetica, sans-serif; "><br></span><span class=3D"Apple-style=
-span" style=3D"font-size: 12px; color: rgb(96, 106, 113); -webkit-border-h=
orizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: =
Arial, Helvetica, sans-serif; "><strong>Web: </strong></span><span cla=
ss=3D"Apple-style-span" style=3D"font-size: 12px; color: rgb(96, 106, 113);=
-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1=
px; font-family: Arial, Helvetica, sans-serif; "><a href=3D"http://www.mcaf=
ee.com/" style=3D"color: rgb(96, 106, 113) !important; ">www.mcafee.com</a>=
</span></div></div></div></div></body></html>
--_000_CB7CD1702DC8Akentlandfieldmcafeecom_--
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Wed Mar 7 15:45:13 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q27KjCAR024429;
Wed, 7 Mar 2012 15:45:12 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 56D2721B157F;
Wed, 7 Mar 2012 15:45:07 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 2938221B1575;
Wed, 7 Mar 2012 15:45:07 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS03.MITRE.ORG (129.83.29.80) with
Microsoft SMTP Server id 14.1.339.1; Wed, 7 Mar 2012 15:45:06 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4519744 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Wed, 7 Mar
2012 15:45:00 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Wed, 7 Mar 2012 15:45:00 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13238208; Wed, 07 Mar 2012 15:44:40 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id EA8F921B1575 for
<cve-editorial-board-list@lists.mitre.org>; Wed, 7 Mar 2012
15:44:39 -0500 (EST)
Received: from psmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 8B72D21B0FF9 for
<cve-editorial-board-list@lists.mitre.org>; Wed, 7 Mar 2012
15:44:36 -0500 (EST)
Received: from USILMS191.ca.com ([141.202.246.45]) (using TLSv1) by
na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID
DSNKT1fIsy/xEFwBqFqR56JByVrPwMnwnoHh@postini.com; Wed, 07 Mar 2012
12:44:36 PST
Received: from USILMS170.ca.com (141.202.6.20) by USILMS191.ca.com
(141.202.246.45) with Microsoft SMTP Server (TLS) id 14.1.355.2;
Wed, 7 Mar 2012 15:44:34 -0500
Received: from USILMS113B.ca.com ([169.254.5.51]) by USILMS170.ca.com
([141.202.6.20]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012
15:44:34 -0500
From: "Williams, James K" <James.Williams@ca.com>
To: "cve-editorial-board-list@lists.mitre.org"
<cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zAABoepg
Date: Wed, 7 Mar 2012 20:44:34 +0000
Message-ID: <ED311CBEE6993C428563DEDF6D083BC81180FBF7@usilms113b.ca.com>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
In-Reply-To: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.132.0.249]
Content-Type: multipart/alternative;
boundary="_000_ED311CBEE6993C428563DEDF6D083BC81180FBF7usilms113bcacom_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.7.203320
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_70_90 0.1,
SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0, FROM_NAME_PHRASE 0,
WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0,
__ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CP_URI_IN_BODY 0,
__CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
__CTYPE_MULTIPART_ALT 0, __FRAUD_CONTACT_NAME 0, __HAS_HTML 0,
__HAS_MSGID 0, __HAS_XOIP 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0,
__INT_PROD_LOC 0, __MIME_HTML 0, __MIME_VERSION 0,
__SANE_MSGID 0, __STYLE_RATWARE_2 0, __TAG_EXISTS_HTML 0,
__TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS '
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 26279
Status: R
X-Status: F
X-Keywords:
--_000_ED311CBEE6993C428563DEDF6D083BC81180FBF7usilms113bcacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
QWdyZWUgd2l0aCBldmVyeXRoaW5nIEtlbnQgc2FpZC4NCg0KT25lIGltcG9ydGFudCBjaGFuZ2Ug
SSB3b3VsZCBsaWtlIHRvIHNlZSBpcyB0aGUgYWRkaXRpb24gb2YgYSDigJxDb21tZW50c+KAnSBm
ZWF0dXJlIG9uIGVhY2ggQ1ZFIHBhZ2UgYXQgY3ZlLm1pdHJlLm9yZy4gIFRoZSBDb21tZW50cyBm
ZWF0dXJlIGNvdWxkIGJlIHVzZWQgYnkgRWRpdG9yaWFsIEJvYXJkIG1lbWJlcnMgKGFuZCBvdGhl
ciB2ZXR0ZWQgaW5kaXZpZHVhbHM/KSB0byBhZGQgaW5mbyBzdWNoIGFzIGNvcnJlY3Rpb25zLCBh
ZGRpdGlvbmFsIHJlZmVyZW5jZXMsIHZlbmRvciByZXNwb25zZXMsIGV0Yy4NCg0KVGhhbmtzIGFu
ZCByZWdhcmRzLA0KS2VuIFdpbGxpYW1zLCBEaXJlY3Rvcg0KQ0EgVGVjaG5vbG9naWVzIFByb2R1
Y3QgVnVsbmVyYWJpbGl0eSBSZXNwb25zZSBUZWFtDQpDQSBUZWNobm9sb2dpZXMgQnVzaW5lc3Mg
VW5pdCBPcGVyYXRpb25zDQp3aWxqYTIyQGNhLmNvbSAtIDgxNi05MTQtNDIyNQ0KDQoNCg0KRnJv
bTogb3duZXItY3ZlLWVkaXRvcmlhbC1ib2FyZC1saXN0QGxpc3RzLm1pdHJlLm9yZyBbbWFpbHRv
Om93bmVyLWN2ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmddIE9uIEJlaGFs
ZiBPZiBLZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDA3
LCAyMDEyIDE6NTMgUE0NClRvOiBjdmUtZWRpdG9yaWFsLWJvYXJkLWxpc3RAbGlzdHMubWl0cmUu
b3JnDQpTdWJqZWN0OiBDb3VudGluZyBvbiBDVkVzDQoNCkFsbCwNCg0KV2UgaGF2ZSBwcm9ibGVt
cyB3aXRoIENWRSByZXBvcnRpbmcgdGhhdCBhcmUga25vd24gaXNzdWVzIGJ1dCB3aGljaCBhcmUg
YmVjb21pbmcgYXBwYXJlbnQgdG8gbWFueSBtb3JlIGFuZCBjb3VsZCBlYXNpbHkgdW5kZXJtaW5l
IHRoZSB1c2VmdWxuZXNzIG9mIENWRSBpZGVudGlmaWNhdGlvbiBpZiBsZWZ0IHVuY2hlY2tlZC4N
Cg0KV2UgZGlzY3Vzc2VkIHRoaXMgYXQgdGhlIElUU0FDIGNvbmZlcmVuY2UgaW4gdGhlIEZ1dHVy
ZSBvZiBWdWxuZXJhYmlsaXR5IFJlcG9ydGluZyBXb3Jrc2hvcCBhbmQgYXQgdGhlIGZvbGxvdy1v
biBWdWxuZXJhYmlsaXR5IFJlcG9ydGluZyBkYXkgYXQgdGhlIFNvZnR3YXJlIEFzc3VyYW5jZSBl
dmVudCBhIG1vbnRoIGxhdGVyLiAoVGhlcmUgd2VyZSBhY3Rpb24gaXRlbXMgb3V0IG9mIHRoZSBs
YXR0ZXIgdGhhdCBJIGFtIG5vdCBhd2FyZSBoYXZlIGJlZW4gY29tcGxldGVk4oCmKQ0KDQpJIGhh
dmUganVzdCBoYWQgYSB2ZXJ5IGNvbmNlcm5pbmcgZGlzY3Vzc2lvbiBhYm91dCB0aGUgdXNlZnVs
bmVzcyBvZiBDVkVzIGFzIGEgbWVhbnMgdG8gbWVhc3VyZSB2dWxuZXJhYmlsaXRpZXMgdG9kYXkg
YW5kIHRoZSBkZWNheSBvZiBpdHMgdmFsdWUgaWYgdGhlIHRyZW5kIGNvbnRpbnVlcy4gICBUaGUg
ZGlzY3Vzc2lvbiBjZW50ZXJlZCBhcm91bmQgdGhlIGFjY3VyYWN5IG9mIHRoZSBudW1iZXJzIG9m
IENWRXMgaWRlbnRpZmllZCBjb21wYXJlZCB0byB0aG9zZSByZXBvcnRlZCBpbiB0aGUgY29tbXVu
aXR5IGFzIGEgd2hvbGUuICBJZiB3ZSBsb29rZWQgYXQganVzdCB0aGUgQ1ZFIG51bWJlcnMsICBp
dCBhcHBlYXJzIHRoYXQgdGhlIG51bWJlcnMgb2YgdnVsbmVyYWJpbGl0aWVzIGhhdmUgYmVlbiBk
cm9wcGluZyBzaW5jZSBhIGhpZ2ggaW4gMjAwOC4gICBUaGlzIGlzIGEgcmF0aGVyIGltcG9ydGFu
dCBlcnJvci4gQXMgd2UgYWxsIGtub3csIHRoaXMgaXMgbm90IGFjY3VyYXRlLiBWdWxuZXJhYmls
aXRpZXMgaGF2ZSBub3QgYmVlbiBkcm9wcGluZywgdGhleSBhcmUgZ3Jvd2luZywgbm90IGRyb3Bw
aW5nIGJ5IDMwJS4NCg0KRm9yIHRoZSB2ZW5kb3IgY29tbXVuaXR5LCB0aGVzZSB0cmVuZHMgaGF2
ZSByYXRoZXIgY29uY2VybmluZyBwb3RlbnRpYWwgaW1wYWN0cyBvbiB1cy4gIEZpcnN0LCBvdXIg
dnVsbmVyYWJpbGl0eSByZXNlYXJjaCBkYXRhYmFzZXMgdXNlIENWRSBhcyBhIHByaW1hcnkgcmVm
ZXJlbmNlLiAgVGhlIENWRSBJZCBoYXMgYmVlbiBhdXRob3JpdGF0aXZlIGluIHRoZSBwYXN0LiAg
SXQgaXMgdXNlZCBpbnRlcm5hbGx5IGFzIGEgbWVhbnMgdG8gY29tbXVuaWNhdGUgdnVsbmVyYWJp
bGl0eSByZWNvcmQgaW5mb3JtYXRpb24gYmV0d2VlbiBmaWVsZGVkIHByb2R1Y3RzIGFuZCBiZXR3
ZWVuIHJlc2VhcmNoIGFuYWx5c2lzIHRlYW1zLiAgQXMgdGhlIG51bWJlcnMgZGVjbGluZSwgaXQg
bWVhbnMgd2UgYXJlIGZvcmNlZCB0byBsb29rIGVsc2V3aGVyZSB0byBwcm92aWRlIHRoZSBpZGVu
dGlmaWNhdGlvbiBhbmQgY29tbXVuaWNhdGlvbiB0aGF0IENWRSBwcm92aWRlZCBpbiB0aGUgcGFz
dC4gTW9yZSBwcm9wcmlldGFyeSBpZHMgYXJlIGJlY29taW5nIG1vcmUgdGhlIG5vcm0uDQoNClRo
ZSBtb3JlIHNlcmlvdXMgY29uY2VybiBpcyB3aGF0IGl0IGlzIHNob3dpbmcgdG8gZXhlY3V0aXZl
cyBvZiBjb21wYW5pZXMuDQoNCiJJZiB0aGUgdnVsbmVyYWJpbGl0aWVzIGhhdmUgZHJvcHBlZCAg
MzAlIHNpbmNlIDIwMDgsIHdoeSBkbyBJIG5lZWQgdG8gYmUgZnVuZGluZyB0aGUgc2VjdXJpdHkg
c3RhZmYgYW5kIGVmZm9ydHMgYXQgdGhlIHJhdGUgSSBhbT8gIEkgc2VlIHRoYXQgTUlUUkUgaXMg
cmVwb3J0aW5nIGFuIG92ZXJhbGwgZHJvcCBlYWNoIHllYXIgc2luY2UgMjAwOCBidXQgeWV0IHlv
dSBmb2xrcyBrZWVwIGNvbWluZyB0byBtZSBzYXlpbmcgdGhhdCB0aGUgdGhyZWF0cyBhcmUgbXVj
aCB3b3JzZSBhbmQgd2UgbWF5IGJlIGluIHRoZSBzYW1lIHJlbGF0aXZlIHNpdHVhdGlvbiB3ZSB3
ZXJlIHdoZW4gbWFsd2FyZSBzcGlrZWQgYSBjb3VwbGUgeWVhcnMgcGFzdOKApiINCg0KRm9yIHRo
b3NlIHRoYXQgYWN0aXZlbHkgd29yayBpbiB0aGlzIGVudmlyb25tZW50LCB3ZSBrbm93IHZ1bG5l
cmFiaWxpdGllcyBoYXZlIG5vdCBkcm9wcGVkIDMwJSBzaW5jZSAyMDA4LiBRdWl0ZSB0aGUgY29u
dHJhcnksIG91ciBpbnRlcm5hbCBudW1iZXJzIGluZGljYXRlIGFuIGluY3JlYXNpbmcgdHJlbmQg
c2ltaWxhciB0byBhIDMwJSByaXNlLiAgU3ltYW50ZWMgaGFzIGFsc28gcmVwb3J0ZWQgYSBzaW1p
bGFyIHRyZW5kLg0KDQpPbmUgb2YgdGhlIG1ham9yIHByb2JsZW1zIGlzIHRoYXQgTUlUUkUgZnVu
ZGluZyBpcyBub3Qgd2hhdCBpdCBzaG91bGQgYmUuIE9uIG11bHRpcGxlIG9jY2FzaW9ucyB3ZSBo
YXZlIGJlZW4gYXNrZWQgdG8gdGFyZ2V0IHRoZSBjbGFzc2VzIG9mIHByb2R1Y3RzIHdoZXJlIHZ1
bG5lcmFiaWxpdGllcyBhcmUgY29uc2lkZXJlZCB0aGUgbW9zdCBjcml0aWNhbCBhbmQgd2hpY2gg
c291cmNlcyBzaG91bGQgYmUgbW9uaXRvcmVkLiBUaGUgdmlldyBvZiB3aGF0IHRvIHRhcmdldCBh
bmQgbW9uaXRvciBnZXRzIHNtYWxsZXIgYW5kIHNtYWxsZXIgYXMgZnVuZGluZyBpcyAgaGVsZCBs
ZXZlbCBvciByZWR1Y2VkLg0KDQpBdCBvbmUgcG9pbnQgdGhlIGludGVudCBvZiB0aGUgZWZmb3J0
IHdhcyB0byBjb3ZlciBhbGwgcHVibGlzaGVkIHZ1bG5lcmFiaWxpdGllcyB0aGF0IGNvdWxkIGJl
IGNvcnJvYm9yYXRlZCBpbiBzb21lIGZhc2hpb24uICBPdmVyIHRoZSB5ZWFycyB0aGUgcmVhbGl0
eSBoYXMgc2V0IGluIHRoYXQgdGhpcyBpcyBhIHZlcnkgcmVzb3VyY2UgaW50ZW5zaXZlIG9wZXJh
dGlvbi4gIEFzIHN1Y2ggdGhlIGZvY3VzIG9mIHRoZSBlZmZvcnQgaGFzIHJlZHVjZWQgd2hhdCBp
cyByZXBvcnRlZCBvbiB0byBhc3N1cmUgQ1ZFcyBjYW4gYmUgYXNzaWduZWQgZm9yIHRoZSB0eXBl
cyBvZiBwcm9kdWN0cyAgbW9zdCBpbXBvcnRhbnQgdG8gdGhlIEVkaXRvcmlhbCBCb2FyZCBwYXJ0
aWNpcGFudHMgYW5kIHRoZWlyIHNwb25zb3IuICBUaGlzIGdpdmVzIGFuIGFydGlmaWNpYWwgdmll
dyBvZiB0aGUgbnVtYmVycyBvZiBleGlzdGluZyB2dWxuZXJhYmlsaXRpZXMgYW5kIHRoYXQgaXMg
YmVpbmcgcmVjb2duaXplZCBvdXRzaWRlIHRoZSB2dWxuZXJhYmlsaXR5IGNvbW11bml0eS4NCg0K
QW5vdGhlciBwcm9ibGVtIGlzIHRoZSBDVkUgZm9ybWF0IGl0c2VsZi4gIFRoZXJlIGhhcyBiZWVu
IGFuIGFjdGl2ZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBmb3JtYXQgbGltaXRhdGlvbnMgYXMgd2Vs
bC4gVGhlIENWRSBmb3JtYXQgaXMgQ1ZFLVlZWVktTk5OTi4gVGhpcyBtZWFucyB0aGF0IGN1cnJl
bnRseSB3ZSBjYW5ub3QgaGF2ZSBtb3JlIHRoYW4gMTAsMDAwIENWRXMgcmVwb3J0ZWQgaW4gYSBz
aW5nbGUgeWVhci4gIEF0IHRoZSByYXRlcyB3ZSBhcmUgc2VlaW5nIGludGVybmFsbHksIHdlIGFy
ZSBhbHJlYWR5IHRoZXJlLg0KDQpUaGVuIHRoZXJlIGFyZSB0aGUgbGltaXRhdGlvbnMgb2YgQ1ZF
IHByb2Nlc3MgaW4gZ2VuZXJhbC4gIFRoZSBmb2N1cyBpcyBFbmdsaXNoIG9ubHkgYWx0aG91Z2gg
c29tZSBub24tVVMgdnVsbmVyYWJpbGl0aWVzIGRvIGdldCBhc3NpZ25lZCBmcm9tIHRpbWUgdG8g
dGltZS4gIENWRSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpbnRlcm5hdGlvbmFsIGNvbW11bml0eSBh
bmQgc29mdHdhcmUgd3JpdHRlbiBmb3Igbm9uLUVuZ2xpc2ggZ2VvLWNlbnRyaWMgYXJlYXMgYXJl
IG5vdCBpbmNsdWRlZC4gIFdoaWxlIHRoaXMgaGFzIG5vdCBiZWVuIGEgY29uY2VybiBmb3IgVVMt
b25seSBzb2Z0d2FyZSB2ZW5kb3JzLCB0aGVyZSBpcyBhIGdyZWF0IGRlYWwgb2YgcmVnaW9uYWwg
c29mdHdhcmUgd3JpdHRlbiBmb3IgbWFqb3IgZW1lcmdpbmcgbWFya2V0cy4gIE5vbmUgb2YgdGhv
c2UgdnVsbmVyYWJpbGl0aWVzIGFyZSBpZGVudGlmaWVkIGJ5IGEgQ1ZFLg0KDQpHaXZlbiB0aGVz
ZSBjb25zdHJhaW50cywgaXQgc2VlbXMgbGlrZSBpdCBpcyB0aW1lIHRvIGZpZ3VyZSBvdXQgaG93
IHRvIGFkZHJlc3MgdGhlIGlzc3VlcyBpbiBhIG1vcmUgb2YgYSBjcmVhdGl2ZSB3YXkuICBXZSBr
bm93IHRoZSBjb25zdHJhaW50cy4gSXMgdGhlcmUgc29tZXRoaW5nIHdlIGNhbiBkbyB0byBhdWdt
ZW50IHRoZSBNSVRSRSBzdGFmZiBpbiBjZXJ0YWluIGFyZWFzIHRoYXQgd291bGQgaGVscD8gIEkg
Y2FuIHNlZSB0aGUgZm9ybWF0IGlzc3VlIGJlaW5nIGEgcmF0aGVyIGVhc3kgb25lIHRvIGF0dGFj
ayBidXQgaXQgaXMgdGhlIGNvdmVyYWdlIGlzc3VlIHRoYXQgaXMgbW9zdCBjb25jZXJuaW5nLiAg
T3Igd2Ugc2hvdWxkIGlnbm9yZSBpdCBhbmQgc2xvd2x5IGxldCB0aGUgdmFsdWUgb2YgQ1ZFIHRv
IHRoZSBjb21tdW5pdHkgYW5kIHZlbmRvcnMgZGVjYXnigKYNCg0KVGhvdWdodHM/DQoNCktlbnQg
TGFuZGZpZWxkDQpEaXJlY3RvciBDb250ZW50IFN0cmF0ZWd5LCBBcmNoaXRlY3R1cmUgYW5kIFN0
YW5kYXJkcw0KDQpNY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55DQo1MDAwIEhlYWRxdWFydGVycyBE
ci4NClBsYW5vLCBUZXhhcyA3NTAyNA0KDQpEaXJlY3Q6ICsxLjk3Mi45NjMuNzA5Ng0KTW9iaWxl
OiArMS44MTcuNjM3LjgwMjYNCldlYjogd3d3Lm1jYWZlZS5jb208aHR0cDovL3d3dy5tY2FmZWUu
Y29tLz4NCg==
--_000_ED311CBEE6993C428563DEDF6D083BC81180FBF7usilms113bcacom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1
IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi
c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0
ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUt
c3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1h
aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd
LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs
ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFncmVlIHdpdGggZXZlcnl0
aGluZyBLZW50IHNhaWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgaW1wb3J0YW50IGNoYW5nZSBJIHdvdWxkIGxp
a2UgdG8gc2VlIGlzIHRoZSBhZGRpdGlvbiBvZiBhIOKAnENvbW1lbnRz4oCdIGZlYXR1cmUgb24g
ZWFjaCBDVkUgcGFnZSBhdCBjdmUubWl0cmUub3JnLiZuYnNwOyBUaGUgQ29tbWVudHMgZmVhdHVy
ZSBjb3VsZCBiZSB1c2VkIGJ5IEVkaXRvcmlhbA0KIEJvYXJkIG1lbWJlcnMgKGFuZCBvdGhlciB2
ZXR0ZWQgaW5kaXZpZHVhbHM/KSB0byBhZGQgaW5mbyBzdWNoIGFzIGNvcnJlY3Rpb25zLCBhZGRp
dGlvbmFsIHJlZmVyZW5jZXMsIHZlbmRvciByZXNwb25zZXMsIGV0Yy48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtW
ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyBh
bmQgcmVnYXJkcyw8YnI+DQpLZW4gV2lsbGlhbXMsIERpcmVjdG9yPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzAwNjRBRiI+Qzwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzE0QUExMyI+QSBUZWNobm9sb2dpZXM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOmJsYWNrIj5Qcm9kdWN0IFZ1bG5lcmFiaWxpdHkgUmVzcG9uc2UgVGVhbTwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQo8L3NwYW4+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNjRBRiI+Qzwvc3Bhbj48L2I+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE0QUExMyI+QSBUZWNobm9sb2dp
ZXM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy
ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CdXNpbmVzcyBV
bml0IE9wZXJhdGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPndpbGphMjJAY2EuY29tIC0gODE2LTkx
NC00MjI1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBvd25lci1jdmUtZWRpdG9yaWFsLWJv
YXJkLWxpc3RAbGlzdHMubWl0cmUub3JnIFttYWlsdG86b3duZXItY3ZlLWVkaXRvcmlhbC1ib2Fy
ZC1saXN0QGxpc3RzLm1pdHJlLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2VudF9MYW5kZmll
bGRATWNBZmVlLmNvbTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDA3LCAyMDEy
IDE6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IGN2ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5t
aXRyZS5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gQ291bnRpbmcgb24gQ1ZFczxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5XZSBoYXZlIHByb2JsZW1zIHdp
dGggQ1ZFIHJlcG9ydGluZyB0aGF0IGFyZSBrbm93biBpc3N1ZXMgYnV0IHdoaWNoIGFyZSBiZWNv
bWluZyBhcHBhcmVudCB0byBtYW55IG1vcmUgYW5kIGNvdWxkIGVhc2lseSB1bmRlcm1pbmUgdGhl
IHVzZWZ1bG5lc3Mgb2YgQ1ZFIGlkZW50aWZpY2F0aW9uIGlmIGxlZnQgdW5jaGVja2VkLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij5XZSBkaXNjdXNzZWQgdGhpcyBhdCB0aGUgSVRTQUMgY29uZmVyZW5jZSBpbiB0aGUgRnV0dXJl
IG9mIFZ1bG5lcmFiaWxpdHkgUmVwb3J0aW5nIFdvcmtzaG9wIGFuZCBhdCB0aGUgZm9sbG93LW9u
IFZ1bG5lcmFiaWxpdHkgUmVwb3J0aW5nIGRheSBhdCB0aGUgU29mdHdhcmUgQXNzdXJhbmNlIGV2
ZW50IGEgbW9udGggbGF0ZXIuIChUaGVyZSB3ZXJlIGFjdGlvbiBpdGVtcw0KIG91dCBvZiB0aGUg
bGF0dGVyIHRoYXQgSSBhbSBub3QgYXdhcmUgaGF2ZSBiZWVuIGNvbXBsZXRlZOKApik8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
SSBoYXZlIGp1c3QgaGFkIGEgdmVyeSBjb25jZXJuaW5nIGRpc2N1c3Npb24gYWJvdXQgdGhlIHVz
ZWZ1bG5lc3Mgb2YgQ1ZFcyBhcyBhIG1lYW5zIHRvIG1lYXN1cmUgdnVsbmVyYWJpbGl0aWVzIHRv
ZGF5IGFuZCB0aGUgZGVjYXkgb2YgaXRzIHZhbHVlIGlmIHRoZSB0cmVuZCBjb250aW51ZXMuICZu
YnNwOyBUaGUgZGlzY3Vzc2lvbiBjZW50ZXJlZCBhcm91bmQgdGhlIGFjY3VyYWN5DQogb2YgdGhl
IG51bWJlcnMgb2YgQ1ZFcyBpZGVudGlmaWVkIGNvbXBhcmVkIHRvIHRob3NlIHJlcG9ydGVkIGlu
IHRoZSBjb21tdW5pdHkgYXMgYSB3aG9sZS4gJm5ic3A7SWYgd2UgbG9va2VkIGF0IGp1c3QgdGhl
IENWRSBudW1iZXJzLCAmbmJzcDtpdCBhcHBlYXJzIHRoYXQgdGhlIG51bWJlcnMgb2YgdnVsbmVy
YWJpbGl0aWVzIGhhdmUgYmVlbiBkcm9wcGluZyBzaW5jZSBhIGhpZ2ggaW4gMjAwOC4gJm5ic3A7
IFRoaXMgaXMgYSByYXRoZXIgaW1wb3J0YW50IGVycm9yLiBBcw0KIHdlIGFsbCBrbm93LCB0aGlz
IGlzIG5vdCBhY2N1cmF0ZS4gVnVsbmVyYWJpbGl0aWVzIGhhdmUgbm90IGJlZW4gZHJvcHBpbmcs
IHRoZXkgYXJlIGdyb3dpbmcsIG5vdCBkcm9wcGluZyBieSAzMCUuICZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gb3Ig
dGhlIHZlbmRvciBjb21tdW5pdHksIHRoZXNlIHRyZW5kcyBoYXZlIHJhdGhlciBjb25jZXJuaW5n
IHBvdGVudGlhbCBpbXBhY3RzIG9uIHVzLiAmbmJzcDtGaXJzdCwgb3VyIHZ1bG5lcmFiaWxpdHkg
cmVzZWFyY2ggZGF0YWJhc2VzIHVzZSBDVkUgYXMgYSBwcmltYXJ5IHJlZmVyZW5jZS4gJm5ic3A7
VGhlIENWRSBJZCBoYXMgYmVlbiBhdXRob3JpdGF0aXZlIGluIHRoZSBwYXN0Lg0KICZuYnNwO0l0
IGlzIHVzZWQgaW50ZXJuYWxseSBhcyBhIG1lYW5zIHRvIGNvbW11bmljYXRlIHZ1bG5lcmFiaWxp
dHkgcmVjb3JkIGluZm9ybWF0aW9uIGJldHdlZW4gZmllbGRlZCBwcm9kdWN0cyBhbmQgYmV0d2Vl
biByZXNlYXJjaCBhbmFseXNpcyB0ZWFtcy4gJm5ic3A7QXMgdGhlIG51bWJlcnMgZGVjbGluZSwg
aXQgbWVhbnMgd2UgYXJlIGZvcmNlZCB0byBsb29rIGVsc2V3aGVyZSB0byBwcm92aWRlIHRoZSBp
ZGVudGlmaWNhdGlvbiBhbmQgY29tbXVuaWNhdGlvbg0KIHRoYXQgQ1ZFIHByb3ZpZGVkIGluIHRo
ZSBwYXN0LiBNb3JlIHByb3ByaWV0YXJ5IGlkcyBhcmUgYmVjb21pbmcgbW9yZSB0aGUgbm9ybS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+VGhlIG1vcmUgc2VyaW91cyBjb25jZXJuIGlzIHdoYXQgaXQgaXMgc2hvd2luZyB0byBl
eGVjdXRpdmVzIG9mIGNvbXBhbmllcy4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZxdW90O0lmIHRoZSB2dWxu
ZXJhYmlsaXRpZXMgaGF2ZSBkcm9wcGVkICZuYnNwOzMwJSBzaW5jZSAyMDA4LCB3aHkgZG8gSSBu
ZWVkIHRvIGJlIGZ1bmRpbmcgdGhlIHNlY3VyaXR5IHN0YWZmIGFuZCBlZmZvcnRzIGF0IHRoZSBy
YXRlIEkgYW0/ICZuYnNwO0kgc2VlIHRoYXQgTUlUUkUgaXMgcmVwb3J0aW5nIGFuIG92ZXJhbGwg
ZHJvcCBlYWNoIHllYXIgc2luY2UgMjAwOCBidXQgeWV0DQogeW91IGZvbGtzIGtlZXAgY29taW5n
IHRvIG1lIHNheWluZyB0aGF0IHRoZSB0aHJlYXRzIGFyZSBtdWNoIHdvcnNlIGFuZCB3ZSBtYXkg
YmUgaW4gdGhlIHNhbWUgcmVsYXRpdmUgc2l0dWF0aW9uIHdlIHdlcmUgd2hlbiBtYWx3YXJlIHNw
aWtlZCBhIGNvdXBsZSB5ZWFycyBwYXN04oCmJnF1b3Q7PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj5Gb3IgdGhvc2UgdGhhdCBhY3RpdmVseSB3b3JrIGluIHRoaXMg
ZW52aXJvbm1lbnQsIHdlIGtub3cgdnVsbmVyYWJpbGl0aWVzIGhhdmUgbm90IGRyb3BwZWQgMzAl
IHNpbmNlIDIwMDguIFF1aXRlIHRoZSBjb250cmFyeSwgb3VyIGludGVybmFsIG51bWJlcnMgaW5k
aWNhdGUgYW4gaW5jcmVhc2luZyB0cmVuZCBzaW1pbGFyIHRvIGEgMzAlIHJpc2UuICZuYnNwO1N5
bWFudGVjDQogaGFzIGFsc28gcmVwb3J0ZWQgYSBzaW1pbGFyIHRyZW5kLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+T25lIG9mIHRoZSBtYWpvciBwcm9ibGVtcyBpcyB0aGF0IE1J
VFJFIGZ1bmRpbmcgaXMgbm90IHdoYXQgaXQgc2hvdWxkIGJlLiBPbiBtdWx0aXBsZSBvY2Nhc2lv
bnMgd2UgaGF2ZSBiZWVuIGFza2VkIHRvIHRhcmdldCB0aGUgY2xhc3NlcyBvZiBwcm9kdWN0cyB3
aGVyZSB2dWxuZXJhYmlsaXRpZXMgYXJlIGNvbnNpZGVyZWQgdGhlIG1vc3QgY3JpdGljYWwgYW5k
IHdoaWNoDQogc291cmNlcyBzaG91bGQgYmUgbW9uaXRvcmVkLiBUaGUgdmlldyBvZiB3aGF0IHRv
IHRhcmdldCBhbmQgbW9uaXRvciBnZXRzIHNtYWxsZXIgYW5kIHNtYWxsZXIgYXMgZnVuZGluZyBp
cyAmbmJzcDtoZWxkIGxldmVsIG9yIHJlZHVjZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkF0IG9uZSBwb2ludCB0aGUgaW50
ZW50IG9mIHRoZSBlZmZvcnQgd2FzIHRvIGNvdmVyIGFsbCBwdWJsaXNoZWQgdnVsbmVyYWJpbGl0
aWVzIHRoYXQgY291bGQgYmUgY29ycm9ib3JhdGVkIGluIHNvbWUgZmFzaGlvbi4gJm5ic3A7T3Zl
ciB0aGUgeWVhcnMgdGhlIHJlYWxpdHkgaGFzIHNldCBpbiB0aGF0IHRoaXMgaXMgYSB2ZXJ5IHJl
c291cmNlIGludGVuc2l2ZSBvcGVyYXRpb24uDQogJm5ic3A7QXMgc3VjaCB0aGUgZm9jdXMgb2Yg
dGhlIGVmZm9ydCBoYXMgcmVkdWNlZCB3aGF0IGlzIHJlcG9ydGVkIG9uIHRvIGFzc3VyZSBDVkVz
IGNhbiBiZSBhc3NpZ25lZCBmb3IgdGhlIHR5cGVzIG9mIHByb2R1Y3RzICZuYnNwO21vc3QgaW1w
b3J0YW50IHRvIHRoZSBFZGl0b3JpYWwgQm9hcmQgcGFydGljaXBhbnRzIGFuZCB0aGVpciBzcG9u
c29yLiAmbmJzcDtUaGlzIGdpdmVzIGFuIGFydGlmaWNpYWwgdmlldyBvZiB0aGUgbnVtYmVycyBv
ZiBleGlzdGluZyB2dWxuZXJhYmlsaXRpZXMNCiBhbmQgdGhhdCBpcyBiZWluZyByZWNvZ25pemVk
IG91dHNpZGUgdGhlIHZ1bG5lcmFiaWxpdHkgY29tbXVuaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Bbm90aGVyIHByb2Js
ZW0gaXMgdGhlIENWRSBmb3JtYXQgaXRzZWxmLiAmbmJzcDtUaGVyZSBoYXMgYmVlbiBhbiBhY3Rp
dmUgZGlzY3Vzc2lvbiBhYm91dCB0aGUgZm9ybWF0IGxpbWl0YXRpb25zIGFzIHdlbGwuIFRoZSBD
VkUgZm9ybWF0IGlzIENWRS1ZWVlZLU5OTk4uIFRoaXMgbWVhbnMgdGhhdCBjdXJyZW50bHkgd2Ug
Y2Fubm90IGhhdmUgbW9yZSB0aGFuIDEwLDAwMCBDVkVzDQogcmVwb3J0ZWQgaW4gYSBzaW5nbGUg
eWVhci4gJm5ic3A7QXQgdGhlIHJhdGVzIHdlIGFyZSBzZWVpbmcgaW50ZXJuYWxseSwgd2UgYXJl
IGFscmVhZHkgdGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPlRoZW4gdGhlcmUgYXJlIHRoZSBsaW1pdGF0aW9ucyBvZiBD
VkUgcHJvY2VzcyBpbiBnZW5lcmFsLiAmbmJzcDtUaGUgZm9jdXMgaXMgRW5nbGlzaCBvbmx5IGFs
dGhvdWdoIHNvbWUgbm9uLVVTIHZ1bG5lcmFiaWxpdGllcyBkbyBnZXQgYXNzaWduZWQgZnJvbSB0
aW1lIHRvIHRpbWUuICZuYnNwO0NWRSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpbnRlcm5hdGlvbmFs
IGNvbW11bml0eSBhbmQNCiBzb2Z0d2FyZSB3cml0dGVuIGZvciBub24tRW5nbGlzaCBnZW8tY2Vu
dHJpYyBhcmVhcyBhcmUgbm90IGluY2x1ZGVkLiAmbmJzcDtXaGlsZSB0aGlzIGhhcyBub3QgYmVl
biBhIGNvbmNlcm4gZm9yIFVTLW9ubHkgc29mdHdhcmUgdmVuZG9ycywgdGhlcmUgaXMgYSBncmVh
dCBkZWFsIG9mIHJlZ2lvbmFsIHNvZnR3YXJlIHdyaXR0ZW4gZm9yIG1ham9yIGVtZXJnaW5nIG1h
cmtldHMuICZuYnNwO05vbmUgb2YgdGhvc2UgdnVsbmVyYWJpbGl0aWVzIGFyZSBpZGVudGlmaWVk
DQogYnkgYSBDVkUuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PkdpdmVuIHRoZXNlIGNvbnN0cmFpbnRzLCBpdCBzZWVtcyBsaWtlIGl0IGlzIHRpbWUgdG8gZmln
dXJlIG91dCBob3cgdG8gYWRkcmVzcyB0aGUgaXNzdWVzIGluIGEgbW9yZSBvZiBhIGNyZWF0aXZl
IHdheS4gJm5ic3A7V2Uga25vdyB0aGUgY29uc3RyYWludHMuIElzIHRoZXJlIHNvbWV0aGluZyB3
ZSBjYW4gZG8gdG8gYXVnbWVudCB0aGUgTUlUUkUgc3RhZmYgaW4gY2VydGFpbg0KIGFyZWFzIHRo
YXQgd291bGQgaGVscD8gJm5ic3A7SSBjYW4gc2VlIHRoZSBmb3JtYXQgaXNzdWUgYmVpbmcgYSBy
YXRoZXIgZWFzeSBvbmUgdG8gYXR0YWNrIGJ1dCBpdCBpcyB0aGUgY292ZXJhZ2UgaXNzdWUgdGhh
dCBpcyBtb3N0IGNvbmNlcm5pbmcuICZuYnNwO09yIHdlIHNob3VsZCBpZ25vcmUgaXQgYW5kIHNs
b3dseSBsZXQgdGhlIHZhbHVlIG9mIENWRSB0byB0aGUgY29tbXVuaXR5IGFuZCB2ZW5kb3JzIGRl
Y2F54oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPlRob3VnaHRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2MDZBNzEi
PktlbnQgTGFuZGZpZWxkPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojNjA2QTcxIj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+RGlyZWN0
b3IgQ29udGVudCBTdHJhdGVneSwgQXJjaGl0ZWN0dXJlIGFuZCBTdGFuZGFyZHM8L3NwYW4+PGJy
Pg0KPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWNBZmVlIHwgQW4gSW50ZWwgQ29tcGFueTwvc3Bh
bj48L3N0cm9uZz48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+NTAwMCBIZWFk
cXVhcnRlcnMgRHIuPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5Q
bGFubywgVGV4YXMgNzUwMjQ8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0
eWxlLXNwYW4iPkRpcmVjdDogJiM0MzsxLjk3Mi45NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+DQo8
c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+TW9iaWxlOiAmIzQzOzEuODE3LjYzNy44MDI2
PC9zcGFuPjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlYjombmJzcDs8L3NwYW4+PC9zdHJvbmc+
PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxhIGhyZWY9Imh0dHA6Ly93d3cubWNhZmVl
LmNvbS8iPnd3dy5tY2FmZWUuY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K
--_000_ED311CBEE6993C428563DEDF6D083BC81180FBF7usilms113bcacom_--
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Wed Mar 7 17:19:17 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q27MJGnK026290;
Wed, 7 Mar 2012 17:19:16 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 768FB21B0D05;
Wed, 7 Mar 2012 17:19:11 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1023321B16C8;
Wed, 7 Mar 2012 17:19:11 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS03.MITRE.ORG (129.83.29.80) with
Microsoft SMTP Server id 14.1.339.1; Wed, 7 Mar 2012 17:19:10 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4520563 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Wed, 7 Mar
2012 17:19:01 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Wed, 7 Mar 2012 17:19:01 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13238539; Wed, 07 Mar 2012 17:18:52 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 7ECC721B100A for
<cve-editorial-board-list@lists.mitre.org>; Wed, 7 Mar 2012
17:18:52 -0500 (EST)
Received: from Crappie.rc.on.ca (unknown [207.176.151.2]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id CB92F21B0A35 for
<cve-editorial-board-list@lists.mitre.org>; Wed, 7 Mar 2012
17:18:48 -0500 (EST)
Received: from Sunfish.rc.on.ca (207.176.151.130) by Crappie.rc.on.ca
(207.176.151.10) with Microsoft SMTP Server (TLS) id 14.0.722.0;
Wed, 7 Mar 2012 17:18:43 -0500
Received: from Sunfish.rc.on.ca ([fe80::b9b7:df1e:3af9:3ad3]) by
Sunfish.rc.on.ca ([fe80::b9b7:df1e:3af9:3ad3%16]) with mapi; Wed, 7
Mar 2012 17:18:43 -0500
From: Russ Cooper <Russ.Cooper@rc.on.ca>
To: "Williams, James K" <James.Williams@ca.com>,
"cve-editorial-board-list@lists.mitre.org"
<cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zAABoepgAAKeHVA=
Date: Wed, 7 Mar 2012 22:18:41 +0000
Message-ID: <A27B80707A1E924891446594C00EBA8C52B245E2@Sunfish.rc.on.ca>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<ED311CBEE6993C428563DEDF6D083BC81180FBF7@usilms113b.ca.com>
In-Reply-To: <ED311CBEE6993C428563DEDF6D083BC81180FBF7@usilms113b.ca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative;
boundary="_000_A27B80707A1E924891446594C00EBA8C52B245E2Sunfishrconca_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.7.220319
X-MITRE-External: True
X-PerlMx-Spam: Gauge=XII, Probability=12%, Report=' HTML_999_100 0.6,
HTML_90_100 0.1, HTML_95_100 0.1, HTML_98_100 0.1,
HTML_99_100 0.1, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0,
RDNS_SERVFAIL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CP_URI_IN_BODY 0,
__CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
__CTYPE_MULTIPART_ALT 0, __FRAUD_CONTACT_NAME 0, __HAS_HTML 0,
__HAS_MSGID 0, __HIGHBITS 0, __HTML_FONT_BLUE 0,
__HTML_MSWORD 0, __IMS_MSGID 0, __INT_PROD_LOC 0, __MIME_HTML 0,
__MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_8 0,
__STYLE_RATWARE_2 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0,
__URI_NS '
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 37012
Status: R
X-Status:
X-Keywords:
--_000_A27B80707A1E924891446594C00EBA8C52B245E2Sunfishrconca_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
SGkgYWxsLCBsb25nIHRpbWUgbm8gc2Vl4oCmOy1dIChidHcsIHVuZW1wbG95ZWQgYW5kIGludGVy
ZXN0ZWQpDQoNClByb2JsZW0gIzEgaXMgdGhlIGRlZmluaXRpb24gb2Yg4oCcdnVsbmVyYWJpbGl0
eeKAnSwgcHJvYmxlbSAjMiBpcyB0aGUgdW5kZXJzdGFuZGluZyBvZiB0aGUgd29yZCDigJxlbnVt
ZXJhdGlvbuKAnSwgSU1P4oCmYnV0IHRoZW4gSSBhbSBpbmNyZWRpYmx5IG91dCBvZiBkYXRlIHNp
bmNlIEkgc2VlIG5vdyB0aGF0IOKAnEXigJ0gc3RhbmRzIGZvciDigJxFeHBvc3VyZXPigJ0sIG5v
dCDigJxFbnVtZXJhdGlvbuKAneKApnNpZ2gsIHRvdWdoIHRvIGdldCBvbGQuDQoNCkZvciBleGFt
cGxlLCBJIGhhdmUgc2VlbiB3aGF0IGFwcGVhcnMgdG8gYmUgdGhlIHVzZSBkaWZmZXJlbnQgQ1ZF
IG51bWJlcnMgZm9yIHRoZSBzYW1lIHZ1bG5lcmFiaWxpdHkgaW4gZGlmZmVyZW50IHByb2R1Y3Rz
4oCmdGhpcyBvdmVyLWluZmxhdGVzIHRoZSBDVkVzIHVubmVjZXNzYXJpbHkuIEEgdnVsbmVyYWJp
bGl0eSwgd2hpY2ggZm9yIGFsbCBpbnRlbnRzIGFuZCBwdXJwb3NlcyBpcyB0aGUgc2FtZSBhcyBh
IHByZXZpb3VzIHZ1bG5lcmFiaWxpdHksIGdldHMgYSBuZXcgQ1ZFIGJlY2F1c2UgcHJvZHVjdHMg
d2FudCB0byB0ZXN0IGZvciBzY2VuYXJpbyBBIGFuZCBzY2VuYXJpbyBC4oCmdGhpcyBlcXVhbGx5
IGluZmxhdGVzIENWRXMgdW5uZWNlc3NhcmlseS4NCg0K4oCcSW4gdGhlIGJlZ2lubmluZ+KAneKA
pndlIHRhbGtlZCBhYm91dCBuZWVkaW5nIDEgQ1ZFIG51bWJlciB0byByZXByZXNlbnQgaW50ZWdl
ciBvdmVyZmxvdywgb3IgYW5vdGhlciBmb3IgIGluc3VmZmljaWVudCBwYXJzaW5n4oCmY2xlYXJs
eSB0aGF0IG5ldmVyIHN0dWNrLiBCdXQgZXF1YWxseSwgaXQgd291bGQgc2VlbSB0aGF0IHNvbWUg
dmVuZG9ycyB3b3VsZCBsaWtlIHRvIGFzc2lnbiBhIENWRSBwZXIg4oCcdGhyZWF04oCdLCB3aGlj
aCBzaG91bGQgYWxzbyBoYXZlIG5ldmVyIHN0dWNrLg0KDQpJ4oCZbSB1bmF3YXJlIG9mID4gMTAs
MDAwIG5ldyB2dWxuZXJhYmlsaXRpZXMgcGVyIHllYXIsIGF0IGxlYXN0IG5vdCBpbiB3aGF0IEkg
d291bGQgY29uc2lkZXIg4oCcbmV3IHZ1bG5lcmFiaWxpdGllc+KAnS4gVGhhdOKAmXMgb25lIGhl
Y2sgb2YgYSBsb3Qgb2YgbGluZXMgb2YgY29kZSwgYnV0IGlmIHlvdeKAmXJlIGNvdW50aW5nIHZ1
bG5lcmFiaWxpdGllcyBpbiBBbmRyb2lkIEFwcHMsIHRoZW4gSSBjb3VsZCBhbHNvIHNlZSB0aGF0
IG51bWJlciBiZSBpbmNyZWRpYmx5IGxvdy4gU28gcGVyaGFwcyB0aGUgaXNzdWVzIGFyZW7igJl0
IHdpdGggdnVsbmVyYWJpbGl0aWVzLCBidXQgaW5zdGVhZCB3aXRoIGV4cG9zdXJlcz8/DQoNCkkg
cmVtZW1iZXIgdGhhdCBhdCBzb21lIHBvaW50IHRoZSBhcHBsaWNhdGlvbiBmb3IgQ1ZFcyB3YXMg
bW9yZSBvciBsZXNzIGd1YXJhbnRlZWQgaWYgZG9uZSBieSBrbm93biBvcmdhbml6YXRpb25zLCBi
dXQgdGhhdCB3YXMgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgaXNzdWVzIHdvdWxkIGJlIHZh
bGlkYXRlZCBhbmQgdGhlIENBTiBwcm92ZW4gbm90IHJlcXVpcmVkLiBXaXRoIGEgbGFjayBvZiBm
dW5kaW5nLCB0aGF0IG1hcHBpbmcgKG9yIHZldHRpbmcpIHN1cmVseSBpc27igJl0IGdldHRpbmcg
dGhlIGF0dGVudGlvbiBpdCBuZWVkcy4gSWYgaXQgZGlkLCBwZXJoYXBzIG1hbnkgQ1ZFcyBjb3Vs
ZCBiZSBzYXZlZCBvciByZWNhbGxlZOKApmJ1dCB0aGVuIHRoZSB3YXkgdGhleSBhcmUgdXNlZCB0
b2RheSB0aGF0IHdvdWxkIGVpdGhlciBsZWFkIHRvIGVtYmFycmFzc21lbnQsIG9yIHNpZ25pZmlj
YW50IGludmVzdG1lbnQgYnkgdGhlIHBlb3BsZSB1c2luZyB0aGVpciBvd24gQ1ZFcy4NCg0KT25l
IHRoaW5nIEkgd291bGQgZXhwZWN0IHRvIHNlZSBhIOKAnENvbW1lbnRz4oCdIGZlYXR1cmUgdXNl
ZCBmb3IgaXMgdG8gc2F5IHRoYXQgMiAob3IgbW9yZSkgZGlmZmVyZW50IENWRXMgcmVwcmVzZW50
IOKAnG1vcmUgb3IgbGVzc+KAnSB0aGUgc2FtZSB0aGluZ+KApmFuZCB0aGVuIGRvY3VtZW50cyB0
aGUgd2F5IHRvIGFkZHJlc3MgdGhlIGlzc3VlIGFjcm9zcyBkaWZmZXJlbnQgcGxhdGZvcm1zL3By
b2R1Y3RzL3ZlbmRvcnPigKYNCg0KSeKAmWQgc2F5IG1vcmUsIGJ1dCBJIHJlYWxseSBnb3R0YSBy
ZWFkIHVwIG9uIGp1c3Qgd2hhdCB0aGUgaGVjayDigJxleHBvc3VyZXPigJ0gYXJlLg0KDQpDaGVl
cnMsDQpSdXNzIOKAkyBmb3JtZXJseSBOVEJ1Z3RyYXEgRWRpdG9y4oCmY3VycmVudGx5IHJhaXNp
bmcgY2hpY2tlbnMgYW5kIGJ1aWxkaW5nIGEgY2hlYXBlciBob3VzZS4NCg0KRnJvbTogb3duZXIt
Y3ZlLWVkaXRvcmlhbC1ib2FyZC1saXN0QGxpc3RzLm1pdHJlLm9yZyBbbWFpbHRvOm93bmVyLWN2
ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmddIE9uIEJlaGFsZiBPZiBXaWxs
aWFtcywgSmFtZXMgSw0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwNywgMjAxMiAzOjQ1IFBNDQpU
bzogY3ZlLWVkaXRvcmlhbC1ib2FyZC1saXN0QGxpc3RzLm1pdHJlLm9yZw0KU3ViamVjdDogUkU6
IENvdW50aW5nIG9uIENWRXMNCg0KQWdyZWUgd2l0aCBldmVyeXRoaW5nIEtlbnQgc2FpZC4NCg0K
T25lIGltcG9ydGFudCBjaGFuZ2UgSSB3b3VsZCBsaWtlIHRvIHNlZSBpcyB0aGUgYWRkaXRpb24g
b2YgYSDigJxDb21tZW50c+KAnSBmZWF0dXJlIG9uIGVhY2ggQ1ZFIHBhZ2UgYXQgY3ZlLm1pdHJl
Lm9yZy4gIFRoZSBDb21tZW50cyBmZWF0dXJlIGNvdWxkIGJlIHVzZWQgYnkgRWRpdG9yaWFsIEJv
YXJkIG1lbWJlcnMgKGFuZCBvdGhlciB2ZXR0ZWQgaW5kaXZpZHVhbHM/KSB0byBhZGQgaW5mbyBz
dWNoIGFzIGNvcnJlY3Rpb25zLCBhZGRpdGlvbmFsIHJlZmVyZW5jZXMsIHZlbmRvciByZXNwb25z
ZXMsIGV0Yy4NCg0KVGhhbmtzIGFuZCByZWdhcmRzLA0KS2VuIFdpbGxpYW1zLCBEaXJlY3Rvcg0K
Q0EgVGVjaG5vbG9naWVzIFByb2R1Y3QgVnVsbmVyYWJpbGl0eSBSZXNwb25zZSBUZWFtDQpDQSBU
ZWNobm9sb2dpZXMgQnVzaW5lc3MgVW5pdCBPcGVyYXRpb25zDQp3aWxqYTIyQGNhLmNvbTxtYWls
dG86d2lsamEyMkBjYS5jb20+IC0gODE2LTkxNC00MjI1DQoNCg0KDQpGcm9tOiBvd25lci1jdmUt
ZWRpdG9yaWFsLWJvYXJkLWxpc3RAbGlzdHMubWl0cmUub3JnPG1haWx0bzpvd25lci1jdmUtZWRp
dG9yaWFsLWJvYXJkLWxpc3RAbGlzdHMubWl0cmUub3JnPiBbbWFpbHRvOm93bmVyLWN2ZS1lZGl0
b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmddPG1haWx0bzpbbWFpbHRvOm93bmVyLWN2
ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmddPiBPbiBCZWhhbGYgT2YgS2Vu
dF9MYW5kZmllbGRATWNBZmVlLmNvbTxtYWlsdG86S2VudF9MYW5kZmllbGRATWNBZmVlLmNvbT4N
ClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDcsIDIwMTIgMTo1MyBQTQ0KVG86IGN2ZS1lZGl0b3Jp
YWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmc8bWFpbHRvOmN2ZS1lZGl0b3JpYWwtYm9hcmQt
bGlzdEBsaXN0cy5taXRyZS5vcmc+DQpTdWJqZWN0OiBDb3VudGluZyBvbiBDVkVzDQoNCkFsbCwN
Cg0KV2UgaGF2ZSBwcm9ibGVtcyB3aXRoIENWRSByZXBvcnRpbmcgdGhhdCBhcmUga25vd24gaXNz
dWVzIGJ1dCB3aGljaCBhcmUgYmVjb21pbmcgYXBwYXJlbnQgdG8gbWFueSBtb3JlIGFuZCBjb3Vs
ZCBlYXNpbHkgdW5kZXJtaW5lIHRoZSB1c2VmdWxuZXNzIG9mIENWRSBpZGVudGlmaWNhdGlvbiBp
ZiBsZWZ0IHVuY2hlY2tlZC4NCg0KV2UgZGlzY3Vzc2VkIHRoaXMgYXQgdGhlIElUU0FDIGNvbmZl
cmVuY2UgaW4gdGhlIEZ1dHVyZSBvZiBWdWxuZXJhYmlsaXR5IFJlcG9ydGluZyBXb3Jrc2hvcCBh
bmQgYXQgdGhlIGZvbGxvdy1vbiBWdWxuZXJhYmlsaXR5IFJlcG9ydGluZyBkYXkgYXQgdGhlIFNv
ZnR3YXJlIEFzc3VyYW5jZSBldmVudCBhIG1vbnRoIGxhdGVyLiAoVGhlcmUgd2VyZSBhY3Rpb24g
aXRlbXMgb3V0IG9mIHRoZSBsYXR0ZXIgdGhhdCBJIGFtIG5vdCBhd2FyZSBoYXZlIGJlZW4gY29t
cGxldGVk4oCmKQ0KDQpJIGhhdmUganVzdCBoYWQgYSB2ZXJ5IGNvbmNlcm5pbmcgZGlzY3Vzc2lv
biBhYm91dCB0aGUgdXNlZnVsbmVzcyBvZiBDVkVzIGFzIGEgbWVhbnMgdG8gbWVhc3VyZSB2dWxu
ZXJhYmlsaXRpZXMgdG9kYXkgYW5kIHRoZSBkZWNheSBvZiBpdHMgdmFsdWUgaWYgdGhlIHRyZW5k
IGNvbnRpbnVlcy4gICBUaGUgZGlzY3Vzc2lvbiBjZW50ZXJlZCBhcm91bmQgdGhlIGFjY3VyYWN5
IG9mIHRoZSBudW1iZXJzIG9mIENWRXMgaWRlbnRpZmllZCBjb21wYXJlZCB0byB0aG9zZSByZXBv
cnRlZCBpbiB0aGUgY29tbXVuaXR5IGFzIGEgd2hvbGUuICBJZiB3ZSBsb29rZWQgYXQganVzdCB0
aGUgQ1ZFIG51bWJlcnMsICBpdCBhcHBlYXJzIHRoYXQgdGhlIG51bWJlcnMgb2YgdnVsbmVyYWJp
bGl0aWVzIGhhdmUgYmVlbiBkcm9wcGluZyBzaW5jZSBhIGhpZ2ggaW4gMjAwOC4gICBUaGlzIGlz
IGEgcmF0aGVyIGltcG9ydGFudCBlcnJvci4gQXMgd2UgYWxsIGtub3csIHRoaXMgaXMgbm90IGFj
Y3VyYXRlLiBWdWxuZXJhYmlsaXRpZXMgaGF2ZSBub3QgYmVlbiBkcm9wcGluZywgdGhleSBhcmUg
Z3Jvd2luZywgbm90IGRyb3BwaW5nIGJ5IDMwJS4NCg0KRm9yIHRoZSB2ZW5kb3IgY29tbXVuaXR5
LCB0aGVzZSB0cmVuZHMgaGF2ZSByYXRoZXIgY29uY2VybmluZyBwb3RlbnRpYWwgaW1wYWN0cyBv
biB1cy4gIEZpcnN0LCBvdXIgdnVsbmVyYWJpbGl0eSByZXNlYXJjaCBkYXRhYmFzZXMgdXNlIENW
RSBhcyBhIHByaW1hcnkgcmVmZXJlbmNlLiAgVGhlIENWRSBJZCBoYXMgYmVlbiBhdXRob3JpdGF0
aXZlIGluIHRoZSBwYXN0LiAgSXQgaXMgdXNlZCBpbnRlcm5hbGx5IGFzIGEgbWVhbnMgdG8gY29t
bXVuaWNhdGUgdnVsbmVyYWJpbGl0eSByZWNvcmQgaW5mb3JtYXRpb24gYmV0d2VlbiBmaWVsZGVk
IHByb2R1Y3RzIGFuZCBiZXR3ZWVuIHJlc2VhcmNoIGFuYWx5c2lzIHRlYW1zLiAgQXMgdGhlIG51
bWJlcnMgZGVjbGluZSwgaXQgbWVhbnMgd2UgYXJlIGZvcmNlZCB0byBsb29rIGVsc2V3aGVyZSB0
byBwcm92aWRlIHRoZSBpZGVudGlmaWNhdGlvbiBhbmQgY29tbXVuaWNhdGlvbiB0aGF0IENWRSBw
cm92aWRlZCBpbiB0aGUgcGFzdC4gTW9yZSBwcm9wcmlldGFyeSBpZHMgYXJlIGJlY29taW5nIG1v
cmUgdGhlIG5vcm0uDQoNClRoZSBtb3JlIHNlcmlvdXMgY29uY2VybiBpcyB3aGF0IGl0IGlzIHNo
b3dpbmcgdG8gZXhlY3V0aXZlcyBvZiBjb21wYW5pZXMuDQoNCiJJZiB0aGUgdnVsbmVyYWJpbGl0
aWVzIGhhdmUgZHJvcHBlZCAgMzAlIHNpbmNlIDIwMDgsIHdoeSBkbyBJIG5lZWQgdG8gYmUgZnVu
ZGluZyB0aGUgc2VjdXJpdHkgc3RhZmYgYW5kIGVmZm9ydHMgYXQgdGhlIHJhdGUgSSBhbT8gIEkg
c2VlIHRoYXQgTUlUUkUgaXMgcmVwb3J0aW5nIGFuIG92ZXJhbGwgZHJvcCBlYWNoIHllYXIgc2lu
Y2UgMjAwOCBidXQgeWV0IHlvdSBmb2xrcyBrZWVwIGNvbWluZyB0byBtZSBzYXlpbmcgdGhhdCB0
aGUgdGhyZWF0cyBhcmUgbXVjaCB3b3JzZSBhbmQgd2UgbWF5IGJlIGluIHRoZSBzYW1lIHJlbGF0
aXZlIHNpdHVhdGlvbiB3ZSB3ZXJlIHdoZW4gbWFsd2FyZSBzcGlrZWQgYSBjb3VwbGUgeWVhcnMg
cGFzdOKApiINCg0KRm9yIHRob3NlIHRoYXQgYWN0aXZlbHkgd29yayBpbiB0aGlzIGVudmlyb25t
ZW50LCB3ZSBrbm93IHZ1bG5lcmFiaWxpdGllcyBoYXZlIG5vdCBkcm9wcGVkIDMwJSBzaW5jZSAy
MDA4LiBRdWl0ZSB0aGUgY29udHJhcnksIG91ciBpbnRlcm5hbCBudW1iZXJzIGluZGljYXRlIGFu
IGluY3JlYXNpbmcgdHJlbmQgc2ltaWxhciB0byBhIDMwJSByaXNlLiAgU3ltYW50ZWMgaGFzIGFs
c28gcmVwb3J0ZWQgYSBzaW1pbGFyIHRyZW5kLg0KDQpPbmUgb2YgdGhlIG1ham9yIHByb2JsZW1z
IGlzIHRoYXQgTUlUUkUgZnVuZGluZyBpcyBub3Qgd2hhdCBpdCBzaG91bGQgYmUuIE9uIG11bHRp
cGxlIG9jY2FzaW9ucyB3ZSBoYXZlIGJlZW4gYXNrZWQgdG8gdGFyZ2V0IHRoZSBjbGFzc2VzIG9m
IHByb2R1Y3RzIHdoZXJlIHZ1bG5lcmFiaWxpdGllcyBhcmUgY29uc2lkZXJlZCB0aGUgbW9zdCBj
cml0aWNhbCBhbmQgd2hpY2ggc291cmNlcyBzaG91bGQgYmUgbW9uaXRvcmVkLiBUaGUgdmlldyBv
ZiB3aGF0IHRvIHRhcmdldCBhbmQgbW9uaXRvciBnZXRzIHNtYWxsZXIgYW5kIHNtYWxsZXIgYXMg
ZnVuZGluZyBpcyAgaGVsZCBsZXZlbCBvciByZWR1Y2VkLg0KDQpBdCBvbmUgcG9pbnQgdGhlIGlu
dGVudCBvZiB0aGUgZWZmb3J0IHdhcyB0byBjb3ZlciBhbGwgcHVibGlzaGVkIHZ1bG5lcmFiaWxp
dGllcyB0aGF0IGNvdWxkIGJlIGNvcnJvYm9yYXRlZCBpbiBzb21lIGZhc2hpb24uICBPdmVyIHRo
ZSB5ZWFycyB0aGUgcmVhbGl0eSBoYXMgc2V0IGluIHRoYXQgdGhpcyBpcyBhIHZlcnkgcmVzb3Vy
Y2UgaW50ZW5zaXZlIG9wZXJhdGlvbi4gIEFzIHN1Y2ggdGhlIGZvY3VzIG9mIHRoZSBlZmZvcnQg
aGFzIHJlZHVjZWQgd2hhdCBpcyByZXBvcnRlZCBvbiB0byBhc3N1cmUgQ1ZFcyBjYW4gYmUgYXNz
aWduZWQgZm9yIHRoZSB0eXBlcyBvZiBwcm9kdWN0cyAgbW9zdCBpbXBvcnRhbnQgdG8gdGhlIEVk
aXRvcmlhbCBCb2FyZCBwYXJ0aWNpcGFudHMgYW5kIHRoZWlyIHNwb25zb3IuICBUaGlzIGdpdmVz
IGFuIGFydGlmaWNpYWwgdmlldyBvZiB0aGUgbnVtYmVycyBvZiBleGlzdGluZyB2dWxuZXJhYmls
aXRpZXMgYW5kIHRoYXQgaXMgYmVpbmcgcmVjb2duaXplZCBvdXRzaWRlIHRoZSB2dWxuZXJhYmls
aXR5IGNvbW11bml0eS4NCg0KQW5vdGhlciBwcm9ibGVtIGlzIHRoZSBDVkUgZm9ybWF0IGl0c2Vs
Zi4gIFRoZXJlIGhhcyBiZWVuIGFuIGFjdGl2ZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBmb3JtYXQg
bGltaXRhdGlvbnMgYXMgd2VsbC4gVGhlIENWRSBmb3JtYXQgaXMgQ1ZFLVlZWVktTk5OTi4gVGhp
cyBtZWFucyB0aGF0IGN1cnJlbnRseSB3ZSBjYW5ub3QgaGF2ZSBtb3JlIHRoYW4gMTAsMDAwIENW
RXMgcmVwb3J0ZWQgaW4gYSBzaW5nbGUgeWVhci4gIEF0IHRoZSByYXRlcyB3ZSBhcmUgc2VlaW5n
IGludGVybmFsbHksIHdlIGFyZSBhbHJlYWR5IHRoZXJlLg0KDQpUaGVuIHRoZXJlIGFyZSB0aGUg
bGltaXRhdGlvbnMgb2YgQ1ZFIHByb2Nlc3MgaW4gZ2VuZXJhbC4gIFRoZSBmb2N1cyBpcyBFbmds
aXNoIG9ubHkgYWx0aG91Z2ggc29tZSBub24tVVMgdnVsbmVyYWJpbGl0aWVzIGRvIGdldCBhc3Np
Z25lZCBmcm9tIHRpbWUgdG8gdGltZS4gIENWRSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpbnRlcm5h
dGlvbmFsIGNvbW11bml0eSBhbmQgc29mdHdhcmUgd3JpdHRlbiBmb3Igbm9uLUVuZ2xpc2ggZ2Vv
LWNlbnRyaWMgYXJlYXMgYXJlIG5vdCBpbmNsdWRlZC4gIFdoaWxlIHRoaXMgaGFzIG5vdCBiZWVu
IGEgY29uY2VybiBmb3IgVVMtb25seSBzb2Z0d2FyZSB2ZW5kb3JzLCB0aGVyZSBpcyBhIGdyZWF0
IGRlYWwgb2YgcmVnaW9uYWwgc29mdHdhcmUgd3JpdHRlbiBmb3IgbWFqb3IgZW1lcmdpbmcgbWFy
a2V0cy4gIE5vbmUgb2YgdGhvc2UgdnVsbmVyYWJpbGl0aWVzIGFyZSBpZGVudGlmaWVkIGJ5IGEg
Q1ZFLg0KDQpHaXZlbiB0aGVzZSBjb25zdHJhaW50cywgaXQgc2VlbXMgbGlrZSBpdCBpcyB0aW1l
IHRvIGZpZ3VyZSBvdXQgaG93IHRvIGFkZHJlc3MgdGhlIGlzc3VlcyBpbiBhIG1vcmUgb2YgYSBj
cmVhdGl2ZSB3YXkuICBXZSBrbm93IHRoZSBjb25zdHJhaW50cy4gSXMgdGhlcmUgc29tZXRoaW5n
IHdlIGNhbiBkbyB0byBhdWdtZW50IHRoZSBNSVRSRSBzdGFmZiBpbiBjZXJ0YWluIGFyZWFzIHRo
YXQgd291bGQgaGVscD8gIEkgY2FuIHNlZSB0aGUgZm9ybWF0IGlzc3VlIGJlaW5nIGEgcmF0aGVy
IGVhc3kgb25lIHRvIGF0dGFjayBidXQgaXQgaXMgdGhlIGNvdmVyYWdlIGlzc3VlIHRoYXQgaXMg
bW9zdCBjb25jZXJuaW5nLiAgT3Igd2Ugc2hvdWxkIGlnbm9yZSBpdCBhbmQgc2xvd2x5IGxldCB0
aGUgdmFsdWUgb2YgQ1ZFIHRvIHRoZSBjb21tdW5pdHkgYW5kIHZlbmRvcnMgZGVjYXnigKYNCg0K
VGhvdWdodHM/DQoNCktlbnQgTGFuZGZpZWxkDQpEaXJlY3RvciBDb250ZW50IFN0cmF0ZWd5LCBB
cmNoaXRlY3R1cmUgYW5kIFN0YW5kYXJkcw0KDQpNY0FmZWUgfCBBbiBJbnRlbCBDb21wYW55DQo1
MDAwIEhlYWRxdWFydGVycyBEci4NClBsYW5vLCBUZXhhcyA3NTAyNA0KDQpEaXJlY3Q6ICsxLjk3
Mi45NjMuNzA5Ng0KTW9iaWxlOiArMS44MTcuNjM3LjgwMjYNCldlYjogd3d3Lm1jYWZlZS5jb208
aHR0cDovL3d3dy5tY2FmZWUuY29tLz4NCg==
--_000_A27B80707A1E924891446594C00EBA8C52B245E2Sunfishrconca_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow
aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh
bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21z
by1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u
YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl
cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs
eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z
aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGlu
az1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+SGkgYWxsLCBsb25nIHRpbWUgbm8gc2Vl4oCmOy1dIChidHcsIHVu
ZW1wbG95ZWQgYW5kIGludGVyZXN0ZWQpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Qcm9ibGVtICMxIGlz
IHRoZSBkZWZpbml0aW9uIG9mIOKAnHZ1bG5lcmFiaWxpdHnigJ0sIHByb2JsZW0gIzIgaXMgdGhl
IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHdvcmQg4oCcZW51bWVyYXRpb27igJ0sIElNT+KApmJ1dCB0
aGVuIEkgYW0gaW5jcmVkaWJseSBvdXQgb2YgZGF0ZSBzaW5jZSBJIHNlZSBub3cgdGhhdCDigJxF
4oCdIHN0YW5kcyBmb3Ig4oCcRXhwb3N1cmVz4oCdLCBub3Qg4oCcRW51bWVyYXRpb27igJ3igKZz
aWdoLCB0b3VnaCB0byBnZXQgb2xkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Rm9yIGV4YW1wbGUsIEkg
aGF2ZSBzZWVuIHdoYXQgYXBwZWFycyB0byBiZSB0aGUgdXNlIGRpZmZlcmVudCBDVkUgbnVtYmVy
cyBmb3IgdGhlIHNhbWUgdnVsbmVyYWJpbGl0eSBpbiBkaWZmZXJlbnQgcHJvZHVjdHPigKZ0aGlz
IG92ZXItaW5mbGF0ZXMgdGhlIENWRXMgdW5uZWNlc3NhcmlseS4gQSB2dWxuZXJhYmlsaXR5LCB3
aGljaCBmb3IgYWxsIGludGVudHMgYW5kIHB1cnBvc2VzIGlzIHRoZSBzYW1lIGFzIGEgcHJldmlv
dXMgdnVsbmVyYWJpbGl0eSwgZ2V0cyBhIG5ldyBDVkUgYmVjYXVzZSBwcm9kdWN0cyB3YW50IHRv
IHRlc3QgZm9yIHNjZW5hcmlvIEEgYW5kIHNjZW5hcmlvIELigKZ0aGlzIGVxdWFsbHkgaW5mbGF0
ZXMgQ1ZFcyB1bm5lY2Vzc2FyaWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCcSW4gdGhlIGJlZ2lu
bmluZ+KAneKApndlIHRhbGtlZCBhYm91dCBuZWVkaW5nIDEgQ1ZFIG51bWJlciB0byByZXByZXNl
bnQgaW50ZWdlciBvdmVyZmxvdywgb3IgYW5vdGhlciBmb3IgwqBpbnN1ZmZpY2llbnQgcGFyc2lu
Z+KApmNsZWFybHkgdGhhdCBuZXZlciBzdHVjay4gQnV0IGVxdWFsbHksIGl0IHdvdWxkIHNlZW0g
dGhhdCBzb21lIHZlbmRvcnMgd291bGQgbGlrZSB0byBhc3NpZ24gYSBDVkUgcGVyIOKAnHRocmVh
dOKAnSwgd2hpY2ggc2hvdWxkIGFsc28gaGF2ZSBuZXZlciBzdHVjay48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5
N0QnPknigJltIHVuYXdhcmUgb2YgJmd0OyAxMCwwMDAgbmV3IHZ1bG5lcmFiaWxpdGllcyBwZXIg
eWVhciwgYXQgbGVhc3Qgbm90IGluIHdoYXQgSSB3b3VsZCBjb25zaWRlciDigJxuZXcgdnVsbmVy
YWJpbGl0aWVz4oCdLiBUaGF04oCZcyBvbmUgaGVjayBvZiBhIGxvdCBvZiBsaW5lcyBvZiBjb2Rl
LCBidXQgaWYgeW914oCZcmUgY291bnRpbmcgdnVsbmVyYWJpbGl0aWVzIGluIEFuZHJvaWQgQXBw
cywgdGhlbiBJIGNvdWxkIGFsc28gc2VlIHRoYXQgbnVtYmVyIGJlIGluY3JlZGlibHkgbG93LiBT
byBwZXJoYXBzIHRoZSBpc3N1ZXMgYXJlbuKAmXQgd2l0aCB2dWxuZXJhYmlsaXRpZXMsIGJ1dCBp
bnN0ZWFkIHdpdGggZXhwb3N1cmVzPz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgcmVtZW1iZXIgdGhh
dCBhdCBzb21lIHBvaW50IHRoZSBhcHBsaWNhdGlvbiBmb3IgQ1ZFcyB3YXMgbW9yZSBvciBsZXNz
IGd1YXJhbnRlZWQgaWYgZG9uZSBieSBrbm93biBvcmdhbml6YXRpb25zLCBidXQgdGhhdCB3YXMg
b24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgaXNzdWVzIHdvdWxkIGJlIHZhbGlkYXRlZCBhbmQg
dGhlIENBTiBwcm92ZW4gbm90IHJlcXVpcmVkLiBXaXRoIGEgbGFjayBvZiBmdW5kaW5nLCB0aGF0
IG1hcHBpbmcgKG9yIHZldHRpbmcpIHN1cmVseSBpc27igJl0IGdldHRpbmcgdGhlIGF0dGVudGlv
biBpdCBuZWVkcy4gSWYgaXQgZGlkLCBwZXJoYXBzIG1hbnkgQ1ZFcyBjb3VsZCBiZSBzYXZlZCBv
ciByZWNhbGxlZOKApmJ1dCB0aGVuIHRoZSB3YXkgdGhleSBhcmUgdXNlZCB0b2RheSB0aGF0IHdv
dWxkIGVpdGhlciBsZWFkIHRvIGVtYmFycmFzc21lbnQsIG9yIHNpZ25pZmljYW50IGludmVzdG1l
bnQgYnkgdGhlIHBlb3BsZSB1c2luZyB0aGVpciBvd24gQ1ZFcy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn
Pk9uZSB0aGluZyBJIHdvdWxkIGV4cGVjdCB0byBzZWUgYSDigJxDb21tZW50c+KAnSBmZWF0dXJl
IHVzZWQgZm9yIGlzIHRvIHNheSB0aGF0IDIgKG9yIG1vcmUpIGRpZmZlcmVudCBDVkVzIHJlcHJl
c2VudCDigJxtb3JlIG9yIGxlc3PigJ0gdGhlIHNhbWUgdGhpbmfigKZhbmQgdGhlbiBkb2N1bWVu
dHMgdGhlIHdheSB0byBhZGRyZXNzIHRoZSBpc3N1ZSBhY3Jvc3MgZGlmZmVyZW50IHBsYXRmb3Jt
cy9wcm9kdWN0cy92ZW5kb3Jz4oCmPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5J4oCZZCBzYXkgbW9yZSwg
YnV0IEkgcmVhbGx5IGdvdHRhIHJlYWQgdXAgb24ganVzdCB3aGF0IHRoZSBoZWNrIOKAnGV4cG9z
dXJlc+KAnSBhcmUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5DaGVlcnMsPG86cD48L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJ1c3Mg4oCTIGZv
cm1lcmx5IE5UQnVndHJhcSBFZGl0b3LigKZjdXJyZW50bHkgcmFpc2luZyBjaGlja2VucyBhbmQg
YnVpbGRpbmcgYSBjaGVhcGVyIGhvdXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg
MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl
cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IG93bmVyLWN2ZS1lZGl0b3JpYWwtYm9hcmQt
bGlzdEBsaXN0cy5taXRyZS5vcmcgW21haWx0bzpvd25lci1jdmUtZWRpdG9yaWFsLWJvYXJkLWxp
c3RAbGlzdHMubWl0cmUub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPldpbGxpYW1zLCBKYW1lcyBL
PGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDA3LCAyMDEyIDM6NDUgUE08YnI+PGI+
VG86PC9iPiBjdmUtZWRpdG9yaWFsLWJvYXJkLWxpc3RAbGlzdHMubWl0cmUub3JnPGJyPjxiPlN1
YmplY3Q6PC9iPiBSRTogQ291bnRpbmcgb24gQ1ZFczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp
dj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWdyZWUgd2l0aCBldmVyeXRoaW5nIEtl
bnQgc2FpZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk9uZSBpbXBvcnRhbnQgY2hhbmdlIEkgd291bGQg
bGlrZSB0byBzZWUgaXMgdGhlIGFkZGl0aW9uIG9mIGEg4oCcQ29tbWVudHPigJ0gZmVhdHVyZSBv
biBlYWNoIENWRSBwYWdlIGF0IGN2ZS5taXRyZS5vcmcuJm5ic3A7IFRoZSBDb21tZW50cyBmZWF0
dXJlIGNvdWxkIGJlIHVzZWQgYnkgRWRpdG9yaWFsIEJvYXJkIG1lbWJlcnMgKGFuZCBvdGhlciB2
ZXR0ZWQgaW5kaXZpZHVhbHM/KSB0byBhZGQgaW5mbyBzdWNoIGFzIGNvcnJlY3Rpb25zLCBhZGRp
dGlvbmFsIHJlZmVyZW5jZXMsIHZlbmRvciByZXNwb25zZXMsIGV0Yy48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn
PlRoYW5rcyBhbmQgcmVnYXJkcyw8YnI+S2VuIFdpbGxpYW1zLCBEaXJlY3RvcjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDY0QUYnPkM8
L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IlZl
cmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMTRBQTEzJz5BIFRlY2hub2xvZ2llczwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNh
bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Qcm9k
dWN0IFZ1bG5lcmFiaWxpdHkgUmVzcG9uc2UgVGVhbTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3
RCc+PGJyPjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNjRBRic+Qzwvc3Bhbj48L2I+PGI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2Vy
aWYiO2NvbG9yOiMxNEFBMTMnPkEgVGVjaG5vbG9naWVzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6
IzFGNDk3RCc+IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkJ1c2luZXNzIFVuaXQgT3BlcmF0
aW9uczwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJWZXJk
YW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzp3aWxq
YTIyQGNhLmNvbSI+d2lsamEyMkBjYS5jb208L2E+IC0gODE2LTkxNC00MjI1PC9zcGFuPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFz
cz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0i
bWFpbHRvOm93bmVyLWN2ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmciPm93
bmVyLWN2ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmc8L2E+IDxhIGhyZWY9
Im1haWx0bzpbbWFpbHRvOm93bmVyLWN2ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRy
ZS5vcmddIj5bbWFpbHRvOm93bmVyLWN2ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRy
ZS5vcmddPC9hPiA8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzpLZW50X0xhbmRm
aWVsZEBNY0FmZWUuY29tIj5LZW50X0xhbmRmaWVsZEBNY0FmZWUuY29tPC9hPjxicj48Yj5TZW50
OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAwNywgMjAxMiAxOjUzIFBNPGJyPjxiPlRvOjwvYj4gPGEg
aHJlZj0ibWFpbHRvOmN2ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmciPmN2
ZS1lZGl0b3JpYWwtYm9hcmQtbGlzdEBsaXN0cy5taXRyZS5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6
PC9iPiBDb3VudGluZyBvbiBDVkVzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjxw
IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5BbGwsPG86cD48L286cD48
L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv
cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+V2UgaGF2ZSBwcm9ibGVtcyB3aXRo
IENWRSByZXBvcnRpbmcgdGhhdCBhcmUga25vd24gaXNzdWVzIGJ1dCB3aGljaCBhcmUgYmVjb21p
bmcgYXBwYXJlbnQgdG8gbWFueSBtb3JlIGFuZCBjb3VsZCBlYXNpbHkgdW5kZXJtaW5lIHRoZSB1
c2VmdWxuZXNzIG9mIENWRSBpZGVudGlmaWNhdGlvbiBpZiBsZWZ0IHVuY2hlY2tlZC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5XZSBkaXNjdXNzZWQgdGhp
cyBhdCB0aGUgSVRTQUMgY29uZmVyZW5jZSBpbiB0aGUgRnV0dXJlIG9mIFZ1bG5lcmFiaWxpdHkg
UmVwb3J0aW5nIFdvcmtzaG9wIGFuZCBhdCB0aGUgZm9sbG93LW9uIFZ1bG5lcmFiaWxpdHkgUmVw
b3J0aW5nIGRheSBhdCB0aGUgU29mdHdhcmUgQXNzdXJhbmNlIGV2ZW50IGEgbW9udGggbGF0ZXIu
IChUaGVyZSB3ZXJlIGFjdGlvbiBpdGVtcyBvdXQgb2YgdGhlIGxhdHRlciB0aGF0IEkgYW0gbm90
IGF3YXJlIGhhdmUgYmVlbiBjb21wbGV0ZWTigKYpPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2
PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdjb2xvcjpibGFjayc+SSBoYXZlIGp1c3QgaGFkIGEgdmVyeSBjb25jZXJuaW5nIGRp
c2N1c3Npb24gYWJvdXQgdGhlIHVzZWZ1bG5lc3Mgb2YgQ1ZFcyBhcyBhIG1lYW5zIHRvIG1lYXN1
cmUgdnVsbmVyYWJpbGl0aWVzIHRvZGF5IGFuZCB0aGUgZGVjYXkgb2YgaXRzIHZhbHVlIGlmIHRo
ZSB0cmVuZCBjb250aW51ZXMuICZuYnNwOyBUaGUgZGlzY3Vzc2lvbiBjZW50ZXJlZCBhcm91bmQg
dGhlIGFjY3VyYWN5IG9mIHRoZSBudW1iZXJzIG9mIENWRXMgaWRlbnRpZmllZCBjb21wYXJlZCB0
byB0aG9zZSByZXBvcnRlZCBpbiB0aGUgY29tbXVuaXR5IGFzIGEgd2hvbGUuICZuYnNwO0lmIHdl
IGxvb2tlZCBhdCBqdXN0IHRoZSBDVkUgbnVtYmVycywgJm5ic3A7aXQgYXBwZWFycyB0aGF0IHRo
ZSBudW1iZXJzIG9mIHZ1bG5lcmFiaWxpdGllcyBoYXZlIGJlZW4gZHJvcHBpbmcgc2luY2UgYSBo
aWdoIGluIDIwMDguICZuYnNwOyBUaGlzIGlzIGEgcmF0aGVyIGltcG9ydGFudCBlcnJvci4gQXMg
d2UgYWxsIGtub3csIHRoaXMgaXMgbm90IGFjY3VyYXRlLiBWdWxuZXJhYmlsaXRpZXMgaGF2ZSBu
b3QgYmVlbiBkcm9wcGluZywgdGhleSBhcmUgZ3Jvd2luZywgbm90IGRyb3BwaW5nIGJ5IDMwJS4g
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwv
ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Rm9y
IHRoZSB2ZW5kb3IgY29tbXVuaXR5LCB0aGVzZSB0cmVuZHMgaGF2ZSByYXRoZXIgY29uY2Vybmlu
ZyBwb3RlbnRpYWwgaW1wYWN0cyBvbiB1cy4gJm5ic3A7Rmlyc3QsIG91ciB2dWxuZXJhYmlsaXR5
IHJlc2VhcmNoIGRhdGFiYXNlcyB1c2UgQ1ZFIGFzIGEgcHJpbWFyeSByZWZlcmVuY2UuICZuYnNw
O1RoZSBDVkUgSWQgaGFzIGJlZW4gYXV0aG9yaXRhdGl2ZSBpbiB0aGUgcGFzdC4gJm5ic3A7SXQg
aXMgdXNlZCBpbnRlcm5hbGx5IGFzIGEgbWVhbnMgdG8gY29tbXVuaWNhdGUgdnVsbmVyYWJpbGl0
eSByZWNvcmQgaW5mb3JtYXRpb24gYmV0d2VlbiBmaWVsZGVkIHByb2R1Y3RzIGFuZCBiZXR3ZWVu
IHJlc2VhcmNoIGFuYWx5c2lzIHRlYW1zLiAmbmJzcDtBcyB0aGUgbnVtYmVycyBkZWNsaW5lLCBp
dCBtZWFucyB3ZSBhcmUgZm9yY2VkIHRvIGxvb2sgZWxzZXdoZXJlIHRvIHByb3ZpZGUgdGhlIGlk
ZW50aWZpY2F0aW9uIGFuZCBjb21tdW5pY2F0aW9uIHRoYXQgQ1ZFIHByb3ZpZGVkIGluIHRoZSBw
YXN0LiBNb3JlIHByb3ByaWV0YXJ5IGlkcyBhcmUgYmVjb21pbmcgbW9yZSB0aGUgbm9ybS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UaGUgbW9yZSBzZXJp
b3VzIGNvbmNlcm4gaXMgd2hhdCBpdCBpcyBzaG93aW5nIHRvIGV4ZWN1dGl2ZXMgb2YgY29tcGFu
aWVzLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PHNwYW4gc3R5bGU9J2NvbG9yOmJs
YWNrJz4mcXVvdDtJZiB0aGUgdnVsbmVyYWJpbGl0aWVzIGhhdmUgZHJvcHBlZCAmbmJzcDszMCUg
c2luY2UgMjAwOCwgd2h5IGRvIEkgbmVlZCB0byBiZSBmdW5kaW5nIHRoZSBzZWN1cml0eSBzdGFm
ZiBhbmQgZWZmb3J0cyBhdCB0aGUgcmF0ZSBJIGFtPyAmbmJzcDtJIHNlZSB0aGF0IE1JVFJFIGlz
IHJlcG9ydGluZyBhbiBvdmVyYWxsIGRyb3AgZWFjaCB5ZWFyIHNpbmNlIDIwMDggYnV0IHlldCB5
b3UgZm9sa3Mga2VlcCBjb21pbmcgdG8gbWUgc2F5aW5nIHRoYXQgdGhlIHRocmVhdHMgYXJlIG11
Y2ggd29yc2UgYW5kIHdlIG1heSBiZSBpbiB0aGUgc2FtZSByZWxhdGl2ZSBzaXR1YXRpb24gd2Ug
d2VyZSB3aGVuIG1hbHdhcmUgc3Bpa2VkIGEgY291cGxlIHllYXJzIHBhc3TigKYmcXVvdDs8L3Nw
YW4+PC9pPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwv
ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Rm9yIHRob3NlIHRoYXQgYWN0aXZlbHkgd29yayBpbiB0
aGlzIGVudmlyb25tZW50LCB3ZSBrbm93IHZ1bG5lcmFiaWxpdGllcyBoYXZlIG5vdCBkcm9wcGVk
IDMwJSBzaW5jZSAyMDA4LiBRdWl0ZSB0aGUgY29udHJhcnksIG91ciBpbnRlcm5hbCBudW1iZXJz
IGluZGljYXRlIGFuIGluY3JlYXNpbmcgdHJlbmQgc2ltaWxhciB0byBhIDMwJSByaXNlLiAmbmJz
cDtTeW1hbnRlYyBoYXMgYWxzbyByZXBvcnRlZCBhIHNpbWlsYXIgdHJlbmQuPG86cD48L286cD48
L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv
cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2
PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5P
bmUgb2YgdGhlIG1ham9yIHByb2JsZW1zIGlzIHRoYXQgTUlUUkUgZnVuZGluZyBpcyBub3Qgd2hh
dCBpdCBzaG91bGQgYmUuIE9uIG11bHRpcGxlIG9jY2FzaW9ucyB3ZSBoYXZlIGJlZW4gYXNrZWQg
dG8gdGFyZ2V0IHRoZSBjbGFzc2VzIG9mIHByb2R1Y3RzIHdoZXJlIHZ1bG5lcmFiaWxpdGllcyBh
cmUgY29uc2lkZXJlZCB0aGUgbW9zdCBjcml0aWNhbCBhbmQgd2hpY2ggc291cmNlcyBzaG91bGQg
YmUgbW9uaXRvcmVkLiBUaGUgdmlldyBvZiB3aGF0IHRvIHRhcmdldCBhbmQgbW9uaXRvciBnZXRz
IHNtYWxsZXIgYW5kIHNtYWxsZXIgYXMgZnVuZGluZyBpcyAmbmJzcDtoZWxkIGxldmVsIG9yIHJl
ZHVjZWQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwv
ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QXQg
b25lIHBvaW50IHRoZSBpbnRlbnQgb2YgdGhlIGVmZm9ydCB3YXMgdG8gY292ZXIgYWxsIHB1Ymxp
c2hlZCB2dWxuZXJhYmlsaXRpZXMgdGhhdCBjb3VsZCBiZSBjb3Jyb2JvcmF0ZWQgaW4gc29tZSBm
YXNoaW9uLiAmbmJzcDtPdmVyIHRoZSB5ZWFycyB0aGUgcmVhbGl0eSBoYXMgc2V0IGluIHRoYXQg
dGhpcyBpcyBhIHZlcnkgcmVzb3VyY2UgaW50ZW5zaXZlIG9wZXJhdGlvbi4gJm5ic3A7QXMgc3Vj
aCB0aGUgZm9jdXMgb2YgdGhlIGVmZm9ydCBoYXMgcmVkdWNlZCB3aGF0IGlzIHJlcG9ydGVkIG9u
IHRvIGFzc3VyZSBDVkVzIGNhbiBiZSBhc3NpZ25lZCBmb3IgdGhlIHR5cGVzIG9mIHByb2R1Y3Rz
ICZuYnNwO21vc3QgaW1wb3J0YW50IHRvIHRoZSBFZGl0b3JpYWwgQm9hcmQgcGFydGljaXBhbnRz
IGFuZCB0aGVpciBzcG9uc29yLiAmbmJzcDtUaGlzIGdpdmVzIGFuIGFydGlmaWNpYWwgdmlldyBv
ZiB0aGUgbnVtYmVycyBvZiBleGlzdGluZyB2dWxuZXJhYmlsaXRpZXMgYW5kIHRoYXQgaXMgYmVp
bmcgcmVjb2duaXplZCBvdXRzaWRlIHRoZSB2dWxuZXJhYmlsaXR5IGNvbW11bml0eS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5Bbm90aGVyIHByb2JsZW0g
aXMgdGhlIENWRSBmb3JtYXQgaXRzZWxmLiAmbmJzcDtUaGVyZSBoYXMgYmVlbiBhbiBhY3RpdmUg
ZGlzY3Vzc2lvbiBhYm91dCB0aGUgZm9ybWF0IGxpbWl0YXRpb25zIGFzIHdlbGwuIFRoZSBDVkUg
Zm9ybWF0IGlzIENWRS1ZWVlZLU5OTk4uIFRoaXMgbWVhbnMgdGhhdCBjdXJyZW50bHkgd2UgY2Fu
bm90IGhhdmUgbW9yZSB0aGFuIDEwLDAwMCBDVkVzIHJlcG9ydGVkIGluIGEgc2luZ2xlIHllYXIu
ICZuYnNwO0F0IHRoZSByYXRlcyB3ZSBhcmUgc2VlaW5nIGludGVybmFsbHksIHdlIGFyZSBhbHJl
YWR5IHRoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn
PlRoZW4gdGhlcmUgYXJlIHRoZSBsaW1pdGF0aW9ucyBvZiBDVkUgcHJvY2VzcyBpbiBnZW5lcmFs
LiAmbmJzcDtUaGUgZm9jdXMgaXMgRW5nbGlzaCBvbmx5IGFsdGhvdWdoIHNvbWUgbm9uLVVTIHZ1
bG5lcmFiaWxpdGllcyBkbyBnZXQgYXNzaWduZWQgZnJvbSB0aW1lIHRvIHRpbWUuICZuYnNwO0NW
RSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpbnRlcm5hdGlvbmFsIGNvbW11bml0eSBhbmQgc29mdHdh
cmUgd3JpdHRlbiBmb3Igbm9uLUVuZ2xpc2ggZ2VvLWNlbnRyaWMgYXJlYXMgYXJlIG5vdCBpbmNs
dWRlZC4gJm5ic3A7V2hpbGUgdGhpcyBoYXMgbm90IGJlZW4gYSBjb25jZXJuIGZvciBVUy1vbmx5
IHNvZnR3YXJlIHZlbmRvcnMsIHRoZXJlIGlzIGEgZ3JlYXQgZGVhbCBvZiByZWdpb25hbCBzb2Z0
d2FyZSB3cml0dGVuIGZvciBtYWpvciBlbWVyZ2luZyBtYXJrZXRzLiAmbmJzcDtOb25lIG9mIHRo
b3NlIHZ1bG5lcmFiaWxpdGllcyBhcmUgaWRlbnRpZmllZCBieSBhIENWRS4gJm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv
cjpibGFjayc+R2l2ZW4gdGhlc2UgY29uc3RyYWludHMsIGl0IHNlZW1zIGxpa2UgaXQgaXMgdGlt
ZSB0byBmaWd1cmUgb3V0IGhvdyB0byBhZGRyZXNzIHRoZSBpc3N1ZXMgaW4gYSBtb3JlIG9mIGEg
Y3JlYXRpdmUgd2F5LiAmbmJzcDtXZSBrbm93IHRoZSBjb25zdHJhaW50cy4gSXMgdGhlcmUgc29t
ZXRoaW5nIHdlIGNhbiBkbyB0byBhdWdtZW50IHRoZSBNSVRSRSBzdGFmZiBpbiBjZXJ0YWluIGFy
ZWFzIHRoYXQgd291bGQgaGVscD8gJm5ic3A7SSBjYW4gc2VlIHRoZSBmb3JtYXQgaXNzdWUgYmVp
bmcgYSByYXRoZXIgZWFzeSBvbmUgdG8gYXR0YWNrIGJ1dCBpdCBpcyB0aGUgY292ZXJhZ2UgaXNz
dWUgdGhhdCBpcyBtb3N0IGNvbmNlcm5pbmcuICZuYnNwO09yIHdlIHNob3VsZCBpZ25vcmUgaXQg
YW5kIHNsb3dseSBsZXQgdGhlIHZhbHVlIG9mIENWRSB0byB0aGUgY29tbXVuaXR5IGFuZCB2ZW5k
b3JzIGRlY2F54oCmPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj
ayc+VGhvdWdodHM/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHN0cm9uZz48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y
OiM2MDZBNzEnPktlbnQgTGFuZGZpZWxkPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzYwNkE3
MSc+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+RGlyZWN0b3IgQ29udGVudCBTdHJh
dGVneSwgQXJjaGl0ZWN0dXJlIGFuZCBTdGFuZGFyZHM8L3NwYW4+PGJyPjxicj48c3Ryb25nPjxz
cGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TWNBZmVlIHwgQW4g
SW50ZWwgQ29tcGFueTwvc3Bhbj48L3N0cm9uZz48YnI+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUt
c3Bhbj41MDAwIEhlYWRxdWFydGVycyBEci48L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWFwcGxlLXN0
eWxlLXNwYW4+UGxhbm8sIFRleGFzIDc1MDI0PC9zcGFuPjxicj48YnI+PHNwYW4gY2xhc3M9YXBw
bGUtc3R5bGUtc3Bhbj5EaXJlY3Q6ICsxLjk3Mi45NjMuNzA5NiZuYnNwOzwvc3Bhbj48YnI+PHNw
YW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj5Nb2JpbGU6ICsxLjgxNy42MzcuODAyNjwvc3Bhbj48
YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiIn
PldlYjombmJzcDs8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48
YSBocmVmPSJodHRwOi8vd3d3Lm1jYWZlZS5jb20vIj53d3cubWNhZmVlLmNvbTwvYT48L3NwYW4+
PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwv
ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+
--_000_A27B80707A1E924891446594C00EBA8C52B245E2Sunfishrconca_--
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 03:32:16 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q288WE2Z010810
for <coley@RCF-SMTP.MITRE.ORG>; Thu, 8 Mar 2012 03:32:14 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 92A8721B11D7;
Thu, 8 Mar 2012 03:32:13 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 7690C21B11BD;
Thu, 8 Mar 2012 03:32:13 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 03:32:13 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4525882 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 03:31:24 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 03:31:24 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13240446; Thu, 08 Mar 2012 03:31:04 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 8B5AB2B78156 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
03:31:04 -0500 (EST)
Received: from forced.attrition.org (forced.attrition.org [72.215.220.112]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 409502B78130 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
03:31:04 -0500 (EST)
Received: by forced.attrition.org (Postfix, from userid 1000) id
21945D90E1; Thu, 8 Mar 2012 02:31:03 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by forced.attrition.org
(Postfix) with ESMTP id 201ACCED2E; Thu, 8 Mar 2012 02:31:03 -0600
(CST)
Date: Thu, 8 Mar 2012 02:31:03 -0600
From: security curmudgeon <jericho@attrition.org>
To: Russ Cooper <Russ.Cooper@rc.on.ca>
CC: "cve-editorial-board-list@lists.mitre.org"
<cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
In-Reply-To: <A27B80707A1E924891446594C00EBA8C52B245E2@Sunfish.rc.on.ca>
Message-ID: <alpine.LNX.2.00.1203080226050.27175@forced.attrition.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<ED311CBEE6993C428563DEDF6D083BC81180FBF7@usilms113b.ca.com>
<A27B80707A1E924891446594C00EBA8C52B245E2@Sunfish.rc.on.ca>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
X-Attrition: Attrition is only good when forced. http://attrition.org
X-OSVDB: Everything is vulnerable. http://osvdb.org/
X-Message-Flag: WARNING: Over 100 published security vulnerabilities in
Microsoft Outlook!
X-Copyright: This e-mail copyright 2011 by jericho@attrition.org where
applicable
X-Encryption: rot26
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.82119
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0,
BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0,
BODY_SIZE_900_999 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0,
__CS_PROD_FROM 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0,
__TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0,
__URI_NS , __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 966
Status:
X-Status:
X-Keywords:
: ?In the beginning??we talked about needing 1 CVE number to represent
: integer overflow, or another for insufficient parsing?clearly that never
: stuck. But equally, it would seem that some vendors would like to assign
: a CVE per ?threat?, which should also have never stuck.
There is CWE for that: http://cwe.mitre.org/
: I?m unaware of > 10,000 new vulnerabilities per year, at least not in
: what I would consider ?new vulnerabilities?. That?s one heck of a lot of
: lines of code, but if you?re counting vulnerabilities in Android Apps,
: then I could also see that number be incredibly low. So perhaps the
: issues aren?t with vulnerabilities, but instead with exposures??
OSVDB has 10,895 entries for 2006. Note, that OSVDB abstracts very
differently than CVE or any other VDB currently, so I would guess we're
the only ones who have hit that mark.
There is additional discussion on CVE handling the #### issue on the
CERT-run vrdx mail list.
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 03:32:19 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q288WIcw010840;
Thu, 8 Mar 2012 03:32:18 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 92A8721B11D7;
Thu, 8 Mar 2012 03:32:13 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 7690C21B11BD;
Thu, 8 Mar 2012 03:32:13 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 03:32:13 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4525882 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 03:31:24 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 03:31:24 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13240446; Thu, 08 Mar 2012 03:31:04 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 8B5AB2B78156 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
03:31:04 -0500 (EST)
Received: from forced.attrition.org (forced.attrition.org [72.215.220.112]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 409502B78130 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
03:31:04 -0500 (EST)
Received: by forced.attrition.org (Postfix, from userid 1000) id
21945D90E1; Thu, 8 Mar 2012 02:31:03 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by forced.attrition.org
(Postfix) with ESMTP id 201ACCED2E; Thu, 8 Mar 2012 02:31:03 -0600
(CST)
Date: Thu, 8 Mar 2012 02:31:03 -0600
From: security curmudgeon <jericho@attrition.org>
To: Russ Cooper <Russ.Cooper@rc.on.ca>
CC: "cve-editorial-board-list@lists.mitre.org"
<cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
In-Reply-To: <A27B80707A1E924891446594C00EBA8C52B245E2@Sunfish.rc.on.ca>
Message-ID: <alpine.LNX.2.00.1203080226050.27175@forced.attrition.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<ED311CBEE6993C428563DEDF6D083BC81180FBF7@usilms113b.ca.com>
<A27B80707A1E924891446594C00EBA8C52B245E2@Sunfish.rc.on.ca>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
X-Attrition: Attrition is only good when forced. http://attrition.org
X-OSVDB: Everything is vulnerable. http://osvdb.org/
X-Message-Flag: WARNING: Over 100 published security vulnerabilities in
Microsoft Outlook!
X-Copyright: This e-mail copyright 2011 by jericho@attrition.org where
applicable
X-Encryption: rot26
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.82119
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0,
BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0,
BODY_SIZE_900_999 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0,
__CS_PROD_FROM 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0,
__TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0,
__URI_NS , __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 966
Status:
X-Status:
X-Keywords:
: ?In the beginning??we talked about needing 1 CVE number to represent
: integer overflow, or another for insufficient parsing?clearly that never
: stuck. But equally, it would seem that some vendors would like to assign
: a CVE per ?threat?, which should also have never stuck.
There is CWE for that: http://cwe.mitre.org/
: I?m unaware of > 10,000 new vulnerabilities per year, at least not in
: what I would consider ?new vulnerabilities?. That?s one heck of a lot of
: lines of code, but if you?re counting vulnerabilities in Android Apps,
: then I could also see that number be incredibly low. So perhaps the
: issues aren?t with vulnerabilities, but instead with exposures??
OSVDB has 10,895 entries for 2006. Note, that OSVDB abstracts very
differently than CVE or any other VDB currently, so I would guess we're
the only ones who have hit that mark.
There is additional discussion on CVE handling the #### issue on the
CERT-run vrdx mail list.
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 03:58:31 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q288wSDa017205
for <coley@RCF-SMTP.MITRE.ORG>; Thu, 8 Mar 2012 03:58:28 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 3896B21B1715;
Thu, 8 Mar 2012 03:58:23 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1BDA121B11BD;
Thu, 8 Mar 2012 03:58:23 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 03:58:22 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4528153 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 03:57:40 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 03:57:40 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13241211; Thu, 08 Mar 2012 03:57:25 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 2464B2B78177 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
03:57:25 -0500 (EST)
Received: from forced.attrition.org (forced.attrition.org [72.215.220.112]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 747AE21B11CE for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
03:57:23 -0500 (EST)
Received: by forced.attrition.org (Postfix, from userid 1000) id
F08D9D90F3; Thu, 8 Mar 2012 02:57:22 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by forced.attrition.org
(Postfix) with ESMTP id EF0EFD9012; Thu, 8 Mar 2012 02:57:22 -0600
(CST)
Date: Thu, 8 Mar 2012 02:57:22 -0600
From: security curmudgeon <jericho@attrition.org>
To: <Kent_Landfield@McAfee.com>
CC: <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
In-Reply-To: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
Message-ID: <alpine.LNX.2.00.1203080235500.27175@forced.attrition.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
X-Attrition: Attrition is only good when forced. http://attrition.org
X-OSVDB: Everything is vulnerable. http://osvdb.org/
X-Message-Flag: WARNING: Over 100 published security vulnerabilities in
Microsoft Outlook!
X-Copyright: This e-mail copyright 2011 by jericho@attrition.org where
applicable
X-Encryption: rot26
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.84815
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0,
__CS_PROD_FROM 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__INT_PROD_LOC 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__SANE_MSGID 0, __STOCK_PHRASE_7 0, __TO_MALFORMED_2 0,
__TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS ,
__USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 7512
Status:
X-Status:
X-Keywords:
: I have just had a very concerning discussion about the usefulness of
: CVEs as a means to measure vulnerabilities today and the decay of its
: value if the trend continues. The discussion centered around the
: accuracy of the numbers of CVEs identified compared to those reported in
: the community as a whole. If we looked at just the CVE numbers, it
: appears that the numbers of vulnerabilities have been dropping since a
: high in 2008. This is a rather important error. As we all know, this is
: not accurate. Vulnerabilities have not been dropping, they are growing,
: not dropping by 30%.
I can't find it right off, but this came up several years back when
several people noticed the drop in vulnerability totals around 2008. After
additional examination of CVE, OSVDB, Secunia, and I believe BID, all four
databases showed roughly the same drop. That in turn lead to speculation
about *why* it was happening. I don't recall seeing anyone showing a 5
year trending of vulnerability counts, as seen through multiple VDBs, but
I would honestly request to see some rough numbers before pursuing this
line of discussion further.
: information between fielded products and between research analysis
: teams. As the numbers decline, it means we are forced to look elsewhere
: to provide the identification and communication that CVE provided in the
: past. More proprietary ids are becoming more the norm.
Is it cheaper for your team to manufacturer proprietary IDs instead of
looking to Secunia, ISS, BID, and OSVDB for external references? If the
answer is 'yes', why rely on CVE at all any more? If the answer is 'no',
then perhaps these other VDBs are doing some of the work for you, where
CVE is currently not.
: "If the vulnerabilities have dropped 30% since 2008, why do I need to be
: funding the security staff and efforts at the rate I am? I see that
: MITRE is reporting an overall drop each year since 2008 but yet you
: folks keep coming to me saying that the threats are much worse and we
: may be in the same relative situation we were when malware spiked a
: couple years past?"
That quote alone is a non sequitur really. I know that the conversations
are more detailed with these executives, but even as a summary, it is too
simplified.
Just because the number of unique vulnerabilities tracked by a VDB drops,
does not mean the number of attackers drop. Further, it does not mean risk
has dropped. Even further, more companies are using custom web
applications, and no VDB tracks site-specific vulnerabilities (one current
OSF project wants to, but we simply don't have funding or volunteers to
make it happen). These are just a few issues of why an overall
vulnerability count may drop, but their need to hire you and any other
security company is stronger than ever. I certainly hope you can steer
them past this limited view re: CVE.
: For those that actively work in this environment, we know
: vulnerabilities have not dropped 30% since 2008. Quite the contrary, our
: internal numbers indicate an increasing trend similar to a 30% rise.
: Symantec has also reported a similar trend.
Could you provide links to the Symantec report? Again, I am just curious
about the ~ 2008 thing where most VDBs reported a drop.
: Another problem is the CVE format itself. There has been an active
: discussion about the format limitations as well. The CVE format is
: CVE-YYYY-NNNN. This means that currently we cannot have more than 10,000
: CVEs reported in a single year. At the rates we are seeing internally,
: we are already there.
As I said in a previous reply, OSVDB hit the 10k mark in 2006 due to our
abstraction method.
: Then there are the limitations of CVE process in general. The focus is
: English only although some non-US vulnerabilities do get assigned from
: time to time. CVE does not support the international community and
: software written for non-English geo-centric areas are not included.
: While this has not been a concern for US-only software vendors, there is
: a great deal of regional software written for major emerging markets.
: None of those vulnerabilities are identified by a CVE.
This is very difficult to manage. Even if CVE could keep up with all
English-based disclosures from all sources (e.g., think of their team
being triple in size at the very least), trying to keep up with foreign on
top of it is another huge jump in resources. Carsten Eiram over at Secunia
could probably give some insight on this better than anyone. I have
noticed over the years that he appears to have several analysts that speak
other languages, as they frequently pull up vulnerabilities with no
English disclosure.
: Given these constraints, it seems like it is time to figure out how to
: address the issues in a more of a creative way. We know the
: constraints. Is there something we can do to augment the MITRE staff in
: certain areas that would help? I can see the format issue being a
: rather easy one to attack but it is the coverage issue that is most
: concerning. Or we should ignore it and slowly let the value of CVE to
: the community and vendors decay?
If MITRE can't get funding to keep up (and catch up), looking to augment
the effort from external staff would certainly be interesting. However, I
would like to make two points on that.
1. Having non-MITRE resources work on CVE would require an entire overhaul
of the process and policies around the project. Further, MITRE would have
to divert some resources away from the already struggling CVE to
implement some form of training program. I know this because Steve
Christey and I 'traded roles' for *one* entry many years back. He gave me
a link to a vulnerability and said "write a CVE". I gave him a link to a
vulnerability and said "mangle the OSVDB entry to 100%". We both learned a
lot from that process, and we both walked away with newfound respect for
each other's process. Trying to train up a dozen people to meet their
standards would not be easy.
2. OSVDB has been around for some time now, and I have been involved with
it since 2004. We have been an 'open' database, where anyone could sign up
for an account and contribute to our entries. We provided an extensive
walk-through, near 24 hour support for a while should anyone have
questions, reminder help screens for entries, templates to help ensure the
text was readable, and more. Over the last 8 or so years, less than 1% of
our data has come from volunteers. Off hand, I would guess that the bottom
1,000 volunteers who signed up have contributed less than the #8 ranking
contributor (http://osvdb.org/contributors). In short, the idea of an open
community-driven database simply did not work. We tried a wide variety of
campaigns to encourage people to help ranging from a reward system to
internships to resume experience working for a 501(c)(3). In all of that
time, less than 5 have stuck with the project and become core
contributors. While we don't quite have the exposure of CVE, we are
certainly not 'unknown'. We've had the framework to do this for a long
time, and I have to think that if the community wanted it, they would have
supported us. I know dozens of researchers and penetration testers that
"don't have the time", but are overjoyed when I can create and mangle an
entry for a vulnerability that no VDB has, so they can provide an external
reference in their reports.
Brian
OSF / OSVDB
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 03:58:31 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q288wSGE017204;
Thu, 8 Mar 2012 03:58:28 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 3896B21B1715;
Thu, 8 Mar 2012 03:58:23 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1BDA121B11BD;
Thu, 8 Mar 2012 03:58:23 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 03:58:22 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4528153 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 03:57:40 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 03:57:40 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13241211; Thu, 08 Mar 2012 03:57:25 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 2464B2B78177 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
03:57:25 -0500 (EST)
Received: from forced.attrition.org (forced.attrition.org [72.215.220.112]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 747AE21B11CE for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
03:57:23 -0500 (EST)
Received: by forced.attrition.org (Postfix, from userid 1000) id
F08D9D90F3; Thu, 8 Mar 2012 02:57:22 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by forced.attrition.org
(Postfix) with ESMTP id EF0EFD9012; Thu, 8 Mar 2012 02:57:22 -0600
(CST)
Date: Thu, 8 Mar 2012 02:57:22 -0600
From: security curmudgeon <jericho@attrition.org>
To: <Kent_Landfield@McAfee.com>
CC: <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
In-Reply-To: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
Message-ID: <alpine.LNX.2.00.1203080235500.27175@forced.attrition.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
X-Attrition: Attrition is only good when forced. http://attrition.org
X-OSVDB: Everything is vulnerable. http://osvdb.org/
X-Message-Flag: WARNING: Over 100 published security vulnerabilities in
Microsoft Outlook!
X-Copyright: This e-mail copyright 2011 by jericho@attrition.org where
applicable
X-Encryption: rot26
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.84815
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0,
__CS_PROD_FROM 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__INT_PROD_LOC 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__SANE_MSGID 0, __STOCK_PHRASE_7 0, __TO_MALFORMED_2 0,
__TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS ,
__USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 7512
Status:
X-Status:
X-Keywords:
: I have just had a very concerning discussion about the usefulness of
: CVEs as a means to measure vulnerabilities today and the decay of its
: value if the trend continues. The discussion centered around the
: accuracy of the numbers of CVEs identified compared to those reported in
: the community as a whole. If we looked at just the CVE numbers, it
: appears that the numbers of vulnerabilities have been dropping since a
: high in 2008. This is a rather important error. As we all know, this is
: not accurate. Vulnerabilities have not been dropping, they are growing,
: not dropping by 30%.
I can't find it right off, but this came up several years back when
several people noticed the drop in vulnerability totals around 2008. After
additional examination of CVE, OSVDB, Secunia, and I believe BID, all four
databases showed roughly the same drop. That in turn lead to speculation
about *why* it was happening. I don't recall seeing anyone showing a 5
year trending of vulnerability counts, as seen through multiple VDBs, but
I would honestly request to see some rough numbers before pursuing this
line of discussion further.
: information between fielded products and between research analysis
: teams. As the numbers decline, it means we are forced to look elsewhere
: to provide the identification and communication that CVE provided in the
: past. More proprietary ids are becoming more the norm.
Is it cheaper for your team to manufacturer proprietary IDs instead of
looking to Secunia, ISS, BID, and OSVDB for external references? If the
answer is 'yes', why rely on CVE at all any more? If the answer is 'no',
then perhaps these other VDBs are doing some of the work for you, where
CVE is currently not.
: "If the vulnerabilities have dropped 30% since 2008, why do I need to be
: funding the security staff and efforts at the rate I am? I see that
: MITRE is reporting an overall drop each year since 2008 but yet you
: folks keep coming to me saying that the threats are much worse and we
: may be in the same relative situation we were when malware spiked a
: couple years past?"
That quote alone is a non sequitur really. I know that the conversations
are more detailed with these executives, but even as a summary, it is too
simplified.
Just because the number of unique vulnerabilities tracked by a VDB drops,
does not mean the number of attackers drop. Further, it does not mean risk
has dropped. Even further, more companies are using custom web
applications, and no VDB tracks site-specific vulnerabilities (one current
OSF project wants to, but we simply don't have funding or volunteers to
make it happen). These are just a few issues of why an overall
vulnerability count may drop, but their need to hire you and any other
security company is stronger than ever. I certainly hope you can steer
them past this limited view re: CVE.
: For those that actively work in this environment, we know
: vulnerabilities have not dropped 30% since 2008. Quite the contrary, our
: internal numbers indicate an increasing trend similar to a 30% rise.
: Symantec has also reported a similar trend.
Could you provide links to the Symantec report? Again, I am just curious
about the ~ 2008 thing where most VDBs reported a drop.
: Another problem is the CVE format itself. There has been an active
: discussion about the format limitations as well. The CVE format is
: CVE-YYYY-NNNN. This means that currently we cannot have more than 10,000
: CVEs reported in a single year. At the rates we are seeing internally,
: we are already there.
As I said in a previous reply, OSVDB hit the 10k mark in 2006 due to our
abstraction method.
: Then there are the limitations of CVE process in general. The focus is
: English only although some non-US vulnerabilities do get assigned from
: time to time. CVE does not support the international community and
: software written for non-English geo-centric areas are not included.
: While this has not been a concern for US-only software vendors, there is
: a great deal of regional software written for major emerging markets.
: None of those vulnerabilities are identified by a CVE.
This is very difficult to manage. Even if CVE could keep up with all
English-based disclosures from all sources (e.g., think of their team
being triple in size at the very least), trying to keep up with foreign on
top of it is another huge jump in resources. Carsten Eiram over at Secunia
could probably give some insight on this better than anyone. I have
noticed over the years that he appears to have several analysts that speak
other languages, as they frequently pull up vulnerabilities with no
English disclosure.
: Given these constraints, it seems like it is time to figure out how to
: address the issues in a more of a creative way. We know the
: constraints. Is there something we can do to augment the MITRE staff in
: certain areas that would help? I can see the format issue being a
: rather easy one to attack but it is the coverage issue that is most
: concerning. Or we should ignore it and slowly let the value of CVE to
: the community and vendors decay?
If MITRE can't get funding to keep up (and catch up), looking to augment
the effort from external staff would certainly be interesting. However, I
would like to make two points on that.
1. Having non-MITRE resources work on CVE would require an entire overhaul
of the process and policies around the project. Further, MITRE would have
to divert some resources away from the already struggling CVE to
implement some form of training program. I know this because Steve
Christey and I 'traded roles' for *one* entry many years back. He gave me
a link to a vulnerability and said "write a CVE". I gave him a link to a
vulnerability and said "mangle the OSVDB entry to 100%". We both learned a
lot from that process, and we both walked away with newfound respect for
each other's process. Trying to train up a dozen people to meet their
standards would not be easy.
2. OSVDB has been around for some time now, and I have been involved with
it since 2004. We have been an 'open' database, where anyone could sign up
for an account and contribute to our entries. We provided an extensive
walk-through, near 24 hour support for a while should anyone have
questions, reminder help screens for entries, templates to help ensure the
text was readable, and more. Over the last 8 or so years, less than 1% of
our data has come from volunteers. Off hand, I would guess that the bottom
1,000 volunteers who signed up have contributed less than the #8 ranking
contributor (http://osvdb.org/contributors). In short, the idea of an open
community-driven database simply did not work. We tried a wide variety of
campaigns to encourage people to help ranging from a reward system to
internships to resume experience working for a 501(c)(3). In all of that
time, less than 5 have stuck with the project and become core
contributors. While we don't quite have the exposure of CVE, we are
certainly not 'unknown'. We've had the framework to do this for a long
time, and I have to think that if the community wanted it, they would have
supported us. I know dozens of researchers and penetration testers that
"don't have the time", but are overjoyed when I can create and mangle an
entry for a vulnerability that no VDB has, so they can provide an external
reference in their reports.
Brian
OSF / OSVDB
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 04:33:44 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q289Xh2a017378
for <coley@RCF-SMTP.MITRE.ORG>; Thu, 8 Mar 2012 04:33:43 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 7E3D621B19A5;
Thu, 8 Mar 2012 04:33:38 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 604C42B7819A;
Thu, 8 Mar 2012 04:33:38 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 04:33:38 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4528234 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 04:32:59 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 04:32:59 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13241257; Thu, 08 Mar 2012 04:32:48 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 07B202B78199 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
04:32:49 -0500 (EST)
Received: from mail2.secunia.com (unknown [91.198.117.240]) by
smtpksrv1.mitre.org (Postfix) with SMTP id 8651F21B19A4 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
04:32:44 -0500 (EST)
Received: (qmail 13697 invoked from network); 8 Mar 2012 09:37:26 -0000
Received: from unknown (HELO exch-hq-1.secunia.local) (192.168.53.101) by
mail2.secunia.com with SMTP; 8 Mar 2012 09:37:26 -0000
Received: from EXCH-HQ-1.secunia.local ([::1]) by exch-hq-1.secunia.local
([::1]) with mapi id 14.01.0270.001; Thu, 8 Mar 2012 10:31:58 +0100
From: Carsten Eiram <che@secunia.com>
To: "'security curmudgeon'" <jericho@attrition.org>,
"'Kent_Landfield@McAfee.com'" <Kent_Landfield@McAfee.com>
CC: "'cve-editorial-board-list@lists.mitre.org'"
<cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zAAZUgUAAAIqAiA=
Date: Thu, 8 Mar 2012 09:31:58 +0000
Message-ID: <F4A3A6029AA9A54E8FA9BF5FB9834C797D0D31@exch-hq-1.secunia.local>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<alpine.LNX.2.00.1203080235500.27175@forced.attrition.org>
In-Reply-To: <alpine.LNX.2.00.1203080235500.27175@forced.attrition.org>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.53.61]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.92131
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_3000_3999 0,
BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, WEBMAIL_SOURCE 0,
WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __HAS_XOIP 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __NET_FUR_RDNS_TIMEOUT , __SANE_MSGID 0,
__TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS '
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q289Xh2a017378
Content-Length: 3324
Status:
X-Status:
X-Keywords:
> -----Original Message-----
> From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-
> editorial-board-list@lists.mitre.org] On Behalf Of security curmudgeon
> Sent: 8. marts 2012 09:57
> To: Kent_Landfield@McAfee.com
> Cc: cve-editorial-board-list@lists.mitre.org
> Subject: Re: Counting on CVEs
>
> : I have just had a very concerning discussion about the usefulness of
> : CVEs as a means to measure vulnerabilities today and the decay of its
> : value if the trend continues. The discussion centered around the
> : accuracy of the numbers of CVEs identified compared to those reported in
> : the community as a whole. If we looked at just the CVE numbers, it
> : appears that the numbers of vulnerabilities have been dropping since a
> : high in 2008. This is a rather important error. As we all know, this is
> : not accurate. Vulnerabilities have not been dropping, they are growing,
> : not dropping by 30%.
>
> I can't find it right off, but this came up several years back when several
> people noticed the drop in vulnerability totals around 2008. After additional
> examination of CVE, OSVDB, Secunia, and I believe BID, all four databases
> showed roughly the same drop. That in turn lead to speculation about *why*
> it was happening. I don't recall seeing anyone showing a 5 year trending of
> vulnerability counts, as seen through multiple VDBs, but I would honestly
> request to see some rough numbers before pursuing this line of discussion
> further.
I just participated in a panel ("Is it 0-day or 0-care?") at RSAC where I had included some slides on various vulnerability trends based on the Secunia database. I'm not sure if the slides are already publicly available, but else they should be at some point in the near future (if not I'll be happy to provide the slides to anyone interested). Anyway, based on our database the total number of vulnerabilities for the past years were:
2005: 6706
2006: 9915
2007: 7595
2008: 8387
2009: 7773
2010: 9640
2011: 9114
These numbers do not include any fake/invalid vulnerabilities and should only include a very low percentage of dupes (cannot be completely filtered out as a result of how we generate the vulnerability numbers from our advisories). Note that the total is for stable products only as the Secunia database (apart from a few exceptional cases) doesn't cover vulnerabilities in unstable/development products.
The same slide also included the trend in the number of SAIDs (Secunia Advisory IDs) issued to cover these vulnerabilities as well as the number of CVEs assigned for these vulnerabilities. While the number of SAIDs isn't interesting to this discussion, the number of CVEs assigned is; there does seem to be a drop in the number of vulnerabilities covered after 2008 (percentage is CVE to vulnerability ratio) and if anything our efforts in ensuring that our SAIDs include CVEs have increased:
2005: 3348 (49,9%)
2006: 5531 (55,8%)
2007: 4443 (58,5%)
2008: 5192 (61,9%)
2009: 3938 (50,7%)
2010: 4122 (42,8%)
2011: 3542 (38,9%)
--
Med venlig hilsen / Kind regards
Carsten H. Eiram
Chief Security Specialist
Follow us on twitter
http://twitter.com/secunia
http://twitter.com/carsteneiram
Secunia
Mikado House
Rued Langgaards Vej 8
2300 Copenhagen S
Denmark
Phone +45 7020 5144
Fax +45 7020 5145
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 04:33:44 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q289Xhwk017376;
Thu, 8 Mar 2012 04:33:43 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 7E3D621B19A5;
Thu, 8 Mar 2012 04:33:38 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 604C42B7819A;
Thu, 8 Mar 2012 04:33:38 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 04:33:38 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4528234 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 04:32:59 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 04:32:59 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13241257; Thu, 08 Mar 2012 04:32:48 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 07B202B78199 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
04:32:49 -0500 (EST)
Received: from mail2.secunia.com (unknown [91.198.117.240]) by
smtpksrv1.mitre.org (Postfix) with SMTP id 8651F21B19A4 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
04:32:44 -0500 (EST)
Received: (qmail 13697 invoked from network); 8 Mar 2012 09:37:26 -0000
Received: from unknown (HELO exch-hq-1.secunia.local) (192.168.53.101) by
mail2.secunia.com with SMTP; 8 Mar 2012 09:37:26 -0000
Received: from EXCH-HQ-1.secunia.local ([::1]) by exch-hq-1.secunia.local
([::1]) with mapi id 14.01.0270.001; Thu, 8 Mar 2012 10:31:58 +0100
From: Carsten Eiram <che@secunia.com>
To: "'security curmudgeon'" <jericho@attrition.org>,
"'Kent_Landfield@McAfee.com'" <Kent_Landfield@McAfee.com>
CC: "'cve-editorial-board-list@lists.mitre.org'"
<cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zAAZUgUAAAIqAiA=
Date: Thu, 8 Mar 2012 09:31:58 +0000
Message-ID: <F4A3A6029AA9A54E8FA9BF5FB9834C797D0D31@exch-hq-1.secunia.local>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<alpine.LNX.2.00.1203080235500.27175@forced.attrition.org>
In-Reply-To: <alpine.LNX.2.00.1203080235500.27175@forced.attrition.org>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.53.61]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.92131
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_3000_3999 0,
BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, WEBMAIL_SOURCE 0,
WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __HAS_XOIP 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __NET_FUR_RDNS_TIMEOUT , __SANE_MSGID 0,
__TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS '
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q289Xhwk017376
Content-Length: 3324
Status:
X-Status:
X-Keywords:
> -----Original Message-----
> From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-
> editorial-board-list@lists.mitre.org] On Behalf Of security curmudgeon
> Sent: 8. marts 2012 09:57
> To: Kent_Landfield@McAfee.com
> Cc: cve-editorial-board-list@lists.mitre.org
> Subject: Re: Counting on CVEs
>
> : I have just had a very concerning discussion about the usefulness of
> : CVEs as a means to measure vulnerabilities today and the decay of its
> : value if the trend continues. The discussion centered around the
> : accuracy of the numbers of CVEs identified compared to those reported in
> : the community as a whole. If we looked at just the CVE numbers, it
> : appears that the numbers of vulnerabilities have been dropping since a
> : high in 2008. This is a rather important error. As we all know, this is
> : not accurate. Vulnerabilities have not been dropping, they are growing,
> : not dropping by 30%.
>
> I can't find it right off, but this came up several years back when several
> people noticed the drop in vulnerability totals around 2008. After additional
> examination of CVE, OSVDB, Secunia, and I believe BID, all four databases
> showed roughly the same drop. That in turn lead to speculation about *why*
> it was happening. I don't recall seeing anyone showing a 5 year trending of
> vulnerability counts, as seen through multiple VDBs, but I would honestly
> request to see some rough numbers before pursuing this line of discussion
> further.
I just participated in a panel ("Is it 0-day or 0-care?") at RSAC where I had included some slides on various vulnerability trends based on the Secunia database. I'm not sure if the slides are already publicly available, but else they should be at some point in the near future (if not I'll be happy to provide the slides to anyone interested). Anyway, based on our database the total number of vulnerabilities for the past years were:
2005: 6706
2006: 9915
2007: 7595
2008: 8387
2009: 7773
2010: 9640
2011: 9114
These numbers do not include any fake/invalid vulnerabilities and should only include a very low percentage of dupes (cannot be completely filtered out as a result of how we generate the vulnerability numbers from our advisories). Note that the total is for stable products only as the Secunia database (apart from a few exceptional cases) doesn't cover vulnerabilities in unstable/development products.
The same slide also included the trend in the number of SAIDs (Secunia Advisory IDs) issued to cover these vulnerabilities as well as the number of CVEs assigned for these vulnerabilities. While the number of SAIDs isn't interesting to this discussion, the number of CVEs assigned is; there does seem to be a drop in the number of vulnerabilities covered after 2008 (percentage is CVE to vulnerability ratio) and if anything our efforts in ensuring that our SAIDs include CVEs have increased:
2005: 3348 (49,9%)
2006: 5531 (55,8%)
2007: 4443 (58,5%)
2008: 5192 (61,9%)
2009: 3938 (50,7%)
2010: 4122 (42,8%)
2011: 3542 (38,9%)
--
Med venlig hilsen / Kind regards
Carsten H. Eiram
Chief Security Specialist
Follow us on twitter
http://twitter.com/secunia
http://twitter.com/carsteneiram
Secunia
Mikado House
Rued Langgaards Vej 8
2300 Copenhagen S
Denmark
Phone +45 7020 5144
Fax +45 7020 5145
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 11:01:08 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q28G13w4011460;
Thu, 8 Mar 2012 11:01:03 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id C4CF421B15A0;
Thu, 8 Mar 2012 11:00:57 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 8636521B156E;
Thu, 8 Mar 2012 11:00:55 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 11:00:55 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4531280 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 11:00:22 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 11:00:22 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13242353; Thu, 08 Mar 2012 11:00:12 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 5D75221B111C for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
11:00:12 -0500 (EST)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id C15B521B0BF3 for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
11:00:11 -0500 (EST)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by
shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id
q28FxwnH005561; Thu, 8 Mar 2012 10:59:58 -0500
Received: from marble.local (vpn-10-61-10-4.remote.cert.org [10.61.10.4]) by
pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id
q28Fxu8G010659; Thu, 8 Mar 2012 10:59:57 -0500
Message-ID: <4F58D77D.7080405@cert.org>
Date: Thu, 8 Mar 2012 10:59:57 -0500
From: Art Manion <amanion@cert.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2)
Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: security curmudgeon <jericho@attrition.org>
CC: Russ Cooper <Russ.Cooper@rc.on.ca>,
"cve-editorial-board-list@lists.mitre.org"
<cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<ED311CBEE6993C428563DEDF6D083BC81180FBF7@usilms113b.ca.com>
<A27B80707A1E924891446594C00EBA8C52B245E2@Sunfish.rc.on.ca>
<alpine.LNX.2.00.1203080226050.27175@forced.attrition.org>
In-Reply-To: <alpine.LNX.2.00.1203080226050.27175@forced.attrition.org>
X-Enigmail-Version: 1.3.5
OpenPGP: id=36C268A3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.154525
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1,
HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0,
BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DATE_TZ_NEG_0500 0,
__ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__MOZILLA_MSGID 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0,
__TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ,
__USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 332
Status:
X-Status:
X-Keywords:
On 2012-03-08 03:31 , security curmudgeon wrote:
> There is additional discussion on CVE handling the #### issue on the
> CERT-run vrdx mail list.
SUBSCRIBING
This is an open list, anybody can join by sending email
to <mailto:Majordomo@cert.org> with the "subscribe vrdx"
(no quotes) in the body of the message.
- Art
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 11:01:08 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q28G133C011461
for <coley@RCF-SMTP.MITRE.ORG>; Thu, 8 Mar 2012 11:01:03 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id C4CF421B15A0;
Thu, 8 Mar 2012 11:00:57 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 8636521B156E;
Thu, 8 Mar 2012 11:00:55 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 11:00:55 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4531280 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 11:00:22 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 11:00:22 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13242353; Thu, 08 Mar 2012 11:00:12 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 5D75221B111C for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
11:00:12 -0500 (EST)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id C15B521B0BF3 for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
11:00:11 -0500 (EST)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by
shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id
q28FxwnH005561; Thu, 8 Mar 2012 10:59:58 -0500
Received: from marble.local (vpn-10-61-10-4.remote.cert.org [10.61.10.4]) by
pawpaw.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id
q28Fxu8G010659; Thu, 8 Mar 2012 10:59:57 -0500
Message-ID: <4F58D77D.7080405@cert.org>
Date: Thu, 8 Mar 2012 10:59:57 -0500
From: Art Manion <amanion@cert.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2)
Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: security curmudgeon <jericho@attrition.org>
CC: Russ Cooper <Russ.Cooper@rc.on.ca>,
"cve-editorial-board-list@lists.mitre.org"
<cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<ED311CBEE6993C428563DEDF6D083BC81180FBF7@usilms113b.ca.com>
<A27B80707A1E924891446594C00EBA8C52B245E2@Sunfish.rc.on.ca>
<alpine.LNX.2.00.1203080226050.27175@forced.attrition.org>
In-Reply-To: <alpine.LNX.2.00.1203080226050.27175@forced.attrition.org>
X-Enigmail-Version: 1.3.5
OpenPGP: id=36C268A3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.154525
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1,
HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0,
BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DATE_TZ_NEG_0500 0,
__ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__MOZILLA_MSGID 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0,
__TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ,
__USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 332
Status:
X-Status:
X-Keywords:
On 2012-03-08 03:31 , security curmudgeon wrote:
> There is additional discussion on CVE handling the #### issue on the
> CERT-run vrdx mail list.
SUBSCRIBING
This is an open list, anybody can join by sending email
to <mailto:Majordomo@cert.org> with the "subscribe vrdx"
(no quotes) in the body of the message.
- Art
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 11:52:48 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q28GqlYi012148
for <coley@RCF-SMTP.MITRE.ORG>; Thu, 8 Mar 2012 11:52:47 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id D272E21B15AA;
Thu, 8 Mar 2012 11:52:41 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 65DF521B158D;
Thu, 8 Mar 2012 11:52:41 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 11:52:41 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4531933 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 11:52:32 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 11:52:32 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13242589; Thu, 08 Mar 2012 11:52:17 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 6B64D21B1252 for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
11:52:17 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 57D0421B123F for
<cve-editorial-board-list@lists.mitre.org>; Thu, 8 Mar 2012
11:52:17 -0500 (EST)
Received: from IMCMBX02.MITRE.ORG ([169.254.2.56]) by IMCCAS01.MITRE.ORG
([129.83.29.78]) with mapi id 14.01.0339.001; Thu, 8 Mar 2012
11:52:17 -0500
From: "Boyle, Stephen V." <sboyle@mitre.org>
To: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zAArww1Q
Date: Thu, 8 Mar 2012 16:52:16 +0000
Message-ID: <5084579A0A81C947AB6E6BFB7AFCF9DF13DC66@IMCMBX02.MITRE.ORG>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
In-Reply-To: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.83.31.51]
Content-Type: multipart/alternative;
boundary="_000_5084579A0A81C947AB6E6BFB7AFCF9DF13DC66IMCMBX02MITREORG_"
MIME-Version: 1.0
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 20072
Status: R
X-Status: A
X-Keywords:
--_000_5084579A0A81C947AB6E6BFB7AFCF9DF13DC66IMCMBX02MITREORG_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
This might sound like splitting hairs, but how "vulnerabilities" are counte=
d may well enter into this. I'm not claiming that CVE is keeping up - both =
Kent and others have correctly stated reasons and history that apply, and y=
eah, somebody who's only looking at somebody's raw numbers (be they CVE or =
anything else) is going to ask hard questions, especially when money is har=
d to come by.
Having said that, it bears mentioning that by design, there are always goin=
g to be fewer CVEs than there are "vulnerabilities" - it's kinda one of the=
key features. :) There are also more players in the space than there were =
a few years ago, each of which has multiple incentives to publish more vuln=
erabilities than others.
Again, I am not saying there's not a problem - we have to be able to answer=
honest questions such as the one Kent relayed. But we also have to be mind=
ful of what are real, what counting problems exist in all vulnerability rep=
orting sources, and what that means for CVE.
Tx,
Steve
From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-edit=
orial-board-list@lists.mitre.org] On Behalf Of Kent_Landfield@McAfee.com
Sent: Wednesday, March 07, 2012 2:53 PM
To: cve-editorial-board-list
Subject: Counting on CVEs
All,
We have problems with CVE reporting that are known issues but which are bec=
oming apparent to many more and could easily undermine the usefulness of CV=
E identification if left unchecked.
We discussed this at the ITSAC conference in the Future of Vulnerability Re=
porting Workshop and at the follow-on Vulnerability Reporting day at the So=
ftware Assurance event a month later. (There were action items out of the l=
atter that I am not aware have been completed...)
I have just had a very concerning discussion about the usefulness of CVEs a=
s a means to measure vulnerabilities today and the decay of its value if th=
e trend continues. The discussion centered around the accuracy of the num=
bers of CVEs identified compared to those reported in the community as a wh=
ole. If we looked at just the CVE numbers, it appears that the numbers of=
vulnerabilities have been dropping since a high in 2008. This is a rathe=
r important error. As we all know, this is not accurate. Vulnerabilities ha=
ve not been dropping, they are growing, not dropping by 30%.
For the vendor community, these trends have rather concerning potential imp=
acts on us. First, our vulnerability research databases use CVE as a prima=
ry reference. The CVE Id has been authoritative in the past. It is used i=
nternally as a means to communicate vulnerability record information betwee=
n fielded products and between research analysis teams. As the numbers dec=
line, it means we are forced to look elsewhere to provide the identificatio=
n and communication that CVE provided in the past. More proprietary ids are=
becoming more the norm.
The more serious concern is what it is showing to executives of companies.
"If the vulnerabilities have dropped 30% since 2008, why do I need to be f=
unding the security staff and efforts at the rate I am? I see that MITRE i=
s reporting an overall drop each year since 2008 but yet you folks keep com=
ing to me saying that the threats are much worse and we may be in the same =
relative situation we were when malware spiked a couple years past..."
For those that actively work in this environment, we know vulnerabilities h=
ave not dropped 30% since 2008. Quite the contrary, our internal numbers in=
dicate an increasing trend similar to a 30% rise. Symantec has also report=
ed a similar trend.
One of the major problems is that MITRE funding is not what it should be. O=
n multiple occasions we have been asked to target the classes of products w=
here vulnerabilities are considered the most critical and which sources sho=
uld be monitored. The view of what to target and monitor gets smaller and s=
maller as funding is held level or reduced.
At one point the intent of the effort was to cover all published vulnerabil=
ities that could be corroborated in some fashion. Over the years the reali=
ty has set in that this is a very resource intensive operation. As such th=
e focus of the effort has reduced what is reported on to assure CVEs can be=
assigned for the types of products most important to the Editorial Board =
participants and their sponsor. This gives an artificial view of the numbe=
rs of existing vulnerabilities and that is being recognized outside the vul=
nerability community.
Another problem is the CVE format itself. There has been an active discuss=
ion about the format limitations as well. The CVE format is CVE-YYYY-NNNN. =
This means that currently we cannot have more than 10,000 CVEs reported in =
a single year. At the rates we are seeing internally, we are already there=
.
Then there are the limitations of CVE process in general. The focus is Eng=
lish only although some non-US vulnerabilities do get assigned from time to=
time. CVE does not support the international community and software writt=
en for non-English geo-centric areas are not included. While this has not =
been a concern for US-only software vendors, there is a great deal of regio=
nal software written for major emerging markets. None of those vulnerabili=
ties are identified by a CVE.
Given these constraints, it seems like it is time to figure out how to addr=
ess the issues in a more of a creative way. We know the constraints. Is th=
ere something we can do to augment the MITRE staff in certain areas that wo=
uld help? I can see the format issue being a rather easy one to attack but=
it is the coverage issue that is most concerning. Or we should ignore it =
and slowly let the value of CVE to the community and vendors decay...
Thoughts?
Kent Landfield
Director Content Strategy, Architecture and Standards
McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>
--_000_5084579A0A81C947AB6E6BFB7AFCF9DF13DC66IMCMBX02MITREORG_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">This might sound like spl=
itting hairs, but how “vulnerabilities” are counted may well en=
ter into this. I’m not claiming that CVE is keeping up – both K=
ent and
others have correctly stated reasons and history that apply, and yeah, som=
ebody who’s only looking at somebody’s raw numbers (be they CVE=
or anything else) is going to ask hard questions, especially when money is=
hard to come by.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Having said that, it bear=
s mentioning that by design, there are always going to be fewer CVEs than t=
here are “vulnerabilities” – it’s kinda one of the =
key features.
</span><span style=3D"font-size:11.0pt;font-family:Wingdings;color:#1F497D"=
>J</span><span style=3D"font-size:11.0pt;font-family:"Calibri",&q=
uot;sans-serif";color:#1F497D"> There are also more players in the spa=
ce than there were a few years ago, each of which has multiple
incentives to publish more vulnerabilities than others. <o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Again, I am not saying th=
ere’s not a problem – we have to be able to answer honest quest=
ions such as the one Kent relayed. But we also have to be mindful of
what are real, what counting problems exist in all vulnerability reporting=
sources, and what that means for CVE.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Tx,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Steve<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"=
;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:"Tahoma","sans-serif""> owner-cv=
e-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-li=
st@lists.mitre.org]
<b>On Behalf Of </b>Kent_Landfield@McAfee.com<br>
<b>Sent:</b> Wednesday, March 07, 2012 2:53 PM<br>
<b>To:</b> cve-editorial-board-list<br>
<b>Subject:</b> Counting on CVEs<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">All,<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">We have problems with CV=
E reporting that are known issues but which are becoming apparent to many m=
ore and could easily undermine the usefulness of CVE identification if left=
unchecked.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">We discussed this at the=
ITSAC conference in the Future of Vulnerability Reporting Workshop and at =
the follow-on Vulnerability Reporting day at the Software Assurance event a=
month later. (There were action items
out of the latter that I am not aware have been completed…)<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">I have just had a very c=
oncerning discussion about the usefulness of CVEs as a means to measure vul=
nerabilities today and the decay of its value if the trend continues.  =
; The discussion centered around the accuracy
of the numbers of CVEs identified compared to those reported in the commun=
ity as a whole. If we looked at just the CVE numbers, it appear=
s that the numbers of vulnerabilities have been dropping since a high in 20=
08. This is a rather important error. As
we all know, this is not accurate. Vulnerabilities have not been dropping,=
they are growing, not dropping by 30%. <o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">For the vendor community=
, these trends have rather concerning potential impacts on us. First,=
our vulnerability research databases use CVE as a primary reference.  =
;The CVE Id has been authoritative in the past.
It is used internally as a means to communicate vulnerability record=
information between fielded products and between research analysis teams. =
As the numbers decline, it means we are forced to look elsewhere to p=
rovide the identification and communication
that CVE provided in the past. More proprietary ids are becoming more the =
norm.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">The more serious concern=
is what it is showing to executives of companies. <o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><i><span style=3D"color:black">"If the vulnerab=
ilities have dropped 30% since 2008, why do I need to be funding the =
security staff and efforts at the rate I am? I see that MITRE is repo=
rting an overall drop each year since 2008 but yet
you folks keep coming to me saying that the threats are much worse and we =
may be in the same relative situation we were when malware spiked a couple =
years past…"</span></i><span style=3D"color:black"><o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">For those that actively =
work in this environment, we know vulnerabilities have not dropped 30% sinc=
e 2008. Quite the contrary, our internal numbers indicate an increasing tre=
nd similar to a 30% rise. Symantec
has also reported a similar trend.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">One of the major problem=
s is that MITRE funding is not what it should be. On multiple occasions we =
have been asked to target the classes of products where vulnerabilities are=
considered the most critical and which
sources should be monitored. The view of what to target and monitor gets s=
maller and smaller as funding is held level or reduced.<o:p></o:p></s=
pan></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">At one point the intent =
of the effort was to cover all published vulnerabilities that could be corr=
oborated in some fashion. Over the years the reality has set in that =
this is a very resource intensive operation.
As such the focus of the effort has reduced what is reported on to a=
ssure CVEs can be assigned for the types of products most important t=
o the Editorial Board participants and their sponsor. This gives an a=
rtificial view of the numbers of existing vulnerabilities
and that is being recognized outside the vulnerability community.<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">Another problem is the C=
VE format itself. There has been an active discussion about the forma=
t limitations as well. The CVE format is CVE-YYYY-NNNN. This means that cur=
rently we cannot have more than 10,000 CVEs
reported in a single year. At the rates we are seeing internally, we=
are already there.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">Then there are the limit=
ations of CVE process in general. The focus is English only although =
some non-US vulnerabilities do get assigned from time to time. CVE do=
es not support the international community and
software written for non-English geo-centric areas are not included.  =
;While this has not been a concern for US-only software vendors, there is a=
great deal of regional software written for major emerging markets. =
None of those vulnerabilities are identified
by a CVE. <o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">Given these constraints,=
it seems like it is time to figure out how to address the issues in a more=
of a creative way. We know the constraints. Is there something we ca=
n do to augment the MITRE staff in certain
areas that would help? I can see the format issue being a rather eas=
y one to attack but it is the coverage issue that is most concerning.  =
;Or we should ignore it and slowly let the value of CVE to the community an=
d vendors decay…<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black">Thoughts?<o:p></o:p></sp=
an></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>=
</p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><strong><span style=3D"font-size:9.0pt;font-family:&=
quot;Arial","sans-serif";color:#606A71">Kent Landfield</span=
></strong><span style=3D"font-size:9.0pt;font-family:"Arial",&quo=
t;sans-serif";color:#606A71"><br>
<span class=3D"apple-style-span">Director Content Strategy, Architecture an=
d Standards</span><br>
<br>
<strong><span style=3D"font-family:"Arial","sans-serif"=
">McAfee | An Intel Company</span></strong><br>
<span class=3D"apple-style-span">5000 Headquarters Dr.</span><br>
<span class=3D"apple-style-span">Plano, Texas 75024</span><br>
<br>
<span class=3D"apple-style-span">Direct: +1.972.963.7096 </span><b=
r>
<span class=3D"apple-style-span">Mobile: +1.817.637.8026</span><br>
<strong><span style=3D"font-family:"Arial","sans-serif"=
">Web: </span></strong><span class=3D"apple-style-span"><a href=3D"htt=
p://www.mcafee.com/">www.mcafee.com</a></span></span><span style=3D"color:b=
lack"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>
--_000_5084579A0A81C947AB6E6BFB7AFCF9DF13DC66IMCMBX02MITREORG_--
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 15:56:33 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q28KuXvG016694
for <coley@RCF-SMTP.MITRE.ORG>; Thu, 8 Mar 2012 15:56:33 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id DD4ED21B0B54;
Thu, 8 Mar 2012 15:56:27 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id B69C821B0A96;
Thu, 8 Mar 2012 15:56:27 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 15:56:27 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4535755 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 15:55:54 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 15:55:54 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13244032; Thu, 08 Mar 2012 15:55:45 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 792CB21B0DDF for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
15:55:45 -0500 (EST)
Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1F62D21B0B54 for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
15:55:45 -0500 (EST)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by
plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id
q28KtiDp012328; Thu, 8 Mar 2012 15:55:44 -0500
Received: from marble.local (vpn-10-61-10-4.remote.cert.org [10.61.10.4]) by
timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id
q28KtiXe010452; Thu, 8 Mar 2012 15:55:44 -0500
Message-ID: <4F591CCF.6050203@cert.org>
Date: Thu, 8 Mar 2012 15:55:43 -0500
From: Art Manion <amanion@cert.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2)
Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Boyle, Stephen V." <sboyle@mitre.org>
CC: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<5084579A0A81C947AB6E6BFB7AFCF9DF13DC66@IMCMBX02.MITRE.ORG>
In-Reply-To: <5084579A0A81C947AB6E6BFB7AFCF9DF13DC66@IMCMBX02.MITRE.ORG>
X-Enigmail-Version: 1.3.5
OpenPGP: id=36C268A3
Content-Type: text/plain; charset="windows-1252"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.204215
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DATE_TZ_NEG_0500 0,
NO_URI_FOUND 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__MOZILLA_MSGID 0, __SANE_MSGID 0, __TO_MALFORMED_2 0,
__USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q28KuXvG016694
Content-Length: 2472
Status:
X-Status:
X-Keywords:
On 2012-03-08 11:52 , Boyle, Stephen V. wrote:
> This might sound like splitting hairs, but how “vulnerabilities” are
> counted may well enter into this. I’m not claiming that CVE is keeping
> up – both Kent and others have correctly stated reasons and history that
> apply, and yeah, somebody who’s only looking at somebody’s raw numbers
> (be they CVE or anything else) is going to ask hard questions,
> especially when money is hard to come by.
>
> Having said that, it bears mentioning that by design, there are always
> going to be fewer CVEs than there are “vulnerabilities” – it’s kinda one
> of the key features. JThere are also more players in the space than
> there were a few years ago, each of which has multiple incentives to
> publish more vulnerabilities than others.
>
> Again, I am not saying there’s not a problem – we have to be able to
> answer honest questions such as the one Kent relayed. But we also have
> to be mindful of what are real, what counting problems exist in all
> vulnerability reporting sources, and what that means for CVE.
The questions remain IMO:
1. What level of abstraction is appropriate for CVE?
2. What level of completeness is appropriate for CVE?
How narrowly do we define "vulnerability," the thing to name/count?
Is there desire/need for an accurate count of vulnerabilities? OSVDB
either abstracts a little more narrowly than CVE and/or collects more
vulnerabilities, so OSVDB has higher numbers.
If CVE or any other database were to try to name and count all publicly
disclosed vulnerabilities, it would be important to be able to
distinguish between a vulnerability that is one of a dozen XSS bugs in a
PHP web app and a vulnerability that is a straight up stack buffer
overflow in httpd. Sure, count them all, but be able to say that out of
20K vulnerabilities named this year, 61% were XSS or SQLi in web apps
with low distribution.
I'm guessing at some numbers in the above example, but this is a big
reason IMO that CVE numbers have declined. Vulnerabilities "worth
tracking with a CVE" have declined, not the total number of
vulnerabilities. Another way to look at it might be that thee criteria
for "worth tracking with a CVE" has changed.
And we're not even talking about threat or asset values (both of which
have changed over time, and are different depending on your
site/assets), which influence risk. So a decrease in CVE IDs has little
directly to do with internet risk overall.
- Art
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 15:56:33 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q28KuXkH016693;
Thu, 8 Mar 2012 15:56:33 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id DD4ED21B0B54;
Thu, 8 Mar 2012 15:56:27 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id B69C821B0A96;
Thu, 8 Mar 2012 15:56:27 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 15:56:27 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4535755 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 15:55:54 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 15:55:54 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13244032; Thu, 08 Mar 2012 15:55:45 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 792CB21B0DDF for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
15:55:45 -0500 (EST)
Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1F62D21B0B54 for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
15:55:45 -0500 (EST)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by
plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id
q28KtiDp012328; Thu, 8 Mar 2012 15:55:44 -0500
Received: from marble.local (vpn-10-61-10-4.remote.cert.org [10.61.10.4]) by
timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id
q28KtiXe010452; Thu, 8 Mar 2012 15:55:44 -0500
Message-ID: <4F591CCF.6050203@cert.org>
Date: Thu, 8 Mar 2012 15:55:43 -0500
From: Art Manion <amanion@cert.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2)
Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Boyle, Stephen V." <sboyle@mitre.org>
CC: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<5084579A0A81C947AB6E6BFB7AFCF9DF13DC66@IMCMBX02.MITRE.ORG>
In-Reply-To: <5084579A0A81C947AB6E6BFB7AFCF9DF13DC66@IMCMBX02.MITRE.ORG>
X-Enigmail-Version: 1.3.5
OpenPGP: id=36C268A3
Content-Type: text/plain; charset="windows-1252"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.204215
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DATE_TZ_NEG_0500 0,
NO_URI_FOUND 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__MOZILLA_MSGID 0, __SANE_MSGID 0, __TO_MALFORMED_2 0,
__USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q28KuXkH016693
Content-Length: 2472
Status:
X-Status:
X-Keywords:
On 2012-03-08 11:52 , Boyle, Stephen V. wrote:
> This might sound like splitting hairs, but how “vulnerabilities” are
> counted may well enter into this. I’m not claiming that CVE is keeping
> up – both Kent and others have correctly stated reasons and history that
> apply, and yeah, somebody who’s only looking at somebody’s raw numbers
> (be they CVE or anything else) is going to ask hard questions,
> especially when money is hard to come by.
>
> Having said that, it bears mentioning that by design, there are always
> going to be fewer CVEs than there are “vulnerabilities” – it’s kinda one
> of the key features. JThere are also more players in the space than
> there were a few years ago, each of which has multiple incentives to
> publish more vulnerabilities than others.
>
> Again, I am not saying there’s not a problem – we have to be able to
> answer honest questions such as the one Kent relayed. But we also have
> to be mindful of what are real, what counting problems exist in all
> vulnerability reporting sources, and what that means for CVE.
The questions remain IMO:
1. What level of abstraction is appropriate for CVE?
2. What level of completeness is appropriate for CVE?
How narrowly do we define "vulnerability," the thing to name/count?
Is there desire/need for an accurate count of vulnerabilities? OSVDB
either abstracts a little more narrowly than CVE and/or collects more
vulnerabilities, so OSVDB has higher numbers.
If CVE or any other database were to try to name and count all publicly
disclosed vulnerabilities, it would be important to be able to
distinguish between a vulnerability that is one of a dozen XSS bugs in a
PHP web app and a vulnerability that is a straight up stack buffer
overflow in httpd. Sure, count them all, but be able to say that out of
20K vulnerabilities named this year, 61% were XSS or SQLi in web apps
with low distribution.
I'm guessing at some numbers in the above example, but this is a big
reason IMO that CVE numbers have declined. Vulnerabilities "worth
tracking with a CVE" have declined, not the total number of
vulnerabilities. Another way to look at it might be that thee criteria
for "worth tracking with a CVE" has changed.
And we're not even talking about threat or asset values (both of which
have changed over time, and are different depending on your
site/assets), which influence risk. So a decrease in CVE IDs has little
directly to do with internet risk overall.
- Art
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Thu Mar 8 17:18:51 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q28MIo3W018327;
Thu, 8 Mar 2012 17:18:50 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id AC78E21B12E1;
Thu, 8 Mar 2012 17:18:45 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 8CB0E21B12D6;
Thu, 8 Mar 2012 17:18:45 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Thu, 8 Mar 2012 17:18:45 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4536614 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Thu, 8 Mar
2012 17:17:48 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Thu, 8 Mar 2012 17:17:48 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13244285; Thu, 08 Mar 2012 17:17:40 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 90C8121B1084 for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
17:17:40 -0500 (EST)
Received: from mail.ncircle.com (mail.ncircle.com [76.247.119.150]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 73A8B21B128D for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012
17:17:38 -0500 (EST)
Received: from corp-mail-sf.ncircle.com (fw-hive-gate-dmz.ncircle.com
[76.247.119.129] (may be forged)) by mail.ncircle.com
(8.14.3/8.14.2) with ESMTP id q28MHaNZ015445 (version=TLSv1/SSLv3
cipher=AES128-SHA bits=128 verify=FAIL) for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Thu, 8 Mar 2012 14:17:36
-0800 (PST) (envelope-from tkeanini@ncircle.com)
Received: from CORP-MAIL.ad.ncircle.com (192.168.75.90) by
EXCH-SF-01.ad.ncircle.com (192.168.75.23) with Microsoft SMTP Server
id 14.2.247.3; Thu, 8 Mar 2012 14:17:36 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Counting on CVEs
Date: Thu, 8 Mar 2012 14:17:34 -0800
Message-ID: <FF3925ED7890A54BAE593422125529930F01AA57@CORP-MAIL.ad.ncircle.com>
In-Reply-To: <4F591CCF.6050203@cert.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Counting on CVEs
Thread-Index: Acz9be9lExCj2x9hSAq0XxuQerh0dQAAUGlQ
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<5084579A0A81C947AB6E6BFB7AFCF9DF13DC66@IMCMBX02.MITRE.ORG>
<4F591CCF.6050203@cert.org>
From: Tim Keanini <tkeanini@ncircle.com>
To: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
X-Spam-Score: -3.727 () ALL_TRUSTED,AWL,BAYES_00
X-Scanned-By: MIMEDefang 2.64 on 76.247.119.150
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.8.220915
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, BODY_SIZE_5000_5999 0, BODY_SIZE_7000_LESS 0,
DATE_TZ_NA 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0,
__URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS '
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q28MIo3W018327
Content-Length: 5344
Status: R
X-Status:
X-Keywords:
In my understanding to this thread, Kent raises three main points:
- The count of members who are of the set CVE (by the people who count
CVE)
- Technical Limitation of the CVE name (namespace boundary)
- The operational quality and quantity of resources within the CVE
counting process (how a CVE comes in to being)
The crux of the problem as a I see it goes something like this: if the
desire is for CVE to be canonical and primary for every vulnerability
reference on a global scale, it certainly is not resourced that way and
the operational resources to really success at this goal is unknown at
this time.
Unless someone can argue otherwise, the growth limits with CVE counts
over the years has more to do with the process capacity to do the
counting and not the expansion of things to be counted. If this
assertion is true, we have at least two choices:
Option A- address the operational resources required to get to the
resolution required by the market to count these items. There will
always be some tolerance because this can never be perfect. Once
identified, some business model must be put in place to sustain growth
and quality.
Or
Option B- create a more ontological model that considers CVE not the
primary or root but just another piece of metadata use to reify some
other assertion. As a vendor, I can only control what I can control and
that is my own internal ID which are organizationally closed for my own
data integrity.
nCircle-ID-667 -has-CVE-ID-> CVE-xxxx-xxxx
nCircle-ID-667 -has-CVE-v2-ID->
CVE-xxxx-xxxx-withextension-yyyy-for-future-format
nCircle-ID-667 -has-Secunia-ID-> Unique-Secunia-ID
nCircle-ID-667 -has-OSVDB-ID-> Unique-OSVDB-ID
(for those of you who know me, I would rather be working on a standard
ontological model that any vendor interoperate no matter what the
resolution or primary identifier. The goal of interoperability should
be to compute syntactic or semantic equivalence )
Call me pragmatic but this is an example of what I have done, not asking
for anyone else to follow. Just needed an example where CVE was not
primary but one of the inverse-functional-properties that can be used
for saying that this is the same as that (compute equivalence)
Call me old and jaded but I just don't see how the CVE operational team
gets the resources they need to succeed when no one is really paying for
the quality or quantity of their efforts. I mean this with the utmost
respect for that team since I know most of the members personally and
know the tireless hours they put in. "NOW GET OFF MY LAWN!" :-)
--tk
-----Original Message-----
From: owner-cve-editorial-board-list@LISTS.MITRE.ORG
[mailto:owner-cve-editorial-board-list@LISTS.MITRE.ORG] On Behalf Of Art
Manion
Sent: Thursday, March 08, 2012 2:56 PM
To: Boyle, Stephen V.
Cc: cve-editorial-board-list
Subject: Re: Counting on CVEs
On 2012-03-08 11:52 , Boyle, Stephen V. wrote:
> This might sound like splitting hairs, but how "vulnerabilities" are
> counted may well enter into this. I'm not claiming that CVE is keeping
> up - both Kent and others have correctly stated reasons and history
> that apply, and yeah, somebody who's only looking at somebody's raw
> numbers (be they CVE or anything else) is going to ask hard questions,
> especially when money is hard to come by.
>
> Having said that, it bears mentioning that by design, there are always
> going to be fewer CVEs than there are "vulnerabilities" - it's kinda
> one of the key features. JThere are also more players in the space
> than there were a few years ago, each of which has multiple incentives
> to publish more vulnerabilities than others.
>
> Again, I am not saying there's not a problem - we have to be able to
> answer honest questions such as the one Kent relayed. But we also have
> to be mindful of what are real, what counting problems exist in all
> vulnerability reporting sources, and what that means for CVE.
The questions remain IMO:
1. What level of abstraction is appropriate for CVE?
2. What level of completeness is appropriate for CVE?
How narrowly do we define "vulnerability," the thing to name/count?
Is there desire/need for an accurate count of vulnerabilities? OSVDB
either abstracts a little more narrowly than CVE and/or collects more
vulnerabilities, so OSVDB has higher numbers.
If CVE or any other database were to try to name and count all publicly
disclosed vulnerabilities, it would be important to be able to
distinguish between a vulnerability that is one of a dozen XSS bugs in a
PHP web app and a vulnerability that is a straight up stack buffer
overflow in httpd. Sure, count them all, but be able to say that out of
20K vulnerabilities named this year, 61% were XSS or SQLi in web apps
with low distribution.
I'm guessing at some numbers in the above example, but this is a big
reason IMO that CVE numbers have declined. Vulnerabilities "worth
tracking with a CVE" have declined, not the total number of
vulnerabilities. Another way to look at it might be that thee criteria
for "worth tracking with a CVE" has changed.
And we're not even talking about threat or asset values (both of which
have changed over time, and are different depending on your
site/assets), which influence risk. So a decrease in CVE IDs has little
directly to do with internet risk overall.
- Art
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Fri Mar 9 16:32:13 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q29LWDUx000843;
Fri, 9 Mar 2012 16:32:13 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 344A521B175D;
Fri, 9 Mar 2012 16:32:08 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 0E5E321B0488;
Fri, 9 Mar 2012 16:32:08 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 16:32:07 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4551400 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Fri, 9 Mar
2012 16:31:40 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Fri, 9 Mar 2012 16:31:40 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13249679; Fri, 09 Mar 2012 16:31:35 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 3F37B21B0401 for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Fri, 9 Mar 2012
16:31:35 -0500 (EST)
Received: from forced.attrition.org (forced.attrition.org [72.215.220.112]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id C548321B03AF for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Fri, 9 Mar 2012
16:31:33 -0500 (EST)
Received: by forced.attrition.org (Postfix, from userid 1000) id
C8AF1D918D; Fri, 9 Mar 2012 15:31:32 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by forced.attrition.org
(Postfix) with ESMTP id C7C78D9178 for
<cve-editorial-board-list@LISTS.MITRE.ORG>; Fri, 9 Mar 2012
15:31:32 -0600 (CST)
Date: Fri, 9 Mar 2012 15:31:32 -0600
From: security curmudgeon <jericho@attrition.org>
To: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
In-Reply-To: <4F591CCF.6050203@cert.org>
Message-ID: <alpine.LNX.2.00.1203091525440.7367@forced.attrition.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<5084579A0A81C947AB6E6BFB7AFCF9DF13DC66@IMCMBX02.MITRE.ORG>
<4F591CCF.6050203@cert.org>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
X-Attrition: Attrition is only good when forced. http://attrition.org
X-OSVDB: Everything is vulnerable. http://osvdb.org/
X-Message-Flag: WARNING: Over 100 published security vulnerabilities in
Microsoft Outlook!
X-Copyright: This e-mail copyright 2011 by jericho@attrition.org where
applicable
X-Encryption: rot26
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.9.211814
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0,
BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, NO_URI_FOUND 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__CS_PROD_FROM 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0,
__TO_MALFORMED_2 0, __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 2813
Status: R
X-Status:
X-Keywords:
On Thu, 8 Mar 2012, Art Manion wrote:
: The questions remain IMO:
:
: 1. What level of abstraction is appropriate for CVE?
Their current method of abstraction is appropriate. It is well defined and
consistent.
: 2. What level of completeness is appropriate for CVE?
I don't think "appropriate" is relevant. I think everyone wants it to be
"absolutely complete". For our business and research, that is the only
appropriate completeness.
: Is there desire/need for an accurate count of vulnerabilities? OSVDB
: either abstracts a little more narrowly than CVE and/or collects more
: vulnerabilities, so OSVDB has higher numbers.
OSVDB does both, but our abstraction is more than "a little more narrow".
We abstract per vulnerability, where CVE will group similiar. So take a
single CVE that lists 10 scripts vulnerable to SQL Injection, and we will
create 10 entries. OSVDB abstracts more than any other VDB, but as I said,
that is not always suitable depending on a person's needs.
: If CVE or any other database were to try to name and count all publicly
: disclosed vulnerabilities, it would be important to be able to
: distinguish between a vulnerability that is one of a dozen XSS bugs in a
: PHP web app and a vulnerability that is a straight up stack buffer
: overflow in httpd. Sure, count them all, but be able to say that out of
: 20K vulnerabilities named this year, 61% were XSS or SQLi in web apps
: with low distribution.
In theory, that is where CVSS (or another classification scheme) could
come in. Combined, that data could be used to pick out 'relevant' or
more critical issues.
: I'm guessing at some numbers in the above example, but this is a big
: reason IMO that CVE numbers have declined. Vulnerabilities "worth
: tracking with a CVE" have declined, not the total number of
: vulnerabilities. Another way to look at it might be that thee criteria
: for "worth tracking with a CVE" has changed.
Based on my chats with CVE, I don't think it is that. I don't believe they
shy away from an issue due to severity. I think that the issue is that CVE
monitors a list of sources for vulnerabilities, and their resources do not
permit them to look at more. For example, they monitor Bugtraq, but not
Full-Disclosure. Over the years, many researchers have started posting to
F-D without CCing Bugtraq (for a variety of reasons). Add to that sites
like Exploit-DB and other exploit aggregation sites that aren't being
monitored, and the numbers quickly explain themselves. OSVDB has a long
list, but we don't have the resources to monitor all of them in a timely
manner. We use a weighted system for checking them as time permits, so the
ones we consider critical (ICS-CERT) get hit daily, but a changelog or bug
tracker may get checked yearly at best.
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Fri Mar 9 17:07:36 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q29M7and001248
for <coley@RCF-SMTP.MITRE.ORG>; Fri, 9 Mar 2012 17:07:36 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 4D4C321B03E4;
Fri, 9 Mar 2012 17:07:31 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1D76D21B03A6;
Fri, 9 Mar 2012 17:07:31 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 17:07:30 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4551595 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Fri, 9 Mar
2012 17:07:23 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Fri, 9 Mar 2012 17:07:23 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13249766; Fri, 09 Mar 2012 17:07:09 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 0E33D21B0413 for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
17:07:09 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id D2FED21B0401 for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
17:07:08 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.106]) by IMCCAS01.MITRE.ORG
([129.83.29.78]) with mapi id 14.01.0339.001; Fri, 9 Mar 2012
17:07:08 -0500
From: "Mann, Dave" <damann@mitre.org>
To: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zABik+Bg
Date: Fri, 9 Mar 2012 22:07:08 +0000
Message-ID: <2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
In-Reply-To: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.83.31.55]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q29M7and001248
Content-Length: 6885
Status: R
X-Status:
X-Keywords:
Kent et al,
Summarizing my take on the situation...
0) People use vulnerability data for statistics at their own peril.
1) CVE cannot solve the global vulnerability reporting problem. We can be a part of the solution, but not *THE* solution.
2) To think clearly about the global vulnerability reporting problem and CVE, we need to think about "sources" of vulnerability disclosures and who is going to process which sources. The analogy here is: sources are to vulnerability reporting as jurisdictions are to law enforcement.
3) We, the CVE community, need to finish our discussion on which sources CVE will cover. And we will need to discuss how fast and how accurately those sources are covered.
4) Once we agree on which sources need to be covered, and how fast and how well, then we can talk about ways to close any gaps such as resources, process improvements, expanding the CNA process and crowd sourcing.
More verbose ramblings on these points follow...
1) GLOBAL VULNERABILITY REPORTING - In my opinion, one thing that CVE cannot do is solve the global vulnerability reporting problem. This was my position in the global vulnerability reporting discussions last fall and my convictions in this regard have only solidified based on discussions with Carsten at Secunia, more detailed discussions with the folks at JP-CERT and others in the international community. The sets of vendors/products in play are too different, the relationships between software vendors and various national governments are too different, and of course, the language barriers are too big. The discussions of the past 2 years on this subject have led me to conclude that when the CVE community set our goal of "all publicly known vulnerabilities" 12 years ago, we did so naively and with an incorrectly parochial view of the global software market. There may or may not be a good solution to the global vulnerability reporting problem. But one thing I'm very sure of is that this solution, if it exists, will need to evolve organically by knitting together various regional capabilities.
I think the best thing that we, the CVE community, can do to help facilitate the emergence of a global vulnerability reporting capability is to be able to speak clearly about what we can and can't do and to try to make as many of our lessons learned available to others as possible.
2) VULNERABILITY SOURCES - We've talked internally at great length on the subject of vendors, products and sources. We've also talked a bit about this as a Board. In my opinion, we'll drive ourselves bonkers if we talk about vendors and products.
The goal of law enforcement isn't to catch bad guys. It's to create and sustain a law enforcement system that can effectively catch bad guys. This is a critical distinction. The first results in cops with guns running around pursuing bad guys with no regard to coordination and jurisdictional boundaries. The latter takes seriously the idea of jurisdictional boundaries and uses this to create command and control systems to operate effectively within those boundaries.
In my opinion, we need to think in these terms regarding vulnerability reporting. The only somewhat stable structure I can see that does this for us to think in terms of "sources" of vulnerability information. So, instead of thinking about vendor X or the list of products produced by vendor X (all of the internationalized variants), we can talk about the English-based security bulletin web site run by vendor X. That web site can be on the list of sites tracked by CVE or not. The set of sources tracked by CVE become, effectively, CVE's jurisdiction. This is the discussion we, as a Board, started last fall.
I can hear the groans of complaint already. Vulnerabilities don't stay on a single set of sources. Absolutely true. In the same way, criminals don't stay in a single jurisdiction. But we can't organize a police force around a single type of criminal or a particular gang and I see no way to structure a CVE-like capability around a set of vendors or products. If other CVE-like capabilities emerge that can handle other sets of sources (different jurisdictions), I suggest we'll have to deal with vulnerabilities that cross jurisdictional boundaries in the same way that law enforcement types handle it.
If people can suggest other better ways to define jurisdictions (or swim lanes) I'm all ears.
3) CVE COVERAGE - This past fall, we had discussions on the Board list about what sources you all felt were "must-haves" and those you considered "nice-to-haves". We're processing this internally and are considering what sources we're actually covering, to what extent and how fast. We hope to present a summary of that in the next little while and I further expect that the summary will highlight some important gaps between our expectations and the realities. We'll have more to talk about at that point.
In preparation for that discussion, I'll quote the sign that hangs on Steve Christey's office door. Vulnerability IDs - Pick 2: Good, Fast, Cheap.
We'll need to talk about each of these dimensions more.
4) EVOLVING THE CVE PROCESS - The CVE ID assignment process has evolved over the past 12 years and will continue to evolve. Once we gain some clarity on which sources we need to cover, how well we need to cover them and at what we speed, we as a community can discuss what, if any, changes are required of the current CVE production process. I believe that everything can be put on the table for discussion at that point, but we really need to agree on the goals in terms coverage.
0) STATISTICS - Statistics require stable social categories and stable social categories require stable shared practices. I'm not going to shock anybody by suggesting that security practices in general, and vulnerability practices in particular are not stable. In short, our field is too young.
The best book on the subject that I know is "Standards and Their Stories: How Quantifying, Classifying, and Formalizing Practices Shape Everyday Life" by Lampland and Star. The discussion of how "calendar age" became a standard in everyday life and how the age classification processes of the US census bureau evolved is particularly germane to the question of vulnerability statistics.
I have no idea how to communicate this sort of troubling truth to upper management types but strongly suggest the book to everyone on this list. You can thank or blame TK when you see him next. He's the one who suggested it to me. ;)
-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:damann@mitre.org | cell:781.424.6003
==================================================================
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Fri Mar 9 17:28:53 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q29MSqAZ001449;
Fri, 9 Mar 2012 17:28:52 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 5729E21B042E;
Fri, 9 Mar 2012 17:28:47 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1E42D21B0414;
Fri, 9 Mar 2012 17:28:47 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 17:28:46 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4551694 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Fri, 9 Mar
2012 17:28:10 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Fri, 9 Mar 2012 17:28:10 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13249812; Fri, 09 Mar 2012 17:28:03 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id ADCC121B03BC for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
17:28:03 -0500 (EST)
Received: from guardian.stonekeep.com (guardian.stonekeep.com [96.39.62.68])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 21D1221B042E for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
17:28:03 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by guardian.stonekeep.com
(Postfix) with ESMTP id CA995990179; Fri, 9 Mar 2012 17:28:02 -0500
(EST)
Received: from guardian.stonekeep.com ([127.0.0.1]) by localhost
(guardian.stonekeep.com [127.0.0.1]) (amavisd-new, port
10024) with ESMTP id mOhxqGbccHMK; Fri, 9 Mar 2012 17:28:01 -0500
(EST)
Received: from boomer.homeport.org (boomer [172.16.1.2]) by
guardian.stonekeep.com (Postfix) with ESMTP id 7F60F99016C; Fri, 9
Mar 2012 17:28:01 -0500 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by
boomer.homeport.org (Postfix) with ESMTP id 61816911C2; Fri, 9 Mar
2012 17:28:01 -0500 (EST)
Received: from boomer.homeport.org ([127.0.0.1]) by localhost
(boomer.homeport.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3V4JzgSEaSMY; Fri, 9 Mar 2012 17:27:59 -0500 (EST)
Received: by boomer.homeport.org (Postfix, from userid 125) id E6D76911C1;
Fri, 9 Mar 2012 17:27:59 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at guardian.stonekeep.com
X-Virus-Scanned: Debian amavisd-new at homeport.org - Happy Homeport Admins
Date: Fri, 9 Mar 2012 17:27:59 -0500
From: Adam Shostack <adam@homeport.org>
To: "Mann, Dave" <damann@mitre.org>
CC: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
Message-ID: <20120309222759.GB21988@homeport.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.9.221817
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, SUPERLONG_LINE 0.05, DATE_TZ_NA 0,
DATE_TZ_NEG_0500 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CD 0,
__CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__INT_PROD_LOC 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0,
__URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q29MSqAZ001449
Content-Length: 8143
Status:
X-Status:
X-Keywords:
Dave (and all),
First, I'd like to suggest that these issues are complex, and require
more than the high-interrupt, delve-in-as-you-can attention that email
can bring. (I've had two people walk into my office as I type this.)
So I think the board should meet in person (unfortunately, we just
missed RSA as an opportunity) or with a monthly call with agendas to
work through some of these questions. I think that email is too
narrow a mechanism for the issues.
Also, I'd like to respond to one of the things you say below:
> I think the best thing that we, the CVE community, can do to help
> facilitate the emergence of a global vulnerability reporting
> capability is to be able to speak clearly about what we can and
> can't do and to try to make as many of our lessons learned available
> to others as possible
I think we should also talk about the goals and uses that CVE
addresses, and reinforce the value to defenders of having the
concordance functions. The reason that there's tension is that
there's value, and we should look for ways to make those explicit.
Adam
On Fri, Mar 09, 2012 at 10:07:08PM +0000, Mann, Dave wrote:
| Kent et al,
|
| Summarizing my take on the situation...
|
| 0) People use vulnerability data for statistics at their own peril.
|
| 1) CVE cannot solve the global vulnerability reporting problem. We can be a part of the solution, but not *THE* solution.
|
| 2) To think clearly about the global vulnerability reporting problem and CVE, we need to think about "sources" of vulnerability disclosures and who is going to process which sources. The analogy here is: sources are to vulnerability reporting as jurisdictions are to law enforcement.
|
| 3) We, the CVE community, need to finish our discussion on which sources CVE will cover. And we will need to discuss how fast and how accurately those sources are covered.
|
| 4) Once we agree on which sources need to be covered, and how fast and how well, then we can talk about ways to close any gaps such as resources, process improvements, expanding the CNA process and crowd sourcing.
|
|
| More verbose ramblings on these points follow...
|
|
| 1) GLOBAL VULNERABILITY REPORTING - In my opinion, one thing that CVE cannot do is solve the global vulnerability reporting problem. This was my position in the global vulnerability reporting discussions last fall and my convictions in this regard have only solidified based on discussions with Carsten at Secunia, more detailed discussions with the folks at JP-CERT and others in the international community. The sets of vendors/products in play are too different, the relationships between software vendors and various national governments are too different, and of course, the language barriers are too big. The discussions of the past 2 years on this subject have led me to conclude that when the CVE community set our goal of "all publicly known vulnerabilities" 12 years ago, we did so naively and with an incorrectly parochial view of the global software market. There may or may not be a good solution to the global vulnerability reporting problem. But one thing I'm very sure of is that this solution, if it exists, will need to evolve organically by knitting together various regional capabilities.
|
| I think the best thing that we, the CVE community, can do to help facilitate the emergence of a global vulnerability reporting capability is to be able to speak clearly about what we can and can't do and to try to make as many of our lessons learned available to others as possible.
|
|
|
| 2) VULNERABILITY SOURCES - We've talked internally at great length on the subject of vendors, products and sources. We've also talked a bit about this as a Board. In my opinion, we'll drive ourselves bonkers if we talk about vendors and products.
|
| The goal of law enforcement isn't to catch bad guys. It's to create and sustain a law enforcement system that can effectively catch bad guys. This is a critical distinction. The first results in cops with guns running around pursuing bad guys with no regard to coordination and jurisdictional boundaries. The latter takes seriously the idea of jurisdictional boundaries and uses this to create command and control systems to operate effectively within those boundaries.
|
| In my opinion, we need to think in these terms regarding vulnerability reporting. The only somewhat stable structure I can see that does this for us to think in terms of "sources" of vulnerability information. So, instead of thinking about vendor X or the list of products produced by vendor X (all of the internationalized variants), we can talk about the English-based security bulletin web site run by vendor X. That web site can be on the list of sites tracked by CVE or not. The set of sources tracked by CVE become, effectively, CVE's jurisdiction. This is the discussion we, as a Board, started last fall.
|
| I can hear the groans of complaint already. Vulnerabilities don't stay on a single set of sources. Absolutely true. In the same way, criminals don't stay in a single jurisdiction. But we can't organize a police force around a single type of criminal or a particular gang and I see no way to structure a CVE-like capability around a set of vendors or products. If other CVE-like capabilities emerge that can handle other sets of sources (different jurisdictions), I suggest we'll have to deal with vulnerabilities that cross jurisdictional boundaries in the same way that law enforcement types handle it.
|
| If people can suggest other better ways to define jurisdictions (or swim lanes) I'm all ears.
|
|
| 3) CVE COVERAGE - This past fall, we had discussions on the Board list about what sources you all felt were "must-haves" and those you considered "nice-to-haves". We're processing this internally and are considering what sources we're actually covering, to what extent and how fast. We hope to present a summary of that in the next little while and I further expect that the summary will highlight some important gaps between our expectations and the realities. We'll have more to talk about at that point.
|
| In preparation for that discussion, I'll quote the sign that hangs on Steve Christey's office door. Vulnerability IDs - Pick 2: Good, Fast, Cheap.
|
| We'll need to talk about each of these dimensions more.
|
|
| 4) EVOLVING THE CVE PROCESS - The CVE ID assignment process has evolved over the past 12 years and will continue to evolve. Once we gain some clarity on which sources we need to cover, how well we need to cover them and at what we speed, we as a community can discuss what, if any, changes are required of the current CVE production process. I believe that everything can be put on the table for discussion at that point, but we really need to agree on the goals in terms coverage.
|
|
| 0) STATISTICS - Statistics require stable social categories and stable social categories require stable shared practices. I'm not going to shock anybody by suggesting that security practices in general, and vulnerability practices in particular are not stable. In short, our field is too young.
|
| The best book on the subject that I know is "Standards and Their Stories: How Quantifying, Classifying, and Formalizing Practices Shape Everyday Life" by Lampland and Star. The discussion of how "calendar age" became a standard in everyday life and how the age classification processes of the US census bureau evolved is particularly germane to the question of vulnerability statistics.
|
| I have no idea how to communicate this sort of troubling truth to upper management types but strongly suggest the book to everyone on this list. You can thank or blame TK when you see him next. He's the one who suggested it to me. ;)
|
|
| -Dave
| ==================================================================
| David Mann | Principal Infosec Scientist | The MITRE Corporation
| ------------------------------------------------------------------
| e-mail:damann@mitre.org | cell:781.424.6003
| ==================================================================
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Fri Mar 9 17:28:53 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q29MSqmD001450
for <coley@RCF-SMTP.MITRE.ORG>; Fri, 9 Mar 2012 17:28:52 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 5729E21B042E;
Fri, 9 Mar 2012 17:28:47 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 1E42D21B0414;
Fri, 9 Mar 2012 17:28:47 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 17:28:46 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4551694 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Fri, 9 Mar
2012 17:28:10 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Fri, 9 Mar 2012 17:28:10 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13249812; Fri, 09 Mar 2012 17:28:03 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id ADCC121B03BC for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
17:28:03 -0500 (EST)
Received: from guardian.stonekeep.com (guardian.stonekeep.com [96.39.62.68])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 21D1221B042E for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
17:28:03 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by guardian.stonekeep.com
(Postfix) with ESMTP id CA995990179; Fri, 9 Mar 2012 17:28:02 -0500
(EST)
Received: from guardian.stonekeep.com ([127.0.0.1]) by localhost
(guardian.stonekeep.com [127.0.0.1]) (amavisd-new, port
10024) with ESMTP id mOhxqGbccHMK; Fri, 9 Mar 2012 17:28:01 -0500
(EST)
Received: from boomer.homeport.org (boomer [172.16.1.2]) by
guardian.stonekeep.com (Postfix) with ESMTP id 7F60F99016C; Fri, 9
Mar 2012 17:28:01 -0500 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by
boomer.homeport.org (Postfix) with ESMTP id 61816911C2; Fri, 9 Mar
2012 17:28:01 -0500 (EST)
Received: from boomer.homeport.org ([127.0.0.1]) by localhost
(boomer.homeport.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3V4JzgSEaSMY; Fri, 9 Mar 2012 17:27:59 -0500 (EST)
Received: by boomer.homeport.org (Postfix, from userid 125) id E6D76911C1;
Fri, 9 Mar 2012 17:27:59 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at guardian.stonekeep.com
X-Virus-Scanned: Debian amavisd-new at homeport.org - Happy Homeport Admins
Date: Fri, 9 Mar 2012 17:27:59 -0500
From: Adam Shostack <adam@homeport.org>
To: "Mann, Dave" <damann@mitre.org>
CC: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: Re: Counting on CVEs
Message-ID: <20120309222759.GB21988@homeport.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.9.221817
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, SUPERLONG_LINE 0.05, DATE_TZ_NA 0,
DATE_TZ_NEG_0500 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CD 0,
__CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__INT_PROD_LOC 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0,
__URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q29MSqmD001450
Content-Length: 8143
Status:
X-Status:
X-Keywords:
Dave (and all),
First, I'd like to suggest that these issues are complex, and require
more than the high-interrupt, delve-in-as-you-can attention that email
can bring. (I've had two people walk into my office as I type this.)
So I think the board should meet in person (unfortunately, we just
missed RSA as an opportunity) or with a monthly call with agendas to
work through some of these questions. I think that email is too
narrow a mechanism for the issues.
Also, I'd like to respond to one of the things you say below:
> I think the best thing that we, the CVE community, can do to help
> facilitate the emergence of a global vulnerability reporting
> capability is to be able to speak clearly about what we can and
> can't do and to try to make as many of our lessons learned available
> to others as possible
I think we should also talk about the goals and uses that CVE
addresses, and reinforce the value to defenders of having the
concordance functions. The reason that there's tension is that
there's value, and we should look for ways to make those explicit.
Adam
On Fri, Mar 09, 2012 at 10:07:08PM +0000, Mann, Dave wrote:
| Kent et al,
|
| Summarizing my take on the situation...
|
| 0) People use vulnerability data for statistics at their own peril.
|
| 1) CVE cannot solve the global vulnerability reporting problem. We can be a part of the solution, but not *THE* solution.
|
| 2) To think clearly about the global vulnerability reporting problem and CVE, we need to think about "sources" of vulnerability disclosures and who is going to process which sources. The analogy here is: sources are to vulnerability reporting as jurisdictions are to law enforcement.
|
| 3) We, the CVE community, need to finish our discussion on which sources CVE will cover. And we will need to discuss how fast and how accurately those sources are covered.
|
| 4) Once we agree on which sources need to be covered, and how fast and how well, then we can talk about ways to close any gaps such as resources, process improvements, expanding the CNA process and crowd sourcing.
|
|
| More verbose ramblings on these points follow...
|
|
| 1) GLOBAL VULNERABILITY REPORTING - In my opinion, one thing that CVE cannot do is solve the global vulnerability reporting problem. This was my position in the global vulnerability reporting discussions last fall and my convictions in this regard have only solidified based on discussions with Carsten at Secunia, more detailed discussions with the folks at JP-CERT and others in the international community. The sets of vendors/products in play are too different, the relationships between software vendors and various national governments are too different, and of course, the language barriers are too big. The discussions of the past 2 years on this subject have led me to conclude that when the CVE community set our goal of "all publicly known vulnerabilities" 12 years ago, we did so naively and with an incorrectly parochial view of the global software market. There may or may not be a good solution to the global vulnerability reporting problem. But one thing I'm very sure of is that this solution, if it exists, will need to evolve organically by knitting together various regional capabilities.
|
| I think the best thing that we, the CVE community, can do to help facilitate the emergence of a global vulnerability reporting capability is to be able to speak clearly about what we can and can't do and to try to make as many of our lessons learned available to others as possible.
|
|
|
| 2) VULNERABILITY SOURCES - We've talked internally at great length on the subject of vendors, products and sources. We've also talked a bit about this as a Board. In my opinion, we'll drive ourselves bonkers if we talk about vendors and products.
|
| The goal of law enforcement isn't to catch bad guys. It's to create and sustain a law enforcement system that can effectively catch bad guys. This is a critical distinction. The first results in cops with guns running around pursuing bad guys with no regard to coordination and jurisdictional boundaries. The latter takes seriously the idea of jurisdictional boundaries and uses this to create command and control systems to operate effectively within those boundaries.
|
| In my opinion, we need to think in these terms regarding vulnerability reporting. The only somewhat stable structure I can see that does this for us to think in terms of "sources" of vulnerability information. So, instead of thinking about vendor X or the list of products produced by vendor X (all of the internationalized variants), we can talk about the English-based security bulletin web site run by vendor X. That web site can be on the list of sites tracked by CVE or not. The set of sources tracked by CVE become, effectively, CVE's jurisdiction. This is the discussion we, as a Board, started last fall.
|
| I can hear the groans of complaint already. Vulnerabilities don't stay on a single set of sources. Absolutely true. In the same way, criminals don't stay in a single jurisdiction. But we can't organize a police force around a single type of criminal or a particular gang and I see no way to structure a CVE-like capability around a set of vendors or products. If other CVE-like capabilities emerge that can handle other sets of sources (different jurisdictions), I suggest we'll have to deal with vulnerabilities that cross jurisdictional boundaries in the same way that law enforcement types handle it.
|
| If people can suggest other better ways to define jurisdictions (or swim lanes) I'm all ears.
|
|
| 3) CVE COVERAGE - This past fall, we had discussions on the Board list about what sources you all felt were "must-haves" and those you considered "nice-to-haves". We're processing this internally and are considering what sources we're actually covering, to what extent and how fast. We hope to present a summary of that in the next little while and I further expect that the summary will highlight some important gaps between our expectations and the realities. We'll have more to talk about at that point.
|
| In preparation for that discussion, I'll quote the sign that hangs on Steve Christey's office door. Vulnerability IDs - Pick 2: Good, Fast, Cheap.
|
| We'll need to talk about each of these dimensions more.
|
|
| 4) EVOLVING THE CVE PROCESS - The CVE ID assignment process has evolved over the past 12 years and will continue to evolve. Once we gain some clarity on which sources we need to cover, how well we need to cover them and at what we speed, we as a community can discuss what, if any, changes are required of the current CVE production process. I believe that everything can be put on the table for discussion at that point, but we really need to agree on the goals in terms coverage.
|
|
| 0) STATISTICS - Statistics require stable social categories and stable social categories require stable shared practices. I'm not going to shock anybody by suggesting that security practices in general, and vulnerability practices in particular are not stable. In short, our field is too young.
|
| The best book on the subject that I know is "Standards and Their Stories: How Quantifying, Classifying, and Formalizing Practices Shape Everyday Life" by Lampland and Star. The discussion of how "calendar age" became a standard in everyday life and how the age classification processes of the US census bureau evolved is particularly germane to the question of vulnerability statistics.
|
| I have no idea how to communicate this sort of troubling truth to upper management types but strongly suggest the book to everyone on this list. You can thank or blame TK when you see him next. He's the one who suggested it to me. ;)
|
|
| -Dave
| ==================================================================
| David Mann | Principal Infosec Scientist | The MITRE Corporation
| ------------------------------------------------------------------
| e-mail:damann@mitre.org | cell:781.424.6003
| ==================================================================
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Fri Mar 9 19:16:14 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q2A0GCHw002732
for <coley@RCF-SMTP.MITRE.ORG>; Fri, 9 Mar 2012 19:16:12 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id B0DE121B04BF;
Fri, 9 Mar 2012 19:16:07 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 9305821B04D6;
Fri, 9 Mar 2012 19:16:07 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 19:16:07 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4552085 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Fri, 9 Mar
2012 19:15:25 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Fri, 9 Mar 2012 19:15:25 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13249976; Fri, 09 Mar 2012 19:15:15 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 72F3A21B04BF for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
19:15:15 -0500 (EST)
Received: from Crappie.rc.on.ca (unknown [207.176.151.2]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 4815921B04E0 for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
19:15:10 -0500 (EST)
Received: from Sunfish.rc.on.ca (207.176.151.130) by Crappie.rc.on.ca
(207.176.151.10) with Microsoft SMTP Server (TLS) id 14.0.722.0;
Fri, 9 Mar 2012 19:15:03 -0500
Received: from Sunfish.rc.on.ca ([fe80::b9b7:df1e:3af9:3ad3]) by
Sunfish.rc.on.ca ([fe80::b9b7:df1e:3af9:3ad3%16]) with mapi; Fri, 9
Mar 2012 19:15:03 -0500
From: Russ Cooper <Russ.Cooper@rc.on.ca>
To: Adam Shostack <adam@homeport.org>, "Mann, Dave" <damann@mitre.org>
CC: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zABik+BgABHq4IAABymxcA==
Date: Sat, 10 Mar 2012 00:15:01 +0000
Message-ID: <A27B80707A1E924891446594C00EBA8C52B24B79@Sunfish.rc.on.ca>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
<20120309222759.GB21988@homeport.org>
In-Reply-To: <20120309222759.GB21988@homeport.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.10.323
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0,
RDNS_SERVFAIL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CP_NOT_1 0,
__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__IMS_MSGID 0, __INT_PROD_LOC 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0,
__URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS '
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q2A0GCHw002732
Content-Length: 9540
Status:
X-Status:
X-Keywords:
I never thought CVE would ever be used as intended. As I remember it, it was intended to get all "vendors" to call a spade a spade. If it worked, U.S gov't would be able to look at a spade called fifteen different things as a single issue, and in so doing, save a lot of money/resources/time.
There has, unfortunately, always been one insurmountable problem...my spade is better than your spade. Which, unfortunately, isn't simply a matter of detection. Seeing as a "spade" means a lot of different things, and vendors differentiate themselves on what they can do with the same CVE, is it not reasonable to understand that CVE has actually been counter-productive to its original intent?
To put it more succinctly, government wanted every vendor see report the same issues, but in enumerating those issue they forced vendors to do more with them.
When the "E" in CVE meant "Enumeration" there was a goal which government would benefit from. If it's not about coming up with a finite list of issues that need to be considered or tested, the I wonder why Government cares, or will pay for insight into...
Cheers,
Russ
-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Adam Shostack
Sent: Friday, March 09, 2012 5:28 PM
To: Mann, Dave
Cc: cve-editorial-board-list
Subject: Re: Counting on CVEs
Dave (and all),
First, I'd like to suggest that these issues are complex, and require
more than the high-interrupt, delve-in-as-you-can attention that email
can bring. (I've had two people walk into my office as I type this.)
So I think the board should meet in person (unfortunately, we just
missed RSA as an opportunity) or with a monthly call with agendas to
work through some of these questions. I think that email is too
narrow a mechanism for the issues.
Also, I'd like to respond to one of the things you say below:
> I think the best thing that we, the CVE community, can do to help
> facilitate the emergence of a global vulnerability reporting
> capability is to be able to speak clearly about what we can and
> can't do and to try to make as many of our lessons learned available
> to others as possible
I think we should also talk about the goals and uses that CVE
addresses, and reinforce the value to defenders of having the
concordance functions. The reason that there's tension is that
there's value, and we should look for ways to make those explicit.
Adam
On Fri, Mar 09, 2012 at 10:07:08PM +0000, Mann, Dave wrote:
| Kent et al,
|
| Summarizing my take on the situation...
|
| 0) People use vulnerability data for statistics at their own peril.
|
| 1) CVE cannot solve the global vulnerability reporting problem. We can be a part of the solution, but not *THE* solution.
|
| 2) To think clearly about the global vulnerability reporting problem and CVE, we need to think about "sources" of vulnerability disclosures and who is going to process which sources. The analogy here is: sources are to vulnerability reporting as jurisdictions are to law enforcement.
|
| 3) We, the CVE community, need to finish our discussion on which sources CVE will cover. And we will need to discuss how fast and how accurately those sources are covered.
|
| 4) Once we agree on which sources need to be covered, and how fast and how well, then we can talk about ways to close any gaps such as resources, process improvements, expanding the CNA process and crowd sourcing.
|
|
| More verbose ramblings on these points follow...
|
|
| 1) GLOBAL VULNERABILITY REPORTING - In my opinion, one thing that CVE cannot do is solve the global vulnerability reporting problem. This was my position in the global vulnerability reporting discussions last fall and my convictions in this regard have only solidified based on discussions with Carsten at Secunia, more detailed discussions with the folks at JP-CERT and others in the international community. The sets of vendors/products in play are too different, the relationships between software vendors and various national governments are too different, and of course, the language barriers are too big. The discussions of the past 2 years on this subject have led me to conclude that when the CVE community set our goal of "all publicly known vulnerabilities" 12 years ago, we did so naively and with an incorrectly parochial view of the global software market. There may or may not be a good solution to the global vulnerability reporting problem. But one thing I'm very sure of is that this solution, if it exists, will need to evolve organically by knitting together various regional capabilities.
|
| I think the best thing that we, the CVE community, can do to help facilitate the emergence of a global vulnerability reporting capability is to be able to speak clearly about what we can and can't do and to try to make as many of our lessons learned available to others as possible.
|
|
|
| 2) VULNERABILITY SOURCES - We've talked internally at great length on the subject of vendors, products and sources. We've also talked a bit about this as a Board. In my opinion, we'll drive ourselves bonkers if we talk about vendors and products.
|
| The goal of law enforcement isn't to catch bad guys. It's to create and sustain a law enforcement system that can effectively catch bad guys. This is a critical distinction. The first results in cops with guns running around pursuing bad guys with no regard to coordination and jurisdictional boundaries. The latter takes seriously the idea of jurisdictional boundaries and uses this to create command and control systems to operate effectively within those boundaries.
|
| In my opinion, we need to think in these terms regarding vulnerability reporting. The only somewhat stable structure I can see that does this for us to think in terms of "sources" of vulnerability information. So, instead of thinking about vendor X or the list of products produced by vendor X (all of the internationalized variants), we can talk about the English-based security bulletin web site run by vendor X. That web site can be on the list of sites tracked by CVE or not. The set of sources tracked by CVE become, effectively, CVE's jurisdiction. This is the discussion we, as a Board, started last fall.
|
| I can hear the groans of complaint already. Vulnerabilities don't stay on a single set of sources. Absolutely true. In the same way, criminals don't stay in a single jurisdiction. But we can't organize a police force around a single type of criminal or a particular gang and I see no way to structure a CVE-like capability around a set of vendors or products. If other CVE-like capabilities emerge that can handle other sets of sources (different jurisdictions), I suggest we'll have to deal with vulnerabilities that cross jurisdictional boundaries in the same way that law enforcement types handle it.
|
| If people can suggest other better ways to define jurisdictions (or swim lanes) I'm all ears.
|
|
| 3) CVE COVERAGE - This past fall, we had discussions on the Board list about what sources you all felt were "must-haves" and those you considered "nice-to-haves". We're processing this internally and are considering what sources we're actually covering, to what extent and how fast. We hope to present a summary of that in the next little while and I further expect that the summary will highlight some important gaps between our expectations and the realities. We'll have more to talk about at that point.
|
| In preparation for that discussion, I'll quote the sign that hangs on Steve Christey's office door. Vulnerability IDs - Pick 2: Good, Fast, Cheap.
|
| We'll need to talk about each of these dimensions more.
|
|
| 4) EVOLVING THE CVE PROCESS - The CVE ID assignment process has evolved over the past 12 years and will continue to evolve. Once we gain some clarity on which sources we need to cover, how well we need to cover them and at what we speed, we as a community can discuss what, if any, changes are required of the current CVE production process. I believe that everything can be put on the table for discussion at that point, but we really need to agree on the goals in terms coverage.
|
|
| 0) STATISTICS - Statistics require stable social categories and stable social categories require stable shared practices. I'm not going to shock anybody by suggesting that security practices in general, and vulnerability practices in particular are not stable. In short, our field is too young.
|
| The best book on the subject that I know is "Standards and Their Stories: How Quantifying, Classifying, and Formalizing Practices Shape Everyday Life" by Lampland and Star. The discussion of how "calendar age" became a standard in everyday life and how the age classification processes of the US census bureau evolved is particularly germane to the question of vulnerability statistics.
|
| I have no idea how to communicate this sort of troubling truth to upper management types but strongly suggest the book to everyone on this list. You can thank or blame TK when you see him next. He's the one who suggested it to me. ;)
|
|
| -Dave
| ==================================================================
| David Mann | Principal Infosec Scientist | The MITRE Corporation
| ------------------------------------------------------------------
| e-mail:damann@mitre.org | cell:781.424.6003
| ==================================================================
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Fri Mar 9 19:16:14 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q2A0GCjY002731;
Fri, 9 Mar 2012 19:16:12 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id B0DE121B04BF;
Fri, 9 Mar 2012 19:16:07 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id 9305821B04D6;
Fri, 9 Mar 2012 19:16:07 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 19:16:07 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4552085 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Fri, 9 Mar
2012 19:15:25 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Fri, 9 Mar 2012 19:15:25 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13249976; Fri, 09 Mar 2012 19:15:15 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 72F3A21B04BF for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
19:15:15 -0500 (EST)
Received: from Crappie.rc.on.ca (unknown [207.176.151.2]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 4815921B04E0 for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
19:15:10 -0500 (EST)
Received: from Sunfish.rc.on.ca (207.176.151.130) by Crappie.rc.on.ca
(207.176.151.10) with Microsoft SMTP Server (TLS) id 14.0.722.0;
Fri, 9 Mar 2012 19:15:03 -0500
Received: from Sunfish.rc.on.ca ([fe80::b9b7:df1e:3af9:3ad3]) by
Sunfish.rc.on.ca ([fe80::b9b7:df1e:3af9:3ad3%16]) with mapi; Fri, 9
Mar 2012 19:15:03 -0500
From: Russ Cooper <Russ.Cooper@rc.on.ca>
To: Adam Shostack <adam@homeport.org>, "Mann, Dave" <damann@mitre.org>
CC: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
Thread-Topic: Counting on CVEs
Thread-Index: Acz8m8+LlLUxyYyKRByHw3mzYu98zABik+BgABHq4IAABymxcA==
Date: Sat, 10 Mar 2012 00:15:01 +0000
Message-ID: <A27B80707A1E924891446594C00EBA8C52B24B79@Sunfish.rc.on.ca>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
<20120309222759.GB21988@homeport.org>
In-Reply-To: <20120309222759.GB21988@homeport.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.10.323
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0,
RDNS_SERVFAIL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CP_NOT_1 0,
__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0,
__IMS_MSGID 0, __INT_PROD_LOC 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0,
__URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS '
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by linus.mitre.org id q2A0GCjY002731
Content-Length: 9540
Status:
X-Status:
X-Keywords:
I never thought CVE would ever be used as intended. As I remember it, it was intended to get all "vendors" to call a spade a spade. If it worked, U.S gov't would be able to look at a spade called fifteen different things as a single issue, and in so doing, save a lot of money/resources/time.
There has, unfortunately, always been one insurmountable problem...my spade is better than your spade. Which, unfortunately, isn't simply a matter of detection. Seeing as a "spade" means a lot of different things, and vendors differentiate themselves on what they can do with the same CVE, is it not reasonable to understand that CVE has actually been counter-productive to its original intent?
To put it more succinctly, government wanted every vendor see report the same issues, but in enumerating those issue they forced vendors to do more with them.
When the "E" in CVE meant "Enumeration" there was a goal which government would benefit from. If it's not about coming up with a finite list of issues that need to be considered or tested, the I wonder why Government cares, or will pay for insight into...
Cheers,
Russ
-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Adam Shostack
Sent: Friday, March 09, 2012 5:28 PM
To: Mann, Dave
Cc: cve-editorial-board-list
Subject: Re: Counting on CVEs
Dave (and all),
First, I'd like to suggest that these issues are complex, and require
more than the high-interrupt, delve-in-as-you-can attention that email
can bring. (I've had two people walk into my office as I type this.)
So I think the board should meet in person (unfortunately, we just
missed RSA as an opportunity) or with a monthly call with agendas to
work through some of these questions. I think that email is too
narrow a mechanism for the issues.
Also, I'd like to respond to one of the things you say below:
> I think the best thing that we, the CVE community, can do to help
> facilitate the emergence of a global vulnerability reporting
> capability is to be able to speak clearly about what we can and
> can't do and to try to make as many of our lessons learned available
> to others as possible
I think we should also talk about the goals and uses that CVE
addresses, and reinforce the value to defenders of having the
concordance functions. The reason that there's tension is that
there's value, and we should look for ways to make those explicit.
Adam
On Fri, Mar 09, 2012 at 10:07:08PM +0000, Mann, Dave wrote:
| Kent et al,
|
| Summarizing my take on the situation...
|
| 0) People use vulnerability data for statistics at their own peril.
|
| 1) CVE cannot solve the global vulnerability reporting problem. We can be a part of the solution, but not *THE* solution.
|
| 2) To think clearly about the global vulnerability reporting problem and CVE, we need to think about "sources" of vulnerability disclosures and who is going to process which sources. The analogy here is: sources are to vulnerability reporting as jurisdictions are to law enforcement.
|
| 3) We, the CVE community, need to finish our discussion on which sources CVE will cover. And we will need to discuss how fast and how accurately those sources are covered.
|
| 4) Once we agree on which sources need to be covered, and how fast and how well, then we can talk about ways to close any gaps such as resources, process improvements, expanding the CNA process and crowd sourcing.
|
|
| More verbose ramblings on these points follow...
|
|
| 1) GLOBAL VULNERABILITY REPORTING - In my opinion, one thing that CVE cannot do is solve the global vulnerability reporting problem. This was my position in the global vulnerability reporting discussions last fall and my convictions in this regard have only solidified based on discussions with Carsten at Secunia, more detailed discussions with the folks at JP-CERT and others in the international community. The sets of vendors/products in play are too different, the relationships between software vendors and various national governments are too different, and of course, the language barriers are too big. The discussions of the past 2 years on this subject have led me to conclude that when the CVE community set our goal of "all publicly known vulnerabilities" 12 years ago, we did so naively and with an incorrectly parochial view of the global software market. There may or may not be a good solution to the global vulnerability reporting problem. But one thing I'm very sure of is that this solution, if it exists, will need to evolve organically by knitting together various regional capabilities.
|
| I think the best thing that we, the CVE community, can do to help facilitate the emergence of a global vulnerability reporting capability is to be able to speak clearly about what we can and can't do and to try to make as many of our lessons learned available to others as possible.
|
|
|
| 2) VULNERABILITY SOURCES - We've talked internally at great length on the subject of vendors, products and sources. We've also talked a bit about this as a Board. In my opinion, we'll drive ourselves bonkers if we talk about vendors and products.
|
| The goal of law enforcement isn't to catch bad guys. It's to create and sustain a law enforcement system that can effectively catch bad guys. This is a critical distinction. The first results in cops with guns running around pursuing bad guys with no regard to coordination and jurisdictional boundaries. The latter takes seriously the idea of jurisdictional boundaries and uses this to create command and control systems to operate effectively within those boundaries.
|
| In my opinion, we need to think in these terms regarding vulnerability reporting. The only somewhat stable structure I can see that does this for us to think in terms of "sources" of vulnerability information. So, instead of thinking about vendor X or the list of products produced by vendor X (all of the internationalized variants), we can talk about the English-based security bulletin web site run by vendor X. That web site can be on the list of sites tracked by CVE or not. The set of sources tracked by CVE become, effectively, CVE's jurisdiction. This is the discussion we, as a Board, started last fall.
|
| I can hear the groans of complaint already. Vulnerabilities don't stay on a single set of sources. Absolutely true. In the same way, criminals don't stay in a single jurisdiction. But we can't organize a police force around a single type of criminal or a particular gang and I see no way to structure a CVE-like capability around a set of vendors or products. If other CVE-like capabilities emerge that can handle other sets of sources (different jurisdictions), I suggest we'll have to deal with vulnerabilities that cross jurisdictional boundaries in the same way that law enforcement types handle it.
|
| If people can suggest other better ways to define jurisdictions (or swim lanes) I'm all ears.
|
|
| 3) CVE COVERAGE - This past fall, we had discussions on the Board list about what sources you all felt were "must-haves" and those you considered "nice-to-haves". We're processing this internally and are considering what sources we're actually covering, to what extent and how fast. We hope to present a summary of that in the next little while and I further expect that the summary will highlight some important gaps between our expectations and the realities. We'll have more to talk about at that point.
|
| In preparation for that discussion, I'll quote the sign that hangs on Steve Christey's office door. Vulnerability IDs - Pick 2: Good, Fast, Cheap.
|
| We'll need to talk about each of these dimensions more.
|
|
| 4) EVOLVING THE CVE PROCESS - The CVE ID assignment process has evolved over the past 12 years and will continue to evolve. Once we gain some clarity on which sources we need to cover, how well we need to cover them and at what we speed, we as a community can discuss what, if any, changes are required of the current CVE production process. I believe that everything can be put on the table for discussion at that point, but we really need to agree on the goals in terms coverage.
|
|
| 0) STATISTICS - Statistics require stable social categories and stable social categories require stable shared practices. I'm not going to shock anybody by suggesting that security practices in general, and vulnerability practices in particular are not stable. In short, our field is too young.
|
| The best book on the subject that I know is "Standards and Their Stories: How Quantifying, Classifying, and Formalizing Practices Shape Everyday Life" by Lampland and Star. The discussion of how "calendar age" became a standard in everyday life and how the age classification processes of the US census bureau evolved is particularly germane to the question of vulnerability statistics.
|
| I have no idea how to communicate this sort of troubling truth to upper management types but strongly suggest the book to everyone on this list. You can thank or blame TK when you see him next. He's the one who suggested it to me. ;)
|
|
| -Dave
| ==================================================================
| David Mann | Principal Infosec Scientist | The MITRE Corporation
| ------------------------------------------------------------------
| e-mail:damann@mitre.org | cell:781.424.6003
| ==================================================================
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Fri Mar 9 21:52:22 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q2A2qMx8004182
for <coley@RCF-SMTP.MITRE.ORG>; Fri, 9 Mar 2012 21:52:22 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id D8F1021B05CD;
Fri, 9 Mar 2012 21:52:16 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id B65A121B05A4;
Fri, 9 Mar 2012 21:52:16 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 21:52:16 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4552614 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Fri, 9 Mar
2012 21:51:34 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Fri, 9 Mar 2012 21:51:34 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13250225; Fri, 09 Mar 2012 21:51:23 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 0D29021B05CD for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
21:51:23 -0500 (EST)
Received: from forced.attrition.org (forced.attrition.org [72.215.220.112]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 7590121B05A4 for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
21:51:22 -0500 (EST)
Received: by forced.attrition.org (Postfix, from userid 1000) id
2990BD9177; Fri, 9 Mar 2012 20:51:22 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by forced.attrition.org
(Postfix) with ESMTP id 288ADD90F4 for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
20:51:22 -0600 (CST)
Date: Fri, 9 Mar 2012 20:51:22 -0600
From: security curmudgeon <jericho@attrition.org>
To: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
In-Reply-To: <2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
Message-ID: <alpine.LNX.2.00.1203092037330.7367@forced.attrition.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
X-Attrition: Attrition is only good when forced. http://attrition.org
X-OSVDB: Everything is vulnerable. http://osvdb.org/
X-Message-Flag: WARNING: Over 100 published security vulnerabilities in
Microsoft Outlook!
X-Copyright: This e-mail copyright 2011 by jericho@attrition.org where
applicable
X-Encryption: rot26
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.10.24525
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, NO_URI_FOUND 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__C230066_P2 0, __CS_PROD_FROM 0, __CT 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 4147
Status:
X-Status:
X-Keywords:
Couple of responses to Dave's points, and one new one for consideration
(that may deserve it's own thread).
On Fri, 9 Mar 2012, Mann, Dave wrote:
: 1) GLOBAL VULNERABILITY REPORTING - In my opinion, one thing that CVE
: global vulnerability reporting problem. But one thing I'm very sure of
: is that this solution, if it exists, will need to evolve organically by
: knitting together various regional capabilities.
Definitely.
: I think the best thing that we, the CVE community, can do to help
: facilitate the emergence of a global vulnerability reporting capability
: is to be able to speak clearly about what we can and can't do and to try
: to make as many of our lessons learned available to others as possible.
Agreed. I think this will be in the form of announcing what vulnerability
disclosure sources are monitored at the very least. After that, perhaps an
average time it takes to issue an identifier after disclosure.
The other thing to consider is that if the regional entities share exports
of references, it would be considerably easier to do matching. One thing
OSVDB has done for vendors that wanted was to exchange such dumps. We'd
provide a list of OSVDB - CVE - Secunia - BID - XSS cross references, they
would provide a list of CVE - internal_id references. Each side could then
import the other's data set to add a new set of references. OSVDB did this
for example with Tenable for both Nessus and PVS. In a matter of hours,
OSVDB could reference some 5,000 PVS references along with 40,000+ Nessus
references.
Think of this on a bigger scale. If CVE and JP-CERT do that, and CVE
shares with OSVDB, and OSVDB and Secunia swap data sets frequently, then
each VDB and regional entity would have a solid framework that achieves
two things:
1. They have good cross-references, which helps avoid duplicate
assignments.
2. Each entity has a concise list of CVE (or any other shared ID) that are
*not* in their database, and they can investigate why.
: 2) VULNERABILITY SOURCES - We've talked internally at great length on
: the subject of vendors, products and sources. We've also talked a bit
: about this as a Board. In my opinion, we'll drive ourselves bonkers if
: we talk about vendors and products.
Totally spitballing here:
With the creation of so many other VDBs that do daily monitoring, perhaps
CVE should dramatically change the focus. Rather than trying to monitor a
percentage of disclosure sources, why not monitor a handful off VDBs? By
watching Secunia, BID, and ISS, CVE could create an entry with a certain
level of confidence (especially if monitoring Secunia). Further, they
could have the original disclosure and three VDB references with each CVE
coming out of the gate. In turn, each of those VDBs can scrape CVE and
import the assignment since their ID is already in the mix.
In short, CVE could become a different style of meta-VDB.
--
The other point I have brought up privately, and publicly to some degree,
is the CVE / NVD relationship. I know the following is kind of a unicorn
at best, because of government bureaucracy, but I think it would be
considerably better for the industry and those that use CVE.
NVD needs to go away. Completely. The money they receive from NIST should
be re-assigned to CVE. Hell, the existing contract could stay in place so
very little is actually changed. For those not aware, NVD outsources the
CVSS scoring to Booze-Allen junior analysts. The only real value NVD
brings to the table, that so many rely on them for, is CVSS scoring.
Having those same analysts report to MITRE instead of NIST would eliminate
another issue many in the industry have, that being the extra day or three
delay between CVE assignment and CVSS scoring. If CVE had those analysts,
they could get a score affiliated with a CVE assignment that much quicker,
not have to go through the daily push of data to NVD who then pushes it on
to BA.
Again, its the government, two agencies and two contractors that make up
the mess of funding and actual work. I know it is a small miracle to make
big changes like that (on paper).
.b
From owner-cve-editorial-board-list@LISTS.MITRE.ORG Fri Mar 9 21:52:22 2012
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77])
by linus.mitre.org (8.12.11/8.12.10) with ESMTP id q2A2qMO4004181;
Fri, 9 Mar 2012 21:52:22 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id D8F1021B05CD;
Fri, 9 Mar 2012 21:52:16 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81])
by smtpksrv1.mitre.org (Postfix) with ESMTP id B65A121B05A4;
Fri, 9 Mar 2012 21:52:16 -0500 (EST)
Received: from lists (129.83.31.52) by IMCCAS04.MITRE.ORG (129.83.29.81) with
Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 21:52:16 -0500
Received: by LISTS.MITRE.ORG (LISTSERV-TCP/IP release 15.5) with spool id
4552614 for CVE-EDITORIAL-BOARD-LIST@LISTS.MITRE.ORG; Fri, 9 Mar
2012 21:51:34 -0500
Received: from [129.83.20.13] by LISTS.MITRE.ORG (SMTPL release 1.0w) with
TCP; Fri, 9 Mar 2012 21:51:34 -0500
Received: from smtpksrv1.mitre.org (198.49.146.77) by lists.mitre.org with
SMTP id 13250225; Fri, 09 Mar 2012 21:51:23 -0500 (EST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by
localhost (Postfix) with SMTP id 0D29021B05CD for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
21:51:23 -0500 (EST)
Received: from forced.attrition.org (forced.attrition.org [72.215.220.112]) by
smtpksrv1.mitre.org (Postfix) with ESMTP id 7590121B05A4 for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
21:51:22 -0500 (EST)
Received: by forced.attrition.org (Postfix, from userid 1000) id
2990BD9177; Fri, 9 Mar 2012 20:51:22 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by forced.attrition.org
(Postfix) with ESMTP id 288ADD90F4 for
<cve-editorial-board-list@lists.mitre.org>; Fri, 9 Mar 2012
20:51:22 -0600 (CST)
Date: Fri, 9 Mar 2012 20:51:22 -0600
From: security curmudgeon <jericho@attrition.org>
To: cve-editorial-board-list <cve-editorial-board-list@LISTS.MITRE.ORG>
Subject: RE: Counting on CVEs
In-Reply-To: <2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
Message-ID: <alpine.LNX.2.00.1203092037330.7367@forced.attrition.org>
References: <CB7CD170.2DC8A%kent_landfield@mcafee.com>
<2F43C4D2BE8AD24C8AC17D8C64B379B30F9B16@IMCMBX01.MITRE.ORG>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
X-Attrition: Attrition is only good when forced. http://attrition.org
X-OSVDB: Everything is vulnerable. http://osvdb.org/
X-Message-Flag: WARNING: Over 100 published security vulnerabilities in
Microsoft Outlook!
X-Copyright: This e-mail copyright 2011 by jericho@attrition.org where
applicable
X-Encryption: rot26
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2012.3.10.24525
X-MITRE-External: True
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05,
HTML_00_10 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, NO_URI_FOUND 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__C230066_P2 0, __CS_PROD_FROM 0, __CT 0, __CT_TEXT_PLAIN 0,
__HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
__SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0'
Sender: <owner-cve-editorial-board-list@LISTS.MITRE.ORG>
Precedence: list
List-Help: <mailto:LISTSERV@LISTS.MITRE.ORG?body=INFO%20CVE-EDITORIAL-BOARD-LIST>
List-Unsubscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-unsubscribe-request@LISTS.MITRE.ORG>
List-Subscribe: <mailto:CVE-EDITORIAL-BOARD-LIST-subscribe-request@LISTS.MITRE.ORG>
List-Owner: <mailto:CVE-EDITORIAL-BOARD-LIST-request@LISTS.MITRE.ORG>
Content-Length: 4147
Status:
X-Status:
X-Keywords:
Couple of responses to Dave's points, and one new one for consideration
(that may deserve it's own thread).
On Fri, 9 Mar 2012, Mann, Dave wrote:
: 1) GLOBAL VULNERABILITY REPORTING - In my opinion, one thing that CVE
: global vulnerability reporting problem. But one thing I'm very sure of
: is that this solution, if it exists, will need to evolve organically by
: knitting together various regional capabilities.
Definitely.
: I think the best thing that we, the CVE community, can do to help
: facilitate the emergence of a global vulnerability reporting capability
: is to be able to speak clearly about what we can and can't do and to try
: to make as many of our lessons learned available to others as possible.
Agreed. I think this will be in the form of announcing what vulnerability
disclosure sources are monitored at the very least. After that, perhaps an
average time it takes to issue an identifier after disclosure.
The other thing to consider is that if the regional entities share exports
of references, it would be considerably easier to do matching. One thing
OSVDB has done for vendors that wanted was to exchange such dumps. We'd
provide a list of OSVDB - CVE - Secunia - BID - XSS cross references, they
would provide a list of CVE - internal_id references. Each side could then
import the other's data set to add a new set of references. OSVDB did this
for example with Tenable for both Nessus and PVS. In a matter of hours,
OSVDB could reference some 5,000 PVS references along with 40,000+ Nessus
references.
Think of this on a bigger scale. If CVE and JP-CERT do that, and CVE
shares with OSVDB, and OSVDB and Secunia swap data sets frequently, then
each VDB and regional entity would have a solid framework that achieves
two things:
1. They have good cross-references, which helps avoid duplicate
assignments.
2. Each entity has a concise list of CVE (or any other shared ID) that are
*not* in their database, and they can investigate why.
: 2) VULNERABILITY SOURCES - We've talked internally at great length on
: the subject of vendors, products and sources. We've also talked a bit
: about this as a Board. In my opinion, we'll drive ourselves bonkers if
: we talk about vendors and products.
Totally spitballing here:
With the creation of so many other VDBs that do daily monitoring, perhaps
CVE should dramatically change the focus. Rather than trying to monitor a
percentage of disclosure sources, why not monitor a handful off VDBs? By
watching Secunia, BID, and ISS, CVE could create an entry with a certain
level of confidence (especially if monitoring Secunia). Further, they
could have the original disclosure and three VDB references with each CVE
coming out of the gate. In turn, each of those VDBs can scrape CVE and
import the assignment since their ID is already in the mix.
In short, CVE could become a different style of meta-VDB.
--
The other point I have brought up privately, and publicly to some degree,
is the CVE / NVD relationship. I know the following is kind of a unicorn
at best, because of government bureaucracy, but I think it would be
considerably better for the industry and those that use CVE.
NVD needs to go away. Completely. The money they receive from NIST should
be re-assigned to CVE. Hell, the existing contract could stay in place so
very little is actually changed. For those not aware, NVD outsources the
CVSS scoring to Booze-Allen junior analysts. The only real value NVD
brings to the table, that so many rely on them for, is CVSS scoring.
Having those same analysts report to MITRE instead of NIST would eliminate
another issue many in the industry have, that being the extra day or three
delay between CVE assignment and CVSS scoring. If CVE had those analysts,
they could get a score affiliated with a CVE assignment that much quicker,
not have to go through the daily push of data to NVD who then pushes it on
to BA.
Again, its the government, two agencies and two contractors that make up
the mess of funding and actual work. I know it is a small miracle to make
big changes like that (on paper).
.b
