Microsoft OS Naming Issue

[Andrew Buttner]

>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 wanted to clarify one point.  Unfortunately CPE was not designed to support this type of name generation.  The notion of an application computing a CPE Name based on return values from system API calls was not the goal.

Our assumption was that applications currently follow one of two paths.  They either pass along return values as their output, or they map return values to an internal product list and output a name from that product list.  (Is this assumption correct?)  CPE is trying to standardize that product list.

Something that I take from this thread though is that maybe there is a possibility to create this standard product list by using terms returned by the API calls.  My concern however would be that these terms are not consistent over time and often change as the marketing directions change.  This change would break the matching algorithm.

I will say that it is not the intention to NOT use terms that an api might return, and my guess is that in many cases these actually will align.  For example, the shift to using a version number should end up aligning us with info that can be collected off the system.  My guess is that edition and update terms are similar in this sense.

In the future, I would love to see each product have an API that returns the CPE Name of that product, thus avoiding this whole challenge.

Thanks
Drew

[Robert Neuman]

Kurt/Blake:

I'd recommend using the Major:Minor:Build:Revision:Other followed by a brief human readable name.


If you want to get detailed information from the OS fill an OSVERSIONINFOEX structure (link) with a call to GetVersionEx (sample).


The table in the remarks section of (link) summarizes the values returned by supported versions of Windows. Use the information in the Other column to distinguish between operating systems with identical version numbers.

This means calls using OSVERSIONINFOEX, GetSystemMetrics(), and SYSTEM_INFO.wProcessorArchitecture.











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:[e-mail]]

[Ernest Park-2]

sounds like we have gone from CPE to a theoretical APi that will query a database of metadata that is currently not populated. 

While it is a nice idea, this goes quite a bit off scope from what CPE is supposed to be.

Any chance we can just work on adding more to existing CPE, and then having a web service to just query the full CPE names?

Ernie

On Fri, May 29, 2009 at 6:04 PM, Robert Neuman <[hidden email]> wrote:

Kurt/Blake: I'd recommend using the Major:Minor:Build:Revision:Other followed by a brief human readable name. If you want to get detailed information from the OS fill an OSVERSIONINFOEX structure (link) with a call to GetVersionEx (sample). The table in the remarks section of (link) summarizes the values returned by supported versions of Windows. Use the information in the Other column to distinguish between operating systems with identical version numbers. This means calls using OSVERSIONINFOEX, GetSystemMetrics(), and SYSTEM_INFO.wProcessorArchitecture. 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]]

---

View this message in context: Re: Microsoft OS Naming Issue

Sent from the CPE - Common Platform Enumeration mailing list archive at Nabble.com.

[Jeffery Turner]

Some javascript/style in this post has been disabled (why?)

 

I agree API design and construction is outside the scope of CPE.  I do think CPE should use more deterministic data in construction of CPE IDs (like using version numbers) so we do not have to have a map for our map (matching Windows titles for all Windows SKUs to CPE IDs is fraught with peril).  By avoiding version numbers in the CPE components to prevent associating “Windows XP x64” with the “Windows Server 2003” code-base (which probably should match at the version level), the system was designed such that “Microsoft Windows” will not match “Microsoft Windows XP”.

 

Would we even be having the heartburn over using / including version numbers if “Windows XP x64” was named “Windows 2003 Workstation x64”?  What if Microsoft had named it something else completely- the “Super-Fantastic Awesome Workstation Operating System by Microsoft” (the future name of Windows 8, maybe)?

 

Version numbers are deterministic; they can be easily determined without a map and can automatically be used to match new versions as they are released.  This limits the need to have a complete list of SKU titles for an Operating System revision and eliminates the perils in trying to put together a regular expression that doesn’t miss anything and doesn’t match too much.

 

I think this list should not focus on how to build an API.  Leave that to products that use CPE.  But we should try to make sure the ID creation / evaluation is as black and white as possible, not ambiguous and subject to interpretation.  There should be no question as to what belongs to a given CPE.  Or make the ID strictly an ID and leave classification (which is really what matching is about) for the CPE Language, at which point GUIDs work just fine for me. J

 

So my long diatribe about deterministic solutions was to support the original “Option 2” as more “API-friendly” and more deterministic data that does not require finding lists of SKUs from vendors to figure out the OS “version” component.

 

I do like the idea of coming up with APIs that map to the correlating CPE entry, but I think that is more a discussion of the implementation of CPE than CPE itself (and the topic of a different discussion list)

 

 

