by alex on March 1, 2011
Mike Rothman’s “Firestarter” on “Risk Metrics are Crap“.
It’s very difficult to argue with a poorly constructed argument. Especially when I have no idea what a “risk metric” is. But best as I can tell, Mike’s position is that unless you are smart and/or have strong resources allocated to your InfoSec team, things like metrics, GRC, application security, SEIM, and a “host of other security processes or technologies.” are “science projects…”
Meaning, I suppose, that they provide no “pragmatic” use to security departments (whatever pragmatic means).
Problem is, for many folks, metrics, risk management, appsec and other “security processes or technologies” can and do have significant value. In fact, in terms of managing a large, disparate enterprise, the data gathering process for risk analysis alone can be more valuable than the result (experience contrary to what Rothman writes in comments: “the value of the (assessment) benefit is outweighed by the cost of gathering the data.”).
That said, it’s a shame that his argument is poorly constructed because, by in large, I have to agree that there’s plenty of poopy risk statements to pick on. As I said in my CSO Magazine interview (shameless self promotion) and in my RSA Risk Management Smackdown panel – there have been times when I’ve counseled an organization to put off making risk statements until their visibility into their environment is much better. In the public record you should be able to find past statements where I say it’s better for a small business to focus resources away from risk assessment when the required assessment was a bureaucratic quest rather than a quest for knowledge or wisdom.
Bottom Line, for risk and metrics, Rothman shouldn’t generalize for the sake of sensationalism and marketing. And he probably shouldn’t be doing that for other security processes and technologies beyond risk analysis and security management, too. But as a consulting firm, what Securosis could/should be doing is giving people help – helping them recognize their organizational maturity, and helping them understand what resource allocation is or isn’t appropriate at various levels of maturity. Just a thought.