Subject: [sacm] SWID M&A topic: reporting source of tags

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 20 May 2016 17:40:08 +0000

Hi all,

At the virtual interim there was some discussion as to whether there was any
utility in tracking tag sources. The source reflects the mechanism by which
a tag was "discovered" and added to an endpoint's SWID tag collection.
Scraping .swid files from the filesystem would be one source. Having a
collection of SWID tags dynamically generated by an endpoint's package
manager would be another source. Having the output of a software inventory
tool expressed as SWID tags would be another source. Etc. 

Connecting to the thread on tracking the location of application
installation (RE: Proto-consensus: Application location), in that discussion
Dave suggested that if the SWID-PC was unable to determine the installation
location of a particular application, then maybe the SWID-PC could report
the location of the SWID tag itself instead. It occurs to me that capturing
the tag location could pretty easily subsume indication of the tag source as
defined above. (I think this was what Dave was getting at in his second
response to this thread.) By extending the concept of "location" a bit so
that it can accommodate dynamically generated, ephemeral tags (which we
would need to do if we wanted to be sure that tag location was always
available for reporting), one would pretty much be required to encapsulate
the source of the tag in that information. I could see something like a URI
working for this. Under this scenario we would have two distinct fields:
Software Installation Location and Tag Location. The former could be
zero-length if the SWID-PC was unable to reliably identify the location of
the software, but the latter would always be present.

Of course, just because we see how to do something doesn't mean we should. I
would still like to hear some thoughts on what use cases people feel that
tag source tracking is needed for. It was noted on the call that different
sources can have different collection characteristics (e.g., some sources
might report real-time detection of changes, while other sources might have
to employ periodic diffing to detect changes). I'm interested in hearing
about any real-world situations where a policy server (or other consumer)'s
behavior would be different because it was able to know that a particular
SWID tag delivered from an endpoint came from one source rather than
another. (E.g., "Ah-ha! This SWID tag for Acme App v1.2.3 came from our
inventory tool rather than being discovered somewhere on the filesystem.
Therefore I will change my default action and do something else instead.")

Charles

---

From: Jerome Athias <[email-masked]>
Date: Fri, 20 May 2016 20:58:54 +0300

Well, one could use Confidence scoring as part of Asset Management,
and so have Confidence scores level on Tools and CollectionMethods

2016-05-20 20:40 GMT+03:00 Schmidt, Charles M. <[email-masked]>:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Thu, 26 May 2016 17:06:11 +0000

Hi Jerome,

I started this email a bit skeptical about this claim, but I think I have come 
around. (One of the advantages of being verbose, I guess.) My reasoning 
follows:

Part of the fundamental nature of software identification tags (of any type) 
is that they are secondary sources of evidence. Some source has made tags 
available as evidence of software presence based on their own understanding of 
present software and we (the parties interested in endpoint inventory) are 
just collecting those tags. This stands in contrast to using a bunch of 
low-level checks to examine an endpoint for direct evidence of software 
presence. (The latter would be more akin to an OVAL definition.)

Given that we are relying on some black-box, third party to create and manage 
the tags we collect, I can see how one might wish to discriminate between 
those parties. One might have a different level of confidence in tags directly 
generated from the endpoint's RPM database vs. from a software inventory tool 
downloaded from BobsSoftwareInventoryAndMotorcycleRepair.com.

Good point. Thanks.

Charles

> -----Original Message-----
> From: Jerome Athias [mailto:[email-masked]]
> Sent: Friday, May 20, 2016 12:59 PM
> To: Schmidt, Charles M. <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sacm] SWID M&A topic: reporting source of tags
>

---

From: Jerome Athias <[email-masked]>
Date: Thu, 26 May 2016 21:47:09 +0300

Yes that's it.
Now, I don't know if we want this ('complexity') (now)

---

From: Adam Montville <[email-masked]>
Date: Fri, 27 May 2016 06:36:05 -0400

Is this relevant within the context of a single enterprise?  One organization, Company X, who is deploying a SACM ecosystem?

> On May 26, 2016, at 2:47 PM, Jerome Athias <[email-masked]> wrote:
> 
> Yes that's it.

---

From: Ira McDonald <[email-masked]>
Date: Fri, 27 May 2016 07:39:33 -0400

Hi,

Even within a single enterprise, the value of SWID Tags (or any other
standards software version labelling system) is that they're (ideally)
assigned by the software creator (big vendor or open source project),
NOT simply by the enterprise themselves, so the "reputations" (or
whatever metrics) of the SWID Tag sources still seems important.

