Subject: [sacm] Some technical details for SWID M&A proposals

From: "Schmidt, Charles M." <[email-masked]>
Date: Thu, 26 May 2016 16:33:47 +0000

Hi all,

Many of the SWID M&A proposals currently undergoing discussion have
technical impacts on messages and control flows. As it can be difficult to
agree on changes without a better sense of what these changes look like, I
have taken a stab at documenting technical changes that would be one way of
meeting the proposals. I hope these will help continue the current
discussion on if/how these proposals should proceed. I want to emphasize
that these are tools for discussion - they are not final decisions of any
kind.

The attached documents address five of the outstanding proposal request.
1.  Support multiple tag types (ISO SWID 2009, ISO SWID 2015, other non-ISO
software identifier, etc.) and explicitly identify their use
2.  Identify the data format (XML, JSON, CBOR, etc.) of a tag
3.  Record application location (when available) along with the tag
associated with that application
4.  Record the tag version associated with each reported ISO SWID tag
5.  Record the tag source for each tag reported in a SWID Response message

I would have separated the technical details into the corresponding
discussion threads, but it turned out that the proposals had significant
overlap and interdependency. Given that, I felt that it was easier to put
this all in one thread rather than have 5 ongoing threads whose decisions
all affect each other. If people disagree, I can try to extricate each of
the proposals into a separate thread.

Two documents are attached:
- Technical Proposal Discussion for SWID MandA.pdf - This provides a
high-level overview and outline of the technical changes associated with
each of the proposals.
- Diagrams of Proposed Changes to SWID MandA.pdf - This supplements the
preceding document by diagraming message composition and the contents of a
proposed IANA table.

What are people's thoughts on these technical changes and do they change
anyone's thoughts about the proposals?

Thanks,
Charles

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 26 May 2016 12:41:22 -0400

Excellent points.  One has a feeling here that this
material in on some kind of institutional auto-pilot,
and the analysis doesn't make much difference. :-)

What you are doing with respect to looking at message
flows and sizes, however, is critical if any of this is ever
to get used even in closed environments.  Would also
like to see it in JSON.

-t

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 26 May 2016 13:27:47 -0700

Charles,

I've missed out on parts of this discussion, but it looks to me like 
what you are attempting to support here is the possibility for the 
payload of the tag data to be formatted in whichever data model is 
native to that particular tag type -- as opposed to using a common 
(standard!) IM/DM regardless of originating tag type.

If that's the case, the consequence is that any particular tag 
information can only be used by a consumer that understands the format 
of that tag type/data format combination.  In other words what this 
would do is standardize the ability to transmit arbitrary data, but does 
nothing to standardize the ability to make use of that data.

--gun

On 5/26/2016 9:33 AM, Schmidt, Charles M. wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

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

Is there a better way to approach this?

> On May 26, 2016, at 4:27 PM, Gunnar Engelbach <[email-masked]> wrote:
> 
> 
> Charles,
> 
> I've missed out on parts of this discussion, but it looks to me like what you are attempting to support here is the possibility for the payload of the tag data to be formatted in whichever data model is native to that particular tag type -- as opposed to using a common (standard!) IM/DM regardless of originating tag type.
> 
> If that's the case, the consequence is that any particular tag information can only be used by a consumer that understands the format of that tag type/data format combination.  In other words what this would do is standardize the ability to transmit arbitrary data, but does nothing to standardize the ability to make use of that data.
> 
> 
> --gun
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
>

---

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

Adam/Gunnar,

There seems to be the familiar tension between flexibility and
predictability. On the one hand, as Gunnar, Tony, and others have noted,
there are multiple software tag structures, none of which can be said to be
dominant in all of the operational environments we want to serve in this
spec. This would argue for supporting flexibility in the types of tag
structures we can support. On the other hand, as Gunnar notes below, if the
consumers cannot rely on receiving data in a certain set of formats, they
may not be able to use the data they receive. Identifying one or more MTI
tag type/formats would help, but would not solve the problem because there
is a third dimension here:

We cannot mandate the type/format of the tags the Posture Collector finds on
the endpoint. By the nature of this spec, we are relying on one or more
"sources" to populate and maintain and/or generate tags. The type/format of
those tags made available by these sources is beyond the scope of the spec
we are considering here. (I.e., I don't think it is reasonable to state
"Every endpoint MUST express its complete software inventory using ISO 2015
SWID XML tags" or any other tag format or set of tag formats.) In the end,
the type of tags that are available to us are outside of our control.

Given this, the only options I am seeing are:
1) Limit the types of tags that our specification collects and delivers,
understanding that this might leave some types of available tags uncollected
and undelivered.
2) Support collection and delivery of any type of tag, understanding that
some collected tags might not be ingestible by the intended recipient.

