Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

From: "Cheikes, Brant A." <[email-masked]>
Date: Mon, 1 Oct 2012 14:40:26 +0000

I'm sorry I didn't join this thread sooner, but I'll try to catch up.  I've been leading the CPE project at MITRE for the last three years, and for the last year-plus have been working closely with Steve Klos, the Executive Director of TagVault.org, to assess similarities/differences between the CPE and SWID tag standards, and to develop a roadmap that enables the two standards to interoperate in some fashion.  Steve and I chaired a session at the recent Developer Days workshop on the topic; see:
http://cpe.mitre.org/news/index.html#jul272012b

CPE names and SWID tags are very different things, with overlapping and non-overlapping use cases, different value propositions to stakeholders, and different procedures for creation and maintenance.  The CPE v2.3 standard is documented in a suite of NIST IRs, and the SWID tag standard is documented in ISO/IEC 19770-2:2009.  This is not the proper venue for tutorials on either CPE or SWID; I would encourage those who know CPE to learn more about SWIDs using TagVault.org resources.  Also note that Steve Klos will be speaking today at ITSAC.

In my view, both CPE and SWID need to be considered when discussing asset inventory solutions.  I suspect that SWID tags will eventually replace CPE names, but that will depend on market uptake and on how well we can deploy and use so-called "third-party" SWID tags-non-authoritative tags created by entities other than the software publisher/creator.  Adam is right that SWID tagging is a relatively new concept.  There aren't many vendors yet who have adopted tags, but there definitely are some, including Symantec and most recently Microsoft.  SWIDs are today where CPE was perhaps five years ago, in terms of adoption and coverage.  Give it time.

SWID tags are full-fledged XML documents, whereas CPE names are just identifying strings assigned by a third party (NIST) to software products.  Embedded within the SWID tag document is a unique ID, which lacks the readability of a CPE name but could serve the same function as a CPE name.  SWID tags are associated with individual product releases; CPE names can also be associated with individual products, but also have the capability to identify broader classes of a product.  You can create a CPE name that generically refers to "all Windows 7 operating systems", but you can't do that with a SWID tag.

