Making Security Metrics That Matter

Sunday, April 22, 2012

Robb Reck


Making security matter to the business

What are the strategic goals for your organization in 2012? Can you recite them off the top of your head? If you can't, you're not alone.

The inability of enterprise security teams to answer those questions is one of the biggest obstacles facing our discipline today, and it's the biggest reason current security metrics do not grab the attention of organization leaders.

Know Why You’re There: Business Productivity

The traditional role of security in the organization has been that of a cost-center to be minimized. Besides preventing breaches, security’s success has historically been defined by internally developed measures. We work to create best-practice metrics that show how mature the security program is, and we pass them around to one another as indications of our success. Unfortunately, those kinds of security metrics do not speak to the heart of the business.

IT has made the shift from support to delivering value. Security must follow.

In many organizations, both small and large, IT has successfully made the transition from its traditional role as a support service to driving business value. In manufacturing firms, IT has provided huge returns in implementing ERP (enterprise resource planning) and MRP (material requirements planning) systems. In marketing organizations, IT provides direct business value in improved marketing through analytics and improved CRM (customer relationship management) solutions. And in many software and solution companies, IT actually is the value the business offers, either through technical skills or solutions made by IT.

So far, security has not managed to make that same shift. We are still implementing security based on our own priorities and goals, rather than on what makes the larger organization successful. Whenever we talk about the success of our security program in terms of adherence to an industry standard, a best-practice or a framework, we’re defining our goals based on the requirements of a third party; a third party who does not have the specific interests of our organization in mind.

I am not suggesting we should abandon frameworks and build everything from scratch. In fact, I strongly believe that most security programs should be built to a framework. But it’s how we customize our specific implementation and how we view that framework that differentiates a business-enabling security program from a stifling one.

How Security Meets Those Objectives

A successful security program starts with the goals of the organization and flows from there. As an example, consider the differing needs of two organizations.

  1. A small software development shop with a couple dozen employees, selling consumer software to end users.
  2. A large manufacturing and retail organization that sells primarily to professionals and corporations.

Company 1 needs to create highly innovative software and get it into the hands of the consumers quickly, while trends are still hot. Company 2 needs a extensible program that can integrate with numerous vendors and partners without adding crushing overhead to the supply chain, and repeatable, provable procedures that can be demonstrated to customers and regulators. Can you imagine trying to implement the same type of security program for both of these companies? Unfortunately, that’s exactly what many security practitioners do. The key to success in both of these organizations is in understanding how the organization can be successful, and implementing security in a way that supports that success.

The objectives of the business should dictate the initiatives of the security team.

For Company 1, security must create efficient ways to rapidly enable the company to go to market, without suffering from devastating security breaches. For this security department, it may entail security initiatives like: (1) secure coding training for developers, (2) security consultation during the software architecture process, (3) automated code review as a part of the development process, and (4) vulnerability scanning and on-going penetration testing as a part of the QA cycle.

For Company 2, the organizational goals are to improve supply chain efficiencies, and reduce the overhead of achieving regulatory compliance. To provide support for these initiatives, security will (1) implement a federated sign-in solution to allow better collaboration between organizations, (2) create a tiering system for vendors, to maintain high security requirements for those vendors with access to sensitive information, but reducing the requirements on vendors without sensitive access, (3) ensure procedures and auditing exist for all processes that are required for compliance, and (4) ensure that disaster recovery plans are created and tested for all critical business functions, in compliance with applicable regulations.

Metrics That Make Sense… To The Business

After we’ve created these security initiatives that address our company’s goals, we need to measure it and show it off. Note the difference between the metrics used by Company 1 and Company 2, and how the security teams uniquely demonstrate and measure the value added to their business. First, we take the organization’s strategic goals. Under those goals, we list the security programs that we’ve implemented to support them. Next, we determine metrics that will explain how those initiatives help the business. The key here is that those metrics must be in words that make sense for the business, not for the InfoSec department.

(click image to enlarge)

Photobucket Photobucket

Gone are metrics like “vulnerabilities found” and “patch level.” In their place are metrics that directly address the priorities of the business. By crafting the metrics in the language of our business leaders, we are demonstrating the value of their security investment in a way that matters to them.

Context is essential. Security measures must be written in the language of the business.

Context is key. Security exists within the context of the company that employs it. Understanding the objectives, motives and vernacular of the industry are critical. A software company may want to read about features released, time to market and improved quality. But a bank is interested in fraud cost reduction, regulatory compliance and accounts added. Knowing what makes your organization successful is essential in capturing the right metrics.

In order for security to have a seat at the table in overall business strategies, the business leaders must see that security is up to the task. They want to see that security is delivering tangible value to the overall organization. Mapping our initiatives back to strategic goals and reporting our results in the language of the business are the best ways to demonstrate that value.

Cross-posted from Enterprise InfoSec Blog from Robb Reck

Possibly Related Articles:
Information Security
Enterprise Security Management Best Practices ROI Analytics metrics Information Security Policies and Procedures Enterprise Resource Planning
Post Rating I Like this!
Phil Agcaoili Robb,

Excellent article and a start at business alignment.

For Company 2 (the large company), the use of COBIT provides an industry framework to address the questions of business alignment and applicability in a structured and consistent manner.

ISO 27000 provides answers whether or not security is applied appropriately in a structured and consistent manner.

ITIL provides a means to operate and measure security's operational efficiency in a structured and consistent manner.

Where ever there are gaps in each framework, your approach (common sense) really helps focus the team.

Since you titled this article "Security Metrics That Matter," can you share the correlating metrics to your strategic goal statements? You succeeded in identifying business aligned strategic goals, but you did not include metrics.
Robb Reck Phil,

Thank you for taking the time to read this post, and for your note.

The format for displaying the metrics here might not be the most clear. The output from some examples of metrics are included in the images above.

As one example, in company 1, there is a corporate goal of delivering apps quickly. Security sets an objective of getting involved in the architecture process early. Then security sets up two metrics to evaluate the success of that goal. First, change in the amount of programs requiring rework. Second, change in the overall time to market.

While these metrics are a simple example, I believe they illustrate the point, which is that metrics must tie directly back to the company's overall success in order for them to have value outside the IT department.

The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.