---

From: Ernest Park [mailto:[hidden email]]
Sent: Friday, May 29, 2009 11:58 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

 

sounds like we have gone from CPE to a theoretical APi that will query a database of metadata that is currently not populated. 

 

 

While it is a nice idea, this goes quite a bit off scope from what CPE is supposed to be.

 

 

Any chance we can just work on adding more to existing CPE, and then having a web service to just query the full CPE names?

 

 

 

Ernie

 

 

On Fri, May 29, 2009 at 6:04 PM, Robert Neuman <[hidden email]> wrote:

Kurt/Blake: I'd recommend using the Major:Minor:Build:Revision:Other followed by a brief human readable name. If you want to get detailed information from the OS fill an OSVERSIONINFOEX structure (link) with a call to GetVersionEx (sample). The table in the remarks section of (link) summarizes the values returned by supported versions of Windows. Use the information in the Other column to distinguish between operating systems with identical version numbers. This means calls using OSVERSIONINFOEX, GetSystemMetrics(), and SYSTEM_INFO.wProcessorArchitecture. 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]]

---

View this message in context: Re: Microsoft OS Naming Issue

Sent from the CPE - Common Platform Enumeration mailing list archive at Nabble.com.

 

[Robert Neuman]

So using the Major:Minor:Build:Revision:Other followed by a brief human readable name. It gives fields to record the data and is applicable across different manufacturers.  For example in the RHEL the version numbers of some applications do not change version numbers when patched, the package info changes for the application.  Therefore the "Other" field might be used to hold the package info.  

Jeffery Turner wrote:

I agree API design and construction is outside the scope of CPE.  I do think CPE should use more deterministic data in construction of CPE IDs (like using version numbers) so we do not have to have a map for our map (matching Windows titles for all Windows SKUs to CPE IDs is fraught with peril).  By avoiding version numbers in the CPE components to prevent associating "Windows XP x64" with the "Windows Server 2003" code-base (which probably should match at the version level), the system was designed such that "Microsoft Windows" will not match "Microsoft Windows XP".

Would we even be having the heartburn over using / including version numbers if "Windows XP x64" was named "Windows 2003 Workstation x64"?  What if Microsoft had named it something else completely- the "Super-Fantastic Awesome Workstation Operating System by Microsoft" (the future name of Windows 8, maybe)?

Version numbers are deterministic; they can be easily determined without a map and can automatically be used to match new versions as they are released.  This limits the need to have a complete list of SKU titles for an Operating System revision and eliminates the perils in trying to put together a regular expression that doesn't miss anything and doesn't match too much.

I think this list should not focus on how to build an API.  Leave that to products that use CPE.  But we should try to make sure the ID creation / evaluation is as black and white as possible, not ambiguous and subject to interpretation.  There should be no question as to what belongs to a given CPE.  Or make the ID strictly an ID and leave classification (which is really what matching is about) for the CPE Language, at which point GUIDs work just fine for me. :)

So my long diatribe about deterministic solutions was to support the original "Option 2" as more "API-friendly" and more deterministic data that does not require finding lists of SKUs from vendors to figure out the OS "version" component.

I do like the idea of coming up with APIs that map to the correlating CPE entry, but I think that is more a discussion of the implementation of CPE than CPE itself (and the topic of a different discussion list)

[Blake Frantz]

Some javascript/style in this post has been disabled (why?)

We ended up in the weeds there for a bit with the API speak - to rewind, does everyone agree on these items:

 

a.  A clear set of rules for how to determine if a given platform instance “belongs to” a CPE-ID would be very useful.

b.  A clear set of rules for CPE-ID globbing (when does a CPE-ID “match” another; when does it not?) would be very useful.

 

Drew – back to your original question, I vote for option 2 as it will make item “a” much easier to implement. Item “a” being one of the most important things missing from CPE today, IMHO.

 

Blake

 

From: Jeffery Turner [mailto:[hidden email]]
Sent: Monday, June 01, 2009 4:01 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

 

 

I agree API design and construction is outside the scope of CPE.  I do think CPE should use more deterministic data in construction of CPE IDs (like using version numbers) so we do not have to have a map for our map (matching Windows titles for all Windows SKUs to CPE IDs is fraught with peril).  By avoiding version numbers in the CPE components to prevent associating “Windows XP x64” with the “Windows Server 2003” code-base (which probably should match at the version level), the system was designed such that “Microsoft Windows” will not match “Microsoft Windows XP”.

 

