Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

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

Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

steveklos

Folks,

 

I wanted to give a very quick update to the e-mail from Brant.

 

The document on the TagVault.org website was updated this evening.  If you downloaded V1.0, please update the document to the latest – V2.0.  The updated document is on the same webpage you visited previously - http://tagvault.org/Automating_CPE_name_creation.

 

Based on further communications with ISO development members and with TagVault.org members, some additional elements are being added to the SWID extended set.  These elements generally augment software identification efforts for security, compliance and logistics in a generic sense, but also remove some of the issues that were voiced regarding the resulting CPE names that would be generated.  Since these new elements provide additional capability to the SWID tag in a generic sense, the final versions of these elements will be incorporated into the ISO/IEC 19770-2 revision which will start in August.

 

Getting to the point, CPE names generated from certified SWID tags using these newly defined elements will look as follows:

 

     cpe:2.3:a:tagvault.org:Tag_Creation_and_Signing_Utility:1.0.0.0:-:-:-:-:-:-:certified_tag
     cpe:2.3:a:symantec.com: Enterprise_Vault:10.0.1.0:-:-:-:-:-:-:certified_tag
     cpe:2.3:a:microsoft.com: Office _2007:12.0.6607.1000:service_pack_3:-:-: Professional:-:-:certified_tag

 

A few notes –

 

1)      Because we need to ensure unique id’s for the companies, the domain name is being used – this is the same as with Version 1.0 of the integration document.

2)      We have added a product_name to the SWID tag.  The product name is different from the data in the add-remove program list, so instead of “Microsoft Office Professional 2010” that we saw in V1, we now will see, “Office…”.

3)      There is one issue when it comes to versions (and the product attribute) – software applications have two versions as far as CPE is concerned.  There is the marketing version (in Office that would be 2003, 2007, 2010, etc) and the product version 11.xxx, 12.xxx, 14.xxx (note, there is no version 13 of the product version in distribution).  CPE only has one area for version data and because CPE names and the SCAP infrastructure should typically more about code base changes than the licensing version, we’ve incorporated the licensing version number in the title as the second component.  This will mean that a wild card will need to be used for applicability statements, but only in those cases where a whole set of different licensing versions are included.

4)      The rest should be relatively obvious with two remaining details

a.      the update attribute (in SWID vernacular, the product_update), will be defined by the publisher as they want to see it, so it may be SP2 or Service_Pack_2.  The key is that it will be consistently applied by way of validating the data against a registration DB.

b.      the target_hw attribute (in SWID vernacular, the target_platform) will validate against a registration set of data, but thus far, I’ve not found a good source of initial values to include.  X32 and X64 seem to be used relatively consistently, but if anyone has a good source of platform values (especially one that includes definitions) and that list can be included in the TagVault.org document, please let me know.

I’m very interested in comments/thoughts/suggestions.

 

Enjoy!

 

Cheers,

 

SK

 

From: Cheikes, Brant A. [hidden email]
Sent: Monday, April 23, 2012 5:52 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Microsoft announces support for ISO/IEC 19770-2:2009 Software Identification Tags

 

CPE Community,

 

Last week Microsoft announced:  Microsoft is collaborating with national standards bodies and industry leading groups to further the development of the ISO/IEC 19770-2:2009 standard for software identification tags. We are folding ISO/IEC 19770-2:2009 support into our product planning cycles, and will begin to include these tags in future product releases.

http://www.microsoft.com/sam/en/us/softwareid.aspx

 

This is a significant step forward for efforts to standardize software product naming and discovery.  To the extent that software identification (SWID) tags become pervasive, it will greatly ease the challenges associated with inventorying the software products installed on computing endpoints and correlating inventory information with vulnerability reports, security guidance, etc.

 

As I announced earlier this year, MITRE and TagVault.org have been working together on a proposal to integrate CPE names into SWID tags, with the goal of enabling publishers to create valid CPE names at the same time they create SWID tags for their products.  The first version of this proposal is posted on the TagVault website:

http://tagvault.org/Automating_CPE_name_creation

 

During the July 2012 SCAP Developer Days Conference at MITRE Bedford, we anticipate two related sessions, one providing a general overview of SWID tags, and a second focusing specifically on the proposal for embedding CPE names in SWID tags.  This will be a great opportunity to learn more about software identification tags and interoperability with CPE.

 

Cheers,

/Brant

 

The MITRE Corporation

202 Burlington Road, M/S K302

Bedford, MA  01730-1420

Tel. 781-271-7505, Cell. 617-694-8180

Reply | Threaded
Open this post in threaded view
|

Re: Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
I'm not comfortable that the use of domain names will solve more problems than it creates.  Currently we can't use tags to derive installed software inventories, so we're using the MS uninstall registry along with RPM and equivalents for 'nix systems.

Using manually created names that are different for the TagVault tags from what the developers put in the uninstall registry will make the process of deconflicting/de-duplicating the data collected from the uninstall registry/package manager from TagVault tags much more difficult.  I would encourage you to make attempts to converge on a consistent set of names across the board instead of creating different, competing names (i.e. your "office" example below).

This problem will persist until everyone that writes software uses TagVault tags, a time period I'm thinking will last for decades.

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


-----Original Message-----
From: Steve Klos [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 1:43 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

Folks,

 

I wanted to give a very quick update to the e-mail from Brant.

 

The document on the TagVault.org website was updated this evening.  If you downloaded V1.0, please update the document to the latest - V2.0.  The updated document is on the same webpage you visited previously - http://tagvault.org/Automating_CPE_name_creation.

 

Based on further communications with ISO development members and with TagVault.org members, some additional elements are being added to the SWID extended set.  These elements generally augment software identification efforts for security, compliance and logistics in a generic sense, but also remove some of the issues that were voiced regarding the resulting CPE names that would be generated.  Since these new elements provide additional capability to the SWID tag in a generic sense, the final versions of these elements will be incorporated into the ISO/IEC 19770-2 revision which will start in August.

 

Getting to the point, CPE names generated from certified SWID tags using these newly defined elements will look as follows:

 

     cpe:2.3:a:tagvault.org:Tag_Creation_and_Signing_Utility:1.0.0.0:-:-:-:-:-:-:certified_tag
     cpe:2.3:a:symantec.com: Enterprise_Vault:10.0.1.0:-:-:-:-:-:-:certified_tag
     cpe:2.3:a:microsoft.com: Office _2007:12.0.6607.1000:service_pack_3:-:-: Professional:-:-:certified_tag

 

A few notes -

 

1)      Because we need to ensure unique id's for the companies, the domain name is being used - this is the same as with Version 1.0 of the integration document.

