CPE values for generic systems

[Ernest Park-2]

Hi Kent -

 

Well stated, and I agree. A comment below . . .

On Fri, Aug 15, 2008 at 4:28 PM, Kent Landfield <[hidden email]> wrote:

:-) I guess I was one of them…

 

I really look at the component standards in different ways that might be useful to consider… I don't want component standards to serve one master…

 

CPE is a standalone standard for exchanging structured naming information. This information can be used between products as in passing system information to another application. This assures the applications can "speak the same language" and know what the type of system the target was to the level of specificity passed.  CPE can be used in databases to relate "Affected Platforms" and system information in a consistent way.  CPEs can also be used to stitch the other five component standards that make up SCAP together.  This allows XCCDF and maybe one day OVAL to target checking to the indicated platforms.

 

CPE came about because of a problem that occurred during the initial OVAL certification testing when two seemingly OVAL compatible products could not exchange system information. One called it Win2k and the other called it Windows 2000 Professional. When the system ID tables were updated to reflect the same system representation, everything worked as expected…  The need to properly exchange a standard representation of a system name (as we know it for this thread) was born, grew into XCCDF-P and morphed into CPE. This was not SCAP centered; this is structured system naming centered. How it is applied is dependent on the usage. CPE should not be developed solely for a single use case.  We could have done that with CVE nine years ago but we did not. We wanted it to be generic, simple and not targeted at a specific usage.  I'd call CVE a success today considering its wide ranging usage.  A usage I might make clear is far beyond what it was initially considered and targeted for.  If we had not taken the simple approach, it would not have found its way into as many security products, databases, and alert communications and inter-applications uses as it has.  We need CPE to be robust but at the same time not target it towards a single use case.  

 

What started this conversation was a request to add a few entries to the CPE dictionary that would allow applications to exchange a state of "unknown" to another application or consumer in CPE format.  CPE needs that ability in the dictionary as a natural extension for inter-application / product communications of structured naming information. This is not inconsistent with CPE and its usage.

 

COMMENT: If an entry is resolved to a NULL between delimiters, such as cpe:/a: :, that in itself provides that you have an app, but you can't determine more than that. While it is a simple case, if we try to move the data description to handle exceptions, rather than those being handled by an app, we inadvertently start to have to build an error handling language. Today, we want to add an unknown, although the absence of a result is implicitly unknown.

 

In the phone book, they list only names that can be resolved to numbers. They don't list the "unlisted" entries.

 

 

I suggest that an incomplete name resolution is programmatically handled based on the situation that generated that unknown value. "unknown" is an exception handling value that should be embedded in an application.

 

I do agree that we may want to settle on standard error and exception language (like a "404"), and that we agree on a basic alias syntax. In that way, while I feel that "cpe:/a::" tells me that I don't know the vendor, you can alias "::" for "unknown" within your app. We may agree that there needs to be aliased language, such that a "::" is insufficient. If that is the case, then we need that alias structure, and the "reserved" error names.

 

Keeping it simple has succeeded in the past. Let's not complicate it.

 

--

Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

 

---

From: Tim Keanini [mailto:[hidden email]]

Sent: Friday, August 15, 2008 2:26 PM

To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

Kent, as you point out, the original subject matter was branched as indicated by the subject line but not everyone made the jump.

 

My post was directed at Dave Mann's comments and I hope nothing in my post suggested that I was calling CPE a discovery tool – I was simply pointing out a relationship that supported Dave's hunch that  based on CPE's origin and SCAP market drivers, the CREDENTIALED END POINT MANAGEMENT mindset is dominant. 

 

To sum it up:  CPE's primary objective is to meet the needs of SCAP and the Federal market it serves.   You can only have one primary objective so if any decision being made on this list compromises the primary objective, it is not valid.  If CPE's primary objective is to serve many different markets, then we have a much different set of requirements.

 

 

--tk

 

From: Kent Landfield [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:44 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

I think the initial request was a way to report unknown information in CPE format for exchanging information between products.  I don't think the original requestor said they wanted to use CPE as discovery tool.  I agree with Joe that we need to have a means to do this if CPE is going to be used as a means to convey information about systems between differing security and network products.  This really was a simple request so that proprietary info did not need to be used and agreed on between products.

 

--

Kent Landfield
Director, Risk and Compliance Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 214.385.1138 Mobile
[hidden email]
www.mcafee.com

 

---

From: Wolfkiel, Joseph [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:13 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

For what it's worth, I'm working in the DoD requirements community and, if I'm successful, you will have at least one potential customer who will say "Provide your platform discovery data in CPE or we'll buy something else."

 

Certainly the OMB memos guiding Federal acquisitions that mandate SCAP compliance will move all the Federal Government toward CPE compliance.

 

I've already started the process of rebuilding at least one of our internally-built tools to speak CPE.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]

-----Original Message-----
From: Ernest Park [mailto:[hidden email]]
Sent: Friday, August 15, 2008 1:45 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

CPE is NOT a discovery mechanism. There are commercial and open source solutions that are readily available to do this. CPE allows us to insist on compliance to a standard for the output format for that automated discovery. How can CPE now try to automatically resolve unknown elements from the software world.  A number of companies for which members of this thread work are in the business of electronic scanning and discovery, inclusive of my employer.

 

What we need to ask for as a community is not to reinvent the wheel, but to make sure that the wheels fit tires of standard specification. If we insist that "discovery" tools output CPE compliant names as part of an inventory report, then we have acheived a milestone. That CPE output from commerically available data can then be used in other commercially available software without an API. I believe that it is the goal of interoperability with standardized names that allows us as a community to use best of breed solutions to manage all parts of our electronic infrastructure without pushing vendors to build customized integrations.

 

How nice would it be if I could take the discovery report from vendor A, input it into the policy management tool of vendor B, and use the same list for the inventory tracker of vendor C?

 

 

Regarding the rant, there is a linear relationship and a very limited hierarchy represented by a CPE name, just like phone number segments denote some hierarchy and relationship <XXX-YYY-ZZZZ>. XXX might denote a high level geographic location, YYY fine tunes it more, and ZZZZ is specific to a location within the hierarchy.

 

In CPE, there should be no more implied relationship than that. We do have the concept of parts, where the URI itself allows some additional sorting, but the name itself is not a database, and further data sorting and categorizing should be done at a level beyond the name, within specialized applications that do that.

 

Remember, if we ask a list to be a database, it constrains the list. The commercial market can add attributes and distinct data elements to the list, thereby evolving a database. The commercial market can build functionality integrating support for the list, such list that can then be used to collect database information from elsewhere.

 

The commercial vendor for whom I work lacks confidence in the need to support CPE. No customer has said - we have a CPE inventory manager. We need your scanner and policy tools to "talk CPE". When we as a community agree that this is a key and fundamental success of CPE, and when the consumer market realizes that interoperability of these distinct tools and datasources may be as close as common naming elements, then the rest of these discussions will become less relevant.

 

Lets insist that CPE compliance means the ability to respond to a formatted CPE query into XML, a database, or a structured datasource, such that the datasource needs minimally to contain certain key CPE elements, under which any number of additional public and proprietary attributes can be added. 

 

 

 

On Fri, Aug 15, 2008 at 1:22 PM, Tim Keanini <[hidden email]> wrote:

Dave,
This is valuable research and hope that there is some report of your
interviews published to other SCAP related working groups.  I know there
maybe some sensitivity to disclosure but a nice summary like the one
below would be helpful to other working groups.  All working groups
under the SCAP umbrella are dealing with similar issues.

I have always felt that CPE design proposals were biased toward
CREDENTIALED END POINT MANAGEMENT because of OVAL's credentialed view of
the world.  If we believe that automated discovery is a necessary part
of the SCAP program then OVAL will influence CPE and vice-versa.  If
this meets the requirements for SCAP, great.  If not, we will either
have to modify the design of the standard or modify the requirements but
let's just pray that somewhere there is a set of requirements that are
true to the needs of SCAP.  In other words, let's hope that this
CREDENTIALED END POINT MANAGEMENT bias satisfies the requirements of
SCAP.  Personally I have been disappointed at this requirements
gathering process and I think I speak for most commercial vendors in
expressing this frustration.

<TK rant>
The fundamental technical issue is that we are being asked to model a
space that is without question a graph.  It is a graph with many types
of nodes but more importantly, many types of relationships (certainly
more than is-member-of) and this lack of relationship types will stand
in the way of any real progress IMHO.  An example of the current state:
Each party brings their own centricity (their own root class) to the
discussion rendering a manifestation of the graph and then presents that
rendition as what we all should use. Other parties do the same and we
spin our wheels arguing about rendered hierarchies that have a
disproportionate amount of utility for one community at the expense of
another; when really we are talking about the same darn graph.  Who is
working on this graph-based model?  No one because in order for it to
succeed, we all have to be able to contribute without compromise to one
another.  The current model and political structures stand in the way of
this progress.
</TK rant>

--tk

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 8:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
>       During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
 for identifications starts with IP and climbs the network
 stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
 audit, end point management and asset inventory tools.
 Sees "platforms" as "units of management".   Typically
 needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
 and vulnerability analysis.  Typically views platforms
 and applications as a part of shipping OS.  Needs to identify
 system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
 and their customrs.  Sees "platforms" in terms of development
 efforts with requirements, schedules, gold dates, licenses
 and inventory numbers.  Must deal with suite and components
 issues (e.g. Office vs Word, what is "Tivioli"?).  This view
 may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
    [hidden email]    |      cell:781.424.6003
=================================================================

 

[Tim Keanini]

David,
I'm doing my best to understand how these objects relate to one another.
Component(s):
Product(s):
Abstract-Product(s):
System(s):
Platform(s):

* What is the smallest most atomic unit in the CPE world?

* In the description you use below, it seems that both Abstract-Product
and System have Products as members?

I'm looking for something like a BNF or railroad diagram of terms.

--tk


-----Original Message-----
From: David Waltermire [mailto:[hidden email]]
Sent: Friday, August 15, 2008 11:37 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

All,

A fundamental disagreement within the CPE community is the notion of
"platform" and "product".  I would define these terms as follows:

Platform - a collection of software and hardware products that define
one or
more systems.

System - A discrete collection of products that together represent a
functional unit of operational capability.  For example: a server,
workstation, network device, etc.

Product - A discrete unit of software or hardware that can be purchased
downloaded, installed, configured and/or licensed.  A product may
consist of
multiple components.

Abstract Product - A reference to a group of products

Component - A unit of function which may be one or more shared
libraries,
configuration files, executables, scripts, compiled code, etc.

Like Sheldon I am also concerned about throwing the baby out with the
bath
water.  One of the primary reasons for an enumeration standard such as
CPE
is that information about products needs to be shared between the
various
use cases in a use case agnostic way.  For example the result of a
network
scan would feed into an asset management tool to populate known assets
or
discover unknown assets, and the asset management information would feed
into a vulnerability management tool to discover what vulnerabilities
exists
for a given set of assets.  I believe a source of our problem is the
level
of abstraction we are choosing to think about CPEs.  An earlier thread
on
this list
(http://n2.nabble.com/Abstract-and-Concrete-CPE-Names-in-the-Dictionary-
tt88
234.html) also discussed this issue, with no final resolution.  I would
suggest that CPE attempt to define the most granular pieces of
information
necessary to identify a product, while specifying a mechanism for
referencing or querying collections of products.  Taking this approach
would
allow each of the use cases to interact with CPEs at their preferred
level
of abstraction, while encouraging interoperability amongst the various
use
cases.

I see the CPE language as the means through which products are joined
together to create platforms.  The CPE language construct is a powerful
mechanism to bridge the gap between product and platform levels of
abstraction.

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
  for identifications starts with IP and climbs the network
  stack model to try to discover "platforms".

Requires discrete and abstract product references:

Part of climbing up the stack is identifying meta information about
products
that are responding to requests.  In unauthenticated scenarios
protocols,
behaviors, and banners are examined to determine facts about the system
and
its constituent products.  Generally, only partial product information
is
able to be discovered.  To support this use case we need to be able to
reference collections of potential products that may be installed on the
system.

Categorization of products is helpful to satisfying this use case.
There is
a need to relate specific products to broad categories.  It is also
equally
important to be able to query which discrete products belong to a
category.
Categorization is also an open issue.

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
  audit, end point management and asset inventory tools.  
  Sees "platforms" as "units of management".   Typically
  needs OSes and applications to be seen as peer concepts.

Requires discrete and abstract product references:

In this use case the "units of management" in a more granular sense are
products.  Asset/Configuration/License management requires knowledge of
discrete products installed on an asset and the ability to query these
assets using both discrete and abstract product representations.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
  and vulnerability analysis.  Typically views platforms
  and applications as a part of shipping OS.  Needs to identify
  system sub-components (files, librarys, shared .dlls)

Uses of this view generally interact with "components" or discrete
product
references.  Abstract product references may be useful to provide
querying
capabilities.  An ability to go from a known "component" to a product is
helpful when dealing with this use case.  This remains an unresolved
issue
with CPE that has been discussed many times before.

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
  and their customers.  Sees "platforms" in terms of development
  efforts with requirements, schedules, gold dates, licenses
  and inventory numbers.  Must deal with suite and components
  issues (e.g. Office vs Word, what is "Tivioli"?).  This view
  may overlap with the end point management view.

In addition to an overlap with the end point management view, there is
probably some overlay with the forensic/architecture view.

Uses of this view have references to discrete products with meta-data
associations.  Some development organizations may also choose to
interact
with "components" to provide more detailed internal tracking.

It seems to me that it is possible to satisfy all of these use cases, we
just need to spend the time on modifying and clarifying the
specification to
support them.  The first change I would suggest would be to switch our
thinking from talking about platforms to talking about products as our
basic
building block.

Dave

-----Original Message-----
From: Mann, Dave [mailto:[hidden email]]
Sent: Friday, August 15, 2008 9:17 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems

Eric Fredericksen wrote:
> During discovery our network scan engine will identify systems
to
> varying levels of accuracy. If we have credentials then everything is
> good. However, without credentials the fingerprinting algorithm will
> gather data and categorize the target.

Wolfkiel, Joseph wrote:
> I agree that returning scan results in some
> sort of CPE format is important to the DoD, and we do want to be able
> to communicate that we weren't able to determine the value, so I
> agree the ability to support unknowns seems like a necessary
function.



Eric, Joe et al,

I think we must open ourselves up to the very real possibility
that there are sets of technical use cases in which "platform"
information needs to be managed but that the ways of expressing
platform information in these cases will be fundementally different
from each other.  That is, we may need to consider more than one
way to express platform information.   Or, putting it yet another
way, we may need to accept that there are going to be sets of
use cases that CPE will not apply to.

I think that the situation may be analagous to how we think
about colors.   We all agree that there are colors.   I'm
wearing a maroon fleece sweater right now, for example.  But
what are colors?   How would we stuff "color" into our data
models so that we could effectively share color information?

For example, imagine that you taken by the color of my old
fleece sweater and decided that you wish to use it as the
main color in your branding.  You would need to be able to
specify this exact color to both your printer and
your web gurus so that your literature and web site would
both have the same "colors".  And if you wanted to paint your
barn or car the same color, you would need to specify the
color to the painter.

What's interesting here is that print, light display and paint
all use different encodings (called color spaces) to represent
colors.  See: http://en.wikipedia.org/wiki/Color_space  for a
starting point.   So here we have the same fleece jacket.
Agreement by all parties that it has the same color but different
ways of representing that color.   More deeply, the different
technical use cases (print, web, paint) demand these different
representations and worse, sometimes color spaces are non-comparable.



What I'm suggesting may be farily radical.  As I understood it,
the original goal of Neil Ziring's (NSA) XCCDF-P was to create
a scheme that would allows platforms to be identified in a
universal way and I believe that CPE has been trying to stay
true to that vision.   However, if I am correct and if the
concept of "platform" is similar to the concept of "color"
we may need to admit that CPE will be tremendously useful for
some technical uses but not for others and, in fact, that
other use cases might only be satisfied by a different,
perhaps incomparable "platform spaces".

Several weeks ago we posted an appeal for people to volunteer
to be interviewed regarding their own technical use cases.
We have interviewed many of you (huge thanks) and are still
actively seeking to interview others (please send me e-mail
if you are interested).   It is still too early for me to
give definitive results as we are still processing the information
as a team but given this thread, it might be useful for
me to share my current working hypothesis.

I think I'm hearing 4 different and largely incomparable
frames of reference for thinking about "platform":

+ NETWORK CENTRIC - Seen among network scanners.  Evidence
  for identifications starts with IP and climbs the network
  stack model to try to discover "platforms".

+ CREDENTIALED END POINT MANAGEMENT - Seen among configuration
  audit, end point management and asset inventory tools.  
  Sees "platforms" as "units of management".   Typically
  needs OSes and applications to be seen as peer concepts.

+ FORENSICS/OS ARCHITECTURE VIEW - Seen among OS vendors
  and vulnerability analysis.  Typically views platforms
  and applications as a part of shipping OS.  Needs to identify
  system sub-components (files, librarys, shared dlls)

+ OS DEVELOPMENT/MARKETING VIEW - Seen among OS vendors
  and their customrs.  Sees "platforms" in terms of development
  efforts with requirements, schedules, gold dates, licenses
  and inventory numbers.  Must deal with suite and components
  issues (e.g. Office vs Word, what is "Tivioli"?).  This view
  may overlap with the end point management view.

My sense is that CPE will be the most closely aligned with
the "Credentialed End Point Management" view, as I think that
is the view that was largely driving the XCCDF issues that
ultimately gave birth to CPE.  

I recognize that the implication of I'm suggesting means
that there will be winners and losers with respect to
CPE utility.  But if I'm correct, it will be impossible for
us to construct a "platform space" that will satisfy all
technical use cases.  If this is true, the best we will
be able to do is to a) identify those technical use cases
that CPE is good for and b) consider the possible need for
other platform encodings for other technical use cases if
the demand is big enough.

