CPE Survey

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

CPE Survey

Brant Cheikes

In connection with the announced upcoming CPE Developer Days Workshop, attached please find the CPE Stakeholder Survey.  The purpose of this survey is to collect information about CPE—community views of its technical strengths and limitations, and plans for future adoption and use—to help guide decisions about near and longer-term efforts to improve it. The survey should take only 10-15 minutes of your time to complete.

 

Please send the completed survey as an e-mail attachment with “CPE Survey” in the subject line to [hidden email] no later than 5:00 PM on Friday, January 8, 2010.  This will give us time to compile and analyze the results in time for the Developer Days Workshop.  Results will be shared back with the community during the Workshop, and posted to the discussion list.

 

Thank you for taking the time to participate in this important activity.

 

/Brant

 

Brant A. Cheikes

Lead, MITRE CPE Project (cpe.mitre.org)
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


CPE_Stakeholder_Survey.doc (104K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE Survey

Brant Cheikes

CPE Community,

 

Just a gentle reminder that we’d like to receive as many responses as we can muster to the CPE Survey.  So far we’re received only five (5).  I’m hoping we can do better than that!  The deadline is this Friday—8 Jan 2010.  Please take advantage of this opportunity to influence the technical evolution of the CPE standard.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Friday, December 11, 2009 9:50 AM
To: cpe-discussion-list CPE Community Forum
Subject: [CPE-DISCUSSION-LIST] CPE Survey

 

In connection with the announced upcoming CPE Developer Days Workshop, attached please find the CPE Stakeholder Survey.  The purpose of this survey is to collect information about CPE—community views of its technical strengths and limitations, and plans for future adoption and use—to help guide decisions about near and longer-term efforts to improve it. The survey should take only 10-15 minutes of your time to complete.

 

Please send the completed survey as an e-mail attachment with “CPE Survey” in the subject line to [hidden email] no later than 5:00 PM on Friday, January 8, 2010.  This will give us time to compile and analyze the results in time for the Developer Days Workshop.  Results will be shared back with the community during the Workshop, and posted to the discussion list.

 

Thank you for taking the time to participate in this important activity.

 

/Brant

 

Brant A. Cheikes

Lead, MITRE CPE Project (cpe.mitre.org)
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

Reply | Threaded
Open this post in threaded view
|

Re: CPE Survey

Mary Parmelee

This message is being sent on behalf of the Common Platform Enumeration (CPE) Project Lead, Brant Cheikes.

 

CPE Community,

 

First let us thank those of you who took the time to submit the CPE survey on time. We appreciate your effort very much. That being said, there has been only a 5% response to the CPE Survey. While the survey was distributed to approximately 200 potential participants, only 10 surveys have been submitted. Therefore, we have decided to expand the invitee list and extend the deadline to 5:00 PM EST on Friday, January 22nd.

 

Completing the survey will take no more than 15 minutes of your time and the results will be directly applied to CPE Workshop activities on February 22. Please take a few minutes to help guide the CPE Team in meeting your operational needs.

 

Thank you in advance for your time and consideration.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Tuesday, January 05, 2010 2:15 PM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] CPE Survey

 

CPE Community,

 

Just a gentle reminder that we’d like to receive as many responses as we can muster to the CPE Survey.  So far we’re received only five (5).  I’m hoping we can do better than that!  The deadline is this Friday—8 Jan 2010.  Please take advantage of this opportunity to influence the technical evolution of the CPE standard.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Friday, December 11, 2009 9:50 AM
To: cpe-discussion-list CPE Community Forum
Subject: [CPE-DISCUSSION-LIST] CPE Survey

 

In connection with the announced upcoming CPE Developer Days Workshop, attached please find the CPE Stakeholder Survey.  The purpose of this survey is to collect information about CPE—community views of its technical strengths and limitations, and plans for future adoption and use—to help guide decisions about near and longer-term efforts to improve it. The survey should take only 10-15 minutes of your time to complete.

 

Please send the completed survey as an e-mail attachment with “CPE Survey” in the subject line to [hidden email] no later than 5:00 PM on Friday, January 8, 2010.  This will give us time to compile and analyze the results in time for the Developer Days Workshop.  Results will be shared back with the community during the Workshop, and posted to the discussion list.

 

Thank you for taking the time to participate in this important activity.

 

/Brant

 

Brant A. Cheikes

Lead, MITRE CPE Project (cpe.mitre.org)
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 