2)      We have added a product_name to the SWID tag.  The product name is different from the data in the add-remove program list, so instead of "Microsoft Office Professional 2010" that we saw in V1, we now will see, "Office.".

3)      There is one issue when it comes to versions (and the product attribute) - software applications have two versions as far as CPE is concerned.  There is the marketing version (in Office that would be 2003, 2007, 2010, etc) and the product version 11.xxx, 12.xxx, 14.xxx (note, there is no version 13 of the product version in distribution).  CPE only has one area for version data and because CPE names and the SCAP infrastructure should typically more about code base changes than the licensing version, we've incorporated the licensing version number in the title as the second component.  This will mean that a wild card will need to be used for applicability statements, but only in those cases where a whole set of different licensing versions are included.

4)      The rest should be relatively obvious with two remaining details

a.      the update attribute (in SWID vernacular, the product_update), will be defined by the publisher as they want to see it, so it may be SP2 or Service_Pack_2.  The key is that it will be consistently applied by way of validating the data against a registration DB.

b.      the target_hw attribute (in SWID vernacular, the target_platform) will validate against a registration set of data, but thus far, I've not found a good source of initial values to include.  X32 and X64 seem to be used relatively consistently, but if anyone has a good source of platform values (especially one that includes definitions) and that list can be included in the TagVault.org document, please let me know.

I'm very interested in comments/thoughts/suggestions.

 

Enjoy!

 

Cheers,

 

SK

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, April 23, 2012 5:52 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Microsoft announces support for ISO/IEC 19770-2:2009 Software Identification Tags

 

CPE Community,

 

Last week Microsoft announced:  Microsoft is collaborating with national standards bodies and industry leading groups to further the development of the ISO/IEC 19770-2:2009 standard for software identification tags. We are folding ISO/IEC 19770-2:2009 support into our product planning cycles, and will begin to include these tags in future product releases.

http://www.microsoft.com/sam/en/us/softwareid.aspx

 

This is a significant step forward for efforts to standardize software product naming and discovery.  To the extent that software identification (SWID) tags become pervasive, it will greatly ease the challenges associated with inventorying the software products installed on computing endpoints and correlating inventory information with vulnerability reports, security guidance, etc.

 

As I announced earlier this year, MITRE and TagVault.org have been working together on a proposal to integrate CPE names into SWID tags, with the goal of enabling publishers to create valid CPE names at the same time they create SWID tags for their products.  The first version of this proposal is posted on the TagVault website:

http://tagvault.org/Automating_CPE_name_creation

 

During the July 2012 SCAP Developer Days Conference at MITRE Bedford, we anticipate two related sessions, one providing a general overview of SWID tags, and a second focusing specifically on the proposal for embedding CPE names in SWID tags.  This will be a great opportunity to learn more about software identification tags and interoperability with CPE.

 

Cheers,

/Brant

 

The MITRE Corporation

202 Burlington Road, M/S K302

Bedford, MA  01730-1420

Tel. 781-271-7505, Cell. 617-694-8180


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

Re: Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

steveklos
Joe,

I understand the thought behind your comment and I'm open to suggestions.
Do you have any thoughts on alternatives?  I'll provide some of the details
behind the thinking that was put into the use of the domain name below so
you can at least get a picture of how the domain became the suggested option
in this version of the document...

For the CPE vendor attribute, a few key issues from the perspective of
creating a SWID are:

  - Must ensure that the vendor details are unique
  - Must ensure that the process by which a vendor defines and uses the name
is easily replicated and understandable to the vendor.
  - Must to ensure the there is no manual process required post tag creation

We also want to meet some other requirements

  - Should provide a way to identify for older, non-tagged software
  - Should be short (not sure how much of a requirement this is)
 
There seem to be three potential options for this that are readily apparent
and possibly alternatives that others can  suggest:

Domain name  - Provides for short and unique - (e.g. Microsoft.com).  Since
a domain name is registered through the DNS system, there should not be
collisions in this namespace.  Note that software titles are purchased (at
which time the domain may or may not change hands), but for a given instance
of a given product, the domain will be consistently applied.

Domain name sans TLD - The domain name without the top level domain (TLD)
included - (e.g. Microsoft).  There can be collisions in this namespace
since one company could own a .com domain and another could own the .org.
For example, Flexera (owners of installshield and other tools), does not
appear to own the flexera.org, Flexera.ca or the Flexera.me TLDs.  Add to
this other countries TLDs (.co.uk, .com.aus, etc) and it would become
difficult to impossible to distinguish different vendors - especially if
they are working in different countries and use the same company name.

Full Company name - the name specified by the company (e.g. Microsoft
Corporation).  There are many ways company names are represented in software
- especially older software.  A few ways Microsoft could be represented -
"Microsoft", "Microsoft, Inc.", "Microsoft, Inc", "Microsoft Corp.", etc...
This seems to be the hardest option to match since it is unclear which of
the many versions should be used.  For automated Tag creation, asking a
vendor to specify their "commonly used reference name" seems problematic.

