New CPE Proposals

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

New CPE Proposals

Waltermire, David A.

Members of the CPE community,

 

Two primary use cases exist today that require support from the Common Platform Enumeration (CPE).  They are:

 

1)       The need to identify discrete products that are able to be downloaded, distributed on CDs or DVDs, installed, assessed, inventoried, and/or licensed.  To support this use case CPE Names need to be made non-ambiguous and specific enough to define discrete products.

2)       The need to support robust statements of applicability associating specific products and arbitrary categories of products with other types of information such as: vulnerabilities, configuration guidance, asset records, etc.  The CPE Language needs to have capabilities to support both references to specific products, abstract products and other categories.

 

Both of these use cases are not fully supported by the CPE Specification version 2.1.  Please find two Microsoft Word formatted proposals attached to this email that address the short-comings of CPE related to these use cases.  Both proposals provide recommendations to address the previously stated use cases while providing a high degree of backwards compatibility with the current CPE Specification.  We feel that this is necessary based on the current investment of organizations into CPE-based capabilities.  The following are summaries of the proposals:

 

1)       cpe-canonical-names-proposal

 

This proposal addresses the first use case by adding support to CPE to identify discrete products in a non-ambiguous way.  It recommends adding placeholder values for CPE components that are not applicable to a single release of a product resulting in canonical CPE Names with all 7 components specified.

 

2)       cpe-tagging-proposal

 

This proposal addresses the second use case through the addition of CPE tags that are essentially name/value paired metadata elements that can be used to associate additional product related data with one or more CPE Names.  It also recommends changes to the CPE Language to allow evaluation of these new metadata elements.  Additionally, a process for creating and managing tag definitions in the Official CPE Dictionary is provided to support an Official Tag List that contains common tags that are of general interest to the broad CPE community.

 

In addition to the proposals, updated XML schema documents and examples are attached to illustrate these new capabilities.  I encourage you to review the proposals, XML schema documents and examples and welcome any feedback that you could provide.  I have enabled track changes in the documents if you would like to provide feedback inline.  It is my hope that after 2-4 weeks of discussion that we can address any concerns that the community may have, update the proposals, and then, if these proposals are accepted, work with the CPE moderator to determine a course of action to update the CPE Specification based on these proposals.

 

Sincerely,

 

David Waltermire

NVD/SCAP Development Team Lead

 


cpe-canonical-names-proposal v0.2.zip (15K) Download Attachment
cpe-tagging-proposal v0.5.zip (1M) Download Attachment
cpe-proposal-files v0.5.zip (49K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New CPE Proposals

Mann, Dave
David Waltermire wrote:

> Two primary use cases exist today that require support from the
> Common Platform Enumeration (CPE).  They are:
>
> 1)       The need to identify discrete products that are able to be
> downloaded, distributed on CDs or DVDs, installed, assessed,
> inventoried, and/or licensed.  To support this use case CPE Names
> need to be made non-ambiguous and specific enough to define discrete
> products.    
>
> 2)       The need to support robust statements of applicability
> associating specific products and arbitrary categories of products
> with other types of information such as: vulnerabilities,
> configuration guidance, asset records, etc.  The CPE Language needs
> to have capabilities to support both references to specific products,
> abstract products and other categories.    
[snip...]




Dave (and the rest of the CPE Community),

Thank you for sending out the proposals.  We encourage the entire
CPE community to closely review and comment on them.

By way of an update...

MITRE has been conducting a series of interviews with participants
in the CPE community with the intent of better understanding
current actual usage of CPE.  The goal of this effort is to
document what we refer to as "Technical Use Cases".

We have written up the results of our analysis and are working
with the MITRE internal review processes (and our sponsors) to get
the report approved for public release.  While the wheels of justice
grind on, we'll summarize the results here in this mail in the
hope of providing additional context for the consideration of
the NIST proposals.  We'll try to summarize the results with a
series of 3 kinds of statements: findings (which are results
of our analysis), observations (which are our attempt
to relate the findings to your recent mail) and questions (which
we believe the CPE community will need to decide on).


FINDING: THERE ARE 4 USE CASES - The interviewees identified 4
different uses for CPEs. They are:
  + SOFTWARE INVENTORY MANAGEMENT, which needs to identify units of
    installed and managed software
  + NETWORK BASED DISCOVERY, which needs to track network devices
    discovered by unauthenticated network discovery tools  
  + FORENSIC ANALYSIS/SOFTWARE ARCHITECTURE, which needs to
    identify components of software like libraries, files and
    drivers
  + IT MANAGEMENT, which needs to identify IT "systems" or "roles"
    such as web servers, financial processing systems


