Subject: [sacm] Using the ISO/IEC 19770-2:2015 SWID tag elements as a starting point for the IM

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 2 Aug 2016 15:55:02 +0000

At the first IETF 96 SACM WG meeting there was consensus that we should use the ISO SWID tag elements as a starting point for discussion about what the software information portion of the SACM information model should contain [1]. The ISO SWID tag elements are documented in the freely available XML Schema [2] for the ISO/IEC 19770-2:2015 standard, along with some additional documentation in the freely available NIST Internal Report (IR) 8060 [3].

To work out what the software information portion of the SACM information model should contain, we need to determine what we want to ignore from the SWID data model, and what additional elements are needed that are not currently defined in the SWID data model.

If we assume that we will keep whatever there is not consensus to ignore, what are your views on what should be ignored?
Given what is currently in the SWID data model, what is missing that should be added?

It would be good to wrap up this discussion by 8/19 to allow for time to update the information model before the next virtual interim. If you could, please weigh in before that date.

Regards,
Dave

[1] https://www.ietf.org/proceedings/96/minutes/minutes-96-sacm 
[2] http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd
[3] https://dx.doi.org/10.6028/NIST.IR.8060

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Thu, 4 Aug 2016 17:58:20 +0000

A few thoughts:

Do not need:
SoftwareIdentity>Corpus- Corpus is intended to indicate a pre-installation description of a component. If our goal is to report the list of installed software, we would never deal with pre-installation descriptions.
SoftwareIdentity>Media - "Used as an optimization hint to notify a system that it can ignore something when it's not likely to be used." Does not seem to be useful - if the tag is present, it applies to us.

Missing fields we need:
Source of the information - The group seemed to agree it would be useful to capture the source from which this descriptive record was generated.
Installation location of the software - Maybe this is just an Evidence entry with the "main" executable, or maybe it is something else.

Charles

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David
> A. (Fed)
> Sent: Tuesday, August 02, 2016 10:55 AM
> To: [email-masked]
> Subject: [sacm] Using the ISO/IEC 19770-2:2015 SWID tag elements as a
> starting point for the IM
> 
> At the first IETF 96 SACM WG meeting there was consensus that we should
> use the ISO SWID tag elements as a starting point for discussion about what
> the software information portion of the SACM information model should
> contain [1]. The ISO SWID tag elements are documented in the freely
> available XML Schema [2] for the ISO/IEC 19770-2:2015 standard, along with
> some additional documentation in the freely available NIST Internal Report
> (IR) 8060 [3].
> 
> To work out what the software information portion of the SACM information
> model should contain, we need to determine what we want to ignore from
> the SWID data model, and what additional elements are needed that are not
> currently defined in the SWID data model.
> 
> If we assume that we will keep whatever there is not consensus to ignore,
> what are your views on what should be ignored?
> It would be good to wrap up this discussion by 8/19 to allow for time to
> update the information model before the next virtual interim. If you could,
> please weigh in before that date.
> 
> Regards,
> Dave
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 4 Aug 2016 20:38:58 +0200

Hello,

are Software Instances covered by SWID sufficiently? There is the 
process entry in the resource collection. Can this represent running 
software on an endpoint in a way that is useful for e.g. the 
Vulnerability Assessment Scenario?

> SoftwareIdentity>Corpus- Corpus is intended to indicate a pre-installation description of a component. If our goal is to report the list of installed software, we would never deal with pre-installa…

Is, for example, an RPM package a Corpus?

> Source of the information - The group seemed to agree it would be useful to capture the source from which this descriptive record was generated.

Indeed, but these information elements are already handled in the IM, I 
think. Maybe we should check if they work as intended regarding SWID.

> Installation location of the software - Maybe this is just an Evidence entry with the "main" executable, or maybe it is something else.

Every representation of a path in the context of a SWID tag seems to be 
relative to the location of the SWID tag in a filesystem structure. We 
might need an absolute path in some usage scenarios? This would be a 
missing field that is outside of the SWID tag itself, I think

---

From: Ira McDonald <[email-masked]>
Date: Thu, 4 Aug 2016 14:52:51 -0400

Hi Henk,

Reuse, recycle...

Please take a look at one of most commonly implemented MIBs,
Host Resources MIB v2 (RFC 2790), which defines separate
tables for installed and running software and also for storage
and file systems.

