Re: Thoughts on Microsoft names and drinkin g our own kool-aid

[Wolfkiel, Joseph]

Hoo boy.  Guess this is a real can of worms.  

So I guess, in the spirit of drinking our own kool-aid, we still need to
pick names we can reasonably expect someone to arrive at based on some
common indicator and a prima-facie reading of the CPE spec.  

Sounds like "Microsoft Windows XP" may be the reasonable common denominator,
pending differing input from the manufacturer...  

So are you thinking the cpe should be "cpe:/o:ms:win:xp" for XP and similar
names for the the other Microsoft OSs?  Or, admitting the "windows"
designation seems to be Microsoft's notation that this software is an OS
versus an application and doesn't really identify discreet products, should
it be "cpe:/o:ms:windows_xp"?

How do we resolve this?  Vote?

Lt Col Joseph L. Wolfkiel

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

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: Gary Newman [mailto:[hidden email]]
Sent: Tuesday, September 25, 2007 4:25 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinking our own kool-aid


Hi Joe,

The technet article you've cited is very loosely saying that Windows XP
reports
"Microsoft Windows NT Workstation 5.1" to the SMS client.  I'm not aware of
any
registry value similar to a string like that.  The SMS client is most likely

creating that string by pulling together other data that's not all in the
registry (e.g. API calls).  I'd suggest that we not consider names created
by
the SMS client as a vendor Registered Name.

Windows XP doesn't refer to itself as Windows NT anywhere that I know of
(ignoring the registry keys below, as they also can appear on Windows 95
computers).  However, the Windows XP registry does have the string
"Microsoft
Windows XP" in the registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

That said, it's fair to note that Microsoft has the OS identify itself as
compatible with the Windows NT "family" with the GetVersion API call

        http://msdn2.microsoft.com/en-us/library/ms724439.aspx

that returns 0 in the high order bit for NT family and 1 for 9x family.
It's
not clear to me whether compatibility with the NT family implies a taxonomy
appropriate for CPE use.

        -Gary-

> [snip]
> Supporting info.
>
> http://www.microsoft.com/technet/sms/2003/library/deployingwinxpsp2_6.mspx
> The value for OperatingSystemNameandVersion is listed as Microsoft Windows
> NT Workstation 5.1. This is what Windows XP reports to SMS when queried
for
> the operating system. Windows XP without a service pack, Windows XP SP1,
and
> Windows XP SP2 all report the same value.

[Michael Tan]

Based on CPE2.0 loosely defined naming convention I do agree it is important to be clear on picking right strings. The main reason behind my observation is that CPE identifier should help SCAP automation in a way that SCAP tools can tell if a SCAP benchmark can apply to a platform. If there is no clear definition on what OS properties to be used, this becomes mess.

