Windows naming in CPE

[Andrew Buttner]

There has been some sidebar discussion about how to correctly name
Windows within CPE.  The specification currently defines the first
three components of the OS part as:

  {vendor}:{family}:{version}

For Windows, additional components are then used to add edition and
service pack level.  For example:

  cpe://microsoft:windows:xp:pro:sp2

This breakdown has been questioned and I would like to get some
different opinions on the direction with which to proceed.  I've tried
to outline all the views that have been presented to me in a concise
manner, but it has still gotten rather lengthy ...

I look forward to any thoughts people have on the matter.

------------------
BACKGROUND
------------------

The big question is about the family name 'windows'.  One of the goals
of a CPE Name is to enable matching among names written to different
levels.  The best example of this is a config guide that wants to say
"set this if you are running a Windows OS".  To do this, the guide
would be written to apply to cpe://microsoft:windows.  Now assume that
you are evaluating a system that is determined to be
cpe://microsoft:windows:vista.  A tool must now determine if
cpe://microsoft:windows:vista is an instance of
cpe://microsoft:windows.  This is matching.

Currently this is done by walking up the hierarchy.  Since
cpe://microsoft:windows:vista includes cpe://microsoft:windows, then we
have a match.

Back to the family name of 'windows'.  The CPE Name
cpe://microsoft:windows implies every Windows OS previously released,
as well as all future releases.  Is it really practical to break out
this level?  Would we really write something that applies to Windows
3.1 and Vista?

Would we be better off separating things out by kernel:

 windows     (1.0, 2.0, 3.0, 3.1, 95, 98, ME)
 windows-nt  (NT, 2000, XP, 2003, Vista)
 windows-ce  (1.0, 2.0, 3.0 ...)

This helps align things a little better with how technically Microsoft
develops things, but it does not align with how things have been
marketed.  This would give us some pretty unintuitive names like
cpe://microsoft:windows-nt:nt and cpe://microsoft:windows-nt:2000.  Of
course the titles associated with each name would help clear up this
confusion.  

Another option would be to move the NT/2000/XP/Vista designator into
the family name so we would have cpe://microsoft:windows-xp.  This
would align better with the public's perception of the different OSs,
but would not give us the matching flexibility that is desired.  To
solve this discrepancy, we could think about the idea of abstractions
where we would create a new CPE Name that would represent a much more
complex CPE name or set of CPEs.  You could have an abstraction for
"all Windows", "all Windows NT kernel", "all Unix OSs", "Microsoft
Office", "all browsers", "all email programs", "firewalls", "IDSs" ...
Each abstraction would be formally mapped to a specific CPE (or set of
CPEs). Thus, cpe://microsoft:windows could be an abstraction that would
map to the set of CPEs that contain all windows OSs.  You could use
abstractions whenever a common grouping occurred where you would write
configuration CCEs or XCCDF rules based on the group as opposed to a
particular product.  This is obviously a topic that would need its own
thread to develop, but I want to make the idea known as it could
influence this discussion.

--------------------
QUESTION
--------------------

For CPE, what should the family name be for names defining the Windows
OSs?
  - should it stay with 'windows'
  - should we switch to kernel names
  - should we change to match public perception


Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Ken Lassesen-2]

To me, one of CPE main client is OVAL and CVE. In both cases, we want a
CPE to be a unique precise identifier and not a fuzzy identifier. So
Avoid public perception --- we do not wish to be marketing driven...

Yes, Kernel names are far superior to public perceptions. Most of the
audience for CPE are technical types and the kernel names are completely
meaningful (IMHO).


Personally, I feel that language is needed if we go to SP level. I
recall well from my days at Microsoft that some system components were
different versions on different languages of an OS.

  {vendor}:{family}:{version}:{language}:

If my memory server me right, a few updates are still delayed for
selected languages for some components -- which would imply that the
versions have changed.


Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

[Scott Carpenter-4]

As a vendor that has been using CPE like technology to match
vulnerabilities and remediations for over three years, I like the way
that CPE is currently set up. It permits wildcarding of checks and
remediations in a way that content developers/sys admins understand
best. I can write a check that is
all windows (most of them fall into this category) or get more specific
as needed.

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, March 26, 2007 12:24 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Windows naming in CPE

There has been some sidebar discussion about how to correctly name
Windows within CPE.  The specification currently defines the first
three components of the OS part as:

  {vendor}:{family}:{version}

For Windows, additional components are then used to add edition and
service pack level.  For example:

  cpe://microsoft:windows:xp:pro:sp2

This breakdown has been questioned and I would like to get some
different opinions on the direction with which to proceed.  I've tried
to outline all the views that have been presented to me in a concise
manner, but it has still gotten rather lengthy ...

I look forward to any thoughts people have on the matter.

------------------
BACKGROUND
------------------

The big question is about the family name 'windows'.  One of the goals
of a CPE Name is to enable matching among names written to different
levels.  The best example of this is a config guide that wants to say
"set this if you are running a Windows OS".  To do this, the guide
would be written to apply to cpe://microsoft:windows.  Now assume that
you are evaluating a system that is determined to be
cpe://microsoft:windows:vista.  A tool must now determine if
cpe://microsoft:windows:vista is an instance of
cpe://microsoft:windows.  This is matching.

Currently this is done by walking up the hierarchy.  Since
cpe://microsoft:windows:vista includes cpe://microsoft:windows, then we
have a match.

Back to the family name of 'windows'.  The CPE Name
cpe://microsoft:windows implies every Windows OS previously released,
as well as all future releases.  Is it really practical to break out
this level?  Would we really write something that applies to Windows
3.1 and Vista?

Would we be better off separating things out by kernel:

 windows     (1.0, 2.0, 3.0, 3.1, 95, 98, ME)
 windows-nt  (NT, 2000, XP, 2003, Vista)
 windows-ce  (1.0, 2.0, 3.0 ...)

This helps align things a little better with how technically Microsoft
develops things, but it does not align with how things have been
marketed.  This would give us some pretty unintuitive names like
cpe://microsoft:windows-nt:nt and cpe://microsoft:windows-nt:2000.  Of
course the titles associated with each name would help clear up this
confusion.  

Another option would be to move the NT/2000/XP/Vista designator into
the family name so we would have cpe://microsoft:windows-xp.  This
would align better with the public's perception of the different OSs,
but would not give us the matching flexibility that is desired.  To
solve this discrepancy, we could think about the idea of abstractions
where we would create a new CPE Name that would represent a much more
complex CPE name or set of CPEs.  You could have an abstraction for
"all Windows", "all Windows NT kernel", "all Unix OSs", "Microsoft
Office", "all browsers", "all email programs", "firewalls", "IDSs" ...
Each abstraction would be formally mapped to a specific CPE (or set of
CPEs). Thus, cpe://microsoft:windows could be an abstraction that would
map to the set of CPEs that contain all windows OSs.  You could use
abstractions whenever a common grouping occurred where you would write
configuration CCEs or XCCDF rules based on the group as opposed to a
particular product.  This is obviously a topic that would need its own
thread to develop, but I want to make the idea known as it could
influence this discussion.

