Microsoft OS Naming Issue

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

Microsoft OS Naming Issue

Andrew Buttner
Administrator
** reply by Friday June 5th **

The creation of CPE Names for the different Microsoft operating systems has been a source of discussion since the beginning of CPE.  In October 2007 the issue was discussed in depth and it was decided to that these names should be based off of the commonly known marketing names.  We have tried this approach for the past year and a half but some issues still remain.

We are realizing that names based off the marketing names are hard to manage as marketing  names change frequently.  Marketing names also lead to incorrect CPE Matching as a marketing name may stay the same but the underlying code may change.  Or the marketing name may change even if the code doesn't.

I'd like to formally bring this up this issue to the CPE community again and make sure we are still going down the correct path.  Obviously, one option will be to keep going down the current path.  But other options would require changes to the current names.  This would mean a lot of depreciation and potential vendor work to readjust their mapping.  The costs of this change may not be worth the benefits.  Unfortunately I do not see the issues and/or discussions surrounding Microsoft names subsiding until we fix the root of the problem.  So at some point I think we are going to have to make some type of change.

Some examples of the issues we currently face:

- Windows XP 64-Bit Edition, Version 2003 which is actually based off of the code for Windows Server 2003

- determining which CPE Name to use being difficult as the technical information returned from a system query is not associated with any CPE Name

- inconsistencies when dealing with beta and pre-releases, for example the current Windows 7 betas and if the OS marketing name will actually be Windows 7

- difficulty determining if certain updates/editions are really different versions, for example the R2 releases

- inconsistency between operating system and application naming as many of the Microsoft application names follow the technical name  (see Internet Explorer)

Below are two options that I see as possible paths forward.  I urge everyone to share their opinion as we can only understand the best course by knowing how it affects the entire community.  If you have other ideas, please don't be afraid to share them as well.

Discussion on this issue will end on Friday June 5th (3 weeks) at which time a decision will be made based on community consensus.

----------------------------------
OPTION 1
----------------------------------

Keep things the way they currently are.  Although not perfect, the current way of creating CPE Names for Microsoft operating systems is a good balance between technical correctness and human understanding.  In addition, the work required to deprecate the current Microsoft CPE Names and remap to new names would not be worth the benefits of the change.

The CPE Specification should be updated to clarify how create CPE Names for Microsoft operating systems and platforms that exhibit related properties.

----------------------------------
OPTION 2
----------------------------------

In order to put to bed the continued discussions on Microsoft names we should change how we create these names.  We should leverage the internal version of the operating system and use that in the version component.  In a way, this is more true to the current CPE Specification.

The <title> element in the dictionary would be used to hold the marketing name associated with each different version.  For example:

cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003 SP2

Note that this option would require deprecating all the existing Microsoft names in the CPE dictionary.  But this option better aligns with the way the specification is currently written.

----------------------------------
----------------------------------

Again, I urge everyone to share their opinion by Friday June 5th.


Thanks
Drew




---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Andrew Buttner
Administrator
I encourage anyone with an opinion on this matter to share their thoughts so that the correct decision can be made going forward.  I personally think that a change to the current Microsoft Windows CPE Names would be the correct way forward.  I think the change would make technical sense and it will bring the Windows names into alignment with the specification.  This of course would mean deprecating all the existing names.  I am very interested to see if you agree with this position, or if you think that this might not be the smartest move to do at this time.

Thanks
Drew




>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, May 18, 2009 7:43 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>
>** reply by Friday June 5th **
>
>The creation of CPE Names for the different Microsoft operating systems
>has been a source of discussion since the beginning of CPE.  In October
>2007 the issue was discussed in depth and it was decided to that these
>names should be based off of the commonly known marketing names.  We
>have tried this approach for the past year and a half but some issues
>still remain.
>
>We are realizing that names based off the marketing names are hard to
>manage as marketing  names change frequently.  Marketing names also lead
>to incorrect CPE Matching as a marketing name may stay the same but the
>underlying code may change.  Or the marketing name may change even if
>the code doesn't.
>
>I'd like to formally bring this up this issue to the CPE community again
>and make sure we are still going down the correct path.  Obviously, one
>option will be to keep going down the current path.  But other options
>would require changes to the current names.  This would mean a lot of
>depreciation and potential vendor work to readjust their mapping.  The
>costs of this change may not be worth the benefits.  Unfortunately I do
>not see the issues and/or discussions surrounding Microsoft names
>subsiding until we fix the root of the problem.  So at some point I
>think we are going to have to make some type of change.
>
>Some examples of the issues we currently face:
>
>- Windows XP 64-Bit Edition, Version 2003 which is actually based off of
>the code for Windows Server 2003
>
>- determining which CPE Name to use being difficult as the technical
>information returned from a system query is not associated with any CPE
>Name
>
>- inconsistencies when dealing with beta and pre-releases, for example
>the current Windows 7 betas and if the OS marketing name will actually
>be Windows 7
>
>- difficulty determining if certain updates/editions are really
>different versions, for example the R2 releases
>
>- inconsistency between operating system and application naming as many
>of the Microsoft application names follow the technical name  (see
>Internet Explorer)
>
>Below are two options that I see as possible paths forward.  I urge
>everyone to share their opinion as we can only understand the best
>course by knowing how it affects the entire community.  If you have
>other ideas, please don't be afraid to share them as well.
>
>Discussion on this issue will end on Friday June 5th (3 weeks) at which
>time a decision will be made based on community consensus.
>
>----------------------------------
>OPTION 1
>----------------------------------
>
>Keep things the way they currently are.  Although not perfect, the
>current way of creating CPE Names for Microsoft operating systems is a
>good balance between technical correctness and human understanding.  In
>addition, the work required to deprecate the current Microsoft CPE Names
>and remap to new names would not be worth the benefits of the change.
>
>The CPE Specification should be updated to clarify how create CPE Names
>for Microsoft operating systems and platforms that exhibit related
>properties.
>
>----------------------------------
>OPTION 2
>----------------------------------
>
>In order to put to bed the continued discussions on Microsoft names we
>should change how we create these names.  We should leverage the
>internal version of the operating system and use that in the version
>component.  In a way, this is more true to the current CPE
>Specification.
>
>The <title> element in the dictionary would be used to hold the
>marketing name associated with each different version.  For example:
>
>cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
>cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
>cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
>cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
>cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003
>SP2
>
>Note that this option would require deprecating all the existing
>Microsoft names in the CPE dictionary.  But this option better aligns
>with the way the specification is currently written.
>
>----------------------------------
>----------------------------------
>
>Again, I urge everyone to share their opinion by Friday June 5th.
>
>
>Thanks
>Drew
>
>
>
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Robert Neuman

Andrew,  I agree option 2 and feel that references should be by mfr:product:build/version:sp instead of nomenclature.  This should be a standard format for the cpe.  







Andrew Buttner wrote
I encourage anyone with an opinion on this matter to share their thoughts so that the correct decision can be made going forward.  I personally think that a change to the current Microsoft Windows CPE Names would be the correct way forward.  I think the change would make technical sense and it will bring the Windows names into alignment with the specification.  This of course would mean deprecating all the existing names.  I am very interested to see if you agree with this position, or if you think that this might not be the smartest move to do at this time.

Thanks
Drew




>-----Original Message-----
>From: Buttner, Drew [mailto:abuttner@MITRE.ORG]
>Sent: Monday, May 18, 2009 7:43 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>
>** reply by Friday June 5th **
>
>The creation of CPE Names for the different Microsoft operating systems
>has been a source of discussion since the beginning of CPE.  In October
>2007 the issue was discussed in depth and it was decided to that these
>names should be based off of the commonly known marketing names.  We
>have tried this approach for the past year and a half but some issues
>still remain.
>
>We are realizing that names based off the marketing names are hard to
>manage as marketing  names change frequently.  Marketing names also lead
>to incorrect CPE Matching as a marketing name may stay the same but the
>underlying code may change.  Or the marketing name may change even if
>the code doesn't.
>
>I'd like to formally bring this up this issue to the CPE community again
>and make sure we are still going down the correct path.  Obviously, one
>option will be to keep going down the current path.  But other options
>would require changes to the current names.  This would mean a lot of
>depreciation and potential vendor work to readjust their mapping.  The
>costs of this change may not be worth the benefits.  Unfortunately I do
>not see the issues and/or discussions surrounding Microsoft names
>subsiding until we fix the root of the problem.  So at some point I
>think we are going to have to make some type of change.
>
>Some examples of the issues we currently face:
>
>- Windows XP 64-Bit Edition, Version 2003 which is actually based off of
>the code for Windows Server 2003
>
>- determining which CPE Name to use being difficult as the technical
>information returned from a system query is not associated with any CPE
>Name
>
>- inconsistencies when dealing with beta and pre-releases, for example
>the current Windows 7 betas and if the OS marketing name will actually
>be Windows 7
>
>- difficulty determining if certain updates/editions are really
>different versions, for example the R2 releases
>
>- inconsistency between operating system and application naming as many
>of the Microsoft application names follow the technical name  (see
>Internet Explorer)
>
>Below are two options that I see as possible paths forward.  I urge
>everyone to share their opinion as we can only understand the best
>course by knowing how it affects the entire community.  If you have
>other ideas, please don't be afraid to share them as well.
>
>Discussion on this issue will end on Friday June 5th (3 weeks) at which
>time a decision will be made based on community consensus.
>
>----------------------------------
>OPTION 1
>----------------------------------
>
>Keep things the way they currently are.  Although not perfect, the
>current way of creating CPE Names for Microsoft operating systems is a
>good balance between technical correctness and human understanding.  In
>addition, the work required to deprecate the current Microsoft CPE Names
>and remap to new names would not be worth the benefits of the change.
>
>The CPE Specification should be updated to clarify how create CPE Names
>for Microsoft operating systems and platforms that exhibit related
>properties.
>
>----------------------------------
>OPTION 2
>----------------------------------
>
>In order to put to bed the continued discussions on Microsoft names we
>should change how we create these names.  We should leverage the
>internal version of the operating system and use that in the version
>component.  In a way, this is more true to the current CPE
>Specification.
>
>The <title> element in the dictionary would be used to hold the
>marketing name associated with each different version.  For example:
>
>cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
>cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
>cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
>cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
>cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003
>SP2
>
>Note that this option would require deprecating all the existing
>Microsoft names in the CPE dictionary.  But this option better aligns
>with the way the specification is currently written.
>
>----------------------------------
>----------------------------------
>
>Again, I urge everyone to share their opinion by Friday June 5th.
>
>
>Thanks
>Drew
>
>
>
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>abuttner@mitre.org
>781-271-3515
Robert Neuman
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Thomas Jones
Option 2 has my vote as well.

Sent from my iPhone

On May 27, 2009, at 8:09 AM, Robert Neuman <[hidden email]> wrote:

> Andrew,  I agree option 2 and feel that references should be by
> mfr:product:build/version:sp instead of nomenclature.  This should  
> be a
> standard format for the cpe.
>
>
>
>
>
>
>
>
> Andrew Buttner wrote:
>>
>> I encourage anyone with an opinion on this matter to share their  
>> thoughts
>> so that the correct decision can be made going forward.  I personally
>> think that a change to the current Microsoft Windows CPE Names  
>> would be
>> the correct way forward.  I think the change would make technical  
>> sense
>> and it will bring the Windows names into alignment with the  
>> specification.
>> This of course would mean deprecating all the existing names.  I am  
>> very
>> interested to see if you agree with this position, or if you think  
>> that
>> this might not be the smartest move to do at this time.
>>
>> Thanks
>> Drew
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Buttner, Drew [mailto:[hidden email]]
>>> Sent: Monday, May 18, 2009 7:43 AM
>>> To: cpe-discussion-list CPE Community Forum
>>> Subject: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>>>
>>> ** reply by Friday June 5th **
>>>
>>> The creation of CPE Names for the different Microsoft operating  
>>> systems
>>> has been a source of discussion since the beginning of CPE.  In  
>>> October
>>> 2007 the issue was discussed in depth and it was decided to that  
>>> these
>>> names should be based off of the commonly known marketing names.  We
>>> have tried this approach for the past year and a half but some  
>>> issues
>>> still remain.
>>>
>>> We are realizing that names based off the marketing names are hard  
>>> to
>>> manage as marketing  names change frequently.  Marketing names  
>>> also lead
>>> to incorrect CPE Matching as a marketing name may stay the same  
>>> but the
>>> underlying code may change.  Or the marketing name may change even  
>>> if
>>> the code doesn't.
>>>
>>> I'd like to formally bring this up this issue to the CPE community  
>>> again
>>> and make sure we are still going down the correct path.  
>>> Obviously, one
>>> option will be to keep going down the current path.  But other  
>>> options
>>> would require changes to the current names.  This would mean a lot  
>>> of
>>> depreciation and potential vendor work to readjust their mapping.  
>>> The
>>> costs of this change may not be worth the benefits.  Unfortunately  
>>> I do
>>> not see the issues and/or discussions surrounding Microsoft names
>>> subsiding until we fix the root of the problem.  So at some point I
>>> think we are going to have to make some type of change.
>>>
>>> Some examples of the issues we currently face:
>>>
>>> - Windows XP 64-Bit Edition, Version 2003 which is actually based  
>>> off of
>>> the code for Windows Server 2003
>>>
>>> - determining which CPE Name to use being difficult as the technical
>>> information returned from a system query is not associated with  
>>> any CPE
>>> Name
>>>
>>> - inconsistencies when dealing with beta and pre-releases, for  
>>> example
>>> the current Windows 7 betas and if the OS marketing name will  
>>> actually
>>> be Windows 7
>>>
>>> - difficulty determining if certain updates/editions are really
>>> different versions, for example the R2 releases
>>>
>>> - inconsistency between operating system and application naming as  
>>> many
>>> of the Microsoft application names follow the technical name  (see
>>> Internet Explorer)
>>>
>>> Below are two options that I see as possible paths forward.  I urge
>>> everyone to share their opinion as we can only understand the best
>>> course by knowing how it affects the entire community.  If you have
>>> other ideas, please don't be afraid to share them as well.
>>>
>>> Discussion on this issue will end on Friday June 5th (3 weeks) at  
>>> which
>>> time a decision will be made based on community consensus.
>>>
>>> ----------------------------------
>>> OPTION 1
>>> ----------------------------------
>>>
>>> Keep things the way they currently are.  Although not perfect, the
>>> current way of creating CPE Names for Microsoft operating systems  
>>> is a
>>> good balance between technical correctness and human  
>>> understanding.  In
>>> addition, the work required to deprecate the current Microsoft CPE  
>>> Names
>>> and remap to new names would not be worth the benefits of the  
>>> change.
>>>
>>> The CPE Specification should be updated to clarify how create CPE  
>>> Names
>>> for Microsoft operating systems and platforms that exhibit related
>>> properties.
>>>
>>> ----------------------------------
>>> OPTION 2
>>> ----------------------------------
>>>
>>> In order to put to bed the continued discussions on Microsoft  
>>> names we
>>> should change how we create these names.  We should leverage the
>>> internal version of the operating system and use that in the version
>>> component.  In a way, this is more true to the current CPE
>>> Specification.
>>>
>>> The <title> element in the dictionary would be used to hold the
>>> marketing name associated with each different version.  For example:
>>>
>>> cpe:/o:microsoft:windows:5.1.2600 -  Microsoft Windows XP
>>> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
>>> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
>>> cpe:/o:microsoft:windows:5.2.3790 -  Microsoft Windows Server 2003
>>> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows  
>>> Server 2003
>>> SP2
>>>
>>> Note that this option would require deprecating all the existing
>>> Microsoft names in the CPE dictionary.  But this option better  
>>> aligns
>>> with the way the specification is currently written.
>>>
>>> ----------------------------------
>>> ----------------------------------
>>>
>>> Again, I urge everyone to share their opinion by Friday June 5th.
>>>
>>>
>>> Thanks
>>> Drew
>>>
>>>
>>>
>>>
>>> ---------
>>>
>>> Andrew Buttner
>>> The MITRE Corporation
>>> [hidden email]
>>> 781-271-3515
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/Microsoft-OS-Naming-Issue-tp2932305p2980950.html
> Sent from the CPE - Common Platform Enumeration mailing list archive  
> at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Wergin, Charles [USA]
In reply to this post by Andrew Buttner
I am in full support of Option #2, provided there is a way to
differentiate between overlaps.  For instance, if a version number is
the same across multiple editions ( I think this is the case with
Windows Vista 32-bit and 64-bit editions), we will still use the edition
field, correct?

