Budget is Not a Metric, But Rather a Means to Address Operational Security Requirements
Recently, I was part of a discussion on Twitter regarding security spending. What sparked the discussion was a picture of a slide from a conference presentation. The slide showed that although a specific organization had an annual security budget of $250 million, they had still been the victim of a high profile breach. This raises an interesting question: Is budget a good metric for security? In other words, if an organization wishes to improve its security posture, is spending more money an appropriate response? Further, how can an organization ensure that any additional budget it allocates to security is spent wisely?
At first, it may seem like a bit of a logical leap to approach the topic of budget in this context. If you think about it though, talking about an organization’s security program in terms of its budget is something we are quite accustomed to. We often hear people discussing security spending in the context of evaluating an organization’s security posture. For example, it’s not uncommon to hear statements such as “The organization is not spending enough on security” or “In an effort to improve its security, the organization has increased its security budget by 30%”. What seems to be missing from the discussion, however, is the answer to a slightly different question: Does the organization spend its budget effectively? Not every dollar spent will have the same impact on the organization’s security posture. That is an important point to consider.
Sometimes I think we think about budget in a backwards manner. Often, organizations say things like “I need a firewall”, “I need a SIEM”, “I need an IDS”, or “I need a DLP solution”. The organization will then communicate the business need for each of these requirements to the executives and make the case for the required budget accordingly. If a new requirement arises down the line, the organization will request more budget, which it may or may not receive.
What’s the issue with this approach you ask? Great question. Well, to begin with, our respective security programs are not tasked with things like “buy a firewall”, “buy a SIEM”, “buy an IDS”, or “buy a DLP solution”. If they were, this would be a fine approach. Rather, most security organizations are tasked with mitigating, managing, and minimizing risk to the organization. That’s essentially what security boils down to conceptually.
Give this, doesn’t it make sense to approach budget from this perspective? In other words, wouldn’t it make more sense to think in terms of statements such as “I need to mitigate risk X posed by threat Y” rather than “I need to buy a SIEM”? For example, “I need to mitigate the risk of payment card data theft posed by organized criminals”. As I’ve discussed elsewhere, including in my earlier piece entitled “Is Security An Unsolvable Problem?”, these risks can then be broken down into realistic and attainable goals and priorities that can be enumerated. This is an iterative process that occurs continually to ensure that the security program stays aligned with the risks and threats faced by the business.
You may find yourself asking: And then what? Well, if we look at the enumerated list of goals and priorities we end up with, we soon realize that we have built for ourselves a framework in which to build our security operations function. It is into this framework that we can drop all of our operational requirements. Each goal generates a set of operational requirements. These operational requirements spell out the people, process, and product required to meet that specific goal.
What does this have to do with budget you ask? It has everything to do with budget. Thinking in this manner, we see that each of our operational requirements guides us as to what we ought to be pursuing budget to address. Although people, process, and product are equally important, I will focus on the product aspect in this piece.
Each operational requirement may take one or more products to address. Similarly, each product may address one or more operational requirement. As you can see, we can quickly build a matrix that will allow us to map – and optimize – the products that best address our operational requirements. The difference here is that instead of buying products and then trying to apply them to the operational requirements we encounter, we are buying products based upon our operational requirements. In other words, each product we buy addresses one or more of our specific requirements. Further, we can ensure that we can optimize our purchases and maximize the value we get from each of our products.
The advantage to this approach is that we will spend our budget much more wisely. We are dramatically lowering our risk of purchasing a product that we cannot fully leverage, as well as the risk of encountering an operational requirement for which we did not purchase a product.
It will take some time to transform budgetary discussions from product centric to operationally centric. I wouldn’t expect this change to occur overnight, although I do see some organizations embracing it already. In my experience, however, this transformation is necessary to ensure that budget that is attained is spent in the most optimal way possible. Further, with this approach, as executives and boards see the direct correlation between increasing budget and improved security posture, they will be more likely to approve future budgetary increases.
So, getting back to the original question: Is budget a good metric for security? I would say that budget is not a metric at all, but rather a means to address operational security requirements. Wouldn’t you agree?