Security Manager's Journal: A new look at vulnerability scanners

Computerworld - In my last column, I wrote about the zero-day Java exploit that was making headlines at the time. In my search for countermeasures, I discovered that my company runs many different version of Java -- and for various reasons, those different versions may be necessary for the functionality of the applications that rely on Java.

This came as some surprise, because I figured (perhaps naively) that upgrading to the latest version would be a reasonable first step in protecting against the exploit by closing the underlying vulnerability, along with all the others that have accumulated over time in older versions of the Java platform. I assumed that older applications would still work on the newest Java version. Don't they make it backward-compatible?

I don't know enough about Java to judge the answer, but the developers tell me it's not true. We have to keep our older versions around, because the newer versions will break our applications. Great. That means I have half a dozen different vulnerable platforms instead of just one.

The search for a solution to this dilemma led me to vulnerability scanners. In order to find out which of my company's servers are vulnerable to the Java exploit, I needed to discover which systems are running Java, and which versions, so I could consistently deploy the right patches. A vulnerability-scanning tool would tell me this.

I've never been a fan of vulnerability scanners before now. It always seemed to me that a scoring system based on the raw number of vulnerabilities, whether confirmed or not, wasn't really all that useful. And I never thought the resulting reports were very good at defining what needs to be done to correct the vulnerabilities. In the end, all you really get from vulnerability scanning is a lot of unactionable raw data that doesn't have much value. But I admit it's been a few years since I've looked at the state of the technology.

So I decided to take another look at vulnerability-scanning products and services. I evaluated several options, and it looks like they've improved since I last checked. The reports are still full of false positives -- about half of the results didn't apply to the operating system I tested -- but the reports are pretty decent, with some amount of actionable remediation suggestions. And they were able to identify the vulnerabilities in Java, which was the driving factor for me.

The server team members now have their hands full closing Java vulnerabilities (and others), and the desktop team is equally busy. So overall, this was a good outcome. Once those holes are closed, I'm thinking of taking another step: basing a server-hardening standard off vulnerability scans. Until now, server hardening has been done based on a checklist I wrote, which was built from a list of best practices and recommendations found on the Web. With a vulnerability scanner to find weaknesses in my company's servers, coupled with a set of configuration and system changes, I'm thinking I should be able to reduce the overall attack surface of my servers. This is basically a feedback process, iterated through scanning and remediation, and that seems to me like a better process than the blind, one-way approach in use today. And that seems like a pretty good outcome from what was originally a search for a quick fix to a high-risk vulnerability.

This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at jf.rice@engineer.com.

Join in

To join in the discussions about security, go to blogs.computerworld.com/security.

Read more about Security in Computerworld's Security Topic Center.