The main issue with CPE is that it has a relatively unsustainable O&M profile.  Since software publishers haven't (and largely won't) adopt CPE and build CPE names somehow into their products (whatever that might mean; CPE thus far hasn't addressed this issue), we need a central authority-NIST-to devote ongoing resources to maintaining the CPE dictionary, with names arriving only when submitted by a member of the "CPE community" in response to a naming need.  In contrast, software publishers who adopt SWID tagging create the tags at product release time, and the tag is included in the installation package for the product.  When the product is installed, the tag is placed on the endpoint.  When the product is uninstalled, the tag is removed.  With the addition of certification and digital signing of tags (not available in CPE), one can have some guarantee that the tag has not been tampered with.  The TagVault community is considering the addition of a "secure asset management" certification level, which would require certified tags to include a "package footprint" element documenting the individual files which comprise the tagged product.  These are features well beyond CPE.

There was a question about CPE's ability to represent product suites/groups.  You can create a CPE name for "Microsoft Office 2010 Professional", and you can create separate CPE names for all the products in that suite (Word, PowerPoint, etc.), but CPE provides no way to represent the fact that by installing MS Office 2010 you also install all the individual products that are included.  SWID tags let you do that explicitly.

That's all for now-I've gone on long enough.  I'll try to keep a closer eye on this thread and do a better job of answering questions as they come up.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Wednesday, September 26, 2012 9:23 AM
To: Jan-Oliver Wagner; [email-masked]
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

This seems like an important discussion.  Asset management is, arguably, the most important foundational piece of an effective information security program, as our use case document [1] recognizes (asset management is the first recognized capability in support of Use Case 1).  Clearly, there are pros and cons to leveraging CPE and/or SWID, and after quickly reading through some of the information available at TagVault [2], it seems clear that SWIDs are roughly equivalent to CPE for operating systems and applications.

Before looking at the differences between CPE and SWID, it's probably a good idea to understand exactly what we need from a software asset classification scheme not only within our use cases, but also from a couple of control frameworks our use cases support (I prefer to look at the Critical Audit Guidelines (CAG) published by SANS and ISO 27002).

Both the CAG and 27002 make reference to managing assets, but only in terms of keeping an inventory.  The CAG goes further by explicitly stating (in Critical Control 2) that we need to have an inventory of all authorized and unauthorized software.  I don't believe either really mentions anything about corrective actions, except implicitly in sections related to incident response.

So, we have a clear need to look at an instance of software, classify it, and build or contribute to an identity profile for it for continued reference.  Can CPE handle this classification for for us?  Yes.  Can SWID handle this classification for us?  It seems so.  Note that we should not rely on either of these methods to identify software for targeted actions - that would be the domain of Asset Identification (we could use CPE or SWID to specify classes of targets for actions).

Distribution and operational identification seems important to consider as well.  CPEs aren't installed with the software and require some assessment action to derive.  SWIDs, on the other hand, appear to be distributed by the software publisher [3].  Moreover, SWIDs are certified and signed by TagVault.  I'm unsure of the details about how SWIDs become available on a given system (they still need to be actively collected from a target system at some point).

At this point, the difference between the two is really volume of available "tags" (we can reasonably call a CPE name a "tag" in this context), and this is where I see the rubber meeting the road - when an operational component is implicitly or explicitly required for a standard to work as intended at scale.

There seems to be very little information about SWID volumes available (at least in the limited time I've had to search around), so it's difficult to judge how well they've penetrated the market.  The last press release from TagVault is from 2010, which may suggest a dropping off of the effort or a satisfaction that they've done enough.  Information about CPE volume seems most readily available from NVD [5].

Can anyone on this list provide additional details about SWID?

I think it may be useful, from a  community perspective, to be able to handle both software identification types, provided both are operationally feasible and foreseeably sustainable.  For example, the ai:software element defined by the Asset Identification draft [4] has an optional CPE attribute that could just as easily be complemented by an optional SWID attribute.

[1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02
[2] http://www.tagvault.org
[3] http://www.tagvault.org/swid-tag-lifecycle
[4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identification-00
[5] http://nvd.nist.gov/cpe.cfm

On 9/26/12 3:28 AM, "Jan-Oliver Wagner" <[email-masked]<mailto:[email-masked]>> wrote:

On Mittwoch, 26. September 2012, Baker, Jon wrote:
I am a big fan of SWIDs and believe that we would really benefit from widespread SWID adoption. In my previous message, I was attempting to state that we need capabilities offer by both CPE and SWID.

I am a big fan of CPE and believe it is fully compatible with Open Source reference
implementation and widespread use/adoption in Open Source tools, especially also
in commercial environments.

Neglecting CPE in favour of SWID would IMHO be a drawback for widespread security
automation because, as to my understanding, SWID is not fully compatible with the vendor-independent
approaches. Convince me I am wrong and I'd be happy ;-)

(Sorry for jumping in here, it was just something I am worried about since some time already
so I spontaneously reacted on the keywords :-)

--
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner

---

From: "Steve Klos" <[email-masked]>
Date: Mon, 1 Oct 2012 20:58:34 -0700

Folks,

A few notes now and I will follow-up at the IT SAC conference in one-on-one
sessions, during various BoF sessions and I’m more than happy to continue
this discussion thread as we move forward.

Brant already provided many details and I’ve seen a variety of comments on
this reflector covering various different topics on SWID tags.  Let me
summarize in bullet points:

1)      SWID Tags provide authoritative identification information provided
by the software publisher (authoritative by nature due to the digital
signatures applied by the publishers).

2)      SWID Tags do not need to be “registered” or “certified” to be
useful, but doing so ensure that the data provided in the tag meets a
well-known minimum data set and it also follows registered and enumerated
values to ensure normalization.

3)      SWID tags can be created by third party organizations and will vary
in the “trust” level based on the identification of the organization
creating the SWID tag.  SWID tags created by “NIST”, for example would have
a much higher degree of trust than tags created by “Mom and Pop Shop Inc.”
Digital signatures (that include recognition by a CA) are used to recognize
the creator.

4)      SWID tags provide support for suites/bundles and the various
software relationships within those software groupings.  

5)      SWID tags also provide support for patches with the identification
of which software the patch is targeted at.

6)      SWID tags support efforts to mitigate the software supply chain
security risk by including (in the secure asset management level of
certification), the footprint of each file on the installation media as well
as for each file that may be copied onto the device the software is being
installed on.  These file level details utilize the SHA 2 (256) algorithm
and are also digitally signed with the publishers signature.

