Re: Query on Cpe 2.2 application entries

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

Re: Query on Cpe 2.2 application entries

Brant Cheikes
Hi Thomas,

You have put your finger on an important issue with the operational use of
CPE to support security automation.  What you've described is the "mapping
problem"--the challenge of inspecting a computing endpoint and mapping
"software signatures" (fingerprints of software discovered to be installed
on computer storage media) to official CPE names.

The mapping problem exists in CPE (in v2.2 as well as the
soon-to-be-released v2.3 specification suite) by deliberate choice.  As
you've noticed, the specification makes provision for a "check" element to
be associated with each cpe-item in the official dictionary.  The intention
here was to create a placeholder for just the kind of information you've
suggested, e.g., the identifier of an OVAL check.

In practice, this feature is unused.  There are several reasons why.  First,
there have been concerns about tightly linking CPE to some other
endpoint-testing standard such as OVAL.  Second, if we don't leverage
another standard, it isn't clear how to define an approach that will work
smoothly across all operating systems.  Third, there's a question of whether
the solution to the mapping problem is rightly left to vendors--this could
be a legitimate realm for innovation and competing approaches.  Lastly, and
perhaps the major reason, the Government has understandably been reluctant
to take on the responsibility (and apply the needed resources) for doing the
necessary research and testing for every CPE name in the dictionary.  We've
considered shifting the burden onto submitters, but thus far have decided
against that due to the belief that this would create a major barrier to
submission.  (Also, that approach doesn't address the 25K+ existing
dictionary entries.)

In sum, this is a known limitation of CPE.  That said, I'm aware of at least
one effort, led by Joe Wolfkiel (Defense Information Systems Agency), to
develop an approach for automatically generating CPE names from, e.g.,
Windows metadata registries, Linux RPM databases, etc.  This attacks the
problem in a novel way, eliminating the mapping problem entirely by building
names automatically in the first place.  I expect to hear more discussion of
this at the upcoming Developer Days conference sponsored by NIST.

I invite others on the CPE list (cc'd) to chime in as well.

Cheers,
/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]

Sent: Tuesday, March 08, 2011 6:18 AM
To: CPE
Subject: Query on Cpe 2.2 application entries


Hi All,
          I have a specific question on cpe 2.2 specification for
application entries e.g. cpe:/a:vendor:product:version.

Observation:
Currently cpe 2.2 is of the following format:
cpe:/part:/vendor:product:version:update:edition:language

Now say, we have a cpe entry [in accordance with cpe 2.2]:
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en

for the below product:
Adobe Reader Lite 9.0.0 Revision 2 Professional Edition English

Query:
Do we have any way to determine whether this cpe entry(i.e. application) is
installed on a system.
i.e. If I have this cpe entry, how can I determine whether this specific
software is installed on a system or not.

Some suggestion:
1. Can we think of a way of map or something which will help the system to
determine whether the cpe entry is existing on a system.
A. All the cpe entries should have a way to determine whether it is existing
on a system or not.
By mapping it to say, registry key test or file test and so on.

2. When the cpe dictionary is published, along with that for every cpe entry
if the oval checks are mapped then it will be very much clear as to what are
the properties to search for a particular cpe entry.

What is the need:
1. I have a system which gets cpe entry as input[Only cpe entry as input and
no other details].
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
And I need to determine whether this cpe entry is valid on a particular
system.

Thanks,
Thomas



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

Re: Query on Cpe 2.2 application entries (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification:  UNCLASSIFIED
Caveats: NONE

Actually, our approach solves the problem in a limited way that we're trying to figure out how to scale across multiple vendor products and data sources.  I do plan to talk about this a developer days.  If I can find some time over the next couple of days, I'll write up some of the issues we've run into and the short-term solutions we're planning to use so we can have a more informed discussion in a couple of weeks.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]

-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Tuesday, March 08, 2011 8:50 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Query on Cpe 2.2 application entries

Hi Thomas,

You have put your finger on an important issue with the operational use of
CPE to support security automation.  What you've described is the "mapping
problem"--the challenge of inspecting a computing endpoint and mapping
"software signatures" (fingerprints of software discovered to be installed
on computer storage media) to official CPE names.

The mapping problem exists in CPE (in v2.2 as well as the
soon-to-be-released v2.3 specification suite) by deliberate choice.  As
you've noticed, the specification makes provision for a "check" element to
be associated with each cpe-item in the official dictionary.  The intention
here was to create a placeholder for just the kind of information you've
suggested, e.g., the identifier of an OVAL check.

In practice, this feature is unused.  There are several reasons why.  First,
there have been concerns about tightly linking CPE to some other
endpoint-testing standard such as OVAL.  Second, if we don't leverage
another standard, it isn't clear how to define an approach that will work
smoothly across all operating systems.  Third, there's a question of whether
the solution to the mapping problem is rightly left to vendors--this could
be a legitimate realm for innovation and competing approaches.  Lastly, and
perhaps the major reason, the Government has understandably been reluctant
to take on the responsibility (and apply the needed resources) for doing the
necessary research and testing for every CPE name in the dictionary.  We've
considered shifting the burden onto submitters, but thus far have decided
against that due to the belief that this would create a major barrier to
submission.  (Also, that approach doesn't address the 25K+ existing
dictionary entries.)

In sum, this is a known limitation of CPE.  That said, I'm aware of at least
one effort, led by Joe Wolfkiel (Defense Information Systems Agency), to
develop an approach for automatically generating CPE names from, e.g.,
Windows metadata registries, Linux RPM databases, etc.  This attacks the
problem in a novel way, eliminating the mapping problem entirely by building
names automatically in the first place.  I expect to hear more discussion of
this at the upcoming Developer Days conference sponsored by NIST.

I invite others on the CPE list (cc'd) to chime in as well.

Cheers,
/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]

Sent: Tuesday, March 08, 2011 6:18 AM
To: CPE
Subject: Query on Cpe 2.2 application entries


Hi All,
          I have a specific question on cpe 2.2 specification for
application entries e.g. cpe:/a:vendor:product:version.

Observation:
Currently cpe 2.2 is of the following format:
cpe:/part:/vendor:product:version:update:edition:language

Now say, we have a cpe entry [in accordance with cpe 2.2]:
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en

for the below product:
Adobe Reader Lite 9.0.0 Revision 2 Professional Edition English

Query:
Do we have any way to determine whether this cpe entry(i.e. application) is
installed on a system.
i.e. If I have this cpe entry, how can I determine whether this specific
software is installed on a system or not.

Some suggestion:
1. Can we think of a way of map or something which will help the system to
determine whether the cpe entry is existing on a system.
A. All the cpe entries should have a way to determine whether it is existing
on a system or not.
By mapping it to say, registry key test or file test and so on.

2. When the cpe dictionary is published, along with that for every cpe entry
if the oval checks are mapped then it will be very much clear as to what are
the properties to search for a particular cpe entry.

What is the need:
1. I have a system which gets cpe entry as input[Only cpe entry as input and
no other details].
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
And I need to determine whether this cpe entry is valid on a particular
system.

Thanks,
Thomas


Classification:  UNCLASSIFIED
Caveats: NONE


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

Re: Query on Cpe 2.2 application entries

steveklos
In reply to this post by Brant Cheikes
Thomas and Brant,

I apologize in advance for the length of this e-mail, but wanted to make
sure that the CPE team gets an understanding of a broader set of use cases
that are directly relevant to the CPE naming issue.  Also, so that everyone
is aware of my background - I was the convener of the ISO/IEC 19770-2:2009
standard and I am the executive director of TagVault.org - the non-profit
registration and certification authority for SWID tags.  