I'll close with one last observation.   Many, many, many
objects in our day to day lives have (by necessity) multiple
identification schemes associated with them.  Our cars have
both VINs and License Plates.  Books cary ISBNs, Library of
Congress IDs and UPCs.  My laptop has 4 different serial
numbers on it and a MITRE inventory number.   We may need
to accept that "platforms" are going to require multiple
"platform spaces" in the same way.

Feedback very much wanted on this...

-Dave
=================================================================
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================

[Ken.Lassesen]

I am inclined to suggest considering different, possibly more rigorous
approach, definitely more academic

Hardware:
=======
Bottom level is bare hardware.


Bare OS:
======
To this hardware, you add the minimum number of files to get an "operating
system" up. Files dealing with physical devices (i.e. Hardware Abstraction
Level) are excluded, but are deemed part of the bare OS.

Bare OS - Patches:
=============
Updates to the above files which can be 'random and arbitary' replacements
to the files in the Bare OS (in some cases there may be sets). If the file
set exceeds X% of the Bare OS files, then it must be deemed to be a
different version

OS Feature
=========
The addition of files to the Bare OS that provides an additional capability.
For example, a Web Server

OS Bundle:
=======
A **marketing** composition consisting of a Bare OS (with or without
Patches) and a set of OS Features and/or Applications Bundles. A bundle does
not require all of the items to be installed but is merely an offering of
options.

Bare Application:
============
Similar to Bare OS, the minimum set of files to add a functionality.
Typically this functionality will run on multiple Bare OS.

Application Patches
==============
Similar to OS Patches. Updates to the above files which can be 'random and
arbitary' replacements to the files in the Bare OS (in some cases there may
be sets). If the file set exceeds X% of the Bare Application files, then it
must be deemed to be a different version

Application Feature
==============
Similar to OS feature. Requires the Bare Application and then adds more
feature.

