An increasing amount of security work these days is very academic and theoretical, rather than hands-on.  The development of risk management (a.k.a. “covering your ass”) as a serious factor driving security awareness over the past ten years has led to a massive amount of paper-generation and abstraction, going hand-in-hand with ever-more-complex attempts to needlessly quantify security realities.

Partially this stems from the desire to apply financial metrics to risk and security, partially from the need of managers lacking a strong technical background or the ability to acquire this to have easy-to-understand, purely numerical descriptions and graphs of where their money is going.

One of my colleagues recently came up with the concept of an abstract measure of security investment (time, effort, grief, etc.) — the securitron.  As in (hold hands zombie-like out front and repeat in a robot manager voice), “we’re going to need more securitrons!  Throw two hundred additional securitrons at this project!”

For some reason, this came up again during a meeting to discuss increased efficiency of risk management paperwork.  The upshot of this meeting, as with pretty much any business meeting consisting of over three people (and not taking place by the coffee machines, where most productive work gets done), was (a) use your own damn judgment, that’ s what you’re paid for, these are only suggestions, (b) if you still have questions, ask your colleagues, that’s why we sit together, and (c) when will this damn meeting end?

However, an interesting point did arise — the idea that security, risk management, and compliance work tends to end up with reams of paper that may or may not ever be read.  This was the case with all medical regulatory and compliance work I’ve ever done, as well as with pretty much every experience I’ve had in financial services since 2000.

The conclusion?  My personal view is that documentation and paperwork does not make much sense unless it’s in an easily accessible format (e.g. a well-organized database schema accessible by very flexible views to whomever wants to use and evaluate the data.)

Another very important point that my colleague raised, though, was the concept of the “thunk test” — i.e. if a security policy is dropped on a desk and makes a “thunk”, it’s too big to be of any use.  Nothing that heavy can possibly have the elegance and simplicity to be easily enough understood for practical everyday application.  At the risk of advocating the development of tired business doublespeak, I could see a use for a plainly worded non-mealy-mouthed type of goals and rules statement (“don’t leave passwords lying around.  Never talk to strangers.  Don’t pet strange dogs”) for security organizations that actually fits on a single piece of A4 paper (or at least in a document that makes no more than a soft whisper as it’s dropped.)

Now, we are working on finding a good name for a measure of the quantitative relationship between securitrons and reams of paper.