Of these options - it would seem that a domain is more likely something that
can be derived from a RPM package (or equiv 'nix install package) as well as
from the MSI and Add/Remove on Windows.  It's not perfect, but when you're
referencing legacy software, I'm not sure there is a perfect...  In the
Windows installer details, for example, I see URL's provided for a large
proportion of the software installed on my device.  

The other thing to consider - if software is currently still under a support
contract, the vendor can provide a patch to provide a SWID tag enabling
accurate identification.  Likewise, I expect to see 3rd party organizations
providing the ability to include a tag on a computing device as it does a
discovery process.  This tag would not be owned by the vendor and would be
only as accurate as the discovery tool used, but would provide significantly
better detail than is available now.

There will be open source applications for which it may not be clear who the
publisher is.  7-zip for example (a commonly used compression utility),
doesn't identify a company name, nor a help link.  The only reference I see
in the install DB for this is the copyright statement which would need to be
parsed.  Having said that, there is a domain for this application -
7zip.com.  

When it comes to open source where there isn't one owner or one vendor, it's
possible that the vendor may go back to the source repository - such as
"sourceforge.org" as the vendor...  

Love to hear your thoughts on this.

Cheers,

SK

-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 4:47 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant
Distributed Earlier on Monday, 4/23

I'm not comfortable that the use of domain names will solve more problems
than it creates.  Currently we can't use tags to derive installed software
inventories, so we're using the MS uninstall registry along with RPM and
equivalents for 'nix systems.

Using manually created names that are different for the TagVault tags from
what the developers put in the uninstall registry will make the process of
deconflicting/de-duplicating the data collected from the uninstall
registry/package manager from TagVault tags much more difficult.  I would
encourage you to make attempts to converge on a consistent set of names
across the board instead of creating different, competing names (i.e. your
"office" example below).

This problem will persist until everyone that writes software uses TagVault
tags, a time period I'm thinking will last for decades.

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


-----Original Message-----
From: Steve Klos [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 1:43 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant Distributed
Earlier on Monday, 4/23

Folks,

 

I wanted to give a very quick update to the e-mail from Brant.

 

The document on the TagVault.org website was updated this evening.  If you
downloaded V1.0, please update the document to the latest - V2.0.  The
updated document is on the same webpage you visited previously -
http://tagvault.org/Automating_CPE_name_creation.

 

Based on further communications with ISO development members and with
TagVault.org members, some additional elements are being added to the SWID
extended set.  These elements generally augment software identification
efforts for security, compliance and logistics in a generic sense, but also
remove some of the issues that were voiced regarding the resulting CPE names
that would be generated.  Since these new elements provide additional
capability to the SWID tag in a generic sense, the final versions of these
elements will be incorporated into the ISO/IEC 19770-2 revision which will
start in August.

 

Getting to the point, CPE names generated from certified SWID tags using
these newly defined elements will look as follows:

 

 
cpe:2.3:a:tagvault.org:Tag_Creation_and_Signing_Utility:1.0.0.0:-:-:-:-:-:-:
certified_tag
     cpe:2.3:a:symantec.com:
Enterprise_Vault:10.0.1.0:-:-:-:-:-:-:certified_tag
     cpe:2.3:a:microsoft.com: Office
_2007:12.0.6607.1000:service_pack_3:-:-: Professional:-:-:certified_tag

 

A few notes -

 

1)      Because we need to ensure unique id's for the companies, the domain
name is being used - this is the same as with Version 1.0 of the integration
document.

2)      We have added a product_name to the SWID tag.  The product name is
different from the data in the add-remove program list, so instead of
"Microsoft Office Professional 2010" that we saw in V1, we now will see,
"Office.".

3)      There is one issue when it comes to versions (and the product
attribute) - software applications have two versions as far as CPE is
concerned.  There is the marketing version (in Office that would be 2003,
2007, 2010, etc) and the product version 11.xxx, 12.xxx, 14.xxx (note, there
is no version 13 of the product version in distribution).  CPE only has one
area for version data and because CPE names and the SCAP infrastructure
should typically more about code base changes than the licensing version,
we've incorporated the licensing version number in the title as the second
component.  This will mean that a wild card will need to be used for
applicability statements, but only in those cases where a whole set of
different licensing versions are included.

4)      The rest should be relatively obvious with two remaining details

a.      the update attribute (in SWID vernacular, the product_update), will
be defined by the publisher as they want to see it, so it may be SP2 or
Service_Pack_2.  The key is that it will be consistently applied by way of
validating the data against a registration DB.

b.      the target_hw attribute (in SWID vernacular, the target_platform)
will validate against a registration set of data, but thus far, I've not
found a good source of initial values to include.  X32 and X64 seem to be
used relatively consistently, but if anyone has a good source of platform
values (especially one that includes definitions) and that list can be
included in the TagVault.org document, please let me know.

I'm very interested in comments/thoughts/suggestions.

 

Enjoy!

 

Cheers,

 

SK

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, April 23, 2012 5:52 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Microsoft announces support for ISO/IEC
19770-2:2009 Software Identification Tags

 

CPE Community,

 

Last week Microsoft announced:  Microsoft is collaborating with national
standards bodies and industry leading groups to further the development of
the ISO/IEC 19770-2:2009 standard for software identification tags. We are
folding ISO/IEC 19770-2:2009 support into our product planning cycles, and
will begin to include these tags in future product releases.

http://www.microsoft.com/sam/en/us/softwareid.aspx

 

This is a significant step forward for efforts to standardize software
product naming and discovery.  To the extent that software identification
(SWID) tags become pervasive, it will greatly ease the challenges associated
with inventorying the software products installed on computing endpoints and
correlating inventory information with vulnerability reports, security
guidance, etc.

 

As I announced earlier this year, MITRE and TagVault.org have been working
together on a proposal to integrate CPE names into SWID tags, with the goal
of enabling publishers to create valid CPE names at the same time they
create SWID tags for their products.  The first version of this proposal is
posted on the TagVault website:

http://tagvault.org/Automating_CPE_name_creation

 

During the July 2012 SCAP Developer Days Conference at MITRE Bedford, we
anticipate two related sessions, one providing a general overview of SWID
tags, and a second focusing specifically on the proposal for embedding CPE
names in SWID tags.  This will be a great opportunity to learn more about
software identification tags and interoperability with CPE.

 

Cheers,

/Brant

 

The MITRE Corporation

202 Burlington Road, M/S K302

Bedford, MA  01730-1420

Tel. 781-271-7505, Cell. 617-694-8180
Reply | Threaded
Open this post in threaded view
|

Re: Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
I've attached a sample list of auto-generated CPE names from a few thousand devices (Windows only).  Just looking at the names in use today, I would tend to prefer using company names versus domains.  Many of the vendor names make me think that expecting/requiring a registered dns name may not be realistic as an industry-wide solution.

We certainly wouldn't expect all organizations within the DoD who write software to go out and get a DNS name they can use for SWID tags.

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


