Re: [mile] CPE and SWID

[John Richardson <[e-mail]>]

Hi Everyone,

I added myself to the this list so that I can comment on SWID tags on this thread from a Symantec perspective. Hopefully my response will be added inline to others on this thread.

Symantec has SWID tags conformant to the ISO 19770-2:2009 standard released in four products - NetBackup 7.0 and later, Endpoint Protection 12.1 and later, Control Compliance Suite 11.0, and Enterprise Vault 9.03 and 10.0 and later.

Symantec has been active in the support and development of the ISO 19770 standards for many years with the initial interest in improving the ability Symantec customers and partners better manage their Symantec assets using COTS SAM tools.

Symantec is a founding member of TagVault.org as we see it necessary to have a consistent implementation of tags across publishers along with normalized data to decrease issues related to the current model where SAM tools use their own proprietary techniques to discover and identify installed software on a device, and to report software asset information.

Symantec, along with TagVault.org members, are working together to agree on common guidelines for how to implement tags against baseline use cases to ensure that if publishers implement tags to these guidelines, COTS tools can use standard algorithms to consistently discover and to identify installed software, as well as consistently report software asset information.

In the past year or so, the Federal Government interest in SWID tags has increased from a security perspective as Dave Waltermire from NIST outlines below. We are actively working with several government agencies, through TagVault.org and along with other TagVault.org members, to ensure that implementation guidelines for SWID tags developed within TagVault.org align with the Federal Government use cases and requirements.

For more information on these activities, please see www.tagvault.org<http://www.tagvault.org>.

Best Regards,

John

________________________________

 *   From: "Waltermire, David A." <david.waltermire at nist.gov<mailto:[e-mail]>>
 *   To: "Moriarty, Kathleen" <kathleen.moriarty at emc.com<mailto:[e-mail]>>, "Roman D. Danyliw" <rdd at cert.org<mailto:[e-mail]>>, "mile at ietf.org<mailto:[e-mail]>" <mile at ietf.org<mailto:[e-mail]>>
 *   Date: Wed, 5 Feb 2014 21:43:46 +0000
 *   List-id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>

________________________________

Changing the subject to reflect the discussion thread.



I just saw this message. Here is what I can vouch for as the NIST lead for these efforts:



NIST is continuing to support CPE as it has for the last few years. SCAP and a few other efforts are dependent on it, so this is critical. It has not been defunded.



NIST is working with the SWID community to advance the ISO specification efforts and to ensure that the necessary implementation guidance for SWID tag producers and tool consumers is put in place.



We see SWID tags as having synergies with the CPE effort. We are looking at methods to consume SWID tags, as software publishers create them, for use in auto generating CPEs. This has significant advantages over the current CPE methodology that largely involves investigating vulnerability reports and vendor product pages and documentation to generate CPE names. By generating CPE names in this way we can increase the fidelity and accuracy of the product data, using less human effort, making product identification information available as close to the publication of the software as possible.



Our long-term plans are to maintain a mapping between SWID and CPE in the National Vulnerability Database. This information does not exist yet, but is in the planning stages. Such information will provide a transition path for the SCAP community and other that use CPE today to take greater advantages of the information that SWID offer including: a more robust product metadata model and footprint information including file names, versions, and hashes.



Please let me know if you have any questions.



Thanks,

Dave







> -----Original Message-----

> From: mile [mailto:mile-bounces at ietf.org] On Behalf Of Moriarty, Kathleen

> Sent: Monday, January 27, 2014 5:40 PM

> To: Roman D. Danyliw; mile at ietf.org

> Subject: Re: [mile] @user-agent attribute

>

> CPE isn't funded anymore and may get folded in SWID.  I don't have the

> latest on this, but would not want to rely on something that may go away.  Is

> anyone aware of the latest on CPE?

>

> Thanks,

> Kathleen

>

> -----Original Message-----

> From: mile [mailto:mile-bounces at ietf.org] On Behalf Of Roman D. Danyliw

> Sent: Monday, January 27, 2014 3:22 PM

> To: mile at ietf.org

> Subject: [mile] @user-agent attribute

>

> Hello!

>

> The -04 schema of 5070bis has the following comment in the definition of

> @user-agent in the Application and OperatingSystem classes.

>

> [begin comment]

> "<!-- CHANGE: Should UserAgent or HTTPUserAgent fit in SoftwareTypes?

> This is typically intended to mean servers, but the category seems more

> appropriate than others.-->"

> [end comment]

>

> SoftwareType is the complexType used to define System/Application and

> Service/OperatingSystem.  Lacking documentation in the text and going only

> on the name in the schema, it would appear that this attribute is attempting

> to describe the "User-Agent" HTTP field per Section 14.43 of RFC2616.  If

> there is a broader definition, could someone please talk us through it.

>

> With the addition of the Service/ApplicationHeader there appear to be two

> ways to represent a User-Agent.  Consider the following XML snippet below:

>

> <System>...

> <Service ip_protocol="80">

> ... <ApplicationHeader proto="80" field="User-Agent"

> dtype="string">Mozilla/5.0 (Windows NT 6.2; Win64; x64)

> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0

> Safari/537.36</ApplicationApplication>

>

> ... <Application swid="xxx" configid="xxx" vendor="Google"

> name="Chrome" user-agent="Mozilla/5.0 (Windows NT 6.2; Win64; x64)

> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"

> version="32.0.11667"> <URL>something</URL> </Application> </Service>

> </System>

>

> A few questions:

> ** Does the data model need the @user-agent attribute if

> ApplicationHeader can model it?

> ** Could @swid (defined as "An identifier that can be used to reference this

> software") be used for a User-Agent?

> ** What implementation guidance should be given about how @user-agent

> should be set with Service/OperatingSystem?

>

> To share my own bias, the Application and OperatingSystem Class are

> currently very poorly specified.  I don't think we should continue improving

> them.  Instead, we should reference software through CPE

> (http://nvd.nist.gov/cpe.cfm) or similar effort as is possible through the SCI-

> defined class Platform.  For the time being, I would drop @user-agent.

>

> Roman

> _______________________________________________

> mile mailing list

> mile at ietf.org

> https://www.ietf.org/mailman/listinfo/mile

>

> _______________________________________________

> mile mailing list

> mile at ietf.org

> https://www.ietf.org/mailman/listinfo/mile

________________________________

 *   Follow-Ups:
    *   Re: [mile] CPE and SWID<http://www.ietf.org/mail-archive/web/mile/current/msg01348.html>
       *   From: Blibbet

 *   Prev by Date: Re: [mile] Documenting DomainData<http://www.ietf.org/mail-archive/web/mile/current/msg01346.html>
 *   Next by Date: Re: [mile] CPE and SWID<http://www.ietf.org/mail-archive/web/mile/current/msg01348.html>
 *   Previous by thread: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-05.txt<http://www.ietf.org/mail-archive/web/mile/current/msg01344.html>
 *   Next by thread: Re: [mile] CPE and SWID<http://www.ietf.org/mail-archive/web/mile/current/msg01348.html>
 *   Index(es):
    *   Date<http://www.ietf.org/mail-archive/web/mile/current/maillist.html#01347>
    *   Thread<http://www.ietf.org/mail-archive/web/mile/current/threads.html#01347>

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.