Re: [sacm] WGLC for draft-ietf-sacm-nea-swima-patnc

[Adam Montville <[e-mail]>]

I think I'm all set, Charles, thanks for your patience. :-)

On Fri, Aug 4, 2017 at 9:10 AM Schmidt, Charles M. <[e-mail]>
wrote:

> Hi Adam,
>
> Sounds like we are mostly aligned. I've trimmed the points where it looks
> like we are on the same page and responded inline to the others.
>
> >       > On Page 15 the draft states "All SW-PCs MUST at least be able to
> > generate
> >       > Software Identifiers for the data model types specified in
> Section 6
> > of this
> >       > document." Section 6 describes data models for SWID 2009 and
> > SWID 2015,
> >       > but nothing else. Is this really what we desire? What about Linux
> > distribution
> >       > package managers?
> >
> >       Adding on to Stephen's comments, I'll note that we intend SWIMA to
> > be extensible. If someone wished to report RPM records or other types of
> > packages, they are welcome to do so. The just need to define an
> > authoritative way of deriving a Software Identifier from the record.
> > However, I don't think we want to *require* support for such packages in
> all
> > SW-PCs.
> >
> > [AWM] I was looking at this a bit differently, I think. If there is a
> collector
> > capable of expressing RPM packages, as an example, and they want to
> > extend this to shuttle that information over PT-TLS, then would they
> need to
> > also collect 2009 and 2015 SWIDs? It seems contrary to the point of
> having
> > posture brokers. Maybe I'm missing something.
>
> <CMS>
> I think that this stems from confusion about what "MTI" means for records
> in SWIMA. SWIMA never requires that any given type of record be collected
> from an endpoint. An endpoint might have hundreds of SWID tags on it, but a
> compliant SWIMA specification might never touch them and instead choose to
> gather some other indicator of software installation. (For example, a SWIMA
> implementation might feel that RPM records are likely to be more complete
> and accurate than any SWID tags that might get installed across the
> endpoint.) The SWIMA specification is explicit that it only requires
> collection to be done in an internally consistent manner (i.e., it cannot
> use one source in one report and ignore that source in a subsequent report)
> but it never requires the use of any specific source of information. In
> short, a SWIMA implementation can make use of whatever information is
> available in whatever way it chooses, provided that it uses those sources
> consistently.
>
> All the MTI requirement means is that every compliant SWIMA-PC MUST know
> how to take any 2009 or 2015 SWID tag it does collect (*if* it collects any
> at all) and deterministically derive a standard Software Identifier from
> that record. The issue this tries to address is that we would need a
> one-to-one mapping between information records describing software and the
> Software Identifier that is the shorthand for the described software.
> Unfortunately, there are lots of ways to do such a mapping, so there could
> be variation across implementations as to how a given piece of software is
> represented by a Software Identifier. By making 2009 and 2015 SWID tags
> MTI, all we are doing is ensuring that every SWIMA implementation will have
> the same one-to-one mapping between a given tag and its Software
> Identifier. This means that, at least for SWID tags, two collectors (from
> different vendors) will use the same Software Identifier for the same SWID
> tag, and thus those Identifiers can be directly compared.
>
> This might get at your "redundancy" comment too - if MTI meant "required
> collection", then yes, requiring both types of tags be collected could be
> redundant. However, that is not the requirement. All the MTI statement
> requires is that SWIMA implementations are universally consistent in their
> mapping of 2009 and 2015 SWID tags to Software Identifiers. I don't think
> that is redundant - it is just better covering the bases.
>
> >       > What about discovered software outside typical
> >       > installation patterns?
> >
> >       As Andreas notes, such software can still be represented using SWID
> > tags. They could also be represented using other record formats, as I
> note
> > above.
> >
> > [AWM] Do we need to mention how? If so, is this the right place to do
> that?
>
> <CMS>
> If you are talking about "how to convert to a SWID tag", I think that is
> beyond the scope of SWIMA. (Maybe if SACM decides someday to endorse SWID
> tags as the official record format for software information, that might be
> reasonable, but for now I think it would be premature.)
>
> If you are talking about how to represent records other than SWID tags
> within SWIMA messages, I'm not sure that is necessary because the
> specification itself is completely generic. We just talk about records and
> Software Identifiers.
>
> >       > And, does it make sense, in a brokered architecture like
> >       > NEA, to require redundant capabilities in the anticipated myriad
> > collectors?
> >
> >       Not sure how this is "redundant". The group agreed that 2009 SWID
> > tags should be supported for legacy reasons, while 2015 tags should be
> > supported for future compliance. In general, SWIMA has virtually no
> control
> > over the nature of the records on the endpoint - they might be SWID 2009,
> > SWID 2015, something completely different, or a combination thereof.
> > SWIMA is concerned with collection and conveyance of available
> information.
> > Normalization of that information into one preferred record format is
> > beyond the scope of SWIMA. (Deliberately so, since our early
> conversations
> > on SWIMA involved a lot of holy wars about preferred record formats, none
> > of which appear to "dominate" are target environment today.) Maybe SACM
> > will eventually get behind a single format, and when they do SWIMA will
> be
> > ready and able to convey it. Until then, SWIMA's goal is to support
> collection
> > and conveyance of whatever software records might be available.
> >
> > [AWM] Maybe I should ask this way. Is the expectation that RPM package
> > management collectors, for example, would require a separate
> specification
> > for shuttling over PT-TLS, or that they would extend this draft? If a
> separate
> > specification, then I retract my comments, because then SWID data models
> > aren't necessary. If an extension of this draft, then my comment remains.
>
> <CMS>
> See my earlier comment about redundancy - if this is related to concerns
> about require collection of records, SWIMA never imposes such a requirement.
>
> To answer your question, no - ideally we would hope that those collectors
> would not use a separate PA-TNC binding. In fact, no extension of this
> draft is necessary for RPM package manifests to be used directly in SWIMA.
> Any representation of installed software can be directly conveyed by SWIMA.
> Of course, if that representation hasn't been standardized in the IANA
> table, then two different vendors might identify that data model
> differently and use a different algorithm to derive Software Identifiers
> from those records, making direct comparison between their findings more
> challenging, but at least within that vendor's product space there would be
> no problem. (The advantage of the IANA table entries, is that the data
> model type identifier of the record will be the same across all
> implementations and the algorithm to derive the Software Identifier will be
> the same, allowing any such records to be directly compared across vendor
> boundaries.)
>
> So, in the current draft, any vendor could declare that an RPM manifest
> entry was a utilized Data Model Type, create a way to create a Software
> Identifier from each manifest entry, and start sending those to a consumer
> via SWIMA with no extensions necessary. Of course, vendor 2 might do the
> same thing, but would use a different type identifier and Software
> Identifier algorithm. In either case, however, the information is collected
> and delivered.
>
> Does this address your questions?
>
> Thanks,
> Charles
>