-----Original Message-----
From: Steve Klos [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 9:27 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

Joe,

I understand the thought behind your comment and I'm open to suggestions.
Do you have any thoughts on alternatives?  I'll provide some of the details
behind the thinking that was put into the use of the domain name below so
you can at least get a picture of how the domain became the suggested option
in this version of the document...

For the CPE vendor attribute, a few key issues from the perspective of
creating a SWID are:

  - Must ensure that the vendor details are unique
  - Must ensure that the process by which a vendor defines and uses the name
is easily replicated and understandable to the vendor.
  - Must to ensure the there is no manual process required post tag creation

We also want to meet some other requirements

  - Should provide a way to identify for older, non-tagged software
  - Should be short (not sure how much of a requirement this is)
 
There seem to be three potential options for this that are readily apparent
and possibly alternatives that others can  suggest:

Domain name  - Provides for short and unique - (e.g. Microsoft.com).  Since
a domain name is registered through the DNS system, there should not be
collisions in this namespace.  Note that software titles are purchased (at
which time the domain may or may not change hands), but for a given instance
of a given product, the domain will be consistently applied.

Domain name sans TLD - The domain name without the top level domain (TLD)
included - (e.g. Microsoft).  There can be collisions in this namespace
since one company could own a .com domain and another could own the .org.
For example, Flexera (owners of installshield and other tools), does not
appear to own the flexera.org, Flexera.ca or the Flexera.me TLDs.  Add to
this other countries TLDs (.co.uk, .com.aus, etc) and it would become
difficult to impossible to distinguish different vendors - especially if
they are working in different countries and use the same company name.

Full Company name - the name specified by the company (e.g. Microsoft
Corporation).  There are many ways company names are represented in software
- especially older software.  A few ways Microsoft could be represented -
"Microsoft", "Microsoft, Inc.", "Microsoft, Inc", "Microsoft Corp.", etc...
This seems to be the hardest option to match since it is unclear which of
the many versions should be used.  For automated Tag creation, asking a
vendor to specify their "commonly used reference name" seems problematic.

Of these options - it would seem that a domain is more likely something that
can be derived from a RPM package (or equiv 'nix install package) as well as
from the MSI and Add/Remove on Windows.  It's not perfect, but when you're
referencing legacy software, I'm not sure there is a perfect...  In the
Windows installer details, for example, I see URL's provided for a large
proportion of the software installed on my device.  

The other thing to consider - if software is currently still under a support
contract, the vendor can provide a patch to provide a SWID tag enabling
accurate identification.  Likewise, I expect to see 3rd party organizations
providing the ability to include a tag on a computing device as it does a
discovery process.  This tag would not be owned by the vendor and would be
only as accurate as the discovery tool used, but would provide significantly
better detail than is available now.

There will be open source applications for which it may not be clear who the
publisher is.  7-zip for example (a commonly used compression utility),
doesn't identify a company name, nor a help link.  The only reference I see
in the install DB for this is the copyright statement which would need to be
parsed.  Having said that, there is a domain for this application -
7zip.com.  

When it comes to open source where there isn't one owner or one vendor, it's
possible that the vendor may go back to the source repository - such as
"sourceforge.org" as the vendor...  

Love to hear your thoughts on this.

Cheers,

SK

-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 4:47 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant
Distributed Earlier on Monday, 4/23

I'm not comfortable that the use of domain names will solve more problems
than it creates.  Currently we can't use tags to derive installed software
inventories, so we're using the MS uninstall registry along with RPM and
equivalents for 'nix systems.

Using manually created names that are different for the TagVault tags from
what the developers put in the uninstall registry will make the process of
deconflicting/de-duplicating the data collected from the uninstall
registry/package manager from TagVault tags much more difficult.  I would
encourage you to make attempts to converge on a consistent set of names
across the board instead of creating different, competing names (i.e. your
"office" example below).

This problem will persist until everyone that writes software uses TagVault
tags, a time period I'm thinking will last for decades.

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


-----Original Message-----
From: Steve Klos [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 1:43 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant Distributed
Earlier on Monday, 4/23

Folks,

 

I wanted to give a very quick update to the e-mail from Brant.

 

The document on the TagVault.org website was updated this evening.  If you
downloaded V1.0, please update the document to the latest - V2.0.  The
updated document is on the same webpage you visited previously -
http://tagvault.org/Automating_CPE_name_creation.

 

Based on further communications with ISO development members and with
TagVault.org members, some additional elements are being added to the SWID
extended set.  These elements generally augment software identification
efforts for security, compliance and logistics in a generic sense, but also
remove some of the issues that were voiced regarding the resulting CPE names
that would be generated.  Since these new elements provide additional
capability to the SWID tag in a generic sense, the final versions of these
elements will be incorporated into the ISO/IEC 19770-2 revision which will
start in August.

 

Getting to the point, CPE names generated from certified SWID tags using
these newly defined elements will look as follows:

 

 
cpe:2.3:a:tagvault.org:Tag_Creation_and_Signing_Utility:1.0.0.0:-:-:-:-:-:-:
certified_tag
     cpe:2.3:a:symantec.com:
Enterprise_Vault:10.0.1.0:-:-:-:-:-:-:certified_tag
     cpe:2.3:a:microsoft.com: Office
_2007:12.0.6607.1000:service_pack_3:-:-: Professional:-:-:certified_tag

 

A few notes -

 

1)      Because we need to ensure unique id's for the companies, the domain
name is being used - this is the same as with Version 1.0 of the integration
document.

2)      We have added a product_name to the SWID tag.  The product name is
different from the data in the add-remove program list, so instead of
"Microsoft Office Professional 2010" that we saw in V1, we now will see,
"Office.".

3)      There is one issue when it comes to versions (and the product
attribute) - software applications have two versions as far as CPE is
concerned.  There is the marketing version (in Office that would be 2003,
2007, 2010, etc) and the product version 11.xxx, 12.xxx, 14.xxx (note, there
is no version 13 of the product version in distribution).  CPE only has one
area for version data and because CPE names and the SCAP infrastructure
should typically more about code base changes than the licensing version,
we've incorporated the licensing version number in the title as the second
component.  This will mean that a wild card will need to be used for
applicability statements, but only in those cases where a whole set of
different licensing versions are included.

