CRISC – The Bottom Line (oh yeah, Happy New Year!)
No doubt my “Why I Don’t Like CRISC” blog post has created a ton of traffic and comments. Unfortunately, I’m not a very good writer because the majority of readers miss the point. Let me try again more succinctly:
Just because you can codify a standard or practice doesn’t mean that this practice is sane. There’s plenty of documentation around homeopathy, astrology, biorhythms, and other pseudosciences, but that doesn’t make them any more real.
In other words, just being able to reference a document for repeatability does not make the outcome of those acts real or valid. Almost everyone in that thread has focused on our industry’s ability to create documentation, not on the fundamental problems of creating a defensible method for risk expression.
This is why our standards blow. And yes, I’m going to expand my focus beyond CRISC/Risk IT and include the 800 series from NIST (including the new releases), the ISO 27005/31000 document, and many others. They are all very heavy on repeating the same idea that risk management is some OODA/PDCA type cycle and subsequent bureaucratic processes and very thin on the actual establishment of useful risk statements. Look, your P/D/C/A policy/procedures only need to be a few pages, and you certainly don’t need the time, expense, and hassle of certification. Spending the time and effort to tailor a several hundred page document and get people all certifiable on the subject to fit your organizational culture is just a rabbit trail of waste.
I mean, as weird as OSSTMM is – at least Pete has done a really good job of trying to provide metrics and derivative values of meaning that are repeatable.
Over the past year, I’ve had several conversations with my boss, the COO, around the same subject. He feels the same way about most tech standards in general (general ISO, etc). His experience is that the people get so obsessed with codifying their behavior, they don’t question whether what they’re doing is useful or contributory to the bottom-line. So basically, it’s a bigger problem than IT infosec.
Here’s a post in response: https://stoicsecurity.com/2011/01/03/complaints-about-compliance-frameworks/. The short of it is that the fault isn’t the frameworks inasmuch as it is the people accountable for their interpretation and implementation. I’m not disagreeing with the sentiments here, but I am challenging the comment “our standards blow.”
Or, as we used to say back when I was subject to the rigors of CMMI, “It’s a measurable, repeatable piece of crap.”