FINDING: EACH OF THESE USE CASES IS TIED TO A DIFFERENT TAXONOMIC
OR CATEGORIZATION POINT OF VIEW - The interviews revealed that
proponents of the different use cases tended to categorize the
items in similar ways within each use case.  Summarizing crudely:
  + SOFTWARE INVENTORY MANAGEMENT tends to organize software
    according to who produced the software
  + NETWORK BASED DISCOVERY tends to organize information according
    to network behavior or functionality  
  + FORENSIC ANALYSIS/SOFTWARE ARCHITECTURE tends to organize
    information according to software architecture concepts
  + IT MANAGEMENT tends to organize information according to
    to IT management concepts
   
OBSERVATION: THE DIFFERING POINTS OF VIEW OF THE 4 USE CASES MAY
EXPLAIN MANY OF THE DISAGREEMENTS IN THE CPE COMMUNITY - In so far
as a taxomony or hierarchy can only support a single point of view,
this calls into question CPE's ability to support multiple use
cases given the hierarchical nature of the namespace.

FINDING: THE SOFTWARE INVENTORY USE CASE IS THE ONLY "MUST-HAVE" -
While several of organizations interviewed had secondary interest
in some of the other use cases, there was universal agreement
that the Software Inventory use case was a "must-have".  No
other use case had any where near this level of support.

QUESTION: THE CPE COMMUNITY WILL NEED TO DECIDE BETWEEN FOCUSING
ON THE SINGLE USE CASE THAT IS UNIVERSALLY AGREED TO AS A "MUST-HAVE"
AND ATTEMPTING TO SUPPORT ANY OR ALL OF THE OTHER 3 USE CASES.

FINDING: WITHIN THE SOFTWARE MANAGEMENT USE CASE, "CONCRETE"
NAMES MUST BE SUPPORTED - There is universal agreement that
a necessary feature of CPE that is required to meet this use case
is the construction of so-called "concrete" names which correspond
to actual installable software. [Caveat: While there is general
agreement on the concept of a "concrete" name, there remains some
lingering disagreement on what constitutes a single piece of
software and correspondingly, how much information is required to
adequately create the associated name.]

OBSERVATION: OUR FINDINGS SUPPORT NIST'S CLAIMS THAT THE CONSTRUCTION
OF "CONCRETE" NAMES IS A MUST-HAVE [with the caveat that agreement
must be reached on what constitutes a single  piece of software and
how to name it sufficiently].

FINDING: THERE IS BROAD AGREEMENT THAT CPE 2.1 PROVIDES SUFFICIENT
STRUCTURES TO CREATE "CONCRETE" NAMES BUT LINGERING DISAGREEMENT
REMAINS ON HOW CONCRETE NAMES SHOULD BE CONSTRUCTED WITHIN CPE 2.1 OR
THE NEED TO UPDATE OR EXTEND CPE 2.1 - This finding has 2 aspects
that must be emphasized.  The first is confirmation that CPE 2.1 is
very well matched to needs of a "must-have" feature (concrete names)
of the single "must-have" use case (software management). Second,
lingering disagreement on how to definitively distinguish between
installable software is reflected in lingering disagreement on how
to best utilize or modify CPE 2.1 for this purpose.

OBSERVATION: OUR FINDINGS SUPPORT NIST'S CLAIMS THAT MORE WORK
NEEDS TO BE DONE TO SUPPORT THE CREATION OF "CONCRETE" NAMES.

FINDING: "ABSTRACT" OR "ROLL-UP" NAMES HAVE NOT BEEN CONFIRMED AS
A "MUST-HAVE" FOR THE SOFTWARE MANAGEMENT USE CASE - Relatively
few organizations report using or having plans to use "abstract"
or "roll-up" names.  

OSERVATION: THE FINDINGS DON'T SUPPORT NIST'S CLAIMS THAT "ABSTRACT"
NAMES MUST BE SUPPORTED - This does not mean that "abstract" names
are not a must have - only that our current analysis has not been
able to document that as a finding. This leads us to...

QUESTION: ARE ABSTRACT NAMES A MUST HAVE FOR SOFTWARE INVENTORY
MANAGEMENT? - This question remains unanswered definitively.  
Answering this question will require active engagement and
involvement with the entire CPE Working Group and further
analysis.  

