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: 

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."