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

From: "Schmidt, Charles M." <[email-masked]>
Date: Wed, 1 Jun 2016 19:19:19 +0000

Hi Gunnar,

Thanks, as always, for the good insights. If I can paraphrase what I think I
am hearing: you are asserting that the use of certain tags is likely to be
context dependent. Specifically, certain types of tags will primarily be
used on certain OSs and/or on devices in a certain role. A centralized
normalization function needs to have translators for the tags of every
context in the enterprise. However, if translation is done on the endpoints
(i.e., within that very context that is producing the tags) those endpoints
only need to support the translators appropriate for their specific context.
Moreover, as new contexts are added to an enterprise, I think you are
arguing that it is more natural to account for the new varieties of tags
that could arise in those contexts locally (i.e., on the endpoint) rather
than updating a central server every time a new context is added.

Do I have this correct? What are others' thoughts on this?

Thanks,
Charles

> -----Original Message-----
> From: Gunnar Engelbach [mailto:[email-masked]]
> Sent: Tuesday, May 31, 2016 1:53 PM
> To: Schmidt, Charles M. <[email-masked]>; Adam Montville
> <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sacm] Some technical details for SWID M&A proposals
> 
> 
> 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
> 
> 
> On 5/31/2016 10:52 AM, Schmidt, Charles M. wrote:
> > Hi Gunnar,
> >
> > Comments below:
> >
> >>>> 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.
> >>> To me, this doesn't seem
> >>> different from the earlier concerns about the Posture Collector
> > receiving
> >>> data it cannot parse.
> >> 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.
> > 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.)
> 
> >> 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.
> > 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?
> >
> >> 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.
> > 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: Adam Montville <[email-masked]>
Date: Wed, 1 Jun 2016 19:10:07 -0500

To clarify, this isn’t as much about tags as it is about the normalization of different tagging structures, correct?  In that case, I think that the normalization/translation should be happening on the endpoints or from within those contexts.

So, information would go from context-specific format to normalized format for centralized needs (i.e. inventory assessment, reporting, what have you).  Then, if something needs to be done with that specific piece of software at the endpoint, we may need a way to get back from the normalized format to the context-specific format, or at least to reference that context-specific format distinctly.

Thoughts?

> On Jun 1, 2016, at 2:19 PM, Schmidt, Charles M. <[email-masked]> wrote:
> 
> Hi Gunnar,
> 
>> If the normalization is done centrally by the Validator
>>

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 1 Jun 2016 18:05:36 -0700

Charles:  Yes, that's a decent restatement of what I have in mind.

Adam:  In line, I think, with what you are saying, the sooner the data 
is transformed into the common format the sooner in its lifecycle 
components can be created that make use of that data. Doing it at the 
endpoint (or a proxy acting on behalf of an endpoint) is as far out on 
that limb as you can get.

The drawback, however, is that the original tag information is not 
available, and that could represent a data loss -- or a lossy 
conversion, as Charles has been characterizing it.  I think there are 
ways around that, such as retaining enough information such that an 
interested party could go back and get the original tag, but the actual 
process of doing something like that would be outside of the scope of SACM.

And with that I'll linger a bit to see what others have to say.

--gun

---

From: Michael Godsey <[email-masked]>
Date: Thu, 2 Jun 2016 14:34:09 +0000

Although I agree that data transformation at the end point is as far out on the limb as you can get (short of data creation itself being done for all formats needed, not likely to ever happen), I think that would be very difficult to expect on a good number of endpoints.   It doesn't make sense to expect each endpoint to have the capability to transpose from all the different potential formats.   Some won't have processing capability to do so, some won't have room on the endpoint for such a transposition service, etc.   It seems much more likely there would need to be an aggregator service that pulls from each endpoint and knows how to do the transposition.  This is probably the proxy you reference, though I don't think of that term in relation to collecting and transposing data.  But maybe the term aggregator doesn't resonate well with everyone either.

Re: the lossy conversion issue, I do think that a repository of tag data helps address this, whereby you can use a tag ID and hit up a service to retrieve the tag's full and original data, would be much needed.   We started discussing on the need for some standard for tag repository service at the NIST workshop on Tag implementation in April, and are creating a Tag Vault work group to look at addressing that.  Probably enough to say it would be out of scope for this SACM effort, although knowing that such a standards compliant service existed and covering how (conceptually anyway, at this point) various monitoring services could utilize such a tag repository, would be helpful to address I think.

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Wednesday, June 1, 2016 6:06 PM
To: Adam Montville <[email-masked]>; Schmidt, Charles M. <[email-masked]>
Cc: [email-masked]
Subject: Re: [sacm] Some technical details for SWID M&A proposals

Adam:  In line, I think, with what you are saying, the sooner the data is transformed into the common format the sooner in its lifecycle components can be created that make use of that data. Doing it at the endpoint (or a proxy acting on behalf of an endpoint) is as far out on that limb as you can get.