OBSERVATION: DNS, VINs AND ISBNs MAY OFFER HISTORICAL GUIDANCE -
If the CPE community decides that both "concrete" and "abstract"
names need to be supported, DNS may offer some guidance since
a single DNS "name" can be associated with different kinds of
meaning (records).  If the community decides that "abstract"
names are not a must have, the VIN and ISBN systems may offer
some insight.  All VINs represent a single, ownable ("concrete") car
but, you cannot create a VIN to describe the "abstract" set of all
Fords.


We recognize that this bulleted set of findings, observations and
questions is only a crude summary of our analysis that may raise
more questions than it answers.   We are working to get the full
report out as soon as we can and appreciate your patience.


-Dave Mann (on behalf of and in collaboration with Drew Buttner,
 Deb Bodeau and Theresa Fersch)

=================================================================
David Mann   |   CVE & CCE Project   |  The MITRE Corporation
-----------------------------------------------------------------
     e-mail:[hidden email]    |      cell:781.424.6003
=================================================================
Reply | Threaded
Open this post in threaded view
|

Re: New CPE Proposals (U)

Smith, Robert J Mr NII/DoD-CIO
In reply to this post by Waltermire, David A.
UNCLASSIFIED
 
Who sponsors the CPE database of product names and the vetting process?  Please provide me a government organization, name and phone number or you can call me.
 

R/
Bob

(703) 601-4729 ext 124

 


From: David Waltermire [mailto:[hidden email]]
Sent: Friday, October 31, 2008 3:19 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] New CPE Proposals

Members of the CPE community,

 

Two primary use cases exist today that require support from the Common Platform Enumeration (CPE).  They are:

 

1)       The need to identify discrete products that are able to be downloaded, distributed on CDs or DVDs, installed, assessed, inventoried, and/or licensed.  To support this use case CPE Names need to be made non-ambiguous and specific enough to define discrete products.

2)       The need to support robust statements of applicability associating specific products and arbitrary categories of products with other types of information such as: vulnerabilities, configuration guidance, asset records, etc.  The CPE Language needs to have capabilities to support both references to specific products, abstract products and other categories.

 

Both of these use cases are not fully supported by the CPE Specification version 2.1.  Please find two Microsoft Word formatted proposals attached to this email that address the short-comings of CPE related to these use cases.  Both proposals provide recommendations to address the previously stated use cases while providing a high degree of backwards compatibility with the current CPE Specification.  We feel that this is necessary based on the current investment of organizations into CPE-based capabilities.  The following are summaries of the proposals:

 

1)       cpe-canonical-names-proposal

 

This proposal addresses the first use case by adding support to CPE to identify discrete products in a non-ambiguous way.  It recommends adding placeholder values for CPE components that are not applicable to a single release of a product resulting in canonical CPE Names with all 7 components specified.

 

2)       cpe-tagging-proposal

 

This proposal addresses the second use case through the addition of CPE tags that are essentially name/value paired metadata elements that can be used to associate additional product related data with one or more CPE Names.  It also recommends changes to the CPE Language to allow evaluation of these new metadata elements.  Additionally, a process for creating and managing tag definitions in the Official CPE Dictionary is provided to support an Official Tag List that contains common tags that are of general interest to the broad CPE community.

 

In addition to the proposals, updated XML schema documents and examples are attached to illustrate these new capabilities.  I encourage you to review the proposals, XML schema documents and examples and welcome any feedback that you could provide.  I have enabled track changes in the documents if you would like to provide feedback inline.  It is my hope that after 2-4 weeks of discussion that we can address any concerns that the community may have, update the proposals, and then, if these proposals are accepted, work with the CPE moderator to determine a course of action to update the CPE Specification based on these proposals.

 

Sincerely,

 

David Waltermire

NVD/SCAP Development Team Lead

 


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New CPE Proposals

Wolfkiel, Joseph
In reply to this post by Waltermire, David A.
I have a few issues with the NIST proposal that I'd like to hear some opinions on:
 
1.  CPE as a tagged value set.
 
I'm personally convinced we need to go this way for several reasons:
    a.  There are requirements within the CPE names that we just can't address within the structured tree paradigm of the URI structure -- specifically the concept of communicating groups and families (e.g. MS Office, Unix variants, hardware architectures) that are much easier to deal with as tags
    b.  As you'll see from a proposal I plan to release on Monday, we have requirements to add attributes to component names of the CPE, which can't be accommodated within the URI structure
    c.  From a computing effort standpoint, the fact that matching requires you to parse the URIs for component names means that you have to parse twice -- first parse the XML tags, then parse through the URI, which inherently is more effort than just parsing XML
 
