Tech Insight: Free Versus Commercial Vulnerability Scanning Tools

Free, open-source vulnerability scanning tools are not always cheaper than their commercial counterparts

When it comes time to implement a vulnerability scanning program within your enterprise, should you be considering free and open-source tools or focusing only on commercial solutions? This question regularly comes up when security teams are faced with budgetary issues and are left wondering whether they can afford the hefty price tag that goes along with most enterprise scanning products.

The price tag is not the sole issue, however. The choice of free vs. commercial is also a highly debated topic when the realization hits that commercial scanning products are not a "set it and forget it" solution that automatically meets all of an organization's needs. This naturally causes an internal push to create a custom solution built around tools that would involve custom programming to automate the scanner, convert and feed the results into a database, email asset owners of new vulnerabilities, and interact with a ticketing system to track when issues are resolved -- not a small endeavor.

The question that management wants answered is, can they rely on free and open-source vulnerability scanning tools when the business is at stake? Can the free tools scale and integrate into existing workflow like the commercial solutions promise? What is it about commercial tools that make them any more or less effective at identifying vulnerabilities as the open-source options available?

Nothing. In fact, I have found in my work as a penetration tester that I regularly get better and more accurate results from open-source tools than I can from commercial products. Is that because the tools are better? Sometimes, but I attribute the difference based on how quickly they are updated, my knowledge of how the tools work, and my ability to modify them as needed for the particular situation –– not something I can do with the majority of the commercial security tools available.

With commercial vulnerability scanning tools, they are usually a black box, sometimes an appliance, where you push a "Scan" button in the user interface and get the results 20 minutes or hours later. Then, you move on to the task of remediating the issues that were identified. That is, unless a problem occurs. And this is where the key differentiator comes into play: technical support. Being able to pick up the phone and receive technical support is a major factor when deciding between free and commercial tool.

On the flip side, the free tools vary greatly in the amount of support available. I've seen emails and tweets to tool authors go unanswered because the tool was created as a proof-of-concept for a specific vulnerability, and the author had no desire to support it after its release. When those attempts fail, getting help might require a visit to that scary, dark area of the Internet known as IRC, where the hackers (and security tool developers) lurk and help can be found for the tool written solely for, and not touched since, the related Black Hat presentation last year.

That last paragraph paints a dark picture for free tools, but, thankfully, there are plenty of awesome security tools that receive a large amount of support from their developers and user community. The Kali Linux (formerly Backtrack Linux) is a great example of a project built around many free and open-source security tools that has extremely supportive developers and a large user base willing to help with problems. Similarly, there are projects that started with free tools and now have a mix of free and commercial offerings, like Metasploit and Burp Suite -- both with very active developers and community support available on forums, mailing lists, Twitter, and IRC.

Getting back to the issue at hand, is it safe for enterprises to rely solely on free tools for their vulnerability scanning program? The better question is whether an enterprise is willing to take on the effort to make the free tools work in their environments. The answer is usually no, not unless their security teams areoverstaffed and can afford to allocate two to five people at the initial design and implementation.

The team will need to integrate those free tools into something that is reliable and can provide actionable data so the enterprise can secure its resources and strengthen its overall security posture. But don't forget about the cost of maintaining the custom code, dealing with keeping the tools relevant, and fixing problems that may arise from upgrading as new versions of the tools get released. Oh, and there are support issues that may come up, and who wants to be the yelled at by the CIO when something breaks?

The most successful and effective vulnerability scanning programs I've encountered use a combination of commercial and free tools. The commercial tools handle most of the heavy lifting because they can track the vulnerability from initial discovery to its resolution. The free tools provide validation, possibly going as far as exploiting the issue and helping identify the true risk to the business if an attacker were to do the same.

Finally, it's important to point out that commercial vulnerability scanning solutions are not simply plug and play. They will require configuration and customization to match each enterprise environment, which may involve writing custom code to interact with the product's API for more granular control of scans or to dump results from the product's database and import them into an existing bug tracking system.

There is no easy right or wrong answer when it comes to deciding whether to use free, open-source tools or commercial solutions, but it's extremely important to realize the potential for free tools to cost more time and money because of initial implementation and ongoing maintenance.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Published: 2015-03-03Off-by-one error in the ecryptfs_decode_from_filename function in fs/ecryptfs/crypto.c in the eCryptfs subsystem in the Linux kernel before 3.18.2 allows local users to cause a denial of service (buffer overflow and system crash) or possibly gain privileges via a crafted filename.

Published: 2015-03-03** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue in customer-controlled software. Notes: none.

How can security professionals better engage with their peers, both in person and online? In this Dark Reading Radio show, we will talk to leaders at some of the security industry’s professional organizations about how security pros can get more involved – with their colleagues in the same industry, with their peers in other industries, and with the IT security community as a whole.