Host Resources MIB has been present and correct in all the
operating systems I've queried for a decade.  This is deployed.

   HrSWInstalledEntry ::= SEQUENCE {
           hrSWInstalledIndex       Integer32,
           hrSWInstalledName        InternationalDisplayString,
           hrSWInstalledID          ProductID,
           hrSWInstalledType        INTEGER,
           hrSWInstalledDate        DateAndTime
   }

   HrSWRunEntry ::= SEQUENCE {
           hrSWRunIndex       Integer32,
           hrSWRunName        InternationalDisplayString,
           hrSWRunID          ProductID,
           hrSWRunPath        InternationalDisplayString,
           hrSWRunParameters  InternationalDisplayString,
           hrSWRunType        INTEGER,
           hrSWRunStatus      INTEGER
       }

   HrStorageEntry ::= SEQUENCE {
           hrStorageIndex               Integer32,
           hrStorageType                AutonomousType,
           hrStorageDescr               DisplayString,
           hrStorageAllocationUnits     Integer32,
           hrStorageSize                Integer32,
           hrStorageUsed                Integer32,
           hrStorageAllocationFailures  Counter32
       }

   HrFSEntry ::= SEQUENCE {
           hrFSIndex                   Integer32,
           hrFSMountPoint              InternationalDisplayString,
           hrFSRemoteMountPoint        InternationalDisplayString,
           hrFSType                    AutonomousType,
           hrFSAccess                  INTEGER,
           hrFSBootable                TruthValue,
           hrFSStorageIndex            Integer32,
           hrFSLastFullBackupDate      DateAndTime,
           hrFSLastPartialBackupDate   DateAndTime
       }

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]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Aug 4, 2016 at 2:38 PM, Henk Birkholz <
[email-masked]> wrote:

> Hello,
>
> are Software Instances covered by SWID sufficiently? There is the process
> entry in the resource collection. Can this represent running software on an
> endpoint in a way that is useful for e.g. the Vulnerability Assessment
> Scenario?
>
>> SoftwareIdentity>Corpus- Corpus is intended to indicate a
>> pre-installation description of a component. If our goal is to report the
>> list of installed software, we would never deal with pre-installation
>> descriptions.
>>
>
> SoftwareIdentity>Media - "Used as an optimization hint to notify a system
>> that it can ignore something when it's not likely to be used." Does not
>> seem to be useful - if the tag is present, it applies to us.
>>
>> Missing fields we need:
>> Source of the information - The group seemed to agree it would be useful
>> to capture the source from which this descriptive record was generated.
>>
>
> Installation location of the software - Maybe this is just an Evidence
>> entry with the "main" executable, or maybe it is something else.
>>
>
>>> Given what is currently in the SWID data model, what is missing that
>>> should
>>> be added?
>>>

---

From: Michael Godsey <[email-masked]>
Date: Thu, 4 Aug 2016 18:59:49 +0000

Re: Corpus tag:  The idea behind this is that you may scan an endpoint at such time as it has downloaded/obtained the setup payload, but has not yet run the installation.   In that case, it seemed worthwhile to have a tag identifying that set of files as being "legit" from an endpoint monitoring perspective.   Also, in the cases where installers do not clean up the install files, having the ability to recognize them as such would be helpful.

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Schmidt, Charles M.
Sent: Thursday, August 4, 2016 10:58 AM
To: Waltermire, David A. (Fed) <[email-masked]>; [email-masked]
Subject: Re: [sacm] Using the ISO/IEC 19770-2:2015 SWID tag elements as a starting point for the IM

A few thoughts:

Do not need:

Missing fields we need:

Charles

> From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, 
> David A. (Fed)
> At the first IETF 96 SACM WG meeting there was consensus that we 
> should use the ISO SWID tag elements as a starting point for 
> discussion about what the software information portion of the SACM 
> information model should contain [1]. The ISO SWID tag elements are 
> documented in the freely available XML Schema [2] for the ISO/IEC 
> 19770-2:2015 standard, along with some additional documentation in the 
> freely available NIST Internal Report
> (IR) 8060 [3].
> 
> To work out what the software information portion of the SACM 
> information model should contain, we need to determine what we want to 
> ignore from the SWID data model, and what additional elements are 
> needed that are not currently defined in the SWID data model.
> 
> If we assume that we will keep whatever there is not consensus to 
> ignore, what are your views on what should be ignored?
> should be added?
> It would be good to wrap up this discussion by 8/19 to allow for time 
> to update the information model before the next virtual interim. If 
> you could, please weigh in before that date.
> 
> Regards,
> Dave
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 5 Aug 2016 19:31:13 +0000

Hi Michael,