Background

The issue of mapping CPE names to software installed on a device is
relatively complicated.  As mentioned, Joseph Wolfkiel been working on a
process to take inventory from a system and derive a CPE name from the
inventoried items.  From a security automation perspective, this approach
will potentially handle a fair number of use cases.

I look at the problem from a slightly different perspective - one with a
wider scope than just the CPE names.  Basically, software identification on
a computing device is required for a number of different reasons, these
include, but are not limited to:

  - Patch management (CPE related)
  - Configuration management  (CPE related)
  - License compliance
  - License optimization
  - Organizational processes compliance
  - Security compliance
  - Desktop management

My view on this, is if a process can be defined and implemented that
provides authoritative and software identification information, this
information will be used by any IT process that includes the requirement to
know exactly what is installed on a computing device.  CPE names accommodate
a few of these uses cases, but as they are currently defined, do not cover
all of them.  

One example - in many instances, a Windows device could have Microsoft SQL
server installed.  From a security automation perspective, organizations
likely don't care if they have SQL Compact, SQL Developer, SQL Express, SQL
Workgroup, SQL Standard, SQL Enterprise or SQL Datacenter installed - what
they care about is that all patches for the SQL installed on that particular
device are installed.  However, when it comes to License compliance, license
optimization, organizational process compliance and desktop management,
organizations need to know the different edition of SQL installed.

On my computer, for example, I have an entry in Add/Remove programs that
specifies (Microsoft SQL Server).  I happen to know that it's the compact
version because it was deployed with another application, but unless I know
that, I would generally have to either get the activation code that was used
and pull that code apart, or make a specific API call to get that
information.  When you look at the differences in licensing costs between
these versions, it can range from free to ~ $80,000.  

It's also understandable that companies do not want to provide a CPE
reference - that solves only one use case and it's not a use case that helps
the companies to sell more software and/or to solve a problem that's high
enough on their priority list.  Note, I'm not at all saying that companies
don't believe it's important, just that it's not above their cut line for
priorities that they need to apply in order to continue to move the
company's stock price upward (which is the goal of a publically traded
company).

I also want to point out that software identification is just as critical to
a cloud and virtual machine environment as it is to physical devices.  

Finally, there are multiple organizations that have application recognition
libraries that attempt to determine what's installed based on a few key
files or registry entries, or product keys.  None of these is, or ever will
be complete because new software is continually hitting the market and there
is simply no way that any one organization can catalog the entire worlds
software titles.  These tools typically excel in one market or another or
one set of publishers or another...  There are many issues with these tools
that I won't get into, but suffice it to say that each library is a
proprietary library and each is different and unique from the others.  

ISO/IEC Proposed Solution

WG21, the Software Asset Management (SAM) working group, recognized the
problem of software identification as a critical one to improving overall IT
processes - specifically as they apply to license compliance and license
optimization.  However, as the standard was developed, the needs of other IT
requirements were considered and included in the thinking for the overall
needs.  The result of this work ended up being the ISO/IEC 19770-2:2009
Software Identification (SWID) Tagging standard.  

This standard puts forth an XML structure for software identification that
includes 7 mandatory elements and 30 optional.  The standard also allows
extensions as required with the thought that the more commercially used
extensions will be rolled back into the standard when it comes back up for
revision in 2014 (5 years after publication).

The goal of the standard is to provide a consistent method that any
publisher can provide application recognition details for any application on
any platform and do so in a consistent and (preferably) authoritative
manner.

Commercial Application of 19770-2:2009

I won't get into all the background and specifics, but Adobe (which has
traditionally had significant problems in the market when it comes to
software identification procedures - the result of which is confusion and
concern from their customer base) has already implemented SWID tags in their
Creative Suite version 4 and 5 products.  Doing this makes it trivial to
determine if an Adobe product was installed as part of a suite, or as a
standalone product and it also makes it absolutely clear which product is
installed (example, depending on the library used and the order of filters
applied, a review of Adobe software would result in a significant number of
devices showing that Adobe Acrobat Professional was installed, when in fact,
only a few devices had Acrobat Professional and most devices only had Reader
installed).

Symantec, CA and ModusLink founded a non-profit registration and
certification organization called TagVault.org under the auspices of the
IEEE-ISTO.  This program has developed tools to create, validate and
digitally sign SWID tags (the digital signatures provide authoritative
identification capabilities) as well as tools to verify signed SWID tags.
The program also provides processes, certification requirements,
documentation and other information to support the creation and use of SWID
tags in the market.

Symantec has already released products with certified tags provided and has
been expanding that program.  You can go to the TagVault.org website to get
their public statement of support for SWID tags.

Additionally, tool providers have already started to support tags as well.
At the moment, Aspera, CA Technologies, MagniComp, Sassafras Software,
Software Management.org and Symantec all have tools that support the
collection and use of SWID tags.  Again, you can look at the tagvault.org
website for some details on this (see best use of tags).

Commercial pickup of any standard requires market demand.  That demand is
now coming from software purchasing organizations.  The Air Force is
requiring SWID tags in their NETCENTS 2 RFP and the GSA includes language
for their SmartBUY program that requires SWID tags.  Other large enterprise
organizations are starting to apply the same requirement - primarily because
these organizations sign off that a software publisher can audit them at any
time.  That being the case, organizations need to make certain they are
compliant with their licenses, but the process of identifying software is
incredibly difficult and expensive to do properly.  So, when it comes to
buying new software, enterprises are either negotiating the software
identification tag into the product (so they know if something is installed
or not), or negotiating the audit clauses out because the software publisher
is not providing specific details required to ID if a software title is
installed or not.

What does all this mean to CPE?

Software publishers have a commercial incentive to include SWID tags in
their products (in fact, they have a commercial incentive to include
certified tags, but I won't go into all the reasons why).  These tags
include a unique_id element.  The tags also include the ability to specify
relationships - meaning that if a patch is created as part of the software
lifecycle, the SWID tag that goes along with the patch references the
product (or products) that it can be applied to.  

Since the publishers have an incentive to provide SWID tags, these can be
used as part of the CPE process.  I won't say at the moment, that the unique
reference information will replace the CPE name - I think there's more
analysis that's required.  However, I do believe that having the publishers
provide this information in a way that the CPE naming process can be
automated is a benefit to the publishing community, the CPE community, the
tools/systems/processes that use the CPE names and, ultimately the ability
to more fully automate the security processes for computing devices.

An added value to the CPE team is that the details in the SWID Tag provide a
significant amount of metadata about the software products that can be used
in conjunction with existing data sources.

I've presented the details of the 19770-2:2009 standard (as well as
TagVault.orgs efforts to normalize terms and provide authoritative
signatures to SWID tags) to the security automation team at NIST as well as
a few of the other CPE members.  I do not believe it makes any sense to
change what's happening with CPE 2.3, but do think it's worth discussing
where CPE is going and how it can be moved from a volunteer or best effort
approach into a commercially consistent and automated approach that provides
significantly more value to all software ecosystem members.

I'd love to be at Developer Days, but working for a non-profit, the budget
isn't available to attend that event.  However, TagVault.org is having a
Software Identification Summit in May in Herndon, VA.  This forum will have
organizations from all parts of the software ecosystem in attendance from
software publisher to tool provider to software purchasing organizations.
The goal of this forum is to attack the problem head on from the top down
and to provide a solution that lowers cost and resource considerations for
all organizations while at the same time significantly increasing the
visibility of the problem.  There is a facilities fee of $75 for the summit
to help defray the costs, but there is no other cost involved (other than
travel if you are not in the local area).

