Subject: [sacm] SWID and CPE discussion

From: [email-masked]
Date: Sat, 09 Mar 2013 16:37:39 -0600 (CST)

Gunnar and all:

I like Gunnar's point.

Here's another observation.

CPE has been very successful because the SCAP community has submitted probably most of the entries, and MITRE has worked with the vendors.

In other words CPE enjoys the positive motivation of the SCAP community.

Socializing SWID to software vendors probably presents a greater challenge if the vendor has to pay a fee.

If vendors were to pay a fee for a CPE, or if CPE depended on the vendors submitting entries for their products, then CPE wouldn't be as successful.

Gunnar's statement about OVAL now checking for duplicates is great.

David Oliva

On 03/08/13, Gunnar Engelbach<[email-masked]> wrote:

It's also worth looking at whole role SWID/CPE is intended to fulfill
within the scope of SACM.

The two roles look to be inventorying and content applicability.

In both cases the are at least two approaches: a dictionary-backed
system or a deterministic rule-based system. Both devolve to a
communicable token that is intended as an unambiguous identifier.

The problems with a dictionary backed system has already been well
stated on these threads.

The rule-based approach is also problematic, as evidenced by the number
of duplicate entries in the existing CPE dictionary, but does have the
strength of being boot-strappable. That is to say, the rules are run to
produce the token, and the token is then available for use. SCAP
benchmarks use this mechanism to automatically determine applicability.

The reason the CPE dictionary has so many duplicates is that the entries
were created, for the most part, prior to OVAL checks written for each.
Had the the CPE dictionary entries been created as the result of OVAL
checks, or some other executable mechanism, there would have been little
to no duplication, but with the side affect of having a dependency on
that mechanism.

What I don't recall seeing mentioned in regard to a dictionary-backed
system is what to do when a software product is not bundled with a
trustworthy SWID or CPE (or whatever) identifier. In that case it would
still be necessary to fall back to a rule-based system to determine that
identifier.

Since both approaches devolve to a need for a rule-based system, then it
seems reasonable to start with that. Unfortunately, that still means a
dictionary of rule definitions, but that's what the content repositories
are for, eh? In any case, I don't see a scenario where this is *not*
necessary to do.

--gun

On 3/8/2013 2:41 PM, Moriarty, Kathleen wrote:
> Hi,
>
> SWID does have adoption as Dave pointed out and could scale better as it relies on vendors being responsible. As I understand it, you don't need to purchase the standard document to use it and TagVault may not be the only option. Someone mentioned that there may be a way for opensource efforts to get a SWID for free as well (not confirmed).
>
> Thanks,
> Kathleen
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Rutkowski
> Sent: Friday, March 08, 2013 2:09 PM
> To: Waltermire, David A.
> Cc: [email-masked]
> Subject: Re: [sacm] SWID and CPE discussion
>
> Hi Dave,
>
> The most significant question here is whether you
> are creating an open tagging scheme or not. In
> other words, is the ISO scheme only one of many
> tagging methods? If not, it's not conceivable that
> you would get acceptance.
>
> Furthermore, if you cannot provide the standard
> to show everyone that you want them to accept
> without paying $400 or more, you're unlikely to
> get traction down that path.
>
> Lastly, in weighing an open and free 3GPP
> Rel. 11 standard that gets baked into the global
> mobile infrastructure - against a virtually unused
> and unknown spec out of ISO, the result seems
> obvious.
>
> --tony
>
>
> On 3/8/2013 10:31 AM, Waltermire, David A. wrote:
>> I would say that ISO is a major standards body. I have been working with the TCG and other fora that are working on capabilities based on SWID. I know of a few major vendors that are already deploying SWIDs within their products (e.g. Microsoft, Adobe) and others that are working on it now.
>>
>>>>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Sat, 09 Mar 2013 19:36:55 -0500

The other side of that is that some vendors are already shipping 
products that use SWID.  So, in some cases, SWID identifiers are already 
sitting there free for the using.