7)      Through work with MITRE, NIST and others, the SWID standard has been
extended to support many of the fields necessary to map against the CPE name
structure – Brant and others have already referenced this work and the
document behind it.  Note that TagVault.org is heavily involved in the ISO
standards development efforts and these extensions are already targeted to
be incorporated back into an amendment to the 19770-2 standard.

8)      To ensure we don’t “mix” standards – the effort for the SWID tag
standard is to ensure the fields are defined properly and that software
publishers are required to include the data in these fields, however, the
CPE name is defined as a process to concatenate fields.  This enables NIST,
IETF, or others to manage the CPE standard as required and for the process
used to create the CPE names to be used as an integration point between the
standards.

9)      Due to the fact that there is a vast library of tools, processes,
etc invested in CPE names, my perspective on the integration is to keep CPE
essentially as is, add the integration with SWID tag names and to utilize
this information with the systems around it to normalize names and terms for
both systems.

10)   SW Publishers are quickly coming to the realization that SWID tags
lower their overall infrastructure costs due to many factors, they provide
the data their customers have been requesting for quite some time and they
provide the added value of ensuring that the customer is receiving only what
the publisher published, so they add a level of supply chain risk management
to the distribution process.  Microsoft and Symantec have certainly
recognized and embraced these benefits and are quickly working to integrate
certified SWID tags into their build environments to provide the highest
value to their customers.

My presentation is on Wed afternoon from 4:30 to 5:30 and as many on this
distribution are aware – this is an area I’m passionate about.  Many IT
processes from compliance to security to logistics require authoritative
identification of software.  Anyone who’s worked with tools in this area
knows that existing systems vary dramatically in their abilities and
generally data sets between different tools cannot be easily reconciled
against each other.  The fact that SWID tags can provide solutions to these
areas, are being supported directly by publishers and can be integrated into
the SCAP infrastructure and can even provide a direct bridge between
discovery data and CPE names, seem to make this technology an ideal fit for
this community.

Looking forward to seeing many of you on Wed!

Regards,

Steve Klos

From: Cheikes, Brant A. [mailto:[email-masked]] 
Sent: Monday, October 01, 2012 7:40 AM
To: Adam Montville; Jan-Oliver Wagner; [email-masked]
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

I’m sorry I didn’t join this thread sooner, but I’ll try to catch up.  I’ve
been leading the CPE project at MITRE for the last three years, and for the
last year-plus have been working closely with Steve Klos, the Executive
Director of TagVault.org, to assess similarities/differences between the CPE
and SWID tag standards, and to develop a roadmap that enables the two
standards to interoperate in some fashion.  Steve and I chaired a session at
the recent Developer Days workshop on the topic; see:

CPE names and SWID tags are very different things, with overlapping and
non-overlapping use cases, different value propositions to stakeholders, and
different procedures for creation and maintenance.  The CPE v2.3 standard is
documented in a suite of NIST IRs, and the SWID tag standard is documented
in ISO/IEC 19770-2:2009.  This is not the proper venue for tutorials on
either CPE or SWID; I would encourage those who know CPE to learn more about
SWIDs using TagVault.org resources.  Also note that Steve Klos will be
speaking today at ITSAC.

In my view, both CPE and SWID need to be considered when discussing asset
inventory solutions.  I suspect that SWID tags will eventually replace CPE
names, but that will depend on market uptake and on how well we can deploy
and use so-called “third-party” SWID tags—non-authoritative tags created by
entities other than the software publisher/creator.  Adam is right that SWID
tagging is a relatively new concept.  There aren’t many vendors yet who have
adopted tags, but there definitely are some, including Symantec and most
recently Microsoft.  SWIDs are today where CPE was perhaps five years ago,
in terms of adoption and coverage.  Give it time.

SWID tags are full-fledged XML documents, whereas CPE names are just
identifying strings assigned by a third party (NIST) to software products.
Embedded within the SWID tag document is a unique ID, which lacks the
readability of a CPE name but could serve the same function as a CPE name.
SWID tags are associated with individual product releases; CPE names can
also be associated with individual products, but also have the capability to
identify broader classes of a product.  You can create a CPE name that
generically refers to “all Windows 7 operating systems”, but you can’t do
that with a SWID tag.