4)      The rest should be relatively obvious with two remaining details

a.      the update attribute (in SWID vernacular, the product_update), will
be defined by the publisher as they want to see it, so it may be SP2 or
Service_Pack_2.  The key is that it will be consistently applied by way of
validating the data against a registration DB.

b.      the target_hw attribute (in SWID vernacular, the target_platform)
will validate against a registration set of data, but thus far, I've not
found a good source of initial values to include.  X32 and X64 seem to be
used relatively consistently, but if anyone has a good source of platform
values (especially one that includes definitions) and that list can be
included in the TagVault.org document, please let me know.

I'm very interested in comments/thoughts/suggestions.

 

Enjoy!

 

Cheers,

 

SK

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, April 23, 2012 5:52 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Microsoft announces support for ISO/IEC
19770-2:2009 Software Identification Tags

 

CPE Community,

 

Last week Microsoft announced:  Microsoft is collaborating with national
standards bodies and industry leading groups to further the development of
the ISO/IEC 19770-2:2009 standard for software identification tags. We are
folding ISO/IEC 19770-2:2009 support into our product planning cycles, and
will begin to include these tags in future product releases.

http://www.microsoft.com/sam/en/us/softwareid.aspx

 

This is a significant step forward for efforts to standardize software
product naming and discovery.  To the extent that software identification
(SWID) tags become pervasive, it will greatly ease the challenges associated
with inventorying the software products installed on computing endpoints and
correlating inventory information with vulnerability reports, security
guidance, etc.

 

As I announced earlier this year, MITRE and TagVault.org have been working
together on a proposal to integrate CPE names into SWID tags, with the goal
of enabling publishers to create valid CPE names at the same time they
create SWID tags for their products.  The first version of this proposal is
posted on the TagVault website:

http://tagvault.org/Automating_CPE_name_creation

 

During the July 2012 SCAP Developer Days Conference at MITRE Bedford, we
anticipate two related sessions, one providing a general overview of SWID
tags, and a second focusing specifically on the proposal for embedding CPE
names in SWID tags.  This will be a great opportunity to learn more about
software identification tags and interoperability with CPE.

 

Cheers,

/Brant

 

The MITRE Corporation

202 Burlington Road, M/S K302

Bedford, MA  01730-1420

Tel. 781-271-7505, Cell. 617-694-8180

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

Re: Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

Brant Cheikes
You're dealing with a present reality in which authoritative information
doesn't exist, so you're scraping data from registries and auto-generating a
mishmash of names.  Your list often contains multiple versions of the same
vendor name.  I don't see how this data should drive decisions about how to
standardize values for the CPE "vendor" field.