CPE_Stakeholder_Survey.doc (99K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Simple view of the CPE dictionary

Jerome Athias
Hi list,

if useful for someone...

Regards & Happy new year!

--
Jerome Athias
http://www.linkedin.com/in/jeromeathias
"The computer security is an art form. It's the ultimate martial art."

CPE_dictionary.png (52K) Download Attachment
jerome_athias.vcf (404 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Simple view of the CPE dictionary

Wolfkiel, Joseph
I think it's very useful, at least as a basis of discussion on where CPE
went wrong as an ontology.  The attached represents the flawed assumption
that different parts of product names have dependencies on the previous
components of the CPE structure.  This is known as the "prefix property" in
the CPE spec.

In my experience (i.e. trying to use CPE operationally for two years in the
DoD), the dependencies represented in the picture are a correct
representation of the CPE construct, but not a good representation of how
the different CPE components are actually related.

In my opinion, product is the real core piece of CPE as demonstrated by
software such as Linux, which is a core software product that is distributed
by multiple vendors.  The majority of other components are also directly
related to product versus the component that immediately precedes them.

For example:
-- Update is not directly dependent on version, though it is referenced in
the version field of some products (e.g. Microsoft OS)
-- Edition (e.g. "professional", "group", "home", etc--typically describes
expanded functionality) is related to products, but not to version or update
-- Language is also a function of which language is supported by the
product, but not the version, update, or edition

The flaws in the ontological concept pervade the CPE specification and cause
problems across the board from matching to transport.  If you check the NIST
CPE dictionary, the requirement to build dependencies where they don't exist
(e.g. make editions of products dependent on updates even though many
software producers don't even use "updates" as a support concept) has forced
NIST to create blank component names specifically so they can support the
prefix property.

This is one of the issues I want to discuss at the February developer days.
Specifically: 1) can we delete the "prefix property" from version 2.2 so we
can use logic that represents how names are really related?  2) can we use
the URI format with its assumption about dependencies that don't really
exist as just another form of transport for software names and not the basis
for business logic?

That said, I think we're pretty close to knowing which software name
components are required to share software names.  The current set works with
the exception of taking target HW and target SW environment (e.g. "for
MacOS" or "i386") out of the edition field and giving them their own
components.

Others include: 3) can we recognize that "edition" shouldn't really be the
full set of edition plus target HW plus target SW?  4) how much of this is
appropriate in a version 2.3 spec and how much must wait for 3.x?

I've been grappling with these issues as we design the next minor release of
ARF 0.41.  I plan to add attributes to the AssessedName portion of ARF
0.41.2 to match each of the CPE components as well as support URI following
the CPE namePattern for known matches in the CPE dictionary.

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: Jerome Athias [mailto:[hidden email]]
Sent: Tuesday, January 12, 2010 9:06 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary

Hi list,

if useful for someone...

Regards & Happy new year!

--
Jerome Athias
http://www.linkedin.com/in/jeromeathias
"The computer security is an art form. It's the ultimate martial art."

CPE_dictionary.png (52K) Download Attachment
smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Simple view of the CPE dictionary

Jerome Athias
Dealing with IT security advisories for years, for our (my company)
internal needs in pentests and other services, we use these items:

- Editor (better name for "vendor"?)
- Product
- Platform (ie: x86 or i386, x64, ARM)
- OS
- Version
- Language

- Update (patch level or modification of a Product-Version, but could
also impact various Product-Version/OS/Platform. ie: SP1)


jerome_athias.vcf (404 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Simple view of the CPE dictionary

Waltermire, David A.
In reply to this post by Wolfkiel, Joseph
Joe,

Please find our feedback on your discussion points below.  This is great dialog in advance of the CPE workshop.  I encourage the community to engage in this thread in the weeks leading up to that meeting.  Active discussion here will allow us to have a more informed working session in February.

1) can we delete the "prefix property" from version 2.2 so we
can use logic that represents how names are really related?

We agree that the "prefix property" creates complication in using CPE Names to fulfill a variety of use cases. We think the core of this issue revolves around the fact that we have combined the identification of products with other use cases put forth in the CPE spec (e.g. matching).  In doing this we have imposed a very static viewpoint on the domain we are working in.  This viewpoint dictates the types of data we can capture (e.g. part, vendor, product, version, edition...) as well as the ways in which this data is related (Joe gave many good examples of this for Update, Edition, and Language).  

If we were to separate the product identifier from everything else it would allow us to start capturing information about products that is applicable at both the global level, as well as information that is applicable for operational use cases of smaller, proprietary systems (i.e. model extensibility).  In the context of the NVD this will allow us to start to model the granular and heterogeneous way in which products are versioned, while communicating this information to the rest of the community using common classes and properties specified in the model.  This ability to capture information specific to an operational use case, while still allowing for the communication of information common across federated use cases is the key to interoperability.

Removing the "prefix property" from the CPE 2.x line may introduce some compatibility problems that are covered later in this posting.

2) can we use the URI format with its assumption about dependencies that don't really exist as just another form of transport for software names and not the basis for business logic?

Based on our view above, we also agree with this suggestion.  The need exists to separate the identification of products from the complex data and relationships that must be captured to fulfill business processes.