Cheers,

Steve Klos

-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Tuesday, March 08, 2011 5:50 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Query on Cpe 2.2 application entries

Hi Thomas,

You have put your finger on an important issue with the operational use of
CPE to support security automation.  What you've described is the "mapping
problem"--the challenge of inspecting a computing endpoint and mapping
"software signatures" (fingerprints of software discovered to be installed
on computer storage media) to official CPE names.

The mapping problem exists in CPE (in v2.2 as well as the
soon-to-be-released v2.3 specification suite) by deliberate choice.  As
you've noticed, the specification makes provision for a "check" element to
be associated with each cpe-item in the official dictionary.  The intention
here was to create a placeholder for just the kind of information you've
suggested, e.g., the identifier of an OVAL check.

In practice, this feature is unused.  There are several reasons why.  First,
there have been concerns about tightly linking CPE to some other
endpoint-testing standard such as OVAL.  Second, if we don't leverage
another standard, it isn't clear how to define an approach that will work
smoothly across all operating systems.  Third, there's a question of whether
the solution to the mapping problem is rightly left to vendors--this could
be a legitimate realm for innovation and competing approaches.  Lastly, and
perhaps the major reason, the Government has understandably been reluctant
to take on the responsibility (and apply the needed resources) for doing the
necessary research and testing for every CPE name in the dictionary.  We've
considered shifting the burden onto submitters, but thus far have decided
against that due to the belief that this would create a major barrier to
submission.  (Also, that approach doesn't address the 25K+ existing
dictionary entries.)

In sum, this is a known limitation of CPE.  That said, I'm aware of at least
one effort, led by Joe Wolfkiel (Defense Information Systems Agency), to
develop an approach for automatically generating CPE names from, e.g.,
Windows metadata registries, Linux RPM databases, etc.  This attacks the
problem in a novel way, eliminating the mapping problem entirely by building
names automatically in the first place.  I expect to hear more discussion of
this at the upcoming Developer Days conference sponsored by NIST.

I invite others on the CPE list (cc'd) to chime in as well.

Cheers,
/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]

Sent: Tuesday, March 08, 2011 6:18 AM
To: CPE
Subject: Query on Cpe 2.2 application entries


Hi All,
          I have a specific question on cpe 2.2 specification for
application entries e.g. cpe:/a:vendor:product:version.

Observation:
Currently cpe 2.2 is of the following format:
cpe:/part:/vendor:product:version:update:edition:language

Now say, we have a cpe entry [in accordance with cpe 2.2]:
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en

for the below product:
Adobe Reader Lite 9.0.0 Revision 2 Professional Edition English

Query:
Do we have any way to determine whether this cpe entry(i.e. application) is
installed on a system.
i.e. If I have this cpe entry, how can I determine whether this specific
software is installed on a system or not.

Some suggestion:
1. Can we think of a way of map or something which will help the system to
determine whether the cpe entry is existing on a system.
A. All the cpe entries should have a way to determine whether it is existing
on a system or not.
By mapping it to say, registry key test or file test and so on.

2. When the cpe dictionary is published, along with that for every cpe entry
if the oval checks are mapped then it will be very much clear as to what are
the properties to search for a particular cpe entry.

What is the need:
1. I have a system which gets cpe entry as input[Only cpe entry as input and
no other details].
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
And I need to determine whether this cpe entry is valid on a particular
system.

Thanks,
Thomas
Reply | Threaded
Open this post in threaded view
|

FW: Query on Cpe 2.2 application entries

Brant Cheikes
In reply to this post by Brant Cheikes
Forwarded to discussion list at sender's request:

-----Original Message-----
From: White, Douglas R.
Sent: Tuesday, March 08, 2011 8:57 PM
To: CPE Community Forum
Subject: RE: Query on Cpe 2.2 application entries

If I understand the question correctly,
NSRL has been working (slowly) on this problem.
We showed a proof-of-concept - coincidentally using Adobe 8 & 9 -
at IEEE HST in 2009.
see http://www.nsrl.nist.gov/Documents/WHITE-ieee-hst-09.pdf

We can link vulnerability announcements to file signatures,
registry entries and active RAM on endpoint systems.
The hard work is in mapping the NSRL description of
an "application" to the CPE name string.

Douglas White              National Institute of Standards and Technology
NIST, 100 Bureau Drive Stop 8970, Gaithersburg, MD 20899-8970
     National Software Reference Library - http://www.nsrl.nist.gov
Voice: 301-975-4761     Fax: 301-975-6097   Email: [hidden email]
My opinions aren't necessarily my employer's nor any other organization's.
虎馬苹果
________________________________________
From: Cheikes, Brant A. [[hidden email]]
Sent: Tuesday, March 08, 2011 8:49 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Query on Cpe 2.2 application entries

Hi Thomas,

You have put your finger on an important issue with the operational use of
CPE to support security automation.  What you've described is the "mapping
problem"--the challenge of inspecting a computing endpoint and mapping
"software signatures" (fingerprints of software discovered to be installed
on computer storage media) to official CPE names.

[snip]

In sum, this is a known limitation of CPE.  That said, I'm aware of at least
one effort, led by Joe Wolfkiel (Defense Information Systems Agency), to
develop an approach for automatically generating CPE names from, e.g.,
Windows metadata registries, Linux RPM databases, etc.  This attacks the
problem in a novel way, eliminating the mapping problem entirely by building
names automatically in the first place.  I expect to hear more discussion of
this at the upcoming Developer Days conference sponsored by NIST.

I invite others on the CPE list (cc'd) to chime in as well.

Cheers,
/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]

Sent: Tuesday, March 08, 2011 6:18 AM
To: CPE
Subject: Query on Cpe 2.2 application entries


Hi All,
          I have a specific question on cpe 2.2 specification for
application entries e.g. cpe:/a:vendor:product:version.

Observation:
Currently cpe 2.2 is of the following format:
cpe:/part:/vendor:product:version:update:edition:language

Now say, we have a cpe entry [in accordance with cpe 2.2]:
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en

for the below product:
Adobe Reader Lite 9.0.0 Revision 2 Professional Edition English

Query:
Do we have any way to determine whether this cpe entry(i.e. application) is
installed on a system.
i.e. If I have this cpe entry, how can I determine whether this specific
software is installed on a system or not.

Some suggestion:
1. Can we think of a way of map or something which will help the system to
determine whether the cpe entry is existing on a system.
A. All the cpe entries should have a way to determine whether it is existing
on a system or not.
By mapping it to say, registry key test or file test and so on.

2. When the cpe dictionary is published, along with that for every cpe entry
if the oval checks are mapped then it will be very much clear as to what are
the properties to search for a particular cpe entry.

What is the need:
1. I have a system which gets cpe entry as input[Only cpe entry as input and
no other details].
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
And I need to determine whether this cpe entry is valid on a particular
system.

Thanks,
Thomas



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

FW: Query on Cpe 2.2 application entries

Brant Cheikes
In reply to this post by Brant Cheikes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]

Sent: Wednesday, March 09, 2011 8:47 AM
To: [hidden email]; Cheikes, Brant A.
Subject: RE: Query on Cpe 2.2 application entries

Hi Doug White,
                      Thanks for the prompt response.

If we have any cpe name, using that name we should be able to identify the
application installed on a system.

Yes, I agree that the description of an application to the CPE name string
is a hard work.