--------------------
QUESTION
--------------------

For CPE, what should the family name be for names defining the Windows
OSs?
  - should it stay with 'windows'
  - should we switch to kernel names
  - should we change to match public perception


Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Peter M. Mell]

This is an excellent recap of the sidebar discussions surrounding the naming
of Windows. One additional point that I would like to mention is that the
way the CPE specification names Windows products deviates from the CPE names
for all other products. With all other products, the 2nd column of the CPE
name represents a product name that is actually sold by a vendor. Only with
Windows does CPE deviate in an attempt to allow people to talk about "all
Windows" abstractly. Thus, to keep a uniform level for all CPEs, I believe
that Windows OS entries should have the 2nd column be the product names as
sold by Microsoft. This is not bowing to "public perception" but instead
using the very names that vendors themselves give to their products. Using
the names used by the vendors themselves is particularly important to me
because I am in the process of providing a public data feed for all CVEs and
CCEs labelled with CPEs. I believe the IT industry and software vendor
community will expect me to use the names by which products are sold.

All of this said, the need to speak abstractly about groups of products is
absolutely vital. Scott is right that we need to be able to talk about "all
Windows" but Ken is also right that we need to be able to talk at the level
of kernel names. There is no one right way to abstract Windows. Also, our
abstraction method should generalize to all products and not be Windows
specific. Note that the current Windows abstraction method will not work for
any other abstraction. We should be able to concisely state, as Drew
mentioned, "all Windows", "all Windows NT kernel", "all Unix OSs",
"Microsoft Office"... We need a generic abstraction capability for CPE.
Until this is developed, I suggest that we limit CPE to the same level of
abstraction (as is being done with CCE and has always been done for CVE).

To bring this down to an implementation level. I suggest naming Windows
using the same model we use for other products (using the name used by the
vendor to sell the product):

cpe://microsoft:windows_xp
cpe://microsoft:windows_vista

These match the form of RedHat and Sun products in the draft CPE dictionary

cpe://redhat:enterprise_linux
cpe://redhat:linux
cpe://sun:sunos

Peter Mell
National Vulnerability Database Program Manager
http://nvd.nist.gov

[Peter M. Mell]

CPE SIG,

Within the National Vulnerability Database we have been labelling CVEs with
all applicable CPEs. In many cases we need to express that the vulnerability
exists when application X is running on OS Y. This is particularly
problematic when the application runs on every Linux OS. It would be
difficult for my analysts to separately list every Linux OS (there are
several hundred) for each CVE about a linux application.

Thus, until CPE solves the abstraction problem, we have implemented a
temporary solution. We create abstract CPE entries that map to the normal
CPE entries. For example, we use a CPE called
cpe://unix:unix:cpe_abstraction to refer to all Unix OSs. Likewise, we have
a cpe://linux:linux:cpe_abstraction and we probably need a
cpe:///microsoft:office:cpe_abstraction. Using this approach we then must
define how each abstraction cpe maps to a set of normal CPEs. So far,
thankfully, the abstractions that we have needed have been few in number.

I'm not claiming that this is necessarily the best solution. It is simply
what we have been forced to temporarily implement until this group decides
on a proper abstraction capability.

Peter

-----Original Message-----
From: Peter Mell [mailto:[hidden email]]
Sent: Monday, March 26, 2007 3:18 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Windows naming in CPE


This is an excellent recap of the sidebar discussions surrounding the naming
of Windows. One additional point that I would like to mention is that the
way the CPE specification names Windows products deviates from the CPE names
for all other products. With all other products, the 2nd column of the CPE
name represents a product name that is actually sold by a vendor. Only with
Windows does CPE deviate in an attempt to allow people to talk about "all
Windows" abstractly. Thus, to keep a uniform level for all CPEs, I believe
that Windows OS entries should have the 2nd column be the product names as
sold by Microsoft. This is not bowing to "public perception" but instead
using the very names that vendors themselves give to their products. Using
the names used by the vendors themselves is particularly important to me
because I am in the process of providing a public data feed for all CVEs and
CCEs labelled with CPEs. I believe the IT industry and software vendor
community will expect me to use the names by which products are sold.

All of this said, the need to speak abstractly about groups of products is
absolutely vital. Scott is right that we need to be able to talk about "all
Windows" but Ken is also right that we need to be able to talk at the level
of kernel names. There is no one right way to abstract Windows. Also, our
abstraction method should generalize to all products and not be Windows
specific. Note that the current Windows abstraction method will not work for
any other abstraction. We should be able to concisely state, as Drew
mentioned, "all Windows", "all Windows NT kernel", "all Unix OSs",
"Microsoft Office"... We need a generic abstraction capability for CPE.
Until this is developed, I suggest that we limit CPE to the same level of
abstraction (as is being done with CCE and has always been done for CVE).

To bring this down to an implementation level. I suggest naming Windows
using the same model we use for other products (using the name used by the
vendor to sell the product):

cpe://microsoft:windows_xp
cpe://microsoft:windows_vista

These match the form of RedHat and Sun products in the draft CPE dictionary

cpe://redhat:enterprise_linux
cpe://redhat:linux
cpe://sun:sunos

Peter Mell
National Vulnerability Database Program Manager
http://nvd.nist.gov

[Andrew Buttner]

>cpe://microsoft:windows_xp
>cpe://microsoft:windows_vista
>
>These match the form of RedHat and Sun products in the draft
>CPE dictionary
>
>cpe://redhat:enterprise_linux
>cpe://redhat:linux
>cpe://sun:sunos


I disagree.  I would argue that "redhat enterprise_linux 4" and
"microsoft windows vista" are both at the same level of abstraction.  I
see the terms NT/2000/XP/Vista as the different major versions of the
Windows OS (more specifically the Windows NT Kernel).

Thanks
Drew

[Mann, Dave]

Ken Lassesen wrote:
> To me, one of CPE main client is OVAL and CVE. In both cases, we want
> a CPE to be a unique precise identifier and not a fuzzy identifier.


Fuzziness is useful!

The language theorists I've been talking with refer to
it as indexicality.  By this they mean that language is
MORE accurate when it captures some forms of ambiguity.
So in general I would argue that fuzziness of some form
needs to be embraced or allowed.  Or, going to the other
direction, I would suggest that it will be impossible
for us to construct CPE in a way that a) provides perfect
precision while b) also remaining useful.

Let me provide 2 observations/lessons learned from CVE and CCE...

