This post is an answer to a LinkedIn question regarding selecting a compliance discovery tool. There is a wide range of considerations when you are interested in investing in this tool. These are only a few. For additional information, please look over The Institute's online Knowledge Brief: “Selecting & Using the Systems Discovery Tool.”
It looks to me like you are primarily concerned about compliance but it's important to recognize that the discovery tool, in and of itself, is not going to do much more than let you know what's present. The most effective discovery tools will contain a dynamic database that includes identifiers for a majority of software products. When it runs the systems, it will compare what you have loaded against its database to identify what you actually have present. This information should include, at least, the precise name of the product, version &/or release, copyright data, size of the executable file & date the executable was finalized. Part of the reason for all this is to prevent users from merely re-naming a file so that it's "hidden" from the tool (that strategy won't work with a good discovery tool). An effective discovery tool will also permit you to add legacy applications (or others not currently in the database) so that you can adjust to your specific environment. The quality of this database, as well as your ability to adjust for missing products, represent serious considerations in selecting a product.
A key element of the database also includes whether or not you can adjust the system to run specialized scans for items such as fonts, graphics, or other problem products that show up as "surprises" during audits. You should also be capable of looking for MP3s, games, &/or video files.
What you want to accomplish with the discovery tool is a baseline analysis of configurations - what's loaded. You'll then compare this baseline against your proofs of possession (licenses & etc) to determine what "should" be on the systems. From that baseline you'll eventually begin monitoring the systems to identify two factors:
- What products "should" be present but are missing
- What products do not belong but are present
In the first case, you have a need to add correctly licensed missing products. In the second, you will have identified products that may or may not be non compliant. If non compliant, they should be removed or licensed (but ensure the install dates match up with your proofs of purchase). When you monitor by exception, you significantly reduce your work load.
What all this implies is that you genuinely have all your proofs of possession under control for eventual entry into the "approved product" database. This side of the discovery tool permits you to establish what you are legally permitted to possess and it will help you reconcile against the configurations. This provides you with a snapshot of compliance status.
As to an uninstall tool: Recognize that the "built-in" uninstall tool for your operating system is not very dependable. It tends to leave elements of applications behind that "could" expose you to hidden audit issues. Depending on your size & systems environment, you can possibly acquire an open source uninstall tool. However, an effective uninstall tool is critical to to compliance assurance.
Another very important issue that Karan mentions is the entire discovery tool acquisition & implementation process. You should be able to have a discovery tool operational in less than 5 hours on a client-server network - more or less depending on the number of client systems the tool has to audit as well as the focus of your install team. Of more importance will be the amount of bandwidth the tool sucks up as it runs the systems reviews - keep it low and minimize the downtime time while it audits a device. Also keep in mind that you may want to run independent reviews of systems that are not accessed via the network - or on remote systems. This option should be considered in tool selection.
Further, is the discovery tool easily managed by a "normal" human being? I.E. a non-techie? Too many of these tools are so over-engineered that it requires an unnecessarily costly team to manage & operate the product. Be sure that any advanced clerical worker can generate & manipulate reports as well as manage the over-all system. This will drastically reduce ongoing costs.
Finally, if you are doing compliance for the sake of compliance, you are wasting money. I know that sounds wrong but, in reality, the majority of cost & risk reductions for your enterprise will be derived from effective life cycle management of both software AND hardware. Yes... You DO have to maintain compliance, but do not stop there. Usually, enterprises that stop with compliance miss out on the true value of SAM & ITAM. The core issue with this comment is that, whenever you select a discovery tool, ensure that it will also help you monitor your hardware configurations.
At the end of the day, it's important that we begin our search for "just the right tool" with a clear concept of what we want that tool to accomplish, in what environment, and with what level of internal talent. There is significantly more to this topic but, since we cover it in our online training, it's best for those who are interested to follow up with the specialized training.
Please let me know if this helps or if you need additional information!
