Well, it’s November again. And in addition to gearing up for turkeys, pumpkin pie and football, those of us in IT know it’s time to gear up for something else, something probably much less pleasant: our annual budget cycle.
It’s time once again for us to enter into days-long deliberation sessions deciding what and where (in some cases whom) to cut, what projects are less or more critical than others, and what further blood we can try to wring from the proverbial stone by thinning out already scarce resources.
Around this time of year, I’m often asked by folks for help in trimming “fat” from the security budget — in other words, helping organizations figure out where it makes the most sense to cut resources based on the disconnect between resources asked for vs. resources received. But because of the way most security organizations operate, this adjustment of budget is often a harder chore than it could otherwise be. So this year, let’s look at the typical security organization — how it’s structured and funded, and why that presents a problem in terms of objective and strategic security program management and governance.
The Transparency Factor
First of all, in order to best evaluate investment in security, it’s important that the security budget be transparent – so that we can understand how, where, and how effectively security dollars are invested. Typically, this is difficult to do because the security budget is opaquely situated as a subset of the broader IT budget.
Traditional wisdom in the information security community would tell us that situating the security office within the IT management chain can lead to potential conflicts of interest. Consider, for example, what happens when a highly visible, client-facing request such as a new application deployment also carries with it a high security risk. The security organization needs to be able to push back or potentially escalate (outside of the information office, in many cases) based on the best interests of the firm. But in practice, rather than having the security function located outside of IT (for example, within the compliance, risk or financial office), it’s inside IT — and needs to stay there for operational reasons.
But this situation makes it difficult from a budgetary perspective: Unless we understand how much we’re spending, and on what, how can we know where to throttle back on spending and where to invest more? The answer is, we can’t. Our ability to effectively decide spending for the next cycle depends on two things: understanding what we’re spending now and how effective that spending is.
In order to do this, we have to first recognize that in most scenarios we’re not going to be able to change the way that our organizations structure the budget at a macro level. In other words, we’re not going to be able to move the security budget out from under IT and make it a “peer” line item. If that’s possible, so much the better, but for most of us, it won’t be.
So what can we do? Well, we can create our own budget. We can, for example, attempt to make the security spending less opaque by cataloging ourselves the hard and soft dollars spent on security — from a technology investment standpoint in terms of dollars spent on products and external services — and from a people perspective by understanding how much time internal resources spend on security activities.
Collecting this data by ourselves is not the ideal scenario because we’re effectively reverse-engineering the budget based on data available. However, it provides a few benefits: it gives us a (granted, rough) model for understanding our spending. We can use this data throughout the year to justify technology purchases that might help bring employee workloads in line, and we can also use it as a benchmark for better understanding when it comes to the yearly budget cycle. We avoid situations where we rob Peter to pay Paul — for example, scenarios where we avoid a technology purchase but increase soft costs through extra resource overhead.
Understanding what money we’re spending is the first step, but we also need some objective way to understand how effective those dollars spent are in terms of increasing the security of the organization overall. One way to do this is with honest and objective risk analysis. Risk analysis (and risk management), as we all know, is important, but it’s an exercise that, let’s face it, not most of us are either not doing — or, when we are doing it, are not doing it well. This inability for organizations to understand their own risk leads to issues with effective budgeting. Why? Because risk assessment is one of the few barometers we have to understand the effectiveness of the controls we deploy — it’s the “benefit” side of the cost/benefit tradeoff equation.
Risk assessment using an objective methodology like OCTAVE or a similar standardized methodology can of course be used to help us choose which controls to deploy. But it also has the benefit of helping us to understand how our investments in security reduce (or fail to reduce) our risk profile. By understanding how our risk profile changes based on the controls we deploy and the cost of those controls, we can understand how the investments we’ve made are paying off in terms of overall risk to our organizations. These are important data points and ones that are very difficult to get to any other way.
So ideally, through these two tools, we can get to a rough “cost/benefit” profile for our security program. We gain understanding about the cost through transparent budgeting — even if we need to create that transparency artificially and overlay it over an inherently opaque process. We gain information about “benefit” through risk analysis — understanding what the risks are gives us a rough and somewhat artificial benchmark.
Of course, both of these activities aren’t easy — we’re not likely to get there for this year’s budgeting discussions. But strategic thinking means thinking beyond where we are currently. And if we start right now, we should be able to get there for next year. A solid risk analysis will take several quarters to complete — longer if we haven’t done it before and don’t have expertise in house. But starting the risk assessment process now should get us to where we need to be ahead of next year’s budget cycle in the very worst case. As far as the transparency side, the budgeting cycle is the perfect time to start gathering data about what and how we’re spending on security technology and staff — it’s top of mind for everyone anyway, so collecting the data during the budget discussions is a good “target of opportunity.”
The seeds we sow during this budget cycle can help us avoid the pain we’re going through right now when this time comes around next year.
Ed Moyle is a manager withCTG’s information security solutions practice, providing strategy, consulting and solutions to clients worldwide, as well as a founding partner ofSecurity Curve. His extensive background in computer security includes experience in forensics, application penetration testing, information security audit and secure solutions development.