On 3/9/2013 5:37 PM, [email-masked] wrote:
> CPE has been very successful because the SCAP community has submitted
> probably most of the entries, and MITRE has worked with the vendors.
> Socializing SWID to software vendors probably presents a greater
> challenge if the vendor has to pay a fee.
> If vendors were to pay a fee for a CPE, or if CPE depended on the
> vendors submitting entries for their products, then CPE wouldn't be as
> successful.
>  > SWID does have adoption as Dave pointed out and could scale better as
> it relies on vendors being responsible. As I understand it, you don't
> need to purchase the standard document to use it and TagVault may not be
> the only option. Someone mentioned that there may be a way for
> opensource efforts to get a SWID for free as well (not confirmed).
>  >
>  > Thanks,
>  > Kathleen
>  >
>  > From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] On Behalf Of Tony Rutkowski
>  > Cc: [email-masked] <mailto:[email-masked]>
>  >> I would say that ISO is a major standards body. I have been working
> with the TCG and other fora that are working on capabilities based on
> SWID. I know of a few major vendors that are already deploying SWIDs
> within their products (e.g. Microsoft, Adobe) and others that are
> working on it now.
>  >>
>  >>>>
>  >
>  >
>  > [email-masked] <mailto:[email-masked]>
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 10 Mar 2013 07:13:28 -0400

As this dialogue moves forward, the
three attached documents should be
useful.  Globally unique software
object tagging standards have been
pursued since Jim White introduce the
notion of OIDs in the early 1980s in JTC1.
Over the past several years, the subject
has risen to increased prominence by
many different communities.

The attached presentation provides
an introduction to them as well as
a deep dive on one that has high
degree of maturity and feasibility
- DIDA.  The adopted DIDA spec
is also attached as well as a correction
adopted a few weeks ago.

The presentation is useful because it
shows how a compelling number of
vendors approached the problem and
ended up with an open globally feasible
solution over roughly the past 18 months.

--tony

---

From: Gary Gapinski <[email-masked]>
Date: Sun, 10 Mar 2013 11:10:37 -0400

On 03/10/2013 07:13 AM, Tony Rutkowski wrote:
> As this dialogue moves forward, the three attached documents should
> be useful.

In addition to some comments and questions, I'm going to paraphrase this
scheme: please correct me where I'm wrong. I'm only at three cups of coffee.

An operating system ID (OSId) is a UUID.

This works well for uniqueness. I do not understand how successive
versions of a particular OS would be identified when one particular
version thereof was of interest.

I am unsure how a specific OSId would be associated with the colloquial
name of the OS thus identified.

An OS specific Application Identifier (OSAppId) (there are none which
are not OS-specific?) uniquely identifies an application found on some
OS. The identifiers noted on slide 5 of your presentation work well, but
again lack version information.

Linux distributions using RPM and Debian style packaging are similar
with arbitrary names for packages, though version is maintained in the
installation database and source repositories.

By the way, I'm using the word "version", but that is just shorthand for
the ability to qualify a thing relative to the passage of time.

Where/how would an OS or application version be obtained or specified?
It will certainly be widely useful, though absent in the DIDA
specification, perhaps because the interest lies in flow control. Would
the version of iOS prior to 6.1.2 have been of interest to the
flowmeisters? Ditto poorly written early versions of social networking apps?

It seems to me that these choices of both OS and application identifiers
are useful but not sufficient.

I particularly like the idea of OS-specific names for
applications/components, as this is common practice. This allows
arbitrary naming schemes in and suitable for various venues without the
necessity of marshaling them through an unnecessary choke point (other
than the accepted OS package distribution scheme).

I am unsure if this precludes an OSAppId identifying a particular
application in multiple OSes (in other words, can the OSAppId be used in
isolation). An example of this would be node.js.

I expect that colloquial OS names will be generally preferred to UUIDs.

I think the concept of OS must at best be stretched in order to
encompass many consumer appliances. For those, it will be necessary to
identify vendor and model, in which case perhaps one should simply cite
vendor and model. Many things that are sold have UPC numbers, which are
also useful identifiers. Unfortunately, UPC does not strictly entail OS.

