Overview

Analytics


About Campaign Tracking Analytics

This analytics page presents Campaign Coverage KPIs and trends, generating a bigger picture of vulnerability instances covered by campaigns and the campaign coverage workload in your organization.
This is a pre-filtered report that only shows data on vulnerabilities running campaigns.

Before you dive in

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


Campaign Tracking KPIs

The Campaign Tracking KPIs are the first and main widgets you encounter when entering the Campaign Tracking Analytics report.

Keep in mind that by default, the data in this report is pre-filtered to show info only on vulnerabilities that have running campaigns.

What each KPI represents?

KPI

Description

What to strive for?

MTTR (days)

"Mean Time To Remediate " is an industry-standard KPI used to refer to remediation progress. In this context, it represents the average time it takes to remediate vulnerability instances from when a campaign is opened to when it is remediated.

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

Campaign Coverage

The % of all vulnerability instances that are 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.

Open Campaigns

The total number of open (AKA running) campaigns

(irrelevant)

Open Actions

The total number of open tickets.

(irrelevant)

Let's put the KPI data into some context

Let's assume you have 100,000 vulnerability instances in the whole environment. Out of which, you've covered 10,000 vulnerabilities instances in one campaign targeting remediation in production environments. The campaign you opened contains 50 different Jira tickets. In this case, the data would show:

  • Campaign Coverage: 10% (10,000 out of 100,000 vulnerability instances)

  • Open Campaigns: 1

  • Open Actions: 50


Remediation Campaigns Workload and Remediation Capacity Delta

In this double graph, you can choose to view cumulative or daily numeric trends of running campaigns or vulnerability instances covered in campaigns. In other words, this double graph offers you a perspective on:

  1. How many campaigns are opened vs. how many are closed (Cumulative vs. Daily)

  2. How many vulnerability instances are introduced vs. how many are covered in campaigns (Cumulative vs. Daily)

    Note: Remember that a single campaign can cover more than one vulnerability.

  3. Your remediation capacity delta

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

In a Cumulative view on Campaigns on May 9, you had 3 open/running campaigns (un-remediated) and 2 remediated ones.
This means that the delta is -1 (2 remediated - 3 introduced = -1).

The delta here represents your workload capacity. In this case, on May 9, you had one un-remediated campaign.

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


Campaign Coverage over time

This is the same graph you have in the Remediation Performance Report.

Read about this graph here.


Open tickets by Business Groups

A bar chart of your business groups and how many open tickets (open actions) for each Business Group, including ticket status.

Note: The statuses are retrieved from the integrated "Take Action" connector (Jira, ServiceNow, etc.,). Each connector has a different set of statuses.


Open tickets by Ticket type

This trend shows the number of tickets opened for each type, depending on your configured integrations (Jira, Service Now, Email, etc.), and the ticket statuses.

Note: The statuses are retrieved from the integrated "Take Action" connector. Each connector has a different set of statuses.


% of Due Date compliant tickets by Business Group

List of Business Groups sorted by the due-date compliance in a closed ticket.


Open tickets past the due date

  • View and access ServiceNow and Jira tickets past the due date (ticket URL available).

  • A metric view of open tickets past the due date, vulnerability instances per due date, and tickets completed past the due date.


Campaign MTTR by Business Group

Look at your Campaigns by Business Groups with the highest MTTR (Mean Time to Remediation) and how their rank shifts (Current vs. Previous Rank).

Let's take a 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 Unassigned Assets Biz Group has the highest rank (#1) as its MTTR is 96 days. In addition, its rank went drastically up (from 9 to 1) apparently due to a significant unwanted increase in MTTR. In other words, the campaign-covered vulnerability instances in this Business Group take the most time to remediate.

  • The VDI Biz Group has the current best rank (#12) as its MTTR is 18 days. This means that the campaign-covered vulnerability instances in this group get remediated the fastest.


Campaign MTTR by Risk Level

This trend shows the MTTR of campaign-covered vulnerability instances by status.

For example:

27 days is the MTTR of Medium risk-level vulnerability instances. In other words, It takes around 27 days to remediate Medium risk level vulnerabilities counted from when a campaign is opened. On the other hand, it takes more time (MTTR 44) to remediate High and Critical vulnerabilities. This indicates that you need to focus on lowering the MTTR for vulnerabilities in higher risk levels.


Campaign MTTR by Asset Type

This trend indicates the MTTR of campaign-covered assets by type (Host, Image, Cloud, Website, etc.).

For example:

The MTTR of Image assets covered in campaigns is 96 days, while the MTTR of Host assets is 43 days.

Did this answer your question?