3) can we recognize that "edition" shouldn't really be the
full set of edition plus target HW plus target SW?

The problem here is that "edition" in the context of CPE is meant to have a single meaning.  However, "edition" in the context of the universe of IT products takes on many different meanings depending on the vendor.  For example, edition for Open Solaris designates the hardware type on which the product is meant to run (e.g. cpe:/o:sun:opensolaris:::x86), but edition for Windows Office designates the OS on which the product runs on (e.g. cpe:/a:microsoft:office:::mac_os) or the feature set of the release (e.g. cpe:/o:microsoft:windows_xp::sp2:professional).  To solve this we need to break out "edition" into multiple properties which capture the varying meaning and use of the current component.  Speaking from the perspective of the NVD it would be ideal if we can create a model that allows the creation of different properties/relationships to support the disparate ways in which vendors make use of terms like "edition."

4) how much of this is appropriate in a version 2.3 spec and how much must wait for 3.x?

The ideas put forth above are part of what we believe is a long term vision of what CPE needs to become to support a broader group of use cases in an interoperable fashion.  However, in the context of CPE 2.3 we will have to carefully consider the changes we can implement without breaking backwards compatibility for existing use cases, content and implementations.  Many of the ideas above suggest a complete paradigm shift in the CPE specifications.  Such a shift will undoubtedly break many of the operational systems already using CPE today.  If we were to break backwards compatibility in CPE the CPE 2.x line with the release of CPE 2.3, it is possible that we will alienate or lose existing CPE adopters due to the instability it will cause in the specification.

It is my hope that we can identify requirements for CPE 2.3 and future efforts and discuss related issues leading up to and during the February CPE workshop.

Sincerely,

Dave Waltermire
SCAP Architect
National Institute of Standards and Technology
(301) 975-3390
[hidden email]

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Wednesday, January 13, 2010 8:21 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary

I think it's very useful, at least as a basis of discussion on where CPE went wrong as an ontology.  The attached represents the flawed assumption that different parts of product names have dependencies on the previous components of the CPE structure.  This is known as the "prefix property" in the CPE spec.

In my experience (i.e. trying to use CPE operationally for two years in the DoD), the dependencies represented in the picture are a correct representation of the CPE construct, but not a good representation of how the different CPE components are actually related.

In my opinion, product is the real core piece of CPE as demonstrated by software such as Linux, which is a core software product that is distributed by multiple vendors.  The majority of other components are also directly related to product versus the component that immediately precedes them.

For example:
-- Update is not directly dependent on version, though it is referenced in the version field of some products (e.g. Microsoft OS)
-- Edition (e.g. "professional", "group", "home", etc--typically describes expanded functionality) is related to products, but not to version or update
-- Language is also a function of which language is supported by the product, but not the version, update, or edition

The flaws in the ontological concept pervade the CPE specification and cause problems across the board from matching to transport.  If you check the NIST CPE dictionary, the requirement to build dependencies where they don't exist (e.g. make editions of products dependent on updates even though many software producers don't even use "updates" as a support concept) has forced NIST to create blank component names specifically so they can support the prefix property.

This is one of the issues I want to discuss at the February developer days.
Specifically: 1) can we delete the "prefix property" from version 2.2 so we can use logic that represents how names are really related?  2) can we use the URI format with its assumption about dependencies that don't really exist as just another form of transport for software names and not the basis for business logic?

That said, I think we're pretty close to knowing which software name components are required to share software names.  The current set works with the exception of taking target HW and target SW environment (e.g. "for MacOS" or "i386") out of the edition field and giving them their own components.

Others include: 3) can we recognize that "edition" shouldn't really be the full set of edition plus target HW plus target SW?  4) how much of this is appropriate in a version 2.3 spec and how much must wait for 3.x?

I've been grappling with these issues as we design the next minor release of ARF 0.41.  I plan to add attributes to the AssessedName portion of ARF
0.41.2 to match each of the CPE components as well as support URI following the CPE namePattern for known matches in the CPE dictionary.

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: Jerome Athias [mailto:[hidden email]]
Sent: Tuesday, January 12, 2010 9:06 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary

Hi list,

if useful for someone...

Regards & Happy new year!

--
Jerome Athias
http://www.linkedin.com/in/jeromeathias
"The computer security is an art form. It's the ultimate martial art."
Reply | Threaded
Open this post in threaded view
|

Re: Simple view of the CPE dictionary

Jerome Athias
Hi list,

I think that removing "prefix property" is not possible, it should be
more "clear" or "flexible" (I think about it but have a solution now,
sorry :p)

The "edition" concept is not good, and should be removed completely or
integrated in "version"
I prefer the "platform" term, as "x86", "x64" or similar purpose -and-
agree for the use of URIs

All of this, from my point of view, should be appropriate for v2.3 (not 3.0)


