When designing a Software Asset Management (SAM) program, a critical decision that can make or break your program is choosing the right technology to power your process. Even the best-designed program and process will have issues if the asset management solution supporting it isn’t up to the task or misses on key parts of your requirements. It’s important to be aware of different technical limitations or gaps that the various tools have especially in relation to what you actually need them to do. In this 3-part blog series, we’ll look at three different pillars of SAM tool usage that you should use as your core requirements when evaluating SAM tools, and share some real-world best practices on how to review a SAM tool and pitfalls to avoid when evaluating an enterprise-wide solution.
Complete & Accurate Discovery
First up, let’s talk about the ‘Discovery’ portion of your solution. Your mantra should be “complete & accurate.” After all, your tool can only be as good as the data you feed it, or as they say, “garbage in, garbage out!” Complete data means that the discovery part of your tool is getting data from all of your devices and systems in your IT environment. You probably have an Active Directory implementation that is a good source of truth for your Windows servers and workstations, but what about all of your Unix and Linux devices? What about virtual host servers? Do you have any public cloud instances that need to be tracked, as cloud deployments may be scoped out of current software audits, but the software installed there is generally not free?
Some SAM tools will leverage existing Configuration Management Databases (CMDB) so if you plan to take that approach, make sure you meet with your CMDB team to understand how they approach these same issues, as many of these repositories have data quality issues and cannot be relied upon for the most up-to-date IT asset records. Some SAM tools even provide network scanning as a method to bolster the amount of data coming in. This can be a great feature, but you need to make sure you talk to your IT security team to ensure they have no issues with the discovery activity, as they can get alarmed and offended when unknown software starts crawling across the entire network! Also, partnering with your Information Security team is a leading practice so you can cross-check with your company’s anti-virus database to help strengthen your end-point data.
Just discovering devices in your environment doesn’t give you everything though, the importance of ensuring accurate and reliable data cannot be understated. On Windows, most tools will capture the information in “Programs & Features” fairly easily. But what if you have covert software that doesn’t show up there? For example, employees could be passing around “portable” versions of software that might just exist as executables in a folder on a USB stick. If your tool can’t search for executables as well as regularly installed programs, you could have a nasty surprise during a vendor audit that could be costly.
On Linux and Unix systems, this problem is even more widespread due to the open-source nature of the systems and common lack of centralized management for these environments. While software can be installed as “packages” on these systems, making it easy to read that data, it’s just as simple for an administrator to get a piece of software up and running on a test server and then start copying folders to production machines. If your SAM tool isn’t scanning file systems for these types of installations, then you could be missing large swathes of installed software and may be at risk for potential software non-compliance.
Some SAM tools can also search for SWID tags (software identification tags). These are pieces of metadata that some software vendors use to help customers find installations. They aren’t ubiquitous, so they can’t be used on their own, but they can provide another useful layer of discovery data.
Now that you’ve reviewed your discovery requirements and have considered all of the common challenges, the next blog installment will address what your SAM tool should actually do with all that data and how it should make it useful for you (i.e., data mapping) to leverage.
About the Author
Russell Lewis is a SAM professional with over 12 years of experience consulting with companies looking to improve their SAM processes and with software vendor compliance programs.