How SCAP Brought Sanity to Vulnerability Management

CSO - It's safe to say that vulnerability assessment tools have become commonplace within most security teams' toolboxes. As security programs mature, they often begin to look at ways to automate tasks that are mundane and repetitive. [Related: How to Handle Security Patches With Sanity]

These applications have become better at identifying common mistakes within Web applications, patch management, configurations, systems and database hardening.

But with the proliferation of vulnerability assessment products and services, we have begun to create a different problem. [Related: The Failure of Security Investments]

Any organization that maintains a reasonably sized infrastructure or Web presence can easily end up with many different applications, services and tools to maintain and monitor their vulnerabilities. These tools include V.A. scanners to identify security bugs within applications, databases, hosts and networks.

Vulnerability management programs may also employ software-as-a-service (SaaS) solutions to assist in vulnerability identification through both automated tools and manual testing.

Static source code analysis tools add to the internal store of vulnerabilities. Want more data? How about adding the results of your penetration tests?

This vulnerability data may include Web application vulnerabilities -- technical vulnerabilities missed by VA scanners, social engineering exploits through a lack of processes or awareness and logic flaws.

A Mountain of DataAs we begin to find out, in some cases, maturity can bring complexity and more data! But more data is just the tip of the iceberg. How does a CISO connect all of this data? How does management understand what issues and bugs should be prioritized when conducting remediation?

Once prioritized, how do we then migrate these bugs to our bug -- tracking, change -- management and trouble ticketing systems?

Your problem is not only managing the mountain of data you're sitting on, it now includes managing all of this data described in different ways -- managing vulnerability assessment reports that contain overlapping bugs or false positives. Identifying your bugs and problems are no longer the primary issues. You now have to do something about them.

In order to get these vulnerabilities closed, the security teams need to start sorting and moving this data around and getting the appropriate issues in front of management, developers and engineers.

You've taken the step to add more tools to your management arsenal to eliminate the mundane and repeatable tasks only to have your team stuck with enough mundane and repeatable tasks to occupy a small army of security professionals!

So when taking on this problem, I set out with six basic requirements:

• Schema normalization: All vulnerability data needs to be described in the same manner to compare apples to apples across host, network, application and database vulnerabilities.
• Use existing standards (where possible): Don't reinvent the wheel.
• Connect the data: If we don't do this, we're not solving the problem! The primary purpose of our solution is to eliminate these silos of data, reporting and tracking.
• Define our metrics: I thought this might be one of the easier requirements; after all, we already have some vulnerability metrics as part of our current program. Lo and behold, as I drilled deeper into this, I discovered once this data is tied together it gives us additional views and metrics to track and measure our success.
• Useful reporting: Once I have centralized, normalized and correlated this data, I have the ability to crack open the database and sort this any way I see fit.
• Keep it simple: Enough said. [Related: A New Hope for Software Security?]