Would we even be having the heartburn over using / including version numbers if “Windows XP x64” was named “Windows 2003 Workstation x64”?  What if Microsoft had named it something else completely- the “Super-Fantastic Awesome Workstation Operating System by Microsoft” (the future name of Windows 8, maybe)?

 

Version numbers are deterministic; they can be easily determined without a map and can automatically be used to match new versions as they are released.  This limits the need to have a complete list of SKU titles for an Operating System revision and eliminates the perils in trying to put together a regular expression that doesn’t miss anything and doesn’t match too much.

 

I think this list should not focus on how to build an API.  Leave that to products that use CPE.  But we should try to make sure the ID creation / evaluation is as black and white as possible, not ambiguous and subject to interpretation.  There should be no question as to what belongs to a given CPE.  Or make the ID strictly an ID and leave classification (which is really what matching is about) for the CPE Language, at which point GUIDs work just fine for me. J

 

So my long diatribe about deterministic solutions was to support the original “Option 2” as more “API-friendly” and more deterministic data that does not require finding lists of SKUs from vendors to figure out the OS “version” component.

 

I do like the idea of coming up with APIs that map to the correlating CPE entry, but I think that is more a discussion of the implementation of CPE than CPE itself (and the topic of a different discussion list)

 

 

---

From: Ernest Park [mailto:[hidden email]]
Sent: Friday, May 29, 2009 11:58 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

 

sounds like we have gone from CPE to a theoretical APi that will query a database of metadata that is currently not populated. 

 

 

While it is a nice idea, this goes quite a bit off scope from what CPE is supposed to be.

 

 

Any chance we can just work on adding more to existing CPE, and then having a web service to just query the full CPE names?

 

 

 

Ernie

 

 

On Fri, May 29, 2009 at 6:04 PM, Robert Neuman <[hidden email]> wrote:

Kurt/Blake: I'd recommend using the Major:Minor:Build:Revision:Other followed by a brief human readable name. If you want to get detailed information from the OS fill an OSVERSIONINFOEX structure (link) with a call to GetVersionEx (sample). The table in the remarks section of (link) summarizes the values returned by supported versions of Windows. Use the information in the Other column to distinguish between operating systems with identical version numbers. This means calls using OSVERSIONINFOEX, GetSystemMetrics(), and SYSTEM_INFO.wProcessorArchitecture. 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]]

---

View this message in context: Re: Microsoft OS Naming Issue

Sent from the CPE - Common Platform Enumeration mailing list archive at Nabble.com.

 

[Mark J Cox-2]

> So using the Major:Minor:Build:Revision:Other followed by a brief human
> readable name. It gives fields to record the data and is applicable across
> different manufacturers.  For example in the RHEL the version numbers of
> some applications do not change version numbers when patched, the package
> info changes for the application.  Therefore the "Other" field might be used
> to hold the package info.

Looking at the breakdown of individual package versions in a release is at
a different level of abstraction to our use of CPE names.  However just to
clarify, every Red Hat RPM package is identified with a name, version, and
release (NVR).  Although a security update in most cases will not update
the version (since it matches the upstream version), the release will be
updated as every package ever released no matter what product is applies
to has a unique NVR.

Thanks, Mark

[Vladimir Giszpenc]

Hi Ernest et al,

> sounds like we have gone from CPE to a theoretical APi that will query
a database of metadata that is currently not populated.

So why aren't you recommending using a Hashing function (or several) to
determine what a product is uniquely (which I believe you do)?  I agree
that we need to agree on the Data before we start discussing the
Metadata.  A Hash of an RPM sounds a lot more unique than an NVR.  We
just need to agree on what we hash.  We can combine things to hash to
produce new hashes.  Hashes are not specific to a vendor since everyone
produces files.

Even if sometimes files are not around to get hashed e.g. the only
change is to a database, we should strive to use an agreed upon API to
identify products when possible and when not possible revert to our
current best guess.  There is too much data/metadata in our key.  I
always liked meaningless keys like numbers and GUIDs/UUIDs.  To ensure
that a key field doesn't change over time, it should have no meaning.
This is a basic normalization concept.

The Query Language could be rewritten to work on MetaData as opposed to
working directly on the keys.

We want a dictionary.  There is no reason why the contents of our
dictionary should not be determined by using an API (when possible).
The problem that we would then have would be how to express our queries
succinctly.

So we could do it not so succinctly (like the rest of SCAP):

<Name operator="patternmatch">^Windows XP*</Name>
<Version operator="greater than or equal to">5.0</Version>
<Version operator="less than">5.3</Version>
Etc...