For Windows, OS platform information can be collected by API through WMI service (don't rely on registry because they may change), specifically it is Win32_OperatingSystem under root\cimv2 name space.

I provide a sample script so you get idea how those information are collected. I have to claim I don't intend asking you to run the script on your pc so use it with your own risk:). The script displays CPE string based on 2.0 convention. It should be very simple to map # to actual string, for example, OSLanguage. Edition information is not available for OS before Vista but they are embedded in product name, either leave it empty or parse it.

I hope this helps. Cheers!

===script begin===
' Query for getting Windows CPE2.0 Identifier
 On Error Resume Next
' Connect to WMI and obtain instances of Win32_OperatingSystem
WScript.Echo
For Each objOS in GetObject( _
    "winmgmts:").InstancesOf ("Win32_OperatingSystem")

WScript.Echo "Based on CPE2.0 naming convention, CPE identifier for your OS is:"
' vista WScript.Echo "cpe:/o:" & objOS.Manufacturer & ":" & objOS.Caption & ":" & objOS.Version & ":" & objOS.CSDVersion & ":" '& objOS.OperatingSystemSKU & ":" & objOS.OSLanguage
WScript.Echo "cpe:/o:" & objOS.Manufacturer & ":" & objOS.Caption & ":" & objOS.Version & ":" & objOS.CSDVersion & ":" & ":" & objOS.OSLanguage
Next

if Err <> 0 Then
    WScript.Echo Err.Description
    Err.Clear
End if
===script end===

Michael X. Tan
Senior Program Manager
Microsoft Solution for Security and Compliance

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Tuesday, September 25, 2007 2:03 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and drinkin g our own kool-aid

Hoo boy.  Guess this is a real can of worms.

So I guess, in the spirit of drinking our own kool-aid, we still need to
pick names we can reasonably expect someone to arrive at based on some
common indicator and a prima-facie reading of the CPE spec.

Sounds like "Microsoft Windows XP" may be the reasonable common denominator,
pending differing input from the manufacturer...

So are you thinking the cpe should be "cpe:/o:ms:win:xp" for XP and similar
names for the the other Microsoft OSs?  Or, admitting the "windows"
designation seems to be Microsoft's notation that this software is an OS
versus an application and doesn't really identify discreet products, should
it be "cpe:/o:ms:windows_xp"?

How do we resolve this?  Vote?

Lt Col Joseph L. Wolfkiel

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

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: Gary Newman [mailto:[hidden email]]
Sent: Tuesday, September 25, 2007 4:25 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinking our own kool-aid


Hi Joe,

The technet article you've cited is very loosely saying that Windows XP
reports
"Microsoft Windows NT Workstation 5.1" to the SMS client.  I'm not aware of
any
registry value similar to a string like that.  The SMS client is most likely

creating that string by pulling together other data that's not all in the
registry (e.g. API calls).  I'd suggest that we not consider names created
by
the SMS client as a vendor Registered Name.

Windows XP doesn't refer to itself as Windows NT anywhere that I know of
(ignoring the registry keys below, as they also can appear on Windows 95
computers).  However, the Windows XP registry does have the string
"Microsoft
Windows XP" in the registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

That said, it's fair to note that Microsoft has the OS identify itself as
compatible with the Windows NT "family" with the GetVersion API call

        http://msdn2.microsoft.com/en-us/library/ms724439.aspx

that returns 0 in the high order bit for NT family and 1 for 9x family.
It's
not clear to me whether compatibility with the NT family implies a taxonomy
appropriate for CPE use.

        -Gary-

> [snip]
> Supporting info.
>
> http://www.microsoft.com/technet/sms/2003/library/deployingwinxpsp2_6.mspx
> The value for OperatingSystemNameandVersion is listed as Microsoft Windows
> NT Workstation 5.1. This is what Windows XP reports to SMS when queried
for
> the operating system. Windows XP without a service pack, Windows XP SP1,
and
> Windows XP SP2 all report the same value.

[Wolfkiel, Joseph]

So the DoD has two other use cases:

1.  Use discovered CPE names to search the NVD for vulnerabilities that may
occur on a given platform (as specified by CPE) and;
2.  Use the CPE Dictionary to populate drop-down lists so our network
defenders can build CPE definitions to search our assets for specific
configurations--via a web service--on CPE-compliant products

These two use cases may give me a somewhat different perspective on what I
want from CPE.  However, I don't think they're unique to the DoD.  I also
believe we can tweak CPE to meet all the use cases if we acknowledge them.

Lt Col Joseph L. Wolfkiel

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

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: Michael Tan [mailto:[hidden email]]
Sent: Tuesday, September 25, 2007 6:26 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinkin g our own kool-aid


Based on CPE2.0 loosely defined naming convention I do agree it is important
to be clear on picking right strings. The main reason behind my observation
is that CPE identifier should help SCAP automation in a way that SCAP tools
can tell if a SCAP benchmark can apply to a platform. If there is no clear
definition on what OS properties to be used, this becomes mess.

For Windows, OS platform information can be collected by API through WMI
service (don't rely on registry because they may change), specifically it is
Win32_OperatingSystem under root\cimv2 name space.

I provide a sample script so you get idea how those information are
collected. I have to claim I don't intend asking you to run the script on
your pc so use it with your own risk:). The script displays CPE string based
on 2.0 convention. It should be very simple to map # to actual string, for
example, OSLanguage. Edition information is not available for OS before
Vista but they are embedded in product name, either leave it empty or parse
it.

I hope this helps. Cheers!

===script begin===
' Query for getting Windows CPE2.0 Identifier
 On Error Resume Next
' Connect to WMI and obtain instances of Win32_OperatingSystem
WScript.Echo
For Each objOS in GetObject( _
    "winmgmts:").InstancesOf ("Win32_OperatingSystem")

WScript.Echo "Based on CPE2.0 naming convention, CPE identifier for your OS
is:"
' vista WScript.Echo "cpe:/o:" & objOS.Manufacturer & ":" & objOS.Caption &
":" & objOS.Version & ":" & objOS.CSDVersion & ":" '&
objOS.OperatingSystemSKU & ":" & objOS.OSLanguage
WScript.Echo "cpe:/o:" & objOS.Manufacturer & ":" & objOS.Caption & ":" &
objOS.Version & ":" & objOS.CSDVersion & ":" & ":" & objOS.OSLanguage
Next

if Err <> 0 Then
    WScript.Echo Err.Description
    Err.Clear
End if
===script end===

Michael X. Tan
Senior Program Manager
Microsoft Solution for Security and Compliance

-----Original Message-----
From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Tuesday, September 25, 2007 2:03 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and drinkin g
our own kool-aid

Hoo boy.  Guess this is a real can of worms.

So I guess, in the spirit of drinking our own kool-aid, we still need to
pick names we can reasonably expect someone to arrive at based on some
common indicator and a prima-facie reading of the CPE spec.

Sounds like "Microsoft Windows XP" may be the reasonable common denominator,
pending differing input from the manufacturer...

So are you thinking the cpe should be "cpe:/o:ms:win:xp" for XP and similar
names for the the other Microsoft OSs?  Or, admitting the "windows"
designation seems to be Microsoft's notation that this software is an OS
versus an application and doesn't really identify discreet products, should
it be "cpe:/o:ms:windows_xp"?

How do we resolve this?  Vote?

Lt Col Joseph L. Wolfkiel

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

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: Gary Newman [mailto:[hidden email]]
Sent: Tuesday, September 25, 2007 4:25 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinking our own kool-aid


Hi Joe,

The technet article you've cited is very loosely saying that Windows XP
reports
"Microsoft Windows NT Workstation 5.1" to the SMS client.  I'm not aware of
any
registry value similar to a string like that.  The SMS client is most likely

creating that string by pulling together other data that's not all in the
registry (e.g. API calls).  I'd suggest that we not consider names created
by
the SMS client as a vendor Registered Name.

Windows XP doesn't refer to itself as Windows NT anywhere that I know of
(ignoring the registry keys below, as they also can appear on Windows 95
computers).  However, the Windows XP registry does have the string
"Microsoft
Windows XP" in the registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

That said, it's fair to note that Microsoft has the OS identify itself as
compatible with the Windows NT "family" with the GetVersion API call

        http://msdn2.microsoft.com/en-us/library/ms724439.aspx

that returns 0 in the high order bit for NT family and 1 for 9x family.
It's
not clear to me whether compatibility with the NT family implies a taxonomy
appropriate for CPE use.

        -Gary-

> [snip]
> Supporting info.
>
> http://www.microsoft.com/technet/sms/2003/library/deployingwinxpsp2_6.mspx
> The value for OperatingSystemNameandVersion is listed as Microsoft Windows
> NT Workstation 5.1. This is what Windows XP reports to SMS when queried
for
> the operating system. Windows XP without a service pack, Windows XP SP1,
and
> Windows XP SP2 all report the same value.

[Andrew Buttner]

>So the DoD has two other use cases:

I'm excited to talk more about these use cases.  As we define them a
bit more, we can add these to the use case section of the spec and then
see what type of modifications might be needed.



>1.  Use discovered CPE names to search the NVD for
>vulnerabilities that may occur on a given platform
>(as specified by CPE)

When you say "discovered", is the use case dependent on a tool
automatically (without the help of a look-up table) determining a CPE
name for a given system by using available fields of info from api
calls?  Or is the use of a look-up table or other method (human input,
OS returning a CPE, etc) acceptable?



>2.  Use the CPE Dictionary to populate drop-down lists so our network
>defenders can build CPE definitions to search our assets for specific
>configurations--via a web service--on CPE-compliant products

Can you expand on this some more?  Specifically, what information do
you see in these drop-down lists?  The different CPE Names found in the
dictionary or the unique individual values for each component of all
the CPE Names in the dictionary.

I assume the building of CPE Names by your network defenders would mean
that you would pull the vendor, product name, version info, etc. off
the system via api call and then use that to determine the CPE Name for
that system.  You would then use that name in the first use case as
mentioned above.



>These two use cases may give me a somewhat different
>perspective on what I want from CPE.

This really helps shed light on how you would like to use CPE.  I think
there are thing that can be done to support these needs.

Thanks
Drew

[Andrew Buttner]

Michael - Thank you very much for this clarification and pointing out
the use of WMI for our needs.  If we are looking to build the CPE Name
related to a Windows systems then I take the following points away from
your email:

1) For the vendor component, we can pull information from the
Manufacturer field.  QUESTION - manufacturer on my system is "Microsoft
Corporation", should we use cpe:/o:microsoft_corporation?  Or should we
put into the spec that the word "Corporation" should be drop for
brevity?  (we have something similar already for the word "Edition".

2) For the version component, we should use the actual version number
(in my case 5.1.2600) instead of the marketing name.  (in my case XP)