But once done, it can help in following way:
1. The cpe string itself can be used to denote whether the application
exists on a system or not.
2. A system will be able to identify a cpe with the actual application
instance running without any ambiguity.

Steps:
A. User inputs a cpe string to a system e.g. System XYZ.
B. System XYZ checks the registry or rpm databases and active RAM on
endpoint systems.
C. System XYZ returns back with whether the cpe application string is
applicable i.e. Whether the application denoted by cpe name string is
installed or not.

First thing which comes to my mind is:
1. Form the cpe string in such a way that, it will be easier to search in
registry or rpm databases.
E.g. For a cpe string: cpe:/a:vendor:product:version in windows,
The vendor, product, version can be same as in windows registry.
i.e. We may need to mandate the content too in cpe specification.

E.g. For Microsoft Office 2007, the cpe entry says, cpe:/a:microsoft:office:
2007.

But for a computer system, it cannot map to one single application with this
kind of input because:
A. There can be any number of applications in a Microsoft office 2007 suite.

Please let me know your comments on this.

Regards,
Thomas

-----Original Message-----
From: White, Douglas R.
Sent: Tuesday, March 08, 2011 8:57 PM
To: CPE Community Forum
Subject: RE: Query on Cpe 2.2 application entries

If I understand the question correctly,
NSRL has been working (slowly) on this problem.
We showed a proof-of-concept - coincidentally using Adobe 8 & 9 - at IEEE
HST in 2009.
see http://www.nsrl.nist.gov/Documents/WHITE-ieee-hst-09.pdf

We can link vulnerability announcements to file signatures, registry entries
and active RAM on endpoint systems.
The hard work is in mapping the NSRL description of an "application" to the
CPE name string.

Douglas White              National Institute of Standards and Technology
NIST, 100 Bureau Drive Stop 8970, Gaithersburg, MD 20899-8970
     National Software Reference Library - http://www.nsrl.nist.gov
Voice: 301-975-4761     Fax: 301-975-6097   Email: [hidden email]
My opinions aren't necessarily my employer's nor any other organization's.
虎馬苹果
________________________________________
From: Cheikes, Brant A. [[hidden email]]
Sent: Tuesday, March 08, 2011 8:49 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Query on Cpe 2.2 application entries

Hi Thomas,

You have put your finger on an important issue with the operational use of
CPE to support security automation.  What you've described is the "mapping
problem"--the challenge of inspecting a computing endpoint and mapping
"software signatures" (fingerprints of software discovered to be installed
on computer storage media) to official CPE names.

[snip]

In sum, this is a known limitation of CPE.  That said, I'm aware of at least
one effort, led by Joe Wolfkiel (Defense Information Systems Agency), to
develop an approach for automatically generating CPE names from, e.g.,
Windows metadata registries, Linux RPM databases, etc.  This attacks the
problem in a novel way, eliminating the mapping problem entirely by building
names automatically in the first place.  I expect to hear more discussion of
this at the upcoming Developer Days conference sponsored by NIST.

I invite others on the CPE list (cc'd) to chime in as well.

Cheers,
/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]

Sent: Tuesday, March 08, 2011 6:18 AM
To: CPE
Subject: Query on Cpe 2.2 application entries


Hi All,
          I have a specific question on cpe 2.2 specification for
application entries e.g. cpe:/a:vendor:product:version.

Observation:
Currently cpe 2.2 is of the following format:
cpe:/part:/vendor:product:version:update:edition:language

Now say, we have a cpe entry [in accordance with cpe 2.2]:
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en

for the below product:
Adobe Reader Lite 9.0.0 Revision 2 Professional Edition English

Query:
Do we have any way to determine whether this cpe entry(i.e. application) is
installed on a system.
i.e. If I have this cpe entry, how can I determine whether this specific
software is installed on a system or not.

Some suggestion:
1. Can we think of a way of map or something which will help the system to
determine whether the cpe entry is existing on a system.
A. All the cpe entries should have a way to determine whether it is existing
on a system or not.
By mapping it to say, registry key test or file test and so on.

2. When the cpe dictionary is published, along with that for every cpe entry
if the oval checks are mapped then it will be very much clear as to what are
the properties to search for a particular cpe entry.

What is the need:
1. I have a system which gets cpe entry as input[Only cpe entry as input and
no other details].
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
And I need to determine whether this cpe entry is valid on a particular
system.

Thanks,
Thomas



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

FW: Query on Cpe 2.2 application entries

Brant Cheikes
In reply to this post by Brant Cheikes
-----Original Message-----
From: White, Douglas R. [mailto:[hidden email]]
Sent: Wednesday, March 09, 2011 9:11 AM
To: <[hidden email]>
Cc: White, Douglas R.; Cheikes, Brant A.
Subject: Re: Query on Cpe 2.2 application entries

Thomas,

I believe we are thinking along the same lines.

Right now, NSRL can generate a crude CPE-like name for all
of the applications in our collection - see
http://www.nsrl.nist.gov/cpe/CPE-list.txt  (warning 600KB)

We are working on the mappings to convert our human-readable
vendor names to the DNS naming used in CPE,
and to normalize the application names/version/etc.
information into the abbreviations and charset for CPE.

That's what we are finding hard - to create and apply the transformations
to take our pseudo-CPE names and make them correct and useful:

cpe:/a:microsoft:microsoft_office2000_professional:2000profess:::english
cpe:/a:microsoft:microsoft_office2000_professional_upgrade:2000_upgrade:::en
glish
cpe:/a:microsoft:microsoft_office97_professional:97:::english
cpe:/a:microsoft:microsoft_office97_professional_edition:1996:::english
cpe:/a:microsoft:microsoft_office97_professional_upgrade:97proupgrade:::engl
ish
cpe:/a:microsoft:microsoft_office:4.2:::english
cpe:/a:microsoft:microsoft_office_2000_professional_upgrade:sr-1:::english
cpe:/a:microsoft:microsoft_office_2000_sp2:2000_sp2:::english
cpe:/a:microsoft:microsoft_office_2000_standard:sr-1:::english
cpe:/a:microsoft:microsoft_office_97_professional_edition:97:::english
cpe:/a:microsoft:microsoft_office_accounting_professional_2008_upgrade:2008:
::english
cpe:/a:microsoft:microsoft_office_developers_kit:na:::english
cpe:/a:microsoft:microsoft_office_for_windows_95_standard:na:::english
cpe:/a:microsoft:microsoft_office_mac_2008:2008:::english
cpe:/a:microsoft:microsoft_office_oem_preinstallation_kit:2003:::english
cpe:/a:microsoft:microsoft_office_one_note_2003:na:::english
cpe:/a:microsoft:microsoft_office_professional_2007:2007:::english
cpe:/a:microsoft:microsoft_office_publisher_2007:2007:::english
cpe:/a:microsoft:microsoft_office_small_business_edition_2003:2003:::english
cpe:/a:microsoft:microsoft_office_system_preview_cd_2003:2003:::english
cpe:/a:microsoft:microsoft_office_xp_professional:2002_enterprise:::english

If we get that nut cracked, we can provide all the metadata anyone wants
on any given CPE name.

This reminds me of a Tom Clancy novel - the Russians have solved a laser
power problem but can't aim it, while the US can aim on a pinpoint but
can't ramp up the power. I need someone to help me aim this thing. :-)

Doug

On Mar 9, 2011, at 8:47 AM, <[hidden email]> wrote:

> Hi Doug White,
>                      Thanks for the prompt response.
>
> If we have any cpe name, using that name we should be able to identify the
application installed on a system.
>
> Yes, I agree that the description of an application to the CPE name string
is a hard work.
>
> But once done, it can help in following way:
> 1. The cpe string itself can be used to denote whether the application
exists on a system or not.
> 2. A system will be able to identify a cpe with the actual application
instance running without any ambiguity.
>
> Steps:
> A. User inputs a cpe string to a system e.g. System XYZ.
> B. System XYZ checks the registry or rpm databases and active RAM on
endpoint systems.
> C. System XYZ returns back with whether the cpe application string is
applicable i.e. Whether the application denoted by cpe name string is
installed or not.
>
> First thing which comes to my mind is:
> 1. Form the cpe string in such a way that, it will be easier to search in
registry or rpm databases.
> E.g. For a cpe string: cpe:/a:vendor:product:version in windows,
> The vendor, product, version can be same as in windows registry.
> i.e. We may need to mandate the content too in cpe specification.
>
> E.g. For Microsoft Office 2007, the cpe entry says,
cpe:/a:microsoft:office:2007.
>
> But for a computer system, it cannot map to one single application with
this kind of input because:
> A. There can be any number of applications in a Microsoft office 2007
suite.

>
> Please let me know your comments on this.
>
> Regards,
> Thomas
>
> -----Original Message-----
> From: White, Douglas R. [mailto:[hidden email]]
> Sent: Wednesday, March 09, 2011 7:34 AM
> To: [hidden email]
> Cc: Joy, Thomas
> Subject: FW: Query on Cpe 2.2 application entries
>
> My post to the list was rejected, so I am resending directly to you. You
may repost this message to the list.

>
> Doug White
>
> ________________________________________
> From: White, Douglas R.
> Sent: Tuesday, March 08, 2011 8:57 PM
> To: CPE Community Forum
> Subject: RE: Query on Cpe 2.2 application entries
>
> If I understand the question correctly,
> NSRL has been working (slowly) on this problem.
> We showed a proof-of-concept - coincidentally using Adobe 8 & 9 - at IEEE
HST in 2009.
> see http://www.nsrl.nist.gov/Documents/WHITE-ieee-hst-09.pdf
>
> We can link vulnerability announcements to file signatures, registry
entries and active RAM on endpoint systems.
> The hard work is in mapping the NSRL description of an "application" to
the CPE name string.

>
> Douglas White              National Institute of Standards and Technology
> NIST, 100 Bureau Drive Stop 8970, Gaithersburg, MD 20899-8970
>     National Software Reference Library - http://www.nsrl.nist.gov
> Voice: 301-975-4761     Fax: 301-975-6097   Email: [hidden email]
> My opinions aren't necessarily my employer's nor any other organization's.
> 虎馬苹果
> ________________________________________
> From: Cheikes, Brant A. [[hidden email]]
> Sent: Tuesday, March 08, 2011 8:49 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Query on Cpe 2.2 application entries
>
> Hi Thomas,
>
> You have put your finger on an important issue with the operational use of
CPE to support security automation.  What you've described is the "mapping
problem"--the challenge of inspecting a computing endpoint and mapping
"software signatures" (fingerprints of software discovered to be installed
on computer storage media) to official CPE names.
>
> [snip]
>
> In sum, this is a known limitation of CPE.  That said, I'm aware of at
least one effort, led by Joe Wolfkiel (Defense Information Systems Agency),
to develop an approach for automatically generating CPE names from, e.g.,
Windows metadata registries, Linux RPM databases, etc.  This attacks the
problem in a novel way, eliminating the mapping problem entirely by building
names automatically in the first place.  I expect to hear more discussion of
this at the upcoming Developer Days conference sponsored by NIST.