The drawback, however, is that the original tag information is not available, and that could represent a data loss -- or a lossy conversion, as Charles has been characterizing it.  I think there are ways around that, such as retaining enough information such that an interested party could go back and get the original tag, but the actual process of doing something like that would be outside of the scope of SACM.

--gun

On 6/1/2016 5:10 PM, Adam Montville wrote:
>> Thanks, as always, for the good insights. If I can paraphrase what I 
>> think I am hearing: you are asserting that the use of certain tags is 
>> likely to be context dependent. Specifically, certain types of tags 
>> will primarily be used on certain OSs and/or on devices in a certain 
>> role. A centralized normalization function needs to have translators 
>> for the tags of every context in the enterprise. However, if 
>> translation is done on the endpoints (i.e., within that very context 
>> that is producing the tags) those endpoints only need to support the translators appropriate for their specific context.
>> arguing that it is more natural to account for the new varieties of 
>> tags that could arise in those contexts locally (i.e., on the 
>> endpoint) rather than updating a central server every time a new context is added.
>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>>>>> 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.
>>>>>> To me, this doesn't seem
>>>>> 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.
>>>> 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
>>>>> 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
>>>> 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.
>>>>
>>>> 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
>>>> 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
>>>> Gunnar, have I misinterpreted any of your comments? Do others have 
>>>> any thoughts on this?
>>>>
>>>> Thanks,
>>>> Charles
>>>>

_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 2 Jun 2016 19:14:07 +0000

Michael,

We are in fact working on a data repository standard for security automation information in IETF MILE [1]. We are currently working on generalizing the current draft, which is focused on incident and indicator information, to allow for an extensible list of information types. This is based on a presentation I made at IETF 95 in MILE [2]. Software tag information is one of the types that we want to allow.

The value of generalizing such an approach is that vendors and end-user organizations can store SWID tags, vulnerability records, configuration checklists, and other forms of security automation data in the same data repository allowing tools to discover, search, access, and retrieve all of this information using the same mechanisms. A one-off tag repository standard is not as useful in my view, since it creates yet another new thing for a specialized purpose that vendors need to build and users need to operate.

We are developing these specifications at: https://github.com/CISecurity/ROLIE

We plan to post an interim ROLIE update based on this tomorrow; however, more work is needed to achieve our goals.

We would welcome the participation of the TagVault group in this work.

[1] https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/
[2] https://datatracker.ietf.org/doc/slides-95-mile-3/

Thanks,
Dave

> From: sacm [mailto:[email-masked]] On Behalf Of Michael Godsey
> Sent: Thursday, June 02, 2016 10:34 AM
> To: Gunnar Engelbach <[email-masked]>; Adam
> Montville <[email-masked]>; Schmidt, Charles M.
> <[email-masked]>
> Cc: [email-masked]
> Although I agree that data transformation at the end point is as far out on the
> limb as you can get (short of data creation itself being done for all formats
> needed, not likely to ever happen), I think that would be very difficult to
> expect on a good number of endpoints.   It doesn't make sense to expect
> each endpoint to have the capability to transpose from all the different
> potential formats.   Some won't have processing capability to do so, some
> won't have room on the endpoint for such a transposition service, etc.   It
> seems much more likely there would need to be an aggregator service that
> pulls from each endpoint and knows how to do the transposition.  This is
> probably the proxy you reference, though I don't think of that term in
> relation to collecting and transposing data.  But maybe the term aggregator
> doesn't resonate well with everyone either.
> 
> Re: the lossy conversion issue, I do think that a repository of tag data helps
> address this, whereby you can use a tag ID and hit up a service to retrieve the
> tag's full and original data, would be much needed.   We started discussing on
> the need for some standard for tag repository service at the NIST workshop
> on Tag implementation in April, and are creating a Tag Vault work group to
> look at addressing that.  Probably enough to say it would be out of scope for
> this SACM effort, although knowing that such a standards compliant service
> existed and covering how (conceptually anyway, at this point) various
> monitoring services could utilize such a tag repository, would be helpful to
> address I think.
> 
> Adam:  In line, I think, with what you are saying, the sooner the data is
> transformed into the common format the sooner in its lifecycle components
> can be created that make use of that data. Doing it at the endpoint (or a
> proxy acting on behalf of an endpoint) is as far out on that limb as you can
> get.
> 
> The drawback, however, is that the original tag information is not available,
> and that could represent a data loss -- or a lossy conversion, as Charles has
> been characterizing it.  I think there are ways around that, such as retaining
> enough information such that an interested party could go back and get the
> original tag, but the actual process of doing something like that would be
> outside of the scope of SACM.
> 
> > To clarify, this isn’t as much about tags as it is about the normalization of
> different tagging structures, correct?  In that case, I think that the
> normalization/translation should be happening on the endpoints or from
> within those contexts.
> >
> > So, information would go from context-specific format to normalized
> format for centralized needs (i.e. inventory assessment, reporting, what
> have you).  Then, if something needs to be done with that specific piece of
> software at the endpoint, we may need a way to get back from the
> normalized format to the context-specific format, or at least to reference
> that context-specific format distinctly.
> >
> > Thoughts?
> >
> >
> >> that is producing the tags) those endpoints only need to support the
> translators appropriate for their specific context.