3) The product component is a bit tricky since there is no field in
Win32_OperatingSystem that is just product name.  Instead the Caption
field can be used, but it is a combination of vendor, product, and
edition information.  Looking at my system, I have "Microsoft Windows
XP Professional"  The question is whether the product name is "Windows
XP" or just "Windows".  My personal assumption is that the product name
is "Windows" and that version 5.1.2600 of Windows is marketed as
"Windows XP".

As a side note, we used the term "Windows" earlier in CPE but the
community raised the concern that we needed to differentiate between
the different windows products, namely the different kernels (9x, nt,
and ce).  Looking at other return values we thought the true product
name was "Windows NT" and the version was "XP"  (or 5.1.2600)



Michael - I am very interested in your response to these points.  Do
you agree/disagree?  Do they even make sense?

Thanks
Drew

>-----Original Message-----
>From: Michael Tan [mailto:[hidden email]]
>Sent: Tuesday, September 25, 2007 6:26 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names
>and drinkin g our own kool-aid
>
>Based on CPE2.0 loosely defined naming convention I do agree
>it is important to be clear on picking right strings. The main
>reason behind my observation is that CPE identifier should
>help SCAP automation in a way that SCAP tools can tell if a
>SCAP benchmark can apply to a platform. If there is no clear
>definition on what OS properties to be used, this becomes mess.
>
>For Windows, OS platform information can be collected by API
>through WMI service (don't rely on registry because they may
>change), specifically it is Win32_OperatingSystem under
>root\cimv2 name space.
>
>I provide a sample script so you get idea how those
>information are collected. I have to claim I don't intend
>asking you to run the script on your pc so use it with your
>own risk:). The script displays CPE string based on 2.0
>convention. It should be very simple to map # to actual
>string, for example, OSLanguage. Edition information is not
>available for OS before Vista but they are embedded in product
>name, either leave it empty or parse it.
>
>I hope this helps. Cheers!
>
>===script begin===
>' Query for getting Windows CPE2.0 Identifier
> On Error Resume Next
>' Connect to WMI and obtain instances of Win32_OperatingSystem
>WScript.Echo
>For Each objOS in GetObject( _
>    "winmgmts:").InstancesOf ("Win32_OperatingSystem")
>
>WScript.Echo "Based on CPE2.0 naming convention, CPE
>identifier for your OS is:"
>' vista WScript.Echo "cpe:/o:" & objOS.Manufacturer & ":" &
>objOS.Caption & ":" & objOS.Version & ":" & objOS.CSDVersion &
>":" '& objOS.OperatingSystemSKU & ":" & objOS.OSLanguage
>WScript.Echo "cpe:/o:" & objOS.Manufacturer & ":" &
>objOS.Caption & ":" & objOS.Version & ":" & objOS.CSDVersion &
>":" & ":" & objOS.OSLanguage
>Next
>
>if Err <> 0 Then
>    WScript.Echo Err.Description
>    Err.Clear
>End if
>===script end===
>
>Michael X. Tan
>Senior Program Manager
>Microsoft Solution for Security and Compliance
>
>-----Original Message-----
>From: Wolfkiel, Joseph [mailto:[hidden email]]
>Sent: Tuesday, September 25, 2007 2:03 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names
>and drinkin g our own kool-aid
>
>Hoo boy.  Guess this is a real can of worms.
>
>So I guess, in the spirit of drinking our own kool-aid, we
>still need to
>pick names we can reasonably expect someone to arrive at based on some
>common indicator and a prima-facie reading of the CPE spec.
>
>Sounds like "Microsoft Windows XP" may be the reasonable
>common denominator,
>pending differing input from the manufacturer...
>
>So are you thinking the cpe should be "cpe:/o:ms:win:xp" for
>XP and similar
>names for the the other Microsoft OSs?  Or, admitting the "windows"
>designation seems to be Microsoft's notation that this
>software is an OS
>versus an application and doesn't really identify discreet
>products, should
>it be "cpe:/o:ms:windows_xp"?
>
>How do we resolve this?  Vote?
>
>Lt Col Joseph L. Wolfkiel
>
>Director, Computer Network Defense Research & Technology (CND
>R&T) Program
>Management Office
>
>NSA/I71
>9800 Savage Rd Ste 6767
>Ft Meade, MD 20755-6767
>Commercial 410-854-5401 DSN 244-5401
>Fax [phone]
>
>
>-----Original Message-----
>From: Gary Newman [mailto:[hidden email]]
>Sent: Tuesday, September 25, 2007 4:25 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
>drinking our own kool-aid
>
>
>Hi Joe,
>
>The technet article you've cited is very loosely saying that Windows

XP

>reports
>"Microsoft Windows NT Workstation 5.1" to the SMS client.  I'm
>not aware of
>any
>registry value similar to a string like that.  The SMS client
>is most likely
>
>creating that string by pulling together other data that's not
>all in the
>registry (e.g. API calls).  I'd suggest that we not consider
>names created
>by
>the SMS client as a vendor Registered Name.
>
>Windows XP doesn't refer to itself as Windows NT anywhere that
>I know of
>(ignoring the registry keys below, as they also can appear on
>Windows 95
>computers).  However, the Windows XP registry does have the string
>"Microsoft
>Windows XP" in the registry value:
>
>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
>NT\CurrentVersion\ProductName
>
>That said, it's fair to note that Microsoft has the OS
>identify itself as
>compatible with the Windows NT "family" with the GetVersion API call
>
>        http://msdn2.microsoft.com/en-us/library/ms724439.aspx
>
>that returns 0 in the high order bit for NT family and 1 for 9x

family.

>It's
>not clear to me whether compatibility with the NT family
>implies a taxonomy
>appropriate for CPE use.
>
>        -Gary-
>
>> [snip]
>> Supporting info.
>>
>>
>http://www.microsoft.com/technet/sms/2003/library/deployingwinx
>psp2_6.mspx
>> The value for OperatingSystemNameandVersion is listed as
>Microsoft Windows
>> NT Workstation 5.1. This is what Windows XP reports to SMS
>when queried
>for
>> the operating system. Windows XP without a service pack,
>Windows XP SP1,
>and
>> Windows XP SP2 all report the same value.
>

[Lemire, David]

Oher possibilities for discovering CPE names that you might wish to check against the NVD:

*
        OS / client application / server application identification based on passive sensing techniques (e.g., banner grabbing).
*
        asset characteristics reported from an asset management system (which, admittedly, may be using API calls behind the scenes)

There are definitely means for "discovering" a CPE name other than building them from API calls about the platform that would appply to the use cases LTC W. described.  

Dave Lemire
A&N Associates, Inc.

 

________________________________

From: Buttner, Drew [mailto:[hidden email]]
Sent: Wed 9/26/2007 8:19 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and drinkin g our own kool-aid