Chuck Wergin
National Vulnerability Database
nvd.nist.gov



-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Wednesday, May 27, 2009 6:52 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I encourage anyone with an opinion on this matter to share their
thoughts so that the correct decision can be made going forward.  I
personally think that a change to the current Microsoft Windows CPE
Names would be the correct way forward.  I think the change would make
technical sense and it will bring the Windows names into alignment with
the specification.  This of course would mean deprecating all the
existing names.  I am very interested to see if you agree with this
position, or if you think that this might not be the smartest move to do
at this time.

Thanks
Drew




>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, May 18, 2009 7:43 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>
>** reply by Friday June 5th **
>
>The creation of CPE Names for the different Microsoft operating systems
>has been a source of discussion since the beginning of CPE.  In October
>2007 the issue was discussed in depth and it was decided to that these
>names should be based off of the commonly known marketing names.  We
>have tried this approach for the past year and a half but some issues
>still remain.
>
>We are realizing that names based off the marketing names are hard to
>manage as marketing  names change frequently.  Marketing names also
lead
>to incorrect CPE Matching as a marketing name may stay the same but the
>underlying code may change.  Or the marketing name may change even if
>the code doesn't.
>
>I'd like to formally bring this up this issue to the CPE community
again

>and make sure we are still going down the correct path.  Obviously, one
>option will be to keep going down the current path.  But other options
>would require changes to the current names.  This would mean a lot of
>depreciation and potential vendor work to readjust their mapping.  The
>costs of this change may not be worth the benefits.  Unfortunately I do
>not see the issues and/or discussions surrounding Microsoft names
>subsiding until we fix the root of the problem.  So at some point I
>think we are going to have to make some type of change.
>
>Some examples of the issues we currently face:
>
>- Windows XP 64-Bit Edition, Version 2003 which is actually based off
of

>the code for Windows Server 2003
>
>- determining which CPE Name to use being difficult as the technical
>information returned from a system query is not associated with any CPE
>Name
>
>- inconsistencies when dealing with beta and pre-releases, for example
>the current Windows 7 betas and if the OS marketing name will actually
>be Windows 7
>
>- difficulty determining if certain updates/editions are really
>different versions, for example the R2 releases
>
>- inconsistency between operating system and application naming as many
>of the Microsoft application names follow the technical name  (see
>Internet Explorer)
>
>Below are two options that I see as possible paths forward.  I urge
>everyone to share their opinion as we can only understand the best
>course by knowing how it affects the entire community.  If you have
>other ideas, please don't be afraid to share them as well.
>
>Discussion on this issue will end on Friday June 5th (3 weeks) at which
>time a decision will be made based on community consensus.
>
>----------------------------------
>OPTION 1
>----------------------------------
>
>Keep things the way they currently are.  Although not perfect, the
>current way of creating CPE Names for Microsoft operating systems is a
>good balance between technical correctness and human understanding.  In
>addition, the work required to deprecate the current Microsoft CPE
Names

>and remap to new names would not be worth the benefits of the change.
>
>The CPE Specification should be updated to clarify how create CPE Names
>for Microsoft operating systems and platforms that exhibit related
>properties.
>
>----------------------------------
>OPTION 2
>----------------------------------
>
>In order to put to bed the continued discussions on Microsoft names we
>should change how we create these names.  We should leverage the
>internal version of the operating system and use that in the version
>component.  In a way, this is more true to the current CPE
>Specification.
>
>The <title> element in the dictionary would be used to hold the
>marketing name associated with each different version.  For example:
>
>cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
>cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
>cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
>cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
>cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server
2003

>SP2
>
>Note that this option would require deprecating all the existing
>Microsoft names in the CPE dictionary.  But this option better aligns
>with the way the specification is currently written.
>
>----------------------------------
>----------------------------------
>
>Again, I urge everyone to share their opinion by Friday June 5th.
>
>
>Thanks
>Drew
>
>
>
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Andrew Buttner
Administrator
I think is a very interesting case.  If it is indeed the case that a piece of software (i.e. codebase) is the same say for both 32-bit and 64-bit (as opposed to two different code bases or editions), yet it is marketed under two different names to accomplish a business goal, then how should we treat it?  In a way this issue is around regardless of where we go with Microsoft OS names.

Put another way, how do we handle the case when a given platform type has more than one title that it is commonly referred to by?  

Should we have two different CPE Names, one for each marketed version (or known name)?  Or should there be one CPE Name and we start allowing multiple titles to be associated with a CPE Name?  If we choose the later, how would a user know which title they should use?

This seems related to the alias issue.

Thoughts?



>-----Original Message-----
>From: Wergin, Charles [USA] [mailto:[hidden email]]
>Sent: Wednesday, May 27, 2009 2:09 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>
>I am in full support of Option #2, provided there is a way to
>differentiate between overlaps.  For instance, if a version number is
>the same across multiple editions ( I think this is the case with
>Windows Vista 32-bit and 64-bit editions), we will still use the edition
>field, correct?
>
>Chuck Wergin
>National Vulnerability Database
>nvd.nist.gov
>
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Wednesday, May 27, 2009 6:52 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>
>I encourage anyone with an opinion on this matter to share their
>thoughts so that the correct decision can be made going forward.  I
>personally think that a change to the current Microsoft Windows CPE
>Names would be the correct way forward.  I think the change would make
>technical sense and it will bring the Windows names into alignment with
>the specification.  This of course would mean deprecating all the
>existing names.  I am very interested to see if you agree with this
>position, or if you think that this might not be the smartest move to do
>at this time.
>
>Thanks
>Drew
>
>
>
>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Monday, May 18, 2009 7:43 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>>
>>** reply by Friday June 5th **
>>
>>The creation of CPE Names for the different Microsoft operating systems
>>has been a source of discussion since the beginning of CPE.  In October
>>2007 the issue was discussed in depth and it was decided to that these
>>names should be based off of the commonly known marketing names.  We
>>have tried this approach for the past year and a half but some issues
>>still remain.
>>
>>We are realizing that names based off the marketing names are hard to
>>manage as marketing  names change frequently.  Marketing names also
>lead
>>to incorrect CPE Matching as a marketing name may stay the same but the
>>underlying code may change.  Or the marketing name may change even if
>>the code doesn't.
>>
>>I'd like to formally bring this up this issue to the CPE community
>again
>>and make sure we are still going down the correct path.  Obviously, one
>>option will be to keep going down the current path.  But other options
>>would require changes to the current names.  This would mean a lot of
>>depreciation and potential vendor work to readjust their mapping.  The
>>costs of this change may not be worth the benefits.  Unfortunately I do
>>not see the issues and/or discussions surrounding Microsoft names
>>subsiding until we fix the root of the problem.  So at some point I
>>think we are going to have to make some type of change.
>>
>>Some examples of the issues we currently face:
>>
>>- Windows XP 64-Bit Edition, Version 2003 which is actually based off
>of
>>the code for Windows Server 2003
>>
>>- determining which CPE Name to use being difficult as the technical
>>information returned from a system query is not associated with any CPE
>>Name
>>
>>- inconsistencies when dealing with beta and pre-releases, for example
>>the current Windows 7 betas and if the OS marketing name will actually
>>be Windows 7
>>
>>- difficulty determining if certain updates/editions are really
>>different versions, for example the R2 releases
>>
>>- inconsistency between operating system and application naming as many
>>of the Microsoft application names follow the technical name  (see
>>Internet Explorer)
>>
>>Below are two options that I see as possible paths forward.  I urge
>>everyone to share their opinion as we can only understand the best
>>course by knowing how it affects the entire community.  If you have
>>other ideas, please don't be afraid to share them as well.
>>
>>Discussion on this issue will end on Friday June 5th (3 weeks) at which
>>time a decision will be made based on community consensus.
>>
>>----------------------------------
>>OPTION 1
>>----------------------------------
>>
>>Keep things the way they currently are.  Although not perfect, the
>>current way of creating CPE Names for Microsoft operating systems is a
>>good balance between technical correctness and human understanding.  In
>>addition, the work required to deprecate the current Microsoft CPE
>Names
>>and remap to new names would not be worth the benefits of the change.
>>
>>The CPE Specification should be updated to clarify how create CPE Names
>>for Microsoft operating systems and platforms that exhibit related
>>properties.
>>
>>----------------------------------
>>OPTION 2
>>----------------------------------
>>
>>In order to put to bed the continued discussions on Microsoft names we
>>should change how we create these names.  We should leverage the
>>internal version of the operating system and use that in the version
>>component.  In a way, this is more true to the current CPE
>>Specification.
>>
>>The <title> element in the dictionary would be used to hold the
>>marketing name associated with each different version.  For example:
>>
>>cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
>>cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
>>cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
>>cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
>>cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server
>2003
>>SP2
>>
>>Note that this option would require deprecating all the existing
>>Microsoft names in the CPE dictionary.  But this option better aligns
>>with the way the specification is currently written.
>>
>>----------------------------------
>>----------------------------------
>>
>>Again, I urge everyone to share their opinion by Friday June 5th.
>>
>>
>>Thanks
>>Drew
>>
>>
>>
>>
>>---------
>>
>>Andrew Buttner
>>The MITRE Corporation
>>[hidden email]
>>781-271-3515
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Sudhir Gandhe-3
Note that both Windows Server 2003 and Windows XP Professional x64 have the same build number 5.2.3790. We need make sure that each is assigned a unique CPE identifier.


Sudhir

On Wed, May 27, 2009 at 2:20 PM, Buttner, Drew <[hidden email]> wrote:
I think is a very interesting case.  If it is indeed the case that a piece of software (i.e. codebase) is the same say for both 32-bit and 64-bit (as opposed to two different code bases or editions), yet it is marketed under two different names to accomplish a business goal, then how should we treat it?  In a way this issue is around regardless of where we go with Microsoft OS names.

Put another way, how do we handle the case when a given platform type has more than one title that it is commonly referred to by?

Should we have two different CPE Names, one for each marketed version (or known name)?  Or should there be one CPE Name and we start allowing multiple titles to be associated with a CPE Name?  If we choose the later, how would a user know which title they should use?

This seems related to the alias issue.

Thoughts?



>-----Original Message-----
>From: Wergin, Charles [USA] [mailto:[hidden email]]
>Sent: Wednesday, May 27, 2009 2:09 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>
>I am in full support of Option #2, provided there is a way to
>differentiate between overlaps.  For instance, if a version number is
>the same across multiple editions ( I think this is the case with
>Windows Vista 32-bit and 64-bit editions), we will still use the edition
>field, correct?
>
>Chuck Wergin
>National Vulnerability Database
>nvd.nist.gov
>
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Wednesday, May 27, 2009 6:52 AM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>
>I encourage anyone with an opinion on this matter to share their
>thoughts so that the correct decision can be made going forward.  I
>personally think that a change to the current Microsoft Windows CPE
>Names would be the correct way forward.  I think the change would make
>technical sense and it will bring the Windows names into alignment with
>the specification.  This of course would mean deprecating all the
>existing names.  I am very interested to see if you agree with this
>position, or if you think that this might not be the smartest move to do
>at this time.
>
>Thanks
>Drew
>
>
>
>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Monday, May 18, 2009 7:43 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>>
>>** reply by Friday June 5th **
>>
>>The creation of CPE Names for the different Microsoft operating systems
>>has been a source of discussion since the beginning of CPE.  In October
>>2007 the issue was discussed in depth and it was decided to that these
>>names should be based off of the commonly known marketing names.  We
>>have tried this approach for the past year and a half but some issues
>>still remain.
>>
>>We are realizing that names based off the marketing names are hard to
>>manage as marketing  names change frequently.  Marketing names also
>lead
>>to incorrect CPE Matching as a marketing name may stay the same but the
>>underlying code may change.  Or the marketing name may change even if
>>the code doesn't.
>>
>>I'd like to formally bring this up this issue to the CPE community
>again
>>and make sure we are still going down the correct path.  Obviously, one
>>option will be to keep going down the current path.  But other options
>>would require changes to the current names.  This would mean a lot of
>>depreciation and potential vendor work to readjust their mapping.  The
>>costs of this change may not be worth the benefits.  Unfortunately I do
>>not see the issues and/or discussions surrounding Microsoft names
>>subsiding until we fix the root of the problem.  So at some point I
>>think we are going to have to make some type of change.
>>
>>Some examples of the issues we currently face:
>>
>>- Windows XP 64-Bit Edition, Version 2003 which is actually based off
>of
>>the code for Windows Server 2003
>>
>>- determining which CPE Name to use being difficult as the technical
>>information returned from a system query is not associated with any CPE
>>Name
>>
>>- inconsistencies when dealing with beta and pre-releases, for example
>>the current Windows 7 betas and if the OS marketing name will actually
>>be Windows 7
>>
>>- difficulty determining if certain updates/editions are really
>>different versions, for example the R2 releases
>>
>>- inconsistency between operating system and application naming as many
>>of the Microsoft application names follow the technical name  (see
>>Internet Explorer)
>>
>>Below are two options that I see as possible paths forward.  I urge
>>everyone to share their opinion as we can only understand the best
>>course by knowing how it affects the entire community.  If you have
>>other ideas, please don't be afraid to share them as well.
>>
>>Discussion on this issue will end on Friday June 5th (3 weeks) at which
>>time a decision will be made based on community consensus.
>>
>>----------------------------------
>>OPTION 1
>>----------------------------------
>>
>>Keep things the way they currently are.  Although not perfect, the
>>current way of creating CPE Names for Microsoft operating systems is a
>>good balance between technical correctness and human understanding.  In
>>addition, the work required to deprecate the current Microsoft CPE
>Names
>>and remap to new names would not be worth the benefits of the change.
>>
>>The CPE Specification should be updated to clarify how create CPE Names
>>for Microsoft operating systems and platforms that exhibit related
>>properties.
>>
>>----------------------------------
>>OPTION 2
>>----------------------------------
>>
>>In order to put to bed the continued discussions on Microsoft names we
>>should change how we create these names.  We should leverage the
>>internal version of the operating system and use that in the version
>>component.  In a way, this is more true to the current CPE
>>Specification.
>>
>>The <title> element in the dictionary would be used to hold the
>>marketing name associated with each different version.  For example:
>>
>>cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
>>cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
>>cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
>>cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
>>cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server
>2003
>>SP2
>>
>>Note that this option would require deprecating all the existing
>>Microsoft names in the CPE dictionary.  But this option better aligns
>>with the way the specification is currently written.
>>
>>----------------------------------
>>----------------------------------
>>
>>Again, I urge everyone to share their opinion by Friday June 5th.
>>
>>
>>Thanks
>>Drew
>>
>>
>>
>>
>>---------
>>
>>Andrew Buttner
>>The MITRE Corporation
>>[hidden email]
>>781-271-3515

Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Andrew Buttner
Administrator
>Note that both Windows Server 2003 and Windows XP Professional x64 have
>the same build number 5.2.3790. We need make sure that each is assigned
>a unique CPE identifier.

Are these different editions of the same 5.2.3790 version?
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Sudhir Gandhe-3
I beleive so.



On May 27, 2009, at 4:24 PM, "Buttner, Drew" <[hidden email]> wrote:

>> Note that both Windows Server 2003 and Windows XP Professional x64  
>> have
>> the same build number 5.2.3790. We need make sure that each is  
>> assigned
>> a unique CPE identifier.
>
> Are these different editions of the same 5.2.3790 version?
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Gary Newman-2
In reply to this post by Andrew Buttner
As prior discussions have pointed out, the issue here is whether CPE will
attempt to reverse engineer a vendors products to determine which marketing
names refer to the same internals.  We concluded that wasn't reasonable.  For
example, although WinXP x64 is reportedly built from the same source code as
Windows Server 2003 they're clearly not the same binaries.  In addition to the
builds using different compile-time options, the final packaged product for
Server 2003 has components that aren't in WinXP.

The justification that "marketing names change frequently" appears to be
another claim that the CPE community can reverse engineer a new product to
determine that it's the same as that of a previous product.

It seems like use of a product's marketing name is the only viable way to name
a CPE.

        -Gary-

> ** reply by Friday June 5th **
>
> The creation of CPE Names for the different Microsoft operating systems has
> been a source of discussion since the beginning of CPE.  In October 2007 the
> issue was discussed in depth and it was decided to that these names should be
> based off of the commonly known marketing names.  We have tried this approach
> for the past year and a half but some issues still remain.
>
> We are realizing that names based off the marketing names are hard to manage
> as marketing  names change frequently.  Marketing names also lead to incorrect
> CPE Matching as a marketing name may stay the same but the underlying code may
> change.  Or the marketing name may change even if the code doesn't.
>
> I'd like to formally bring this up this issue to the CPE community again and
> make sure we are still going down the correct path.  Obviously, one option
> will be to keep going down the current path.  But other options would require
> changes to the current names.  This would mean a lot of depreciation and
> potential vendor work to readjust their mapping.  The costs of this change may
> not be worth the benefits.  Unfortunately I do not see the issues and/or
> discussions surrounding Microsoft names subsiding until we fix the root of the
> problem.  So at some point I think we are going to have to make some type of
> change.
>
> Some examples of the issues we currently face:
>
> - Windows XP 64-Bit Edition, Version 2003 which is actually based off of the
> code for Windows Server 2003
>
> - determining which CPE Name to use being difficult as the technical
> information returned from a system query is not associated with any CPE Name
>
> - inconsistencies when dealing with beta and pre-releases, for example the
> current Windows 7 betas and if the OS marketing name will actually be Windows
> 7
>
> - difficulty determining if certain updates/editions are really different
> versions, for example the R2 releases
>
> - inconsistency between operating system and application naming as many of the
> Microsoft application names follow the technical name  (see Internet
> Explorer)
>
> Below are two options that I see as possible paths forward.  I urge everyone
> to share their opinion as we can only understand the best course by knowing
> how it affects the entire community.  If you have other ideas, please don't be
> afraid to share them as well.
>
> Discussion on this issue will end on Friday June 5th (3 weeks) at which time a
> decision will be made based on community consensus.
>
> ----------------------------------
> OPTION 1
> ----------------------------------
>
> Keep things the way they currently are.  Although not perfect, the current way
> of creating CPE Names for Microsoft operating systems is a good balance
> between technical correctness and human understanding.  In addition, the work
> required to deprecate the current Microsoft CPE Names and remap to new names
> would not be worth the benefits of the change.
>
> The CPE Specification should be updated to clarify how create CPE Names for
> Microsoft operating systems and platforms that exhibit related properties.
>
> ----------------------------------
> OPTION 2
> ----------------------------------
>
> In order to put to bed the continued discussions on Microsoft names we should
> change how we create these names.  We should leverage the internal version of
> the operating system and use that in the version component.  In a way, this is
> more true to the current CPE Specification.
>
> The <title> element in the dictionary would be used to hold the marketing name
> associated with each different version.  For example:
>
> cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
> cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003 SP2
>
> Note that this option would require deprecating all the existing Microsoft
> names in the CPE dictionary.  But this option better aligns with the way the
> specification is currently written.
>
> ----------------------------------
> ----------------------------------
>
> Again, I urge everyone to share their opinion by Friday June 5th.
>
>
> Thanks
> Drew
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Gary Newman-2
In reply to this post by Andrew Buttner
Is this a proposal to move the operating system name into the edition
component?

> >Note that both Windows Server 2003 and Windows XP Professional x64 have
> >the same build number 5.2.3790. We need make sure that each is assigned
> >a unique CPE identifier.
>
> Are these different editions of the same 5.2.3790 version?
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Robert Neuman
In reply to this post by Andrew Buttner
We'll need the Major.Minor.Build.Revision numbers a list is here:





Andrew Buttner wrote
>Note that both Windows Server 2003 and Windows XP Professional x64 have
>the same build number 5.2.3790. We need make sure that each is assigned
>a unique CPE identifier.

Are these different editions of the same 5.2.3790 version?
Robert Neuman
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Wolfkiel, Joseph
In reply to this post by Gary Newman-2
I tend to agree with Gary on the product name issue.  While it's probably a
good practice to include the version number of Windows platforms, which
would allow you to reverse engineer the code base, it's not clear to me that
calling both of them "Windows" and assuming that all patches and platform
definitions for Server 2003 and Windows XP x64 are interchangeable.

I'm also not clear if we're willing to perform the same degree of reverse
engineering for non-Microsoft products that this type of naming convention
would imply.

That said, the DoD does have some use cases where it would be convenient to
have a product that was generically named "windows" -- though that may
really be synonymous with "cpe:/o:microsoft".


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: Gary Newman [mailto:[hidden email]]
Sent: Wednesday, May 27, 2009 5:35 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

As prior discussions have pointed out, the issue here is whether CPE will
attempt to reverse engineer a vendors products to determine which marketing
names refer to the same internals.  We concluded that wasn't reasonable.
For example, although WinXP x64 is reportedly built from the same source
code as Windows Server 2003 they're clearly not the same binaries.  In
addition to the builds using different compile-time options, the final
packaged product for Server 2003 has components that aren't in WinXP.

The justification that "marketing names change frequently" appears to be
another claim that the CPE community can reverse engineer a new product to
determine that it's the same as that of a previous product.

It seems like use of a product's marketing name is the only viable way to
name a CPE.

        -Gary-

> ** reply by Friday June 5th **
>
> The creation of CPE Names for the different Microsoft operating
> systems has been a source of discussion since the beginning of CPE.  
> In October 2007 the issue was discussed in depth and it was decided to
> that these names should be based off of the commonly known marketing
> names.  We have tried this approach for the past year and a half but some
issues still remain.
>
> We are realizing that names based off the marketing names are hard to
> manage as marketing  names change frequently.  Marketing names also
> lead to incorrect CPE Matching as a marketing name may stay the same
> but the underlying code may change.  Or the marketing name may change even
if the code doesn't.

>
> I'd like to formally bring this up this issue to the CPE community
> again and make sure we are still going down the correct path.  
> Obviously, one option will be to keep going down the current path.  
> But other options would require changes to the current names.  This
> would mean a lot of depreciation and potential vendor work to readjust
> their mapping.  The costs of this change may not be worth the
> benefits.  Unfortunately I do not see the issues and/or discussions
> surrounding Microsoft names subsiding until we fix the root of the
> problem.  So at some point I think we are going to have to make some type
of change.

>
> Some examples of the issues we currently face:
>
> - Windows XP 64-Bit Edition, Version 2003 which is actually based off
> of the code for Windows Server 2003
>
> - determining which CPE Name to use being difficult as the technical
> information returned from a system query is not associated with any
> CPE Name
>
> - inconsistencies when dealing with beta and pre-releases, for example
> the current Windows 7 betas and if the OS marketing name will actually
> be Windows
> 7
>
> - difficulty determining if certain updates/editions are really
> different versions, for example the R2 releases
>
> - inconsistency between operating system and application naming as
> many of the Microsoft application names follow the technical name  
> (see Internet
> Explorer)
>
> Below are two options that I see as possible paths forward.  I urge
> everyone to share their opinion as we can only understand the best
> course by knowing how it affects the entire community.  If you have
> other ideas, please don't be afraid to share them as well.
>
> Discussion on this issue will end on Friday June 5th (3 weeks) at
> which time a decision will be made based on community consensus.
>
> ----------------------------------
> OPTION 1
> ----------------------------------
>
> Keep things the way they currently are.  Although not perfect, the
> current way of creating CPE Names for Microsoft operating systems is a
> good balance between technical correctness and human understanding.  
> In addition, the work required to deprecate the current Microsoft CPE
> Names and remap to new names would not be worth the benefits of the
change.
>
> The CPE Specification should be updated to clarify how create CPE
> Names for Microsoft operating systems and platforms that exhibit related
properties.

>
> ----------------------------------
> OPTION 2
> ----------------------------------
>
> In order to put to bed the continued discussions on Microsoft names we
> should change how we create these names.  We should leverage the
> internal version of the operating system and use that in the version
> component.  In a way, this is more true to the current CPE Specification.
>
> The <title> element in the dictionary would be used to hold the
> marketing name associated with each different version.  For example:
>
> cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
> cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server
> 2003 SP2
>
> Note that this option would require deprecating all the existing
> Microsoft names in the CPE dictionary.  But this option better aligns
> with the way the specification is currently written.
>
> ----------------------------------
> ----------------------------------
>
> Again, I urge everyone to share their opinion by Friday June 5th.
>
>
> Thanks
> Drew
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>

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

Re: Microsoft OS Naming Issue

Andrew Buttner
Administrator
In reply to this post by Gary Newman-2
The thinking in this (and similar) cases would be to have CPE Names like:

cpe:/o:microsoft:windows:5.2.3790::x86  - win server 03
cpe:/o:microsoft:windows:5.2.3790::x64  - win xp pro x64

Obviously more thought needs to go into what exactly would be in the edition field for these examples as my guess is that there is also a win 2003 64-bit as well.  I think the question raised here is how to create CPE Names for platforms that are known by different product names, even when they might not be different products.

Thanks
Drew


>-----Original Message-----
>From: Gary Newman [mailto:[hidden email]]
>Sent: Wednesday, May 27, 2009 5:38 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue
>
>Is this a proposal to move the operating system name into the edition
>component?
>
>> >Note that both Windows Server 2003 and Windows XP Professional x64
>have
>> >the same build number 5.2.3790. We need make sure that each is
>assigned
>> >a unique CPE identifier.
>>
>> Are these different editions of the same 5.2.3790 version?
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