This is not all thought out, but it seems to have potential...

Best regards,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]

[Gary Newman-2]

It's good that we're back on the discussion of Drew's suggested reforming of
Microsoft CPE names.

Drew's May 18th Option 2 proposal appears to suggest that Microsoft OS version
numbers trump product name.  Blake's May 27th response nicely points out that
other components of an OS product are important as well so each separately
marketed product should continue to have a separate CPE id.

With that in mind, it seems that the proposal just reorders information within
the name.  Mostly it pushes product marketing name details out of the product
component and into the edition component.  This doesn't seem to "put to bed the
continued discussions on Microsoft names" so as far as I can see.

It's best to stay with Option 1, with the OS version component filled in
(instead of left out, as is the case for the current dictionary).

        -Gary-

> 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?

[Andrew Buttner]

>a.  A clear set of rules for how to determine if a given platform
>instance "belongs to" a CPE-ID would be very useful.

Could an OVAL Definition be used to satisfy this?  This at least was the intention when CPE was created.  The <check> element in the dictionary is there to hold such info.  The problem we have found is that creating the hundreds or thousands of OVAL Definition is very labor intensive and currently beyond available resources of the community.

Thanks
Drew

[Tim Keanini]

Team,
I am going to abstain from voting for option 1 or option 2 because IMHO
both of them have equal amount of costs and benefit; changing may solve
old problems but introduce new ones.  Please don't take this the wrong
way, I have spent a lot of time arguing it one way and the other and I
think it is a wash.

I hope to have more discussion with the CPE community when I am out
there at SCAP Developer Days.  I believe there is a way for us to
propose a new form that will remain compatible with the current form and
better support the growing needs of CPE as it pertains to SCAP and
beyond to other communities like ITIL.

For those who care to read on, it would be helpful for us to think in
terms of relationships and inference to get to the heart of this matter.
Let me first define two necessary terms:

Inverse Functional Property:
We need a property P such that when we assert A P X, and B P X, that we
can correctly infer that A and B are the same.  We can find this
characteristic in standards that leverage Social Security Number,
Drivers License Number, Employee number, and so on.  In all cases there
is an explicit function scope from domain specific all the way to
universal.  
Example:
 TK               hasSocSecurityNumber      555-55-5555
"Tim Keanini"     hasSocSecurityNumber      555-55-5555
We can infer that:
"TK" is the same as "Tim Keanini"
Rarely are these inverse functional properties comprised from metadata.
How crazy would it be to compute a Social Security Number from the many
observable facets of my being and even if it were true at one time,
would it be durable across large periods of time. Its primary objective
is to provide uniqueness within a Class (aka Set) and leave inference
and meaning to the rich metadata form.

Inference:
What makes the standard correct or incorrect is based on the inferences
drawn that are useful to a community.  As we have seen in this thread,
there is a need from different roles (heterogeneous viewpoints) within
an enterprise to be able to infer that two different CPEs are:
- based on the same codebase therefore code-level inferences can be
drawn
- related to a particular weakness or vulnerability therefore
security-level inferences can be drawn
- related to a particular regulation, guidelines, or policy therefore
compliance-level inferences can be drawn
There are roles and processes that are not being represented as we
create this standard so we must ensure that the standard will be
extensible (new terms created from relationships to old terms).  

For discussions sake, I am going to use the term 'marketing names' to
make reference to option 1 and the term 'technical names' to reference
option 2.

Marketing names for the most part serve to promote a single view-point
(the viewpoint of its creator) and operate much in the way that
firstname/givenname and lastname/surname are used in society.  It is a
label that is imprecise, has a likelihood of changing, and could lead to
an incorrect inference as with names inferring genetic relationships:

- Same surname but different code: Jim Jones and Tom Jones are not
based on the same genetic codebase
- Different surname but same code: Angelina Jolie is based off the
genetic codebase of Jon Voight and Marcheline Bertrand  

They serve a social function but make for poor 'inverse functional
properties'  for machine-readability and  make for poor inferences
because so many exceptions can be made to the rules.  This does not make
them useless, they are useful but only within specific context.  I
thought Blake Frantnz makes an excellent point about the way advisories
and guidance documents are socialized using the marketing names.  While
marketing names are required, we must satisfy it without comprising a
globally unique identifier.  