I'm sure that a conceptual map and a PoC soft should help me(us) to have
a better view on the usablity of CPE definition and dictionary

My 2c
/JA


Le 15/01/2010 18:00, Waltermire, David a écrit :

> Joe,
>
> Please find our feedback on your discussion points below.  This is great dialog in advance of the CPE workshop.  I encourage the community to engage in this thread in the weeks leading up to that meeting.  Active discussion here will allow us to have a more informed working session in February.
>
> 1) can we delete the "prefix property" from version 2.2 so we
> can use logic that represents how names are really related?
>
> We agree that the "prefix property" creates complication in using CPE Names to fulfill a variety of use cases. We think the core of this issue revolves around the fact that we have combined the identification of products with other use cases put forth in the CPE spec (e.g. matching).  In doing this we have imposed a very static viewpoint on the domain we are working in.  This viewpoint dictates the types of data we can capture (e.g. part, vendor, product, version, edition...) as well as the ways in which this data is related (Joe gave many good examples of this for Update, Edition, and Language).  
>
> If we were to separate the product identifier from everything else it would allow us to start capturing information about products that is applicable at both the global level, as well as information that is applicable for operational use cases of smaller, proprietary systems (i.e. model extensibility).  In the context of the NVD this will allow us to start to model the granular and heterogeneous way in which products are versioned, while communicating this information to the rest of the community using common classes and properties specified in the model.  This ability to capture information specific to an operational use case, while still allowing for the communication of information common across federated use cases is the key to interoperability.
>
> Removing the "prefix property" from the CPE 2.x line may introduce some compatibility problems that are covered later in this posting.
>
> 2) can we use the URI format with its assumption about dependencies that don't really exist as just another form of transport for software names and not the basis for business logic?
>
> Based on our view above, we also agree with this suggestion.  The need exists to separate the identification of products from the complex data and relationships that must be captured to fulfill business processes.
>
> 3) can we recognize that "edition" shouldn't really be the
> full set of edition plus target HW plus target SW?
>
> The problem here is that "edition" in the context of CPE is meant to have a single meaning.  However, "edition" in the context of the universe of IT products takes on many different meanings depending on the vendor.  For example, edition for Open Solaris designates the hardware type on which the product is meant to run (e.g. cpe:/o:sun:opensolaris:::x86), but edition for Windows Office designates the OS on which the product runs on (e.g. cpe:/a:microsoft:office:::mac_os) or the feature set of the release (e.g. cpe:/o:microsoft:windows_xp::sp2:professional).  To solve this we need to break out "edition" into multiple properties which capture the varying meaning and use of the current component.  Speaking from the perspective of the NVD it would be ideal if we can create a model that allows the creation of different properties/relationships to support the disparate ways in which vendors make use of terms like "edition."
>
> 4) how much of this is appropriate in a version 2.3 spec and how much must wait for 3.x?
>
> The ideas put forth above are part of what we believe is a long term vision of what CPE needs to become to support a broader group of use cases in an interoperable fashion.  However, in the context of CPE 2.3 we will have to carefully consider the changes we can implement without breaking backwards compatibility for existing use cases, content and implementations.  Many of the ideas above suggest a complete paradigm shift in the CPE specifications.  Such a shift will undoubtedly break many of the operational systems already using CPE today.  If we were to break backwards compatibility in CPE the CPE 2.x line with the release of CPE 2.3, it is possible that we will alienate or lose existing CPE adopters due to the instability it will cause in the specification.
>
> It is my hope that we can identify requirements for CPE 2.3 and future efforts and discuss related issues leading up to and during the February CPE workshop.
>
> Sincerely,
>
> Dave Waltermire
> SCAP Architect
> National Institute of Standards and Technology
> (301) 975-3390
> [hidden email]
>
> -----Original Message-----
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Wednesday, January 13, 2010 8:21 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary
>
> I think it's very useful, at least as a basis of discussion on where CPE went wrong as an ontology.  The attached represents the flawed assumption that different parts of product names have dependencies on the previous components of the CPE structure.  This is known as the "prefix property" in the CPE spec.
>
> In my experience (i.e. trying to use CPE operationally for two years in the DoD), the dependencies represented in the picture are a correct representation of the CPE construct, but not a good representation of how the different CPE components are actually related.
>
> In my opinion, product is the real core piece of CPE as demonstrated by software such as Linux, which is a core software product that is distributed by multiple vendors.  The majority of other components are also directly related to product versus the component that immediately precedes them.
>
> For example:
> -- Update is not directly dependent on version, though it is referenced in the version field of some products (e.g. Microsoft OS)
> -- Edition (e.g. "professional", "group", "home", etc--typically describes expanded functionality) is related to products, but not to version or update
> -- Language is also a function of which language is supported by the product, but not the version, update, or edition
>
> The flaws in the ontological concept pervade the CPE specification and cause problems across the board from matching to transport.  If you check the NIST CPE dictionary, the requirement to build dependencies where they don't exist (e.g. make editions of products dependent on updates even though many software producers don't even use "updates" as a support concept) has forced NIST to create blank component names specifically so they can support the prefix property.
>
> This is one of the issues I want to discuss at the February developer days.
> Specifically: 1) can we delete the "prefix property" from version 2.2 so we can use logic that represents how names are really related?  2) can we use the URI format with its assumption about dependencies that don't really exist as just another form of transport for software names and not the basis for business logic?
>
> That said, I think we're pretty close to knowing which software name components are required to share software names.  The current set works with the exception of taking target HW and target SW environment (e.g. "for MacOS" or "i386") out of the edition field and giving them their own components.
>
> Others include: 3) can we recognize that "edition" shouldn't really be the full set of edition plus target HW plus target SW?  4) how much of this is appropriate in a version 2.3 spec and how much must wait for 3.x?
>
> I've been grappling with these issues as we design the next minor release of ARF 0.41.  I plan to add attributes to the AssessedName portion of ARF
> 0.41.2 to match each of the CPE components as well as support URI following the CPE namePattern for known matches in the CPE dictionary.
>
> 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: Jerome Athias [mailto:[hidden email]]
> Sent: Tuesday, January 12, 2010 9:06 AM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary
>
> Hi list,
>
> if useful for someone...
>
> Regards & Happy new year!
>
> --
> Jerome Athias
> http://www.linkedin.com/in/jeromeathias
> "The computer security is an art form. It's the ultimate martial art."
>
--
Cordialement,