>
> I invite others on the CPE list (cc'd) to chime in as well.
>
> Cheers,
> /Brant
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
> -----Original Message-----
> From: [hidden email]
[mailto:[hidden email]]
>
> Sent: Tuesday, March 08, 2011 6:18 AM
> To: CPE
> Subject: Query on Cpe 2.2 application entries
>
>
> Hi All,
>          I have a specific question on cpe 2.2 specification for
application entries e.g. cpe:/a:vendor:product:version.

>
> Observation:
> Currently cpe 2.2 is of the following format:
> cpe:/part:/vendor:product:version:update:edition:language
>
> Now say, we have a cpe entry [in accordance with cpe 2.2]:
> cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
>
> for the below product:
> Adobe Reader Lite 9.0.0 Revision 2 Professional Edition English
>
> Query:
> Do we have any way to determine whether this cpe entry(i.e. application)
is installed on a system.
> i.e. If I have this cpe entry, how can I determine whether this specific
software is installed on a system or not.
>
> Some suggestion:
> 1. Can we think of a way of map or something which will help the system to
determine whether the cpe entry is existing on a system.
> A. All the cpe entries should have a way to determine whether it is
existing on a system or not.
> By mapping it to say, registry key test or file test and so on.
>
> 2. When the cpe dictionary is published, along with that for every cpe
entry if the oval checks are mapped then it will be very much clear as to
what are the properties to search for a particular cpe entry.
>
> What is the need:
> 1. I have a system which gets cpe entry as input[Only cpe entry as input
and no other details].
> cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
> And I need to determine whether this cpe entry is valid on a particular
system.
>
> Thanks,
> Thomas
>
>

Douglas White              National Institute of Standards and Technology
NIST, 100 Bureau Drive MS 8970, Gaithersburg, MD 20899-8970
    National Software Reference Library - http://www.nsrl.nist.gov
Voice: 301-975-4761     Fax: 301-975-6097   Email: [hidden email]
My opinions aren't necessarily my employer's nor any other organization's


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

Re: FW: Query on Cpe 2.2 application entries

steveklos
Folks,

I'm copying Douglas on this e-mail because of Brant's posting his e-mails to
this list - hope nobody minds.

I'm going to stir the pot a bit - I'm finding this discussion very
interesting...

Before you read this please realize, I don’t have a product in this area...
I'm working for a non-profit that has the goal of getting all major
commercial software vendors to provide specific identification information
for every one of their software products.  This is needed by Government,
non-profit and commercial organizations and it will benefit efforts such as
Security Automation, the NSRL DB data sets and various different Software
Asset Management toolsets.  This e-mail is not meant to dump cold water on
any efforts - in fact, I think the discussions are extremely interesting and
helpful to the community.  My goal with this e-mail is to help stretch some
of the thinking to consider how the current efforts can be made easier,
better, faster, more accurate...

So everyone is aware, many of the efforts being made in this space are
similar to efforts that have gone through various development cycles in the
commercial world.  Off the top of my head, the following companies all have
libraries that attempt to take various levels of inventory information and
turn it into application identification data (there may be more):

    BDNA
    CA
    Eracent
    Express Metrix
    Flexera
    HP
    IBM
    Microsoft
    PC-Ware

Each of these libraries has its strengths and weaknesses, each has to be
manually updated, then redeployed to customers and none of these libraries
is ever complete because new software comes out regularly.  Note that each
of these will explain away the issue as part of their sales and marketing in
one way or another...  I wouldn't say that any of these libraries is
necessarily better or worse than another, but I would say that all use
different approaches to identification, deal with different core
applications and focus on a variety of platforms.

These libraries work to some degree or another, but they all leave
significant room for improvement.  In general, the libraries are created in
order to sell the primary products which are generally focused on software
asset management.  Almost every SAM tool out there either maintains a
library, or OEM's a library and spends $'s (either through licensing or
resources) to maintain what's effectively an incomplete list.

Take a look at the following Blog postings to get a perspective of what I'm
talking about:

http://h30501.www3.hp.com/t5/IT-Service-Management-Blog/Can-Software-Asset-M
anagement-Become-Easier/ba-p/7781

http://h30501.www3.hp.com/t5/ARCHIVE-ITSM-Blog-HP-IT-Service/The-complex-wor
ld-of-Software-Inventory/ba-p/7808

http://h30501.www3.hp.com/t5/IT-Service-Management-Blog/Important-week-for-S
oftware-Asset-Management/ba-p/7800

This was why the ISO/IEC 19770-2 standard was developed to ensure that the
publisher provided very specific software identification information along
with their software installations.  This will not put the library vendors
out of the library business, but what it will do is stop some of the guess
work.  For example, I know that at least one of the recognition libraries
will look to see if there are multiple Adobe products installed and, if so,
make the assumption that it's a suite product (which suite - who knows - the
rules didn't get to be that accurate).  Some of these decisions can have
major financial repercussions if an audit is done by the vendor and the best
guesses made by the tool are wrong.

The NSRL database is even more interesting - I love the fact that there is
additional thought and work being done in this space, but it seems that if
some of this effort were made to pushing vendors to provide SWID tags
(regardless if they are certified or not), than the NSRL database would
become significantly more robust and useful both to government and
commercial entities.  As I understand, one of the primary use cases for the
NSRL database is for law enforcement to remove all known commercial files
from a hard disk - leaving the data that needs to be analyzed.  The database
provides enough data to do that.  However, if the software titles included
references to the SWID tags provided by publishers, law enforcement agencies
could get a listing of all data files + get the Meta data for all commercial
applications telling the name (including if it’s a pro, std, enterprise,
extended or any other information), the publisher, UNSPSC category details
and potentially a significant amount of additional details depending on what
the publisher provided.

The interesting thing from my perspective is that if there was a common key
that was consistent from the SCAP system to the NSRL DB, than the value of
the two databases can be even greater.

Imagine a system that's doing discovery of an agencies more secure policy
finding various SWID tags on a device - these can be setup to either be CPE
references (through the unique_id) or could be setup to reference the CPE
specifically through a CPE element that's included with the SWID tag.  These
can then reference the NSRL DB (which uses exactly the same references) to
find out which files and hashes are included in those applications.  You now
have the CPE references for installed apps, you know the executable files
for all those apps and, if desired, you could find any executable files that
are not part of the identified SWID tags.  These files can then be sent
through the NRSL DB to get a list of potential applications (and their CPE
references) that may be installed on the devices - perhaps in a
surreptitious manner.  An exception report for this type of finding would
specify that a system has software that does or does not match policy for
that device, but can also identify that some applications appear to be
installed in an invalid manner.  The report would include the specific
publisher, application and category of the application as well as the files
that indicate that the application may be installed.  Obviously, this can
also be filtered through the OVAL and NVD DB's to get a set of potential
vulnerabilities.

Note that the NSRL DB archiving structure already unpacks installer
information from the installer disks.  The SWID tag would be included as one
of the various files on the installer, so all this information is readily
available to existing processes.

Also note that patches are expected to include SWID tags as well.  The SWID
tags in the patches will reference the unique_id's for the SWID tags of
installed software, meaning that the NVD and OVAL DB generation could be
done in a completely automated manner simply by processing a patch through a
system that adds it to the various databases are required.

This is but one scenario...  There are many others.  In addition to these
issues, the ability to consolidate inventory/application data across
multiple agencies or business units (all of whom may use a different tool
and get slightly different results and/or different application titles).
This is complex stuff.

I will be giving a presentation at the Summit in May (and will set something
up with anyone on the CPE team if desired) that discusses software
identification from the various approaches that are used by various products
in the market.  You don't have to go to the Summit to hear the presentation,
but it would be great if the various interests in this area are able to get
together to discuss the overall problem and how a solution needs to address
SCAP, NSRL use cases, the GSA and DOD ITAM concerns as well as other policy
management and reporting concerns.

I'm happy to discuss more technical details if folks want more information.

Cheers,

SK

-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, March 09, 2011 6:56 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] FW: Query on Cpe 2.2 application entries

-----Original Message-----
From: White, Douglas R. [mailto:[hidden email]]
Sent: Wednesday, March 09, 2011 9:11 AM
To: <[hidden email]>
Cc: White, Douglas R.; Cheikes, Brant A.
Subject: Re: Query on Cpe 2.2 application entries

Thomas,

I believe we are thinking along the same lines.

Right now, NSRL can generate a crude CPE-like name for all
of the applications in our collection - see
http://www.nsrl.nist.gov/cpe/CPE-list.txt  (warning 600KB)

We are working on the mappings to convert our human-readable
vendor names to the DNS naming used in CPE,
and to normalize the application names/version/etc.
information into the abbreviations and charset for CPE.

That's what we are finding hard - to create and apply the transformations
to take our pseudo-CPE names and make them correct and useful:

cpe:/a:microsoft:microsoft_office2000_professional:2000profess:::english
cpe:/a:microsoft:microsoft_office2000_professional_upgrade:2000_upgrade:::en
glish
cpe:/a:microsoft:microsoft_office97_professional:97:::english
cpe:/a:microsoft:microsoft_office97_professional_edition:1996:::english
cpe:/a:microsoft:microsoft_office97_professional_upgrade:97proupgrade:::engl
ish
cpe:/a:microsoft:microsoft_office:4.2:::english
cpe:/a:microsoft:microsoft_office_2000_professional_upgrade:sr-1:::english
cpe:/a:microsoft:microsoft_office_2000_sp2:2000_sp2:::english
cpe:/a:microsoft:microsoft_office_2000_standard:sr-1:::english
cpe:/a:microsoft:microsoft_office_97_professional_edition:97:::english
cpe:/a:microsoft:microsoft_office_accounting_professional_2008_upgrade:2008:
::english
cpe:/a:microsoft:microsoft_office_developers_kit:na:::english
cpe:/a:microsoft:microsoft_office_for_windows_95_standard:na:::english
cpe:/a:microsoft:microsoft_office_mac_2008:2008:::english
cpe:/a:microsoft:microsoft_office_oem_preinstallation_kit:2003:::english
cpe:/a:microsoft:microsoft_office_one_note_2003:na:::english
cpe:/a:microsoft:microsoft_office_professional_2007:2007:::english
cpe:/a:microsoft:microsoft_office_publisher_2007:2007:::english
cpe:/a:microsoft:microsoft_office_small_business_edition_2003:2003:::english
cpe:/a:microsoft:microsoft_office_system_preview_cd_2003:2003:::english
cpe:/a:microsoft:microsoft_office_xp_professional:2002_enterprise:::english

If we get that nut cracked, we can provide all the metadata anyone wants
on any given CPE name.

This reminds me of a Tom Clancy novel - the Russians have solved a laser
power problem but can't aim it, while the US can aim on a pinpoint but
can't ramp up the power. I need someone to help me aim this thing. :-)

Doug

On Mar 9, 2011, at 8:47 AM, <[hidden email]> wrote:

