Subject: [sacm] SWID and CPE discussion

From: [email-masked]
Date: Wed, 06 Mar 2013 17:40:38 -0600 (CST)

Adamand all:

This is what I understand.

SWID appears to be a goodsoftware licensing mechanism and not an security automation specification (or format).

SWID does not appear to talk to any of the current SCAP specifications.

If individual instances of a piece of software (operating system of application) are present in an IT-Asset, CPE will not detect which one is licensed and which one is not.

SWID would be of use with SCAP if a security scan also aims to detect unlicensed software.

NeitherCPE 2.2 nor 2.3 (or Asset Identification, AI) include a field for software licensing.

If CPE were to have an additional field for software licensing, then it would nicely fit a SWID function.

None of the current SCAP specifications does anything for software integrity, but SWID appears to do this.

If my understanding of SWID is incorrect, please help me.

David Oliva

On 03/06/13, Adam Montville<[email-masked]> wrote:

Sean, thanks for taking the time to review the draft, and I apologize for
taking so long to provide responses - hopefully what I'm saying inline
won't be a rehash.

It's clear there are a lot of issues to work through for this draft.

I'm also assuming that the AI draft is still part of SACM's proposed work
- someone let me know if this isn't true (the fourth line in the proposed
charter can be interpreted as quite inclusive).

Adam

On 1/28/13 7:20 PM, "Sean Turner" <[email-masked]> wrote:

>Hi all (these aren't directed just at Adam),
>
>I've got some comments/questions that are I guess pretty basic but also
>some questions about how the model works/fits with the information
>collected about assets that's been previously specified (or is currently
>being specified elsewhere) in the IETF. In no particular order:
>
>1) CPE: I guess it's an open question as to whether we should go with
>CPE', SWID, or do we need both because SWID is just software and CPE
>also includes hardware?

We need ways to identify the assets we want to assess. Sometimes, we'll
identify assets by class, and other times we'll identify assets very
specifically. There are three asset identification schemes at play:

1. CPE
2. SWID
3. Asset Identification (AI)

CPE can be used to identify classes of hardware, operating systems (for
endpoints and network devices), and application-level software.

SWID provides instance-level identification for software assets, but can
probably be used to identify classes of software (I'm not up-to-speed on
SWID).

AI is used for two reasons: 1) it applies to anything of value to an
organization, and 2) it provides relationships between assets. So, assets
can be information, people, facilities, IT things, and so on, and they can
be related to each other: asset A (a person) is the owner of asset B (a
critical system) and asset B is composed of the following set of assets...

I think all have their place and we should be open to leveraging what
works for the problem we're solving. Scoping assets is an important piece
of UC1 and I'd be inclined to say that we can leverage CPE and SWID in AI.

>
>a) My initial concern was that open source folks would have to pay to
>get a SWID, but it looks like tagvault.org has free memberships. I'd
>like to get that confirmed though.

I'll see what I can find out unless someone else has already done this.

>
>b) I used CPE' purposely because I think we'd need an international
>multistakeholder organization to maintain the registries because like it
>or not not everybody is going to be willing or be able to use a USG site
>to register their software/hardware. The registry could be set up as
>expert required and a pool of volunteer experts would review the
>requests. I'm just saying...

100% agree that not everyone will want to use USG. If you're suggesting
that the draft should leverage IANA for the registry, then I would not be
opposed to that. However, it's the operations that matter and I'd like to
understand more about who is willing and able to do the necessary work of
maintaining the registry for free.

>
>2) Possibly related cross area work: There's some work that's being done
>in other areas, but I asked around and there isn't one model that pulls
>it all together. But, there are data models being developed by vendors
>in other areas and I think we owe it ourselves to have a look at them
>and see what if anything is missing. It's nice if we as security
>practitioners say we want to know 1..n pieces of data about an asset,
>but if that asset isn't going to give that data up we're not going to be
>getting anywhere.

I have some additional comments inline for the options presented below,
but I also want to add that alignment is great, but at the end of the day
we need to get something working in the field. I can see a phased
approach to Asset Identification. Not suggesting that anything you've
said here precludes that option, just explicitly saying that I'd prefer to
get stuff working and add to it as things become available.

For example, Asset Identification can be largely informed by AD or other
CMDB sources. I'm not sure how many of these sources are going to be
NETMOD-/SCIM-/GEOPRIV-compliant by the time we need them to be.

>
>a) NETMOD (https://datatracker.ietf.org/wg/netmod/): NETMOD is a wg in
>the Operations and Management area that's working on data models for
>system management (draft-ietf-netmod-system-mgmt), ip management
>(draft-ietf-netmod-ip-cfg), routing management
>(draft-ietf-netmod-routing-cfg), and interfaces
>(draft-ietf-netmod-interfaces-cfg). If this proposed WG thinks it's
>going to also provide a data model for some of these same things - the
>models better be aligned. And yeah I know NETMOD uses YANG, but they've
>got data node figures and that means you don't have to read the YANG ;)

I will try to take some time to review this information before Orlando so
we can at least have a face-to-face discussion about it.

>
>b) SCIM (https://datatracker.ietf.org/wg/scim/): SCIM is a wg in the
>Applications area that's working on cross-domain identity management.
>Seems like if we're going to be using user identity data that we're
>aligned and maybe even use their schema.

Same as above, I'll take a look at this, too.

>
>c) GEOPRIV (https://datatracker.ietf.org/wg/geopriv/): GEOPRIV is a wg
>in Real-time Applications and Infrastructure Area that produced RFCs on
>both civic and geospatial data which we and NETMOD ought to be using.
>For civic addresses, the GEOPRIV WG produced the Civic Location Format
>for Presence Information Data Format Location Object (PIDF-LO)
>(RFC5139), which builds on DHCPv4/v6 Option for Civic Addresses
>Configuration Information (RFC4766) and is extended by RFC 6848*,
>there's a whole lot more in those RFCs for civic locations.** For
>geospatial (or geodetic) coordinates, there's DHCPv4/v6 Options for
>Coordinate-Based Location Configuration Information (RFC6225) and
>there's got to be some XML schema for it somewhere.

Not sure why, but this one seems more daunting - probably because I know
next to nothing about geo-anything :-) Nevertheless, will try to review
before Orlando.

>
>* Because you may need to know the pole # to which your router is
>attached.
>
>** Because you may need to know the cubicle # where your router is.
>Note: the format for civic and postal information differs from country
>to country and RFC 4776 captures some of that.
>
>3) s5.3: Maybe do the data model like this to save some trees:
>
> +-- Asset
> +-- Person
> +-- Organization
> +-- IT Asset
> +-- System
> +-- Software
> +-- Database
> +-- Network
> +-- Service
> +-- Data
> +-- Computing Device
> +-- Circuit
> +-- Website

I hate trees.

Kidding.

>
>4) Global Ids: I'm curious why there's not one identifier to rule them
>all? I get that assets can have more than one identifier depending on
>the management domain they're in (like I've got an SSN, DL, and Employee
>#), but doesn't the enterprise need one way to unique identify an asset?
> If we're looking for one might I suggest Universally Unique IDentifier
>(UUID) URN Namespace (RFC 4122), but there might be others out there.

This is likely to be important especially for trusted information sharing
efforts, if this information ever gets there. I'm not opposed to global
Ids, and in fact, I'd suspect that's how most implementations will end up
leveraging the AI specification anyway - each implementation will have
it's particular ID...

>
>5) Circuit/ai:circuit: I'm having visions of circuit-switched networks
>;) Is this describing the physical connections between two entities?