Jérôme Athias
Consultant principal JA-PSI
http://www.linkedin.com/in/jeromeathias
"The computer security is an art form. It's the ultimate martial art."
"Le savoir sans partage, ne sert à rien ..."

JA-PSI
9 b Rue Stéphane Mallarmé
25000 BESANCON
FRANCE

Tel: +33 (0)950.100.111
Fax: +33 (0)955.100.111
Gsm: +33 (0)687.254.532
http://www.ja-psi.fr

SIRET: 500 451 25700017 - TVA: FR05500451257 - RCS BESANCON
Code APE: 6202A - Conseil en systèmes et logiciels informatiques
Déclaration d'activité de formation enregistrée sous le numéro
43250224925 auprès du préfet de région de Franche-Comté.
Déclaration CNIL: 1282266
Membre de la FSF (www.fsf.org - Free Software Foundation)
Membre de l'APRIL (www.april.org - Promouvoir et défendre les logiciels
libres.)

-------------------------------
(Gvidon descend de la côte vers la mer. Hors de l'eau vole un bourdon,
tourbillonnant autour du cygne.)
Le cygne:
Eh bien, maintenant, mon bourdon, en avant,
rattrape le navire sur la mer,
ralenti doucement,
pénètre dans la fissure un peu plus loin.
Bonne chance, Gvidon, vole,
mais ne reste pas longtemps!
(Le bourdon s'en va en volant.)

-------------------------------
Chihiro: Guys, don't take that food! We're gonna get in trouble!
Chihiro's Father: Don't worry, you've got Daddy with you. He's got
credit cards and cash!

jerome_athias.vcf (404 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Simple view of the CPE dictionary

Wolfkiel, Joseph
I think that the "prefix property" is pretty easy to do away with.  Our
matching implementation supports matching as a function of which components
are populated versus any assumption about what was in the preceding
component.

Other issues, I'll wait to discuss in person.

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: Jerome Athias [mailto:[hidden email]]
Sent: Friday, January 15, 2010 2:50 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary

Hi list,

I think that removing "prefix property" is not possible, it should be more
"clear" or "flexible" (I think about it but have a solution now, sorry :p)

The "edition" concept is not good, and should be removed completely or
integrated in "version"
I prefer the "platform" term, as "x86", "x64" or similar purpose -and- agree
for the use of URIs

All of this, from my point of view, should be appropriate for v2.3 (not 3.0)


I'm sure that a conceptual map and a PoC soft should help me(us) to have a
better view on the usablity of CPE definition and dictionary

My 2c
/JA


Le 15/01/2010 18:00, Waltermire, David a écrit :
> Joe,
>
> Please find our feedback on your discussion points below.  This is great
dialog in advance of the CPE workshop.  I encourage the community to engage
in this thread in the weeks leading up to that meeting.  Active discussion
here will allow us to have a more informed working session in February.
>
> 1) can we delete the "prefix property" from version 2.2 so we can use
> logic that represents how names are really related?
>
> We agree that the "prefix property" creates complication in using CPE
Names to fulfill a variety of use cases. We think the core of this issue
revolves around the fact that we have combined the identification of
products with other use cases put forth in the CPE spec (e.g. matching).  In
doing this we have imposed a very static viewpoint on the domain we are
working in.  This viewpoint dictates the types of data we can capture (e.g.
part, vendor, product, version, edition...) as well as the ways in which
this data is related (Joe gave many good examples of this for Update,
Edition, and Language).  
>
> If we were to separate the product identifier from everything else it
would allow us to start capturing information about products that is
applicable at both the global level, as well as information that is
applicable for operational use cases of smaller, proprietary systems (i.e.
model extensibility).  In the context of the NVD this will allow us to start
to model the granular and heterogeneous way in which products are versioned,
while communicating this information to the rest of the community using
common classes and properties specified in the model.  This ability to
capture information specific to an operational use case, while still
allowing for the communication of information common across federated use
cases is the key to interoperability.
>
> Removing the "prefix property" from the CPE 2.x line may introduce some
compatibility problems that are covered later in this posting.
>
> 2) can we use the URI format with its assumption about dependencies that
don't really exist as just another form of transport for software names and
not the basis for business logic?
>
> Based on our view above, we also agree with this suggestion.  The need
exists to separate the identification of products from the complex data and
relationships that must be captured to fulfill business processes.
>
> 3) can we recognize that "edition" shouldn't really be the full set of
> edition plus target HW plus target SW?
>
> The problem here is that "edition" in the context of CPE is meant to have
a single meaning.  However, "edition" in the context of the universe of IT
products takes on many different meanings depending on the vendor.  For
example, edition for Open Solaris designates the hardware type on which the
product is meant to run (e.g. cpe:/o:sun:opensolaris:::x86), but edition for
Windows Office designates the OS on which the product runs on (e.g.
cpe:/a:microsoft:office:::mac_os) or the feature set of the release (e.g.
cpe:/o:microsoft:windows_xp::sp2:professional).  To solve this we need to
break out "edition" into multiple properties which capture the varying
meaning and use of the current component.  Speaking from the perspective of
the NVD it would be ideal if we can create a model that allows the creation
of different properties/relationships to support the disparate ways in which
vendors make use of terms like "edition."
>
> 4) how much of this is appropriate in a version 2.3 spec and how much must
wait for 3.x?
>
> The ideas put forth above are part of what we believe is a long term
vision of what CPE needs to become to support a broader group of use cases
in an interoperable fashion.  However, in the context of CPE 2.3 we will
have to carefully consider the changes we can implement without breaking
backwards compatibility for existing use cases, content and implementations.
Many of the ideas above suggest a complete paradigm shift in the CPE
specifications.  Such a shift will undoubtedly break many of the operational
systems already using CPE today.  If we were to break backwards
compatibility in CPE the CPE 2.x line with the release of CPE 2.3, it is
possible that we will alienate or lose existing CPE adopters due to the
instability it will cause in the specification.
>
> It is my hope that we can identify requirements for CPE 2.3 and future
efforts and discuss related issues leading up to and during the February CPE
workshop.