1) The association between a CVE and known affected software
is ambiguous at best, changeable over time and ultimately
unknowable in any real sense.  CVE analysts work with vulnerability
information as soon as it is made public and often the
first reports are unclear.  The best CVE can do in the
time frames we opperate in is to make an ambiguous association
with affected software.  Natural language allows us to do
this in a way that captures some of the context that allows
other humans to figure out most of the truth.  

2) CCEs are, by their nature, somewhat ambiguous.
CCEs are defined at a level of abstraction ABOVE the
technical mechanisms at which they are set.  They very
much are a statement about a logical construct more
than they are a technically precise notion.  


I don't have enough experience with CPE yet to make any
suggestion about which of the 3 approaches would be best.

All I'm noting is that ambiguity is useful and unavoidable.

-Dave
==================================================================
David Mann     |   CVE Project Lead   |  The MITRE Corporation
------------------------------------------------------------------
     e-mail:[hidden email]    |      cell:781.424.6003
==================================================================

[Mann, Dave]

Peter Mell wrote:
> All of this said, the need to speak abstractly about groups of
> products is absolutely vital. Scott is right that we need to be able
> to talk about "all Windows" but Ken is also right that we need to be
> able to talk at the level of kernel names. There is no one right way
> to abstract Windows. Also, our abstraction method should generalize
> to all products and not be Windows specific.

Nor is there a single correct way to abstract configurations
or vulnerabilities.  

I think we need to understand that XCCDF-P and now CPE has
been more along the lines of a structured naming scheme.
Structured naming schemes all carry with them an implicit
classification scheme.  

The problem is just what Peter has identified... all
classification schemes, schemaa and taxonomies are best
suited for a small set of use cases and they don't work
well for others.  

This is why CVE and CCE have avoided codifying a single
categorization or classification scheme.  

Please note... it may be that CPE *must* be a naming
scheme.  Naming schemes produce human readable (somewhat)
names and true enumerations like CVE and CCE don't.  CCE-145
is meaningless to us all.

Just pointing out that since CPE is more of an expression
language (Common Platform Expression) than it will be
guaranteed to:
a) codify one and only one classification scheme
b) answer the needs of a small set of classification
   problems well
c) won't answer the needs of other classification
   problems well

Perhaps the best thing to do is to be at peace with
this and to pick the one that minimizes problems.

Please note... I'm not arguing that CPE should be
reduced to a pure enumeration.  I think people would
reject CPE-123 as the right way to refer to Windows XP.
And it doesn't solve the roll up and abstraction problem.


-Dave
==================================================================
David Mann     |   CVE Project Lead   |  The MITRE Corporation
------------------------------------------------------------------
     e-mail:[hidden email]    |      cell:781.424.6003
==================================================================

[Ken Lassesen-2]

Dave,

"And it doesn't solve the roll up and abstraction problem."


Actually this raises one of my concern...  Roll-up tend to imply
hierarchical and I do not think that is a safe assumption, or should I
say, assuming hierarchical will restrict it's applicability. Two
alternatives to hierarchical data structures are relational and
network...

Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

And it doesn't solve the roll up and abstraction problem.


-Dave
==================================================================
David Mann     |   CVE Project Lead   |  The MITRE Corporation
------------------------------------------------------------------
     e-mail:[hidden email]    |      cell:781.424.6003
==================================================================

[Peter M. Mell]

Drew,

It appears from your response that you didn't create cpe://microsoft:windows
as a method to abstract Windows OSs but instead you truly see 3.1, 95, NT,
XP, Server 2003, Vista, and Longhorn as all the same product with different
version numbers. If we are creating cpe://microsoft:windows for that
purpose, instead of trying to create an abstraction mechanism that only
works for "all Windows", then I'm personally okay with it. My main concern
is that we don't avoid the general abstraction problem by using a convenient
"shortcut" for abstracting Windows.

Peter

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, March 26, 2007 4:02 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Windows naming in CPE


>cpe://microsoft:windows_xp
>cpe://microsoft:windows_vista
>
>These match the form of RedHat and Sun products in the draft
>CPE dictionary
>
>cpe://redhat:enterprise_linux
>cpe://redhat:linux
>cpe://sun:sunos


I disagree.  I would argue that "redhat enterprise_linux 4" and
"microsoft windows vista" are both at the same level of abstraction.  I
see the terms NT/2000/XP/Vista as the different major versions of the
Windows OS (more specifically the Windows NT Kernel).

Thanks
Drew

[Wojcik, Matthew N.]

On Monday, March 26, 2007 Drew Buttner wrote:

> Would we be better off separating things out by kernel:
>
>  windows     (1.0, 2.0, 3.0, 3.1, 95, 98, ME)
>  windows-nt  (NT, 2000, XP, 2003, Vista)
>  windows-ce  (1.0, 2.0, 3.0 ...)
>
> This helps align things a little better with how technically
Microsoft
> develops things, but it does not align with how things have been
> marketed.  This would give us some pretty unintuitive names like
> cpe://microsoft:windows-nt:nt and cpe://microsoft:windows-nt:2000.
Of
> course the titles associated with each name would help clear up this
> confusion.  

Just to further complicate things, I have to point out that
"cpe://microsoft:windows-nt:nt" isn't really analagous to
"cpe://microsoft:windows-nt:2000".

The history of OS releases that were based on the NT kernel does not
proceed from Windows NT to Windows 2000; first there was Windows NT
3.1, then Windows NT 3.5, Windows NT 3.51, Windows NT Server 4.0, and
then the Windows 2000 variants.  The proposed name
"cpe://microsoft:windows-nt:nt" therefore actually lumps together a
larger and much more diverse set of versions than
"cpe://microsoft:windows-nt:2000".  Having such significant asymmetry
at one level of the hierarchy when considering only one vendor's OS
releases seems undesireable!

Since Windows NT 4.0 is more analagous to Windows 2000 or Windows XP,
etc., than just "Windows NT" is, we need to reflect that in the CPE
list.  We clearly don't want cpe://microsoft:windows-nt:nt:4.0 because
we've just trampled on the edition field.
cpe://microsoft:windows-nt:nt-4.0 looks weird.

cpe://microsoft:windows-nt:4.0 might work the best; we'd have versions
like 3.1, 3.5, 3.51, 4.0, 2000, xp, 2003, vista.  That definitely
means we'd need to use "windows-nt" instead of just "windows" in the
family field, though, or cpe://microsoft:windows:3.1 would be
ambiguous.  It also begs the question of whether we should use 5.0
instead of 2000, 5.1 instead of xp, etc.  (Though we've seen in OVAL
that breaks down too...).

I must say that I've never been a big fan of the hierarchy because it
gets us into exactly this swamp.  David Mann's observations on the
usefulness of fuzziness are also right on the mark.  We're also
fighting the fact that vendors have multiple ways of grouping their
own products--just look at how Microsoft's technical and marketing
arms differ on OS versions (again, Windows 2000 vs Windows NT 5.0).