Let's focus on the primary SWID use case: software publishers adopt SWID
tagging and voluntarily populate the required fields.  Given that, we need
to be realistic.  The SWID tag offers two possible sources for a CPE
"vendor" name: the swid:name of the swid:software_creator (e.g., "Symantec
Corporation") or the domain name embedded in the swid:regid.  There is no
third option to require publishers to create a special "vendor name string
which the CPE community will like".  The current proposal recommends
standardizing on the domain name, and Steve has articulated the arguments
for that position.  If we were to standardize on the swid:name then the CPE
community would have to be happy with, e.g.,

cpe:/a:symantec_corporation:...
cpe:/a:hewlett-packard_corp:...
cpe:/a:adobe_systems_incorporated:...

That is, whatever the vendors themselves choose to standardize on as their
swid:name when creating SWID tags.  This means longer vendor name strings,
more variations in certain elements (like "Inc", "Corp", etc.), and also the
need to cope with embedded punctuation ("Adobe Systems, Inc.").  Each
options has advantages and disadvantages.  We'll need to discuss this at
Developer Days in July.

Third-party tagging is a whole different ball game.  I suspect you're
imagining that third-party tags will be created using a process very much
like your CPE-name auto-generation system, i.e., tools will scrape
registries and invent SWID tags based on what they find.  That is unlikely
to be the right technical solution.  SWID tags are intended to improve upon
today's Wild West product naming situation, not merely encode it.

Here's the bottom line:  the CPE community cannot expect a naming system
that has all the benefits of human curation (such as thoughtfully crafted
vendor names, product names, versions, update strings, etc.) and also scales
gracefully to the size of the real problem.

/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: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 10:32 AM
To: cpe-discussion-list CPE Community Forum
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant
Distributed Earlier on Monday, 4/23

I've attached a sample list of auto-generated CPE names from a few thousand
devices (Windows only).  Just looking at the names in use today, I would
tend to prefer using company names versus domains.  Many of the vendor names
make me think that expecting/requiring a registered dns name may not be
realistic as an industry-wide solution.

We certainly wouldn't expect all organizations within the DoD who write
software to go out and get a DNS name they can use for SWID tags.

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


-----Original Message-----
From: Steve Klos [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 9:27 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant
Distributed Earlier on Monday, 4/23

Joe,

I understand the thought behind your comment and I'm open to suggestions.
Do you have any thoughts on alternatives?  I'll provide some of the details
behind the thinking that was put into the use of the domain name below so
you can at least get a picture of how the domain became the suggested option
in this version of the document...

For the CPE vendor attribute, a few key issues from the perspective of
creating a SWID are:

  - Must ensure that the vendor details are unique
  - Must ensure that the process by which a vendor defines and uses the name
is easily replicated and understandable to the vendor.
  - Must to ensure the there is no manual process required post tag creation

We also want to meet some other requirements

  - Should provide a way to identify for older, non-tagged software
  - Should be short (not sure how much of a requirement this is)
 
There seem to be three potential options for this that are readily apparent
and possibly alternatives that others can  suggest:

Domain name  - Provides for short and unique - (e.g. Microsoft.com).  Since
a domain name is registered through the DNS system, there should not be
collisions in this namespace.  Note that software titles are purchased (at
which time the domain may or may not change hands), but for a given instance
of a given product, the domain will be consistently applied.

Domain name sans TLD - The domain name without the top level domain (TLD)
included - (e.g. Microsoft).  There can be collisions in this namespace
since one company could own a .com domain and another could own the .org.
For example, Flexera (owners of installshield and other tools), does not
appear to own the flexera.org, Flexera.ca or the Flexera.me TLDs.  Add to
this other countries TLDs (.co.uk, .com.aus, etc) and it would become
difficult to impossible to distinguish different vendors - especially if
they are working in different countries and use the same company name.

Full Company name - the name specified by the company (e.g. Microsoft
Corporation).  There are many ways company names are represented in software
- especially older software.  A few ways Microsoft could be represented -
"Microsoft", "Microsoft, Inc.", "Microsoft, Inc", "Microsoft Corp.", etc...
This seems to be the hardest option to match since it is unclear which of
the many versions should be used.  For automated Tag creation, asking a
vendor to specify their "commonly used reference name" seems problematic.

Of these options - it would seem that a domain is more likely something that
can be derived from a RPM package (or equiv 'nix install package) as well as
from the MSI and Add/Remove on Windows.  It's not perfect, but when you're
referencing legacy software, I'm not sure there is a perfect...  In the
Windows installer details, for example, I see URL's provided for a large
proportion of the software installed on my device.  

The other thing to consider - if software is currently still under a support
contract, the vendor can provide a patch to provide a SWID tag enabling
accurate identification.  Likewise, I expect to see 3rd party organizations
providing the ability to include a tag on a computing device as it does a
discovery process.  This tag would not be owned by the vendor and would be
only as accurate as the discovery tool used, but would provide significantly
better detail than is available now.

There will be open source applications for which it may not be clear who the
publisher is.  7-zip for example (a commonly used compression utility),
doesn't identify a company name, nor a help link.  The only reference I see
in the install DB for this is the copyright statement which would need to be
parsed.  Having said that, there is a domain for this application -
7zip.com.  

When it comes to open source where there isn't one owner or one vendor, it's
possible that the vendor may go back to the source repository - such as
"sourceforge.org" as the vendor...  

Love to hear your thoughts on this.

Cheers,

SK

-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 4:47 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant
Distributed Earlier on Monday, 4/23

I'm not comfortable that the use of domain names will solve more problems
than it creates.  Currently we can't use tags to derive installed software
inventories, so we're using the MS uninstall registry along with RPM and
equivalents for 'nix systems.

Using manually created names that are different for the TagVault tags from
what the developers put in the uninstall registry will make the process of
deconflicting/de-duplicating the data collected from the uninstall
registry/package manager from TagVault tags much more difficult.  I would
encourage you to make attempts to converge on a consistent set of names
across the board instead of creating different, competing names (i.e. your
"office" example below).

This problem will persist until everyone that writes software uses TagVault
tags, a time period I'm thinking will last for decades.

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


-----Original Message-----
From: Steve Klos [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 1:43 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant Distributed
Earlier on Monday, 4/23

Folks,

 

I wanted to give a very quick update to the e-mail from Brant.

 

The document on the TagVault.org website was updated this evening.  If you
downloaded V1.0, please update the document to the latest - V2.0.  The
updated document is on the same webpage you visited previously -
http://tagvault.org/Automating_CPE_name_creation.

 

Based on further communications with ISO development members and with
TagVault.org members, some additional elements are being added to the SWID
extended set.  These elements generally augment software identification
efforts for security, compliance and logistics in a generic sense, but also
remove some of the issues that were voiced regarding the resulting CPE names
that would be generated.  Since these new elements provide additional
capability to the SWID tag in a generic sense, the final versions of these
elements will be incorporated into the ISO/IEC 19770-2 revision which will
start in August.

 

Getting to the point, CPE names generated from certified SWID tags using
these newly defined elements will look as follows:

 

 
cpe:2.3:a:tagvault.org:Tag_Creation_and_Signing_Utility:1.0.0.0:-:-:-:-:-:-:
certified_tag
     cpe:2.3:a:symantec.com:
Enterprise_Vault:10.0.1.0:-:-:-:-:-:-:certified_tag
     cpe:2.3:a:microsoft.com: Office
_2007:12.0.6607.1000:service_pack_3:-:-: Professional:-:-:certified_tag

 

A few notes -

 

1)      Because we need to ensure unique id's for the companies, the domain
name is being used - this is the same as with Version 1.0 of the integration
document.

2)      We have added a product_name to the SWID tag.  The product name is
different from the data in the add-remove program list, so instead of
"Microsoft Office Professional 2010" that we saw in V1, we now will see,
"Office.".

3)      There is one issue when it comes to versions (and the product
attribute) - software applications have two versions as far as CPE is
concerned.  There is the marketing version (in Office that would be 2003,
2007, 2010, etc) and the product version 11.xxx, 12.xxx, 14.xxx (note, there
is no version 13 of the product version in distribution).  CPE only has one
area for version data and because CPE names and the SCAP infrastructure
should typically more about code base changes than the licensing version,
we've incorporated the licensing version number in the title as the second
component.  This will mean that a wild card will need to be used for
applicability statements, but only in those cases where a whole set of
different licensing versions are included.

4)      The rest should be relatively obvious with two remaining details

a.      the update attribute (in SWID vernacular, the product_update), will
be defined by the publisher as they want to see it, so it may be SP2 or
Service_Pack_2.  The key is that it will be consistently applied by way of
validating the data against a registration DB.

b.      the target_hw attribute (in SWID vernacular, the target_platform)
will validate against a registration set of data, but thus far, I've not
found a good source of initial values to include.  X32 and X64 seem to be
used relatively consistently, but if anyone has a good source of platform
values (especially one that includes definitions) and that list can be
included in the TagVault.org document, please let me know.

I'm very interested in comments/thoughts/suggestions.

 

Enjoy!

 

Cheers,

 

SK

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, April 23, 2012 5:52 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Microsoft announces support for ISO/IEC
19770-2:2009 Software Identification Tags

 

CPE Community,

 

Last week Microsoft announced:  Microsoft is collaborating with national
standards bodies and industry leading groups to further the development of
the ISO/IEC 19770-2:2009 standard for software identification tags. We are
folding ISO/IEC 19770-2:2009 support into our product planning cycles, and
will begin to include these tags in future product releases.

http://www.microsoft.com/sam/en/us/softwareid.aspx

 

