We’re in the home stretch of the Vulnerability Management Evolution research project. After talking mostly about the transition from an audit-centric tactical tool to a much more strategic platform providing security decision support, it is now time to look critically at what’s required to make the platform work in your enterprise. That means providing both built-in tools to help manage your vulnerability management program, as well as supporting integration with existing security and IT management tools.

Remember, it is very rare to have an opportunity to start fresh in a green field. So whether you select a new platform or stay with your incumbent provider, as you add functionality you’ll need to play nicely in your existing sandbox.

Managing the Vulnerability Management Program

We have been around way too long to actually believe that any tool (or toolset) can ever entirely solve any problem, so our research tends to focus around implementing programs to address problems rather than selecting products. Vulnerability management is no different, so let’s list what you need to actually manage the program internally.

First you basic information before you can attempt any kind of prioritization. That has really been the focus of the research to date. Taking tactical scans and configuration assessments of the infrastructure and application layers, then combining then with perceived asset value and the value-added technologies we discussed in the last post, and running some analytics to provide usable information. But the fun begins once you have an idea of what needs to be fixed and relative priorities.

Dashboards

Given the rate of change in today’s organizations, wading through a 200-page vulnerability report or doing manual differential comparisons of configuration files isn’t efficient or scalable. Add in cloud computing and everything is happening even faster, making automation critical to security operations. You need the ability to take information and visualize it in ways that makes sense for a variety of constituencies. You need an Executive View, providing a high-level view of current security posture and other important executive-level metrics. You need an operational view to help guide the security team on what they need to do. And you can probably use views for application-specific vulnerabilities and perhaps infrastructure and database visuals for those folks. Basically you need the flexibility to design an appropriate dashboard/interface for any staffer needing to access the platform’s information. Most vendors ship with a bunch of out-of-the-box options, but more importantly ensure they offer a user-friendly capability to easily customize the interface for what staff needs.

Workflow

Unless your IT shop is a one-man (or one-woman) band, some level of communication is required to keep everything straight. With a small enough team a daily coffee discussion might suffice. But that doesn’t scale so the vulnerability/threat management platform should include the ability to open ‘tickets’, or whatever you call them, to get work done. It certainly doesn’t need to include a full-blown trouble ticket system, but this capability comes in handy if you don’t have an existing support/help desk system. As a base level of functionality look for the ability to do simple ticket routing, approval / authorization, and indicate work has been done (close tickets). Obviously you’ll want extensive reporting on tickets and the ability to give specific staff members lists of the things they should be doing. Straightforward stuff.

Don’t forget that any program needs to have checks and balances, so an integral part of the workflow capability must be enforcement of proper separation of duties to ensure no one individual has too much control over your environment. That means proper authorization before making changes or remediating issues, and ensuring a proper audit trail for everything administrators do with the platform.

Compliance Reporting

Finally you need to substantiate your controls for the inevitable audits, which means your platform needs to generate documentation to satisfy the auditor’s appetite for information. Okay, it won’t totally satisfy the auditor (as if that were even possible) but at least provide a good perspective on what you do and how well it works, with artifacts to prove it. Since most audits break down to some kind of checklist you need to follow, having those lists enumerated in the vulnerability management platform is important and saves a bunch of time. You don’t want to be mapping reports on firewall configurations to PCI Requirement 1 – the tool should do that out of the box. Make sure whatever you choose offers the reports you need for the mandates you are subject to.

But reporting shouldn’t end when the auditor goes away. You should also use the reports to keep everyone operationally honest. That means reports showing similar information to the dashboards we outlined above. You’ll want your senior folks to get periodic reports talking about open vulnerabilities and configuration problems, newly opened attack paths, and systems that can be exploited by the pen test tool. Similarly, operational folks might get reports of their overdue tasks or efficiency reports showing how quickly they remediate their assigned vulnerabilities. Again, look for customization – everyone seems to want the information in their own format.

Dashboards and reporting are really the ying/yang of managing any security-oriented program. So make sure the platform provides the flexibility to display and disseminate information however you need it.

Enterprise Integration

As we mentioned, in today’s technology environment nothing stands alone, so when looking at this evolved vulnerability management platform, how well it integrates with what you already have is a strong consideration. But you have a lot of stuff, right? So let’s prioritize integration a bit.

• Patch/Config Management: In the value-add technologies piece, we speculated a bit on the future evolution of common platforms for vulnerability/threat and configuration/patch management. As hinted there, tight integration between these two functions is critical. You will probably hear the term vulnerability validation to describe this integration, but it basically means closing the loop between assessment and remediation. So when an issue is identified by the VM platform, the fix is made (presumably by the patch/config tool) and then the VM platform verifies that the fix was actually made correctly, eliminating the exposure. Check and balances make for happy ops and security people.
• SIEM: Another area where you will want integration is with the SIEM. The data from the vulnerability/threat platform can help supplement log events, identity, network flow, and all the other data sources collected and analyzed by the SIEM. Of course there is overlap with the analytics we have described in the evolved vulnerability management platform, but that’s not a bad thing – remember checks and balances. It’s not realistic to expect (or even want) a single point of aggregation for all security data, though you should make sure all the data ends up in the SIEM.
• Cloud Consoles: The other area of integration is the emerging cloud computing management consoles. We talked about discovering devices on a continuous basis earlier, and integration with the cloud console helps identify new instances being spun up – whether in a private or public cloud. Getting information from the cloud console doesn’t mean you don’t need to use other more traditional mechanisms to discover devices as well (trust but verify), but strategic integration offers a valuable head start. Of course the virtualization management players play API ping-pong and seem to constantly change the interfaces and integration points to maintain tighter control of the virtualization stack but that’s not your problem – it’s the vulnerability management vendor’s problem. You should expect a measure of integration with your cloud computing resources. Again, you can’t assess it if you don’t know it exists, especially in a limited visibility environment like public or private clouds.

And with that we have covered the main technology areas of the evolved vulnerability/threat management platform. But you still need to figure out whether you can or should look to a different offering or service, or whether staying put makes more sense. So we will wrap up by walking through a process to evaluate your current offering and make a fact-based determination of the best way to move forward: evolution or revolution.