I believe that no matter how we choose to construct our hierarchy, it
will break down under some use cases.  Relying on the hierarchy to
provide useful abstractions will only work if it was constructed with
your abstractions in mind.

--Woj                  Matthew N. Wojcik                 [hidden email]

A couple of useful references for Windows OS version history:

http://www.microsoft.com/windows/WinHistoryServer.mspx

http://en.wikipedia.org/wiki/Microsoft_Windows

[Andrew Buttner]

In an attempt to bring this thread on the naming of Windows platforms
back into focus and at least achieve resolution on how to proceed ...

The following points were made:

* avoid following public perception that is just marketing driven, make
sure we follow the technical rationales

* some amount of fuzziness is useful as perfect precision is impossible
and any inaccuracies will be sources of confusion

* naming scheme should allow wildcarding and roll-up so we can identify
general platform types like all Windows platforms, or we can be more
specific as needed

* the need to speak abstractly about groups of products is
absolutely vital

With those points taken into consideration, let's look at the current
specifications.  It defines the first three components of the OS part
as:

  {vendor}:{family}:{version}

For Windows, the name becomes 'cpe://microsoft:windows:xp'  Looking at
just these three components, I think the specification meets all the
points above.  We can roll up to 'cpe://microsoft:windows' if desired.
Yes, there are abstractions that can not be expressed, namely in
relation to the different kernels.  We can't specify a CPE Name for all
systems running a winnt kernel.  (Unless you group this in the
fuzziness category with cpe://microsoft:windows)

I think the biggest problem is what to do with the additional
components when naming Windows platforms.  How do we express SP2?  How
do we express Professional?  How do we express the Chinese version?
Microsoft follows a different pattern in naming than Cisco, which
follows a different pattern than Linux systems.  The specification
currently avoids these problems by leaving a lot of this undefined (ie
fuzzy) since we don't know how to deal with it.  Our goal is to fix
areas as we learn more.

We can't seem to find a common order to components.  CPE is in essence
a hierarchy and we know this really doesn't work.  But at the same
time, we can't figure out a better solution that provides a simple name
with roll-up and matching capabilities.  By matching capabilities, we
mean that one can deduce that a platform with a CPE Name
'cpe://microsoft:windows:vista' is also part of
'cpe://microsoft:windows'.  See the specification for more info on
matching.

Just a note, abstractions that don't follow the hierarchy break the
matching requirement of the specification.  For example, if we have a
name 'cpe://redhat:enterprise-linux:4' there is no way to know if is
part of 'cpe://linux' without additional information.

Do we try to stick with the current spec and do our best to force the
platforms into defined components?  Do we remove the matching
requirement and make better use of abstractions?  Do we try vendor
level hierarchies?  Any other ideas?

Currently, I lean toward trying to use the specification for a while
and gaining some more experience with the issues before making some
drastic changes.

Thoughts?  To keep some of this discussion under control, let's try to
start new treads as appropriate.

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Andrew Buttner]

I see the problem here.  There is currently no way to identify a
platform type that is all Linux OSs.  There are a lot of such
abstractions that could be needed.

Abstractions as you have proposed will not satisfy the matching
requirement of the specification.  Is this important?  Since we can't
currently identify all Linux OSs, we can't match against it either.  At
least an abstractions will give us part of the functionality desired.

I don't think we can use the same format for abstractions as users will
get confused.  If we say cpe://linux:linux:cpe_abstraction then some
might think of linux as a vendor name.

I want to think about this some today and get some ideas out to
everyone.  In the meantime, are there other ideas on this topic of
abstractions?

Thanks
Drew

>-----Original Message-----
>From: Peter Mell [mailto:[hidden email]]
>Sent: Monday, March 26, 2007 3:29 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] CPE Abstractions
>
>CPE SIG,
>
>Within the National Vulnerability Database we have been
>labelling CVEs with
>all applicable CPEs. In many cases we need to express that the
>vulnerability
>exists when application X is running on OS Y. This is particularly
>problematic when the application runs on every Linux OS. It would be
>difficult for my analysts to separately list every Linux OS (there are
>several hundred) for each CVE about a linux application.
>
>Thus, until CPE solves the abstraction problem, we have implemented a
>temporary solution. We create abstract CPE entries that map to
>the normal
>CPE entries. For example, we use a CPE called
>cpe://unix:unix:cpe_abstraction to refer to all Unix OSs.
>Likewise, we have
>a cpe://linux:linux:cpe_abstraction and we probably need a
>cpe:///microsoft:office:cpe_abstraction. Using this approach
>we then must
>define how each abstraction cpe maps to a set of normal CPEs. So far,
>thankfully, the abstractions that we have needed have been few
>in number.
>
>I'm not claiming that this is necessarily the best solution.
>It is simply
>what we have been forced to temporarily implement until this
>group decides
>on a proper abstraction capability.
>
>Peter
>
>-----Original Message-----
>From: Peter Mell [mailto:[hidden email]]
>Sent: Monday, March 26, 2007 3:18 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Windows naming in CPE
>
>
>This is an excellent recap of the sidebar discussions
>surrounding the naming
>of Windows. One additional point that I would like to mention
>is that the
>way the CPE specification names Windows products deviates from
>the CPE names
>for all other products. With all other products, the 2nd
>column of the CPE
>name represents a product name that is actually sold by a
>vendor. Only with
>Windows does CPE deviate in an attempt to allow people to talk
>about "all
>Windows" abstractly. Thus, to keep a uniform level for all
>CPEs, I believe
>that Windows OS entries should have the 2nd column be the
>product names as
>sold by Microsoft. This is not bowing to "public perception"
>but instead
>using the very names that vendors themselves give to their
>products. Using
>the names used by the vendors themselves is particularly
>important to me
>because I am in the process of providing a public data feed
>for all CVEs and
>CCEs labelled with CPEs. I believe the IT industry and software vendor
>community will expect me to use the names by which products are sold.
>
>All of this said, the need to speak abstractly about groups of
>products is
>absolutely vital. Scott is right that we need to be able to
>talk about "all
>Windows" but Ken is also right that we need to be able to talk
>at the level
>of kernel names. There is no one right way to abstract
>Windows. Also, our
>abstraction method should generalize to all products and not be

Windows
>specific. Note that the current Windows abstraction method
>will not work for
>any other abstraction. We should be able to concisely state, as Drew
>mentioned, "all Windows", "all Windows NT kernel", "all Unix OSs",
>"Microsoft Office"... We need a generic abstraction capability for
CPE.
>Until this is developed, I suggest that we limit CPE to the
>same level of
>abstraction (as is being done with CCE and has always been
>done for CVE).
>
>To bring this down to an implementation level. I suggest naming
Windows

