Gunnar’s Flat Tax: An Alternative to Prescriptive Compliance?

by alex on January 14, 2011

Hey everybody!

I was just reading Gunnar Peterson’s fun little back of the napkin security spending exercise, in which he references his post on a security budget “flat tax” (Three Steps To A Rational Security Budget).  This got me to thinking a bit  –

What if, instead of in the world of compliance where we now demand and audit against a de facto ISMS, what if we just demanded an audit of security spend?

Bear with me here…. If/When we demand Compliance to a group of controls, we are insisting that these controls *and their operation* have efficacy.  The emphasis there is to identify compliance “shelfware” or “zombieware”^1.  But we really don’t know other than anecdotes and deduction that the controls are effective against, or alternately more than needed for, a given organization’s threat landscape.  In addition, the effective operation of security controls requires skills and resources beyond their rote existence.  We might buy all these shiny new security controls, but if our department consists of Moe Howard, Larry Fine, and Shemp Howard, well…

Futhermore, there are plenty of controls that we can deduce or even prove are incident reducing that are *not* required when compliance demands an ISMS.  These controls never get implemented because business management now sees security as a diligence function, not a protection function.

So as I was reading Gunnar’s flat tax proposal, I started to really, really like the idea.  Perhaps a stronger alternative would be to simply require that security budget be a “flat tax” on IT spend for a company.  Instead of auditing against a list of controls and their existence, your compliance audit would simply be an exercise around reviewing budget and sanity of security spend.  By sanity, I mean “this security spend” isn’t really on trips to Bermuda, or somehow commandeered by IT for non-security projects.

Now we can argue about how much that tax would be and other details of how this might all work, but at least when I think about this at a high level it’s starting to occur to me that this approach may have several benefits.

  1. It would certainly be simpler to draw an inference as to whether more security spend increases or decreases # of, and impact of, incidents.  Not that this inference still wouldn’t be fraught with uncertainty, just “simpler” and I would question whether it would be less informative than insisting that a prescriptive ISMS has never been breached.
  2. If the “spend” audit consisted of “were the dollars actually spent” and “how sane the spending was” – it would still be up to the CISO to be able to have a defensive strategy (instead of having just a compliance strategy).  The “spend” could still be risk-based.
  3. Similarly this would help enable budget for effective security department investments ( like, say, a metrics program, training, conference attendance, threat intelligence, etc… ) that would otherwise be spend above and beyond what is currently “required”.
  4. This spend would allow security departments to be more agile.  If our ISMS compliance standards don’t change as frequently as the threats they’re supposed to defend against – it’s pretty obvious we’re screwed spending money to defend against last year’s threats. But a flat tax of spend would allow security departments to reallocate funds in the event of new, dynamic threats to the environment.
  5. This might help restart the innovation in security that draconian security standards and compliance requirements have killed. Josh Corman (among others, I’m sure) is famous for pointing out that compliance spend stifles innovation because budgets are allocated towards “must have’s”.  If you were a start up with an innovative new security tool, but it isn’t on the radar of the standards bodies (or won’t be until the new req’s 3 years from now), only the very well funded organizations will buy your product.  If I’m a CISO with a weaker budget and want the innovative product that my compliance masters don’t require, I’ll never buy it –  all my budget is spent trying to prove I can defeat threats from 2 years ago.

1 Compliance shelfware is a security spend that is done but never implemented.  Compliance zombieware is a control or security spend actually implemented, but never really utilized.

“Of course we have log management.  We have to in order to be compliant.  But it’s just zombieware, nobody ever actually reads those logs or does analysis on them…”


Hmm, I’m concerned that this rests on a lot of undefined benchmarks — like “sanity,” “efficacy,” and even “security.” I love the point that if your security team is Larry, Curly and Moe, it doesn’t matter how much of your IT spend you pay them.

But when you try to categorize security spending, it gets messy, especially if you’re trying to amortize spending on a switch, for example, because there are some security settings in it. I’ve tried to do that exercise to calculate our real security spend, and I decided to take up naked polar bear dentistry instead.

I could buy 100 kilobucks’ worth of antivirus, which is an obvious, well-known industry standard, or I could hire a team of pentesters to do manual attacks every week (but not fix anything they find). Which one is the “saner” spend?

by shrdlu on January 14, 2011 at 3:36 pm. Reply #

I’m *so* glad people are talking about the value of understanding where security money is being spent relative to priorities or IT spend or business spending.

While I sympathize with SHRDLU regarding the pain and messiness of the task, given current systems, it’s really not more complicated in principle than many other cost accounting problems that have been solved elsewhere. Anyone familiar with Activity-based costing (ABC)??

As a start, it would really help of people with cost accounting and economic analysis backgrounds were working on this. It would also really help if it were built into enterprise financial systems.

Here’s a link to a preso I gave years ago at Mini-metricon about measuring total costs and how to make use of that information.

by Russell on January 14, 2011 at 6:58 pm. Reply #

Hmm. A “flat tax” on IT spend would unfairly tax the little guy who doesn’t spend anything on security now. You’re not against the “little guy” and “small business” now are you? I think we need a “Progressive” security tax such that the “Rich” will spend way more on security than the little guys. Oh! In fact, we could take money from the evil “Big Corporations” and give it to the little companies such that they could have some security too! It’s not fair that the successful big corporations have all the security and the poor little companies can’t afford any.

Of course, we’d need to have some central governing body control this “redistribution” of security funds from one company to another….


by Jack on January 14, 2011 at 7:09 pm. Reply #

As Dan Geer pointed out, around twenty minutes into the fifth episode of Marcus Ranum’s The Rear Guard podcast, we may benefit by moving from cost/benefit analysis to cost/effectiveness analysis.

The problem with the former is at that they sometimes does compare easily (“Do you want another year of life or a million dollars?”), whereas the latter focus on maximizing the effect of the money we’re going to spend. Simply another way of stating the auditing of security spending that Gunnar pointed out.

by Oddbjorn on January 16, 2011 at 2:51 pm. Reply #

That’s interesting in terms of enterprise-wide costs. But what about line of business oriented controls? When you have multiple internal organizations delivering services that need to be secure, how should we decide how much we’ll spend with each?

Eventually that may trigger a good situation, where LOBs that require less security money are able to put more initiatives forward, but I can also see the CSO being brought to internal political disputes for budget.

Interesting to think about the implications and how to operationalize a model like that.

by Augusto Paes de Barros on January 17, 2011 at 9:12 pm. Reply #

Leave your comment

Not published.

If you have one.