---

From: Michael Godsey <[email-masked]>
Date: Thu, 2 Jun 2016 20:09:53 +0000

Thanks David, I knew there were other efforts based on some discussions in April but didn't know the specifics so this is most helpful.   I completely support the notion of a more comprehensive portal that a vendor could store related data, not just tags.   As I mentioned, tags and their file manifests is only one of the things I would think we would want to cover.   We do want to figure out how broadly to make it, while not including everything under the sun.   I think it might be broader than just security automated info, though I think that probably covers a large % of it.

Will be great to collaborate and make sure the work in Tag Vault isn't duplicate and redundant, and we can leverage rather than reinvent.  I'll chat more with you on that as we go along  :)

-----Original Message-----
From: Waltermire, David A. (Fed) [mailto:[email-masked]] 
Sent: Thursday, June 2, 2016 12:14 PM
To: Michael Godsey <[email-masked]>; Gunnar Engelbach <[email-masked]>; Adam Montville <[email-masked]>; Schmidt, Charles M. <[email-masked]>
Cc: [email-masked]
Subject: RE: [sacm] Some technical details for SWID M&A proposals

Michael,

Thanks,
Dave

> Although I agree that data transformation at the end point is as far 
> out on the limb as you can get (short of data creation itself being 
> done for all formats needed, not likely to ever happen), I think that would be very difficult to
> seems much more likely there would need to be an aggregator service 
> that pulls from each endpoint and knows how to do the transposition.  
> This is probably the proxy you reference, though I don't think of that 
> term in relation to collecting and transposing data.  But maybe the 
> term aggregator doesn't resonate well with everyone either.
> 
> Re: the lossy conversion issue, I do think that a repository of tag 
> data helps address this, whereby you can use a tag ID and hit up a service to retrieve the
> the need for some standard for tag repository service at the NIST 
> workshop on Tag implementation in April, and are creating a Tag Vault 
> work group to look at addressing that.  Probably enough to say it 
> would be out of scope for this SACM effort, although knowing that such 
> a standards compliant service existed and covering how (conceptually 
> anyway, at this point) various monitoring services could utilize such 
> a tag repository, would be helpful to address I think.
> 
> interested party could go back and get the original tag, but the 
> actual process of doing something like that would be outside of the scope of SACM.
> 
> format for centralized needs (i.e. inventory assessment, reporting, 
> what have you).  Then, if something needs to be done with that 
> specific piece of software at the endpoint, we may need a way to get 
> back from the normalized format to the context-specific format, or at 
> least to reference that context-specific format distinctly.
> >
> > Thoughts?
> >
> >
> >> On Jun 1, 2016, at 2:19 PM, Schmidt, Charles M. 
> >> <[email-masked]>
> wrote:
> >>
> >> Hi Gunnar,
> >>
> >> Thanks, as always, for the good insights. If I can paraphrase what 
> >> I think I am hearing: you are asserting that the use of certain 
> >> tags is likely to be context dependent. Specifically, certain types 
> >> of tags will primarily be used on certain OSs and/or on devices in 
> >> a certain role. A centralized normalization function needs to have 
> >> translators for the tags of every context in the enterprise. 
> >> However, if translation is done on the endpoints (i.e., within that 
> >> very context that is producing the tags) those endpoints only need 
> >> to support the
> >> Moreover, as new contexts are added to an enterprise, I think you 
> >> are arguing that it is more natural to account for the new 
> >> varieties of tags that could arise in those contexts locally (i.e., 
> >> on the
> >> endpoint) rather than updating a central server every time a new 
> >> context
> is added.
> >>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> So, yeah, your option (C) is what I would go with with (E) being 
> >>> the most palatable of any of the other options.
> >>>
> >>>
> >>> --gun
> >>>
> >>>
> >>>>>>> collector.  This will still create some limitation on the 
> >>>>>>> number of formats supportable within a SACM environment since 
> >>>>>>> it is reliant on
> >>>> the
> >>>>> 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
> >>>> That said, from an enterprise perspective I would think the set 
> >>>> of translators would be constant regardless of whether 
> >>>> translation occurred
> >>> on
> >>>> of the specified SACM forms, the appropriate translator needs to 
> >>>> be somewhere. The question is whether that somewhere should be 
> >>>> the
> >>> endpoint or
> >>>> 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
> >>>>> duplication to say the very least.  The same can be said for 
> >>>>> every other type of data
> >> being
> >>>> E) Consumer normalization. Posture Collectors collect and SWID 
> >>>> M&A transports any type or format of tags. Tags are stored on the 
> >>>> Gunnar, have I misinterpreted any of your comments? Do others 
> >>>> have any thoughts on this?
> >>>>
> >>>> Thanks,
> >>>> Charles
> >>>>
>