I had been coming at Dave's question with two assumptions: 1) that we were identifying the data model to be used by the SWID M&A messages when reporting software inventory; 2) that the goal of SWID M&A was to report the software installed on an endpoint. Either of those assumptions might diverge from the opinions of the group, so I want to get clarity on both.

Regarding assumption 2: my understanding is that when SWID M&A reports an inventory or reports a change, then it is reporting about installed software. If this is the case, then corpus tags would not be part of that report because they do not necessarily correlate to installed software. In both of the cases you mention, the discovery of the corpus tag would not be a reliable indicator of installed software. I'm not sure how SWID M&A is useful if its reports cannot be associated with installed software.

Regarding assumption 1: If we are trying to build a software data model that covers information beyond the information supportable by SWID M&A then I have no objection to that, but it seems reasonable to have some scenario under which the information in question would be collected. Assuming that it would not be collected by SWID M&A (as described above) could you describe a scenario under which a corpus tag would be collected?

Thanks,
Charles

> From: Michael Godsey [mailto:[email-masked]]
> Sent: Thursday, August 04, 2016 2:00 PM
> To: Schmidt, Charles M. <[email-masked]>; Waltermire, David A. (Fed)
> <[email-masked]>; [email-masked]
> Subject: RE: Using the ISO/IEC 19770-2:2015 SWID tag elements as a starting
> point for the IM
> 
> Re: Corpus tag:  The idea behind this is that you may scan an endpoint at such
> time as it has downloaded/obtained the setup payload, but has not yet run
> the installation.   In that case, it seemed worthwhile to have a tag identifying
> that set of files as being "legit" from an endpoint monitoring perspective.
> Also, in the cases where installers do not clean up the install files, having the
> ability to recognize them as such would be helpful.
> 
> SoftwareIdentity>Corpus- Corpus is intended to indicate a pre-installation
> description of a component. If our goal is to report the list of installed
> software, we would never deal with pre-installation descriptions.
> that it can ignore something when it's not likely to be used." Does not seem
> to be useful - if the tag is present, it applies to us.
> 
> Missing fields we need:
> Source of the information - The group seemed to agree it would be useful to
> capture the source from which this descriptive record was generated.
> Installation location of the software - Maybe this is just an Evidence entry
> with the "main" executable, or maybe it is something else.
> 
> Charles
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 5 Aug 2016 19:42:36 +0000

Hi Ira,

Thanks for the pointer. Just focusing on installed (rather than running) software for the moment, this entry seems much sparser than defined in the ISO SWID data model. In particular I don't see how it would consistently and reliably provide a product's name, publisher, and full version in an extractable way. I would think that all three of those pieces of information would need to be present and identifiable to support the Vulnerability Assessment Scenario.

Am I misunderstanding the MIB entry? Do you disagree with any of my statements? Or were you not suggesting this as an alternative for describing installed software?

Charles