>
> Sincerely,
>
> Dave Waltermire
> SCAP Architect
> National Institute of Standards and Technology
> (301) 975-3390
> [hidden email]
>
> -----Original Message-----
> From: Wolfkiel, Joseph [mailto:[hidden email]]
> Sent: Wednesday, January 13, 2010 8:21 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary
>
> I think it's very useful, at least as a basis of discussion on where CPE
went wrong as an ontology.  The attached represents the flawed assumption
that different parts of product names have dependencies on the previous
components of the CPE structure.  This is known as the "prefix property" in
the CPE spec.
>
> In my experience (i.e. trying to use CPE operationally for two years in
the DoD), the dependencies represented in the picture are a correct
representation of the CPE construct, but not a good representation of how
the different CPE components are actually related.
>
> In my opinion, product is the real core piece of CPE as demonstrated by
software such as Linux, which is a core software product that is distributed
by multiple vendors.  The majority of other components are also directly
related to product versus the component that immediately precedes them.

>
> For example:
> -- Update is not directly dependent on version, though it is
> referenced in the version field of some products (e.g. Microsoft OS)
> -- Edition (e.g. "professional", "group", "home", etc--typically
> describes expanded functionality) is related to products, but not to
> version or update
> -- Language is also a function of which language is supported by the
> product, but not the version, update, or edition
>
> The flaws in the ontological concept pervade the CPE specification and
cause problems across the board from matching to transport.  If you check
the NIST CPE dictionary, the requirement to build dependencies where they
don't exist (e.g. make editions of products dependent on updates even though
many software producers don't even use "updates" as a support concept) has
forced NIST to create blank component names specifically so they can support
the prefix property.
>
> This is one of the issues I want to discuss at the February developer
days.
> Specifically: 1) can we delete the "prefix property" from version 2.2 so
we can use logic that represents how names are really related?  2) can we
use the URI format with its assumption about dependencies that don't really
exist as just another form of transport for software names and not the basis
for business logic?
>
> That said, I think we're pretty close to knowing which software name
components are required to share software names.  The current set works with
the exception of taking target HW and target SW environment (e.g. "for
MacOS" or "i386") out of the edition field and giving them their own
components.
>
> Others include: 3) can we recognize that "edition" shouldn't really be the
full set of edition plus target HW plus target SW?  4) how much of this is
appropriate in a version 2.3 spec and how much must wait for 3.x?
>
> I've been grappling with these issues as we design the next minor
> release of ARF 0.41.  I plan to add attributes to the AssessedName
> portion of ARF
> 0.41.2 to match each of the CPE components as well as support URI
following the CPE namePattern for known matches in the CPE dictionary.

