Automation of CPE names using certified SWID tags

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

Automation of CPE names using certified SWID tags

Brant Cheikes

CPE Community,

 

This message summarizes a recently-released proposal, authored by TagVault.org with assistance from MITRE, describing how software identification (SWID) tags for identifying software installed on computing assets can integrate with and potentially automate the creation of  CPE names.  Further information and the full proposal are available here: http://tagvault.org./Automating_CPE_name_creation

 

Over the next several weeks I'll be posting updates with additional information about the proposal, and fielding questions.  As you will learn, although the proposal itself is not directed to the CPE community, it will require changes on "our side" to some of the conventions we have been using to assign names to products, if the proposal is to fully succeed.  Through an extended e-mail based discussion carried out on the CPE Community Discussion List,  I hope to clearly describe those changes and solicit your feedback and recommendations about them.  Ultimately I hope to drive towards a community consensus on what changes we are willing to make.  This consensus will eventually be framed as a set of recommendations to NIST regarding CPE Dictionary operation and maintenance.

 

IN MORE DETAIL

 

As I mentioned in an email to this list on 23 December 2011, MITRE joined TagVault.org as a Corporate Member during 2011.  TagVault is a non-profit organization formed as a program of IEEE-ISTO to be a registration and certification authority for SWID tags, and to provide a forum for sharing information and resources about software tags among software publishers, tool providers and software asset management practitioners.

 

The SWID tag is defined by an international standard, ISO/IEC 19770-2:2009.  The standard specifies the content, format and installation location of XML documents, called SWID tags, which are shipped with software products and installed/uninstalled on computing endpoints whenever the products are installed/uninstalled.  If a software product conforms to the SWID standard, then the presence of a SWID tag on a computing endpoint provides a high degree of proof that the product is actually installed and able to operate on that endpoint (and the absence of the tag strongly implies that the product is not installed).

 

Over the last several months, MITRE and TagVault have each been working to learn more about SWID tagging and CPE naming, respectively.  We've recognized that while each effort has unique goals, audiences and stakeholders, there are areas of overlap where both efforts could benefit substantially from forging closer ties.  With that in mind, we have been collaborating on ways to insert a CPE name-assignment step into the procedure that software publishers would follow when creating SWID tags for their products.  The proposal at the link above captures the latest draft of our joint work on this topic.

 

The proposal, directed to the SWID community, suggests revisions to the SWID tag format and creation process such that every new SWID tag has an embedded  unique identifier which is the product's CPE name as assigned by the publisher.  This proposal is now being circulated for comment among SWID stakeholders.  Let me underscore what this means:  the SWID community is considering revisions to their own technical standard in order to build an explicit bridge to CPE and SCAP.

 

If the proposal gains support and is implemented (i.e., the ISO/IEC 19770-2 standard is revised and published), it could prove to be a major win for both communities.  For the CPE community, to the extent that SWID tagging grows in adoption, we would gain a stream of new CPE names flowing into the CPE Dictionary which are publisher-defined, authoritative, and directly linked to the discoverable SWID tags.  In short, industry success of "CPE-enabled SWID tags" would make CPE itself more useful, and would also help solve a long-standing problem that has plagued CPE--that of automating the association of a CPE name with a discoverable "fingerprint" on a computing endpoint.  (In this scenario, each product's SWID tag becomes its fingerprint, and each discovered SWID tag contains the product's CPE name.)  For the SWID community, CPE-enabled SWID tags addresses a gap in the SWID tag value proposition, by adding a pathway (via CPE ) for SWID tags to help address software assurance challenges.

 

In the interest of keeping this message (relatively) short, I'll stop here and simply encourage you to find some time to look over the proposal and post any comments or questions you may have to this list.  As I said at the beginning of this note, a careful reading will reveal that the CPE community will need to consider certain changes in our naming conventions, so that publisher-created CPE names embedded in SWIDs can be directly imported into the CPE Dictionary without additional review.  I'll post more information about that in the weeks ahead.

 

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

 


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