Personally, I would opt for option 2, especially given an ability for the
consumer to explicitly specify the type/format of tags it wants delivered so
as to avoid the overhead of delivering unreadable content. This would avoid
the possibility of leaving usable data behind. This is, by the way, the
approach supported by the technical proposal I delivered yesterday. 

Thoughts? Gunnar - does this in any way allay your concerns?

Charles

> -----Original Message-----
> From: Adam Montville [mailto:[email-masked]]
> Sent: Friday, May 27, 2016 5:43 AM
> To: Gunnar Engelbach <[email-masked]>
> Cc: Schmidt, Charles M. <[email-masked]>; [email-masked]
> Subject: Re: [sacm] Some technical details for SWID M&A proposals
> 
> 	On May 26, 2016, at 4:27 PM, Gunnar Engelbach
> <[email-masked]
> <mailto:[email-masked]> > wrote:
> 
> 
> 	Charles,
> 
what
> you are attempting to support here is the possibility for the payload of
the
> tag data to be formatted in whichever data model is native to that
particular
> tag type -- as opposed to using a common (standard!) IM/DM regardless of
> originating tag type.
> 
> information can only be used by a consumer that understands the format of
> that tag type/data format combination.  In other words what this would do
is
> standardize the ability to transmit arbitrary data, but does nothing to
> standardize the ability to make use of that data.
> 
> 
> 	--gun
> 
> 
> 		technical impacts on messages and control flows. As it can
be
> difficult to
> 		1.  Support multiple tag types (ISO SWID 2009, ISO SWID
2015,
> other non-ISO
> 		3.  Record application location (when available) along with
the
> tag
> 		all affect each other. If people disagree, I can try to
extricate
> each of

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 27 May 2016 11:31:44 -0700

Look out below...

> some collected tags might not be ingestible by the intended recipient.

3) Tag information intended for use in a SACM environment is translated 
into a common standard data format prior to delivery from the 
collector.  This will still create some limitation on the number of 
formats supportable within a SACM environment since it is reliant on the 
collector being able to do that translation, but any data that does 
enter the SACM sphere will be usable.

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Fri, 27 May 2016 18:52:35 +0000

Hi Gunnar,

> enter the SACM sphere will be usable.

True - a valid third alternative, but I have some concerns about it.
Specifically, it seems like it is just moving the earlier concern about
"finding tags one cannot parse" from the Posture Validator to the Posture
Collector. In fact, it is adding even more responsibility: now the Posture
Collector not only needs to be able to consume as many tag formats as
possible, but it must be able to normalize them into the chosen SACM format.
The endpoint could have sources that produce tags that it cannot parse, or
that it can only convert via a lossy translation. To me, this doesn't seem
different from the earlier concerns about the Posture Collector receiving
data it cannot parse.

If we are going to rely on converters as part of our architecture, why not
put them with the Posture Validator? Doing so means 1) there is a single
location where normalization occurs, rather than forcing every endpoint
(including embedded systems, IoT, etc.) to load their own normalization
functions, which then need to be consistently maintained across the
enterprise, and 2) the original tags remain available (and not just
potentially lossy translations) in any data store populated by the Posture
Validator (e.g., a CMDB) if any tools that are collecting information from
the Posture Validator want it.

It seems like we are likely to lose data in all scenarios: 
(option 1) because an available tag is not one of the formats permitted by
SWID M&A
(option 2) because a tag was delivered but could not be consumed by the
Posture Validator
(option 3) because a tag could not be translated by the Posture Collector
into the official SACM format

Given all those options, though, I think 1 and 3 potentially exclude tags
that could be consumed by the enterprise's Posture Collector or components
that use it. Option 2 (in my option) is the least lossy of the options.

Charles

> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Friday, May 27, 2016 1:32 PM
> To: Schmidt, Charles M. <[email-masked]>; Adam Montville
> <[email-masked]>
> Cc: [email-masked]
> of

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 27 May 2016 13:40:25 -0700

> different from the earlier concerns about the Posture Collector receiving

Well, no, it's not commensurate, for at least three reasons:

1)  The tag types that need to be known to a collector is a subset of 
all tag types, since a collector runs on a particular type of system.  A 
Windows agent would not be expected to be able to handle OSX-specific 
tag types.

2)  Similar to (1), a single collector does not necessarily need to be 
able to translate every tag type it could possibly come across. This 
might be because multiple collection methods are in use, a collector is 
built for a single narrow function, etc.

3)  There is more than one consumer for the collected data.  It could be 
for vulnerability analysis, license administration, inventory, 
compliance, and so on.  Every current and future use for that 
information would need to be able to parse every supported tag type in 
order to do its function.  A considerable amount of duplication to say 
the very least.  The same can be said for every other type of data being 
collected from an endpoint.

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 31 May 2016 17:52:47 +0000