Technical names in the way proposed in option 2 are an attempt to
compute an inverse functional property from a set of observable facets.
The problems then become which facets and are those facets the right
facets over the entire domain of anything that could be a CPE.  As an
example, consider your Passport and how that system would work if the
Passport Number was a label we were trying to derive from any one of the
many facets/metadata that was declared on that object.  

A character set (alpha and/or numeric) on the other hand when void of
any metadata make for excellent 'inverse functional properties' for
machine-readability but without metadata are not very useful to humans.
Consider the inodes to your filesystem and its relationship with the
other layers like sectors below (machine-needs) and filenames above
(human-needs).

As I had suggested in late 2006 and recently suggested by Valdimir
Giszpenc and Jeffery Turner, the ideal is to have the ID strictly an ID
like http://nvd.nist.gov/cpe123125# or some other form that only
satisfies the requirement of an inverse functional property - all that
can be inferred is that it is a unique member of the class that is CPE.
Then have a metadata structure ranging from RDF to OWL-FULL that
delivered a vocabulary and ontology that would support multiple
inference needs and would be extensible without to any specific
viewpoint.

--tk

-----Original Message-----
From: Gary Newman [mailto:[hidden email]]
Sent: Tuesday, June 02, 2009 12:39 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

It's good that we're back on the discussion of Drew's suggested
reforming of
Microsoft CPE names.

Drew's May 18th Option 2 proposal appears to suggest that Microsoft OS
version
numbers trump product name.  Blake's May 27th response nicely points out
that
other components of an OS product are important as well so each
separately
marketed product should continue to have a separate CPE id.

With that in mind, it seems that the proposal just reorders information
within
the name.  Mostly it pushes product marketing name details out of the
product
component and into the edition component.  This doesn't seem to "put to
bed the
continued discussions on Microsoft names" so as far as I can see.

It's best to stay with Option 1, with the OS version component filled in

(instead of left out, as is the case for the current dictionary).

        -Gary-

> 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?

[Vladimir Giszpenc]

Tim et al,

There are two camps here and they should separate into two different
communities.

Camp 1 has access to the host and is authenticated.  Camp 1 can query
the system through a query language.  Camp 1 has OVAL.  I recently
discovered camp 1 has CIM (is there a good reason we did not build on
top of that?)  Camp 1 can come up with a consistent API to definitively
have the system describe itself.  I am not convinced we need another
querying language even though I am intrigued.  There would probably be
greater value in developing a SimpleOVAL that builds on OVAL but is much
easier.  The barrier to entry seems to be a huge obstacle.  CIS had a
checking system so simple it got neatly embedded in the XCCDF.  We need
something like that.  Guidance can be expressed using queries without
the need for IDs (even meaningless IDs).

Camp 2 does not have access to the host or can get to the host but is
not authenticated.  Two databases need to refer to the same software, a
network scanner makes an educated guess as to what is running and all
want to talk about the same thing using a common vocabulary.  Good luck
to us on this one.  We have people entering stuff in the databases,
scanners guessing, vendors changing names and other stuff constantly and
systems generally changing over time.  Our goal should be to come close
and that should be plenty here.  A more sophisticated query language
could be useful here.  

As useful as it is, CPE should not be part of SCAP.  CVE, CCE and XCCDF
should be able to be expressed as applying to a host in a given state
using an API i.e. a checking system.

There are probably funding implications so I am sure to get flamed for
such heresy.  It is true that I was not there from the beginning.
XCCDF-P and whatever else came before was just as bad.  On the SCAP
side, we should use a checking system.  OVAL is one.  It sounds like we
need to simplify it to achieve our goals.  We need to do a better job of
reducing what we need to know to a simple API.  Why do we need a CPE ID
that in the end refers to an OVAL test.  Have an OVAL definition ID and
be done with it.  If we want to optimize OVAL to have an "applies to"
that short circuits the rest of the criteria, then we should just add a
mandatory short circuit capability to the criteria.

Now we should have plenty of time to talk about remediation :).

Best regards,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]

[Tim Keanini]

Vladimir,
If anything I think this is further evidence that the name(s) cannot be
the same as the thing named.  I respectfully disagree and assert that
CPE is a necessary part of SCAP for there must be an unambiguous object
for:
- that which has a CVE
- that which has a CCE
- that which has a XCCDF

As one of the vendors on the list, I can address your Camp1 and Camp2
scenarios with excruciating first-hand knowledge.  It is the norm these
days for vendor to have both authenticated and unauthenticated methods
of discovery; it is also the norm for a customer to have authenticated
and unauthenticated methods of discovery and for the customer it might
be from multiple vendors (I feel your pain).  