>
> 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: Jerome Athias [mailto:[hidden email]]
> Sent: Tuesday, January 12, 2010 9:06 AM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary
>
> Hi list,
>
> if useful for someone...
>
> Regards & Happy new year!
>
> --
> Jerome Athias
> http://www.linkedin.com/in/jeromeathias
> "The computer security is an art form. It's the ultimate martial art."
>
--
Cordialement,

Jérôme Athias
Consultant principal JA-PSI
http://www.linkedin.com/in/jeromeathias
"The computer security is an art form. It's the ultimate martial art."
"Le savoir sans partage, ne sert à rien ..."

JA-PSI
9 b Rue Stéphane Mallarmé
25000 BESANCON
FRANCE

Tel: +33 (0)950.100.111
Fax: +33 (0)955.100.111
Gsm: +33 (0)687.254.532
http://www.ja-psi.fr

SIRET: 500 451 25700017 - TVA: FR05500451257 - RCS BESANCON Code APE: 6202A
- Conseil en systèmes et logiciels informatiques Déclaration d'activité de
formation enregistrée sous le numéro
43250224925 auprès du préfet de région de Franche-Comté.
Déclaration CNIL: 1282266
Membre de la FSF (www.fsf.org - Free Software Foundation) Membre de l'APRIL
(www.april.org - Promouvoir et défendre les logiciels
libres.)

-------------------------------
(Gvidon descend de la côte vers la mer. Hors de l'eau vole un bourdon,
tourbillonnant autour du cygne.) Le cygne:
Eh bien, maintenant, mon bourdon, en avant, rattrape le navire sur la mer,
ralenti doucement, pénètre dans la fissure un peu plus loin.
Bonne chance, Gvidon, vole,
mais ne reste pas longtemps!
(Le bourdon s'en va en volant.)

-------------------------------
Chihiro: Guys, don't take that food! We're gonna get in trouble!
Chihiro's Father: Don't worry, you've got Daddy with you. He's got credit
cards and cash!

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Simple view of the CPE dictionary

Tim Keanini
In reply to this post by Waltermire, David A.
On May 23rd 2007 I posted this design concern to the list - subject
reads: "Faceted Vocabulary" and cite some examples on the dangers of a
fixed citation order within the identifier itself.

I do think we can fix this problem for the future of CPE and at the very
least compartmentalize the problems we have with the format today so
that it can gracefully age out of products.

I look forward to the discussions in February and look forward to
spending time with people who really care about solving this problem.
It is in my opinion, the reverse salient to all of our other efforts.

--tk

--
Tim "TK" Keanini, CTO
nCircle Inc.
mbl (415) 328-2722





-----Original Message-----
From: Waltermire, David [mailto:[hidden email]]
Sent: Friday, January 15, 2010 9:01 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary

Joe,

Please find our feedback on your discussion points below.  This is great
dialog in advance of the CPE workshop.  I encourage the community to
engage in this thread in the weeks leading up to that meeting.  Active
discussion here will allow us to have a more informed working session in
February.

1) can we delete the "prefix property" from version 2.2 so we
can use logic that represents how names are really related?

We agree that the "prefix property" creates complication in using CPE
Names to fulfill a variety of use cases. We think the core of this issue
revolves around the fact that we have combined the identification of
products with other use cases put forth in the CPE spec (e.g. matching).
In doing this we have imposed a very static viewpoint on the domain we
are working in.  This viewpoint dictates the types of data we can
capture (e.g. part, vendor, product, version, edition...) as well as the
ways in which this data is related (Joe gave many good examples of this
for Update, Edition, and Language).  

If we were to separate the product identifier from everything else it
would allow us to start capturing information about products that is
applicable at both the global level, as well as information that is
applicable for operational use cases of smaller, proprietary systems
(i.e. model extensibility).  In the context of the NVD this will allow
us to start to model the granular and heterogeneous way in which
products are versioned, while communicating this information to the rest
of the community using common classes and properties specified in the
model.  This ability to capture information specific to an operational
use case, while still allowing for the communication of information
common across federated use cases is the key to interoperability.