I wonder whether this minimalist approach to "OS" by 3GPP resulted from
the unmentioned presence of IMEI/SV on such user equipment. I do not
think OSId will be sufficient to identify particular instances of an
operating system. While an OSAppId can happily be the same as the
identifier commonly used in the OS package distribution scheme, an OS
UUID will not be as friendly.

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 10 Mar 2013 11:28:17 -0400

Good summary.

As to user friendliness of UUIDs, it's not apparent
that human readability was a requisite.

Almost every GSMA SG meeting (every 90 days)
there is a new briefing on app stores of different
flavors.  Whatever is adopted in the SACM work
must clearly be adaptable and scalable in a very
rapidly evolving, autonomous, and open environment.

--tony

ps. I'm still waiting for a peek at that "secret"
ISO 19770 spec.  At $200 a pop, it seems to
be well protected. :-)

---

From: "Struse, Richard" <[email-masked]>
Date: Sun, 10 Mar 2013 01:15:21 +0000

I think a number of good points have already been made by Kathleen, Dave, David, Gunnar, etc. but I wanted to add my $0.02.  Sorry for the length but there is a lot to cover.

First, if there are other viable solutions in the area of software identification, we definitely should be considering those.  Having said that, I think that the SWID approach has a number of benefits that we shouldn't ignore. Second, let's all make sure we understand the problem that SWID's are attempting to solve.

As I understand it, SWID's (ISO 19770-2:2009) were designed to allow producers of software (and third parties where desired) to create standard tags that identify software products.  As we all know, there are many complexities in identifying software including product names, versions, editions, suites, bundles, patches, etc.  From my experience, SWID's were explicitly designed by people who understand how software is packaged and distributed to handle these complexities.  Note that SWID's identify a specific piece of software - not an installed instance of a piece of software.  What I mean by that, in general, is that if two different people install the same version/edition/etc. of MS Word 2010 on each of their systems, the same exact SWID tag file will be deposited on each of those systems. 

SWID's do not require a central registry or repository for the tags themselves.  While there is a once-per-publisher registration step in the current TagVault.org process, that is simply to normalize core information about the publisher.  Nothing says that has to be done by TagVault or by anyone at all if the community wants an even more decentralized approach.  Regardless, once I create/obtain what is known as my "regid", as a publisher I never have to touch a centralized repository again if I don't want to.  I simply create tag files for each of the products I want to tag and ship them with my product.

>From a security automation perspective there appear to be multiple, significant benefits to this approach.  First, I can digitally sign the SWID's I produce and this allows "consumers" of tags to verify their authenticity.  Second, using what is known as "secure asset management-level" tags (essentially an additional set of elements in the SWID XML), the publisher can include a "package footprint" that contains file names and hashes for each of the components in the package that are expected to remain inviolate.  This enables the customer to then verify the integrity of a package installed in their infrastructure via the following process: 1) verify the integrity of the entire SWID file and its digital signature, 2) compute the current hash for each of the files in the footprint elements and compare them to the hashes stored in the footprint.  Note that none of this required the consultation of any centralized repository of tags - it only required the ability to verify the digital signatures.  Third, in those cases where the publisher cannot (or will not) produce tags themselves (e.g. perhaps the publisher is out of business), third parties can produce and sign SWID tags for other software packages.  Thus, a third-party could produce a tag for an Oracle product and sign it as themselves but they will not be able to successfully claim that they are the publisher (i.e. they can't create a tag file and sign it as Oracle).  This is also important for custom-developed and/or legacy software.

As far as adoption goes, SWID tags can be utilized by the open source community today, they can also be created as part of a software management process by organizations buying and managing software and they are starting to see significant publisher support from companies like Symantec, Microsoft, EMC and IBM.   Microsoft has already started to ship basic tags in all new software titles and have indicated they will provide tags as part of a patching process for older products.  This range of support allows for authoritative information coming directly from the publisher and is a good indication that the tags are viable and at a minimum, worthy of consideration.