Application Bundle
=============
A **marketing** composition consisting of a Bare Application (with or
without Patches) and a set of Application Features and/or Applications
Bundles.
 (typical example is:  "Lite","Standard","Professional", "Enterprise"
version. A bundle does not require all of the items to be installed but is
merely an offering of options.

--------------------------------------------------------------
The problem is that the above can be represented as a tree EXCEPT for the
Bundles (i.e. easy to produce a BNF for). An OS Bundle can consist of OS
Features and Application Bundles.
The root problem is that we are trying to force CPE to be bundle centric
(i.e. arbitrary marketing arrangement) instead of decomposing the issue into
their technical components.


A CPE ID tied to a collection of files with MD5's for each would be a
logical way of addressing matters. a MPE (Marketing ...) being a collection
of CPE ID (thus a collection of collections of files) would be a logical
step to proceed down this path.


Ken Lassesen,
Lassesen Consulting, LLC.
http://www.linkedin.com/in/lassesen
MSNMessenger: [hidden email]
Office: 360-724-3190  Fax: [phone]
Cell:360-509-2402 Skype:Ken.Lassesen

CONFIDENTIALITY NOTICE

The information contained in this electronic message may contain
confidential and priviledged 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: "Tim Keanini" <[hidden email]>
To: <[hidden email]>
Sent: Friday, August 15, 2008 8:52 PM
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE
values for generic systems


David,
I'm doing my best to understand how these objects relate to one another.
Component(s):
Product(s):
Abstract-Product(s):
System(s):
Platform(s):

* What is the smallest most atomic unit in the CPE world?

* In the description you use below, it seems that both Abstract-Product
and System have Products as members?

I'm looking for something like a BNF or railroad diagram of terms.

--tk

[Andrew Buttner]

The two threads that have been running on this list the couple of days,
along with the conversations we have had with different users has been
invaluable to us at MITRE.  I can't tell you how excited we are to see
the level of interest in CPE and how important this is for everyone.  I
want to take some time and to confirm some things that I have heard as
well as relay some thoughts of my own.  We are by no means done
gathering information about different uses, but now seems like a great
time to share some of what we have learned.

Please note that in addition to this email, I will be sending out
another email more focused on the technical discussion about generic
values that is ongoing.  I'm not ignoring that issue!

Regarding the uses of CPE ...

=================================
== PROBLEM
=================================

I agree with Dave Waltermire in that we are stumbling on truly
understanding CPE because the term "platform" or "platform type" means
different things to different people.  This has lead to conflicting
views as to what 'things' we should be able to tag with a CPE Name, and
about what a CPE Name should look like.

For many, the term "platform" represents something that is too broad to
be enumerated by a single enumeration.  Enumerating roles that a system
plays probably requires a different naming convention than enumerating
operating systems.

As TK pointed out, the space that we are working in is a graph and
there are more type of relationships than just 'is a member of'.  My
guess is that we find ourselves in this world because we attempted to
enumerate something that was at too high a level.  "Platform" is
probably not the correct 'thing' to enumerate.

=================================
== THEORY
=================================

I still think Ernest is correct in stating that "CPE is a dictionary,
not an encyclopedia".  The first step in solving the different problems
that we all face is to enumerate the entities that we are dealing with.
In other words, we need to establish a common set of words.

My theory is that if we divide CPE up into a number of different
sub-enumerations that we will be better able to come to agreement on
the things that need to identified and how a CPE Name should be viewed
for that specific thing.

Kent Landfield also correctly pointed out keeping things simple yet
broad in focus will help an enumeration succeed well down the road.  My
opinion is that by being more specific about the 'things' that we are
enumerating, we will simplify our job of enumerating them.  But by not
limiting ourselves to the types of 'things' that deserve enumerations
we will be able to respond to future needs and be better positioned use
them in ways we don't currently anticipate.  

=================================
== FUTURE
=================================

I will try to sum up what I have heard so far and bring it together
into an achievable path going forward.  Of course our biggest challenge
might be getting started down such a path (and when to do so) but
hopefully this will all sound like a great direction going forward.

One idea would have CPE refocused on enumerating a number of different
things.  Each of these enumerations would likely follow different
naming conventions.  E.g. The vendor:product:version URI might not make
sense for system roles or environments.  Granted maybe we can find a
way to enumerate everyone under one naming convention, but I hope we
aren't going to limit ourselves to this.

I think I have seen requests for CPE enumerating:

- products / software
- hardware
- roles
- environment (DMZ, intranet)
- patches
- classifications / families

I'm sure there are others.  Basically, CPE can split into different
many different smaller enumerations, each helping to identify a small
fact about a platform.  (I'm even more convinced that the word platform
is the source of our problems!!)

This notion of facts was actually central to the early ideas running
around CPE (or XCCDF-P).  The idea was that CPE could be used to
identify a fact about a system and the CPE Language could be used to
combine these facts.  This idea lost its momentum because we tried to
fit all the different facts under one single hierarchy.  We all quickly
realized that this would not work.  So we tried to simplify the
hierarchy into a more common (and simple) hierarchy that was more
likely to apply in a general sense.  The problem is that this doesn't
scope very well, and it doesn't work as we move beyond products.

The hierarchy might be good for supporting the matching problem, and it
might work at some level for product names, but it falls apart when we
bring in other facts about a platform.

There is one additional piece to this puzzle.  A CPE Name cannot be
used to do more than it is intended.  I think many of us see a CPE Name
as something very close to what might be needed to solve our problems
and say "if we can just add this one thing".  My thinking is that this
often comes about because we do not have a way to correctly express the
relationships between the different things.  The CPE Language can play
a central role here.  I would love to think of the CPE Language as a
way of combining different facts about a system into a true platform
definition.  In a way, this would fully return the language back to its
original roots.  (Yes Neal, you were right!!)

A powerful CPE Language would allow us to do things that are beyond the
scope of an enumeration, but not at the complexity and power of an OVAL
Definition.  This is actually getting me all excited!!

=================================
== WHAT NOW?
=================================

Is this the right path to start down?  How do we start down this path?
What do we do in the meantime?  I think that some of these answers will
come about through the use case research we are doing.  Obviously a lot
of the answers depend on how the community continues to support and
foster the growth of CPE.  I cannot stress enough the importance of
sharing your thoughts and points of view.  For now, I think continuing
to push the limits of the current specification and discussing areas
that the spec falls apart will help us better understand how and when
to perform such a transition.

I think Version 3 of CPE has the potential to hit a home run!

---------

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

[Andrew Buttner]

I think I am hearing a request for 3 different technical needs in this
thread.

#1 - ability to name unknown platforms
#2 - ability to enumerate family / type information
#3 - ability to specify 'component does not apply'

For #1, you bring up the example of an unknown operating system.  Doesn't
the name "cpe:/o" satisfy this need?  What this name is supposed to
represent is the platform type of an operating system (any operating
system).  In other words, for your discovery use case, if you want to report
that the system has an operating system installed but that you don't have
any additional information, you could tag that part of the result set with
"cpe:/o"

For #2, I agree that this type of enumeration is needed somewhere.  OVAL
needs the same thing and currently defines a <family> element to relay this
information.  I'm intrigued by Lt. Col Wolfkiel's proposal, but I think some
questions still remain.  I would think that if family information was added
to the current CPE Name structure that it would want to be part of the
matching functionality.  Put another way, if we have a name for Sun Solaris,
that we know that this platform type is part of the UNIX platform type.
Since the UNIX platform type would not have the same vendor component, I
don't see how matching would occur given the [family=xxxxx] proposal.  Are
we trying to push too much information into a name that is suppose to
enumerate a 'thing'?  Is the solution to this have a separate enumeration
for family and then relate CPE Names to a certain family (or multiple
families).  This information could be available in a language format and
carried by those use cases that need such information?

For #3, I can see how this is different than the empty component, which
targets all things.  A blank version component would be used to identify all
versions of a given vendor:product.  But what if the platform doesn't have a
version?  (or more likely doesn't have an edition)  I'm not exactly sure the
best way forward here.  Is creating a special character(s) going to cause
problems down the road?

Maybe an even better question is if there really is a difference between a
name that leaves a component blank and a name that uses a 'null' code.  In
both cases, would the platform type being identified be the same thing?

Definitely looking for more discussion on these points.

Thanks
Drew

---------

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

[Tim Keanini]

Drew, will there be a working group session during the Sept. SCAP
conference?
--tk


-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, August 18, 2008 8:27 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

The two threads that have been running on this list the couple of days,
along with the conversations we have had with different users has been
invaluable to us at MITRE.  I can't tell you how excited we are to see
the level of interest in CPE and how important this is for everyone.  I
want to take some time and to confirm some things that I have heard as
well as relay some thoughts of my own.  We are by no means done
gathering information about different uses, but now seems like a great
time to share some of what we have learned.

Please note that in addition to this email, I will be sending out
another email more focused on the technical discussion about generic
values that is ongoing.  I'm not ignoring that issue!

Regarding the uses of CPE ...

=================================
== PROBLEM
=================================

I agree with Dave Waltermire in that we are stumbling on truly
understanding CPE because the term "platform" or "platform type" means
different things to different people.  This has lead to conflicting
views as to what 'things' we should be able to tag with a CPE Name, and
about what a CPE Name should look like.

For many, the term "platform" represents something that is too broad to
be enumerated by a single enumeration.  Enumerating roles that a system
plays probably requires a different naming convention than enumerating
operating systems.

As TK pointed out, the space that we are working in is a graph and
there are more type of relationships than just 'is a member of'.  My
guess is that we find ourselves in this world because we attempted to
enumerate something that was at too high a level.  "Platform" is
probably not the correct 'thing' to enumerate.

=================================
== THEORY
=================================

I still think Ernest is correct in stating that "CPE is a dictionary,
not an encyclopedia".  The first step in solving the different problems
that we all face is to enumerate the entities that we are dealing with.
In other words, we need to establish a common set of words.

My theory is that if we divide CPE up into a number of different
sub-enumerations that we will be better able to come to agreement on
the things that need to identified and how a CPE Name should be viewed
for that specific thing.

Kent Landfield also correctly pointed out keeping things simple yet
broad in focus will help an enumeration succeed well down the road.  My
opinion is that by being more specific about the 'things' that we are
enumerating, we will simplify our job of enumerating them.  But by not
limiting ourselves to the types of 'things' that deserve enumerations
we will be able to respond to future needs and be better positioned use
them in ways we don't currently anticipate.  

=================================
== FUTURE
=================================

I will try to sum up what I have heard so far and bring it together
into an achievable path going forward.  Of course our biggest challenge
might be getting started down such a path (and when to do so) but
hopefully this will all sound like a great direction going forward.

One idea would have CPE refocused on enumerating a number of different
things.  Each of these enumerations would likely follow different
naming conventions.  E.g. The vendor:product:version URI might not make
sense for system roles or environments.  Granted maybe we can find a
way to enumerate everyone under one naming convention, but I hope we
aren't going to limit ourselves to this.

I think I have seen requests for CPE enumerating:

- products / software
- hardware
- roles
- environment (DMZ, intranet)
- patches
- classifications / families

I'm sure there are others.  Basically, CPE can split into different
many different smaller enumerations, each helping to identify a small
fact about a platform.  (I'm even more convinced that the word platform
is the source of our problems!!)

This notion of facts was actually central to the early ideas running
around CPE (or XCCDF-P).  The idea was that CPE could be used to
identify a fact about a system and the CPE Language could be used to
combine these facts.  This idea lost its momentum because we tried to
fit all the different facts under one single hierarchy.  We all quickly
realized that this would not work.  So we tried to simplify the
hierarchy into a more common (and simple) hierarchy that was more
likely to apply in a general sense.  The problem is that this doesn't
scope very well, and it doesn't work as we move beyond products.

The hierarchy might be good for supporting the matching problem, and it
might work at some level for product names, but it falls apart when we
bring in other facts about a platform.

There is one additional piece to this puzzle.  A CPE Name cannot be
used to do more than it is intended.  I think many of us see a CPE Name
as something very close to what might be needed to solve our problems
and say "if we can just add this one thing".  My thinking is that this
often comes about because we do not have a way to correctly express the
relationships between the different things.  The CPE Language can play
a central role here.  I would love to think of the CPE Language as a
way of combining different facts about a system into a true platform
definition.  In a way, this would fully return the language back to its
original roots.  (Yes Neal, you were right!!)

A powerful CPE Language would allow us to do things that are beyond the
scope of an enumeration, but not at the complexity and power of an OVAL
Definition.  This is actually getting me all excited!!

=================================
== WHAT NOW?
=================================

Is this the right path to start down?  How do we start down this path?
What do we do in the meantime?  I think that some of these answers will
come about through the use case research we are doing.  Obviously a lot
of the answers depend on how the community continues to support and
foster the growth of CPE.  I cannot stress enough the importance of
sharing your thoughts and points of view.  For now, I think continuing
to push the limits of the current specification and discussing areas
that the spec falls apart will help us better understand how and when
to perform such a transition.

I think Version 3 of CPE has the potential to hit a home run!

---------

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

[Andrew Buttner]

There is not one planned as far as know.  The thinking is that there is
already a full schedule with everything else being discussed.
Thoughts?

Thanks
Drew


>-----Original Message-----
>From: Tim Keanini [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 11:10 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases
WAS:

>CPE values for generic systems
>
>Drew, will there be a working group session during the Sept. SCAP
>conference?
>--tk
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 8:27 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases

WAS:
>CPE values for generic systems
>
>The two threads that have been running on this list the couple of
days,
>along with the conversations we have had with different users has been
>invaluable to us at MITRE.  I can't tell you how excited we are to see
>the level of interest in CPE and how important this is for everyone.
I

>want to take some time and to confirm some things that I have heard as
>well as relay some thoughts of my own.  We are by no means done
>gathering information about different uses, but now seems like a great
>time to share some of what we have learned.
>
>Please note that in addition to this email, I will be sending out
>another email more focused on the technical discussion about generic
>values that is ongoing.  I'm not ignoring that issue!
>
>Regarding the uses of CPE ...
>
>=================================
>== PROBLEM
>=================================
>
>I agree with Dave Waltermire in that we are stumbling on truly
>understanding CPE because the term "platform" or "platform type" means
>different things to different people.  This has lead to conflicting
>views as to what 'things' we should be able to tag with a CPE Name,

and
>about what a CPE Name should look like.
>
>For many, the term "platform" represents something that is too broad
to
>be enumerated by a single enumeration.  Enumerating roles that a
system

>plays probably requires a different naming convention than enumerating
>operating systems.
>
>As TK pointed out, the space that we are working in is a graph and
>there are more type of relationships than just 'is a member of'.  My
>guess is that we find ourselves in this world because we attempted to
>enumerate something that was at too high a level.  "Platform" is
>probably not the correct 'thing' to enumerate.
>
>=================================
>== THEORY
>=================================
>
>I still think Ernest is correct in stating that "CPE is a dictionary,
>not an encyclopedia".  The first step in solving the different

problems
>that we all face is to enumerate the entities that we are dealing
with.
>In other words, we need to establish a common set of words.
>
>My theory is that if we divide CPE up into a number of different
>sub-enumerations that we will be better able to come to agreement on
>the things that need to identified and how a CPE Name should be viewed
>for that specific thing.
>
>Kent Landfield also correctly pointed out keeping things simple yet
>broad in focus will help an enumeration succeed well down the road.
My
>opinion is that by being more specific about the 'things' that we are
>enumerating, we will simplify our job of enumerating them.  But by not
>limiting ourselves to the types of 'things' that deserve enumerations
>we will be able to respond to future needs and be better positioned
use
>them in ways we don't currently anticipate.
>
>=================================
>== FUTURE
>=================================
>
>I will try to sum up what I have heard so far and bring it together
>into an achievable path going forward.  Of course our biggest
challenge
>might be getting started down such a path (and when to do so) but
>hopefully this will all sound like a great direction going forward.
>
>One idea would have CPE refocused on enumerating a number of different
>things.  Each of these enumerations would likely follow different
>naming conventions.  E.g. The vendor:product:version URI might not
make

>sense for system roles or environments.  Granted maybe we can find a
>way to enumerate everyone under one naming convention, but I hope we
>aren't going to limit ourselves to this.
>
>I think I have seen requests for CPE enumerating:
>
>- products / software
>- hardware
>- roles
>- environment (DMZ, intranet)
>- patches
>- classifications / families
>
>I'm sure there are others.  Basically, CPE can split into different
>many different smaller enumerations, each helping to identify a small
>fact about a platform.  (I'm even more convinced that the word

platform
>is the source of our problems!!)
>
>This notion of facts was actually central to the early ideas running
>around CPE (or XCCDF-P).  The idea was that CPE could be used to
>identify a fact about a system and the CPE Language could be used to
>combine these facts.  This idea lost its momentum because we tried to
>fit all the different facts under one single hierarchy.  We all
quickly
>realized that this would not work.  So we tried to simplify the
>hierarchy into a more common (and simple) hierarchy that was more
>likely to apply in a general sense.  The problem is that this doesn't
>scope very well, and it doesn't work as we move beyond products.
>
>The hierarchy might be good for supporting the matching problem, and
it
>might work at some level for product names, but it falls apart when we
>bring in other facts about a platform.
>
>There is one additional piece to this puzzle.  A CPE Name cannot be
>used to do more than it is intended.  I think many of us see a CPE
Name
>as something very close to what might be needed to solve our problems
>and say "if we can just add this one thing".  My thinking is that this
>often comes about because we do not have a way to correctly express
the
>relationships between the different things.  The CPE Language can play
>a central role here.  I would love to think of the CPE Language as a
>way of combining different facts about a system into a true platform
>definition.  In a way, this would fully return the language back to
its
>original roots.  (Yes Neal, you were right!!)
>
>A powerful CPE Language would allow us to do things that are beyond
the
>scope of an enumeration, but not at the complexity and power of an
OVAL
>Definition.  This is actually getting me all excited!!
>
>=================================
>== WHAT NOW?
>=================================
>
>Is this the right path to start down?  How do we start down this path?
>What do we do in the meantime?  I think that some of these answers
will
>come about through the use case research we are doing.  Obviously a
lot

>of the answers depend on how the community continues to support and
>foster the growth of CPE.  I cannot stress enough the importance of
>sharing your thoughts and points of view.  For now, I think continuing
>to push the limits of the current specification and discussing areas
>that the spec falls apart will help us better understand how and when
>to perform such a transition.
>
>I think Version 3 of CPE has the potential to hit a home run!
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515

[Kent_Landfield]

I would love to see a couple hours working group session for each of the
working groups. CPE really needs it and the face to face situation
allows for much higher bandwidth....  This is probably also a NIST
request for space and time...

We have shown how effective these types of meeting are at past NIST SCAP
conferences.  We should try not to loose the opportunity that the
conference presents.

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

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 6:24 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

There is not one planned as far as know.  The thinking is that there is
already a full schedule with everything else being discussed.
Thoughts?

Thanks
Drew


>-----Original Message-----
>From: Tim Keanini [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 11:10 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases
WAS:

>CPE values for generic systems
>
>Drew, will there be a working group session during the Sept. SCAP
>conference?
>--tk
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 8:27 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases

WAS:
>CPE values for generic systems
>
>The two threads that have been running on this list the couple of
days,
>along with the conversations we have had with different users has been
>invaluable to us at MITRE.  I can't tell you how excited we are to see
>the level of interest in CPE and how important this is for everyone.
I

>want to take some time and to confirm some things that I have heard as
>well as relay some thoughts of my own.  We are by no means done
>gathering information about different uses, but now seems like a great
>time to share some of what we have learned.
>
>Please note that in addition to this email, I will be sending out
>another email more focused on the technical discussion about generic
>values that is ongoing.  I'm not ignoring that issue!
>
>Regarding the uses of CPE ...
>
>=================================
>== PROBLEM
>=================================
>
>I agree with Dave Waltermire in that we are stumbling on truly
>understanding CPE because the term "platform" or "platform type" means
>different things to different people.  This has lead to conflicting
>views as to what 'things' we should be able to tag with a CPE Name,

and
>about what a CPE Name should look like.
>
>For many, the term "platform" represents something that is too broad
to
>be enumerated by a single enumeration.  Enumerating roles that a
system

>plays probably requires a different naming convention than enumerating
>operating systems.
>
>As TK pointed out, the space that we are working in is a graph and
>there are more type of relationships than just 'is a member of'.  My
>guess is that we find ourselves in this world because we attempted to
>enumerate something that was at too high a level.  "Platform" is
>probably not the correct 'thing' to enumerate.
>
>=================================
>== THEORY
>=================================
>
>I still think Ernest is correct in stating that "CPE is a dictionary,
>not an encyclopedia".  The first step in solving the different

problems
>that we all face is to enumerate the entities that we are dealing
with.
>In other words, we need to establish a common set of words.
>
>My theory is that if we divide CPE up into a number of different
>sub-enumerations that we will be better able to come to agreement on
>the things that need to identified and how a CPE Name should be viewed
>for that specific thing.
>
>Kent Landfield also correctly pointed out keeping things simple yet
>broad in focus will help an enumeration succeed well down the road.
My
>opinion is that by being more specific about the 'things' that we are
>enumerating, we will simplify our job of enumerating them.  But by not
>limiting ourselves to the types of 'things' that deserve enumerations
>we will be able to respond to future needs and be better positioned
use
>them in ways we don't currently anticipate.
>
>=================================
>== FUTURE
>=================================
>
>I will try to sum up what I have heard so far and bring it together
>into an achievable path going forward.  Of course our biggest
challenge
>might be getting started down such a path (and when to do so) but
>hopefully this will all sound like a great direction going forward.
>
>One idea would have CPE refocused on enumerating a number of different
>things.  Each of these enumerations would likely follow different
>naming conventions.  E.g. The vendor:product:version URI might not
make

>sense for system roles or environments.  Granted maybe we can find a
>way to enumerate everyone under one naming convention, but I hope we
>aren't going to limit ourselves to this.
>
>I think I have seen requests for CPE enumerating:
>
>- products / software
>- hardware
>- roles
>- environment (DMZ, intranet)
>- patches
>- classifications / families
>
>I'm sure there are others.  Basically, CPE can split into different
>many different smaller enumerations, each helping to identify a small
>fact about a platform.  (I'm even more convinced that the word

platform
>is the source of our problems!!)
>
>This notion of facts was actually central to the early ideas running
>around CPE (or XCCDF-P).  The idea was that CPE could be used to
>identify a fact about a system and the CPE Language could be used to
>combine these facts.  This idea lost its momentum because we tried to
>fit all the different facts under one single hierarchy.  We all
quickly
>realized that this would not work.  So we tried to simplify the
>hierarchy into a more common (and simple) hierarchy that was more
>likely to apply in a general sense.  The problem is that this doesn't
>scope very well, and it doesn't work as we move beyond products.
>
>The hierarchy might be good for supporting the matching problem, and
it
>might work at some level for product names, but it falls apart when we
>bring in other facts about a platform.
>
>There is one additional piece to this puzzle.  A CPE Name cannot be
>used to do more than it is intended.  I think many of us see a CPE
Name
>as something very close to what might be needed to solve our problems
>and say "if we can just add this one thing".  My thinking is that this
>often comes about because we do not have a way to correctly express
the
>relationships between the different things.  The CPE Language can play
>a central role here.  I would love to think of the CPE Language as a
>way of combining different facts about a system into a true platform
>definition.  In a way, this would fully return the language back to
its
>original roots.  (Yes Neal, you were right!!)
>
>A powerful CPE Language would allow us to do things that are beyond
the
>scope of an enumeration, but not at the complexity and power of an
OVAL
>Definition.  This is actually getting me all excited!!
>
>=================================
>== WHAT NOW?
>=================================
>
>Is this the right path to start down?  How do we start down this path?
>What do we do in the meantime?  I think that some of these answers
will
>come about through the use case research we are doing.  Obviously a
lot

>of the answers depend on how the community continues to support and
>foster the growth of CPE.  I cannot stress enough the importance of
>sharing your thoughts and points of view.  For now, I think continuing
>to push the limits of the current specification and discussing areas
>that the spec falls apart will help us better understand how and when
>to perform such a transition.
>
>I think Version 3 of CPE has the potential to hit a home run!
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515

[Tim Keanini]

I don't think people would mind a gathering at a pub which began at 1730
hours.
--tk

-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 8:36 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

I would love to see a couple hours working group session for each of the
working groups. CPE really needs it and the face to face situation
allows for much higher bandwidth....  This is probably also a NIST
request for space and time...

We have shown how effective these types of meeting are at past NIST SCAP
conferences.  We should try not to loose the opportunity that the
conference presents.

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

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 6:24 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

There is not one planned as far as know.  The thinking is that there is
already a full schedule with everything else being discussed.
Thoughts?

Thanks
Drew


>-----Original Message-----
>From: Tim Keanini [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 11:10 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases
WAS:

>CPE values for generic systems
>
>Drew, will there be a working group session during the Sept. SCAP
>conference?
>--tk
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 8:27 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases

WAS:
>CPE values for generic systems
>
>The two threads that have been running on this list the couple of
days,
>along with the conversations we have had with different users has been
>invaluable to us at MITRE.  I can't tell you how excited we are to see
>the level of interest in CPE and how important this is for everyone.
I

>want to take some time and to confirm some things that I have heard as
>well as relay some thoughts of my own.  We are by no means done
>gathering information about different uses, but now seems like a great
>time to share some of what we have learned.
>
>Please note that in addition to this email, I will be sending out
>another email more focused on the technical discussion about generic
>values that is ongoing.  I'm not ignoring that issue!
>
>Regarding the uses of CPE ...
>
>=================================
>== PROBLEM
>=================================
>
>I agree with Dave Waltermire in that we are stumbling on truly
>understanding CPE because the term "platform" or "platform type" means
>different things to different people.  This has lead to conflicting
>views as to what 'things' we should be able to tag with a CPE Name,

and
>about what a CPE Name should look like.
>
>For many, the term "platform" represents something that is too broad
to
>be enumerated by a single enumeration.  Enumerating roles that a
system

>plays probably requires a different naming convention than enumerating
>operating systems.
>
>As TK pointed out, the space that we are working in is a graph and
>there are more type of relationships than just 'is a member of'.  My
>guess is that we find ourselves in this world because we attempted to
>enumerate something that was at too high a level.  "Platform" is
>probably not the correct 'thing' to enumerate.
>
>=================================
>== THEORY
>=================================
>
>I still think Ernest is correct in stating that "CPE is a dictionary,
>not an encyclopedia".  The first step in solving the different

problems
>that we all face is to enumerate the entities that we are dealing
with.
>In other words, we need to establish a common set of words.
>
>My theory is that if we divide CPE up into a number of different
>sub-enumerations that we will be better able to come to agreement on
>the things that need to identified and how a CPE Name should be viewed
>for that specific thing.
>
>Kent Landfield also correctly pointed out keeping things simple yet
>broad in focus will help an enumeration succeed well down the road.
My
>opinion is that by being more specific about the 'things' that we are
>enumerating, we will simplify our job of enumerating them.  But by not
>limiting ourselves to the types of 'things' that deserve enumerations
>we will be able to respond to future needs and be better positioned
use
>them in ways we don't currently anticipate.
>
>=================================
>== FUTURE
>=================================
>
>I will try to sum up what I have heard so far and bring it together
>into an achievable path going forward.  Of course our biggest
challenge
>might be getting started down such a path (and when to do so) but
>hopefully this will all sound like a great direction going forward.
>
>One idea would have CPE refocused on enumerating a number of different
>things.  Each of these enumerations would likely follow different
>naming conventions.  E.g. The vendor:product:version URI might not
make

>sense for system roles or environments.  Granted maybe we can find a
>way to enumerate everyone under one naming convention, but I hope we
>aren't going to limit ourselves to this.
>
>I think I have seen requests for CPE enumerating:
>
>- products / software
>- hardware
>- roles
>- environment (DMZ, intranet)
>- patches
>- classifications / families
>
>I'm sure there are others.  Basically, CPE can split into different
>many different smaller enumerations, each helping to identify a small
>fact about a platform.  (I'm even more convinced that the word

platform
>is the source of our problems!!)
>
>This notion of facts was actually central to the early ideas running
>around CPE (or XCCDF-P).  The idea was that CPE could be used to
>identify a fact about a system and the CPE Language could be used to
>combine these facts.  This idea lost its momentum because we tried to
>fit all the different facts under one single hierarchy.  We all
quickly
>realized that this would not work.  So we tried to simplify the
>hierarchy into a more common (and simple) hierarchy that was more
>likely to apply in a general sense.  The problem is that this doesn't
>scope very well, and it doesn't work as we move beyond products.
>
>The hierarchy might be good for supporting the matching problem, and
it
>might work at some level for product names, but it falls apart when we
>bring in other facts about a platform.
>
>There is one additional piece to this puzzle.  A CPE Name cannot be
>used to do more than it is intended.  I think many of us see a CPE
Name
>as something very close to what might be needed to solve our problems
>and say "if we can just add this one thing".  My thinking is that this
>often comes about because we do not have a way to correctly express
the
>relationships between the different things.  The CPE Language can play
>a central role here.  I would love to think of the CPE Language as a
>way of combining different facts about a system into a true platform
>definition.  In a way, this would fully return the language back to
its
>original roots.  (Yes Neal, you were right!!)
>
>A powerful CPE Language would allow us to do things that are beyond
the
>scope of an enumeration, but not at the complexity and power of an
OVAL
>Definition.  This is actually getting me all excited!!
>
>=================================
>== WHAT NOW?
>=================================
>
>Is this the right path to start down?  How do we start down this path?
>What do we do in the meantime?  I think that some of these answers
will
>come about through the use case research we are doing.  Obviously a
lot

>of the answers depend on how the community continues to support and
>foster the growth of CPE.  I cannot stress enough the importance of
>sharing your thoughts and points of view.  For now, I think continuing
>to push the limits of the current specification and discussing areas
>that the spec falls apart will help us better understand how and when
>to perform such a transition.
>
>I think Version 3 of CPE has the potential to hit a home run!
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515

[Kent_Landfield]

:-)  Yep, that's true but if we are going to do that we should publish a
time so those interested would know where to go. :-)  

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

-----Original Message-----
From: Tim Keanini [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 9:05 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

I don't think people would mind a gathering at a pub which began at 1730
hours.
--tk

-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 8:36 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

I would love to see a couple hours working group session for each of the
working groups. CPE really needs it and the face to face situation
allows for much higher bandwidth....  This is probably also a NIST
request for space and time...

We have shown how effective these types of meeting are at past NIST SCAP
conferences.  We should try not to loose the opportunity that the
conference presents.

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

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 6:24 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

There is not one planned as far as know.  The thinking is that there is
already a full schedule with everything else being discussed.
Thoughts?

Thanks
Drew


>-----Original Message-----
>From: Tim Keanini [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 11:10 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases
WAS:

>CPE values for generic systems
>
>Drew, will there be a working group session during the Sept. SCAP
>conference?
>--tk
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 8:27 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases

WAS:
>CPE values for generic systems
>
>The two threads that have been running on this list the couple of
days,
>along with the conversations we have had with different users has been
>invaluable to us at MITRE.  I can't tell you how excited we are to see
>the level of interest in CPE and how important this is for everyone.
I

>want to take some time and to confirm some things that I have heard as
>well as relay some thoughts of my own.  We are by no means done
>gathering information about different uses, but now seems like a great
>time to share some of what we have learned.
>
>Please note that in addition to this email, I will be sending out
>another email more focused on the technical discussion about generic
>values that is ongoing.  I'm not ignoring that issue!
>
>Regarding the uses of CPE ...
>
>=================================
>== PROBLEM
>=================================
>
>I agree with Dave Waltermire in that we are stumbling on truly
>understanding CPE because the term "platform" or "platform type" means
>different things to different people.  This has lead to conflicting
>views as to what 'things' we should be able to tag with a CPE Name,

and
>about what a CPE Name should look like.
>
>For many, the term "platform" represents something that is too broad
to
>be enumerated by a single enumeration.  Enumerating roles that a
system

>plays probably requires a different naming convention than enumerating
>operating systems.
>
>As TK pointed out, the space that we are working in is a graph and
>there are more type of relationships than just 'is a member of'.  My
>guess is that we find ourselves in this world because we attempted to
>enumerate something that was at too high a level.  "Platform" is
>probably not the correct 'thing' to enumerate.
>
>=================================
>== THEORY
>=================================
>
>I still think Ernest is correct in stating that "CPE is a dictionary,
>not an encyclopedia".  The first step in solving the different

problems
>that we all face is to enumerate the entities that we are dealing
with.
>In other words, we need to establish a common set of words.
>
>My theory is that if we divide CPE up into a number of different
>sub-enumerations that we will be better able to come to agreement on
>the things that need to identified and how a CPE Name should be viewed
>for that specific thing.
>
>Kent Landfield also correctly pointed out keeping things simple yet
>broad in focus will help an enumeration succeed well down the road.
My
>opinion is that by being more specific about the 'things' that we are
>enumerating, we will simplify our job of enumerating them.  But by not
>limiting ourselves to the types of 'things' that deserve enumerations
>we will be able to respond to future needs and be better positioned
use
>them in ways we don't currently anticipate.
>
>=================================
>== FUTURE
>=================================
>
>I will try to sum up what I have heard so far and bring it together
>into an achievable path going forward.  Of course our biggest
challenge
>might be getting started down such a path (and when to do so) but
>hopefully this will all sound like a great direction going forward.
>
>One idea would have CPE refocused on enumerating a number of different
>things.  Each of these enumerations would likely follow different
>naming conventions.  E.g. The vendor:product:version URI might not
make

>sense for system roles or environments.  Granted maybe we can find a
>way to enumerate everyone under one naming convention, but I hope we
>aren't going to limit ourselves to this.
>
>I think I have seen requests for CPE enumerating:
>
>- products / software
>- hardware
>- roles
>- environment (DMZ, intranet)
>- patches
>- classifications / families
>
>I'm sure there are others.  Basically, CPE can split into different
>many different smaller enumerations, each helping to identify a small
>fact about a platform.  (I'm even more convinced that the word

platform
>is the source of our problems!!)
>
>This notion of facts was actually central to the early ideas running
>around CPE (or XCCDF-P).  The idea was that CPE could be used to
>identify a fact about a system and the CPE Language could be used to
>combine these facts.  This idea lost its momentum because we tried to
>fit all the different facts under one single hierarchy.  We all
quickly
>realized that this would not work.  So we tried to simplify the
>hierarchy into a more common (and simple) hierarchy that was more
>likely to apply in a general sense.  The problem is that this doesn't
>scope very well, and it doesn't work as we move beyond products.
>
>The hierarchy might be good for supporting the matching problem, and
it
>might work at some level for product names, but it falls apart when we
>bring in other facts about a platform.
>
>There is one additional piece to this puzzle.  A CPE Name cannot be
>used to do more than it is intended.  I think many of us see a CPE
Name
>as something very close to what might be needed to solve our problems
>and say "if we can just add this one thing".  My thinking is that this
>often comes about because we do not have a way to correctly express
the
>relationships between the different things.  The CPE Language can play
>a central role here.  I would love to think of the CPE Language as a
>way of combining different facts about a system into a true platform
>definition.  In a way, this would fully return the language back to
its
>original roots.  (Yes Neal, you were right!!)
>
>A powerful CPE Language would allow us to do things that are beyond
the
>scope of an enumeration, but not at the complexity and power of an
OVAL
>Definition.  This is actually getting me all excited!!
>
>=================================
>== WHAT NOW?
>=================================
>
>Is this the right path to start down?  How do we start down this path?
>What do we do in the meantime?  I think that some of these answers
will
>come about through the use case research we are doing.  Obviously a
lot

>of the answers depend on how the community continues to support and
>foster the growth of CPE.  I cannot stress enough the importance of
>sharing your thoughts and points of view.  For now, I think continuing
>to push the limits of the current specification and discussing areas
>that the spec falls apart will help us better understand how and when
>to perform such a transition.
>
>I think Version 3 of CPE has the potential to hit a home run!
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515

[Wolfkiel, Joseph]

I think we can probably work something out.  The last schedule I saw had
meetings set up that I thought were a little redundant.  I'll check with
the NIST guys to see if there's any flex.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T)
Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]



-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 10:06 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems


:-)  Yep, that's true but if we are going to do that we should publish a
time so those interested would know where to go. :-)  

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

-----Original Message-----
From: Tim Keanini [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 9:05 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

I don't think people would mind a gathering at a pub which began at 1730
hours.
--tk

-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 8:36 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

I would love to see a couple hours working group session for each of the
working groups. CPE really needs it and the face to face situation
allows for much higher bandwidth....  This is probably also a NIST
request for space and time...

We have shown how effective these types of meeting are at past NIST SCAP
conferences.  We should try not to loose the opportunity that the
conference presents.

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

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 6:24 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS:
CPE values for generic systems

There is not one planned as far as know.  The thinking is that there is
already a full schedule with everything else being discussed.
Thoughts?

Thanks
Drew


>-----Original Message-----
>From: Tim Keanini [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 11:10 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases
WAS:

>CPE values for generic systems
>
>Drew, will there be a working group session during the Sept. SCAP
>conference?
>--tk
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Monday, August 18, 2008 8:27 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases

WAS:
>CPE values for generic systems
>
>The two threads that have been running on this list the couple of

days,
>along with the conversations we have had with different users has been
>invaluable to us at MITRE.  I can't tell you how excited we are to see
>the level of interest in CPE and how important this is for everyone.
I

>want to take some time and to confirm some things that I have heard as
>well as relay some thoughts of my own.  We are by no means done
>gathering information about different uses, but now seems like a great
>time to share some of what we have learned.
>
>Please note that in addition to this email, I will be sending out
>another email more focused on the technical discussion about generic
>values that is ongoing.  I'm not ignoring that issue!
>
>Regarding the uses of CPE ...
>
>=================================
>== PROBLEM
>=================================
>
>I agree with Dave Waltermire in that we are stumbling on truly
>understanding CPE because the term "platform" or "platform type" means
>different things to different people.  This has lead to conflicting
>views as to what 'things' we should be able to tag with a CPE Name,

and
>about what a CPE Name should look like.
>
>For many, the term "platform" represents something that is too broad

to
>be enumerated by a single enumeration.  Enumerating roles that a
system

>plays probably requires a different naming convention than enumerating
>operating systems.
>
>As TK pointed out, the space that we are working in is a graph and
>there are more type of relationships than just 'is a member of'.  My
>guess is that we find ourselves in this world because we attempted to
>enumerate something that was at too high a level.  "Platform" is
>probably not the correct 'thing' to enumerate.
>
>=================================
>== THEORY
>=================================
>
>I still think Ernest is correct in stating that "CPE is a dictionary,
>not an encyclopedia".  The first step in solving the different

problems
>that we all face is to enumerate the entities that we are dealing

with.
>In other words, we need to establish a common set of words.
>
>My theory is that if we divide CPE up into a number of different
>sub-enumerations that we will be better able to come to agreement on
>the things that need to identified and how a CPE Name should be viewed
>for that specific thing.
>
>Kent Landfield also correctly pointed out keeping things simple yet
>broad in focus will help an enumeration succeed well down the road.
My
>opinion is that by being more specific about the 'things' that we are
>enumerating, we will simplify our job of enumerating them.  But by not
>limiting ourselves to the types of 'things' that deserve enumerations
>we will be able to respond to future needs and be better positioned
use
>them in ways we don't currently anticipate.
>
>=================================
>== FUTURE
>=================================
>
>I will try to sum up what I have heard so far and bring it together
>into an achievable path going forward.  Of course our biggest
challenge
>might be getting started down such a path (and when to do so) but
>hopefully this will all sound like a great direction going forward.
>
>One idea would have CPE refocused on enumerating a number of different
>things.  Each of these enumerations would likely follow different
>naming conventions.  E.g. The vendor:product:version URI might not
make

>sense for system roles or environments.  Granted maybe we can find a
>way to enumerate everyone under one naming convention, but I hope we
>aren't going to limit ourselves to this.
>
>I think I have seen requests for CPE enumerating:
>
>- products / software
>- hardware
>- roles
>- environment (DMZ, intranet)
>- patches
>- classifications / families
>
>I'm sure there are others.  Basically, CPE can split into different
>many different smaller enumerations, each helping to identify a small
>fact about a platform.  (I'm even more convinced that the word

platform
>is the source of our problems!!)
>
>This notion of facts was actually central to the early ideas running
>around CPE (or XCCDF-P).  The idea was that CPE could be used to
>identify a fact about a system and the CPE Language could be used to
>combine these facts.  This idea lost its momentum because we tried to
>fit all the different facts under one single hierarchy.  We all

quickly
>realized that this would not work.  So we tried to simplify the
>hierarchy into a more common (and simple) hierarchy that was more
>likely to apply in a general sense.  The problem is that this doesn't
>scope very well, and it doesn't work as we move beyond products.
>
>The hierarchy might be good for supporting the matching problem, and
it
>might work at some level for product names, but it falls apart when we
>bring in other facts about a platform.
>
>There is one additional piece to this puzzle.  A CPE Name cannot be
>used to do more than it is intended.  I think many of us see a CPE
Name
>as something very close to what might be needed to solve our problems
>and say "if we can just add this one thing".  My thinking is that this
>often comes about because we do not have a way to correctly express
the
>relationships between the different things.  The CPE Language can play
>a central role here.  I would love to think of the CPE Language as a
>way of combining different facts about a system into a true platform
>definition.  In a way, this would fully return the language back to
its
>original roots.  (Yes Neal, you were right!!)
>
>A powerful CPE Language would allow us to do things that are beyond
the
>scope of an enumeration, but not at the complexity and power of an
OVAL
>Definition.  This is actually getting me all excited!!
>
>=================================
>== WHAT NOW?
>=================================
>
>Is this the right path to start down?  How do we start down this path?
>What do we do in the meantime?  I think that some of these answers
will
>come about through the use case research we are doing.  Obviously a
lot

>of the answers depend on how the community continues to support and
>foster the growth of CPE.  I cannot stress enough the importance of
>sharing your thoughts and points of view.  For now, I think continuing
>to push the limits of the current specification and discussing areas
>that the spec falls apart will help us better understand how and when
>to perform such a transition.
>
>I think Version 3 of CPE has the potential to hit a home run!
>
>---------
>
>Andrew Buttner
>The MITRE Corporation
>[hidden email]
>781-271-3515

[Wolfkiel, Joseph]

Drew,

For case #1, the desire was to show that a tool was unable to determine
which operating system was installed.  Based on the spec, "cpe:/o"
basically states that it is a match for all operating systems.  If you
used this cpeID as a cross ref to look up vulnerabilities from the NVD,
you'd get all vulnerabilities for every operating system.  It's not
clear to me that everyone agrees that being unable to determine OS
should require you to match all OSs.

For case #2, It's not clear in my mind how, exactly we'd manage the
[family] concept.  The case that comes to mind for me is if we have a
passive scanner (e.g. NetMap) that watches traffic pass, and determines
that a box is some flavor of UNIX (possibly by seeing a BIND, FTP, or
SMTP service running is a UNIX daemon), but that's all.  You would infer
a cpe of cpe:/o::[family=UNIX] and publish that as scan results.  This
is probably the case where I have the least strong feelings.  It would
also be reasonable to take the "Family" stuff and put it into a tag that
would be appended to the CPE as metadata and would fall outside the
spec.  We could also use "group," which is more generic. Example:

<platform_description>
     <cpeItem>cpe:/o</cpeItem>
     <family>product:UNIX</family>
</platform_description>

For case #3, I think we need to do something to prevent a blank
component from requiring a match against all possible values of that
component.  I think this is an inherent part of the cpeID string and
can't be gracefully resolved outside of the specification.  Even coming
to a convention such as populating empty components with "no_component",
"blank", or some other value would resolve this issue.

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T)
Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]



-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, August 18, 2008 10:09 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE values for generic systems


I think I am hearing a request for 3 different technical needs in this
thread.

#1 - ability to name unknown platforms
#2 - ability to enumerate family / type information
#3 - ability to specify 'component does not apply'

For #1, you bring up the example of an unknown operating system.
Doesn't
the name "cpe:/o" satisfy this need?  What this name is supposed to
represent is the platform type of an operating system (any operating
system).  In other words, for your discovery use case, if you want to
report
that the system has an operating system installed but that you don't
have
any additional information, you could tag that part of the result set
with
"cpe:/o"

For #2, I agree that this type of enumeration is needed somewhere.  OVAL
needs the same thing and currently defines a <family> element to relay
this
information.  I'm intrigued by Lt. Col Wolfkiel's proposal, but I think
some
questions still remain.  I would think that if family information was
added
to the current CPE Name structure that it would want to be part of the
matching functionality.  Put another way, if we have a name for Sun
Solaris,
that we know that this platform type is part of the UNIX platform type.
Since the UNIX platform type would not have the same vendor component, I
don't see how matching would occur given the [family=xxxxx] proposal.
Are
we trying to push too much information into a name that is suppose to
enumerate a 'thing'?  Is the solution to this have a separate
enumeration
for family and then relate CPE Names to a certain family (or multiple
families).  This information could be available in a language format and
carried by those use cases that need such information?

For #3, I can see how this is different than the empty component, which
targets all things.  A blank version component would be used to identify
all
versions of a given vendor:product.  But what if the platform doesn't
have a
version?  (or more likely doesn't have an edition)  I'm not exactly sure
the
best way forward here.  Is creating a special character(s) going to
cause
problems down the road?

Maybe an even better question is if there really is a difference between
a
name that leaves a component blank and a name that uses a 'null' code.
In
both cases, would the platform type being identified be the same thing?

Definitely looking for more discussion on these points.

Thanks
Drew

---------

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

[Ernest Park-2]

Comments inline . . .

On Wed, Aug 20, 2008 at 9:21 AM, Wolfkiel, Joseph <[hidden email]> wrote:

Drew,

For case #1, the desire was to show that a tool was unable to determine
which operating system was installed.  Based on the spec, "cpe:/o"
basically states that it is a match for all operating systems.  If you
used this cpeID as a cross ref to look up vulnerabilities from the NVD,
you'd get all vulnerabilities for every operating system.  It's not
clear to me that everyone agrees that being unable to determine OS
should require you to match all OSs.

 

As I read this, if I have one record in the DB with "cpe:/o", I can resolve that it's part is Operating System. Since I have no detail beyond that, I have as much information as if I had a tag called unknown, without having to create and manage a label that is effectively a non-value.

 

Therefore, I know that I have an OS because of the "part". I do not have any more info than that, but it would answer the problem previously presented.

 

For case #2, It's not clear in my mind how, exactly we'd manage the
[family] concept.  The case that comes to mind for me is if we have a
passive scanner (e.g. NetMap) that watches traffic pass, and determines
that a box is some flavor of UNIX (possibly by seeing a BIND, FTP, or
SMTP service running is a UNIX daemon), but that's all.  You would infer
a cpe of cpe:/o::[family=UNIX] and publish that as scan results.  This
is probably the case where I have the least strong feelings.  It would
also be reasonable to take the "Family" stuff and put it into a tag that
would be appended to the CPE as metadata and would fall outside the
spec.  We could also use "group," which is more generic. Example:

<platform_description>
    <cpeItem>cpe:/o</cpeItem>
    <family>product:UNIX</family>
</platform_description>

 

 

We have talked about the concept of aliasing and tagging. If we agree on a general construct, we can share this. While we can all create our own schemas to support tags and aliases, if we agree on a structure, such extended metadata can follow a reliable pattern.

 

The example above is easy, would need some constructs, and can be mirrored in a database. I suggest that the "extended" data goes beyond what CPE is, but such use is exactly where we should be getting with the CPE names.

For case #3, I think we need to do something to prevent a blank
component from requiring a match against all possible values of that
component.  I think this is an inherent part of the cpeID string and
can't be gracefully resolved outside of the specification.  Even coming
to a convention such as populating empty components with "no_component",
"blank", or some other value would resolve this issue.

 

 

Wouldn't the "matching" be governed by the business and progammatic logic of your application against the database? So, perhaps no value does not mean "match all". Instead, no value means stop here. If I have cpe:/o::app, I don't "match" all vendors, but this string means that I cannot filter results to a vendor, and I "may" get overlap results since the only granular value I have is an app name, in this case.

 

How would having an identifier differ from cpe:/o::app, and why would we want to fix this in CPE, rather than program for this in our code?

 

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T)
Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]



-----Original Message-----

From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, August 18, 2008 10:09 PM
To: [hidden email]

Subject: Re: [CPE-DISCUSSION-LIST] CPE values for generic systems


I think I am hearing a request for 3 different technical needs in this
thread.

#1 - ability to name unknown platforms
#2 - ability to enumerate family / type information
#3 - ability to specify 'component does not apply'

For #1, you bring up the example of an unknown operating system.
Doesn't
the name "cpe:/o" satisfy this need?  What this name is supposed to
represent is the platform type of an operating system (any operating
system).  In other words, for your discovery use case, if you want to
report
that the system has an operating system installed but that you don't
have
any additional information, you could tag that part of the result set
with
"cpe:/o"

For #2, I agree that this type of enumeration is needed somewhere.  OVAL
needs the same thing and currently defines a <family> element to relay
this
information.  I'm intrigued by Lt. Col Wolfkiel's proposal, but I think
some
questions still remain.  I would think that if family information was
added
to the current CPE Name structure that it would want to be part of the
matching functionality.  Put another way, if we have a name for Sun
Solaris,
that we know that this platform type is part of the UNIX platform type.
Since the UNIX platform type would not have the same vendor component, I
don't see how matching would occur given the [family=xxxxx] proposal.
Are
we trying to push too much information into a name that is suppose to
enumerate a 'thing'?  Is the solution to this have a separate
enumeration
for family and then relate CPE Names to a certain family (or multiple
families).  This information could be available in a language format and
carried by those use cases that need such information?

For #3, I can see how this is different than the empty component, which
targets all things.  A blank version component would be used to identify
all
versions of a given vendor:product.  But what if the platform doesn't
have a
version?  (or more likely doesn't have an edition)  I'm not exactly sure
the
best way forward here.  Is creating a special character(s) going to
cause
problems down the road?

Maybe an even better question is if there really is a difference between
a
name that leaves a component blank and a name that uses a 'null' code.
In
both cases, would the platform type being identified be the same thing?

Definitely looking for more discussion on these points.

Thanks
Drew

---------

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

[Stav Raviv]

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

The following seems to me to be a rather fundamental issue, which must have been talked about before, and yet, I couldn't find a satisfying answer.

So, if I'm missing some really obvious answer, I apologize in advance:

 

Regarding the "CPE is a dictionary, not an encyclopedia" catchphrase:

I agree. CPE should not contain detailed information about the platforms it enumerates within the standard itself.

But I would like to stress the "is a dictionary" part, which, I think, is essential:

 

A dictionary is a kind of mapping from words to their definitions (or to words in another language).

I don't see the "mapping" in CPE. The only thing I can think of is the title, and this is not good enough.

In other words, CPE is not a dictionary, it is a list.

 

Here is my problem:

In order to use CPE as a dictionary I need to know how to find the right CPE name for a certain "real-life object", e.g.-

Let's say I want to use a CPE entry to say I have a certain object I know as "MS Windows 2K Service Pack 2".

How would I know which CPE to use (other than humanly doing the research and then searching through the list for what seems most appropriate)?

 

If the problem is that there's no standardized way to name platforms, how does CPE help relating the different names existing to one official (CPE-) name?

 

Obviously, once all vendors use CPE, there would be no such problem, as the "objects" would come with a "built-in" CPE name. But I'm afraid waiting for this to happen would take some time… In the meantime, I don’t know how to solve the practical mapping problem.

 

And a last word on the subject- we can compare this to the successful CVE standard: Each CVE ID comes with a short description and a list of references that allow one to identify which "object" (vulnerability) that ID refers to.

 

 

Thanks,

(and enjoy the pub meeting at the SCAP conference…)

 

Stav Kaufman-Raviv

Content Team

Skybox Security Ltd.

T: 972-9-9545922 Ext: 201

www.skyboxsecurity.com

 

 

 

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, August 19, 2008 4:27 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

The two threads that have been running on this list the couple of days,

along with the conversations we have had with different users has been

invaluable to us at MITRE.  I can't tell you how excited we are to see

the level of interest in CPE and how important this is for everyone.  I

want to take some time and to confirm some things that I have heard as

well as relay some thoughts of my own.  We are by no means done

gathering information about different uses, but now seems like a great

time to share some of what we have learned.

 

Please note that in addition to this email, I will be sending out

another email more focused on the technical discussion about generic

values that is ongoing.  I'm not ignoring that issue!

 

Regarding the uses of CPE ...

 

=================================

== PROBLEM

=================================

 

I agree with Dave Waltermire in that we are stumbling on truly

understanding CPE because the term "platform" or "platform type" means

different things to different people.  This has lead to conflicting

views as to what 'things' we should be able to tag with a CPE Name, and

about what a CPE Name should look like.

 

For many, the term "platform" represents something that is too broad to

be enumerated by a single enumeration.  Enumerating roles that a system

plays probably requires a different naming convention than enumerating

operating systems.

 

As TK pointed out, the space that we are working in is a graph and

there are more type of relationships than just 'is a member of'.  My

guess is that we find ourselves in this world because we attempted to

enumerate something that was at too high a level.  "Platform" is

probably not the correct 'thing' to enumerate.

 

=================================

== THEORY

=================================

 

I still think Ernest is correct in stating that "CPE is a dictionary,

not an encyclopedia".  The first step in solving the different problems

that we all face is to enumerate the entities that we are dealing with.

In other words, we need to establish a common set of words.

 

My theory is that if we divide CPE up into a number of different

sub-enumerations that we will be better able to come to agreement on

the things that need to identified and how a CPE Name should be viewed

for that specific thing.

 

Kent Landfield also correctly pointed out keeping things simple yet

broad in focus will help an enumeration succeed well down the road.  My

opinion is that by being more specific about the 'things' that we are

enumerating, we will simplify our job of enumerating them.  But by not

limiting ourselves to the types of 'things' that deserve enumerations

we will be able to respond to future needs and be better positioned use

them in ways we don't currently anticipate. 

 

=================================

== FUTURE

=================================

 

I will try to sum up what I have heard so far and bring it together

into an achievable path going forward.  Of course our biggest challenge

might be getting started down such a path (and when to do so) but

hopefully this will all sound like a great direction going forward.

 

One idea would have CPE refocused on enumerating a number of different

things.  Each of these enumerations would likely follow different

naming conventions.  E.g. The vendor:product:version URI might not make

sense for system roles or environments.  Granted maybe we can find a

way to enumerate everyone under one naming convention, but I hope we

aren't going to limit ourselves to this.

 

I think I have seen requests for CPE enumerating:

 

- products / software

- hardware

- roles

- environment (DMZ, intranet)

- patches

- classifications / families

 

I'm sure there are others.  Basically, CPE can split into different

many different smaller enumerations, each helping to identify a small

fact about a platform.  (I'm even more convinced that the word platform

is the source of our problems!!)

 

This notion of facts was actually central to the early ideas running

around CPE (or XCCDF-P).  The idea was that CPE could be used to

identify a fact about a system and the CPE Language could be used to

combine these facts.  This idea lost its momentum because we tried to

fit all the different facts under one single hierarchy.  We all quickly

realized that this would not work.  So we tried to simplify the

hierarchy into a more common (and simple) hierarchy that was more

likely to apply in a general sense.  The problem is that this doesn't

scope very well, and it doesn't work as we move beyond products.

 

The hierarchy might be good for supporting the matching problem, and it

might work at some level for product names, but it falls apart when we

bring in other facts about a platform.

 

There is one additional piece to this puzzle.  A CPE Name cannot be

used to do more than it is intended.  I think many of us see a CPE Name

as something very close to what might be needed to solve our problems

and say "if we can just add this one thing".  My thinking is that this

often comes about because we do not have a way to correctly express the

relationships between the different things.  The CPE Language can play

a central role here.  I would love to think of the CPE Language as a

way of combining different facts about a system into a true platform

definition.  In a way, this would fully return the language back to its

original roots.  (Yes Neal, you were right!!)

 

A powerful CPE Language would allow us to do things that are beyond the

scope of an enumeration, but not at the complexity and power of an OVAL

Definition.  This is actually getting me all excited!!

 

=================================

== WHAT NOW?

=================================

 

Is this the right path to start down?  How do we start down this path?

What do we do in the meantime?  I think that some of these answers will

come about through the use case research we are doing.  Obviously a lot

of the answers depend on how the community continues to support and

foster the growth of CPE.  I cannot stress enough the importance of

sharing your thoughts and points of view.  For now, I think continuing

to push the limits of the current specification and discussing areas

that the spec falls apart will help us better understand how and when

to perform such a transition.

 

I think Version 3 of CPE has the potential to hit a home run!

 

---------

 

Andrew Buttner

The MITRE Corporation

[hidden email]

781-271-3515

 

 

[Ernest Park-2]

I agree with your points. Comments inline . . .

 

On Thu, Aug 21, 2008 at 8:55 AM, Stav Raviv <[hidden email]> wrote:

The following seems to me to be a rather fundamental issue, which must have been talked about before, and yet, I couldn't find a satisfying answer.

So, if I'm missing some really obvious answer, I apologize in advance:

 

Regarding the "CPE is a dictionary, not an encyclopedia" catchphrase:

I agree. CPE should not contain detailed information about the platforms it enumerates within the standard itself.

But I would like to stress the "is a dictionary" part, which, I think, is essential:

 

 

I "interpret" this to understand that we are being given a dictionary with a bunch of names pending resolution. What is missing is how to resolve these. I have suggested standardized extended schemas, qualification for CPE compatible third party apps, standard CPE query structure, and so on.

 

Yes, CPE is a list, nothing more. If we as a group agree on how to grow this, then CPE grows. I believe that if we agree on how to query DBs and XML for accepted standard CPE components, and value added extras, then we can grow a meta-database of CPE information thanks to the interoperability of numerous CPE repositories, all needing that one thing to talk.

 

So, I prefer my analogy - CPE is the phone number to get to who and what you want. It is currently up to you to figure out the rest.

 

A dictionary is a kind of mapping from words to their definitions (or to words in another language).

I don't see the "mapping" in CPE. The only thing I can think of is the title, and this is not good enough.

In other words, CPE is not a dictionary, it is a list.

 

 

It is a list, but hopefully, a constrained one that can grow through the participation of the community to provide additional metadata.

 

Here is my problem:

In order to use CPE as a dictionary I need to know how to find the right CPE name for a certain "real-life object", e.g.-

Let's say I want to use a CPE entry to say I have a certain object I know as "MS Windows 2K Service Pack 2".

How would I know which CPE to use (other than humanly doing the research and then searching through the list for what seems most appropriate)?

 

So, if you use CPE as a list to find things within your application or a third party, it is currently your responsibility to add the content and the usability to each CPE list item.

 

If the problem is that there's no standardized way to name platforms, how does CPE help relating the different names existing to one official (CPE-) name?

 

There was a concept of <alias> and <type>, among others, introduced at CPE developer days. These would give us an accepted way to layer additional metadata into a CPE record, data that could be used in a proprietary fashion, or shared.

 

I add lots of additional metadata, like <license>. For me, license and type are significant. It gives me an ability to check within my software inventory how many of the applications i have to manage are open source, and therefore may not be covered by a vendor agreement. CPE creates a mechanism by which I can talk about my applications to another ISV using hte same language, even though my application is unique, and my specific use of the data is proprietary.

 

I have lots of data about open source software. I can speak to ISVs, and agree that we will together build a virtual database of information, maybe they layer security information on CPEs, I have license and release history, so combined, we have information on what releases in open source are more insecure than others. The thing is that I can build this without an API.

 

CPE is NOT a dictionary, unless that term was intended to represent what they hoped the commercial marketplace would do with it. What CPE is, and should be, is a reliable language for naming, such that my apple and your apple are effectively the same thing.

 

Obviously, once all vendors use CPE, there would be no such problem, as the "objects" would come with a "built-in" CPE name. But I'm afraid waiting for this to happen would take some time… In the meantime, I don't know how to solve the practical mapping problem.

 

 

If the CPE team can get around trying to solve all the use cases, I can push for solving the first. Define qualification for being CPE compatible. Give us a verifiable test so that we know that our databases meet the basic qualification of being able to answer the CPE phone call. If we can do that, perhaps I can expose some of my data, and we will all see alias tags, platforms, type (browser, word processor, etc), license, and more. Perhaps we have to agree to have a standard CPE query, like

 

select part,vendor,application,release from cpe_database

where cve_name IS NOT NULL

and type like '%web_server%"

and license like "%open_source%"

and platform like "%LINUX%"

and part is "HARDWARE"

 

If we all agree on how to describe things, how to alias them, and how to "share" CPE data for our internal community, the use cases may quickly be served by our communal access to a meta-database of interrelated information.

 

 

 

 

 

And a last word on the subject- we can compare this to the successful CVE standard: Each CVE ID comes with a short description and a list of references that allow one to identify which "object" (vulnerability) that ID refers to.

 

 

Thanks,

(and enjoy the pub meeting at the SCAP conference…)

 

Stav Kaufman-Raviv

Content Team

Skybox Security Ltd.

T: 972-9-9545922 Ext: 201

www.skyboxsecurity.com

 

 

 

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]

Sent: Tuesday, August 19, 2008 4:27 AM
To: [hidden email]

Subject: Re: [CPE-DISCUSSION-LIST] Conflicting Technical Use Cases WAS: CPE values for generic systems

 

The two threads that have been running on this list the couple of days,

along with the conversations we have had with different users has been

invaluable to us at MITRE.  I can't tell you how excited we are to see

the level of interest in CPE and how important this is for everyone.  I

want to take some time and to confirm some things that I have heard as

well as relay some thoughts of my own.  We are by no means done

gathering information about different uses, but now seems like a great

time to share some of what we have learned.

 

Please note that in addition to this email, I will be sending out

another email more focused on the technical discussion about generic

values that is ongoing.  I'm not ignoring that issue!

 

Regarding the uses of CPE ...

 

=================================

== PROBLEM

=================================

 

I agree with Dave Waltermire in that we are stumbling on truly

understanding CPE because the term "platform" or "platform type" means

different things to different people.  This has lead to conflicting

views as to what 'things' we should be able to tag with a CPE Name, and

about what a CPE Name should look like.

 

For many, the term "platform" represents something that is too broad to

be enumerated by a single enumeration.  Enumerating roles that a system

plays probably requires a different naming convention than enumerating

operating systems.

 

As TK pointed out, the space that we are working in is a graph and

there are more type of relationships than just 'is a member of'.  My

guess is that we find ourselves in this world because we attempted to

enumerate something that was at too high a level.  "Platform" is

probably not the correct 'thing' to enumerate.

 

=================================

== THEORY

=================================

 

I still think Ernest is correct in stating that "CPE is a dictionary,

not an encyclopedia".  The first step in solving the different problems

that we all face is to enumerate the entities that we are dealing with.

In other words, we need to establish a common set of words.

 

My theory is that if we divide CPE up into a number of different

sub-enumerations that we will be better able to come to agreement on

the things that need to identified and how a CPE Name should be viewed

for that specific thing.

 

Kent Landfield also correctly pointed out keeping things simple yet

broad in focus will help an enumeration succeed well down the road.  My

opinion is that by being more specific about the 'things' that we are

enumerating, we will simplify our job of enumerating them.  But by not

limiting ourselves to the types of 'things' that deserve enumerations

we will be able to respond to future needs and be better positioned use

them in ways we don't currently anticipate. 

 

=================================

== FUTURE

=================================

 

I will try to sum up what I have heard so far and bring it together

into an achievable path going forward.  Of course our biggest challenge

might be getting started down such a path (and when to do so) but

hopefully this will all sound like a great direction going forward.

 

One idea would have CPE refocused on enumerating a number of different

things.  Each of these enumerations would likely follow different

naming conventions.  E.g. The vendor:product:version URI might not make

sense for system roles or environments.  Granted maybe we can find a

way to enumerate everyone under one naming convention, but I hope we

aren't going to limit ourselves to this.

 

I think I have seen requests for CPE enumerating:

 

- products / software

- hardware

- roles

- environment (DMZ, intranet)

- patches

- classifications / families

 

I'm sure there are others.  Basically, CPE can split into different

many different smaller enumerations, each helping to identify a small

fact about a platform.  (I'm even more convinced that the word platform

is the source of our problems!!)

 

This notion of facts was actually central to the early ideas running

around CPE (or XCCDF-P).  The idea was that CPE could be used to

identify a fact about a system and the CPE Language could be used to

combine these facts.  This idea lost its momentum because we tried to

fit all the different facts under one single hierarchy.  We all quickly

realized that this would not work.  So we tried to simplify the

hierarchy into a more common (and simple) hierarchy that was more

likely to apply in a general sense.  The problem is that this doesn't

scope very well, and it doesn't work as we move beyond products.

 

The hierarchy might be good for supporting the matching problem, and it

might work at some level for product names, but it falls apart when we

bring in other facts about a platform.

 

There is one additional piece to this puzzle.  A CPE Name cannot be

used to do more than it is intended.  I think many of us see a CPE Name

as something very close to what might be needed to solve our problems

and say "if we can just add this one thing".  My thinking is that this

often comes about because we do not have a way to correctly express the

relationships between the different things.  The CPE Language can play

a central role here.  I would love to think of the CPE Language as a

way of combining different facts about a system into a true platform

definition.  In a way, this would fully return the language back to its

original roots.  (Yes Neal, you were right!!)

 

A powerful CPE Language would allow us to do things that are beyond the

scope of an enumeration, but not at the complexity and power of an OVAL

Definition.  This is actually getting me all excited!!

 

=================================

== WHAT NOW?

=================================

 

Is this the right path to start down?  How do we start down this path?

What do we do in the meantime?  I think that some of these answers will

come about through the use case research we are doing.  Obviously a lot

of the answers depend on how the community continues to support and

foster the growth of CPE.  I cannot stress enough the importance of

sharing your thoughts and points of view.  For now, I think continuing

to push the limits of the current specification and discussing areas

that the spec falls apart will help us better understand how and when

to perform such a transition.

 

I think Version 3 of CPE has the potential to hit a home run!

 

---------

 

Andrew Buttner

The MITRE Corporation

[hidden email]

781-271-3515

 

 

[Eric Fredericksen]

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

OK. Now you've done it. You made me read through all 30+ pages of the CPE specification. :)

I am not going to try responding to the collection of philosophical positions expressed in this email thread. What I will do is

1) clarify what I was asking for
2) explain why I think the request is reasonable
3) make a proposal that follows the spec and achieves the desired goal
4) make a proposal for a modification of the spec that provides more capability of this type