I *believe* that is the case - I'm not the original author, however, so
I'll need to rely on either others on this list who have the appropriate
history or reach back to the original author, if I can. I have been
working under the assumption that this means there's some network
connection between the two entities.

>
>6) ai:computing-device: Whole lotta questions here:
>
>a) distinguished-name/fqdn/hostname: If I were to do this, I'd have an
>element name that had subelements of the three here and the other names
>used in the document.

In person for this one is going to be best, I think. I don't want to
assume I know what you're trying to convey.

>
>b) connections: Drilling down in the subelements: I'd add references for
>the IPv4/v6, MAC, and URI formats and maybe even subnet (RFC922 maybe)*.
>Do we need to know about other types of connections usb, firewire,
>thunderbolt, etc. Finally, hasn't somebody already done the IPv4/v6/MAC
>addresses in XML with the proper constraints?

Good advice. I don't know the answer to the last question above. Anyone
else?

>
>* Something like: The syntax for IPv4 addresses described in this
>document MUST conform to [RFC791]. The syntax for IPv6 addresses
>described in this document MUST conform to [RFC3513]. The syntax for
>MAC addresses described in this document MUST conform to [802]. The
>syntax for the URIs described in this document MUST conform to
>[RFC3986]. etc.
>
>c) Additional info: After clicking on about my mac, don't you want to
>know a little more like bios/firmware version, memory, storage capacity,
>processor speed, cache size, etc.? Or do you think the information
>listed there is enough to uniquely identify the computing-device?

You raise an interesting point, but I believe the philosophy behind the
spec is to rely on synthetic Ids and a non-technical Asset Management
process to keep those synthetic Ids up-to-date.

Also, I don't think the original authors knew how to uniquely identify an
asset, given they did not offer any reconciliation algorithms (there could
be other reasons for this, of course).

>
>d) For hostname you could informatively refer to RFC 1178 for choosing
>good hostnames.

Thanks.

>
>7) ai:network: ip-net-range is there a reason you can't have more than
>one block of addresses? Right now it's just one or none. Don't we want
>to know what other networks it connects to (wait that's done later never
>mind)?
>
>8) ai:organization: also a couple here:
>
>a) There's got to be XML for email and telephone numbers with the proper
>constraints from W3C? mailto URI [RFC6068] and tel URI [RFC3966]?

Good.

>
>b) Why only website? What about my orgs twitter feed? :)

Shoot, why not just go for FOAF and call it a day? (Half serious.)

>
>c) Should stuff like DUNS # be listed here or is that synthetic-id?

DUNno...

>
>9) ai:person: a couple here too:
>
>a) email-address/telephone-number: see earlier comments. And, do we
>need an element for jabber id?

See above comment about FOAF :-)

>
>b) Way back in the day PKIX produced RFC 3739, Qualified Certificates
>Profile, which describes "a certificate whose primary purpose is to
>identify a person with a high level of assurance, where the certificate
>meets some qualification requirements defined by an applicable legal
>framework," ... blah, blah EU Directive. Basically, it stuff you'd put
>in a certificate to better identify the subject instead of being stuck
>with only the RDNs specified in RFC 5280. Stuff like placeOfBirth,
>gender, countryOfCitizenship, and countryOfResidence and not to be
>outdone it also allows for biometric data. Some of these you might want
>to use to identify a person and I'm not sure they're in SCIM or
>inetOrgPerson.

Cool. That is way back. Who uses these?

>
>10) ai:service: I think for the port # and port name you should be
>pointing to the port registry:
>https://www.iana.org/assignments/service-names-port-numbers/service-names-
>port-numbers.xml
>I think you might also need to include protocol because not all services
>available on a port are available on all protocols (tcp, udp,sctp, dccp).

Good.

>
>11) ai-system/ai-website: Where's parent defined? Isn't it asset?

I have to check.

>
>12) Energy/Power: I was surprised to not see any elements addressing
>energy/power. I'm thinking this data would be collected and if the
>temperature of my router is really, really hot I'd love to know because
>it might be one fire ;)

Does this information help ID the asset or would that be operational
information?

>That's it for now.

Only that much?

>
>spt
>
>On 9/23/12 2:49 PM, Adam Montville wrote:
>> All:
>>
>> I'm pleased to announce that I have transformed the NIST IR 7693 into an
>> RFC format and submitted it for our consideration (see post notification
>> e-mail below). Please note that this transformation is just that ¡© a
>> transformation. I have taken liberties where necessary (mainly for
>> formatting purposes), but the major points, content, and style of the
>> original document remain intact. There are sure to be issues with the
>> document as posted. For example, it is unclear to me what can and
>>cannot
>> be normatively referenced with respect to this transformation. There
>>are
>> also several areas for IANA considerations beyond registering the asset
>> identification namespace (extensions to asset types and relationships,
>> for example).
>>
>> I look forward to working these, and other, issues on this list.
>>
>> Finally, a world of thanks goes to John Wunder, Adam Halbardier, and
>>David
>> Waltermire for their effort in getting IR 7693 finalized ¡© this is
>>really
>> their work.
>>
>> Regards,
>>
>> Adam
>>
>>
>>
>> On 9/23/12 11:39 AM, "[email-masked]"
>><[email-masked]>
>> wrote:
>>
>>>
>>> A new version of I-D, draft-montville-sacm-asset-identification-00.txt
>>> has been successfully submitted by Adam W. Montville and posted to the
>>> IETF repository.
>>>
>>> Filename: draft-montville-sacm-asset-identification
>>> Revision: 00
>>> Title: Asset Identification
>>> Creation date: 2012-09-23
>>> WG ID: Individual Submission
>>> Number of pages: 73
>>> URL:
>>>
>>>http://www.ietf.org/internet-drafts/draft-montville-sacm-asset-identific
>>>at
>>> ion-00.txt
>>> Status:
>>>
>>>http://datatracker.ietf.org/doc/draft-montville-sacm-asset-identificatio
>>>n
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-montville-sacm-asset-identification-00
>>>
>>>
>>> Abstract:
>>> Asset identification plays an important role in an organization's
>>> ability to quickly correlate different sets of information about
>>> assets. This document provides the necessary constructs to uniquely
>>> identify assets based on known identifiers and/or known information
>>> about the assets. This document describes the purpose of asset
>>> identification, a data model for identifying assets, methods for
>>> identifying assets, and guidance on how to use asset identification.
>>> It also identifies a number of known use cases for asset
>>> identification.
>>>
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> sacm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>_______________________________________________
>sacm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sacm
>
>

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

---

From: Adam Montville <[email-masked]>
Date: Thu, 7 Mar 2013 00:54:53 +0000

Licensing is an important aspect, so it's good that you brought that up.  I think you've got it right.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 6, 2013 3:40 PM
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: SWID and CPE discussion

Adamand all:

David Oliva

On 03/06/13, Adam Montville<[email-masked]<mailto:[email-masked]>> wrote:

Adam

1. CPE
2. SWID

I hate trees.

Kidding.

Thanks.

Good.

DUNno...

Good.

I have to check.

Only that much?

>> On 9/23/12 11:39 AM, "[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>>>
>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

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

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 7 Mar 2013 09:28:17 -0500

David,

It is a bit premature to decide what specifications we can use for what purpose under the SACM architecture.  We still have work to do to get to a final list of requirements and a stable architecture based on consensus.  We have a good start, but more work is needed once we can get a working group established.  It’s important to not get too far ahead of this initial step.  Individual SCAP specifications like CPE need to be part of the future discussion once we work through the requirements and architecture. There has been a lot of good work outside the SCAP efforts, including other work in the IETF that we need to consider when we get to the right point.