With respect to CPE, this page - http://tagvault.org/Automating_CPE_name_creation - and the accompanying document do a pretty good job of describing the relationship between CPE and SWID's.  Over time, this would allow us to refocus CPE away from a centralized registry to more of an "applicability language" that supports the expression of patterns that describe useful groupings of software (e.g. what software is affected by a specific vulnerability).

Tony raises a good point about the cost of ISO standards as a potential barrier - a point I have made myself.  However, as is the case with many standards, many, if not most people leverage standards without ever reading the formal specification.  Between the no-cost materials published by TagVault.org and the use of tools (both commercial and open source) to generate and verify tags, I don't see this as a real barrier.  There is more work to be done in this area and I'd love to see an open-source implementation of a SWID producer/consumer tool but I think that is just a matter of time.

Again, sorry for the long email but this is an important topic and one we need to get right.

Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Saturday, March 09, 2013 7:37 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sacm] SWID and CPE discussion

The other side of that is that some vendors are already shipping products that use SWID.  So, in some cases, SWID identifiers are already sitting there free for the using.

On 3/9/2013 5:37 PM, [email-masked] wrote:
> The rule-based approach is also problematic, as evidenced by the 
> number of duplicate entries in the existing CPE dictionary, but does 
> have the strength of being boot-strappable. That is to say, the rules 
> are run to produce the token, and the token is then available for use. 
> SCAP benchmarks use this mechanism to automatically determine applicability.
>
> The reason the CPE dictionary has so many duplicates is that the 
> entries were created, for the most part, prior to OVAL checks written for each.
> checks, or some other executable mechanism, there would have been 
> little to no duplication, but with the side affect of having a 
> dependency on that mechanism.
>
> trustworthy SWID or CPE (or whatever) identifier. In that case it 
> would still be necessary to fall back to a rule-based system to 
> determine that identifier.
>
> Since both approaches devolve to a need for a rule-based system, then 
> it seems reasonable to start with that. Unfortunately, that still 
> means a dictionary of rule definitions, but that's what the content 
> repositories are for, eh? In any case, I don't see a scenario where 
> this is *not* necessary to do.
>
>
> --gun
>
>
>
>
>
>  > SWID does have adoption as Dave pointed out and could scale better 
> as it relies on vendors being responsible. As I understand it, you 
> don't need to purchase the standard document to use it and TagVault 
> may not be the only option. Someone mentioned that there may be a way 
> for opensource efforts to get a SWID for free as well (not confirmed).
>  >
>  > Thanks,
>  > Kathleen
>  >
> [mailto:[email-masked]] On Behalf Of Tony Rutkowski  > Sent: 
> Friday, March 08, 2013 2:09 PM  > To: Waltermire, David A.
>  > Cc: [email-masked] <mailto:[email-masked]>  > Subject: Re: [sacm] 
> SWID and CPE discussion  >  > Hi Dave,  >  > The most significant 
> question here is whether you  > are creating an open tagging scheme or 
> not. In  > other words, is the ISO scheme only one of many  > tagging 
> methods? If not, it's not conceivable that  > you would get 
> acceptance.
>  >
>  > Furthermore, if you cannot provide the standard  > to show everyone 
> that you want them to accept  > without paying $400 or more, you're 
> unlikely to  > get traction down that path.
>  >
>  > Lastly, in weighing an open and free 3GPP  > Rel. 11 standard that 
> gets baked into the global  > mobile infrastructure - against a 
> virtually unused  > and unknown spec out of ISO, the result seems  > 
> obvious.
>  >
>  > --tony
>  >
>  >
>  >> I would say that ISO is a major standards body. I have been 
> working with the TCG and other fora that are working on capabilities 
> based on SWID. I know of a few major vendors that are already 
> deploying SWIDs within their products (e.g. Microsoft, Adobe) and 
> others that are working on it now.
>  >>
>  >>>>
>  >
>  >
>  > [email-masked] <mailto:[email-masked]>  > 
>  > [email-masked] <mailto:[email-masked]>  >