Perhaps I haven't had enough coffee this morning...

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, May 27, 2016 at 6:36 AM, Adam Montville <[email-masked]>
wrote:

> Is this relevant within the context of a single enterprise?  One
> organization, Company X, who is deploying a SACM ecosystem?
>
>
> >>>> At the virtual interim there was some discussion as to whether there
> was
> >>> any
> >>>> the tag location could pretty easily subsume indication of the tag
> source
> >>>> as
> >>>> the source of the tag in that information. I could see something like
> a
> >>>> URI

---

From: Adam Montville <[email-masked]>
Date: Fri, 27 May 2016 08:54:04 -0400

I think I might be the one who needs coffee.  The way I read the chain seemed to imply an inter-organizational context to the “third-party creation” of such tags.  Within the context of a single enterprise, it seems that the problems that would be introduced by inter-organizational contexts would be reduced or at least deferred for later consideration.

> On May 27, 2016, at 7:39 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> On Fri, May 27, 2016 at 6:36 AM, Adam Montville <[email-masked] <mailto:[email-masked]>> wrote:
> > On May 26, 2016, at 2:47 PM, Jerome Athias <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Yes that's it.
> > 2016-05-26 20:06 GMT+03:00 Schmidt, Charles M. <[email-masked] <mailto:[email-masked]>>:
> >> Hi Jerome,
> >>
> >>> From: Jerome Athias [mailto:[email-masked] <mailto:[email-masked]>]
> >>> To: Schmidt, Charles M. <[email-masked] <mailto:[email-masked]>>
> >>> Cc: [email-masked] <mailto:[email-masked]>
> >>> 2016-05-20 20:40 GMT+03:00 Schmidt, Charles M. <[email-masked] <mailto:[email-masked]>>:
> >>>> Hi all,
> >>>>
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> >>>>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
>

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 27 May 2016 11:47:17 -0400

Two related reputation related platforms
may be useful here.  One is EVcerts and
the CA/B Forum's recent creation of its
Code Signing Working Group.  Another
that's emerging is blockchain and interledger
platforms being developed in W3C that
uses far broader than payments.

The former relies on the vetting process
and inclusion of embedded policy information.
The latter relies on trust reputation.  The
EU's action yesterday on the latter may
boost it's ubiquity.

--tony

ps. apologies for sometimes appearing to post
negative comments.  Call them spontaneous -
offered as ideas and reactions; and I do it
in all the many bodies that I inhabit.

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 27 May 2016 17:56:36 +0000

Hi Adam,

To clarify, I am speaking of a scenario in a single enterprise. On each endpoint in a single enterprise, that endpoint could have multiple sources for tags. For example, tags could be collected by scanning the endpoint's file system for .swid files (one source), tags could be generated by the endpoint's package manager (another source), or tags could be created from the output of an inventory scanning tool installed on that endpoint (a third source). All of these sources provide a set of tags that reflect an understanding of what software is on that one endpoint. These tags from all sources are collected by our Posture Collector and delivered to that enterprise's Posture Validator. The question Jerome was asking was whether that Posture Validator (or some component that used data provided by the Posture Validator) would have a different degree of confidence in the accuracy or thoroughness of these sources. If the answer is yes, then that would argue for annotating the information sent by the Posture Collector with some identifier associated with the information's source. (Currently, the SWID M&A spec just dumps tags from all sources into a single collection and reports that information without source annotation.)

So we are talking about a single enterprise here, but the sources of the tags the Posture Collector collects and delivers will, in most cases, be written by vendors outside that enterprise.

Does that clarify the situation, or have I missed your concerns?

Charles