>using the same model we use for other products (using the name
>used by the
>vendor to sell the product):
>
>cpe://microsoft:windows_xp
>cpe://microsoft:windows_vista
>
>These match the form of RedHat and Sun products in the draft
>CPE dictionary
>
>cpe://redhat:enterprise_linux
>cpe://redhat:linux
>cpe://sun:sunos
>
>Peter Mell
>National Vulnerability Database Program Manager
>http://nvd.nist.gov
>

[Andrew Buttner]

Another point I will add, is that one of the reasons for the hierarchy
type naming scheme is that it allows users to create new names
following the spec and not have to wait for those names to be
published.  At least that was the intention.

There are so many platform possibilities out there that we did not want
to create a bottleneck for users.  When they need a name for Vendor-A
Application-B, we want them to be able to create that name by following
the spec.

If we removed this desire, we could have names follow their own path,
using the best formula for the different components, while still
allowing roll-up and matching.  One OS might follow the
vendor:family:version:edition path, while another may user
vendor:version:language:release

Thanks
Drew

>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, April 09, 2007 8:28 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Windows naming in CPE
>
>In an attempt to bring this thread on the naming of Windows platforms
>back into focus and at least achieve resolution on how to proceed ...
>
>The following points were made:
>
>* avoid following public perception that is just marketing driven,

make
>sure we follow the technical rationales
>
>* some amount of fuzziness is useful as perfect precision is
impossible
>and any inaccuracies will be sources of confusion
>
>* naming scheme should allow wildcarding and roll-up so we can
identify

>general platform types like all Windows platforms, or we can be more
>specific as needed
>
>* the need to speak abstractly about groups of products is
>absolutely vital
>
>With those points taken into consideration, let's look at the current
>specifications.  It defines the first three components of the OS part
>as:
>
>  {vendor}:{family}:{version}
>
>For Windows, the name becomes 'cpe://microsoft:windows:xp'  Looking at
>just these three components, I think the specification meets all the
>points above.  We can roll up to 'cpe://microsoft:windows' if desired.
>Yes, there are abstractions that can not be expressed, namely in
>relation to the different kernels.  We can't specify a CPE Name for

all

>systems running a winnt kernel.  (Unless you group this in the
>fuzziness category with cpe://microsoft:windows)
>
>I think the biggest problem is what to do with the additional
>components when naming Windows platforms.  How do we express SP2?  How
>do we express Professional?  How do we express the Chinese version?
>Microsoft follows a different pattern in naming than Cisco, which
>follows a different pattern than Linux systems.  The specification
>currently avoids these problems by leaving a lot of this undefined (ie
>fuzzy) since we don't know how to deal with it.  Our goal is to fix
>areas as we learn more.
>
>We can't seem to find a common order to components.  CPE is in essence
>a hierarchy and we know this really doesn't work.  But at the same
>time, we can't figure out a better solution that provides a simple

name

>with roll-up and matching capabilities.  By matching capabilities, we
>mean that one can deduce that a platform with a CPE Name
>'cpe://microsoft:windows:vista' is also part of
>'cpe://microsoft:windows'.  See the specification for more info on
>matching.
>
>Just a note, abstractions that don't follow the hierarchy break the
>matching requirement of the specification.  For example, if we have a
>name 'cpe://redhat:enterprise-linux:4' there is no way to know if is
>part of 'cpe://linux' without additional information.
>
>Do we try to stick with the current spec and do our best to force the
>platforms into defined components?  Do we remove the matching
>requirement and make better use of abstractions?  Do we try vendor
>level hierarchies?  Any other ideas?
>
>Currently, I lean toward trying to use the specification for a while
>and gaining some more experience with the issues before making some
>drastic changes.
>
>Thoughts?  To keep some of this discussion under control, let's try to
>start new treads as appropriate.
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515
>

[Ken Lassesen-2]

Approaching the issues from a slightly different angle...

1) At the hardward level, there commonality between all of the OS's, so
to grab the low hanging fruit, that portion of the CPE should be seized
and can be executed. (thus x64 or x32 or .... Hardware-based OS-dialects
could be isolated from the OS). Call this LEVEL1
2) At the next level up we have the HAL and then the kernel. These tend
to be the same between SP's (and sometimes across versions). Call this
LEVEL2
3) In the Windows environment, for many products, the code is identical
-- it is just the registry settings or other keys that enable or disable
features in the product. The enable/disabling is not always cummative.
Product 1 may have a,b,c; Product 2 may have a,c,d; Product 3 may have
a,b,c,d,e. At this point we may wish to have alphabetically ordered
n-tuples
To give a real example (not alphabetic ordered):
 i.e.
        Vista,
        Vista{Aero,Tablet,MeetingSpace,Business },
        Vista{Aero,Tablet,MeetingSpace,MediaCenter,XBox },
        Vista{Aero,Tablet,MeetingSpace,MediaCenter,Business,
Xbox,BitLocker }
Of course, you see that we are now entering a relational world.

We could have these items NESTED...
        Vista{Aero,Tablet,MeetingSpace,Business{Remote Desktop} },
        Vista{Aero,Tablet,MeetingSpace,Business{BackUp} },

I recall writing ages ago on one of these lists that I would prefer to
see every optional install/optional component broken out seperately,
thus:
        WinXP  -No Windows Components installed at all
        WinXP{IE}
        WinXP{IE,IIS)
        WinXP{IE,IIS {Common,FTP,SMTP})
        WinXP{IE,IIS {Common,FTP,SMTP,WWS})
        WinXP{IE,IIS {Common,FTP,SMTP,WWS:5.1})
        WinXP{IE,IIS {Common,FTP,SMTP,WWS:5.0}) -- yes, this is
possible.

So if a product depends on a specific component, then using a | 'subject
to' may reduce some of the data length.

        WinXP{IIS {WWS:5.0})|FooBar

The presence of the | decouples it from a hierarchy and ties it to the
cross-OS-versions components that determines it's installation.

In short, there may be distinct advantage to increase the symbol set
from (':') to something like (':','|','{}') or even more operators. What
we would be doing is converting the CPE from a pure
identifier/enumeration to a CPL (i.e. Language). The language would be
low structure, akin to Reverse Polish Notation or FORTH.

I think it would be more expressive and likely deal with every concern
raised.  It is however a change from an enumeration to a symbolic
language.

Comments??

       




Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

[Andrew Buttner]

Related to this, is the idea to completely remove the notion of
mandating a component to be of a certain type of information.  For
example, the specification would not say that the first component has
to be vendor, or the third component has to be version, etc.  This
would allow names to be created that correspond to the exact platform
being described without trying to fit this to an existing hierarchy,
and vendors could use their own rules for the ordering of components.