PLEASE NOTE: I will be using the terms CATEGORY or CATEGORIZATION to mean GROUPING of items into a SET. This is not to be confused with creating a “unique categorization of a platform” by populating the CPE name components with unique values.

IMPORTANT – I would like to get a consensus on (3) before this thread expands the way it did last time. :) I ask this because anything taking the path of (4) (or any other expansion of the spec) will take too long for my current needs. Thanks in advance for your aid in this.

              ======================
1) We (my employer and this community) need to define and communicate CPE item categories (reminder: I mean groupings) that do not require enumeration (and hence constant updating) of all CPE names in the category. The reasons we need this capability were well enunciated in the thread(s) so I will refrain from reiterating them.

The category-type needs stated in my original posting were:

        CPE items with an unknown OS
        CPE items that are routers
        CPE items that are printers
        CPE items with an os in the unix family
       
I am studiously avoiding the terms "system" and "platform" because of the ambiguity involved.

              ======================
2) It looks to me like the CPE specification already supports categorization. I’ll explain.

2.1) The CPE specification does not attempt to follow or enforce a philosophy that CPE names map to a unique product.

CPE section 4. - "Security guidance information and vulnerability information apply to a wide range of product and system categories. For example, some vulnerabilities affect an entire product line, while others affect only a particular product release or version. Some guidance applies to entire product family or system type, but other guidance can apply only to a particular version of an application running on a particular OS release.