>So the DoD has two other use cases:

I'm excited to talk more about these use cases.  As we define them a
bit more, we can add these to the use case section of the spec and then
see what type of modifications might be needed.



>1.  Use discovered CPE names to search the NVD for
>vulnerabilities that may occur on a given platform
>(as specified by CPE)

When you say "discovered", is the use case dependent on a tool
automatically (without the help of a look-up table) determining a CPE
name for a given system by using available fields of info from api
calls?  Or is the use of a look-up table or other method (human input,
OS returning a CPE, etc) acceptable?



>2.  Use the CPE Dictionary to populate drop-down lists so our network
>defenders can build CPE definitions to search our assets for specific
>configurations--via a web service--on CPE-compliant products

Can you expand on this some more?  Specifically, what information do
you see in these drop-down lists?  The different CPE Names found in the
dictionary or the unique individual values for each component of all
the CPE Names in the dictionary.

I assume the building of CPE Names by your network defenders would mean
that you would pull the vendor, product name, version info, etc. off
the system via api call and then use that to determine the CPE Name for
that system.  You would then use that name in the first use case as
mentioned above.



>These two use cases may give me a somewhat different
>perspective on what I want from CPE.

This really helps shed light on how you would like to use CPE.  I think
there are thing that can be done to support these needs.

Thanks
Drew

[Gary Newman-2]

Hi Drew,

1) This highlights a concern I've had with CPE naming, that the spec calls for
names that are quite hard to derive.  The current CPE spec says the vendor
component is the second level DNS name, so it should be microsoft.  That's fine
for the top 50 vendors, where someone (volunteers?) can build a list for us all
to use.  However this makes even the creation of the simple vendor component a
bottleneck that will slow CPE dictionary creation.

I favor, instead, CPE names composed of authoritative manufacturer names (e.g.
Microsoft Corporation as returned by WMI) cleaned up by a few simple rules.  
The rules should be to remove certain common incorporation markers and the like
(e.g. remove corporation, inc, etc).

3) This further highlights the difficulties that CPE will face attempting to
"reverse engineer" a taxonomy from only marketing product names.  Further, this
current example is an easy one, as Microsoft's products are relatively well
understood by comparison to many other products.  Even if Microsoft were to
specify a complete CPE taxonomy for all their products it's only a start at a
dictionary.  We need a method that works for all products in a general way.

The current CPE specification (draft 2.0) works well for a hand-built
dictionary (e.g. the current CPE names used in CVE) but isn't scalable to the
universe of widely distributed software.

Again, I favor instead the use of cleaned up authoritative manufacturer names.

        -Gary-

> Michael - Thank you very much for this clarification and pointing out
> the use of WMI for our needs.  If we are looking to build the CPE Name
> related to a Windows systems then I take the following points away from
> your email:
>
> 1) For the vendor component, we can pull information from the
> Manufacturer field.  QUESTION - manufacturer on my system is "Microsoft
> Corporation", should we use cpe:/o:microsoft_corporation?  Or should we
> put into the spec that the word "Corporation" should be drop for
> brevity?  (we have something similar already for the word "Edition".
>
> 2) For the version component, we should use the actual version number
> (in my case 5.1.2600) instead of the marketing name.  (in my case XP)
>
> 3) The product component is a bit tricky since there is no field in
> Win32_OperatingSystem that is just product name.  Instead the Caption
> field can be used, but it is a combination of vendor, product, and
> edition information.  Looking at my system, I have "Microsoft Windows
> XP Professional"  The question is whether the product name is "Windows
> XP" or just "Windows".  My personal assumption is that the product name
> is "Windows" and that version 5.1.2600 of Windows is marketed as
> "Windows XP".
>
> As a side note, we used the term "Windows" earlier in CPE but the
> community raised the concern that we needed to differentiate between
> the different windows products, namely the different kernels (9x, nt,
> and ce).  Looking at other return values we thought the true product
> name was "Windows NT" and the version was "XP"  (or 5.1.2600)
>
>
>
> Michael - I am very interested in your response to these points.  Do
> you agree/disagree?  Do they even make sense?
>
> Thanks
> Drew

[Wolfkiel, Joseph]

>So the DoD has two other use cases:

I'm excited to talk more about these use cases.  As we define them a
bit more, we can add these to the use case section of the spec and then
see what type of modifications might be needed.



>1.  Use discovered CPE names to search the NVD for vulnerabilities that may
occur on a given platform (as specified by CPE)

Q: When you say "discovered", is the use case dependent on a tool
automatically (without the help of a look-up table) determining a CPE name
for a given system by using available fields of info from api calls?  Or is
the use of a look-up table or other method (human input, OS returning a CPE,
etc) acceptable?

A: No.  I'm assuming that pretty much any tool we use will have to use a
lookup table to find CPE names.  What I really want to do is avoid the
situation where a tool returns some number of sub-parts that don't match the
number of sub-parts in the CPE.  Example -- our tool returns
vendor="microsoft", product="Windows XP", however the CPE list says the
actual CPE is "cpe:/o:ms:win-nt:xp and now we have a lookup problem since
"Windows XP" doesn't directly match either "win-nt" or "xp" and, even if we
successfully look it up, we have to convert a 2-part name into a 3-part
name.  Not impossible, but not something I would intentionally set myself up
for.  I should also note that we don't intend to always use the CPE uri
format to transmit our data.

>2.  Use the CPE Dictionary to populate drop-down lists so our network
>defenders can build CPE definitions to search our assets for specific
>configurations--via a web service--on CPE-compliant products

Q: Can you expand on this some more?  Specifically, what information do
you see in these drop-down lists?  The different CPE Names found in the
dictionary or the unique individual values for each component of all
the CPE Names in the dictionary.

I assume the building of CPE Names by your network defenders would mean
that you would pull the vendor, product name, version info, etc. off
the system via api call and then use that to determine the CPE Name for
that system.  You would then use that name in the first use case as
mentioned above.

