Gunnar's Flat Tax: An Alternative to Prescriptive Compliance?
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.
- 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.
- 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.
- 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”.
- 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.
- 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…”