Of course the downside is that without the specification of defined
components, names could be made that mean the same thing, have the same
components, but all in different order.  For example
cpe://microsoft:windows:xp:pro:sp3 and
cpe://microsoft:windows:xp:sp3:pro  Of course we already have this
problem since we can create a hierarchy deep enough to cover all these
fields.  We would mitigate this (in the absence of vendor
participation) by having the dictionary be the official place of
deconfliction in that it would choose the official name.

Matching could still take place by looking for commonality between the
supplied components.  I think the algorithm would stay exactly the
same.  The only loss in the proposal would be in knowing what third
component in a name represents.  But I don't think this information is
what is important to tools.  They are more concerned with correctly
determining if a CPE Name matches a given system.  Is this a correct
assumption?  The gain would be the ability easily name a wider variety
of platforms without running into the problems of a hierarchy.

To summarize, we could modify CPE to say:

* Elements of a Part are made up of some number of components separated
by semi-colons.

* There is no set meaning to the position of each component

* A CPE name is only official once it is added to the dictionary

* The specification gives guidelines for creating components (when to
abbreviate, etc.) and how to create full CPE names but does not define
a hierarchy


The upside of all this is that it would become easier to create CPE
Names as we would not be bound to an attempted hierarchy.  We could
create names for Cisco according to their naming scheme, and then
create names for windows according to Microsoft's scheme.

Thanks
Drew

>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, April 09, 2007 8:44 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] On the fly creation
>
>Another point I will add, is that one of the reasons for the hierarchy
>type naming scheme is that it allows users to create new names
>following the spec and not have to wait for those names to be
>published.  At least that was the intention.
>
>There are so many platform possibilities out there that we did not

want
>to create a bottleneck for users.  When they need a name for Vendor-A
>Application-B, we want them to be able to create that name by
following

>the spec.
>
>If we removed this desire, we could have names follow their own path,
>using the best formula for the different components, while still
>allowing roll-up and matching.  One OS might follow the
>vendor:family:version:edition path, while another may user
>vendor:version:language:release
>
>Thanks
>Drew
>
>
>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Monday, April 09, 2007 8:28 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] Windows naming in CPE
>>
>>In an attempt to bring this thread on the naming of Windows platforms
>>back into focus and at least achieve resolution on how to proceed ...
>>
>>The following points were made:
>>
>>* avoid following public perception that is just marketing driven,
>make
>>sure we follow the technical rationales
>>
>>* some amount of fuzziness is useful as perfect precision is
>impossible
>>and any inaccuracies will be sources of confusion
>>
>>* naming scheme should allow wildcarding and roll-up so we can
>identify
>>general platform types like all Windows platforms, or we can be more
>>specific as needed
>>
>>* the need to speak abstractly about groups of products is
>>absolutely vital
>>
>>With those points taken into consideration, let's look at the current
>>specifications.  It defines the first three components of the OS part
>>as:
>>
>>  {vendor}:{family}:{version}
>>
>>For Windows, the name becomes 'cpe://microsoft:windows:xp'  Looking

at
>>just these three components, I think the specification meets all the
>>points above.  We can roll up to 'cpe://microsoft:windows' if
desired.
>>Yes, there are abstractions that can not be expressed, namely in
>>relation to the different kernels.  We can't specify a CPE Name for
>all
>>systems running a winnt kernel.  (Unless you group this in the
>>fuzziness category with cpe://microsoft:windows)
>>
>>I think the biggest problem is what to do with the additional
>>components when naming Windows platforms.  How do we express SP2?
How
>>do we express Professional?  How do we express the Chinese version?
>>Microsoft follows a different pattern in naming than Cisco, which
>>follows a different pattern than Linux systems.  The specification
>>currently avoids these problems by leaving a lot of this undefined
(ie
>>fuzzy) since we don't know how to deal with it.  Our goal is to fix
>>areas as we learn more.
>>
>>We can't seem to find a common order to components.  CPE is in
essence

>>a hierarchy and we know this really doesn't work.  But at the same
>>time, we can't figure out a better solution that provides a simple
>name
>>with roll-up and matching capabilities.  By matching capabilities, we
>>mean that one can deduce that a platform with a CPE Name
>>'cpe://microsoft:windows:vista' is also part of
>>'cpe://microsoft:windows'.  See the specification for more info on
>>matching.
>>
>>Just a note, abstractions that don't follow the hierarchy break the
>>matching requirement of the specification.  For example, if we have a
>>name 'cpe://redhat:enterprise-linux:4' there is no way to know if is
>>part of 'cpe://linux' without additional information.
>>
>>Do we try to stick with the current spec and do our best to force the
>>platforms into defined components?  Do we remove the matching
>>requirement and make better use of abstractions?  Do we try vendor
>>level hierarchies?  Any other ideas?
>>
>>Currently, I lean toward trying to use the specification for a while
>>and gaining some more experience with the issues before making some
>>drastic changes.
>>
>>Thoughts?  To keep some of this discussion under control, let's try

to

>>start new treads as appropriate.
>>
>>---------
>>
>>Andrew Buttner
>>The MITRE Corporation
>>[hidden email]
>>781-271-3515
>>
>

[Ken Lassesen-2]

That is my thinking -- I've been reflecting on this a little longer on
this and looking at what CPE stands for,  

I would love to see (it may already be there) for unique identifiers for
any part of any name, i.e. a unique name for a specific product would
never have name-space collision [thus an Enumeration]. This name may
apply across versions and platforms, for example

        "Word" is Microsoft Word (regardless of whether it is MacOS or
Windows)

In many cases, a product may change name several times and in some cases
either fragment or be combined --- so this is likely just wishful
dreaming for the name to persist for a long duration.

The ideal unique identifier should likely be by TradeMark Name (if there
is one), then common name , etc.

This would support on the fly naming, so we would need a structure for
nesting and for versions, i.e.

   Gizmo{Addin1,Addin2 @ 4.0,6.5}

That is Gizmo with two specific addin installed (i.e. an interaction
problem) for Gizmo versions 4.0 thru (and including) 6.5.

This pattern seems flexible i.e.
   Gizmo{Addin1,Addin2{@ 2.0,2.9} @ 4.0,6.5}
Would indicate that it applies only if the Addin2 is between versions
2.0 and 2.9

The test would be to sketch out a grammar and then see if all of the
worst case/boundary conditions can be expressed well...


Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Thursday, April 12, 2007 10:57 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] On the fly creation

Related to this, is the idea to completely remove the notion of
mandating a component to be of a certain type of information.  For
example, the specification would not say that the first component has to
be vendor, or the third component has to be version, etc.  This would
allow names to be created that correspond to the exact platform being
described without trying to fit this to an existing hierarchy, and
vendors could use their own rules for the ordering of components.

