Security Performance Reporting

Command guidance for CISO-to-stakeholder communications

Written by John Hellickson, Field CISO, Coalfire

There is tremendous urgency for security professionals to do a better job at communicating security program performance to enterprise stakeholders and boards of directors. For the Coalfire Cloud Advisory Board (CAB), effective reporting on this level is mission-critical for cyber teams, and was a dominant theme throughout the comprehensive report, Smartest Path to DevSecOps Transformation.

In the cloud, where everything is programmable out to the edge, protecting code becomes the mission. As CISOs and DevSecOps team leaders, our effectiveness in reporting security program performance – especially in terms of application security – has never been more paramount. Digital transformation compels us to prioritize the security of product lifecycles, and to educate our stakeholders by integrating business objectives into continuous security oversight and reporting.

“For non-technical stakeholders, ROI calculations and cyber performance metrics have been murky at best for decades. However, with a shifting economy pushing us into a cloud-dominant computing environment, we need to show our fellow officers, directors, team leaders, employees, and customers how to think about measuring what we do.”

– Tony Spinelli
Coalfire Cloud Advisory Board
CSO, Urban One, Inc.
Director, Peapack Bank
Director, Blue Cross Blue Shield

My co-author on the report’s chapter on reporting, Tony Spinelli, emphasizes that cyber leaders need to embrace new behaviors in their communications if they want to be understood by enterprise decision makers:

First, shift your talking points to reflect functional business objectives instead of security objectives. Second, adopt a “defensible” mentality instead of obsessing over being “secure.” Third, streamline tools to ensure technology and people are being deployed efficiently and effectively.

Secure vs defensible

We can build a defensible application. But can we build one without a single point of failure? Not likely. Security needs to be reported on as a race we run every day to beat the bad actors, who are working feverishly to break into our system while avoiding detection.

Two critical measures to capture defensible positions in reporting are:

Dwell time reduction

This concept helps to remove any unrealistic expectation that security is infallible. Boards can be conditioned to judge security performance on how quickly we identify and contain threats. Prioritize threats and vulnerabilities that will matter to the board, then figure out dwell time reduction tactics and the simplest ways to measure and express them.

Failsafe measures

These contingencies and practices are designed to respond to and minimize damage from a specific threat unique to the enterprise. This will get all leadership involved in translating resources into security posture and connecting simple and straightforward metrics to each priority element.

Zero trust

Zero trust is a network architecture. Cyber teams need to work with developers, starting with the first scrum, to build failsafe measures into every app, especially those that come into human contact. Zero (or at least minimal) trust is also a management philosophy that can be illustrated and understood by all stakeholders in a world without perimeters. Everyone from the leadership team to the end user can comprehend the strict default position that no device or touchpoint can be trusted, even if connected to the corporate network, or even if previously verified.

Tool baggage

The “buy tech/fix problem” mentality has been around for decades. With hybrid cloud environments and questionably secure code thrust out to the edge of networks, this mentality is dangerous for security leaders.

In direct conflict with the perpetual motion of cloud security, tool baggage exacerbates the point-in-time mentality that we need to get away from. CISOs fighting for their share of budget that later appears on a spreadsheet of capital expenses is not a productive way to implement a continuous integration mentality into your reporting.

Having a multitude of products means you’re going to need a multitude of people to know them and gain their utility. Again, expense line items of security product purchases and more headcount to support those expenditures is not the way you want to manage your program, report on it, or to have your own performance judged.

Top tips for CISOs reporting to the board:

• Break the mold: security is not point-in-time and requires continuous metrics.
• Frame the risks: Connect enterprise products with the code that creates them to show how security protects each product and its corresponding revenue along its unique journey to the customer.
• Executive dashboards: Keep it simple with minimal factors to track, and stay away from the highly technical. Build a risk register with factors determined by the risk priorities that have the greatest impact on your organization.
• Align with business unit leaders individually: Learn their strategy, align security into their objectives, and get their support before stepping into the boardroom itself.
• Build capability: Include in your reporting narratives about DevSecOps team integration, your philosophy on enterprise risk priorities, and how you can compare your security operations with peers, with competitors, and within regulatory frameworks.
• Build support: Include processes correlated to costs and revenues that clearly show business impact.

This is a journey, one of technology and methodology adoption, and of cultural change. It all boils down to keeping software secure. Sounds simple, but this is a profound change from the way boards of directors have traditionally viewed security: criminals breach inside a system and steal data. Now the very lifeblood of our enterprise – the product code – is outside the disappearing perimeter, exposed everywhere.