Today, I am going to switch gears a little bit regarding my blog entries, and take a look at vulnerability scanners from an end user perspective. As you are no doubt aware, there are several to choose from. Rather than pander to a specific product, I would like to keep it general and list out some of the features that I would love to see integrated into the product that may not get as much attention, but important nonetheless. I apologize in advance if $product has these features baked in. I don’t need rebuttals from vulnerability scanning companies. This is just my solo opinion, that is all.

First, if a vulnerability scanning product is putting an agent on the target, you lose. Most of the good ones I know of do not have this problem; however, in the race to improve scanning efficiency, don’t even think about it; not for a second, not for a minute. I see a tremendous opportunity for integration within the concept of vulnerability scanning. One major vendor that I am aware of has bolted on some functionality, but in my opinion, it is not the use case that I am looking for. While it is nice from a penetration testing standpoint to take the results from a scan and exploit the target; I am defensive minded. Therefore, how about an option to patch the vulnerability directly from the vulnerability scanning console? NOTE: I understand that there are times when change and config management may get in the way; but if I see a huge gaping hole on my web server and I am in a smallish shop, close the dang hole!

To take this concept one step further… Let’s look at the ‘typical’ asset definition within a vulnerability scanning system. While I agree that a vulnerability scanning system should not be the system of record for assets, wouldn’t it be cool if an upstream change to the system of record automatically popped the asset into the vulnerability scanning cycle? When combined with some rudimentary optional fields within the data source to retrieve nuances in the architecture, all of the sudden the vulnerability scanning begins getting smart. So what fields should/could be added to assist in scanning the enterprise. Most of the good ones use a concept of sites and asset groups in some flavor or variety. How about virtual vs. physical? How about Production, Dev, Test, DR, etc.? Sure, an admin with plenty of time on their hands could organize things to account for these variations; however, if there was integration with a config database, this stuff happens automatically!

Another area that I see vulnerability scanners missing on is the ability to fine tune the risk rating to account for specific conditions in the environment. If I have an IIS server serving public content (don’t laugh), versus one that is serving a collaboration site internally only, shouldn’t the risk reflect this, or at least be able to be modified? If we take the Base CVSS score for a particular vulnerability and apply a multiplier based on the role and/or location of the device, we get a much more accurate perspective on the prioritization of applying patches. Furthermore, when combined with the ability to instantly patch from the console, all of the sudden you have the ability to proactively solve the vulnerability and risk associated with it. This leads to much more flexible patching schedules as well. “Patch all internal development web servers running IIS in x location”  Bang, go. BTW… Update the config database to record the change in the configs too…

Next, the CVEs give great information on the vulnerability, and most scanners correlate that into a process that one can take to remediate the gap. Short of actually performing the patching, why not download the patch, hash it, and store it in a central location? In nearly all situations, if there are 50 database servers to patch, the handful of people tasked to do this work will either click the link in the remediation report or will navigate to the site and download the package… sometimes multiple times. This is a waste of time and effort in my opinion. Sure, the really cool kids will download it to a management server and/or common file share. Last time I checked, hashing is not immediately available on a file share, and some of the most popular software distribution applications are vendor specific.

In summary, I think that vulnerability scanners are getting better every day. Regardless of the product of choice, the most important thing to consider is scan efficiency and minimizing Type I and Type II errors. I get it. However, the market is getting increasingly crowded and performance and accuracy deltas are getting thinner and thinner. Maybe it is high time to peel away from the evolution of the anti-virus malware scanner model and look for tangible opportunities to make the products we use more intuitive and flexible to new use cases. If you are failing to make the connection between vulnerability and malware analysis, let me try to explain. Remember when anti-virus software was important? For years, emphasis was placed on scanning efficiency and minimizing errors. Because of a lack of planning, the industry, who had now become crowded, began bolting on features, bells and whistles, and simultaneously… bloat. Product differentiation should not be measured by a fancy HUD, a traffic light, font type, or any other aesthetic program. It seems that all antivirus products are within striking distance of sucking the same when it comes to Type I and Type II errors. I will save my antivirus opportunities for another time. Suffice it to say, the vulnerability scanning product market needs to continue to raise its game in the right direction.