Of course the downside is that without the specification of defined
components, names could be made that mean the same thing, have the same
components, but all in different order.  For example
cpe://microsoft:windows:xp:pro:sp3 and
cpe://microsoft:windows:xp:sp3:pro  Of course we already have this
problem since we can create a hierarchy deep enough to cover all these
fields.  We would mitigate this (in the absence of vendor
participation) by having the dictionary be the official place of
deconfliction in that it would choose the official name.

Matching could still take place by looking for commonality between the
supplied components.  I think the algorithm would stay exactly the same.
The only loss in the proposal would be in knowing what third component
in a name represents.  But I don't think this information is what is
important to tools.  They are more concerned with correctly determining
if a CPE Name matches a given system.  Is this a correct assumption?
The gain would be the ability easily name a wider variety of platforms
without running into the problems of a hierarchy.

To summarize, we could modify CPE to say:

* Elements of a Part are made up of some number of components separated
by semi-colons.

* There is no set meaning to the position of each component

* A CPE name is only official once it is added to the dictionary

* The specification gives guidelines for creating components (when to
abbreviate, etc.) and how to create full CPE names but does not define a
hierarchy


The upside of all this is that it would become easier to create CPE
Names as we would not be bound to an attempted hierarchy.  We could
create names for Cisco according to their naming scheme, and then create
names for windows according to Microsoft's scheme.

Thanks
Drew

>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, April 09, 2007 8:44 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] On the fly creation
>
>Another point I will add, is that one of the reasons for the hierarchy
>type naming scheme is that it allows users to create new names
>following the spec and not have to wait for those names to be
>published.  At least that was the intention.
>
>There are so many platform possibilities out there that we did not

want
>to create a bottleneck for users.  When they need a name for Vendor-A
>Application-B, we want them to be able to create that name by
following

>the spec.
>
>If we removed this desire, we could have names follow their own path,
>using the best formula for the different components, while still
>allowing roll-up and matching.  One OS might follow the
>vendor:family:version:edition path, while another may user
>vendor:version:language:release
>
>Thanks
>Drew
>
>
>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Monday, April 09, 2007 8:28 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] Windows naming in CPE
>>
>>In an attempt to bring this thread on the naming of Windows platforms
>>back into focus and at least achieve resolution on how to proceed ...
>>
>>The following points were made:
>>
>>* avoid following public perception that is just marketing driven,
>make
>>sure we follow the technical rationales
>>
>>* some amount of fuzziness is useful as perfect precision is
>impossible
>>and any inaccuracies will be sources of confusion
>>
>>* naming scheme should allow wildcarding and roll-up so we can
>identify
>>general platform types like all Windows platforms, or we can be more
>>specific as needed
>>
>>* the need to speak abstractly about groups of products is absolutely
>>vital
>>
>>With those points taken into consideration, let's look at the current
>>specifications.  It defines the first three components of the OS part
>>as:
>>
>>  {vendor}:{family}:{version}
>>
>>For Windows, the name becomes 'cpe://microsoft:windows:xp'  Looking

at
>>just these three components, I think the specification meets all the
>>points above.  We can roll up to 'cpe://microsoft:windows' if
desired.
>>Yes, there are abstractions that can not be expressed, namely in
>>relation to the different kernels.  We can't specify a CPE Name for
>all
>>systems running a winnt kernel.  (Unless you group this in the
>>fuzziness category with cpe://microsoft:windows)
>>
>>I think the biggest problem is what to do with the additional
>>components when naming Windows platforms.  How do we express SP2?
How
>>do we express Professional?  How do we express the Chinese version?
>>Microsoft follows a different pattern in naming than Cisco, which
>>follows a different pattern than Linux systems.  The specification
>>currently avoids these problems by leaving a lot of this undefined
(ie
>>fuzzy) since we don't know how to deal with it.  Our goal is to fix
>>areas as we learn more.
>>
>>We can't seem to find a common order to components.  CPE is in
essence

>>a hierarchy and we know this really doesn't work.  But at the same
>>time, we can't figure out a better solution that provides a simple
>name
>>with roll-up and matching capabilities.  By matching capabilities, we
>>mean that one can deduce that a platform with a CPE Name
>>'cpe://microsoft:windows:vista' is also part of
>>'cpe://microsoft:windows'.  See the specification for more info on
>>matching.
>>
>>Just a note, abstractions that don't follow the hierarchy break the
>>matching requirement of the specification.  For example, if we have a
>>name 'cpe://redhat:enterprise-linux:4' there is no way to know if is
>>part of 'cpe://linux' without additional information.
>>
>>Do we try to stick with the current spec and do our best to force the
>>platforms into defined components?  Do we remove the matching
>>requirement and make better use of abstractions?  Do we try vendor
>>level hierarchies?  Any other ideas?
>>
>>Currently, I lean toward trying to use the specification for a while
>>and gaining some more experience with the issues before making some
>>drastic changes.
>>
>>Thoughts?  To keep some of this discussion under control, let's try

to

>>start new treads as appropriate.
>>
>>---------
>>
>>Andrew Buttner
>>The MITRE Corporation
>>[hidden email]
>>781-271-3515
>>
>

[Andrew Buttner]

>This would support on the fly naming, so we would need a structure for
>nesting and for versions, i.e.
>
>   Gizmo{Addin1,Addin2 @ 4.0,6.5}
>
>That is Gizmo with two specific addin installed (i.e. an interaction
>problem) for Gizmo versions 4.0 thru (and including) 6.5.


The CPE spec does already have this with the use of ! to represent OR.
For example cpe://microsoft:windows:xp!vista

Version info is held in its own component.

[Wolfkiel, Joseph]

So we've been thinking along the same lines here at NSA/I7 (not necessarily
everywhere in NSA).

I think there should be an acknowledgement that the names in CPE won't be
unique, so it would be helpful to have names bound to a unique identifier.
That way, you could different the "SP2" in Office 97 from the "SP2" for
Windows XP.  You could also change the text when it becomes appropriate e.g
when TimeStep was bought by Alcatel, the name was changed, though the
manufacturer stayed the same.  If you used a unique identifier for the
hardware, you could still tell that a TimeStep VPN and an Alcatel VPN are
the same product, even though the name is now Alcatel.


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: Ken Lassesen [mailto:[hidden email]]
Sent: Thursday, April 12, 2007 3:13 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] On the fly creation


That is my thinking -- I've been reflecting on this a little longer on
this and looking at what CPE stands for,  

I would love to see (it may already be there) for unique identifiers for
any part of any name, i.e. a unique name for a specific product would
never have name-space collision [thus an Enumeration]. This name may
apply across versions and platforms, for example

        "Word" is Microsoft Word (regardless of whether it is MacOS or
Windows)

In many cases, a product may change name several times and in some cases
either fragment or be combined --- so this is likely just wishful
dreaming for the name to persist for a long duration.

The ideal unique identifier should likely be by TradeMark Name (if there
is one), then common name , etc.