> Hi Doug White,
>                      Thanks for the prompt response.
>
> If we have any cpe name, using that name we should be able to identify the
application installed on a system.
>
> Yes, I agree that the description of an application to the CPE name string
is a hard work.
>
> But once done, it can help in following way:
> 1. The cpe string itself can be used to denote whether the application
exists on a system or not.
> 2. A system will be able to identify a cpe with the actual application
instance running without any ambiguity.
>
> Steps:
> A. User inputs a cpe string to a system e.g. System XYZ.
> B. System XYZ checks the registry or rpm databases and active RAM on
endpoint systems.
> C. System XYZ returns back with whether the cpe application string is
applicable i.e. Whether the application denoted by cpe name string is
installed or not.
>
> First thing which comes to my mind is:
> 1. Form the cpe string in such a way that, it will be easier to search in
registry or rpm databases.
> E.g. For a cpe string: cpe:/a:vendor:product:version in windows,
> The vendor, product, version can be same as in windows registry.
> i.e. We may need to mandate the content too in cpe specification.
>
> E.g. For Microsoft Office 2007, the cpe entry says,
cpe:/a:microsoft:office:2007.
>
> But for a computer system, it cannot map to one single application with
this kind of input because:
> A. There can be any number of applications in a Microsoft office 2007
suite.

>
> Please let me know your comments on this.
>
> Regards,
> Thomas
>
> -----Original Message-----
> From: White, Douglas R. [mailto:[hidden email]]
> Sent: Wednesday, March 09, 2011 7:34 AM
> To: [hidden email]
> Cc: Joy, Thomas
> Subject: FW: Query on Cpe 2.2 application entries
>
> My post to the list was rejected, so I am resending directly to you. You
may repost this message to the list.

>
> Doug White
>
> ________________________________________
> From: White, Douglas R.
> Sent: Tuesday, March 08, 2011 8:57 PM
> To: CPE Community Forum
> Subject: RE: Query on Cpe 2.2 application entries
>
> If I understand the question correctly,
> NSRL has been working (slowly) on this problem.
> We showed a proof-of-concept - coincidentally using Adobe 8 & 9 - at IEEE
HST in 2009.
> see http://www.nsrl.nist.gov/Documents/WHITE-ieee-hst-09.pdf
>
> We can link vulnerability announcements to file signatures, registry
entries and active RAM on endpoint systems.
> The hard work is in mapping the NSRL description of an "application" to
the CPE name string.

>
> Douglas White              National Institute of Standards and Technology
> NIST, 100 Bureau Drive Stop 8970, Gaithersburg, MD 20899-8970
>     National Software Reference Library - http://www.nsrl.nist.gov
> Voice: 301-975-4761     Fax: 301-975-6097   Email: [hidden email]
> My opinions aren't necessarily my employer's nor any other organization's.
> 虎馬苹果
> ________________________________________
> From: Cheikes, Brant A. [[hidden email]]
> Sent: Tuesday, March 08, 2011 8:49 AM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] Query on Cpe 2.2 application entries
>
> Hi Thomas,
>
> You have put your finger on an important issue with the operational use of
CPE to support security automation.  What you've described is the "mapping
problem"--the challenge of inspecting a computing endpoint and mapping
"software signatures" (fingerprints of software discovered to be installed
on computer storage media) to official CPE names.
>
> [snip]
>
> In sum, this is a known limitation of CPE.  That said, I'm aware of at
least one effort, led by Joe Wolfkiel (Defense Information Systems Agency),
to develop an approach for automatically generating CPE names from, e.g.,
Windows metadata registries, Linux RPM databases, etc.  This attacks the
problem in a novel way, eliminating the mapping problem entirely by building
names automatically in the first place.  I expect to hear more discussion of
this at the upcoming Developer Days conference sponsored by NIST.