> From: sacm [mailto:[email-masked]] On Behalf Of Ira McDonald
> Sent: Thursday, August 04, 2016 1:53 PM
> To: Henk Birkholz <[email-masked]>; Ira McDonald
> <[email-masked]>
> Cc: [email-masked]
> mailto: [email-masked] <mailto:[email-masked]>
> On Thu, Aug 4, 2016 at 2:38 PM, Henk Birkholz
> <[email-masked]
> <mailto:[email-masked]> > wrote:
> 
> 
> 	Hello,
> 
> process entry in the resource collection. Can this represent running software
> on an endpoint in a way that is useful for e.g. the Vulnerability Assessment
> Scenario?
> 
> pre-installation description of a component. If our goal is to report the list of
> installed software, we would never deal with pre-installation descriptions.
> 
> 
> 
> 		SoftwareIdentity>Media - "Used as an optimization hint to
> notify a system that it can ignore something when it's not likely to be used."
> Does not seem to be useful - if the tag is present, it applies to us.
> 
> 		Missing fields we need:
> 		Source of the information - The group seemed to agree it
> would be useful to capture the source from which this descriptive record was
> generated.
> 
> 
> 
> 	Indeed, but these information elements are already handled in the
> IM, I think. Maybe we should check if they work as intended regarding SWID.
> 
> 
> 
> 		Installation location of the software - Maybe this is just an
> Evidence entry with the "main" executable, or maybe it is something else.
> 
> 
> 
> 	Every representation of a path in the context of a SWID tag seems to
> be relative to the location of the SWID tag in a filesystem structure. We might
> need an absolute path in some usage scenarios? This would be a missing field
> that is outside of the SWID tag itself, I think
> 
> 
> 
> 
> 		Charles
> 
> 
> 
> 			From: sacm [mailto:[email-masked]
> <mailto:[email-masked]> ] On Behalf Of Waltermire, David
> 			A. (Fed)
> 			To: [email-masked] <mailto:[email-masked]>
> 			Given what is currently in the SWID data model, what
> is missing that should
> 			be added?
> 
> 			[1]
> https://www.ietf.org/proceedings/96/minutes/minutes-96-sacm
> <https://www.ietf.org/proceedings/96/minutes/minutes-96-sacm>
> 			[2] http://standards.iso.org/iso/19770/-2/2015-
> current/schema.xsd <http://standards.iso.org/iso/19770/-2/2015-
> current/schema.xsd>
> <https://dx.doi.org/10.6028/NIST.IR.8060>
> 
> 
> 			[email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
> 
> 
> 		[email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
> 
> 
> 	[email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/sacm>
> 
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 5 Aug 2016 15:50:08 -0400

Hi Charles,

I was just pointing out the data fields in the HR MIB v2 for software
tables.

Bear in mind that when the original HR MIB v1 (RFC 1514, September 1993)
was published, nobody had thought of SWID tags (or any other machine-
readable software info format across operating systems).

Cheers,
- Ira

On Fri, Aug 5, 2016 at 3:42 PM, Schmidt, Charles M. <[email-masked]>
wrote:

> Hi Ira,
>
> Thanks for the pointer. Just focusing on installed (rather than running)
> software for the moment, this entry seems much sparser than defined in the
> ISO SWID data model. In particular I don't see how it would consistently
> and reliably provide a product's name, publisher, and full version in an
> extractable way. I would think that all three of those pieces of
> information would need to be present and identifiable to support the
> Vulnerability Assessment Scenario.
>
> Am I misunderstanding the MIB entry? Do you disagree with any of my
> statements? Or were you not suggesting this as an alternative for
> describing installed software?
>
> Charles
>
> software
> >                       use the ISO SWID tag elements as a starting point
> for
> > discussion about what
> >                       If we assume that we will keep whatever there is
> not
> > consensus to ignore,
> >                       It would be good to wrap up this discussion by
> 8/19 to
> > allow for time to
> >                       update the information model before the next
> virtual
> > interim. If you could,

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 5 Aug 2016 20:09:05 +0000

Hi Henk,

> Vulnerability Assessment Scenario?

The SWID information model is primarily focused on installed software (i.e., SACM Software Components). If we are looking for a data model that reflects running software and the state thereof (i.e. SACM Software Instances), then I definitely think there are more fields to add. Currently, SWID M&A focuses only on reporting installed software, but that may be a separate discussion.
 
> Is, for example, an RPM package a Corpus?

Yes - An RPM package that had been downloaded but not installed could reasonably be reported by SWID instance with the corpus tag set.
 
> think. Maybe we should check if they work as intended regarding SWID.

I did not see anything in the -06 Information Model that corresponded to the source of the information. To be clear, by "source" I mean the raw data from which the data model instance was generated. A source could be an actual SWID tag, a third party software inventory tool, a package manager, or something else capable of providing information about the endpoints installed software inventory.

> missing field that is outside of the SWID tag itself, I think

I think Dave's intention here is to ask about the sufficiency of the ISO SWID information as the portion of the SACM information model used to describe software instances. I believe it would be perfectly reasonable to use absolute paths in all places relative paths could appear in a regular SWID tag. 

Charles

> David
> information
> ignore,

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 5 Aug 2016 22:23:05 +0200

> Yes - An RPM package that had been downloaded but not installed could reasonably be reported by SWID instance with the corpus tag set.

In this case, I am not sure if Corpus is not needed. If a package 
repository distributes packages that include vulnerabilities that might 
be of interest?

> I did not see anything in the -06 Information Model that corresponded to the source of the information. To be clear, by "source" I mean the raw data from which the data model instance was generated…

I think you are referring to a Data Origin? Could you have quick look at 
the definition of Data Source and Data Origin and assess if those would 
already satisfy your requirements regarding "source of the information"? 
It might be, for example, that data origin has to be extended (and 
therefore becomes a subject in the IM). Maybe we have to work on these 
definitions more.

> I think Dave's intention here is to ask about the sufficiency of the ISO SWID information as the portion of the SACM information model used to describe software instances. I believe it would be per…

The information about relative paths would be coming from outside the 
SWID tag. That's why I would classify that as a missing field. It is 
covered by SWID M&A, I suppose?

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 5 Aug 2016 20:42:08 +0000

> > Yes - An RPM package that had been downloaded but not installed could
> reasonably be reported by SWID instance with the corpus tag set.
> 

This gets back to my response to Michael: SWID M&A is (currently) designed to provide a list of installed software, so it would not report a tag that had no known correlation to whether a piece of software was installed. Can you come up with a scenario under which such a tag would be delivered? 

> seem
> > I did not see anything in the -06 Information Model that corresponded to
> the source of the information. To be clear, by "source" I mean the raw data
> from which the data model instance was generated. A source could be an
> actual SWID tag, a third party software inventory tool, a package manager, or
> something else capable of providing information about the endpoints
> installed software inventory.
> 

Thank you for the pointer. These fields could reasonably be interpreted as meeting this need, although the descriptions would need to be expanded to be sure.

Regardless, I think the point is that this is a piece of information that the group has suggested should be conveyed when reporting information about installed software, and which is not currently in the ISO SWID information model, which is what I believe Dave was asking about.

> entry
> > I think Dave's intention here is to ask about the sufficiency of the ISO SWID
> information as the portion of the SACM information model used to describe
> software instances. I believe it would be perfectly reasonable to use
> absolute paths in all places relative paths could appear in a regular SWID tag.
> 

I believe Dave is asking whether the ISO SWID information model meets our needs for reporting Software Components. As such, whether the data comes from actual ISO SWID tags or some other source is beside the point. I imagine in many cases (at least in the near future) the reported information will be generated from sources other than ISO SWID tags pulled from the file system. Even if it is pulled from a SWID tag it could be changed before delivery (such as by turning relative paths into absolute paths). The question (assuming I understand Dave's intent) is just whether the ISO SWID information model is capable of expressing the information we need when reporting Software Components. (Dave - let me know if I have this wrong.)

Charles

> >>>> the SWID data model, and what additional elements are needed that
> are
> >> not

---

From: Michael Godsey <[email-masked]>
Date: Fri, 5 Aug 2016 22:33:49 +0000

What I mentioned is, I think,  a valid endpoint monitoring scenario, and helps to reduce the large pool of unknown files on an endpoint, by identifying install files with a corpus tag.   Are you suggesting this is not part of the "design" of SWID?  Or that it is not the intent of this WG to include only  scenarios relating to installed software?   One of the reasons we baked the corpus tag into the 19770-2:2015 revision was to enable these kinds of scenarios, but if your point is this current work is more narrowly focused, then ok.

As a software publisher, we would create SWID tags for the installed software as well as corpus tags for the installation package.   Assuming an aggregator or other collection service didn't drop them as not "valid" (from its perspective) I would think they would be aggregated and used in assessing the endpoint.  This might be especially helpful if the SWID tag were to reference a file manifest of files associated with either the installation file, or even the "to be" installed software.   I understand this is not part of standard, but the scenario has held great interest with many of the govt. agencies we have talked to over the past 3+ years who are interested in SWID tags to enable continuous monitoring

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Schmidt, Charles M.
Sent: Friday, August 5, 2016 1:42 PM
To: Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [sacm] Using the ISO/IEC 19770-2:2015 SWID tag elements as a starting point for the IM

> repository distributes packages that include vulnerabilities that 
> might be of interest?

> the source of the information. To be clear, by "source" I mean the raw 
> data from which the data model instance was generated. A source could 
> be an actual SWID tag, a third party software inventory tool, a 
> package manager, or something else capable of providing information 
> about the endpoints installed software inventory.
> 
> I think you are referring to a Data Origin? Could you have quick look 
> at the definition of Data Source and Data Origin and assess if those 
> would already satisfy your requirements regarding "source of the information"?

> >>> Evidence
> >> Every representation of a path in the context of a SWID tag seems 
> >> to be relative to the location of the SWID tag in a filesystem 
> >> structure. We might need an absolute path in some usage scenarios? 
> >> This would be a missing field that is outside of the SWID tag 
> >> itself, I think
> >
> information as the portion of the SACM information model used to 
> describe software instances. I believe it would be perfectly 
> reasonable to use absolute paths in all places relative paths could appear in a regular SWID tag.
> 

Charles

> >>>> Subject: [sacm] Using the ISO/IEC 19770-2:2015 SWID tag elements 
> >>>> as a starting point for the IM
> >>>>
> >>>> use the ISO SWID tag elements as a starting point for discussion 
> >>>> about
> >> what
> >>>> contain [1]. The ISO SWID tag elements are documented in the 
> >>>> freely available XML Schema [2] for the ISO/IEC 19770-2:2015 
> >>>> standard, along
> >> with
> >>>> some additional documentation in the freely available NIST 
> >>>> Internal
> >> Report
> >>>> (IR) 8060 [3].
> >>>>
> >>>> It would be good to wrap up this discussion by 8/19 to allow for 
> >>>> time to update the information model before the next virtual 
> >>>> interim. If you
> >> could,

---

From: Michael Godsey <[email-masked]>
Date: Fri, 5 Aug 2016 23:17:29 +0000

Yes, I think you have it.  Good summary of the 3 actually :)

-------- Original message --------
From: "Schmidt, Charles M." <[email-masked]>
Date: 8/5/16 4:05 PM (GMT-08:00)
To: Michael Godsey <[email-masked]>, Henk Birkholz <[email-masked]>, [email-masked]
Subject: RE: [sacm] Using the ISO/IEC 19770-2:2015 SWID tag elements as a starting point for the IM

Hi Michael,

Thanks for the clarification. This clarifies the use case I was not seeing. Thank you.

It sounds like there are actually three types of "software inventories" that people are interested in:
- Installed software (SACM "Software Components") - This is what the SWID M&A currently focuses on (but that document is under revision anyway)
- Running software (SACM "Software Instances") - Per comments by Henk and others, this could be of interest. This would overlap with the installed software but would not be identical since not all installed software would be running, some installed software could be running multiple instances, and some running software might not actually be installed on the device.
- Installation packages - These would be discovered corpus tags, reports of identified RPM or similar packages (installed or not), and the like. These would not necessarily have reliable correlation to installed software, but I believe you are arguing these would be useful in their own right.

Am I correctly following?

Thanks,
Charles

> Sent: Friday, August 05, 2016 5:34 PM
> To: Schmidt, Charles M. <[email-masked]>; Henk Birkholz
> <[email-masked]>; [email-masked]
> Subject: RE: [sacm] Using the ISO/IEC 19770-2:2015 SWID tag elements as a
> What I mentioned is, I think,  a valid endpoint monitoring scenario, and helps
> to reduce the large pool of unknown files on an endpoint, by identifying
> install files with a corpus tag.   Are you suggesting this is not part of the
> "design" of SWID?  Or that it is not the intent of this WG to include only
> scenarios relating to installed software?   One of the reasons we baked the
> corpus tag into the 19770-2:2015 revision was to enable these kinds of
> scenarios, but if your point is this current work is more narrowly focused,
> then ok.
>
> As a software publisher, we would create SWID tags for the installed
> software as well as corpus tags for the installation package.   Assuming an
> aggregator or other collection service didn't drop them as not "valid" (from its
> perspective) I would think they would be aggregated and used in assessing
> the endpoint.  This might be especially helpful if the SWID tag were to
> reference a file manifest of files associated with either the installation file, or
> even the "to be" installed software.   I understand this is not part of
> standard, but the scenario has held great interest with many of the govt.
> agencies we have talked to over the past 3+ years who are interested in
> SWID tags to enable continuous monitoring
>
> This gets back to my response to Michael: SWID M&A is (currently) designed
> to provide a list of installed software, so it would not report a tag that had no
> known correlation to whether a piece of software was installed. Can you
> come up with a scenario under which such a tag would be delivered?
>
> Thank you for the pointer. These fields could reasonably be interpreted as
> meeting this need, although the descriptions would need to be expanded to
> be sure.
>
> Regardless, I think the point is that this is a piece of information that the
> group has suggested should be conveyed when reporting information about
> installed software, and which is not currently in the ISO SWID information
> model, which is what I believe Dave was asking about.
>
> I believe Dave is asking whether the ISO SWID information model meets our
> needs for reporting Software Components. As such, whether the data comes
> from actual ISO SWID tags or some other source is beside the point. I imagine
> in many cases (at least in the near future) the reported information will be
> generated from sources other than ISO SWID tags pulled from the file
> system. Even if it is pulled from a SWID tag it could be changed before
> delivery (such as by turning relative paths into absolute paths). The question
> (assuming I understand Dave's intent) is just whether the ISO SWID
> information model is capable of expressing the information we need when
> reporting Software Components. (Dave - let me know if I have this wrong.)
>
> Charles
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 5 Aug 2016 23:05:02 +0000

Hi Michael,

Thanks,
Charles