Putting the “Management” Back Into “Vulnerability Management”

One of the most frustrating parts of external penetration testing was coming back the next year and finding the same vulnerabilities. When you look at the remediation plan you gave them, it looks like it took nine months just to figure out who was responsible for each of the problems. The other three months seem to have been spent on rationalizing why a critical vulnerability shouldn’t be resolved until after the next big upgrade, with a few minor patches being applied just to get the numbers to drop. Yet somehow, your client is astounded when you have domain admin creds by noon on the first day.

The worst part is that this isn’t limited to the findings of external consultants. Year after year, I come into organizations who have embraced the need for Vulnerability Management. SCAN ALL THE THINGS! GATHER ALL THE DATA! The metrics show you must be succeeding, because 100% of your enterprise is being scanned every month and you have an independent penetration test performed once a year. We lose sight of the “Management” part of Vulnerability Management and stop at Vulnerability Identification.

Knowing might be half the battle, but the war is won with actions. A truly successful Vulnerability Management program must have a function in place to see vulnerabilities through to remediation. Of course, the actual remediation activities almost always take place within various IT engineering teams, which means that in order to succeed, you have to drive cross-functional work streams. Taking accountability for overall security posture while simultaneously farming it out to individual business units is difficult, but it’s not impossible. Here are some simple steps to drive and measure a successful Vulnerability Management program.

1. Know how your organization is structured.

Are functional IT groups responsible for all systems by platform? Does each application have an assigned IT owner? You have to know who is responsible for which layer of the stack before you can start delegating.

For internal vulnerability management, set up reporting within your scanner to do some of this delegation for you. If you know that an IP block corresponds with a specific application, assign these addresses to logical groups. The more information you can assign statically, the less work you’ll have down the line.

2. Notify the proper teams.

If you’ve discovered a XSRF vulnerability within a web page, you’re unlikely to make much traction with the Unix team that maintains their servers. Within your reporting, start by sorting results by server platform. Then, while performing analysis on the results and eliminating false positives or allowable configuration items, sort the results further by the teams you previously identified.

Ultimately, you should have several reports tailored for each specific group. For example, all of the Windows items pertaining to patching and configuration may be consolidated into a single report for that team, but this report wouldn’t have database or application vulnerabilities. The application layer vulnerabilities would be similarly grouped according to which developers were responsible for each application. If applications share development teams, group those together for the fastest response.

3. Hold teams accountable.

A vulnerability management policy is essential to your success here, along with the organizational divisions you identified earlier. If your policy on critical security vulnerabilities states remediation should occur within 30 days, run a report on critical vulnerabilities over 30 days old, grouped by division of accountability. Do the same for all vulnerabilities, by division, older than 30, 60, 90, 180, and 365 days.

Use these in report-outs to leadership to show where teams are consistently failing to meet remediation obligations. While the business owner might not understand what each of these vulnerabilities means individually, they must be held accountable for the risks they are introducing.

4. Work on the bigger picture.

Delegating responsibility for individual vulnerabilities still only resolves the immediate problem. Go back and look at all vulnerabilities for the month and identify trends. Are you seeing that OS patches are being applied, but third-party applications are being missed? Perhaps there is a single cluster of systems that are consistently being missed in patching or configuration updates. Maybe there has been a high number of SQL injection flaws in applications. These are all symptoms of a bigger problem.

Work with divisional teams to reduce vulnerabilities proactively. Evangelize the need for baseline configurations for systems and standard patch windows. Train developers on preventing and identifying security errors earlier in the development lifecycle. While “total number of vulnerabilities” type metrics are generally bad for showing an improved security posture due to the unpredictable number of new vulnerabilities, you may see improvement in “vulnerabilities by type” through earlier security involvement.

5. Follow through with support.

Last but certainly not least, make sure your business partners know that you’re there to help them. Help find workarounds and mitigations for critical vulnerabilities that don’t have a patch available. Show developers how to reproduce an attack so that they can test their fix. Ensure those responsible for fixing the vulnerability understand how an attack would be executed, as they may have a workaround that resolves the problem when the proposed solution impedes business operations. Be a partner to your business units and they will work with you to drive security throughout the organization.