David Raphael
In reply to this post by Gary Newman-2
Reply from Jeff Turner (my coworker can't post to the list at the moment):

I humbly disagree.  Windows Server 2003 x64 and Windows XP x64 receive
identical patch packages.  Calculate an MD5 (or hash of your choosing)
on the patches delivered by WSUS / Windows Update / Patch Delivery tool
of your choosing to both Operating Systems.  It is the same file.  And
those patches deploy the same binary files.

Win XP x64 and Server 2003 x64 are as closely related as Windows 2000
Professional and Windows 2000 Server.  The marketing names just muddy
the issue.  Sure there are components that are not available in the
"Workstation" Edition vs the "Server" Editions of an Operating System.
Just like there are components that differentiate Windows Server 2003
Standard from Enterprise.

CPE can still be an effective tool to enumerate these, though edition is
probably where the distinction properly lies (read: Option 2).  I think
that Windows Server 2003 / XP x64 can and should be identified
similarly.

The difficulty is trying to educate people that XP x64 is the little
brother to Server 2003 x64 and only a first cousin to XP x86.  I think
the marketing names only serve to perpetuate the confusion.




On 5/27/09 4:34 PM, "Gary Newman" <[hidden email]> wrote:

As prior discussions have pointed out, the issue here is whether CPE will
attempt to reverse engineer a vendors products to determine which marketing
names refer to the same internals.  We concluded that wasn't reasonable.  For
example, although WinXP x64 is reportedly built from the same source code as
Windows Server 2003 they're clearly not the same binaries.  In addition to the
builds using different compile-time options, the final packaged product for
Server 2003 has components that aren't in WinXP.

The justification that "marketing names change frequently" appears to be
another claim that the CPE community can reverse engineer a new product to
determine that it's the same as that of a previous product.

It seems like use of a product's marketing name is the only viable way to name
a CPE.

        -Gary-

> ** reply by Friday June 5th **
>
> The creation of CPE Names for the different Microsoft operating systems has
> been a source of discussion since the beginning of CPE.  In October 2007 the
> issue was discussed in depth and it was decided to that these names should be
> based off of the commonly known marketing names.  We have tried this approach
> for the past year and a half but some issues still remain.
>
> We are realizing that names based off the marketing names are hard to manage
> as marketing  names change frequently.  Marketing names also lead to incorrect
> CPE Matching as a marketing name may stay the same but the underlying code may
> change.  Or the marketing name may change even if the code doesn't.
>
> I'd like to formally bring this up this issue to the CPE community again and
> make sure we are still going down the correct path.  Obviously, one option
> will be to keep going down the current path.  But other options would require
> changes to the current names.  This would mean a lot of depreciation and
> potential vendor work to readjust their mapping.  The costs of this change may
> not be worth the benefits.  Unfortunately I do not see the issues and/or
> discussions surrounding Microsoft names subsiding until we fix the root of the
> problem.  So at some point I think we are going to have to make some type of
> change.
>
> Some examples of the issues we currently face:
>
> - Windows XP 64-Bit Edition, Version 2003 which is actually based off of the
> code for Windows Server 2003
>
> - determining which CPE Name to use being difficult as the technical
> information returned from a system query is not associated with any CPE Name
>
> - inconsistencies when dealing with beta and pre-releases, for example the
> current Windows 7 betas and if the OS marketing name will actually be Windows
> 7
>
> - difficulty determining if certain updates/editions are really different
> versions, for example the R2 releases
>
> - inconsistency between operating system and application naming as many of the
> Microsoft application names follow the technical name  (see Internet
> Explorer)
>
> Below are two options that I see as possible paths forward.  I urge everyone
> to share their opinion as we can only understand the best course by knowing
> how it affects the entire community.  If you have other ideas, please don't be
> afraid to share them as well.
>
> Discussion on this issue will end on Friday June 5th (3 weeks) at which time a
> decision will be made based on community consensus.
>
> ----------------------------------
> OPTION 1
> ----------------------------------
>
> Keep things the way they currently are.  Although not perfect, the current way
> of creating CPE Names for Microsoft operating systems is a good balance
> between technical correctness and human understanding.  In addition, the work
> required to deprecate the current Microsoft CPE Names and remap to new names
> would not be worth the benefits of the change.
>
> The CPE Specification should be updated to clarify how create CPE Names for
> Microsoft operating systems and platforms that exhibit related properties.
>
> ----------------------------------
> OPTION 2
> ----------------------------------
>
> In order to put to bed the continued discussions on Microsoft names we should
> change how we create these names.  We should leverage the internal version of
> the operating system and use that in the version component.  In a way, this is
> more true to the current CPE Specification.
>
> The <title> element in the dictionary would be used to hold the marketing name
> associated with each different version.  For example:
>
> cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
> cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003 SP2
>
> Note that this option would require deprecating all the existing Microsoft
> names in the CPE dictionary.  But this option better aligns with the way the
> specification is currently written.
>
> ----------------------------------
> ----------------------------------
>
> Again, I urge everyone to share their opinion by Friday June 5th.
>
>
> Thanks
> Drew
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>


--
David Raphael

Research Tools Manager
Risk and Compliance Security Research
McAfee, Inc.

972.963.7224 Direct
214.769.6098 Mobile

[hidden email]
http://www.mcafee.com
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Blake Frantz
I agree that XP and Win2k3 are born of the same kernel, shell, etc. Same with Win2k Server and Workstation, and NT Server and Workstation. In many instances patches may be the same. Configuration recommendations may largely overlap. But they are not entirely the same beast. You're not legitimately going to enable the Domain Controller role on an XP box. Nor the DNS, DHCP, or WINS server roles. Any guidance or vulnerability information affecting these roles (which are part of the platform) are applicable to Win2k3 but not applicable XP. Given this, I recommend we maintain discrete CPE-IDs for each "marketing name".

That being said, I don't have a strong opinion on if the CPE-ID is constructed from marketing names or build names. I do know, however, that all the vulnerability and guidance information I'm aware of today for the Windows platforms operates at the "marketing name" level.

1. Vulnerability information resides at the "marketing name" level
        - The "Affected Software" section of MS Security bulletins use terms such as - no build info present.
                - Windows Server 2003 Service Pack 1
                - Windows Server 2003 Service Pack 2
                - Windows XP Professional x64 Edition
                - Windows XP Professional x64 Edition Service Pack 2
                - Windows Server 2003 with SP1 for Itanium-based Systems
                - Windows Server 2003 with SP2 for Itanium-based Systems
                - Windows Server 2008 for 32-bit Systems
                - Windows Server 2008 for x64-based Systems

        - Pick your favorite vulnerability aggregator, they operate at the same level.
        - CVE Overviews operate at the "marketing level". No mention of build information.

2. Security Guidance operates at the "marketing name" level
        - Microsoft security guides do not mention build version
        - CIS guides don't mention build numbers
        - DISA STIGs don't mention build numbers
        - All three use "marketing name"

Again, I'm not hung up on the composition of the CPE at this point because no matter the composition of the identifier the only important thing is how you define what the identifier represents.  

I could be way off base here but what I think the CPE community is missing is a clear set of rules for determining how to *compute* a CPE-ID for a given target Windows (or other platform) box and how that computed CPE-ID aligns in the official CPE-ID dictionary.

We have a discrete list of information we know we need to get off the box:

        1. Vendor
        2. Product
        3. Version
        4. Update
        5. Edition
        6. Language

If we provide CPE consumers with rules on how to derive these values from the OS to build a CPE-ID from the target computer it no longer matters if we use build numbers or marketing names for composing the CPE-ID - make it a GUID, even, so long as the <title> is understandable by a human.

We could borrow from the IETF and other standards bodies and accomplish this using BNF (http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form) backed by a procedure for how an implementer should compute a CPE-ID from a given Windows box.  Here's an example of what this might look like:

Note: The emphasis here is on the concept, not the specifics of where or how I'm getting the information. There are much better ways to go about gathering some of this information and even different values to use.
 
The BNF:

<cpe-id> ::= "cpe:/" <part> ":" <vendor> ":" <product> ":" <version> ":" <update> ":" <edition_base> <edition_arch> ":" <language>

Examples:
cpe:/o:microsoft:windows:server_2003::: Windows Server 2003
cpe:/o:microsoft:windows:server_2003::datacenter: Windows Server 2003 Data Center Edition
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_x86: Windows Server 2003 SP 1 Data Center Edition for 32-bit systems
cpe:/o:microsoft:windows:server_2003:sp2:datacenter_x64: Windows Server 2003 SP 2 Data Center Edition for x64-bit systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64: Windows Server 2003 SP 1 Data Center Edition for Itanium systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:ar Windows Server 2003 SP 1 Arabic Data Center Edition for Itanium systems

Implementers should use the following algorithm to compute the CPE ID for a given Microsoft Windows system:

1. set <part> to "o"
2. set <vendor> to "microsoft"
3. set <product> to "windows"
4. set <version> based on the presence of <string> in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string> <version>
        "Windows Server 2003" "server_2003"
        "Windows XP" "xp"
        "Windows Vista "vista"
       
5. set <update> based on the presence of <string> in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion

        <string> <update>
        "Service Pack 1" "sp1"
        "Service Pack 2" "sp2"
        "" ""
       
6. set <edition_base> based on the presence of <string> in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string> <edition>
        "Data Center" "datacenter"
        "Professional" "pro"
        "home" "home"
        "Ultimate" "ultimate"

7. set <edition_arch> based on the <value> found in SYSTEM_INFO.dwProcessorType returned from GetNativeSystemInfo()[2]

        <value> <edition_arch>
        0x09 "_x64"
        0x06 "_ia64"
        0x00 "_x86"

8. set <language> based on the <value> returned from GetSystemDefaultLangID()[1]

        <value <language>
        0x0409 "en" (English)
        0x1401 "ar" (Arabic)
        ...

Again, there are a obvious ways we can avoid building tables, supported APIs[3] we could use, and different CPE-ID forms we might adopt to achieve this - the emphasis is on the concept. With something similar to this, CPE consumers can build a CPE-ID from a host, determine which CPE-ID the target "belongs to" then apply "the content" (i.e XCCDF/OVAL/etc). When the above is finalized, I could see value in a reference implementation for "CPE_INFO* ComputeCPE()" that returns a structure or class that contains each subcomponent of a CPE-ID - or maybe I'm in orbit some place.

The next step as I see it is to provide rules for CPE-ID globbing. This would take the form of another set of rules for how a CPE-ID matches up with the official set. I can image a reference implementation of "CPE_LIST* ResolveCPE(char* computedCpe)" that returns an array of CPE_INFO structures/classes from the official dictionary that match the CPE-ID computed using a procedure similar to the one provided above. Again - I may be in orbit here, but I think those writing tools and those building mega maps might value this information.

These concepts would obvious apply to other platforms as well, including your favorite *NIX's.

An additional benefit of this model is a decreased chance of software vendors classifying a population of machines differently due to differences in how they determine which CPE-ID a target "belongs to".

SO.....What are some thoughts on all this? If this is something the community thinks is sane I'm happy to help create the draft for what the real procedures might look like. Or I can put the keyboard down and slowly back away from my computer. :)

Blake


[1] http://msdn.microsoft.com/en-us/library/dd318120(VS.85).aspx 
[2] http://msdn.microsoft.com/en-us/library/ms724340(VS.85).aspx
[3] http://msdn.microsoft.com/en-us/library/ms724429(VS.85).aspx


-----Original Message-----
From: David Raphael [mailto:[hidden email]]
Sent: Wednesday, May 27, 2009 4:24 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

Reply from Jeff Turner (my coworker can't post to the list at the moment):

I humbly disagree.  Windows Server 2003 x64 and Windows XP x64 receive
identical patch packages.  Calculate an MD5 (or hash of your choosing)
on the patches delivered by WSUS / Windows Update / Patch Delivery tool
of your choosing to both Operating Systems.  It is the same file.  And
those patches deploy the same binary files.

Win XP x64 and Server 2003 x64 are as closely related as Windows 2000
Professional and Windows 2000 Server.  The marketing names just muddy
the issue.  Sure there are components that are not available in the
"Workstation" Edition vs the "Server" Editions of an Operating System.
Just like there are components that differentiate Windows Server 2003
Standard from Enterprise.

CPE can still be an effective tool to enumerate these, though edition is
probably where the distinction properly lies (read: Option 2).  I think
that Windows Server 2003 / XP x64 can and should be identified
similarly.

The difficulty is trying to educate people that XP x64 is the little
brother to Server 2003 x64 and only a first cousin to XP x86.  I think
the marketing names only serve to perpetuate the confusion.




On 5/27/09 4:34 PM, "Gary Newman" <[hidden email]> wrote:

As prior discussions have pointed out, the issue here is whether CPE will
attempt to reverse engineer a vendors products to determine which marketing
names refer to the same internals.  We concluded that wasn't reasonable.  For
example, although WinXP x64 is reportedly built from the same source code as
Windows Server 2003 they're clearly not the same binaries.  In addition to the
builds using different compile-time options, the final packaged product for
Server 2003 has components that aren't in WinXP.

The justification that "marketing names change frequently" appears to be
another claim that the CPE community can reverse engineer a new product to
determine that it's the same as that of a previous product.

It seems like use of a product's marketing name is the only viable way to name
a CPE.

        -Gary-

> ** reply by Friday June 5th **
>
> The creation of CPE Names for the different Microsoft operating systems has
> been a source of discussion since the beginning of CPE.  In October 2007 the
> issue was discussed in depth and it was decided to that these names should be
> based off of the commonly known marketing names.  We have tried this approach
> for the past year and a half but some issues still remain.
>
> We are realizing that names based off the marketing names are hard to manage
> as marketing  names change frequently.  Marketing names also lead to incorrect
> CPE Matching as a marketing name may stay the same but the underlying code may
> change.  Or the marketing name may change even if the code doesn't.
>
> I'd like to formally bring this up this issue to the CPE community again and
> make sure we are still going down the correct path.  Obviously, one option
> will be to keep going down the current path.  But other options would require
> changes to the current names.  This would mean a lot of depreciation and
> potential vendor work to readjust their mapping.  The costs of this change may
> not be worth the benefits.  Unfortunately I do not see the issues and/or
> discussions surrounding Microsoft names subsiding until we fix the root of the
> problem.  So at some point I think we are going to have to make some type of
> change.
>
> Some examples of the issues we currently face:
>
> - Windows XP 64-Bit Edition, Version 2003 which is actually based off of the
> code for Windows Server 2003
>
> - determining which CPE Name to use being difficult as the technical
> information returned from a system query is not associated with any CPE Name
>
> - inconsistencies when dealing with beta and pre-releases, for example the
> current Windows 7 betas and if the OS marketing name will actually be Windows
> 7
>
> - difficulty determining if certain updates/editions are really different
> versions, for example the R2 releases
>
> - inconsistency between operating system and application naming as many of the
> Microsoft application names follow the technical name  (see Internet
> Explorer)
>
> Below are two options that I see as possible paths forward.  I urge everyone
> to share their opinion as we can only understand the best course by knowing
> how it affects the entire community.  If you have other ideas, please don't be
> afraid to share them as well.
>
> Discussion on this issue will end on Friday June 5th (3 weeks) at which time a
> decision will be made based on community consensus.
>
> ----------------------------------
> OPTION 1
> ----------------------------------
>
> Keep things the way they currently are.  Although not perfect, the current way
> of creating CPE Names for Microsoft operating systems is a good balance
> between technical correctness and human understanding.  In addition, the work
> required to deprecate the current Microsoft CPE Names and remap to new names
> would not be worth the benefits of the change.
>
> The CPE Specification should be updated to clarify how create CPE Names for
> Microsoft operating systems and platforms that exhibit related properties.
>
> ----------------------------------
> OPTION 2
> ----------------------------------
>
> In order to put to bed the continued discussions on Microsoft names we should
> change how we create these names.  We should leverage the internal version of
> the operating system and use that in the version component.  In a way, this is
> more true to the current CPE Specification.
>
> The <title> element in the dictionary would be used to hold the marketing name
> associated with each different version.  For example:
>
> cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
> cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003 SP2
>
> Note that this option would require deprecating all the existing Microsoft
> names in the CPE dictionary.  But this option better aligns with the way the
> specification is currently written.
>
> ----------------------------------
> ----------------------------------
>
> Again, I urge everyone to share their opinion by Friday June 5th.
>
>
> Thanks
> Drew
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>


--
David Raphael

Research Tools Manager
Risk and Compliance Security Research
McAfee, Inc.

972.963.7224 Direct
214.769.6098 Mobile

[hidden email]
http://www.mcafee.com
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Maneesh Jolly
I feel that making a choice between whether to use version info like "5.1",
"5.2" etc or to use marketing name might not be able to put all the
Microsoft OS naming issues to bed.
Incase we choose to go with version info like "5.1", "5.2" etc. then we also
need to take care of Product Type (wProductType received from
GetNativeSystemInfo) to distinguish between Vista and 2008, both of which
have version 6.0 and can have same build number, revision etc. Marketing
name can be inferred by using version and product type. e.g.
Version + Product type = marketing name
5.0 + Workstataion = Windows 2000 prof
5.0 + Server = Windows 2000 server
5.1 + Workstation = Windows XP
5.2 + Workstation = Windows XP 64 bit
5.2 + Server = Windows 2003 server
6.0 + workstation = Windows Vista
6.0 + server = Windows 2008 server

I am also in favor of Option 2 implemented along the lines proposed by
Blake's concept. The easiest method for making new CPE Ids for Microsoft OS
would be to use the values retrieved from the system as CPE components. But
this approach will make CPE Ids very unreadable.

Thanks,
Maneesh


-----Original Message-----
From: Blake Frantz [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 8:35 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I agree that XP and Win2k3 are born of the same kernel, shell, etc. Same
with Win2k Server and Workstation, and NT Server and Workstation. In many
instances patches may be the same. Configuration recommendations may largely
overlap. But they are not entirely the same beast. You're not legitimately
going to enable the Domain Controller role on an XP box. Nor the DNS, DHCP,
or WINS server roles. Any guidance or vulnerability information affecting
these roles (which are part of the platform) are applicable to Win2k3 but
not applicable XP. Given this, I recommend we maintain discrete CPE-IDs for
each "marketing name".

That being said, I don't have a strong opinion on if the CPE-ID is
constructed from marketing names or build names. I do know, however, that
all the vulnerability and guidance information I'm aware of today for the
Windows platforms operates at the "marketing name" level.

1. Vulnerability information resides at the "marketing name" level
        - The "Affected Software" section of MS Security bulletins use terms
such as - no build info present.
                - Windows Server 2003 Service Pack 1
                - Windows Server 2003 Service Pack 2
                - Windows XP Professional x64 Edition
                - Windows XP Professional x64 Edition Service Pack 2
                - Windows Server 2003 with SP1 for Itanium-based Systems
                - Windows Server 2003 with SP2 for Itanium-based Systems
                - Windows Server 2008 for 32-bit Systems
                - Windows Server 2008 for x64-based Systems

        - Pick your favorite vulnerability aggregator, they operate at the
same level.
        - CVE Overviews operate at the "marketing level". No mention of
build information.

2. Security Guidance operates at the "marketing name" level
        - Microsoft security guides do not mention build version
        - CIS guides don't mention build numbers
        - DISA STIGs don't mention build numbers
        - All three use "marketing name"

Again, I'm not hung up on the composition of the CPE at this point because
no matter the composition of the identifier the only important thing is how
you define what the identifier represents.  

I could be way off base here but what I think the CPE community is missing
is a clear set of rules for determining how to *compute* a CPE-ID for a
given target Windows (or other platform) box and how that computed CPE-ID
aligns in the official CPE-ID dictionary.

We have a discrete list of information we know we need to get off the box:

        1. Vendor
        2. Product
        3. Version
        4. Update
        5. Edition
        6. Language

If we provide CPE consumers with rules on how to derive these values from
the OS to build a CPE-ID from the target computer it no longer matters if we
use build numbers or marketing names for composing the CPE-ID - make it a
GUID, even, so long as the <title> is understandable by a human.

We could borrow from the IETF and other standards bodies and accomplish this
using BNF (http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form) backed by
a procedure for how an implementer should compute a CPE-ID from a given
Windows box.  Here's an example of what this might look like:

Note: The emphasis here is on the concept, not the specifics of where or how
I'm getting the information. There are much better ways to go about
gathering some of this information and even different values to use.
 
The BNF:

<cpe-id> ::= "cpe:/" <part> ":" <vendor> ":" <product> ":" <version> ":"
<update> ":" <edition_base> <edition_arch> ":" <language>

Examples:
cpe:/o:microsoft:windows:server_2003:::
Windows Server 2003
cpe:/o:microsoft:windows:server_2003::datacenter:
Windows Server 2003 Data Center Edition
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_x86:
Windows Server 2003 SP 1 Data Center Edition for 32-bit systems
cpe:/o:microsoft:windows:server_2003:sp2:datacenter_x64:
Windows Server 2003 SP 2 Data Center Edition for x64-bit systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:
Windows Server 2003 SP 1 Data Center Edition for Itanium systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:ar
Windows Server 2003 SP 1 Arabic Data Center Edition for Itanium systems

Implementers should use the following algorithm to compute the CPE ID for a
given Microsoft Windows system:

1. set <part> to "o"
2. set <vendor> to "microsoft"
3. set <product> to "windows"
4. set <version> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string> <version>
        "Windows Server 2003" "server_2003"
        "Windows XP" "xp"
        "Windows Vista "vista"
       
5. set <update> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion

        <string> <update>
        "Service Pack 1" "sp1"
        "Service Pack 2" "sp2"
        "" ""
       
6. set <edition_base> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string> <edition>
        "Data Center" "datacenter"
        "Professional" "pro"
        "home" "home"
        "Ultimate" "ultimate"

7. set <edition_arch> based on the <value> found in
SYSTEM_INFO.dwProcessorType returned from GetNativeSystemInfo()[2]

        <value> <edition_arch>
        0x09 "_x64"
        0x06 "_ia64"
        0x00 "_x86"

8. set <language> based on the <value> returned from
GetSystemDefaultLangID()[1]

        <value <language>
        0x0409 "en" (English)
        0x1401 "ar" (Arabic)
        ...

Again, there are a obvious ways we can avoid building tables, supported
APIs[3] we could use, and different CPE-ID forms we might adopt to achieve
this - the emphasis is on the concept. With something similar to this, CPE
consumers can build a CPE-ID from a host, determine which CPE-ID the target
"belongs to" then apply "the content" (i.e XCCDF/OVAL/etc). When the above
is finalized, I could see value in a reference implementation for "CPE_INFO*
ComputeCPE()" that returns a structure or class that contains each
subcomponent of a CPE-ID - or maybe I'm in orbit some place.

The next step as I see it is to provide rules for CPE-ID globbing. This
would take the form of another set of rules for how a CPE-ID matches up with
the official set. I can image a reference implementation of "CPE_LIST*
ResolveCPE(char* computedCpe)" that returns an array of CPE_INFO
structures/classes from the official dictionary that match the CPE-ID
computed using a procedure similar to the one provided above. Again - I may
be in orbit here, but I think those writing tools and those building mega
maps might value this information.

These concepts would obvious apply to other platforms as well, including
your favorite *NIX's.

An additional benefit of this model is a decreased chance of software
vendors classifying a population of machines differently due to differences
in how they determine which CPE-ID a target "belongs to".

SO.....What are some thoughts on all this? If this is something the
community thinks is sane I'm happy to help create the draft for what the
real procedures might look like. Or I can put the keyboard down and slowly
back away from my computer. :)

Blake


[1] http://msdn.microsoft.com/en-us/library/dd318120(VS.85).aspx 
[2] http://msdn.microsoft.com/en-us/library/ms724340(VS.85).aspx
[3] http://msdn.microsoft.com/en-us/library/ms724429(VS.85).aspx


-----Original Message-----
From: David Raphael [mailto:[hidden email]]
Sent: Wednesday, May 27, 2009 4:24 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

Reply from Jeff Turner (my coworker can't post to the list at the moment):

I humbly disagree.  Windows Server 2003 x64 and Windows XP x64 receive
identical patch packages.  Calculate an MD5 (or hash of your choosing)
on the patches delivered by WSUS / Windows Update / Patch Delivery tool
of your choosing to both Operating Systems.  It is the same file.  And
those patches deploy the same binary files.

Win XP x64 and Server 2003 x64 are as closely related as Windows 2000
Professional and Windows 2000 Server.  The marketing names just muddy
the issue.  Sure there are components that are not available in the
"Workstation" Edition vs the "Server" Editions of an Operating System.
Just like there are components that differentiate Windows Server 2003
Standard from Enterprise.

CPE can still be an effective tool to enumerate these, though edition is
probably where the distinction properly lies (read: Option 2).  I think
that Windows Server 2003 / XP x64 can and should be identified
similarly.

The difficulty is trying to educate people that XP x64 is the little
brother to Server 2003 x64 and only a first cousin to XP x86.  I think
the marketing names only serve to perpetuate the confusion.




On 5/27/09 4:34 PM, "Gary Newman" <[hidden email]> wrote:

As prior discussions have pointed out, the issue here is whether CPE will
attempt to reverse engineer a vendors products to determine which marketing
names refer to the same internals.  We concluded that wasn't reasonable.
For
example, although WinXP x64 is reportedly built from the same source code as
Windows Server 2003 they're clearly not the same binaries.  In addition to
the
builds using different compile-time options, the final packaged product for
Server 2003 has components that aren't in WinXP.

The justification that "marketing names change frequently" appears to be
another claim that the CPE community can reverse engineer a new product to
determine that it's the same as that of a previous product.

It seems like use of a product's marketing name is the only viable way to
name
a CPE.

        -Gary-

> ** reply by Friday June 5th **
>
> The creation of CPE Names for the different Microsoft operating systems
has
> been a source of discussion since the beginning of CPE.  In October 2007
the
> issue was discussed in depth and it was decided to that these names should
be
> based off of the commonly known marketing names.  We have tried this
approach
> for the past year and a half but some issues still remain.
>
> We are realizing that names based off the marketing names are hard to
manage
> as marketing  names change frequently.  Marketing names also lead to
incorrect
> CPE Matching as a marketing name may stay the same but the underlying code
may
> change.  Or the marketing name may change even if the code doesn't.
>
> I'd like to formally bring this up this issue to the CPE community again
and
> make sure we are still going down the correct path.  Obviously, one option
> will be to keep going down the current path.  But other options would
require
> changes to the current names.  This would mean a lot of depreciation and
> potential vendor work to readjust their mapping.  The costs of this change
may
> not be worth the benefits.  Unfortunately I do not see the issues and/or
> discussions surrounding Microsoft names subsiding until we fix the root of
the
> problem.  So at some point I think we are going to have to make some type
of
> change.
>
> Some examples of the issues we currently face:
>
> - Windows XP 64-Bit Edition, Version 2003 which is actually based off of
the
> code for Windows Server 2003
>
> - determining which CPE Name to use being difficult as the technical
> information returned from a system query is not associated with any CPE
Name
>
> - inconsistencies when dealing with beta and pre-releases, for example the
> current Windows 7 betas and if the OS marketing name will actually be
Windows
> 7
>
> - difficulty determining if certain updates/editions are really different
> versions, for example the R2 releases
>
> - inconsistency between operating system and application naming as many of
the
> Microsoft application names follow the technical name  (see Internet
> Explorer)
>
> Below are two options that I see as possible paths forward.  I urge
everyone
> to share their opinion as we can only understand the best course by
knowing
> how it affects the entire community.  If you have other ideas, please
don't be
> afraid to share them as well.
>
> Discussion on this issue will end on Friday June 5th (3 weeks) at which
time a
> decision will be made based on community consensus.
>
> ----------------------------------
> OPTION 1
> ----------------------------------
>
> Keep things the way they currently are.  Although not perfect, the current
way
> of creating CPE Names for Microsoft operating systems is a good balance
> between technical correctness and human understanding.  In addition, the
work
> required to deprecate the current Microsoft CPE Names and remap to new
names
> would not be worth the benefits of the change.
>
> The CPE Specification should be updated to clarify how create CPE Names
for
> Microsoft operating systems and platforms that exhibit related properties.
>
> ----------------------------------
> OPTION 2
> ----------------------------------
>
> In order to put to bed the continued discussions on Microsoft names we
should
> change how we create these names.  We should leverage the internal version
of
> the operating system and use that in the version component.  In a way,
this is
> more true to the current CPE Specification.
>
> The <title> element in the dictionary would be used to hold the marketing
name
> associated with each different version.  For example:
>
> cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
> cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003
SP2
>
> Note that this option would require deprecating all the existing Microsoft
> names in the CPE dictionary.  But this option better aligns with the way
the

> specification is currently written.
>
> ----------------------------------
> ----------------------------------
>
> Again, I urge everyone to share their opinion by Friday June 5th.
>
>
> Thanks
> Drew
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>


--
David Raphael

Research Tools Manager
Risk and Compliance Security Research
McAfee, Inc.

972.963.7224 Direct
214.769.6098 Mobile

[hidden email]
http://www.mcafee.com
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Jeffery Turner
I like Maneesh's suggestion regarding programmatic determination of the OS and translating that to determine a CPE.  The ProductType can be used to determine the edition.

There does need to be a way to distinguish between these products within a CPE just like there needs to be a way to distinguish "Windows 2008 Server Core" from other Windows 2008 installations.   I am not putting forth that CPE should not be able to distinguish Win XP x64 from Server 2003 x64.  Just that I do not think it is a "Version" distinction.

An example, the following patch applies to both Win XP x64 and Windows Server 2003 x64.  And my database of Microsoft Security Patches has 172 that do the same.
http://download.microsoft.com/download/0/1/2/0123e76a-b415-4af6-b038-b49dd090a0a8/WindowsServer2003.WindowsXP-KB926122-x64-ENU.exe

Technically, the "marketing name" can include the edition and the architecture (when not x86) as well, so the marketing name of Windows XP x64 is actually "Windows XP Professional x64 Edition".  So which marketing name do you use and how do you determine which parts of the marketing name define the version and which parts define the edition, etc?  This introduces a non-deterministic evaluation that results in variance; the exact concern that CPE is trying to eliminate (everybody calling the OS something different and how everybody can enumerate a platform the same way).

Applying a Domain Controller policy based strictly on the marketing name might not be the best option either.  You need to define the ROLE of the system for that.  Operating System Marketing name would not be enough (you probably don't want to apply the domain controller policy to a Web Server or Database Server either).

I agree with Blake when he states:
>I could be way off base here but what I think the CPE community is missing
>is a clear set of rules for determining how to *compute* a CPE-ID for a
>given target Windows (or other platform) box and how that computed CPE-ID
>aligns in the official CPE-ID dictionary.

I also agree with this:
>If we provide CPE consumers with rules on how to derive these values from
>the OS to build a CPE-ID from the target computer it no longer matters if >we use build numbers or marketing names for composing the CPE-ID - make it >a GUID, even, so long as the <title> is understandable by a human.

Providing a standard title for each CPE should reflect a "marketing name" and products / UIs can maintain CPE compatibility while obfuscating the computation of the ID.  The end user of a product does not need to see the ID.  The relevant software can handle that.  CPE just gives us a standard way to define all the components of a platform for cross compatibility.

I like where Blake is going in determining an algorithm for computing a CPE because an evaluation of system characteristics should always produce the same result.  It eliminates the variants in naming where there are multiple marketing names and confusion over whether "Windows XP Professional" should include x64 or if that is strictly the marketing name for x86.  An algorithm provides a more "mathematical" formula where all CPE-knowledgeable persons could take a new variant of Windows and compute the same CPE.  That said, my algorithm might look a little different.  I would favor using Windows numeric versions for versions and leave the marketing name for display values.

Ultimately, I think the CPE consumers (software developers, technical control authors, etc) have a different need than the consumer of a software product that uses CPEs.  I think the software developer's goal when using CPE is to transparently provide a mechanism by which to uniquely identify platforms and provide a way to communicate and evaluate the affected platforms clearly.  The end user does not need to be aware of the "id" at all.

As for DISA, Microsoft, CIS, other security policies, they do not always all use the SAME marketing name.  They are written to groupings of platforms that contain ambiguities because they do not use CPEs or something specific.  They often make assumptions about how the end user defines "Windows XP Professional".  Is that strictly the x86 version?  Because it does not call out x86 vs x64, but that is the marketing name for the x86 variant.  You can easily make a case that the various security policies define groupings of CPEs whether by architecture (x86 vs x64), edition (Standard, Enterprise), or any other characteristic.  And the whole problem is what CPE should be trying to rectify...how to clearly state what system(s) a security template, patch, or whatever should apply to rather than leaving it up to evaluation where we all disagree about the author's intent.  We just have to get the authors onboard with using CPE. :-)

Overall, I am not necessarily committed to "Version" vs. "Edition" on the x86 vs x64 issue.  I do think a good goal of CPE should be to provide an enumeration based on objective criteria in an algorithm such that a newly released variant of an existing OS can be computed identically by different people in different places based off a shared formula, though that may be a little idealistic.




-----Original Message-----
From: Maneesh Jolly [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 3:24 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I feel that making a choice between whether to use version info like "5.1",
"5.2" etc or to use marketing name might not be able to put all the
Microsoft OS naming issues to bed.
Incase we choose to go with version info like "5.1", "5.2" etc. then we also
need to take care of Product Type (wProductType received from
GetNativeSystemInfo) to distinguish between Vista and 2008, both of which
have version 6.0 and can have same build number, revision etc. Marketing
name can be inferred by using version and product type. e.g.
Version + Product type = marketing name
5.0 + Workstataion = Windows 2000 prof
5.0 + Server = Windows 2000 server
5.1 + Workstation = Windows XP
5.2 + Workstation = Windows XP 64 bit
5.2 + Server = Windows 2003 server
6.0 + workstation = Windows Vista
6.0 + server = Windows 2008 server

I am also in favor of Option 2 implemented along the lines proposed by
Blake's concept. The easiest method for making new CPE Ids for Microsoft OS
would be to use the values retrieved from the system as CPE components. But
this approach will make CPE Ids very unreadable.

Thanks,
Maneesh


-----Original Message-----
From: Blake Frantz [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 8:35 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I agree that XP and Win2k3 are born of the same kernel, shell, etc. Same
with Win2k Server and Workstation, and NT Server and Workstation. In many
instances patches may be the same. Configuration recommendations may largely
overlap. But they are not entirely the same beast. You're not legitimately
going to enable the Domain Controller role on an XP box. Nor the DNS, DHCP,
or WINS server roles. Any guidance or vulnerability information affecting
these roles (which are part of the platform) are applicable to Win2k3 but
not applicable XP. Given this, I recommend we maintain discrete CPE-IDs for
each "marketing name".

That being said, I don't have a strong opinion on if the CPE-ID is
constructed from marketing names or build names. I do know, however, that
all the vulnerability and guidance information I'm aware of today for the
Windows platforms operates at the "marketing name" level.

1. Vulnerability information resides at the "marketing name" level
        - The "Affected Software" section of MS Security bulletins use terms
such as - no build info present.
                - Windows Server 2003 Service Pack 1
                - Windows Server 2003 Service Pack 2
                - Windows XP Professional x64 Edition
                - Windows XP Professional x64 Edition Service Pack 2
                - Windows Server 2003 with SP1 for Itanium-based Systems
                - Windows Server 2003 with SP2 for Itanium-based Systems
                - Windows Server 2008 for 32-bit Systems
                - Windows Server 2008 for x64-based Systems

        - Pick your favorite vulnerability aggregator, they operate at the
same level.
        - CVE Overviews operate at the "marketing level". No mention of
build information.

2. Security Guidance operates at the "marketing name" level
        - Microsoft security guides do not mention build version
        - CIS guides don't mention build numbers
        - DISA STIGs don't mention build numbers
        - All three use "marketing name"

Again, I'm not hung up on the composition of the CPE at this point because
no matter the composition of the identifier the only important thing is how
you define what the identifier represents.

I could be way off base here but what I think the CPE community is missing
is a clear set of rules for determining how to *compute* a CPE-ID for a
given target Windows (or other platform) box and how that computed CPE-ID
aligns in the official CPE-ID dictionary.

We have a discrete list of information we know we need to get off the box:

        1. Vendor
        2. Product
        3. Version
        4. Update
        5. Edition
        6. Language

If we provide CPE consumers with rules on how to derive these values from
the OS to build a CPE-ID from the target computer it no longer matters if we
use build numbers or marketing names for composing the CPE-ID - make it a
GUID, even, so long as the <title> is understandable by a human.

We could borrow from the IETF and other standards bodies and accomplish this
using BNF (http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form) backed by
a procedure for how an implementer should compute a CPE-ID from a given
Windows box.  Here's an example of what this might look like:

Note: The emphasis here is on the concept, not the specifics of where or how
I'm getting the information. There are much better ways to go about
gathering some of this information and even different values to use.

The BNF:

<cpe-id> ::= "cpe:/" <part> ":" <vendor> ":" <product> ":" <version> ":"
<update> ":" <edition_base> <edition_arch> ":" <language>

Examples:
cpe:/o:microsoft:windows:server_2003:::
Windows Server 2003
cpe:/o:microsoft:windows:server_2003::datacenter:
Windows Server 2003 Data Center Edition
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_x86:
Windows Server 2003 SP 1 Data Center Edition for 32-bit systems
cpe:/o:microsoft:windows:server_2003:sp2:datacenter_x64:
Windows Server 2003 SP 2 Data Center Edition for x64-bit systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:
Windows Server 2003 SP 1 Data Center Edition for Itanium systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:ar
Windows Server 2003 SP 1 Arabic Data Center Edition for Itanium systems

Implementers should use the following algorithm to compute the CPE ID for a
given Microsoft Windows system:

1. set <part> to "o"
2. set <vendor> to "microsoft"
3. set <product> to "windows"
4. set <version> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string>                        <version>
        "Windows Server 2003"   "server_2003"
        "Windows XP"            "xp"
        "Windows Vista          "vista"

5. set <update> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion

        <string>                        <update>
        "Service Pack 1"                "sp1"
        "Service Pack 2"                "sp2"
        ""                              ""

6. set <edition_base> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string>                <edition>
        "Data Center"   "datacenter"
        "Professional"  "pro"
        "home"          "home"
        "Ultimate"              "ultimate"

7. set <edition_arch> based on the <value> found in
SYSTEM_INFO.dwProcessorType returned from GetNativeSystemInfo()[2]

        <value>         <edition_arch>
        0x09                    "_x64"
        0x06                    "_ia64"
        0x00                    "_x86"

8. set <language> based on the <value> returned from
GetSystemDefaultLangID()[1]

        <value  <language>
        0x0409  "en"            (English)
        0x1401  "ar"            (Arabic)
        ...

Again, there are a obvious ways we can avoid building tables, supported
APIs[3] we could use, and different CPE-ID forms we might adopt to achieve
this - the emphasis is on the concept. With something similar to this, CPE
consumers can build a CPE-ID from a host, determine which CPE-ID the target
"belongs to" then apply "the content" (i.e XCCDF/OVAL/etc). When the above
is finalized, I could see value in a reference implementation for "CPE_INFO*
ComputeCPE()" that returns a structure or class that contains each
subcomponent of a CPE-ID - or maybe I'm in orbit some place.

The next step as I see it is to provide rules for CPE-ID globbing. This
would take the form of another set of rules for how a CPE-ID matches up with
the official set. I can image a reference implementation of "CPE_LIST*
ResolveCPE(char* computedCpe)" that returns an array of CPE_INFO
structures/classes from the official dictionary that match the CPE-ID
computed using a procedure similar to the one provided above. Again - I may
be in orbit here, but I think those writing tools and those building mega
maps might value this information.

These concepts would obvious apply to other platforms as well, including
your favorite *NIX's.

An additional benefit of this model is a decreased chance of software
vendors classifying a population of machines differently due to differences
in how they determine which CPE-ID a target "belongs to".

SO.....What are some thoughts on all this? If this is something the
community thinks is sane I'm happy to help create the draft for what the
real procedures might look like. Or I can put the keyboard down and slowly
back away from my computer. :)

Blake


[1] http://msdn.microsoft.com/en-us/library/dd318120(VS.85).aspx
[2] http://msdn.microsoft.com/en-us/library/ms724340(VS.85).aspx
[3] http://msdn.microsoft.com/en-us/library/ms724429(VS.85).aspx


-----Original Message-----
From: David Raphael [mailto:[hidden email]]
Sent: Wednesday, May 27, 2009 4:24 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

Reply from Jeff Turner (my coworker can't post to the list at the moment):

I humbly disagree.  Windows Server 2003 x64 and Windows XP x64 receive
identical patch packages.  Calculate an MD5 (or hash of your choosing)
on the patches delivered by WSUS / Windows Update / Patch Delivery tool
of your choosing to both Operating Systems.  It is the same file.  And
those patches deploy the same binary files.

Win XP x64 and Server 2003 x64 are as closely related as Windows 2000
Professional and Windows 2000 Server.  The marketing names just muddy
the issue.  Sure there are components that are not available in the
"Workstation" Edition vs the "Server" Editions of an Operating System.
Just like there are components that differentiate Windows Server 2003
Standard from Enterprise.

CPE can still be an effective tool to enumerate these, though edition is
probably where the distinction properly lies (read: Option 2).  I think
that Windows Server 2003 / XP x64 can and should be identified
similarly.

The difficulty is trying to educate people that XP x64 is the little
brother to Server 2003 x64 and only a first cousin to XP x86.  I think
the marketing names only serve to perpetuate the confusion.




On 5/27/09 4:34 PM, "Gary Newman" <[hidden email]> wrote:

As prior discussions have pointed out, the issue here is whether CPE will
attempt to reverse engineer a vendors products to determine which marketing
names refer to the same internals.  We concluded that wasn't reasonable.
For
example, although WinXP x64 is reportedly built from the same source code as
Windows Server 2003 they're clearly not the same binaries.  In addition to
the
builds using different compile-time options, the final packaged product for
Server 2003 has components that aren't in WinXP.

The justification that "marketing names change frequently" appears to be
another claim that the CPE community can reverse engineer a new product to
determine that it's the same as that of a previous product.

It seems like use of a product's marketing name is the only viable way to
name
a CPE.

        -Gary-

> ** reply by Friday June 5th **
>
> The creation of CPE Names for the different Microsoft operating systems
has
> been a source of discussion since the beginning of CPE.  In October 2007
the
> issue was discussed in depth and it was decided to that these names should
be
> based off of the commonly known marketing names.  We have tried this
approach
> for the past year and a half but some issues still remain.
>
> We are realizing that names based off the marketing names are hard to
manage
> as marketing  names change frequently.  Marketing names also lead to
incorrect
> CPE Matching as a marketing name may stay the same but the underlying code
may
> change.  Or the marketing name may change even if the code doesn't.
>
> I'd like to formally bring this up this issue to the CPE community again
and
> make sure we are still going down the correct path.  Obviously, one option
> will be to keep going down the current path.  But other options would
require
> changes to the current names.  This would mean a lot of depreciation and
> potential vendor work to readjust their mapping.  The costs of this change
may
> not be worth the benefits.  Unfortunately I do not see the issues and/or
> discussions surrounding Microsoft names subsiding until we fix the root of
the
> problem.  So at some point I think we are going to have to make some type
of
> change.
>
> Some examples of the issues we currently face:
>
> - Windows XP 64-Bit Edition, Version 2003 which is actually based off of
the
> code for Windows Server 2003
>
> - determining which CPE Name to use being difficult as the technical
> information returned from a system query is not associated with any CPE
Name
>
> - inconsistencies when dealing with beta and pre-releases, for example the
> current Windows 7 betas and if the OS marketing name will actually be
Windows
> 7
>
> - difficulty determining if certain updates/editions are really different
> versions, for example the R2 releases
>
> - inconsistency between operating system and application naming as many of
the
> Microsoft application names follow the technical name  (see Internet
> Explorer)
>
> Below are two options that I see as possible paths forward.  I urge
everyone
> to share their opinion as we can only understand the best course by
knowing
> how it affects the entire community.  If you have other ideas, please
don't be
> afraid to share them as well.
>
> Discussion on this issue will end on Friday June 5th (3 weeks) at which
time a
> decision will be made based on community consensus.
>
> ----------------------------------
> OPTION 1
> ----------------------------------
>
> Keep things the way they currently are.  Although not perfect, the current
way
> of creating CPE Names for Microsoft operating systems is a good balance
> between technical correctness and human understanding.  In addition, the
work
> required to deprecate the current Microsoft CPE Names and remap to new
names
> would not be worth the benefits of the change.
>
> The CPE Specification should be updated to clarify how create CPE Names
for
> Microsoft operating systems and platforms that exhibit related properties.
>
> ----------------------------------
> OPTION 2
> ----------------------------------
>
> In order to put to bed the continued discussions on Microsoft names we
should
> change how we create these names.  We should leverage the internal version
of
> the operating system and use that in the version component.  In a way,
this is
> more true to the current CPE Specification.
>
> The <title> element in the dictionary would be used to hold the marketing
name
> associated with each different version.  For example:
>
> cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
> cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003
SP2
>
> Note that this option would require deprecating all the existing Microsoft
> names in the CPE dictionary.  But this option better aligns with the way
the

> specification is currently written.
>
> ----------------------------------
> ----------------------------------
>
> Again, I urge everyone to share their opinion by Friday June 5th.
>
>
> Thanks
> Drew
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>


--
David Raphael

Research Tools Manager
Risk and Compliance Security Research
McAfee, Inc.

972.963.7224 Direct
214.769.6098 Mobile

[hidden email]
http://www.mcafee.com
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Blake Frantz
>>That said, my algorithm might look a little different.  I would favor using Windows numeric versions for >>versions and leave the marketing name for display values.

I agree. We should be able to take values directly out of a reg key, structure, or return value from a native API call to build a CPE-ID. This would be a much cleaner solution to implement.

If this is the direction people want to move in I recommend we:

1. Revisit the components that are interesting to us from a CPE-ID generation perspective.

        Note: Processor architecture has come up a few times. I'm in favor of including this in the CPE ID. My  initial thought is to slap it on the end after <language> as its own component - though this would change       the composition of CPE-IDs across the board.

2. Scope the windows platforms we want a procedure for.

3. For each windows platform in our scope, identify the supported APIs or mechanisms to obtain the information determined in #1.

4. Write the procedure for computing a CPE-ID using the least common denominators from #3.

Thoughts?

Also, please excuse the following if it's already defined:

Regarding the structure of the CPE-ID: I recommend formally stating how CPE will be extended in the future, should the need arise. Currently, all CPE-ID components are separated by a colon. If we state all future extensions to CPE-IDs will take the form of additional colon-separated values being appended to the end, then we can provide implementers with an opportunity to future proof their CPE-ID parsers. I mention this now as it relates to the question regarding what to do with the platform architecture (#1) - build it in as a sub component of <version> <edition> or create a distinct <architecture> component.

One final blurb - it would be sweet if we could come up with a way to achieve all this w/o having to deprecate the existing namespace. I think this is possible but only if we forego the efficiencies in the CPE-ID generation algorithm described at the top of this and Jeff's email. If the community agrees to move in the algorithm direction then I recommend deprecating.

Blake

-----Original Message-----
From: Jeffery Turner [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 1:31 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I like Maneesh's suggestion regarding programmatic determination of the OS and translating that to determine a CPE.  The ProductType can be used to determine the edition.

There does need to be a way to distinguish between these products within a CPE just like there needs to be a way to distinguish "Windows 2008 Server Core" from other Windows 2008 installations.   I am not putting forth that CPE should not be able to distinguish Win XP x64 from Server 2003 x64.  Just that I do not think it is a "Version" distinction.

An example, the following patch applies to both Win XP x64 and Windows Server 2003 x64.  And my database of Microsoft Security Patches has 172 that do the same.
http://download.microsoft.com/download/0/1/2/0123e76a-b415-4af6-b038-b49dd090a0a8/WindowsServer2003.WindowsXP-KB926122-x64-ENU.exe

Technically, the "marketing name" can include the edition and the architecture (when not x86) as well, so the marketing name of Windows XP x64 is actually "Windows XP Professional x64 Edition".  So which marketing name do you use and how do you determine which parts of the marketing name define the version and which parts define the edition, etc?  This introduces a non-deterministic evaluation that results in variance; the exact concern that CPE is trying to eliminate (everybody calling the OS something different and how everybody can enumerate a platform the same way).

Applying a Domain Controller policy based strictly on the marketing name might not be the best option either.  You need to define the ROLE of the system for that.  Operating System Marketing name would not be enough (you probably don't want to apply the domain controller policy to a Web Server or Database Server either).

I agree with Blake when he states:
>I could be way off base here but what I think the CPE community is missing
>is a clear set of rules for determining how to *compute* a CPE-ID for a
>given target Windows (or other platform) box and how that computed CPE-ID
>aligns in the official CPE-ID dictionary.

I also agree with this:
>If we provide CPE consumers with rules on how to derive these values from
>the OS to build a CPE-ID from the target computer it no longer matters if >we use build numbers or marketing names for composing the CPE-ID - make it >a GUID, even, so long as the <title> is understandable by a human.

Providing a standard title for each CPE should reflect a "marketing name" and products / UIs can maintain CPE compatibility while obfuscating the computation of the ID.  The end user of a product does not need to see the ID.  The relevant software can handle that.  CPE just gives us a standard way to define all the components of a platform for cross compatibility.

I like where Blake is going in determining an algorithm for computing a CPE because an evaluation of system characteristics should always produce the same result.  It eliminates the variants in naming where there are multiple marketing names and confusion over whether "Windows XP Professional" should include x64 or if that is strictly the marketing name for x86.  An algorithm provides a more "mathematical" formula where all CPE-knowledgeable persons could take a new variant of Windows and compute the same CPE.  That said, my algorithm might look a little different.  I would favor using Windows numeric versions for versions and leave the marketing name for display values.

Ultimately, I think the CPE consumers (software developers, technical control authors, etc) have a different need than the consumer of a software product that uses CPEs.  I think the software developer's goal when using CPE is to transparently provide a mechanism by which to uniquely identify platforms and provide a way to communicate and evaluate the affected platforms clearly.  The end user does not need to be aware of the "id" at all.

As for DISA, Microsoft, CIS, other security policies, they do not always all use the SAME marketing name.  They are written to groupings of platforms that contain ambiguities because they do not use CPEs or something specific.  They often make assumptions about how the end user defines "Windows XP Professional".  Is that strictly the x86 version?  Because it does not call out x86 vs x64, but that is the marketing name for the x86 variant.  You can easily make a case that the various security policies define groupings of CPEs whether by architecture (x86 vs x64), edition (Standard, Enterprise), or any other characteristic.  And the whole problem is what CPE should be trying to rectify...how to clearly state what system(s) a security template, patch, or whatever should apply to rather than leaving it up to evaluation where we all disagree about the author's intent.  We just have to get the authors onboard with using CPE. :-)

Overall, I am not necessarily committed to "Version" vs. "Edition" on the x86 vs x64 issue.  I do think a good goal of CPE should be to provide an enumeration based on objective criteria in an algorithm such that a newly released variant of an existing OS can be computed identically by different people in different places based off a shared formula, though that may be a little idealistic.




-----Original Message-----
From: Maneesh Jolly [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 3:24 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I feel that making a choice between whether to use version info like "5.1",
"5.2" etc or to use marketing name might not be able to put all the
Microsoft OS naming issues to bed.
Incase we choose to go with version info like "5.1", "5.2" etc. then we also
need to take care of Product Type (wProductType received from
GetNativeSystemInfo) to distinguish between Vista and 2008, both of which
have version 6.0 and can have same build number, revision etc. Marketing
name can be inferred by using version and product type. e.g.
Version + Product type = marketing name
5.0 + Workstataion = Windows 2000 prof
5.0 + Server = Windows 2000 server
5.1 + Workstation = Windows XP
5.2 + Workstation = Windows XP 64 bit
5.2 + Server = Windows 2003 server
6.0 + workstation = Windows Vista
6.0 + server = Windows 2008 server

I am also in favor of Option 2 implemented along the lines proposed by
Blake's concept. The easiest method for making new CPE Ids for Microsoft OS
would be to use the values retrieved from the system as CPE components. But
this approach will make CPE Ids very unreadable.

Thanks,
Maneesh


-----Original Message-----
From: Blake Frantz [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 8:35 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I agree that XP and Win2k3 are born of the same kernel, shell, etc. Same
with Win2k Server and Workstation, and NT Server and Workstation. In many
instances patches may be the same. Configuration recommendations may largely
overlap. But they are not entirely the same beast. You're not legitimately
going to enable the Domain Controller role on an XP box. Nor the DNS, DHCP,
or WINS server roles. Any guidance or vulnerability information affecting
these roles (which are part of the platform) are applicable to Win2k3 but
not applicable XP. Given this, I recommend we maintain discrete CPE-IDs for
each "marketing name".

That being said, I don't have a strong opinion on if the CPE-ID is
constructed from marketing names or build names. I do know, however, that
all the vulnerability and guidance information I'm aware of today for the
Windows platforms operates at the "marketing name" level.

1. Vulnerability information resides at the "marketing name" level
        - The "Affected Software" section of MS Security bulletins use terms
such as - no build info present.
                - Windows Server 2003 Service Pack 1
                - Windows Server 2003 Service Pack 2
                - Windows XP Professional x64 Edition
                - Windows XP Professional x64 Edition Service Pack 2
                - Windows Server 2003 with SP1 for Itanium-based Systems
                - Windows Server 2003 with SP2 for Itanium-based Systems
                - Windows Server 2008 for 32-bit Systems
                - Windows Server 2008 for x64-based Systems

        - Pick your favorite vulnerability aggregator, they operate at the
same level.
        - CVE Overviews operate at the "marketing level". No mention of
build information.

2. Security Guidance operates at the "marketing name" level
        - Microsoft security guides do not mention build version
        - CIS guides don't mention build numbers
        - DISA STIGs don't mention build numbers
        - All three use "marketing name"

Again, I'm not hung up on the composition of the CPE at this point because
no matter the composition of the identifier the only important thing is how
you define what the identifier represents.

I could be way off base here but what I think the CPE community is missing
is a clear set of rules for determining how to *compute* a CPE-ID for a
given target Windows (or other platform) box and how that computed CPE-ID
aligns in the official CPE-ID dictionary.

We have a discrete list of information we know we need to get off the box:

        1. Vendor
        2. Product
        3. Version
        4. Update
        5. Edition
        6. Language

If we provide CPE consumers with rules on how to derive these values from
the OS to build a CPE-ID from the target computer it no longer matters if we
use build numbers or marketing names for composing the CPE-ID - make it a
GUID, even, so long as the <title> is understandable by a human.

We could borrow from the IETF and other standards bodies and accomplish this
using BNF (http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form) backed by
a procedure for how an implementer should compute a CPE-ID from a given
Windows box.  Here's an example of what this might look like:

Note: The emphasis here is on the concept, not the specifics of where or how
I'm getting the information. There are much better ways to go about
gathering some of this information and even different values to use.

The BNF:

<cpe-id> ::= "cpe:/" <part> ":" <vendor> ":" <product> ":" <version> ":"
<update> ":" <edition_base> <edition_arch> ":" <language>

Examples:
cpe:/o:microsoft:windows:server_2003:::
Windows Server 2003
cpe:/o:microsoft:windows:server_2003::datacenter:
Windows Server 2003 Data Center Edition
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_x86:
Windows Server 2003 SP 1 Data Center Edition for 32-bit systems
cpe:/o:microsoft:windows:server_2003:sp2:datacenter_x64:
Windows Server 2003 SP 2 Data Center Edition for x64-bit systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:
Windows Server 2003 SP 1 Data Center Edition for Itanium systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:ar
Windows Server 2003 SP 1 Arabic Data Center Edition for Itanium systems

Implementers should use the following algorithm to compute the CPE ID for a
given Microsoft Windows system:

1. set <part> to "o"
2. set <vendor> to "microsoft"
3. set <product> to "windows"
4. set <version> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string>                        <version>
        "Windows Server 2003"   "server_2003"
        "Windows XP"            "xp"
        "Windows Vista          "vista"

5. set <update> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion

        <string>                        <update>
        "Service Pack 1"                "sp1"
        "Service Pack 2"                "sp2"
        ""                              ""

6. set <edition_base> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string>                <edition>
        "Data Center"   "datacenter"
        "Professional"  "pro"
        "home"          "home"
        "Ultimate"              "ultimate"

7. set <edition_arch> based on the <value> found in
SYSTEM_INFO.dwProcessorType returned from GetNativeSystemInfo()[2]

        <value>         <edition_arch>
        0x09                    "_x64"
        0x06                    "_ia64"
        0x00                    "_x86"

8. set <language> based on the <value> returned from
GetSystemDefaultLangID()[1]

        <value  <language>
        0x0409  "en"            (English)
        0x1401  "ar"            (Arabic)
        ...

Again, there are a obvious ways we can avoid building tables, supported
APIs[3] we could use, and different CPE-ID forms we might adopt to achieve
this - the emphasis is on the concept. With something similar to this, CPE
consumers can build a CPE-ID from a host, determine which CPE-ID the target
"belongs to" then apply "the content" (i.e XCCDF/OVAL/etc). When the above
is finalized, I could see value in a reference implementation for "CPE_INFO*
ComputeCPE()" that returns a structure or class that contains each
subcomponent of a CPE-ID - or maybe I'm in orbit some place.

The next step as I see it is to provide rules for CPE-ID globbing. This
would take the form of another set of rules for how a CPE-ID matches up with
the official set. I can image a reference implementation of "CPE_LIST*
ResolveCPE(char* computedCpe)" that returns an array of CPE_INFO
structures/classes from the official dictionary that match the CPE-ID
computed using a procedure similar to the one provided above. Again - I may
be in orbit here, but I think those writing tools and those building mega
maps might value this information.

These concepts would obvious apply to other platforms as well, including
your favorite *NIX's.

An additional benefit of this model is a decreased chance of software
vendors classifying a population of machines differently due to differences
in how they determine which CPE-ID a target "belongs to".

SO.....What are some thoughts on all this? If this is something the
community thinks is sane I'm happy to help create the draft for what the
real procedures might look like. Or I can put the keyboard down and slowly
back away from my computer. :)

Blake


[1] http://msdn.microsoft.com/en-us/library/dd318120(VS.85).aspx
[2] http://msdn.microsoft.com/en-us/library/ms724340(VS.85).aspx
[3] http://msdn.microsoft.com/en-us/library/ms724429(VS.85).aspx


-----Original Message-----
From: David Raphael [mailto:[hidden email]]
Sent: Wednesday, May 27, 2009 4:24 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

Reply from Jeff Turner (my coworker can't post to the list at the moment):

I humbly disagree.  Windows Server 2003 x64 and Windows XP x64 receive
identical patch packages.  Calculate an MD5 (or hash of your choosing)
on the patches delivered by WSUS / Windows Update / Patch Delivery tool
of your choosing to both Operating Systems.  It is the same file.  And
those patches deploy the same binary files.

Win XP x64 and Server 2003 x64 are as closely related as Windows 2000
Professional and Windows 2000 Server.  The marketing names just muddy
the issue.  Sure there are components that are not available in the
"Workstation" Edition vs the "Server" Editions of an Operating System.
Just like there are components that differentiate Windows Server 2003
Standard from Enterprise.

CPE can still be an effective tool to enumerate these, though edition is
probably where the distinction properly lies (read: Option 2).  I think
that Windows Server 2003 / XP x64 can and should be identified
similarly.

The difficulty is trying to educate people that XP x64 is the little
brother to Server 2003 x64 and only a first cousin to XP x86.  I think
the marketing names only serve to perpetuate the confusion.




On 5/27/09 4:34 PM, "Gary Newman" <[hidden email]> wrote:

As prior discussions have pointed out, the issue here is whether CPE will
attempt to reverse engineer a vendors products to determine which marketing
names refer to the same internals.  We concluded that wasn't reasonable.
For
example, although WinXP x64 is reportedly built from the same source code as
Windows Server 2003 they're clearly not the same binaries.  In addition to
the
builds using different compile-time options, the final packaged product for
Server 2003 has components that aren't in WinXP.

The justification that "marketing names change frequently" appears to be
another claim that the CPE community can reverse engineer a new product to
determine that it's the same as that of a previous product.

It seems like use of a product's marketing name is the only viable way to
name
a CPE.

        -Gary-

> ** reply by Friday June 5th **
>
> The creation of CPE Names for the different Microsoft operating systems
has
> been a source of discussion since the beginning of CPE.  In October 2007
the
> issue was discussed in depth and it was decided to that these names should
be
> based off of the commonly known marketing names.  We have tried this
approach
> for the past year and a half but some issues still remain.
>
> We are realizing that names based off the marketing names are hard to
manage
> as marketing  names change frequently.  Marketing names also lead to
incorrect
> CPE Matching as a marketing name may stay the same but the underlying code
may
> change.  Or the marketing name may change even if the code doesn't.
>
> I'd like to formally bring this up this issue to the CPE community again
and
> make sure we are still going down the correct path.  Obviously, one option
> will be to keep going down the current path.  But other options would
require
> changes to the current names.  This would mean a lot of depreciation and
> potential vendor work to readjust their mapping.  The costs of this change
may
> not be worth the benefits.  Unfortunately I do not see the issues and/or
> discussions surrounding Microsoft names subsiding until we fix the root of
the
> problem.  So at some point I think we are going to have to make some type
of
> change.
>
> Some examples of the issues we currently face:
>
> - Windows XP 64-Bit Edition, Version 2003 which is actually based off of
the
> code for Windows Server 2003
>
> - determining which CPE Name to use being difficult as the technical
> information returned from a system query is not associated with any CPE
Name
>
> - inconsistencies when dealing with beta and pre-releases, for example the
> current Windows 7 betas and if the OS marketing name will actually be
Windows
> 7
>
> - difficulty determining if certain updates/editions are really different
> versions, for example the R2 releases
>
> - inconsistency between operating system and application naming as many of
the
> Microsoft application names follow the technical name  (see Internet
> Explorer)
>
> Below are two options that I see as possible paths forward.  I urge
everyone
> to share their opinion as we can only understand the best course by
knowing
> how it affects the entire community.  If you have other ideas, please
don't be
> afraid to share them as well.
>
> Discussion on this issue will end on Friday June 5th (3 weeks) at which
time a
> decision will be made based on community consensus.
>
> ----------------------------------
> OPTION 1
> ----------------------------------
>
> Keep things the way they currently are.  Although not perfect, the current
way
> of creating CPE Names for Microsoft operating systems is a good balance
> between technical correctness and human understanding.  In addition, the
work
> required to deprecate the current Microsoft CPE Names and remap to new
names
> would not be worth the benefits of the change.
>
> The CPE Specification should be updated to clarify how create CPE Names
for
> Microsoft operating systems and platforms that exhibit related properties.
>
> ----------------------------------
> OPTION 2
> ----------------------------------
>
> In order to put to bed the continued discussions on Microsoft names we
should
> change how we create these names.  We should leverage the internal version
of
> the operating system and use that in the version component.  In a way,
this is
> more true to the current CPE Specification.
>
> The <title> element in the dictionary would be used to hold the marketing
name
> associated with each different version.  For example:
>
> cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
> cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003
SP2
>
> Note that this option would require deprecating all the existing Microsoft
> names in the CPE dictionary.  But this option better aligns with the way
the

> specification is currently written.
>
> ----------------------------------
> ----------------------------------
>
> Again, I urge everyone to share their opinion by Friday June 5th.
>
>
> Thanks
> Drew
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>


--
David Raphael

Research Tools Manager
Risk and Compliance Security Research
McAfee, Inc.

972.963.7224 Direct
214.769.6098 Mobile

[hidden email]
http://www.mcafee.com
Reply | Threaded
Open this post in threaded view
|

Re: Microsoft OS Naming Issue

Kurt Dillard
Blake;
Rather than processor architecture I think we want the OS architecture. Most
of the data is in the registry, but the only way I know to get the OS
architecture is via WMI. There's probably some API accessible through C++
and C# that I don't know about though.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion:

-The version, stored as CurrentVersion, is in x.y format where x is the
major version and y the minor. So 6.0 is Vista, 6.1 is Win7.
-The build, stored as CurrentBuild, in xxxx format, So Win7 RC is 7100
-The service pack, stored in CSDVersion as a string
-The commercial name, stored in ProductName, as a string, e.g. Windows Vista
Ultimate.

-----Original Message-----
From: Blake Frantz [mailto:[hidden email]]
Sent: Friday, May 29, 2009 2:53 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

>>That said, my algorithm might look a little different.  I would favor
using Windows numeric versions for >>versions and leave the marketing name
for display values.

I agree. We should be able to take values directly out of a reg key,
structure, or return value from a native API call to build a CPE-ID. This
would be a much cleaner solution to implement.

If this is the direction people want to move in I recommend we:

1. Revisit the components that are interesting to us from a CPE-ID
generation perspective.

        Note: Processor architecture has come up a few times. I'm in favor
of including this in the CPE ID. My  initial thought is to slap it on the
end after <language> as its own component - though this would change
the composition of CPE-IDs across the board.

2. Scope the windows platforms we want a procedure for.

3. For each windows platform in our scope, identify the supported APIs or
mechanisms to obtain the information determined in #1.

4. Write the procedure for computing a CPE-ID using the least common
denominators from #3.

Thoughts?

Also, please excuse the following if it's already defined:

Regarding the structure of the CPE-ID: I recommend formally stating how CPE
will be extended in the future, should the need arise. Currently, all CPE-ID
components are separated by a colon. If we state all future extensions to
CPE-IDs will take the form of additional colon-separated values being
appended to the end, then we can provide implementers with an opportunity to
future proof their CPE-ID parsers. I mention this now as it relates to the
question regarding what to do with the platform architecture (#1) - build it
in as a sub component of <version> <edition> or create a distinct
<architecture> component.

One final blurb - it would be sweet if we could come up with a way to
achieve all this w/o having to deprecate the existing namespace. I think
this is possible but only if we forego the efficiencies in the CPE-ID
generation algorithm described at the top of this and Jeff's email. If the
community agrees to move in the algorithm direction then I recommend
deprecating.

Blake

-----Original Message-----
From: Jeffery Turner [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 1:31 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I like Maneesh's suggestion regarding programmatic determination of the OS
and translating that to determine a CPE.  The ProductType can be used to
determine the edition.

There does need to be a way to distinguish between these products within a
CPE just like there needs to be a way to distinguish "Windows 2008 Server
Core" from other Windows 2008 installations.   I am not putting forth that
CPE should not be able to distinguish Win XP x64 from Server 2003 x64.  Just
that I do not think it is a "Version" distinction.

An example, the following patch applies to both Win XP x64 and Windows
Server 2003 x64.  And my database of Microsoft Security Patches has 172 that
do the same.
http://download.microsoft.com/download/0/1/2/0123e76a-b415-4af6-b038-b49dd09
0a0a8/WindowsServer2003.WindowsXP-KB926122-x64-ENU.exe

Technically, the "marketing name" can include the edition and the
architecture (when not x86) as well, so the marketing name of Windows XP x64
is actually "Windows XP Professional x64 Edition".  So which marketing name
do you use and how do you determine which parts of the marketing name define
the version and which parts define the edition, etc?  This introduces a
non-deterministic evaluation that results in variance; the exact concern
that CPE is trying to eliminate (everybody calling the OS something
different and how everybody can enumerate a platform the same way).

Applying a Domain Controller policy based strictly on the marketing name
might not be the best option either.  You need to define the ROLE of the
system for that.  Operating System Marketing name would not be enough (you
probably don't want to apply the domain controller policy to a Web Server or
Database Server either).

I agree with Blake when he states:
>I could be way off base here but what I think the CPE community is missing
>is a clear set of rules for determining how to *compute* a CPE-ID for a
>given target Windows (or other platform) box and how that computed CPE-ID
>aligns in the official CPE-ID dictionary.

I also agree with this:
>If we provide CPE consumers with rules on how to derive these values from
>the OS to build a CPE-ID from the target computer it no longer matters if
>we use build numbers or marketing names for composing the CPE-ID - make it
>a GUID, even, so long as the <title> is understandable by a human.

Providing a standard title for each CPE should reflect a "marketing name"
and products / UIs can maintain CPE compatibility while obfuscating the
computation of the ID.  The end user of a product does not need to see the
ID.  The relevant software can handle that.  CPE just gives us a standard
way to define all the components of a platform for cross compatibility.

I like where Blake is going in determining an algorithm for computing a CPE
because an evaluation of system characteristics should always produce the
same result.  It eliminates the variants in naming where there are multiple
marketing names and confusion over whether "Windows XP Professional" should
include x64 or if that is strictly the marketing name for x86.  An algorithm
provides a more "mathematical" formula where all CPE-knowledgeable persons
could take a new variant of Windows and compute the same CPE.  That said, my
algorithm might look a little different.  I would favor using Windows
numeric versions for versions and leave the marketing name for display
values.

Ultimately, I think the CPE consumers (software developers, technical
control authors, etc) have a different need than the consumer of a software
product that uses CPEs.  I think the software developer's goal when using
CPE is to transparently provide a mechanism by which to uniquely identify
platforms and provide a way to communicate and evaluate the affected
platforms clearly.  The end user does not need to be aware of the "id" at
all.

As for DISA, Microsoft, CIS, other security policies, they do not always all
use the SAME marketing name.  They are written to groupings of platforms
that contain ambiguities because they do not use CPEs or something specific.
They often make assumptions about how the end user defines "Windows XP
Professional".  Is that strictly the x86 version?  Because it does not call
out x86 vs x64, but that is the marketing name for the x86 variant.  You can
easily make a case that the various security policies define groupings of
CPEs whether by architecture (x86 vs x64), edition (Standard, Enterprise),
or any other characteristic.  And the whole problem is what CPE should be
trying to rectify...how to clearly state what system(s) a security template,
patch, or whatever should apply to rather than leaving it up to evaluation
where we all disagree about the author's intent.  We just have to get the
authors onboard with using CPE. :-)

Overall, I am not necessarily committed to "Version" vs. "Edition" on the
x86 vs x64 issue.  I do think a good goal of CPE should be to provide an
enumeration based on objective criteria in an algorithm such that a newly
released variant of an existing OS can be computed identically by different
people in different places based off a shared formula, though that may be a
little idealistic.




-----Original Message-----
From: Maneesh Jolly [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 3:24 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I feel that making a choice between whether to use version info like "5.1",
"5.2" etc or to use marketing name might not be able to put all the
Microsoft OS naming issues to bed.
Incase we choose to go with version info like "5.1", "5.2" etc. then we also
need to take care of Product Type (wProductType received from
GetNativeSystemInfo) to distinguish between Vista and 2008, both of which
have version 6.0 and can have same build number, revision etc. Marketing
name can be inferred by using version and product type. e.g.
Version + Product type = marketing name
5.0 + Workstataion = Windows 2000 prof
5.0 + Server = Windows 2000 server
5.1 + Workstation = Windows XP
5.2 + Workstation = Windows XP 64 bit
5.2 + Server = Windows 2003 server
6.0 + workstation = Windows Vista
6.0 + server = Windows 2008 server

I am also in favor of Option 2 implemented along the lines proposed by
Blake's concept. The easiest method for making new CPE Ids for Microsoft OS
would be to use the values retrieved from the system as CPE components. But
this approach will make CPE Ids very unreadable.

Thanks,
Maneesh


-----Original Message-----
From: Blake Frantz [mailto:[hidden email]]
Sent: Thursday, May 28, 2009 8:35 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

I agree that XP and Win2k3 are born of the same kernel, shell, etc. Same
with Win2k Server and Workstation, and NT Server and Workstation. In many
instances patches may be the same. Configuration recommendations may largely
overlap. But they are not entirely the same beast. You're not legitimately
going to enable the Domain Controller role on an XP box. Nor the DNS, DHCP,
or WINS server roles. Any guidance or vulnerability information affecting
these roles (which are part of the platform) are applicable to Win2k3 but
not applicable XP. Given this, I recommend we maintain discrete CPE-IDs for
each "marketing name".

That being said, I don't have a strong opinion on if the CPE-ID is
constructed from marketing names or build names. I do know, however, that
all the vulnerability and guidance information I'm aware of today for the
Windows platforms operates at the "marketing name" level.

1. Vulnerability information resides at the "marketing name" level
        - The "Affected Software" section of MS Security bulletins use terms
such as - no build info present.
                - Windows Server 2003 Service Pack 1
                - Windows Server 2003 Service Pack 2
                - Windows XP Professional x64 Edition
                - Windows XP Professional x64 Edition Service Pack 2
                - Windows Server 2003 with SP1 for Itanium-based Systems
                - Windows Server 2003 with SP2 for Itanium-based Systems
                - Windows Server 2008 for 32-bit Systems
                - Windows Server 2008 for x64-based Systems

        - Pick your favorite vulnerability aggregator, they operate at the
same level.
        - CVE Overviews operate at the "marketing level". No mention of
build information.

2. Security Guidance operates at the "marketing name" level
        - Microsoft security guides do not mention build version
        - CIS guides don't mention build numbers
        - DISA STIGs don't mention build numbers
        - All three use "marketing name"

Again, I'm not hung up on the composition of the CPE at this point because
no matter the composition of the identifier the only important thing is how
you define what the identifier represents.

I could be way off base here but what I think the CPE community is missing
is a clear set of rules for determining how to *compute* a CPE-ID for a
given target Windows (or other platform) box and how that computed CPE-ID
aligns in the official CPE-ID dictionary.

We have a discrete list of information we know we need to get off the box:

        1. Vendor
        2. Product
        3. Version
        4. Update
        5. Edition
        6. Language

If we provide CPE consumers with rules on how to derive these values from
the OS to build a CPE-ID from the target computer it no longer matters if we
use build numbers or marketing names for composing the CPE-ID - make it a
GUID, even, so long as the <title> is understandable by a human.

We could borrow from the IETF and other standards bodies and accomplish this
using BNF (http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form) backed by
a procedure for how an implementer should compute a CPE-ID from a given
Windows box.  Here's an example of what this might look like:

Note: The emphasis here is on the concept, not the specifics of where or how
I'm getting the information. There are much better ways to go about
gathering some of this information and even different values to use.

The BNF:

<cpe-id> ::= "cpe:/" <part> ":" <vendor> ":" <product> ":" <version> ":"
<update> ":" <edition_base> <edition_arch> ":" <language>

Examples:
cpe:/o:microsoft:windows:server_2003:::
Windows Server 2003
cpe:/o:microsoft:windows:server_2003::datacenter:
Windows Server 2003 Data Center Edition
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_x86:
Windows Server 2003 SP 1 Data Center Edition for 32-bit systems
cpe:/o:microsoft:windows:server_2003:sp2:datacenter_x64:
Windows Server 2003 SP 2 Data Center Edition for x64-bit systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:
Windows Server 2003 SP 1 Data Center Edition for Itanium systems
cpe:/o:microsoft:windows:server_2003:sp1:datacenter_ia64:ar
Windows Server 2003 SP 1 Arabic Data Center Edition for Itanium systems

Implementers should use the following algorithm to compute the CPE ID for a
given Microsoft Windows system:

1. set <part> to "o"
2. set <vendor> to "microsoft"
3. set <product> to "windows"
4. set <version> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string>                        <version>
        "Windows Server 2003"   "server_2003"
        "Windows XP"            "xp"
        "Windows Vista          "vista"

5. set <update> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion

        <string>                        <update>
        "Service Pack 1"                "sp1"
        "Service Pack 2"                "sp2"
        ""                              ""

6. set <edition_base> based on the presence of <string> in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

        <string>                <edition>
        "Data Center"   "datacenter"
        "Professional"  "pro"
        "home"          "home"
        "Ultimate"              "ultimate"

7. set <edition_arch> based on the <value> found in
SYSTEM_INFO.dwProcessorType returned from GetNativeSystemInfo()[2]

        <value>         <edition_arch>
        0x09                    "_x64"
        0x06                    "_ia64"
        0x00                    "_x86"

8. set <language> based on the <value> returned from
GetSystemDefaultLangID()[1]

        <value  <language>
        0x0409  "en"            (English)
        0x1401  "ar"            (Arabic)
        ...

Again, there are a obvious ways we can avoid building tables, supported
APIs[3] we could use, and different CPE-ID forms we might adopt to achieve
this - the emphasis is on the concept. With something similar to this, CPE
consumers can build a CPE-ID from a host, determine which CPE-ID the target
"belongs to" then apply "the content" (i.e XCCDF/OVAL/etc). When the above
is finalized, I could see value in a reference implementation for "CPE_INFO*
ComputeCPE()" that returns a structure or class that contains each
subcomponent of a CPE-ID - or maybe I'm in orbit some place.

The next step as I see it is to provide rules for CPE-ID globbing. This
would take the form of another set of rules for how a CPE-ID matches up with
the official set. I can image a reference implementation of "CPE_LIST*
ResolveCPE(char* computedCpe)" that returns an array of CPE_INFO
structures/classes from the official dictionary that match the CPE-ID
computed using a procedure similar to the one provided above. Again - I may
be in orbit here, but I think those writing tools and those building mega
maps might value this information.

These concepts would obvious apply to other platforms as well, including
your favorite *NIX's.

An additional benefit of this model is a decreased chance of software
vendors classifying a population of machines differently due to differences
in how they determine which CPE-ID a target "belongs to".

SO.....What are some thoughts on all this? If this is something the
community thinks is sane I'm happy to help create the draft for what the
real procedures might look like. Or I can put the keyboard down and slowly
back away from my computer. :)

Blake


[1] http://msdn.microsoft.com/en-us/library/dd318120(VS.85).aspx
[2] http://msdn.microsoft.com/en-us/library/ms724340(VS.85).aspx
[3] http://msdn.microsoft.com/en-us/library/ms724429(VS.85).aspx


-----Original Message-----
From: David Raphael [mailto:[hidden email]]
Sent: Wednesday, May 27, 2009 4:24 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

Reply from Jeff Turner (my coworker can't post to the list at the moment):

I humbly disagree.  Windows Server 2003 x64 and Windows XP x64 receive
identical patch packages.  Calculate an MD5 (or hash of your choosing)
on the patches delivered by WSUS / Windows Update / Patch Delivery tool
of your choosing to both Operating Systems.  It is the same file.  And
those patches deploy the same binary files.

Win XP x64 and Server 2003 x64 are as closely related as Windows 2000
Professional and Windows 2000 Server.  The marketing names just muddy
the issue.  Sure there are components that are not available in the
"Workstation" Edition vs the "Server" Editions of an Operating System.
Just like there are components that differentiate Windows Server 2003
Standard from Enterprise.

CPE can still be an effective tool to enumerate these, though edition is
probably where the distinction properly lies (read: Option 2).  I think
that Windows Server 2003 / XP x64 can and should be identified
similarly.

The difficulty is trying to educate people that XP x64 is the little
brother to Server 2003 x64 and only a first cousin to XP x86.  I think
the marketing names only serve to perpetuate the confusion.




On 5/27/09 4:34 PM, "Gary Newman" <[hidden email]> wrote:

As prior discussions have pointed out, the issue here is whether CPE will
attempt to reverse engineer a vendors products to determine which marketing
names refer to the same internals.  We concluded that wasn't reasonable.
For
example, although WinXP x64 is reportedly built from the same source code as
Windows Server 2003 they're clearly not the same binaries.  In addition to
the
builds using different compile-time options, the final packaged product for
Server 2003 has components that aren't in WinXP.

The justification that "marketing names change frequently" appears to be
another claim that the CPE community can reverse engineer a new product to
determine that it's the same as that of a previous product.

It seems like use of a product's marketing name is the only viable way to
name
a CPE.

        -Gary-

> ** reply by Friday June 5th **
>
> The creation of CPE Names for the different Microsoft operating systems
has
> been a source of discussion since the beginning of CPE.  In October 2007
the
> issue was discussed in depth and it was decided to that these names should
be
> based off of the commonly known marketing names.  We have tried this
approach
> for the past year and a half but some issues still remain.
>
> We are realizing that names based off the marketing names are hard to
manage
> as marketing  names change frequently.  Marketing names also lead to
incorrect
> CPE Matching as a marketing name may stay the same but the underlying code
may
> change.  Or the marketing name may change even if the code doesn't.
>
> I'd like to formally bring this up this issue to the CPE community again
and
> make sure we are still going down the correct path.  Obviously, one option
> will be to keep going down the current path.  But other options would
require
> changes to the current names.  This would mean a lot of depreciation and
> potential vendor work to readjust their mapping.  The costs of this change
may
> not be worth the benefits.  Unfortunately I do not see the issues and/or
> discussions surrounding Microsoft names subsiding until we fix the root of
the
> problem.  So at some point I think we are going to have to make some type
of
> change.
>
> Some examples of the issues we currently face:
>
> - Windows XP 64-Bit Edition, Version 2003 which is actually based off of
the
> code for Windows Server 2003
>
> - determining which CPE Name to use being difficult as the technical
> information returned from a system query is not associated with any CPE
Name
>
> - inconsistencies when dealing with beta and pre-releases, for example the
> current Windows 7 betas and if the OS marketing name will actually be
Windows
> 7
>
> - difficulty determining if certain updates/editions are really different
> versions, for example the R2 releases
>
> - inconsistency between operating system and application naming as many of
the
> Microsoft application names follow the technical name  (see Internet
> Explorer)
>
> Below are two options that I see as possible paths forward.  I urge
everyone
> to share their opinion as we can only understand the best course by
knowing
> how it affects the entire community.  If you have other ideas, please
don't be
> afraid to share them as well.
>
> Discussion on this issue will end on Friday June 5th (3 weeks) at which
time a
> decision will be made based on community consensus.
>
> ----------------------------------
> OPTION 1
> ----------------------------------
>
> Keep things the way they currently are.  Although not perfect, the current
way
> of creating CPE Names for Microsoft operating systems is a good balance
> between technical correctness and human understanding.  In addition, the
work
> required to deprecate the current Microsoft CPE Names and remap to new
names
> would not be worth the benefits of the change.
>
> The CPE Specification should be updated to clarify how create CPE Names
for
> Microsoft operating systems and platforms that exhibit related properties.
>
> ----------------------------------
> OPTION 2
> ----------------------------------
>
> In order to put to bed the continued discussions on Microsoft names we
should
> change how we create these names.  We should leverage the internal version
of
> the operating system and use that in the version component.  In a way,
this is
> more true to the current CPE Specification.
>
> The <title> element in the dictionary would be used to hold the marketing
name
> associated with each different version.  For example:
>
> cpe:/o:microsoft:windows:5.1.2600  -  Microsoft Windows XP
> cpe:/o:microsoft:windows:5.1.2600:2180  -  Microsoft Windows XP SP2
> cpe:/o:microsoft:windows:5.1.2600:5512  -  Microsoft Windows XP SP3
> cpe:/o:microsoft:windows:5.2.3790  -  Microsoft Windows Server 2003
> cpe:/o:microsoft:windows:5.2.3790:3959  -  Microsoft Windows Server 2003
SP2
>
> Note that this option would require deprecating all the existing Microsoft
> names in the CPE dictionary.  But this option better aligns with the way
the

> specification is currently written.
>
> ----------------------------------
> ----------------------------------
>
> Again, I urge everyone to share their opinion by Friday June 5th.
>
>
> Thanks
> Drew
>
>
>
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>
>


--
David Raphael

Research Tools Manager
Risk and Compliance Security Research
McAfee, Inc.

972.963.7224 Direct
214.769.6098 Mobile

[hidden email]
http://www.mcafee.com
12