Photo by Rennett Stowe
Last Friday I elaborated on the first four mistakes made by windows administrators in their collection of PC inventory. Today I conclude by jumping into more detail on numbers 5-7.
To refresh, here is the list.
Limiting inventory collection to entries in Add/Remove Programs
Excluding important registry entries
Giving them what they ‘ask for’
Limiting inventory scans to .exe files
No master baseline table to compare against
Data is static
Poor reporting
Let’s jump into number 5. If you scan for all files that are executable and do a count search on any random PC you’ll discover that the average workstation will contain well over 10,000 of these types of files. Gathering this much information will make you data rich but information poor. Make your data meaningful by comparing what you collect against what you are expecting (or what constitutes a vulnerability if performing a security scan).This is done by storing an expected baseline in a database table.
Number 6 is the static problem. This usually results when your reporting (or collection) is stored on spreadsheets. This is especially true if data is manually gathered. Be careful with this method – remember that your decisions are only as good as the data that they were based on. A good automated scanning solution writing to a relational database is the most desired method.
Ahh, number 7. This last item is perhaps the most dangerous because it impacts organizations that have the best inventory scanning solutions as well as those who only collect manually. It’s the inability to report what you have.
SQL skills are essential when you’re dealing with data stored in a relational database. I learned this years ago when I had a organization level manager ask for a report of all installed software on his computers. When I provided him the list he quickly stated that it was wrong. It was too granular (see item 3). He didn’t want to see every Microsoft hotfix listed. He also only wanted to see one entry for Microsoft Office, rather than each component (Excel, Word, Powerpoint).
In short he wanted an inventory summary rather than an installed software report, even though he specifically asked for “what was installed on his computers.” Remember, what they want and what they ask for are sometimes quite different.
SQL knowledge as well as a baseline of expected software (see item 5) would’ve done the trick. Instead of listing all the hotfixes installed I should have compared against a table listing required patches and reported the discrepencies.
On the Microsoft Office issue certain components discovered could be compared against a table to reflect the Office installation as a whole.
The frustrating outcome is that this manager concluded that we didn’t know what was installed. Even though we were scanning registries, looking for many types of executable files, and even scanning for .exe header information, without the reporting skills I wasn’t able to show what we knew. In a way he was right. I resolved to make reporting a central feature of inventory collection.
Afterall, if you can’t show someone what you know, you might as well not know it.
