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/27/2020
10:00 AM
Curtis Simpson
Curtis Simpson
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

How to Get the Most Out of Your Security Metrics

There's an art to reporting security metrics so that they speak the language of leadership and connect the data from tools to business objectives.

Much is at stake when reporting security metrics. This data is critical for management to evaluate security programs and justify further investment in security tools. The value of metrics comes from their ability to tell larger stories about a business that resonate with key stakeholders. You lose that opportunity if security teams use the wrong metrics — those that are overly technical or detailed — or miscommunicate the right metrics. Here are some of the more common reporting mistakes and best practices for avoiding them. 

Generic or Overly Technical Metrics
This problem involves generic reports that are focused on the number of attacks that took place in a given time period and the percentage that were prevented versus those that had an impact. Those numbers don't reflect the maturity of a security program.

Metrics that are shallow or too high level don't effectively tie back to specific business strategies or critical objectives. They have limited value and don't track the overall effectiveness of security operations. Relying on simple metrics to tell the larger risk story can have an unintended budgetary impact. For example, if consistently reporting that 99% of known cyberattacks are being prevented, why would leadership support a budget to add a new solution to the security portfolio?

On the flip side are metrics that are too technical or detailed for the board to understand. For instance, leaders don't need a breakdown of each vulnerability by operating system or platform. Why? It's not clear how that information relates back to critical business functions or strategic objectives — in other words, the language of the business. Faced with data they don't understand, board members not only will lose interest in the conversation, they may even question the security leadership's strategy.

Connect Metrics to Business Outcomes 
A more effective way of reporting to leadership is to speak directly to the risk level associated with critical business functions, the core contributors to this risk, and the actions being taken. For example, security leaders should be ready to answer these questions: 

  • What kinds of attacks are we prepared to defend against? 
  • Where do we have deficiencies as an organization, and what risks to business operations are elevated as a result? 
  • What is being done to reduce such risks (from a business and technology perspective)? 
  • Has a risk grown in significance? 
  • What is the proposed strategy to reduce the risk to an acceptable level? 

The storytelling needs to focus on business risk rather than technical facts. 

Let's dive into an example. Company X has identified that nontraditional competitors are taking market share by solving long-standing complaints or requests from customers. One of the requests is the ability to place online orders 24/7 and to have such orders fulfilled within 24 hours.

From a security practitioner's perspective, this can be interpreted as "no critical business operations or capabilities supporting online ordering or fulfillment can be affected by a cyberattack and if unavoidably affected, must be rapidly recovered." When viewed from this perspective, the metrics of value become clear. What are the top risks to enabling and protecting related critical business capabilities and the underlying supporting technology? What is the likelihood of risk actually happenning? What is the potential monetary impact associated with the likely event, and what are the key risk contributors? What is already being done, and what is the proposed cross-function strategy to mitigate residual risk?

Metrics Overload
Often, security teams will deliver an overwhelming amount of metrics and data to the technical teams responsible for fixing these vulnerabilities through software updates and/or configuration changes. For example, these metrics often detail the number of critical, high-, medium-, and low-risk vulnerabilities across the entire environment with little to no logical prioritization.

But not all vulnerabilities are equally important or have equal business effects. Generic metrics with highly extensive reports listing the details and remediation actions of all identified vulnerabilities often fail to result in a meaningful outcome. Executives reading them can get overwhelmed with the amount of information or they can misunderstand it. Too many metrics can deter people from taking action or cause miscommunication, delaying remediation and increasing the likelihood of exploitation and business impact.

Focus on the Biggest Risks
Instead, help technical teams understand the most important vulnerabilities that require their attention and what progress needs to be made. Again, this needs to be tied back to key business objectives and prioritized based on those functions. 

Let's refer back to the Company X example and its objective to deliver 24/7 online ordering and order fulfillment capabilities to its customers. Vulnerabilities with a high potential for exploitation and the potential to significantly affect these critical business operations should be prioritized for remediation. It's also important to prioritize cases where executing a specific remediation action (for example, updating a software package on all PCs to the latest version) will have a significant risk reduction impact against common attack vectors being exploited by bad actors.  

People presented with a massive list of objectives often are overwhelmed to the point that no action is taken, or too few actions are taken to make a difference. Instead, presenting people with a list of specific actions to take first, next, and last, and specifying how these actions will directly affect business operations, lets people take action and feel a level of accomplishment. This can keep the team engaged. 

There is an art to reporting security metrics so that they speak the language of leadership and effectively connect the data from security tools and processes to key business objectives. It's crucial to articulate the metrics well so business leaders understand the significance and recognize the true effect the security program is having. Without this understanding, security teams, budgets, and processes could be overlooked, which increases security risks to the company and could negatively affect brand reputation and customer trust.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "7 Steps to IoT Security in 2020."

As the CISO at Armis, Curtis Simpson is responsible for ensuring that the Armis product continues to maintain its high standard and vigilant focus on platform and customer security and privacy. Prior to Armis, he was the CISO at Sysco, a Fortune 54 corporation. ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
The Yellow Brick Road to Risk Management
Andrew Lowe, Senior Information Security Consultant, TalaTek,  11/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: He hits the gong anytime he sees someone click on an email link.
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
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7779
PUBLISHED: 2020-11-26
All versions of package djvalidator are vulnerable to Regular Expression Denial of Service (ReDoS) by sending crafted invalid emails - for example, [email protected]-----------------------------------------------------------!.
CVE-2020-7778
PUBLISHED: 2020-11-26
This affects the package systeminformation before 4.30.2. The attacker can overwrite the properties and functions of an object, which can lead to executing OS commands.
CVE-2020-29128
PUBLISHED: 2020-11-26
petl before 1.68, in some configurations, allows resolution of entities in an XML document.
CVE-2020-27251
PUBLISHED: 2020-11-26
A heap overflow vulnerability exists within FactoryTalk Linx Version 6.11 and prior. This vulnerability could allow a remote, unauthenticated attacker to send malicious port ranges, which could result in remote code execution.
CVE-2020-27253
PUBLISHED: 2020-11-26
A flaw exists in the Ingress/Egress checks routine of FactoryTalk Linx Version 6.11 and prior. This vulnerability could allow a remote, unauthenticated attacker to specifically craft a malicious packet resulting in a denial-of-service condition on the device.