A: Actually, we had envisioned downloading the CPE dictionary from the NVD
and then explore the vendor-product-version-update-edition relationships to
limit choices on the drop down menu so that only microsoft products could be
chosen when microsoft was selected, only windows versions could be selected
when windows was selected, etc.  Once the analysts had assembled the CPE
names they wished to search for, they would send out the CPEs to the
different asset databases, which would return lists of assets that matched
the specified CPEs.  We had also envisioned combining CPE names and patch
information to be able to specify that we are specifically looking for
certain configurations that lack certain patches.  We actually developed a
schema we call "CPE Logical Specifier" that is very similar to the CPE
Language that allows us to logically combine CPE names and patch information
(using nested statements and the operators [and,or,not] to specify the exact
logical set of information we're looking for).  I've attached it.

>These two use cases may give me a somewhat different
>perspective on what I want from CPE.

Q: This really helps shed light on how you would like to use CPE.  I think
there are thing that can be done to support these needs.

A: I hope so.  Dave Lemire also highlighted a couple of other use cases we
have.

Lt Col Joseph L. Wolfkiel

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

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Wednesday, September 26, 2007 8:19 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinkin g our own kool-aid


>So the DoD has two other use cases:

I'm excited to talk more about these use cases.  As we define them a
bit more, we can add these to the use case section of the spec and then
see what type of modifications might be needed.



>1.  Use discovered CPE names to search the NVD for
>vulnerabilities that may occur on a given platform
>(as specified by CPE)

When you say "discovered", is the use case dependent on a tool
automatically (without the help of a look-up table) determining a CPE
name for a given system by using available fields of info from api
calls?  Or is the use of a look-up table or other method (human input,
OS returning a CPE, etc) acceptable?



>2.  Use the CPE Dictionary to populate drop-down lists so our network
>defenders can build CPE definitions to search our assets for specific
>configurations--via a web service--on CPE-compliant products

Can you expand on this some more?  Specifically, what information do
you see in these drop-down lists?  The different CPE Names found in the
dictionary or the unique individual values for each component of all
the CPE Names in the dictionary.

I assume the building of CPE Names by your network defenders would mean
that you would pull the vendor, product name, version info, etc. off
the system via api call and then use that to determine the CPE Name for
that system.  You would then use that name in the first use case as
mentioned above.



>These two use cases may give me a somewhat different
>perspective on what I want from CPE.

This really helps shed light on how you would like to use CPE.  I think
there are thing that can be done to support these needs.

Thanks
Drew

[Andrew Buttner]

>>1.  Use discovered CPE names to search the NVD for
>>vulnerabilities that may occur on a given platform
>>(as specified by CPE)
>
>Q: When you say "discovered", is the use case dependent
>on a tool automatically (without the help of a look-up
>table) determining a CPE name for a given system by
>using available fields of info from api calls?  Or is
>the use of a look-up table or other method (human input,
>OS returning a CPE, etc) acceptable?
>
>A: No.  I'm assuming that pretty much any tool we use
>will have to use a lookup table to find CPE names.  What
>I really want to do is avoid the situation where a tool
>returns some number of sub-parts that don't match the
>number of sub-parts in the CPE.  Example -- our tool
>returns vendor="microsoft", product="Windows XP", however
>the CPE list says the actual CPE is "cpe:/o:ms:win-nt:xp
>and now we have a lookup problem since "Windows XP"
>doesn't directly match either "win-nt" or "xp" and, even
>if we successfully look it up, we have to convert a 2-part
>name into a 3-part name.  Not impossible, but not
>something I would intentionally set myself up for.  I
>should also note that we don't intend to always use the
>CPE uri format to transmit our data.

I think I may understand your frustration.  Trying to match a two field
name to a three field name would put a burden on the tool doing the
matching.  Could this be solved by having your tool return 'version'
along with 'vendor' and product'?  It seems like the level of platform
detail that you are interested in is defined by those three components
of a CPE Name.  This will also mean that the fields you get back from
your tool will correspond to those in the CPE Dictionary.

Since you will be using a look-up table, try creating the following
transform:  When your tool submits the value of "Windows XP" transform
it to "windows-nt".  This is the same type of transformation you would
have to do to go from "Windows XP" to windows_xp".  You might have to
do a similar transformation on the version field.  Of course, there is
an open discussion about how the version field should look (should we
use XP or 5.1.2600?) and this could affect your need for a
transformation here.

This type of transformation is what I meant by the term look-up table.
In other words, a table that has a list of paired values.  One value is
what your tool understands, the other value is what the CPE Dictionary
uses.  I think this type of table is unavoidable since different tools
will be returning different values for the same component.  For
example, your tool might return "Windows XP" for a product name while a
different tool might return "Microsoft Windows XP Professional" and a
third might return "Microsoft Windows NT Workstation 5.1".

My guess is that that most tools are going to have to utilize a look-up
table to translate between their internal naming scheme and CPE.  But
thinking about it, most tools already need such a look-up table, the
difference being that without CPE, they need a different look-up table
for each external tool that they want to communicate with.  With CPE
they only need to work on a single look-up table.

Thanks
Drew

[Sheldon Malm]

Perhaps I'm over-simplifying the issue here, but I do not see an issue with using the 'windows' title for the flagship OS kernel, and treating 'windows_9x' and 'windows_CE' as separate product names.  If Microsoft had decided to market Access as 'SQL Server Lite', would we want to treat them as the same product?

I'm not out to bash Marketing departments here; just want to ensure that we're not tying our strategy to a company's marketing department.  When we write detection, we identify the kernel's version and then present the results to the end user with a name that is meaningful to them.  It is then pretty straight forward to "change all" if the market requires us to change this common product display name without updating the checks themselves.


--------------------------
Sheldon Malm
Director
Security Research and Development
nCircle VERT

Sent from my BlackBerry Wireless Handheld


----- Original Message -----
From: Buttner, Drew <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Tue Oct 02 05:42:36 2007
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and drinking our own kool-aid

I propose that we have a telephone conference to discuss the issue
below further.  I will send out details for this call shortly.  Please
read the rest of this post.  I encourage all community members to weigh
in on this issue, even if you disagree with the current spec.  The only
way we are going to move forward is if everyone voices their opinions.
Please do keep the response focused on this topic of naming Microsoft
operating systems.  Of course vendor (Microsoft) input would help put
this issue to bed as they are the only ones that know the real answer
to this question :)



>We've been having discussions on this thread for a week now,
>and I have yet to see a case that supports naming Microsoft
>products 'win-nt:xp', 'win-nt:2000', or 'win-nt:nt'.  Based
>on the cases I've seen, I am requesting the MS OS naming
>convention be 'windows_xp', 'windows_nt', 'windows_2000',
>etc.  This seems to most closely follow the CPE spec and can
>be arrived at both by reading the advertising and, in many
>cases, by checking one or more registry settings.


The question of windows naming has been going on since March when it
was first brought up on the CPE mailing list.  It is a tough debate
with arguments for and against any of the different methods chosen.
The community itself is conflicted on what is the best approach.  The
original thread that also provides some great background information
can be found at:

http://www.nabble.com/Windows-naming-in-CPE-tf4230138.html

The problem we face is the relation between the roll-up capability
built into the CPE Naming structure, and the way Microsoft markets
their Windows operating System.  CPE has tried to create a naming
structure that allows matching to be performed on names related to
different levels of platform abstraction.  This is use case is defined
in section 2.2 of the current spec.

The goal of this use case is that a name can be specified for a
particular version of a product and this name can be matched to the a
more general name related to all versions of the product.  For example,
a configuration guide can be written for "Acme BestProgram" and this
guide can be known to apply to a platform that is identified to have
"Acme BestProgram 2.3".  This is why we build our names using the
vendor:product:version:.... convention.