The main issue with CPE is that it has a relatively unsustainable O&M
profile.  Since software publishers haven’t (and largely won’t) adopt CPE
and build CPE names somehow into their products (whatever that might mean;
CPE thus far hasn’t addressed this issue), we need a central
authority—NIST—to devote ongoing resources to maintaining the CPE
dictionary, with names arriving only when submitted by a member of the “CPE
community” in response to a naming need.  In contrast, software publishers
who adopt SWID tagging create the tags at product release time, and the tag
is included in the installation package for the product.  When the product
is installed, the tag is placed on the endpoint.  When the product is
uninstalled, the tag is removed.  With the addition of certification and
digital signing of tags (not available in CPE), one can have some guarantee
that the tag has not been tampered with.  The TagVault community is
considering the addition of a “secure asset management” certification level,
which would require certified tags to include a “package footprint” element
documenting the individual files which comprise the tagged product.  These
are features well beyond CPE.

There was a question about CPE’s ability to represent product suites/groups.
You can create a CPE name for “Microsoft Office 2010 Professional”, and you
can create separate CPE names for all the products in that suite (Word,
PowerPoint, etc.), but CPE provides no way to represent the fact that by
installing MS Office 2010 you also install all the individual products that
are included.  SWID tags let you do that explicitly.

That’s all for now—I’ve gone on long enough.  I’ll try to keep a closer eye
on this thread and do a better job of answering questions as they come up.

Cheers,

/Brant

Brant A. Cheikes
The MITRE Corporation

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Montville

This seems like an important discussion.  Asset management is, arguably, the
most important foundational piece of an effective information security
program, as our use case document [1] recognizes (asset management is the
first recognized capability in support of Use Case 1).  Clearly, there are
pros and cons to leveraging CPE and/or SWID, and after quickly reading
through some of the information available at TagVault [2], it seems clear
that SWIDs are roughly equivalent to CPE for operating systems and
applications.

Before looking at the differences between CPE and SWID, it's probably a good
idea to understand exactly what we need from a software asset classification
scheme not only within our use cases, but also from a couple of control
frameworks our use cases support (I prefer to look at the Critical Audit
Guidelines (CAG) published by SANS and ISO 27002).

Both the CAG and 27002 make reference to managing assets, but only in terms
of keeping an inventory.  The CAG goes further by explicitly stating (in
Critical Control 2) that we need to have an inventory of all authorized and
unauthorized software.  I don't believe either really mentions anything
about corrective actions, except implicitly in sections related to incident
response.  

So, we have a clear need to look at an instance of software, classify it,
and build or contribute to an identity profile for it for continued
reference.  Can CPE handle this classification for for us?  Yes.  Can SWID
handle this classification for us?  It seems so.  Note that we should not
rely on either of these methods to identify software for targeted actions –
that would be the domain of Asset Identification (we could use CPE or SWID
to specify classes of targets for actions).

Distribution and operational identification seems important to consider as
well.  CPEs aren't installed with the software and require some assessment
action to derive.  SWIDs, on the other hand, appear to be distributed by the
software publisher [3].  Moreover, SWIDs are certified and signed by
TagVault.  I'm unsure of the details about how SWIDs become available on a
given system (they still need to be actively collected from a target system
at some point).

At this point, the difference between the two is really volume of available
"tags" (we can reasonably call a CPE name a "tag" in this context), and this
is where I see the rubber meeting the road – when an operational component
is implicitly or explicitly required for a standard to work as intended at
scale.  