2.  CPE tags as flexible tag-value pairs with attributes
    a.    Tag naming as proposed by the NIST document would do away with dedicated tag names (e.g. <version>1.4</version> ) and implement flexible names (e.g. <string-tag-fact-ref name="part" value="o" operator="EQUAL"/>  <string-tag-fact-ref name="vendor" value="Microsoft").  The feedback I've been getting my developers and others in the DoD is that fixed tag names and enumerations build into schemas make processing easier for several reasons, including:
        - Fixed tag names in known sequences make parsing and shredding XML documents into databases significantly easier because you can customize business logic for each dedicated tag name
        - Taking tag names and enumerated lists out of the schemas means you have to validate twice -- once for the XML schema validation, then via some out-of-band process to check against tag definitions and enumerations maintained by NIST for flexible tag types
        -  The dynamic nature of having names and enumerations managed in a parallel process to schemas means that it's no longer possible to use a schema as the definitive test for interoperability.  It may become dynamic and potentially (depending on how often names and enumerations change) difficult to maintain
        - Going to dynamic tags means that every vendor has to trust every other vendor to correctly implement standard tags, with no common way to check for inconsistencies
 
I do see a need for dynamic tags so vendor products can support unanticipated data needs, particularly when they are unique to a vendor product, or a small community, but I have serious concerns about making all tags dynamic in nature.  My personal recommendation was to develop a community list of fixed tags and enumerations, then use the flexible tag types to address evolving tag types or for special interest data needs.
 
Does anyone agree/disagree?
 
- Joe Wolfkiel
 
 
 
 

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

-----Original Message-----
From: David Waltermire [mailto:[hidden email]]
Sent: Friday, October 31, 2008 3:19 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] New CPE Proposals

Members of the CPE community,

 

Two primary use cases exist today that require support from the Common Platform Enumeration (CPE).  They are:

 

1)       The need to identify discrete products that are able to be downloaded, distributed on CDs or DVDs, installed, assessed, inventoried, and/or licensed.  To support this use case CPE Names need to be made non-ambiguous and specific enough to define discrete products.

2)       The need to support robust statements of applicability associating specific products and arbitrary categories of products with other types of information such as: vulnerabilities, configuration guidance, asset records, etc.  The CPE Language needs to have capabilities to support both references to specific products, abstract products and other categories.

 

Both of these use cases are not fully supported by the CPE Specification version 2.1.  Please find two Microsoft Word formatted proposals attached to this email that address the short-comings of CPE related to these use cases.  Both proposals provide recommendations to address the previously stated use cases while providing a high degree of backwards compatibility with the current CPE Specification.  We feel that this is necessary based on the current investment of organizations into CPE-based capabilities.  The following are summaries of the proposals:

 

1)       cpe-canonical-names-proposal

 

This proposal addresses the first use case by adding support to CPE to identify discrete products in a non-ambiguous way.  It recommends adding placeholder values for CPE components that are not applicable to a single release of a product resulting in canonical CPE Names with all 7 components specified.

 

2)       cpe-tagging-proposal

 

This proposal addresses the second use case through the addition of CPE tags that are essentially name/value paired metadata elements that can be used to associate additional product related data with one or more CPE Names.  It also recommends changes to the CPE Language to allow evaluation of these new metadata elements.  Additionally, a process for creating and managing tag definitions in the Official CPE Dictionary is provided to support an Official Tag List that contains common tags that are of general interest to the broad CPE community.

 

In addition to the proposals, updated XML schema documents and examples are attached to illustrate these new capabilities.  I encourage you to review the proposals, XML schema documents and examples and welcome any feedback that you could provide.  I have enabled track changes in the documents if you would like to provide feedback inline.  It is my hope that after 2-4 weeks of discussion that we can address any concerns that the community may have, update the proposals, and then, if these proposals are accepted, work with the CPE moderator to determine a course of action to update the CPE Specification based on these proposals.

 

Sincerely,

 

David Waltermire

NVD/SCAP Development Team Lead

 


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New CPE Proposals

Eric Fredericksen
In reply to this post by Waltermire, David A.
My apologies if these remarks a bit late. These are my observations related to the cpe tagging proposal.
Regards,
Eric
 
 
 
Requirement 10 - A vendor SHOULD be able to declare tags against CPE names without having to create or modify a full-blown CPE dictionary. The proposed tree organization provides economy of initial expression in the case where we desire to apply a new tag to the entire subtree. However, in the case of adding new cpe instances to the tree there is no savings. The same issue must be faced whether a linear list or a tree-based representation is used - a decision must be made whether the existing tags apply to the new node and appropriate changes made.
 
Question: Why are we not using XML namespaces to differentiate source rather than an atrribute containing that namespace?
 