• CPE MUST be able to express platform information across a wide range of specificity."

NOTE: There is a specific reference to "system type". I equate the category names unknown, unix, router, and printer to "system type" and categorization falls into "wide range of specificity".

       
2.2) The CPE specification acknowledges that it would be unrealistic to expect that we can design a system that works like IUPAC nomenclature does for chemistry (http://en.wikipedia.org/wiki/International_Union_of_Pure_and_Applied_Chemistry_nomenclature).

       

CPE section 4. - "One of the goals of the CPE Specification is to outline a way for unique names to be created in a defined way. For example, if two people were to try to create a new CPE Name for the same application, the hope is that by following the specification, that they will come up with the same name. It is realized though that this is unrealistic for a requirement."

2.3) The CPE naming structure already explicitly allows definition of categories in the matching algorithm and name structure.

CPE section 5.2 - "Empty components are legal; they designate a part of the platform name for which any aspect of the platform is valid."

CPE section 7.2 - "CPE Name Matching" -
                if comp(X,i) = comp(N,i) or comp(X,i) = ""
                then
                        r := true.
                else
                        r := false.

An empty component entry means "match everything". For example, cpe:/o:microsoft is the category of all Microsoft operating systems. The "prefix property" allows for grouping of across vendors and within products of a vendor. Why should CPE not allow categorization across products as apparently called out in (2.1) above?

              ======================