In my mind SWID is one area that has significant merit and your characterization of SWID (ISO/IEC 19770-2) as a license management specification is not accurate. It does not directly address license management, also known as entitlement management. It provides data elements that can point to license details, but entitlement management is intended to be addressed in ISO/IEC 19770-3.  SWID in general supports software asset management including footprinting using hashes, patch management, and software identification. It also contains many of the metadata elements supported by CPE. Through work that TagVault has been pursuing, it is possible to auto generate CPEs based on the data elements provided by a SWID.  This means that the data elements that SWID addresses is a superset of what CPE addresses. This means that SWID may be used to support similar functional capabilities as those addressed by CPE.

When thinking about security automation in the area of software asset management, there are three primary questions that we need to answer.

1)      What software (operating systems, applications, and patches) is present on an endpoint?

2)      What software is authorized to be on an endpoint?

3)      What is left that is not identified and authorized?

The capabilities in SWID help us get to these answers in a more robust way than CPE ever did. We need software identifiers to address #1 and #2. Footprinting capabilities in SWID help us to identify what is actually installed. Software identifiers provided by SWID enable us to address software in a fine-grained way to develop authorization policies. Through the use of footprinting capabilities, we can eliminate what should be on an endpoint, and identify what is left which addresses #3. This narrows the amount of software that a human or tool needs to analyze to determine the presence of malicious or unauthorized software.

A side benefit of collecting SWID information from endpoints is that it can be used for both security and broader IT management capabilities. I believe this represents a core tenant of this work: using data collected from sensors to support a variety of IT related processes using a single point of data collection. This adds value to the ecosystem of tools supported by security automation standards.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 06, 2013 6:41 PM
To: [email-masked]; [email-masked]
Subject: [sacm] SWID and CPE discussion

Adamand all:

David Oliva

Adam

1. CPE
2. SWID

I hate trees.

Kidding.

Thanks.

Good.

DUNno...

Good.

I have to check.

Only that much?

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 08 Mar 2013 06:22:17 -0500

On 3/7/2013 9:28 AM, Waltermire, David A. wrote:
> In my mind SWID is one area that has significant merit and your 
> characterization of SWID (ISO/IEC 19770-2) as a license management 
> specification is not accurate. It does not directly address license 
> management, also known as entitlement management. It provides data 
> elements that can point to license details, but entitlement management 
> is intended to be addressed in ISO/IEC 19770-3.  SWID 

Hi Dave,

There are three significant obstacles
here.

First the ISO/IEC specs are not publicly
available.  -1 and -2 will set you back
about $400 to even take a peek at to
verify anything you are saying, and -3
isn't available at all.  The IETF (and
most other bodies and activities these
days) reject secret standards (as some
of the IETF T-shirts occasionally read).

Second, a global registration scheme
for all software in existence doesn't
really scale.

Third, and perhaps most importantly,
most of the major players and standards
bodies have taken other approaches,
e.g., DIDA in Rel. 11 - which CT
further blessed and tweaked in Vienna
a week ago.

best,
tony

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 8 Mar 2013 10:31:33 -0500

Tony,

Comments inline.

Thanks,
Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tony Rutkowski
> Sent: Friday, March 08, 2013 6:22 AM
> To: [email-masked]
> Subject: Re: [sacm] SWID and CPE discussion
> 
> First the ISO/IEC specs are not publicly available.  -1 and -2 will set you back
> about $400 to even take a peek at to verify anything you are saying, and -3
> isn't available at all.  The IETF (and most other bodies and activities these

The IETF references ISO standards and vice versa. Paying a fee to access the standard hardly makes it secret. The -3 standard hasn't been developed yet.  That is why you can't find it. ;-)

> for all software in existence doesn't

Tell me about it.  This is a significant challenge for us with maintaining CPE.  It's a good thing that SWID doesn't require a global registration scheme. It allows for any number of tag repositories.

> further blessed and tweaked in Vienna

I would say that ISO is a major standards body.  I have been working with the TCG and other fora that are working on capabilities based on SWID.  I know of a few major vendors that are already deploying SWIDs within their products (e.g. Microsoft, Adobe) and others that are working on it now.

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 08 Mar 2013 14:08:36 -0500

Hi Dave,

The most significant question here is whether you
are creating an open tagging scheme or not.  In
other words, is the ISO scheme only one of many
tagging methods?  If not, it's not conceivable that
you would get acceptance.

Furthermore, if you cannot provide the standard
to show everyone that you want them to accept
without paying $400 or more, you're unlikely to
get traction down that path.

Lastly, in weighing an open and free 3GPP
Rel. 11 standard that gets baked into the global
mobile infrastructure - against a virtually unused
and unknown spec out of ISO, the result seems
obvious.

--tony

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 8 Mar 2013 14:41:20 -0500

Hi,

SWID does have adoption as Dave pointed out and could scale better as it relies on vendors being responsible. As I understand it, you don't need to purchase the standard document to use it and TagVault may not be the only option.  Someone mentioned that there may be a way for opensource efforts to get a SWID for free as well (not confirmed).

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Rutkowski
Sent: Friday, March 08, 2013 2:09 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [sacm] SWID and CPE discussion

Hi Dave,

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 08 Mar 2013 15:14:06 -0500

Hi Kathleen,

The almost trivial adoption was engendered by
NIST's choice of an almost unknown standard
here in a body that it likes.  This pales in comparison
to what already exists across the industry.   While
the SACM efforts are great, this piece is definitely
in the category of surreal.

Something as fundamental as app/software
tagging deserves better than a broken 19770
based scheme being pursued simply because
somebody in the USG funded a project.  If
SACM platforms are going to succeed, they
need to have some rational accommodation of
the real world.

--tony

---

From: Shane Shaffer <[email-masked]>
Date: Fri, 8 Mar 2013 16:24:50 -0500

Tony,

To play the devil's advocate here, how does the spec you have mentioned not
fall victim to the exact same criticism? The adoption by the 3GPP is worth
noting, but that is ultimately a small portion of the greater industry
where the nature of the sector makes solving the problem relatively trivial
compared to the greater industry, thus one might be suspect of its utility
to SACM use. I don't know that an endorsement by 3GPP carries that much
weight outside that specific sector, nor does any such standard endorsement
outside of its native sector.

While that spec is something worth considering, to be successful in our
efforts we need to focus on capabilities, not which community of interest
has produced or endorsed the components that are used. All of the standards
we discuss were ultimately created somewhat reluctantly - nobody rational
will invest in creating their own standards for the sake of creating
standards, so they first look for an existing solution. In the case of CPE
no existing solution could be found, and as far as I know SWID came about
the same way, though the two had different original motivating factors. As
use cases for both matured and grew over the years they began to overlap
and roadmaps were subsequently reconsidered, but neither in current form is
likely a perfect solution. Is this 3GPP approach a better answer? Let's
take a look - can you point us in the direction of the appropriate
documentation?

Shane Shaffer
G2, Inc.
[email-masked]

On Fri, Mar 8, 2013 at 3:14 PM, Tony Rutkowski <[email-masked]> wrote:

>> SWID does have adoption as Dave pointed out and could scale better as it
>> relies on vendors being responsible. As I understand it, you don't need to
>> purchase the standard document to use it and TagVault may not be the only
>> option.  Someone mentioned that there may be a way for opensource efforts
>> to get a SWID for free as well (not confirmed).
>>
>
>
> ______________________________**_________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sacm<https://www.ietf.org/mailman/listinfo/sacm>
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 08 Mar 2013 16:27:04 -0500

It's also worth looking at whole role SWID/CPE is intended to fulfill 
within the scope of SACM.

The two roles look to be inventorying and content applicability.

