Roadmap for CPE v2.3

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

Roadmap for CPE v2.3

Brant Cheikes

The CPE Core Team, with representatives from MITRE, NIST and the US Department of Defense, has been working actively on the plan for the next release of CPE, v2.3.  The attached roadmap briefing is intended to provide a high level summary of our current thinking and directions.  This will continue to evolve over time as we identify and hash out a variety of technical issues, so please do not consider it fixed and final.  We know it contains gaps and other technical issues.  But we wanted to share this summary sooner rather than later, warts and all, with the community and give you an opportunity to provide feedback.  You can expect more details to get posted over the weeks ahead.  As the concluding chart shows, we are working towards a very challenging 11 June deadline, at which point we’ll be releasing draft specifications for a public comment period.  We encourage you to engage as early as you can.

 

I’d also like to reiterate an invitation to others on the list to join our Core Team.  If you’re prepared to participate in one or two weekly teleconferences of 1-2 hrs in length each (with homework!) and commit to doing so at least through June, please contact me to discuss.

 

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

 


cpe-future-roadmap_2010-04-21.pptx (200K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for CPE v2.3

Wolfkiel, Joseph

Given the limitations specified, I have 2 proposed additions:

 

1.        Deprecate abbreviations in preference of full spelling to enhance matching. (e.g.  it’s much easier for a computer to match “internet explorer” than it is to match “ie”)

2.       If we must leave all the packed data in the edition field, at least provide guidance on what order different values are concatenated together to build the packing (i.e. “edition” first, “target software platform” second, then “target hardware platform” third).  So if you have a product that like “Word 7 Professional for MacOS, 32bit” we can all put them in the edition field in the same order (e.g. cpe:\a:microsoft:word:7.1.6.3:sp2:professional_macos_x32:en_us) – in the hopes that we might construct the same cpe string from different sources.

 

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

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Thursday, April 22, 2010 6:21 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3

 

The CPE Core Team, with representatives from MITRE, NIST and the US Department of Defense, has been working actively on the plan for the next release of CPE, v2.3.  The attached roadmap briefing is intended to provide a high level summary of our current thinking and directions.  This will continue to evolve over time as we identify and hash out a variety of technical issues, so please do not consider it fixed and final.  We know it contains gaps and other technical issues.  But we wanted to share this summary sooner rather than later, warts and all, with the community and give you an opportunity to provide feedback.  You can expect more details to get posted over the weeks ahead.  As the concluding chart shows, we are working towards a very challenging 11 June deadline, at which point we’ll be releasing draft specifications for a public comment period.  We encourage you to engage as early as you can.

 

I’d also like to reiterate an invitation to others on the list to join our Core Team.  If you’re prepared to participate in one or two weekly teleconferences of 1-2 hrs in length each (with homework!) and commit to doing so at least through June, please contact me to discuss.

 

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

 


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

Re: Roadmap for CPE v2.3

shanford
On 4/23/10 7:13 AM, "Wolfkiel, Joseph" <[hidden email]> wrote:

> 1.       Deprecate abbreviations in preference of full spelling to enhance
> matching. (e.g. it¹s much easier for a computer to match ³internet explorer²
> than it is to match ³ie²)

I agree. While the CPE URIs look ugly, their purpose is to enhance machine
readability. Abbreviations to make the long strings look more appealing runs
counter to their primary purpose.

> 2.      If we must leave all the packed data in the edition field, at least
> provide guidance on what order different values are concatenated together to
> build the packing (i.e. ³edition² first, ³target software platform² second,
> then ³target hardware platform² third).  So if you have a product that like
> ³Word 7 Professional for MacOS, 32bit² we can all put them in the edition
> field in the same order (e.g.
> cpe:\a:microsoft:word:7.1.6.3:sp2:professional_macos_x32:en_us) ­ in the hopes
> that we might construct the same cpe string from different sources.

Per my mail from yesterday, I would also like to see the edition component
unpacked if possible (and I had missed Target Software Platform, that would
also be a great inclusion).

If these are packed together and guidance given to their order, would it be
sensible to require leading "-"? So if there is no edition or target
software platform, but there is a target hardware platform:
cpe:/a:vendor:product:version:update:-_-_x86

Or, if only target software platform:

cpe:/a:vendor:product:version:update:-_linux

- Seth
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for CPE v2.3

shanford
In reply to this post by Brant Cheikes
Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3 Brant,

I’d like to offer my services for the Core Team for CPE.  We can discuss over email, or touch base in tomorrow’s call, whichever works better.

Thanks,
Seth


On 4/22/10 6:20 PM, "Cheikes, Brant A." <bcheikes@...> wrote:

The CPE Core Team, with representatives from MITRE, NIST and the US Department of Defense, has been working actively on the plan for the next release of CPE, v2.3.  The attached roadmap briefing is intended to provide a high level summary of our current thinking and directions.  This will continue to evolve over time as we identify and hash out a variety of technical issues, so please do not consider it fixed and final.  We know it contains gaps and other technical issues.  But we wanted to share this summary sooner rather than later, warts and all, with the community and give you an opportunity to provide feedback.  You can expect more details to get posted over the weeks ahead.  As the concluding chart shows, we are working towards a very challenging 11 June deadline, at which point we’ll be releasing draft specifications for a public comment period.  We encourage you to engage as early as you can.
 
I’d also like to reiterate an invitation to others on the list to join our Core Team.  If you’re prepared to participate in one or two weekly teleconferences of 1-2 hrs in length each (with homework!) and commit to doing so at least through June, please contact me to discuss.
 
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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for CPE v2.3

shanford
In reply to this post by Brant Cheikes
Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3 I have a potential pitfall for the proposed “Solution B”, the tagging system, in 2.3.  I was working on HP Systems Insight Manager 6.0 this morning for this HP bulletin:
<http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02027185>

From the advisory, we see:
Note:
 HP System Insight Manager version 6.0 for HP-UX contains Namazu v2.0.19
 HP System Insight Manager version 6.0 for Linux contains Namazu v2.0.19
 HP System Insight Manager version 6.0 for Windows contains Namazu v2.0.18

In examining the three target software platforms, HP-UX, Linux, and Windows, there is a very interesting interplay between editions and included software. I’ll express these as CPE names, though they do not appear to exist in the CPE dictionary currently.

cpe:/a:hp:systems_insight_manager:5.1_Windows:-
cpe:/a:hp:systems_insight_manager:5.2_Windows:-
cpe:/a:hp:systems_insight_manager:5.2_Windows:SP1
cpe:/a:hp:systems_insight_manager:5.2_Windows:SP2
cpe:/a:hp:systems_insight_manager:5.3_Windows:-
cpe:/a:hp:systems_insight_manager:5.3_Windows:SP1
cpe:/a:hp:systems_insight_manager:6.0_Windows:-
<http://h18013.www1.hp.com/products/servers/management/hpsim/dl_windows.html>

cpe:/a:hp:systems_insight_manager:5.1_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.1_HP-UX:U1
cpe:/a:hp:systems_insight_manager:5.2_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.2_HP-UX:U1
cpe:/a:hp:systems_insight_manager:5.3_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.3_HP-UX:U1
cpe:/a:hp:systems_insight_manager:6.0_HP-UX:-
<http://h18000.www1.hp.com/products/servers/management/hpsim/dl_hpux.html>

cpe:/a:hp:systems_insight_manager:5.1_Linux:-
cpe:/a:hp:systems_insight_manager:5.2_Linux:-
cpe:/a:hp:systems_insight_manager:5.2_Linux:U1
cpe:/a:hp:systems_insight_manager:5.2_Linux:U2
cpe:/a:hp:systems_insight_manager:5.3_Linux:-
cpe:/a:hp:systems_insight_manager:5.3_Linux:U1
cpe:/a:hp:systems_insight_manager:6.0_Linux:-
<http://h18000.www1.hp.com/products/servers/management/hpsim/dl_linux.html>

So if these sets represent the affected software for this advisory, I’m concerned that the Solution B tagging system, without a structure that requires each component to be accounted for in some way, could mistakenly equate software that is not the same. For example the following are not the same, as HP says that 6.0 for Windows does not contain Namazu 2.0.19:

cpe:/a:hp:systems_insight_manager:6.0_Windows:-
cpe:/a:hp:systems_insight_manager:6.0_HP-UX:-
cpe:/a:hp:systems_insight_manager:6.0_Linux:-

If tagged only with “Systems Insight Manager” and “6.0”, we miss correctly identifying a vulnerability that affects Namazu 2.0.19 (Windows Systems Insight Managers would be unaffected).

Further, if we tag only with “Systems Insight Manager” and “5.2” and “U1”, what do we assume that this means? Windows platform has SP1, not U1. Further, Linux platforms have a “5.2” and “U2”, where HP-UX do not. If the updates are not equivalent between HP-UX and Linux, are “HP-UX” “U1” and “Linux” “U1” the same?

I understand that the current CPE standard does not have to carry a component (and thus the “-” is used), but if we go to a tagging system and do not require a similar “-” tag for each possible tag, we could be incorrectly identifying software on an automated basis.  This example suggests to me that while it may not always be possible to tag things correctly, a vendor’s usage of the same edition names among various target software platforms (in this case, U1 and U2 on HPUX and Linux, versus SP1 and SP2 for Windows, as well as v6.0 for all three but with different included Namazu components) causes potential problems for tagging vs. a structured URI naming scheme.

This differentiation also suggests again that Target Software Platform and Target Hardware Platform should have their own separate components, and not be necessarily shoe-horned into Edition.

Thanks,
Seth Hanford


On 4/22/10 6:20 PM, "Cheikes, Brant A." <bcheikes@...> wrote:

The CPE Core Team, with representatives from MITRE, NIST and the US Department of Defense, has been working actively on the plan for the next release of CPE, v2.3.  The attached roadmap briefing is intended to provide a high level summary of our current thinking and directions.  This will continue to evolve over time as we identify and hash out a variety of technical issues, so please do not consider it fixed and final.  We know it contains gaps and other technical issues.  But we wanted to share this summary sooner rather than later, warts and all, with the community and give you an opportunity to provide feedback.  You can expect more details to get posted over the weeks ahead.  As the concluding chart shows, we are working towards a very challenging 11 June deadline, at which point we’ll be releasing draft specifications for a public comment period.  We encourage you to engage as early as you can.
 
I’d also like to reiterate an invitation to others on the list to join our Core Team.  If you’re prepared to participate in one or two weekly teleconferences of 1-2 hrs in length each (with homework!) and commit to doing so at least through June, please contact me to discuss.
 
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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for CPE v2.3

Paul Cichonski
Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3

Seth,

 

I do not think a move to a “tagging” approach presupposes the removal of required tags/components, nor does it necessarily result in the removal of the ‘-‘.  A tagging approach would simply be a different binding for CPE data.  The primary advantage of this binding is that it separates the product identifier from the meaning  represented by that identifier.  It is still possible to define required tags which must be present within a product data element.  For example if the community decides it is necessary we can mandate that all CPEs within the dictionary contain tags representing all of the legacy components (vendor, product, version, update, edition, language).   It is also still possible to use a character like the ‘-‘ to represent data which does not exist for a specific tag of a specific product.  In fact, this approach is actually desired if we are operating under an “Open World Assumption” so that we can explicitly assert that a specific product does not have any data for a specific component.   

 

To give a specific example, the CPE name “cpe:/a:hp:systems_insight_manager:6.0_Linux:-“ could be represented in a tag-based binding as:

 

<cpe-item id="http://nvd.nist.gov/cpe/product-211">

      <cpe-tag:string-tag name="part"  value="a"/>

      <cpe-tag:string-tag name="vendor"  value="hp"/>

      <cpe-tag:string-tag name="product" value="systems_insight_manager"/>

      <cpe-tag:string-tag name="version" value="6.0_Linux"/>

      <cpe-tag:string-tag name="update" value="-"/>

</cpe-item>

 

We could also easily introduce separate tags to represent the more granular relationships such as “target-hardware”.  In the end the tagging approach is just a different binding that allows us to remove the meaning from the identifier, but it does not change the information that can (or must) be captured.  It actually makes it easier to adjust our model to add more granular relationships since we no longer have to worry about changing the ID syntax, and how that will effect backwards compatibility of IDs.  Also, the problem you mention is still possible using the current URI syntax  since there is nothing stopping CPE name creators from only populating the Vendor, Product, Version components and leaving the rest of the components unpopulated (e.g. cpe:/a:hp:systems_insight_manager:6.0_Linux). 

 

-Paul

 

 

From: Seth Hanford [mailto:[hidden email]]
Sent: Wednesday, April 28, 2010 8:07 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3

 

I have a potential pitfall for the proposed “Solution B”, the tagging system, in 2.3.  I was working on HP Systems Insight Manager 6.0 this morning for this HP bulletin:
<http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02027185>

From the advisory, we see:
Note:
 HP System Insight Manager version 6.0 for HP-UX contains Namazu v2.0.19
 HP System Insight Manager version 6.0 for Linux contains Namazu v2.0.19
 HP System Insight Manager version 6.0 for Windows contains Namazu v2.0.18

In examining the three target software platforms, HP-UX, Linux, and Windows, there is a very interesting interplay between editions and included software. I’ll express these as CPE names, though they do not appear to exist in the CPE dictionary currently.

cpe:/a:hp:systems_insight_manager:5.1_Windows:-
cpe:/a:hp:systems_insight_manager:5.2_Windows:-
cpe:/a:hp:systems_insight_manager:5.2_Windows:SP1
cpe:/a:hp:systems_insight_manager:5.2_Windows:SP2
cpe:/a:hp:systems_insight_manager:5.3_Windows:-
cpe:/a:hp:systems_insight_manager:5.3_Windows:SP1
cpe:/a:hp:systems_insight_manager:6.0_Windows:-
<http://h18013.www1.hp.com/products/servers/management/hpsim/dl_windows.html>

cpe:/a:hp:systems_insight_manager:5.1_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.1_HP-UX:U1
cpe:/a:hp:systems_insight_manager:5.2_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.2_HP-UX:U1
cpe:/a:hp:systems_insight_manager:5.3_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.3_HP-UX:U1
cpe:/a:hp:systems_insight_manager:6.0_HP-UX:-
<http://h18000.www1.hp.com/products/servers/management/hpsim/dl_hpux.html>

cpe:/a:hp:systems_insight_manager:5.1_Linux:-
cpe:/a:hp:systems_insight_manager:5.2_Linux:-
cpe:/a:hp:systems_insight_manager:5.2_Linux:U1
cpe:/a:hp:systems_insight_manager:5.2_Linux:U2
cpe:/a:hp:systems_insight_manager:5.3_Linux:-
cpe:/a:hp:systems_insight_manager:5.3_Linux:U1
cpe:/a:hp:systems_insight_manager:6.0_Linux:-
<http://h18000.www1.hp.com/products/servers/management/hpsim/dl_linux.html>

So if these sets represent the affected software for this advisory, I’m concerned that the Solution B tagging system, without a structure that requires each component to be accounted for in some way, could mistakenly equate software that is not the same. For example the following are not the same, as HP says that 6.0 for Windows does not contain Namazu 2.0.19:

cpe:/a:hp:systems_insight_manager:6.0_Windows:-
cpe:/a:hp:systems_insight_manager:6.0_HP-UX:-
cpe:/a:hp:systems_insight_manager:6.0_Linux:-

If tagged only with “Systems Insight Manager” and “6.0”, we miss correctly identifying a vulnerability that affects Namazu 2.0.19 (Windows Systems Insight Managers would be unaffected).

Further, if we tag only with “Systems Insight Manager” and “5.2” and “U1”, what do we assume that this means? Windows platform has SP1, not U1. Further, Linux platforms have a “5.2” and “U2”, where HP-UX do not. If the updates are not equivalent between HP-UX and Linux, are “HP-UX” “U1” and “Linux” “U1” the same?

I understand that the current CPE standard does not have to carry a component (and thus the “-” is used), but if we go to a tagging system and do not require a similar “-” tag for each possible tag, we could be incorrectly identifying software on an automated basis.  This example suggests to me that while it may not always be possible to tag things correctly, a vendor’s usage of the same edition names among various target software platforms (in this case, U1 and U2 on HPUX and Linux, versus SP1 and SP2 for Windows, as well as v6.0 for all three but with different included Namazu components) causes potential problems for tagging vs. a structured URI naming scheme.

This differentiation also suggests again that Target Software Platform and Target Hardware Platform should have their own separate components, and not be necessarily shoe-horned into Edition.

Thanks,
Seth Hanford


On 4/22/10 6:20 PM, "Cheikes, Brant A." <bcheikes@...> wrote:

The CPE Core Team, with representatives from MITRE, NIST and the US Department of Defense, has been working actively on the plan for the next release of CPE, v2.3.  The attached roadmap briefing is intended to provide a high level summary of our current thinking and directions.  This will continue to evolve over time as we identify and hash out a variety of technical issues, so please do not consider it fixed and final.  We know it contains gaps and other technical issues.  But we wanted to share this summary sooner rather than later, warts and all, with the community and give you an opportunity to provide feedback.  You can expect more details to get posted over the weeks ahead.  As the concluding chart shows, we are working towards a very challenging 11 June deadline, at which point we’ll be releasing draft specifications for a public comment period.  We encourage you to engage as early as you can.
 
I’d also like to reiterate an invitation to others on the list to join our Core Team.  If you’re prepared to participate in one or two weekly teleconferences of 1-2 hrs in length each (with homework!) and commit to doing so at least through June, please contact me to discuss.
 
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

Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for CPE v2.3

shanford
Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3 Thanks, Paul, that makes sense.

- Seth


On 4/28/10 1:28 PM, "Cichonski, Paul" <paul.cichonski@...> wrote:

Seth,
 
I do not think a move to a “tagging” approach presupposes the removal of required tags/components, nor does it necessarily result in the removal of the ‘-‘.  A tagging approach would simply be a different binding for CPE data.  The primary advantage of this binding is that it separates the product identifier from the meaning  represented by that identifier.  It is still possible to define required tags which must be present within a product data element. For example if the community decides it is necessary we can mandate that all CPEs within the dictionary contain tags representing all of the legacy components (vendor, product, version, update, edition, language).   It is also still possible to use a character like the ‘-‘ to represent data which does not exist for a specific tag of a specific product.  In fact, this approach is actually desired if we are operating under an “Open World Assumption” so that we can explicitly assert that a specific product does not have any data for a specific component.   
 
To give a specific example, the CPE name “
cpe:/a:hp:systems_insight_manager:6.0_Linux:-“ could be represented in a tag-based binding as:
 
<cpe-item id="http://nvd.nist.gov/cpe/product-211">
     <cpe-tag:string-tag name="part"  value="a"/>
     <cpe-tag:string-tag name="vendor"  value="hp"/>
     <cpe-tag:string-tag name="product" value="systems_insight_manager"/>
     <cpe-tag:string-tag name="version" value="6.0_Linux"/>
     <cpe-tag:string-tag name="update" value="-"/>
</cpe-item>
 
We could also easily introduce separate tags to represent the more granular relationships such as “target-hardware”.  In the end the tagging approach is just a different binding that allows us to remove the meaning from the identifier, but it does not change the information that can (or must) be captured.  It actually makes it easier to adjust our model to add more granular relationships since we no longer have to worry about changing the ID syntax, and how that will effect backwards compatibility of IDs.  Also, the problem you mention is still possible using the current URI syntax  since there is nothing stopping CPE name creators from only populating the Vendor, Product, Version components and leaving the rest of the components unpopulated (e.g.
cpe:/a:hp:systems_insight_manager:6.0_Linux).  
 
-Paul

 

From: Seth Hanford [[hidden email]]
Sent: Wednesday, April 28, 2010 8:07 AM
To: CPE-DISCUSSION-LIST@...
Subject: Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3

I have a potential pitfall for the proposed “Solution B”, the tagging system, in 2.3.  I was working on HP Systems Insight Manager 6.0 this morning for this HP bulletin:
<http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02027185>

From the advisory, we see:
Note:
 HP System Insight Manager version 6.0 for HP-UX contains Namazu v2.0.19
 HP System Insight Manager version 6.0 for Linux contains Namazu v2.0.19
 HP System Insight Manager version 6.0 for Windows contains Namazu v2.0.18

In examining the three target software platforms, HP-UX, Linux, and Windows, there is a very interesting interplay between editions and included software. I’ll express these as CPE names, though they do not appear to exist in the CPE dictionary currently.

cpe:/a:hp:systems_insight_manager:5.1_Windows:-
cpe:/a:hp:systems_insight_manager:5.2_Windows:-
cpe:/a:hp:systems_insight_manager:5.2_Windows:SP1
cpe:/a:hp:systems_insight_manager:5.2_Windows:SP2
cpe:/a:hp:systems_insight_manager:5.3_Windows:-
cpe:/a:hp:systems_insight_manager:5.3_Windows:SP1
cpe:/a:hp:systems_insight_manager:6.0_Windows:-
<http://h18013.www1.hp.com/products/servers/management/hpsim/dl_windows.html>

cpe:/a:hp:systems_insight_manager:5.1_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.1_HP-UX:U1
cpe:/a:hp:systems_insight_manager:5.2_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.2_HP-UX:U1
cpe:/a:hp:systems_insight_manager:5.3_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.3_HP-UX:U1
cpe:/a:hp:systems_insight_manager:6.0_HP-UX:-
<http://h18000.www1.hp.com/products/servers/management/hpsim/dl_hpux.html>

cpe:/a:hp:systems_insight_manager:5.1_Linux:-
cpe:/a:hp:systems_insight_manager:5.2_Linux:-
cpe:/a:hp:systems_insight_manager:5.2_Linux:U1
cpe:/a:hp:systems_insight_manager:5.2_Linux:U2
cpe:/a:hp:systems_insight_manager:5.3_Linux:-
cpe:/a:hp:systems_insight_manager:5.3_Linux:U1
cpe:/a:hp:systems_insight_manager:6.0_Linux:-
<http://h18000.www1.hp.com/products/servers/management/hpsim/dl_linux.html>

So if these sets represent the affected software for this advisory, I’m concerned that the Solution B tagging system, without a structure that requires each component to be accounted for in some way, could mistakenly equate software that is not the same. For example the following are not the same, as HP says that 6.0 for Windows does not contain Namazu 2.0.19:

cpe:/a:hp:systems_insight_manager:6.0_Windows:-
cpe:/a:hp:systems_insight_manager:6.0_HP-UX:-
cpe:/a:hp:systems_insight_manager:6.0_Linux:-

If tagged only with “Systems Insight Manager” and “6.0”, we miss correctly identifying a vulnerability that affects Namazu 2.0.19 (Windows Systems Insight Managers would be unaffected).

Further, if we tag only with “Systems Insight Manager” and “5.2” and “U1”, what do we assume that this means? Windows platform has SP1, not U1. Further, Linux platforms have a “5.2” and “U2”, where HP-UX do not. If the updates are not equivalent between HP-UX and Linux, are “HP-UX” “U1” and “Linux” “U1” the same?

I understand that the current CPE standard does not have to carry a component (and thus the “-” is used), but if we go to a tagging system and do not require a similar “-” tag for each possible tag, we could be incorrectly identifying software on an automated basis.  This example suggests to me that while it may not always be possible to tag things correctly, a vendor’s usage of the same edition names among various target software platforms (in this case, U1 and U2 on HPUX and Linux, versus SP1 and SP2 for Windows, as well as v6.0 for all three but with different included Namazu components) causes potential problems for tagging vs. a structured URI naming scheme.

This differentiation also suggests again that Target Software Platform and Target Hardware Platform should have their own separate components, and not be necessarily shoe-horned into Edition.

Thanks,
Seth Hanford


On 4/22/10 6:20 PM, "Cheikes, Brant A." <bcheikes@...> wrote:
The CPE Core Team, with representatives from MITRE, NIST and the US Department of Defense, has been working actively on the plan for the next release of CPE, v2.3.  The attached roadmap briefing is intended to provide a high level summary of our current thinking and directions.  This will continue to evolve over time as we identify and hash out a variety of technical issues, so please do not consider it fixed and final.  We know it contains gaps and other technical issues.  But we wanted to share this summary sooner rather than later, warts and all, with the community and give you an opportunity to provide feedback.  You can expect more details to get posted over the weeks ahead.  As the concluding chart shows, we are working towards a very challenging 11 June deadline, at which point we’ll be releasing draft specifications for a public comment period.  We encourage you to engage as early as you can.
 
I’d also like to reiterate an invitation to others on the list to join our Core Team.  If you’re prepared to participate in one or two weekly teleconferences of 1-2 hrs in length each (with homework!) and commit to doing so at least through June, please contact me to discuss.
 
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


Reply | Threaded
Open this post in threaded view
|

Re: Roadmap for CPE v2.3

Wolfkiel, Joseph
Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3

Once we go to a tagged approach, I think      <cpe-tag:string-tag name="update" value="-"/> could also be expressed as      <cpe-tag:string-tag name="update" value=""/>.  It was the CPE assumption that null=wildcard that required the “-“ character.  In a tagged expression, a null tag value can be expressed as “” where an omitted tag will say that particular tag will not be used in matching or was not captured as part of the name.  My preference would be for the “-“ usage to be deprecated once we escape from the URI format.

 

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

From: Seth Hanford [mailto:[hidden email]]
Sent: Wednesday, April 28, 2010 3:07 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3

 

Thanks, Paul, that makes sense.

- Seth


On 4/28/10 1:28 PM, "Cichonski, Paul" <paul.cichonski@...> wrote:

Seth,
 
I do not think a move to a “tagging” approach presupposes the removal of required tags/components, nor does it necessarily result in the removal of the ‘-‘.  A tagging approach would simply be a different binding for CPE data.  The primary advantage of this binding is that it separates the product identifier from the meaning  represented by that identifier.  It is still possible to define required tags which must be present within a product data element. For example if the community decides it is necessary we can mandate that all CPEs within the dictionary contain tags representing all of the legacy components (vendor, product, version, update, edition, language).   It is also still possible to use a character like the ‘-‘ to represent data which does not exist for a specific tag of a specific product.  In fact, this approach is actually desired if we are operating under an “Open World Assumption” so that we can explicitly assert that a specific product does not have any data for a specific component.   
 
To give a specific example, the CPE name “
cpe:/a:hp:systems_insight_manager:6.0_Linux:-“ could be represented in a tag-based binding as:
 
<cpe-item id="http://nvd.nist.gov/cpe/product-211">
     <cpe-tag:string-tag name="part"  value="a"/>
     <cpe-tag:string-tag name="vendor"  value="hp"/>
     <cpe-tag:string-tag name="product" value="systems_insight_manager"/>
     <cpe-tag:string-tag name="version" value="6.0_Linux"/>
     <cpe-tag:string-tag name="update" value="-"/>
</cpe-item>
 
We could also easily introduce separate tags to represent the more granular relationships such as “target-hardware”.  In the end the tagging approach is just a different binding that allows us to remove the meaning from the identifier, but it does not change the information that can (or must) be captured.  It actually makes it easier to adjust our model to add more granular relationships since we no longer have to worry about changing the ID syntax, and how that will effect backwards compatibility of IDs.  Also, the problem you mention is still possible using the current URI syntax  since there is nothing stopping CPE name creators from only populating the Vendor, Product, Version components and leaving the rest of the components unpopulated (e.g.
cpe:/a:hp:systems_insight_manager:6.0_Linux).  
 
-Paul

 

From: Seth Hanford [[hidden email]]
Sent: Wednesday, April 28, 2010 8:07 AM
To: CPE-DISCUSSION-LIST@...
Subject: Re: [CPE-DISCUSSION-LIST] Roadmap for CPE v2.3

I have a potential pitfall for the proposed “Solution B”, the tagging system, in 2.3.  I was working on HP Systems Insight Manager 6.0 this morning for this HP bulletin:
<http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02027185>

From the advisory, we see:
Note:
 HP System Insight Manager version 6.0 for HP-UX contains Namazu v2.0.19
 HP System Insight Manager version 6.0 for Linux contains Namazu v2.0.19
 HP System Insight Manager version 6.0 for Windows contains Namazu v2.0.18

In examining the three target software platforms, HP-UX, Linux, and Windows, there is a very interesting interplay between editions and included software. I’ll express these as CPE names, though they do not appear to exist in the CPE dictionary currently.

cpe:/a:hp:systems_insight_manager:5.1_Windows:-
cpe:/a:hp:systems_insight_manager:5.2_Windows:-
cpe:/a:hp:systems_insight_manager:5.2_Windows:SP1
cpe:/a:hp:systems_insight_manager:5.2_Windows:SP2
cpe:/a:hp:systems_insight_manager:5.3_Windows:-
cpe:/a:hp:systems_insight_manager:5.3_Windows:SP1
cpe:/a:hp:systems_insight_manager:6.0_Windows:-
<http://h18013.www1.hp.com/products/servers/management/hpsim/dl_windows.html>

cpe:/a:hp:systems_insight_manager:5.1_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.1_HP-UX:U1
cpe:/a:hp:systems_insight_manager:5.2_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.2_HP-UX:U1
cpe:/a:hp:systems_insight_manager:5.3_HP-UX:-
cpe:/a:hp:systems_insight_manager:5.3_HP-UX:U1
cpe:/a:hp:systems_insight_manager:6.0_HP-UX:-
<http://h18000.www1.hp.com/products/servers/management/hpsim/dl_hpux.html>

cpe:/a:hp:systems_insight_manager:5.1_Linux:-
cpe:/a:hp:systems_insight_manager:5.2_Linux:-
cpe:/a:hp:systems_insight_manager:5.2_Linux:U1
cpe:/a:hp:systems_insight_manager:5.2_Linux:U2
cpe:/a:hp:systems_insight_manager:5.3_Linux:-
cpe:/a:hp:systems_insight_manager:5.3_Linux:U1
cpe:/a:hp:systems_insight_manager:6.0_Linux:-
<http://h18000.www1.hp.com/products/servers/management/hpsim/dl_linux.html>

So if these sets represent the affected software for this advisory, I’m concerned that the Solution B tagging system, without a structure that requires each component to be accounted for in some way, could mistakenly equate software that is not the same. For example the following are not the same, as HP says that 6.0 for Windows does not contain Namazu 2.0.19:

cpe:/a:hp:systems_insight_manager:6.0_Windows:-
cpe:/a:hp:systems_insight_manager:6.0_HP-UX:-
cpe:/a:hp:systems_insight_manager:6.0_Linux:-

If tagged only with “Systems Insight Manager” and “6.0”, we miss correctly identifying a vulnerability that affects Namazu 2.0.19 (Windows Systems Insight Managers would be unaffected).

Further, if we tag only with “Systems Insight Manager” and “5.2” and “U1”, what do we assume that this means? Windows platform has SP1, not U1. Further, Linux platforms have a “5.2” and “U2”, where HP-UX do not. If the updates are not equivalent between HP-UX and Linux, are “HP-UX” “U1” and “Linux” “U1” the same?

I understand that the current CPE standard does not have to carry a component (and thus the “-” is used), but if we go to a tagging system and do not require a similar “-” tag for each possible tag, we could be incorrectly identifying software on an automated basis.  This example suggests to me that while it may not always be possible to tag things correctly, a vendor’s usage of the same edition names among various target software platforms (in this case, U1 and U2 on HPUX and Linux, versus SP1 and SP2 for Windows, as well as v6.0 for all three but with different included Namazu components) causes potential problems for tagging vs. a structured URI naming scheme.

This differentiation also suggests again that Target Software Platform and Target Hardware Platform should have their own separate components, and not be necessarily shoe-horned into Edition.

Thanks,
Seth Hanford


On 4/22/10 6:20 PM, "Cheikes, Brant A." <bcheikes@...> wrote:
The CPE Core Team, with representatives from MITRE, NIST and the US Department of Defense, has been working actively on the plan for the next release of CPE, v2.3.  The attached roadmap briefing is intended to provide a high level summary of our current thinking and directions.  This will continue to evolve over time as we identify and hash out a variety of technical issues, so please do not consider it fixed and final.  We know it contains gaps and other technical issues.  But we wanted to share this summary sooner rather than later, warts and all, with the community and give you an opportunity to provide feedback.  You can expect more details to get posted over the weeks ahead.  As the concluding chart shows, we are working towards a very challenging 11 June deadline, at which point we’ll be releasing draft specifications for a public comment period.  We encourage you to engage as early as you can.
 
I’d also like to reiterate an invitation to others on the list to join our Core Team.  If you’re prepared to participate in one or two weekly teleconferences of 1-2 hrs in length each (with homework!) and commit to doing so at least through June, please contact me to discuss.
 
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


smime.p7s (6K) Download Attachment