Unfortunately with Microsoft Windows, there becomes a grey area.  What
is the 'product'?  Is it "Windows"?  Or is it "Windows XP".  Looking at
the internals of the operating system, and reading books and other
information available about the os, it is pretty convincing that the
true product is a kernel that has been updated over the years, from
version 4.0 to version 5.0 to 5.1 to 5.2 and now version 6.0.

The grey area is that Microsoft does not give a name to this product
(at least not to the general public that I am aware of).  Instead,
Microsoft has named each version (NT, 2000, XP, Vista, etc).  In the
1.1 spec, we used the term 'windows' as the product but it was pointed
out that matching didn't work correctly since the older 9x kernel and
the CE kernels were included in this term and they were not the same
product.  If we are to follow the defined vendor:product:version
convention, then we need to create a name for the kernel of the windows
operating system.  Again, see the original thread from back in March.
If we use the marketing name of "Window XP" as the product name, we
will lose the ability to satisfy the matching use case.

Thanks
Drew

[Wolfkiel, Joseph]

So I disagree with this in concept.  If you translate "Windows XP" to
"windows-nt", what do you translate "Windows NT" to?

Fundamentally, based on what was briefed at the SCAP conference and what is
in the CPE spec, if the application tells me it's "Windows XP" and I read
the CPE spec, which tells me:

The third component of a CPE Name is the product name of the platform part.
Multi-word
product names and designations should be spelled out in full, replacing
spaces with underscores.  The example below shows how this would look for
the Zone Labs ZoneAlarm Internet Security Suite version 7.0.
cpe:/a:zonelabs:zonealarm_internet_security_suite:7.0

The CPE spec doesn't say anything about making the product name up by
applying some CPE-discussion group conversation as a reference.  It talks
about taking names that can be readily found and converting them into common
expressions using the conventions in the spec.  Based on the spec, I can
make a case for calling XP either "windows workstation version 5.1" or
"windows xp," or some variation.

Of course there is always some exotic business logic I could ask my DoD
users to implement that can map "windows-nt:xp" to "windows xp", but I think
it defeats the intent of the CPE spec that they should have to.  I think you
also have to look at other "windows" products like windows ce.  Can we work
the same voodoo there?  Do we want to?

I think the association of operating systems with code bases may be
valuable, but it shouldn't be forced on the platform naming scheme.  Why not
just maintain a code-base to product association on the NVD and let names
just be names?


Lt Col Joseph L. Wolfkiel

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

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, October 02, 2007 8:43 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinking our own kool-aid

>>1.  Use discovered CPE names to search the NVD for
>>vulnerabilities that may occur on a given platform
>>(as specified by CPE)
>
>Q: When you say "discovered", is the use case dependent
>on a tool automatically (without the help of a look-up
>table) determining a CPE name for a given system by
>using available fields of info from api calls?  Or is
>the use of a look-up table or other method (human input,
>OS returning a CPE, etc) acceptable?
>
>A: No.  I'm assuming that pretty much any tool we use
>will have to use a lookup table to find CPE names.  What
>I really want to do is avoid the situation where a tool
>returns some number of sub-parts that don't match the
>number of sub-parts in the CPE.  Example -- our tool
>returns vendor="microsoft", product="Windows XP", however
>the CPE list says the actual CPE is "cpe:/o:ms:win-nt:xp
>and now we have a lookup problem since "Windows XP"
>doesn't directly match either "win-nt" or "xp" and, even
>if we successfully look it up, we have to convert a 2-part
>name into a 3-part name.  Not impossible, but not
>something I would intentionally set myself up for.  I
>should also note that we don't intend to always use the
>CPE uri format to transmit our data.

I think I may understand your frustration.  Trying to match a two field
name to a three field name would put a burden on the tool doing the
matching.  Could this be solved by having your tool return 'version'
along with 'vendor' and product'?  It seems like the level of platform
detail that you are interested in is defined by those three components
of a CPE Name.  This will also mean that the fields you get back from
your tool will correspond to those in the CPE Dictionary.

Since you will be using a look-up table, try creating the following
transform:  When your tool submits the value of "Windows XP" transform
it to "windows-nt".  This is the same type of transformation you would
have to do to go from "Windows XP" to windows_xp".  You might have to
do a similar transformation on the version field.  Of course, there is
an open discussion about how the version field should look (should we
use XP or 5.1.2600?) and this could affect your need for a
transformation here.

This type of transformation is what I meant by the term look-up table.
In other words, a table that has a list of paired values.  One value is
what your tool understands, the other value is what the CPE Dictionary
uses.  I think this type of table is unavoidable since different tools
will be returning different values for the same component.  For
example, your tool might return "Windows XP" for a product name while a
different tool might return "Microsoft Windows XP Professional" and a
third might return "Microsoft Windows NT Workstation 5.1".

My guess is that that most tools are going to have to utilize a look-up
table to translate between their internal naming scheme and CPE.  But
thinking about it, most tools already need such a look-up table, the
difference being that without CPE, they need a different look-up table
for each external tool that they want to communicate with.  With CPE
they only need to work on a single look-up table.

Thanks
Drew

[Kent_Landfield]

Ok. I'll come clean... I don't like the usage of "kernel" as a product
name but after discussions here (that too have been intense at times...)
there may be some value in it.  It really depends on the intended usage
for CPE names.  

The original use case for what was to become CPE was to remove the
ambiguity of OS names that occurred when we tried to initially pass OVAL
results between ThreatGuard and (then) Citadel's products during OVAL
certification testing. Since then the need for a way to pass platform
and application related information has shown itself to be a critical
missing piece of the SCAP puzzle.

The real question is what are we trying to do with the CPE entry?  Is it
meant for human consumption more than machine consumption?  If so
Marketeers' product names may be more important.  If the real focus of
CPE is on intercommunications between SCAP related components then maybe
we need to take a look at it from that angle.  I am working this through
in my own mind so please bear with me.  

We have already stated a goal of the CPE effort is to produce a
dictionary we can call "CPE Official Names".  This will be developed
with vendor support where possible but we may not have the luxury in
some cases.  What ever we decide on and is then "officially" (whatever
that means) approved will be what is integrated into products and
databases, etc.  So for the most part we are talking about a one-time
pain... Maybe I am missing something here but McAfee plans on using the
"official CPE names" whenever possible and not creating these on the
fly.

The question is... is there something wrong with the spec that will
cause us to rev it one more time over the Microsoft naming issue.  As
much as it is non-intuitive and pains me to say so, I do not think it
needs to be.  One of the guys here, Jeff Turner pointed out by using NT
related version information it allows for "walking up" a Microsoft CPE
name.

If the spec wants:

cpe://vendor:family:product:version

Then something like the following meets spec and could provide greater
flexibility,

cpe://microsoft:windows:nt:4
cpe://microsoft:windows:nt:5.0
cpe://microsoft:windows:nt:5.1

This is where I had issues because there is seemingly no definitive
source for the NT Product line version information. (If someone can find
it, please let the list know where... I have reached out to Microsoft to
help.) Searching the Microsoft site for NT related items is not very
helpful due to the massive amount of data that is presented.  But we did
find something on (of all places) Wikipedia.  I know, I know, but take a
look...

http://en.wikipedia.org/wiki/Windows_NT#Releases

So what does this buy us from a data perspective?

1) We can now determine things like the system is "XP or later",
2) We can quickly group NT versus non-NT related Windows software,
3) We can now provide the content needed for any lookup table as has
been mentioned here.  

Is it intuitive? NO. Should CPE be focused for machine to machine
communications? IMHO, yes.

Is there a need for a field for "friendly name" such as "Windows XP (64
Bit)" for NT 5.2? Maybe, but that's another discussion...

Do I like it, not really, but it is a one-time pain and is a bit more
useful out of the box than simple marketing names that have no real
correlation between each other.

FWIW...

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

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, October 02, 2007 7:43 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinking our own kool-aid

>>1.  Use discovered CPE names to search the NVD for
>>vulnerabilities that may occur on a given platform
>>(as specified by CPE)
>
>Q: When you say "discovered", is the use case dependent
>on a tool automatically (without the help of a look-up
>table) determining a CPE name for a given system by
>using available fields of info from api calls?  Or is
>the use of a look-up table or other method (human input,
>OS returning a CPE, etc) acceptable?
>
>A: No.  I'm assuming that pretty much any tool we use
>will have to use a lookup table to find CPE names.  What
>I really want to do is avoid the situation where a tool
>returns some number of sub-parts that don't match the
>number of sub-parts in the CPE.  Example -- our tool
>returns vendor="microsoft", product="Windows XP", however
>the CPE list says the actual CPE is "cpe:/o:ms:win-nt:xp
>and now we have a lookup problem since "Windows XP"
>doesn't directly match either "win-nt" or "xp" and, even
>if we successfully look it up, we have to convert a 2-part
>name into a 3-part name.  Not impossible, but not
>something I would intentionally set myself up for.  I
>should also note that we don't intend to always use the
>CPE uri format to transmit our data.

I think I may understand your frustration.  Trying to match a two field
name to a three field name would put a burden on the tool doing the
matching.  Could this be solved by having your tool return 'version'
along with 'vendor' and product'?  It seems like the level of platform
detail that you are interested in is defined by those three components
of a CPE Name.  This will also mean that the fields you get back from
your tool will correspond to those in the CPE Dictionary.

Since you will be using a look-up table, try creating the following
transform:  When your tool submits the value of "Windows XP" transform
it to "windows-nt".  This is the same type of transformation you would
have to do to go from "Windows XP" to windows_xp".  You might have to
do a similar transformation on the version field.  Of course, there is
an open discussion about how the version field should look (should we
use XP or 5.1.2600?) and this could affect your need for a
transformation here.

This type of transformation is what I meant by the term look-up table.
In other words, a table that has a list of paired values.  One value is
what your tool understands, the other value is what the CPE Dictionary
uses.  I think this type of table is unavoidable since different tools
will be returning different values for the same component.  For
example, your tool might return "Windows XP" for a product name while a
different tool might return "Microsoft Windows XP Professional" and a
third might return "Microsoft Windows NT Workstation 5.1".

My guess is that that most tools are going to have to utilize a look-up
table to translate between their internal naming scheme and CPE.  But
thinking about it, most tools already need such a look-up table, the
difference being that without CPE, they need a different look-up table
for each external tool that they want to communicate with.  With CPE
they only need to work on a single look-up table.

Thanks
Drew

[Gary Newman-2]

Hi Kent,

The version number method doesn't work here because Microsoft used version
number 5.2 for both Windows XP x64 and Windows Server 2003.  Also, if that were
done the edition portion for version 5.2 would be a strange mix of server and
desktop.  This isn't allowed due to the prefix property requirement.

        -Gary-

> [snip]
> Then something like the following meets spec and could provide greater
> flexibility,
>
> cpe://microsoft:windows:nt:4
> cpe://microsoft:windows:nt:5.0
> cpe://microsoft:windows:nt:5.1
>
> This is where I had issues because there is seemingly no definitive
> source for the NT Product line version information. (If someone can find
> it, please let the list know where... I have reached out to Microsoft to
> help.) Searching the Microsoft site for NT related items is not very
> helpful due to the massive amount of data that is presented.  But we did
> find something on (of all places) Wikipedia.  I know, I know, but take a
> look...
>
> http://en.wikipedia.org/wiki/Windows_NT#Releases
>
> So what does this buy us from a data perspective?
>
> 1) We can now determine things like the system is "XP or later",
> 2) We can quickly group NT versus non-NT related Windows software,
> 3) We can now provide the content needed for any lookup table as has
> been mentioned here.  
>
> Is it intuitive? NO. Should CPE be focused for machine to machine
> communications? IMHO, yes.
>
> Is there a need for a field for "friendly name" such as "Windows XP (64
> Bit)" for NT 5.2? Maybe, but that's another discussion...
>
> Do I like it, not really, but it is a one-time pain and is a bit more
> useful out of the box than simple marketing names that have no real
> correlation between each other.
>
> FWIW...
>
> --
> Kent Landfield
> Director, Security Research
> McAfee, Inc.
> +1 972.963.7096 Direct
> +1 817.637.8026 Mobile
> [hidden email]
> www.mcafee.com

[Kent_Landfield]

Not sure I trust Wikipedia but it illustrated the point. That's why I
asked Microsoft to see if this is a valid list or if a valid list even
exists on their public site.  But your point is valid if this is as
well.

The point of the message was that we need to just pick one and move on.
This is a one time pain and due to the criticality of getting a stable
set of CPE names out there we cannot afford to just keep discussing this
month after month. We should try to look at it from what we can get out
of the box with the naming we agree on. Remember someone has to
implement this. :-)

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

-----Original Message-----
From: Gary Newman [mailto:[hidden email]]
Sent: Tuesday, October 02, 2007 4:50 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinking our own kool-aid

Hi Kent,

The version number method doesn't work here because Microsoft used
version
number 5.2 for both Windows XP x64 and Windows Server 2003.  Also, if
that were
done the edition portion for version 5.2 would be a strange mix of
server and
desktop.  This isn't allowed due to the prefix property requirement.

        -Gary-

