Cybersecurity Metrics: Purpose Drives Measurements

Measuring your information and cybersecurity program can be difficult. But when a metrics program is developed using the right measurements from the right sources, it can provide incredible value insights into your program, reveal weak areas, market your strengths, and drive investment and budget. 

So what are the right measurements? 

Purpose Drives Measurements

It depends on the purpose of the metrics program. Too often cybersecurity metrics are collected and reported on just for the purpose of reporting. The result is a report with an overwhelming amount of numbers and information. The data doesn’t tell a story, other than the team is doing a lot of ‘stuff’. 

From my experience, the purpose and goal of a good cybersecurity metrics program can be identified into one of three buckets:

1. Cybersecurity initiatives – the progress of existing initiatives, and the evidence justifying future initiatives. 
2. Risk Ownership – Showing the data and risk drivers that support visibility on how the distributed teams are handing and addressing risk. 
3. Team Tuning – How well the security tools are being used, and how equipped the team is with the right training and skills. 

IF you can identify one of those purposes, then you can pivot and start identifying all the data that can be measured to support those goals. 

Supporting Layers

Without a goal in mind, you will be reporting on the number of firewall blocks, antivirus alerts, and threat intelligence feeds digested. These numbers don’t support anything without context. They are what I call ‘single-layer’ metrics. 

Instead, build a ‘multi-layer’ metrics program where the data supports the support programs, and the program sources support the purpose of the metric. For example, if the purpose is to track cybersecurity initiatives a case might show:

Last year we had eight endpoints compromised due to unique phishing attempts. Our goal this is year is to reduce endpoint compromise due to email phishing. 

Metrics:

• How many emails do we get a day?
  Do we have perimeter email security solution, how well is it operationalized (updates, effectiveness)?
• How many users do we have in the environment? 
• How many of these users are included in the scope of this initiative (contractors too? Vendors?)
• Confidence our current user awareness training equips users to identify and report these threats?
• Percentage of users successfully completed users awareness training?
• Percentage of users failed training, or didn’t take the training?
• Percentage of users tied to compromised machine incidents? 
• Percentage of users that have administrative rights on their endpoint?
• Number of endpoints participating in the patch management program?
• Coverage of patches vs applications installed on endpoints?

Story

By collecting these metrics for this purpose you should be able to reveal a story. Ideally, with some help and great visuals, you can present and filter all this data on a single slide. 

For example, maybe your metrics for this particular case shows this in a visual:

7/8 users didn’t take users awareness training

5/8 users had admin rights to endpoint

30% of endpoint applications were being patched 

Those metrics tell a story. That story clearly reveals what further, layered, initiatives can be built out to drive risk reduction in this area. The next step is to have a discussion on what cybersecurity initiatives can be agreed upon and supported by the business.

• Does this justify removing admin access?
• Does this justify disciplinary actions for not taking the training?
• Does this justify an improved application support pipeline?

For the initiatives agreed upon, metrics can be captured and tracked over time to show progress. For ones that are not agreed upon, metrics should not be tracked or reported on. There is no purpose. 

Summary

A successful cybersecurity metrics program needs to be tied to purpose. Without the reason for measurement collection and reporting, it is just a bunch of numbers that will not drive and support risk change. 

When pressed to develop improved metrics reporting, push into the issue until it is clear to everyone what will need to be reported on to be successful. Just like a cybersecurity consulting engagement, if the deliverables are not identified then the engagement has a very low chance of success and providing value. 

Risk reduction is your deliverable. Metrics support how, what, when, how, where and why.