Lets address both sides of the graph traversal:
From the scanners perspective, as you have described, a CPE is
discovered with the prior knowledge of the IP, the TCP or UDP port
information, and maybe some service identification.  Essentially, you
are walking up the TCP stack until you can find something to
authenticate to or pre-qualify as a CPE.  In this perspective, every
scanner will have some method to recognize the application or OS.  This
puts a heavy emphasis on the way in which the CPE is discovered and the
precision of that method.  (i.e scanner can tell it is Apache but can it
tell if it is Apache 1.3.30 even before any CVE or CCE discovery has
been run)

From the synthesis/analytical perspective, from one source I may learn
of a CVE and need to properly infer the CPE associated with that CVE.
Or it may be that a policy editor has set a directive to police a
particular XCCDF and before I can go about delegating these tasks, I
must be able to infer the appropriate CPE's and whether I know of them
(in cache) or I need to scan for them.  

Lastly, there are many use-cases around efficiency whereby you don't
want a bunch of multi-vendor scanners all asking the same damn question
of the target host.  CPE turns out to be a very important node in the
graph to make sure you are checking a shared cache.

--tk

-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Wednesday, June 03, 2009 8:00 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

Tim et al,

There are two camps here and they should separate into two different
communities.

Camp 1 has access to the host and is authenticated.  Camp 1 can query
the system through a query language.  Camp 1 has OVAL.  I recently
discovered camp 1 has CIM (is there a good reason we did not build on
top of that?)  Camp 1 can come up with a consistent API to definitively
have the system describe itself.  I am not convinced we need another
querying language even though I am intrigued.  There would probably be
greater value in developing a SimpleOVAL that builds on OVAL but is much
easier.  The barrier to entry seems to be a huge obstacle.  CIS had a
checking system so simple it got neatly embedded in the XCCDF.  We need
something like that.  Guidance can be expressed using queries without
the need for IDs (even meaningless IDs).

Camp 2 does not have access to the host or can get to the host but is
not authenticated.  Two databases need to refer to the same software, a
network scanner makes an educated guess as to what is running and all
want to talk about the same thing using a common vocabulary.  Good luck
to us on this one.  We have people entering stuff in the databases,
scanners guessing, vendors changing names and other stuff constantly and
systems generally changing over time.  Our goal should be to come close
and that should be plenty here.  A more sophisticated query language
could be useful here.  

As useful as it is, CPE should not be part of SCAP.  CVE, CCE and XCCDF
should be able to be expressed as applying to a host in a given state
using an API i.e. a checking system.

There are probably funding implications so I am sure to get flamed for
such heresy.  It is true that I was not there from the beginning.
XCCDF-P and whatever else came before was just as bad.  On the SCAP
side, we should use a checking system.  OVAL is one.  It sounds like we
need to simplify it to achieve our goals.  We need to do a better job of
reducing what we need to know to a simple API.  Why do we need a CPE ID
that in the end refers to an OVAL test.  Have an OVAL definition ID and
be done with it.  If we want to optimize OVAL to have an "applies to"
that short circuits the rest of the criteria, then we should just add a
mandatory short circuit capability to the criteria.

Now we should have plenty of time to talk about remediation :).

Best regards,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]

[Vladimir Giszpenc]

TK,

> If anything I think this is further evidence that the name(s) cannot
be
> the same as the thing named.  I respectfully disagree and assert that
> CPE is a necessary part of SCAP for there must be an unambiguous
object
> for:
> - that which has a CVE
> - that which has a CCE
> - that which has a XCCDF

There is no disagreement here.  However, a system based on a list of IDs
will fail, where an API will be unambiguous and authoritative (coming
from the source).  If we need to enhance OVAL or have another
Unauthenticated checking system, I am all for that.

> scanner will have some method to recognize the application or OS.
This
> puts a heavy emphasis on the way in which the CPE is discovered and
the
> precision of that method.  (i.e scanner can tell it is Apache but can
> it
> tell if it is Apache 1.3.30 even before any CVE or CCE discovery has
> been run)

You need a mapping between the discovery that Apache is (probably)
running on a host and a CVE saying version 1.3.30 of Apache has a
vulnerability.  Are we talking about a vendor agnostic way of defining
that mapping?  I would turn the problem around.  Why not get CVE and
friends to add applicable checking system results as a criteria.  My
problem lies in reducing platforms to IDs when all we care about are
criteria that can be expressed as API queries (or some XML such as OVAL
that translates to API calls).

