Driving Stakeholder Alignment in Vulnerability Management

“Can I get a view of where and how long we’ve had these high vulnerabilities in the environment?” is a question from the CISO that gets many security operations (SecOps) team members’ eyes twitching. 

The reason for the reaction is that despite having solid vulnerability discovery tools, reporting and management of this capability has been a weakness for this corner of the security space. Between false positives and poor historical data, the SecOps team has to do a substantial amount of work to present a clear picture of the overall performance of the vulnerability management program to key stakeholders.

Despite these issues in reporting, the key to a successful vulnerability management program is often how well SecOps teams are managing the other stakeholders in the process. The information security (InfoSec) team isn’t going to be deploying infrastructure changes and executives want to focus on how long it took to fix the issues. This leaves a decent reporting gap for the SecOps team to fill between the vulnerability scanner and those that need to care about what it finds. 

To combat this, the following are some recommended strategies for SecOps teams to bring clarity and focus to the vulnerability management process for the stakeholders that are needed to make the program successful.

IT Stakeholders: Keep the Solution—Not the Problem—Front and Center

In your mind, envision a standard vulnerability scan report. If you are seeing a bar graph with a y-axis of several vulnerabilities and an x-axis with criticality (high, medium, etc.), you are in the right ballpark of what you get out of most vulnerability scanning tools. This context is great for InfoSec teams to understand the scope of the problem and risk associated with the current environment. However, it’s the antithesis of what an IT manager needs to remediate the issue that SecOps has identified.

For large and legacy environments, the infrastructure problem comes in the fix, mainly, legacy dependencies for software programs require testing before a patch is deployed. With that in mind, a potentially stronger vulnerability report would have the solution in the x-axis and the number of total vulnerabilities (or even the number of infrastructure that need the fix) reported in the y-axis. 

This lean-in on the reporting allows the infrastructure team to use that report as their basis of remediation effort and allows them to focus on how the latest Windows patch can remediate 80% of what was found in the latest scan as well as keep them focused on what needs to be done instead of a raw vulnerability count.

Executive Stakeholders: Focus on Technical Agility as Much as Risk

A pure risk-focused discussion with the executive team around vulnerability management can be difficult for several reasons. One reason, in particular, is the priority balancing act by the executive team when they are faced with the following realities from both the IT and security teams:

• IT: An unknown impact to the business in patching certain servers, for example, a new version could impact their existing software installed
• Security: An unknown likelihood of an attack that could leverage the vulnerability

In this scenario, the executive or decision-maker can easily choose the path of inaction since “understanding the problem more” is safer politically than pushing for the required security change and causing business disruptions.

To help shift this conversation into a more proactive posture, InfoSec leadership can lean on the “digital transformation” concepts that are front and center for IT thought leaders with the same solution-focused reporting discussed in the prior section. The goal of the reporting should be to deliver two focused data points:

• Performance against vulnerability SLAs - example: (y-axis) Number of breached vulnerability SLAs vs. (x-axis) vulnerability fix/patch
• Last Updated Box Chart - example: (y-axis) Box chart for time since last update vs. (x-axis) date

The goal of both is to focus executives on what ultimately makes vulnerability management better, the time to patch/remediate issues found in the environment. With both of these focusing on performance instead of overall risk posture, the conversation can then use more standard talking points around why technical agility and IT modernization are strategically important as much as solving the more tangible InfoSec problem of reducing the potential attack surface through a known vulnerability.

Tying It All Together

There are a variety of options and strategies around improving vulnerability management reporting, including options that make reporting more relevant to the SecOps team itself. The reality is that for many SecOps teams, the effort to generate good reports is time-intensive and manual. 

If that’s the reality for your organization, regardless of the strategy you deploy on vulnerability management reporting, prioritizing the stakeholder reporting over internal reports can provide major improvements to your process. If those stakeholder reports force proactive conversations and pull in concepts being discussed by the leaders and their peers, it can lead to long-term success and buy-in from all parties involved. This buy-in can then lead to a best-in-class vulnerability management program and a stronger overall risk posture for the organization.

Learn how Risk Cloud’s Vulnerability Management Application can help your organization monitor and mitigate vulnerabilities in one centralized platform by requesting a demo or visiting us at logicgate.com.