There seems to be very little information about SWID volumes available (at
least in the limited time I've had to search around), so it's difficult to
judge how well they've penetrated the market.  The last press release from
TagVault is from 2010, which may suggest a dropping off of the effort or a
satisfaction that they've done enough.  Information about CPE volume seems
most readily available from NVD [5].

I think it may be useful, from a  community perspective, to be able to
handle both software identification types, provided both are operationally
feasible and foreseeably sustainable.  For example, the ai:software element
defined by the Asset Identification draft [4] has an optional CPE attribute
that could just as easily be complemented by an optional SWID attribute.

[4]
http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identification-00

 

On 9/26/12 3:28 AM, "Jan-Oliver Wagner" <[email-masked]>
wrote:

I am a big fan of SWIDs and believe that we would really benefit from
widespread SWID adoption. In my previous message, I was attempting to state
that we need capabilities offer by both CPE and SWID. 

I am a big fan of CPE and believe it is fully compatible with Open Source
reference

implementation and widespread use/adoption in Open Source tools, especially
also

Neglecting CPE in favour of SWID would IMHO be a drawback for widespread
security

automation because, as to my understanding, SWID is not fully compatible
with the vendor-independent

 

(Sorry for jumping in here, it was just something I am worried about since
some time already

 

-- 

Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR
B 202460

---

From: "Jan-Oliver Wagner" <[email-masked]>
Date: Tue, 2 Oct 2012 08:53:33 +0200

Hello,

thanks to all for the comprehensive insights into SWID vs. CPE.

However, I come back to my original concerns, cited below, which
so far remained mostly unanswered.

Most insights were about technical aspects. I still saw no
argument why SWID is well compatible with Open Source
community and vendor-independent approaches. CPE seems by far
more competitive and compatible in this regard. At least I found
no clarifying statements from SWID side. Maybe I did not manage
to find it. At least such were not brought to attention in this thread.

I am starting to have doubts about the non-technical genes of SWID to
solve the challenge of helpful product enumeration for security
automation. If we only target a part of the IT industry, there
will always be a gap in security coverage. It has to be filled
with another concept and automatically we end up with two of them.
Which in turn will make IT security more expensive for customers.

I'd really love to be prooven wrong with my pessimistic concerns!

All the best

Jan

---

From: Michael Hammer <[email-masked]>
Date: Tue, 2 Oct 2012 13:25:52 +0000

Steve,

For #3, I would hope that trust is based on more than being well-known.
After all, we have known some well-known government agencies that have
failed miserably at security from time to time.  Same thing with some rather
large, well-known companies.  Mom and Pop might actually be much better at
doing it right because their very existence depends on it.

Better to define trust as something you gain by following well-proven
methodologies that are traceable and testable.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Steve Klos
Sent: Monday, October 01, 2012 11:59 PM
To: [email-masked]
Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

Folks,

Regards,

Steve Klos

Cheers,

/Brant

Brant A. Cheikes
The MITRE Corporation

 

[4]

 

 

 

--

---

From: Steve Klos <[email-masked]>
Date: Tue, 02 Oct 2012 07:33:52 -0700

Mike,

Actually, I can't tell you who to trust.  The SWID tags provide the trust chain (which may include multiple signatures from a variety of sources that include things like pgp and digital certs from a CA).

What a particular organization then sets up as the entities, or certificates they trust is up to each org. 

Cheers,

SK
408.202.1900
--
Sent from a mobile device. Please excuse brevity and typos.

Michael Hammer <[email-masked]> wrote:

>sessions, during various BoF sessions and Im more than happy to
>continue
>Brant already provided many details and Ive seen a variety of comments
>on
>2)      SWID Tags do not need to be registered or certified to be
>in the trust level based on the identification of the organization
>creating the SWID tag.  SWID tags created by NIST, for example would
>have
>a much higher degree of trust than tags created by Mom and Pop Shop
>Inc.
>structure  Brant and others have already referenced this work and the
>8)      To ensure we dont mix standards  the effort for the SWID
>tag
>distribution are aware  this is an area Im passionate about.  Many IT
>identification of software.  Anyone whos worked with tools in this
>area
>Im sorry I didnt join this thread sooner, but Ill try to catch up. 
>Ive
>and use so-called third-party SWID tagsnon-authoritative tags
>created by
>tagging is a relatively new concept.  There arent many vendors yet who
>have
>generically refers to all Windows 7 operating systems, but you cant
>do
>that with a SWID tag.
>
> 
>
>profile.  Since software publishers havent (and largely wont) adopt
>CPE
>CPE thus far hasnt addressed this issue), we need a central
>authorityNISTto devote ongoing resources to maintaining the CPE
>dictionary, with names arriving only when submitted by a member of the
>CPE
>community in response to a naming need.  In contrast, software
>publishers
>considering the addition of a secure asset management certification
>level,
>which would require certified tags to include a package footprint
>element
>There was a question about CPEs ability to represent product
>suites/groups.
>You can create a CPE name for Microsoft Office 2010 Professional, and
>you
>Thats all for nowIve gone on long enough.  Ill try to keep a closer
>eye
>Adam
>rely on either of these methods to identify software for targeted
>actions 
>is where I see the rubber meeting the road  when an operational
>component