On the other hand, it must be difficult to express "CVE 123 is a finding
if Apache version 1.3.30 is installed (test using definition id
whatever-123) or if a packet is sent containing foo and a packet is
received containing bar and ..."  There is no question that we need ways
to make writing CVEs and friends manageable.  Defining queries OVAL or
otherwise that match our CVE seems less ambiguous than listing CPE IDs.
CPE in the SCAP context loses value without the OVAL or other checking
systems making things *automatable*.

Best regards,

Vlad


P.S.  See you at the SCAP Developer Conference

[Paul Cichonski]

TK/ Vladimir et all,

I agree that CPE is a necessary part of SCAP, not just for its ability to
uniquely identify a product, but also for its ability to communicate
metadata information about that product.  As TK suggested the unique
identifier for a product permits communication about a product regardless of
the mechanism for how the product was discovered.  In the ideal model
changes to the product meta-data will not result in a change to the unique
identifier; CPE mixes the meta-data into the identifier breaking this model,
which is one of the reasons why the community struggles with what to put
into the CPE Name.  Using an Oval check as the identifier (any specific
check system) causes two problems: the specification would be tied to a
particular check implementation, and it does not allow for the exchange of
product meta-data information.  A unique identifier allows organizations to
associate any organization-specific meta-data, this meta-data could be a
product check system, a maintained list of product tags, or any other
proprietary  information the organization needs to maintain internally.

Recently there has been a lot of talk on the list relating to all the
additional product metadata that we need to capture and store.  I think
everyone has been laying down the reasons as to why CPE will work well as an
ontology.  Some of these reasons include the dynamic nature of the model,
and the need for organizations to only support certain parts of the model
(or even extend it to fit their unique use case).

Here at NVD we are exploring the possibility of moving our internal
relational CPE data model over to an ontological model.  In case this alarms
anyone, I should clarify that this work will not affect any of the CPE
support we provide; this ontology would only be used for our internal
storage and we will continue to fully support all the CPE functionality we
provide (we will of course make our work public as we progress).  Some of
the reasons for exploring the ontological model are:

- The ontological solution has built-in support for dynamic growth of the
model while the relational approach requires schema changes to support any
additional metadata fields.  
- Built in support (through W3C modeling languages) for inferencing
(asserted triples) that could potentially allow for machine-assisted
cleaning of the data, as well as the automatic generation of relationships
that were not captured by analysts.
- Support for tagging (through defined relationships/classes) that will
increase both the efficiency and accuracy relating to the process of
associating CPEs with vulnerabilities, checklists and other product/asset
related information.