Removing the "prefix property" from the CPE 2.x line may introduce some
compatibility problems that are covered later in this posting.

2) can we use the URI format with its assumption about dependencies that
don't really exist as just another form of transport for software names
and not the basis for business logic?

Based on our view above, we also agree with this suggestion.  The need
exists to separate the identification of products from the complex data
and relationships that must be captured to fulfill business processes.

3) can we recognize that "edition" shouldn't really be the
full set of edition plus target HW plus target SW?

The problem here is that "edition" in the context of CPE is meant to
have a single meaning.  However, "edition" in the context of the
universe of IT products takes on many different meanings depending on
the vendor.  For example, edition for Open Solaris designates the
hardware type on which the product is meant to run (e.g.
cpe:/o:sun:opensolaris:::x86), but edition for Windows Office designates
the OS on which the product runs on (e.g.
cpe:/a:microsoft:office:::mac_os) or the feature set of the release
(e.g. cpe:/o:microsoft:windows_xp::sp2:professional).  To solve this we
need to break out "edition" into multiple properties which capture the
varying meaning and use of the current component.  Speaking from the
perspective of the NVD it would be ideal if we can create a model that
allows the creation of different properties/relationships to support the
disparate ways in which vendors make use of terms like "edition."

4) how much of this is appropriate in a version 2.3 spec and how much
must wait for 3.x?

The ideas put forth above are part of what we believe is a long term
vision of what CPE needs to become to support a broader group of use
cases in an interoperable fashion.  However, in the context of CPE 2.3
we will have to carefully consider the changes we can implement without
breaking backwards compatibility for existing use cases, content and
implementations.  Many of the ideas above suggest a complete paradigm
shift in the CPE specifications.  Such a shift will undoubtedly break
many of the operational systems already using CPE today.  If we were to
break backwards compatibility in CPE the CPE 2.x line with the release
of CPE 2.3, it is possible that we will alienate or lose existing CPE
adopters due to the instability it will cause in the specification.

It is my hope that we can identify requirements for CPE 2.3 and future
efforts and discuss related issues leading up to and during the February
CPE workshop.

Sincerely,

Dave Waltermire
SCAP Architect
National Institute of Standards and Technology
(301) 975-3390
[hidden email]

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Wednesday, January 13, 2010 8:21 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary

I think it's very useful, at least as a basis of discussion on where CPE
went wrong as an ontology.  The attached represents the flawed
assumption that different parts of product names have dependencies on
the previous components of the CPE structure.  This is known as the
"prefix property" in the CPE spec.

In my experience (i.e. trying to use CPE operationally for two years in
the DoD), the dependencies represented in the picture are a correct
representation of the CPE construct, but not a good representation of
how the different CPE components are actually related.

In my opinion, product is the real core piece of CPE as demonstrated by
software such as Linux, which is a core software product that is
distributed by multiple vendors.  The majority of other components are
also directly related to product versus the component that immediately
precedes them.

For example:
-- Update is not directly dependent on version, though it is referenced
in the version field of some products (e.g. Microsoft OS)
-- Edition (e.g. "professional", "group", "home", etc--typically
describes expanded functionality) is related to products, but not to
version or update
-- Language is also a function of which language is supported by the
product, but not the version, update, or edition

The flaws in the ontological concept pervade the CPE specification and
cause problems across the board from matching to transport.  If you
check the NIST CPE dictionary, the requirement to build dependencies
where they don't exist (e.g. make editions of products dependent on
updates even though many software producers don't even use "updates" as
a support concept) has forced NIST to create blank component names
specifically so they can support the prefix property.

This is one of the issues I want to discuss at the February developer
days.
Specifically: 1) can we delete the "prefix property" from version 2.2 so
we can use logic that represents how names are really related?  2) can
we use the URI format with its assumption about dependencies that don't
really exist as just another form of transport for software names and
not the basis for business logic?

That said, I think we're pretty close to knowing which software name
components are required to share software names.  The current set works
with the exception of taking target HW and target SW environment (e.g.
"for MacOS" or "i386") out of the edition field and giving them their
own components.

Others include: 3) can we recognize that "edition" shouldn't really be
the full set of edition plus target HW plus target SW?  4) how much of
this is appropriate in a version 2.3 spec and how much must wait for
3.x?

I've been grappling with these issues as we design the next minor
release of ARF 0.41.  I plan to add attributes to the AssessedName
portion of ARF
0.41.2 to match each of the CPE components as well as support URI
following the CPE namePattern for known matches in the CPE dictionary.

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: Jerome Athias [mailto:[hidden email]]
Sent: Tuesday, January 12, 2010 9:06 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Simple view of the CPE dictionary

Hi list,

if useful for someone...

Regards & Happy new year!

--
Jerome Athias
http://www.linkedin.com/in/jeromeathias
"The computer security is an art form. It's the ultimate martial art."