> From: Adam Montville [mailto:[email-masked]]
> Sent: Friday, May 27, 2016 7:54 AM
> To: Ira McDonald <[email-masked]>
> Cc: Jerome Athias <[email-masked]>; [email-masked]; Schmidt,
> Charles M. <[email-masked]>
> I think I might be the one who needs coffee.  The way I read the chain
> seemed to imply an inter-organizational context to the “third-party creation”
> of such tags.  Within the context of a single enterprise, it seems that the
> problems that would be introduced by inter-organizational contexts would
> be reduced or at least deferred for later consideration.
> 
> 
> 	On May 27, 2016, at 7:39 AM, Ira McDonald
> <[email-masked] <mailto:[email-masked]> > wrote:
> 
> 	Hi,
> 
> 
> <mailto:[email-masked]>
> 	On Fri, May 27, 2016 at 6:36 AM, Adam Montville
> <[email-masked] <mailto:[email-masked]> >
> wrote:
> 
> 
> 		> On May 26, 2016, at 2:47 PM, Jerome Athias
> <[email-masked] <mailto:[email-masked]> > wrote:
> 		>
> 		> Yes that's it.
> 		> 2016-05-26 20:06 GMT+03:00 Schmidt, Charles M.
> <[email-masked] <mailto:[email-masked]> >:
> 		>> Hi Jerome,
> 		>>
> 		>> downloaded from
> BobsSoftwareInventoryAndMotorcycleRepair.com
> <http://bobssoftwareinventoryandmotorcyclerepair.com> .
> 		>>
> 		>> Good point. Thanks.
> 		>>
> 		>> Charles
> 		>>
> 		>>> From: Jerome Athias [mailto:[email-masked]
> <mailto:[email-masked]> ]
> 		>>> To: Schmidt, Charles M. <[email-masked]
> <mailto:[email-masked]> >
> 		>>> 2016-05-20 20:40 GMT+03:00 Schmidt, Charles M.
> <[email-masked] <mailto:[email-masked]> >:
> 		>>>> Hi all,
> 		>>>>
> 		>>>> At the virtual interim there was some discussion as to
> whether there was
> 		>>> any
> 		>>>> utility in tracking tag sources. The source reflects the
> mechanism by
> 		>>>> which
> 		>>>> manager would be another source. Having the output
> of a software
> 		>>> inventory
> 		>>>> installation (RE: Proto-consensus: Application location),
> in that
> 		>>>> discussion
> 		>>>> Dave suggested that if the SWID-PC was unable to
> determine the
> 		>>> installation
> 		>>>> the location of the SWID tag itself instead. It occurs to
> me that
> 		>>>> capturing
> 		>>>> the tag location could pretty easily subsume indication
> of the tag source
> 		>>>> as
> 		>>>> the source of the tag in that information. I could see
> something like a
> 		>>>> URI
> 		>>>> Of course, just because we see how to do something
> doesn't mean we
> 		>>> should. I
> 		>>>> might report real-time detection of changes, while
> other sources might
> 		>>> have
> 		>>>> about any real-world situations where a policy server
> (or other
> 		>>>> consumer)'s

---

From: Adam Montville <[email-masked]>
Date: Tue, 31 May 2016 12:07:03 -0500

Hi Charles,

I think this is clearer.  I’m still wondering, however, how big an issue this is for 80% of the enterprises out there (or possibly even more).  If I buy an asset management solution and it generates tags, then do I not implicitly have confidence in that source?

On the other hand, for the 20% that are going to use the sources they have available and don’t trust those sources for any given reason, we might want some annotation mechanism.

I’m trying to determine if this is something we really need to be concerned with.

Adam

> On May 27, 2016, at 12:56 PM, Schmidt, Charles M. <[email-masked]> wrote:
> 
> Hi Adam,
>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 31 May 2016 18:20:25 +0000

There is also the consideration that the presence of tags will largely be driven by the OS provider in most cases (e.g., packages, app stores, OS-based installers, etc.). OS vendors will likely want to select a given type of tag for broad use. This means that the majority of tags on the system will either be provided by the OS vendor or by a single third-party discovery tool which will likely exhibit similar selection criteria.

Assuming all of this, the result should be a fairly regular set of tag types, with few outliers. For outliers, if the collection system can read the tags, an identifier will be made available to the evaluator at minimum. If not, we are back to the current state of non-interoperability which will require some exception handling. One way of looking at exception handling is to use the discovery tool to address any gaps.

If all of this becomes reality, I'd say this represents a significant leap forward overall.

Dave