3) This is a proposal using the current CPE specification.

Here is some text from the specification:

CPE section 5.1 - "Note that the distinction between OS and Application is currently a bit of a grey area. The argument could be made that the OS is just another application."

CPE section 5.5 - "This example name below refers to a Cisco model 3825 integrated services router.
                        cpe:/h:cisco:router:3825"

The example above is already 95% of what I asked for a router class. :)
                       
So, reading the CPE specification without invoking any specific philosophy regarding the proper employment of the CPE specification leads me to propose the following possible solutions. Many use the term "unknown". Why? The OVAL specification has the concept of OS categorization (the family test) – and OVAL 5.5 is adding three new categories to that list. One of those is the category "unknown".

NOTE: There was some discussion of the semantics of "unknown" in this thread. In summary, the question was: “Is the intent of unknown to match every OS or to not match any OS?” I assert that the answer is not only product dependent but use-case dependent. I will therefore avoid taking sides on the "match everything" or "express uncertainty" debate.

                PROPOSED CATEGORY NAMES using CPE 2.1

== CPE items with an unknown OS ==
One or more of the following:

        cpe:/o
        cpe:/o:unknown

== CPE items that are routers ==
One or more of the following:

        cpe:/h::router
        cpe:/a::router
        cpe:/h:unknown:router
        cpe:/a:unknown:router