Re: Automation of CPE names using certified SWID tags

Stav Raviv

Dear Brant,

 

The proposal to integrate CPE and SWID seems to offer an opportunity for great progress. For us, in risk management business, the success of this project is extremely desired.

We currently use CPE in our products and would like to extend our reliance on it even further.

 

Reading the referenced proposal (http://tagvault.org./Automating_CPE_name_creation), though, we immediately had some doubts, that we would be glad if you could  resolve.

 

 

The most pressing issue is regarding the changes proposed to the product attribute conventions (section 3.3, p. 15):

“Our proposal for the automated generation of CPE names within SWID tags is to fill the CPE ‘product’

attribute with the title as the publisher defines it. Thus, Microsoft Office Professional 2010 would have

the Product attribute in the CPE name be “Microsoft_Office_Professional_2010” (spaces converted to

underscores in order to conform with the CPE 2.3 naming specification).

This will require a slightly different applicability statement if the statement needs to reference a generic

edition of the product. Instead of referencing “office”, the applicability statement would reference, e.g.,

“Microsoft_Office*” or even just “*office*”.”

 

We believe that this is problematic in a few levels:

·         In a logical level:

It creates redundancy (which might also allow inconsistencies). E.g.- a duplication of the vendor name, edition, etc.

·         In a practical level, for matching purposes:

o   When one wants to match all, e.g., Office, versions and editions using the current specification, she would use “cpe:2.3:a:microsoft:office::::::::” (with or without the trailing ::::::::)

But according to the new suggestion, she would have to use “cpe:2.3:a:microsoft.com:*office*::::::::” (with or without the trailing ::::::::) or something of that sort

This would not allow to differentiate Office’s add-ons, plugins, etc. from the actual Office product.

o   In contrary to what is said in p. 15:

“One problem with this CPE naming convention (at least, in the context of the “Microsoft Office

Professional 2010” example) is that many products are Microsoft Office plug‐ins or Microsoft Office add-ons

which could also be mistakenly identified as being in the “office” family. Though it’s relatively easy

for a human to understand that the add‐ons and plug‐ins should not be identified as “office” in the CPE

name, it’s much more difficult for that process to be automated and it’s even more difficult, time

consuming and expensive to research applications with which an analyst is not familiar.”

                                it is the new convention that allows such mistakes, while in the existing CPE specification it is easy to group all office products under “cpe:2.3:a:Microsoft:office:”, thus excluding “cpe:2.3:a:sun:openoffice:3.1.1” , “cpe:2.3a:microsoft:office_msodatasourcecontrol_activex” etc.

o   So, we do not agree that

“Since CPE 2.3 allows for wildcard text characters and has the Applicability Language Specification,

it is expected that using the software publisher’s real product name will have no long‐term negative impacts.” (p.21)

·         In other words- CPE’s feature of allowing logical groupings of products would be severely damaged.

o   This feature is very important when dealing with vulnerability report and discovery, as one does not always have information regarding the exact vulnerable editions, and she needs a way to specify “any edition of this product”.

 

We hope that a way can be found to integrate the two projects without harming neither.

 

Best Regards,

Stav Kaufman

[hidden email]

Office: +972-9-9545922

 

    

 

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, February 01, 2012 8:18 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Automation of CPE names using certified SWID tags

 

CPE Community,

 

This message summarizes a recently-released proposal, authored by TagVault.org with assistance from MITRE, describing how software identification (SWID) tags for identifying software installed on computing assets can integrate with and potentially automate the creation of  CPE names.  Further information and the full proposal are available here: http://tagvault.org./Automating_CPE_name_creation

 

Over the next several weeks I'll be posting updates with additional information about the proposal, and fielding questions.  As you will learn, although the proposal itself is not directed to the CPE community, it will require changes on "our side" to some of the conventions we have been using to assign names to products, if the proposal is to fully succeed.  Through an extended e-mail based discussion carried out on the CPE Community Discussion List,  I hope to clearly describe those changes and solicit your feedback and recommendations about them.  Ultimately I hope to drive towards a community consensus on what changes we are willing to make.  This consensus will eventually be framed as a set of recommendations to NIST regarding CPE Dictionary operation and maintenance.

 

IN MORE DETAIL

 

As I mentioned in an email to this list on 23 December 2011, MITRE joined TagVault.org as a Corporate Member during 2011.  TagVault is a non-profit organization formed as a program of IEEE-ISTO to be a registration and certification authority for SWID tags, and to provide a forum for sharing information and resources about software tags among software publishers, tool providers and software asset management practitioners.

 

The SWID tag is defined by an international standard, ISO/IEC 19770-2:2009.  The standard specifies the content, format and installation location of XML documents, called SWID tags, which are shipped with software products and installed/uninstalled on computing endpoints whenever the products are installed/uninstalled.  If a software product conforms to the SWID standard, then the presence of a SWID tag on a computing endpoint provides a high degree of proof that the product is actually installed and able to operate on that endpoint (and the absence of the tag strongly implies that the product is not installed).

 

Over the last several months, MITRE and TagVault have each been working to learn more about SWID tagging and CPE naming, respectively.  We've recognized that while each effort has unique goals, audiences and stakeholders, there are areas of overlap where both efforts could benefit substantially from forging closer ties.  With that in mind, we have been collaborating on ways to insert a CPE name-assignment step into the procedure that software publishers would follow when creating SWID tags for their products.  The proposal at the link above captures the latest draft of our joint work on this topic.

 

The proposal, directed to the SWID community, suggests revisions to the SWID tag format and creation process such that every new SWID tag has an embedded  unique identifier which is the product's CPE name as assigned by the publisher.  This proposal is now being circulated for comment among SWID stakeholders.  Let me underscore what this means:  the SWID community is considering revisions to their own technical standard in order to build an explicit bridge to CPE and SCAP.

 

If the proposal gains support and is implemented (i.e., the ISO/IEC 19770-2 standard is revised and published), it could prove to be a major win for both communities.  For the CPE community, to the extent that SWID tagging grows in adoption, we would gain a stream of new CPE names flowing into the CPE Dictionary which are publisher-defined, authoritative, and directly linked to the discoverable SWID tags.  In short, industry success of "CPE-enabled SWID tags" would make CPE itself more useful, and would also help solve a long-standing problem that has plagued CPE--that of automating the association of a CPE name with a discoverable "fingerprint" on a computing endpoint.  (In this scenario, each product's SWID tag becomes its fingerprint, and each discovered SWID tag contains the product's CPE name.)  For the SWID community, CPE-enabled SWID tags addresses a gap in the SWID tag value proposition, by adding a pathway (via CPE ) for SWID tags to help address software assurance challenges.

 

In the interest of keeping this message (relatively) short, I'll stop here and simply encourage you to find some time to look over the proposal and post any comments or questions you may have to this list.  As I said at the beginning of this note, a careful reading will reveal that the CPE community will need to consider certain changes in our naming conventions, so that publisher-created CPE names embedded in SWIDs can be directly imported into the CPE Dictionary without additional review.  I'll post more information about that in the weeks ahead.

 

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

 

Reply | Threaded
Open this post in threaded view
|

Re: Automation of CPE names using certified SWID tags (UNCLASSIFIED)

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

I'd like to chime in on this.  Mr Raviv's issues are all valid, BUT...  The current process of manually generating CPE names by second-guessing the names assigned by distributors isn't sustainable.  We're automatically generating CPE 2.2-compliant (using the tildes per CPE 2.3 guidance) names across roughly 11000 devices in the DoD.  The process of manually validating each name, one-at-a-time, takes a lot of effort and no one is ponying up the manpower to do it.

Right now, a Windows-only registry scrape across all computers returns 23,800+ unique names that represent OS's, applications, patchs, hardware drivers, libraries, and other installed software.  We haven't expanded to the other 2.2million+ computers across the DoD or into non-Windows, but I expect the list to grow substantially when we do.

Unless ~someone~ at NIST or MITRE is going to resource the analysis of this quantity of names, we'll have to embrace some level of automation.

It's my plan to only match our auto-generated names against the NIST CPE dictionary when a name already exists in the NIST CPE dictionary.  Otherwise the process of manually reviewing every potential CPE name is too hard and expensive.

Matching would be much easier (from an automation perspective) if NIST composed their CPE names using an automated process versus the existing manual process.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]