Above and beyond the specific NVD use cases, which tend to focus on
associating CPEs with software flaws, checklists, or configuration issues, a
CPE ontology can also satisfy many of the use cases which have been
discussed on the list.  One example of this is the "Camp 2" use case which
Vladimir hinted at.  This use case is where a network scanner identifies a
product that is responding on a system.  The network scanner does not know
exactly what this product is, but it does capture some "fuzzy" information
relating to that product.  I think the end goal in this use case is to
identify the product(s) that "could be" on the system and more specifically
identify all the CVEs associated with that product(s).  The network scanner
did not return enough information to identify the product as a fully
qualified CPE, but it did return certain properties relating to one or more
products.  In a well-defined ontological model, it would be possible to pull
CVE information from a subset of CPE properties/components.  What I am
talking about here is the ability to pull CVE information through the
individual properties of a CPE (e.g. "CVE-2009-XXX is vulnerable to all
products that have a vendor of Vendor-A, and a product of Product-B").

In the past NVD had put forth a proposal for CPE tagging
(http://n2.nabble.com/New-CPE-Proposals-td1438230.html); another benefit of
an ontological model is the ability to easily tag products, and to relate
software flaws to a tag instead of an individual CPE.  When a category/tag
is applied to a vulnerability, the system (NVD) will dynamically generate
the list of affected products (i.e. all products belonging to a tag)
whenever a user requests it.  This list automatically grows when new
products are tagged with the same category, which significantly reduces the
maintenance burden.  To highlight why this tagging is necessary, take for
example CVE-2008-4609
(http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-4609) which is a
vulnerability in operating systems that have a TCP/IP implementation.  In
order to add the correct CPEs for this CVE our analysts had to go through
and manually add every CPE that has a TCP/IP implementation (and we
undoubtedly missed some).  The ideal solution would be to have a Product
Category called "has_TCP/IP_stack", and add any newly created CPEs to this
category at the time of their instantiation.  This would allow our analyst
to say "CVE-2009-4609" affects all CPEs that are members of the
"has_TCP/IP_stack" Product Category." and that is all; the system could then
build out the full product list internally; an ontology would support this
out of the box by defining the correct set of relationships.

The technologies we have been exploring at NVD for this project are not new.
The entire semantic stack of technologies are W3C recommended.  The semantic
stack actually builds off the current technologies being used in CPE (XML
makes up the Transport/Syntax layer of the semantic stack).

The word "ontology" is fairly loaded and I want to make it clear that this
is not a magic bullet, and will not solve all our problems in a day.  Most
of what I have described above can be done in a relational model.  The key
point to understand here is that a semantic model provides certain
capabilities, above and beyond standard XML/relational data models, that can
ease our burden.  CPE is by no means an easy problem, and trying to solve it
without leveraging semantic technologies (that are fully backed by the W3C)
may limit our ability to succeed.

-Paul Cichonski
National Vulnerability Database

-----Original Message-----
From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Wednesday, June 03, 2009 11:20 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Microsoft OS Naming Issue

TK,

> If anything I think this is further evidence that the name(s) cannot
be
> the same as the thing named.  I respectfully disagree and assert that
> CPE is a necessary part of SCAP for there must be an unambiguous
object
> for:
> - that which has a CVE
> - that which has a CCE
> - that which has a XCCDF

There is no disagreement here.  However, a system based on a list of IDs
will fail, where an API will be unambiguous and authoritative (coming
from the source).  If we need to enhance OVAL or have another
Unauthenticated checking system, I am all for that.

> scanner will have some method to recognize the application or OS.
This
> puts a heavy emphasis on the way in which the CPE is discovered and
the
> precision of that method.  (i.e scanner can tell it is Apache but can
> it
> tell if it is Apache 1.3.30 even before any CVE or CCE discovery has
> been run)

You need a mapping between the discovery that Apache is (probably)
running on a host and a CVE saying version 1.3.30 of Apache has a
vulnerability.  Are we talking about a vendor agnostic way of defining
that mapping?  I would turn the problem around.  Why not get CVE and
friends to add applicable checking system results as a criteria.  My
problem lies in reducing platforms to IDs when all we care about are
criteria that can be expressed as API queries (or some XML such as OVAL
that translates to API calls).

On the other hand, it must be difficult to express "CVE 123 is a finding
if Apache version 1.3.30 is installed (test using definition id
whatever-123) or if a packet is sent containing foo and a packet is
received containing bar and ..."  There is no question that we need ways
to make writing CVEs and friends manageable.  Defining queries OVAL or
otherwise that match our CVE seems less ambiguous than listing CPE IDs.
CPE in the SCAP context loses value without the OVAL or other checking
systems making things *automatable*.

Best regards,

Vlad


P.S.  See you at the SCAP Developer Conference

[Andrew Buttner]

>In the ideal model
>changes to the product meta-data will not result in a change to the
>unique identifier; CPE mixes the meta-data into the identifier
>breaking this model, which is one of the reasons why the community
>struggles with what to put into the CPE Name.

First, I do agree with the above statement.  But I want to make sure everyone is aware why we chose to embed semantics into the identifier.  It was NOT in an attempt to enable the metadata to be transmitted from one source to another.  We did not want the CPE Name to be an expression format.  Rather, we were looking for a way to avoid the resource intensive analysis team that is typically in charge of assigning numeric IDs.  Our hope was to develop an id format that would allow two people to independently come up with the same unique id.  (yes we have realized that this is an unrealistic goal in a perfect sense)

Again, the above is just to make sure everyone is aware of the history.

Thanks
Drew

[Andrew Buttner]

Thank you to all that weighed in on this issue.  I think this was one of the better discussions we have had and I think we have made some great progress in understanding where CPE might need to go in the future.  I am excited to get to work on turning some of these thoughts into reality.

I will be summarizing the different views and forwarding this summary on to our government sponsor for a decision.  Once a decision has been reached, I will make sure to pass this along to the community.  In addition I will forward on any decision on how to enact the decision (spec change, etc.).

In short, I saw a lot of support for moving away from marketing names and attempting to leverage the technical lineage of code when possible.  But I also heard that this type of change will not solve some of real core issues of CPE and that a possible drastic change should be examined.  The notion of numerical ids, inference, and leveraging more deterministic data continue to be talked about with the community and spending some time putting together a real proposal to discuss is in order.

Again, will forward out my official summary shortly.

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