Informal Meeting at RSA

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Informal Meeting at RSA

Wolfkiel, Joseph
If spending our time doing incremental updates to CPE 2.x is the best option for the April meeting, then I'll support that.
 
However, some of the things that keep tripping us up are fundamental concepts in CPE 2.x such as the omnipotent URI format, lack of tolerance for aliasing, the inability to do matching within components, and the inability to gracefully deal with component names that can be associated with multiple other higher-level component names.
 
My vision was to design a 3.0 version that could re-use all the content from 2.x, but better deal with the limitations.  I think we can tweak 2.x to deal with some of the issues (and have, within the DoD data strategy pilot confines), but there are limitations on what you can do with the concept of "item" and "platform" as all-purpose text strings.
 
I'll see everyone at the April meeting.
 
Cheers,
 
- Joe

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office

9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Thursday, March 20, 2008 3:26 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Informal Meeting at RSA

Wow… very old data… A word count on The Official NVD CPE Dictionary is

    2661    7586  133511 cpe-dictionary-2.0.xml

 

And has only 839 CPE entries from two vendors.

 

What you are looking at was the NVD dictionary before CPE 2.0 was adopted.

 

--

Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

 


From: Ernest Park [mailto:[hidden email]]
Sent: Thursday, March 20, 2008 1:58 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Informal Meeting at RSA

 

The NVD CPE list includes around 5500 vendors, over 20,000 releases.

 

The existing list has approximately 5% duplicate entries, where it seems that one NVD collector created one name and entry, and another created a different vendor name.

 

The CPE needs a meta-layer, allowing name aliases for vendors, applications, releases. The aliases would allow both private and public alias for existing names. In this way, a vendor can map a proprietary naming scheme into the CPE using the alias table, without breaking his software or requiring the CPE to change.

 

  • Names for applications, releases and so on should be open to public review and approval, and the submission process should be public.
  • For every vendor, application and release name approved through a public database registration system, individuals can submit information. Following peer scrutiny, or no challenge on an entry, the entry becomes definitive. any subsequent entries can be aliased to that one.
  • CPE name search and creation could be automated, or auto-assisted. If a user searches vendors, applications, releases, a web form can structure such queries to find the right result, or build a conforming CPE string and submit for review.

 

 

The dictionary benefits when it is public, searchable, and can be synchronized among users in some fashion.

 

I believe that authoritative data can come from a number of sources. My staff researches this information daily, and can provide valuable information on an ongoing basis. If more of our professional community can rate their expertise to deliver this information, we can build a community created and edited dictionary of very reliable information, a definitive index of names and identifiers of those millions of electronic assets that we all work with.

 

What the dictionary needs is a member forum for immediately growing and editing the dictionary, and an alias framework to allow working through the duplicates and the naming irregularities.

 

 

Ernie

 

On 3/20/08, Waltermire, Dave [USA] <[hidden email]> wrote:

Matt,

 

The only authoritative data we have is from Apple and RedHat as you have indicated.  Any names beyond this are for products that we have had in the NVD that we are adding to the dictionary.

 

Dave

 


From: Wojcik, Matthew N. [mailto:[hidden email]]
Sent: Thu 3/20/2008 11:21 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Informal Meeting at RSA

 

Waltermire, Dave [USA] <[hidden email]> wrote:
> Kent,
>
> We will be expanding the scope of vendors included in the CPE
> dictionary when we release the next dictionary revision on April
> 15th.  It will have data from ~250 common vendors of products (i.e.
> hp, sun, oracle, etc).  I will post more info as we get closer to
> this date.   
>
> Dave

Dave,

Just to be clear--will it have data *from* 250 vendors, or *for* the
products from 250 vendors?  It's an important distinction.  The Red Hat
and Apple names have been contributed directly from those vendors, and
should be considered authoritative for their respective products.  Do
we really have the same kind of contributions from that many additional
vendors?

I should say that having names in the published dictionary for so many
vendors' products is a huge step even if they don't come direct from
the source, as it were.

Thanks,

--Woj                  Matthew N. Wojcik                 [hidden email]

 

Reply | Threaded
Open this post in threaded view
|

Re: Informal Meeting at RSA

Andrew Buttner
Administrator
All,

Great thread, it is always positive when so much of the community comes
together in a discussion.  I will try to throw my thoughts into this
and add a little history as well.  (I hope I have the history correct)

I personally think the 2.x spec is very solid and meets the goals we
set out to accomplish.  Having said that, it obviously can not be used,
or meet its goals, without a robust dictionary of official names.  We
have seen the importance of the dictionary in CVE, as well as the
reliance on such for the progress of CCE.  The biggest need for CPE
right now is the dictionary.

The idea behind the 3.0 discussion was focused on requests that have
been made to MITRE and what we perceived as a call for the next
version.  CPE 2.0 was released on 9/14/08.  (Yes, the release was a
little rushed to meet requests from SCAP, but it also followed over 2
months of work with a first draft on 7/20/08)  My thinking was that if
we discuss possible changes in the spring, we wouldn't have a release
until fall, meaning that 2.x would have been out there for a full year.
Given the amount and urgency of requests that were made, I was ok with
this time frame.

I think both Neal and I have been adamant about giving 2.x a chance. If
the community wants to continue with 2.x, we obviously would more than
happy to follow this course.  Again, I really think 2.x is solid and
workable.  Of course we NEED a dictionary to make this happen.

Going forward ...  I will continue to do what I can to help bring a
working dictionary to CPE.  I will also work on a new version of the
agenda for our meeting April 30th.

Please do not consider this thread closed.  The more opinions that are
expressed the better.

Thanks
Drew
Reply | Threaded
Open this post in threaded view
|

Re: Informal Meeting at RSA

Vladimir Giszpenc
Hi all,

> I personally think the 2.x spec is very solid and meets the goals we
> set out to accomplish.  Having said that, it obviously can not be used,

It seems that huge changes are off the table and that is fine, but I think
we should identify things we can do now to make migration to a 3.0
specification later as easy as possible.

> However, some of the things that keep tripping us up are fundamental
> concepts in CPE 2.x such as the omnipotent URI format, lack of tolerance
> for aliasing, the inability to do matching within components, and the
> inability to gracefully deal with component names that can be associated
> with multiple other higher-level component names.

Are these issues barriers to adoption?  In other words, are they the reason
we are not getting new CPEs in mass?

> Come on. Sigh. Sorry, take 'commercial' out of my statement and it covers
> open source as well.  I was trying to differentiate it from only a federal

> government GOTS focus. This is a community standard as you so accurately
> stated.

As a GOTS producer I take offense :).  Seriously, we all need stability,
COTS, GOTS, open source, commercial and all.  I think that we should strive
to make the current standard as forward compatible (i.e. extensible e.g. add
aliasing) as possible.  

My 2 cents (worth less and less each day)

Have a nice weekend and take nice notes at RSA!

Thanks,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959


smime.p7s (4K) Download Attachment
12