This is a significant step forward for efforts to standardize software
product naming and discovery.  To the extent that software identification
(SWID) tags become pervasive, it will greatly ease the challenges associated
with inventorying the software products installed on computing endpoints and
correlating inventory information with vulnerability reports, security
guidance, etc.

 

As I announced earlier this year, MITRE and TagVault.org have been working
together on a proposal to integrate CPE names into SWID tags, with the goal
of enabling publishers to create valid CPE names at the same time they
create SWID tags for their products.  The first version of this proposal is
posted on the TagVault website:

http://tagvault.org/Automating_CPE_name_creation

 

During the July 2012 SCAP Developer Days Conference at MITRE Bedford, we
anticipate two related sessions, one providing a general overview of SWID
tags, and a second focusing specifically on the proposal for embedding CPE
names in SWID tags.  This will be a great opportunity to learn more about
software identification tags and interoperability with CPE.

 

Cheers,

/Brant

 

The MITRE Corporation

202 Burlington Road, M/S K302

Bedford, MA  01730-1420

Tel. 781-271-7505, Cell. 617-694-8180

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

Re: Update to Microsoft Details Brant Distributed Earlier on Monday, 4/23

steveklos
In reply to this post by WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Joe,

Just noted Brant's comments, so I'll defer further questions on the domain
name v.s. a curated name...  Be aware the actual process used to create a
CPE name can basically be any explicit rules that are defined for the
process.  The major caveat is that the process at least for CPE names
generated from a SWID must be consistent every time.  The SWID tag will
provide normative details from the publisher and these can be structured
into a CPE name based on the rules the CPE community approves...

Understand that this is a problem for legacy software, but there will be
options available to address that.  In fact, as the community and certified
repository grows, it would be relatively straight-forward to use rules to
create publisher names based on existing data sets.

What we want to avoid is what we see when we look at Adobe (note, you can
find numerous examples of this, Adobe is not the only company to have this
issue by a long shot) in the distribution you sent as an example, we have
the following publishers listed:

  adobe
  adobe_corp
  adobe_system_incorporated
  adobe_systems%2c_inc.
  adobe_systems%2c_inc
  adobe_systems%2c_incorporated
  adobe_systems
  adobe_systems_inc.
  adobe_systems_incorporated.
  adobe_systems_incorporated
  adobe_systems_incorporated_-_dsa_inc

If we utilized a community and registered repository of names, all of these
can readily be resolved to either "adobe.com", or to "
Adobe_Systems_Incorporated" (domain, or the company specified company name).
By having a single reference, it would be seem that the process would create
something that could have much more automation put around it.  Would the
scanning be perfect overnight - not by a long-shot.  However, as the
community works together to resolve these issues, it could be resolved
within a couple of years.

As for individual developers, I'm basing much of my processing time at the
moment on the current regid as described in the 19770-2 standard.  The
revision to 19770-2 (which starts in Aug), will accommodate individuals as
well by way of using a reference e-mail address instead of a domain.  That
can potentially accommodate the issue that if a dept does not have a unique
domain name, they can use a unique e-mail address (i.e. [hidden email] as an
example if individual publisher identification is required, or in the case
of software written by DISA, it could be IDd as publisher DISA.MIL).  The
e-mail support is more geared towards open source tools where there may not
be a domain that "claims" ownership over a developers work.

Cheers,

SK


-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 7:32 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant
Distributed Earlier on Monday, 4/23

I've attached a sample list of auto-generated CPE names from a few thousand
devices (Windows only).  Just looking at the names in use today, I would
tend to prefer using company names versus domains.  Many of the vendor names
make me think that expecting/requiring a registered dns name may not be
realistic as an industry-wide solution.

We certainly wouldn't expect all organizations within the DoD who write
software to go out and get a DNS name they can use for SWID tags.

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