== CPE items that are printers ==
One or more of the following:

        cpe:/h::printer
        cpe:/a::printer
        cpe:/h:unknown:printer
        cpe:/a:unknown:printer

== CPE items with a UNIX OS ==
One or more of the following:

        cpe:/o:unix
        cpe:/o::unix
        cpe:/o:unknown:unix

This last one feels like it has a worse fit. However, note that OVAL already includes a category of UNIX (in addition to unknown, windows, etc)

STOP HERE! DO NOT READ FURTHER :) (until you respond to (3), please)

              ======================
4) Ok. I know the proposal made in (3) above is not aesthetically pleasing. :) I think that, at least in part, this is because the tokens "router", "printer", and "unix" do not properly fit their slots. They are, arguably, "roles" as indicated in at least one email in this thread. Other folks might want to think of these tokens as tags or attributes applied to the thing of interest. In either case they feel a bit “wrong”.  They “inject impurity” into the CPE names because they are not specific products.

How can we do better? I observed that the XSD for CPE defines an acceptable CPE name component with a regular expression.

                       
        <xsd:pattern value="[c][pP][eE]:/[AHOaho]?(:[A-Za-z0-9\._\-~%]*){0,6}"/>

Perhaps we can alleviate our communal feeling of “wrongness” if we just expand the CPE naming convention to include regular expressions.  We already use regular expressions throughout the SCAP standards, so why not here? Moreover, use of regular expressions would simply require an extension of the matching algorithm as defined in the spec.

According to the specification these CPE names are an equivalence class:

        cpe:/o          cpe:/o:         cpe:/o::                cpe:/o:::
        cpe:/o::::      cpe:/o:::::     cpe:/o::::::

Using simplified regular expression syntax, the category could be expressed abstractly as

        cpe:/o:*        ….      cpe:/o:*:*:*:*:*:*

So printer and router categories might be defined as

        cpe:h:*:*router*

        cpe:h:*:*printer*

Two problems arise here:

a) Using regular expressions requires correctness by convention: CPE component strings must include the required token (e.g., printer or router).

I think that (a) is not a problem because even if we build a categorization extension to CPE where we “tag” or “decorate” individual items with properties we would still be compelled use the same approach: define a set of known tokens for attributes and require that tags be properly applied. Using regular expressions avoids building a whole new tagging or attribute system.

b) The current definition of CPE naming does not allow for insertion of regular expressions.

One method to deal with (b) is to introduce characters that indicate the regex, e.g., curly braces (example using more familiar syntax).

        cpe:{h|o}:cisco:{router|IOS}

A second method to deal with (b) is to introduce an entirely new URN. Call it “cpc” for common platform category (not that I am a fan of creating more TLAs).  This new thing allows regular expressions for defining categories (collections) of CPE names. Defined as: 

        “[c][pP][cC]:{REGEX}?(:{ REGEX }?){0,6}"

where REGEX represents the regular expression. The first { REGEX } instance is to match the “part” component of cpe names. Note that we can retain or omit the “empty entry” syntax to mean “.*” if we wish.

Our example then becomes

        cpc:{h|o}:cisco:{router|IOS}

This approach will provide for a great deal of flexibility in categorization without invoking a heavyweight implementation for categorization.

Regards,
Eric

Eric Fredericksen, PhD
Solutions Architect
Risk and Compliance Business Unit
McAfee, Inc.

949.297.5600 Main
949.297.5574 Direct
949.466.5196 Mobile
949.297.5575 Fax
[hidden email]
www.mcafee.com

This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you.

 

-----Original Message-----
From: Buttner, Drew [[hidden email]]
Sent: Monday, August 18, 2008 7:09 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE values for generic systems

I think I am hearing a request for 3 different technical needs in this
thread.

#1 - ability to name unknown platforms
#2 - ability to enumerate family / type information
#3 - ability to specify 'component does not apply'

For #1, you bring up the example of an unknown operating system.  Doesn't
the name "cpe:/o" satisfy this need?  What this name is supposed to
represent is the platform type of an operating system (any operating
system).  In other words, for your discovery use case, if you want to report
that the system has an operating system installed but that you don't have
any additional information, you could tag that part of the result set with
"cpe:/o"

For #2, I agree that this type of enumeration is needed somewhere.  OVAL
needs the same thing and currently defines a <family> element to relay this
information.  I'm intrigued by Lt. Col Wolfkiel's proposal, but I think some
questions still remain.  I would think that if family information was added
to the current CPE Name structure that it would want to be part of the
matching functionality.  Put another way, if we have a name for Sun Solaris,
that we know that this platform type is part of the UNIX platform type.
Since the UNIX platform type would not have the same vendor component, I
don't see how matching would occur given the [family=xxxxx] proposal.  Are
we trying to push too much information into a name that is suppose to
enumerate a 'thing'?  Is the solution to this have a separate enumeration
for family and then relate CPE Names to a certain family (or multiple
families).  This information could be available in a language format and
carried by those use cases that need such information?

For #3, I can see how this is different than the empty component, which
targets all things.  A blank version component would be used to identify all
versions of a given vendor:product.  But what if the platform doesn't have a
version?  (or more likely doesn't have an edition)  I'm not exactly sure the
best way forward here.  Is creating a special character(s) going to cause
problems down the road?

Maybe an even better question is if there really is a difference between a
name that leaves a component blank and a name that uses a 'null' code.  In
both cases, would the platform type being identified be the same thing?

Definitely looking for more discussion on these points.

Thanks
Drew

---------

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

[Wolfkiel, Joseph]

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

This looks like a proposal.  I suggest we attempt some sort of vetting and approval process to determine if the "community" agrees that it needs to be implemented and how we incorporate it into CPE.  Some questions to be discussed-

 

1.  Does doing the proposed 'things' break the CPE format or usages in the spec?

2.  Regardless of (1), if we do these things, will the new CPE content be backward compatible with the old CPE content?

3.  Based on (1 and 2) above, is this a major or minor change to the spec... or ... is it additional business logic that can be incorporated with no required change to the CPE format?

4.  Once we've resolved the 3 items above, we can "vote" or invoke some other decision making process to decide whether to go ahead then

5.  Figure out what the phase-in timeline should be for anything that gets approved

6.  Formally document what we've decided and move on to the next issue

 

Responses encouraged.

 

my 2 cents:

I agree with the "unknown" case.  It won't cause any incorrect matches and will match with blanks using the spec matching algorithms.  Consistent with "unknown" I would also suggest adding "null" to state that the field should only match with an empty set when compared with other "concrete" (i.e. discoverable) cpes versus everything.

I'm not comfortable with adding function in place of vendor/product/version since it may preclude matching -- i.e. "laserjet" and "printer" should match (in some cases), but don't.  Same issue for putting "UNIX" in the product field in place of LINUX/HPUX/CISCO IOS and other OS's that look enough like UNIX to be functionally equivalent.

 

Bottom line:  I think "unknown" and "null" are easy wins that require no mods to the spec, but the "group" and "function" specifiers do break backwards compatibility and would require some sort of longer-term solution.

 

Lt Col Joseph L. Wolfkiel
Director, Computer Network Defense Research & Technology (CND R&T) Program Management Office
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax [phone]

-----Original Message-----
From: Eric Fredericksen [mailto:[hidden email]]
Sent: Tuesday, August 26, 2008 10:28 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE values for generic systems

OK. Now you've done it. You made me read through all 30+ pages of the CPE specification. :)

I am not going to try responding to the collection of philosophical positions expressed in this email thread. What I will do is

1) clarify what I was asking for
2) explain why I think the request is reasonable
3) make a proposal that follows the spec and achieves the desired goal
4) make a proposal for a modification of the spec that provides more capability of this type

PLEASE NOTE: I will be using the terms CATEGORY or CATEGORIZATION to mean GROUPING of items into a SET. This is not to be confused with creating a "unique categorization of a platform" by populating the CPE name components with unique values.

IMPORTANT - I would like to get a consensus on (3) before this thread expands the way it did last time. :) I ask this because anything taking the path of (4) (or any other expansion of the spec) will take too long for my current needs. Thanks in advance for your aid in this.

              ======================
1) We (my employer and this community) need to define and communicate CPE item categories (reminder: I mean groupings) that do not require enumeration (and hence constant updating) of all CPE names in the category. The reasons we need this capability were well enunciated in the thread(s) so I will refrain from reiterating them.

The category-type needs stated in my original posting were:

        CPE items with an unknown OS
        CPE items that are routers
        CPE items that are printers
        CPE items with an os in the unix family
       
I am studiously avoiding the terms "system" and "platform" because of the ambiguity involved.

              ======================
2) It looks to me like the CPE specification already supports categorization. I'll explain.

2.1) The CPE specification does not attempt to follow or enforce a philosophy that CPE names map to a unique product.

CPE section 4. - "Security guidance information and vulnerability information apply to a wide range of product and system categories. For example, some vulnerabilities affect an entire product line, while others affect only a particular product release or version. Some guidance applies to entire product family or system type, but other guidance can apply only to a particular version of an application running on a particular OS release.

* CPE MUST be able to express platform information across a wide range of specificity."

NOTE: There is a specific reference to "system type". I equate the category names unknown, unix, router, and printer to "system type" and categorization falls into "wide range of specificity".

       
2.2) The CPE specification acknowledges that it would be unrealistic to expect that we can design a system that works like IUPAC nomenclature does for chemistry (http://en.wikipedia.org/wiki/International_Union_of_Pure_and_Applied_Chemistry_nomenclature).

       

CPE section 4. - "One of the goals of the CPE Specification is to outline a way for unique names to be created in a defined way. For example, if two people were to try to create a new CPE Name for the same application, the hope is that by following the specification, that they will come up with the same name. It is realized though that this is unrealistic for a requirement."

2.3) The CPE naming structure already explicitly allows definition of categories in the matching algorithm and name structure.

CPE section 5.2 - "Empty components are legal; they designate a part of the platform name for which any aspect of the platform is valid."

CPE section 7.2 - "CPE Name Matching" -
                if comp(X,i) = comp(N,i) or comp(X,i) = ""
                then
                        r := true.
                else
                        r := false.

An empty component entry means "match everything". For example, cpe:/o:microsoft is the category of all Microsoft operating systems. The "prefix property" allows for grouping of across vendors and within products of a vendor. Why should CPE not allow categorization across products as apparently called out in (2.1) above?

              ======================
3) This is a proposal using the current CPE specification.

Here is some text from the specification:

CPE section 5.1 - "Note that the distinction between OS and Application is currently a bit of a grey area. The argument could be made that the OS is just another application."

CPE section 5.5 - "This example name below refers to a Cisco model 3825 integrated services router.
                        cpe:/h:cisco:router:3825"

The example above is already 95% of what I asked for a router class. :)
                       
So, reading the CPE specification without invoking any specific philosophy regarding the proper employment of the CPE specification leads me to propose the following possible solutions. Many use the term "unknown". Why? The OVAL specification has the concept of OS categorization (the family test) - and OVAL 5.5 is adding three new categories to that list. One of those is the category "unknown".

NOTE: There was some discussion of the semantics of "unknown" in this thread. In summary, the question was: "Is the intent of unknown to match every OS or to not match any OS?" I assert that the answer is not only product dependent but use-case dependent. I will therefore avoid taking sides on the "match everything" or "express uncertainty" debate.

                PROPOSED CATEGORY NAMES using CPE 2.1

== CPE items with an unknown OS ==
One or more of the following:

        cpe:/o
        cpe:/o:unknown

== CPE items that are routers ==
One or more of the following:

        cpe:/h::router
        cpe:/a::router
        cpe:/h:unknown:router
        cpe:/a:unknown:router

== CPE items that are printers ==
One or more of the following:

        cpe:/h::printer
        cpe:/a::printer
        cpe:/h:unknown:printer
        cpe:/a:unknown:printer

== CPE items with a UNIX OS ==
One or more of the following:

        cpe:/o:unix
        cpe:/o::unix
        cpe:/o:unknown:unix

This last one feels like it has a worse fit. However, note that OVAL already includes a category of UNIX (in addition to unknown, windows, etc)

STOP HERE! DO NOT READ FURTHER :) (until you respond to (3), please)

              ======================
4) Ok. I know the proposal made in (3) above is not aesthetically pleasing. :) I think that, at least in part, this is because the tokens "router", "printer", and "unix" do not properly fit their slots. They are, arguably, "roles" as indicated in at least one email in this thread. Other folks might want to think of these tokens as tags or attributes applied to the thing of interest. In either case they feel a bit "wrong".  They "inject impurity" into the CPE names because they are not specific products.

How can we do better? I observed that the XSD for CPE defines an acceptable CPE name component with a regular expression.

                       
        <xsd:pattern value="[c][pP][eE]:/[AHOaho]?(:[A-Za-z0-9\._\-~%]*){0,6}"/>

Perhaps we can alleviate our communal feeling of "wrongness" if we just expand the CPE naming convention to include regular expressions.  We already use regular expressions throughout the SCAP standards, so why not here? Moreover, use of regular expressions would simply require an extension of the matching algorithm as defined in the spec.

According to the specification these CPE names are an equivalence class:

        cpe:/o          cpe:/o:         cpe:/o::                cpe:/o:::
        cpe:/o::::      cpe:/o:::::     cpe:/o::::::

Using simplified regular expression syntax, the category could be expressed abstractly as

        cpe:/o:*        ....      cpe:/o:*:*:*:*:*:*

So printer and router categories might be defined as

        cpe:h:*:*router*

        cpe:h:*:*printer*

Two problems arise here:

a) Using regular expressions requires correctness by convention: CPE component strings must include the required token (e.g., printer or router).

I think that (a) is not a problem because even if we build a categorization extension to CPE where we "tag" or "decorate" individual items with properties we would still be compelled use the same approach: define a set of known tokens for attributes and require that tags be properly applied. Using regular expressions avoids building a whole new tagging or attribute system.

b) The current definition of CPE naming does not allow for insertion of regular expressions.

One method to deal with (b) is to introduce characters that indicate the regex, e.g., curly braces (example using more familiar syntax).

        cpe:{h|o}:cisco:{router|IOS}

