Software ID Tags
In my research on the topic, I cant seem to find any information on the actual usage of this standard. I'm wondering if anyone can share their experience with creating, deploying, and using SWID tags, especially for internally created applications. What tools are available? What issues did you have? We would be interested in creating the tags and deploying them to the applicaitons that are already in the environment and then making tag creation and deployment part of the process moving forward.
Just looking for any information people might have from practical usage.
Do you have the same question? Follow this Question
Apr 15, 2016 - 06:22 AM
Apr 15, 2016 - 07:48 AM
1) A vast majority of your deployed software is older than the SWIDTAG structure. There's no effective way to retro-actively deploy a SWIDTAG to a software title published in 2006.. or to apply post-install SWIDTAG insert should that 2006 software be re-installed next week. Ofcourse, that could change over time as older titles go to that big trashcan in the sky.... but you'll have to wait some time.
2) SWIDTAG structures are (currently) not being adopted by a majority of the leading SW vendors. Yup, Adobe is implementing them, and Microsoft has made a token effort to deploy them, but go look for yourself on your own PC. Search for REGID or SWIDTAG FILE and see how many - or how little - SWIDTAGS are out there at the moment. Though MS & Adobe are leading the way, the other vendors are currently not following in a way that is generating industry wide recognition. If you want to see what swidtags are existing across your Windows devices, take a look at Microsoft's MAP tool; it picks up SWIDTAGS !
3) Some of the 'ends' to the means of SWIDTAGs already exist. Software title normalization and categorization has been developed and managed by many, many solution providers for quite some time. They manage and deploy 'libraries' wonderfully formatted and data-extended software from the 'primitive' inventory data. Though created independantly over time by different vendors (and AssetLabs is one of those vendors.... and Microsoft bought my previous company 'AssetMetrix' to deliver AI software recognition in SCCM) , these commerical Software 'ID' libraries are 'convergent' in their data structure such that they all tend to deliver similar values related to licensing, productivty and security issues.
All of these vendor libraries have approached the SW recognition from the perspective of decoupling the recognition from the installation 'instance' where the install is not responsible for 'declaring' what it is That is a 'top-down' model and has certain advantages that include modifiability over time independant of the install/instance.
In the SWIDTAG model, the install/instance is assumed to self-declare via a supplementary XML file that richly describes it - this is clearly a different approach. This is a 'bottom-up' model and has certain advantages including authenticity/validation via the vendor or install package operator.
That being said, keep in mind that I participate in the ISO-19770 working group that has built the SWIDTAG structure. The data structure and logic is sound, but SWDTAGs are currently a standard from an academic sense, and less so from an applied sense. Though not commercially recognized, your current requirements of creating internal SWIDTAGs may be something to consider.
Apr 15, 2016 - 08:09 AM
Apr 15, 2016 - 10:26 AM
My thought is that we could reach out to the application owners to get their inventory lists and information about their application. Then, create a tag for their app and deploy it to the devices that the app is installed on. We would then have to tell discovery to look for that file and recognize it as the application we tell it. Going forward, the tag would be part of the process to deploy a new instance or version or the application. I'm just not sure about the feasibility of this as it seems that no one has really done it.
Any thoughts? What are the options for tag creation? Do you see any issues with my thought process?
Again, thanks for the help so far!
Apr 18, 2016 - 01:52 AM
There has been a bit of confusion with SWID tags and certain vendors recently. Some seem to have adopted the approach, whilst others are not so sure. I echo the link Rory has sent you!
For in-house applications, if you are struggling with the SWID route, I would suggest creating the 'rules' around how you track installs and manage usage using whatever SAM solution you have in place. There is usually a list of executable files within the admin console that show the applications that have been identified, but have no rules or usage parameters.
I was in a similar situation to you a few years ago, and found that finding the exe file for internal applications, then creating the 'rules' regarding usage and licensing was a lot quicker and easier than the SWID route. However, we had a limited number of in-house applications so the manual process didn't take too long!
Apr 18, 2016 - 06:37 AM
Not only would you have to build an exhaustive to deploy, redeploy and delate XML tags ( because that required function would NOT be in the applications install/uninstall sequences), but you've just 'become the swidtag' by getting the data from the vendor!
Understand that - for the most part- SWID tags are not a management process; they are an extended data 'vector' to 'declare' descriptors as deemed by the SWIDTAG creator ( typically the vendor) . At the end of the day, all of the desciptor elements would have been collected by some sort of inventory tool and then inserted into a repository ( where the XML file *may* be destoyed as part of the transformation into a database). Now, you have database where you have a library of applications.... and these applications have extended 'inventory' data ( the stuff in the SWIDTAG! ).
With such a library, you could then - in theory - auto-recognize that one, single 'rogue' installation of 'Snartblat 16' that dodged your SWIDTAG efforts...because you applied a SWID tag to the other three that you found; all 4 instances of Snartblat 16' would share a common descriptor as declared by the vendor.
So, consider the option of applying the vendors descriptions directly to the 'library entry' of the application as found in the inventory database; that's where the SWIDTAG data descriptors are going to reside anyways. Same ends, different means.
Apr 18, 2016 - 07:43 AM
Apr 19, 2016 - 07:18 AM
Keep in mind, the suppliers here are internal cusomers/application ownerrs and they are internal applications. Reaching out to the "suppliers" here would be to get a list of servers that their applicaitons run on so that we could take a look at their apps. We have started to do this to a cerrtain extent already, with the goal being to create "signatures" (I think Dave calls them "rules") for the application that can then be discovered. The problem is that many of these applications do not have good signatures which is what led me down the SWID tag road. Maybe they dont have executables or are home grown implementations of COTS apps. Either way, assume that they are not easily discoverable via signature/rule/fingerprint.
I agree that it would be a large effort to deploy the tags out to the applications that are already out in the environment. However, once we got past that part, going forward, tag deployment would be part of the install/update/change process.That is my thought, anyways.
From an in house application perspective, it seems like the SWID tag would make a lot of sense but like I said, there doesnt seem to be a good way to get the tools that you would need to essentially play the supplier/vendor role in this. Lots of theroy but not much out there in practice.
Again, thanks a lot to everyone for their input and I would love to hear any other input you have on this.
Apr 20, 2016 - 11:13 AM
Let me ask WHY are you looking to add SWIDs? Is it solely to identify the homegrown applications? One alternative would to set and maintain version control and a robust Release and Deployment practice (see ITIL) with standard naming conventions which Configuration Management would help with.
If you are deadset on using SWIDs, there are commercial products out there that allow you to create installations that automagically add a SWID to the registry/filesystem. You could also teach the developpers how to manually create a SWID.... which maybe interesting for them :)
Good LUCK! And may the SWIDs be with you....