This would support on the fly naming, so we would need a structure for
nesting and for versions, i.e.

   Gizmo{Addin1,Addin2 @ 4.0,6.5}

That is Gizmo with two specific addin installed (i.e. an interaction
problem) for Gizmo versions 4.0 thru (and including) 6.5.

This pattern seems flexible i.e.
   Gizmo{Addin1,Addin2{@ 2.0,2.9} @ 4.0,6.5}
Would indicate that it applies only if the Addin2 is between versions
2.0 and 2.9

The test would be to sketch out a grammar and then see if all of the
worst case/boundary conditions can be expressed well...


Ken Lassesen,
HomeOffice: 360-297-4717   Cell: 360-509-2402  Fax: [phone]
IM: [hidden email]  [hidden email]
mailto:[hidden email]
CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Thursday, April 12, 2007 10:57 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] On the fly creation

Related to this, is the idea to completely remove the notion of
mandating a component to be of a certain type of information.  For
example, the specification would not say that the first component has to
be vendor, or the third component has to be version, etc.  This would
allow names to be created that correspond to the exact platform being
described without trying to fit this to an existing hierarchy, and
vendors could use their own rules for the ordering of components.

Of course the downside is that without the specification of defined
components, names could be made that mean the same thing, have the same
components, but all in different order.  For example
cpe://microsoft:windows:xp:pro:sp3 and
cpe://microsoft:windows:xp:sp3:pro  Of course we already have this
problem since we can create a hierarchy deep enough to cover all these
fields.  We would mitigate this (in the absence of vendor
participation) by having the dictionary be the official place of
deconfliction in that it would choose the official name.

Matching could still take place by looking for commonality between the
supplied components.  I think the algorithm would stay exactly the same.
The only loss in the proposal would be in knowing what third component
in a name represents.  But I don't think this information is what is
important to tools.  They are more concerned with correctly determining
if a CPE Name matches a given system.  Is this a correct assumption?
The gain would be the ability easily name a wider variety of platforms
without running into the problems of a hierarchy.

To summarize, we could modify CPE to say:

* Elements of a Part are made up of some number of components separated
by semi-colons.

* There is no set meaning to the position of each component

* A CPE name is only official once it is added to the dictionary

* The specification gives guidelines for creating components (when to
abbreviate, etc.) and how to create full CPE names but does not define a
hierarchy


The upside of all this is that it would become easier to create CPE
Names as we would not be bound to an attempted hierarchy.  We could
create names for Cisco according to their naming scheme, and then create
names for windows according to Microsoft's scheme.

Thanks
Drew

>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, April 09, 2007 8:44 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] On the fly creation
>
>Another point I will add, is that one of the reasons for the hierarchy
>type naming scheme is that it allows users to create new names
>following the spec and not have to wait for those names to be
>published.  At least that was the intention.
>
>There are so many platform possibilities out there that we did not

want
>to create a bottleneck for users.  When they need a name for Vendor-A
>Application-B, we want them to be able to create that name by
following

>the spec.
>
>If we removed this desire, we could have names follow their own path,
>using the best formula for the different components, while still
>allowing roll-up and matching.  One OS might follow the
>vendor:family:version:edition path, while another may user
>vendor:version:language:release
>
>Thanks
>Drew
>
>
>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:[hidden email]]
>>Sent: Monday, April 09, 2007 8:28 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] Windows naming in CPE
>>
>>In an attempt to bring this thread on the naming of Windows platforms
>>back into focus and at least achieve resolution on how to proceed ...
>>
>>The following points were made:
>>
>>* avoid following public perception that is just marketing driven,
>make
>>sure we follow the technical rationales
>>
>>* some amount of fuzziness is useful as perfect precision is
>impossible
>>and any inaccuracies will be sources of confusion
>>
>>* naming scheme should allow wildcarding and roll-up so we can
>identify
>>general platform types like all Windows platforms, or we can be more
>>specific as needed
>>
>>* the need to speak abstractly about groups of products is absolutely
>>vital
>>
>>With those points taken into consideration, let's look at the current
>>specifications.  It defines the first three components of the OS part
>>as:
>>
>>  {vendor}:{family}:{version}
>>
>>For Windows, the name becomes 'cpe://microsoft:windows:xp'  Looking

at
>>just these three components, I think the specification meets all the
>>points above.  We can roll up to 'cpe://microsoft:windows' if
desired.
>>Yes, there are abstractions that can not be expressed, namely in
>>relation to the different kernels.  We can't specify a CPE Name for
>all
>>systems running a winnt kernel.  (Unless you group this in the
>>fuzziness category with cpe://microsoft:windows)
>>
>>I think the biggest problem is what to do with the additional
>>components when naming Windows platforms.  How do we express SP2?
How
>>do we express Professional?  How do we express the Chinese version?
>>Microsoft follows a different pattern in naming than Cisco, which
>>follows a different pattern than Linux systems.  The specification
>>currently avoids these problems by leaving a lot of this undefined
(ie
>>fuzzy) since we don't know how to deal with it.  Our goal is to fix
>>areas as we learn more.
>>
>>We can't seem to find a common order to components.  CPE is in
essence

>>a hierarchy and we know this really doesn't work.  But at the same
>>time, we can't figure out a better solution that provides a simple
>name
>>with roll-up and matching capabilities.  By matching capabilities, we
>>mean that one can deduce that a platform with a CPE Name
>>'cpe://microsoft:windows:vista' is also part of
>>'cpe://microsoft:windows'.  See the specification for more info on
>>matching.
>>
>>Just a note, abstractions that don't follow the hierarchy break the
>>matching requirement of the specification.  For example, if we have a
>>name 'cpe://redhat:enterprise-linux:4' there is no way to know if is
>>part of 'cpe://linux' without additional information.
>>
>>Do we try to stick with the current spec and do our best to force the
>>platforms into defined components?  Do we remove the matching
>>requirement and make better use of abstractions?  Do we try vendor
>>level hierarchies?  Any other ideas?
>>
>>Currently, I lean toward trying to use the specification for a while
>>and gaining some more experience with the issues before making some
>>drastic changes.
>>
>>Thoughts?  To keep some of this discussion under control, let's try

to

>>start new treads as appropriate.
>>
>>---------
>>
>>Andrew Buttner
>>The MITRE Corporation
>>[hidden email]
>>781-271-3515
>>
>

[Andrew Buttner]

>I would love to see (it may already be there) for unique
>identifiers for
>any part of any name, i.e. a unique name for a specific product would
>never have name-space collision [thus an Enumeration]. This name may
>apply across versions and platforms, for example
>
> "Word" is Microsoft Word (regardless of whether it is MacOS or
>Windows)

I agree, I don't think this requires much of a change from the current
spec.  More just a change in how we think of things.  In a way, each
value that we have been assigning to a component acts in this way.  But
we haven't thought of them as unique in their own right.

Drew