Software Discovery Tool Analysis

Identifying which software products are installed on a computing device is similar to an archeological dig (i.e. trying to determine which software titles are installed based on various artifacts discovered on the device) and regularly results in incomplete and incorrect results. Unfortunately, compliance, logistics and security processes and procedures rely on this discovery data to manage an organization’s infrastructure.

Incorrect data from software discovery utilities can and does result in:

• Higher risk of being out of compliance with software entitlements, which can lead to audit costs and further costs from the audit’s outcomes.
   
• Higher risk of malicious, out-of-date or non-patched software being installed and used within the organization, with the associated potential for loss of data or intellectual property, or higher IT costs.
   

• Higher cost of specialized technical resources required to constantly create, monitor and update discovery procedures.
   
• Higher switching costs for discovery tools due to complexities and incompatibilities between tools.

There are many tools on the market that provide discovery capabilities with varying degrees of success depending on the platform, publisher and third party tools used. This paper reviews six mainstream discovery and identification tools and provides criteria to consider when selecting a tool.

It’s important to know that the risks arising from incorrect software identification lie with the organization using the tool, not the tool provider. This means that any tool (or tools) an organization selects must use the most accurate information available – preferably information that comes directly from the software publisher. Unfortunately, there are too many publishers and tool providers for each to set up their own communication with every software publisher, and vice versa.

When it comes to larger organizations, software identification becomes even more difficult and expensive to manage. Most large organizations have multiple software discovery tools. These can be found in desktop management systems, help desk utilities, patch management tools, and software asset management tools. It is a good practice to be able to reconcile the data collected from these various tools to create a “single source of truth” about what is installed on the organization’s computing devices, but the reality is that if the data from each of the tools is not provided in the same way, it is costly to consolidate this data into a normalized set of discovery data. This means that the reconciliation rarely happens, with the prime exception being during an external audit when it is beneficial for the auditor to provide additional justification for the final audit report. Even then, these reconciliation procedures often need to make use of pragmatic and industry-accepted estimates due to the cost and complexity of doing a complete reconciliation between data sets from different tools.

There is a better way that lowers costs for both the publisher and the buyer of software! ISO/IEC has published a software identification standard (19770-2) and TagVault.org is a non-profit program designed to make implementation of the standard and data consistency as easy and inexpensive as possible.

Read about the problems discovered through a live test of some these tools in this paper, then contact your software publishers and tool providers and require them to provide and support software identification (SWID) tags.

Some helpful reference documents you may find useful after reading this whitepaper include:

• Include SWID support in RFPs
   
• Require SWID through contract language