-----Original Message-----
From: Stav Raviv [mailto:[hidden email]]
Sent: Thursday, February 09, 2012 3:59 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Automation of CPE names using certified SWID tags

Dear Brant,

 

The proposal to integrate CPE and SWID seems to offer an opportunity for great progress. For us, in risk management business <http://www.skyboxsecurity.com/> , the success of this project is extremely desired.

We currently use CPE in our products and would like to extend our reliance on it even further.

 

Reading the referenced proposal (http://tagvault.org./Automating_CPE_name_creation), though, we immediately had some doubts, that we would be glad if you could  resolve.

 

 

The most pressing issue is regarding the changes proposed to the product attribute conventions (section 3.3, p. 15):

“Our proposal for the automated generation of CPE names within SWID tags is to fill the CPE ‘product’

attribute with the title as the publisher defines it. Thus, Microsoft Office Professional 2010 would have

the Product attribute in the CPE name be “Microsoft_Office_Professional_2010” (spaces converted to

underscores in order to conform with the CPE 2.3 naming specification).

This will require a slightly different applicability statement if the statement needs to reference a generic

edition of the product. Instead of referencing “office”, the applicability statement would reference, e.g.,

“Microsoft_Office*” or even just “*office*”.”

 

We believe that this is problematic in a few levels:

・         In a logical level:

It creates redundancy (which might also allow inconsistencies). E.g.- a duplication of the vendor name, edition, etc.

・         In a practical level, for matching purposes:

o   When one wants to match all, e.g., Office, versions and editions using the current specification, she would use “cpe:2.3:a:microsoft:office::::::::” (with or without the trailing ::::::::)

But according to the new suggestion, she would have to use “cpe:2.3:a:microsoft.com:*office*::::::::” (with or without the trailing ::::::::) or something of that sort

This would not allow to differentiate Office’s add-ons, plugins, etc. from the actual Office product.

o   In contrary to what is said in p. 15:

“One problem with this CPE naming convention (at least, in the context of the “Microsoft Office

Professional 2010” example) is that many products are Microsoft Office plug‐ins or Microsoft Office add-ons

which could also be mistakenly identified as being in the “office” family. Though it’s relatively easy

for a human to understand that the add‐ons and plug‐ins should not be identified as “office” in the CPE

name, it’s much more difficult for that process to be automated and it’s even more difficult, time

consuming and expensive to research applications with which an analyst is not familiar.”

                                it is the new convention that allows such mistakes, while in the existing CPE specification it is easy to group all office products under “cpe:2.3:a:Microsoft:office:”, thus excluding “cpe:2.3:a:sun:openoffice:3.1.1” , “cpe:2.3a:microsoft:office_msodatasourcecontrol_activex” etc.

o   So, we do not agree that

“Since CPE 2.3 allows for wildcard text characters and has the Applicability Language Specification,

it is expected that using the software publisher’s real product name will have no long‐term negative impacts.” (p.21)

・         In other words- CPE’s feature of allowing logical groupings of products would be severely damaged.

o   This feature is very important when dealing with vulnerability report and discovery, as one does not always have information regarding the exact vulnerable editions, and she needs a way to specify “any edition of this product”.

 

We hope that a way can be found to integrate the two projects without harming neither.

 

Best Regards,

Stav Kaufman

[hidden email]

Office: +972-9-9545922

 

 <http://www.skyboxsecurity.com/>    <http://twitter.com/skyboxsecurity>   <http://www.linkedin.com/companies/skybox-security>  

 

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Wednesday, February 01, 2012 8:18 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Automation of CPE names using certified SWID tags

 

CPE Community,

 

This message summarizes a recently-released proposal, authored by TagVault.org with assistance from MITRE, describing how software identification (SWID) tags for identifying software installed on computing assets can integrate with and potentially automate the creation of  CPE names.  Further information and the full proposal are available here: http://tagvault.org./Automating_CPE_name_creation

 

Over the next several weeks I'll be posting updates with additional information about the proposal, and fielding questions.  As you will learn, although the proposal itself is not directed to the CPE community, it will require changes on "our side" to some of the conventions we have been using to assign names to products, if the proposal is to fully succeed.  Through an extended e-mail based discussion carried out on the CPE Community Discussion List,  I hope to clearly describe those changes and solicit your feedback and recommendations about them.  Ultimately I hope to drive towards a community consensus on what changes we are willing to make.  This consensus will eventually be framed as a set of recommendations to NIST regarding CPE Dictionary operation and maintenance.

 

IN MORE DETAIL

 

As I mentioned in an email to this list on 23 December 2011, MITRE joined TagVault.org as a Corporate Member during 2011.  TagVault is a non-profit organization formed as a program of IEEE-ISTO to be a registration and certification authority for SWID tags, and to provide a forum for sharing information and resources about software tags among software publishers, tool providers and software asset management practitioners.

 

The SWID tag is defined by an international standard, ISO/IEC 19770-2:2009.  The standard specifies the content, format and installation location of XML documents, called SWID tags, which are shipped with software products and installed/uninstalled on computing endpoints whenever the products are installed/uninstalled.  If a software product conforms to the SWID standard, then the presence of a SWID tag on a computing endpoint provides a high degree of proof that the product is actually installed and able to operate on that endpoint (and the absence of the tag strongly implies that the product is not installed).

 

Over the last several months, MITRE and TagVault have each been working to learn more about SWID tagging and CPE naming, respectively.  We've recognized that while each effort has unique goals, audiences and stakeholders, there are areas of overlap where both efforts could benefit substantially from forging closer ties.  With that in mind, we have been collaborating on ways to insert a CPE name-assignment step into the procedure that software publishers would follow when creating SWID tags for their products.  The proposal at the link above captures the latest draft of our joint work on this topic.

 

The proposal, directed to the SWID community, suggests revisions to the SWID tag format and creation process such that every new SWID tag has an embedded  unique identifier which is the product's CPE name as assigned by the publisher.  This proposal is now being circulated for comment among SWID stakeholders.  Let me underscore what this means:  the SWID community is considering revisions to their own technical standard in order to build an explicit bridge to CPE and SCAP.

 

If the proposal gains support and is implemented (i.e., the ISO/IEC 19770-2 standard is revised and published), it could prove to be a major win for both communities.  For the CPE community, to the extent that SWID tagging grows in adoption, we would gain a stream of new CPE names flowing into the CPE Dictionary which are publisher-defined, authoritative, and directly linked to the discoverable SWID tags.  In short, industry success of "CPE-enabled SWID tags" would make CPE itself more useful, and would also help solve a long-standing problem that has plagued CPE--that of automating the association of a CPE name with a discoverable "fingerprint" on a computing endpoint.  (In this scenario, each product's SWID tag becomes its fingerprint, and each discovered SWID tag contains the product's CPE name.)  For the SWID community, CPE-enabled SWID tags addresses a gap in the SWID tag value proposition, by adding a pathway (via CPE ) for SWID tags to help address software assurance c
 hallenges.

 

In the interest of keeping this message (relatively) short, I'll stop here and simply encourage you to find some time to look over the proposal and post any comments or questions you may have to this list.  As I said at the beginning of this note, a careful reading will reveal that the CPE community will need to consider certain changes in our naming conventions, so that publisher-created CPE names embedded in SWIDs can be directly imported into the CPE Dictionary without additional review.  I'll post more information about that in the weeks ahead.

 

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

 


Classification: UNCLASSIFIED
Caveats: NONE



smime.p7s (15K) Download Attachment