The average time for security teams to remediate issues is far higher than the average time to exploit (TTE) for attackers.
And while the published stats in this area leave a lot to be desired (averages have plenty to answer for) the takeaway is clear: Fixing exploitable issues quickly is always a good idea.
So, what stops you?
This can be a difficult question to answer… but we must answer it if we want to reduce our exposure window.
Headline metrics obscure the real problem
It’s easy to think of vulnerability management as a single function. Issues are reported, triaged, and resolved, and in the process, your exposure gets reduced.
But like most things, vulnerability management is really a series of interconnected processes with handoffs in-between. Multiple people are involved, and that inevitably causes delays.
But where exactly are those delays?
An overall Time to Resolve figure is a staple of any vulnerability management program. On average, how long does it take from the moment you receive a new vulnerability report to it being resolved?
This is similar to the idea of an exposure window: how long a system remains vulnerable to a known threat, starting from vulnerability disclosure (e.g., when a new CVE is published) and ending with the deployment of a patch.
Clearly, a shorter exposure window is better. But what if your exposure window isn’t as good as you’d like? “Make it faster” isn’t much of a strategy, especially if you don’t know where the holdups are.
Stages of the vulnerability management lifecycle
Your vulnerabilities go through a series of distinct stages before they're remediated. By tracking the progress of vulnerabilities through these stages, you can identify any potential bottlenecks that may be delaying remediation.
The transition between stages is a measurable interval, and each tells a story about where the process is working well (and where it isn't).
A report might sit idle for three weeks because:
- It hasn’t been acknowledged
- There’s limited capacity to triage it
- There’s a communication breakdown between your team and the hunter who reported the issue
… or for another reason altogether.
Further, just because you find the problem holding up one vulnerability, doesn’t mean that’s always the problem
Without visibility into the individual stages of the process (for each vulnerability and aggregated across your program) it’s tough to figure out where the problems really lie. And that’s why we believe it’s important to use more granular metrics.
Understanding your report lifecycle
You can track all this using YesWeHack's Report Lifecycle dashboard. It breaks the story down into its most important stages, and then provides additional granular detail.
The high-level metrics are:
- New to Under Review. How quickly a new report is acknowledged with a first response.
- New to Accepted. How long it takes from receiving a new report to it being validated as a legitimate issue.
- New to Resolved (a.k.a. Mean Time to Resolve). The end-to-end figure that captures your average remediation timeline.
Beyond these, there are more granular metrics that can help you uncover delays.
For example, Assessment to Resolved is a metric that tells our customers how long it takes them on average to remediate and close an issue after it has been evaluated and reproduced by our Triage team, and they have provided their assessment. This helps customers understand how long it takes them to act once they have full context.
New to Rewarded is an important metric for Bug Bounty customers, because it helps ensure they are providing a Hunter-friendly experience that encourages engagement.
Fix Verification shows how long it takes from requesting a post-fix verification to receiving confirmation that the fix has worked.
…and so on.
Breaking the process up into these stages helps security teams understand the why behind their MTTR figure. “We’re too slow” isn’t helpful, but “we’re losing time at these specific stages” is. For example, if New to Accepted looks healthy but reports frequently stall at Accepted to Resolved, that may be a remediation capacity issue.
The Report Lifecycle dashboard helps your team quickly identify these bottlenecks so they can make useful improvements instead of trying to fix the entire process at once.
Benchmarks provide context
Which brings us to one final question: “What does good look like?”
Naturally, this is where benchmarks come in.
The Report Lifecycle dashboard lets you see at a glance how your vulnerability management metrics compare to other organisations. This can help you understand whether each of your metrics is reasonable, or if there’s room for improvement.
Of course, there will be nuances to your process and organisation to consider. But if you’re performing dramatically better or worse than other organisations in some areas, it’s at least worth asking why. At the very least, this information can highlight areas that are worth investigating.
Direction of travel matters
A static MTTR figure is useful, but it’s not the full picture. Even with granular metrics and benchmarking data, a point-in-time snapshot can leave you jumping to the wrong conclusions.
To fix this, the Report Lifecycle dashboard makes it easy to see your direction of travel over time, both for headline and granular metrics.
Is each metric better or worse than three months ago? Did a recent process change help? Is one particular stage of the process stubbornly skewing your figures?
Tracking metrics over time will help you answer these types of questions and focus your energy where it matters most: improving those parts of the vulnerability management process that will significantly reduce your exposure window.