7.2.1 Para2 - see Requirement 10 comment above
 
7.2.2 - We should be careful of trying to optimize for SAX parsers at the expense of DOM parsing methods. Neither approcah should be favored.
 
7.2.3 - Where is the vendor freedom in defining types? - This problem could of course be remedied by adding
 
 <xsd:anyAttribute namespace="##other" processContents="lax" />
 
and
 
 <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="##other"  processContents="lax"/>
 
in the appropriate locations for each record type, providing freedom while allowing the consumer to toss out content that is unknown or untrusted (content from an unknown namespace).
 
It also looks like we are reinventing XSD by using XML to define the acceptable types. I would think that simply using a substitution group or appropriate namespaces would be a better design.
 
7.2.3.2
What requirement does this satisfy? It seems like something related to a UI implementation, which should not be part of this specification. Morever, this part of the specification should *not* depend on the CPE language (see comments below).
 
We *do* need a method for tag application other than inserting items into a tree structure. Restriction of tag application, however, does not IMO have a use case.
 

7.2.4 - Regarding the note text. The argument regarding computational complexity w.r.t. implementing a matching algorithm is only applicable if a specific implementation (and hence parsed representation) is assumed. For example, an XPath expression applied to a list (which can be automatically indexed by the XSLT processor for speed) is extremely simple. The equivalent search of a tree may be much more complex.
 
To be clear, it is unlikely that everyone will parse the tree encoding of the tags and then continue to represent the data directly as a tree structure. For example, SQL is table based. The decomposition may be a direct encoding of the tree but may also be the actual list of fully-tagged cpe entries. This latter is the natural representaiton for indexed data in a relational database.
 
7.3.1 - We are having a proliferation of different mathematical operation symbols. Oval uses lower case words with spaces. This sections uses UPPER_CASE_WORDS_WITH_UNDERSCORES.  We need to be consistent across all SCAP standards.
 
Section 8: I agree with the decomposition of the three components. However, the CPE Dictionary really should have no dependence on the CPE language matching system. The CPE language is, IMO, an overcomplication that we don't really need and is not currently in (widespread) use, to my knowledge. Of course satisfying that requirement would mean revision of the current schema.

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


From: David Waltermire [mailto:[hidden email]]
Sent: Friday, October 31, 2008 12:19 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] New CPE Proposals

Members of the CPE community,

 

Two primary use cases exist today that require support from the Common Platform Enumeration (CPE).  They are:

 

1)       The need to identify discrete products that are able to be downloaded, distributed on CDs or DVDs, installed, assessed, inventoried, and/or licensed.  To support this use case CPE Names need to be made non-ambiguous and specific enough to define discrete products.

2)       The need to support robust statements of applicability associating specific products and arbitrary categories of products with other types of information such as: vulnerabilities, configuration guidance, asset records, etc.  The CPE Language needs to have capabilities to support both references to specific products, abstract products and other categories.

 

Both of these use cases are not fully supported by the CPE Specification version 2.1.  Please find two Microsoft Word formatted proposals attached to this email that address the short-comings of CPE related to these use cases.  Both proposals provide recommendations to address the previously stated use cases while providing a high degree of backwards compatibility with the current CPE Specification.  We feel that this is necessary based on the current investment of organizations into CPE-based capabilities.  The following are summaries of the proposals:

 

1)       cpe-canonical-names-proposal

 

This proposal addresses the first use case by adding support to CPE to identify discrete products in a non-ambiguous way.  It recommends adding placeholder values for CPE components that are not applicable to a single release of a product resulting in canonical CPE Names with all 7 components specified.

 

2)       cpe-tagging-proposal

 

This proposal addresses the second use case through the addition of CPE tags that are essentially name/value paired metadata elements that can be used to associate additional product related data with one or more CPE Names.  It also recommends changes to the CPE Language to allow evaluation of these new metadata elements.  Additionally, a process for creating and managing tag definitions in the Official CPE Dictionary is provided to support an Official Tag List that contains common tags that are of general interest to the broad CPE community.

 

In addition to the proposals, updated XML schema documents and examples are attached to illustrate these new capabilities.  I encourage you to review the proposals, XML schema documents and examples and welcome any feedback that you could provide.  I have enabled track changes in the documents if you would like to provide feedback inline.  It is my hope that after 2-4 weeks of discussion that we can address any concerns that the community may have, update the proposals, and then, if these proposals are accepted, work with the CPE moderator to determine a course of action to update the CPE Specification based on these proposals.

 

Sincerely,

 

David Waltermire

NVD/SCAP Development Team Lead