In both cases the are at least two approaches:  a dictionary-backed 
system or a deterministic rule-based system.  Both devolve to a 
communicable token that is intended as an unambiguous identifier.

The problems with a dictionary backed system has already been well 
stated on these threads.

The rule-based approach is also problematic, as evidenced by the number 
of duplicate entries in the existing CPE dictionary, but does have the 
strength of being boot-strappable.  That is to say, the rules are run to 
produce the token, and the token is then available for use.  SCAP 
benchmarks use this mechanism to automatically determine applicability.

The reason the CPE dictionary has so many duplicates is that the entries 
were created, for the most part, prior to OVAL checks written for each. 
  Had the the CPE dictionary entries been created as the result of OVAL 
checks, or some other executable mechanism, there would have been little 
to no duplication, but with the side affect of having a dependency on 
that mechanism.

What I don't recall seeing mentioned in regard to a dictionary-backed 
system is what to do when a software product is not bundled with a 
trustworthy SWID or CPE (or whatever) identifier.  In that case it would 
still be necessary to fall back to a rule-based system to determine that 
identifier.

Since both approaches devolve to a need for a rule-based system, then it 
seems reasonable to start with that.  Unfortunately, that still means a 
dictionary of rule definitions, but that's what the content repositories 
are for, eh?  In any case, I don't see a scenario where this is *not* 
necessary to do.

--gun

---

From: Shane Shaffer <[email-masked]>
Date: Fri, 8 Mar 2013 17:40:25 -0500

The number of devices/apps/etc in any sector is irrelevant to a solution's
applicability to other sectors. SACM ideally would have a solution that
works for mobile, desktops, servers, virtual devices, cloud, network
devices, SCADA equipment, a smart refrigerator, your car, etc. Even if the
declared scope is currently smaller than that, we're dealing with a more
diverse problem than the mobile world. Can the 3GPP solution work
elsewhere? Let's find out, instead making assumptions one way or another.

Shane Shaffer
G2, Inc.
[email-masked]

On Fri, Mar 8, 2013 at 4:46 PM, Michael Hammer <[email-masked]

> You are kidding right?****
>
> ** **
>
> Over a billion phones?****
>
> Millions of Apps?****
>
> Links to cloud-based services?****
>
> ** **
>
> Mike****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Shane Shaffer
> *Sent:* Friday, March 08, 2013 4:25 PM
> *To:* Tony Rutkowski
> *Cc:* Moriarty, Kathleen; Waltermire, David A.; [email-masked]
>
> *Subject:* Re: [sacm] SWID and CPE discussion****
>
> ** **
>
> Tony,****
>
> ** **
>
> To play the devil's advocate here, how does the spec you have mentioned
> not fall victim to the exact same criticism? The adoption by the 3GPP is
> worth noting, but that is ultimately a small portion of the greater
> industry where the nature of the sector makes solving the problem
> relatively trivial compared to the greater industry, thus one might be
> suspect of its utility to SACM use. I don't know that an endorsement by
> 3GPP carries that much weight outside that specific sector, nor does any
> such standard endorsement outside of its native sector.****
>
> ** **
>
> documentation? ****
> ** **
> Shane Shaffer****
> G2, Inc.****
> [email-masked]  ****
>
> ** **
>
> ****
> --tony****
> On 3/8/2013 2:41 PM, Moriarty, Kathleen wrote:****
>
> to get a SWID for free as well (not confirmed).****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/sacm****
>
> ** **
>

---

From: David Solin <[email-masked]>
Date: Fri, 08 Mar 2013 17:00:55 -0600

+1 for Gunnar's entire commentary.

On 3/8/2013 3:27 PM, Gunnar Engelbach wrote:
> The rule-based approach is also problematic, as evidenced by the 
> number of duplicate entries in the existing CPE dictionary, but does 
> have the strength of being boot-strappable.  That is to say, the rules 
> are run to produce the token, and the token is then available for 
> use.  SCAP benchmarks use this mechanism to automatically determine 
> applicability.
>
> The reason the CPE dictionary has so many duplicates is that the 
> entries were created, for the most part, prior to OVAL checks written 
> for each.  Had the the CPE dictionary entries been created as the 
> result of OVAL checks, or some other executable mechanism, there would 
> have been little to no duplication, but with the side affect of having 
> a dependency on that mechanism.
>
> trustworthy SWID or CPE (or whatever) identifier.  In that case it 
> would still be necessary to fall back to a rule-based system to 
> determine that identifier.
>
> Since both approaches devolve to a need for a rule-based system, then 
> it seems reasonable to start with that.  Unfortunately, that still 
> means a dictionary of rule definitions, but that's what the content 
> repositories are for, eh?  In any case, I don't see a scenario where 
> this is *not* necessary to do.
>
>
> --gun
>
>
>
>
>
>> SWID does have adoption as Dave pointed out and could scale better as 
>> it relies on vendors being responsible. As I understand it, you don't 
>> need to purchase the standard document to use it and TagVault may not 
>> be the only option.  Someone mentioned that there may be a way for 
>> opensource efforts to get a SWID for free as well (not confirmed).
>>
>> Thanks,
>> Kathleen
>>
>>> I would say that ISO is a major standards body.  I have been working 
>>> with the TCG and other fora that are working on capabilities based 
>>> on SWID.  I know of a few major vendors that are already deploying 
>>> SWIDs within their products (e.g. Microsoft, Adobe) and others that 
>>> are working on it now.
>>>
>>>>>
>>
>>

-- 

jOVAL.org: SCAP Simplified.
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 07 Mar 2013 17:53:55 -0500

Is there some way we can look at these specifications to
assess what they do or don't do?  Apparently 19770-2
costs nearly $200 to take a peek at, and 19770-3 is not
publicly available.  I thought that the IETF eschewed
references to secret standards.

As an aside, it appears that basically no other body
dealing with this subject intends to purse SWID.

Both of these factors would seem to diminish whatever
merit SWID might have.

--tony

On 3/7/2013 9:28 AM, Waltermire, David A. wrote:
> is intended to be addressed in ISO/IEC 19770-3.  SWID in general 
> supports software asset management including footprinting using 
> hashes, patch management, and software identification. It also contains

---

From: "Steve Klos" <[email-masked]>
Date: Sun, 10 Mar 2013 20:41:13 -0700

Folks,

I've hesitated to wade into these conversations because I've regularly seen
that communications via e-mail are often not interactive enough to work
through questions/issues on why one approach v.s. another.  I will also say
that this e-mail is very long, but there's a lot in here that relevant.
I've tried to organize the thoughts into sections to help folks skip areas
that are not part of their focus.

For context, I'm the Executive Director of TagVault.org, so my opinions will
be coming from a particular perspective.  However, I'm primarily involved
with TagVault.org because the commercial companies that wanted to get this
standard rolled out into industry faster asked me to help build
TagVault.org.  I also believe strongly that software publishers should have
some method they can use to authoritatively provide identification of their
software to the tool and user community.  TagVault.org is a program under
IEEE-ISTO and has bylaws, a board of directors and a program manager who
provide oversight.  There is a membership fee to join TagVault.org and those
fees cover costs (E&O insurance, contractor costs for tool development,
costs for material development and distribution, website development, etc),
but this is not a money making effort.  There is also a strong desire to
provide additional support for open source efforts once the infrastructure
is built to support the additional influx, before that happens, there are
other ways open source providers can participate in the tagging effort.

There are numerous reasons to use an approach like SWID tags in the space of
authoritative software identification (regardless if they are being used as
part of the SCAP process or not).  The reasons vary form organization to
organization, and I will not attempt to provide all the reasons in this
e-mail as it's already too long, but I will hit on some of the themes raised
so far.