Hi Gunnar,

Comments below:

> > To me, this doesn't seem

True - I clearly overstated the burden on individual endpoints, so thank you
for the correction.

That said, from an enterprise perspective I would think the set of
translators would be constant regardless of whether translation occurred on
endpoints or servers. If one endpoint has tags of interest that are not one
of the specified SACM forms, the appropriate translator needs to be
somewhere. The question is whether that somewhere should be the endpoint or
the server. (Or, as you note below, on the end-consumer.)

> built for a single narrow function, etc.

I think I agree, but I think I would phrase it differently. I would say that
not all tags on an endpoint are necessarily of interest to the enterprise.
Some types of tags might be generally unreliable in nature (e.g., a poor
correlator with software presence), might not have the needed metadata bout
installed software products, or could be for software the enterprise doesn't
care about monitoring. In the first two cases, the presence of an alternate
tag type from the same source (and covering the same products) could render
the second format completely unnecessary.

Are we saying the same thing using different words here? 

> collected from an endpoint.

I think you are talking about a scenario where every end consumer of tags is
responsible for normalization. That is certainly yet another option (call it
option 4), although I agree that it has the weaknesses you note here. I
would argue that this is not equivalent to having normalization done on the
Posture Validator, which is more what I was thinking of in my previous
email.

Given this discussion, it might be useful to recast our options based on who
is responsible for data normalization. 

A) No normalization + data model. Posture Collectors collect and SWID M&A
transports only a defined set of tag types and formats. All tags that are
not expressed in those formats are not collected and are ignored. (Former
option 1)
B) No normalization + no data model. Posture Collectors collect and SWID M&A
transports any type or format of tags. Tag consumers collecting tags from
the CMDB/Posture Validator get whatever tags they can understand and other
types of tags are ignored.
C) Posture Collector normalization. The Posture Collector is responsible for
normalizing the tags collected on an endpoint prior to delivery to a Posture
Validator. SWID M&A supports transmission of a defined set of tag types and
formats, to which the Posture Collector translates. (Option 3 from Gunnar's
earlier email)
D) Posture Validator normalization. Posture Collectors collect and SWID M&A
transports any type or format of tags. The receiving Posture Validator is
responsible for normalizing the incoming data to a set of types and formats
identified by SACM (but whose specification is outside the scope of SWID M&A
itself). 
E) Consumer normalization. Posture Collectors collect and SWID M&A
transports any type or format of tags. Tags are stored on the Posture
Validator or CMDB until a consumer needs them. The consumer then collects
the relevant tags and is responsible for translating any tags into a format
it can consume. (Option 4 from this email)

Gunnar, I believe you are an advocate of C, correct? I also think both of
use agree that options B and E are probably bad ideas since the data
consumers can have no idea as to what they are going to get. Personally, I
think I'm more of a fan of D - it has a centralized rather than distributed
normalization function and can avoid unnecessary data loss.

Gunnar, have I misinterpreted any of your comments? Do others have any
thoughts on this?

Thanks,
Charles

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 31 May 2016 11:53:22 -0700

The reality is that not all tagging formats are going to be implemented 
on the first iteration and new ones will be devised and revisions made 
to the existing ones.

Depending on the vendor, the most likely outcome is that only a few of 
the most common tagging systems will ever be implemented and if your 
enterprise uses any others you are just out of luck -- unless you do 
some in-house work or some other vendor is willing to invest the time 
and effort into supporting the less common tag types.

If the normalization is done centrally by the Validator then the 
Validators (and every other consumer) needs to support all tag types 
right from the start, keep updating as the various tag formats change, 
and be done thus by every vendor.

Which, I can guarantee, won't happen.  And even if it did, the develop 
and release cycle on large systems is typically 1 to 2 years, which is 
just too large a gap in this space.

I also don't expect collectors to implement all tag types.  Even 
accounting for the obvious omissions -- a Windows agent wouldn't be 
expected to have any awareness of tagging specific to OSX, HP-UX, 
Android, etc,  -- I think we can count on agents having incomplete 
coverage.  In fact, I think we should plan on that being the case.

But if the collector does the translation to a standardized format, then 
that data is available for any SACM usage immediately with no need for 
updates to any other part of the SACM environment.  In the worst case I 
would have my own IT department develop something to fill in the gaps, 
and the only part they would need to worry about is the tag 
collector-to-common-DM for that specific tag type.

The downside is that I may need to install and maintain multiple agents 
on some systems, but the most likely case is that that kind of 
customization will only be necessary to cover systems that otherwise 
wouldn't be covered at all.

So, yeah, your option (C) is what I would go with with (E) being the 
most palatable of any of the other options.

--gun