Remediation Performance Report

Learn all about the trends and insights in the Remediation Performance Analytics

Updated over a week ago

About Remediation Performance Analytics

This analytics page presents remediation KPIs, such as MTTR (Mean Time to Remediation), average daily remediated/introduced vulnerabilities, and campaign coverage, generating a bigger picture of the remediation workload capacity in your organization. You can filter the report to present data on all your organization or on selected Busines Groups.

Before you dive in

First, make sure you cover the Analytics Filters and Data Drilling to learn about the expected behavior of the trends and presented data.


Remediation KPIs

The Remediation KPIs are the first and main widgets you encounter when entering the Remediation Performance Analytics report.

What each KPI represents?

KPI

Description

What to strive for?

MTTR (days)

Mean Time To Remediate is an industry-standard KPI that refers to remediation progress. It represents the average time it takes to remediate vulnerabilities from when it is identified to when it is remediated.

The lower the MTTR is, the better your organization is doing regarding the time it takes to remediate vulnerabilities.

Average Daily Remediation

The daily average number of fixed vulnerability instances during the selected time.

A higher number means more vulnerability instances are being remediated.

Remediated / Introduced

The daily average number of remediated vulnerability instances is divided by the average number of newly introduced vulnerability instances during the selected time.

Strive for remediating 100%+ of the introduced vulnerability instances.

If there are 1,000 newly introduced vulnerability instances at any given day and you remediate 800 instances, your workload remediation capacity is 80% (800/100=0.8).

Campaign Coverage

The % of vulnerability instances linked to remediation campaigns out of all existing vulnerability instances.

Strive for a higher % as it means more vulnerability instances are being covered in active remediation campaigns.


Campaign Coverage over time

The campaign coverage graph shows the % of vulnerability instances linked to remediation campaigns over time by Risk Level. You should strive to have all the vulnerability instances most important to you (e.g., Critical/High) covered by remediation campaigns.

For example, if we look at the date 03/20/2022, we can tell that 40% of the Critical-risk vulnerability instances were covered in the remediation campaigns running on that date. If we look at the rest of the % division, we also learn that 29.5% of the High-risk vulnerability instances were linked to remediation campaigns on that date.

  • Click a Risk level to better highlight the trend in the graph

  • Filter to focus on specific Risk level

  • Use the data-drilling buttons to dig deeper into the data

See it in action:

Using the "Has Campaign" filter

We've also added a special filter called "Has Campaign" to help you view data only on vulnerability instances covered by campaigns. In the example below, we use the "Has Campaign" filter and the Risk Level filter to show valuable data, such as MTTR, only on Critical vulnerability instances covered by campaigns.


Average Daily Remediation by Business Group

Look at the average daily remediation by business groups and how their rank shifts (Current vs. Previous Rank). The more remediations done on vulnerability instances in a Business Group, the higher the rank climbs for that Business Group.

Let's look at the example below, assuming we've set the Period filter to compare the "Last 30 Days" with the 30 days before it:

  • The DMZ Biz Group climbed up from rank 2 to rank 1 as it's the business group with the highest avg. number of fixed vulnerability instances.

  • The Qualys Biz Group went down in 3 ranks from 1 to 3 because of a decrease in the avg. number of fixed vulnerability instances.


MTTR by Business Group

Look at your business groups with the highest MTTR (Mean Time to Remediation) and how their rank shifts (Current vs. Previous Rank).

Let's look at the example below, assuming we've set the Period filter to compare the "Last 30 Days" with the 30 days before it:

  • The WebGoat Biz Group has the highest rank (#1) as its MTTR is 934 days. In addition, its rank went drastically up apparently due to a significant unwanted increase in MTTR. In other words, the vulnerability instances in this Business Group take the most time to remediate.

  • The S3 Application Biz Group has the current best rank (#35) as its MTTR is only one day. This means that the vulnerability instances in this group get remediated the fastest.


MTTR over Time

This graph presents a straightforward trend that focuses on the shifts in MTTR over the days, within the range of the selected Period of time.

You can use the data-drilling buttons to drill up and down.


MTTR by Risk Level

Mean Time to Remediate in days per each risk level: None, Low, Medium, High, and Critical.

You should always strive for the lowest MTTR for the higher risk levels.

Tip: Click on a severity level to present more focused data across the other MTTRs.

MTTR by Risk (focused view) - Watch Video


MTTR by Asset Type

Mean Time to Remediate in days per each asset type in the Vulcan Platform: Website, Host, Code Project, Image, and Cloud Resource.

This trend indicates to you what type of assets takes the most time to remediate.


MTTR by Campaigns

Mean Time to Remediate in days of vulnerability instances that are vs. aren't covered in campaigns.

The MTTR of vulnerability instances covered in campaigns is significantly lower than those with no attached campaigns.


Remediation Workload

This graph shows a numeric trend of newly introduced vulnerability instances (i.e., newly identified by the Vulcan Platform) vs. remediated vulnerability instances. This trend offers a perspective on how much is getting done in remediation actions.

Let's look at the following data point and learn how the Remediation / Introduced KPI can be quickly calculated.

Divide the number of remediated vulnerability instances by the number of introduced vulnerability instances.
For example: 17,497 (Remediated) / 24,648 (Introduced) = 0.70... = your Workload capacity on that day was 70%.

Your security team workload capacity was less than the 100%+ goal. Keep in mind that you should always be remediating more vulnerabilities than introduced.

Following the calculation example above, if you click on the calculated data point on the Campaign Coverage graph, the Remediated / Introduced KPI should show ~70%:

On top of that, we offer you another graph that automatically calculates the Remediation Capacity Delta. Based on the example above, the delta of the same data point is -7,151. It means that there are 7,151 vulnerability instances left in a vulnerable state on that date.

Let's see it in action:


Remediated / Introduced by Risk Level

This trend shows the % of Remediated / Introduced when calculated per Risk Level. In the example below, 1200% of the introduced critical vulnerability instances get remediated. This means that the remediation capacity is mainly dedicated to fixing Critical vulnerabilities.


Remediated / Introduced by Asset Type

This trend shows the % of Remediated / Introduced when calculated per Asset Type. In the example below, 52% of the remediation capacity is carried on Code Project type of assets, and only 7% on Images.


Analytics FAQ and Data Validation

Read our Analytics FAQ and Data Validation article here.

Did this answer your question?