Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/10/2020
10:00 AM
Joshua Goldfarb
Joshua Goldfarb
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
50%
50%

5 Tips on How to Build a Strong Security Metrics Framework

The carpentry maxim "measure twice, cut once" underscores the importance of timely, accurate, and regular metrics to inform security leaders' risk decisions.

When designed appropriately and measured objectively, metrics are an indispensable part of a mature security program. Solid metrics can help an organization measure and track risk and performance as well as make educated adjustments and decisions as required. While most security professionals recognize and understand this, in practice, only a few organizations actually realize significant benefits from security metrics. There are many approaches to building an effective security metrics program. In this piece, I'd like to share some thoughts on a framework that has worked well for me.

Tip 1: Know your audience. Years ago, when I took a presentation seminar, I was given some very good advice: Know your audience. This advice applies to many areas, including metrics. The first step toward building a strong metrics framework is to understand who you're building it for, even if there are multiple audiences. The metrics reported to the board and executives will be different than those you use to make operational improvements and tactical adjustments. The metrics provided to customers showing that their data is protected will be different than the metrics for security management to make well-informed decisions. A good metrics framework provides the right metrics to the appropriate audiences, even when there are multiple audiences.

Tip 2: Aggregate: One great way to provide the right metrics to the appropriate audiences is to aggregate strategically. Each tier is more detailed than the tier above it, and more granular metrics roll up into broader, more strategic metrics as you move up through the tiers. As an example, consider four tiers of aggregation that I have found helpful in building out a sound security metrics framework:

œ Group: The highest-level aggregate is the group. Each group should be a broad area within security made up of different functional areas. Some examples of groups might include "Compliance," "Vulnerability Management," and "Security Monitoring," among others.

œ Area: The next-level aggregate is the area. Each area should be a specific function within security that contains one or more risks that need to be measured. Areas might be "Application Risk Assessment," "Vendor Risk Assessment," and "Training and Awareness," among others.

œ Key risk: The next level aggregate is the key risk. Each key risk should represent an area of concern and focus for the business where security is expected to measure, monitor, manage, and mitigate that specific risk. Each key risk should measure whether or not the organization has incurred an unacceptable risk. Within each key risk are one or more metrics that can help shine light onto whether or not controls are effective.

œ Metric: The metric level is the lowest level — and, in fact, isn't really an aggregate at all. Metrics should be as granular, scientific, and objective as possible, while allowing the security team to measure specific risks. Each metric should be mapped to a control and should help to measure whether or not the control is mitigating risk appropriately.

Tip 3: Map to controls. Ultimately, a good metric will help assess whether or not a control is effective at reducing risk. This has many benefits, including allowing the security organization to gain an understanding of where gaps may exist or where controls may need to be either designed or implemented differently. Of course, these benefits are only attainable when metrics are mapped to controls. It is a bit of a time investment to do so, though it is well worth it.

Tip 4: Designate acceptable values and objective ranges. If you've ever had your home or car inspected, you know that there are acceptable levels for radon in a home or emissions from a car. It isn't black or white or on or off. There is a range of levels within which the home or car passes the test, and outside of which, it fails. The same should be true for metrics. Once you have a solid set of metrics, define acceptable values for those metrics together with ranges that define different levels of risk (for example, low/medium/high, green/amber/red, or any other set of groupings that suits your organization). That will allow you to more objectively calculate risk levels for each metric, different aggregates of metrics, and in total across the organization.

Tip 5: Measure and report regularly. The carpentry proverb, "measure twice, cut once" can help us understand the importance of timely, accurate, and regular metrics. Metrics should be living and dynamic, rather than snapshotted and static. Just as accurate measurements inform the carpenter's cutting decisions, accurate security metrics inform the security leader's risk decisions. It's important to remember that the value of a given metric represents an accurate measurement only in the moment it is measured. Because of this, it's important to measure frequently and report metrics regularly. This allows the security organization to trend over time, spot abnormalities early on, and prevent additional risk from entering the organization unnecessarily.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "In App Development, Does No-Code Mean No Security?"

Josh (Twitter: @ananalytical) is currently Director of Product Management at F5.  Previously, Josh served as VP, CTO - Emerging Technologies at FireEye and as Chief Security Officer for nPulse Technologies until its acquisition by FireEye.  Prior to joining nPulse, ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Cloud Security Threats for 2021
Or Azarzar, CTO & Co-Founder of Lightspin,  12/3/2020
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Assessing Cybersecurity Risk in Todays Enterprises
Assessing Cybersecurity Risk in Todays Enterprises
COVID-19 has created a new IT paradigm in the enterprise and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27772
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in coders/bmp.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type `unsigned int`. This would most likely lead to an impact to application availability, but could po...
CVE-2020-27773
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/gem-private.h. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type `unsigned char` or division by zero. This would most likely lead to an impact to appli...
CVE-2020-28950
PUBLISHED: 2020-12-04
The installer of Kaspersky Anti-Ransomware Tool (KART) prior to KART 4.0 Patch C was vulnerable to a DLL hijacking attack that allowed an attacker to elevate privileges during installation process.
CVE-2020-27774
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/statistic.c. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of a too large shift for 64-bit type `ssize_t`. This would most likely lead to an impact to application availability, but co...
CVE-2020-27775
PUBLISHED: 2020-12-04
A flaw was found in ImageMagick in MagickCore/quantum.h. An attacker who submits a crafted file that is processed by ImageMagick could trigger undefined behavior in the form of values outside the range of type unsigned char. This would most likely lead to an impact to application availability, but c...