We still see vulnerability assessment, vulnerability management and penetration testing products, but, as time passes, tools in this segment are acquiring other capabilities.
The field of vulnerability management continues to coalesce into some specific market segments this year. We still see vulnerability assessment, penetration testing and vulnerability management products, but, as time passes, products are acquiring other capabilities. The inevitable result is that, as with multipurpose appliances that became gateways, and then security event management (SEMs) and security information management (SIMs) and then finally security information and event management (SIEMs), we eventually will see completely integrated vulnerability management products. To be accurate, there are a few of those today. But the question that we should be asking is, "Is this really a good idea?"
We can make a pretty good case for just about any way you want to answer that question. For example, we could point to the fact that penetration testing is as much art as it is technology, and is not likely to be fully automated any time soon. Of course, we do have products that automate quite a bit of the pen-testing process. But we have to look at why we would want to automate that process in the first place. The obvious answer: To speed the production pen testing of the enterprise. The other side of that argument is that many pen testers prefer a less automated approach, even though that is not scalable in large networks.
From the perspective of external vulnerability assessment, using a cloud-based scanning service makes a lot of sense since there are ways to keep the scanners more current than by distribution of updates to end-users. Also, automating the scanning process allows security administrators to schedule frequent scans, thus keeping current with the latest known vulnerabilities.
Automating internal vulnerability scans is, on the surface, a good idea. Doing it from the cloud, of course, requires an internal box that does the scans and then ships the data out to the cloud for analysis and reporting. The danger in frequent internal scans is performance hits. A heavy vulnerability scan across a large enterprise can cause performance degradation to the point where customers complain to the IT shop. Obviously, we want to avoid that, so we need a network segmentation scheme that makes sense in the particular enterprise if we plan ongoing or frequent vulnerability scans.
There always is the argument that doing scans from the cloud provides a third party with deep details of an enterprise's vulnerabilities, leaving it open to compromise if a rogue employee from the cloud provider wants to take undue advantage. It also potentially opens up the enterprise to an attacker who successfully exploits the cloud provider.
Further, today's attackers are far more sophisticated than in the past and there is a level of anonymity in the cloud that makes chasing and catching bad guys more difficult. Providers can make this worse by not allowing access to logs on the premises. Often, these logs are commingled between all of their clients, and the other clients deserve the same privacy and security. Besides, parsing out one's problems is too big a challenge given the hundreds of terabytes of log data generated by a large scanning operation.
However, don't bite on those excuses. If a vendor does not have ways to protect a client appropriately from miscreants riding piggyback on their services, move on. But ask the questions. No fly-by-nighters need apply.
We tested these products in the most logical way: We vulnerability or pen tested them directly. The results were excellent and we got a very nice snapshot of what currently constitutes the market-leading tools for vulnerability management. Some of these we have used extensively in a production environment outside of the SC Lab. The bottom line, there are no bad ones...some are just better than others. That of course, made the job of selecting a Best Buy and Recommended product much more difficult. Enjoy!