A plea to security auditors
When you give your customers the list of “vulnerabilities” to take up with their vendor, can you please make sure of a couple of things?
- Actually identify the security vulnerability with a reference so we don’t have to try to interpret your vague description of it (a pointer to one of the sites that reports security vulnerabilities isn’t that hard is it?)
- Verify that the system really is vulnerable. As I pointed out in an earlier blog, looking at the version label is not always enough to say that a version is vulnerable. Let alone the fact that sometimes even the best of tools get false positives.
One call I have been dealing with over the last few days identified that a customer was vulnerable to five different items. After working out what was really meant by three of them I was able to determine that they were vulnerabilities that we put patches out for back in 2003 and the customer had patches on the system that included these fixes. If the scanner software had probed the vulnerability it would have seen the product in question safe. Of the other two, “rexec” was commented out of /etc/inetd.conf and netstat -a showed nothing listening on port 512, and they actually did still have rshd running, which they needed to turn off.
Because of the vagueness of the descriptions I was given I had to spend quite some time researching three of those vulnerabilities to find exactly what they meant (not helped by how old they were).
You can probably imagine how pleased I was at having to spend time doing this research when I have other calls in my queue that really also needed attention, only to find out that it could all have been avoided.