> From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
> Sent: Tuesday, May 31, 2016 1:07 PM
> Cc: Ira McDonald <[email-masked]>; [email-masked]; Jerome
> Athias <[email-masked]>
> I think this is clearer.  I’m still wondering, however, how big an issue this is for
> 80% of the enterprises out there (or possibly even more).  If I buy an asset
> management solution and it generates tags, then do I not implicitly have
> confidence in that source?
> 
> On the other hand, for the 20% that are going to use the sources they have
> available and don’t trust those sources for any given reason, we might want
> some annotation mechanism.
> 
> > To clarify, I am speaking of a scenario in a single enterprise. On
> > each endpoint in a single enterprise, that endpoint could have
> > multiple sources for tags. For example, tags could be collected by
> > scanning the endpoint's file system for .swid files (one source), tags
> > could be generated by the endpoint's package manager (another source),
> > or tags could be created from the output of an inventory scanning tool
> > installed on that endpoint (a third source). All of these sources
> > provide a set of tags that reflect an understanding of what software
> > is on that one endpoint. These tags from all sources are collected by
> > our Posture Collector and delivered to that enterprise's Posture
> > Validator. The question Jerome was asking was whether that Posture
> > Validator (or some component that used data provided by the Posture
> > Validator) would have a different degree of confidence in the accuracy
> > or thoroughness of these sources. If the answer is yes, then that
> > would argue for annotating the information sent by the Posture
> > Collector with some identifier associated with the information's
> > source. (Currently, the SWID M&A spec just dumps tags from all sources
> > into a single collection and reports that information without source
> > annotation.)
> >
> > So we are talking about a single enterprise here, but the sources of the tags
> the Posture Collector collects and delivers will, in most cases, be written by
> vendors outside that enterprise.
> >
> >> I think I might be the one who needs coffee.  The way I read the
> >> chain seemed to imply an inter-organizational context to the “third-party
> creation”
> >> of such tags.  Within the context of a single enterprise, it seems
> >> that the problems that would be introduced by inter-organizational
> >> contexts would be reduced or at least deferred for later consideration.
> >>
> >>
> <[email-masked]
> >> <mailto:[email-masked]> > wrote:
> >>
> >> 	Hi,
> >>
> >>
> >> 		>> Part of the fundamental nature of software identification
> tags
> >> (of any type)
> >> 		>> is that they are secondary sources of evidence. Some
> source has
> >> made tags
> >> 		>> available as evidence of software presence based on their
> own
> >> understanding of
> >> 		>> present software and we (the parties interested in
> endpoint
> >> inventory) are
> >> 		>> low-level checks to examine an endpoint for direct
> evidence of
> >> software
> >> 		>> Given that we are relying on some black-box, third party
> to
> >> create and manage
> >> 		>> those parties. One might have a different level of
> confidence in
> >> tags directly
> >> 		>> generated from the endpoint's RPM database vs. from a
> software
> >> inventory tool
> >> 		>> downloaded from
> whether
> >> there was
> >> 		>>>> a tag was "discovered" and added to an endpoint's
> SWID tag
> >> collection.
> >> 		>>>> Scraping .swid files from the filesystem would be one
> source.
> >> Having a
> >> 		>>>> collection of SWID tags dynamically generated by an
> endpoint's
> >> package
> of a
> >> software
> in
> >> that
> >> 		>>>> location of a particular application, then maybe the
> SWID-PC
> >> could report
> me
> >> that
> of the
> >> tag source
> >> 		>>>> defined above. (I think this was what Dave was getting
> at in
> >> his second
> >> 		>>>> that it can accommodate dynamically generated,
> ephemeral tags
> >> (which we
> >> 		>>>> would need to do if we wanted to be sure that tag
> location was
> >> always
> >> 		>>>> available for reporting), one would pretty much be
> required to
> >> encapsulate
> >> 		>>>> working for this. Under this scenario we would have
> two
> >> distinct fields:
> >> 		>>>> Software Installation Location and Tag Location. The
> former
> >> could be
> >> 		>>>> zero-length if the SWID-PC was unable to reliably
> identify the
> >> location of
> doesn't
> >> mean we
> >> 		>>>> would still like to hear some thoughts on what use
> cases
> >> people feel that
> >> 		>>>> tag source tracking is needed for. It was noted on the
> call
> >> that different
> >> 		>>>> sources can have different collection characteristics
> (e.g.,
> >> some sources
> other
> >> sources might
> >> 		>>>> to employ periodic diffing to detect changes). I'm
> interested
> >> in hearing
> (or
> >> other
> >> 		>>>> behavior would be different because it was able to
> know that a
> >> particular
> >> 		>>>> SWID tag delivered from an endpoint came from one
> source
> >> rather than
> >> 		>>>> inventory tool rather than being discovered
> somewhere on the
> >> filesystem.
> >> 		>>>> Therefore I will change my default action and do
> something
> >> else instead.")
> >> 		>>>>
> >> 		>>>> Charles
> >> 		>>>>
> >> 		>>>>
> >> 		>>>>