> [snip]
> Then something like the following meets spec and could provide greater
> flexibility,
>
> cpe://microsoft:windows:nt:4
> cpe://microsoft:windows:nt:5.0
> cpe://microsoft:windows:nt:5.1
>
> This is where I had issues because there is seemingly no definitive
> source for the NT Product line version information. (If someone can

find
> it, please let the list know where... I have reached out to Microsoft
to
> help.) Searching the Microsoft site for NT related items is not very
> helpful due to the massive amount of data that is presented.  But we
did
> find something on (of all places) Wikipedia.  I know, I know, but take
a

> look...
>
> http://en.wikipedia.org/wiki/Windows_NT#Releases
>
> So what does this buy us from a data perspective?
>
> 1) We can now determine things like the system is "XP or later",
> 2) We can quickly group NT versus non-NT related Windows software,
> 3) We can now provide the content needed for any lookup table as has
> been mentioned here.  
>
> Is it intuitive? NO. Should CPE be focused for machine to machine
> communications? IMHO, yes.
>
> Is there a need for a field for "friendly name" such as "Windows XP

(64

> Bit)" for NT 5.2? Maybe, but that's another discussion...
>
> Do I like it, not really, but it is a one-time pain and is a bit more
> useful out of the box than simple marketing names that have no real
> correlation between each other.
>
> FWIW...
>
> --
> Kent Landfield
> Director, Security Research
> McAfee, Inc.
> +1 972.963.7096 Direct
> +1 817.637.8026 Mobile
> [hidden email]
> www.mcafee.com

[Ken Lassesen-3]

I agree with Joseph approach.
 
What I see is some noble efforts with goals that are starting to look like "can't get to all of them from here". The goal of inferring    a:b:c is a subset of a:b is suspect from a technical perspective; it makes perfect sense from a point of view of common sense. We may need to discard this goal and via meta data explicitly set the hierarchy(s). Similarly, if we include in metadata the 'internal' names, version information etc then we may have operational effectiveness (for example, <environmental name="OS">WINDOWS_NT</environmental> is returned from WindowsXP).
 
The goal of repeatability (i.e. McAfee, Lumension and MMGSecurity would all create the same CPE by using the rules) is increasingly suspect (IMHO).
 
To me, the use of a central co-operative repository that issues arbitrary ID's based on operational data entered seems to be one possible route out of this. All of the "a:b:c" information can be put into the metadata (and alternative x:y:z) so we are no worst off and likely have a more robust solution.
 
The bottom line is that CPE is shifted towards a Xml-based CPL.
 
 
Many thanks!
 
Ken Lassesen
Home Office: 360-297-4717   Cell: 360-509-2402   Fax: [phone]
IM: [hidden email] <mailto:[hidden email]>  or [hidden email] <mailto:[hidden email]>  

________________________________

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Tue 02-Oct-07 6:54 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and drinkin g our own kool-aid



So I disagree with this in concept.  If you translate "Windows XP" to
"windows-nt", what do you translate "Windows NT" to?

Fundamentally, based on what was briefed at the SCAP conference and what is
in the CPE spec, if the application tells me it's "Windows XP" and I read
the CPE spec, which tells me:

The third component of a CPE Name is the product name of the platform part.
Multi-word
product names and designations should be spelled out in full, replacing
spaces with underscores.  The example below shows how this would look for
the Zone Labs ZoneAlarm Internet Security Suite version 7.0.
cpe:/a:zonelabs:zonealarm_internet_security_suite:7.0

The CPE spec doesn't say anything about making the product name up by
applying some CPE-discussion group conversation as a reference.  It talks
about taking names that can be readily found and converting them into common
expressions using the conventions in the spec.  Based on the spec, I can
make a case for calling XP either "windows workstation version 5.1" or
"windows xp," or some variation.

Of course there is always some exotic business logic I could ask my DoD
users to implement that can map "windows-nt:xp" to "windows xp", but I think
it defeats the intent of the CPE spec that they should have to.  I think you
also have to look at other "windows" products like windows ce.  Can we work
the same voodoo there?  Do we want to?

I think the association of operating systems with code bases may be
valuable, but it shouldn't be forced on the platform naming scheme.  Why not
just maintain a code-base to product association on the NVD and let names
just be names?


Lt Col Joseph L. Wolfkiel

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

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, October 02, 2007 8:43 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Thoughts on Microsoft names and
drinking our own kool-aid

>>1.  Use discovered CPE names to search the NVD for
>>vulnerabilities that may occur on a given platform
>>(as specified by CPE)
>
>Q: When you say "discovered", is the use case dependent
>on a tool automatically (without the help of a look-up
>table) determining a CPE name for a given system by
>using available fields of info from api calls?  Or is
>the use of a look-up table or other method (human input,
>OS returning a CPE, etc) acceptable?
>
>A: No.  I'm assuming that pretty much any tool we use
>will have to use a lookup table to find CPE names.  What
>I really want to do is avoid the situation where a tool
>returns some number of sub-parts that don't match the
>number of sub-parts in the CPE.  Example -- our tool
>returns vendor="microsoft", product="Windows XP", however
>the CPE list says the actual CPE is "cpe:/o:ms:win-nt:xp
>and now we have a lookup problem since "Windows XP"
>doesn't directly match either "win-nt" or "xp" and, even
>if we successfully look it up, we have to convert a 2-part
>name into a 3-part name.  Not impossible, but not
>something I would intentionally set myself up for.  I
>should also note that we don't intend to always use the
>CPE uri format to transmit our data.

I think I may understand your frustration.  Trying to match a two field
name to a three field name would put a burden on the tool doing the
matching.  Could this be solved by having your tool return 'version'
along with 'vendor' and product'?  It seems like the level of platform
detail that you are interested in is defined by those three components
of a CPE Name.  This will also mean that the fields you get back from
your tool will correspond to those in the CPE Dictionary.

Since you will be using a look-up table, try creating the following
transform:  When your tool submits the value of "Windows XP" transform
it to "windows-nt".  This is the same type of transformation you would
have to do to go from "Windows XP" to windows_xp".  You might have to
do a similar transformation on the version field.  Of course, there is
an open discussion about how the version field should look (should we
use XP or 5.1.2600?) and this could affect your need for a
transformation here.

This type of transformation is what I meant by the term look-up table.
In other words, a table that has a list of paired values.  One value is
what your tool understands, the other value is what the CPE Dictionary
uses.  I think this type of table is unavoidable since different tools
will be returning different values for the same component.  For
example, your tool might return "Windows XP" for a product name while a
different tool might return "Microsoft Windows XP Professional" and a
third might return "Microsoft Windows NT Workstation 5.1".

My guess is that that most tools are going to have to utilize a look-up
table to translate between their internal naming scheme and CPE.  But
thinking about it, most tools already need such a look-up table, the
difference being that without CPE, they need a different look-up table
for each external tool that they want to communicate with.  With CPE
they only need to work on a single look-up table.

Thanks
Drew