I’ve talked about security cost as the key metric to report on your security program when working with executives and the board. What we have not discussed, however, is how. This blog post will start with a reminder of the security cost metric and its components, then discuss the three implementation maturity levels.
Security Cost is a compound metric that combines four key elements:
This is your budget for security programs, controls, and people. This is generally the most straightforward metric to measure – really the one at the top of the security cost iceberg. Ideally, you're building your budget on a 0-based approach based on your risks, priorities, and business needs. Still, regardless of your budget methodology, the budget is where most teams begin and end when evaluating security costs.
This is the cost of security incidents across all six forms of loss. For this to work, you do need to apply a relatively broad definition of incident – that is, a security event that requires response from the security team to mitigate or prevent loss. This is not just a breach (although a breach is an incident). If your AI robot automatically responds to the incident, it still counts as an incident.
This is the “Cost of No”. If projects are cancelled, their scope is reduced, or the sponsoring business unit cannot otherwise recognize the full benefit of the project due to security team restrictions, that lost business benefit is your opportunity cost.
Often, the biggest and sometimes the most surprising cost of all is security friction, so we'll spend a bit of extra time here. Every security control, policy, process or procedure imposes some cost on the rest of the company. Security friction captures the costs for everyone else who does NOT report up to the CISO. These costs fall under five areas:
The objective of your security program is to optimize the combination of actual costs (Spend + Incident + Opportunity + Friction) to the lowest possible total, rather than focusing on only one section. Common traps this approach prevents include deploying excessive controls to reduce incident costs, blowing the budget, and creating friction.
The big challenge for many security leaders, even those who agree with me on the model, is how to get there. What are the steps, and what value can you derive from each step of the process? The remainder of this article will walk through the maturity steps on this journey.
Maturity level 1 is about understanding how much you have spent in the last period (however you define it - month, quarter, or year). This requires setting up systems to collect the data for each component of cost:
For spending, that should be simple; the finance team is typically reliable at telling you how much money you’ve spent.
Opportunity Costs – Review all projects that have been cancelled or scaled back at the security team's request and identify the business benefits lost. Talk to your project managers to see if any projects have been scaled back from the initial business benefit because they *thought* the security team might say no.
Security Friction Costs – Build a security control library if you don’t already have one. List all your controls, policies, and processes. (This is a great exercise to do for other regulatory compliance efforts, anyhow) In addition to the control, enabling technology, regulatory compliance, and framework fields, add columns for each of the five friction areas. For each control, first identify where you might gather that data (simple arithmetic, Help Desk tickets, ERP systems, etc.) and tackle it control by control. Wherever possible, as you find the data, automate its collection using tools such as Power BI so you can get a live view.
Once this data is in place, you can begin communicating and reporting on it as periods pass, whether monthly, quarterly, or annually. Start slow here. You don’t want to drop this number in your SMT or Board’s lap. Look at it yourself, any crazy numbers? Do they all make sense? Identify flawed assumptions and weird data before you report it.
Once you reach maturity level 1, with your incident lists and impacts complete and your control library at 80% or better, it is time to move on to maturity level 2, using this data to make good decisions and identify projects. This is the start of optimizing for the whole. As you evaluate new technology or security projects, you can now estimate the costs of all four quadrants to make the go/no-go decision. Challenge your vendors to help you reduce friction.
This is also when you start identifying and justifying new projects. Have you determined that your MFA solution is causing people to authenticate too many times? Want to run a conditional access project to reduce the number of scenarios where MFA is required? You can use the reduction in friction costs to justify that project. Want to automate containment and workstation remediation? Then you can show the decrease in incident costs to explain that one. For every project you do, every hire you make, you should be able to show a reduction in overall security costs.
This will really start to have an impact come budget time. CFO wants you to reduce the budget by 20%. Great. Plan those budget impacts realistically and show the projected impact in incidents, friction, and opportunity costs. Demonstrate, with data, the effect on the company. Rather than commit to reducing the budget by 20%, commit to reducing overall costs by the same amount.
Once you’ve spent some time in maturity level 2, inevitable questions start to come up. How do we show the potential impact of a new control in preventing a significant breach that has never happened before? How do we demonstrate the effect of a new resiliency approach to ensure we can recover more quickly from a CrowdStrike-like outage across a wide swath of our technology footprint?
Once you start asking these questions, you’re ready for maturity level 3, risk. Of the four components of the framework, 2 have significant risk components – Incident costs and friction. By quantifying and reporting these risks in a supportable way, you can begin to show the impact of risk reduction. For both sections, the FAIR risk taxonomy is a good choice, but it is not the only option for building the risk portion of the program. At one point, FAIR was a challenging taxonomy to implement; however, newer tooling, ranging from Excel-based spreadsheets with built-in Monte Carlo simulations to purpose-built tools, is available from free to enterprise-class. There is a range of other risk quantification frameworks and tools available on the market. Still, the main feature needed is to break the risk into a dollar-value range, supported by data, and to be adaptable and updateable at your reporting frequency.
Once you’ve got your framework, craft a set of risk statements for the most likely and most impactful risks in your organization, covering both the incident cost and security friction sections. Good risk statements cover the following:
Threat – who are we protecting from?
Asset – What is it we are protecting?
Method – What is the behaviour you’re worried about?
Impact – What are you worried about happening?
As examples of good risk statements in mining, we might go with “A financially motivated threat actor impacts operational technology systems at site, causing a loss of view and/or control” for a potential statement on the incident costs side. In contrast, on the security friction side, “An EDR Security Vendor impacts all endpoints via a bad content update, causing all systems to suffer a Blue Screen of Death”.
Once these statements are crafted, individual risk models can be created and aggregated to provide a view of the cost of friction incidents. The big difference here is that, since we’re forecasting the future rather than counting the past, we won't give a single number; instead, we’ll provide a range of potential costs based on the simulations. Statements like we expect security friction to cost the company between $8 and $10, with a most likely impact of $8.5M. This gives an accurate view of the future without locking into an overly precise (and incorrect) prediction.
Once you’ve built out your future-looking model, you can compare these risk values with board-approved risk appetite statements and evaluate and account for the risk-reduction value of projects.
By proceeding in a measured, data-driven way, all organizations can begin to see the benefits of treating security costs as a key metric that supports and measures the effectiveness of the cybersecurity program. By using a measure the business is already familiar with —Dollars (or Euro, Peso, etc.). You begin to align the business objectives with the cybersecurity program objectives. We also provide a frame for good storytelling. The best storytelling in executive and board meetings is directly tied to what they know.
I encourage you to give it a try. Let me know how it goes. As always, I'm happy to help you along the journey should you get stuck.