Cost to implement the standard:

Leaving aside the fact that the 19770-2 (-2) standard is something that has
a price to it - the standard could have been developed within any group, but
ISO/IEC took it on and it's easy to apply ISO (as well as some other)
standards to purchasing requirement from international bodies.  There is no
need to purchase the 19770-1 as that is related to Software Asset Management
Processes.  -2 is a data standard focused on software identification.  As
you'll read, there will also not necessarily be a need to purchase the
19770-2 standard either due to the fact that numerous tools (both commercial
and open source) provide support for tagging now, with extensions and
enhancements happening to these tools on a regular basis).

As you'll also read further in this document, TagVault.org has been working
to make the cost of the standard as immaterial to any development effort as
we possibly can - if you choose to implement on your own, you will have the
information you need freely available.  

FOSS support for the standard:

The standard also allows for and supports the concept that any organization
can make their own tags without having to do any registration or
normalization should they choose.  This allows any Free and Open Source
(FOSS) developers to access the XSD for free
(http://standards.iso.org/iso/19770/-2/2009/) and create tags as they
desire.  So everyone is aware, the TagVault.org certification document
currently going through a publication cycle is intended to be a freely
distributable document  This TagVault.org certification document is rather
weighty because it provides almost all of the context any user needs to
create a SWID tag, so if you don't want to buy the standard to get the
explicit details, you don't have to.  Once TagVault.org (in association with
the various member organizations) has developed the various tools and
services required to make this effort as automated as possible (which is
where member $'s are being focused), it is expected that this infrastructure
will support the FOSS community as well by providing additional levels of
normalization to various data values at no cost to the FOSS community.

I should point out that one of the Windows installation tools that is used
by numerous large corporations as well as some FOSS organizations is a tool
called WiX.  WiX already supports the generation and installation of SWID
tags in its current release and I would expect to see additional support
being added over time.  I you use an open source tool like WiX, or the
commercial tools like Advanced Installer or InstallShield, these tools
already create the SWID tag, so there's no need to even know the number
19770-2...

I do understand the issue some have with ISO charging for standards, but I
also recognize that there is a benefit to having an infrastructure setup to
support the standards development process (including editing and publishing
efforts).  

I very much appreciate the availability of free standards as provided by
some standards bodies, and I also recognize that if everything in the world
was free, it'd be pretty difficult for most of us to live as we would not be
making any salaries.  There's often a balance of commercial and free
materials available...

Having said that, I'll also point out that if one were to query
[ask/bing/google/<insert search engine here>] the standard, you'll likely
drop into links such as this one -
http://www.snowsoftware.com/website1/10.0.1.0/69/ISO19770-2-Final_Draft.pdf.
That link may, or may not stay up, since there are potential IP issues with
this link and this is a draft that does not have all materials complete, but
you'll get a good perspective.

Finally, TagVault.org has recognized that there is a need for the material
to be as available as possible.  The latest certification document should be
distributed in March and it has the details of all the elements in the
standard as well as the certification limitations that are expected to be
applied so the market sees normalized data coming from all publishers.  I
will send a link when this is available.

Viability of the 19770-2 standard:

Some of the reasons that -2 fits into the identification role well is
because it provides benefits to almost every eco-system member.  Further,
this is a very easy standard for commercial entities (such as Adobe, CA
Technologies, EMC, HP, IBM, iQuate, ModusLink, Microsoft, Symantec, etc) to
utilize the standard.  Some of these organizations are also part of
TagVault.org and they are working with customers to agree on a set of
minimum required data elements and normalized data values in a way that
helps tool providers with their identification efforts and end-users with a
more automated set of IT processes for software items.  By having an agreed
approach to levels of certification that are defined by the community, it
ensures a recognition, knowledge and pragmatic approach to delivering the
data that's needed to the organizations that are ultimately installing and
managing the software.

As for tool vendors that read and use the standard, there are the tier one
vendors, CA Technologies, Microsoft System Center, Symantec's Altiris, and
HP's DDMI all support the standard.  Second tier vendors are numerous with
Aspera, AssetMetrics, Eracent, Express Metrix, Flexera, Magnicomp, and
Software Management.org (and likely others that I'm not aware of) all
supporting the consumption and use of the SWID tags.

I mentioned that WiX provides SWID tag support as part of their installation
process. The two other commercial tools, Advanced Installer and
InstallShield (and the various off-shoots of those tools) all support SWID
tags to the point where everything is pretty much done for you
automatically.  In fact, I've been informed that InstallShield creates SWID
tags by default - as a publisher, you actively need to turn that feature off
if you do not want to create and install SWID tags.  This means there are
likely hundreds, if not thousands of organizations already creating tags
with the basic set of data required to conform with the ISO standard - most
of them are likely not even aware that there is a standard available to
purchase.

The way the registration/certification effort is being setup is for it to be
a federated approach.  It is expected that multiple country non-profit
organizations as well as governmental organizations (possibly including
organizations like NIST) will be involved as registration/certification
organizations over time.  Further, it's an absolute requirement that the
certification process be able to be executed locally inside the publishers
domain (very few commercial and likely no FOSS software publishers would
want a round trip transaction for a 3rd party to validate and sign a SWID
tag before they could ship a product).  To this end, the utilities being
developed by TagVault.org and others are setup as a command line utility
that can validate and sign tags in an automated manner as part of a build
process.

The 19770-2 standard also does have a community that has a set of bylaws and
requirements it must follow.  This currently does require paid membership,
but mostly because the community needs to have some resources to setup and
provide the tools and infrastructure.  I fully expect that as the community
gets to a size where it's fully self-sustaining, that the systems, processes
and working groups will support the FOSS community.  However, before that
occurs, I could see FOSS based organizations (such as RedHat and others)
getting involved earlier.  As more members join and the startup costs are
all taken care of the membership fees will drop to a point where the cost is
absolutely negligible. 

The benefit of having a community - there is a defined set of governance
applied to how rules are set.  This includes a very clear voting process on
changes and direct oversight by a board of directors and a program manager
that ensures all parties are being treated fairly and that each vote is
accounted for.

Security Automation Needs:

>From an automation perspective, there will likely be some rules based
identification that continues to be used for a period of time.  However,
organizations like Microsoft have already started to roll basic tags out in
all their new products and have indicated they will include tags for older
products as part of their patch Tuesday rollouts.  Essentially, if the
process to create tags is easily added to a build process, it can be part of
a common engineering criteria so tags can be rolled out in both new and
existing software.  Additionally, we are starting to see a great deal of
interest from organization to add tags to non-tagged software in a manner
that allows them to manage their software portfolio more actively,
effectively and most of all with more automation.

In terms of security, one set of requirements for security (of which there
are many) is to know the following:

  - Know authoritatively what software you have and who the publisher is
  - Know that the software has not been compromised
  - Be able to account for the software that you do not know

In this third category, end-user and 3rd party organizations can create
their own SWID tags for new software as it's brought in, or can add tags
after the analysis of the software with a validation that the software is
approved.  Essentially as the catalog of "publisher known" installations and
files increases, the list of unknown software decreases.  Here, there is
another ally that can be used - the NSRL database (nsrl.nist.gov).  This
group has been taking file snapshots of software for some time to support
law enforcement efforts.  Though the software titles are not always perfect
(and likely won't be in almost any case where a third party is entering the
information instead of the publisher), the NSRL DB provides a great deal of
information about commercially created software that is in the process of
being expressed through SWID tags.

Without these fundamental security considerations taken into account, issues
such as those raised in the Mandiant APT1 report and viruses such as Stuxnet
will continue to be injected into systems because they cannot be readily
ID'd.  As indicated, there are multiple facets to security and even with
tags fully implemented, there may be ways these types of payloads can be
installed on an organizations computers, but not knowing what's installed
seems to be a fundamental issue that to a large degree would seem to trump
even a question of if a software product patched...

Summary:

19770-2 SWID tags have a commercial and FOSS value for the market place.
This standard was created to assist with software compliance activities
(note - not for audits - the purpose of this standard is for companies to be
able to more effectively, automatically and inexpensively manage their
software portfolios so they don't get audited).  The standard was designed
to meet these use cases as well as security and logistics use cases as well.
In short, if a software product includes SWID tags (created by the
publisher, a 3rd party, or the software customer), it is possible to
automate many IT functions that are focused on software issues
(distribution, help desk, security, patching, retirement, etc).

Is 19770-2 perfect - nope, through the TagVault.org community, we have
already identified a number of elements that should be added to the
standard.  These are extensions in the TagVault.org documents and the
community is working on rolling back into a revision of the standard at the
moment.  Some of these additions are created to highlight why software
relationships (parent to child or child to parent) are in place (is it a
patch, feature, component, plug in, suite, etc).  Others have been added in
specifically to integrate with the CPE and SCAP infrastructure (if you have
a signed SWID tag, you can create a normalized CPE name and use that
information to search other SCAP DB's).  These efforts are driven through
the ISO/IEC, JTC1, SC7, Working Group 21 which has a close working
relationship with TagVault.org.

Does 19770-2 provide many missing data elements that are required for
automation - absolutely!  As part of an analysis of discovery/identification
tools, TagVault.org setup some virtual machines with differing software
packages installed as test devices, then setup a number of discovery tools
and tested them on some straight-forward Microsoft installations.  The test
suite was setup without any efforts to obfuscate any details about the
software (which is not always the case when software is distributed and
installed within organizations).  Running the test with 6 different tools,
there were 7 different answers (one of the tools included raw inventory and
interpreted inventory) - unfortunately, every single tool gave incorrect
answers on what was installed on the devices.  It's clear that trying to use
a rules based approach will still be needed to a degree, but as more tags
become available and as the NSRL DB expands and companies like Microsoft
start to roll tags into their patching process for older titles, these rules
based approaches will become fewer and fewer.

As I mentioned, I do have a perspective on this standard that very well may
not be consistent with everyone on this list - and that's OK.  Through
TagVault.org, we've been working with other standards bodies (both ISO and
the DMTF) to further extend the capabilities of the various standards
available in this space.  ISO's WG21 is working on an entitlements standard
that will help software buyers manage their software portfolio and DMTF is
working on standards to support the capture of usage metrics which are
required, especially in the VM and Cloud space, but also for in-house
software installations.  

I would suggest that it may make sense for us to have an open discussion on
this topic at some point.  I'd be happy to make myself available for a
webinar or conference call and can either bring some of the commercial
providers (who are willing to provide this information as part of their
build process) along on the call or not.  I'm happy to work with others to
either help educate organizations on what SWID tags are and/or to improve
the data sets available in SWID tags.  I can tell you that TagVault.org
members see this as a required capability in their products, tools or
infrastructure and something that does need to be driven in the marketplace.
To the degree we have time available, TagVault.org is happy to support these
efforts!

Cheers,

Steve Klos

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 11 Mar 2013 08:19:52 -0400

Steve et al,

Thanks for the pre-approvalcopy of
the 19770-2 specification.

It appears as if you and your 20 other
colleagues in ISO/IEC JTC1 SC7 produced
a good specification for identifying
software and you have faithfully
implemented it at TagVault as a major
registration authority.  One can also
appreciate why some parties may have
chosen to implement the provisions.

However, creating a critical dependency
between this specification in an IETF
RFC intended for widespread use for
cybersecurity purposes seems fatally
flawed, and a notion that essentially
has zero chance of being adopted by the
IETF. Scott Bradner is free to opine
here.

It is not reasonable to expect that all
of the world's software identification
would migrate to this singlespecification
and associated registration withits
global registration authorities.  Some
means must be found to accommodate the
autonomous diversity that exists in the
world, such as other standards bodies
facing this same software tagging need
have provided.

You might consider, by the way,
enhancing the success of 19770-2 use by
emulating what sister ISO/IEC JTC1 SC6
has done with respect to its "SWID"
specification, and make it apublicly-
available standard.  This wasdone for
the SC6 OID standard which wasdeveloped
to provide a similarfunctionality and
has been widely usedwithin the IETF
via the IANA PENregistry over several
decades. Those embedded in EVcerts
have especially desirable trust properties.
Additionally, a special OID arc was
allocated for cybersecurity information
exchange, including software tagging,
under ITU-T X.1500.1 and FIRST tentatively
agreed to serve as a global registry.

OIDs are one of the several SWID
mechanisms in widespread use that
needto be accommodated.

--tony

---

From: "Steve Klos" <[email-masked]>
Date: Mon, 11 Mar 2013 10:31:41 -0700

Tony,

I understand the perspective and we have been working to get the 19770-2
specification to be freely available, but as in a number of standards
bodies, there are different ways to do this and it may take some time to get
there.

A few various comments and questions for you...

Liaisons with ISO and reference of ISO standards:

I do see that IETF has Liaisons with three different sub-committees (SC2,
SC29 and SC6).  Do all of these sub-committees have freely available
standards that may be referenced by IETF, or are these Liaisons setup to
provide the integration requirements?  We are currently working through the
process to establish a Liaison with another standards body that is
referencing the -2 and future -3 standards in their work - if there is a
desire to work with the SWID tagging standard, would it make sense to
establish a Liaison between IETF and SC7 (the -2 standard is under JTC1,
SC7, WG21)?

IETF Development Efforts:

As indicated, we will continue to work towards making the -2 standard public
as it would make it easier for others to use, but it seems as if ISO's
general model is that the organizations that get utility from a standard pay
for that utility - I don't view this as right or wrong, I simply see it as
one model that's been reasonably effective (just as IETF, DMTF, W3C, etc
have different models for how they are effective).  There are likely many
different ways to move the -2 standard into the publically accessible realm,
it's more a matter of determining the best approach.  You mentioned that the
OID standard is public - do you know the process that was used to move this
into the publically available realm?

I'm looking for the bylaws that indicate the process by which the IETF works
and how voting for specifications is managed...  I have not yet found the
process for how an RFC is approved for publication, but I did find one
reference in RFC 5378 in section 3.3 on referencing other standards.  It's
clear that references to other standards bodies work is expected, but RFC
5378 does not say that a reference to a standard that is not a public
document is not allowed.  It's possible that the security world has a
different set of requirements that are applied to standards development
under the IETF charter and I can also understand that there may not be a
desire to reference a non-public standard.  Are there other reference
documents available that details what is and is not allowed within IETF
standards when it comes to the reference of non-public standards - perhaps
there are other things TagVault.org or WG21 can do within ISO to help move
this effort forward in a way that supports the IETF's effort...  Thoughts?

OID Details:

As for OID's - interesting standard, wish I'd known about it as we were
developing -2 as we would have included it in the review process for
development.  I will have to look at it a bit further, but it's possible we
can integrate OID's into the -2 standard during the revision...  The OID
does not appear to be an ID tag, but rather a unique reference id that can
be utilized to reference data about that OID - is my high-level
interpretation correct?  A bit of background for you here - 

During the development of 19770-2, we recognized that we would need a
globally unique identifier for each software release.  We also recognized
that we did not want to *require* a registration body as this could hinder
acceptance of the standard either  from the perspective of delaying the
development, or acceptance by the market.  We did recognize that a
registration organization would be beneficial (and it appears that is the
case for OID's as well).  We also did not want to use GUID's due to the fact
that they don't provide a natural "hierarchy" of relationship to the creator
of the GUID.  

Instead, we went with the iSCSI Qualified Name (iQN from RFC 3720) approach
which is completely decentralized, but results in unique names as well.  In
this case, you base the qualified name on a domain name which can only be
owned by one organization at a time.  There is a definition for how this is
applied to address any conflicts of ownership transition as well...  Since
the iQN references the entity that created the SWID tag when it was created,
you end up with a timeless reference as well as a historical reference that
could be used to identify where a software product originated from.  To
ensure that the unique ID was not confused with an iQN, the prefix was
changed to "regid"...

Back to integration options - the regid reference has been improved in the
work that's been happening with the 19770-3 WG.  Basically, it's allowed for
individuals, who may not have a domain, to create their own regid
references...  It is expected that the scope of the -2 revision that is
coming up will include an update to the regid reference to expand the
options available.  If it makes sense, we could utilize an OID option as a
regid alternative.  I'm not certain we could restrict the unique ID to only
use OID's as they require a registration authority.  With the regid process,
organizations can register their regid, or not.  This allows for open source
and individual developers to create their own SWID tags without requiring
any further "validation" from an external source.

Reference to 19770-2 in an IETF body of work:

I do understand that there may be a perspective that non-public standards
are not referenced in an IETF RFC.  However, in the case of SWID tags the
following apply:

- the XSD is publically available
- there are sample SWID tags that anyone can review and implement
- there is no requirement to register or certify a SWID tag - those products
that do register and certify will have more authoritative data that can
likely be relied on more, but it's not a requirement
- the three major installer tools for windows platforms (including one
that's open source) already create SWID tags as part of their build process
- TagVault.org is creating freely available materials to help publishers
create their SWID tags
- we could potentially integrate the OID spec into the -2 revision as one
option as a regid substitute (needs more research, but it seems like it
could be a potential option)

We are trying to remove any barriers that would block market uptake from a
standard that has so many benefits to the overall software market.  SWID
tags can be made by anyone, without any requirement of registration or
certification.  SWID tags can get increasingly more authoritative and
normalized depending on the requirements of the developer and purchaser.
There will be some customers who want to ensure that a certain level of data
is provided with the SWID tag and that the tag is normalized and carries a
digital signature, this entails a set of rules for the requirements, but
this is also the higher level of authoritative data and is not required for
all software.

I'm Interested in further discussions on this topic!

Cheers,

SK

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Monday, March 11, 2013 5:20 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sacm] SWID and CPE discussion

Steve et al,

It is not reasonable to expect that all
of the world's software identification
would migrate to this singlespecification and associated registration
withits global registration authorities.  Some means must be found to
accommodate the autonomous diversity that exists in the world, such as other
standards bodies facing this same software tagging need have provided.

under ITU-T X.1500.1 and FIRST tentatively agreed to serve as a global
registry.

--tony

On 3/10/2013 11:41 PM, Steve Klos wrote:
> Folks,
>
> I've hesitated to wade into these conversations because I've regularly 
> seen that communications via e-mail are often not interactive enough 
> to work through questions/issues on why one approach v.s. another.  I 
> will also say that this e-mail is very long, but there's a lot in here
that relevant.
> I've tried to organize the thoughts into sections to help folks skip 
> areas that are not part of their focus.
>
> For context, I'm the Executive Director of TagVault.org, so my 
> opinions will be coming from a particular perspective.  However, I'm 
> primarily involved with TagVault.org because the commercial companies 
> that wanted to get this standard rolled out into industry faster asked 
> me to help build TagVault.org.  I also believe strongly that software 
> publishers should have some method they can use to authoritatively 
> provide identification of their software to the tool and user 
> community.  TagVault.org is a program under IEEE-ISTO and has bylaws, 
> a board of directors and a program manager who provide oversight.  
> There is a membership fee to join TagVault.org and those fees cover 
> costs (E&O insurance, contractor costs for tool development, costs for 
> material development and distribution, website development, etc), but 
> this is not a money making effort.  There is also a strong desire to 
> provide additional support for open source efforts once the 
> infrastructure is built to support the additional influx, before that
happens, there are other ways open source providers can participate in the
tagging effort.
>
> There are numerous reasons to use an approach like SWID tags in the 
> space of authoritative software identification (regardless if they are 
> being used as part of the SCAP process or not).  The reasons vary form 
> organization to organization, and I will not attempt to provide all 
> the reasons in this e-mail as it's already too long, but I will hit on 
> some of the themes raised so far.
>
> Leaving aside the fact that the 19770-2 (-2) standard is something 
> that has a price to it - the standard could have been developed within 
> any group, but ISO/IEC took it on and it's easy to apply ISO (as well 
> as some other) standards to purchasing requirement from international 
> bodies.  There is no need to purchase the 19770-1 as that is related 
> to Software Asset Management Processes.  -2 is a data standard focused 
> on software identification.  As you'll read, there will also not 
> necessarily be a need to purchase the
> 19770-2 standard either due to the fact that numerous tools (both 
> commercial and open source) provide support for tagging now, with 
> extensions and enhancements happening to these tools on a regular basis).
>
> As you'll also read further in this document, TagVault.org has been 
> working to make the cost of the standard as immaterial to any 
> development effort as we possibly can - if you choose to implement on 
> your own, you will have the information you need freely available.
>
> The standard also allows for and supports the concept that any 
> organization can make their own tags without having to do any 
> registration or normalization should they choose.  This allows any 
> Free and Open Source
> distributable document  This TagVault.org certification document is 
> rather weighty because it provides almost all of the context any user 
> needs to create a SWID tag, so if you don't want to buy the standard 
> to get the explicit details, you don't have to.  Once TagVault.org (in 
> association with the various member organizations) has developed the 
> various tools and services required to make this effort as automated 
> as possible (which is where member $'s are being focused), it is 
> expected that this infrastructure will support the FOSS community as 
> well by providing additional levels of normalization to various data
values at no cost to the FOSS community.
>
> I should point out that one of the Windows installation tools that is 
> used by numerous large corporations as well as some FOSS organizations 
> is a tool called WiX.  WiX already supports the generation and 
> installation of SWID tags in its current release and I would expect to 
> see additional support being added over time.  I you use an open 
> source tool like WiX, or the commercial tools like Advanced Installer 
> or InstallShield, these tools already create the SWID tag, so there's 
> no need to even know the number 19770-2...
>
> I do understand the issue some have with ISO charging for standards, 
> but I also recognize that there is a benefit to having an 
> infrastructure setup to support the standards development process 
> (including editing and publishing efforts).
>
> I very much appreciate the availability of free standards as provided 
> by some standards bodies, and I also recognize that if everything in 
> the world was free, it'd be pretty difficult for most of us to live as 
> we would not be making any salaries.  There's often a balance of 
> commercial and free materials available...
>
> [ask/bing/google/<insert search engine here>] the standard, you'll 
> likely drop into links such as this one - 
>
> That link may, or may not stay up, since there are potential IP issues 
> with this link and this is a draft that does not have all materials 
> complete, but you'll get a good perspective.
>
> Finally, TagVault.org has recognized that there is a need for the 
> material to be as available as possible.  The latest certification 
> document should be distributed in March and it has the details of all 
> the elements in the standard as well as the certification limitations 
> that are expected to be applied so the market sees normalized data 
> coming from all publishers.  I will send a link when this is available.
>
> because it provides benefits to almost every eco-system member.  
> Further, this is a very easy standard for commercial entities (such as 
> Adobe, CA Technologies, EMC, HP, IBM, iQuate, ModusLink, Microsoft, 
> Symantec, etc) to utilize the standard.  Some of these organizations 
> are also part of TagVault.org and they are working with customers to 
> agree on a set of minimum required data elements and normalized data 
> values in a way that helps tool providers with their identification 
> efforts and end-users with a more automated set of IT processes for 
> software items.  By having an agreed approach to levels of 
> certification that are defined by the community, it ensures a 
> recognition, knowledge and pragmatic approach to delivering the data 
> that's needed to the organizations that are ultimately installing and
managing the software.
>
> As for tool vendors that read and use the standard, there are the tier 
> one vendors, CA Technologies, Microsoft System Center, Symantec's 
> Altiris, and HP's DDMI all support the standard.  Second tier vendors 
> are numerous with Aspera, AssetMetrics, Eracent, Express Metrix, 
> Flexera, Magnicomp, and Software Management.org (and likely others 
> that I'm not aware of) all supporting the consumption and use of the SWID
tags.
>
> I mentioned that WiX provides SWID tag support as part of their 
> installation process. The two other commercial tools, Advanced 
> Installer and InstallShield (and the various off-shoots of those 
> tools) all support SWID tags to the point where everything is pretty 
> much done for you automatically.  In fact, I've been informed that 
> InstallShield creates SWID tags by default - as a publisher, you 
> actively need to turn that feature off if you do not want to create 
> and install SWID tags.  This means there are likely hundreds, if not 
> thousands of organizations already creating tags with the basic set of 
> data required to conform with the ISO standard - most of them are 
> likely not even aware that there is a standard available to purchase.
>
> The way the registration/certification effort is being setup is for it 
> to be a federated approach.  It is expected that multiple country 
> non-profit organizations as well as governmental organizations 
> (possibly including organizations like NIST) will be involved as 
> registration/certification organizations over time.  Further, it's an 
> absolute requirement that the certification process be able to be 
> executed locally inside the publishers domain (very few commercial and 
> likely no FOSS software publishers would want a round trip transaction 
> for a 3rd party to validate and sign a SWID tag before they could ship 
> a product).  To this end, the utilities being developed by 
> TagVault.org and others are setup as a command line utility that can 
> validate and sign tags in an automated manner as part of a build process.
>
> The 19770-2 standard also does have a community that has a set of 
> bylaws and requirements it must follow.  This currently does require 
> paid membership, but mostly because the community needs to have some 
> resources to setup and provide the tools and infrastructure.  I fully 
> expect that as the community gets to a size where it's fully 
> self-sustaining, that the systems, processes and working groups will 
> support the FOSS community.  However, before that occurs, I could see 
> FOSS based organizations (such as RedHat and others) getting involved 
> earlier.  As more members join and the startup costs are all taken 
> care of the membership fees will drop to a point where the cost is
absolutely negligible.
>
> The benefit of having a community - there is a defined set of 
> governance applied to how rules are set.  This includes a very clear 
> voting process on changes and direct oversight by a board of directors 
> and a program manager that ensures all parties are being treated 
> fairly and that each vote is accounted for.
>
> identification that continues to be used for a period of time.  
> However, organizations like Microsoft have already started to roll 
> basic tags out in all their new products and have indicated they will 
> include tags for older products as part of their patch Tuesday 
> rollouts.  Essentially, if the process to create tags is easily added 
> to a build process, it can be part of a common engineering criteria so 
> tags can be rolled out in both new and existing software.  
> Additionally, we are starting to see a great deal of interest from 
> organization to add tags to non-tagged software in a manner that 
> allows them to manage their software portfolio more actively, effectively
and most of all with more automation.
>
> In terms of security, one set of requirements for security (of which 
> there are many) is to know the following:
>
> In this third category, end-user and 3rd party organizations can 
> create their own SWID tags for new software as it's brought in, or can 
> add tags after the analysis of the software with a validation that the 
> software is approved.  Essentially as the catalog of "publisher known" 
> installations and files increases, the list of unknown software 
> decreases.  Here, there is another ally that can be used - the NSRL 
> database (nsrl.nist.gov).  This group has been taking file snapshots 
> of software for some time to support law enforcement efforts.  Though 
> the software titles are not always perfect (and likely won't be in 
> almost any case where a third party is entering the information 
> instead of the publisher), the NSRL DB provides a great deal of 
>
> Without these fundamental security considerations taken into account, 
> issues such as those raised in the Mandiant APT1 report and viruses 
> such as Stuxnet will continue to be injected into systems because they 
> cannot be readily ID'd.  As indicated, there are multiple facets to 
> security and even with tags fully implemented, there may be ways these 
> types of payloads can be installed on an organizations computers, but 
> not knowing what's installed seems to be a fundamental issue that to a 
> large degree would seem to trump even a question of if a software product
patched...
> This standard was created to assist with software compliance 
> activities (note - not for audits - the purpose of this standard is 
> for companies to be able to more effectively, automatically and 
> inexpensively manage their software portfolios so they don't get 
> audited).  The standard was designed to meet these use cases as well as
security and logistics use cases as well.
> community is working on rolling back into a revision of the standard 
> at the moment.  Some of these additions are created to highlight why 
> software relationships (parent to child or child to parent) are in 
> place (is it a patch, feature, component, plug in, suite, etc).  
> Others have been added in specifically to integrate with the CPE and 
> SCAP infrastructure (if you have a signed SWID tag, you can create a 
> normalized CPE name and use that information to search other SCAP 
> DB's).  These efforts are driven through the ISO/IEC, JTC1, SC7, 
> Working Group 21 which has a close working relationship with TagVault.org.
>
> automation - absolutely!  As part of an analysis of 
> discovery/identification tools, TagVault.org setup some virtual 
> machines with differing software packages installed as test devices, 
> then setup a number of discovery tools and tested them on some 
> straight-forward Microsoft installations.  The test suite was setup 
> without any efforts to obfuscate any details about the software (which 
> is not always the case when software is distributed and installed 
> within organizations).  Running the test with 6 different tools, there 
> were 7 different answers (one of the tools included raw inventory and 
> interpreted inventory) - unfortunately, every single tool gave 
> incorrect answers on what was installed on the devices.  It's clear 
> that trying to use a rules based approach will still be needed to a 
> degree, but as more tags become available and as the NSRL DB expands 
> and companies like Microsoft start to roll tags into their patching
process for older titles, these rules based approaches will become fewer and
fewer.
>
> As I mentioned, I do have a perspective on this standard that very 
> well may not be consistent with everyone on this list - and that's OK.  
> Through TagVault.org, we've been working with other standards bodies 
> (both ISO and the DMTF) to further extend the capabilities of the 
> various standards available in this space.  ISO's WG21 is working on 
> an entitlements standard that will help software buyers manage their 
> software portfolio and DMTF is working on standards to support the 
> capture of usage metrics which are required, especially in the VM and 
> Cloud space, but also for in-house software installations.
>
> I would suggest that it may make sense for us to have an open 
> discussion on this topic at some point.  I'd be happy to make myself 
> available for a webinar or conference call and can either bring some 
> of the commercial providers (who are willing to provide this 
> information as part of their build process) along on the call or not.  
> I'm happy to work with others to either help educate organizations on 
> what SWID tags are and/or to improve the data sets available in SWID 
> tags.  I can tell you that TagVault.org members see this as a required 
> capability in their products, tools or infrastructure and something that
does need to be driven in the marketplace.
> To the degree we have time available, TagVault.org is happy to support 
> these efforts!
>
> Cheers,
>
> Steve Klos
>