Microsoft OS Naming Issue
|
|
| 1 2 |
Andrew Buttner
|
** 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 |
||||||||||||||||
|
Andrew Buttner
|
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 |
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.
Robert Neuman
|
||||||||||||||||
Thomas R. 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. |
||||||||||||||||
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 >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 >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 >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 >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 |
||||||||||||||||
|
Andrew Buttner
|
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 |
||||||||||||||||
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. |
||||||||||||||||
|
Andrew Buttner
|
>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? |
||||||||||||||||
|
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? |
||||||||||||||||
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 > > > |
||||||||||||||||
|
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? |
||||||||||||||||
|
Robert Neuman
|
In reply to this post
by Andrew Buttner
We'll need the Major.Minor.Build.Revision numbers a list is here:
Robert Neuman
|
||||||||||||||||
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 > > 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 > > The CPE Specification should be updated to clarify how create CPE > Names for Microsoft operating systems and platforms that exhibit related > > ---------------------------------- > 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) |
Andrew Buttner
|
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? |
||||||||||||||||
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 |
||||||||||||||||
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 |
||||||||||||||||
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 |
||||||||||||||||
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 |
||||||||||||||||
|
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 |
||||||||||||||||
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 |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