>
> I invite others on the CPE list (cc'd) to chime in as well.
>
> Cheers,
> /Brant
>
> Brant A. Cheikes
> The MITRE Corporation
> 202 Burlington Road, M/S K302
> Bedford, MA 01730-1420
> Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
>
> -----Original Message-----
> From: [hidden email]
[mailto:[hidden email]]
>
> Sent: Tuesday, March 08, 2011 6:18 AM
> To: CPE
> Subject: Query on Cpe 2.2 application entries
>
>
> Hi All,
>          I have a specific question on cpe 2.2 specification for
application entries e.g. cpe:/a:vendor:product:version.

>
> Observation:
> Currently cpe 2.2 is of the following format:
> cpe:/part:/vendor:product:version:update:edition:language
>
> Now say, we have a cpe entry [in accordance with cpe 2.2]:
> cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
>
> for the below product:
> Adobe Reader Lite 9.0.0 Revision 2 Professional Edition English
>
> Query:
> Do we have any way to determine whether this cpe entry(i.e. application)
is installed on a system.
> i.e. If I have this cpe entry, how can I determine whether this specific
software is installed on a system or not.
>
> Some suggestion:
> 1. Can we think of a way of map or something which will help the system to
determine whether the cpe entry is existing on a system.
> A. All the cpe entries should have a way to determine whether it is
existing on a system or not.
> By mapping it to say, registry key test or file test and so on.
>
> 2. When the cpe dictionary is published, along with that for every cpe
entry if the oval checks are mapped then it will be very much clear as to
what are the properties to search for a particular cpe entry.
>
> What is the need:
> 1. I have a system which gets cpe entry as input[Only cpe entry as input
and no other details].
> cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
> And I need to determine whether this cpe entry is valid on a particular
system.
>
> Thanks,
> Thomas
>
>

Douglas White              National Institute of Standards and Technology
NIST, 100 Bureau Drive MS 8970, Gaithersburg, MD 20899-8970
    National Software Reference Library - http://www.nsrl.nist.gov
Voice: 301-975-4761     Fax: 301-975-6097   Email: [hidden email]
My opinions aren't necessarily my employer's nor any other organization's
Reply | Threaded
Open this post in threaded view
|

Re: Query on Cpe 2.2 application entries (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
In reply to this post by WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification:  UNCLASSIFIED
Caveats: NONE

So here's the more detailed response:

We're deploying a capability that scans the registry on Windows boxes to discover the OS, applications, patches/updates, and whatever software has "registered" itself on the system.  We plan to follow on with expansion to RHEL, Solaris, and MacOS later this year.

Due to slow/nonexistent adoption of CPE by vendors (along with an unwillingness to commit to integrating with our Host-Based Security Solution), this will be a government-built capability that we hope we can stop using in a few years when the commercial market catches up.

I'll go through issue by issue and provide some discussion in depth about the problem we are or have had to work through.

1.  Products don't register themselves consistently.
A.  Patches/updates and applications are intermixed in the registry with patches and service packs installed as applications and applications (such as Dr Watson) installing as patches or updates.  CPE does not support the ability to report patches/updates in the CPE URI format; however, because it's not possible to construct machine logic to tell them apart, we have to basically assume that patches/updates and applications have to be treated interchangeably and will use the CPE URI format to report both.  Making that decision opens up whole new vistas in terms of how you can construct Boolean logic.  Within XCCDF, if any generic CPE can be used as a "platform" identifier, I can now write policies to check OS, application and patch/update configurations.  What we trade for this decision is that the "a" and "h" parts of CPE effectively become unusable.  Fortunately, CPE 2.2 made the part designator optional, so we can just omit it.
I'm working on a spec for how we can use XCCDF, coupled with logic from the CPE Language schema and with policy statements about the decisions made about whether a given application, OS, or patch/update is required, permitted, or required to be on any given device.  The language treats anything in a CPE string interchangeably and could, for example use a patch as a platform definition and then state that you are required to have a certain OS and application anytime that patch is present.
B.  Different Operating Systems register software differently.  In a Windows OS, you get three names installed that roughly equate to vendor, product, and version.  Any other information is either embedded into the names that get registered, or has to be discovered in some product-specific location or through some evaluation of a non-registered property (i.e. discovering if you have Win7 64 bit or Win7 32 bit installed).  In Red Hat Linux, you get the vendor, product, version info, plus release and architecture.  Other Operating Systems support different metadata.
For basic asset inventory, many of these problems aren't major show stoppers.  However, when you try to correlate the information the products register about themselves with what's been hand-jammed into the NVD or into the platform statements in XCCDF benchmarks or even with the data that is collected by different vendor products, the matching problem becomes "significant".
I've spent some time working on automated algorithms to do computer matching to try to assist analysts in mapping auto-generated CPE names to the manually-generated names in the NVD and CPE dictionary.  The algorithm treats CPE as a single string and ranks CPEs based on a "similarity score" that says the more matching sub-strings you have in two CPEs of different lengths, the more "similar" they are and that the longer the matching strings are, the higher the score should be.  In general, this has worked pretty well.  However, there are a few things in CPE that defeat machine-assisted matching.  
        1.  Abbreviations defeat machine-based matching.  I think it should be obvious why this is a problem.  The abbreviation "ie" will be equally similar to windows:ie as it is to fred:unbelievable, but a similarity-based algorithm will have a reasonable chance of matching "internet_explorer" correctly to windows:internet_explorer versus fred:unbelievable.  
        2.  Inconsistently used punctuation, particularly when coupled with percent encoding, makes machine-based matching less successful when comparing short names.  For example, when mcafee registers itself in one place as "mcafee" and in another as mcafee inc., which is then percent encoded (disregard the hex.  Too lazy to look it up) mcafee_inc%AA%BB, then any product that contains the _inc%AA%BB will be more similar to the mcafee inc., string than "mcafee".  It's reasonably easy to fix this, but it entails an amount of coding and CPU cycles over and above basic string comparisons.

2.  The CPE registration and maintenance process is extremely labor-intensive.  Because the CPE submission process, using CPE Dictionary, was engineered as a manual process, requiring generation of a "Title", lookup of a vendor web site, then manual submission and vetting it takes a long time to formally get new software names into the dictionary.  I haven't checked, but wouldn't be surprised to find that common applications like Internet Explorer and Adobe Reader are releasing new product versions faster than the CPE Dictionary can be updated to include them.

3.  XCCDF was engineered as a document-focused process.  Since we require a policy for every OS, application, and patch on our networks (per Consensus Audit Guidelines) and this will need to be updated continuously, the need to deprecate XCCDF documents at the benchmark vs the rule level means that we can't reasonably publish a single benchmark with all the policies in it, otherwise we would have to issue a completely new version of the benchmark every day.  This drove the requirement to construct a dedicated benchmark for each application and patch.  While this isn't a show stopper, it requires the ability to distribute and update multiple policy benchmarks on a continuous basis (daily/weekly).  The current SCAP standards don't gracefully scale to this requirement since content distribution isn't supported by any standards.  The DoD has enterprise licenses to multiple asset management and network inventory tools and will have to manage different content distribution methodol
 ogies and processes for each one.


As we work through the issues of trying to deploy CPE-based asset management capabilities across the DoD while supporting centralized control and de-centralized execution with operational reporting capabilities, the need to add significant automation to CPE and CPE-related processes looms large.

There's lots more, but this provides an initial taste for the problems we've been working through.  I'd like to share our experiences and shape CPE implementation in a way that accelerates vendor adoption of CPE-based reporting of installed software names and provides the DoD with the ability to commercially acquire products that use CPE-supported processes to accomplish asset, security, and compliance management missions in the Federal Government.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Tuesday, March 08, 2011 8:57 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Query on Cpe 2.2 application entries (UNCLASSIFIED)

Classification:  UNCLASSIFIED
Caveats: NONE

Actually, our approach solves the problem in a limited way that we're trying to figure out how to scale across multiple vendor products and data sources.  I do plan to talk about this a developer days.  If I can find some time over the next couple of days, I'll write up some of the issues we've run into and the short-term solutions we're planning to use so we can have a more informed discussion in a couple of weeks.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]

-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Tuesday, March 08, 2011 8:50 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Query on Cpe 2.2 application entries

Hi Thomas,

You have put your finger on an important issue with the operational use of
CPE to support security automation.  What you've described is the "mapping
problem"--the challenge of inspecting a computing endpoint and mapping
"software signatures" (fingerprints of software discovered to be installed
on computer storage media) to official CPE names.

The mapping problem exists in CPE (in v2.2 as well as the
soon-to-be-released v2.3 specification suite) by deliberate choice.  As
you've noticed, the specification makes provision for a "check" element to
be associated with each cpe-item in the official dictionary.  The intention
here was to create a placeholder for just the kind of information you've
suggested, e.g., the identifier of an OVAL check.

In practice, this feature is unused.  There are several reasons why.  First,
there have been concerns about tightly linking CPE to some other
endpoint-testing standard such as OVAL.  Second, if we don't leverage
another standard, it isn't clear how to define an approach that will work
smoothly across all operating systems.  Third, there's a question of whether
the solution to the mapping problem is rightly left to vendors--this could
be a legitimate realm for innovation and competing approaches.  Lastly, and
perhaps the major reason, the Government has understandably been reluctant
to take on the responsibility (and apply the needed resources) for doing the
necessary research and testing for every CPE name in the dictionary.  We've
considered shifting the burden onto submitters, but thus far have decided
against that due to the belief that this would create a major barrier to
submission.  (Also, that approach doesn't address the 25K+ existing
dictionary entries.)

In sum, this is a known limitation of CPE.  That said, I'm aware of at least
one effort, led by Joe Wolfkiel (Defense Information Systems Agency), to
develop an approach for automatically generating CPE names from, e.g.,
Windows metadata registries, Linux RPM databases, etc.  This attacks the
problem in a novel way, eliminating the mapping problem entirely by building
names automatically in the first place.  I expect to hear more discussion of
this at the upcoming Developer Days conference sponsored by NIST.

I invite others on the CPE list (cc'd) to chime in as well.

Cheers,
/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]

Sent: Tuesday, March 08, 2011 6:18 AM
To: CPE
Subject: Query on Cpe 2.2 application entries


Hi All,
          I have a specific question on cpe 2.2 specification for
application entries e.g. cpe:/a:vendor:product:version.

Observation:
Currently cpe 2.2 is of the following format:
cpe:/part:/vendor:product:version:update:edition:language

Now say, we have a cpe entry [in accordance with cpe 2.2]:
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en

for the below product:
Adobe Reader Lite 9.0.0 Revision 2 Professional Edition English

Query:
Do we have any way to determine whether this cpe entry(i.e. application) is
installed on a system.
i.e. If I have this cpe entry, how can I determine whether this specific
software is installed on a system or not.

Some suggestion:
1. Can we think of a way of map or something which will help the system to
determine whether the cpe entry is existing on a system.
A. All the cpe entries should have a way to determine whether it is existing
on a system or not.
By mapping it to say, registry key test or file test and so on.

2. When the cpe dictionary is published, along with that for every cpe entry
if the oval checks are mapped then it will be very much clear as to what are
the properties to search for a particular cpe entry.

What is the need:
1. I have a system which gets cpe entry as input[Only cpe entry as input and
no other details].
cpe:/a:adobe:reader_lite:9.0.0:revision_2:pro:en
And I need to determine whether this cpe entry is valid on a particular
system.

Thanks,
Thomas


Classification:  UNCLASSIFIED
Caveats: NONE

Classification:  UNCLASSIFIED
Caveats: NONE


smime.p7s (7K) Download Attachment