A second method to deal with (b) is to introduce an entirely new URN. Call it "cpc" for common platform category (not that I am a fan of creating more TLAs).  This new thing allows regular expressions for defining categories (collections) of CPE names. Defined as: 

        "[c][pP][cC]:{REGEX}?(:{ REGEX }?){0,6}"

where REGEX represents the regular expression. The first { REGEX } instance is to match the "part" component of cpe names. Note that we can retain or omit the "empty entry" syntax to mean ".*" if we wish.

Our example then becomes

        cpc:{h|o}:cisco:{router|IOS}

This approach will provide for a great deal of flexibility in categorization without invoking a heavyweight implementation for categorization.

Regards,
Eric

Eric Fredericksen, PhD
Solutions Architect
Risk and Compliance Business Unit
McAfee, Inc.

949.297.5600 Main
949.297.5574 Direct
949.466.5196 Mobile
949.297.5575 Fax
[hidden email]
www.mcafee.com

This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you.

-----Original Message-----
From: Buttner, Drew [[hidden email]]
Sent: Monday, August 18, 2008 7:09 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE values for generic systems

I think I am hearing a request for 3 different technical needs in this
thread.

#1 - ability to name unknown platforms
#2 - ability to enumerate family / type information
#3 - ability to specify 'component does not apply'

For #1, you bring up the example of an unknown operating system.  Doesn't
the name "cpe:/o" satisfy this need?  What this name is supposed to
represent is the platform type of an operating system (any operating
system).  In other words, for your discovery use case, if you want to report
that the system has an operating system installed but that you don't have
any additional information, you could tag that part of the result set with
"cpe:/o"

For #2, I agree that this type of enumeration is needed somewhere.  OVAL
needs the same thing and currently defines a <family> element to relay this
information.  I'm intrigued by Lt. Col Wolfkiel's proposal, but I think some
questions still remain.  I would think that if family information was added
to the current CPE Name structure that it would want to be part of the
matching functionality.  Put another way, if we have a name for Sun Solaris,
that we know that this platform type is part of the UNIX platform type.
Since the UNIX platform type would not have the same vendor component, I
don't see how matching would occur given the [family=xxxxx] proposal.  Are
we trying to push too much information into a name that is suppose to
enumerate a 'thing'?  Is the solution to this have a separate enumeration
for family and then relate CPE Names to a certain family (or multiple
families).  This information could be available in a language format and
carried by those use cases that need such information?

For #3, I can see how this is different than the empty component, which
targets all things.  A blank version component would be used to identify all
versions of a given vendor:product.  But what if the platform doesn't have a
version?  (or more likely doesn't have an edition)  I'm not exactly sure the
best way forward here.  Is creating a special character(s) going to cause
problems down the road?

Maybe an even better question is if there really is a difference between a
name that leaves a component blank and a name that uses a 'null' code.  In
both cases, would the platform type being identified be the same thing?

Definitely looking for more discussion on these points.

Thanks
Drew

---------

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

[Ernest Park-2]

Great analysis, but I fear a problem -

 

In recent analysis of the existing CPE dictionary and related information, I have seen such issues with data validation, constraint, bad structures, that we want to reduce this to the most simple of subsets to the problem.

 

We all want to extend the capabilities of how we describe software, from granular, at the file level, to macro, at the functional unit level, the type, where it fits in the world. I believe that given the flexibility to use the language as you describe, such can be delivered in a CPE compliant datasource, while the CPE name becomes merely the hook into the data.

 

 

There are two halves of this. The first is the CPE, an enumeration, and the second, a dictionary, more aptly described as a list.

 

If we start to submit regular expressions as part of the naming structure, and start to make CPE names into programmatic strings that need to be parsed, we will then need a CPE parser/validator to confirm that we have a valid CPE expression.

 

Secondly, while it is nice to have a free form structure within which we can describe anything, I still think we can acheive this with a simplified identifier syntax and a database or XML schema that can be queried.

 

 

In the end, the problem is that we still have to agree either on a dictionary (aka, the list), or an API structure, or a query syntax, such that we can either get the list to build off of from a qualified source, or we build the extended data, and we agree that we collect the list via query across approved metadata partners.

 

 

I propose that the theoretical ideals of the original CPE spec to convert a descriptor string into a self contained hierarchical database constrains its own ability to be used and implemented. Further, it increases greatly the difficulty imposed to develop and qualify that "list" data.

 

 

I do feel that the points made are highly relevant and much needed. I do feel that CPE needs to separate into two distinct part in order to more aggressively allow we the community to grow it.

 

First, the list is the holy grail. If we go with a list of structured names, then either CPE's list strategy is to maintain a single list, or maintain a metalist assembled via query across trusted providers.

 

Second, (the enumeration) - we need to develop the XML schema, the database schema or the data constructs that need to exist in order to extend the value of listed information into categories, groups, types, etc, while not trying to make a list into a database. It is the second part that this select community can rapidly participate in. If we agree on the API, or the DB structure, or some uniform set of elements, then we can start to query across multiple data repositories, using only the CPE as the "key" to get us all the additional metadata.

 

 

I would encourage the CPE team to decouple the deliverables of CPE so that they can focus on the first. If they focus on the first, perhaps they can allow the community to participate in the delivery of the second much faster.

 

 

 

Ernest Park

VP, Research Group

Palamida, Inc.

 

 

On Tue, Aug 26, 2008 at 10:27 PM, Eric Fredericksen <[hidden email]> wrote:

OK. Now you've done it. You made me read through all 30+ pages of the CPE specification. :)

I am not going to try responding to the collection of philosophical positions expressed in this email thread. What I will do is

1) clarify what I was asking for
2) explain why I think the request is reasonable
3) make a proposal that follows the spec and achieves the desired goal
4) make a proposal for a modification of the spec that provides more capability of this type

PLEASE NOTE: I will be using the terms CATEGORY or CATEGORIZATION to mean GROUPING of items into a SET. This is not to be confused with creating a "unique categorization of a platform" by populating the CPE name components with unique values.

IMPORTANT – I would like to get a consensus on (3) before this thread expands the way it did last time. :) I ask this because anything taking the path of (4) (or any other expansion of the spec) will take too long for my current needs. Thanks in advance for your aid in this.

              ======================
1) We (my employer and this community) need to define and communicate CPE item categories (reminder: I mean groupings) that do not require enumeration (and hence constant updating) of all CPE names in the category. The reasons we need this capability were well enunciated in the thread(s) so I will refrain from reiterating them.

The category-type needs stated in my original posting were:

        CPE items with an unknown OS
        CPE items that are routers
        CPE items that are printers
        CPE items with an os in the unix family
       
I am studiously avoiding the terms "system" and "platform" because of the ambiguity involved.

              ======================
2) It looks to me like the CPE specification already supports categorization. I'll explain.

2.1) The CPE specification does not attempt to follow or enforce a philosophy that CPE names map to a unique product.

CPE section 4. - "Security guidance information and vulnerability information apply to a wide range of product and system categories. For example, some vulnerabilities affect an entire product line, while others affect only a particular product release or version. Some guidance applies to entire product family or system type, but other guidance can apply only to a particular version of an application running on a particular OS release.

• CPE MUST be able to express platform information across a wide range of specificity."

NOTE: There is a specific reference to "system type". I equate the category names unknown, unix, router, and printer to "system type" and categorization falls into "wide range of specificity".

       
2.2) The CPE specification acknowledges that it would be unrealistic to expect that we can design a system that works like IUPAC nomenclature does for chemistry (http://en.wikipedia.org/wiki/International_Union_of_Pure_and_Applied_Chemistry_nomenclature).

       

CPE section 4. - "One of the goals of the CPE Specification is to outline a way for unique names to be created in a defined way. For example, if two people were to try to create a new CPE Name for the same application, the hope is that by following the specification, that they will come up with the same name. It is realized though that this is unrealistic for a requirement."

2.3) The CPE naming structure already explicitly allows definition of categories in the matching algorithm and name structure.

CPE section 5.2 - "Empty components are legal; they designate a part of the platform name for which any aspect of the platform is valid."

CPE section 7.2 - "CPE Name Matching" -
                if comp(X,i) = comp(N,i) or comp(X,i) = ""
                then
                        r := true.
                else
                        r := false.

An empty component entry means "match everything". For example, cpe:/o:microsoft is the category of all Microsoft operating systems. The "prefix property" allows for grouping of across vendors and within products of a vendor. Why should CPE not allow categorization across products as apparently called out in (2.1) above?

              ======================
3) This is a proposal using the current CPE specification.

Here is some text from the specification:

CPE section 5.1 - "Note that the distinction between OS and Application is currently a bit of a grey area. The argument could be made that the OS is just another application."

CPE section 5.5 - "This example name below refers to a Cisco model 3825 integrated services router.
                        cpe:/h:cisco:router:3825"

The example above is already 95% of what I asked for a router class. :)
                       
So, reading the CPE specification without invoking any specific philosophy regarding the proper employment of the CPE specification leads me to propose the following possible solutions. Many use the term "unknown". Why? The OVAL specification has the concept of OS categorization (the family test) – and OVAL 5.5 is adding three new categories to that list. One of those is the category "unknown".

NOTE: There was some discussion of the semantics of "unknown" in this thread. In summary, the question was: "Is the intent of unknown to match every OS or to not match any OS?" I assert that the answer is not only product dependent but use-case dependent. I will therefore avoid taking sides on the "match everything" or "express uncertainty" debate.

                PROPOSED CATEGORY NAMES using CPE 2.1

== CPE items with an unknown OS ==
One or more of the following:

        cpe:/o
        cpe:/o:unknown

== CPE items that are routers ==
One or more of the following:

        cpe:/h::router
        cpe:/a::router
        cpe:/h:unknown:router
        cpe:/a:unknown:router

== CPE items that are printers ==
One or more of the following:

        cpe:/h::printer
        cpe:/a::printer
        cpe:/h:unknown:printer
        cpe:/a:unknown:printer

== CPE items with a UNIX OS ==
One or more of the following:

        cpe:/o:unix
        cpe:/o::unix
        cpe:/o:unknown:unix

This last one feels like it has a worse fit. However, note that OVAL already includes a category of UNIX (in addition to unknown, windows, etc)

STOP HERE! DO NOT READ FURTHER :) (until you respond to (3), please)

              ======================
4) Ok. I know the proposal made in (3) above is not aesthetically pleasing. :) I think that, at least in part, this is because the tokens "router", "printer", and "unix" do not properly fit their slots. They are, arguably, "roles" as indicated in at least one email in this thread. Other folks might want to think of these tokens as tags or attributes applied to the thing of interest. In either case they feel a bit "wrong".  They "inject impurity" into the CPE names because they are not specific products.

How can we do better? I observed that the XSD for CPE defines an acceptable CPE name component with a regular expression.

                       
        <xsd:pattern value="[c][pP][eE]:/[AHOaho]?(:[A-Za-z0-9\._\-~%]*){0,6}"/>

Perhaps we can alleviate our communal feeling of "wrongness" if we just expand the CPE naming convention to include regular expressions.  We already use regular expressions throughout the SCAP standards, so why not here? Moreover, use of regular expressions would simply require an extension of the matching algorithm as defined in the spec.

According to the specification these CPE names are an equivalence class:

        cpe:/o          cpe:/o:         cpe:/o::                cpe:/o:::
        cpe:/o::::      cpe:/o:::::     cpe:/o::::::

Using simplified regular expression syntax, the category could be expressed abstractly as

        cpe:/o:*        ….      cpe:/o:*:*:*:*:*:*

So printer and router categories might be defined as

        cpe:h:*:*router*

        cpe:h:*:*printer*

Two problems arise here:

a) Using regular expressions requires correctness by convention: CPE component strings must include the required token (e.g., printer or router).

I think that (a) is not a problem because even if we build a categorization extension to CPE where we "tag" or "decorate" individual items with properties we would still be compelled use the same approach: define a set of known tokens for attributes and require that tags be properly applied. Using regular expressions avoids building a whole new tagging or attribute system.

b) The current definition of CPE naming does not allow for insertion of regular expressions.

One method to deal with (b) is to introduce characters that indicate the regex, e.g., curly braces (example using more familiar syntax).

        cpe:{h|o}:cisco:{router|IOS}

A second method to deal with (b) is to introduce an entirely new URN. Call it "cpc" for common platform category (not that I am a fan of creating more TLAs).  This new thing allows regular expressions for defining categories (collections) of CPE names. Defined as: 

        "[c][pP][cC]:{REGEX}?(:{ REGEX }?){0,6}"

where REGEX represents the regular expression. The first { REGEX } instance is to match the "part" component of cpe names. Note that we can retain or omit the "empty entry" syntax to mean ".*" if we wish.

Our example then becomes

        cpc:{h|o}:cisco:{router|IOS}

This approach will provide for a great deal of flexibility in categorization without invoking a heavyweight implementation for categorization.

Regards,
Eric

Eric Fredericksen, PhD
Solutions Architect
Risk and Compliance Business Unit
McAfee, Inc.

949.297.5600 Main
949.297.5574 Direct
949.466.5196 Mobile
949.297.5575 Fax

[hidden email]
www.mcafee.com

This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you.

 

-----Original Message-----

From: Buttner, Drew [[hidden email]]

Sent: Monday, August 18, 2008 7:09 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE values for generic systems

I think I am hearing a request for 3 different technical needs in this
thread.

#1 - ability to name unknown platforms
#2 - ability to enumerate family / type information
#3 - ability to specify 'component does not apply'

For #1, you bring up the example of an unknown operating system.  Doesn't
the name "cpe:/o" satisfy this need?  What this name is supposed to
represent is the platform type of an operating system (any operating
system).  In other words, for your discovery use case, if you want to report
that the system has an operating system installed but that you don't have
any additional information, you could tag that part of the result set with
"cpe:/o"

For #2, I agree that this type of enumeration is needed somewhere.  OVAL
needs the same thing and currently defines a <family> element to relay this
information.  I'm intrigued by Lt. Col Wolfkiel's proposal, but I think some
questions still remain.  I would think that if family information was added
to the current CPE Name structure that it would want to be part of the
matching functionality.  Put another way, if we have a name for Sun Solaris,
that we know that this platform type is part of the UNIX platform type.
Since the UNIX platform type would not have the same vendor component, I
don't see how matching would occur given the [family=xxxxx] proposal.  Are
we trying to push too much information into a name that is suppose to
enumerate a 'thing'?  Is the solution to this have a separate enumeration
for family and then relate CPE Names to a certain family (or multiple
families).  This information could be available in a language format and
carried by those use cases that need such information?

For #3, I can see how this is different than the empty component, which
targets all things.  A blank version component would be used to identify all
versions of a given vendor:product.  But what if the platform doesn't have a
version?  (or more likely doesn't have an edition)  I'm not exactly sure the
best way forward here.  Is creating a special character(s) going to cause
problems down the road?

Maybe an even better question is if there really is a difference between a
name that leaves a component blank and a name that uses a 'null' code.  In
both cases, would the platform type being identified be the same thing?

Definitely looking for more discussion on these points.

Thanks
Drew

---------

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