-----Original Message-----
From: Steve Klos [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 9:27 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant
Distributed Earlier on Monday, 4/23

Joe,

I understand the thought behind your comment and I'm open to suggestions.
Do you have any thoughts on alternatives?  I'll provide some of the details
behind the thinking that was put into the use of the domain name below so
you can at least get a picture of how the domain became the suggested option
in this version of the document...

For the CPE vendor attribute, a few key issues from the perspective of
creating a SWID are:

  - Must ensure that the vendor details are unique
  - Must ensure that the process by which a vendor defines and uses the name
is easily replicated and understandable to the vendor.
  - Must to ensure the there is no manual process required post tag creation

We also want to meet some other requirements

  - Should provide a way to identify for older, non-tagged software
  - Should be short (not sure how much of a requirement this is)
 
There seem to be three potential options for this that are readily apparent
and possibly alternatives that others can  suggest:

Domain name  - Provides for short and unique - (e.g. Microsoft.com).  Since
a domain name is registered through the DNS system, there should not be
collisions in this namespace.  Note that software titles are purchased (at
which time the domain may or may not change hands), but for a given instance
of a given product, the domain will be consistently applied.

Domain name sans TLD - The domain name without the top level domain (TLD)
included - (e.g. Microsoft).  There can be collisions in this namespace
since one company could own a .com domain and another could own the .org.
For example, Flexera (owners of installshield and other tools), does not
appear to own the flexera.org, Flexera.ca or the Flexera.me TLDs.  Add to
this other countries TLDs (.co.uk, .com.aus, etc) and it would become
difficult to impossible to distinguish different vendors - especially if
they are working in different countries and use the same company name.

Full Company name - the name specified by the company (e.g. Microsoft
Corporation).  There are many ways company names are represented in software
- especially older software.  A few ways Microsoft could be represented -
"Microsoft", "Microsoft, Inc.", "Microsoft, Inc", "Microsoft Corp.", etc...
This seems to be the hardest option to match since it is unclear which of
the many versions should be used.  For automated Tag creation, asking a
vendor to specify their "commonly used reference name" seems problematic.

Of these options - it would seem that a domain is more likely something that
can be derived from a RPM package (or equiv 'nix install package) as well as
from the MSI and Add/Remove on Windows.  It's not perfect, but when you're
referencing legacy software, I'm not sure there is a perfect...  In the
Windows installer details, for example, I see URL's provided for a large
proportion of the software installed on my device.  

The other thing to consider - if software is currently still under a support
contract, the vendor can provide a patch to provide a SWID tag enabling
accurate identification.  Likewise, I expect to see 3rd party organizations
providing the ability to include a tag on a computing device as it does a
discovery process.  This tag would not be owned by the vendor and would be
only as accurate as the discovery tool used, but would provide significantly
better detail than is available now.

There will be open source applications for which it may not be clear who the
publisher is.  7-zip for example (a commonly used compression utility),
doesn't identify a company name, nor a help link.  The only reference I see
in the install DB for this is the copyright statement which would need to be
parsed.  Having said that, there is a domain for this application -
7zip.com.  

When it comes to open source where there isn't one owner or one vendor, it's
possible that the vendor may go back to the source repository - such as
"sourceforge.org" as the vendor...  

Love to hear your thoughts on this.

Cheers,

SK

-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 4:47 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant
Distributed Earlier on Monday, 4/23

I'm not comfortable that the use of domain names will solve more problems
than it creates.  Currently we can't use tags to derive installed software
inventories, so we're using the MS uninstall registry along with RPM and
equivalents for 'nix systems.

Using manually created names that are different for the TagVault tags from
what the developers put in the uninstall registry will make the process of
deconflicting/de-duplicating the data collected from the uninstall
registry/package manager from TagVault tags much more difficult.  I would
encourage you to make attempts to converge on a consistent set of names
across the board instead of creating different, competing names (i.e. your
"office" example below).

This problem will persist until everyone that writes software uses TagVault
tags, a time period I'm thinking will last for decades.

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


-----Original Message-----
From: Steve Klos [mailto:[hidden email]]
Sent: Tuesday, April 24, 2012 1:43 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Update to Microsoft Details Brant Distributed
Earlier on Monday, 4/23

Folks,

 

I wanted to give a very quick update to the e-mail from Brant.

 

The document on the TagVault.org website was updated this evening.  If you
downloaded V1.0, please update the document to the latest - V2.0.  The
updated document is on the same webpage you visited previously -
http://tagvault.org/Automating_CPE_name_creation.

 

Based on further communications with ISO development members and with
TagVault.org members, some additional elements are being added to the SWID
extended set.  These elements generally augment software identification
efforts for security, compliance and logistics in a generic sense, but also
remove some of the issues that were voiced regarding the resulting CPE names
that would be generated.  Since these new elements provide additional
capability to the SWID tag in a generic sense, the final versions of these
elements will be incorporated into the ISO/IEC 19770-2 revision which will
start in August.

 

Getting to the point, CPE names generated from certified SWID tags using
these newly defined elements will look as follows:

 

 
cpe:2.3:a:tagvault.org:Tag_Creation_and_Signing_Utility:1.0.0.0:-:-:-:-:-:-:
certified_tag
     cpe:2.3:a:symantec.com:
Enterprise_Vault:10.0.1.0:-:-:-:-:-:-:certified_tag
     cpe:2.3:a:microsoft.com: Office
_2007:12.0.6607.1000:service_pack_3:-:-: Professional:-:-:certified_tag

 

A few notes -

 

1)      Because we need to ensure unique id's for the companies, the domain
name is being used - this is the same as with Version 1.0 of the integration
document.

2)      We have added a product_name to the SWID tag.  The product name is
different from the data in the add-remove program list, so instead of
"Microsoft Office Professional 2010" that we saw in V1, we now will see,
"Office.".

3)      There is one issue when it comes to versions (and the product
attribute) - software applications have two versions as far as CPE is
concerned.  There is the marketing version (in Office that would be 2003,
2007, 2010, etc) and the product version 11.xxx, 12.xxx, 14.xxx (note, there
is no version 13 of the product version in distribution).  CPE only has one
area for version data and because CPE names and the SCAP infrastructure
should typically more about code base changes than the licensing version,
we've incorporated the licensing version number in the title as the second
component.  This will mean that a wild card will need to be used for
applicability statements, but only in those cases where a whole set of
different licensing versions are included.

4)      The rest should be relatively obvious with two remaining details

a.      the update attribute (in SWID vernacular, the product_update), will
be defined by the publisher as they want to see it, so it may be SP2 or
Service_Pack_2.  The key is that it will be consistently applied by way of
validating the data against a registration DB.

b.      the target_hw attribute (in SWID vernacular, the target_platform)
will validate against a registration set of data, but thus far, I've not
found a good source of initial values to include.  X32 and X64 seem to be
used relatively consistently, but if anyone has a good source of platform
values (especially one that includes definitions) and that list can be
included in the TagVault.org document, please let me know.

I'm very interested in comments/thoughts/suggestions.

 

Enjoy!

 

Cheers,

 

SK

 

From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, April 23, 2012 5:52 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] Microsoft announces support for ISO/IEC
19770-2:2009 Software Identification Tags

 

CPE Community,

 

Last week Microsoft announced:  Microsoft is collaborating with national
standards bodies and industry leading groups to further the development of
the ISO/IEC 19770-2:2009 standard for software identification tags. We are
folding ISO/IEC 19770-2:2009 support into our product planning cycles, and
will begin to include these tags in future product releases.

http://www.microsoft.com/sam/en/us/softwareid.aspx

 

This is a significant step forward for efforts to standardize software
product naming and discovery.  To the extent that software identification
(SWID) tags become pervasive, it will greatly ease the challenges associated
with inventorying the software products installed on computing endpoints and
correlating inventory information with vulnerability reports, security
guidance, etc.

 

As I announced earlier this year, MITRE and TagVault.org have been working
together on a proposal to integrate CPE names into SWID tags, with the goal
of enabling publishers to create valid CPE names at the same time they
create SWID tags for their products.  The first version of this proposal is
posted on the TagVault website:

http://tagvault.org/Automating_CPE_name_creation

 

During the July 2012 SCAP Developer Days Conference at MITRE Bedford, we
anticipate two related sessions, one providing a general overview of SWID
tags, and a second focusing specifically on the proposal for embedding CPE
names in SWID tags.  This will be a great opportunity to learn more about
software identification tags and interoperability with CPE.

 

Cheers,

/Brant

 

The MITRE Corporation

202 Burlington Road, M/S K302

Bedford, MA  01730-1420

Tel. 781-271-7505, Cell. 617-694-8180